Endlich sagt es mal einer deutlich: Softwareentwicklung beginnt beim UI. Jeff Atwood spricht es in seinem Coding Horror Blog deutlich aus: Programmierung ist "UI-First Software Development". Zwar wussten wir das irgendwie schon seit 17 Jahren - aber es ist gut, wenn es endlich auch mal jemand so deutlich sagt. Microsoft hat es uns zwar im Grunde nie anders demonstriert - von VB 1.0 bis WPF, AJAX und Silverlight. Aber ein Unbehagen blieb dennoch. Denn seit mindestens 10-12 Jahren gibt es auch genügend Stimmen, die immer wieder mahnen, dass das UI nicht so wichtig sei, dass man damit doch nicht die Softwareentwicklung beginnen solle. Ja, ja, ja... aber... hm...
Diese Unsicherheit löst sich auf, wenn wir das unselige Akronym RAD ersetzen durch RUID. Denn was VB 1.0 und Delphi und WinForms und Expression usw. bieten, ist nicht Rapid Application Development. Rapidly kann man damit zwar arbeiten - aber RAD war nie (!) dazu gedacht, bei der Architektur zu helfen. Design von Strukturen - denn dafür könnte das D in RAD auch stehen - war nie Sache der RAD-Tools. Nur das visuelle Design, die Oberfläche war gemeint. Eigentlich. Doch dann hat jemand zwischen R und D ein A für Application gesetzt und damit das Kind in den Brunnen geworfen. Bei RAD sollte es um alles gehen, um ganze Anwendungen.
Damals mögen Anwendungen vielleicht noch entweder so simpel gewesen sein, dass man keine weitere Struktur gebraucht hat als die, die sich durch Platzierung von Steuerelementen und Auswahl ihrer Events ergab. Oder Anwendungen waren doch kompliziert, wobei das wirklich Komplizierte sich jedoch in einem DB-Server abspielte und nicht weiter vom Entwickler "designt" werden musste. Was blieb war der (kleine) Anteil der Applikation, mit der der Benutzer interagiert.
Letztlich ist es aber einerlei. RAD für mehr als eine Hilfe beim Entwurf des Aussehens (!) einer Anwendung anzusehen, war immer schon falsch oder zumindest ein Missverständnis. Und das wurde eigentlich auch relativ bald bemerkt. Dadurch geriet dann RAD bzw. das UI in Verruf. Schade. Denn in einer Hinsicht hatte die missverstandene RAD-Botschaft Recht: Das UI muss am Anfang der Softwareentwicklung stehen. Ja, "muss", denn das UI ist ein Kontrakt.
UI-first für den Kunden
Jeff bringt es auf den Punkt: "Remember, to the end user, the interface is the application." Für den Kunden ist Software vor allem durch das UI greifbar. Von dem, was dahinter steht, hat er noch weniger eine Vorstellung als von dem, was hinter einem Armaturenbrett ein Auto wirklich ausmacht. Wo aber Unwissen herrscht, da ist Unsicherheit nicht weit. Und Unsicherheit ist wiederum der beste Nährboden für Konflikte. Wer also Konflikten aus dem Weg gehen möchte, der versuche nicht, den Kunden über die Interna der von ihm bestellten Software aufzuklären. Solche Wissensvermittlung kommt schnell an ihre Grenzen und interessiert den Kunden auch nicht wirklich. Er empfindet sich als vom Wesentlichen ablenkende Belehrung. Viel effektiver beugen Sie Konflikten vor, indem Sie mit dem Kunden darüber reden, wozu er einen unmittelbaren Bezug hat: das UI.
In einem Projekt möglichst früh mit dem Kunden ausführlich über das UI zu sprechen, ist aber nicht nur eine vertrauensbildende Maßnahme und beugt Konflikten vor, sondern hat darüber hinaus konkreten Nutzen. Die Arbeit am UI definiert nämlich den wesentlichen Kontrakt zwischen Mensch und Software. Ohne hohe Usability ist alle grundsätzlich vorhandene Funktionalität nutzlos. Das werden Sie bestätigen, wenn Sie schon einmal in einem Land waren, dessen Sprache Sie nicht beherrschten, und dort in einem guten Restaurant speisen wollten. Solange das Restaurant die Menükarte nicht in einer Ihnen verständlichen Sprache bereitgehalten hat, war sein guter Service für Sie nutzlos oder zumindest nicht kontrollierbar. Die Usability des Restaurants war bei aller Qualität seiner "Funktionalität" niedrig.
Damit Ihrem Kunden das nicht mit Ihrer Software passiert, sollte UI-Design am Anfang der Implementierung stehen. Um den Aufwand dafür klein zu halten, hat Jeff dafür z.B. Papierprototypen vorgeschlagen:
Quelle: Jeff Atwood, www.codinghorror.com
Ob Sie nun aber Papier benutzen oder Powerpoint oder Visio oder andere Demowerkzeuge, das ist egal. Hauptsache der Kunde bekommt möglichst früh das Gefühl, das am Ende Ihrerer Arbeit wirklich benutzbare Software herauskommt. Und Sie bekommen möglichst schnell ein Gefühl dafür, was der Kunde wirklich will. Denn Kunden können meist nicht gut abstrakt beschreiben, was Sie sich wünschen. Dafür sind sie jedoch sehr gut darin zu erkennen, ob etwas so ist, wie sie es sich vorgestellt haben. Mit einem UI-Prototypen nun geben Sie Ihrem Kunden etwas zum Erkennen. Die Software wird für ihn greifbar. Und das auch noch sehr früh und für Sie quasi ohne Risiko.
UI-first Design reduziert also Konfliktpotenzial, dient dem Verständnis beider Seiten, was eigentlich zu erreichen ist, verspricht höhere Usability und reduziert den Frust durch Änderungen später im Software-Lifecycle. Damit aber nicht genug...
UI-first für den Entwickler
Der Nutzen von UI-first Design reicht über Vertrauensbildung, Anforderungsverfeinerung und Usability-Steigerung hinaus. Wichtig beim UI ist nämlich nicht nur das Aussehen und die grundsätzliche Dienstleistung, wichtig sind die Trigger, der Event-Fluss, die konkreten Funktionen, die ein Benutzer anstößt. Das UI ist nicht nur ein Kontrakt mit dem Kunden, der menschenlesbar beschreibt, was wie getan können werden soll mit einer Software. Das UI ist auch ein maschinenlesbarer Kontrakt innerhalb der Software. Genau wie ein Kontrakt zwischen zwei Komponenten:
Während ein "normaler" Komponentenkontrakt allerdings meistens aus Interfaces besteht, definiert den UI-Kontrakt meist ein WinForms-Formular. Seine Eventhandler-Methoden beschreiben die Funktionalität eines Dialogs. Interaktionen mit dem Benutzer finden immer über solche Methoden statt, die der Benutzer durch Tastendrücke oder Mausaktionen oder auch Spracheingabe triggert.
Was eine Service-Komponente nun für Funktionen bieten sollte, bestimmen ihre "Kunden". Im vorstehenden Bild ist der "Kunde" von M die Komponente L. Der Kunde von L ist K, der von K... ist der Benutzer. Die Funktionalität von M, ihre Funktionen sind damit mittelbar abhängig vom... Benutzer. Wenn Sie effizient arbeiten wollen, d.h. nicht potenziell unnötige Funktionalität in M implementieren möchten, dann tun Sie gut daran, die Kontraktdefinition nicht mit M zu beginnen, sondern mit L, nein, mit K, also dem UI. Denn aus den Funktionen des UI ergibt sich erst, welche Leistungen K von L benötigt. Und daraus ergibt sich erst, welche Leistungen M bieten muss. Lean Software Development entwickelt nur das, was unbedingt nötig ist. Das aber finden Sie heraus, indem Sie Ihren Entwurf beim Benutzer mit dem UI beginnen.
Dafür ist eine gestaltungsorientierte Darstellung wie sie Jeff sie skizziert hat eigentlich schon zu detailliert. Vor allem ist sein Bild zu statisch. Es zeigt nur einen Schnappschuss des Zustands eines UI. Funktionalität im Sinne von "Was kann ich jetzt tun?" ist daraus nur mühsam ablesbar.
Deshalb sollten Sie beim UI-first Design nicht nur über die Gestaltung sprechen, sondern auch die Interaktionsmöglichkeiten explizit festhalten. Welche Funktionen stehen einem Anwender zur Verfügung? Das Programm von Jeff erlaubt einem Anwender anscheinend, sich zu authentifizieren und etwas zu suchen. Der rote Login-Dialog liegt allerdings nur platt auf der Suchmaske. Welche Trigger dieser Kontrakt bietet, ist nicht zu erkennen. Hier zwei Beispiele, wie die Skizze von Jeff verstanden werden könnte:
Der "maschinenrelevante" Kontrakt des UI besteht danach vor allem aus den Funktionen:
- Open() des Hauptfensters bzw. des Login-Dialogs
- Login() für die Anmeldung
- Search() zum Suchen
Mit diesen Funktionen (für ein K) in der Hand kann nun die Frage gestellt werden, welche Funktionen nachgeschaltete Komponenten (wie L und M) bieten sollten.
Ohne ein explizites UI-Design würde solche Überlegung viel schwerer fallen. Sie müssten dafür quasi in die Glaskugel blicken. Sie könnten nur spekulieren, was von einer Komponente wie M oder L gefordert sein könnte. Das ist bottom-up oder inside-out Entwicklung, die leicht zu sehr allgemeinen Lösungen führt - und damit unnötig ineffizient ist.
Outside-in, d.h. beim UI beginnend, kommen Sie zu Kontraktdefinitionen mit minimal nötiger Funktionalität. Das ist produktiv.
UI-first Design dient nicht nur weichen Faktoren wie Usability oder Vertrauen, sondern harter Architektur. Wenn Sie mit dem UI beginnen, müssen Sie in Zukunft also kein schlechtes Gewissen mehr haben. Allerdings sollten Sie auch nicht mehr tun, als hier beschrieben. Das UI ist nicht die Applikation, sondern die Applikation hat nur eine dünne UI-Schale.