The image below shows the action panel of a table holding a range of items. Whether an action is available or not depends on the properties of the item(s) that are currently selected, E.g. if the user selects an item that is already activated the "Activate" action will be disabled.

enter image description here (Right-click and choose "Show image" if you want to see it more clearly)

I know similar subjects have been discussed before, such as Don't hide or disable menu items?, but this thread doesn't really cover what I was wondering.

Is it a good idea to have the reason for an action being unavailable printed out? Personally I would think so, but I've seen it too rarely to simply just trust my own intuition about it. Could it merely be a matter of the space it occupies and therefore is not used more frequently? Or is it that the interface could be considered cluttered..?

I do realize that the use of tooltips could cover this feedback to the user as well but I'd like to display the reason for toggling enabling/disabling of actions immediately on selection in the table.

I would really like to know if you agree with me, or if you would consider this a poor solution?

  • 1
    So essentially what you want to do is show Current state and Available actions. Why not just actually do that with intent. Remember, many people just will not see or read the message. I didn't, when I first looked at the image. Commented May 23, 2012 at 13:18

3 Answers 3


It seems that what you want to do is show Current state and Available actions.

You could just actually do that as an intentional part of the interface. Remember, many people just will not see or read the message. I didn't, when I first looked at the image.

Below is what might be a starter design for a clearer mechanism.

The 3 part display shows number of items selected, their current state, and available actions. (Use appropriate icons for appropriate states, especially if mixed state.)

The connectedness of the three areas hints that there is a flow between the sections and that the available actions are related to the current states.

enter image description here

It's just a quick mock-up - but maybe it might help trigger the design of something appropriate for your particular scenario.

  • 1
    I like this idea. Redesigning to create an intuitive flow of the prerequisites of an item and the possible actions that follow. I really like it, I'll probably use this concept instead of the one I have. Thanks! Commented May 23, 2012 at 14:01

If the reasons for toggling the menu items are too complex be understood, displaying them in an unobtrusive way could be helpful. If a user can't remove an item without knowing why a hint (deactivate to remove, or similar) could help avoid a trip to the documentation.

I do find the message in your example too long and possibly containing unnecessary information such as "Activation and removal unavailable", which is already shown by the disabled buttons. Concise wording and easy scannability are very important here. Red is too much of an attention-grabber as well, a low key visual design that can be ignored by advanced users might be a better call.

descriptive text

I would base this decision on the complexity of the system involved and whether the correlations are likely to be understood.

  • I like the reasoning behind your answer. To be honest I already know the descriptive text is very poor, and has to be re-phrased if kept anyhow (temporary during development). One problem is that the system that the interface is handling is quite complex, and previous experience from a similar system will be zero, because none exists. Changing the colour I definitely agree on, it was selected by another party and I will argue to change it. A question though, what is the reasoning behind moving the text to the right? I would assume having it closely mapped to the buttons would be preferable. Commented May 23, 2012 at 13:47
  • I think the right-aligned text is still a) visible enough not to be overlooked and b) as much, if not more related to the list of elements below than the buttons themselves (it describes properties/relationships of the items not the buttons). At least as much as I can tell from the cropped screenshot :)
    – Mel
    Commented May 23, 2012 at 20:58

As I implied in my answer on the other question: ideally you present descriptive text of why you can't do X when you try to interact with the disabled menu item. When the user hovers over, clicks, taps ect on a disabled item, give them a pop over of some sort like Google Doc's "save button" message here:

enter image description here

The problem with displaying disabled item text is that it takes up a lot of space and you might be displaying it all the time. If it's disabled, odds are the user doesn't care in most contexts; disabled actions are generally something that's not logical to do now (saving an autosaved document) or something the user is generally unable to do.

Showing the descriptive text when they actually try and interact ensures you're presenting the text to users that actually care in some way; they either want to do X or they're curious as to why X is disabled.

There might be a small amount of users who want to do X and are frustrated but don't think to click/tap on the disabled button, but for the most part why something is disabled should be logical to figure out; in your example I can't remove/activate subscriptions that aren't selected, simple enough. If it's a common, available action that's suddenly (and infrequently) disabled you might want to display text on the interface; this situation is more like an error. Generally your controls shouldn't need a full tutorial written next to them at all times; if they do they have bigger problems.

In the case of your example, the descriptive text actually doesn't make any sense. It tells me the buttons are disabled (but I can see that because they're grayed out...) but it doesn't tell me why. If instead it was a pop-over, I could actually explain "You must select an item to remove/Activate" and I'd have all the space in the world to explain it. Leaving the text in the interface adds clutter and limits your descriptive text to what fits...in this case they didn't manage to actually fit in anything helpful!

  • Thanks Ben. I know the descriptive text is very poor, it's temporary and the question is more regarding the concept. I agree that descriptive text for actions are redundant for Simple to understand actions. But in my example it's not merely because no item is selected (maybe I should have included the table in the image) but because the selected item is PROVISIONED, has a policy and is already activated. The result of that it's already activated is simple enough to understand, but the rest? Users will have knowledge of the system, but comparing actions to saving of a document is not fair. Commented May 23, 2012 at 13:57

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.