Menu Bar Menus are standard application menus which appear in the menu bar at the top of a computer’s display. Some Menu Bar Menu items are Unity-specific while others are conventional menus (like “Apple” or “Windows”) which appear across applications. These menus contain essential actions and items related to the interface and the development process. Menu Bar Menus are persistent, though they can be expanded to include additional top-tier items or have their subitems items
For more information on how to properly build a menu bar menu please refer to the Menu Bar Menu Construction Guide
Structured. Menu Bar Menus should be future-proof; they should have a sensible structure with a clean, logical organization of items that maps to local menus in tool windows (e.g. Project and Hierarchy menus).
Efficient. Menus should allow for increased user performance by facilitating user workflow (e.g. via reducing the number of clicks needed to perform tasks and keyboard shortcuts)
Scalable & Extendible. Menus should be easy and clear for the ecosystem to extend, with consistent usage of UI text labels.
Familiar. Menu Bar Menus should be visually consistent and recognizable to users coming from similar products; their appearance should be modern, professional, and extensible when compared with other products.
Each Menu Bar Menu should be specialized, containing only items related to their root. Top-tier menus must be limited to general concepts, such as a menu containing actions relating to the display (“Window”), Element-type (“Assets”, “GameObjects”, “Components”) or processes (“File”, “Edit”). They should be clearly labeled with identify the nature or subject from which their contents derive context.
Additional Menu Bar Menus should only be generated for subjects that contain a variety of unique actions with a context that is not covered by an existing menu, as seen in the Terrain plugin.
Menu Bar Menus should not be generated for subjects with pre-existing menus, even if new controls are available; in those circumstances they should appear within the existing category as new menu items or may be grouped under a parent menu item, with specific actions in its submenu.
Menu Bar Menus are used to organize and display key functions relating to the Editor, taking a large volume of actions and structuring them into navigable categories. They act as an omnipresent resource, allowing users to easily navigate to commonly used commands regardless of which window they have been interacting with.
Menu bar menus can be used to condense actions under a shared subject or context, saving on real estate while providing a logical path to arrive at specific outcomes. They also provide a means for users to view available actions they may not be aware of or to perform specialized actions relating to the Editor itself.
There are three types of menu bar menu; os menus, standard Unity menus, and extension menus.
OS menus are generated by the operating system and contain high-level application actions such as saving, opening preference menus, and closing the application. OS menus contain an assortment of default options required by the operating system, as well as a few Unity specific items within the same subject or domain as the base items. These menus include the File, Edit, Window, and Help menus, each of which include default OS options alongside Editor-specific items like "Build Settings".
OS menus can be extended, though their default options cannot be replaced or altered.
The Editor includes a set of Unity-specific menus by default, such as the GameObject menu (containing GameObject-specific actions). These menus contain core subjects in the Editor, including Assets, Components, and GameObjects.
Like OS menus, standard menus can be extended through code, with additional items appearing alongside default options.
Extension menus are custom menus created through packages or code. An extension menu should only be created when a subject falls outside the available subjects or contexts, or if the content density and frequency of selections are such that nesting would adversely affect navigability.
The menu bar houses the application’s main menus, including the operating system’s general menu. Each menu is contained within a labeled volume which acts as its interaction element and separates it from other selections. Clicking on the men’s label will open the menu, displaying the contents in a dropdown list.
The menu bar should not contain additional elements save for those rendered by the OS (time, user, etc.).
Menu Bar Menus consist of a list of full-line menu items, each appearing as a simple text label. Items can be actions, which initiate a process or open an interface, or submenus, which gather related items under a shared context.
Menu Items contain a left-aligned text string detailing the action they will perform, along with any relevant shortcuts which may be used to invoke the action through keyboarding. Menu items can also be used to invoke submenus, indicating the behavior with a right-aligned arrow glyph in-line with their label.
Submenus discretely gather related actions under a shared context, allowing for a logical progression from action-type to unique commands. Each menu item within a submenu should provide greater specificity for action being performed under the parent context.
For example, selecting the “Create” menu item in the Asset menu will open an additional submenu with specific creation options, such as “Scene”. In this example the general context is that the user will be focusing on Assets, trying to Create a specific asset type, and selecting Scene from the available choices.
Submenus help to keep menus organized, allowing users to hone in on the action they desire to perform: They can be used to mitigate deep and complex menus by providing a logical path to their goal while providing visibility for other choices
Action Groups are, as the name implies, sections of the menu where related actions are grouped together. These groups are then divided from other unrelated actions with a Divider to help separate them visually from the rest of the menu’s contents. The result is a visual structure that allows a user to skim the menu and find their desired action quickly.
Dividers split up action groups in a menu, dividing the contents into a navigable structure. Dividers help organize related choices and provide a boundary for the list of possible actions
Menus should facilitate user workflow and performance by presenting an organized structure, reducing the number of clicks or travel required. Menu bar menus follow a cascading layout, with each parent expanding into a more-detailed list of items for the user to choose from.
Items are broken into action groups relating to their function which are then divided from each other with a line. Related actions should be placed near each other or nested into action groups and submenus for easy navigation.
Place related actions nearby in the menu.
List the menu items arbitrarily.
High-traffic actions should be placed near the top of menus and destructive actions should be placed towards the bottom of their action group.
List high-traffic actions first.
Arrange items freely or diverge from standard ordering.
Action groups should be separated by Dividers to help give visual structure to the menu and allow for easy navigation by proxy.
Split up menus into action groups and separate action groups by dividers
Over-structure and add dividers inside action groups.
Menu Items with actions that are complex and allow for further stratification should be organized into submenus. An example of this can be seen in the “Create” menu within the top-tier “Asset” menu; by entering the “Create” item. A submenu should provide a clear course for discovery of available actions.
Some menu items have shortcuts, a sequence of keys which can be used to invoke an action or process, listed alongside their label. These are often general actions like “saving” or “copying”, which can be applied in multiple contexts and are performed frequently in multiple workflows. In these situations the shortcut is listed alongside the menu item’s label, but it is right-aligned and separated by a gap.
Shortcuts should only be included for high-frequency actions . Do not include shortcuts on menu items if they require more than three keys to be pressed in sequence.
Some menu items, such as “Copy” and “Paste”, are common to other interfaces and operating systems themselves and are steeping in conventions that affect user expectations. In such cases it’s important to leave those items in their standard location to prevent confusing the user.
Labels should be concise and clearly indicate the purpose and outcome of the action or, in the case of submenus, indicate their contents. The naming and labeling of actions should be consistent with other appearances in the editor.
Use the same text for a menu item as appears on a tab
Deviate from the original text.
When an action requires additional inputs it should be indicated by the inclusion of an ellipses.
Submenus are indicated with arrows on the right side of menu item label.
For actions that contain hotkeys (such as “Refresh” or “New Scene”) add the Hotkey shortcut on the right end of the menu item label.
Add hotkey information on applicable menu items, aligned to the right of the menu container.
Labels in menus are generally 12pt sized to ensure readability. Menu titles should use titlecase capitalization.
Menus item text is indented below the initial label, however submenus feature the same indentation as the initial tier. This is because the menu style and behaviour does not require additional indentation to convey their nature as submenus, instead using positioning and segmenting as is general convention.
Items that have not been interacted with generally have the Default state. This state is limited to items that are not being interacted with and/or are not unavailable.
The Active state is complex in menus: Root elements enter the Active state when selected and maintain the state until it is closed, either by a selection being made or another non-menu interaction being performed (for example, clicking elsewhere on the screen). Similarly, menu item parents enter the Active state while their submenus are being navigated. This is to provide context for each major step in the progression. Only one menu item can be in a hover state at a time with the exception of parent menu items as noted above.
Menu items enter their Hover state when they are navigated to. Menu items enter the Hover state when the user is focusing on them, either by passing over them with the cursor or having navigated to them with the arrow keys.
Only one menu item can be in a hover state at a time with the exception of parent menu items as noted above.
Submenus automatically open when their parent menu item is being interacted with and only display their first level of content. Additional submenus are not displayed until their parent menu items are interacted with.
A menu item has the Disabled state when its action cannot be performed or is being restricted. Disabled or unavailable menu items still appear in-line with other items in a menu, but do not enter the Hover state.
A menu is only opened when prompted by user input, either on the menu or on an action element that opens the menu. Menus only display the first level content when opened, submenus and overflow menus are opened separately.
Submenus open on hover or when their parent menu item is in the focused state.
Opening a menu does not initiate an animation, its contents are displayed immediately.
Menus always open in-display and will shift opening position to avoid being cut off on the screen.
Users can navigate a menu bar menu with the cursor, hovering over parent menu items to open submenus and clicking to make selections. There is no direct input necessary on the parent menu item for cursor navigation, however a direct input is required while using keyboard navigation; a user must press the right arrow key to open a submenu.
Once a selection has been made the menu with automatically close. Selecting a menu item will initiate that item's action, whether that means performing the action directly or invoking the interface the action refers to. Only one selection/action can be performed at a time, requiring the user to reopen and re-navigate the menu bar menu before initiating another.
Closing a menu initiates a brief and rapid opacity fade animation before returning the root element to its default state.
Menus always appear above all other UI elements in the interface, taking precedence until they are closed.
Standard menus display attached to their root element as dropdowns. Menus and Submenus follow a cascading layout: Submenus open to the right of their parent menu item and are aligned to its top.
Context menus are generated at the point of interaction and display beside the cursor, primarily to the right although they can appear to the left depending on the available space in the display.