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.
