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.1  Dialog boxes                                               TOS

During the construction of dialog boxes a software developer should 
adhere to both an inner and outer consistecy, i.e. he should orient 
himself on typical dialog boxes of other programs (outer consistency) 
and also ensure that within an application the dialog boxes have a 
uniform appearance (inner consistency).

The following list names some exemplary aspects that should be paid 
regard to in the design of dialog boxes:

   . Similar structure of all of an application's dialog boxes

   . Similar structure of dialog boxes of all applications if possible

   . Each dialog should handle a partial task complete in itself

   . Use uniform buttons for the same actions

   . Split information into logical blocks

   . Omit superfluous information

   . Do not use too many objects on one plane

   . Clearly differentiate between activating and indicating elements

   . Use special effects and colours very sparsely and deliberately

In addition one should think very carefully about which type of dialog 
is to be used for which purpose. Here one can differentiate between 
the following dialog types:




Alert boxes are used to inform the user about important events, or to 
ask questions that need to be answered. They inform briefly about the 
state of affairs, and if appropriate offer several alternatives of how 
to react to them. The above illustration shows an alert box which has 
been placed in a window to actively support multitasking.




Modal dialog boxes should be used always when the user has to be, or 
should be, forced to take immediate action. The user can only continue 
to use the application when he has left the corresponding dialog. The 
above illustration shows a modal dialog box, which has been placed in 
a window to actively support multitasking. Modal window-dialogs can be 
recognized by the user by the missing Closer in the window components.




Nonmodal dialog boxes should be used whenever this is possible. Such a 
dialog exists like a window parallel to the actual program, and offers 
maximum flexibility to the user. The illustration above shows a 
nonmodal dialog box, which has been placed in a window to actively 
support multitasking. Nonmodal window-dialogs can be recognized by the 
user by the presence of a Closer in the window components.

Important: So that all applications can make unrestricted outputs to 
the screen at any time in a multitasking environment, it is imperative 
that all alert and dialog boxes of a program are placed in windows. 
Some applications (e.g. the resource editor Interface) allows one to 
switch at any time between conventional dialogs and window-dialogs; 
however this option should be offered only when it is really 
necessary. In view of future, or already existing, multitasking- 
capable TOS versions, conventional dialogs will only play a 
subordinate role.

See Also: About the AES   Window-dialogs   Forms