Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

What are current best practices regarding the idea of having both a menu item as well as widget--I'm thinking of a button with an icon on it, but it could be any graphical element that you could interact with--point to the same function?

Strictly speaking, it is redundant, since the function can be accessed in two ways. But, e.g., most word processors have traditionally had both the File > Save menu item as well as the little floppy disk icon for the same purpose. The redundancy never bothered me as a user.

But I am trying to make an application that has far fewer features than, say, Word, and so the redundancy might seem a little silly. Specifically, I was going to have a "Settings" menu item as well as a "Settings" button with a gear icon or such (part of the motivation for the button is it provides very good visual balance to the UI based on the layout of the other buttons...probably not a compelling reason to have it, I know)

share|improve this question
add comment

3 Answers

Adding to the benefits of redundancy benefits:

Menu and "widget palette" traditionally serve different purposes:

  • the menu gives systematic access to all possible commands
    this is supported by hierarchical access unlike a typical toolbar, commands can be discovered by keyboard

  • widgets give quick access to frequent commands this is supported by a distinct icon and a fixed location

The distinction has waned a bit, sicne they have grown into almost the same by appearance and customizability. The Windows Ribbon seems to me a bit weird approach to unify these two roles.


IMO the purposes - quick access, systematic access, and keyboard navigation - are good reasons for the redundancy. They can be improved, of course: e.g. quick search like the windows start menu give quick access for both known and unknown hierarchies, "favorites" are a somewhat easier concept than "customize toolbar".


If you have only a few options, this might be overkill. you might consider a web-style navigation instead. Throw in some easy to discover keyboard shortcuts, and you'll be fine.

share|improve this answer
add comment

Ben Brocka has explained the relevant theoretical background perfectly.

Keeping all of that in mind, you should ask yourself one simple question:

How often will the user want to access the settings?

If the average user is going to use your settings button even half as often as one uses the save button in MS Office - go for it.

If, on the other hand, the user would seldom want/need to change any setting - don't clutter your UI.


P.S.:

part of the motivation for the button is it provides very good visual balance

I don't think that aesthetics (being subjective) should be a valid reason for adding/not adding buttons to your UI.

share|improve this answer
add comment

Redundancy isn't always bad! There's a concept called Redundancy Gain:

If a signal is presented more than once, it is more likely that it will be understood correctly. This can be done by presenting the signal in alternative physical forms (e.g. color and shape, voice and print, etc.), as redundancy does not imply repetition. A traffic light is a good example of redundancy, as color and position are redundant.

In addition to interpreting the signals correctly, menu items may benefit from redundancy for logical reasons. As you said the floppy disc icon is easily accessible from the menu bar, and also from the File > Save option. This is because you want quick access to Save, but it makes logical sense that it's also under the File menu. It's also right next to Save As; of course Save should be right next to Save As, even if there's a little redundancy.

Giving users multiple entry points to common features can be helpful. Even though the on-screen Save button might be easier to use, many might be used to going to File > Save. It's consistent with other apps.

Redundancy can be bad and cause clutter of course, but consider why you're making a duplicate control. Chances are there's a reason; is a redundant control used to maintain internal/external consistency (with your apps or other people's apps)? Is the control used to keep things logically sorted but also easily accessible where needed? Is the control duplicated to help the user find it or understand it's use?

If yes to any of the above, it's quite possible a duplicated control may be helpful.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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