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?
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.
Generally speaking, if it looks like a link, I expect it to load a new page of content from a different URL. Sometimes it will change my focus within the current document (i.e. href="#fragment") which is not too much of a problem, so long as it's obvious.
If it looks like a standard button (i.e. the same as my OS's standard button), I expect it to have the same effect, but with a side-effect that some information I have entered will affect the resultant page.
Any other, significantly different, behaviour should, in my opinion, be signalled, primarily through styling. That's the purist view. From a pragmatic point of view, it could be argued that, if a user clicks something that looks like a link and, rather than navigating to a different URL, part of the page changes in some way (the 'add a comment' link on this site is a good example), the user is going to 'lose' much as a result.
Note that this site has an awful lot of different link styles/behaviours (I count at least 8) but that's less of an issue since the main audience is likely to be very web-savvy.
The web has become more than a collection of static HTML-pages where hyperlinks are solely used for navigating the documents. I don't think it's bad design to use hyperlinks to execute commands. If we were to use buttons for everything that can be clicked and that is not navigation, web applications would look ugly and very busy.
One very important thing to note in the differences between links and buttons is that crawlers (both for search sites like Google and many site-level search engines) will not go to the target of a button; they only follow links.
