It Just Takes One Good Way

Can't decide which way is the right way to provide access to a feature? Just support them all! We know that users have a hard time figuring some things out. It must be their fault. We also know that users, in general, don't read documentation. Obviously, that's their fault. But, if we support a lot of different ways to access the feature, surely one of them will work for users.

Take this example. How do you edit the blog post in this user interface?

Let's see. You can click on the pencil icon for the blog post ...

... or you can right-click on the blog post and choose Edit from the context menu ...


... or you could click on the blog post to select it and then click on the pencil icon on the toolbar.


Two of those three methods have an unlabeled icon for a non-standard operation (Edit), so it's just as well that there are three different methods. Oh, wait, I forgot. You can also double-click the line.

One Good Way

Instead of providing multiple not-so-great ways of editing the blog entry, why not just provide one good way?

If you provide a method which is clear and consistent, you don't need to provide alternatives. Notice I'm so confident you can find it, that I didn't even bother highlighting it like I did in the earlier examples.

Then why do we still support double-click?

Good question. We probably won't document double-click, but double-click happens to be a near-universal standard for editing. If a user does double-click the row, what would they expect to happen? Our choices are: something else, nothing, Edit. Let's take this point-by-point:

• something else - this is pretty unlikely. Double-click almost always means Edit.
• nothing - the user double-clicked. What is the chance that they did it just for fun?
  
• Edit - this is almost certainly what the user expects. Whenever possible, we should do what they expect.
  

But isn't it a good idea to provide multiple access points?

Sure, but that doesn't mean multiple ways at the same location. It means that there may be completely different places in your user interface where access to a feature makes sense. While changing this, we did add another access point -- at the blog entry itself. If you view the blog and you have permission to edit an entry, then an edit icon appears next to the title of the entry.

Notice that it's a larger icon than the ones used earlier, so as to make it stand out better. You won't see this icon on other blogs, so that helps too. If you move the mouse over it, it highlights and a tooltip appears that reads "Click to Edit this Blog Entry."

In Summary ...

The principles are simple:

• When providing access to a feature, provide a single, clear method in any given location.
  
• If users expect to get access to the feature in multiple locations in your user interface, then there's a good chance you should be meeting their expectations.
• If users expect a standard mechanism (like double-click) to work for accessing a feature, then you should probably make it work -- but don't rely on this for making the feature discoverable.