Immer mehr Programme werden nicht über die Bedienoberfläche des Betriebssystems gesteuert (GUI), sondern über einen Webbrowser. Das hat viele Vorteile, u.a. die fehlende Installation beim Anwender und die zentrale Datensicherung. Aber es hat auch einen sehr großen Nachteil: Das Interface des Programms.
(Dieser Artikel erschien im Buch “PHP im Einsatz” vom Software & Support Verlag.)

Zur Verfügung stehen nur Links und HTML-Formulare. Es gibt z.B. keine Icons, kein Drag-&-Drop, keine Menüleisten und keine Schieberegler. Damit machen wir einen großen Schritt zurück in die Steinzeit des Interface-Designs.
Ein gutes und einfach zu bedienendes Interface ist keine leichte Aufgabe. Es ist vor allem keine schnelle Aufgabe. Planen Sie daher unbedingt viel Zeit für das Interface ein – und zwar von Anfang an. Planen Sie noch mehr Zeit für das Testen des Programms ein und für die Korrektur der dadurch gefundenen Fehler.
Interface-Design ist ein wichtiger Bestandteil eines jeden Projekts und es wird immer entscheidender für den Erfolg einer Web-Anwendung. Während ein spezieller Interface-Designer im Projekt-Team das beste währe, ist dies nicht immer der Fall. Bedingt durch knappe Zeit oder ein knappes Budget wird oft der Programmierer mit dieser Aufgabe konfrontiert.
Interface-Design hat auch bei Webapplikationen nichts mit dem Design von “normalen” Webseiten gemein. Dieser Artikel soll daher eine Einführung in Interface-Design geben. Im folgenden werde ich vier Phasen des Interface-Designs aufzeigen: Entwurf, Implementierung, Design und Test.

1. Entwurf

Das wichtigste vorweg: Es geht um den Anwender, nicht um die Technik. Wie eine Funktion implementiert wird, ist eine Frage, die sich die Programmierer stellen müssen, aber nicht der Anwender. Die Schnittstelle zwischen Anwender und Programm sollte die Art und Weise, wie das Programm intern arbeitet, nach Möglichkeit verbergen. Auch wenn dies manchmal mehr Aufwand für die Programmierer bedeutet.

Zielgruppe

Dafür ist ein grundlegendes Verständnis der Zielgruppe nötig. Wer wird das Programm später verwenden? Wie soll das Programm dem Anwender bei seinen Aufgaben helfen? Wie erledigt der Anwender seine Aufgaben und wie wird das Programm dieses verändern? In welchem Umfeld wird es eingesetzt? Diese und noch viel mehr Fragen stehen am Anfang eines jeden Projekts. Ihre Beantwortung ist nicht immer leicht und kann viel Zeit in Anspruch nehmen.
Übrigens: Die einfachste Methode, Informationen über die Zielgruppe zu bekommen, ist sie zu fragen.

Aufgaben

Mit dem Programm kann der Anwender verschiedene Aufgaben lösen. Definieren Sie diese Aufgaben genau. Was kann man mit dem Programm machen und was nicht? Diese Aufgaben werden nach verschiedenen Konzepten bearbeitet. Soweit möglich, sollten Sie dabei auf vorhandene oder bekannte Konzepte zurückgreifen. Am besten auf Konzepte, welche im realen Leben vorkommen. Sind für einzelne Aufgaben neue Konzepte nötig oder kann man vorhandene Konzepte übernehmen bzw. anpassen?
Welche Daten kann man mit dem Programm erstellen oder bearbeiten? Welche Informationen gewinnt der Anwender daraus? Und wie kann er sie weiterverarbeiten (z.B. speichern, ausdrucken, verschicken)?
Konzentrieren Sie sich bei diesem Schritt auf die Aufgaben, nicht auf die Umsetzung oder das Design. Das kommt später.

Konzeptmodell

Das Konzeptmodell ist der Plan, nach dem das Programm funktioniert. Jede Aufgabe ist darin eingetragen, mitsamt dem Konzept, nach dem sie bearbeitet wird. Vermerken Sie dazu genau, welche Optionen und Möglichkeiten der Anwender wählen muß und welche er wählen kann. Stellen Sie klar, wo sich verschiedene Aufgaben und Konzepte überschneiden oder ergänzen.
Das Konzeptmodell beschreibt die Aufgaben und deren Lösungen, aber es erklärt nicht die Bedienung des Programms. Sie brauchen also hier noch nicht entscheiden, wann man wo welchen Knopf zu drücken hat. Das ist auch wieder erst beim Design relevant.

Objektmodell

Das Programm präsentiert sich dem Anwender je nach gewähltem Konzept in verschiedenen Objekten. Microsoft Word z.B. zeigt dem Anwender ein weißes Blatt Papier, welches er beschreiben kann. Apples Mac-OS präsentiert sich als Schreibtisch, auf dem ein Computer steht, ein Drucker, ein Papierkorb, etc. Das sind alles Objekte, mit denen der Anwender zu tun hat.
Das Objektmodell listet alle diese Objekte als Flußdiagramm auf. Linien kennzeichnen die Beziehungen zwischen den Objekten. Definieren Sie für jedes Objekt was es kann, welche Daten es verarbeitet oder repräsentiert und welche Optionen für das Objekt nötig sind. Wie gelangt man zu einem Objekt und wie verläßt man es? Welche Objekte existieren beim Start und welche muß der Anwender erzeugen?
Und überlegen Sie sich bei jedem Objekt und bei jeder Option, ob es notwendig ist. Jedes zusätzliche Feature macht das Programm auch komplexer. Oft erzeugt allein die Fülle an Möglichkeiten beim Anwender das Gefühl, er habe es mit einem komplizierten Programm zu tun. Also halten Sie das Programm so einfach wie möglich und treffen Sie Entscheidungen für Ihre Anwender, wenn eine Option sowieso nur selten gebraucht wird.
Das ganze hat übrigens nichts mit den Objekten der objektorientierter Programmierung zu tun. Hier geht es um die Sicht des Anwenders, und der interessiert sich für die Programm-Interna nicht.

Lexikon

Geben Sie jedem Objekt einen Namen und behalten Sie diesen Namen im gesamten Programm bei. Geben Sie auch jedem Konzept, jeder Dialogbox und jeder Option einen Namen. Legen Sie für diese Namen ein Lexikon an.
Wenn Sie im Lexikon alle Namen zusammen haben, überprüfen Sie diese. Sind die gewählten Begriffe eindeutig? Oder könnte man sie mißverstehen? Gibt es Objekte, die ähnlich heißen? Oder sind Namen zu schwammig definiert? Mit diesen Begriffen wird der Anwender später arbeiten, also achten Sie darauf, daß sie leicht zu verstehen und zu merken sind. Nach Möglichkeit verwenden Sie Begriffe aus dem Umfeld des Anwenders. Nicht alle Fachwörter, die für Programmierer alltäglich sind, sind es auch für den Endanwender.

2. Implementierung

Mit den Modellen und dem Lexikon aus dem letzten Abschnitt sind Sie gut vorbereitet für die Implementierung des Programms und dessen Interfaces. Wie bereits am Anfang erwähnt, liegt der Schwerpunkt dieses Artikels auf Programmen, welche über ein Web-Interface und einen Browser bedient werden. Die meisten Konzepte des traditionellen Interface-Designs sind hier nicht möglich. Ich werde im Folgenden besonders auf diese Problematik eingehen.

Browser

Sehen Sie sich dieses Bild an, ein Screenshot aus Mac-OS mit dem Microsoft Internet Explorer.

So oder so ähnlich sieht jedes graphische Betriebssystem aus. Die weiße Fläche in der Mitte ist der Platz, der Ihrem Programm zur Verfügung steht. Alles andere drum herum gehört nicht zum Programm, sondern entweder zum Betriebssystem oder zum Browser. Trotzdem buhlt dieser Bereich um die Aufmerksamkeit des Anwenders. Schnell klickt der Anwender z.B. auf die Favoriten-Leiste des Browsers oder gibt eine neue Adresse ein. Ihr Programm, welches er gerade noch benutzt hat, ist dann weg, mitsamt allen nicht gespeicherten Daten. Denken Sie nur daran, was passiert, wenn ein unbedarfter Benutzer ein größeres Formular zur Hälfte ausgefüllt hat und dann auf den Zurück-Button des Browsers klickt.
Sie können dieses Problem auf zwei Arten lösen: Entweder, Sie gestalten Ihr Programm so, daß es zu keiner Zeit zu Inkonsistenzen kommt, egal wie der Anwender durch die Seiten navigiert. Oder Sie nehmen dem Anwender einen Teil der Kontrolle über den Browser. Öffnen Sie ein neues Browserfenster (mit Javascript) und deaktivieren Sie alle Menü- und Buttonleisten, aber lassen Sie die Statusleiste aktiv. Sie können das tun, weil es hier um ein Programm geht und nicht um eine Website. Wo z.B. der Zurück-Button bei Websites als überlebensnotwendig gilt, ist er bei Webapplikationen eher hinderlich.
Ich persönlich bevorzuge einen Mittelweg: Das Programm und seine Daten werden im Hauptfenster angezeigt, aber für alle Formulare, bei denen der Benutzer Daten eingeben muß, öffnet sich ein neues Fenster ohne die Steuerelemente des Browsers.

Navigation

Die Art der Navigation hängt in weiten Teilen von der Arbeitsweise des Programms ab. Wenn gewisse Schritte aufeinander aufbauen, reichen einfache Vor- und Zurück-Links, wie bei einem “Wizard”. Wenn mehrere Funktionen gleichberechtigt sind oder wenn die Reihenfolge des Ablaufs nicht festgelegt ist, bieten Sie dem Benutzer eine Reihe von Links als Navigationsleiste.
Die Anordnung der Links erfolgt wie bei einer Website. Mehr als 5 Links positionieren Sie am besten am linken Rand der Seite. Wenn Sie 5 oder weniger Links haben, können Sie diese auch am oberen Rand als horizontale Leiste einfügen. Wichtig ist, daß der Anwender jederzeit erkennt, in welchem Bereich er sich gerade befindet. Signalisieren Sie dies durch die Überschrift und indem Sie den Link einfärben oder anderweitig verändern. Die Rückmeldung muß auf jeden Fall dort erfolgen, wo der Benutzer geklickt hat.
Wenn Sie besonders viele Optionen oder Menüpunkte haben, gruppieren Sie diese. Ein schönes Beispiel hierfür sind die Einstellungen des Netscape Navigators oder des Microsoft Internet Explorers am Mac.

Benutzen Sie auf jeden Fall Text-Links für die Navigation. In Ausnahmefällen können Sie auch Graphiken verwenden, beispielsweise für die Überschriften von Funktionsgruppen oder wenn Sie nur wenige Optionen haben. In diesem Fall sollten Sie durch ein “Roll-over”-Bild kennzeichnen, daß es sich um einen Link handelt. Benutzen Sie für die Navigation niemals Buttons — die sind für Formulare reserviert!

Befehle

Der Anwender kann in Ihrem Programm verschiedene Befehle ausführen. Für einen Befehl nehmen Sie am besten einen Text-Link. Wichtig ist, ob es sich dabei um Befehle handelt, die beim Anklicken sofort ausgeführt werden (direkte Funktionen) oder ob noch weitere Daten dazu benötigt werden (indirekte Funktionen).
Wenn ein Befehl auf Knopfdruck sofort ausgeführt wird, stellen Sie ihn auf die Hauptebene. Wenn weitere Formulardaten abgefragt werden, öffnen Sie ein neues Fenster (s.o.). Das Fenster sollte so heißen wie der Link, der es geöffnet hat. Vermeiden Sie Fenster, die gleich heißen oder die nur den Namen des Programms tragen. Am unteren Ende des Formulars kommt rechts der Button zum Abschicken und links der Button zum Abbrechen hin. Und seien Sie vorsichtig mit der Beschriftung: Ein Button “Abbrechen” ist größer und leichter zu klicken, als ein Button “OK”. Wenn möglich, verzichten Sie ganz auf den “Abbrechen”-Button.
Wenn das Formular abgeschickt wurde, schließen Sie das Fenster wieder und laden Sie die darunter liegende Seite neu, um die Änderungen anzuzeigen.
Fügen Sie bei Text-Links, bei denen sich ein neues Fenster öffnet, am Ende drei Punkte an (z.B. “Optionen…”). Wenn Sie dies konsequent durchhalten, lernt der Anwender sofort, zwischen direkten und indirekten Funktionen zu unterscheiden.

Formular-Elemente

HTML bietet wenig Möglichkeiten der Dateneingabe. Wichtige Konzepte wie z.B. Schieberegler oder Drag-&-Drop sind nicht vorhanden. Statt dessen müssen Sie mit den bekannten Formular-Elementen auskommen.

Das Texteingabefeld ist das universelle Element. Jede Information läßt sich im Grunde durch Text abbilden. Das macht es auch so verlockend, das Textfeld einzusetzen. Sie sollten aber, wo möglich, andere Elemente verwenden, bei denen Sie leichter die Eingabe überprüfen können. Das Textfeld ist für Texteingaben reserviert, z.B. für den Benutzernamen und das Paßwort. Bieten Sie dem Benutzer Hilfestellung, indem Sie das Feld vorformatieren oder aufteilen, z.B. für die Kreditkartennummer oder das Datum.
Voreinstellungen sollten sie nur in das Feld schreiben, wenn diese auch beibehalten werden. Wenn der Benutzer den Text erst löschen muß, um dann seinen eigenen einzugeben, wird das auf Dauer mehr ärgern als nützen
Ein Sonderfall ist das mehrzeilige Textfeld (“Textarea”). Je nach Textlänge, die Sie erwarten, sollten Sie das Textfeld ausreichend groß dimensionieren, um unnötiges Scrollen zu vermeiden. Moderne Browser nehmen am Ende einer Zeile automatisch einen Zeilenumbruch vor, ältere machen dies nicht. Aktivieren Sie in diesem Fall den Zeilenumbruch mit dem Attribut wrap=”virtual”.

Mit Radio-Buttons kann man genau eine Option aus beliebig vielen wählen. Wichtig ist, daß Sie eine Option als Voreinstellung wählen, sonst wird der Benutzer unnötig verwirrt. Klickt er nämlich dann in einen der Radio-Buttons, erscheint ein Punkt, der die gewählte Option markiert. Diesen Punkt kann man dann zwar auf die anderen Optionen springen lassen, aber man bekommt ihn nicht mehr weg, so wie es vorher war. Fügen Sie in diesem Fall lieber noch eine Option “Aus” an und wählen Sie diese als Standard.

“Drop-down”-Listen sind eine andere Möglichkeit, eine aus mehreren Optionen zu wählen. Sie eignen sich besonders gut für längere Listen. Zur besseren Orientierung sollten Sie die Optionen sortieren, z.B. alphabetisch. Auch hier gilt: fügen Sie im Zweifelsfall eine Option “Aus” mit ein.

“Checkboxes” (Kontrollkästchen) haben genau zwei mögliche Werte: Ein oder Aus. Die beiden Möglichkeiten müssen eindeutig sein. Entweder eine Option ist aktiv, oder sie ist es nicht. Wenn sich aus der nicht-aktiven Option andere Konsequenzen ergeben, nehmen Sie lieber Radio-Buttons. Angenommen, Sie haben ein Kontrollkästchen “Textfarbe: Rot”. Wenn es nicht angeklickt ist, ist der Text aber grün. Nehmen Sie in diesem Fall lieber Radio-Buttons.

Mehrere aus mehreren Optionen wählen Sie am besten mit dem Listenfeld. Auch hier gilt wieder: Vermeiden Sie unnötiges Scrollen und machen Sie das Feld ausreichend groß.

Buttons sind ausschließlich zum Abschicken und Abbrechen eines Formulars reserviert. Einzige Ausnahme ist der Button, um eine Datei auf der Festplatte auszuwählen — ansonsten sind Buttons tabu! Wenn Sie eine Funktion ausführen wollen oder wenn Sie ein Fenster öffnen wollen, nehmen Sie statt dessen lieber Text-Links. Bilder als Buttons sind mit Vorsicht zu verwenden: Die wenigsten Benutzer erkennen diese als Elemente zum Anklicken.

Ebenfalls tabu sind die Formular-Elemente für das Ergebnis. Wenn Sie ein Ergebnis präsentieren, machen Sie dies mit reinem HTML, aber schreiben Sie das Ergebnis nicht in Formular-Elemente, wie z.B. ein Textfeld. Der Benutzer denkt sonst, er könnte diese Daten weiter bearbeiten.

Reaktion

Wenn der Anwender in einem Programm eine Funktion ausführt, erwartet er von diesem eine Reaktion. Wichtig ist hierbei, daß die Reaktion so schnell wie möglich erfolgt. Wenn ein Anwender nach jedem Mausklick länger warten muß, denkt er, sein Computer wäre zu langsam oder das Programm verschluckt Eingaben.
Im Web sind lange Reaktionszeiten prinzipbedingt nicht vermeidbar, weil jedes Mal eine neue Website geladen wird. Aber der Benutzer rechnet hier auch mit etwas längeren Wartezeiten. Vorsicht ist geboten, wenn diese Wartezeiten unerwartet auftreten. Wenn Sie z.B. per Javascript eine neue Seite aufrufen, nur weil der Benutzer einen Radio-Button angeklickt hat, ist das entgegen seiner Erfahrung. Er erwartet, daß nach dem Klick der Button aktiv ist und zwar sofort (wie es ja auch normalerweise der Fall ist). Daß er länger warten muß, verwirrt und verunsichert nur.
Bei Text-Links und Buttons sind Wartezeiten erlaubt, weil sie hier erwartet werden. Bei allen anderen Elementen nicht. Wenn Sie nicht sicher stellen können, daß eine Reaktion sofort erfolgt, sollten Sie diese nur durch einen Link oder Button auslösen lassen.

Beachten Sie die Reihenfolge der Ereignisse, wenn Sie ein Formular in einen Popup-Fenster haben. Wenn der Benutzer auf “Abbrechen” klickt, wird das Fenster geschlossen. Wenn das Formular groß und aufwendig ist, sollten Sie vor dem Schließen lieber einmal nachfragen. Wenn der Benutzer auf “Abschicken” klickt, senden Sie die Formulardaten an den Server. Dieser schickt eine leere Seite zurück, in der mit Javascript das Fenster geschlossen und die darunter liegende Seite neu geladen wird.
Wenn Sie die Daten an den Server schicken und gleichzeitig das Fenster schließen, sind im Falle eines Fehlers die Daten weg. Das ist unverantwortlich gegenüber dem Anwender des Programms.

Fehlermeldung

Fehler kann es immer geben, wichtig ist jedoch, wie man damit umgeht. Das oberste Gebot hierbei: Stellen Sie sicher, daß die Daten, die der Anwender in ein Formular eingegeben hat, erhalten bleiben. Nichts ist ärgerlicher, als diese nochmals eingeben zu müssen.
Sagen Sie dem Benutzer, daß ein Fehler aufgetreten ist. Schreiben Sie dies kurz und verständlich in einer natürlichen Sprache und vermeiden Sie Fachbegriffe oder gar Wörter aus dem Quellcode des Programms. Unter “Object class_id.new not found on line 42” kann sich kein normaler Mensch etwas vorstellen. Wenn der Benutzer an dem Fehler schuld ist, schreiben Sie kurz, warum. Wenn er nicht Schuld ist, interessiert es ihn auch nicht. Beschreiben Sie in einer Fehlermeldung die Lösung, nicht das Problem!
Bieten Sie nach der Meldung einen Link oder Button, um die gewünschte Aktion ohne größere Umwege noch einmal auszuführen.

3. Design

Wenn Sie die Struktur des Programms festgelegt haben, geht es an das Design. Ich werde an dieser Stelle nicht die Grundlagen von Graphikdesign wiederholen, das würde den Rahmen dieses Artikels sprengen. Allerdings gelten die etablierten Prinzipien auch für das Design von Interfaces und Formularen.

Wahrnehmung

Wichtig ist die Reihenfolge, in der ein Mensch das Interface betrachtet. Das gilt für alle Objekte, seien es Bilder, Webseiten oder Zeitungen. Zuerst “scannt” man die Breite und Höhe des Objekts. Dann schaut das Auge in die linke obere Ecke und wandert von dort nach rechts unten. Dies geschieht in einer Zick-Zack-Bewegung. In der Graphik sehen Sie grau markierte Felder, diese sind besonders prominent.
Daraus ergeben sich folgende Konsequenzen: Wichtig ist ein klar definierter Bereich, z.B. für ein Formular. Hinterlegen Sie ein Formular mit einer grauen Fläche. Es muß sofort ersichtlich sein, wo das Formular anfängt und wo es aufhört. Außerdem hilft ein grauer Hintergrund zur besseren Unterscheidung von Textfeldern. Diese sind innen weiß, also kann man hineinschreiben. Wenn sowohl Textfelder als auch Hintergrund weiß sind, ist dies nicht sofort ersichtlich.
In der linken oberen Ecke steht die Überschrift für das Formular, in der rechten unteren der Button zum Abschicken. Falls Sie einen Abbrechen-Button verwenden, steht er in der linken unteren Ecke. Die Buttons, die das Formular steuern, sollten auf alle Fälle klar getrennt sein vom Inhalt des Formulars.

Nähe

Elemente, die inhaltlich zusammen gehören, gehören auch optisch zusammen. Ihre Formular-Elemente sollten also nicht über die ganze Seite verstreut sein. Fassen Sie statt dessen Elemente oder Optionen zu Gruppen zusammen. Diesen Gruppen können Sie dann eine Unterüberschrift geben. Diese Überschriften sollten auch wiederum in der Nähe der Elemente sein, die sie beschreiben.
Besonders gilt das Prinzip für Radio-Buttons. Sie gehören zusammen und sollten auch so nah wie möglich beieinander stehen. Der Name eines Feldes sollte in der Nähe des Feldes stehen, der Button zum Abschicken eines Formulars sollte auch wieder in der Nähe desselben sein. Das klingt banal, ist aber in der Realität oft nicht der Fall.
Sie können um eine Gruppe von Elementen auch einen Rahmen ziehen. Seien Sie damit aber sparsam. Verwenden Sie es nicht bei sehr kleinen Gruppen und schon gar nicht bei einem einzelnen Element. Ein Rahmen in einem anderen Rahmen ist ebenfalls tabu.
Achten Sie darauf, daß Elemente, die nicht zusammen gehören, auch nicht zufällig nahe beieinander stehen. So könnte ein falscher Eindruck erweckt werden und der Anwender denkt, es handle sich um eine Funktionsgruppe.

Ausrichtung

Ziehen Sie zwei, maximal drei Achsen und richten Sie alle Elemente an diesen aus. Wenn Elemente auf einer Achse stehen, sind sie miteinander verbunden, auch wenn sie nicht direkt zusammen stehen. So sollte der “Abschicken”-Button auf der gleichen Achse stehen, wie die Felder des dazugehörigen Formulars. Radio-Buttons, die zu einer Gruppe gehören, sollten auch auf der gleichen Achse stehen.
Richten Sie Ihre Elemente entweder links- oder rechtsbündig aus. Zentrieren Sie sie nicht. Das wirkt ungleichmäßig und verwirrt, weil weder eine linke noch eine rechte Achse existiert. Blocksatz können Sie simulieren, indem Sie mit Stylesheets die Pixelbreite von Eingabefeldern festlegen. Dies unterstützen aber nicht alle Browser.
Die Namen für Formularfelder richten Sie am besten rechtsbündig aus. Dann stehen an einer Achse rechtsbündig alle Namen und linksbündig die dazugehörigen Felder.
Übrigens ist es Standard, nach dem Feldnamen einen Doppelpunkt zu setzen. Sie müssen sich nicht daran halten, sollten aber eine einmal gewählte Schreibweise konsequent beibehalten.

Kontrast

Manche Elemente sind wichtiger als andere. So sind z.B. die Überschriften wichtiger als der Text. Um diese Elemente zu unterscheiden, verwenden Sie Kontrast.
Kontrast gibt es in verschiedenen Dimensionen: Sie können unterscheiden durch Größe, Stärke, Abstand oder durch Farbe. Suchen Sie sich eine Dimension aus, wählen Sie zwei deutlich verschiedene Werte und verwenden Sie diese beiden konsequent. Für ganz wichtige Fälle können Sie eine weitere Dimension einsetzen, jedoch nie mehr als zwei. Machen Sie klar, was wichtig ist und was nicht.

Wiederholung

Durch Wiederholung schlagen Sie gleich drei Fliegen mit einer Klappe: Erstens schaffen Sie ein ruhiges Gesamtbild. Sie müssen nicht für jede Überschrift eine neue Schriftart einsetzen oder einen neuen Effekt. Es reicht, wenn Sie sich auf einige wenige Stile beschränken und diese konsequent einsetzen. Auch brauchen Sie nicht für jedes Formular ein neues Layout erfinden. Ziehen Sie ein einmal gewähltes Schema im gesamten Programm durch.
Zweitens lernt der Benutzer das Programm leichter. Wenn Elemente z.B. in jedem Formular am gleichen Platz sind, merkt sich das der Benutzer und erwartet sie beim nächsten Mal bereits dort. Das gleiche gilt für Funktionsabläufe. Wenn der Anwender einen Ablauf einmal gelernt hat, kann er ihn bei jeder Funktion sofort einsetzen.
Und drittens sparen Sie sich eine Menge an Zeit. Wenn Sie Ihre Formulare und Seiten immer wieder nach dem gleichen Schema aufbauen, können Sie diese schneller produzieren. Vielleicht können Sie sogar Vorlagen (Templates) einsetzen.
Bei all diesen Prinzipien ist eines ganz wichtig: Exzessive Design-Auswüchse sind hier fehl am Platz. Es geht um eine einfach zu bedienende Software. Die muß keine Design-Preise gewinnen, sie muß nur funktionieren. Wenn sie dabei etwas langweilig aussieht, dafür aber einfach zu lernen ist, ist uns das nur Recht.

4. Test

Der vierte ist der wichtigste Teil: Der Benutzertest. Während die ersten drei Phasen nacheinander bearbeitet werden, ist der Test während der ganzen Produktion wichtig. Planen Sie unbedingt von Anfang an viel Zeit für Tests und für die Korrektur der gefundenen Fehler ein.
Als Testpersonen eignen sich alle Menschen, die nicht selber an dem Programm entwickeln. Suchen Sie sich am besten Anwender des Programms, aber auch unbedarfte Personen. Die Testpersonen sollten aus der anvisierten Zielgruppe kommen. Es macht keinen Sinn, eine neue Programmierumgebung mit der eigenen Großmutter zu testen.

Quantitative und qualitative Tests

Testen kann man verschiedene Faktoren. Ganz grob wird unterschieden zwischen quantitativen und qualitativen Tests.
Quantitative Tests sind meßbar und stellen genau eine Frage: Wie lange braucht ein Benutzer für eine Aktion? Oder wie viele Klicks? Oder: Wo schaut er als erstes hin? Diese Daten sind nützlich, um Thesen zu belegen und Entscheidungen zu untermauern. Sie sind aber auch teuer, weil eine große Zahl von Menschen befragt werden muß und weil manche Geräte dafür teuer zu beschaffen oder zu leihen sind (z.B. Augen-Tracker).
Eine andere Möglichkeit sind qualitative Tests. Hier liegt der Schwerpunkt auf den Ideen der Testpersonen. Sie besprechen das Programm oder dessen Konzept mit der Testperson und machen sich Notizen. Daraus entwickeln sich dann neue Anregungen für das Programm. Wenn die Person einverstanden ist, können Sie das Gespräch auch aufnehmen.
Diese Methode hat den Vorteil, daß weit weniger Tests genügen, um ein ausreichendes Ergebnis zu bekommen. Außerdem brauchen Sie sich nicht mit statistischen Berechnungen und genauen Versuchsanordnungen beschäftigen. Die gewonnene Zeit können Sie wieder für neue Tests einsetzen. Sie sehen, dies ist ein iterativer Prozeß zwischen Ihnen und Ihren Anwendern.
Im folgenden möchte ich exemplarisch zwei von vielen möglichen Tests vorstellen.

Karteikartenspiel

Nehmen Sie einen großen Stapel Karteikarten und schreiben Sie auf jede Karte eine Funktion, ein Objekt oder ein Modell des Programms. Verwenden Sie nie mehr als 3 Wörter für die Beschreibung. Wenn Sie eine Funktion mit 3 Wörtern nicht unmißverständlich beschreiben können, teilen Sie die Funktion in mehrere Unterfunktionen und somit auf mehrere Karten auf.
Setzen Sie die Testperson an einen großen Tisch und geben Sie ihr die Karten. Sie soll die Karten so auslegen und gruppieren, wie sie denkt, daß die Funktionen zusammengehören. Beobachten Sie die Person, aber sagen Sie nichts. Sie sehen so, wie für einen typischen Anwender die Funktionen zusammengehören. Sie sehen auch, wenn die Testperson eine Karte nicht eindeutig oder nur zögerlich zuordnen kann.

Machen Sie diesen Test mit mehreren Personen und Sie werden eine Tendenz feststellen. Diese Anordnung der Funktionen ist nicht bindend für das Programmdesign, aber Sie sollten es als Anregung betrachten.

Papierprogramm

Machen Sie einen Screenshot vom Programm und drucken Sie diesen aus. Es ist hilfreich, wenn Sie ihn vergrößern (am besten A3 oder größer). Legen Sie den Screenshot auf einen Tisch und zeigen Sie ihn der Testperson. Die Person soll jetzt nacheinander auf alle Elemente, Buttons und Felder zeigen und erklären, was sie sich darunter vorstellt, welche Daten in dieses Feld gehören und was Sie denkt, wie das Programm reagiert, wenn man diesen Button drückt.

Machen Sie den Test auch mit Teilen des Programms, die Sie als trivial ansehen. Endanwender haben oft eine ganz andere Sicht, als ein Entwickler. Sie werden überrascht sein, daß manche Felder oder Buttons mißverständlich sein können.

Und jetzt?

Jetzt sind Sie dran! Ich hoffe, dieser kleine Artikel hat ihnen geholfen und einen Einblick in die Problematik des Interface-Designs geschaffen. Benutzerfreundlichkeit wird immer wichtiger, je mehr Anwender ins Web gehen.
Webbrowser sind uns bei dieser Mission leider nicht dienlich. Die Möglichkeiten von HTML sind zu beschränkt. Ein Ausweg wäre, Java zu verwenden. Doch durch die langsame Ausführung der Programme scheidet Java aus. Eine andere Möglichkeit wäre Macromedia Flash. Hier kann der Interface-Designer die Programmoberfläche komplett frei gestalten. Also auch mit Drag-&-Drop und allen anderen Konzepten. Über XML lassen sich Daten dann mit dem Server austauschen. Und das Plug-In ist mittlerweile für alle wichtigen Plattformen verfügbar, sogar für Linux und Handhelds.
Eine richtige Lösung wäre aber ein neuer Browser. Ein Browser nur für Webapplikationen. Ein Browser mit Menüleisten, Dialogboxen und Drag-&-Drop. Ein Applikations-Browser. Bis dahin wird es noch eine ganze Zeit brauchen. Aber wer weiß, vielleicht haben wir eines Tages ein wirklich benutzerfreundliches Web.

Bücher

Jeff Johnson: “GUI Bloopers”, Morgan Kaufmann (2000), ISBN: 1558605827
Kevin Mullet, Darrell Sano: “Designing Visual Interfaces”, Prentice Hall PTR (1994), ISBN: 0133033899
Hugh Beyer, Karen Holtzblatt: “Contextual Design”, Morgan Kaufmann (1997), ISBN: 1558604111
Vanessa Donnelly: “Designing Easy-to-use Websites”, Addison Wesley (2000), ISBN: 0201674688