Don't Change Menu Options Based on State

I recommend that you never change the options in the menus based on the state of the program.

I wasted a lot of time trying to find a menu option that didn’t exist. I figured it out, but avoiding that is an easy way to make the interface easier to use.

How would you recommend indicating that the Templates Folder is already set, then?

The issue – here and in general – is that different options are available depending on the state of the program. When the choice is essentially binary, having both options on the menu but graying out the one that doesn’t apply would lead to a tremendous amount of menu clutter in an already complex interface.

Katherine

This specific example will be indirectly resolved in a future redesign that will do without the menu system for setting up this option. Are there any other places where a menu option outright vanishes depending upon the state of the project? There might be something I’m forgetting—generally speaking we do go for disabling items that are irrelevant though.

There are a number of items like this: Set Templates Folder becomes Clear Templates Folder; Show/Hide Ruler; Convert to Folder/Text; View → Scrivenings/Document; and so on. I like it, because the relevant options are in the same place regardless of program state, but I can see the OP’s confusion.

Katherine

Sorry I didn’t reply sooner. I’ve been busy and haven’t checked this forum lately.

In general, I would favor menu clutter over menus that change. However, in most instances, if you have menu clutter with a lot of options, those options should be in a dialog.

As for graying out inappropriate options, the person (Steve Jobs?) who came up with that concept has caused millions of hours of frustration around the world. How often have you wanted to choose an item that’s grayed out, and you can’t figure out why it’s grayed out. That happens to me often, especially with a new app.

Want to make users happier and reduce tech support calls? Don’t gray out menu items. When they are selected inappropriately bring up a dialog. For example:

[b][code]The option Project/Set Selection as Templates Folder, can only be used when blah blah. You already have a templates folder defined. To set a new Templates folder, do this:

  1. Choose Project/Clear Templates Folder
  2. Select your new templates folder
  3. Choose Project/Set Selection as Templates Folder[/code][/b]

or, much better:

You have already selected a Templates folder. Would you like to change that to the currently selected folder? [Yes][No]

Follow that general principle, and you will never get tech support calls like “I can’t find the xxx menu option” or “Why is that menu option grayed out?”

[former interface designer steps off soapbox]

I have never heard the theory advocated that inapplicable menu items should be left black, to be honest. And it would go against Microsoft’s design guidelines:

As to whoever invented the idea first, I don’t know if that was Jobs, or Xerox, DOS menus or what, but the idea has surely seen enough decades at this point to be as expected as the shape of a “search” icon. I don’t think I’ve seen a single complaint expressed about disabled menu items, so I’m fine with our current support load on that matter. :slight_smile:

Surely it has happened, but I don’t recall being frustrated about it when it wasn’t obvious as to why. It just meant I had more to learn, and I like learning. What would frustrate me is a program that violated GUI design theory/convention and lit up every single menu item in every available context, and then repeatedly chastised you with alert messages whenever you accidentally did something completely illogical like trying to merge two documents with some text selected in a file.

I am more inclined to agree with you on the matter of completely removing menu commands. As Microsoft notes in that same article, there are places where that is appropriate, it is what makes a contextual menu contextual, but by and large we should strive to avoid it where we can.

As to the specific menu command here, as I mentioned earlier, this won’t be a menu command in the future. As you say, sometimes a dialogue is a better approach, and that is already the plan for this feature.

As i recall, the changing menu was an apple thing. I just hate it.

And now gmail, and others, do the same. Stupid interface stuff.

These are examples of clever-stupidity::: “Look what I can do.”