1

If I have a "File" menu on my software (for example 3d modelling SW like 3Ds max), should all of the possible actions that has an on screen interface be in the "File" menu?

For example: the viewcube has 27 positions. Should all of them be included in the "File" menu?

  • what made you think all of them belong there in the first place? – Dvir Adler Oct 1 '15 at 16:54
1

No. These aren't regular buttons/actions. You wouldn't include all the colors from a palette/colorpicker in the menu in Photoshop either.

1

It depends

you're providing a very specific case dealing with variants of subsets (in this case positions or angles of a view), but in general, it could be not only feasible, but recommendable. While in other cases, the answer would be NO!. It all depends on context and information architecture.

Be logical

In a case like you mention, it's obvious you won't need all variants. But the rule of thumb is to provide all elements that are commonly used both in accessible options (toolbars, icon bars, toolbox, panels, widgets and such) as in menus. Think about this: many people dealing with highly specialized software tends to use keyboard to perform common actions, including... navigation.

An approach

I don't know 3Ds max, so let's take Photoshop: you have a Menu, a dynamic mini-toolbar below this which is related to the tool currently in use, a side toolbox, a side panel where you can dock widgets, a bottom bar with on and off program navigation.... or something totally different, since Photoshop uses Workspaces. See image below:

enter image description here

(in this case the sections are A: Tools panel | B: History panel | C: Color panel | D: Creative Cloud Libraries panel | E: Layers panel )

So... what's the only secure way to have all the program actions? Of course, the top menu. And because of this, Photoshop includes all possible actions in its menu.

Understanding IA

Back to Photoshop, you'll notice that the menu includes a taxonomy that organizes all actions in a logical way which we could call conceptual sections. As a curious note, English version mixes verbs and nouns (or undetermined taxonomies that could be either a verb or a noun). In Spanish, it only includes nouns, which makes it easier to understand.

Either way, you'll see the menu bar has these conceptual sections like File, Edit, Image, Layer, Type and so on. This menu is static and can't be changed. If you click on any of these options, you'll see a bunch of actions, some of them have sub-menus with different sub actions. These inner options can be modified by addition (some plugins add options) but you can't delete any of them.

And this is it! You won't find a deeper level, which would be "the result of an action that has been performed or a preset to perform an action" (or, in other words, your 27 positions for an element). These may exist in widgets, palettes and such, just not in the menu. Similar logic is applied to toolbox: it's used on a document, so it won't work without a canvas.

What do you get from this? The menu structure deals with concepts and actions. The results of these actions require input user, so it makes no logic to display them on the menu, unless the program includes an option for users to create a macro

When to use it all?

Environments for this approach are more common than you may believe. Almost any simple program, specially those where there's no user input are prone to this behavior. Remember that a menu structure is a mapping of the software capabilities and the available options for users. Take your browser: I bet you don't have 1/10 of the available options in your screen, yet you'll have ALL of them in your menu.

Something you will always need to create an app is to conceptualize and draw a map, see Apple's App Anatomy sample: enter image description here

you'll notice what I said above: conceptual sections or taxonomies, then actions, then results of these actions are NOT linked to menus. As per Apple Yosemite's UI guidelines:

All menus implement the explicit action paradigm: People identify what needs to be acted on and then specify the action by choosing a menu item. (To learn more about this paradigm, see Explicit and Implied Actions .)

Conclusion

If your software can do an action, it should be on your menu structure. The results of the user's interaction with any given set of actions shouldn't.

Not the answer you're looking for? Browse other questions tagged or ask your own question.