Yes, menus at the top level may be organized by the class of object they act on (e.g., Foos or Bars), or the type of action they carry out (e.g., filing actions). As a general rule, the menu bar or Ribbon at the top of the window should be organized by action type in order to provide the user with an alternative way to find a command to the context (right-click) menus that are necessarily organized by object class.
That said, many menu hierarchies, including the “old school” one, would benefit from being “flattened” –from being made broader at each level and less deep. Deep hierarchies mean cascade menus, which are slow and awkward to use. Few options at the top level mean general vague labels that provide very little information scent (what does File really mean anyway?).
There are several ways to fix this while still organizing the menu bar by action type. First, there’s the simple flattening of the old school File menu, much like Firefox does:
- File
- New Foo
- New Bar
- Open Foo
- Open Bar
- Quit
The problem is that the traditional File menu was intended for “document” applications that operate on only one principal object class. For example word processors operate on papers, spreadsheet programs operate on worksheets, image editors work on pictures, and so on. File becomes unwieldy when there are multiple principal classes. Two classes isn’t a problem, but three or more is.
In some cases, it’s best to take the “suite” approach and make it look like you’ve a separate program for each object class. Take object class selection out of your menu bar and put it in the Start menu, where you’ve installed shortcuts corresponding to each object class that open a primary window for that class. Each of these “applications” only has New and Open acting on only its class:
In a sense, you’ve made broader the menu above your menu bar in the hierarchy. This is entirely consistent with other desktop apps. It’s an attractive option if users tend to work with only one class for a session. Frequent trips to the Start menu gets old.
If you need to keep everything in your menu bar, you can spread the File menu out along the menu bar.
Many apps with multiple principal classes are database apps where each window shows multiple objects (database records). What the user is “opening” is not a single file but a query result. Typically, the user almost never has use for a blank window. Even for data entry, it’s often helpful and rarely hurtful to show the results of a default query in order to provide some context (e.g., records entered last time). If the user wants to add a new record to those already shown, it’s an action under Edit, not File. So we can eliminate New.
I suggest you take a cue from Mac OSX and have a Program menu for Quit (in OSX the name of the application is the menu caption). The Program menu has menu items labeled by their object class, but they’re actions –they open the Foo and Bar windows respectively. You either fill these windows with a default query result (which could be empty), or automatically show the query dialog for the user to select one. The Query menu item under File pops up this dialog to allow the user to change the query for the window at any time. This dialog may include an Empty option for edge cases where users need an empty window.