Atarium: Neues aus dem »Inside Mac«

Seit es grafische Benutzeroberflächen gibt, sind User Interface-Guidelines in aller Munde. Besondere Beachtung verdienen sie bei Multitasking.

In den vergangenen Monaten haben wir uns an dieser Stelle intensiv mit technischen Details von Plattentreibern (XHDI-Standard) und Dateisystemen (MiNT-Verzeichnisfunktionen) beschäftigt. Im Bereich des MiNT-Kernels gibt es natürlich noch viel mehr zu erörtern, beispielsweise die Behandlung von Prozessen, Prozeßgruppen, Terminals, Signalen und ähnliches. Wenn Sie sich mehr Informationen über eines dieser (oder anderer) MiNT-spezifischer Themen wünschen, dann schreiben Sie uns doch einfach - wir werden die MiNT-Berichterstattung schon bald wieder aufnehmen.

Abb. 1: Eine bewegbare, modale Dialogbox aus der nächsten Version von »Interface«

Diesen Monat soll aber wieder einmal ein Thema zur Sprache kommen, das in letzter Zeit etwas zu kurz gekommen ist: User Interface. Durch die Verfügbarkeit multitaskingfähiger AES-Versionen wie »MultiGEM«, »Mag!X« ([1]) und demnächst »MultiTOS« gilt es, viele Dinge zu überdenken. Eine interessante Informationsquelle dazu ist wie so oft die Apple-Dokumentation, in diesem Fall der »Inside Mac Volume VI« ([2]), der sich mit den Erweiterungen in Apples System 7 auseinandersetzt. Auch wenn Apples Betriebssystem eben nicht mit dem AES identisch ist, gibt es doch viele Parallelen, und es kann durchaus nicht schaden, sich die von Apple vorgeschlagenen Wege genauer anzusehen (der Rest der Computerindustrie tut es ja schließlich auch).

Schon immer war es wichtig, dem Anwender durch »Feedback« zu signalisieren, was das System gerade tut. In einer Multitasking-Umgebung ist es (noch) schwieriger, die Dauer bestimmter Operationen abzuschätzen. Daher sollte man wann immer irgend möglich, den Fortlauf des Vorgangs optisch anzeigen (wie z.B. der Formatierdialog des Atari-Desktop). Es versteht sich von selber, daß solche Anzeigen stets in Fenstern erfolgen sollten (damit nicht die Bildschirmausgaben anderer Programme blockiert werden).

Für Programme, die gerade nicht im Vordergrund ablaufen (die also nicht das oberste Fenster besitzen), ist es schwierig, mit dem Benutzer in Kontakt zu treten nichts ist irritierender, als eine plötzlich auftauchende Alertbox, die man nicht auf Anhieb einem bestimmten Programm zuordnen kann.

Eine kurzfristige Abhilfe schafft die Faustregel, daß in Alertboxen immer der Programmname auftauchen sollte - damit weiß der Benutzer wenigstens schon einmal, von wem die Meldung kommt. Langfristig wären allerdings andere Mechanismen wünschenswert (für die es sehr nützlich wäre, wenn Atari selbst das AES dafür erweiterte).

Schon seit Apple System 6 gibt es dafür den »Notification Manager«, der verschiedene Möglichkeiten für derartige Benachrichtigungen enthält. Jede Notification wird dabei in eine Warteschlange eingespeist, und der Notification Manager sorgt dafür, daß die Nachrichten nacheinander angezeigt werden. Das aufrufende Anwendungsprogramm kann dann abfragen, ob die Notification übermittelt worden ist.

Der Mac kennt mehrere Typen von Notifications, die man relativ frei kombinieren kann. Dazu gehören Toneffekte, die Markierung des Programms im Applikationsmenü sowie ganz normale Alertboxen.

Übertragen auf GEM wären folgende Typen von Nachrichten vorstellbar:

Im Normalfall sollte eine Applikation also eine derartige Notification vornehmen und dann darauf warten, daß eines ihrer Fenster nach oben geholt wird.

Doch nicht jedes Programm ist ein GEM-Programm, dennoch ist es ab und zu unverzichtbar, den Benutzer über kritische Fehler zu informieren. Ein klassisches Beispiel sind einige Festplattentreiber, die mittels der BIOS-Ausgabefunktionen kritische Fehlermeldungen in der rechten oberen Bildschirmecke ausgeben (z. B. »HuSHI«). In Unix-Systemen, die unter dem X-Fenstersystem laufen, wird dazu normalerweise ein spezielles Konsolenfenster geöffnet, in dem derartige Fehlermeldungen erscheinen. Dies wird auch unter MultiTOS problemlos möglich ein (wie man es schon jetzt mit MiNT leicht ausprobieren kann).

Ein anderes wichtiges Thema sind natürlich Dialogboxen. Normale GEM-Dialoge blockieren die Bildschirmausgaben anderer Prozesse, da sie den Bildschirm via »wind_update()« sperren. Die offensichtlichste Lösung ist natürlich, die Dialoge in Fenster zu verfrachten. Ganz so einfach, wie das klingt, ist es allerdings nicht - und das nicht nur aus technischen Gründen.

Zunächst einmal sollte man sich den Unterschied zwischen modalen und nichtmodalen Dialogen vergegenwärtigen. Ein gutes Beispiel für nichtmodale Dialoge sind die CPX-Module, wie man sie aus dem XControl-Fenster kennt: jede Änderung im Dialog wird sofort übernommen (wie zum Beispiel die Einstellung eines Farbregisters mittels des Farben-CPXs). Nur bei »Abbruch« (oder Schließen des CPX-Moduls via ACCLOSE, siehe [3]) werden die ursprünglichen Einstellungen wiederhergestellt.

Der wichtigste Aspekt eines nichtmodalen Dialogs wird also schon durch die Bezeichnung ausgedrückt: das Aufrufen des Dialogs zwängt den Benutzer in keinen Modus, er kann in allen Fenstern wie gewohnt weiterarbeiten.

Und hier liegt der Knackpunkt: allein dadurch, daß man eine GEM-Dialogbox in einem Fenster ausgibt, wird sie nicht zu einer nichtmodalen Dialogbox. Oft ist das auch gar nicht wünschenswert, weil der Benutzer ja eben eine bestimmte Auswahl treffen soll, bevor er weiterarbeiten kann. Wie sollte also ein modaler Fensterdialog aussehen?

Abb. 2: Ein »Panel« in »Interface«

Auch dieser Frage hat sich Apple angenommen und im System 7 die "verschiebbaren modalen Dialogboxen« (»Movable Modal Dialox Boxes«) eingeführt. Solche Dialoge haben nur ein einziges sichtbares Fensterattribut, nämlich die Titelzeile (die natürlich unter GEM intern aus »TITLE« und »MOVER« besteht). Das heißt: man kann sie - genau wie eine normale Dialogbox - nur über die normalen Exit-Buttons verlassen. Andere Fenster der Applikation können nicht nach vorne geholt werden, solange der Dialog nicht verlassen worden ist. Andere Applikationen hingegen können nach oben geholt werden.

In der Menüleiste sollten zu diesem Zeitpunkt nur noch solche Menüpunkte erreichbar sein, die man auch benutzen kann (gäbe es eine dokumentierte Methode, Menütitel zu desaktivieren, wäre dies natürlich noch praktischer).

Ein Beispiel für modale Fensterdialoge findet man in der neuen Version des Resource Construction Sets »Interface« (Vertrieb: Shift), das ab Ende September ausgeliefert werden soll (s. Abb. 1).

Aus programmiertechnischer Sicht sind natürlich noch einige Dinge mehr zu beachten:

Das heißt natürlich nicht, daß man nicht die Gelegenheit nutzen kann, einige Dialoge in nichtmodale Fensterdialoge umzuwandeln nur muß man dann eben auch an alle Konsequenzen denken: z. B. kann es zu verwirrenden Überdeckungen von Menü-Shortcuts und Tastatur-Shortcuts in der Dialogbox kommen.

Natürlich gibt es einige sehr gute Kandidaten für nichtmodale Dialoge (wie man sie auf anderen Betriebssystemen, wie zum Beispiel »OpenWindows«, häufiger benutzt). Ein gutes Beispiel ist ein »Suchen & Ersetzen«-Dialog, der bei Bedarf immer offengelassen werden kann und damit immer direkt zur Verfügung steht, ohne erst einen Menüeintrag auswählen zu müssen (oder einen Tastaturshortcut zu benutzen). Gerade auf großen Bildschirmen kann der Benutzer sich so ein geeignetes Bildschirm »Layout« aufbauen (das natürlich auch gesichert werden können sollte).

Solche nichtmodalen Fensterdialoge sollten natürlich ein Schließfeld besitzen und den Zugang zu allen anderen Fenstern der Applikation gewähren.

Mit nichtmodalen Dialogen sollte man »Panel«-Fenster (s. Abb. 2) benutzen. Auch Panel-Fenster können während der normalen Arbeit geöffnet bleiben. Im Gegensatz zu Dialogen haben sie aber normalerweise keine Exit-Buttons und können nur über Fensteroperationen geschlossen werden. Normalerweise enthalten sie Werkzeuge oder spezielle Objekte, die man in ein Dokumentfenster einfügen kann.

Volle drei Seiten widmet der Inside Mac der Beschriftung von Buttons (womit auf dem Mac ja bekanntlich nur die Exit-Buttons, nicht etwa Radio-Buttons oder CheckBoxes gemeint sind). Einfach, aber oft falsch gemacht: es heißt »Cancel« bzw. »Abbruch« (nicht etwa »CANCEL« oder »ABBRUCH«), wohl aber »OK«. Zu diesem Hinweis hat sich allerdings Atari selbst in der XControl-Dokumentation durchgerungen (dann aber selbst nicht immer beherzigt). Mehrdeutige und nicht auf Anhieb zuzuordnende Beschriftungen wie »Ja«, »Nein« oder »Doch« sollten vermieden und wenn möglich durch Verben ersetzt werden (»Kopieren«, »Überspringen«, »Verwerfen«).

Abb. 3: Dialogbox »Änderungen sichern«

»Abbruch« bricht den Dialog ab und versetzt den Computer in exakt den Zustand vor dem Aufruf des Dialogs. Damit entspricht »Abbruch« der Anweisung »breche diese Operation ohne jeden Nebeneffekt ab«, nicht etwa »ich habe diesen Hinweis gelesen« oder »beende den Vorgang dennoch«. Wenn sich der Ursprungszustand nicht wiederherstellen läßt, sollte es auch kein »Abbruch« geben (Alternative: »Stop«).

Der Default-Button in einem Dialog sollte immer derjenige sein, den der Anwender mit der größten Wahrscheinlichkeit drücken wird. Eine wichtige Ausnahme von der Regel: wenn dieser Knopf gefährliche Folgen auslösen kann (z.B. das Formatieren einer Diskette). In einem solchen Fall ist es unter Umständen am besten, gar keinen Knopf zum Default-Button zu machen und beide gleichberechtigt erscheinen zu lassen.

Auch das Thema »allgemeines Layout von Dialogen« kommt bei Apple nicht zu kurz. Hier eine Zusammenfassung der wichtigsten Vorschläge (die sich mit dem decken, was man seit geraumer Zeit auch in vielen GEM-Applikationen sieht):

Wie intensiv sich die Experten bei Apple mit den Problemen der Anwender auseinandersetzen, zeigt eine lange Erörterung der »Änderungen sichern«-Dialogbox (s. Abb. 3) - wer ist nicht selbst schon mal einem Programm begegnet, bei dem die in diesem Zusammenhang erscheinende Dialogbox überhaupt nicht oder erst nach minutenlangem Überlegen zu verstehen war?

Am Apple-Vorschlag sind folgende Details beachtenswert:

Fazit: Die Apple-Systemdokumentation ist und bleibt eine nützliche Informationsquelle für alle, die benutzerfreundliche Programme schreiben wollen.

Natürlich sind auch Apples Vorschläge nicht über jeden Zweifel erhaben - auf jeden Fall stecken aber erheblich mehr Aufwand, Erfahrung und Erfolg als bei jedem anderen User-Interface dahinter (wobei man die Optik von »Windows« nur als mäßige Mac-Kopie bezeichnen kann).

(uw)

Quellennachweis:

[1] Patrick G. Dubbrow: »Magix Der Softwarjongleur«, ST-Magazin 7/92, Seite 48
[2] Apple Computer »Inside Macintosh Volume VII«, Addison Wessley Publishing Company. Inc., ISBN 0-201 57755 0
[3] Jankowski/Rabich/Reschke: »ATARI Profibuch ST-STE-TT«, 12. Auflage, Sybex Düsseldorf 1992, ISBN 3-88745-888-5


Julian F. Reschke
Aus: ST-Magazin 09 / 1992, Seite
Links
Copyright-Bestimmungen: siehe Über diese Seite