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.

At the top of the application we have a function bar that (almost) contains all functions that can be done on entries in a table below, quite similar to Office Fluent UI. We try to minimize the amount of functions but we have several screens in the application which will exceed the space that is in the bar. We now want to include a dropdown button / split button /menu button /... .

However we have one function group where the options are disjunct and are never active at the same time, it would be sensible, however, to group them together. We never hide buttons in the application but grey them out.

How would you proceed, if the top function is deactivated (but is the most used function) and the second function is active.
Should the second function "jump" to the top?
Should it stay there? If it should stay there, how do I indicate that that the button is inactive but the dropdown is active.
Should I not use a menu button at all?

share|improve this question
add comment

2 Answers 2

up vote 9 down vote accepted

Split buttons are great when there is one command that users use most of the time and then several others they use some of the time. Users have fast single-click access to what they need most of the time, while less commonly needed commands are still available but out of the way. This is how it contributes to a “fluid” (fast and mindless) UI: by promoting speed for the common commands while hiding the clutter of rare commands.

Here the options I see you faced with in your situation:

Disabling the Button. When using a split button, if you keep the command for the button the same and disable it when necessary, users may think the entire menu is disabled (if they fail to notice the little arrow is enabled). It also undermines the “fluidity” of the split button in that the most users can’t always access the command they most likely need access to.

Swap Button Command. The second worse option is to swap commands for the button. Here the concern is that users won’t be able to develop helpful habits for each command since sometimes a command is on the button and other times it’s on the split. They’ll have to stop, read the button, and think before acting (“okay, the command I want is not here, so it must be on the split this time”). Again, not too good for fluidity. The Windows UX Guidelines permit making the button be the last command used, under the assumption that it’s likely to be used again. If that fits your case, then it’s a good solution. However I’d be careful about swapping in a different command from the last one used (e.g., because the last command is now disabled) unless the new command is highly predictable and “makes sense” to your users. I wouldn’t try this without a good amount of user research first.

Menu Button. It sounds like you have a case where the command usage is more evenly distributed across the commands –indeed each command is unavailable for a good chunk of the time. Perhaps you need a menu button, which is different than a split button in that a menu button always opens a dropdown of commands, essentially being the same as a pulldown menu. Label the menu button with the category of commands. Clicking it drops down a stable list of commands, with some disabled as necessary. This means your commands always need two clicks to select, costing the user some efficiency, but at least users won’t have to stop and think before using it.

Toggling Button. By any chance, are the two most commonly used command mutually exclusive opposites of the other such that one is always enabled and when the other is disabled and vice versa? For example, one command expands the view and one the shrinks the view? If so, maybe you can combine the two into a toggling _ attribute _. Here you have one toggling button (or even a check box) labeled as the one the states of the attribute (e.g., “Expand”) that the user can set (check) or unset. You still have a dropdown arrow for other commands to fine tune the current state. This way, you always have the “same” function (as your users perceive it) enabled as your button.

Menu Bank. If there are lots of commands on the split side, the final option I can think of is to construct a “menu bank,” essentially a split button with more than one button. Select two to four of the most commonly used commands, where at least one of them is always enabled. Give each of these commands their own command button that is always visible, group them together, and add a dropdown arrow for the remaining commands. The downside of this is that it takes more space than a single button, and you’re always going to have disabled buttons taking up valuable space, but at least it ensures the most commonly needed command is always one click away.

share|improve this answer
    
Thank you very much! That really wraps everything up quite nicely. The action in the split button are really different and go to different dialogs, so i fear -as you said above- that your second option is not feasible. The second option is really an intermediate to power user function, so we really don't want to expose it too much. Sorry, that I wasn't clear about that beforehand. We will go with the worst option and hide it. I still have problems with that but as it is an intermediate function I think it is okay. Thanks again! –  marten Oct 20 '10 at 15:00
add comment

If I understand you correctly, it is like this, you have a menu lets say

Save | Edit | Undo

The Undo as the main point has a dropdown option to Redo, but it might be that one can't undo anything but only redo.

In this case I would have it jump to the top to be seen, even though normally it is better to have a consistent menu. People are used to this however, because it is a little like hiding buttons which can not be used and showing buttons which can be used.

share|improve this answer
    
Thanks for your reply, that example fits. I'm a bit concerned because - as you say - people might expect buttons which cannot be used to disappear, usually in the app we just deactivate them. –  marten Oct 20 '10 at 11:09
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.