Bausteine für Benutzeroberflächen (2)

Feature | 13. Dezember 2004 von admin 0

Teil 1
Der Ansatz, Benutzeroberflächen mit User-Interface-Patterns zu konfigurieren, funktioniert nur dann, wenn die Zahl der “generischen” Aufgaben einerseits gering bleibt, mit ihnen andererseits aber viele, auch sehr unterschiedliche Business-Aktivitäten beschrieben werden können. In den nachfolgenden Abschnitten wird beispielhaft gezeigt, wie generische Aufgaben aussehen können und wie daraus wieder verwendbare Bausteine bestimmt werden.

Arbeitsobjekt suchen und auswählen

Arbeitsobjekt suchen und auswählen

Bevor der Anwender eine Aktivität ausführen, also etwa eine Rechnung bearbeiten kann, muss er den entsprechenden Geschäftsprozess auswählen. Anschließend kann er ein Arbeitsobjekt suchen oder direkt bestimmen. Die Auswahl des Arbeitsobjekts lässt sich auf der Benutzeroberfläche beispielsweise mit Hilfe von verschiedenen Dropdown-Boxen und einer Drucktaste realisieren. Die Dropdown-Box “Show” erlaubt es zum Beispiel, eine vordefinierte Suchabfrage auszuwählen, die Dropdown-Box “Get” ermöglicht alternativ die Auswahl eines Schlüsselfeldes und die Eingabe eines Wertes im zugehörigen Eingabefeld. Hinter der Drucktaste “Advanced” verbirgt sich ein Fenster, in dem eine erweiterte Suchanfrage ausgelöst werden kann.

Orientieren, identifizieren, bearbeiten

Mögliche Arbeitsobjekte in einer Ergebnisliste

Mögliche Arbeitsobjekte in einer Ergebnisliste

Die möglichen Arbeitsobjekte, die bei der Suchanfrage ermittelt wurden, lassen sich in einem Bereich der Benutzeroberfläche sammeln. Der Anwender kann dann entscheiden, wie er weiter verfährt, ob er also eines oder mehrere Objekte auswählt. Zur Orientierung benötigt er Informationen über das aktuelle Arbeitsobjekt, beispielsweise den Status und die Möglichkeiten der Navigation. Die Benutzeroberfläche muss es dem Anwender erlauben, das zu bearbeitende Objekt eindeutig zu identifizieren. Dafür müssen ihm die wichtigsten Daten in einem Formular, einer Tabelle, einem Baum oder grafisch zur Verfügung gestellt werden.

Leicht nachvollziehbare Strukturen

Beispiel-Objektstruktur für eine Rechnung

Beispiel-Objektstruktur für eine Rechnung

Als Maßeinheit für die Definition einer Applikation wählte SAP eine Aktivität wie “Rechnung erfassen”. Man geht davon aus, dass jede Business-Aktivität aus einer leicht beschreibbaren Basisstruktur besteht, die ein Anwender in ähnlicher Weise nachvollzieht. Diese Struktur setzt sich aus Begriffen (Objekten) unterschiedlicher Abstraktion zusammen. Jedes Objekt kann vom Typ “kategorial” oder “aufzählend” sein. Ein Rechnungskopf zum Beispiel besteht aus verschiedenen Informationen, die sich formularähnlich abbilden lassen (kategorial), die Rechnungspositionen dagegen sind aufzählend und können gut in einer Tabelle dargestellt werden.
Beim Reengineering zahlreicher Business-Aktivitäten stellte SAP fest, dass die spezifische Objektstruktur häufig Teil einer allgemeinen Objektstruktur ist.

Grundriss für generische Aufgaben vom Typ "Bearbeiten von Objekten")

Grundriss für generische Aufgaben vom Typ "Bearbeiten von Objekten")

Die Fokusbereiche eines Geschäftsprozesses lassen sich zu einem Grundriss (Floor Plan) zusammenstellen. Jeder “Raum” des Grundrisses bestimmt einen Platz auf dem User-Interface, etwa oben horizontal, links senkrecht oder rechts unten. Jedes Stockwerk dieses Grundrisses wiederum beschreibt einen Bildwechsel. Für jeden Fokusbereich, der eine spezifische Aufgabe beschreibt, lässt sich folglich eine zugrunde liegende generische Aufgabe identifizieren. So definierte SAP beispielsweise für die Lösung “User Centric” mySAP CRM einen Applikations-Grundriss, der für die Aufgabe “Objekte bearbeiten” geeignet ist. Für andere Aufgaben sind andere Grundrisse notwendig.

Generische Aufgaben auf das User-Interface abbilden

Der Grundriss der generischen Aufgaben lässt sich dann auf den Grundriss ausprogrammierter User-Interface-Patterns abbilden. Dabei gilt:

  1. Eine oder mehrere generische Aufgaben werden auf ein User-Interface-Pattern abgebildet.
  2. Diese Komponente wird auf dem Bildschirm entsprechend eines vordefinierten Grundrisses angeordnet.
  3. Die Komponente enthält alle Funktionen, Daten und Links, die ein Anwender für die entsprechende Aufgabe benötigt.

Mit User-Interface-Patterns konfigurieren Entwickler die Oberflächen, anstatt sie zu programmieren. Der Entwickler entscheidet nur noch, welche Funktionen und welche Felder für jedes Pattern auf der Benutzeroberfläche erscheinen sollen. Dabei wählt er aus Vorschlagslisten aus, die ihm das Entwicklungswerkzeug liefert. Das eigentliche Erscheinungsbild auf der Benutzeroberfläche wird generiert. So lässt sich beispielsweise eine Formularsicht für kategoriale Daten durch Layout-Algorithmen erzeugen, die die entsprechenden Bildschirmelemente, beispielsweise Felder, Auswahlknöpfe (Radio Buttons) oder Ankreuzfelder (Check Boxes) gruppiert und zweidimensional anordnet.

Positive Bilanz

Nach dem ersten Projekt mit User-Interface-Patterns zieht SAP eine positive Bilanz. Folgende Ergebnisse lassen sich festhalten:

  • Die gewählte Abstraktionsebene erwies sich als geeignet, funktional mächtige und allgemeine Bausteine abzuleiten.
  • Die Zahl der identifizierbaren generischen Funktionen bleibt überschaubar.
  • Generische Funktionen lassen sich auf generische User-Interface-Patterns abbilden. Hierbei ist eine präzise Beschreibung der Funktionen notwendig.
  • Die Komposition zu Grundrissen ist relativ einfach. Dabei ist zu bestimmen, wie Daten zwischen User-Interface-Patterns ausgetauscht werden. Bei so genannten Master-Detail-Beziehungen zwischen zwei Objekt-Daten-Patterns beeinflusst die Auswahl einer anderen Zeile im übergeordneten Pattern natürlich die Darstellung im untergeordneten Pattern.
  • Technisch ist es möglich, Benutzeroberflächen zu konfigurieren, anstatt sie zu programmieren. Dies erleichtert Entwicklern die Arbeit beträchtlich.

Vordefinierte User-Interface-Komponenten bieten einen dreifachen Vorteil. Erstens können damit hochkonsistente Benutzeroberflächen einfach erstellt werden. Zweitens lassen sich einzelne Komponenten auch im Nachhinein ergonomisch optimieren, und drittens entsteht ein hoher Produktivitätsgewinn bei der Entwicklung, da die Oberflächen nur konfiguriert werden müssen. Herausforderungen ergeben sich zum einen durch die Verschiedenartigkeit der Business-Aktivitäten, die einen Kompromiss zwischen Aufgabenangemessenheit und Konsistenz erfordern. Zudem können Entwicklungsanfragen zur Erweiterung der Funktionalität im Laufe der Zeit die klare Struktur eines User-Interface-Patterns verkomplizieren. Mit der Erfahrung wird sich zeigen, welche Grundrisse für welche Anwendungstypen am geeignetsten sind.

Dr. Udo Arend

Dr. Udo Arend

Leave a Reply