views:

59

answers:

2

It seems like buttons and links are interchangeable these days. From a user-experience perspective, are there guidelines for choosing between the two? Does it even matter?

As a rule of thumb, I'd say that pure navigation should always be expressed with a link and an action should be expressed with a button. But there are so many examples and situations that veer from this, such as the Google Checkout Shipping Addresses page. Save performs an action and uses a button. Edit is a link that takes the user to a new page. Both make sense. However, delete performs an action with a link.

So, when how and why do we choose buttons or links?

Example Scenarios:

A page with a grid of users:

  • An add user feature that takes you to a new page. Link, because it navigates.
  • A reset password feature that remains on the same page. Button, because it's an action.
  • An export to csv feature that opens a download box but stays on the same page. I don't know.
  • A pager at the bottom of the grid that uses AJAX to refresh the grid. Links, because of existing precedence.

A wizard with "Next", "Back", "Cancel" and "Finish" features. While Next and Back should probably be links, precedence says they should all be buttons.

+1  A: 

I think the decision is based on how you want the page to work. For example, if part of the navigation involves using results from the form, then you would want to use a button.

So, if Add User has a select box on which type of user is being added, as it may determine which add user form to use, then a button.

For reset password, since it remains on the same page then a button could make sense.

I tend to do Next, back, etc as links, as I may have words or an image, but I like the hand that shows up for links.

Export to csv should be a button, since you are not going anywhere, just doing a download.

Either can work, but what is important is to not only be consistent, but to look at what similar applications are doing, to see if you can try to follow some industry standard.

As I mentioned, there are times I want the hand to show up, as it may not be obvious that something is clickable, but I don't want the button appearance.

So, if I have a word that can lead to an action, it should flow in with the rest of the text, but if you mouse over you can get some indication that this is clickable, then the link works best.

We don't always want buttons to look like buttons, so then links work, but this requires a very consistent interface.

James Black
+1  A: 

Good resources are: Nielsen (duh) and this discussion

Main guidelines used to be that buttons are for things that have effects (e.g. "Delete") while links are for actions that affect navigation. These days it's a bit blurred, but it is a good idea that non-recoverable action like deletion of a record should be a button no matter what.

In general, it is a lot worse to err by using a link instead of a button, since user does not expect the side effect action to take place at all.

I agree with all 5 of your examples, although Download CSV can safely be either and mostly depends on how the rest of the UI looks (e.g. if it is a part of a panel of actions like "Download"|"Options"|"Bookmark", and the other two are links, then yours obviously should be a links as well.

DVK
Good links, I don't know how I managed to avoid that Nielsen page for so long.
Greg