I accidentally stumbled on the second most useful plugin I’ve ever seen for WordPress. The first, of course, is W3-Total-Cache. If you’re not using it, you should, as it’s incredibly powerful and makes your blog about as fast as it’s possible for WordPress to be.
However, the second most useful plugin I’ve ever found for WordPress is Editorial Calendar. I don’t write a lot on my blog, and I’ve been trying to get better at it. But one thing I’ve really wanted to do was be more organized about what and when I post. I’d like to have my content be a bit more regular; for example, I’ve got a few posts about Scotch PHP and I’d like that to be weekly. Another “series” of posts I’ve been doing are Netflix Reviews, which I also want to be weekly (I watch enough Netflix for it to work, frankly). And, of course, I’ve got quite a few bits of information about transsexual transition I’d like to share as well.
But because I don’t write often, I want to spread out my writing. My previous method was to put a note to myself to write something in a week, but I’m never available then. Another idea was to use Scheduled Posts, but that’s hard to visualize.
Editorial Calendar lets you see your WordPress Posts on an actual calendar, and let’s you drag-and-drop your articles from one date to another. So now, not only can I write when inspiration hits, I can make sure my content is properly spread out, giving me time to refine and update my content between my first draft (written today) and the scheduled final draft (in two weeks). But that’s not all!
It turns out that the author of Editorial Calendar has made something even more useful for site designers. Might I present the WordPress Editorial Calendar Statistics Site.
Many applications ask for information about your blog or computer: monitor resolution, update frequency, etc. All really useful data, but not everyone wants to share. Frankly this is the fault of the data gatherers, who not only rarely want to tell you what they want, but rarely do they share why they want it or more importantly, share the data afterward. Zack, one of the developers of the plugin, has taken the alternate route: not only has he told us exactly what and why he’s capturing data, he’s also provided the data itself.
How cool is that?
Not only can you now help them develop the plugin (for example, I’d rather have shorter days as I won’t have more than one-post-a-day anyway) by seeing it’s actual useage pattern (and therefore provide defaults that actually work for everyone).. but you can also use their data itself! I write web applications as a second life (when I’m not doing Linux System Administration) so this data is incredibly useful. The common wisdom on the Internet is that 968px is a excellent width for content; now you can see that 98% of users of the plugin can see 968px wide. That’s useful to know! Only 50% of users have windows tall enough to see more than 500px high. Useful as well! 62% of users use Windows, but only 1% use Internet Explorer. Good to know!
When designing user interfaces, it’s nice to know I can use 968px wide and not worry too much about IE quirks… to a point.
The only problem with this data is it’s self-selected. Because we have to opt in, the data is going to bias to those who run open source browsers with high resolutions; we’re more comfortable sharing data. Which is why so many operations choose to simply take the data without asking, to get a more representative sample.
But this is still useful, as the type of people willing to share the data are also the type of people who care about these types of metrics… so it’s more useful overall.
