Irgendwo dort draußen ist ein Team gerade dabei, eine Anwendung mit einer erstaunlichen, nie zuvor gesehenen Funktionalität zu entwickeln. Und um in den Genuss dieses atemberaubenden, bahnbrechenden Features zu kommen, werden die User sich einloggen müssen.
Nun ist eine Login-Funktionalität wiederum weder neu noch sonderlich beeindruckend und die Umsetzung wahrlich keine große Herausforderung. Doch Teams realisieren diese Funktion häufig so, als hätte dies noch nie zuvor jemand getan.
Das ist natürlich nicht der Fall. Überall auf der Welt bauen Teams Logins in ihre Anwendungen ein, millionenfach. Und hier kommen wir und fangen noch einmal ganz von vorne an.
Dieses Immer-wieder-Neuerfinden ist nicht nur ineffizient, es stellt die Teams auch vor weitreichende Probleme. Das Umsetzen eines Login-Bereichs ist nicht unbedingt der sexyeste Teil der Anwendungsentwicklung. Leider wird diesem Job oft entsprechend wenig Aufmerksamkeit geschenkt. Die Ergebnisse sind nicht selten unbrauchbar und führen zu frustrierenden Nutzererlebnissen.
Hier kommt das Dreigestirn der Wiederverwertung ins Spiel: Muster, Komponenten und Interaktionsdesign-Frameworks.
Mehr von kleinen Teams erwarten
Heute erwarten Unternehmen mehr von jedem Team und Projekte sind anspruchsvoller als je zuvor. Agile Entwicklungsmethoden zwingen Teams, sich darüber Gedanken zu machen, wie sie Sachen nutzen können, die bereits vorhanden sind. Wiederverwertung gewinnt an Priorität.
Wir beobachten, dass die besten Teams einer Wiederverwertungsstrategie folgen, die auf drei, nennen wir es Sammlungen, basiert: Muster, Komponenten und Interaktionsdesign-Frameworks. Diese Sammlungen verleihen dem Team Geschwindigkeit und Effizienz, denn es kann aus dem reichen Fundus bereits implementierter Elemente schöpfen.
Wir sehen auch immer wieder, dass die Teams, die diese Strategie anwenden und verfeinern, fühlbaren Nutzen davon haben: Sie kommen schneller zu kompletten Prototypen mit allen kleinen Nuancen und Details, die für großartige Nutzererlebnisse wichtig sind. Die Anwendungen entsprechen eher den Erwartungen der User, weil Teams die Entwürfe immer in ihrer Gesamtheit und unter Konsistenz-Gesichtspunkten betrachten. Außerdem können Teams ihre Prototypen problemlos und vor allem häufig verändern, während die Applikation sich noch in einem formbaren Stadium befindet.
Muster, Komponenten und Interaktionsdesign-Frameworks spielen tragende, essenzielle Rollen bei der Wiederverwertung.
Muster: Ein Katalog für Verhaltensweisen
Muster, inspiriert von den architektonischen Mustern des Christopher Alexander, sind zuerst auf der Bildfläche erschienen. Alexander hat seinerzeit die Verhaltensweisen der Menschen im täglichen Leben und bei der Arbeit beobachtet und wiederverwendbare Beschreibungen davon entwickelt, wie Gebäude diese Verhaltensweisen unterstützen können. Diese Muster sollen einen Architekten nicht beschränken, vielmehr liefern sie ihm wertvolle Anhaltspunkte darüber, ob er wirklich an alles gedacht hat.
Mit den Mustern, von denen wir sprechen, verhält es sich ähnlich. Ein Beispiel: Nehmen wir an, ein User möchte bei einer Reservierung ein Datum eingeben. Welche Möglichkeiten haben nun wir, um diesen Prozess abzubilden und zu unterstützen? Eine formlose Textbox mit einem Parser? Drei Eingabefelder für Tag, Monat und Jahr? Ein Kalender-Pop-up, in dem das gewünschte Datum nur angeklickt werden muss?
Jede der drei Möglichkeiten ist sozusagen eine entwicklungsspezifische Antwort auf ein und dieselbe Verhaltensweise. Wenn das Team sich entschieden hat, welche Möglichkeit am besten geeignet ist, kodiert es diese in ein Muster. Teams, die später wiederum eine Reaktion auf eine solche Verhaltensweise finden müssen, können nun das vorhandene Element einsetzen, das sich bereits bewährt hat und die Nutzererwartungen erfüllt.
Viele Teams, die ihre Sammlungen ausstatten, nutzen Musterbibliotheken von der Stange, von denen es etliche am Markt gibt. Diese sind zwar häufig gut dokumentiert und billig (einige sind sogar Open Source und kostenlos), dafür aber weniger hilfreich, als es zunächst den Anschein hat: Sie bilden allgemeine Lösungen ab und tragen den spezifischen technologischen Beschränkungen des Projektes und den Geschäftsanforderungen kaum Rechnung. Wirklich nützliche Mustersammlungen dagegen konzentrieren sich auf solche Beschränkungen und Anforderungen.
Komponenten: Die Vorteile wiederverwendbarer Codes
Während wir unsere Musterbibliotheken zusammenstellten, wurde rasch ein neues Bedürfnis ersichtlich: Die Entwickler benötigten eine einfache Methode, um spezifischen Code wiederzuverwenden.
Haben wir ein Muster ausgewählt, das einem speziellen Nutzerverhalten entspricht, müssen wir über die tatsächliche Umsetzung nachdenken. Wenn wir unseren Pop-up-Kalender nehmen, müssen wir dafür sorgen, dass er funktioniert: Das Datum soll auf dem Bildschirm erscheinen, der Kalender muss auf Anklicken reagieren, es soll erkennbar sein, dass die Funktion Bestandteil der Anwendung ist.
An diesem Punkt treten Komponenten auf den Plan. Eine Komponente transferiert die Antwort auf eine Verhaltensweise auf die Pixel-Ebene, sie drückt in Form ihres Codes ein spezifisches Interaktionsverhalten aus. Zudem beinhaltet sie die wesentlichen visuellen Elemente wie Schriftsatz, Farbe und Aussehen.
Entwickler nutzen diese Komponenten, um die Spezifika des Entwurfs zusammenzusetzen. Einmal fertiggestellt, ist eine Komponente ein gebrauchsfertiges Element, das ganz einfach in jeden neuen Bildschirm eingebaut werden kann. Dies beschleunigt den Entwicklungsprozess von den frühen Prototypen bis hin zur ausgereiften Anwendung signifikant.
Interaktionsdesign-Frameworks: Das Puzzle zusammensetzen
Interaktionsdesign-Frameworks, erdacht vom Entwickler Robert Hoekman, sind das jüngste Mitglied in unserem Dreiergespann. Während Komponenten sich mit den Details einzelner Muster beschäftigen, bilden Frameworks Gruppen von Mustern ab und fügen sie zu einem größeren Bild zusammen.
Frameworks beschreiben ganze Subsysteme von Mustern. Ein Login-Subsystem benötigt beispielsweise ein Muster für die Eingabe von Benutzernamen und Passwort, nötig sind aber auch Muster für die Passwort-vergessen-Funktion, für die Registrierung eines neuen Benutzernamens, für die Änderung der Zugangsdaten usw.
Teams erstellen diese Frameworks, indem sie sich ansehen, wie andere Anwendungen eine Herausforderung gemeistert haben. Sie funktionieren quasi wie Checklisten und helfen dem Team, diejenigen Muster zu identifizieren, die nötig sind, um anzufangen.
Frameworks sind sehr abstrakt. Sie sagen nichts über das Erscheinungsbild oder Design-Spezifika aus. Diese Aufgabe erfüllen die Komponenten, die auf den einzelnen Mustern basieren.
Die Verantwortung verteilen
Der hohe Nutzen der Wiederverwertung ist nicht ganz umsonst zu haben. Es sind Zeit und Erfahrung nötig, um die wiederverwendbaren Elemente zu identifizieren. Die Dokumentation dieser Elemente ist nicht weniger zeitaufwändig. Die Aktualitätspflege der Sammlungen bindet Ressourcen dauerhaft und langfristig.
Der Aufwand lohnt sich jedoch, und zwar insbesondere dann, wenn er auf mehrere Schultern verteilt wird.
Weil die Komponenten eng an die tatsächliche Entwicklungsarbeit gekoppelt sind, sind hierfür zumeist auch die Programmierer zuständig. Bei Interaktionsdesign-Frameworks geht es dagegen um die ganzheitliche Erfahrung und um das Gesamtbild – dieser Teil sollte im Verantwortungsbereich von Konzeptionern und Designern liegen. Für die Muster-Sammlung sind in der Regel Konzeptioner, Designer und Entwickler gleichermaßen verantwortlich.
Während kleine Unternehmen ihre Sammlungen noch mit vergleichsweise geringem Aufwand pflegen können, müssen größere Firmen damit rechnen, dass sie dafür einen Vollzeitmitarbeiter benötigen werden. Dessen Aufgabe besteht vor allem darin, Teammitglieder anzuregen, den Sammlungen neue Elemente hinzuzufügen bzw. vorhandene Elemente aktuell zu halten: Die Sammlungen bilden eine wertvolle Ressource, von der alle profitieren; deshalb sollte sich auch das gesamte Team an ihnen beteiligen.
Dies verhindert, dass einer einzigen Person die gesamte Verantwortung aufgelastet wird, und hat den Nebeneffekt, dass die Team-Mitglieder ständig an das Vorhandensein und die Verfügbarkeit dieser Ressource erinnert werden.
Tolle Ergebnisse auf dem Weg des geringsten Widerstandes
Sind sie erst einmal erarbeitet, bergen Muster-, Komponenten- und Framework-Bibliotheken ein enormes Potenzial, denn sie erneuern den gesamten Entwicklungsprozess und beschleunigen Projekte. So nehmen Sie den Weg des geringsten Widerstandes und liefern dabei hervorragende Anwendungen ab.
Dieser Artikel wurde im Original am 20. Mai 2009 unter dem Titel „Components, Patterns, and Frameworks! Oh My!“ von Jared M. Spool veröffentlicht. Jared M. Spool gehört zu den führenden Usability-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.uie.com. Weitere Artikel von Jared M. Spool finden Sie im Usability-Special von //SEIBERT/MEDIA.
