Dissabling buttons.

I was discussing UI with a friend recently (as we often do) and he mentioned his dislike of greyed out disabled buttons. Upon further query it was revealed that he once discovered that the save button was disabled and he didn't know why. This is obviously a very distressing thing - save is core to most applications. He finally worked out that it was because he had just saved, so saving would not have been to any benefit.

His suggestion was that it should just let you continue to click save and just silently do nothing if it's only just saved*. While this works fine for save, there are a lot of UI components where it makes no sense to have them enabled in certain contexts.

Take a word processor for example, it makes no sense to be able to add a new row if you are not inside a table, so it is disabled. In a mail application it makes no sense to be able to reply if no email is selected. In a media player application it makes no sense to be able to stop or pause if the media is not playing.

So the solution is generally either to disable it, or hide it. I have a dislike of hiding UI components on the fly (with an exception that will be explained later). It makes the UI confusing and feel unstable, things will shift around and all your visual cues and markers can disappear and change.

Also, like simply disabling the button, it gives no indication as to why you cannot perform the action. Indeed, you no longer know that you can't perform the action for some reason, you're unsure if the feature is still there.

The solution to this, I feel, is to display the information to the user if they request it, and the simplest model we currently have for this are tool tips. However, the traditional tool tips in Windows are one liners that simply display the action. As developers, we need to start making a move to display more helpful information in tool tips.

Ironically Word 2007 does this. Ironic because it also sidesteps the need to display much of the information as to why buttons are disabled. It does this, horror, by hiding the buttons. However, and here is the exception, it does so based purely on context. If, in the current context, an entire group of actions (such as manipulating tables) doesn't make sense then it moves them to a new tab. This means that the UI still feels stable, as all the old cues are still in place but are not cluttered by nonsensical items.

It is important to group these contextual anomalies together, or else the it will feel too bitty and unstable. In the example of the media player given above (or to relate it to Word, macro recording), the stop/pause button** is too much of an isolated anomaly to abstract into a new tab and as such should simply be disabled (but with a tool tipped description as to why).

So to sum up when something should be disabled, hidden or simply not disabled - if it can still conceptually perform an action then let it do so, just conceptually; if it can be grouped with other contextual actions then they should be groups and displayed/hidden depending on context; if it is an isolated component then it should be disabled (but with a tool tipped description).

* As a side note Textpad, which I am currently writing this post in, greys out the save button but does not disable it. Instead it still pops up upon hover like a normal actionable button and performs a Save As upon clicking instead. An arguably useful, but non humane feature.

** Whichever is not, quite rightly, simply a toggle of play. If you can make a togglable action (toggle, not modal) then it is usually best to do so.