Benutzeroberflächen sind das für die Nutzer sichtbare Ergebnis unseres Projektes. Zum einen unterstützt die Benutzeroberfläche Abläufe innerhalb von Geschäftsprozessen des Unternehmens. Auf der anderen Seite stellen die Daten, die mithilfe der Benutzeroberfläche erfasst werden, einen hohen Wert für die Nutzer und das Unternehmen dar. In der Benutzeroberfläche einer Anwendung steckt daher ein enormes Wissen. Dieses Wissen gilt es zu sichern.

In einem Layout beschreiben wir die Gestaltung und die Struktur der Benutzeroberfläche. Layouts benötigen wir bereits vor dem Start des Sprint in der geforderten Qualität. Mit bestimmten Typen von Layouts wird bereits in der Analyse der Versuch unternommen, wiederverwendbare Elemente der Benutzeroberfläche zu identifizieren. Teilbereiche der Benutzeroberfläche erfassen wir als Layouts vom Typ Panel. Der Designer der Benutzeroberfläche gibt dem Entwickler damit frühzeitig den Hinweis, dass es Potential für eine wiederverwendbare Software-Komponente gibt. Weitere Bausteine für eine geplante Wiederverwendung sind Layouts vom Typ Prompt und Widget.

Motivation

Im Zusammenhang mit der Spezifikation von Benutzeroberflächen der Anwendung unterscheiden wir Layouts und Manuals. Beide Artefakte haben das Ziel, die Benutzeroberfläche zu beschreiben.

Beispiel Beschreibung im Layout Beschreibung im Manual
Eingabe eines Wertes Im Layout legen wir fest, dass es ein einzelnes Feld mit freier Eingabe ist. Wir definieren die erlaubten Zeichen und die maximale Anzahl der Zeichen. Im Manual legen wir je Anwendungsfall fest, welche Werte fachlich gültig sind. Wir legen auch fest, dass bei Fehleingaben eine Fehlermeldung angezeigt wird.
Eingabe eines Datums Im Layout beschreiben wir das Datumsformat, ob eine freie Eingabe erlaubt wird und welcher Dialog aufgerufen wird, um eine Datum aus einem Kalender zu wählen. Im Manual legen wir je Anwendungsfall fest, in welchem Bereich das Datum eingegeben wird. Auch Abhängigkeiten zwischen Feldern (z.B. die Grenzen eines Intervalls) erklären wir hier.
Eingabe einer Entscheidung Im Layout legen wir fest, dass wir eine Gruppe von Umschaltern mit einem gemeinsamen Titel verwenden. Im Manual legen wir je Anwendungsfall fest, welche Wahlmöglichkeiten zulässig sind.

Im Grunde genommen muss sich der Analyst beim Schreiben von Layout und Manual eine Frage stellen: Muss das ein Nutzer wissen? Wenn diese Frage mit ja beantwortet wird, gehört diese Information ins Manual. Auf der anderen Seite wird für ein Layout ganz klar und eindeutig festgelegt, was der Analyst beschreiben muss, um das Dokument «ready» für die Entwicklung zu bekommen. Die Zielgruppe für ein Manual ist daher ganz klar der Nutzer, während die Zielgruppe für ein Layout das cross-funktionale Team ist.

Für das Schreiben einer Layout-Seite gibt es ein praxistaugliches agiles Vorgehen:

  1. Vor dem Sprint legen wir ein Layout mit Mockup an. In der Beschreibung vermitteln wir grob den Wert dieser Benutzeroberfläche für den Nutzer.
  2. Im Layout beschreiben wir die Elemente und deren Initialisierung. Die  Validierung beschreiben wir nur dort, wo sie sich nur auf ein Element alleine bezieht.
  3. Wir legen für jeden Anwendungsfall, der durch die Akzeptanzkriterien in der User-Story gefordert wird, ein Manual an und beschreiben dort aus Sicht des Nutzers die besonderen Randbedingungen für die Verwendung der Benutzeroberfläche.
  4. Im Sprint klären wir während der Entwicklung weitere Details und aktualisieren das Layout und die Manuals. Ebenfalls als Teil der Manuals beschreiben wir die feld-übergreifenden Validierungen.

Am Ende des Sprints haben wir mit diesem Vorgehen ein fertiges Layout mit einem Manual je realisiertem und getesteten Anwendungsfall. Die Kombination aus Layout und Manuals ergibt eine vollständige Beschreibung der Struktur und des Verhaltens der Benutzeroberfläche. Aus diesem Ansatz ergeben sich für das cross-funktionale Team eine Reihe von Vorteilen.

  • Wir vermeiden redundante Inhalte.
  • Wir können ein Layout vor dem Start des Sprints in ausreichender Qualität bereitstellen. Während des Sprints sind im Layout nur Fehlerkorrekturen aufgrund des Feedback der Entwickler notwendig.
  • Wir erstellen Manuals als Entwurf des Benutzerhandbuches während des Sprints mit Hilfe der “echten” Anwendung. Entwickler und Tester verwenden die Manuals daher frühzeitig und validieren automatisch die Beschreibungen.
  • Wir können uns bei der Erstellung von Testfällen von Beginn an auf die Manuals beziehen. Manuals haben daher für einen Tester einen hohen Wert.

Am Ende des Sprints haben die Entwickler das Layout der Benutzeroberfläche realisiert und die Tester mit der Erstellung der Testfälle die Manuals dazu fertiggestellt.

Mockup

Entwickler erhalten durch das Mockup die Idee für die Gestaltung der Benutzeroberfläche. Die Aufgabe des Entwicklers ist es, diese Idee in der gegebenen Architektur und unter Berücksichtigung des aktuell gültigen Style-Guides umzusetzen. Durch die Verwendung von Mockups sind wir im Projekt in der Lage, ein Layout als Ganzes darzustellen, ohne Gefahr zu laufen, dass in der Zwischenzeit eine Änderung im Style-Guide dazu führt, dass das Layout “verdirbt” und überarbeitet werden muss.

Ein Mockup ist eine realitätsnahe Darstellung der Benutzeroberfläche und vermittelt das look and feel!

Realitätsnah bedeutet in diesem Zusammenhang, dass wir erkennen können, in welcher Architektur wir uns bewegen, ohne aber zu sehr ins Detail zu gehen. Anders gesagt: Ein Screen für eine mobile Anwendung würde sich auf jedem Fall von einem Dialog einer Desktop-Anwendung unterscheiden. Wir machen aber keinen Unterschied, ob wir nun die Desktop-Anwendung mit web-basiert mit JSF oder klassisch mit JavaFX machen. Dadurch behalten die Entwickler eine gewisse Freiheit bei der technischen Umsetzung. Diese Freiheit geht so weit, dass es möglich ist, die technische Umsetzung zu ändern. Ein gutes Beispiel ist der Umstieg von Swing auf JavaFX bei einer Desktop-Anwendung. Ich denke, dass es viele Gründe für diesen Wechsel gibt. Es wäre aber eine große Einschränkung für die Entwicklung, wenn die Benutzeroberfläche in JavaFX exakt gleich ausschauen muss wie die existierende Umsetzung mit Swing.

Auch die Gestaltung und die Farbe der Steuerelemente und Bilder ist nicht endgültig festgelegt und lässt genügend Spielraum, um beispielsweise einen Grafiker während der Entwicklung zu beauftragen, ein durchgängiges Farbschema und gut gestaltet, “coole” Icons zu entwerfen. Gleichzeitig können wir aber den Stakeholdern schnell und ausreichend genau einen Eindruck von der geplanten Benutzeroberfläche vermitteln.

Ein wesentlicher Vorteil eines Mockup gegenüber einem Screenshot ist die Möglichkeit, jede fachliche Situation in der Benutzeroberfläche darstellen zu können. Das gilt auch für Situation, die in der echten Anwendung nur mit sehr großem Aufwand herzustellen ist oder nur kurze Zeit existiert.

Definition

Beschreibung

In einem Layout beschreiben wir die Gestaltung und die Struktur der Benutzeroberfläche. Es ist ein Überbegriff für eine ganze Reihe von Typen, die es in einer ganzen Reihe spezialisierter Ausprägungen gibt:

  • Layouts vom Typ Screen, Client, Window oder Dialog beschreiben vollständige Ansichten einer Benutzeroberfläche einer Anwendung, z.B. Fenster eines Rich-Client, Seiten eines Web-Clients oder Ansichten einer mobilen App. In komplexen Anwendungen sind sie häufig nur “Container” für eine Zusammenstellung von Layouts vom Typ Panel.
  • Ein Layout vom Typ Panel hingegen unterstützt den Versuch, Teile der Benutzeroberfläche von Anfang an wiederverwendbar zu gestalten. Panels sind daher ein wichtiges Werkzeug zur Durchsetzung eines gemeinsamen Stils und einheitlichem Verhalten in der Benutzeroberfläche. Panels sind immer Teil eines Style-Guides.
  • Für wiederverwendbare Standard-Dialoge gibt es das Layout vom Typ Prompt. Die vereinfachte Beschreibung erlaubt nur die Verwendung eines von mehreren Piktogrammen, einen Text aus einem Meldungskatalog und eine begrenzte Menge an Schaltflächen. Prompts sind immer Teil eines Style-Guides.
  • Systemspezifische Steuerelemente werden in einem Layout vom Typ Widget beschrieben und verfolgen wie Layouts vom Typ Panel das Ziel, einen gemeinsamen Stil und einheitliches Verhalten in der Benutzeroberfläche durchzusetzen. Widgets sind immer Teil eines Style-Guides.

Allen Typen von Layouts ist gemeinsam, dass sie die Gestaltung, die Struktur und die “Mechanik” einer Benutzeroberfläche beschreiben. Im Wesentlichen geht es dabei um die Festlegung, wie ein Element der Benutzeroberfläche realisiert (um welche “Art” von Element handelt es sich) und initialisiert (u.a. der Tooltip) wird und wie das grundsätzliche Verhalten des Elementes ist.

Bei der Erfassung bekommt jedes Element eine eindeutige Bezeichnung (ID), einen Namen, ein Icon (optional) und eine Beschreibung. Die ID eines Elementes verwenden wir im weiteren Verlauf für die eindeutige Referenzierung eines Elementes in den folgenden Abschnitten, auch für Querverweise. Dort beschreiben wir die Struktur, die Initialisierung und die Validierung für die Elemente in den Kategorien “Menü”, “Felder” und “Schaltflächen”.

Zur Visualisierung der Layouts verwenden wir generell Mockups. Der Stil eines Mockups gleicht in etwa einer Bleistiftzeichnung. In der Praxis können wir durchaus auch Bilder von handgefertigten Zeichnungen auf Flip-Charts oder vergleichbaren Medien aus Workshops verwenden.

Struktur

Abschnitt Beschreibung

Der Abschnitt soll den Lesen einen groben Überblick über den Verwendungszweck dieses Elements der Benutzeroberfläche geben.

 

Abschnitt Entwurf

Der Abschnitt  enthält eine grafische Darstellung (z.B. Mockup, Wireframe, Foto aus der Design-Session) , die die Idee für die Gestaltung der Benutzeroberfläche vermittelt. Wo die bildhafte Darstellung nicht klar ist, werden entsprechende Hinweise in Textform inklusive Verlinkung zu anderen Seiten gegeben.