Topic       : TOS - das Betriebssystem
Author      : 
Version     : tos.hyp (5. März 2013)
Subject     : Programmieren/Atari
Nodes       : 3001
Index Size  : 93602
HCP-Version : 5
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : Titel
@help       : 
@options    : +g -i -s +x +zz -t4
@width      : 70
View Ref-File10.2.1  Dialogboxen                                                TOS

Bei der Gestaltung der Dialogboxen sollte ein Software-Entwickler auf 
eine innere und äußere Konsistenz achten, d.h. er sollte sich an 
vorbildlichen Dialogboxen anderer Programme orientieren (äußere 
Konsistenz), und darauf achten, daß innerhalb seiner Anwendung die 
Dialogboxen ein einheitliches Outfit erhalten (innere Konsistenz).

Die folgende Liste nennt beispielhaft einige Aspekte, die beim Design 
von Dialogboxen beachtet werden sollten:

   ∙ gleicher Aufbau aller Dialogboxen der Applikation

   ∙ möglichst gleicher Aufbau der Dialogboxen aller Applikationen

   ∙ jeder Dialog sollte eine in sich abgeschlossene Teilaufgabe 
     behandeln

   ∙ für gleiche Aktionen einheitliche Buttons verwenden

   ∙ Informationen in logische Blöcke aufspalten

   ∙ überflüssige Informationen weglassen

   ∙ nicht zu viele Objekte auf einer Ebene verwenden

   ∙ aktivierbare Elemente deutlich von Anzeigen trennen

   ∙ Spezialeffekte und Farben sehr überlegt und sparsam einsetzen

Darüber hinaus sollte man sich genau überlegen, welche Art von Dialog 
für welchen Zweck eingesetzt wird. Hier lassen sich die folgenden 
Dialogarten unterscheiden:


Alertboxen werden eingesetzt, um den Benutzer über wichtige Ereignisse 
zu informieren, oder um Rückfragen an ihn zu stellen. Sie informieren 
in knapper Form über den Sachverhalt, und bieten ggfs. mehrere 
Alternativen, um auf diesen zu reagieren. Die Abbildung oben zeigt 
eine Alertbox, die zur aktiven Unterstützung von Multitasking in ein 
Fenster gelegt wurde.


Modale Dialogboxen sollten immer dann benutzt werden, wenn der 
Benutzer zu einer sofortigen Aktion gezwungen werden muß bzw. soll. 
Der Anwender kann erst dann in der Applikation weiterarbeiten, wenn er 
den entsprechenden Dialog verlassen hat. Die Abbildung oben zeigt eine 
modale Dialogbox, die zur aktiven Unterstützung von Multitasking in 
ein Fenster gelegt wurde. Modale Fensterdialoge können vom Benutzer 
anhand des fehlenden Closers der Fensterkomponenten erkannt werden.


Unmodale Dialogboxen sollten eingesetzt werden, wann immer dies 
möglich ist. Ein solcher Dialog existiert wie ein Fenster parallel zum 
eigentlichen Programm, und bietet dem Anwender ein Maximum an 
Flexibilität. Die Abbildung oben zeigt eine nicht-modale Dialogbox, 
die zur aktiven Unterstützung von Multitasking in ein Fenster gelegt 
wurde. Nicht-modale Fensterdialoge können vom Benutzer anhand des 
Closer in den Komponenten des Fensters erkannt werden.

Wichtig: Damit in einer Multitasking-Umgebung alle Applikationen zu 
jeder Zeit ungehindert Ausgaben auf dem Bildschirm tätigen können, 
sollten die Alert- und Dialogboxen eines Programms unbedingt in 
Fenster gelegt werden. Einige Applikationen (z.B. der Resource-Editor 
Interface) erlauben es, jederzeit zwischen konventionellen Dialogen 
und Fensterdialogen umzuschalten; diese Möglichkeit sollte jedoch nur 
dann angeboten werden, wenn es wirklich notwendig ist. Im Hinblick auf 
zukünftige bzw. bereits bestehende, Multitasking-fähige TOS-Versionen, 
werden koventionelle Dialoge nur noch eine untergeordnete Rolle 
spielen.

Querverweis: AES   Fensterdialoge   Formulare