Menus
Caveats
Most if not all pages are just rough notes, and these pages as a whole are far from complete. More notes will be added in time, eventually, maybe.
If, from reading these notes, you conclude that I am off my rocker, you won’t be the first, and you may even be right.
No doubt there are a dozen and one reasons why none of this would ever work, but perhaps somewhere deep down there is a tiny fragment that could be used for something.
Contents
Overview
Menus and related interface concepts (toolbars, ribbons etc) provide a repertoire of commands available to the user. A large variety of approaches have been taken over the decades.
Approaches
There are various ways to implement menus. From the outset, Microsoft opted for in-window menu bars with Windows:
Mac OS opted for a single, central menu bar. This has certain advantages, including:
- Menus within the menu bar are easier to reach with the mouse by way of Fitts’ Law, as the menu bar is infinitely tall and it is impossible to overshoot it with the mouse cursor.
- Menus are available within dialog boxes, meaning that Edit → Copy and Edit → Paste are able to remain accessible at all times.
RISC OS unified the application menus and context menus into a single menu system invoked with the middle (“Menu”) mouse button:
Microsoft Office 2007 introduced a new menu system referred to a the “ribbon”, where the menus and toolbars were merged into a single interface. This implementation was kept proprietary and private, necessitating third party vendors to re-implement it from scratch. Most third-party implementations were unsightly, some even hideous, as a result. A simplified version was implemented in Windows 7 and used by a tiny subset of built-in tools.
More commonly, menus are now buried in a button with a randomly-chosen symbol, somewhere in the window (could be on the left, could be on the right) if indeed the program even implements menus at all.
Some programs combine the menu bar and toolbar (e.g. Windows 11 Notepad) or allow the user do this if they please (e.g. Tracker PDFXchange Editor). This works well so long as the menu bar and toolbar are both limited in their number of items.
One major concern is that most of these approaches make the Edit menu unavailable to dialog boxes. The Macintosh is so far the only mainstream system to allow the user to access the Edit menu with a dialog box open.
Moving forwards
Ideally it should be possible to adopt a menu implementation that can be used in any of the Windows, macOS or RISC OS approaches according to the user’s preference (based on the user’s choice of window manager). Ideally, the whole menu structure would be defined collectively and passed to the window manager, although this raises questions about interchangeable menus, such as context-specific submenus. It’s clear that a lot of thought is needed here. Systems with in-window menus are able to use totally different sets of menus for different windows, which is not as straightforward with a global menu bar. Mac practice has been to have a single set of menus across a whole application, enabled and disabled according to context. If the global menu bar were to be made part of the window manager role, the window manager could inject a Window menu to cater for this menu not being relevant to other menu implementations, meaning that applications do not need to be concerned with it.
With the goal of consistency in mind, the standard menu system should apply to the maximum number of programs possible, instead of (as is all too common under Windows) every program doing something different. Research is needed to ascertain which programs might be considered acceptable exceptions; for these cases, it may be possible to find an alternative implementation common to all of them.
Of course, there is no guarantee that a hierarchical menu system is even the correct choice at all. It’s unlikely that much in the way of alternatives—such as ribbons—could be automatically built from a pre-defined menu structure. That is to say, if ribbons were made the standard UI or some other radical new approach were to be chosen, there would be no way to have traditional menus as an alternative UI for those people who prefer it.
Toolbars
One advantage of pre-defined menus is that, so long as icons are assigned to the commands (whether or not icons are shown againt menu items), the user can be offered the ability to add any command to a toolbar. This was a feature of Microsoft Office for a long time, but it was never extended out to the rest of Microsoft Windows as a desktop environment. The likely problem here is programs not choosing to assign every single menu command an icon, especially considering that this involves a lot of work (and a suitable source of material). There are many commands for which it is quite frankly impossible to represent them meaningfully with a small image, and menu commands whose caption is too long for a toolbar button caption. The range of menu commands available to be added to toolbars will likely be restricted to those menu items prepared for being added to the toolbar.
Implementation details
Menu choices
Menu items can have the same behaviour as checkboxes and radio buttons. In some interfaces (including Windows and EIKON), checkbox-type items show a tick symbol when selected and radio button–type items show a bullet symbol, enabling the user to discern at a glance whether the item has an on–off behaviour or a mutually-exclusive behaviour. The latter are typically framed by separators to indicate the scope of the option. Apple and Acorn instead chose to use a tick symbol for both situations, which is needlessly confusing.
The screenshot below from EIKON on the Psion Revo shows both types: a tick next to Show toolbar (on-off choice) and a bullet next to Sort files → By type (a mutually exclusive choice).
Windows applications seem to be more erratic as to which they choose. Windows 10 still supports the use of bullets for mutually-exclusive options but many programs get this wrong. It would appear that more programs in Windows use a tick mark for mutually exclusive choices than use a bullet mark.
Windows requires all menu items within a radio choice group to have sequential IDs, which is not always practical when old translation DLLs are tied into specific menu IDs. The difficulty in maintaining sequential IDs may be why the idea has been largely abandoned.
Instead, the menu system should have properly-define item groups, with items collected together regardless of ID. As noted below, this will allow groups to be converted to submenus when there is a shortage of screen space. As such, groups will require a caption to be shown under this or similar circumstances; these captions will also help with accessibility and could thus be made permanently visible where required.
Overflow
Where a menu for some reason cannot fit on the screen, it should have a scroll bar or other convenient means to ensure that all items are accessible. Psion’s EIKON UI used scroll bars for menus to accommodate small screens. Pointing to an arrow at the end of the menu and waiting for more items to tediously slide into position is not a good implementation.
An alternative to avoid scrolling would be option group collapse. That is, where part of a menu represents a set of choices, if screen space is constrained, this group can be automatically converted to a submenu. The use of submenus for this purpose was used on Psion EPOC32-based palmtops.
Parent linking
RISC OS allows the parent menu item to toggle an item within its submenu, for example enabling and disabling the grid in !Draw without needing to go into the submenu to do so. In the screenshots below, the Grid submenu is shown, but this works even if the submenu is not opened. Clicking Grid and clicking Grid → Show do the same thing.
This is one of many unusual features of the RISC OS menu system.
Hold on right-click
RISC OS has a curious feature: when you right-click on a menu item, the command is invoked and the menu remains open. This way, you can select multiple commands without needing to keep re-opening the menus. This behaviour cannot be directly overlaid onto any menu system, as the menu command may alter the context upon which the menu tree was formed. For example, if the command is “Delete”, what should happen to the menu afterwards? The RISC OS Filer accommodates this by disabling the menu for the file and any other related menu items:
