In simpler times, there was one set of
guidelines for websites
and another set of
guidelines for applications
. And the two were clearly
. For example, there were different rules for presenting the user's options:
underlined colored text
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:
: The user's primary task is to
an information space and
: The user's primary task is to
change the state
of some data set by issuing
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
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
, 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
, 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.
Guidelines for Command Link Design
Windows Vista introduced a new GUI widget for commands: the
. Once something is in the system that people use on a daily basis, it becomes a de facto standard. Because they'll encounter them frequently in Vista, users will come to
know and expect command links
Many websites already use links for commands. Still, while users are increasingly aware that links can activate a command, there's still the risk of confusing users because most links are navigational.
To reduce confusion, link text should
explicitly state that it leads to an action
and not just to a new page. It's not enough to communicate this info in the surrounding text; users often
scan Web pages
for the areas they can act on. Thus, you should assume that most users will only read the link text. In fact, users often read only the link text's first few words, so it's important to
start with a word
(typically a verb) that
indicates the action
that results if they click the link.
, refer to the guidelines for regular links in your corporate style guide. If you don't have a style guide, use sentence-style capitalization (that is, capitalize only the first letter of the first word in the command name). The exception would be if it's an inline link within a surrounding sentence. However, it's typically best to avoid having commands in the body text; inline linking should be limited to navigation.
Limit the use of command links
Actions with minor consequences
, since users might click something that looks like a link with the expectation that all it'll do is bring up a new page. In a brokerage application, for example, continue to use a button for the "buy this stock" command.
, since users will scan the screen for a button when they're looking for the "serious" or main commands. Thus, you should display the commands that are most important -- whether from the user's perspective or your own -- as buttons. For example, continue to use a button for "add to shopping cart."
Despite these limitations, command links have their place because they introduce some benefits. Most notably, with a link, you can write a
longer command name
and thus make it more descriptive, whereas button labels have to be short (4 words or less) or the button will look weird. Of course, since users don't like to read, you should keep your command descriptions as short as possible.
Vista showcases another benefit of command links: the ability to
add explanatory text
below the primary link text. You can present this explanation in a smaller typeface to emphasize its secondary nature (so experienced users won't waste time reading it). Because buttons are enclosed and thus self-contained, it's harder to add an explanation next to a command button. And, if you do, users are likely to overlook it.
The time has come to show some of your commands as links. Just don't overdo it.