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.

Anchor Link vs Button

When authoring web sites are there any guidelines one should use in determining whether to use a anchor link vs. a button to go to a new page?
New to Web Applications
Friday, September 14, 2007
 
 
Use links. That's the normal way to point at other pages. Period.

Use buttons only when you need to submit some user-entered data to the next page - i.e. only when you go from the "hypertext" model to "terminal" model.
ping?
Friday, September 14, 2007
 
 
I would say links are for navigation and buttons are for invoking actions that will (potentially) change state.
Arethuza Send private email
Friday, September 14, 2007
 
 
Links must never change state, while buttons could potentially change state.

Google for REST.
Troels Knak-Nielsen Send private email
Friday, September 14, 2007
 
 
IMO, use links when the most concise caption is noun. This includes:
- Loading a page of content
- Loading dynamically generated content.
- Loading content to part of a page if no other option is tenable.
- Navigating between pages of a wizard.
Use command buttons when the most concise caption includes a verb. This includes:
- Actions that change or apply the underlying content or business 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 page.
For rationale and more than you'd think was possible to say about buttons versus links, see http://www.zuschlogin.com/?p=18.
Michael Zuschlag Send private email
Friday, September 14, 2007
 
 
I agree with the people above, with one precision:

What's important is the way your controls LOOK. Not the underlying HTML tag you used.

Use CSS to create links that look like buttons; that will help you get away from the default grey buttons, and keep the "intuitiveness" of your app.

That is, unless you absolutely want to use HTML button or submit controls.
Don't fix what ain't broke.
Friday, September 14, 2007
 
 
Yes, there are guidelines for using links in websites - The Research-Based Web Design & Usability Guidelines

http://www.usability.gov/pdfs/guidelines.html

Chaper 10 contains the info about links.
Craig Pickering Send private email
Friday, September 14, 2007
 
 
Think of it this way: links get crawled, buttons do not.
John Cromartie Send private email
Friday, September 14, 2007
 
 
> What's important is the way your controls LOOK. Not the
> underlying HTML tag you used.

Completely false.  See my last comment.  When you use a link that LOOKS like a button (through CSS), nearly all automated web crawlers will follow it anyway.  It doesn't matter how hard you tried to make that "delete this page" link look like a button... it's going to be interpreted as just another link to follow.

Of course robots.txt helps, but unless your app is a carefully warded off from the rest of the world, it is safe to assume that it WILL get crawled at some point.
John Cromartie Send private email
Friday, September 14, 2007
 
 
In addition to what's being said here, it's vital that you read up on GET vs. POST. *NEVER* write anything that changes state on the server in response to a GET request.

As for buttons vs. links, use buttons if you're submitting a form and links otherwise. If you find yourself styling links to look like buttons, buttons to look like links, or wrapping submit buttons in forms with no other inputs, you're doing it wrong.
clcr
Friday, September 14, 2007
 
 
I'm not sure how you would apply that rule in real life.

How about cancel buttons, which might just send you to another URL. Should those be links, even if there's a Submit button right next to them? (Facebook does this, and it looks weird.)

What about buttons that submit forms, when the user doesn't think of them as submitting forms? For example, compare Previous and Next buttons in a multiple-page form, to Previous and Next links in a sequence of static pages. Should they really be different?
JW
Friday, September 14, 2007
 
 
It's perfectly acceptable to wrap a <button> inside an <a>, and to use <button type="submit">Save</button> in place of <input type="submit" /> in a form. Best of both worlds!
<buttons> tend to be easier to style than <input>s as well.
G Jones Send private email
Saturday, September 15, 2007
 
 
It's perfectly acceptable to wrap a <button> inside an <a>, and to use <button type="submit">Save</button> in place of <input type="submit" /> in a form.

Why would you do this? What do you set the target of the hyperlink to?
John Topley Send private email
Saturday, September 15, 2007
 
 
The link contains the page you want to direct to- I think there might be some confusion:

My post contained two separate (possible) practices, I wasn't advocating putting submit buttons inside a-tags, but using a submit-button and an a-wrapped cancel button next to one another makes styling them consistently a lot easier.
G Jones Send private email
Saturday, September 15, 2007
 
 
The usual guideline is:  Links navigate to/from pages.  Buttons perform actions (i.e. they "do things").  It's normally best to stick with that convention, although if you're using a language that lets you use links that act as buttons (here's looking at you, ASP.NET), then make sure you style them to *look* like buttons.
The Ruby Warlock
Sunday, September 16, 2007
 
 
> How about cancel buttons, which might just send you to
> another URL. Should those be links, even if there's a
> Submit button right next to them? (Facebook does this,
> and it looks weird.)

From a usability perspective, you certainly should. Just like links should be blue, with underlines (Or at least clearly stand out from the main text).

> For example, compare Previous and Next buttons in a
> multiple-page form, to Previous and Next links in a
> sequence of static pages. Should they really be different?

That depends on the function. The 'Next' item could either a) go to the next page, without saving the current content, or b) save the current page, and go to the next page. In a multi page form, you would probably have both functionalities - a) should be represented by a button, and b) should be represented by a link.
Troels Knak-Nielsen Send private email
Tuesday, September 18, 2007
 
 
Cancel buttons are one of those exception-to-the-rule sort of things.

Though you could think of it like this: a button is used for performing *some action*. A link is navigation. Cancelling (an order, for example) is an action - an act of saying "Hold on! I don't want to do that!".

Also, beware of styling buttons to look like links:
http://jivlain.wordpress.com/2007/09/01/why-you-shouldnt-use-linkbuttons/
Jivlain Send private email
Thursday, September 20, 2007
 
 
Buttons block a user's ability to open in a new tab. Any site that blocks me opening something in a new tab without good reason( form post etc. ) I block unless I really really need it.
pgb
Friday, September 21, 2007
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz