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

I would like to know whether it is sometimes understood to provide some functionality in a piece of software which is only one Through the context (right click) menus, it seems that in most software I have worked with the right click menu, always used as a quick way to get the features available from other buttons or menus.

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

Screen shot shows that I created the browser is. Some commands can be executed independently of any specific list (new, add). Nevertheless, other commands should be applied to a specially selected Catalog (Close, Open, Remove, Read Only, Refresh, Clean UP, Rename).

At present, the "Catalog" menu at the top of the window looks the same. In this context menu, I still think that it can confuse users as a trigger view, which shows the currently selected catalog Can not always be visible Users can switch to the Search or Filter tabs or the left pane can be completely hidden.

However, I am hesitant to change the UI so that the commands dependent on a specific selected catalog can be available only through the context menu. Windows User Interaction Guidelines for Windows 7 and Windows Vista (PG333):

"

< P> "Not only the commands available through the context menu, like the shortcut, context menus are alternative means of running commands and choosing options."

Apple has been asked in the Human Interface Guidelines (pg189): < / P>

"Always make sure there are also relevant menu items [pulldown] menu A contextual menu available in the form of Manda hides by default and the user does not know that it exists, so it should not be the only way to access the command. "

In your case, Opening and closing the list is already available in the tree +/- buttons, then you are already in line with the Windows guidelines, if not the Apple's guidelines IMO, they are the only reason on the context menu Ena, if they default (double-click) action (which are not they). Rename can also be already available by selecting the name of a selected catalog, but you may want a pulldown menu item for any type, after which it can be searched anywhere else from the context menu. The rest of the commands are probably on a pulldown menu other than the context menu.

As far as the Catalog Toolbar menu menu is redundant from the context menu, you may want to consider adjusting your pulldown menu instead of the category of the object to provide an alternate organization. Type work As you have realized, the context menu organizes commands by the class of the object. In addition to providing an alternative organization, some of you users can be more intuitive, it can make your menubar easier, for example, instead of a catalog and family menu, you can add, delete, name, copy, Etc., where these commands apply when selected, whether it is a catalog, folder or family. If they do not apply to the current selection, they have been disabled, but if it does make any sense in your app, then apply them.

What is the difference between BTW, catalog and new catalog?