Explaining the difference between Posts and Pages to new users is time consuming and often frustrating. We’ve all done it, have our best/fastest version of the talk down pat, but it still takes longer than it should to get many new users to the point of understanding the difference.
Back in 2.7, when we set up the left navigation we put Pages at the bottom of the content nav section because in testing 2.5/2.6 so many people complained about accidentally clicking Posts/Pages by accident because they were close together in the old UI and both started with P (blame it on capital_p). Because of this, Pages falls below the less-frequently accessed areas of Media and Links, and people don’t necessarily see it right away because they expect it to be higher up.
I’ve been testing out two changes to the left navigation aimed at reducing these two issues on my test blog for some time now, and have been using it during demos with both new and existing users to great success, so I think it’s time to propose it for core.
Change 1: Change the Posts label to Blog. All Posts can remain as is, or could be reduced to just Posts, since the reason we added the All in the first place was that Matt thought it looked weird to have the same word shown twice.
This change reduces the amount of time it takes me to get a new user really understanding the difference between posts and pages by about 75% (very informal testing, have kept track with about 30 new users by just keeping an eye on the computer clock to see how long it is before we move on). The dynamic blog/static site difference is much easier to grasp when they see that familiar word Blog instead of Posts because “posting” is an action that applies even to static content, and even posts are displayed in web pages (vs Pages).
Change 2: move Pages up the menu to sit below Blog, so the two most important content types are at the top. Since they wouldn’t look similar (ha ha capital_p) there would be much less risk of accidental misclick based on letter shape (poor manual dexterity would not be affected, but in that case those people are already clicking the wrong things, right?)
I’ve attached a screenshot showing what the navigation would look like with these changes.
One of the new features in WordPress 2.7 (currently in an almost-beta development state) is a feature we’ve been referring to as the Favorites Menu. The idea was that instead of having just a write new post/write new page button on the Dashboard, there should be shortcuts for the screens you use the most accessible at any time so you have one-click access to those screens. The plan was to allow users to decide for themselves what would go into this menu via a configuration interface, but we weren’t able to make that happen in time for this release, so for 2.7 this will be more of a shortcuts menu than a favorites menu. That means we’re going to choose the 3-4 most commonly used screens and include those shortcuts in the dropdown menu. That’s where you come in.
For WordPress.com, we can see which screens get the most traffic, but for self-hosted sites running software from WordPress.org we’d just be guessing. Also, in some cases, even though a screen is accessed frequently, it’s only one click away in the main navigation anyway, so might not be needed in the shortcuts menu. With that in mind, the poll below lists some of the main screens in the WordPress admin interface. Please select the ones you would most like to have in the shortcuts menu. You can choose as many as you like, but please limit yourself to three or four or your vote will be diluted. If there is a screen we didn’t include on this list, enter the screens you want to suggest in the Other box. Note the poll choices use the navigation language of 2.5/2.6 so that people who haven’t downloaded 2.7 won’t be thrown by the new labels.
When Liz and I put together the navigation sections for Crazyhorse, we didn’t anticipate how strongly people would react to it (positively) or that it would be merged with the 2.7 development effort. We had been thinking of it as more of an experiment that would lead to change later on rather than a primetime-ready application, which is why some of the things we included were non-functional or required additional thought. As people who saw our WordCamp presentation know, many of the decisions we made in designing Crazyhorse were specifically chosen to elicit information during usabiliy testing rather than being intended as a final design.
So now I work for Automattic, 2.7 is under development, and some of those things that “required additional thought” are on my list of to-dos. At the same time, the members of the development community who’ve downloaded the nightly builds have been commenting on various features and making suggestions. In order to collect as much feedback as possible, I’ve posted a survey with a few variations of the Crazyhorse navigation to see which groupings/labels people prefer. Who knows, maybe this will wind up being the first in a series of interface surveys. If you are a WordPress user and you care about that sort of thing and want to be a part of the 2.7 effort, take the survey.