I’ve often wondered what the difference is between a button and a link. I mean, why do designers prefer one over the other? Isn’t the link a rather modern “invention?” During my day-to-day work, this is an issue that has come up on numerous occasions.
Why do users sometimes expect buttons and at other times expect links? What should we do to further differentiate these interface elements and make them unambiguous?
While refining the interface at Event Seek we always strived for consistency. Making sure that your interface uses buttons and links in a consistent manner saves users from second-guessing what your interface implies.
Based on my use of the web during the course of my lifetime, I’ve assumed a number of things about how links and buttons work independently and together.
Speaking from experience: Links generally navigate the browser to or from a particular view, but have no real effect in terms of data creation or loss. That means, generally speaking, links should only change what or how data is displayed to the end user.
On the other hand, buttons typically execute an action (create/update/delete) on a particular item within your web application. Hence, if you are changing the state of any part of your application (modifying a database, for example), it may be best to use a button to do so.
This action/navigation convention is just one of many possible UI delegations. Find something that makes the most sense for you—or indeed, your users—and stick with it. Perhaps your users would find it weird if “adding someone as a friend” was a button they could click (after all, that is a bit verbose for a button), but, again, it is changing the state of the application. These are the kinds of questions you should ask yourself before choosing a convention. What will make the most sense (consistently) throughout the application? A user’s mental model may dictate that a link should be used over a button.
Consistency is one of the best ways to make your site more usable and your design more attractive.
The advent of RESTful application architectures facilitates this generalization. In RESTful applications, any links on the site can be considered “safe”, that is, clicking them will generally not change the applications’ state. If the state is indeed changed, it is easily recoverable. By the same token, any buttons on the site will change the applications state. Think: adding items to a shopping cart or saving a document. These are actions and are therefore better suited to buttons.
After you’ve decided which UI element does what, you should pay attention to making your links look like links and your buttons look like buttons.
Traditionally, links came in the blue variety; a fragment of underlined text that renders a “hand” style cursor on hover will meet nearly everyone’s mental model of a link. Over time, this model has changed to merely text which is underlined, or text that is visually distinct yet still presented in content.
In the early days of the web, most links were chunks of text that merely said “click here.” Unfortunately, many people (and search engines) didn’t understand that text. “Click here” doesn’t describe the content being linked to. More often than not, to understand what content lie on the end of the link, someone would actually have to go to the page for to which link pointed towards. Today, we can fix this problem by two means: make the linked text actually describe the destination (For example: Your buddy list will display if you sign in now.). Now users can simply see the ‘linked’ text and know what will be on the end of the link. Secondly, providing a ‘title’ tag to links will create a tooltip that gives both users and search engines more information about what lies beyond the click.
Buttons have evolved over the years. Initially, buttons were presented as static boxes in a rather simple UI. Today, buttons on the web are generally operating-system-specific UI elements that are rendered within a web page. Moreover, these buttons are generally 3-dimensional in shape with no highlight state. Presented this way, buttons can be the most easily overlooked element on a web page, since they will blend in with the operating system around them.
Thankfully we can style them any of a number of ways thanks to CSS–but try and keep something resembling a button. Slight bevels and rounded corners are key indicators that the user can click a button and initiate an action.
To further illustrate how important the distinction between links and buttons are, consider navigation without links, but rather, with buttons:
How confusing would it be to come to a site and be presented with a series of buttons that renders your navigation? Surely users would be much more apt to use “tabs” to navigate your site. Tabs, for those of you wondering, have become increasingly popular because they fit a user’s mental model of how a physical page works. In a tabbed notebook, flipping to a certain tab will bring that tab to the top of the notebook and show you content only related to the tab (assuming good sorting!).
Always look to the physical world for examples of best practices. In many cases problems that appear new are only virtual copies of problems in the physical world. Tabbed navigation is a common UI-Pattern that uses links to display collections of information.
Lastly, the concept of Extras on Demand allows Interaction Designers to simplify an interface by hiding ancillary interface elements. Extras on demand is a very useful pattern for displaying information to users. Always look to simplify your interface and provide users with only the bare-minimum interface elements. Allowing extras options only to savvy users, comforts new users and empowers advanced users.
Would these extras be better reached by the use of a “link” in the OS? Interestingly enough, links have slowly made their way into operating systems, yet they are the product of the internet. Do you think the differences between these two interface elements are subtle or distinct? When are each of these elements are appropriate?