Tuesday, May 15, 2007

Command Links

Command line links vs buttons ...

"Application commands can be presented as buttons or as links, which offer more room for explanation. For primary commands, however, buttons are still best.

In simpler times, there was one set of guidelines for websites and another set of guidelines for applications. And the two were clearly different. For example, there were different rules for presenting the user's options:

• Websites offered navigation through links (underlined colored text).
• Applications offered actions through menus and buttons.

The guidelines for websites and applications were different (and continue to be different) because of one of usability's foundational tenets: Good design is based on (a) the users and (b) their tasks. Websites and applications differ fundamentally along the latter dimension:

• Websites: The user's primary task is to move around an information space and read its content.
• Applications: The user's primary task is to change the state of some data set by issuing commands.

In fact, the very definition of an application is that its features affect something external to its own user interface. Using an application will make something change, because a user asks for it to be changed. In contrast, a website doesn't change simply because it's being used; the pages are always the same. (Although the information might change, website pages are conceptually static. For example, a page with tomorrow's weather forecast always contains this information, even though one day it displays the icon for rainy weather and another it shows the icon for sunshine.)

Blurring the Line between Apps and Sites
Over the last decade, the clear distinction between websites and applications has blurred.
First, on the semantic level, websites are offering more and more features. The first widely used feature was "add to shopping cart," and it's always been a guideline for e-commerce usability to show this feature as a button, even though it's found on a website.

So, for application-like website components -- those representing features or commands, rather than plain information -- you should follow the guidelines for application usability (as with the "add to shopping cart" feature).

The second issue is harder to deal with: On the syntax level, the distinction between buttons and links has blurred, because some commands are being shown as links.

Fortunately, we have at least one clear rule: don't use buttons for navigation. Users should click a plain link to move to another page of information.

Even this rule has an exception, however: the "continue shopping" and "proceed to checkout" options in a shopping cart are traditionally shown as buttons, even though they're pure navigation. Nothing changes when users click one of these two options -- they simply move to another page that has the commands they need to use. But because checkout is part of a workflow process, it gets a waiver from the plain-link navigation rule.

Mainly, though, the rule is to use links when users move between pages. Among many other benefits, plain links let users open a new page in a new tab or window if they so desire, and you can also show link text in different colors, depending on whether the user has visited the destination before."    (Continued via Alertbox)    [Usability Resources]

1 Comments:

Anonymous Michael Zuschlag said...

Nielsen has earlier argued that users are confused by within-page anchor links, yet he seems willing to endorse command links, which strike me as more confusing. I wish he had used his influence to discourage this growing misuse of links. We don’t need to use links for commands. There’re other ways to get the advantages of links while using command buttons.

9:57 AM  

Post a Comment

<< Home

<< Home
.