Bausteine für Benutzeroberflächen (1)

Feature | 25. November 2004 von admin 0

Beim Entwurf der Benutzeroberfläche (User-Interface, UI) einer Unternehmenssoftware sehen sich Entwickler mit zahlreichen Fragen konfrontiert. Sollen sie Symbole (Icons) verwenden? Wo sind die Kopfdaten und wo die Detaildaten zu platzieren? Wie suchen Anwender nach Objekten oder Daten? Wie sollen neue Zeilen in eine Tabelle eingefügt werden? Aus welchen Arbeitsbereichen soll ein Bild aufgebaut werden?
Die richtigen Antworten auf all diese Fragen zu finden ist nicht leicht. SAP setzt bei der Entwicklung von Benutzeroberflächen daher auf vordefinierte “Grundrisse” (Floor Plans), die durch wieder verwendbare generische “User-Interface-Patterns” gefüllt werden. Im Rahmen eines anwenderzentrierten Design-Prozesses (“User-Interface First”) entwerfen Entwickler – unterstützt durch geeignete Entwicklungswerkzeuge – Geschäftsanwendungen und konfigurieren deren Benutzeroberfläche mit Hilfe vordefinierter Bausteine.

Der Pattern-Ansatz bei SAP

Wieder verwendbare Bausteine, “Patterns”, sind nichts Neues in der Software-Entwicklung und beim Entwurf von Benutzeroberflächen. Gemäß der Definition der Design-Experten Douglas van Duyne, James Landay und Jason Hong vermitteln sie Einblicke in Design-Probleme, indem sie das jeweils Wesentliche einer Fragestellung und ihrer Lösung in kompakter Form erfassen. Ein bekanntes Beispiel hierfür ist der Einkaufswagen bei Online-Shops, in dem Anwender die gewünschten Waren vor der Bestellung sammeln können.

Das UI-Pattern-Konzept

Das UI-Pattern-Konzept

Der Pattern-Ansatz bei SAP zeichnet sich durch zwei Besonderheiten aus. Zum einen trennt er die Beschreibung einer Aufgabe, die ein Anwender in der Software ausführt, und ihre Abbildung auf der Benutzeroberfläche. Diese Trennung hat den Vorteil, dass die Grundrisse und Bausteine entsprechend dem herrschenden Design-Paradigma und den Besonderheiten des Endgeräts – großer Monitor am PC oder kleiner Monitor am PDA – gestaltet werden können. Zum anderen funktioniert der Ansatz nur, wenn für allgemein gültige, so genannte “generische” Aufgaben generische User-Interface-Lösungen gefunden werden – ein Baustein soll ja für viele Anwendungen verwendet werden. Sowohl die Aufgaben als auch die Elemente der Benutzeroberfläche lassen sich geschachtelt in einer “Dekompositionshierarchie” abbilden, das heißt, einfachere Elemente lassen sich zu komplexeren zusammenstellen.
Eine solche generische Aufgabe ist beispielsweise die “Suche nach einem Arbeitsobjekt”. Hierbei spielt es keine Rolle, ob es sich um eine Bestellung, Lieferung, einen Rechnungsbeleg oder um Material handelt. Die allgemeine Annahme lautet: Wenn generische Aufgaben für eine bestimmte Zahl von Geschäftsprozessen gleichartige Eigenschaften aufweisen, lässt sich auf der Benutzeroberfläche eine einheitliche Lösung finden. So stellt eine “Drucktaste” (Button) eine “klassische” Lösung für das generische Problem “Funktion auslösen” dar.
Beim Ansatz von SAP geht es darum, die Ebene dieser elementaren Aktionen und Lösungen, beispielsweise die Eingabe von Text oder der Klick auf einen Knopf, zu verlassen und komplexere Aufgaben zu identifizieren. Dazu werden die elementaren Bausteine, die “User-Interface-Controls”, etwa die Drucktaste, zu höherwertigen Bausteinen, den “Pattern-Elementen”, zusammengesetzt. Solch ein Pattern-Element ist beispielsweise eine Werkzeugleiste, die verschiedene Controls zur Funktionsauslösung zusammenfasst. Pattern-Elemente lassen sich wiederum zu noch komplexeren Bausteinen, den User-Interface-Patterns, kombinieren. Ein User-Interface-Pattern bedient eine oder mehrere generische Aufgaben, etwa die Suche nach einem Geschäftsobjekt und dessen Auswahl. Ein solches Pattern könnte etwa aus einem Suchbereich, verschiedenen Funktionstasten in einer Werkzeugleiste und einem Sammelbereich für die Trefferliste bestehen.

Standardisierte Grundrisse für Applikationen

Bei der Applikationsentwicklung werden User-Interface-Patterns zu Applikations-Grundrissen kombiniert und dabei auf dem Bildschirm angeordnet. Für gleiche Anwendungstypen (“Business-Aktivitäten”), etwa das Bearbeiten eines Kundenauftrags, lassen sich Applikations-Grundrisse standardisieren. Ein Teil der Lösung “People Centric” mySAP Customer Relationship Management (mySAP CRM), die den Auftakt zur Umsetzung von User-Interface-Patterns bei SAP markiert, besteht aus nur zwei Grundrissen und verwendet lediglich zwei unterschiedliche User-Interface-Patterns. Dadurch ist die Lösung sehr konsistent. Mit wenigen Grundrissen auszukommen ist in diesem Anwendungsgebiet allerdings nur möglich, weil die Applikationen ähnlich strukturiert sind. Natürlich lassen sich weitere Grundrisse und User-Interface-Patterns verwenden, wenn die Applikation dadurch besser den Anforderungen der Anwender entspricht.
SAP orientiert sich bei der Entwicklung von Benutzeroberflächen an der “Contextual Design”-Methode von Karen Holtzblatt, die von der Arbeitspraxis der Anwender ausgeht. Mit dieser Methode erstellen Entwickler und UI-Designer das Modell einer Interaktionsstruktur (“User Environment”-Modell) – also die Struktur eines Geschäftsprozesses aus Sicht des Benutzers. Die Interaktionsstruktur besteht aus abgeschlossenen Bereichen, den so genannten Fokusbereichen (Focus Areas), die jeweils eine Benutzeraktivität beschreiben, beispielsweise die Eingabe von Rechnungspositionen. Ein Fokusbereich wird bestimmt durch seinen Zweck für den Anwender, durch andere Bereiche, zu denen er navigieren kann, und durch die Funktionen, die ihm zur Verfügung stehen. Nach Holtzblatt soll die Benutzeroberfläche einen Fokusbereich auf dem Bildschirm als zusammenhängend darstellen, so dass sich der Anwender darauf konzentrieren und seine Aktivität dort vollständig ausführen kann.
Normalerweise werden Fokusbereiche für einen bestimmten Geschäftsprozess hergeleitet und sind nur für diesen gültig. Für den Ansatz von SAP allerdings ist es entscheidend, gleichartige Fokusbereiche von verschiedenen Geschäftsprozessen zu ermitteln. Nur dann lassen sich wieder verwendbare UI-Komponenten bauen, die für den jeweiligen Anwendungsfall konfiguriert werden können. Auf diese Weise erhalten unterschiedliche, aber gleich strukturierte Applikationen eine konsistent aufgebaute Benutzeroberfläche.
Der Ansatz funktioniert allerdings nur dann, wenn die Zahl der “generischen” Aufgaben einerseits gering bleibt, damit andererseits aber viele, auch sehr verschiedenartige Business-Aktivitäten beschrieben werden können.
Teil 2

Dr. Udo Arend

Dr. Udo Arend

Leave a Reply