Single Document Interface vs. Multiple Document Interface
Fensterordnung
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.
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.
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.
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.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...