deactivating or remove not available context menu commands

26 May 2009 - 3:35am
4 years ago
3 replies
508 reads


i have a question about the behavior of context menu commands in tables which are not available. The tables could be contain different "objects" with different options (commands) and supporting multiple selections.

My favored behavior is to remove commands which are not available. But when i distinguish between single and multiple selection and the different options of the objects i think it could be not self-explanatory about for the user which commands generally available.

But in some cases i think it would be better to deactivating the commands which are not available or mixed the both bevaviors.

When i select a single row i can open in context menu the object properties. At multiple selection the user could not be realised that the option to open the object properties is generally possible.

Has anyone experience about the problem?


26 May 2009 - 1:15pm
Luke Loeffler

I would display, but gray-out commands the items have in common but do not apply to the set of objects. I would remove the commands that are not common to all the items in the set and maybe add a grayed line that says something to the effect of "plus N commands not common to all items."

26 May 2009 - 4:26pm
Sascha Brossmann

Dear anonymous,

On Tue, May 26, 2009 at 10:35, <mail at> wrote:
> My favored behavior is to remove commands which are not available.
> (...)
> But in some cases i think it would be better to deactivating the
> commands which are not available or mixed the both bevaviors.

It depends. If the actual context is different, I would not totally
object against having different contextual menus -- that's why they're
called contextual. ;-) If not, the general and IMHO reasonable stance
on this in most guidelines is to disable but not hide unavailable menu
options: consequently, all items are kept in their normal place, and
the user may build up some motoric memory. Which eases navigation.


Sascha Brossmann
& : create

26 May 2009 - 7:03pm
Chauncey Wilson

There are two different principles at work in context menus:
Predictability and efficiency. If your users are novices or casuals
users, then it might be better to disable some items and keep them
around (assumming that they are used often across contexts). If your
users are expert, then you may want to keep the menus as short as
possible to maximize efficiency. If you are designing for software
developers who might use context menus then efficiency might be more
important than high predicability.

If you are designing context menus try to avoid submenus and consider
that the purpose of context menus originally was to keep a person's
focus on the work area and minimize travel to and from the menu bar.
I now see some context menus that are way too long and that would
offer little advantage in efficiency over a toolbar or menu or ribbon

In the later 1980s, the design of context menus was considered high
priority since they were a key accelerator for graphics programs,
spreadsheets, and text editors. Now, I often see them thrown together
without great thought about what items to choose, where they should be
placed, how things should be grouped.....

On Tue, May 26, 2009 at 4:35 AM, <mail at> wrote:
> hello,
> i have a question about the behavior of context menu commands in tables which are not available. The tables could be contain different "objects" with different options (commands) and supporting multiple selections.
> My favored behavior is to remove commands which are not available. But when i distinguish between single and multiple selection and the different options of the objects i think it could be not self-explanatory about for the user which commands generally available.
> But in some cases i think it would be better to deactivating the commands which are not available or mixed the both bevaviors.
> Example:
> When i select a single row i can open in context menu the object properties. At multiple selection the user could not be realised that the option to open the object properties is generally possible.
> Has anyone experience about the problem?
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at
> Unsubscribe ................
> List Guidelines ............
> List Help ..................

Syndicate content Get the feed