Embed Size (px)
Citation preview
Von Frames zu Textbausteinen
Eine Implementationstechnik für Autorensysteme
Volkert Brosda
Interface
Gestaltung von Softwareoberflächen nach nutzerorientierten Kriterien
George Gindi
Fachbereich Informations- und Kommunikationswesen Forschungsprojekt
Nutzerorientiertes Risikomanagement NORMA
Fachhochschule Hannover
Hannover im Juni 2003
ISSN 1612-068X
Inhaltsverzeichnis
Von Frames zu Textbausteinen ...............................................3 1 Zusammenfassung .........................................................4 2 Einleitung.......................................................................5 3 Anforderungen...............................................................9 4 Architektur...................................................................10 5 Implementation............................................................12 6 Evaluation....................................................................20 7 Ausblick.......................................................................21 Literatur/Links ..........................................................................22
Interface...................................................................................23 Einleitung..................................................................................24 1 Menschliche Faktoren..................................................27 1.1 Erkennen und selektieren.............................................28 1.2 Gedächtnis ...................................................................28 1.3 Lernen..........................................................................30 1.4 Probleme lösen.............................................................31 2 Ergonomie....................................................................33 2.1 Top-Down und Bottom-Up..........................................33 2.2 Dialoggestaltung – EN ISO 9241/10 ...........................35 2.3 Theorien, Prinzipien und Richtlinien...........................37 2.3.1 Direkte Manipulation...................................................37 2.3.2 Das Objekt-Aktions-Interfacemodell...........................39 2.4 Designpraxis und -prozess...........................................41 Literaturverzeichnis ..................................................................45
Von Frames zu Textbausteinen
Eine Implementationstechnik für Autorensysteme
Autor: Volkert Brosda
Zusammenfassung
4
1 Zusammenfassung
Spezialisierte Autorensysteme können den Anwender so weit führen, dass vordefinierte Qualitätskriterien in der Textproduktion erreicht werden. Dies ist vergleichbar mit dem Einsatz eines Wizzards in der Software-Entwicklung.
Ein solches Autorensystem geht von einer Wissensdarstellung mittels Frames aus und führt den Nutzer (Autor) über eine Folge von Schreibhandlungen zu einer Komposition von Textbausteinen, die zuvor von Experten aus vorgegebenen Textkorpora ermittelt wurden.
In diesem Beitrag werden der Aufbau und die Implementation eines solchen Autorensystems erläutert. Es wird dabei eine Unterteilung in ein Kernsystem und einen Diskursbereich vorgenommen, die eine hohe Wiederverwendbarkeit und flexible Nutzerorientierung sicherstellt. Das System NORMA [9] liefert ein Beispiel für die hier erläuterte Implementationstechnik.
Einleitung
5
2 Einleitung
Mit dem Wandel von der Industrie- zur Informationsgesellschaft ändert sich auch das Tätigkeitsprofil in vielen Arbeitsbereichen hin zu einem erhöhten Aufkommen an Kommunikation: inner-betrieblich aber auch im Geschäftsumfeld mit Partnern und Kunden. Gerade im Falle der schriftlichen Kommunikation gewinnt die Qualität der Textprodukte an Bedeutung, egal ob im E-Mail oder im technischen Datenblatt, ob im Printbereich oder im Webauftritt.
Dabei sind die qualitativen Merkmale sehr unterschiedlich. Sie reichen von korrektem Adressatenbezug bis zu minimierter Produktionszeit. Ebenso wichtig können die Erstellungskosten, die Vollständigkeit oder die Konsistenz eines Textproduktes sein.
Spezialisierte Autorensysteme können den Anwender so weit führen, dass vordefinierte Qualitätskriterien in der Textproduktion erreicht werden. Dies ist vergleichbar mit einem Wizzard in der Software-Entwicklung. Ein solches Autorensystem geht von einer Wissensdarstellung mittels Frames aus [8].
Einleitung
6
Frame-Modell »Aktion«
Übergang <Wert>
Akteur <Wert>
Zustand A <Wert>
Zustand B <Wert>
Instanz
Übergang zum Kochen bringen
Akteur Person
Zustand A
Liste:
Objekt | Wasser
Temperatur | < 100
Zustand B
Liste:
Objekt | Wasser
Temperatur | = 100
Akteur | Person
Akteur | hat Verbrennung
Bild 1: Frame-Modell, Frame-Modell-Instanz
Es wird zwischen einem Frame-Modell und einer Frame-Modell-Instanz unterschieden. In Bild 1 wird dies stark vereinfacht am Beispiel eines Frame-Modells »Aktion« gezeigt.
Das Autorensystem führt in einem (Anwendungs-)Fall den Autor über eine Folge von Schreibhandlungen zu einer Komposition von Textbausteinen (siehe Bild 2). Der Autor wählt dabei jeweils nur aus einer Menge von vorgegebenen Möglichkeiten. Die
Einleitung
7
Auswahlmöglichkeiten selbst werden ebenso wie die zu erzielenden Textbausteine zuvor von Experten bereitgestellt. Auch die Definition geeigneter Schreibhandlungen ist Sache von entsprechenden Experten. Das Ergebnis einer Schreibhandlung basiert technisch gesehen auf einem Ausschnitt einer Frame-Modell-Instanz. Durch Kombination von Instanzen werden am Ende einer Schreibhandlungsfolge die konkreten Textbausteine referenziert.
Bild 2: Schreibhandlungen als Brücke zwischen Frames und Textbausteinen
Je nach Diskursbereich müssen von geeigneten Experten andere Frame-Modelle, Schreibhandlungen und Textbausteine definiert werden. Ein Beispiel für einen Diskursbereich stellen die Risikotexte in NORMA [9] dar (siehe Bild 3). Dort werden die Handlungen »Recherchieren«, »Konstruieren« und »Formulieren« unterschieden.
Einleitung
8
Bild 3: Risikotext
Ein typischer Autor arbeitet an einer Schreibaufgabe (Schreibhandlung) oder einer Ergebnisanzeige. Ein Experte dagegen wird sich mit der Ressourcenverwaltung (Frame-Modelle und Instanzen sowie den Textbausteinen) beschäftigen. Z.B. kann auf der Basis eines Frame-Modells »Risikomodell« mit Kom-ponenten wie »Risikoidentifikation«, »Schadensauslöser« oder »Risikobewertung« eine entsprechende Instanz »Sicherheitsgurt anlegen« gebildet werden, indem in entsprechende Slots Werte oder Referenzen zu anderen Frame-Modell-Instanzen angegeben werden. Auch legt ein Experte fest, welche Teile einer Frame-Modell-Instanz in einem Schritt mit anderen verknüpft werden müssen, um nach mehreren Schritten schließlich eine Zuordnung zu konkreten Textbausteinen zu ermöglichen.
Anforderungen
9
3 Anforderungen
Wie auch in anderen Fällen der Software-Entwicklung ist das entscheidende Kriterium für ein gelungenes Autorensystem ganz allgemein ein hoher Grad an Wiederverwendbarkeit einzelner Module. Dies sollte die Änderungskosten und auch die Fehler-anfälligkeit reduzieren.
Eine weitere Anforderung liegt in der hohen Nutzerorientierung eines Autorensystems. Erst im Dialog mit den Experten für die speziellen Schreibhandlungen kann das Autorensystem in seinen Dialogen und konkreten Verarbeitungsschritten festgelegt werden. Das bedeutet, dass auch während der Entwicklung des Autoren-systems die Frame-Modelle, die Schreibhandlungen und die Ergebnisdarstellungen verändert werden.
Konkret müssen z.B. die folgenden während der Entwicklung eines Autorensystems zu erwartenden Änderungsfälle von vorn-herein berücksichtigt werden:
• Änderung einer Frame-Modell-Instanz
• Änderung der Struktur eines Frame-Modells
• Änderung des Layouts eines Frame-Modells
• Änderung einer Schreibhandlung
Darüber hinaus wird eine hohe Plattformunabhängigkeit gefordert, um dem Anspruch der diversen Einsatzgebiete gerecht werden zu können.
Architektur
10
4 Architektur
Um die genannten Anforderungen zu erfüllen wird folgende Architektur vorgeschlagen.
Das Gesamtsystem besteht aus einem Systemkern und einem je nach Anwendung variierenden Diskursbereich, der Funktionen des Systemkerns verwendet.
Bild 4: Architekturübersicht
In einem Diskursbereich werden entsprechende Frame-Modelle, Schreibhandlungen und Textbausteine definiert.
Zum Systemkern gehört eine sich selbst beschreibende Basis-klasse, die als Template für alle Klassen des Diskursbereiches (Anwendungsklassen) verwendet wird. Eine Reihe von generi-schen Methoden stattet die Anwendungsklassen mit einem
Architektur
11
gleichartigen Verhalten aus. »Generisch« bedeutet dabei Unabhängigkeit von einer bestimmten Klasse (siehe Abschnitt 5 Implementation). Es muss nur das Template eingehalten werden. Des Weiteren liegt eine Systematik vor, nach der Informationen im System verwaltet, d.h. gespeichert, verarbeitet und angezeigt werden. Der Systemkern sorgt durch seine generischen Methoden dafür, dass ein entsprechendes Autorensystem einer klassischen 3 Ebenen Architektur genügt, in der die Dialogoberfläche, die Verarbeitungsprozesse und die Datenhaltung strikt getrennt sind.
Die Dialogoberfläche wird über die 3 Kategorien »Ressourcen-verwaltung«, »Schreibaufgaben« (Schreibhandlungen) und »Er-gebnisanzeige« an die Verarbeitungsprozesse angebunden. Die Dialogoberfläche ist formular- bzw. dokumentenzentriert. Dazu wird über den Systemkern eine Klasse »Formular« angeboten, die sämtliche Informationen zur Formularverwaltung enthält. Ein Mechanismus zur Bildung einer kontextsensitiven Hilfe ist ebenfalls Bestandteil des Systemkerns. Als Kontext fungieren die 3 genannten Kategorien des Autorensystems.
Das Autorensystem arbeitet in 3 Phasen: Laden aller persistenten Informationen in den Hauptspeicher, Verknüpfen von Frame-Modell-Instanzen oder Teilen davon und Zurückspeichern der Informationen in einen persistenten Bestand. Zwischen je 2 persistenten Zuständen arbeitet der Anwender in einer Sitzung. Die Verwaltung von Frame-Modellen und entsprechenden Instan-zen ist generisch, so dass nur die entsprechenden Anwendungs-klassen in ihrer Struktur geändert werden müssen, wenn sich die Datenstrukturen im Dialog mit den Experten oder typischen Autoren während der Entwicklungszeit des Autorensystems ändern. Dabei müssen die Anwendungsklassen nur konform zur Basisklasse gebildet werden.
Implementation
12
5 Implementation
Das Autorensystem verwendet sogenannte Frame-Modelle in Anlehnung an eine formalisierte Wissensverarbeitung, um die anwendungsspezifischen Informationen zu verwalten (siehe Bild 1). Ein komplexeres Beispiel ist das Risikomodell im System NORMA. Es besteht aus diversen weiteren Komponenten-modellen wie etwa der Risikoidentifikation. Eine konkrete Risikomodellinstanz, die einem entsprechenden Modell genügt, ist z.B. eine Beschreibung für das Anlegen eines Sicherheitsgurtes. Im Rahmen der weiteren Verarbeitungsprozesse (z.B. Schreibauf-gaben) werden Teile (Ausschnitte) von Risikomodellinstanzen ge-bildet und mit einander kombiniert, d.h. wechselseitig referenziert.
Die zentrale Aufgabe der Implementation der oben angegebenen Architektur liegt in der Realisierung einer generischen Verwaltung von Frame-Modellen und entsprechenden Instanzen für einen beliebigen Diskursbereich.
Ein Frame-Modell wird dazu technisch als eine sich selbst beschreibende Klasse (siehe Basisklasse »Klasse« in Bild 5) mit einer festen Namenskonvention für diverse Metainformationen implementiert. In mindestens den folgenden Aspekten beschreibt sich jede Klasse selbst:
Implementation
13
• Name,
• Komponentennamen,
• Komponententypen,
• Sichtbarkeit und
• Bearbeitungsfunktionalität.
Jede solche Klasse besitzt eine Menge von stets gleichen generi-schen Methoden. Sie greifen auf die Selbstbeschreibung einer Klasse zu und sind rekursiv, um eine beliebige Schachtelungstiefe von Unterklassen bearbeiten zu können.
Diese generischen Methoden stellen sicher, dass Änderungen in der Frame-Struktur keine Auswirkungen in der Frame-Verwaltung wie etwa Speichern, Anzeige oder Instanzbildung nach sich ziehen (siehe dazu auch die Nutzung des Operators »eval« in Bild 7).
Das Verhalten einer Klasse (bzw. eines Frame-Modells) kann sich zur Laufzeit ändern, in dem eine andere Implementation einer Methode referenziert wird.
Im Beispiel des Autorensystems NORMA werden die Frame-Modelle als JavaScript-Klassen realisiert, wie in Bild 5 gezeigt wird.
Implementation
14
function Klasse(<Komponenten als Parameter>){
this.v<i> = i-ter Parameter // value
this.klasse = "Klasse"; // Name dieser Klasse
this.name = <Name>; // Name der Klasse in
Anzeigedarstellung,
Layout
this.n<i> = <Name der i-ten Komponente>
this.t<i> = <Typ der i.-ten Komponente: Wert
| Referenz auf Frame | Array>
this.vis = <Sichtbarkeit des gesamten
Objektes in der Anzeige>
this.vis<i> = <Sichtbarkeit der i-ten
Komponente in der Anzeige>
this.kr = <Ankreuzmöglichkeit (Auswahl) in
einer Schreibhandlung>
// generische Methoden; sie werden erst zur
Laufzeit angebunden
}
Bild 5: Frame-Modell als selbstbeschreibende JavaScript-Klasse
Die Script-Sprache JavaScript sichert durch ihren Einsatz im Umfeld anderer Internet-Techniken wie z.B. HTML eine hohe Plattformunabhängigkeit. Es wird sogar ein rein clientseitiger (Web Browser) Einsatz des Autorensystems möglich, der ein sehr preiswertes Rapid-Prototyping unterstützt. Aufwendigere Server-Technologien wie z.B. PHP [7], oder die Anbindung an eine Datenbank mittels SQL (siehe z.B. [3]) etc. können jederzeit zusätzlich ohne Architekturänderung eingebracht werden. Die Dialogschnittstelle bietet dem Autor die Informationen eines Frame-Modells oder einer zugehörigen Instanz über ein komplex strukturiertes HTML-Formular an. Bild 6 skizziert den Formularaufbau. Dabei bieten die Button »plus« und »minus« die Expansion bzw. Reduktion um komplexe Unterstrukturen. In den
Implementation
15
einzelnen Schreibhandlungen wird ein solches Formular passend um weitere Funktionen wie z.B. Checkboxes etc. und Button zur Formularverarbeitung ergänzt. Hierbei können sehr gut systema-tisch aufgebaute HTML-Frames zum Einsatz kommen, um Funktionselemente eines solchen Formulares zu kombinieren.
Formular
Slot Wert/Referenz auf Frame
Slot plus minus
Slot plus minus
Bild 6: Frame-Modell-Instanz als HTML-Formular
Zur Realisierung der angesprochenen generischen Methoden wird in JavaScript der Operator »eval« eingesetzt. In Bild 7 wird am Beispiel einer generischen Ausgabe skizziert, wie für eine Instanz einer beliebigen aus der Basisklasse abgeleiteten Klasse die Ausgabe einer entsprechenden Zeichenkette vorgenommen wird.
Implementation
16
function ausgabe(AusgabeString){
...
beliebigerSlot=eval('this.v'+i+'['+j+']');
if(beliebigerSlot.klasse)
AusgabeString=
beliebigerSlot.ausgabe(AusgabeString)
else AusgabeString += beliebigerSlot;
...
return AusgabeString
}
Bild 7: Einsatz des Operators »eval«
Der »eval«-Operator interpretiert zur Laufzeit eine Zeichenkette als einen JavaScript-Ausdruck. So wird nach einem Zugriff auf die Beschreibung einer Klasse zunächst eine Wertekategorie (Attribut, Slot, Komponente) ermittelt und dann erst der Wert angesprochen. Ebenso kann einer Instanz ein Verhalten erst unmittelbar vor einem entsprechenden Bedarf zugewiesen werden, bevor dieses Verhalten aktiviert wird. Dies entspricht einem Interface in Java [6], welches erst zur Laufzeit angebunden wird. Bei der Datenhaltung der Frame-Modelle wird zwischen Objektkonstruktoren wie z.B.:
"new hparent.PT("1","pictogramme/test.jpg",
"Warnung","4","Person");"
im Falle einer Klasse PT und den darüber instantiierten Objekten wie z.B.:
"objekt=new hparent.PT("1","pictogramme/test.jpg",
"Warnung","4","Person");"
unterschieden.
Implementation
17
Die Konstruktoren werden als Zeichenketten in dynamischen Arrays im Hauptspeicher bzw. als Array-Konstruktoren in entsprechenden Dateien gespeichert. Erst wenn ein Objekt als Repräsentation einer Frame-Modell-Instanz, wie z.B. einer kon-kreten Instanz eines Risikomodells für »Sicherheitsgurt anlegen« benötigt wird, wird der Konstruktor mittels »eval« ausgeführt und das Objekt erzeugt.
Die oben angeführte Varibale »hparent« stellt ein technisches Detail dar, mit dem der Kontext für den Konstruktoraufruf in einem HTML-Frame variabel bei stets gleicher Konstruktorform gestaltet werden kann. Das Laden eines Konstruktors in den Hauptspeicher wird aus Gründen der Browser-Kompatibilität und der anschließenden verzögerungsfreien Interaktion beim Laden des Autorensystems vorgenommen. Die Anzeige der jeweiligen Verarbeitungssituationen, die in komplexen Hauptspeicher-repräsentationen der Frame-Modell-Instanzen vorliegen, werden stets in gleicher Weise vorgenommen: Eine HTML-Datei fungiert als Container für den Aufruf eines stets analog aufgebauten Skriptes, welches per »document.write« den Container geeignet ausfüllt. Hierbei wird auf eine strikte Trennung zwischen Inhalt, Struktur und Layout geachtet. Zur Anbindung eines flexiblen Layouts werden Layoutklassen angesprochen, die z.B. in einer CSS-Datei abgelegt werden.
Die sichtbare Struktur eines Frame-Modells bzw. einer Instanz wird über geeignete Arbeitsmodi gesteuert. Das Autorensystem NORMA z.B. unterscheidet die unten genannten Arbeitsmodi im Umgang mit den Frame-Modellen, d.h. bei den generischen Methoden des Systemkerns. Der Systemkern enthält z.B. die generischen Methoden »schema« (Bildung eines varianten HTML-Formulars für ein beliebiges Frame-Modell), »skelett« (Bildung eines kleinsten Konstruktors für ein beliebiges Frame-
Implementation
18
Modell), »konst« (Bildung eines Konstruktors für eine beliebige Frame-Modell-Instanz) und »collect« (Erfassen von Daten zu einer Frame-Modell-Instanz auf der Basis eines jeweiligen HTML-Formulares).
Der Modus »ressource« sorgt für die Verwaltung von Frame-Modellen in der Ressourcenverwaltung. Dies ist der default.
Der Modus »schreiben« sorgt für eine gezielte Unterstützung der Dialoge in den Schreibhandlungen. Einzelne Komponenten einer Frame-Modell-Instanz im Formular sind hier z.B. ankreuzbar. Es muss z.B. unterschieden werden, ob eine Komponente im Dialog angekreuzt wurde und sich so anschließend die Sichtbarkeit (siehe Komponente »vis« und »vis[i]« in Bild 5) der Frame-Modell-Instanz geändert hat. Listen mit atomaren Werten werden hier z.B. im Gegensatz zum Modus »ressource« über einen Button nur bei Bedarf im entsprechenden Formular eingeblendet.
Der Modus »schreiben1« stellt ganze Teilstrukturen nicht im entsprechenden Anzeigeformular dar, wenn ein Indikator auf »false« gesetzt wurde. So wird die Anzeige an den Informations-bedarf des Nutzers bei der jeweiligen Schreibhandlung angepasst.
Der Modus »tzustand« führt in NORMA zu einer Formular-darstellung wie im Modus »schreiben1« allerdings ohne die Möglichkeit, Daten zu speichern.
Die Ergebnisse der Schreibaufgaben werden fallbezogen auf der Basis einer Risiko-Modell-Instanz verwaltet. Nach der ersten Schreibhandlung werden Ausschnitte einer Frame-Modell-Instanz unter einer Fallbezeichnung in einer Datei »t0.js« gespeichert. In NORMA ist dies ein bestimmter Ausschnitt einer Risiko-Modell-Instanz.
Implementation
19
Die Ergebnisse weiterer Schreibhandlungen (in NORMA sind dies Konstruktion und Formulierung) werden inkrementell in weiteren Dateien (in NORMA »t1.js« bzw. »t2.js«) abgelegt. Beim Ladevorgang werden dann komplexe Hauptspeicher-strukturen zur Darstellung eines entsprechenden Ausschnittes einer Frame-Modell-Instanz gebildet, die sich auf einen Datensatz in »t0.js« beziehen.
Damit wird das Datenvolumen reduziert und die Ladezeit verringert. Die Ablöse der genannten Dateien durch entsprechende SQL-Tabellen ist so ohne weiteren Aufwand je nach Bedarf möglich.
Evaluation
20
6 Evaluation
Bei der Entwicklung des Autorensystems NORMA wurde zunächst der oben skizzierte Systemkern implementiert. Anschließend wurde durch Experten für die geplanten Schreibhandlungen ein erster Ansatz für den Diskursbereich »Risikotext« spezifiziert. Es folgte die Erfassung erster Risiko-Modell-Instanzen und beispielhafter Textbausteine im Kern-system des Autorensystems. Danach wurde versucht, durch geeignete Schreibhandlungen eine Verknüpfung zwischen den Ressourcen und den Textbausteinen zu erreichen. Dies gelang natürlich nicht auf Anhieb. Das Risikomodell musste überarbeitet werden. Die zuvor bereits erfassten Instanzen sollten aber nicht verloren gehen. Hier hat sich der Systemkern mit seinen generischen Methoden eindeutig bewährt. Es konnten die bereits mit einem alten Modell gebildeten Instanzen über das vorhandene System in ein neues Schema eines Risikomodells überführt werden. Ein zentraler Grund liegt in der Verwaltung der Konstruktoren für die Frame-Modell-Instanzen als Zeichenketten an Stelle der Instanzen selbst; dies sowohl in einer persistenten Datei als auch in einem dynamischen Array.
Ausblick
21
7 Ausblick
Die Aufteilung eines Autorensystems in ein Kernsystem mit einer generische Verwaltung von Frame-Modellen sowie in einen Diskursbereich bestehend aus einer Folge spezifischer Frame-Modelle, Schreibhandlungen und Textbausteine hat sich bewährt. Es wird im Weiteren versucht, auch die Schreibaufgaben in ein Kernsystem und einen Diskurs abhängigen Teil zu zerlegen, um die Wiederverwendbarkeit einzelner Komponenten des Systems weiter zu steigern. Hier kann eventuell die Logikprogrammierung weiterhelfen.
Literatur/Links
22
Literatur/Links
[1] BROSDA, Volkert/JASPERSEN, Thomas 2002. Elektronische Online-Dokumentation. In: Pepels, Werner (Hrsg.), Bedienungsanleitungen als Marketinginstrument. S 111-125. Expert Verlag, Renningen.
[2] BROSDA, Volkert/JASPERSEN, Thomas 1995. Lean Information Management. Datacom Buchverlag GmbH, Bergheim.
[3] BROSDA, Volkert 1997. Datenbank gestützter Dialog – Von den relationalen zu den Frame gestützten Systemen. In: JASPERSEN, Thomas; BLÖMER, Arnold (Hrsg.). Business Online. Kommunalverband Großraum Hannover – Wirtschaftsförderung.
[4] http://www.teamone.de/selfaktuell. Abschnitt CSS
[5] http://www.teamone.de/selfaktuell. Abschnitt JavaScript
[6] KÜHNEL, Ralf 1996. Die Java-Fibel. Addison Wesley, München.
[7] PEYTON, Christine 2002. PHP Der leichte Einstieg. Markt+Technik, München.
[8] REIMER, Ulrich 1991. Einführung in die Wissens-repräsentation. Teubner, Stuttgart.
[9] ROTHKEGEL, Annely. NORMA – Nutzerorientiertes Risikomanagement in der Technischen Kommunikation – Konzept eines Autorensystems. In: Sprache und Daten-verarbeitung Vol. 2/2002
Interface
Gestaltung von Softwareoberflächen nach nutzerorientierten Kriterien
Autor: George Gindi
Einleitung
24
Einleitung
Software löst spezielle Aufgaben in den unterschiedlichsten Nutzungskontexten. Wie man Nutzer in die Lage versetzt, mit Software Ziele zu erreichen und Probleme zu lösen, ist Untersuchungsgegenstand dieses Aufsatzes. Interfaces bergen die Chance in sich, den Nutzer in einen kreativen Flow zu versetzen. Flow meint hier den psychologischen Fachbegriff, geprägt durch den Psychologen MIHALYI CSIKZENTMYHALYI (1977). CSIK-ZENTMYHALYI versteht unter Flow einen Zustand des Ver-senktseins in eine Tätigkeit. Flow besteht immer dann, wenn man sich konzentriert und vertieft mit einer Sache auseinandersetzt, das Zeitgefühl pausiert und psychische Bedürfnisse befriedigt werden. Spiele, Kunst, Rituale und Sport sind Beispiele für mögliche Flow-Aktivitäten, die positive Erlebnisse auslösen können [vgl. CSIKZENTMYHALYI 1999:104].
Flow-Erlebnisse mit Software basieren einerseits auf einem vorhandenen Wissensstand der Nutzer und andererseits auf der adäquaten Oberflächengestaltung in Kombination mit den richtigen Funktionen. Software bietet in ganz besonderer Weise die Chance, die Selbstverwirklichung und Kreativität des Nutzers zu fördern. Ist der nötige Wissensstand nicht vorhanden, hat die Software Sorge zu tragen, dem Nutzer das nötige Wissen bereitzustellen. Deshalb ist eine nutzerorientierte Dokumentation fester Bestandteil von Software. Der gegenteilige Fall ist derjenige, der zu Frustrationen führt. Manchmal kommt man mit einer Software einfach nicht klar, weil kein mentales Modell vorhanden ist und weder die Oberfläche noch die Dokumentation den Nutzer unterstützt ein solches zu bilden.
Einleitung
25
Zu Beginn des Computerzeitalters war es nur einigen Wenigen unter großen Anstrengungen vorbehalten sich die Technologie anzueignen. Um zum Beispiel eine Leerzeile zu löschen, war es erforderlich bestimmte Befehle zu kennen (grep -v ^$). Heute setzt man den Cursor in die Zeile und drückt die Rücktaste. Eine Entwicklung, die den weniger Technophilen sehr entgegen kommt [vgl. SHNEIDERMAN 2002a:52]. Mit dieser Entwicklung lässt sich auch die ausschweifende Diskussion zum Thema Usability erklären. Ausschweifend insofern, als dass innerhalb eines kurzen Zeitraums sehr viele Publikationen aus vielen verschiedenen Disziplinen im Netz oder als Print zum Thema auftauchen. Ein beachtlich großer Teil davon ist populärwissenschaftlich und behandelt die Gestaltung von Internetauftritten.
Die psychologisch motivierte Forschung begründet viele Maßnahmen mit den verlässlich wiederkehrenden Mechanismen der Informationsaufnahme und -verarbeitung der menschlichen Kognition. Die Informatik verfolgt mit Interaction-Design-Patterns (vgl. z.B. VAN WELIE 2002) und weiteren Konzepten und Ansätzen zur Umsetzung und Gestaltung von nutzerorientierten Schnittstellen ein dynamisches Standardisierungskonzept. Es fließt aber noch einiges mehr zusammen als nur Psychologie und Informatik: Informationsarchitektur, Informationsdesign, Inter-aktionsdesign, Interfacedesign, Ergonomie/Usability, um die wichtigsten Disziplinen zu nennen. Human Computer Interface (HCI) fasst das Zusammenwirken der Disziplinen zusammen.
Fairerweise möchte ich an dieser Stelle darauf hinweisen, dass meine Leser hinterher keine spitzen Softwaredesigner oder Usability-Ingenieure sein werden. Die Zielsetzung dieses Aufsatzes besteht in der Vermittlung folgender Erkenntnisse:
Einleitung
26
•••• Software dient der Kreativität und Selbstverwirklichung des Nutzers.
•••• Software kann durch implementierte Funktionen oder Routi-nen Mehrwerte produzieren.
•••• Die Art und Weise der Präsentation und Bedienbarkeit entscheidet über das Entstehen eines Flows oder das Nichterreichen der gefassten Nutzerziele.
In diesem Aufsatz werden nur für die Nutzerorientierung wichtige Aspekte des Softwaredesigns angesprochen. Anspruch auf Vollständigkeit besteht auf Grund der Kürze nicht. Anvisiert ist eine Annäherung der disziplinären Sichtweisen aus Informatik, Psychologie und Gestaltung (Design). In Beispielen wird Bezug auf das Forschungsprojekt nutzerorientiertes Risikomanagement (NORMA) genommen und einige Szenarios zum Entstehungsprozess von Software entwickelt.
Menschliche Faktoren
27
1 Menschliche Faktoren
Die Wahrnehmung des Menschen arbeitet nach dem Prinzip, diverse Reize mit bereits gespeichertem Wissen zu vergleichen. Der Weg dabei geht in Bezug auf Software über das Auge zum Verstand. Dort werden bestehende Muster (bereits vorhandene mentale Modelle) mit neuen verglichen. Daraufhin entsteht ein neues Muster, das die neuen Reize zuordnet. Etwas undifferenziert könnte man das auch Lernen nennen. Lernen als Transformation von Information zu Wissen beschreibt kognitive Vorgänge, bei denen Erfahrung, bereits vorhandene Muster, Gewohnheiten sowie der Kenntnisstand zu einem Sachverhalt und weitere Faktoren immer unterschiedliche Voraussetzungen schaffen. Genau aus diesem Grund ist das einfache Interface oft das effektivste, da einfache und übersichtliche Strukturen leichter erlernbar sind. Dabei ist das Problemlösen (vgl. 1.3) das Band zwischen Software und Nutzer. Wie versetzt man die Nutzer in die Lage sich ein mentales Modell zu bilden? Immer wieder steht die reale Welt als Vorbild, die die Strukturen der »virtuellen Softwarewelt« festschreibt. Ein Beispiel für diese Vorgehensweise ist die Datenmodellierung mit Entity-Relationship-Diagrammen. Die Adressdatenbank hat die Struktur Titel, Name, Vorname, Straße, Ort, PLZ, Tel. usw., weil die Realität das erfordert. Ebenso unterstützt Risikomanagement-Software Funktionen wie Risiko-Identifikation, Risiko-Analyse und Risiko-Bewertung, weil die Realität das erfordert. Der Spielraum der nutzerorientierten Gestaltung liegt in der Abstraktion von der Realität und dem Wie der nachempfundenen Realität.
Menschliche Faktoren
28
1.1 Erkennen und selektieren
Der Nutzer lenkt seine Aufmerksamkeit nach seinem Ermessen in Abhängigkeit seines (Teil-)Ziels auf Informationen, um diese zu filtern, bevor die Informationen im Gedächtnis gespeichert werden. Dabei gibt es unterschiedliche Verarbeitungsstufen, die von der aktuellen Situation oder Stimmung beeinflusst werden. Ein nutzerorientiertes Interface oder die Textgestaltung bietet durch differenzierte Strukturierung der Informationen eine erleichterte Selektion der Information. In dem Fall, dass die Informationen unstrukturiert präsentiert sind, ist es möglich, dass der Nutzer die Informationen lediglich bewertet. Die Chance, Informationen in Wissen zu transformieren (GINDI 2002:24-29) bleibt dann leider auf der Strecke. Durch Erkennen und Selektieren werden den gebotenen Informationen Bedeutungen zugeordnet. Der Nutzer lässt sich dabei unterstützen durch Anwenden der Gestaltgesetze 1, ein hohes Maß an Eindeutigkeit und klaren Unterscheidungsmöglichkeiten.
1.2 Gedächtnis
Als ein menschlicher Faktor mit besonderen Auswirkungen auf Softwaredesign steht das Gedächtnis des Menschen. Gelingt es, das Funktionsprinzip zu unterstützen, ist ein Schritt zur mentalen Modellbildung beim Nutzer getan. Dazu muss der Gestalter des Interfaces die allgemeinen Gedächtnisstrukturen kennen. MARLANA COE (1996:70-96) unterscheidet drei Stufen:
1 Gesetz der Nähe, Gesetz der Ähnlichkeit, Gesetz des glatten Verlaufs, Gesetz der guten
Gestalt [ZIMBARDO/RUCH 1974:217ff]
Menschliche Faktoren
29
1. Sensory registers (sensorische Speicher)
2. Short-term memory (Kurzzeitgedächtnis)
3. Long-term memory (Langzeitgedächtnis)
Die drei Stufen entsprechen der Einteilung der Informations-aufnahme, -verarbeitung und -speicherung. Ständige Begleiter der Gedächtnisprozesse sind Emotion, Motivation und Einstellung. Damit eine Information dauerhaft gespeichert wird, braucht es für den Weg vom Kurzeitgedächtnis zum Langzeitgedächtnis unter anderem Aufmerksamkeit. Diese zu beeinflussen ist fester Bestandteil der Interfacegestaltung. Ein wichtiger Gedächtnis-aspekt ist die grundsätzliche Unterteilung in sprachliche und bildhafte Informationen. Gemäß PAIVIO (1986) verfügt das Ge-dächtnis über zwei getrennte Speichersysteme Logogens und Imagens, die aber sehr wohl zusammenwirken (duale Codierung). Wenn dem so ist, liegt darin eine Begründung für das leichtere Behalten und Erinnern von Symbolen mit Textlabel. Demgemäß ist eine Kombination aus visueller Darstellung und Text immer ein Entgegenkommen für die Nutzer. Ganz entscheidend für den Designer ist es, die Aufteilung des Langzeitgedächtnisses zu kennen. Auf diese Weise können gezielt Maßnahmen kombiniert und variiert werden, um heterogenen Nutzergruppen einen einfachen Zugang zur Software ermöglichen. Abbildung 1 zeigt die Struktur und Ansprechmöglichkeiten des Langzeit-gedächtnisses. In der Technischen Redaktion sind Beispiele für klassisches Konditionieren Indexe, Glossare, Inhaltsverzeichnisse und Quickfinder. Priming bedeutet das Ausnutzen von Vorwissen durch spezielle Hinweisreize. Wenn man z.B. den Begriff Küche einführt, hält der Nutzer die gezielt gewünschten Assoziationen Essen, Herd und Teller bereit.
Menschliche Faktoren
30
Abbildung 1 – Aufteilung des Langzeitgedächtnisses [COE 1996:80]
1.3 Lernen
Das will ich auch können! Das Motiv Spaß am Lernen ist sicher ein positiver Verstärker. Jedoch die Motivation auszulösen, ist die eigentliche Kunst beim Modellieren von Interfaces. Das Was und Wie sollte beim Nutzer am besten über verschiedene Wege ankommen. In Verbindung mit Gedächtnis repräsentiert das Was und Wie eine Analogie zwischen deklarativen und prozeduralen Verarbeitungsmechanismen bei der Bildung von Wissen im Langzeitgedächtnis (Long-Term-Memory). Deshalb unterstützt ein Zugang, der sowohl das Was als auch das Wie berücksichtigt, die Transformation von Informationen zu Wissen wesentlich besser als ein Zugang, der nur das Was oder nur das Wie berücksichtigt.
Erfahrungen, bereits vorhandene mentale Modelle, Gewohn-heiten, Verstärker (reinforcement) und Interferenzen (Überschnei-dungen mit bereits Gelerntem) schaffen für jeden individuell unterschiedliche Voraussetzungen für das Lernen.
Menschliche Faktoren
31
1.4 Probleme lösen
In Bezug auf das Lösen von Problemen ist eine Software-oberfläche eine Art Vermittlungsinstanz zwischen dem vom Nutzer gefassten Ziel ein Problem zu lösen und den dazu von der Software bereitgestellten Funktionen. Der Mechanismus des Problemlösens ruht in den prozeduralen Gedächtnisstrukturen. Umgekehrt ist es auch gültig:
Der Ursprung des prozeduralen Wissens liegt in Prozessen des Problemlösens. Beim Pro-blemlösen wird ein Ziel in Teilziele zerlegt, für die der Problemlösende Operatoren besitzt [ANDERSON 1996:235].
Mögliche Strategien des Problemlösens sind Analogiebildung, Anleiten und Entdecken (Explorieren). Entdecken insofern, dass der Nutzer direkt ausprobiert oder z.B. das Handbuch studiert. Anleiten durch Instruieren bis zur Lösung eines Problems und Entdecken vor allem für den Erwerb von Operatoren. Gemäß ANDERSON (1996:234) bezeichnet Operator eine Handlung, die den vorliegenden Problemzustand in einen anderen Problem-zustand transformiert. In Hinblick auf die Ziele sind Operatoren Wenn-dann-Regeln, die einerseits zum Problemlösen gebildet werden müssen (Lernen) und andererseits bereits vorhanden sind. Die bereits vorhandenen Operatoren führen durch direktes Abrufen schnell zum Erreichen von Teilzielen. Mit Teilzielen ist bereits angedeutet, dass ein Problem i.d.R. in Teilprobleme zerlegt wird.
Analogiebildung ist ein Prozess, der die Lösung eines (Teil)problems durch ein bereits bekanntes gelöstes Problem beschreibt. Verschiedene Standards beim Gestalten von Software-oberflächen unterstützen die Analogiebildung zum Beispiel die
Menschliche Faktoren
32
Erwartungskonformität und Vorhersagbarkeit (Predictability). Dem Nutzer kommt eine Software immer dann entgegen, wenn sie viele Ziele und verschiedene »Lösungspfade« anbietet. Eindeutige Hindernisse, die es zu vermeiden gilt, sind [COE 1996:125ff]:
• funktionale Fixiertheit (functional fixedness),
• Gewohnheitsneigung (confirmation bias),
• Negativer Transfer (negative transfer),
• Problemlöseeinstellung (problem-solving set).
Funktionale Fixiertheit entsteht, wenn der Problemlösende nicht in der Lage ist eine neue Sicht auf ihm bekannte Dinge zu entwickeln. Die Gewohnheitsneigung entwickelt sich aus der Tendenz, einmal gefasste Ideen zur Problemlösung nicht wieder verwerfen zu wollen. Negativer Transfer bedeutet nur bereits gesammelte Erfahrungen zum Problemlösen heranzuziehen. Deshalb bleiben neue Problemlösungsstrategien auf der Strecke. Die Problemlöseeinstellung in MARLANA COES Sinne beschreibt, ähnlich dem negativen Transfer, das alleinige Heranziehen von Erfahrungen zusammenwirkend mit der Unfähigkeit, das Problem in Teilprobleme zu zerlegen. Neue Lösungsstrategien lassen sich so nicht bilden. Sozusagen ein eingeschränkter »solution pool«.
Ergonomie
33
2 Ergonomie
Nachdem in Kapitel 1 theoretische Aspekte in aller Kürze als Basiswissen angedeutet wurden, führt dieses Kapitel in die praktische Anwendung und Umsetzung der Aspekte ein. Zunächst ist wegen der Popularität des Themas eine Eingrenzung nötig. Informatiker, Designer und Psychologen betrachten Ergonomie durch verschiedene Brillen. Für den Technischen Redakteur wächst das mentale Modell zur Ergonomie aus dem Zusammenführen der disziplinären Erkenntnisse. Bei Software-oberflächen ist entscheidend, den Nutzer in die Lage zu versetzen, selbständig Ziele zu finden und diese zu erreichen. Welche Maßnahmen dafür günstig sind, ist Gegenstand dieses Kapitels.
2.1 Top-Down und Bottom-Up
Eine nutzerorientierte Softwareoberfläche entsteht durch eine sich aus beiden Methoden ergänzende Vorgehensweise, die im Austausch der Beteiligten erarbeitet wird. Das Top-Down Prinzip kommt dahingehend zur Anwendung, dass Richtlinien, Theorien und Prinzipien bekannt sind und als gemeinsamer Zeichenvorrat genutzt werden. Die EN ISO 9241 (1995) für Dialoggestaltung ist nur ein Beispiel für die Anwendung des Top-Down-Verfahrens [vgl. 2.2]. Ebenso gilt es, die Quasi-Standards der Design-Pattern-Konzepte 2 umzusetzen. Für welches Ziel ist welches Pattern
2 Jede Programmiersprache bietet unterschiedliche Möglichkeiten und verschieden Design-
Patterns, die je nachdem ob ein Graphical User-, Web- oder Mobile-Interface entwickelt wird, verschiedene Bedienelemente (Widgets) zur Verfügung stellen.
Ergonomie
34
angemessen? Dabei sollte man sich jedoch immer die Flexibilität bewahren, auch neue Wege für bestimmte Ziele zu gehen.
Die Bottom-Up-Methode bezieht sich auf den zu vermittelnden Inhalt. Die Weichen für eine effektive nutzerorientierte Softwareoberfläche werden über die Repräsentation der nach-empfundenen »Softwarewelt« gestellt. Erstellt man eine Software zur Generierung von Risikoinformationen, so muss es einen Risikomanagement-Prozess geben, der dem System erklärt, was wie gefährlich ist. Hier hat der Nutzer teilweise schwere Ent-scheidungen zu treffen. Nutzerfreundlich ist es, wenn das System durch gezielte Rückfragen und visuelle Hervorhebungen den Entscheidungsprozess erleichtert. Das Was und Wie muss entsprechend der zu realisierenden Ziele erarbeitet werden. Die frühe Modellierungsphase sollte ein modularisierbares und erweiterbares Konzept hervorbringen, das vor allem die Anforderungen der Nutzer mit einbezieht. Der frühe und regelmäßige Dialog mit dem künftigen Anwender, in Fachkreisen auch iterative Entwicklung genannt, begünstigt die Entwicklung einer benutzerfreundlichen Software.
Ergonomie
35
2.2 Dialoggestaltung – EN ISO 9241/10
Das gesamte Paket der europäischen Norm liefert Kriterien für das Design ergonomischer Benutzerschnittstellen. Teil 10 – Grundsätze der Dialoggestaltung – ist als Leitfaden der Interaktion zwischen Mensch und Maschine relevant. Nachfolgend stark gekürzte Auszüge aus der Norm (1995:5-13):
Ein Dialog ist...
1. aufgabenangemessen, wenn er den Benutzer unterstützt, seine Arbeitsaufgabe effektiv und effizient zu erledigen.
2. selbstbeschreibungsfähig, wenn jeder einzelne Dialogabschnitt durch Rückmeldung des Dialogsystems unmittelbar verständlich ist oder dem Benutzer auf Anfrage erklärt wird.
3. steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist.
4. erwartungskonform, wenn er konsistent ist und den Merkmalen des Benutzers entspricht, z.B. seinen Kenntnissen aus dem Arbeitsgebiet, seiner Ausbildung und seiner Erfahrung sowie den allgemein anerkannten Konventionen.
5. fehlertolerant, wenn das beabsichtigte Arbeits-ergebnis trotz erkennbarer fehlerhafter Ein-gaben entweder mit keinem oder minimalem
Ergonomie
36
Korrekturaufwand seitens des Benutzers erreicht werden kann.
6. individualisierbar, wenn das Dialogsystem Anpassungen an die Erfordernisse der Arbeitsaufgabe sowie an die individuellen Vorlieben des Benutzers zuläßt.
7. lernförderlich, wenn er den Benutzer beim Erlernen des Dialogsystems unterstützt und anleitet.
Sieben Eigenschaften, die jeder Software-Designer immer im Hinterkopf behalten sollte und vor allem, die er an der Aufgabe orientiert erarbeiten muss. Sehr ähnliche Hinweise findet man bei BEN SHNEIDERMAN (2002b:100ff). Nur das dort von acht Goldenen Regeln des Schnittstellendesigns die Rede ist. Die achte Regel besagt:
Reduzieren Sie die Belastung des Kurzzeitge-dächtnisses. Die Begrenzung der menschlichen Informationsverarbeitung im Kurzzeitgedächtnis […] erfordert es, dass die Anzeigen einfach gehalten, multiple Anzeigeseiten zusammengelegt, die Frequenz der Fensterbewegungen reduziert und ausreichende Trainingszeiten für Codes, Eselsbrücken und Aktionssequenzen zugestanden werden.
Dem möchte ich dringlichst zustimmen, da das Ergonomie-Prinzip darauf beruht, dass der Nutzer seine Handlungsziele ohne Umschweife erreicht. So viel Angebot, dass alles gern rezipiert wird, ist das richtige Maß. Der cognitive overload zerstört sowohl die Motivation, als auch die Chance den kreativen Flow
Ergonomie
37
auszulösen. Eine goldene Regel, die in der Dialoggestaltung mehr Glanz verdient.
2.3 Theorien, Prinzipien und Richtlinien
BEN SHNEIDERMAN (2002b:73) kategorisiert Vorgaben und Anleitungen in drei verschiedene Level:
1. Anspruchsvolle Theorien und Modelle auf einem hohen, übergeordneten Level,
2. Prinzipien auf einem mittleren Level und
3. spezifische und praktische Richtlinien.
Alle drei Levels der Regularien helfen intuitive Entscheidungen zu überwinden und schaffen einen Gesamtrahmen der Software-entwicklung bzw. ebenso eine Sprache, um die Problematik unab-hängig von einzelnen Anwendungen zu diskutieren. Das ganze 2. Kapitel in SHNEIDERMAN'S aktuellem Werk User Interface Design bietet zahlreiche Anstöße für ein strukturiertes Vorgehen beim Gestalten von Softwareoberflächen. Als essentielle Methodik zu einer nutzerorientierten Softwareoberfläche steht das Objekt-Aktions-Interfacemodell (OAI-Modell) und das Prinzip der direkten Manipulation. Im Folgenden einige Betrachtungen dazu, die kritisch am Beispiel des Prototyps NORMA einen praktischen Bezug finden.
2.3.1 Direkte Manipulation
Zur Erklärung eine Annährung mit einer Definition von TED
NELSON (1980:56): Das Prinzip der Virtualität – eine Reprä-sentation der Realität, die manipuliert werden kann. Gemeint ist vornehmlich ein Interaktionsstil, der visuelle Komponenten gezielt
Ergonomie
38
zum Nachempfinden der Realität benutzt. Daraus Resultierende Vorteile sind ein visuell verständliches Aufgabenkonzept, leichte Erlernbarkeit, leichtes Erinnern, Fehlervermeidung und eine Ermutigung zur Exploration. Ein Geniestreich der direkten Manipulation ist z.B. die Desktopmetapher. Wer weiß, dass ein Schreibtisch zum Arbeiten mit Papieren und Ordnern gemacht ist, der wird mit der virtuellen Schreibtischumgebung auf dem Bildschirm schnelle Erfolge haben.
Soeben ist auch das Stichwort Metapher gefallen. Sie sind auch außerhalb der virtuellen Welt eine wertvolle Denkhilfe. Gelingt es durch sorgfältiges Design eine visuelle Repräsentation der Hand-lungswelt zu schaffen, können die Aufgaben der Anwender ernorm vereinfacht werden, weil die direkte Manipulation ver-trauter Objekte möglich wird. Auf Grund der Kürze unseres Projektes NORMA konnten wir leider keine adäquate Re-präsentation in Form von Iconschaltflächen entwickeln. Lediglich eine kleine Ampel symbolisiert den Drei-Phasen-Prozess und deutet die reale Ablauffolge des Schreibprozesses in den Phasen Recherchieren, Konstruieren und Formulieren an (Abb. 2).
Abbildung 2 – Metapher zur Nutzerunterstützung
Der Aktionsraum ist framebasiert und arbeitet mit speziell angepassten Risikomodellinstanzen [vgl. Von Frames zu Textbausteinen in diesem Heft]. Verfolgt man einen anderen
Ergonomie
39
Modellierungsansatz [vgl. 2.3.2], so müsste eine Zergliederung in Einzelaufgaben eine Einteilung in die Aktionsräume Risiko-management und Schreiben ermöglichen, die miteinander verbunden sind und kooperieren können.
2.3.2 Das Objekt-Aktions-Interfacemodell
Das OAI-Modell ist eine Design-Theorie, die mit dem Verstehen der Aufgabe beginnt. Die Aufgabe beinhaltet das Universum der Objekte aus der realen Welt. Die Anwender verwirklichen ihre Ziele durch die auf die Objekte angewandten Aktionen [SHNEI-DERMAN:2002b]. Die Ziele dieser Aufgabenobjekte können das Identifizieren, Analysieren oder Bewerten eines Risikos sein oder aber das Produzieren einer Risikoinformation bzw. die Ausgabe eines Sicherheitskapitels. Die Aufgabenaktionen beginnen immer auf der obersten Ebene und werden in Zwischenziele und einzelne Schritte zergliedert. Das geht soweit, dass atomare Einheiten, wie Gurtstraffer, Gurtschloss oder Stromkabelstecker individuell attributierbar werden [vgl. Abbildung 3].
Ergonomie
40
Abbildung 3 – Das OAI-Modell [vgl. Shneiderman 2002b:250]
Bei diesem Ansatz muss der Anwender wesentliche Kenntnisse über die Aufgabe erwerben. So ist besonderes Augenmerk auf die Vermittlung des erforderlichen Wissens zu legen. Was Risiko-management ist, wie man Gefahren graduiert, wie entsteht Text, was Schadenskompensation bedeutet und vieles mehr ist nicht einfach so in der Welt des Nutzers vorhanden. Der Vorteil des OAI-Modells liegt darin, dass der Anwender durch das direkt manipulative Interface nur wenig Wissen zur Bedienung des Systems oder anders gesagt beim Verwirklichen seiner Ziele benötigt. Bereichert man das System zusätzlich um didaktisch aufbereitete Dokumentationen in Form von durchdachten Online-
Ergonomie
41
Hilfen und wohlstrukturierten Handbüchern (Doku-Sets), ist die Nutzerorientierung nahezu gelungen. Nahezu weil die Zielgruppe letztendlich ein spezifisches Klientel ist, deren Kenntnisstand zur Bedienung der Software angereichert werden muss. Ist der Nutzer dagegen nicht Angehöriger der Zielgruppe, sollte es zwar auch ihm möglich sein mit der Software Ergebnisse zu produzieren, aber ein gewisser Mehraufwand für die mentale Modellbildung ist gerechtfertigt. Dem Technischen Redakteur zu erklären wie er mit der Maus an Schaltfläche X zu navigieren hat, um dann einen Doppelklick auszuführen, geht an der fokussierten Zielgruppe vorbei, für den totalen Computerneuling wäre es jedoch das angemessene Erklärungsniveau. Angedeutet ist damit das Prinzip der Vielfalt der Anwender. Vor Beginn des Designs muss der Anwender so genau wie möglich charakterisiert werden, denn kein Design kann alle Nutzer gleichzeitig zufrieden stellen.
Das OAI-Modell beginnt mit dem Verstehen der Aufgabe. Wie auch beim Problemlösen [vgl. 1.3], werden Ziele in Teilziele zerlegt, die Stück für Stück zur Lösung der Aufgabe führen. Das Konzept, Objekte zu finden, mit denen sich das zu beschreibende Universum abbilden lässt, harmoniert einerseits mit den Konzepten der objektorientierten Programmierung. Andererseits führt im idealen Fall das Finden der benötigten Objekte auch zu den hilfreichen Metaphern, die es sowohl Novizen als auch Experten erlauben Ziele zu finden und Lösungen zu generieren.
2.4 Designpraxis und -prozess
Design ist ein kreativer Prozess, für den es keine absolut klaren Vorgehensweisen gibt. Dennoch haben sich verschiedene Richtlinien und Methoden bewährt, die einen geordneten Ablauf und ein konstruktives Miteinander fördern. Je größer und
Ergonomie
42
komplizierter das Vorhaben, umso wichtiger wird es, ein so genanntes Pflichtenheft zu erarbeiten, weiterzuentwickeln und einzuhalten. Die Koordination und auch Kooperation der Beteiligten wie Designer, Programmierer, Wissensingenieure, Manager und vielleicht auch Technische Redakteure soll letztendlich zu einer erfolgreichen Software führen, für die die Nutzer bereit sind viel Geld zu bezahlen. Die Zielsetzungen in der Designpraxis sind variabel und schließen das Finden neuer Ziele gezielt mit ein. Entgegen der Aufgabenfindung und Objektbildung ist der Design-Prozess nicht in hierarchischen Strukturen abbildbar. Weder strikte Top-Down- noch Bottom-Up-Verfahren machen den Designprozess beschreibbar. Er ist dynamisch. Es gibt eine anschauliche Metapher, die SHNEIDERMAN (2002b:130) mit den drei Säulen des Designs beschreibt. Das Fundament ist akademische Forschung. Darauf stehen 3 Säulen:
• Theorien und Modelle (Richtlinien und Teil-prozessbeschreibungen),
• Algorithmen und Prototypen (Software-Werkzeuge) sowie
• Expertenüberprüfung und Usabilitytests.
Diese drei Säulen stützen die erfolgreiche Softwareoberfläche.
Um das Was des Designprozesses anzudeuten, ein paar wesentliche Topics aus einem fiktiven Pflichtenheft, das den Designprozess als Leitfaden begleiten könnte.
• Wording (konsistent versprachlichte Menüs, Schalt-flächen und Dialogboxen)
• Schriftsatz (Arten, Größe, Stile),
• Icons, Grafiken und Linienstärken,
Ergonomie
43
• Farben, Hintergründe, Hervorhebungen,
• Bildschirmlayout (Widget-Sets 3) zzgl.
� Leerraumfestlegungen (im Sinne von kognitiven Erholungszonen),
� Abstandsfestlegungen,
� Advanced Organizer (je nach Bedarf auch in Form von Metanavigation),
� Dateneingabeformate und Anzeigefor-mate für Listen, Tabellen, Überschriften,
• Ein- und Ausgabe:
� Cursorwechsel bei Aktionen,
� visuelle Feedbackmaßnahmen,
� Ereignisklänge (auditives Feedback),
� Reaktionszeiten für verschiedene Auf-gaben.
• Handlungssequenzen:
� direkte Manipulation (Klicken, dragen und dropen),
� Befehlssyntax, Funktionstasten,
� Prozeduren zur Fehlerbeseitigung und Wiederherstellung.
3 Die Zusammenstellung der erforderlichen Bedienelemente und ggf. die Spezifikation
neuer Bedienelemente.
Ergonomie
44
• Festlegungen für die Wissensbildung:
� Online-Hilfe,
� Tutorial,
� Handbuch,
� Schulungsunterlagen.
Da für das Wie in diesem Textstudioheft nicht genug Raum ist, möchte ich einen ganz wesentlichen Punkt für das Warum nennen: Für alle Beteiligten sichert das Pflichtenheft einen sozialen Prozess und kooperativen Transfer, der im besten Fall kontrolliert zu einer nutzerorientierten Software führt.
Die Qualität von Software kann zusätzlich durch aktives Risikomanagement verbessert werden. Dazu gibt es verschiedene Standards (vgl. GINDI 2003:38-42), die zu insgesamt erfolgreichen IT-Projekten führen können.
Software-Design ist Kunst, die sich nützlich macht, die Pfade zum Ziel legt und die Ziele als Leuchttürme darstellen kann.
Literaturverzeichnis
45
Literaturverzeichnis
ANDERSON, John R. 1996. Kognitive Psychologie. 2. Auflage. Spektrum Akademischer Verlag, Heidelberg, Berlin, Oxford.
COE, Marlana 1996. Human Factors - for Technical Communicators. Wiley, New York.
CSIKZENTMYHALYI, Mihalyi 1977. Beyond Bordedom and Anxiety. Jossy-Bass, San Francisco.
CSIKZENTMYHALYI, Mihalyi 1999. Flow das Geheimnis des Glücks. 8. Auflage. Klett-Cotta, Stuttgart.
EN ISO 9241-10 1995. Grundsätze der Dialoggestaltung. Euro-päisches Komitee für Normung, Brüssel.
GINDI, George 2002. Weitsicht durch Risiko – Wandel von Risiken zu Chance und Gewinn mit Normen und Gesetzen. Textstudio-heft 7. Hannover, Fachhochschule Hannover.
GINDI, George 2003. Normen zu NORMA – Über das Wahrnehmen und Kommunizieren von Risiken. Textstudio-heft 8. Hannover, Fachhochschule Hannover.
PAIVIO, Allan 1986. Mental representations: A dual-coding approach. New York, Oxford: Oxford University Press.
SHNEIDERMAN, Ben 2002a. Leonardo's Laptop. The MIT Press, Cambridge Massachusetts/London England.
SHNEIDERMAN, Ben 2002b. User Interfacedesign. 3. Auflage, mitp-Verlag, Bonn.
NELSON, Ted 1980. Interactive systems and the design of virtuality. In: Creative Computing, 6,II. S. 56ff.
Literaturverzeichnis
46
VAN WELIE, Martijn 2002. www.welie.com/patterns – Inter aktiondesign, HCI-Patterns für GUI und Web.
ZIMBARDO Philip G./RUCH Floyd L. 1974. Lehrbuch der Psychologie. Springer, Berlin-Heidelberg-New York.
Textstudioreihe
47
Heft 1 ANNELY ROTHKEGEL (1996):
Hypertextproduktion – Ein Überblick
Heft 2 MICHAEL SCHMITT (1996): Supporting formulation: a practical tool for technical writers
Heft 3 SABINE ZIMMERMANN (1996): Linguistische Strukturanalyse technischer Texte
Heft 4 ANNELY ROTHKEGEL et al. (1997):
Grundlagen, Beschaffung, Organisation und Darstellung von Informationen
Heft 5 CLAUDIA VILLIGER (1999): Lexikurs – Lexikalisierung im Diskurs
Heft 6 ANNELY ROTHKEGEL (2002): Das Autorensystem NORMA – nutzerorientiertes Risikomanagement
Heft 7 GEORGE GINDI (2002): Weitsicht durch Risiko
Heft 8 GEORGE GINDI (2003): Normen zu NORMA
Heft 9 CLAUDIA VILLIGER (2003): Vom Risikomodell zur Sprachhandlung
Heft 10 VOLKERT BROSDA/GEORGE GINDI (2003):
Von Frames zu Textbausteinen/Interface
