Revisit structure of “System” menu

Start by reviewing the component in app/templates/custom-elements/menu-bar.html and the current System and Help menu structure. Consider the stated constraints and possible approaches, then document the agreed structure in a nearby comment. Done means the menu organization has been decided and the component documentation reflects it.

The “System” menu keeps growing as we add new features. In Pro, the ”System” menu can contain up to 8 items:

(Note, “Logout” is conditional, i.e. only shown if user authentication is enabled.)

Before we add the next item to the “System” menu, we want to revisit the structure of it. We should also write up a few sentences as documentation, probably as comment somewhere in the <menu-bar> component.

Considerations

On a high-level, our menu(s) should be…:

• Neat: the more items a menu contains, the harder it is for users to grasp its structure, and to find where things are.
  • There certainly is no hard limit in regards to items-per-menu, but 8 items on the same level (without any sort of grouping / division / sub-structure) feels quite a lot already.
• Intuitive: the menu labels should be straightforward, and the menu structure should “feel” right – i.e., logical and consistent.
  • E.g., “System” implies “global”/“device-wide”, whereas “View” implies “local”/“client-side”. And “Actions” are operations against the target machine.
• Practical: often-used items should be easy to reach, whereas less-used functionality can be “stashed away” somewhere.
  • One example here is the “About” menu item in the “Help” menu. You could argue whether that’s the right place, but the “About” dialog is really not that important in day-to-day usage, so it shouldn’t reside in “System” for example, to avoid clutter.

Some random notes for reference:

• We mix items in the “System” menu that fall into slightly different categories. E.g., “Hostname” and “Virtual Media” are true properties of the device’s system, whereas e.g. “Log Out” is actually client-specific state, or “Update” is kind-of a meta functionality. We certainly don’t have to nail the semantics 100%, but maybe that realization helps us to think about the structure internally.
• One constraint is that some items should stay in place for historical reasons. E.g., “Logs” could theoretically be moved somewhere else, but the problem is we’d have to change a lot of documentation and public support posts then.
• Potential approaches to clear up the menu structure could be:
  • Sub-menus
  • Menu separators
  • A new top-level menu
• We already introduced a new top-level menu “Help”, which allowed us to move “About” out of from the “System” menu.