For readers who aren’t familiar with the process behind usability testing, here’s an overview. First, determine the scope of your test and create a test protocol/script. Determine the audience segments to be included in the test group(s), and begin recruiting. Recruiting may mean hiring an agency to find participants, but for testing WordPress, it makes more sense to recruit from within this community, so that means making a screening survey, reading all the responses, segmenting the respondents into categories and contacting people until you’ve filled your desired quotas (for whatever segments you’re seeking, such as newbie, experienced user, developer, CMS user, photoblogger, mobile user, etc. ). Then come the test sessions.

Depending on what is being tested, these last anywhere from half an hour to an hour and half apiece. Sessions are generally recorded using screen capture and web cam, with a video camera for backup. The moderator(s) generally take notes during sessions and/or (depending on what software is being used for the session capture) set markers in the video to indicate task completion, comments of interest, etc.  In some cases, auxiliary test methods such as eye-tracking may be included. When the sessions are complete, the results are analyzed. All the notes and videos are reviewed, patterns are identified, and ultimately a report is written and the feedback informs the next round of revisions.

Some people think it shouldn’t take much time to do all this. I’ve lost count of the number of people who cite an old article by Jakob Nielsen that says you don’t need to test with more than 5 users because usability issues become clear right away. While I’ve found that to be generally true, when your user base is as diverse in experience level, usage, platform  configuration, language (right to left languages have a pretty different experience) and demography as the WordPress community is, 5 users really isn’t enough to get a clear picture. We try to test with at least a dozen people each round, but then we are limited to a geographic region (test in NY, test in SF, or test wherever we can schedule enough people back to back to make it worthwhile), while WordPress users are located all over the globe.

To address this, we’re introducing a set of new contribution opportunities to expand our usability testing program. As with development and graphic design, we’re going to create an infrastructure to allow community participation in usability testing on a regular basis and in a much broader capacity than existed before, when it was limited to announcements that we needed participants in x city on y date. We’ll be looking for volunteer moderators as well as participants, hopefully from all over the world.

Moderators. Observational usability testing isn’t rocket science, but neither is it a simple task to reduce bias. Because of this, at first we’ll choose only moderators who have professional experience conducting usability tests. People who conduct testing for design agencies, software companies, usability consulting firms and the like will be our first round draft picks. In the future, when we have a group of regular volunteers and have ironed out any kinks in the process, we’ll ideally match up experienced testers with aspiring ones, using a mentorship model to increase the number of people who can contribute in this fashion.

Participants. If you use WordPress, chances are you could participant in a usability test at some point. In some cases we’re looking for particular behaviors (people who upload large video files, people who blog from their iPhone, people who manage more than 5 blogs, etc.), while other times the behaviors we’re looking for are much more common (do you have widgets in your sidebar, have you changed themes in the last 6 months, is there more than one author on your blog, etc.).

So how will these opportunities come into play, and how will it make WordPress better?

We’ll start with the moderators, and try to get volunteers with a decent geographic spread. Then, we’ll start signing up potential test participants in those areas (though we’ll also allow at-large registrations, since traveling testing will still be happening). We’re working on a registration process for potential participants. You’ll enter your basic info (location, contact info) and answer some questions about your WordPress usage to be entered in the database, and when there’s a testing opportunity coming up that’s appropriate for you, a local moderator will get in touch to see if you’re interested. Further down the road we may experiment with remote testing and other methods, but for now, this approach will broaden the geographic scope of our testing.

All moderators will follow the same test protocols and script, and their results/reports/video will be reviewed and collated, with a composite report (including the protocol/script that was used) published to the community. This will provide designers and developers with broader feedback during the dev cycle, and will allow the wider community to both understand and participate in the testing program.

If you’re interested in being a moderator during this initial phase (meaning you do it professionally), send me an email and introduce yourself. If you’re interested in signing up as a potential test participant, watch this space. We’ll post a link to the registration survey once it’s ready.

As several people have rightly pointed out, the Fluency-style designs not only took the top spot, but in combination added up to a higher percentage than any other. We’re not focusing solely on that statistic, though, because had other designers submitted multiple versions, the numbers might have looked different. What was most interesting for me was checking in on the votes over the course of the two days the poll was open. The top three (Fluency-dark, Current 2.7, MT) kept beating each other out for the #1 spot as they cycled back and forth through the top three slots, and had the poll closed on time (left it open a little longer in case anyone translated the time zone incorrectly), the order would have been a bit different.

What’s more interesting to me is the overall style that seems to be preferred among voters, as Matt’s comp has some stylistic similarities to Dean’s (see image at left). It also would be interesting to know how many of the votes for the current 2.7 interface were based on thinking it looked the best vs. how many were votes against changing the interface at all so soon after the 2.7 redesign. If you want to comment on what you liked best and/or least about any of the designs, this thread is a good place.

So what happens now? However we look at it, the Fluency-style designs clearly have a lot of fans. Then again, so do the designs of Matt Thomas (he’s behind the current style of 2.7, remember, in addition to the comp labeled MT). To give the interface the attention it is due, and to take seriously some of the interface feedback around usability and accessibility, we’re going to leave the looks alone for 2.8. It’s our guess that a revised style will make into 2.9 early in the development cycle to allow us plenty of time for user testing and revision. How close it winds up being to the comps submitted in this design tweaks challenge will depend, but in the meantime:

Congratulations, Dean J. Robinson, on winning the vote!

Below are the links to the screenshots that were submitted. Please review each one (I’d open them all in tabs so I could look back and forth while they are all large size, because the voting poll just uses thumbnails), then choose the one you think looks the best/is the most usable.

This poll was supposed to close at 8pm NY time on Tuesday (today), but we’re going to leave it open for an extra day. The voting poll will now be closed at 8pm NY time on Wednesday (that’s 2am Thursday, UTC). If you want to discuss the entries’ pros/cons, this thread would be a good place.

Current: The existing interface, for reference

KM: Current nav, header elements moved

AN: Current nav, file folder style header

KD: Current nav, modified header style

JJ: Swap blog title and favorites menu

DR1: Fluency style, dark

DR2: Fluency style, medium

DR3: Fluency style, light

IK: Nav layered over dark background

GB: Modified nav/header intersection

MT: Modified nav and header

Results will be posted the day after the polls close.

ACT I

Jane: It is a thorn in my side that the blog name header is above the “dashboard” nav section in the admin, since in MU installations and with plugins (like stats), things in the Dashboard section span multiple blogs. Makes more sense for the header to head only the per-blog content area.

Mark: I agree about the header. “This is the menu, this is the content.”

All: Yep.

Five minutes later…

Mark: What do you guys this of this quick mockup I just did, playing with the admin header?

Jane: I like it that the nav is not under the header. Might need some styling help. I was also thinking maybe the favorites menu should drop down into the white h2 area by screen options/help tabs.

Ryan: Menu color to the top with blog title pushed over and favorites next to screen options sounds quite nice.

Jane: I’ll ask Matt Thomas if he could style it [ed. note: Matt Thomas created the visual style for 2.7], and we can see what people think, maybe post on wpdevel for feedback.

Ryan: If it’s quick, maybe we could even get it into 2.8.

ACT II

Matt T: Here are some comps based on what you told me.

Jane: Cool, but where are Screen Options and Help tabs?

Matt T: Still working on that.

Jane: Hm. Wonder if there’s time to open this up to community designers? I know we’re in freeze, and it’s no notice, but you didn’t get any notice either when we dropped this styling request on your lap a few hours ago. That’s the way open software development works: sometimes the best ideas come at the last minute!

Matt T: I’m all for letting the community take a stab at it. Especially if they come up with something brilliant to do with the Screen Options and Help tabs.

Jane: I’ll ask Ryan about release date and see if there’s time. I know they wanted your style recommendations today.

Act III

Ryan: Tuesday is probably doable, no later than that for final delivery of style and any gradient graphics, etc.

Jane: Awesome! People will hate me for the short notice after the has-patch marathon, but since it’s a small project and over the weekend, and wasn’t even something anyone was planning until a few hours ago, I’m *really hoping* people will take this for what it is, an attempt to give more people input into an upcoming visual change in the interface, even if it’s not a huge one.

Ryan: Would have the benefit of warning people that header and menu will be changed a bit.

Jane: And we can have a vote. If I can get all the materials together and post in the morning, that would give 2 days of design time for submissions on Monday, and if we do a day of voting Tuesday, that’s 3 days notice for the vote. I’ll make sure to post to all the lists, etc.

Ryan: Will we announce with comps from Matt T as examples of what we’re thinking?

Jane: I’ll write up the UX reasons for considering the change, and Matt T can provide some style guidelines and his original comps so no one will have to waste time mocking up the basic screen layout.

Ryan: That would help set the scope. We just want tweaks here and there, given the timing.

Jane: Woot!

On Your Mark, Get Set…
Okay, so here’s the deal. Modifying the nav/header to be a little nicer is was a last-minute design idea, and if it can’t be worked out in the time we have left before 2.8 (which is very little), we’ll just wait until 2.9 to work on it. But! If someone comes up with something the community really likes and it doesn’t break any of the design guidelines for the rest of WordPress, we could sneak it in.

UX and design guidelines for this mini-project are posted here (so as not to clog up anyone’s feed reader with big graphics). Read through the UX stuff, check out the comps Matt Thomas mocked up last night (with absolutely no notice, for the record). Use the .psd as your base, and when it’s time to submit your ideas, make a .jpg or .png and post a link to it in the comments on this post. (Note: Only comments containing a link to a design submission using this format will be approved. For general discussion about this design challenge or any of the submissions, please head into the #wordpress-dev IRC channel.)

Submit the link to your comps by 1am Tuesday, April 28 UTC (7pm Monday, April 27, New York time). If you have questions or want early feedback, we’ll be in and out of the #wordpress-dev IRC channel between now and then.

Once we’ve received the submissions, we’ll post a voting survey (much simpler than the icon survey; this one will be more of poll, just choose the one you like best) as soon as possible, and will post the link to it here as soon as it’s online. We’ll only keep voting open for one day because of the 2.8 deadline, so put it on your calendar if you think you’ll forget. Voting will close at 2am Wednesday, April 29 UTC (8pm Tuesday, April 28, New York time). Results will be announced the following day.

Go!

* Chats above are a conglomeration of actual chats.

Reminder: Only comments containing a link to a design submission will be published here. All other comments will be deleted.

If you want to leave a public comment about this contest, the design, etc., I’ve created a thread in the forums that you can use. Please discuss these things there. If you leave a regular comment here on this blog, no one will be able to reply to you, because only actual links to design submissions will be posted in the comments here.

The wide lead of BD and VS made it clear that voters had a clear preference for these sets.

Question 20 was not mandatory, so a few hundred people skipped it, but the responses we did get (3366 of them) reinforced the fact that the two most popular sets were also the most popular 2nd choices, which made the decision of the judges to go with the popular vote an easy one (take that, electoral college!).

A few of the individual icon metaphors also had a significant lead over the other choices.
Dashboard: 1333 voters (40%) chose a house as the best metaphor. We agree, so both Ben and Verena will be replacing their Dashboard icons.

Media: 2097 voters (65%) chose the combination camera + musical note icon, which was part of Ben’s set. We also really loved it, and Verena will amend her media icon to incorporate this idea.

Plugins: 1682 voters (53%) selected the outlet plug metaphor, which both Ben and Verena used in their sets.

Tools: 1581 voters (49%) liked the combination of two tools better than anything else, so Ben and Verena will try this approach.

So those are the results, and soon you’ll see the new icons coming to a 2.7 installation near you.

Need another look at the entries to remember which one you liked best? Here are some reminder images, as well as the identity of each set’s creator.

BD was Ben Dunkle, a designer, professor and artist from upstate/western New York State. In case you’ve already forgotten, Ben’s icon set is the winner of Project Icon and will become the default icon set after a few minor changes.	VS was Verena Segert, our runner-up, a designer from Germany who presented sets in both grayscale and blue. Her blue icons received more specific voter comments than the gray ones, so we’re planning the second color palette to be in shades of blue so that we can use the blue icon set.
GB was Guillaume Berry, a designer from France who submitted two sets in the same style in order to propose a couple of different metaphors. One of his sets came in third while the other came in last, but whether you only look at the higher scoring set or you combine their votes, Guillaume had the next highest percentage of votes, and many people liked the metaphors he used for various icons. In fact, given the enthusiasm of the community for Guillaume’s icons, we think a great plugin would be one that would allow the user to upload the icon set of their choice. Any volunteers?
OSD was the Open Source Design class at Parson’s in New york City, taught by Mushon Zer-Aviv and consisting of students Alexandra Zsigmond, Ed Nacional, Karen Messing, Khurram Bajwa, Leonie Leibenfrost. Teacher and students worked together to determine their metaphors and visual style.	LS was Luke Smith, a designer from Iowa who specializes in icons among his other design pursuits.

If you need to hire an icon designer any time soon, we highly recommend our Project Icon contestants, who all delivered great work in a very short timeframe. It was great to work with all of them, even for such a short assignment.

So, to sum up:

1. The winning icon sets by Ben Dunkle and Verena Segert will be incorporated into WordPress 2.7 RC1.
2. Someone should write a plugin that would allow anyone to upload a custom icon set (I bet the other contestants could be convinced to release their icon sets for such a purpose).
3. 2.7 is still trucking away, but we can always use help with patches, especially for IE6! (I know, that wasn’t in the main post, but it’s true, so hmph)

Thanks again to everyone who participated in this experiment, and we hope you enjoyed it as much as we did. And congratulations again to Ben and Verena!

Once we decided to go with a contest format instead of a single-designer gig, about half the original volunteers changed their minds. The remaining designers each submitted two icons (Posts, Links) in their proposed style. At this stage a couple of designers were thanked for their submissions but eliminated from the competition because their icons were considered too far afield from the WordPress visual style. The remaining designers were given feedback on the icons they had submitted and given about a week to complete the icon set for the menu as well as the list/excerpt icons that are shown on the Edit Posts screen. All but one of these designers finished a complete set, giving us five sets in total.

So now we need to choose a direction. For each of the icon sets, we’ll show you the set itself, the designer’s introduction, and some feedback from the lead developers. After you’ve reviewed all five, place your vote for the set you think has the visual style that is the most suitable for WordPress 2.7. This will be followed by additional votes on specific icons, so if you like the specific image used in one set but like the style of another, you can vote to change the metaphor for a given icon. You’ll also be able to leave general feedback throughout the voting process. When voting has concluded, we’ll review the comments and the votes, and will declare a winner.

Things to bear in mind when making your selections:
A week is not a long time to create 13 icons. The winning set will undergo a revision to be refined, and some icons may be substituted. We asked for all icons in grayscale for the contest. An “on” state and a larger size for screen headers will be designed by the winner. It seemed like too much work to have everyone do multiple states for so many icons.

Ready? Go and take the icon survey. (The survey has now been closed.) Voting will remain open for 48 hours from the time of this post to allow people from all time zones a chance to participate before we close the survey and make a decision (since we’d like to include the new icons in Beta 3).

A Note Regarding the 2.7 Release Date:
As we approach Beta 3, bug tickets continue to be added to Trac, the pain of making things look good in IE6 continues to be felt, and the need to improve accessibility looms. If you love WordPress, are a decent coder, and want to contribute like these icon designers contributed, please consider contributing a patch to help with one of these efforts. Jump right in on current Trac tickets, or pop into the #wordpress-dev IRC channel to ask what to do.

When the community response to the 2.5 admin redesign was mixed, it seemed like a good idea to do usability testing to find out which issues were based on actual interface problems vs. which complaints were just a result of not liking change. To prevent bias, a third party was contracted to conduct usability testing, Ball State University’s Center for Media Design, Insight and Research division. Try saying that three times fast with a mouth full of peanut butter. Or fitting it on a business card. To save time, we’ll just call that third party CMD, since that’s what they call themselves.

The plan that was developed involved multiple rounds of testing, as well as the creation of two prototypes, hardcore! The first phase involved a usability review of 2.5 by CMD, the results of which were discussed with lead developers. A quick prototype was created that addressed some of the lightweight issues, so that the test participants could use both 2.5 on their own blogs and the prototype on a test site. Results would be analyzed and compared, leading to a second round of suggestions. A second prototype would be developed over a week or two, which would then be tested with the same participants, and a final report delivered. But you know what they say… the best laid plans of designers and developers often go awry.

After the first round of testing, it was clear that a prototype delivering the kind of fixes that could be coded in a week or two wouldn’t make much of a difference overall. We all decided a more ambitious prototype was in order, one that would experiment with a new approach to screen real estate and attempt to address as many of the issues from 2.5 as was possible with a few extra weeks of time. A rapid design process was followed by an even more rapid development cycle. The second prototype is what you know as Crazyhorse.

The second round of testing blew everyone away. The research team had never seen such consistent results. Tasks were completed faster, participant opinions rated it higher, understanding of how interface elements worked was greater, and it wasn’t even a fully functional application. Of the test participants, every single one said they would choose the prototype over their current administrative interface, and it wasn’t even pretty (those of you who remember the original Crazyhorse will vouch for this).

A presentation on the process from start to finish was part of the schedule at WordCamp 2008 in San Francisco, and the slides are available online, but as always the slides only tell you so much without the videos, live demo and verbal narration that went with it. (Use Google and you can see audience videos of the presentation.)

Here, then, is a PDF of reasonable size that you can download and peruse at your leisure that outlines the usability testing project in some detail. I wanted to include some eye tracking videos, but the file was so huge it would have been ridiculous for anyone to download it, so I stuck with eye tracking outputs called gaze trails to illustrate the findings. I also tried to pare down the text to the more salient points, since more than 50 hours of test video really does reveal an insane amount of data. I also cut out the section about designing Crazyhorse in the interest of staying under 25 pages. Hopefully you’ll think it’s a good balance. I’ll try to put together a separate document on the design process of 2.7 in a couple of weeks that will include the early Crazyhorse material.

So, if you want to know what we learned from the usability testing this summer that caused us to create what is now 2.7, go ahead and read the report.

WordPress 2.5/Crazyhorse Usability Testing Report (PDF)

I’m always meeting people at WordCamps or via email who say they wish they could give back to WordPress, but that since they aren’t PHP developers, they feel like there isn’t any opportunity for them to be a part of the open source project. Well, here’s a golden opportunity. Want to design the new WordPress icons?

The icons:
We’ll need icons for each of the main navigation sections, plus a matching pair of list/excerpt view icons for the table screens like Edit Posts. That’s a total of 13, and for the navigation icons we’ll also need a larger size for use in the screen headers. Some of the sections have natural iconography, while others may be more challenging. The sections are: Dashboard, Posts, Media, Links, Pages, Comments, Appearance, Settings, Users, Plugins, Tools.

The style:
Icons should be subtle, with a classic/designed look, nothing cartoonish. Thin lines. Maybe a little old-fashioned looking. They’ll be grayscale by default, possibly with a color version for active menu items.

The timing:
Fast, fast, fast. 2.7 is due to release on November 10. That means icons need to be ready within two weeks, give or take.

The required experience:
To be taken seriously, you’ll need to show a background in icon design. It’s a different skill than web site or application design, and given that there’s not much time before the 2.7 launch, someone with experience (and possibly existing work they can leverage) is going to be the best candidate.

Interested? Send us an email and tell us why you want to design the icons, and include a link to your portfolio. How we wind up choosing an icon designer will depend on how many people respond, but we’ll keep you posted on the process. For now, send in portfolio links by Saturday night, October 25, 2008. We’ll review them over the weekend and get in touch with people on Monday. Hopefully we can be designing by early next week.

Menus
I described the menu functions last week, but I forgot to mention something. By default, when you arrive at your Dashboard the first time, two sections of the navigation will be expanded: the Dashboard section (because it is active, so it will have the color highlight) and the Posts section (because it has often-accessed screens in it, and will serve as a cue that you can view other section menus without loading new screens). Once you start clicking menus open and closed, your browser will cookie you, and will remember your menu state. So if you open Posts and Comments, when you come back the next time, Posts and Comments will be open. If you click into your Settings, Posts and Comments will still be open. You’ll need to manually close nav sections. We went back and forth on this, and there was community discussion about perhaps only allowing two sections to be open at a time, but ultimately those approaches would have removed control from the user. And since the mantra of 2.7 is to give the user control over his/her admin interface, we chose to keeps things open if the user had opened them.

Contextual Access Tabs
In the upper right, drop-tabs provide access to contextual features displayed in a layer that appears between the header and the main working area. Screen Options will allow you to choose which modules to display on the current screen. Don’t like seeing the Incoming Links module because no one links to you? A simple checkbox in the Options tab will remove the module from your Dashboard until you decide to reinstate it. Help will highlight some of the changes since the previous version, and provide links to help resources such as FAQ/Forums/Contact Support for .com and Documentation/Support Forums for .org.

Module Layout
In addition to using the Options tab to decide which modules to display on the Dashboard, all the modules on the Dashboard may be moved up or down or between columns using drag and drop. Modules also may be collapsed or expanded by clicking the title bar, allowing another level of screen customization. In 2.8, we also hope to make every single module configurable in terms of what content it displays… we ran out of time for this in 2.7, so for now only the newsfeed modules will be configurable. When you hover over the module, a link will appear in the module header allowing access to the configuration view.

Right Now
The Right Now module contains the same data as before, but it’s been rearranged to provide a clearer display. This list style, as opposed to the previous sentence style, will also make translation for non-English sites easier. Color cues help to highlight things that are not good (red), things that are pending (yellow/orange), and things that are good to go (green).

Stats
I’d like to apologize for having a non-core piece of functionality on the Dashboard comp. It’s my fault… when we were working on the comps, we used my wireframes and my live 2.7 Dashboard to assemble our elements, and I forgot that I had the WordPress.com stats plugin installed and a module on my Dashboard. So even though it’s not in core and it turns out the WordPress.com stats plugin is undergoing some reworking of its own, we made the Dashboard stats module easier to scan than the one I currently see when I log in. For those of you on .org who got excited when you saw the Dashboard comp with stats, again, I apologize for the oversight on my part. If you want the candy-like stats goodness we comped up you’d need to install the plugin (or another stats plugin with candy-like elements). There should be a fine-looking Dashboard module as part of the update they release.

QuickPress
QuickPress is a new feature that provides the ability to start (or publish) a simple post from the Dashboard when you don’t need the full feature set of the Add New Post screen. Currently, these posts can contain title, text, media and tags. In 2.8 we hope to make the module configurable, so that each user can decide which few fields make the most sense to display. If you Save as Draft, you will see the new draft appear in the Recent Drafts module right away. Clicking Cancel will clear the form. Publish publishes the post. Posts made using QuickPress are the same as other posts and may be editing by going to Posts > Edit and selecting the post in question. One last thing: both in this module and on the Add New post screen, we’ve put as much space as possible between the Save Draft and Publish buttons, so for all of you who’ve asked at WordCamps or emailed or posted somewhere to request this, ta da! Hopefully this will reduce accidental publications.

Recent Drafts
During the summer testing, one thing we heard over and over was the desire to access recent drafts more easily, preferably with one click from the Dashboard (as opposed to clicking on Drafts from the Right Now module, waiting for page to load, then clicking on a specific draft title and waiting for a second page load). The Recent Drafts module is meant to address that need, displaying the five most recent drafts with the date they were created. In a future version, this module will be configurable as well. In the meantime, if you’re a crosswords-in-pen kind of person and you don’t write drafts, just use the Options tab at the top to hide the Drafts module, and it won’t take up space on your Dashboard.

Feeds
News feeds of WordPress-related news will function largely the same as they did in 2.6 in terms of configurability, and will simply have a new look. You can still specify the URL of the feed, how many items to display, whether to show headline vs excerpt, author, date, etc.

Incoming Links
Just getting a face lift. Or maybe not a face lift, more like a visit to the Clinique counter.

Hooks
Plugins can still add modules to the Dashboard. They also still can add top-level menu items if necessary (as opposed to having them in Tools, Plugins, Settings or wherever…like Posts if it’s post-specific). Because we’ll be using iconography in the collapsed menu state, plugins that create top-level menus can create an icon for use in the menu system. When there’s no icon associated with the plugin, a default will be used (kind of the way some blogs show default avatars when no Gravatar is associated with a commenter on your blog). Hopefully, though, most plugins will fit within existing section headers, since our “top level” is not actually made up of menu items, but section headers that open to reveal the real menu items that have screens associated with them. Plugins can also put themselves into the Shortcuts/Favorites menu in the header.

Recent Comments
This module, as in 2.6, displays the most recent comments. However, you now can moderate comments directly from this Dashboard module, including the new Comment Reply feature. For now it will show only the last x number of comments, as it does currently, though in 2.8 we hope to add more configurability to this, or roll it into the Inbox concept.

Bye-Bye Inbox
For those who were at WordCamp SF or who were using the nightly builds while there was still an Inbox placeholder, sorry, no Inbox in 2.7. It turned out to be far more complex than anticipated, and rather than including something rushed and clunky, we’re holding off until a later version. We added the comment moderation to the Comments module to make up for it, so you don’t have to wait for that, at least.

So that’s the new Dashboard. A little more usable, a little prettier, a little more you, a little cooler. Or maybe a lot of all those things. We’ll let you be the judge.

The visuals you have been craving are finally finished enough to show, and have been approved by the lead developers. We hope you like them. Mad props to Matt Thomas and Andy Peatling for their visual talents. You can expect these designs to be extended to the rest of the 2.7 screens and implemented over the coming weeks.

So now that we finally nailed down the look, how’s it going to work? The menu system in particular has been the topic of discussion on the hackers and testers lists, so I thought I would take this opportunity to explain how we plan for it to work. As you know, one of the goals of 2.7 was to reduce the necessity to load new screens just to access sub-navigation menus; we wanted the most-used screens to be within a click or two at most. If you’ve been using the nightly builds, you got used to the arrow controls that allowed you to expand and contract the menus. Then you got used to the box-style with icons that not only opened and closed vertically, but could be minimized horizontally as well, leaving a remnant of icons to provide a kind of “advanced mode,” though you don’t need to be particularly advanced to use it. Now that we have real button styles (the icons are still placeholders, and we hope to have some new ones soonish), we’ve nailed down the menu functionality.

2.7 New Post Screen, Unfinished

Each section header has three parts: the icon on the left, the blue link text, and the area to the right where an expansion arrow appears on hover or in expanded state. You can see that the arrow is contained in a small segment of the header, similar to the way the favorites menu is structured. If you click on this segment, the menu will expand to show the choices in that section. Click again to close the menu. Click on the blue link text and you will go directly to the screen for the first choice in that section, where the section menu will be opened to show you the other section choices. Double-click on the section icon and the menu will close horizontally, leaving the icon list visible. In this state, hovering over the icons will display the menus for each section, so you’re still only a click away from most screens. Double-click on an icon when the menu is closed this way and it will take you to the first screen in that section. The small arrows attached to the dividing lines between menu groups will also act as open/close toggles for using the horizontal collapse/expand function.

This variety of ways of using the menu system aims to accommodate both power user and novice alike. Clicking on blue link text like normal will bring the expected result for the novice, while the advanced user has more options for navigation that allow a more customized experience. We hope you like this result as much as we do, and you can expect to see it implemented in Trunk soon.

The image below is the new Dashboard style, for which I’ll save the explanations until early next week, but hopefully the preview will get you excited for the new design.

2.7 Dashboard