Is it wrong for a context (right click) menu be the only way a user can perform a certain task?

Question

I'd like to know if it ever makes sense to provide some functionality in a piece of software that is only available to the user through a context (right click) menu. It seems that in most software I've worked with the right click menu is always used as a quick way to get to features that are otherwise available from other buttons or menus.

Below is a screen shot of the UI I'm developing. The tree view on the right shows the user's library of catalogs. Users can create new catalogs, or add and remove existing catalogs to and from their library. Catalogs in their library can then be opened or closed, or set to read-only.

The screen shot shows the context menu I've created for the browser. Some commands can be executed independently from any specific catalog (New, Add). Yet the other commands must be applied to a specifically selected catalog (Close, Open, Remove, ReadOnly, Refresh, Clean UP, Rename).

Currently the "Catalog" menu at the top of the window looks identical to this context menu. Yet I think this may be confusing to the users as the tree view which shows the currently selected catalog may not always be visible. The user may have switched to the Search or Filters tab, or the left pane may be hidden entirely.

However, I'm hesitant to change the UI so that the commands that depends on a specifically selected catalog are only available through the context menu.

Answer 1

The Windows User Experience Interaction Guidelines for Windows 7 and Windows Vista states (pg233):

“Don’t make commands only available through context menus. Like shortcut keys, context menus are alternative means of performing commands and choosing options.”

The Apple Human Interface Guidelines states (pg189):

“Always ensure that contextual menu items are also available as [pulldown] menu commands. A contextual menu is hidden by default and a user might not know it exists, so it should never be the only way to access a command.”

In your case, opening and closing the catalogue appears already available through the +/- buttons in the tree itself, so you’re already consistent with the Windows guidelines, if not the Apple guidelines. IMO, the only reason to put them on the context menu at all is if they're the default (double-click) action (which they're not right now). Rename may also already be available by directly selecting the name of a selected catalog, but you may want a pulldown menu item for that any way since that may be no more discoverable than the context menu. The rest of the commands probably belong on a pulldown menu in addition to the context menu.

As far as the Catalog pulldown menu being redundant with the Catalog context menu, you may want to consider organizing your pulldown menus by type of action, rather than class of object, in order to provide an alternative organization. As you’ve realized, context menus already organize commands by class of object. In addition to providing an alternative organization that some of you users may find more intuitive, this may simplify your menubar. For example, rather than a Catalog and Family menus, you can have a single Edit menu with Add, Delete, Rename, Copy, etc. where these commands apply to whatever is selected, whether it be a catalog, folder, or family. If they don't apply to the current selection, they're disabled, but if it makes any sense in your app, make them apply.

BTW, what’s the difference between Add Catalog and New Catalog?