The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Links vs. Buttons in web apps

I've noticed many web apps use links where native desktop apps use buttons.

For example, using Gmail to reply to an email presents me with a UI containing only 3 buttons: Send, Save Now and Discard. Yet the UI also contains links for 5 additional features such as adding a CC and attaching a file.

Another example: 37Signals' Basecamp. The "New Message" form contains buttons for Posting the message and Previewing it, but a link for Canceling it.

Is there a subtle rule of thumb for what features should mandate a button instead of a link? Does keeping a low button count make for a cleaner page?

What are the opinions of web UI designers out there?
MonkeySpank Send private email
Monday, October 16, 2006
Links are somewhat "stylish". Big fat buttons may look a bit fisher-price like.
Anyway it is a subtle alchemy and, in my opinion, there are no recipes.
Sevenoaks Send private email
Monday, October 16, 2006
I have a personal theory that Ruby on Rails applications (like Basecamp) use hyperlinks for Cancel because there doesn't appear to be an easy way to use a button to cancel a form in Rails.
John Topley Send private email
Monday, October 16, 2006
Links are for fetching and showing things (GET), buttons are for storing or changing things (PUT, POST).
Zenon Send private email
Monday, October 16, 2006
>Links are for fetching and showing things (GET),
>buttons are for storing or changing things

Well, yeah, I understand that. I was asking more from the point of view of a user's expectations.

In a traditional desktop UI, buttons "do" things. Links don't exist. Along comes the web and now links "do" things too.

Whilst we, as web developers, understand the distinction between POSTs and GETs, and submission buttons and hyperlinks, is it also fair game to expose the user to this paradigm? How much confusion does Joe Average experience when using a UI where some actions are trigged by buttons, and others are triggered by links?

My own dad, for instance, took a long time to come to grips with clicking links in Gmail to "do" things. He didn't even *see* them on the page; he was so used to clicking buttons in Outlook Express.
MonkeySpank Send private email
Monday, October 16, 2006
I think most users perspective is somewhat aligned with the technical one. They may be used to clicking links in applications to fetch and display stuff, like in Windows help files, but actions that change state are usually started by clicking a button. I agree with your dad that Gmail uses links incorrectly in som places :-)
Zenon Send private email
Monday, October 16, 2006
This is an interesting issue to me as I spent yesteday trying to rationalise this.  I ultimately swapped out some buttons for links in my desktop app but this was further aided and abetted by Microsofts Vista design guidelines found here
and here
Monday, October 16, 2006
IMO, the use of links in place of buttons is among the most confusing and potentially dangerous developments to come out of web apps. More frightening, this convention appears to be creeping into desktop apps too. What does the link “Delete History” do? Users might expect it to provide a list of all the things deleted, when they were deleted, and by whom. Imagine their surprise when it erases all their log files. How about the link “Format your hard drive”?

From a little testing I’ve done, users expect links to “navigate”: to take them immediately to content or data, generally an entirely new page. Buttons are expected to execute commands, changing the underlying content or data: create, save, delete, modify, associate, replicate, convert, format, etc. However, I believe these expectations are rapidly decaying to user confusion due to the abuse of links such as mentioned by others (e.g., GMail, Ruby on Rails, and now  institutionalized by Vista). We as designers need to stop this before users are left playing Russian Roulette with our UIs. As far as I’m concern, links-for-commands is in the same category as using checkboxes when option/radio buttons should be used.

There’re gray areas we need to hash out, such as should a link or button change the *appearance* of the data/content (I vote for buttons) What about displaying a “dialog,” like one to add an address to your favorites –does that count as “navigating”? (I say, no; displaying such a dialog should be done by a button with an ellipsis in the caption). Should buttons or links be used for dynamically generated content when there is no dialog? (I suggest links be used). Also, I admit there are advantages to having “lightweight” controls for secondary commands, but the solution for that is to have smaller, flatter looking buttons, not use an entirely different control created for an entirely different purpose. For more discussion see .
Michael Zuschlag Send private email
Monday, October 16, 2006
Speaking as a web developer:

In my applications I typically use links in the way they were intended.. i.e. for page navigation.  I reserve buttons on certain applications for "commands" so the user understands that it is a command to process some form of data or perform some action with the data. 

I admit that I occasionally use "LinkButtons" (I develop in .NET) when I want to customize the UI with stylesheets to provide a better user experiece and when I do this I make sure to add an active link change so the user "thinks" they're pressing a button (e.g. change color to a darker shade, or modify the borders so the link looks like it's being pressed).

It's worked well in my limited experience using them.
Wayne M. Send private email
Monday, October 16, 2006
I don't think users have any mental assumptions about the difference between buttons and links.

I think a user would expect the exact same behavior from a widget labeled "Cancel Account", regardless of whether it was implemented as a button or a link.

From a technical perspective, though, it's important to only use GET for idempotent requests, and use POST for anything that modifies state on the server.

From a UI perspective, I don't think it really matters. Buttons can be more cumbersome in a UI than links. Not always, though. Like most other design principles, there are no hard-and-fast rules. Just do the right thing. And avoid doing the wrong thing. :)
BenjiSmith Send private email
Monday, October 16, 2006
On the other hand, buttons are likely to be larger than links, and thus easier to click.  (Well, larger than text links, anyway.)
Kyralessa Send private email
Monday, October 16, 2006
I think it's contextual.

If a link is by itself in the sense that it's surrounded by whitespace, people think of it as an action, similar to a button.

If a link is surrounded by text, then yes, either it's a request for more info or launches a separate window that allows you to do something else in parallel.

Imagine how confused people would be if you placed an actual "Save" button in the middle of a paragraph?
Monday, October 16, 2006
Slightly OT, but still related.  :)

Whatever you use, make sure they "LOOK" clickable.  If you use links, use underlines.  If you use buttons, make them look like a button.  If you use custom graphical buttons, make them look clickable.

If you don't, you confuse your users, and they leave.
Eric D. Burdo Send private email
Tuesday, October 17, 2006
Links should _only_ be used for navigation.  changing that breaks years of UI training.

There are a heap of untrained idiots out there who are using links for a bunch of stupid stuff, but the basic rule is that links should never, ever, ever change anything except the page you are on. Something that is going to change data or throwaway data should be a button and should check beforehand.
Tuesday, October 17, 2006
In the case of cancel it is rather hard to decide.

Cause cancel doesn't do anything at the side of the application data. it just navigates to an empty form or somewhere else.
On the other hand you could argue, that cancel does something in regards of the actual usecase/workflow.
So it is dependent how clear it is, that you have started some sort of workflow.

Most of the time i would go for the cancel button. Cause the only thing which matters in that case is the user not my application data status.
squiddle Send private email
Wednesday, October 18, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz