Ive recently started switching my application over to using link labels with appropriate image from the standard command button. My main reason for doing this was to maximise the textual information i can convey in my ui without resorting to ugly 'stretched' buttons.

Eg Adding the text "Edit Selected Item" looks ugly on a command button having to stretch its width nearly twofold from standard size but from a usability standpoint, tells the user exactly what will happen when he/she clicks it. I dont know if its just me but it just looks wrong somehow having a double width button parked next to a standard size "OK" button

However, the converse of this also jarrs me, namely a tiny little 2 character link label for an "OK" button that, even when placed with an appropriate icon, just looks wrong.

So I'm now thinking maybe a mix of both command buttons for 'actions' like OK, Save, Cancel etc, and link labels for 'navigation' types, 'Edit Selected Item' for instance opens a new dialog so it is in keeping with the web navigation metaphor, navigating from one dialog to another. But this is then breaking consistency throughout the app mixing the two controls.

What are peoples thoughts from both a usability and design standpoint?

4 Answers 4


As long as you are consistent within your application I think it should be OK.

If you take Stack Exchange as an example (as we are here) it successfully mixes the two with buttons for actions like "Post Your Answer" and link labels for pretty much everything else (though the top navigation links do look like buttons on the original sites).

  • Consistency is essential. However, you should decide on the design according to what you want the user to do or what you expect they'd want to do. Using SE as the role model, they use buttons for adding comments - which is what they want us to and not because it is an action or navigation. Use your link design to make your user feel you knew what they'd want to do on each step.
    – idophir
    Jan 18, 2011 at 18:26

I think your basic idea to mix the two controls is the correct approach. It is not inconsistent because you have two different controls doing two different things –links for navigating and buttons for “actions” (what I would call a “command”). This is consistent with user expectations for these controls, and, as I’ve discussed in my answer to HTML buttons vs hyperlinks, I believe it is important to distinguish when users are about to command versus navigate.

However, there are a couple things to consider with your “Edit Selected Item” example, assuming that is an actual case from an app you’re designing.

Is it a Command or Navigation?

A control to “Edit Selected Item” is actually in a gray area between navigation and command. Yes, it does navigate in the sense that it brings the user to a dialogue, but it’s a dialogue strictly for executing a command, namely an edit. The fact that you are labeling it with a verb implies it’s primarily a command, not navigation.

Look at it this way: suppose the users want to edit an item. They know this is a command, but they aren’t going to necessarily know that they have to navigate to complete the command. Thus they’re going to be scanning your page for something that looks like a button and may not even notice anything that looks like a link. On the other hand, it is also helpful to signal to the users that they have to provide additional input to complete the command –that edit doesn’t happen immediately on clicking the control

Fortunately, there is a well-established convention to address this issue, and that is to use a command button, but add an ellipsis (“…”) to the end of the label.

I discuss gray areas more at Links and Other Wrong Controls.

(Another possibility is “Edit Selected Item” isn’t just for editing. Rather, it’s really drill-down. It shows the item in greater detail, allowing the user to change individual fields or attributes, but it also allows the user to do other things, such as delete the entire item, or forward it to a friend, or even simply view fields that aren’t shown on the parent page. If that’s the case, then "Details" or "Properties" may be a better label, and it’s a link, performing general navigation rather than a single command.)

Does it Really Need a Long Label?

I think you really should be able to label the control simply “Edit…” The text “Selected Item” doesn’t convey much of any information to the user. “Item” in particular is unspecific, but maybe that’s the best you can do (e.g., items in a shopping cart). But usually it’s implied that a command like Edit edits a selection. Users don’t see GUI apps with labels like “Cut Selected Item” or “Copy Selected Item” or “Delete Selected Item.” What these commands act on is indicated by their position and function (e.g., being in an Edit menu). Perhaps you can do the same, which will eliminate the problem of ugly long buttons. Long captions not only make ugly buttons but also add clutter which can obscure or demote more important controls. I wouldn’t use a label like “Edit Selected Item” unless I had usability test results showing that users are confused, and even then, I’d first try alternatives such as…

Can You Use In-line Documentation?

Sometimes there’s no escaping needing clarifying text for a button. Sometimes, however, you can avoid a long label by putting some of text outside the button as in-line documentation, such as shown for the Add button below:


In your case, you could have “Edit…” as the button label, and “selected item” as a static text to the right or below the button. Or if you have multiple commands that act on the selected item (and if you don’t I don’t see why you’re supporting selection), you could group all these buttons together with short labels (“Edit…”, “Delete”, “Forward…” “Activate”) and put them in a frame labeled “Selected Items” at the top.

Do You Need an Edit Command Anyway?

Ideally, your app should support edit-in-place. Don't make the user select and navigate to edit an item. Rather provide the controls to edit the item right where it's being shown for selection. For example, instead of showing the item as static text, show all the fields in text boxes, dropdown lists and other controls and allow the user to make changes directly. This simplifies your app and makes editing faster and easier, in addition to eliminating the problem of how to show "Edit Selected Item."


Usability: You have to be careful with your "link label" that never change color and have a good position, so It could be visible to any users.

Design: I agree with web navigation metaphor, personally, I like page-based applications, and in the design, I think there are technologies to change the classic look of the button, you can change the appearance of button and not using link label, I don't think using link labels is the best option, I would change the look of buttons using the XAML markup language in WPF. If I can't use this technology, surely I use labels.

  • Thanks for your comments. The link label I use isnt actually a standard control, its an extended button control dressed up to look like one so I could switch them back to standard buttons if I wanted. So maybe I'll switch OKs and Cancels back to standard buttons and keep navigation types as links
    – user3285
    Jan 16, 2011 at 22:36
  • That's what I would do exactly. Buttons to change the status of your window (Ok,Cancel,Yes,No,Abort), should be explicitly standard buttons. Jan 17, 2011 at 2:40

The other thing that may have a bearing on this is the context of the application. Its an MDI application as its a requirement that the user be able to have 'detail' views on one or more record open at a time in its own window allowing a side by side comparison of data.

To that end, a navigation type context for a link label breaks down slightly as the user is not actually 'navigating' from single page to single page. The concept of navigating implies having the use of a back and forward button or breadcrumb bar but that wouldn't be appropriate for an MDI application as the user is free to hop around the app giving each window focus.

Does this change things?

  • Hi @user325. This site doesn't quite work like a discussion board. Instead of posting a follow-up as an answer, you should either edit your original question or ask a new question. Jan 30, 2011 at 16:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.