Welches Fensterlayout ist das richtige? Diese Frage muss ein GUI-Entwickler gleich zu Beginn seiner Arbeit stellen. Die Antwort hängt von der Art der Anwendung ab.

Eine wesentliche Entscheidung müssen Programmierer grafischer Anwendungen bereits treffen, wenn sie die Bedienoberfläche entwerfen: Welches Fensterlayout erfüllt die Ansprüche der Anwender am besten? Grundsätzlich konkurrieren zwei Ansätze: Single Document Interface (SDI, ein Dokument pro Fenster) und Multiple Document Interface (MDI, ein Fenster, das alle geöffneten Dateien enthält). Da beide Ansätze aus Sicht der Benutzerfreundlichkeit Nachteile bergen, hat sich in den letzten Jahren eine Vielzahl an Modifikationen und Mischformen entwickelt; am beliebtesten ist das durch Mozilla und Opera bekannte Tabbed Document Interface.

Der Klassiker

Das Multiple Document Interface stammt aus den Anfangstagen von Microsoft Windows, denn die frühen Versionen dieser weit verbreiteten grafischen Oberfläche konnten nur ein Toplevel-Fenster pro Anwendung darstellen. Also ordneten die Programme als Behelfslösung ihre einzelnen geöffneten Dokumente in einem gemeinsamen Fenster an, damit die Benutzer mehrere Dateien gleichzeitig öffnen konnten. Windows 95 beseitigte zwar das technische Problem, doch viele grafische Programme verwendeten das MDI-Konzept weiterhein, nicht nur unter Windows [1].

Ein großer Nachteil des auch Childframe Window Interface genannten MDI-Konzepts liegt darin, dass es schnell unübersichtlich wird. Um ein geöffnetes Fenster mit einer bestimmten Datei zu finden, navigiert sich der Anwender oft durch ein »Fenster«-Menü und wählt aus der Liste das gesuchte Unterfenster. Abbildung 1 zeigt als Beispiel die KDE-Entwicklungsumgebung KDevelop. Alternativ verkleinert der Benutzer die Unterfenster nach und nach, bis das gewünschte im Vordergrund erscheint.

Eine anwendungsübergreifende Methode zum Window-Cycling, also für den schnellen Wechsel zwischen den Fenstern, fehlt MDI-Anwendungen. Einige Programme verwenden als Ersatz für die Desktop-weite Tastenkombination [Alt] +[Tab] Alternativen wie [Strg] zusammen mit den Pfeiltasten. Da diese Mittel jedoch uneinheitlich sind, eignen sie sich nicht als generelle Lösung zur Navigation durch die Unterfenster.

Der zweite Hauptkritikpunkt am MDI-Konzept betrifft das schlechte Raummanagement: Die Unterfenster lassen sich ausschließlich innerhalb des umrahmenden Mutterfensters platzieren, und zwar nur so, wie es die jeweilige Anwendung vorsieht. Der Benutzer kann sie nicht unbedingt nach eigener Logik anordnen, denn die Entwickler von MDI-Anwendungen implementieren das Fenstermanagement selbst und erreichen dabei selten dieselben Möglichkeiten wie darüber liegende Windowmanager.

Toplevel-Window

Als Variante zum klassischen Multiple Document Interface öffnen manche Anwendungen für jedes Dokument ein eigenes Fenster als Toplevel-Window auf dem Desktop. Der Steuerung des Programms dient ein zentrales Hauptfenster, das alle Menüs und Werkzeugleisten beherbergt. Die Fensterverwaltung übernimmt der Windowmanager.

Dieser Ansatz birgt jedoch ein schwerwiegendes Problem: Sobald der Nutzer von einem aktiven Dokument zum Hauptfenster wechselt, um einen Menüpunkt oder ein Werkzeug zu verwenden, verliert das aktuelle Fenster den Fokus. Wenn mehrere Dokumente geöffnet sind, erhält der Nutzer keinerlei visuelle Rückmeldung, auf welches Dokument sich eine Operation bezieht. Ist der Windowmanager zudem so konfiguriert, dass ein Fenster bei Kontakt mit dem Maus-Cursor den Fokus erhält, sind Fehler programmiert.

Abbildung 1: Das Multiple Document Interface erschwert den Wechsel zwischen den einzelnen Fenstern. Wie bei KDevelop erfolgt er meist über das Menü, einheitliche Shortcuts fehlen.

Zumindest eine Teillösung für dieses Problem liefert das Bildbearbeitungsprogramm Gimp (Abbildung 2). Es sortiert die Menü-Einträge in Anwendungs- und Dokument-bezogene Punkte. Jedes Dokument-Fenster erhält eine eigene Menüleiste mit Funktionen wie »Bearbeiten | Ausschneiden«, während allgemeine Menü-Einträge wie »Datei | Einstellungen« im Hauptfenster liegen.

Dieses Konzept mildert zwar das Problem der reinen Toplevel-Window-Anwendungen, löst es aber nicht vollständig. Auch bei Gimp verliert der Benutzer den Fokus des Dokument-Fensters, wenn er beispielsweise die Werkzeugbox verwendet. Zudem verläuft die Grenze zwischen Anwendungs- und Dokument-bezogenen Menüpunkten fließend, sodass der Benutzer häufig nicht weiß, wo er nach einer Funktion suchen muss.

Abbildung 2: Gimp unterscheidet mit einer Sonderform des MDI zwischen Dokument- und Anwendungsbezogenen Funktionen und stattet seine Toplevel-Windows mit den entsprechenden Menüs aus.

Weiterentwicklung

Mehr Eigenständigkeit als bei Toplevel-Window-Anwendungen erhalten die einzelnen Dokument-Fenster beim Single Document Interface (SDI). Statt Menüs und Werkzeuge zwischen den Dokumenten zu teilen, starten SDI-Programme jedes Dokument in eigenständigen Anwendungs-Fenstern. Sie besitzen eigene Menüleisten, Toolbars und Optionen-Fenster, sodass sich der Zusammenhang zwischen aktivem Dokument und ausgeführter Option daraus erschließt.

SDI kam vor einigen Jahren in Mode, so urteilten die Usability-Experten von Microsoft, das Konzept schaffe ein einfacheres Interface, das die Mehrheit der Benutzer besser verstehe [2]. Star Office und Open Office zogen nach und verwenden inzwischen ebenfalls ein Single Document Interface.

Doch die Gebrauchstauglichkeit von Single Document Interfaces stößt an ihre Grenzen, wenn mehr als drei oder vier Fenster derselben Applikation geöffnet sind. Dann stellt die Taskleiste die offenen Fenster entweder sehr klein dar oder gruppiert sie so, dass der Benutzer wiederum nicht alle auf einmal im Blick hat. Bei Office-Anwendungen geschieht das selten, beispielsweise bei Webbrowsern dagegen sehr häufig.

Tabbed Document Interface

Um eine größere Zahl an Dokumenten zu verwalten, führten zunächst Webbrowser das Tabbed Document Interface ein. Dieses Design sammelt die Unterfenster als Reiter oder Tabs in einem Mutterfenster (Abbildung 3). Die Fensterverwaltung übernimmt hier also wie beim MDI die Anwendung selbst.

Pionier des Tab-Designs war Netcaptor, ein alternatives Interface zum Internet Explorer von Microsoft. Ab dem Jahr 2000 begannen Opera, Mozilla und die meisten anderen Browser, das Konzept zu übernehmen. Aber auch in anderen Bereichen stößt das Tabbed Document Interface heute auf Beliebtheit, zum Beispiel in Entwicklungsumgebungen, Shells, Instant Messengern oder Tabellenkalkulationen.

Ein Tab-Interface zeigt immer nur ein Dokument an und unterliegt damit noch größeren Einschränkungen in der Fensterverwaltung als das MDI. Die meisten Programme mit einem solchen Oberflächendesign lösen dieses Problem, indem sie es als Alternative zu den Reitern anbieten, neue Dokumente SDI-typisch in einem eigenen Hauptfenster zu öffnen.

Abbildung 3: Browser wie Firefox verbinden Tabbed und Single Document Interface, indem sie dem Benutzer die Wahl zwischen beiden Möglichkeiten lassen.

Dateien schließen

Die Wahl des Fensterlayouts beeinflusst auch das Verhalten beim Schließen von Dateien. Das liegt zum einen an der üblichen Trennung zwischen den Funktionen zum Schließen der Datei und zum Beenden der Anwendung. Relativ eindeutig ergibt sich das Verhalten im Multiple Document Interface: »Datei | Schließen« etwa schließt gewöhnlich nur das aktuelle Dokument, aber nicht das Mutterfenster. Um die gesamte Anwendung zu beenden, wählt der Nutzer den Menüpunkt »Datei | Beenden«.

Im Tabbed und im Single Document Interface ist das Verhalten weniger eindeutig. Während »Beenden« im Textverarbeitungsprogramm KWrite mit SDI-Oberfläche das aktuelle Fenster schließt, verschwinden bei Open Office mit diesem Befehl alle Programmfenster. Der Menüpunkt »Datei | Schließen« beendet bei KWrite das aktuelle Dokument, lässt aber das Fenster mit einer neuen, leeren Datei geöffnet. Open Office dagegen schließt mit dem gleichen Kommando das Fenster; nur wenn es sich um das letzte offene Programmfenster handelt, bleibt es geöffnet. (csc)