Topic       : TOS - The Operating System
Author      : 
Version     : tos.hyp (December 19, 2008)
Subject     : Programmieren/Atari
Nodes       : 3010
Index Size  : 93790
HCP-Version : 5
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : Title
@help       : 
@options    : +g -i -s +x +zz -t4
@width      : 70
View Ref-File10.2.4  Menus and menu bars                                        TOS

To a large extent, the design of the menus is responsible for the 
clarity and user-friendliness of an application. Therefore every 
software developer should take enough time to create these in a 
sensible and appealing manner.

As already mentioned, the capacity of short-term memory is restricted. 
For this reason a menu bar should not offer more than seven menu 
entries, if possible; otherwise the user has to glance at the menu bar 
several times to be able to decide what he wants to select. The 
following illustration shows the main menu bar of the relational 
database system Phoenix in its English version:

  MANAGER  File   Edit  Process  Report  Parameters  Options  Help

Both the menu bar as well as the menus contained in it should have a 
standard make-up, so that the user feels 'at home' immediately after 
the launch of a program. The first menu from the left should always 
carry the name of the current application; this has the inestimable 
advantage in a multitasking environment of being able to identify the 
active application immediately by a quick glance at the menu bar.




The second menu title should always be named Fite, and offer menu 
entries that deal with various aspects of input and output. The lowest 
entry of this menu should always offer the option of quitting the 
program.

As one can see in the above illustration, individual entries within a 
menu can be collected together in logical subgroups separated by fixed 
or dashed lines, which contributes greatly to clarity and acceptance 
by the user.

Note: In assigning shortcuts in menus, take care not to duplicate any 
of them in the complete set of menu entries and also within any of the 
non-modal dialogs. Furthermore, avoid using accented characters, since 
these may not be present on keyboards used in countries other than 
that of the original programmer (Example: Umlauts [Ä], [Ö], [Ü] and 
[ß] are only present on German keyboards, and similar restrictions 
apply for French, Spanish or Swedish etc.)

Also remember that while [Control] combinations will use a modified 
ASCII-code of the character key to execute the menu event, [Alternate] 
combinations cannot do this and have to use the scancode; however, the 
keyboard layouts in some countries differ in a few keys (for instance, 
the [Y] and [Z] keys are transposed in English and German-language 
keyboards, and the French ones have other differences). It may thus be 
impossible to use some of these characters together with [Alternate] 
successfully as shortcuts in many programs when run on keyboards in 
languages other than that of the programmer without changing and then 
recompiling the program source. Just changing the shortcut in the RSC 
file or program file will not work!

Three dots following a menu entry indicate that after selecting this 
entry a dialog box (or file-selector) will open; the user can then 
attune himself to this, and move the mouse pointer to the middle of 
the screen, for instance, while the dialog is built up.

Further frequently used menu titles are Edit, Parameters, Options and 
Help. The first should always lie to the right of the File menu, the 
last should always be placed at the right end of the menu bar.

Each title should start with a capital (upper case) letter (the name 
of the program at far left should always be completely in capitals), 
consist of a single word only, and as demarcation to other titles 
always have a space character to both its left and right.

In addition, menu entries should always have a context-sensitive 
configuration, i.e. an entry may only be selectable if this is 
possible or sensible at the current situation of the program. Thus, 
say, there is no point of calling the menu entry Save when there is 
nothing to be saved. The same applies for an entry Close, which should 
be selectable only if a window or a dialog exists that can be closed. 
Such non-selectable menu entries should be displayed 'greyed out' (in 
light type).




Apart from the conventional menu bar, some further and interesting 
possibilities exist to allow the user to make selections. Thus many 
programs (e.g. the shells Thing or Ease - see illustration above) make 
popup-menus available to the user to facilitate fast selection between 
various alternatives or perform an operation.

The main advantage of a popup menu lies in shortening mouse movements. 
The menu simply appears at the screen position where the mouse click 
was performed (usually with the right mouse button). In implementing 
popup-menus one should ensure that these always appear complete on the 
screen (long popup-menus can often be scrolled).

Last but not least there is the possibility to place a menu bar in a 
window. This method offers many advantages: First of all the main menu 
bar can be relieved in this way and so allow a much clearer layout, 
secondly it makes possible building up an application in a much more 
logical way; all operations affecting a given window wander into the 
window menu, all others into the global menu bar.




As one can not only move windows on the screen but, generally, also 
change their size, it is possible that not all titles of a window menu 
are visible. Hence some programs allow the menu bar to be scrolled. 
This applies, for instance, to the text editor Grismo or the resource 
editor Interface.

See Also: About the AES   Menu library