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.
Guidelines for Command Link Design
Windows Vista introduced a new GUI widget for commands: the command link. 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.
As for capitalization rules, 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 to:
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.
Secondary commands, 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.