Joystiq 3.0 Usability Mini-Review

Gamer website Joystiq has just been redesigned. The main purpose of the new design was to reunite the brand that had bled out through various platform specific subsites.

The design is decent, a minor improvement that keeps the blue, white and orange brand colors, while tightening things up. Pity to see the logo all glossed up, when “plain” would have been preferrable. Uniting the subbrands was a good idea, it’ll lessen the feeling of redundancy. While pulldown menus are generally a nono, I’m liking them in their incarnation here; they unclutter truly tertiary info to those who want to explore. The search feature is skinned, which is always a bad idea, but at least the background in the search box is white and the placement is logical. It’s interesting to see the “4 good stories” feature area right at the top of the blog, I’ve seen that on Lifehacker as well. The next big blog thing?

WordPress 2.7 Admin Interface Usability Quick-Review

Blogging software and part CMS, WordPress, has gotten a major overhaul from version 2.6 to the just-released 2.7. Besides some very neat new features such as threaded comments, the administration interface has gotten the most work. Dubbed “Crazyhorse”, this admin update is mostly good, tweaking and building on usability work that was done for version 2.5 and 2.6. A few usability mistakes, common ones at that, remain, however, and some have been re-introduced.

As a sidenote, I love WordPress, its features and its free nature. It certainly is standing on the shoulders of giants, and when I criticise it, I hope to improve it rather than belittle it.

Wordpress 2.7 Write screen

The WordPress Write screen has seen the most improvement.

Regressions and as yet unfixed issues

Hyperlinks are (still) not universally underlined

Sure, some are, but the distinction between whether links are underlined or not seems random. This is probably one of the most violated usability mistakes on the web. I remember that at one point Wikipedia abandoned underlined links only to add them back later on in a popular vote. Good choice. The underline, even more so than the color blue, is synonymous with “click me and you’ll leave this page”. Don’t mess with that.

Form elements are (still) styled

This is also a classic one, straight out of web usability 101. Things are made worse as this is an administration system, where very special rules apply. Sure, it’s okay to style buttons in World of Warcraft, but this admin is supposed to be accessible to everyone; eveyone knows the look of unstyled buttons and textareas, so why should you style them? I know the answer, and vanity is thy name. That is the honest to goodness truth of it, and no matter how much you try and veil this shallow truth up in a story about “platform uniform look”, it’ll remain a damn dirty lie.

Point of note: I will make an exception of the button styling for the Flash uploader. Long story: the Flash uploader (which is available right above your Edit area), uses Adobe Flash to allow you to select several files at once and enqueue them for upload; which is a big deal considering most web interfaces, even Gmails, allow you to upload only one file at the time. The exception in this case, stems from the fact that Adobe changed the security sandbox between Flash Player 9 and 10, effectively killing the Flash uploader in WordPress 2.6. The only way to add it back in 2.7 was to have the actual “Upload” button be part of the Flash web-bug that does the uploading. So to sum things up: the Flash uploader button has to be styled, because Flash does not use native UI widgets.

Textareas are (still) styled

Like the styling of buttons, the styling of textareas is also an across-the-board bad idea. Every computer user knows what a textfied looks like, but the probably hasn’t seen your particular brand of textarea (so leave it alone). In the case of the WordPress UI, the problem is not egregious, as the background is, at least, white. Even so, this is a usability mistake. Would you style a scrollbar if you could? Wait, yeah, people would do that. And they’d be wrong about that too.

The visual hierarchy of WordPress Pages is still very basic

As opposed to posts, pages are static content holders, a feature which puts WordPress squarely into CMS country. It’s a pity, however, that the Page administration screen can be an enigma. Sure, subpages are indented below their parents and that helps a little, but the addition of pagination certainly doesn’t. Considering the value of this feature, however, I’m surprised this section doesn’t show an advanced JavaScript powered expand/collapsable page tree akin to the folder tree on your Finder or Windows Explorer.

Widgets are still a mystery

Widgets provide users with a way of simply adding, removing or resorting content boxes. Unfortunately, adding and removing these widgets is far less intuitive than it could have been. Where it could have made elegant use of drag/drop features, adding and removing widgets is now, as it was in 2.6, a matter of clicking hyperlinks in the right sequence. To make matters worse, the change of design from 2.6 to 2.7 further confuses things, by removing a few borders that helped connect the whole thing.

The case of the misunderstood use of a hyperlink

Slightly related to the styling of hyperlinks, the use of said for activating and deactivating WordPress plugins constitutes a misunderstanding of what hyperlinks do. Yes, clicking “Activate” involves a page-reload but that’s where the hyperlink metaphor ends. Because the activation of a plugin is a “toggle”, activating plugins should be done using a push-button. This has been an on/off thing for WordPress; I remember several versions which feature buttons instead of hyperlinks.

WordPress eats your formatting

In a moment of weakness, perhaps you decided to add two consecutive linebreaks, just to fix the layout here and now. I’m sure you were surprised when WordPress “corrected” this semantically unsound decision. Or did you even discover that was what happened? As it turns out, WordPress is the Soup-Nazi when it comes to semantic post authoring. If you don’t do things correctly, WordPress will “help” by correcting things for you. That means linebreaks are eaten. In case you were wondering why this is extremely bad usability, I’ll spell it out: it’s not what the user wants. It’s the second law of robotics: computers are supposed to do what we tell them to, even if we ask it to do stupid things.

Navigation buttons could be bigger

While the new sidebar navigation is superior to the topmost tab navigation found in 2.6 in almost every way, buttons are actually smaller than they used to be. In the mathematically complex looking words of Fitt’s law, a large button is easier to hit with a mouse. As such, this is a pity. I bet they could have padded things a bit without changing the layout much.

Another missed opportunity is for the sidebar buttons to have extended all the way to the left screen edge. This would make the buttons easier to hit; anyone can find a screen edge, even blindfolded. In this case, you’d only have to worry about up or down, to hit the button you wanted.

Improvements in 2.7

In case you didn’t read the disclaimer right at the top of this post, where I openly declare my love for WordPress, a love which you may have forgotten reading the criticism above, I’ll repeat it here: WordPress is mostly good. Here are some very welcome improvements over 2.6.

The sidebar navigation really is a good idea

Moving the main navigation from the top to the left of the administration theme as a collapsible sidebar may take some getting used to, but you will get used to it. There are numerous improvements, including the renaming of some odd sections such as “Themes” (which also featured Widgets) to “Appearance”. Additionally, because the menu is now a sidebar, it’s possible to have longer and therefore more descriptive section titles. This should finally also solve the problem of the plethora of configuration tabs that would appear due to plugins and then proceed to overflow miserably. Most importantly, however, you can now expand your favourite section (whose expanded or collapsed state will be cookied), allowing you quick access to the subsections of said section. Previously you had to wait for the parent section to load, before you could jump to a sub section.

Tags and categories are to the right of the post window, again

For some reason, these two semi-critical metadata tools were moved below the post window in 2.6. They’ve been moved back to the rightmost sidebar, where they’re contextual.

The Flash uploader works again

As alluded to in my push-button criticism, there were problems with the otherwise excellent multi-file uploader that was introduced in 2.6. For the better part of a month, this button did nothing, if you had Flash 10 installed. Now it works again. Hallelujah!

Icons beautify and help distinquish sections

For the first time, probably since the birth of WordPress, icons have been added to section buttons. Lovely! It helps distinguish sections by adding a silhuette.

Publish settings is more logical

Future posting, or even posting to the distant past, has become so easy that anyone can do it. Slow claps from yours truly.

Comment administration is nice

Administrating comments is faster and simpler than before and receives extra marks for the addition of keyboard shortcuts. Additionally, the ability to administrate comments directly on a corresponding post page is very nice.

The timestamp layout has presets

To change the layout of your post timestamps (say, from 12/12/2008 to December 12h 2008) has been simplified quite a bit, with the ability to select from a few presets. Previously you had to visit PHP.net to find out how to do that.

Media configuration earns its name

Tweaking media sizes for the automatic rescaling of uploaded images is somewhat easier, now that the settings are available in Settings > Media as opposed to Settings > Misc.

WordPress, Habari And The iPhone

Not two days ago, I hurled myself into the fray once more, discussing usability with the WordPress developers. The topic of discussion was a recently unveiled demo site showing off work being done to improve the backend design for the next version.

I do usability reviews for a living. Among other things, I’ve worked with LEGO on Mindstorms. I’ve been through the motions for years now, and I’ve learned to avoid a few common pitfalls in the process. The great thing about usability is that it empowers products. You might have an incredible product that won’t sell because it’s not user friendly. Then you have a bad product that succeeds against all odds because it’s easy to use. Finally you have the cream of the crop that’s both. Compare it to cell phones; there’s the feature-laden but ultimately complex LG or Siemens phone, there’s the trusty old boring but simple Nokia 3310 and then there’s the iPhone. Do you think the iPhone would have succeeded, was it not for it’s delicious user friendly interface? Me either.

I love WordPress. I think it’s a fantastic piece of free blogging software that does so much more than just blogging. It’s extensible and has a great support community. But do not mistake love of a product with mute obedience; I’ve said it countless times: I criticize because I love. And with WordPress, there’s a whole heap of moronic usability decisions to tackle and ridicule. That’s right, ridicule. I don’t remember anyone, ever, saying “wow that was quick” about anything other than the WordPress install process and even that could be changed from “quick” to “quick and pleasant”1.

It’s now 2008. Let’s go back in time to an article I wrote in August 2004:

The priority recipe for most commercial pieces of software is the following:

  1. Build the best product ever
  2. Profit!

In comparison, the recipe for most open source projects only include the first of these priorities—the product.

Now, 4 years later, I’m unsure whether I was right or wrong; WordPress does have a “profit” element today. It’s called WordPress.com. Don’t get me wrong, I’m no longer blind sighted by open source idealism: I do think that profit is a good thing, it works for Firefox. The problem is, it doesn’t seem to have mattered in the case of WordPress. Writing a post or creating a page is still akin to solving an enigma hidden in a maze, wrapped in the same tough plastic that CDs come in. That means it’s tedious and overly complex. Profit, apparently, made no difference. Then again, that’s why the iPhone can enter a market that’s otherwise so heavily dominated by Nokia and Sony Ericsson.

We come now to the crux of this story. I examined the nightly-build demo site and decided to give what advice I could muster. I wrote a quick usability review and submitted it to the discussion. I tried to do this before, via more official channels. Being part of a so-called “Shuttle” project2, I joined forces with several others in advising the WordPress team. It was a miserable failure and the end result was a bluish bastard child appearing in WordPress 2.0. Months of work from a team of several was hacked to pieces and implemented in what looked like a completely ad-hoc process. Naturally the end result, from which WordPress 2.3 is still reeling, wasn’t very user-friendly at all.

What I see on the demo site may be a “work in progress”, in fact that’s the main counter argument, but there’s a real problem with that. It’s not that I mind baby blue and curry red. The problem is that a usability-work-in-progress doesn’t look like that, that there is a “live redesign”3—at best. Usability is not achieved thusly. Usability is a process that starts with identifying user tasks and then moves on to visualizing those tasks either with pen and paper, faux screenshots or actual prototypes in Flash or what have you. Personally I’d find it a striking waste of time to jump right in, pick some colors and start playing. Usability is not a Jackson Pollock painting.

You’d think that would scare me from ever trying to advise the WordPress team again. No. Despite all my misgivings, WordPress is still the best blogging tool out there. It is no coincidence that it’s beaten Movable Type to such a pulp as to have them finally open source. Imagine where WordPress could have been today, had they just focused on usability? Habari, probably wouldn’t have existed. Habari is an open source alternative to WordPress that’s slowly gaining traction. It’s built ground-up for “todays bloggers”, and it is built primarily by talented ex-Wordpress developers. Perhaps it’s not quite an alternative to WordPress just yet, but unless WordPress ramps up, it might become the iPhone of blogging. Both WordPress and Habari blog, but one does it deliciously and with a sprinkle of user friendliness.

You can download the review in PDF format. Even if the nightly build has moved on from the screenshots in the review, I’d wager the advice is still useful.

  1. In case you were wondering how this could be done, my advice would be add an install-script that asked for database information instead of asking users to enter information in a cryptic looking text-file.  ↑
  2. I have a Shuttle screenshot gallery available, should you be interested.  ↑
  3. “Live redesign” is the web 2.0 term for “Under construction”. It means redesigning your website, aimlessly, while users can watch you work.  ↑

Usability in WordPress' Admin Interface

As a blogging tool, WordPress is great. It provides countless features and works flawlessly. Existing WordPress users know that they bet on the right horse. Users considering migrating to WordPress, however, might not be so sure.

I was once a Movable Type user myself, and one of the things I was looking at, when considering migrating, was the admin interface.

As such, in order for WordPress to be considered a serious alternative to more main-stream CMS‘s such as Movable Type, a few things have to be changed and improved. With the outlook of a new and improved default template in the next WordPress release, most of the remaining issues, as I see it, are with the Admin Interface.

This article is a follow up to “About WordPress, Usability and Open Source Development“.

The Interface

Currently, WordPress comes with a nice looking admin interface—[view screenshot]. However, the problem does not lie in the design of this interface, rather in the usability of this interface. While the WordPress interface is, technically, just a web page, it has more in common with an application than it does with a web page, simply due to it being an admin interface. Movable Type does this a little better—[view screenshot], but it is also far from perfect.

There are a number of reasons why the Admin Interface is not perfect, and in the spirit of constructive criticism, I will now run through the most important issues, and suggest possible solutions.

1. The Main Navigation

Nav

The main navigation of WordPress, resides right at the top. It works well, and the idea of using a layer of primary and secondary tabs is a good idea. It allows WordPress to have a great many options and features, while remaining clean and tidy.

The main problem with this navigation, as it is now, is that while it works like tabs would, it doesn’t look like tabs. There is a gray focus area behind the selected page of the primary navigation, and although the secondary tab navigation does look more like tabs, it is easy to miss because the links are white.

Suggestion

Nav Suggestion

When working with a web-based admin interface, we are working with two metaphors. One is the HyperText metaphor, with hyperlinks, scrolling pages etc. On the other hand, with it being an admin interface, we are working with something that’s more like a Windows or OSX application.

In order to make the navigation more clear, we should use the strengths of both worlds. That is, clearly indicate that the primary navigation (Write / Edit / Categories / Links … ), are tabs, and only have one layer of tabs. This would mean that the secondary navigation (as seen on the picture above, Manage Links / Add Link / Link Categories …) cannot be tabs. A solution could be to use the hypertext metaphor here, and simply make blue links, with the active link in black and bold.

Please note, the redesigns presented here, are quick and dirty suggestions and serve only to communicate the idea rather than actually being redesigns.

2. Common UI Elements

UI Elements

Currently, WordPress uses highly stylized UI elements, with button backgrounds, and custom input box borders. While it does admittedly, look better than the default input boxes, it not as usable as it could be.

Suggestion

UI Elements, Suggestion

In this case, WordPress should follow the application metaphor, and make use of the default operating system buttons and input boxes. This will serve to let buttons and input boxes become tools rather than demand that the user has to learn and decipher new UI components in order to use the software.

Furthermore, it is important that the background of the input box is clean white, because “that’s how input boxes look”, and a white rectangle is what the user is scanning the page for, when looking for an input box.

3. Base Font

Base Font

WordPress is currently using a lovely Georgia font, for all elements used. While this font looks great as a heading, the only other benefit is that it’s highly readable when printed. When used as a body font in an already complex interface, it only serves to add clutter, with it’s high detail.

Suggestion

Base Font Suggestion

Again, WordPress should make use of the application metaphor, and use a sans-serif font as it’s base, just like most other actual applications do. It doesn’t necessarily have to be Verdana as used in this example.

The sans-serif (French for “without feet”) font, ironically, is much more readable on a screen, than a serif font. This is ironic because all typographers learn that serif fonts are more readable due to the feet creating an optical horisontal line that leads the eye. This is not the case on a screen, where pixels fail to reproduce the soft curves that make up a well designed serif font. On the other hand, the low detail of sans-serif fonts serve to simplify things, and give a “cleaner and tighter” look.

4. Help text / links

Help

As it is now, there are small help articles for most of the common areas of the WordPress interface. They provide direct links to the online WordPress documentation.

There are two main problems with this, in their current iteration. First of all, deciphering what they do, is not clear by just looking at them. Secondly, clicking on them takes you to a help file on wordpress.org, replacing what you were doing (possibly writing an entry), bringing you to a web page that doesn’t look like a help file.

Suggestion

Help Suggestion

This area needs more work than a simple screenshot can communicate. The above image is far from enough with respects to what should be done.

However, some of the concepts are improved, and show what direction should be taken. First of all, I am not fond of the idea that it is a link at all, since these “quick help” links aren’t logical places to present help. I honestly think that if it should even have help attached to it, it should be on rollover and explained in the rollover title. This would be indicated by the “help” cursor, as seen in the screenshot. Additionally, the rollover text could be more descriptive in itself, than it is now.

If, however, it should remain a link, it should a) open in a small pop up window, as to not interfere with what is being done or written, and b) be bundled with the wordpress package, so no visit to WordPress.org is necessary, and c) be designed as a help file, i.e. no fancy backgrounds or graphics.

Another solution would be to provide a simple “help” link next to each item, such as this:

Help Suggestion 2

5. Other issues

There are numerous minor issues that could also be improved upon. Here are a few of them.

  • The “Save and Continue Editing”, “Save” and “Publish” buttons are illogical
    For one, “Save and Continue Editing” should be renamed to, for instance “Preview”, because having two buttons that say “Save” in their title is confusing: which one is the right one?

    “Publish”, is unnecessary since there is a “Post Status” radio group that defines the status of an entry. Instead, the “Post Status” radio group should be moved closer to new “Save” and “Preview” buttons.

  • The “Quicktag” buttons above an entry are mostly unnecessary
    Those who can decipher what “b-quote”, “del”, “ins”, “ul”, “ol”, “li” and “code” means, are likely to write them by hand. These buttons should only be available in the advanced interface.

    The “link” button should have blue text and an underline, to be easier to decode.

    The “str” and “em” buttons should be renamed “B” and “i”, because that’s what they’re named in Word.

    The “img” button should have a small image icon, for instance Image Icon (taken from Dreamweaver).

    The “Dict.” button should be renamed “Dictionary”.

  • The various Delete this post, Delete comment and other “delete” buttons, should actually be buttons

Currently, they are blue web links, with a huge, liquid-width red background square.

Conclusion

In it’s current iteration (v1.2), WordPress has a lot of things going for itself. It’s loaded with features, it’s stable, fast, it’s free and it’s undergoing a continuous rapid development.

However, WordPress is suffering from this very development it is undergoing. As I wrote in my article on the development of WordPress, the nature of open-source development is to add features, features and more features, not worrying about profit since that factor is not part of the open-source game. Combine this with the common developer knowledge, that building a feature may be easy and fast, but making that feature configurable via an interface, takes time, and the result is a user interface that grows ever more complex with every release, and WordPress is beginning to show signs of wear and tear.

While effort has certainly gone into making a comprehensive and good looking WordPress interface, it is my impression that not enough focus has been on making this interface truly usable for the end user. Any power user may be able to use it, but new users will certainly have to learn it. More focus should be put into making the interface user-friendly. More often than not, a few adjustments here and there can make all the difference.

In the end, the main purpose of developing a product such as WordPress is to gather a huge and varied user-base. WordPress is already a good product, it’s just not aimed at the average user… yet.