Netzwerkprodukte - Userinterfaces (4)

(Themenanfang)

Man hat in den letzten Dekaden wiederholt darüber gestritten, wie ein ideales GUI auszusehen habe, und diese Diskussionen waren nicht nur kontrovers, sondern häufig außerordentlich emotional besetzt. Eigentlich sollte man meinen, daß man es hier mit einem technischen Thema zu tun hat, bei dem sich allenfalls unbedarfte User vehement in die Haare geraten, die Fachleute hingegen eine sachliche Debatte führen. Auch unter letzteren toben aber Auseinandersetzungen, die manchmal an Glaubenskriege erinnern, und deren Ende nicht absehbar ist, auch wenn in bestimmten Teilbereichen mittlerweile stillschweigende Übereinstimmung herrscht. Die Antwort auf die Frage, warum es hier so bewegt zugeht, ist dabei wohl ein Schlüssel, um zum Thema selbst relevantes zu sagen.

Ich bin der Meinung, daß es keine allgemeingültige Theorie darüber geben kann, wie ein optimales GUI auszusehen hat. Man hat öfters versucht, allgemeine Regeln aufzustellen, was man zu tun bzw. zu lassen habe - gerade Apple hat schon früh versucht, den Macintosh-Entwicklern klare Richtlinien auf den Weg zu geben. Dabei hat man sich aber wiederholt in Widersprüche verwickelt, bzw. immer mal wieder Entwicklungen auf den Weg gebracht, die den eigenen Regeln widersprachen. Das ist eigentlich auch kein Wunder - die Anforderungen an ein GUI widersprechen einander selbst.

Ich sehe zwei zentrale Anforderungen an ein GUI, die jeweils durch andere, widersprüchliche Ansprüche in die Zange genommen werden:

• Ein GUI soll intuitiv verständlich, gleichzeitig aber einfach bedienbar sein. Der Widerspruch zwischen diesen Anforderungen wird immer dort deutlich, wo ein Power-User mit einem GUI zurande kommen soll, das auf einen Anfänger zugeschnitten wurde. Der Profi braucht Abkürzungen jeder Art[1], wo der Einsteiger ausführlich an die Hand genommen werden will, und vice versa[2].

• Ein GUI soll konsistent sein - d.h., eine einmal eingeübte Metapher oder Folge von Befehlen soll sich überall gleich verhalten. Copy&Paste z.B. soll sich auf alle Daten anwenden lassen, egal, wie diese konkret aussehen.

Dem Wunsch nach Konsistenz stehen andere Anforderungen entgegen:

• Ein GUI muß an vielen Stellen redundant sein - d.h., es muß mehr als nur einen Weg bieten, ein bestimmtes Ziel zu erreichen (z.B. einen Befehl durch ein Menu, oder aber ein Icon in einer Toolbar verfügbar machen). Konsistenz und Redundanz sind zwei einander widersprechende Prinzipien.

• Jede Präferenz, jede konfigurierbare Toolbar und jedes vom User individuell zuweisbare Tastaturkommando widerspricht der Forderung nach Konsistenz, und bedeutet zusätzlich zunehmende Komplexität, die dem intuitiven Verständnis entgegen läuft. Ohne solche Konfigurierbarkeit läßt sich aber keine halbwegs komplexe Applikation realisieren, die den Ansprüchen einer größeren Gruppe von Usern gerecht wird.

• Weiterhin steht der Versuch, ein Interface so konsistent wie nur möglich zu implementieren, dem Unterschied in der Beschaffenheit der Daten entgegen, wodurch gelegentlich Lösungen entstehen, die aufgesetzt wirken und für den User nicht wirklich produktiv sind. Ein Beispiel hierfür ist Drag&Drop von Textblöcken in „Word” & Co. Ein Feature, das für Dateioperationen im Betriebssystem perfekten Sinn ergibt, ist nicht ohne Grund in den meisten Texteditoren in den Präferenzen abschaltbar.

  In diese Rubrik gehört sogar das „universelle” Prinzip von Selection&Action - man selektiert Daten, und führt auf dieser Selektion eine Aktion aus, die man z.B. in einem Menu anwählt. Es gibt durchaus Situationen, in denen dieses - allgemein fraglos akzeptierte - Schema sich nur gewaltsam durchziehen läßt - der „Selected”-Status von farbigen Objekten in einem Grafikprogramm etwa läßt sich nur mühsam und unter Verrenkungen konsistent auf dem Bildschirm darstellen.

Um diese Widersprüche aufzulösen, hat man gelegentlich die Forderung erhoben, Monster wie „Word” oder auch „Cubase” in eine Gruppe von Modulen aufzuteilen, die jeweils auf einen bestimmten Task spezialisiert sind und die Komplexität einer Applikation, die für alles eine Lösung hat, aufteilt, und für den User beherrschbar machen. Dabei übersieht man, daß die Komplexität auf diese Weise lediglich verteilt, nicht aber reduziert wird - um den zusätzlichen Preis, daß die Userinterfaces nur locker miteinander verkoppelter Module große Probleme mit kohärentem Verhalten im GUI haben[3].