When creating an overall site style guide, how do you determine when a button or a hyperlink should be for something other than navigation?
I see many time with the heavy usage of jQuery and AJAX, hyperlinks do more than just navigation. Is it bad design to use them for something other than navigation?
Answer
In general, users expect links to link and command buttons to command. That is, links navigate, presenting new content without changing the underlying data objects or their relations or positions. Buttons change these things, performing creation, deletion, association, conversion, duplication, etc. An easy rule-of-thumb is if the most terse caption for the control is a noun (e.g., Home, Products, Site Map), then use a link. If the caption is a verb (e.g., Update, Submit, Delete, Purchase), then use a button.
However, you are correct that recently links have been used in place of command buttons in various web sites and even some style guides endorse this. In fact, links have been used in place of just about every other control (e.g., radio buttons, tabs, checkboxes). Furthermore, in thick-client desktop apps, buttons may navigate, especially in older apps that originated before the web (and links) was commonly used. I believe this confuses users and we really should use distinct-looking controls for distinct functions. Both web apps and desktop apps should clearly distinguish between navigation and commands by using links and buttons respectively. Navigating is significantly distinct than commands because:
Users easily revert navigation by clicking Back or closing the window. It’s always a “safe” action. Commands frequently cannot be reverted in a web app. If commands can be reverted, it’s through an Undo feature, which involves a different user response than Back or Close.
In desktop apps, users don’t have to save after navigating. Saving is frequently necessary after a command.
Commands provide different feedback that is often more subtle than navigation. It’s generally apparent when the user is presented with new content. Commands may show the change in the content, but often no change is apparent (e.g., for Copy or Save). Web apps often resort to confirmation pages (which doesn’t count as navigation in my book).
For these reasons, it helps the user to have distinct controls for navigation and commands, and fortunately user expectations for buttons and links make this easy. However, continued use of links for commands (and buttons for navigation) undermine these expectations, and soon we’ll lose this opportunity.
Graphically distinguishing navigation and commands afford us powerful ways to communicate with our users. For example if Contact Us is a link, then it displays a list of addresses and phone numbers (I’d label it “Contact Us” rather than the more terse “Contacts” since “Contact Us” is such a common convention, users scan for it specifically in menus). In contrast, if Contact Us is a button, then it takes users to a form where they can directly submit questions or comments (the button caption should have an ellipsis to indicate more information is required for the command).
I agree that command buttons tend to be bigger and uglier than links, especially when you have to have a lot of them in the same window, which is typical for web apps that lack an object-selection-action interface or pull-down command menus. However, the solution is to develop lightweight version of the appropriate controls, not recruit another control with a totally different user expectations. Such lightweight controls may technically be links, but they should look like the control they’re imitating. For example, a lightweight “button” can be a linked image of a small shaded rectangle with a center-aligned caption.
There is a gray area in navigation/command distinction which we should sort out. I recommend the following until the appropriate research can be conducted:
Use links for:
Loading a page of content
Loading dynamically generated content.
Loading content to part of a page if no other option is tenable (e.g., a tab).
Navigating between pages of a wizard (in contrast to traditional desktop wizards that use buttons).
Use command buttons for:
Actions that change or apply the underlying content or data 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.
Even more details, if you can believe it, at http://www.zuschlogin.com/?p=18.
No comments:
Post a Comment