What are the differences between buttons and links?

Question

What are the differences between buttons and links?

Answer 1

Rule of thumb: a link takes you to other place, a button does something.

That said, things can be flexible in this regard. Links are sometimes seen as low priority buttons, and buttons, almost always take you to other place.

[edit 2013] Things have changed a bit since I wrote this answer. I now use big buttons as clear "call to action" and try to avoid using more than two of them on any screen. Then I use smallish, tag-like buttons or links as low priority options.

The different meaning of buttons and links is not in their nature, but in its visual weight and its place in the hierarchy of the screen/design.

Answer 2

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, in thick-client desktop apps, buttons may navigate, especially in older apps that originated before the web (and links) was commonly used. Furthermore, more 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).

I believe all 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 link and buttons respectively. Navigating is significantly distinct than commands because:

• Users don’t have to save after navigating. Saving is frequently necessary after a command.

• 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.

• 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 there is a need for light-weight controls for secondary actions, especially for typical web apps that lack an object-selection-action interface. 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.

Gory details at http://www.zuschlogin.com/?p=18.

Answer 3

Links convey relationship, whereas buttons stress action.

This reasoning is based on the premiss that buttons actually mimic physical buttons, and the symbolic meaning of links stems from chaining.

If you think what a real button or trigger on a machine does, it is easier to see what kind of actions a digital button can use. I.e. on, off, fire, and so on. The same goes for thinking of hyperlinks as index cards in a library - book abc on shelf a1 section b - they are used to identify a way to an item.

Both are interchangeable in different scenarios, but the implied functionality is slightly different.

Answer 4

Links are text—if you can only click the text, it's a link.

Buttons tend to look like physical controls or icons (although many are disguised as links)—if you can click the area around the text, it's a button.

Links tend to navigate to different pages, while buttons tend to stand for actions, but those actions often include navigation. Links tend to provide a lighter visual impact because they are text-based. Buttons tend to emphasize a functional use. For example, a big SAVE button has more impact than an inline "Save" link.

Buttons represent the mental model of physical controls, while links are a purely hypertext entity with no physical analog. As web design has evolved, the UX distinction between buttons and links has blurred: many buttons are styled to look like just text; CSS-styled text takes on the look of buttons.

Answer 5

Semantically speaking, any action which modifies server state should be done using a POST request from a and therefore use a button, rather than a link.

That's not to say the two can't be styled up to look and behave identically, but the markup should be different.

Answer 6

In the good old days when you could easily change the 'read / unread' period in the browser, which show read links in a different colour - the advantage of links would be that you could easily see where you'd already been.

(Footnote - you may still be able to change the periods - but I've long since given up trying to find the control which does this...)

Answer 7

Links have been around for a long time and have a higher population than buttons on the web. When used in the context of navigating content they are effective.

Buttons are a much stronger affordance when you use them in the contexts when he user makes a form of commitment or investment to the website. (ie. saving, sharing, subscribing, joining, etc.)

I explain this in detail in the article I wrote: the-link-vs-button-debate

I hope this clears up the question of when to use the two once and for all.

Answer 8

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.

Beyond that, luna, Michael and Pete all have valid points that cover just about everything else that I could think of.

Answer 9

I agree with the above, and I am against using hyperlinks for commands, particularly in non-web apps (e.g. winforms).

In non-web apps a hyperlink says to the user "ignore me unless to want to navigate away to some different information" and a button says "I'm going to change something or show a dialog if you click me".

The problem comes when the two are used interchangeably and a new user is scanning the form looking for a particular command. After a while they realise that they need to look at all of the hyperlinks too and invariably it takes the user twice as long to find what they are looking for because UI metaphors are not consistent. If the metaphors are not consistent the user loses trust and begins to hate the software. Trying to use software like this drives users up the wall (I think hotmail had the "attach" command as a hyperlink for a while and certainly for a while they had it in a combobox).

The Microsoft Windows Interaction Guidelines are a little fuzzy on the issue:

Command Buttons Vs Links

Guidelines: Links

They suggest that they are acceptable for secondary commands. The link posted by Michael Zushlag above makes an excellent point about this and the need for lightweight buttons.

The problem I see with lightweight buttons for secondary commands is knowing which commands these are. If you can come up with a consistent logic behind these (that is apparent to the user) and you can differentiate between primary and secondary commands with ease, then this is the best option.

Answer 10

Michael Zuschlag's answer is great, I would only precise that a link is different than a simple reference (an anchor).

Many people make a confusion between user experiences/interactions and HTML markup because they do not view the difference between a link and an anchor: - a link has a direction (forward or reverse link) and can be identify with a relation but can not be used by users with their user-agents to access to the hypertext reference (href attribute in HTML) because they can not be activated (except on Opera with the navigation toolbar). - an anchor only refers to something. It is only a reference to another resource even if it can be activated (with a click or with your keyboard) because user-agents defines this behavior.

And I think it help us to understand differences between an anchor and a button: - use a button when you call to action (as Michael said with "Update, Submit, Delete, Purchase" but also "read more", "download", etc.) - use a anchor when you just refers to another resource with an anchor text identifying the resource. If you require your user to read it, that means it is a "call-to-action" and not just a reference, so implement it with a button.

Answer 11

My experience show that often links are recognized easier as clickable and therefore clicked better taht for us sometimes leads to decisions to use links instead of buttons. But I agree that that shouldn't be done deep inside a process where the user is triggering an action. I also would like to add that the verb/noun differentiation can be difficult in other languages than english.

Answer 12

Whilst it is true that buttons and links are used interchangeably on the modern web, there is one fundamental browser feature that sets them apart:

Users can open a link in a new window or tab. A <button> or <input type='button'> cannot.

(As an example, try right-clicking on the "add comment" link and the (Add Comment) button below - only the first allows "Open Link In New Tab".)

Although <a> links can be styled to look like buttons, users will generally only expect the open-in-tab functionality to work on things that look like links.