Disabling Inactive Menu Items

Joel Spolsky thinks that we should not disable inactive menu items because it’s confusing users who may not know why a menu item is disabled. In reality, disabling menu items is rarely a problem because it’s usually obvious why menu items are disabled (for example, if there’s no selection, you obviously can’t copy anything). ¹

He is right though that there are some cases where disabling menu items can be confusing (and Gruber’s solution to just let the user figure it out isn’t an acceptable solution at all). It’s not only menu items, by the way; all UI elements which can be disabled can confuse users.

Mac OS 7 had a solution to this problem: Balloon Help allowed users to mouse over disabled UI elements, getting information explaining why they were disabled (If I remember correctly, I used this feature in Interarchy - née Anarchie - more than once). Wikipedia writes:

Developers were encouraged to include help text with a certain grammar, and not only name the object being looked at, but also explain to the user any state it might have

What a great idea! Apple already thought of this issue in 1991! ²

In its infinite wisdom, Microsoft does not display tooltips on disabled interface elements (or at least did not show them the last time I wrote Windows software, two or three years ago). People, this is the only time users actually want to see these damned yellow thingies! What were you thinking?

Fortunately, Mac OS X does allow tooltips on disabled menu items. So just do the right thing and show an explanation telling the user why a menu item (or any other UI widget) is disabled.

Here’s a disabled menu with a tooltip:

And here’s a disabled checkbox with a tooltip:

Take some time to think of a good explanation telling the user why these items are disabled and how they can enable them, too.

Please don’t just assume that people will figure it out, and don’t confuse people by enabling menu items which should be disabled. Use tooltips instead.

Addendum: Daniel Jalkut has an additional solution to this issue: “If the problem is especially grievous, it could warrant a dedicated reference page in the documentation, where users could easily look up the cause of their frustration.”

While documentation should not replace usable interfaces, documenting such things is a great idea because some people will consult the documentation if they can’t figure out why something is disabled.

July 1st, 2008 / Tags: Gruber, Spolsky, usability, Interachy, disabled menu items, balloon help, tooltips / Trackback

Consistency Killed the Cat

When people talk about an application’s usability, they’ll often discuss the application’s “consistency.”¹ The more consistent an application, the more usable it is, it seems. But what exactly is consistency, and is it really always a good thing?

The relevant definition from Merriam-Webster is probably the one which says that consistency is

agreement or harmony of parts or features to one another or a whole

When people say that an application is “consistent” with its host system, they usually mean that the application “agrees” with its host system by being “similar” to other applications on that system. This is good because knowing how to use other applications helps users of the new application understand this new application.

However, not all forms of consistency are good, and not all forms of consistency are important. Let’s have a look at what consistency is and when it’s important.

Visual Consistency

Applications are often said to be inconsistent with their host system if they look different from other applications on that system. However, look alone doesn’t really matter. As long as users are capable of easily identifying the different UI elements, applications don’t have to look like their host system.

Here are a number of different buttons from different Mac OS X applications:

While some of these buttons may be downright ugly, they’re all immediately identifiable as buttons. The fact that they don’t look exactly like each other does not harm usability.

People see all kinds of different user interfaces while surfing the web. A different look doesn’t harm usability, as long as the individual widgets are easily recognizable, and as long as they behave the way the user expects them to.

Behavioral Consistency

From a usability standpoint, behavioral consistency is a more meaningful type of consistency than visual consistency. Being behaviorally consistent means that an application behaves in the same way as other applications, and thus in the way the user would typically expect.

The more consistent the look, the more important behavioral consistency becomes. Visual consistency can hurt usability if it gives a false sense of behavioral consistency, telling the user that a given widget will behave like something he already knows when it does not.

If an UI component looks exactly like a standard UI component, every little behavioral issue can confuse the user tremendously, essentially killing his suspension of disbelief and thus his trust in your application. This is the uncanny valley of UI design, and it is probably one of the issues people have with Firefox: because it gets the Mac OS X UI almost right, the remaining issues seem all the more jarring.

Some Examples — Combo boxes combine the features of a text box and a dropdown menu. Here’s what combo boxes look like in Mac OS X:

Clicking once on the blue arrow will open a menu from which the user can select a predefined value:

This is a combo box from OmniFocus:

Even though it looks different from normal combo boxes, it is immediately recognizable as a combo box. Unfortunately, it doesn’t quite behave like a normal combo box. For example, if the focus is on the text box, clicking on the little arrow will open and immediately close the menu. If the text inside the combo box is not selected, the menu will remain open (as it always does for the normal combo box).²

Here’s another example. This is a window from a Fireworks beta,³ sporting Adobe’s new CS4 user interface:

This looks pretty much like a normal Mac OS X window with a bunch of color changes. It doesn’t behave quite like a normal Mac OS X window, though. For example, clicking on the “zoom to fit” button will maximize the window. In most cases, Mac applications should not maximize windows when this button is clicked. Instead, the window should be resized to fit the exact size of its content.

Another discrepancy to “normal” windows is the fact that you can’t resize this window by dragging the bottom-right corner. Or, more specifically, you have to hit the actual border of the window with your mouse, instead of the empty area inside the corner.

Finally, the CS4 windows don’t show the “this document has unsaved changes” dot in the close button, which can be confusing if you make changes to the document and don’t see these changes acknowledged by the application.

Details such as these are incredibly frustrating to your users. It’s okay to introduce new concepts that don’t already exist on a platform. It’s not okay, however, to ignore the things your users have already learned while using other applications, or to actively go against the things your users already know by mimicking user interface elements they recognize while making them behave slightly different.

An extreme example of this are applications which abuse existing UI components for something else than what all other applications use them for.

False Friends — Before I explain this next and final example, I want to say that I’m not actually sure VectorDesigner is doing anything wrong as per Apple’s HIG. I do, however, find what they’re doing quite confusing.

Mac OS X supports something called a “toolbar.” This is the list of icons many applications show at the top of their windows. Here’s how they look in Apple’s Keynote:

Clicking on some these icons will start an action. The “Play” icon starts the presentation, the “Text Box” icon adds a text box to your active slide. Clicking on others will open a dropdown menu, and clicking on one of the entries will, again, start an action. These toolbar icons have no active state; clicking on them will not activate the icons.

However, Toolbars can have icons with active states. Apple calls them “Selectable Toolbar Items” and writes:

This is often used in conjunction with an NSTabView that is configured to have no visible tabs.

Apple writes that this is “often” used in conjunction with an NSTabView, but in fact, tabs is almost the only use of selectable toolbar items I’ve ever seen. Here’s an example for selectable toolbar icons used as tabs; it’s Safari’s preferences window:

In fact, I have never seen this look described as anything other than “tabs.” For all intents and purposes, users don’t see these “selectable toolbar items” as toolbar items at all, but as tabs. Clicking on them does not select tools, but changes the windows contents in almost all applications which use them.

Vector Designer is probably my favourite vector drawing application. I’m using it every day. Yet its toolbar still regularly throws me off.

Admirably, Vector Designer goes for an iWork type of user interface. It has a toolbar similar to Apple applications like Keynote. However, while Keynote’s toolbar icons start actions, Vector Designer’s toolbar icons are selectable tools. Clicking on them changes the tool you’re currently working with. This means that Vector Designer uses Apple’s “Selectable Toolbar Icons,” which look like tabs in Leopard:

Clicking on the icons with the small triangles opens a dropdown menu:

The fact that I’m clicking on something that looks like a tab to select a tool or open a dropdown menu seems terribly strange.

In Vector Designer’s defense, selectable toolbar icons used to look different in earlier versions of OS X, but it seems since most developers use selectable toolbar icons only for tabs, Apple abandoned the “button” look and went with a tab look pioneered by Panic’s Coda.

Perhaps it was a bad idea to mix the concept of selectable toolbar icons and tabs in the first place, but now that these things look like tabs, and most devs use them as tabs, using them as selectable tools is starting to feel terribly inconsistent. People are used to seeing selectable toolbar icons as tabs, and that’s what applications should use them for.

If anyone knows other applications which use selectable toolbar icons to select actual tools, please drop me a line.

Internal Consistency

So far, we have discussed consistency with the host operating system. However, there is a second kind of consistency: Consistency within the application itself. This is especially important if you decide to forego consistency with the host system for certain aspects of your application. Think about the rules and conventions that should apply, then apply them everywhere. Also consider the mental model your user will build of your application. Are the rules at work in this mental model always consistent?

Conclusion

You don’t need to make an application that looks like every other application. But you do need to make sure your application behaves the way the user expects. If you can’t use or mimic existing widgets, it’s better to look entirely inconsistent with the host OS, hence influencing the user’s expectations. Inconsistency can be a good thing: If your widget’s behaviour is inconsistent, make sure its look is inconsistent, too.

Don’t be visually consistent for consistency’s sake. Be consistent when it helps usability.

June 29th, 2008 / Tags: consistency, usability / Trackback

You really, really need to do Usability Tests

I often write articles where I complain about specific user interfaces. You should not believe anything I say in those articles. User interface design is nothing that can be reduced to a bunch of rules which create a good user interface if followed¹. User interface issues can’t be found by staring at an user interface and picking out the mistakes.

User interface issues can only really be found by doing usability tests.

Okay, admittedly there are some issues you can pick out by just thinking about an UI or trying it out yourself. It’s easy to see when an UI for a touch-based phone has buttons which are too small for a human finger. It’s easy to see that CS4’s MDI doesn’t work well with Exposé. However, fixing these obvious issues doesn’t give you a usable interface. It just gives you an interface without some of the most obvious issues.

Unless you find a bunch of “naïve” users (as in: people who don’t know your application) and put them through a usability test, your UI probably sucks.² Because you really, really need to do usability tests to find the issues in your user interface.

Why you need to do UI tests

So why can’t you just test the application yourself? Because you’ve either designed the user interface, or used the application extensively. That means you got used to its flaws. You won’t even notice things which will become insurmountable stumbling blocks³ for your users.

Here’s an example. This is a prototype for a (now defunct) social networking site. I did usability tests for this site about four years ago; we tested with German-speaking users, so the on-screen text is in German. I’ve removed parts of the image which are unimportant for the eventual usability error many users encountered.

A lot of thought was put into designing this page. Since people who wanted to log in typically had seen the site before and thus know how it worked, the site’s homepage was designed to be easily understandable for first-time visitors. It starts out with a short “About Us” section explaining what the site is all about, then it encourages the user to register. Finally, for returning (and hence experienced) visitors, there is the login form.

And yes, when we tested the site, first-time visitors could easily figure out what the site was all about and how to register. Unfortunately, they couldn’t figure out how to log in. The login form ended up being just below the bottom border of the screen, below the fold, and a lot of user never tried scrolling down. The designers actually anticipated this and put a “login” link at the top of the screen, but the text was too small and too low-contrast, so users never saw the link.

Even though these users were returning visitors, they had not yet learned how to use the site and could not figure out how to log in.

This simple redesign fixed the issue; after the color of the header was changed to be more prominent and provide more contrast, and the text size was increased slightly, all test subjects were able to log in:

As you can see, the designers of the site’s homepage actually anticipated most of what could go wrong and tried to fix it even before any tests were done. Yet they still got it wrong.

How to do usability tests

Hopefully I have now convinced you that you should do usability tests with your application. If so, surely you’re wondering how to do that.

First of all, this blog entry assumes that you can’t afford to hire an actual usability expert, and have no usability expert on your staff. If this is not the case, consult with them instead of reading this.

If you ask ten usability experts how to run a valid usability test, you’ll get about twenty different answers. The truth is, it really doesn’t matter too much, as long as you get users to use your application, get out of their way, and record all issues they encounter.

It’s great to have a usability lab with two-way mirrors and recording equipment. These things help a lot, and you can rent such labs in most larger cities. But you don’t have to! You can just sit somebody down in front of your computer, tell them which app to use, be quiet and look over their shoulders while they give it a shot.

Eventually, your guinea pig will make mistakes, become confused, or even get stuck. And if he does, don’t chalk it up to his stupidity. It’s always your fault.

How many users do you need to test?

If you’re going to rent a usability lab, it makes sense to test a few people each round - five seems to be the sweet spot, but in my experience you will find plenty of issues even when testing with only three users. An advantage of having more test subjects is that you can test different versions of the same user interface to see which one works best.

If you’re not going to rent an UI lab, it’s enough to test one person at a time. Even when testing with only one person, you’ll probably find a ton of things to fix.

Just don’t stop after the first round; keep going with new people until you’ve eradicated at least the most atrocious issues (and use different test subjects each round, of course - otherwise they will learn your UI).

How to choose testers

In my experience, it really doesn’t matter too much. While expert users are more confident with new interfaces and will be more likely to try different things, eventually figuring out how your UI works, they are actually quite likely to become confused by the same things as inexperienced users.

Even so, it’s a good idea to try your UI with a wide variety of users. There are some things which confuse certain types of users, but may not confuse others.

How to prep users

It’s extremely important that users don’t think they are being tested. Make sure to tell them that you’re not testing them, you’re testing your application’s user interface. Every mistake they make helps you improve the application.

It’s okay to explain what the application is all about. You should not, however, actually show them your application. At most, launch the application for them, but then, hand them the mouse and get out of their way.

Should I encourage users to talk?

Some users are more comfortable when they don’t have to talk. You should probably tell them that it’s okay to talk about what they’re doing, but don’t imply that they’re required to talk. You don’t want the user’s opinion of your application or its user interface. Instead, you want to know why he’s confused so you can more easily figure out what’s wrong with your application.

Task-based or freeform?

Typically, usability tests are based on a set of tasks testers want users to complete. While this is a valid way of testing applications, sometimes just letting the users figure out what to do by themselves can offer interesting insight, as well. You could also start out by not telling users what to do, and then guide them into doing specific tasks if they don’t do it themselves. It depends on the application you’re testing, and on what you want to get out of the usability test.⁴

How to observe users

First of all, shut up. It’s very tempting to guide your test subjects to the proper solution every time they hesitate. Don’t. After your application ships and is in your user’s hands, you won’t be there to guide them, so test subjects must be able to figure out how to use the application without your help. You should probably only help your subjects if they themselves announce that they have given up and require your help. Typically, you should only interact with test subjects if they request it or if they’re obviously stuck in a way they can’t get out again.

The key to good listening lab moderation is to stay quiet, except in those moments where intervention is necessary (Mark Hurst)

Second, your test subjects are not stupid. Yes, they will struggle with the easiest tasks. No, it’s not their fault, it’s yours. Keep telling yourself that: It’s your fault, and it’s your job to fix these issues. If one person doesn’t get something in a usability test, thousands of your users won’t get it after you’ve shipped your application! Think of the support cost you can save by fixing this issue once instead of answering all those support calls. Never assume mistakes are the user’s fault!

Third, if you can, you should record the session - the screen itself, what is spoken, and - if possible - the test subject as well. It’s useful to record the test subject because his facial expression and gestures will help figure out what exactly he was doing.

You will miss a lot of issues while the test actually happens. It’s important to keep track of what happened so you can go back and check out what issues the user encountered and what specifically triggered the user’s confusion. Also, modern usability labs may be able to do eye tracking so you can see what the user was actually looking at; this is tremendously helpful.

Sometimes, watching the recorded session together with the test subject can provide further insight on why something confused him (although users will often be confused as to why they were confused - if this is the case, it’s your job to figure out what confused them and how to fix it).

If you can’t record the test, at least make extensive notes while it is running. If you don’t, you simply won’t remember all the issues the user encountered during the test. In most cases, even if you don’t have any external way of recording a usability test, it should at least be possible to keep some kind of screen capture application running which can also record input from the computer’s microphone. Keep minute track of what happens during the test.

After the test

Sometimes, we give little questionaires after tests, asking users what they liked or disliked about the application, what features they expect from such an application, whether they would use such an application and if not, why not. These often make for interesting statistics, and sometimes provide additional insight into why users behaved the way they did during the test. If you’re doing a one-on-one test, you can do this in person. However, always leave this for after the test, never ask questions like these during the test; you will only confuse your users and distract them from actually using your application.

What to do with the results

Fix them, then test again. Most likely, your fix won’t be much better than the original UI. This is an iterative task. Find an issue, try to fix it, test the fix, repeat.

When to test

Simple answer: Whenever you change something which affects the application’s users, even if it doesn’t change the application’s user interface. It’s important to remember that users build a mental model of how your applications work, what rules apply inside the black box. Even if you “only” change something in the back end of the application, that change may break the user’s mental model, creating confusion and doubt.

What about existing users?

In certain cases, it may be a good idea to test new versions of your application with existing users of your application. These users will behave differently from naïve users; changes which are easy to understand for users new to your application may confuse existing users because these changes don’t match their mental model of your application.

Conclusion

The main thing I want you to take from this is that you have to test. You can’t do flawless user interfaces without testing. Even just sitting somebody in front of your application and observing how they interact with it can be tremendously helpful, bringing many potential issues with your application to light. Just don’t forget that it’s always your fault. Never blame the user.

June 22nd, 2008 / Tags: usability, use tests, usability lab / Trackback

What I'd like to see in iPhone 2.0

On monday, Steve Jobs will open this year’s WWDC, Apple’s Worldwide Developers Conference. Chances are Apple will demo version 2.0 of it’s iPhone version of OS X, as well as a new iPhone. Here’s a few things I’d like to see in the new iPhone:

• An LED. Most Americans will probably wonder why you’d need an LED on your cell phone. That’s because you don’t use SMS; but over here in Europe, we do! Each time I leave my cell phone lying around and come back to it, I have to turn on the iPhone’s screen to see whether I’ve got a text message. Most cell phones sold over here have an LED that starts blinking when a new message is waiting or when you miss a call; this way, you don’t have to turn on the screen to see whether somebody has tried to contact you.
• A better camera. The current camera sucks. Enough said.
• A second, front-mounted camera.
• Bluetooth. The hardware is already in the phone. Support it, at least for sending and receiving files, and for Bluetooth keyboards.
• Search. Especially in the address book.
• Auto-correction. I want to enable several languages at the same time. And I want to be able to quickly turn it off for a minute, then turn it back on.
• MMS. Again, this is an European thing. Over here, pretty much all phones support MMS. Not being able to send and receive MMS is not only annoying, but also kind of embarrassing.
• 3G. Edge is neat, I guess, but over here in Europe, we have a great 3G network. Let me use it!
• GPS. Okay, I don’t really need this, but it would be a cool feature to demo.
• Street View. The iPhone already has a neat Google Maps app; Android’s is better, supporting great features like Street View. Copy this from Android.
• Some way for users to install apps without Apple’s blessing.

That is all.

June 7th, 2008 / Trackback

Where are Android's User Interface Guidelines?

The answer, it seems, is “nowhere.” As far as I can tell, there are no user interface guidelines for Android. Microsoft provides design guidelines for Windows Mobile. Apple has pretty good iPhone Human Interface Guidelines, for web sites designed for the iPhone as well as for native iPhone applications. Even Symbian has some usability documentation. Google, it seems, has nothing.

Will this hurt Android?

Well, go and take a look at the results of the Android Developer Challenge. Download the Top 50 Slideshow (pdf) and look at the screenshots.

In my opinion, from a UI standpoint, the results are rather sad. Don’t get me wrong, the applications themselves are awesome. There are some great, great ideas, and I will definitely pick up an Android phone as soon as I can. However, the user interfaces are all over the place.

There is no consistency. Many applications invent their own iconography and nomenclature for things. Most applications have custom buttons, windows, color schemes and widgets. Applications use different typefaces and font sizes, sometimes inconsistent within the same screen. The icon style seems to be undefined; some use flat icons, some have realistic pseudo-3D icons, some have even other icon styles; they all look different from each other.

Even worse, many applications have small, tightly placed buttons. These interfaces will be useless without a stylus; it seems these apps were designed to run inside the Android emulator, where they can be controlled using a mouse.

Frankly, while most of the application ideas themselves are awesome, the inconsistent (and, in a few cases, just poor) UI design is disheartening. Hopefully, these UI issues will be fixed before users get to try these applications.

June 7th, 2008 / Tags: Google, Symbian, Apple, iPhone, Microsoft, Windows Mobile, Nokia / Trackback