Entwicklung eines Bedienkonzepts
Für die Entwicklung eines auf den Rahmenbedingungen fußenden
Bedienkonzepts gibt es zahlreiche Ansätze. Im Folgenden wird eine
Herangehensweise vorgestellt, welche sich in der Praxis bewährt
hat. Sie hat nicht den Anspruch, in jeder denkbaren Situation
anwendbar oder gar absolut perfekt zu sein. Sie stellt eine aus der
Praxis entwickelte Vorgehensweise dar. Die verwendete Terminologie
ist zur KlarsteIlung in Tabelle 5.1 fixiert. Die Beispiele in der
Tabelle beziehen sich auf eine Registrierkassen-Anwendung, die im
weiteren Verlauf des Buches immer wieder als Beispielanwendung
herangezogen werden wird.
Tabelle 5.1: Die verwendete Terminologie
Term
Beschreibung
Beispiel
Anwendung
Die Software als Ganzes
Die gesamte RegistrierkassenAnwendung
Aufgabe
Ein Teilbereich einer Software,
eine Funktion der Anwendung, die
es ermöglicht, ein Ziel zu erreichen
Erfassen eines Kundeneinkaufs
Ziel
Das Ziel ist der Abschluss
einer Aufgabe
Den gesamten Einkauferfassungsund
Bezahlvorgang mit einem
Kunden abwickeln
Operation
Eine Operation ist ein Teilschritt
einer Aufgabe
Einscannen eines Artikels
Ablauf
Eine meist logische Folge
von Operationen
Einscannen eines Artikels,
Summenbildung der bislang
gescannten Artikel usw.
Die Systematik beginnt mit der differenzierten Erfassung der
Bestandteile der Anwendung und ihrer Abläufe. Sie sieht folgende
Schritte vor:
Die Anwendung in einzelne Aufgaben und ihre Ziele gliedern
Eine Aufgabe in reguläre Operationen gliedern
Die optionalen Operationen erfassen
Die notwendige Informationen erfassen
Die Operationen und Abläufe strukturieren
Die Anwendung in einzelne Aufgaben
und ihre Ziele gliedern
Der erste Schritt bei der Entwicklung eines Bedienkonzepts sieht
die Unterteilung einer Anwendung in die verschiedenen Aufgaben
vor. Da diese Unterteilung direkten Einfluss auf die bedienenden
Benutzer hat, wurde sie bereits ganz zu Anfang dieses Kapitels unter »Das Aufgabenspektrum der Software« thematisiert.
Die einzelnen Aufgaben der resultierenden Liste werden nun im
weiteren Verlauf in ihre Operationen unterteilt.
Die Aufgaben in einzelne Operationen gliedern
Bei der Gliederung der Aufgaben in ihre Operationen wird zunächst
der direkte Weg zum Ziel formuliert. Als Anfangspunkt kann die
erste direkt mit dem Ziel in Verbindung stehende Operation gelten.
Wenn es geplante alternative Wege gibt, so sollten sie gleichberechtigt
behandelt werden. Allerdings sollte verifiziert werden, ob zwei
Abläufe mit gleichem Ziel tatsächlich notwendig sind. Sie könnten
auch unnötig Verwirrung stiften.
Abbildung 5.9 zeigt eine mögliche Dokumentation der einfachen
Aufgabe, eine E-Mail zu versenden.
Abbildung 5.9: Reguläre Operationen des Ablaufs »E-Mail versenden«
Die optionalen Operationen erfassen
Die optionalen Operationen sind alle Operationen, die nicht direkt
zielführend sind. Es kann sich dabei beispielsweise um parallele
oder verkürzende Abläufe, begleitende oder unterstützende Operationen
handeln.
Ein Ergebnis der Planung
des UI-Designs kann an diesem
einfachen Beispiel bereits
abgelesen werden: Die
Notwendigkeit, zu jedem
Zeitpunkt andere Informationen
in Microsoft Outlook
nachschlagen zu können,
hat sicherlich zur Implementierung
des E-Mail-Formulars
als sich öffnendes neues
Fenster geführt.
SELFPHP
SELFPHP OHG, info@selfphp.de, Impressum, Kontakt