Perhaps it has happened to you as a user. Say you’re ordering a dog pack on line. Never mind what a dog pack is, just pretend you’re ordering one as a gift and you get to a part of the page something like this:
“Well, self,” you say to yourself, “Let’s gift wrap it, but it should have a card too.” Click, click, and you move on down the page. What you didn’t notice is that the three options were coded to be mutually exclusive (a card is implied by gift wrapping), so by clicking the Gift Wrapped then Include Card, you ended up selecting the card and no gift wrapping. You were fooled because for some reason the page had check box controls when it should have had option buttons (a.k.a. radio buttons).
A scenario similar to this happened to me just recently (not involving dog packs), and I only just caught it. At the very least it would have been a big hassle if I hadn’t.
Using the right control for the job is elementary user interface design. There is a fairly small set of basic controls that cover nearly all user input you’re likely to encounter. These controls have a standardize appearance and behavior so the user knows what to expect from each so she or he is less likely to make errors. Users may not always be able to articulate what they expect a certain control to do (but I’ve been surprise by some that could). Typically no one has overtly explained to them the differences among controls to them. However, expectations form unconsciously from regular interaction with the controls. This guides users’ interpretations and decisions regarding the interface.
As we move to ever more sophisticated web applications, it’s important to remember this basic lesson from thick client GUIs: controls need to have distinct appearances that correspond to distinct behaviors. If we forget that and instead adopt an anything-goes attitude, our users will be left with only one strategy to cope with computers: CAMIDS. That’s:
Click Anywhere. Maybe It Does Something.
With so little direction to rely on, user inputs will be error prone and slow as users mis-guess what controls do and pause to check and re-try in order to get things the way they want. Users will ultimately feel lost and powerless.
Here’s another example: how often have you seen something like this proposed in a design meeting, where a combo box is displayed to provide compact and relatively easy access to a set of links?
How much of the meeting was then consumed in a tedious argument over whether it should have a Go button or not? One side argues that UI standards require a Go button because the combo box only sets an attribute or parameter value; users will be confused if it immediately jumps to executing an action such as navigating to a new page. The other side argues how pointless it is to make the user click an unnecessary and cluttering Go button; the user has made a clear choice, so why confuse them by requiring a separate action? There may have even been a third voice pointing out how nonstandard, potentially confusing, and downright silly it is to have the caption for the control also be among the list items to choose.
The truth is everyone is right. However, the problem isn’t to Go or not to Go. The problem is the combo box is the wrong control for the job. Desktop GUIs have the right control for this situation, but somehow it was forgotten when migrating to HTML. The proper control for this is a pulldown menu.
That is a control for executing actions immediately after selection, no Go button needed. It’s compact and uncluttering. It has a caption, but the caption is not among the possible items to choose. Since a pulldown menu doesn’t display a current value, you don’t have to worry about that value being out of sync with the page displayed. Unfortunately, because they are not among the controls accessed by HTML, to use a pulldown menu you have to create it yourself from scratch.
Link Misuse
There is another case of control misuse that is more serious than misuse of check boxes or a combo boxes, and that is the use of links for commands. Here’s some from REI’s web page.
I’m talking about the links for Update and Remove. If you already agree that using links for anything other than navigation is the greatest evil to emerge from web sites since the appearance of Flash intro screens, then scroll down to Gray Areas. If on the other hand, you consider links to be just another kind of command button, or you want ammunition to argue against someone who endorses such a position, read on here.
The Update and Remove functionality have no business being links. Links should link things. They connect the current content to another, providing a navigation path for the user. They present content, whether it be text, fields, pictures, tables, records, or attributes. The links above by and large do not do this. The Remove link doesn’t link to anything. It deletes the adjacent item from the shopping cart. That may come as a surprise to a user that expects a link to display content, an action easily reversible by the browser’s Back button. The Update likewise doesn’t display content about updating. Rather, it posts changes made to the quantities text box. I wonder if REI gets complaints from users who, expecting the Update link to take them to a page that shows some updates, instead experience a link that seems to just re-load the same page without any changes.
Arguing that a link should link is not just being pedantic. Users expect links to navigate. Specifically, they expect an entirely new page to load, replacing the current page. Any other action is liable to cause confusion. To users, navigating is far removed from what the links in the REI do, which is execute commands, actions that apply or alter the underlying business objects. Navigation is a very different action in the users mind, a safe action that changes no underlying content, that becomes another step in the user’s browsing history, an action easily reversible by the browser’s Back button, the one safety net even the most novice web surfer knows. The Update and Remove links on the REI form are not reversible by the Back button. In fact, I don’t believe they’re undo-able at all. Now that’s a cruel trick to play on users: present something as harmless and reversible, when it is neither.
And it is also unnecessary. There is another perfectly well-established control that users expect to execute commands, and that’s the aptly named command button. Command buttons are for initiating or stopping a process or action, usually something that changes the content: creating, updating, deleting, copying, converting, transmitting, associating, or dissociating the underlying business objects. Using REI’s own graphic “buttons” (although there are technical reasons to consider using only genuine command buttons), the REI page should look like this:
Command buttons look entirely different from links, reinforcing the intuition that they perform a different kind of action than a link, just as the distinct appearance of a check box indicates it performs a different kind of action than a option button. Even if users didn’t have pre-existing expectations for links and command buttons, we shouldn’t have two very different looking things doing the same thing. It’s like have two entirely different looking kinds of list boxes.
The Cost of Link Misuse
The misuse of links in place of command buttons must be stopped now. Rich web apps are becoming more commonplace. Once isolated to a few e-commerce or email web sites, users are increasingly likely to come across this link misuse. The more that happens, the more the normal and necessary expectations about links will be diminished.
Furthermore, web app conventions, including the use of links, are making their way into desktop apps. This is a good thing. In a traditional desktop GUI, if you wanted to provide a control to navigate the user from the current content to some other, you had little choice other than… a command button. Another possibility is a menu item, a control also typically associated with executing commands more than navigating. This has never been really satisfactory. For one thing, big clumsy command buttons and menu items are at best awkward to embed in text (e.g., as part of in-the-window documentation). Links handle this situation with aplomb.
Secondly, because users expect command buttons and menu items to execute actions, many designers feel compelled to include verbs in the captions of such controls when used for navigation. You get buttons and menu items labeled “View Inventory” or “Manage Accounts” or “Open Sales Report.” The problem is such verbs really don’t provide much information, instead adding clutter to the caption, obscuring what really matters, the content the user can access. I’ve seen whole menus with nothing but items saying “View this” and “View that.” Such a waste of pixels. Worse, the verb may even mislead. “View Inventory” for example may suggest that viewing is the only task supported –no updating allowed. It’s so much better if we can just have links for Inventory, Accounts, and Sales Report. The fact that they are links makes it clear that they perform navigation. But this assumes we consistently use links only for navigation.
(Parenthetically, you sometimes see links on web pages that include a verb that simply means “navigate.” For example, note the REI web page above includes a “Get info on taxes” link. What’s up with that? Wouldn’t simply labeling the link “Taxes” be enough? After all, don’t all links get info? Well, I guess not, at least on REI’s web page.)
So while having links in desktop apps is a potential improvement, the misuse of links for commands will undermine this. What’s worse, this practice is about to be institutionalized. It’s one thing to see it in the Wild West of experimental interactive web apps, but it’s quite another to be a suggestion in the friggin’ Vista User Experience Guidelines:
Traditionally, command buttons are used to initiate actions whereas links are used to navigate to other places.
So far, so good.
Given the popularity of the Web, the usage of links has expanded to include initiating commands and selecting options as well. [Emphasis in the original]
What kind of rationale is that? “Well, they do that on the web pages, so it must be okay”? News flash: Lots of things done on the web pages are stupid, stupid, stupid. Hey, MS, if all your friends jumped off a bridge….
But let’s discuss Vista some other time. The point is that if we as designers don’t stop this link misuse now, the clear and useful expectations users have for links will be replaced with a case of CAMIDS.
In a simple web app like an e-commerce site or web mail, like Gmail above, you might get away with link misuse because the presence of a verb in the link label, like “Attach,” cues the user that a command results. Text can overpower other visual cues sometimes. I suppose you could write “Attach File” on a landmine and users would click it to attach a file. However, there is still a conflicting message being sent to the user that can give a sense of unease and delay responses. Also in English, the part of speech is not always unambiguous or may be determined by only a few letters the user may fail to notice.
Let’s say you’re working in a personal financial app, and there’s a link labeled “File Details.” Well, hey, maybe you’d like to see the details on your file. Unfortunately, what this link actually does is file all your financial details with the local IRS office. And request an audit. And please do “the works.” How about a link labeled “Delete Log”? Maybe it shows a log of all deletions, but it sounds more like it will delete your log. Do you want to click it and see? Need to see earlier drafts of your document? Click “Rewrite History.” Da, comrade, am re-writink your ‘istory now. Maybe you’d like some documentation on doing a completely clean installation of the operating system on a computer. So, do you click “Formatting Your Hard Drive”? Or did that say “Format Your Hard Drive”? Is there a difference? Well, if links always link to content, then a link labeled “Formatting Your Hard Drive” would safely mean it navigates to an explanation on how to format a hard drive. On the other hand, a button labeled “Format Your Hard Drive” would clearly mean, well, it’s not something to click cavalierly. On the other hand, if we keep using links for commands, pretty soon we’ll have to label all proper links with “Get info on” just to prevent confusion.
What does it mean when the caption for a field or the field value itself is a link?
If links consistently navigate, then the user would probably guess that it provides documentation or details on that field or value. But if links can execute commands, it could do anything. Maybe it opens a menu to select a value for the field, maybe it sets the field to the default value, maybe it sorts the displayed records on that field, maybe it filters the records on the field value. You’ve a UI well on its way to CAMIDS.
Gray Areas
My impression is that designers here and there agree with the principle that links are for navigating and commands should be left to command buttons. However, there are some gray areas between navigation and command that need to be worked out. Ultimately, empirical research on users should decide these gray areas, but in the mean time, consider the following to be working hypotheses, with the goals of consistency with existing GUI and web page conventions and maximization the usefulness and simplicity of information conveyed to the user by the choice of control.
Dynamic Generation of Content
What if your content is generated dynamically? For example, what if your content is the latest inventory of dog packs, content that may change each time it is displayed? Should that content be accessed by a link or command button? Traditionally, links access static content. The same link accesses the same content each time, at least until the link breaks. One may argue that generating content is a computational process and processes are initiated by command buttons. However, looking at this from the users’ perspective, any invisible processing is unimportant to them. As far as they are concerned, they navigated to content when they clicked something. That the link happens to fire off a stored procedure is both unknown and unimportant to them. Thus, the control to do this probably should be a link, as long as the user is not overtly supplying parameters for the content generation (more on that later). The dynamic nature of the content may be indicated by the link label (e.g., “Dog Pack Inventory (Current)”) if there’s reason to believe users will be confused by content changing with each click.
Within-page Content Changes
Suppose you are only changing some of the content on the page. For example, say your web page displays the essentials about your dog packs one part of the page, while below alternative content may be displayed to the user (e.g., photos of dog packs, comparative specifications on dog packs, reviews of dog packs, etc.). Or suppose you have a master-detail layout for a page of dog packs, where one half of the page is a table of all available models of dog packs, while the other half of the page lists the features of a single dog pack from the table. Clicking on a dog pack in the table results in the details of the selected dog pack appearing in the other half.
Or then there’s something like a tree control, where the user can click on a dog pack in a list and the space for that pack in the list expands to show details of the pack right within the list.
These seem like a clear case for links rather than commands buttons, and I’m inclined to agree, at least with the “rather than command buttons” part. A click loads different content, just to a part of the page rather than the whole page. Maybe you could even construe it as a click loading a different portion of a page –where all detailed content for all dog packs is considered to belong to a single Dog Packs page, and clicking determines what particular content to be visible to the user. There’s a precedent for that already with web pages, namely, anchor links, where clicking the link scrolls the user to a different part of the same page. There’s also the precedent of web pages with two of more frames, where selecting a link in one frame determines the content in another. These are conceptually close to using of links to populate the viewable portion of a page. If the choice is only between a link or a command button, then a link is the control to choose.
However, there are two disadvantages to using links for changing within-page content. First of all, even after years of exposure, users are still confused by within-page links. Users assume whole new pages to be loaded from links, and can become disoriented if that does not happen. You as a designer may construe it as all one page, but users won’t necessary see it that way. Maybe they’ll re-read the master half of the page thinking it must have changed. Or maybe they’ll repeatedly re-click the “broken” link, not realizing something new has loaded in the detail half. It has been suggested that such within-page linking be signaled with an icon, but right now no standard exists for that (my vote is for a simple arrow like 
).
An even more serious problem with changing within-page content applies to both links and command buttons and that is neither indicates a state of the content they display. After clicking on “Reviews by Humans” (versus dogs) how does the user know they’re looking at a review by a human? They have to look around for a title in the detail half. With a master-detail layout, how do show you which dog pack the specifications apply to? Again you need a title for the detail half that is removed from the user’s focus when they clicked. With a tree display, how do you remove the dog pack detail? Click the same link again? When has a link ever just removed content?
The answer to within-page content changes is to avoid links and command buttons whenever possible. Use other controls or conventions that show the current state. For example, place the photos, specs, and reviews on different tabs. Even using a list control to select the within-page content is better than using links. For the master-detail layout, use a current record indicator, such as seen in Microsoft Access and Oracle Applications. If you’re not inclined to custom-build your own control for this, an option button may be adequate.
For a tree display, use toggling “–“ and “+” buttons, like you would see in an actual tree control.
Views
Views are alternative presentation of the same content, while the underlying content itself is not changed. Changing the filtering, sorting, or field order of a table, for example, represents changing views of the content in the table. Showing user-entered content in Normal versus HTML also represents different views, as does showing a geographic region as a street map versus a satellite photo. The key here is that the same content is being shown differently, which is not consistent with original concept of hypertext: links are always between content, not between the same content, even if viewed differently. On the other hand, if command buttons are used, what’s the command? Sorting, filtering, and ordering are sort of like commands in that they manipulate data, even if they don’t actually alter the underlying business objects, so they are probably closer to something done with a command button than a link. For example, if you want to allow sorting of a table by clicking on the column headings, the headings should have a command button look and feel, rather than link. Otherwise, users may think clicking the header provides documentation on the column (e.g., maximum and minimum values).
Switching between Normal and HTML or street map and satellite photo however are more like things done by a link, as there no real data processing going on, just a change in the user’s point of view, something that can be accomplished with “navigation.” Seems like splitting hairs, I know. This is the grayest of the grays.
However, like within-page content, link-or-command-button is the wrong question. It would be better to use a control that indicates the current state of the view, something neither a link nor a command button does well if at all. Views are usually best changed with attribute controls such as check boxes, option buttons, and combo boxes. In a sense, changing views is changing the attributes of the data presentation, changes that are seen instantly in the content (no Apply command button necessary or desirable), not unlike the Format toolbar in an office suite where the font and style of the current text is shown and changeable from one set of controls.
Dialogs Execution
By “dialogs” I mean a page or portion of a page where the user enters parameters to execute a command. For example, a page where a user can build a list of addresses to send an email to, or create an appointment in an on-line organizer, or your basic Search page or section of a page. So what control should execute the command, applying the user-selected parameters, whether it be the list of addresses for an email, the required fields for a new appointment, or the criteria for a search? That’s an easy one: dialogs by definition execute commands, so you use a command button.
Some might argue that the Search page is really navigation not a command, taking the user to content and not altering the underlying content. However, unlike command buttons, links have no tradition of applying user-supplied parameters. The only parameters in a link are those implied in the link label itself (which usually gives the name of the content that will be shown). Users are liable to be confused by a link that changes based on input on an entirely separate control. Also, Search by convention has always used buttons on the web. Users often learn new things by thinking by analogy, so any “navigating” that involves applying user-supplied parameters should use a command button just like Search does. A query page, for example should execute the query with a command button.
Dialog Access
There’s dialog execution. Then there’s dialog access. Should a button or link be used to get to the dialog page? Sounds like pretty straightforward navigation that should be done with a link, but assuming the page only includes the parameters to execute a command (no real content), I would actually recommend a command button. My reason is that when a user is looking for a command (e.g., to create an appointment), s/he is not necessarily going to know if parameters are needed or not. If the Create Appointment dialog may be accessed by a link or command button, the user has to scan the page for both, which will take longer. If commands are consistently accessed with command buttons, whether they need parameters or not, then there’s only one type of thing to look for.
Of course, a user who clicks a Create Appointment button may be surprised if they end up going to a new dialog page rather than simply seeing a new appointment appear on the current page. Fortunately, designers of desktop apps from ancient times anticipated this confusion and provided a solution: if a command requires a dialog, include an ellipsis at the end of the button’s (or menu item’s) caption. That cues the user that there’ll be navigation before execution of a command. The same convention should be applied to web apps. In a sense, we have three distinct-looking controls that do three different things, providing users with the best information on what to expect.
- Use links for navigation to content
- Use a command button with an ellipsis for navigation to a command’s dialog
- Use a command button without an ellipsis for executing a command.
Dialog Canceling
So if you have a dialog, you should provide you user with a means to cancel the associated command. Link or Button? Being a verb, “Cancel” sounds like a command, but what is does is navigate the user back to the previous content. I think it could be either. If in addition to navigating back, canceling also resets the parameters to their default or previous values (just as canceling a dialog box in a thick-client app), then it’s a command button; the potential changing of values is clearly a command. However, if canceling does not reset any user entry, then it should be a link; all it does is navigation. However, if it is a link, I wouldn’t label it “Cancel” but rather “Back to [content name]” to make this clear.
Back and Next in a Wizard
Convention says users move back and forwards in a multi-page “wizard” dialog with command buttons. I say that’s a mistake. This is navigation pure and simple and should be done with links. There’re advantages to having only the Finish action be a command button while navigating within the wizard is accomplished with links. It makes it visually clear to the user when they are giving their “final answer” and the command is about to execute –no going back and changing things after clicking “Finish.” It makes it easy to label Next and Back with the actual name of the page they go to, cuing the users to what to expect (e.g., whether they can just skip it or not). Thick-client apps as well as web apps would benefit from adopting such a convention.
Using links for Back and Next won’t cause confusion as long as Back and Next are always links and other visual cues make it clear to the user that they have entered a wizard. It’s not like the problem of using links to get to a command’s dialog (including a wizard) from a content page, which would require the user to know something about implementation (whether a command uses a dialog or not) in order to know what to look for.
Pulldown Menus
I had mentioned that users usually anticipate menu items in a pulldown menu to execute a command, not navigation, although I think this expectation is not as strong as for command buttons. Nonetheless, this may lead some to argue that pulldown menus should only execute commands. Personally, I don’t see a problem with a menu item performing navigation as long as the menu item looks like a link. For example, while command menu items typically have black captions on a gray background (having the visual cues of a command button as well as the typical pulldown menu), link menu items should have a link-colored captions on a white background. Maybe such menu items should also have underlining, as long as access keys are not being supported (although, actually, they should be). This is something desktop apps can use too, eliminating the tendency for those View this-and-that menu captions. If a menu item looks like a link, then it links; no need for any action words like View etc.
The Quick Answer
If all this talk about gray zones is way to philosophical for you, the easiest answer to the question of links versus buttons is to let your control’s caption tell you. Pick the best most concise caption for the control. If the most informative or important word in the caption is a verb, it’s a command button. If it’s a noun or noun phrase, it’s a link. A verb indicates the command executed. A noun indicates the content the user navigates to. A Refresh control is a button because “refresh” is a verb. That’s easy enough.
The only exception that comes to mind is “Contact Us” which should be a link if it presents a page of contact information like email addresses and phone numbers. It probably should be labeled “Our Addresses and Phone,” but “Contact Us” has become a de facto standard that users have come to expect, so stick with it. Of course if “Contact Us” presents a page to provide immediate feedback via a form, then it should be a button with an ellipsis at the end of the caption. Come to think of it, that’s a nice way to subtly indicate if you’re providing contact information or a more immediate means of contacting, something I as a user would appreciate.
This caption test works best if you pare down your captions to their essentials, which is generally a good idea anyway. You should never have a button or link labeled “Transfer funds wizard.” A user will be looking to transfer funds, not use a wizard. They don’t really know or care if funds are transferred via a dialog, a wizard, digital ESP, or a dog pack. The caption should be “Transfer Funds” or maybe just “Transfer” if it’s shown right next to the user’s funds. And it’s a command button.
You should never have a link or button labeled “Manage Funds” or “View Funds” or “Get Info on Funds” or “Download and display in your browser window some data regarding your funds right here and now, yep, yessiree.” The verbs and other words are vague and do not provide enough information to justify their pixel consumption. Whatever the user is looking to do to their funds, chances are it’s something more specific than “managing” them, so that word helps them little. The caption should simply be “Funds.” And it’s a link.
A Need for Lightweight Buttons
You may still experience resistance to using command buttons rather than links for all commands and for good reason. The problem with command buttons is that they were never intended to be used en masse. A window in a thick client app might have two or three or at most six buttons. Any more and a pulldown menu would be used. The appearance of command buttons was developed with the expectation that they execute actions within a dialog box or message box. Thus, they were designed to be “heavy”; to grab attention. When a user looks at a dialog box, you want his or her eyes to fall on the OK and Cancel buttons easily since their operation is key to making the dialog box work.
Unfortunately, when making a web application, there is often need for a whole flocks of controls for commands. My mock-up of the REI page with Update and Remove buttons might look okay with only one item in the shopping cart, but imagine if there were 10. Using buttons for all of these commands would be too cluttering, distracting attention away from the actual page content, which is generally more important. Plus, it just looks ugly.
The tendency for large numbers of command controls in web apps is partly due to web apps not having an object-selection-action model for their commands, thus requiring every object represented to have it’s own set of command controls. As web apps become more interactive, web apps will ultimately need object-seletion-action syntax because even using links for commands will become too cluttering. But what do you do if a web app is not worth the complexity of implementing an object-selection-action syntax?
Even if there are only a few command buttons, some buttons are more important than others, and should be more obvious to draw user attention. Some commands are what MS calls “secondary commands,” representing minor or rare branches off the most common use case. Wouldn’t be great if secondary commands were visually distinguishable from primary? Ideally, controls should be salient contingent on their importance.
Another problem with command buttons is the long captions that often go with command controls in web apps to provide better self-documentation for the controls. Command buttons were designed to handle short captions, maybe a word or two. Long phases like “Return to Quality Control for Review” make big ugly buttons. Links are a visually more appealing and less cluttering alternative.
A case can be made for having a command control that is more lightweight than a command button. However, the solution is not to use an entirely different control with an entirely different appearance, history, and set of expectations. The solution is to create a lightweight command button. Such a control should have the basic button visual features, such as a gray rectangular background, but otherwise should be more subtle than full-fledged command button. In particular, loosing the beveled border, at least until mouseover, may be a good idea. GUI’s have always had variable size and weight for font, yet on thick clients we still lay out complex forms and dialog boxes like we’re dealing with fixed-font character cell displays. We need lightweight buttons and other controls for both web and thick-client apps. Amazon apparently follows this philosophy, using lightweight versions of their buttons for secondary commands.
Note how the lightweight buttons contain the same graphic features (e.g., color and shape) as the more prominent main buttons.
As for long captions, I don’t see any reason that additional or explanatory text can’t be placed beside a button.
Summary Checklist
Problem: Selecting links, buttons, and other controls for specific purposes to minimize user confusion.
Potential Solutions
- Use a pulldown menu rather than a combo box for lists of links or commands.
- Use state-showing controls like tabs, option buttons, checkboxes, and combo boxes to control the view of the content or the appearance of content on a part of a page.
- Use links when the most concise caption is noun. This includes:
- Loading a page of content
- Loading dynamically generated content.
- Loading content to part of a page if no other option is tenable.
- Navigating between pages of a wizard.
- Use command buttons when the most concise caption includes a verb. This includes:
- Actions that change or apply the underlying content or business objects.
- Actions that affect the view of the content if no other option is tenable.
- Execution of a dialog’s commands, including the Finish action of a wizard.
- Canceling of a dialog, assuming canceling resets the dialogs parameters to the default or previous values.
- Use a command button with an ellipsis at the end of the caption to access a dialog.
- Develop and use lightweight buttons for secondary commands.
