Follow my new blog

Samstag, 5. April 2008

UI-first Design ganz ohne schlechtes Gewissen

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:

image

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:

image

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:

image

image

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.

Kommentare:

Thomas Schissler hat gesagt…

Ralf, ich kann dir hier 100% zustimmen. Das deckt sich auch mit unseren Erfahrungen. Es ist leider nicht üblich die UI als Teil der Architektur zu sehen. Ich sehe auch die UI als besonders geeignet, die Funktionalität einer Anwendung zu definieren. Schön, dass diese Meinung nun auch prominent vertreten wird.

Christian Kesselheim hat gesagt…

Sehr gut und auf den Punkt; insbesondere die Interpretation der UI als Struktur der Schnittstelle zwischen dem Client "Anwender" und der Komponente "Anwendung" finde ich gelungen. Ein Grund, warum Jeffs Skizze vielleicht etwas "statisch" und zweideutig erscheinen mag ist der Umstand, das meiner Erfahrung nach solche frühen UI Prototypen oft in Kundenworkshops als Hilfsmittel zum verbalen "Durchspielen" der von der Anwendung zu unterstützenden Anwendungsfälle dienen (welche dann anderweitig festgehalten werden). So aus dem Kontext gerissen (bzw. als allein stehende, eindeutige Spezifikation) reichen sie damit natürlich nicht aus. In wie weit verwendest du selbst Papierprotoypen bzw. greifst auf softwaregestützte Werkzeuge zurück? Ich selbst empfinde je nach Szenario und Umfang der Anwendung die Papierversion als recht "wartungsintensiv".

Ralf Westphal - One Man Think Tank hat gesagt…

@Christian: Ich verwende vor allem Visio- oder Flipchart-Skizzen. Aber letztlich ist das abhängig vom Kunden und vom Szenario und vom Zweck.

In meinem Architekturworkshops und bei Beratungen zum Thema Modellierung gehts ja nicht um Usability oder Aussehen. Paperprototypes wären da also Overkill. Wichtig ist da nur soviel Detail/Vorstellungsvermögen, dass wir auf die wichtigen Trigger kommen.

Beim Gespräch mit Anwendern ist das dann aber durchaus anders. Da wollen Georg, Maria und Sebastian als die personae des Anwendungsszenarios (bzw. ihre realen Vertreter) möglichst konkrete Darstellungen. Papier ist da ein schön formbares Mittel - wenn auch etwas am Bildschirm noch realistischer ist. Aufwand und Nutzung sind abzuwägen. Warum nicht mit dem einen anfangen und dem anderen weitermachen.

-Ralf

Alexander Zeitler hat gesagt…

Dem Posting kann ich insgesamt nur zustimmen.

Bei einer aktuell in der Entwicklung befindlichen - eigentlich recht kleinen Applikation - bin ich genau diesen Weg gegangen.

Die Problematik, die richtigen Trigger und Methoden zu finden, lässt sich damit sehr gut lösen.

Allerdings bin ich den Weg über Visio / Word gegangen - einfach um auch diese Infos im TFS versionieren und als WorkItems verwalten zu können.

Als Alternative könnte ich mir auch OneNote vorstellen.

Notebooks hat gesagt…
Der Kommentar wurde von einem Blog-Administrator entfernt.