Component Layout Guidelines

Required 

6-1: 

Your application should be composed of at least one main window. 

A main window contains a client area and, optionally, a menu bar, a command area, a message area, and scroll bars. The client area contains the framework of the application. The use of a main window ensures interapplication consistency. 

Required 

bd: 

The default size of the application's main window must be large enough to accommodate a typical amount of data, but should not fill the entire physical display size to minimize visual conflicts with other applications. 

Required 

6-2: 

If your application has multiple main windows that serve the same primary function, each window closes and iconifies separately. 

For example, a text editor might allow the user to edit multiple documents, each in its own main window. Each window is then treated as a separate application and can be closed or iconified when it is not being used. 

Required 

6-3: 

If your application has multiple main windows that serve different primary functions, each window should be able to iconify independently of the other windows. 

For instance, a debugger might provide separate main windows for editing source code, examining data values, and viewing results. Each window can be iconified when it is not being used, but it is up to the application to decide whether each window closes separately or whether closing one window closes the entire application. 

Required 

be: 

Resize corners should be included in any main window that incorporates a scrolling data pane or list. 

Any changes to the overall size of the window should result in a corresponding increase or decrease in the size of the scrollable portion. Additionally, your application might reorganize elements within the window based on the increased or decreased amount of space (for example, it might reorganize a row of buttons into two rows). 

Required 

6-4: 

If your application has a menu bar, it is a horizontal bar at the top edge of the application, just below the title area of the window frame. A menu bar organizes the most common features of an application. It contains a list of menu topics in cascading buttons; each button is associated with a distinct pull-down menu containing commands that are grouped by common functionality. The use of a menu bar yields consistency across applications. 

A menu bar organizes the most common features of an application. It contains a list of menu topics in buttons; each button is associated with a distinct pull-down menu containing commands that are grouped by common functionality. The use of a menu bar is not required, but it is strongly recommended. 

Required 

6-5: 

The menu bar for your application contains only cascading buttons. 

The use of other types of buttons in the bar precludes user browsing of the menu structure. 

Recommended 

bn: 

There are several common menu operations that should be considered "standard". The standard menu bar entries are File, Edit, View, Options and Help. If your application provides that functionality to the user, it should be included in the menu bar under the appropriate name. The contents of these menu entries are discussed below in more detail. 

Standard menu bar entries should be presented in the following order: 

File Edit View Options Help 

You should exclude from your menu bar any item shown in the preceding text if your application does not support the associated function. For example, if your application does not support the ability to display its data in different views, then you should not include a View menu. 

You may add application-specific menus in between any of the standard menu items, with the following exceptions: 

• The File menu, if present, is located in the first menu position on the left.

• The Help menu is located on the far right position.

• If File and Edit are present, they should be next to each other.

For example, your application may have: 

File Edit <category1> <category2> View Options <category3> Help 

Recommended 

bo: 

Applications that are not file-oriented in nature (or that manage files transparently, not exposing this activity to the user) should replace the File menu with one or more application-specific menus. 

Possible replacements for the File menu: 

Replacement1: <app-label> Selected  

Replacement2: <app-label><obj-type>  

Replacement3: <obj-type> 

You may use Replacement1 if your application has more than one object type. Items on <app-label> would be used for global actions that are not specific to an object type. The items in Selected are actions that pertain to objects that are currently selected, and may change depending on what objects are selected. If nothing is selected, this menu should have a single item that says (none selected). If an item is selected, but there are no items that apply to that object, this menu should have a single item that says (none). 

You may use Replacement2 if your application has a single object type. Actions that are global to the application are on <app-label>, and actions that are specific to the object type are on <obj-type>. 

You may use Replacement3 if your application has a single object type, and does not require an <app-label> menu. For example, a Print Manager might contain a Printer menu. 

All other menubar guidelines that apply to File-oriented applications also apply to non-File-oriented applications. Thus, the following menubar would be valid: 

<app-label> Selected Edit <category1> View <category2> Help 

Applications that are complex or are extremely domain-specific (for example, an application for medical imaging and diagnosis of cat scan data) may require other approaches to their menu bar design. For example, 

<app-label><category1><category2> Selected Edit <object-type> Options Help 

Recommended 

bp: 

Exit or Close should be located on the first (leftmost) menu of your menubar.