Bedienkonzepte für ein zukünftiges PMX.

Transcrição

Diplomarbeit
Fachhochschule Karlsruhe – Hochschule für Technik
Fachbereich Informatik
Bedienkonzepte für ein zukünftiges PMX
Ulrich Schmid
Propack Data GmbH
Vincenz-Prießnitz Straße 1
76131 Karlsruhe
Referent:
Prof. Klaus Gremminger
Koreferent: Prof. Dr. Peter A. Henning
Betreuer:
Dr. August Ludviksson
Dipl.-Inform. Wolfgang Schmitt
Inhalt
Abbildungsverzeichnis ..............................................................................................I
Tabellenverzeichnis .................................................................................................III
Erklärung.................................................................................................................. IV
Zusammenfassung................................................................................................... V
Abstract.................................................................................................................... VI
1
Einleitung ............................................................................................................1
1.1 Aufgabenbeschreibung......................................................................................1
1.2 Die Propack Data GmbH ...................................................................................2
1.3 Gliederung der Arbeit ........................................................................................3
2
Software-Ergonomie und Usability Engineering..............................................4
2.1 Software-Ergonomie..........................................................................................4
2.1.1 Richtlinien und Normen auf nationaler Ebene ...................................................... 5
2.1.2 Richtlinien und Normen auf internationaler Ebene ............................................... 6
2.2 Usability Engineering .........................................................................................8
2.2.1 Analyse................................................................................................................ 8
2.2.2 Design ............................................................................................................... 13
2.2.3 Usability Evaluation............................................................................................ 15
3
Stand der Technik von Dialogsystemen .........................................................17
3.1 Grafische Benutzeroberflächen .......................................................................17
3.1.1 Standard Interaktionskomponenten ................................................................... 17
3.1.2 Wizards.............................................................................................................. 25
3.1.3 Direkte Manipulation .......................................................................................... 26
3.2 Neue Dialogtechniken......................................................................................27
3.2.1 Treibende Kräfte ................................................................................................ 27
3.2.2 Neue Dialogkomponenten.................................................................................. 27
3.2.3 Fisheye-View ..................................................................................................... 30
3.2.4 Zoombare User Interfaces - ZUI......................................................................... 32
3.2.5 Virtuelle Realität und 3D User-Interfaces ........................................................... 33
3.2.6 Adaptive Systeme .............................................................................................. 34
3.2.7 Akustische Interaktion - Sprache........................................................................ 36
3.2.8 Gestenbasierte Interaktion ................................................................................. 39
3.2.9 Haptische Eingabegeräte................................................................................... 39
3.2.10
Weitere innovative Interaktionsformen............................................................ 40
3.3 Höhere Qualitäten - Joy of use ........................................................................40
3.3.1 Gründe warum Software Freude machen sollte: ................................................ 41
3.3.2 Hedonistische Qualitäten ................................................................................... 41
3.3.3 Semantic Differential.......................................................................................... 42
3.4 Psychologische Aspekte - Wahrnehmungspsychologie...................................43
3.4.1 Farbpsychologie ................................................................................................ 43
3.4.2 Gestaltpsychologie............................................................................................. 46
4
CTM – Clinical Trial Management ....................................................................49
4.1 EDB – die Engineering Database von CTM.....................................................49
4.1.1 Master Data Management.................................................................................. 49
4.1.2 Versionskontrolle ............................................................................................... 50
4.1.3 Herstellungs- und Verpackungsanweisungen .................................................... 50
4.1.4 Management von Studien .................................................................................. 51
4.1.5 Design, Pflege und Ausdruck von mehrsprachigen Etiketten ............................. 52
4.2 Analyse............................................................................................................53
4.2.1 Das bestehende Bedienkonzept ........................................................................ 53
4.2.2 Schwachstellen des gegenwärtigen Bedienkonzeptes ....................................... 55
4.2.3 Analyse der Benutzer......................................................................................... 58
4.2.4 Aufgabenanalyse ............................................................................................... 60
5
Design und Implementierung...........................................................................68
5.1 Die Lücke zwischen Analyse und Design ........................................................68
5.2 Konzeptuelles Design ......................................................................................68
5.2.1 Wizard-Konzept für das Anlegen von Studiendaten ........................................... 69
5.2.2 Modus für das Editieren von Studiendaten......................................................... 69
5.3 Visuelles Design – Implementierung von Prototypen ......................................72
5.3.1 Java Swing ........................................................................................................ 72
5.3.2 Implementierung eines Editier-Konzeptes.......................................................... 74
5.3.3 Realisierung des Wizard-Konzeptes .................................................................. 86
6
Evaluierung der Prototypen .............................................................................97
6.1 Aufgabenstellung .............................................................................................97
6.2 Durchführung der Evaluierung.........................................................................99
6.2.1 Teilanlegen der Studiendaten ............................................................................ 99
6.2.2 Editieren der Studiendaten............................................................................... 101
6.2.3 Vollständiges Anlegen der Studiendaten.......................................................... 101
6.2.4 Schlussfolgerung ............................................................................................. 101
6.3 Hedonistische Qualität des neuen Konzeptes ...............................................102
7
Bewertung und Ausblick................................................................................103
7.1 Bewertung der neuen Konzepte ....................................................................104
7.2 Ausblick .........................................................................................................105
A
Literaturverzeichnis........................................................................................107
Abbildungsverzeichnis
Abbildung 1.1: Propack-Data................................................................................................. 2
Abbildung 1.2: Produktions Management mit PMX ................................................................ 2
Abbildung 2.1: Iterativer Prozess des Usability Engineering .................................................. 8
Abbildung 2.2: Task Trees [Welie01] ................................................................................... 11
Abbildung 2.3: Aktivitätendiagramm [Welie01]..................................................................... 12
Abbildung 2.4: Kollaborationsdiagramm[Welie01]................................................................ 12
Abbildung 3.1: Ergänzung der Mauszeigers [Wessel98] ...................................................... 24
Abbildung 3.2: Animation eines Prozesses [Wessel98] ....................................................... 25
Abbildung 3.3: Window Shade Container – closed [Hudson97] ........................................... 28
Abbildung 3.4: Window Shade Container – opened [Hudson97].......................................... 28
Abbildung 3.5: IBM RealPhone [IBM]................................................................................... 29
Abbildung 3.6: JGraph [Sun01]............................................................................................ 30
Abbildung 3.7: Fisheye Menu [HCIL00] ............................................................................... 31
Abbildung 3.8: Hyperbolic Browser [inxight02]..................................................................... 31
Abbildung 3.9: Zoombares User Interface – Großansicht [HCIL00] ..................................... 32
Abbildung 3.10: Zoombares User Interface – Detailansicht [HCIL00]................................... 32
Abbildung 3.11: Task Gallery[Micros00] .............................................................................. 33
Abbildung 3.12: Conetree [Geisler98] .................................................................................. 34
Abbildung 3.13: antropomorpher Agent [TUD00] ................................................................. 36
Abbildung 3.14: Nähe .......................................................................................................... 47
Abbildung 3.15: Geschlossenheit ........................................................................................ 47
Abbildung 3.16: Ähnlichkeit ................................................................................................. 47
Abbildung 3.17: Kontinuität.................................................................................................. 48
Abbildung 3.18: Erfahrung ................................................................................................... 48
Abbildung 4.1: Herstellungs - und Verpackungsanweisung [PD01a].................................... 50
Abbildung 4.2:Snapshot - Medikations-Matrix...................................................................... 52
Abbildung 4.3: Abhängigkeiten der Objekte [PD01a] ........................................................... 54
Abbildung 4.4: Snapshot - Hauptfenster der CTM-EDB ....................................................... 56
Abbildung 4.5: Snapshot - Auswahlliste mit Selektionsfeldern ............................................. 57
Abbildung 4.6: Abhängigkeiten der Objekte in der CTM-EDB .............................................. 58
Abbildung 4.7: Snapshot - Dialogfenster einer Studie.......................................................... 58
-I-
Abbildung 4.8: Tasktree - Hauptaufgaben von CTM ............................................................ 60
Abbildung 4.9: Tasktree - Management von Studiendaten................................................... 61
Abbildung 4.10: Datenbankdiagramm der Studiendaten ...................................................... 62
Abbildung 4.11: Aktivitätsdiagramm - Anlegen von Studiendaten ........................................ 63
Abbildung 4.12: Aktivitätsdiagramm - Durchführen der Randomisierung ............................. 64
Abbildung 4.13: Tasktree - Anlegen eines Medikationskopfes ............................................. 65
Abbildung 4.14: Snapshot - Unübersichtlichkeit des bestehenden Systems ........................ 66
Abbildung 5.1: Papierentwurf - Eingangsdialog ................................................................... 70
Abbildung 5.2: Papierentwurf - 1. Editierkonzept ................................................................. 70
Abbildung 5.3: Papierentwurf - 2. Editierkonzept ................................................................. 71
Abbildung 5.4: MVC-Konzept in der Theorie [Schlie99] ....................................................... 73
Abbildung 5.5: MVC-Konzept von Java-Swing [Schlie99] .................................................... 74
Abbildung 5.6: Übersichtsgraph........................................................................................... 75
Abbildung 5.7: Klassendiagramm - Datasource ................................................................... 76
Abbildung 5.8: Klassendiagramm - JApplicationFrame........................................................ 77
Abbildung 5.9: Eingangsdialog des neuen Konzeptes ......................................................... 78
Abbildung 5.10: Klassendiagramm - Explorer ...................................................................... 79
Abbildung 5.11: Sequenzdiagramm - Zusammenspiel der Objekte...................................... 83
Abbildung 5.12: Klassendiagramm - Editier-Sichten ............................................................ 84
Abbildung 5.13: Klassendiagramm - JCTMNode ................................................................. 85
Abbildung 5.14: Papierentwurf für das Wizardkonzept......................................................... 87
Abbildung 5.15: Snapshot des Wizardkonzeptes................................................................. 88
Abbildung 5.16: Snapshot - Anlegen von Medikationen und Medikationskennungen........... 89
Abbildung 5.17: Snapshot - Statuswechsel.......................................................................... 90
Abbildung 5.18: Snapshot - Eingangsdarstellung des Wizard.............................................. 91
Abbildung 5.19: Klassendiagramm - IncompleteStudy......................................................... 92
Abbildung 5.20: Sequenzdiagramm - Anlegen neuer Studiendaten ..................................... 93
Abbildung 5.21: Sequenzdiagramm - Wiederaufnahme des Anlegevorgangs...................... 94
Abbildung 6.1: Snapshot - Aufruf des Wizard-Modus........................................................... 99
Abbildung 6.2: Snapshot - Vorzeitiges Verlassen des Wizard-Modus ................................ 100
- II -
Tabellenverzeichnis
Tabelle 3.1: Semantic Differential ........................................................................................ 42
Tabelle 4.1: Vergleich mit Richtlinien und Normen............................................................... 56
Tabelle 6.1: Beurteilung nach der Technik des Semantic Differential................................. 102
Tabelle 7.1: Vergleich des neuen Konzeptes mit Richtlinien und Normen ......................... 105
- III -
Erklärung
Hiermit erkläre ich, dass ich die vorliegende Diplomarbeit mit dem Titel ‘Bedienkonzepte für
ein zukünftiges PMX’ selbständig und ausschließlich unter Verwendung der angegebenen
Literatur verfasst habe. Die Arbeit wurde in gleicher oder ähnlicher Form keiner anderen
Prüfungsbehörde zum Erlangen eines akademischen Grades vorgelegt.
Karlsruhe, den 25. Februar 2002
Ulrich Schmid
- IV -
Zusammenfassung
Thema dieser Diplomarbeit ist die Evaluierung moderner Bedienkonzepte sowie der darauf
aufbauende Entwurf eines neuen Benutzerdialoges für ein zukünftiges PMX-System.
Hierzu wird zunächst untersucht welche Eigenschaften ein gut zu bedienendes und
benutzerfreundliches Softwaresystem auszeichnen. In diesem Zusammenhang wird der
Begriff der Software-Ergonomie aufgrund von bestehenden Richtlinien und Normen genau
definiert. Darauf folgend wird die Vorgehensweise des Usability Engineering beschrieben.
Hierbei handelt es sich um einen iterativen Prozess, der es ermöglicht von einer gegebenen
Aufgabenstellung zum letztendlichen ergonomischen Bedienkonzept zu gelangen.
Anhand von Literatur- und Internetrecherche wurde untersucht, welche Möglichkeiten der
Gestaltung von Benutzerschnittstellen es gibt. Zudem wurde nach neuen Dialogtechniken
gesucht, die es ermöglichen große Datenmengen und komplexe Datenstrukturen
übersichtlich darzustellen. Im Kapitel Stand der Technik von Dialogsystemen werden die
dabei gewonnenen Ergebnisse aufgezeigt. Unter dem Begriff des Joy of use werden neue,
höher gesteckte Qualitäten bei der Entwicklung moderner Benutzerdialoge vorgestellt. Da
zudem auch psychologische Aspekte eine Rolle spielen, wird abschließend auf die Gebiete
Farbpsychologie sowie Gestaltpsychologie eingegangen.
Im praktischen Teil wird für die Aufgabenstellung des Managements von Studiendaten ein
neues Bedienkonzept entworfen. Hierzu erfolgt, entsprechend der Methodik des Usability
Engineering, zunächst die Analyse der Benutzer sowie die Aufgabenanalyse. Aufbauend auf
den Analyseergebnissen werden dann konzeptuelle Entwürfe verschiedener Bedienkonzepte
erstellt, von denen ein Teil mit der Grafikbibliothek Java-Swing umgesetzt wird. Um einen
Iterationszyklus des Usability Engineerings zu vervollständigen, erfolgt zum Abschluss noch
die Evaluierung anhand einer Testperson.
-V-
Abstract
Subject of this thesis is the evaluation of modern usability concept as well as the design of a
new user interface prototype for a future PMX system.
At first there will be investigated which properties mark a well to use and user-friendly
software system. In this context the term “software ergonomics” will be specified based on
rules and standards. The approach of usability engineering describes an iterative process,
which enables getting from a task to the appropriate ergonomic user interface. This approach
will be described additionally.
Based on a literature and internet inquiry different approaches towards the design of a user
interface were investigated. Furthermore we searched for new presentation techniques that
enable the concise display of large amounts of data as well as complex data structures. In
the chapter Stand der Technik von Dialogsystemen the results of this inquiry are presented.
Under the term joy of use new and higher qualities in developing modern user interfaces will
be pointed out. As additional psychological aspects are also relevant, the fields of color
psychology as well as gestalt psychology will be touched upon.
In the practical part of this thesis prototypes for a new usability concept for the task of
management of studydata will be designed. Following the methodology of usability
engineering the analysis of users and tasks will be carried out. Based on the results of this
analysis conceptual designs of different usability concepts will be created. Parts of these
concepts will be implemented in the graphical library Java Swing. To complete one iterative
cycle of the usability engineering process the step of evaluating the prototypes will be carried
out with a test person.
- VI -
1 Einleitung
“To the user, the system is the interface.”
unbekannt
Durch den rasanten Fortschritt der Informationstechnologie werden immer neue und
komplexere Aufgaben durch den Computer übernommen und immer größere Datenmengen
müssen verwaltet werden. Menschen müssen sich mit einer Vielzahl von Systemen zurecht
finden und es bleibt oft keine Zeit sich in diese entsprechend einzuarbeiten. Zudem ist es
dem Benutzer nicht mehr zumutbar sich die Bedienschritte der verschiedensten, immer
komplexeren Produkte zu merken.
Diese Umstände verlangen es, die Benutzung moderner Softwaresysteme so weit wie
möglich zu vereinfachen und intuitiv zu gestalten. Die Benutzung eines Systems sollte
problemlos möglich sein und nicht vom eigentlichen Ziel, der Durchführung einer Aufgabe,
ablenken. Ist dies nicht gegeben wird der Nutzer sehr schnell in die Rolle des „Be-Dieners“
gezwängt und ihm ein Gefühl der Abhängigkeit vom Softwaresystem vermittelt.
Ein im Aussehen und in der Bedienbarkeit gut gestaltetes Softwareprodukt, hat durchaus
auch einen ökonomischen Faktor sowohl für den Hersteller des Systems als auch für den
Käufer. Aus dem Blickwinkel des Herstellers wird sich ein Softwareprodukt, das ein
gelungenes Bedienkonzept besitzt, wesentlich besser verkaufen. Zum einen eben wegen
seiner guten Bedienbarkeit zum anderen aber auch weil die Qualität der Benutzerschnittstelle oft mit der Qualität des eigentlichen Systems gleichgesetzt wird.
Der ökonomische Vorteil des Käufers einer gut zu bedienenden Software liegt auf der Hand.
Einfache Bedienung verkürzt sowohl die Einarbeitungszeit als auch die effektive Zeit des
Benutzens. Zudem steigert ein gelungenes Bedienkonzept die Zufriedenheit der Benutzer,
erhöht dadurch auch die Qualität ihrer Arbeit und wird somit zu einem wesentlichen
Erfolgsfaktor.
1.1 Aufgabenbeschreibung
In dieser Diplomarbeit ist zunächst zu untersuchen welche Eigenschaften eine
Benutzerschnittstelle haben sollte, damit sie optimal bedienbar ist. In diesem
Zusammenhang ist der Begriff der Software-Ergonomie zu klären und anhand von
bestehenden Richtlinien und Normen genauer zu definieren.
Ob es allgemeingültige Vorgehensweisen gibt um von einer Aufgabenstellung zum
entsprechenden gut zu bedienenden Softwaresystem zu gelangen wird darauf folgend
untersucht und dargestellt.
Des weiteren erfolgt eine Aufnahme des Standes der Technik anhand von Literatur- und
Internetrecherche, die zeigen soll, welche verschiedenen Bedienkonzepte und Möglichkeiten
zur übersichtlichen Darstellung großer Datenmengen und komplexer Datenstrukturen es gibt.
Einleitung
2
Dabei ist vornehmlich an die Bedienung grafischer Benutzeroberflächen gedacht aber auch
Spracheingabe sowie gestische Eingabe sollten in die Betrachtungen mit einfließen. Neben
neuen Visualisierungs- und Interaktionsansätzen soll diese Recherche aber auch neue
Qualitäten bei der Gestaltung der Mensch-Technik-Interaktion berücksichtigen.
Da diese Arbeit bei der Firma Propack Data entsteht, werden danach, in Zusammenarbeit
mit Domain-Spezialisten von Propack Data, die besonderen Anforderungen der SoftwareLösung für das Clinical Trial Management (CTM) aufgenommen. Schließlich erfolgt die
iterative Umsetzung der Ergebnisse in Form von Prototypen die dann mit DomainSpezialisten bewertet werden.
1.2 Die Propack Data GmbH
Die Propack Data GmbH wurde 1984 gegründet und ist heute mit seinem System PMX der
weltweit führende Anbieter von Hard- und Software im Bereich des Enterprise Production
Management in der pharmazeutischen Industrie. Zudem findet PMX auch Einsatz in den
Bereichen der Nahrungsmittel- und Getränke-, sowie der kosmetischen und chemischen
Industrie. Im Januar 2002 wurden die bisherigen Gesellschafter von Propack Data durch die
US-amerikanische Firma Rockwell Automation abgelöst.
Abbildung 1.1: Propack-Data
PMX besteht aus den 4 Lösungen Manufacturing Execution System (MES), Clinical Trial
Management (CTM), Research Development Management (RDM) sowie Manufacturing
Quality Service (MQS), die wiederum aus verschiedenen Modulen aufgebaut sind. Diese
verschiedenen integrierten Module, begleiten den gesamten Produktionsprozess, von der
Wirkstoffentdeckung und –entwicklung über klinische Studien bis hin zur Fertigung.
Abbildung 1.2: Produktions Management mit PMX
Das System wurde und wird in enger Zusammenarbeit mit Propack Data’s Kunden entwickelt
und stellt somit einen weltweiten Standard dar. Zudem ist das System in hohem Maße
Einleitung
3
anpassbar und ermöglicht es den unterschiedlichen Anforderungen der Kunden gerecht zu
werden.
Neben der Integration und dem Projektmanagement bietet Propack Data weitere
Dienstleistungen wie beispielsweise Wartung oder Schulung. Zusätzliche Informationen
hierzu sind im Internet unter http://www.propack-data.com zugänglich.
1.3 Gliederung der Arbeit
Im Kapitel 2 Software Ergonomie und Usability Engineering wird zunächst der Begriff der
Software-Ergonomie genauer beschrieben. Zudem wird anhand von bestehenden Richtlinien
und Normen dargestellt welche Eigenschaften ein gut zu bedienendes und
benutzerfreundliches Dialogsystem auszeichnen.
Da das Wissen über die Eigenschaften eines ergonomischen Softwaresystems nicht
ausreicht um später einen gut zu bedienenden und benutzerfreundlichen Prototypen zu
schaffen wird ergänzend in Kapitel 2 die Vorgehensweise des Usability Engineering
beschrieben. Hierbei handelt sich um eine festgelegte Methodik um von einer gegebenen
Aufgabenstellung zum entsprechenden ergonomischen System zu kommen.
Darauf folgend wird in Kapitel 3 Stand der Technik von Dialogsystemen zunächst auf die
Grundbestandteile gegenwärtiger grafischer Benutzeroberflächen eingegangen und erläutert
wie diese sinnvoll eingesetzt werden.
Ziel dieser Arbeit war es auch, aufgrund von Literatur- und Internetrecherche neue
Möglichkeiten der Visualisierung, sowie darüber hinaus neue Interaktionstechniken zu
finden. Da die Ergebnisse dieser Recherche sehr vielfältig waren, werden hier hauptsächlich
Möglichkeiten und Techniken aufgeführt, die in einem neuen Bedienkonzept für das System
PMX in Frage kommen könnten.
Des weiteren werden in Kapitel 3 unter dem Begriff des Joy of use neue Qualitäten bei der
Gestaltung von Benutzerschnittstellen vorgestellt sowie psychologische Aspekte erläutert.
Die späteren Prototypen eines neuen Bedienkonzeptes wurden für die Aufgabenstellung des
Managements von Studiendaten geschaffen. In Kapitel 4 CTM – Clinical Trial Management
wird deshalb die CTM-Lösung von PMX vorgestellt, in der diese Aufgabenstellung realisiert
ist. Anschließend erfolgt, basierend auf der in Kapitel 2 vorgestellten Methodik des Usability
Engineering, die Benutzer- und Aufgabenanalyse.
In Kapitel 5 Design und Implementierung wird der Entwurf verschiedener Konzepte
aufbauend auf den Analyseergebnissen anhand von textuellen Beschreibungen aber auch
durch Papier-Prototypen und Snapshots näher erläutert. Aufbauend auf den konzeptuellen
Entwürfen wurden zwei Prototypen umgesetzt. Diese realisierten die beiden folgenden Modi:
·
·
Wizard-Modus zum Anlegen von Studiendaten
Editier-Modus zum Ändern und Ergänzen von Studiendaten
Die Realisierung dieser Modi wird textuell und anhand von Diagrammen sowie CodeBeispielen dokumentiert.
Nach der Implementierung der Prototypen wurden diese entsprechend der Methodik des
Usability Engineering einer Testperson vorgeführt und ausgewertet. Kapitel 6 Evaluierung
der Prototypen beschreibt diesen Schritt und zeigt die Testergebnisse.
2 Software-Ergonomie und Usability
Engineering
„Sind ihre User alle Vollidioten?“
Worte eines Programmierers
Um eine optimal zu bedienende Benutzerschnittstelle realisieren zu können, ist es wichtig
Kenntnis darüber zu haben, welche Kriterien ein solches System erfüllen muss. Unter dem
Begriff der Software-Ergonomie werden diese Eigenschaften eines guten Bedienkonzepts im
folgenden dargestellt.
Neben dem Wissen welche Qualitäten ein ergonomisches System auszeichnen, ist es
zudem wichtig eine Vorgehensweise an der Hand zu haben, die es ermöglicht von einer
gegebenen Aufgabenstellung zur entsprechenden gut zu bedienenden Benutzerschnittstelle
zu gelangen. In diesem Zusammenhang wird der Entwicklungsprozess des Usability
Engineering vorgestellt und seine Möglichkeiten untersucht.
2.1 Software-Ergonomie
Gleichbedeutend für die Begriffe Bedienbarkeit, Benutzerfreundlichkeit oder Usability steht
heute der Begriff der Software-Ergonomie. Bei dem Begriff Ergonomie geht es um die
Anpassung der Arbeitsaufgaben, des Arbeitsumfeldes und der Hilfsmittel an die physischen
und psychischen Fähigkeiten des arbeitenden Menschen. Ziel ist es Gesundheit, Sicherheit,
Wohlbefinden und Leistungsvermögen des Menschen zu verbessern. Aus diesem Grund
greift die Software-Ergonomie neben den Kenntnissen aus der Informatik auch auf das
Wissen aus der Psychologie und den Arbeitswissenschaften zurück.
Ergonomie u. Ergonomik = Wissenschaft von den Leistungsmöglichkeiten und grenzen des arbeitenden Menschen sowie der besten wechselseitigen Anpassung
zwischen dem Menschen und seinen Arbeitsbedingungen
nach Duden, Band 5, Das Fremdwörterbuch
Einfach formuliert zeichnet sich eine optimale ergonomische Software dadurch aus, dass sie
an den Benutzer angepasst ist. Natürlich ist diese Forderung nie komplett zu erfüllen, da die
Benutzer einer Software verschiedene individuelle Eigenschaften und Fähigkeiten besitzen.
Trotzdem kann bei der Entwicklung einer Benutzerschnittstelle auf die verschiedenen Typen
von Benutzern eingegangen und ein Höchstmaß an Anpassung angestrebt werden.
Software-Ergonomie und Usability Engineering
Die Erkenntnisse aus der Software-Ergonomie sind in verschiedenen Normen und Richtlinien
definiert. Grundsätzlich bieten Normen und Richtlinien bei der Gestaltung ergonomischer
Software die Möglichkeit die Erfahrungen verschiedener Projekte zu sammeln und
Schnittstellen zu vereinheitlichen. Laut [Mekel01] können Gesetze, Richtlinien und Normen
folgende Funktionen erfüllen:
·
·
·
Sie sind ein Hilfsmittel, um unterschiedliche Beiträge zu koordinieren und zu
vereinheitlichen.
Entscheidungen müssen nur einmal gefällt werden und nicht immer wieder aufs Neue,
entsprechend der Kenntnisse und Ansichten der gerade Beteiligten. Außerdem lassen
sich Entscheidungen durch eine Richtlinie gut kommunizieren.
Zudem lassen sich detaillierte Anforderungskataloge aufstellen, die umfangreiche
Erfahrungen berücksichtigen. Diese dienen gleichzeitig als Grundlage der Prüfung von
Zwischenstadien und des Endprodukts.
Im folgenden werden nun die für die Entwicklung von Benutzerschnittstellen wichtigsten
Richtlinien und Normen aufgeführt:
2.1.1
Richtlinien und Normen auf nationaler Ebene
VDI-Richtlinie 5005: Software-Ergonomie in der Bürokommunikation
Der VDI definiert drei Kriterien, die bei einer software-ergonomischen Systemgestaltung
gemeinsam in ausreichendem Maß erfüllt sein müssen [Mekel01]:
1. Kompetenzförderlichkeit:
Die software-ergonomische Gestaltung der Mensch-Rechner-Interaktion soll dazu
beitragen, dem Benutzer einen kompetenten Umgang mit dem System zu ermöglichen
und damit seine Handlungskompetenz zu fördern. Handlungskompetenz bedeutet, dass
sich der Benutzer Wissen über das System und seine organisatorische Einbettung
erworben hat und dass er dieses Wissen auf die von ihm zu erfüllenden Aufgaben
beziehen kann. Das Erwerben einer solchen Handlungskompetenz erfolgt durch
Lernprozesse. Weitere Anforderungen aus diesem Kriterium heraus sind: Abbildung
vertrauter Aufgabenbereiche; Verständlichkeit der Systemfunktionalität; konsistente
handlungsunterstützende Benutzeroperationen; verständliche Ein- und AusgabeAktionen.
2. Handlungsflexibilität:
Ein Bürosystem wird dann als flexibel angesehen, wenn es so ausgelegt ist, dass der
Benutzer auch bei einer geänderten Aufgabenstellung seine Arbeit noch effizient mit
demselben System erledigen kann, dem Benutzer das Erfüllen einer bestimmten
Aufgabe auf alternativen Wegen ermöglicht, die er entsprechend seinem wechselnden
Kenntnisstand und seiner aktuellen Leistungsfähigkeit wählen kann, unterschiedlichen
Benutzern mit unterschiedlichem Erfahrungshintergrund das Erfüllen ihrer Aufgaben auf
alternativen Wegen ermöglicht.
Weitere Anforderungen aus diesem Kriterium heraus sind: Anpassungsfähigkeit an neue
Aufgaben; Zulässigkeit individueller Arbeitsobjekte; alternative Benutzeroperationen;
freizügige Informations-Ein- und -Ausgaben.
5
3. Aufgabenangemessenheit:
Sie wird durch folgende zwei Fragen bestimmt:
· Kann der Benutzer die Zielsetzung seiner Aufgabe überhaupt mit dem System oder
der Anwendung erreichen oder muss er andere Systeme oder Medien zu Hilfe
nehmen (Mediensprünge: z.B. Speicherung von Zwischenergebnissen auf Papier)?
· Mit welchem Planungs- und Zeitaufwand (einschließlich des Aufwandes zur Korrektur
von Fehlern) sowie mit welcher Qualität des Arbeitsergebnisses kann dieses Ziel
erreicht werden?
Weitere Anforderungen dieses Kriteriums sind: Unterstützung grundlegender
Büroaufgaben; aufgabenangepasste Büroobjekte und -funktionen; Effizienz der
Benutzeroperationen; aufgabengerechte Informations-Ein und Ausgabe.
DIN 66 234:
Bildschirmarbeitsplätze, Grundsätze ergonomischer
Dialoggestaltung
Diese Norm ist in die ISO 9241 Teil 10 eingegangen. Daher hat sie als Norm nicht mehr den
Stellenwert, inhaltlich gilt sie durch die ISO 9241 um so mehr.
2.1.2
Richtlinien und Normen auf internationaler Ebene
ISO 9241 Teil 10 - Ergonomic requirements for office work with visual
display terminals
Bei der Erstellung von Dialogabläufen bietet diese Norm sieben Grundsätze, die als
richtungweisende Orientierung dienen sollen [Mekel01]:
1. Aufgabenangemessenheit
Ein Dialog ist in dem Maße aufgabenangemessen, wie er den Benutzer unterstützt, seine
Arbeitsabläufe effektiv und effizient zu erledigen.
2. Selbstbeschreibungsfähigkeit
Ein Dialog ist in dem Maße selbstbeschreibungsfähig, wie jeder einzelne Dialogschritt
durch Rückmeldung unmittelbar verständlich ist oder dem Benutzer erklärt wird, wenn er
die entsprechende Information verlangt.
3. Steuerbarkeit
Ein Dialog ist in dem Maße steuerbar, wie der Anwender in der Lage ist, den gesamten
Dialogablauf zu beeinflussen.
4. Erwartungskonformität
Ein Dialog ist in dem Maße erwartungskonform, wie er den Kenntnissen aus bisherigen
Arbeitsabläufen, der Ausbildung und den Erfahrungen des Benutzers sowie allgemein
anerkannten Konventionen entspricht.
6
5. Fehlerrobustheit (-toleranz)
Ein Dialog ist in dem Maße fehlerrobust, wie das beabsichtigte Arbeitsergebnis trotz
erkennbar fehlerhafter Eingaben mit minimalen oder ganz ohne Korrekturaufwand
erreicht wird.
6. Individualisierbarkeit
Ein Dialog ist in dem Maße individualisierbar, wie er Anpassungen an individuelle
Benutzerbelange und Benutzerfähigkeiten in Hinblick auf seine Arbeitsaufgabe zulässt.
7. Lernförderlichkeit
Ein Dialog ist in dem Maße lernförderlich, wie er dem Benutzer während des Erlernens
Unterstützung und Anleitung gibt.
Regeln von Shneiderman:
Im Zusammenhang mit der Definition des Begriffes Software-Ergonomie wird auch häufig auf
die „8 goldenen Regeln“ für das Design von Benutzerschnittstellen von Ben Shneiderman
verwiesen [Shneid99]. Hier die Regeln und ihre Bedeutung im einzelnen:
1. Streben nach Konsistenz
Ein Bedienkonzept sollte eine einheitliche Terminologie und einen einheitlichen Aufbau
besitzen.
2. Anbieten von Shortcuts
Erfahrenen Benutzern sollten Abkürzungen zur Verfügung gestellt werden, um die
Nutzung des Systems zu beschleunigen.
3. Anbieten von informativen Rückmeldungen
Rückmeldungen die das System liefert, sollten klar und aussagekräftig sein.
4. Sinnvolle und Abgeschlossene Gliederung von Dialogen
Interaktionen mit dem System sollen so gestaltet sein, dass diese einheitlich ablaufen
und in sich geschlossen sind.
5. Einfache Fehlerbehandlung
Fehler sollten einfach handhabbar sein.
6. Reversibilität von Aktionen
Die Wiederholung von Aktionen soll so einfach wie möglich gehalten werden, d.h. eine
Wiederholmöglichkeit einer Aktion soll ohne große Neueingaben möglich sein.
7. Den Benutzer als „Herrn des Systems“ unterstützen
Erfahrene Benutzer wollen die Verantwortung über das System, überraschende Aktionen
und andere Effekte sollten vermieden werden, um Unzufriedenheit zu vermeiden.
8. Kurzfristige Gedächtnisbelastungen reduzieren
Da der Mensch nur eine gewisse Anzahl von Informationen in kurzer Zeit aufnehmen
kann (Faustregel: 7 +/- 2 Informationen), sollte der Bildschirmaufbau einfach gehalten
werden und zahlreiche Informationen zu größeren Einheiten zusammengefasst werden.
7
8
2.2 Usability Engineering
Die Themen Bedienbarkeit und Benutzerfreundlichkeit wurden erstmals in den achtziger
Jahren bekannt. Unter dem Begriff der Software-Ergonomie wurden zunächst Anforderungen
an ergonomische Software in Form von Richtlinien und Normen definiert. Mit der Zeit richtete
sich das Interesse aber immer mehr auf den Prozess zur Erstellung ergonomischer
Software. Die Vorgehensweise des Usability Engineering entstand und bildet das derzeitige
Ende dieser Entwicklung [Mekel01].
Der Begriff Usability Engineering beschreibt eine methodische, iterative Vorgehensweise mit
der man systematisch versucht eine optimale Benutzbarkeit und Benutzerfreundlichkeit eines
Systems unter software-ergonomischen Gesichtspunkten zu erreichen. In diesem Prozess
sind nach der Analyse die Phasen des Designs, des Prototyping sowie der Evaluierung
mehrfach zu durchlaufen um alle notwendigen Informationen zu gewinnen, die später helfen
eine benutzbare und benutzerfreundliche Schnittstelle zu schaffen (siehe Abbildung 2.1).
Nachfolgend werden die einzelnen Schritte dieser Vorgehensweise näher erläutert, um
später, basierend auf dieser Methodik einen Entwurf für ein zukünftiges Bedienkonzept für
das „Clinical Trial Management“ zu schaffen.
Abbildung 2.1: Iterativer Prozess des Usability Engineering
2.2.1
Analyse
Hey, we´ve got the contract!
You start coding while I go
and find out what they want ...
Die Analyse von Benutzern und Aufgaben ist eine wichtige Voraussetzung für die
Entwicklung einer ergonomischen Benutzerschnittstelle und bildet den 1. Schritt im Usability
Engineering. [Preim99] erwähnt, dass 60% der Probleme bei der Benutzung auf die
unzureichende Anpassung der Schnittstelle an die Aufgaben und die Benutzer herrühren.
Die zunächst ins Auge stechenden Merkmale wie die visuelle Gestaltung oder die
Anordnung und Platzierung von Dialogbausteinen haben demgegenüber ein geringeres
Gewicht.
Laut [Preim99] ist die Vorgehensweise des Software-Engineerings mit relativ klar
abgegrenzten, nacheinander zu durchlaufenden Phasen nicht mit der Methodik des Usability
Engineerings vergleichbar. Ein Grund hierfür liegt in der wesentlich höheren Komplexität
interaktiver Systeme. Dies führt dazu, dass eine vollständige Analyse und eine komplette
Spezifikation fast nicht durchzuführen sind. Zum anderen ist schwer vorhersagbar wie
Benutzer auf die Gestaltung einer Benutzerschnittstelle reagieren. Aus diesem Grund
müssen die Benutzer befragt und Prototypen getestet werden. Tests dienen hierbei nicht
dazu die letzten Fehler zu finden, sondern sollen zeigen wie Benutzer auf bestimmte
Interaktionsmuster reagieren. Als Folge dieser Tests sind häufig Veränderungen
durchzuführen, die dann wiederum einem Test unterzogen werden. Dieser Zyklus wird wie
oben schon erwähnt, beim Usability Engineering normalerweise mehrere Male durchlaufen.
Im folgenden werden die Schritte der Benutzer- und der Aufgabenanalyse näher erläutert,
deren Ergebnisse dann Ausgangspunkt sind für erste Entwürfe.
Benutzeranalyse
Der Auftraggeber eines Systems ist häufig nicht der eigentliche Benutzer. Da die
Auftraggeber meistens Vorgesetzte der „Endbenutzer“ sind, glauben sie die Anforderungen
an ein zukünftiges System zu kennen. Der direkte Kontakt zu den letztendlichen Benutzern
ist aber notwendig, da die „Chefs“ meist nur Kenntnis über die Aufgaben der Mitarbeiter und
der daraus resultierenden Arbeitsergebnisse haben. Sie sind sich häufig nicht im klaren
darüber welche Probleme auf dem Weg zu diesen Ergebnissen gelöst werden müssen. Da
oft nur das Ergebnis zählt, werden solche Schwierigkeiten verdrängt.
Der Kontakt zu den Mitarbeitern hat aber noch einen weiteren wesentlichen Grund: Dadurch,
dass sie in die Entwicklung mit einbezogen werden, steigt ihre Akzeptanz gegenüber dem
System. Sie bekommen nicht das Gefühl, dass ihnen ein System aufgedrängt wird oder,
dass es sie womöglich ersetzen soll. Dieses Gefühl der „Mitsprache“ trägt wesentlich zum
Erfolg eines Systems bei.
Der Kontakt mit dem Endbenutzer sollte dazu genutzt werden um konkrete Fragen zu
stellen. Dies kann in Form eines Interviews erfolgen, aber auch mit Hilfe von Fragebögen.
Zudem sollte der Kontakt auch genutzt werden um den Benutzern bei ihrer Arbeit „über die
Schulter“ zu schauen. Dieses Beobachten vermittelt oft Einsichten, die allein durch ein
Interview nicht möglich sind.
[Preim99] erwähnt folgende Aspekte der Anwender, die bei der Analyse der Benutzer
berücksichtigt werden sollten:
·
·
·
·
·
·
·
·
Alter, Geschlecht
Körperliche Fähigkeiten, Behinderungen
Ausbildung (allgemeines Ausbildungsniveau und spezifische Schulungen)
Motivation
Computervertrautheit
Vertrautheit mit dem Problem bzw. Anwendungsgebiet
Intensität der Anwendung (Wie oft und wie intensiv wird die Anwendung genutzt?)
Kulturkreis (z.B. unterschiedliche Semantik von Farben und Icons)
Unterschiede der einzelnen Benutzer bezüglich dieser Aspekte lassen auf unterschiedliche
kognitive und motorische Fähigkeiten schließen. [Preim99] nennt hier beispielhaft folgende
Eigenschaften:
·
·
·
·
Bewusst gesteuerte Prozesse und automatisch ablaufende Prozesse.
Vieles was erfahrene Benutzer so verinnerlicht haben, dass es automatisch abläuft, ist
für den Anfänger Gegenstand seiner bewussten Aufmerksamkeit.
Lernen und Problemlösung (eher systematische Herangehensweise oder Ausprobieren)
Entscheidungsfähigkeit
Strategien für das Suchen und Auswählen
9
Laut [Preim99] werden diese wiederum von verschiedenen Faktoren beeinflusst, wie:
·
·
·
·
·
·
Aufmerksamkeit, Wachsamkeit, Ermüdung (Durch welche Reize wird der Mensch wie
schnell auf etwas aufmerksam gemacht? Dies ist wesentlich für kritische Meldungen,
Warnungen oder ähnliches.)
Ablenkung (Wodurch werden Benutzer häufig abgelenkt?)
Menge der zu merkenden Informationen
Kenntnis von Ergebnissen
Monotonie, Langweile
Angst, Furcht, Isolierung
Welche konkreten Schlüsse aus diesen Aspekten für den Entwurf einer ergonomischen
Benutzerschnittstelle gezogen werden können, stellt [Preim99] nicht dar. Grund hierfür ist
wahrscheinlich dass die Berücksichtigung solcher Aspekte von Anwendung zu Anwendung
unterschiedlich ausfällt. Trotzdem werden nachfolgend einige allgemeingültige Regeln
aufgestellt, die hier zwar nicht bewiesen sind, aber auf der Hand liegen:
1. Sind viele ältere Personen unter den Benutzern, sollte auf modernste Dialogtechniken
verzichtet werden. Gängige Dialogkomponenten, bei denen ein Wiedererkennungseffekt
erzielt wird, eignen sich hier besser.
2. Der Dialog sollte den körperlichen Fähigkeiten der Benutzer angepasst sein. (Bsp.:
Größere Darstellung der Dialogbestandteile für sehbehinderte Menschen)
3. Ist der Anwender nicht ausreichend mit der zugrunde liegenden Aufgabe vertraut, sollte,
wenn möglich, das System diese Aufgabe übernehmen oder den Benutzer erklärend
durch die Aufgabe führen.
4. Ist eine Aufgabe sehr häufig durchzuführen, sollte das System Abkürzungen bereitstellen
um den Vorgang zu beschleunigen.
5. Wird eine Aufgabe eher selten durchgeführt, sollte das System den Benutzer durch
entsprechende Darstellungen und Erläuterungen unterstützen.
6. Wird der Benutzer häufig abgelenkt, sollte der Dialog so gestaltet sein, dass jederzeit der
aktuelle Stand der Interaktion ersichtlich ist.
7. Ist die Struktur der Benutzer heterogen, sollte das System verschiedene Bedienmodi
(Anfängermodus, Expertenmodus) für die unterschiedlichen Benutzer zur Verfügung
stellen.
Aufgaben-Analyse
Obwohl Benutzer und Aufgaben zunächst getrennt voneinander betrachtet werden sollten,
können die entsprechenden Analysen parallel erfolgen. Bei der Aufgabenanalyse geht es
darum die Aufgaben zu identifizieren, die vom Benutzer ausgeführt werden und die zum
Aufgabenbereich des geplanten Systems gehören.
Laut [Preim99] beschäftigt man sich hierbei mit folgenden Fragen:
·
·
·
·
·
·
·
Welche Arbeitsprozesse müssen modelliert werden?
Welche Objekte werden im Arbeitsprozess erzeugt oder manipuliert?
Welche Anwender sind mit welchen Verantwortlichkeiten daran beteiligt?
Welche Schnittstellen zu anderen (nicht modellierten Prozessen) existieren?
Welche Datenmengen aus welchen Datenbeständen werden in einem bestimmten
Zeitraum bearbeitet?
Welche Arbeitsschritte rufen bei den Anwendern Unzufriedenheit hervor?
Wie hoch ist die Fehlerrate in den einzelnen Arbeitsschritten?
Viele dieser Fragen können durch strukturierte Interviews, Fragebögen oder durch
Beobachtungen beantwortet werden. Um darauf aufbauend eine Übersicht über die
bestehenden Aufgaben und ihrer Ziele zu bekommen und um daraus eine Strukturierung
10
ableiten zu können, müssen die Aufgaben in eine einheitliche und übersichtliche Form
gebracht werden. Da die Aufgaben meist komplex sind können sie nicht mit einer einzigen
Sicht dargestellt werden.
Modellierung der Aufgaben
[Welie01] zeigt hier einige Möglichkeiten zur Darstellung von Aufgabenstrukturen auf:
Task Trees:
Abbildung 2.2: Task Trees [Welie01]
Mit einem Task Tree kann dargestellt werden aus welchen Teilaufgaben eine Aufgabe
besteht. Sie sind recht einfach zu erzeugen und zu verstehen, weshalb sie gerade bei der
Kommunikation mit Benutzern oder im Design Team sehr nützlich sind. Wesentliche Dinge,
die später beim Design wichtig sind, können von ihnen allerdings nicht abgedeckt werden.
Hierzu zählen:
·
·
·
Zeitliche Abhängigkeiten können nicht dargestellt werden.
Zustände von Rollen bzw. Objekten sind nicht ersichtlich.
Bei eventuell mehreren handelnden Personen ist keine Zuordnung zu den einzelnen
Aufgaben möglich.
Bei der Aufgabenanalyse in Kapitel 4 wird anhand von Task Trees die Aufgabenstellung des
Management von Studiendaten in die einzelnen Teilaufgaben aufgeteilt und dargestellt.
Die Unified Modelling Language (UML)
UML ist eine weit verbreitete und anerkannte Modellierungssprache und hat sich speziell im
Bereich des Software Engineering etabliert. Obwohl die UML nicht für den Bereich der
Aufgabenmodellierung entwickelt wurde, bietet sie verschiedene Diagramme, die zur
Aufgabenanalyse sehr gut verwendet werden können.
1. Aktivitätendiagramm
Dieses Diagramm kann verwendet werden um Aufgabenabläufe in Bezug zu
Ereignissen, Aktivitäten, Rollen und Zielen zu modellieren. Abbildung 2.3 zeigt hier ein
Beispiel einer solchen Darstellung. Die Aufgabenstellung des Anlegen von Studiendaten
sowie das Durchführen der Randomisierung mit der Engineering Database von CTM wird
in Kapitel 4 – Aufgabenanalyse mit Hilfe von Aktivitätendiagrammen modelliert.
11
Abbildung 2.3: Aktivitätendiagramm [Welie01]
2. Kollaborationsdiagramm
Dieses Diagramm zeigt wie die verschiedenen Rollen oder Objekte zusammenarbeiten.
Diese Zusammenarbeit erfolgt durch den Austausch von Nachrichten, die in dieser
Diagrammart dargestellt werden. Um eine zeitliche Folge modellieren zu können erhält
jede Nachricht eine eindeutige Nummer. Beziehungen werden anhand von Pfeilen
dargestellt. Abbildung 2.4 zeigt ein Beispiel eines Kollaborationsdiagramms.
Abbildung 2.4: Kollaborationsdiagramm [Welie01]
3. Sequenzdiagramm
Mit dem Sequenzdiagramm kann ähnlich wie bei Kollaborationsdiagrammen die Folge
von Aufgaben dargestellt werden, die von verschiedenen Rollen oder Objekten
nacheinander ausgeführt werden. Abhängigkeiten von Aufgaben oder optionale
Aufgaben können durch dieses Diagramm nicht dargestellt werden.
Bei der Analyse der Aufgaben für das Verwalten der Studiendaten wurde diese
Diagrammart nicht eingesetzt. Bei der Darstellung der Implementierung der Prototypen in
Kapitel 5 – Design findet das Sequenzdiagramm aber Verwendung.
Eine genauere Beschreibung der Diagramme ist unter [Oester98] zu finden.
Zusätzlich zu diesen aufgezeigten Möglichkeiten der Modellierung von Aufgabenabläufen,
Abhängigkeiten, Zuständen von Objekten und Rollen sowie Ereignissen, die Aufgaben
auslösen, gibt es noch einige weitere. Hierzu zählen beispielsweise Petri-Netze oder
12
einfache Flow Charts, die gleichwertig sind zu den oben genannten, auf die hier aber nicht
näher eingegangen wird.
Auswertung der Aufgabenanalyse
Die bei der Aufgabenmodellierung gewonnen Informationen können nun als Grundlage für
die Entwürfe dienen. Zudem können sie auch Ausgangspunkt sein für die Analyse des
Bestehenden und für das Auffinden von Verbesserung im Ablauf und in der Gestaltung von
Aufgaben. Leider gibt es hier keine allgemeingültige Vorgehensweise die Schritt für Schritt
durchlaufen werden kann, um Probleme und Schwachpunkte aufzudecken und einen
Aufgabenablauf zu verbessern. Trotzdem nennt [Welie01] einige allgemeingültige Probleme
von Aufgaben auf die zu achten ist:
·
Probleme in einzelnen Aufgabenstrukturen. Die Aufgabenstruktur ist sub-optimal weil
zu viele Unteraufgaben durchgeführt werden oder verschiedene Aufgaben zu
zeitaufwendig sind oder zu oft auftreten.
·
Unterschiede in der formellen und der tatsächlichen Ausführung von Aufgaben.
Häufig sind Aufgabenabläufe festgeschrieben z.B. als Teil der ISO 9000 Richtlinie. Oft
werden Aufgaben aber nicht so ausgeführt, wie in diesen Dokumenten beschrieben, und
meistens gibt es nicht nur „einen Weg“ der Ausführung der Aufgabe. Wenn Benutzer
unterschiedlich darüber denken wie etwas gemacht werden muss entstehen Probleme.
·
Ungenügende Kommunikation in einer Organisation. Bei komplexen Aufgaben sind
meistens viele Personen einbezogen, die aus verschiedensten Gründen kommunizieren
und zusammenarbeiten müssen, wie beispielsweise beim Wissen über spezielle
Tätigkeiten oder bei der Verantwortung für Aufgaben. Dies sind oft Gründe für
zeitintensive Aufgaben aber auch für Probleme bei zusammen arbeitenden Personen.
·
Widersprüche bei Tätigkeiten. Aufgaben sind definiert, werden aber von niemandem
getätigt, oder sie werden in der falschen Reihenfolge ausgeführt.
·
Personen führen ihnen nicht erlaubte Tätigkeiten durch. In komplexen
Organisationen werden Personen Rollen zugeteilt, die sie für bestimmte Aufgaben
verantwortlich machen. Häufig führen aber Personen zusätzliche Tätigkeiten aus für die
sie keine Erlaubnis haben.
Nach der Analyse und eventuellen Verbesserung der Aufgabenabläufe und der Modellierung
der angestrebten Strukturen, dienen diese Ergebnisse dann als Grundlage für die Erzeugung
der ersten Prototypen und später der eigentlichen Benutzerschnittstelle.
2.2.2
Design
Nach Abschluss der Analyse beginnt die Phase des iterativen Design-Prozesses in dem ein
erster konzeptioneller Entwurf der Benutzerschnittstelle durchgeführt wird.
Konzeptionelles Design
In der Phase des konzeptionellen Designs werden die grundlegenden Interaktionen
zwischen Mensch und System bestimmt sowie die Objekte der Benutzerschnittstelle
festgelegt. Die Ergebnisse der Benutzer und Aufgaben Analyse bilden hierbei die Basis.
Resultate des konzeptionellen Designs von Benutzerschnittstellen sind vor allem Papier-
13
Prototypen wie Bleistiftzeichnungen aber auch textuelle Beschreibungen die das Verhalten
der Benutzerschnittstelle beschreiben [Ferré01]. In Kapitel 5 – Design sind solche PapierPrototypen der einzelnen Konzepte zu sehen. Zudem erfolgt dort auch eine textuelle
Beschreibung.
Diese Phase ist sehr wichtig im Entwicklungsprozess, da hier die grundlegende Struktur und
das Aussehen des späteren Dialogsystems festgelegt werden.
Aufgrund der Tatsache, dass Design ein sehr kreativer Prozess ist gibt es hierfür wie auch
bei der Neustrukturierung von Aufgaben keine festgelegte Vorgehensweise. Die oben
genannten Richtlinien und Normen für die Gestaltung von Benutzerschnittstellen, sowie
Kenntnis über die Struktur der Benutzer und die Aufgabenabläufe helfen aber eine MenschMaschine-Schnittstelle software-ergonomisch zu gestalten. Zudem ist es auch sinnvoll sich
bei anderen bekannten Systemen Eindrücke zu verschaffen. Dies ist nicht nur als
Erleichterung zu sehen, sondern führt auch meist zu besseren Ergebnissen, da eigene
Entwürfe meist nicht an den heutigen Stand der Technik der Dialoggestaltung
herankommen. Zusätzlich führt dies beim Benutzer letzten Endes auch zu
Wiedererkennungseffekten, was unter dem Gesichtspunkt der Software-Ergonomie positiv
zu werten ist.
Visuelles Design
Nachdem die im konzeptionellen Design erstellten Entwürfe mehrfach ausgewertet,
verbessert und ein Optimum gefunden wurde, werden die Entwürfe in einen konkreten
Dialog umgesetzt. Hierbei werden dann alle Details, wie Arten von Widgets, Layout oder
auch Gestaltung von Grafiken und Icons berücksichtigt. Auch diese Phase wird zumeist
mehrfach durchlaufen um erste Entwürfe zu optimieren.
Beim visuellen Design sind bereits Prinzipien und Regeln bezüglich der Auswahl von Farben,
Verwendung von Text, Layout, Anordnung von verschiedenen Widgets oder dem Design von
Icons zu beachten. Diese werden in Kapitel 4 Stand der Technik von Dialogsystemen näher
erläutert.
Prototyping
Das Erstellen von Prototypen ist ein wesentlicher Bestandteil im Designprozess und
ermöglicht es schon frühzeitig Tests auf Benutzbarkeit und Benutzerfreundlichkeit
durchzuführen. Sie sind notwendig, da abstrakte technische Darstellungen nicht sehr dienlich
sind bei der Kommunikation mit Benutzern oder im Design Team. [Ferré01] nennen hier die
folgenden Möglichkeiten des Prototypings:
·
Papier Entwürfe
In der Anfangsphase des Design Prozesses (konzeptuelles Design) entwirft der Designer
erste Papierskizzen für den Benutzer. Der Designer verhält sich bei der Vorführung
dieser wie ein Computer indem er dem Benutzer bei einem Übergang die entsprechende
nächste Skizze vorlegt. Die Evaluierung aufgrund derartiger Prototypen wird auch
Walkthrough genannt. Die Durchführung von Aufgaben wird hier zwar nur simuliert,
trotzdem lassen sich bereits in dieser Phase einige Kritikpunkte und Probleme
aufdecken.
·
„Wizard of Oz“ Technik
Ein Experte verhält sich bei dieser Art des Prototypings wie das zukünftige System und
reagiert dementsprechend auf Eingaben des Benutzers, ohne ihn zu kennen. Der
Benutzer sitzt normalerweise vor einem Bildschirm, anstelle einer Software sitzt aber der
Experte an einem anderen Gerät (verbunden durch ein Netzwerk) und beantwortet die
14
15
Anfragen des Anwenders. Ein Vorteil dieser Methode ist, dass sie wesentlich günstiger
ist, als einen Software Prototypen zu erstellen.
·
Szenarios, Snapshots und Storyboards
Das Erstellen von Prototypen ist nicht auf das Entwerfen der Oberfläche beschränkt.
Zusätzlich können an Hand eines Szenarios Überlegungen zum Ablauf der Bedienung
dargestellt werden. Snapshots sind Abbildungen die eine Interaktion während eines
Szenarios darstellen. Ein Storyboard (Drehbuch) wiederum besteht aus einer Folge von
Snapshots, die sich auf die hauptsächlichen Aktionen in einer angenommenen Situation
beziehen.
Des weiteren können Prototypen nach der Auswertung der ersten Entwürfe implementiert
werden. Hierdurch lässt sich ein Bedienkonzept wesentlich realistischer darstellen. Da ein
Prototyp nur einen Teilbereich der Anwendung umfassen kann, muss eine Auswahl getroffen
werden. [Preim99] beschreibt hierzu zwei Vorgehensweisen:
1. Horizontales Prototyping
Diese Art des Prototyping reduziert die Tiefe der Anwendung. Die oberflächlichen
Eigenschaften der Benutzerschnittstelle, wie Menüs, Buttons usw., werden weitgehend
umgesetzt, aber sie besitzen keine Funktionalität. Anhand eines horizontalen Prototypen
kann ein Großteil der zu implementierend Anwendung „oberflächlich“ betrachtet und ein
Gesamteindruck der Benutzerschnittstelle gewonnen werden. Es können hierbei
allerdings keine echten Aufgaben durchgeführt werden.
2. Vertikales Prototyping
Anders als beim Horizontalen Prototyping werden bei dieser Vorgehensweise nur
einzelne Teile der zu implementierenden Anwendung umgesetzt. Allerdings werden
diese Teilbereiche dabei in Layout und Funktionalität weitgehend vollständig realisiert
und andere dagegen völlig ignoriert. Die umgesetzten Teilbereiche vermitteln bereits sehr
realistisches der zukünftigen Anwendung ähnliches Verhalten.
2.2.3
Usability Evaluation
We can’t predict a software system’s usability
without testing it with real users.
Der Begriff der „Usability Evaluation“ beschreibt die Auswertung des umgesetzten Designs
auf seine Benutzbarkeit und Benutzerfreundlichkeit und ist ein weiterer wichtiger Schritt
während des Usability Engineerings. Hier wird festgestellt ob das neue Konzept funktioniert
und ob es zu einer Steigerung des Grades der Benutzbarkeit führt. [Ferrè01] beschreibt in
diesem Zusammenhang eine Vorgehensweise bei der das angestrebte Ziel und der
gegenwärtige Grad an Benutzbarkeit durch Maßzahlen festgelegt werden. Beispielsweise ist
ein Qualitätsattribut die Zeit, die benötigt wird, um eine bestimmte Aufgabe mit dem System
durchzuführen. Auf solche Maßzahlen wird aber in dieser Arbeit nicht näher eingegangen, da
es schwer vorstellbar ist, dass Benutzbarkeit und Benutzerfreundlichkeit eines
Bedienkonzeptes mit Zahlen zu messen sind. Vielmehr sollte eine positive Reaktion der
Benutzer angestrebt werden.
Im folgenden werden nun verschiedene Strategien erläutert, mit denen die Qualität eines
Bedienkonzeptes ausgewertet werden kann:
Usability Testing
Beim „Usability Testing“ werden die Prototypen einer Gruppe von Benutzern vorgeführt und
dabei die Reaktionen und das Verhalten der Personen aufgezeichnet. Diese Resultate sind
später wieder die Grundlage für die Analyse und die Verbesserung des bereits Umgesetzten.
Hierbei muss zunächst festgelegt werden welche Gruppen von Benutzern und wie viele
Benutzer pro Gruppe ausgewählt werden. Zudem müssen Testaufgaben definiert werden,
die von den Benutzern mit dem Prototypen durchzuführen sind. Des weiteren sind noch
folgende Fragen zu klären:
·
·
·
·
Dürfen die Testpersonen während der Aufgabe Fragen an den/die Auswerter stellen?
Sollten zwei Personen gemeinsam die Aufgaben durchführen? Hierdurch könnten
Bemerkungen, die sie austauschen untersucht werden.
Welche Informationen zum Testsystem erhalten die Beteiligten im Voraus?
Wie viel Zeit bekommen die Testpersonen um sich mit dem System vertraut zu machen?
Bei der Durchführung der Tests können diese optional per Video oder mit einem Audiogerät
aufgenommen werden. Zusätzlich können die Aktionen der Benutzer protokolliert werden.
Nachdem ausreichende Ergebnisse gewonnen wurden beginnt der nächste iterative Zyklus.
Dies wird so lange fortgesetzt bis das Ziel, eine software-ergonomische Benutzerschnittstelle
zu schaffen, erfüllt ist [Ferré01].
Laut denken
Bei der Methode des „Laut denken“ werden die Testpersonen dazu aufgefordert während der
Durchführung einer Aufgabe mit einem Testsystem ihre Gedanken zu formulieren. Nach
einem Beispiel von [Ferrè01] könnte eine Testperson möglicherweise sagen:
„Zunächst öffne ich die Datei und klicke einmal auf das Dateisymbol. Nichts
passiert. Ich weiß nicht warum es nicht wie im Internet funktioniert. Ich drücke die
Enter-Taste und sie öffnet sich. Jetzt will ich die Farbe des Etiketts ändern.
Hierzu suche ich im Menü ‘Tools’, finde aber keine Option dazu.“
Diese Kommentare können wesentliche Einblicke geben, wie eine Benutzerschnittstelle am
besten gestaltet werden sollte. Durch die Detaillierung des mentalen Prozesses können
versteckte Probleme bei der Benutzung aufgedeckt werden [Ferré01]. In Kapitel 6 –
Evaluierung der Prototypen wurde ein Test nach dieser Methode durchgeführt.
Weitere Strategien für die Evaluierung von Benutzerschnittstellen sind beispielsweise die
Heuristische Evaluierung oder die Empirische Evaluierung auf die hier aber nicht näher
eingegangen wird. Weitere Informationen hierzu findet man unter [Preim99] oder auf der
Interseite http://www.usability-forum.com.
16
3 Stand der Technik von
Dialogsystemen
Die Informationstechnik hat heute in fast allen Bereichen Einzug gehalten und nahezu jeder
Mensch ist gegenwärtig in der Lage einen Computer zu bedienen. War es vor einigen Jahren
nur Experten möglich Computer zu nutzen so hat die Entwicklung der bestehenden
Dialogsysteme hauptsächlich zu dieser Steigerung der Benutzbarkeit beigetragen. Im
folgenden werden nun verschiedene Möglichkeiten der Gestaltung von Grafischen aber auch
von Multimedialen Benutzerschnittstellen dargestellt, aus denen später eine Auswahl für die
Neugestaltung der Benutzerschnittstelle des Clinical Trial Managements getroffen werden
kann. Unter dem Begriff Joy of use werden zudem neue Qualitäten bei der Gestaltung von
Dialogen aufgezeigt. Da beim Design von Benutzerschnittstellen auch psychologische
Aspekte eine Rolle spielen wird abschließend in diesem Kapitel auf die Bereiche
Farbpsychologie sowie Gestaltpsychologie eingegangen.
3.1 Grafische Benutzeroberflächen
Hierbei handelt es sich grundsätzlich um visuelle Dialoge, die meist per Maus und Tastatur
aber auch durch Touchscreens bedient werden. Bekannte Systeme sind hier Windows, KDE
für Linux, aber auch das Dialogsystem von MacOS. Diese unterscheiden sich alle in ihrem
Layout enthalten aber alle grundsätzlich dieselben Dialogelemente. Nachfolgend wird nun
auf diese Grundbestandteile von Benutzeroberflächen und wie sie sinnvoll eingesetzt werden
näher eingegangen. Danach werden Möglichkeiten aufgezeigt, welche Alternativen es zu
dem bestehenden gibt.
3.1.1
Standard Interaktionskomponenten
Fenster
Bei den meisten grafischen Dialogsystemen werden sämtliche Ein- und Ausgaben über
Elemente von Fenstern getätigt. [Wessel98] nennt hier einige Grundprinzipien bei der
Gestaltung der einzelnen Teile eines Fenster:
·
Titelleiste:
Sie kann als praktische Informationsfläche genutzt werden.
·
Menüleiste:
Das Hauptmenü sollte nur so viele Auswahlpunkte besitzen wie in einer Zeile darstellbar
sind.
Stand der Technik von Dialogsystemen
18
·
Symbolleiste:
Ein Fenster sollte wenn möglich nicht mehr als eine Symbolleiste mit einer einfachen
Zusammenstellung der wirklich notwendigen Symbole und Buttons aufweisen. Die
Anzahl von Buttons und Symbolen scheint heute bei manchen Anwendungen ein
wichtiges Qualitätskriterium zu sein. Eine hohe Anzahl führt aber leider zu
Unübersichtlichkeit und schränkt zudem die eigentliche Arbeitsfläche zu sehr ein.
·
Bildlaufleisten:
Grundsätzlich gilt hier, dass Scrollbars bei der Fenstergestaltung vermieden werden
sollten. Der Dialog sollte für eine sinnvolle Auflösung (beispielsweise 1024 mal 768)
geplant und umgesetzt werden.
·
Statusleiste:
Die Aufmerksamkeit die ein Benutzer diesem Bereich zukommen lässt, sollte nicht
überschätzt werden. Häufig nehmen Anwender Texte, die hier erscheinen gar nicht zur
Kenntnis, da der Blick bei einer Menüauswahl eher auf den oberen Teil des Fensters
gerichtet ist. Wichtige Meldungen sollten deshalb eher über Message Boxen mitgeteilt
werden.
Menüs
In einem Menü werden verschiedene Haupt- und Unterfunktionen aufgeführt. Zumindest die
wichtigen, also die häufig verwendeten Menüpunkte sollten zusätzlich zur Maus noch mit
einer Tastenkombination ausgewählt werden können. Zudem sollten die am häufigsten
verwendeten Funktionen im Menü ganz oben stehen. Bezeichnungen für die Auswahlpunkte
sollten aussagekräftig und gut verständlich sein.
Im Unterschied zu Kommandosprachen besteht der Vorteil von Menüs darin, dass der
Benutzer Funktionen nur wiedererkennen muss. Zudem werden ihm Alternativen angezeigt
und er kann eine Auswahl treffen.
Steuerelemente
Bei der Verwendung verschiedener Controls in einem Dialog müssen diese durch eine
entsprechende optische Darstellung unterscheidbar gemacht werden. Hier bietet sich
zunächst eine sinnvolle Beschriftung aber auch die Verwendung von eindeutig erkennbaren
Icons an. Gruppen von Elementen können durch Leerräume, Rahmen und Linien aber auch
durch eine entsprechende farbliche Gestaltung optisch von einander getrennt werden.
Zudem ist es wichtig, dass die Reihenfolge der Steuerelemente mit der Folge der
durchzuführenden Aktionen übereinstimmt.
Nachfolgend werden die Steuerelemente aufgeführt, die in gegenwärtigen Grafikbibliotheken
verfügbar sind, und ihre Einsatzbereiche und sinnvolle Verwendung wird erläutert:
Textelemente
Sie werden verwendet um andere Controls näher zu bezeichnen oder um Informationen
darzustellen. [Wessel98] nennt hier sehr strenge Richtlinien zur Anordnung und Bemaßung,
wie beispielsweise den genauen Abstand eines Textelements zu einem Control. Dies
erscheint zunächst übertrieben, führt aber in der Praxis zu einer Verbesserung der
Konsistenz.
19
Rahmen und Linien
Sie dienen der Gliederung und Abgrenzung von anderen Dialogelementen. Um die
abgegrenzten Elemente zu benennen, können Beschriftungen angefügt werden. Zudem
kann laut [Wessel98] durch Linien die Leserichtung eines Dialogs beeinflusst werden und bei
konsistentem Einsatz eine Art „Hinführung“ zu bestimmten Dialogelementen stattfinden. Ein
sinnvoller Einsatz von Farbe kann bei Rahmen und Linien die Übersicht eines Dialogs
wesentlich verbessern.
Eingabefelder
Hier unterscheidet man Single-Line-Edit-Felder, die nur die Eingabe einer einzelnen
Textzeile erlauben und Multi-Line-Edit-Felder, die die Eingabe mehrerer Zeilen ermöglichen.
Drehfelder (Spinbuttons)
Sie bestehen aus einem Eingabefeld mit einem kleinen Scrollbar an der rechten Seite, der
aber nur einen Auf- und einen Ab-Pfeil besitzt. Sie dienen zur Auswahl eines numerischen
Wertes oder zur Auswahl eines Elementes aus einer relativ kleinen Liste. Die Selektion sollte
im Falle einer numerischen Auswahl auch immer direkt über das Eingabefeld durchgeführt
werden können. Da die Elemente eines Drehfeldes nie komplett zu sehen sind sollten die
Folgeelemente vorhersehbar sein.
Kontextmenüs
Durch Drücken der rechten Maustaste auf Dialogelementen oder Fenstern wird ein Menü
aufgeklappt welches Operationen des entsprechenden Elementes anzeigt. Diese Art von
Menüs entlasten zum einen das Hauptmenü. Durch die Kopplung von Darstellung und Inhalt
wird aber auch die Aufgabenangemessenheit und die Natürlichkeit einer Bedienung
gefördert. Es wird eine räumliche Nähe des Menüs zum Dialogobjekt geschaffen, was den
Anwender davon entlastet den Blick mehr als notwendig von der aktuellen Arbeitsposition
abwenden zu müssen.
[Wessel98] nennt hierbei als Nachteil, dass man nicht erkennen kann zu welchen
Dialogelementen Kontextmenüs existieren. Durch ein Maussymbol bei dem die rechte
Maustaste farblich hervorgehoben ist kann die Existenz aber durchaus angezeigt werden.
Popup-Menüs
Anders als bei einem Kontext-Menü wird das gewünschte Menü durch Drücken eines
Buttons aufgerufen und dann am Rand des Buttons dargestellt. In diesem Fall muss der
Anwender das Vorhandensein der Komponente nicht erahnen.
Bei dieser Menüart ist darauf zu achten, dass die einzelnen Menüpunkte aus einer für den
Anwender überschaubaren Liste von Möglichkeiten stammen. Da die Menge der zur
Verfügung stehenden Optionen nicht sichtbar ist, sollte die Liste der Auswahlpunkte zudem
für den Anwender erratbar sein. [Wessel98] nennt hier beispielsweise die Auswahl eines
Wochentags oder eines Laufwerks.
Radiobuttons
Sie werden immer in Gruppen verwendet und ermöglichen die Auswahl immer nur einer
Option dieser Gruppe. Wird ein Radiobutton gedrückt verschwindet die Markierung eines
anderen.
20
Radiobuttons sind immer untereinander anzuordnen, da sie nebeneinander gestellt zu sehr
viel Unübersichtlichkeit führen. Sie sollten auch immer in einer erkennbaren Reihenfolge
angeordnet werden. Falls nötig eben alphabetisch.
Checkboxen
Diese Kontrollkästchen ermöglichen es Optionen an- oder abzuwählen, wobei im Gegensatz
zu Radiobuttons mehr als eine Option ausgewählt sein kann.
Ähnlich wie bei Radiobuttons gilt auch für Checkboxen, dass sie wenn möglich vertikal
angeordnet werden sollten, da dies für den Benutzer wesentlich übersichtlicher ist. Werden
Checkboxen zusammen mit Eingabeelementen verwendet so sollten diese, sofern sich das
Kontrollkästchen links vom Text befindet, linksbündig mit diesen Eingabefeldern
abschließen.
Ein beliebter Fehler ist es, dass der Anwender nicht genau weiß was mit der Auswahl einer
Checkbox genau gemeint ist. Negativ formulierte Texte wie „Diesen Hinweis beim nächsten
mal nicht mehr anzeigen.“ sollten nicht verwendet werden [Wessel98].
Comboboxen
Dieses Auswahlelement bietet die Möglichkeit auf Bedarf eine Liste mit Optionen
aufzuklappen. Nach der Auswahl klappt die Liste wieder automatisch zu und sie benötigt
dann sehr wenig Platz.
Die Anzahl der Elemente sollte so bemessen sein, dass das Erreichen der einzelnen
Optionen oder eine größere Anzahl an Mausklicks möglich ist. Bei zu vielen
Auswahlmöglichkeiten sollte auf andere Elemente, wie etwa ein weiteres Dialogfenster, das
die Auswahl über ein entsprechendes Treeview-Control ermöglicht, ausgewichen werden.
Bei weniger als etwa fünf Optionen sollte laut [Wessel98] auf Radiobuttons ausgewichen
werden, da diese sehr viel schneller zu bedienen sind. Auf die Problematik des Platzbedarfs
geht er hierbei nicht ein, was wohl zu bedenken ist, will man Radiobuttons als Alternative
verwenden.
Weitere beliebte Fehler bei der Verwendung von Comboboxen sind zu lange Einträge,
schlecht sortierte Einträge, eine unvollständige Auswahl oder das Fehlen einer
Standardauswahl.
Listboxen
Anders wie Comboboxen zeigen Listboxen die Auswahlmöglichkeiten ständig an und
brauchen deshalb auch mehr Platz. Ist dieser ausreichend vorhanden können sie sinnvoll zur
Anzeige einer dynamischen Menge von Elementen, wie beispielsweise die Aufträge eines
Kunden eingesetzt werden. Sie bieten die Möglichkeit mehrere Optionen (beispielsweise
durch <Shift>-Taste und Mausklick) auszuwählen.
Laut [Wessel98] ist es sehr sinnvoll neben einer solchen Listbox Pushbuttons wie „Alles
markieren“, „Nichts markieren“ und vor allem „Markierung umkehren“ anzubieten. Dies
erleichtert die Auswahl erheblich.
Listview-Controls
Die in einer Listview enthaltenen Daten sind in Zeilen und Spalten organisiert. Dieses
Element ermöglicht das Sortieren nach gewünschten Spalten, aufsteigend und absteigend.
Die Sortierung sollte im Spaltenkopf beispielsweise durch einen Pfeil dargestellt werden. Die
Breite der Spalten sollte zudem veränderbar sein. Moderne Listviews bieten außerdem die
Möglichkeit Spalten zu vertauschen um Informationen, die von Interesse sind,
nebeneinander zu haben.
21
In PMX-System werden Listviews, allerdings mit minimaler Funktionalität, bereits eingesetzt.
Bisher ist es hier nicht möglich die Spaltenbreite zu manipulieren, welche Spalte als
Sortierkriterium dient wird nicht angezeigt und auch das Vertauschen und Ausblenden von
Spalten ist nicht möglich. Dies sollte bei einem zukünftigen Bedienkonzept unbedingt
realisiert werden.
Treeview-Controls
Sie besitzen ein Wurzel-, beliebige Eltern- und Kindelemente und dienen zur übersichtlichen
Darstellung von hierarchischen Daten. Ein Beispiel hierbei ist die Baumstruktur des
Explorers von Microsoft.
Elemente eines Treeviews können per Doppelklick aufgerufen oder editiert werden. Zudem
sollte die Möglichkeit vorhanden sein die einzelnen Teile per Drag & Drop umzuordnen.
In Bezug zu PMX wäre diese Komponente dazu dienlich um Beziehungen von Objekten
aufzuzeigen. Ist ein Objekt von anderen abhängig könnten diese in der untergeordneten
Ebene dargestellt werden.
Pushbuttons
Sie sind in einem Fenster angebracht und dienen dazu Funktionen wie „Dialog schließen“
oder ein Dialogfenster öffnen, auszulösen. [Wessel98] unterscheidet hier zwischen
Schaltflächen und Toolbarbuttons. Erst genannte lösen grundsätzlich eine Aktion innerhalb
eines Fensters aus während die letzteren die wichtigsten Funktionen des Menüs direkt
zugänglich machen und durchaus auf verschiedene Fenster anwendbar sind.
Die Größe einer Schaltfläche sollte grundsätzlich kompakt gehalten werden, eben so, dass
man sie mit der Maus noch gut anwählen kann und der darauf angebrachte Text keinen zu
großen und auch keinen zu kleinen Abstand zum Buttonrand hat. In PMX sind einige Buttons
vorhanden die sehr breit gehalten sind, obwohl der darauf angebrachte Text diesen Platz gar
nicht benötigt. Auch dies sollte bei einem zukünftigen Bedienkonzept vermieden werden.
[Wessel98] macht bei der Bemaßung von Buttons sehr genaue Angaben in Form von
Pixelanzahl und Twips (Twentieth of a Point = 1/567 cm, 1000 Twips = 67 Pixel) um das
Erscheinen der Buttons konsistent zu halten.
Bei der Beschriftung der Buttons sollten Verben wie „übernehmen“ statt „Übernahme“ der
Vorzug gegeben werden. Zudem sollte man bei der Entwicklung einer Benutzerdialoges
versuchen, die Begriffe die ein Anwender im Kopf hat zu erahnen, um diese als
Beschriftungen einzusetzen. Der Benutzer wird dadurch den gewünschten Button umso
schneller erkennen.
Für Standardbuttons wie „Ok“ und „Abbrechen“ sollten zusätzlich Hotkeys wie <Enter> und
<Esc> eingeführt werden.
Bei Buttons die zu weiteren Dialogen führen ist das Anfügen von drei Punkten („…“) sehr
sinnvoll. Es signalisiert dem Anwender, dass hier keine Veränderung ausgelöst wird.
Bezüglich der Farbe sollten Buttons immer schwarz auf grau gehalten werden. Um eine
Akzentuierung oder ein Aufpeppen zu erreichen können zudem einfarbige Bitmaps
angebracht werden. Bunte Schaltflächen wirken zu poppig und lenken den Anwender meist
nur ab.
Auf die grafische Gestaltung von Buttons wird im Kapitel „Grafikelemente“ näher
eingegangen.
22
Tab-Controls
Hierbei handelt es sich um Karteikarten mit einer Reiterlasche. Sie sind sehr dienlich bei der
Darstellung größerer Mengen an Dialogelementen in einem Fenster.
Beim Einsatz von Tab-Controls ermöglichen viele Frameworks das Anbringen der Laschen
an einer beliebigen Seite. Am sinnvollsten ist es aber wohl, diese Reiter oberhalb
anzubringen. Die Variante die Laschen seitlich anzuordnen, führt bei einer vertikalen
Beschriftung zu schlechter Lesbarkeit und bei horizontaler Beschriftung zu einem hohen
Platzbedarf, sofern es sich um eine geringe Anzahl von Karteikarten handelt. Eine
Ausnahme besteht bei einer großen Anzahl an Karteikarten. Hier sind bei einer seitlichen
horizontalen Anordnung wesentlich mehr Laschen auf einer Ebene darstellbar. Werden die
Reiter oberhalb angebracht, müssten sie übereinander gestellt werden, was zu sehr starker
Unübersichtlichkeit führt.
Die Laschentexte sollten grundsätzlich kurz und eindeutig gewählt werden.
Grafikelemente
Durch den Einsatz von sinnvollen grafischen Elementen, beispielsweise durch Icons zur
Darstellung von Objekten oder Programmen, kann die Bedienung von Applikationen
wesentlich vereinfacht und für den Anwender attraktiver gemacht werden. Grafische
Elemente sind auch die Grundlage für das „Look & Feel“ einer Software, also für das
Erkennen von Objekten und ihrer Funktionalität durch entsprechende Visualisierung.
[Wessel98] nennt folgende Gründe für die Verwendung von Grafik:
·
·
·
·
·
Attraktivität einer Anwendung wird gesteigert
Benutzererwartungen werden besser erfüllt
Grafische Elemente werden schneller wiedererkannt als beispielsweise Textelemente
Kompatibilität mit anderen GUI-Applikationen
Sprachunabhängigkeit
Grafiken können grundsätzlich auf verschiedene Weise bei Benutzerdialogen zum Einsatz
kommen. Hier unterscheidet man folgende Arten von Elementen:
·
Schmuckelemente
Diese können in Form von Bitmaps beispielsweise in Begrüßungsfenstern oder als
Hintergrund in einem Hauptfenster (Shell-Window) verwendet werden.
Bei Wizards können diese Elemente außer der reinen schmückenden Funktion auch
Informationen über den aktuellen Arbeitsschritt enthalten und durch sinnvolle Texte
ergänzt werden. Bei der Gestaltung solcher Grafiken sollte man versuchen sich in den
Benutzer hinein zu versetzen und sich fragen: „Was würde ich in dieser Situation dort
sehen wollen?“ Dieser Gedanke sollte aber nicht auf die Gestaltung dieser Elemente
beschränkt bleiben. [Wessel98]
·
WYSIWYG-Elemente
Beim Begriff WYSIWYG (What you see is what you get) geht es um die grafische
Gestaltung von Elementen derart, dass ihre Darstellung Auskunft über das Wesen eines
Objektes oder Programmes, sowie der vorhandenen Operationen und die Auswirkungen
dieser Operationen gibt. Die Auswahl zwischen Quer- und Hochformaten, das Verändern
der Spaltenbreite in einer Tabelle oder die Darstellung eines Laufwerks durch ein kleines
Symbol anstelle eines Buchstabens wie C: sind hier Beispiele. [Wessel98]
23
In weit verbreiteten Softwareprodukten wie Windows kommen diese häufig zum Einsatz
sind aber bei Systemen mit vergleichsweise kleinem Anwenderkreis leider weniger zu
finden.
·
Validierungsanzeigen
Diese Art von grafischen Elementen dienen der Anzeige von Zuständen bestimmter
Controls. Häufig werden hierfür Ampelsymbole eingesetzt, da sie vom Benutzer sofort
verstanden werden. Diese Elemente können dazu verwendet werden, Fehler die bei der
Eingabe gemacht wurden direkt vor Ort anzuzeigen. [Wessel98]
In einem zukünftigen Benutzerdialog könnten die Stati einzelner Objekte, also „edit“,
„valid“ oder „archived“, durch ein Ampelsymbol visualisiert werden. Sind die Beziehungen
der Objekte zusätzlich durch einen Treeview oder einen Graphen dargestellt, könnte die
Übersichtlichkeit wesentlich gesteigert werden.
·
Bitmaps in Pushbuttons
Ob die Funktion eines Pushbuttons durch ein Symbol oder eher durch darauf
angebrachtem Text dargestellt werden soll, ist ein ziemlich strittiges Thema.
Grundsätzlich sind hier zunächst 3 verschiedene Kategorien von Pushbuttons zu
unterscheiden:
1.
2.
3.
Standardbuttons wie „Ok“, „Abbruch“ oder „Hilfe“;
Genormte Buttons wie „Übernehmen“ oder „Löschen“;
Spezielle Buttons wie „Statuswechsel“ oder „Suche starten“;
Für die letzte Kategorie wäre eine symbolische Darstellung nicht sinnvoll, da diese
Funktionen zu speziell sind um sie durch ein Bitmap wirklich eindeutig zu kennzeichnen.
Bei den beiden anderen Kategorien, besonders aber bei der ersten ist eine Beschriftung
wie beispielsweise „Ok“ derart eindeutig, dass auf sie nicht verzichtet werden sollte. Eine
Ergänzung dieser Beschriftung durch ein entsprechendes Symbol zur Aufpeppung ist
aber durchaus denkbar und würde die Attraktivität und somit die Benutzerfreundlichkeit
erhöhen.
Werden aber die Buttons der 1. Kategorie mit ergänzenden Symbolen versehen, so
müssen die Elemente der 2. und 3. Kategorie aus Paritätsgründen ebenfalls mit
Symbolen ausgestattet werden. Dies wird unweigerlich zu unerkennbaren Symbolen
führen, bei denen sich der Anwender erst einmal daran machen wird, diese mit dem
Beschriftungstext in Verbindung zu bringen.
Eine Ausnahme zum oben genannten könnte gemacht werden, wenn ein Benutzer eine
Applikation sehr häufig benutzt und er sich an die Symbole der Pushbuttons sehr schnell
gewöhnen kann. In einem solchen Fall könnte hier eine rein symbolische Darstellung
gewählt werden. Die Pushbuttons sollten dann aber zumindest mit einem zusätzlichen
Tooltip, das die Funktionalität textuell beschreibt, ausgestattet werden. Zudem sollte die
Anzahl der verschiedenen Buttons sehr begrenzt sein (weniger als zehn Buttons).
Buttons der 3. Kategorie sollten möglichst nicht auftauchen oder durch erkennbare
Symbole dargestellt werden.
In Bezug zum gegenwärtigen PMX-System sind die Standard-Pushbuttons („Ok“,
„Abbrechen“, „Einfügen“, „Statuswechsel“, usw.), die in sehr vielen Dialogen eingesetzt
werden nur symbolisch dargestellt. Die Anzahl dieser ist sehr gering und die
verwendeten Symbole geben relativ gut Aufschluss über die enthaltene Funktionalität.
Zudem sind diese mit einem Tooltip ausgestattet, das die Funktion textuell beschreibt.
Würde das System von allen Anwendern häufig benutzt werden, könnte in diesem Fall
24
die rein symbolische Darstellung dieser Standard-Pushbuttons beibehalten werden. Da
dies aber nicht bei allen Benutzern der Fall ist, ist es empfehlenswert die Buttons mit
einer zusätzlichen Beschriftung auszustatten.
Manche Dialogmasken enthalten spezielle Buttons (3. Kategorie) mit textueller
Beschriftung. Diese können nicht durch ein sinnvolles Symbol ergänzt werden. Werden
die Standard-Buttons aber durch ein Symbol ergänzt, könnte hierin ein Konsistenzbruch
gesehen werden. Da diese Buttons von den Standard-Pushbuttons aber immer
bereichsmäßig getrennt sind kann dieser „Bruch“ wohl akzeptiert werden.
·
Bitmaps in verschiedenen Dialogkomponenten
Neben Pushbuttons können Bitmaps durchaus auch in weiteren Dialogkomponenten wie
beispielsweise Menüs, Treeviews, Listviews oder in Tab-Controls angebracht werden.
Hierdurch kann der Zweck einer Komponente verdeutlicht werden, oder die
Aufmerksamkeit des Benutzers auf die entsprechende Komponente gelenkt werden.
Enthält eine Karteikarte innerhalb eines Tab-Controls notwendige Eingabefelder, könnte
dies beispielsweise durch ein entsprechendes Bitmap (Achtung-Symbol) in der
entsprechenden Lasche visualisiert werden. Auch Elemente verschiedenen Typs in
einem Treeview können durch Bitmaps unterscheidbar gemacht werden.
·
Mauszeiger
Der Mauscursor kann dazu verwendet werden um dem Anwender anzuzeigen welche
Möglichkeiten der Manipulation er bei verschiedenen Elementen hat. Abbildung 3.1 zeigt
hier einige Möglichkeiten, wie der Mauszeiger ergänzt werden kann.
Abbildung 3.1: Ergänzung der Mauszeigers [Wessel98]
·
Animationen
Der Sinn von animierten Bitmaps und kleinen Videosequenzen ist grundsätzlich dem
Anwender einen laufenden Prozess zu visualisieren, ihm die Restzeit anzuzeigen und
ihm dadurch mitzuteilen, dass das System keineswegs abgestürzt ist. Der Einsatz
solcher Animationen sollte aber in sinnvollen Grenzen gehalten werden, da
beispielsweise übertriebene Videosequenzen das System nur zusätzlich auslasten.
25
Abbildung 3.2: Animation eines Prozesses [Wessel98]
In PMX gibt es verschiedene Prozesse, wie beispielsweise die Randomisierung von
Studien, die einige Zeit in Anspruch nehmen. Die Abarbeitung dieses Prozesses könnte
dem Anwender durch eine Animation angezeigt werden. Zusätzlich könnte eine gut
gestaltete Animation dem Benutzer einen Vorgang verständlicher machen.
3.1.2
Wizards
Ein Wizard ist eine strukturierte Folge von Dialogen, die den Benutzer durch Fragen zu
Eingaben auffordern und basierend auf diesen versuchen eine bestimmte Aufgabe zu lösen.
In verschiedenen Dialogsystemen wie beispielsweise Windows werden Wizards heute
eingesetzt um den Benutzer bei seiner Aufgabe zu unterstützen. Die Verwendung von
Wizards sollte aber gut durchdacht werden, da beispielsweise für Experten das Durchlaufen
eines Wizards zu umständlich ist.
In folgenden Aufgabengebieten ist es sinnvoll einen Wizard zu verwenden [IBM01]:
·
·
·
·
Wenn Benutzer Aufgaben ausführen, die selten vorkommen.
Bei Benutzern deren Kenntnisse zu gering sind um eine komplexe Aufgabe durchführen
zu können.
Wenn eine genaue Ablauffolge für das korrekte Ausführen einer Aufgabe wichtig ist.
Wenn Benutzer Aufgaben jetzt ausführen sollen und das „wie“ und „warum“ später folgt.
Grundsätzlich gilt, dass ein Wizard niemals lehrend sein sollte sondern nur einen „WalkThrough“ bietet. Er sollte den Benutzer vor der Komplexität einer Aufgabe schützen und nur
die Informationen erfragen, die für die Ausführung der Aufgabe wirklich notwendig sind.
Design
Beim Entwurf eines Wizards gilt es zunächst das eigentliche Ziel zu definieren und in einem
Ablaufplan festzulegen welche Aufgaben nacheinander folgen. Danach muss getrennt
werden welche Aufgaben vom System und welche vom Benutzer durchzuführen sind, also
welche Entscheidungen der Benutzer treffen muss.
Für das Design eines Wizards gibt es einige Richtlinien und Tips [IBM01]:
·
·
·
·
Nur eine Frage per Screen
Maximal 10 Fragen in einem Wizard
Nur einmal nach einer Information fragen
Verwendung von Klartext und Icons. Keine Fachausdrücke!
·
·
·
·
·
26
Bei der Formulierung von Fragen sollten eher Phrasen wie „Möchten Sie …“ als „Sie
müssen jetzt …“ benutzt werden.
Bereitstellung von On-Screen Previews.
Sicherstellen, dass der Benutzer den Wizard ohne Training verwenden kann.
Benutzer sollten den Wizard nochmals aufrufen und ihre vorherige Eingabe verändern
können.
Roadmaps:
Sie zeigen dem Anwender welche Funktionen aufeinander folgen und wo sich der
Benutzer gerade befindet.
In einem zukünftigen Benutzerdialog könnte für das Anlegen verschiedener Objekte ein
Wizard eingesetzt werden. Das Anlegen einer klinischen Studie wäre beispielsweise eine
komplexe Aufgabe, die von vielen Benutzern eher selten ausgeführt wird und bei der das
Einhalten einer Reihenfolge relativ wichtig ist. Als Preview wäre eine Struktur der
voneinander abhängigen Objekte denkbar, die zeigt welche Objekte bereits angelegt wurden
und welche noch anzulegen sind. Für die Benutzer, die das System gut beherrschen, müsste
allerdings eine Alternative geschaffen werden, da das Ausführen eines Wizards für sie zu
umständlich wäre.
3.1.3
Direkte Manipulation
Die durch grafische Komponenten dargestellten Bestandteile eines Dialoges können hierbei
direkt aktiviert, markiert, verschoben oder verändert werden. Dabei erhält der Anwender eine
direkte Rückkopplung über die Folge seiner Aktion. Beispielsweise wird das Drücken eines
Buttons optisch dargestellt oder das Kopieren einer textuell dargestellten Datei per Drag &
Drop sichtbar gemacht.
Laut [Wessel98] funktioniert die direkte Manipulation nur, wenn die entsprechenden
Komponenten genügend „einladend“ sind, sich also beispielsweise deutlich vom Hintergrund
abheben und sich als manipulierbar zu erkennen geben. Die sichtbare Reaktion eines
manipulierten Elements sollte hinreichend schnell sein und der entsprechende Kontext
bereitgestellt werden. [Wessel98] bezieht sich hierbei auch auf die Gestaltpsychologie.
Verschiedene Gesetze, wie beispielsweise das Fitts’sche Gesetz oder auch die zu Beginn
des 19. Jahrhunderts aufgestellten Gestaltgesetze des Psychologen Max Wertheimer gelten
auch beim Entwurf ergonomischer Applikationen.
Metaphern
Der Begriff der Metapher wird im Zusammenhang mit der direkten Manipulation häufig
verwendet. Hierbei verwendet man zur Darstellung von Dialogobjekten Strukturen oder
Bilder die mit der realen Welt vergleichbar sind. Ein bekanntes Beispiel ist die SchreibtischMetapher, die die Arbeit mit Dokumenten, Verzeichnissen und Karteien durch Begriffe aus
der realen Bürowelt darstellt.
In Bezug zum gegenwärtigen Bedienkonzept von PMX wäre die Darstellung der
verschiedenen Objekte als Icons denkbar, die über ein Kontextmenü manipuliert werden
können. Zudem könnten diese Icons Bestandteil eines Graphen sein, der die Beziehungen
zwischen ihnen aufzeigt. Im Kapitel 5 – Design und Implementierung ist dies im Konzept für
das Editieren von Studiendaten umgesetzt.
27
3.2 Neue Dialogtechniken
Zusätzlich zu den gängigen grafischen Benutzeroberflächen gibt es Ansätze zur Erweiterung
und Verbesserung der bestehenden Interaktionsformen. Im einfachsten Fall geht es hierbei
um das Auffinden oder Erstellen neuartiger Dialogkomponenten, aber auch Begriffe wie
Virtual Reality, Zoomable User Interfaces oder User Interface Agents spielen hierbei eine
Rolle. Mensch-Maschine-Schnittstellen können zusätzlich oder anstatt des visuellen Kanals
auch auf akustischen oder haptischen Interaktionsmöglichkeiten aufbauen. Aktuell gibt es
Ansätze die bisherigen Ziele des Usability Engineerings wie Gebrauchstauglichkeit oder
Benutzerfreundlichkeit höher zu stecken und sie durch den Begriff des Joy of use zu
ersetzen.
3.2.1
Treibende Kräfte
[Maybury01] nennt folgende Gründe für die Forderung nach erweiterten und verbesserten
Mensch-Maschine-Schnittstellen:
·
·
·
·
Geschwindigkeit, Effizienz und Freude. Die Unternehmen sind heutzutage gezwungen
ihre Produktivität und die Verwendung von Ressourcen (besonders der menschlichen)
effizienter zu gestalten. Hierbei haben effektive User-Interfaces einen starken Einfluss
auf die Produktivität eines Mitarbeiters. Zudem zeigen angenehm gestaltete
Benutzerschnittstellen (Joy of use) die Minderung von Stress und Senkung von Fehlern.
Allgegenwärtigkeit (Ubiquity) und Mobilität. Computer tauchen immer mehr in den
verschiedensten Bereichen unseres Lebens auf. Neue kabellose Geräte wie Handys,
PDAs und tragbare Computer können mobil genutzt werden und dies erfordert neue
Möglichkeiten der Interaktion.
Personalisierung. Die Nachfrage nach Anpassung von Interfaces aber auch von Geräten
des alltäglichen Lebens steigt. Benutzer können die Schnittstelle selbst anpassen, die sie
bedienen oder die Schnittstelle passt sich selbst an (Beispiele hierbei sind: Einstellung
der Sprache eines bestimmten Landes, Anpassung eines Dialogs an das Display eines
PDAs).
Das Ergrauen der Gesellschaft. Die zunehmende Alterung der Gesellschaft führt zu
einem gesteigerten Bedarf an Benutzerschnittstellen, die diese Personen durch
verbesserte visuelle, optische und physische Interaktionsmöglichkeiten unterstützen.
3.2.2
Neue Dialogkomponenten
Ein Ziel dieser Arbeit ist es zu den bestehenden Dialogelementen, wie sie die verschiedenen
Bibliotheken wie beispielsweise Java Swing bieten, neue Komponenten zu finden. Diese
sollten es ermöglichen die Qualität einer Benutzerschnittstelle unter software-ergonomischen
Gesichtspunkten zu erhöhen.
Nach längerer Internetrecherche konnten einige neue Komponenten bzw. ergänzende
Grafik-Bibliotheken gefunden werden, die dazu beitragen können einen Dialog intuitiver und
ergonomischer zu gestalten.
Im Folgenden werden hier einige neuartige Komponenten beschrieben:
28
Window Shade Container
Abbildung 3.3: Window Shade Container – closed [Hudson97]
Abbildung 3.4: Window Shade Container – opened [Hudson97]
Durch anklicken der „Zugschnurr“ wird das Rollo geöffnet bzw. geschlossen. Dadurch
können Informationen, die erst zu einem späteren Zeitpunkt notwendig sind verdeckt
werden.
Das Beispiel in den Abbildungen 3.3 und 3.4 entstammt dem auf Java basierenden Toolkit
subArctic und wurde am Georgia Institut of Technology entwickelt. Weitere Informationen
hierzu sind auf der Internetseite http://www.cc.gatech.edu/gvu/ui/sub_arctic zu finden.
29
Shockwave Demo des IBM RealPhones
Abbildung 3.5: IBM RealPhone [IBM]
Die Funktionalität des in Abbildung 3.5 gezeigten virtuellen Telefons könnte in etwas
abgeänderter Form beispielsweise dazu verwendet werden um Information und Funktion zu
einem Objekt aus einer Liste anzuzeigen.
Beim System PMX kommt es häufig vor, dass sehr viele unterschiedliche und zum Teil erst
zu einem späteren Zeitpunkt notwendige Informationen in einem Fenster oder Panel
dargestellt werden. Mit Hilfe der Komponente in Abbildung 3.5 könnten Informationen besser
strukturiert werden. Dadurch, dass hierbei zunächst nur die wichtigsten Informationen direkt
sichtbar sind, fühlt sich der Benutzer nicht mit einer Vielzahl von Elementen überfordert.
Außerdem vermittelt eine solche Komponente beim Benutzer den Eindruck, dass diese
Funktionen nicht grundlegend wichtig sind und er sich um sie erst später kümmern muss.
Um eine solche Komponente bei der Neugestaltung eines Dialogs verwenden zu können,
müsste diese aber selbst programmiert werden, da sie in bekannten Grafik-Bibliotheken nicht
zur Verfügung steht. Hier muss man abwägen ob sich dieser Zeitaufwand lohnt, oder ob es
bereits bestehende Alternativen gibt.
30
JGraph
Abbildung 3.6: JGraph [Sun01]
Dies ist ein Beispiel aus dem JGraph-Package für Swing mit dem Graphen verschiedenster
Formen dargestellt werden können. Da im System PMX viele verschiedene Objekte, die zu
einander in Beziehung stehen, verwaltet werden müssen, ist zu überlegen diese
Beziehungen anhand eines solchen Graphen zu visualisieren.
3.2.3
Fisheye-View
Fisheye-Views dienen dazu sehr große aber auch sehr komplexe Informationsmengen
darzustellen. Sie ermöglichen es lokale Details eines ausgewählten Bereichs in einem
globalen Zusammenhang zu visualisieren. Nach [Preim99] ist sowohl unsere visuelle
Wahrnehmung als auch unser Denken von der Konzentration auf lokale Details und einem
(globalen) Überblick über wichtige Informationen gekennzeichnet. Fisheye-Views
unterstützen diese Eigenschaften des Menschen indem sie wie eine Lupe funktionieren und
dem ausgewählten Punkt des Interesses mehr Platz geben um somit die dortige Information
detaillierter oder einfach größer anzuzeigen.
Das folgende Bild zeigt ein Fisheye-Menu. Die Technik des Fisheye-Views wird aber auch in
anderen Bereichen, wie beispielsweise zur Darstellung großer Listen oder zur Visualisierung
von Landkarten eingesetzt.
31
Abbildung 3.7: Fisheye-Menu [HCIL00]
Ein Hyperbolic Browser ist ebenfalls ein Beispiel für einen Fisheye-View. Dabei wird eine
hierarchische Struktur auf einer hyperbolischen Oberfläche dargestellt. Durch Verschieben
der Struktur mit Hilfe der Maus können die gewünschten Teile genauer betrachtet und
ausgewählt werden. Ein solches Element dient dazu relativ große Informations-Strukturen
darzustellen und vereinfacht die Suche. Abbildung 3.8 zeigt einen Hyperbolic Browser.
Abbildung 3.8: Hyperbolic Browser [inxight02]
32
Auch mit einem solchen Element könnten komplexe Beziehungen von Objekten im PMXSystem dargestellt werden.
3.2.4
Zoombare User Interfaces - ZUI
Zoombare Benutzeroberflächen ermöglichen es auf einer sehr großen Benutzeroberfläche
verschiedene Applikationen oder zu bearbeitende Objekte zu platzieren. In einer
Übersichtsdarstellung sind alle Gegenstände ohne irgendwelche Details zu sehen. Durch
entsprechendes Zoomen kann dann das gewünschte Objekt fokussiert und bearbeitet
werden.
Beispiel eines ZUI:
Abbildung 3.9: Zoombares User Interface – Großansicht [HCIL00]
Abbildung 3.10: Zoombares User Interface – Detailansicht [HCIL00]
3.2.5
33
Virtuelle Realität und 3D User-Interfaces
Waren früher 3D Systeme nur auf teuren High-End-Rechnern einsetzbar, so ermöglichen es
heutige Standard-PCs dreidimensionale Benutzerschnittstellen und virtuelle Welten mühelos
darzustellen.
Verglichen mit 2D bzw. 2,5D Dialogsystemen werden bei 3D Benutzerschnittstellen die
Elemente in einem xyz-Raum angeordnet und werden somit auch mit 3D Koordinaten
beschrieben. Die Überlegungen bezüglich des Designs sind hier wesentlich komplexer.
Zudem müssen Metaphern und Elemente für diese Darstellung neu definiert werden, da die
bisherigen Komponenten wie Fenster, Icons, Menüs und Zeigegeräte speziell für 2D
Benutzerschnittstellen geschaffen wurden.
Trotzdem bietet eine dreidimensionale Benutzerschnittstelle wesentlich mehr
Gestaltungsmöglichkeiten hinsichtlich Metaphern und Elementen, da hier wirklich Dinge der
realen Welt im virtuellen Raum abgebildet werden können, wie beispielsweise eine
Büroumgebung als Office-Metapher. Zudem sind auch wesentlich komplexere
Dialogkomponenten vorstellbar.
Die folgenden zwei Beispiele zeigen Möglichkeiten des Einsatzes von 3D-Userinterfaces:
Task Gallery
Abbildung 3.11: Task Gallery[Micros00]
Dieser Prototyp eines 3D User Interfaces wurde von Microsoft entwickelt. Er erweitert den
Desktop in ein komplettes Büro mit einer unlimitierten Anzahl an virtuellen Desktops. Der
Bildschirm wird zu einem langen Raum mit Bildern an der Wand, die die verschiedenen
Aufgabenbereiche darstellen. Der Benutzer kann sich hier sehr schnell und einfach per
Mausklick und Tastatureingaben von einer Aufgabe zur nächsten bewegen.
Laut Microsoft soll durch dieses Interface beim Benutzer der Eindruck entstehen sich durch
einen realen Raum zu bewegen. Dies soll dazu führen, dass er das System intuitiv versteht
ohne es erlernen oder sich ihm anpassen zu müssen.
Microsoft:
34
Je weniger Menschen darüber nachdenken wie sie mit ihrem Computer
umzugehen haben, desto mehr mentale Energie haben sie übrig für ihre
eigentliche Arbeit.
Der Conetree
Abbildung 3.12: Conetree [Geisler98]
Dieses Visualisierungselement stellt eine Baumstruktur dreidimensional dar. Durch Ziehen
an einem Kegel kann dieser gedreht und das gewünschte Element (Menüpunkt, Objekt oder
Programm) in den Vordergrund geholt werden. Zusätzlich kann beispielsweise durch einen
<Shift>-Klick auf das gewünschte Element dieses automatisch nach vorne gedreht werden.
3.2.6
Adaptive Systeme
Beim Begriff Adaptive Systeme wird unterschieden zwischen
·
·
Adaptivität (das System passt sich an die Benutzer an) und
Adaptierbarkeit (das System kann vom Benutzer durch Parametrierung angepasst
werden)
Adaptierbare Systeme
Mit Hilfe entsprechender Werkzeuge kann der Benutzer das User Interface an seine
Bedürfnisse, an Anforderungen spezieller Aufgaben oder nach anderen Kriterien anpassen.
Beispiele hierfür sind die Auswahl der Hintergrunddarstellung, die Einstellung der Maus oder
die Größe von Schriften. Die notwendigen Werkzeuge zur Manipulation dieser Parameter
sollten den Benutzer dabei nicht unnötig belasten.
Adaptive Systeme im Sinn von „Adaptivität“
Diese zeichnen sich durch selbstständige Anpassung an den Benutzer aus. Ziel hierbei ist
die Verbesserung der Benutzbarkeit eines User Interfaces aber auch die Steigerung der
Effizienz und Effektivität der Arbeit.
35
User Interface Agenten
Das Adaptieren einer Benutzerschnittstelle wird häufig von Agenten ausgeführt. Da jedem
Benutzer ein eigener Agent zugeordnet ist, werden sie in diesem Zusammenhang auch
häufig als „persönliche Agenten“ bezeichnet. Diese können Benutzer bei einer Reihe
unterschiedlicher Aufgaben unterstützen [Holzin01]:
·
·
·
·
·
Verbergen der Komplexität von schwierigen Aufgaben,
Ausführen von (definierten) Aufgaben im Auftrag des Benutzers,
Trainieren oder Lehren des Benutzers,
verschiedenen Benutzern bei der Zusammenarbeit helfen,
Ereignisse oder Prozeduren überwachen.
Da es trotz der relativ langen Geschichte von Agenten noch keine einheitliche Definition des
Begriffs „Agent“ gibt, nennt [Holzin01] einige Eigenschaften, die für einen Agenten notwendig
sind:
·
·
·
·
·
·
·
·
Autonomie
Der Agent kann unabhängig vom Benutzer Entscheidungen treffen. Damit dies möglich
ist muss der Agent Informationen über seine Aktionen und seinen augenblicklichen
Status haben.
Zuverlässigkeit
Bei der Delegation einer Aufgabe an einen Agenten wird, sofern keine Kontrolle
stattfindet, ein gewisses Risiko eingegangen. Der Benutzer muss deshalb seinem
Agenten „vertrauen“ können, dass die ihm übertragenen Aufgaben auch in der
gewünschten Form ausgeführt werden.
Reaktionsfähigkeit
Ein Agent muss Veränderungen in seiner Umgebung war nehmen und darauf reagieren
können.
Zielorientierte Initiative
Außer der Fähigkeit zur Reaktion sollte ein Agent auch aktiv die Initiative ergreifen
können. Dies muss aber zielorientiert sein, es dürfen keine Aktionen ausgeführt werden,
die keinen Einfluss auf die Realisierung eines Ziels haben.
Kommunikationsfähigkeit
Ein Agent sollte mit dem Benutzer als auch mit anderen Agenten kommunizieren können.
Kooperationsfähigkeit
Die Kooperationsfähigkeit ist eine Spezialisierung der Kommunikationsfähigkeit und
bezieht sich auf die Kommunikation zwischen Agenten zum Zweck der Zusammenarbeit.
Lernfähigkeit
Ein persönlicher Agent soll seinem Benutzer beim Umgang mit verschiedenen
Anwendungen helfen.
Anthropomorphismus
Hiermit ist die Darstellung menschenähnlichen Verhaltens gemeint, was zwar keine
notwendige Eigenschaft ist, die Akzeptanz beim Benutzer aber erhöhen kann.
Cartoonistische Gesichter oder spracherkennende Systeme können hier zur Realisierung
verwendet werden. Abbildung 3.13 zeigt einen anthropomorphen Agenten in Form eines
cartoonistischen Gesichtes.
36
Abbildung 3.13: anthropomorpher Agent [TUD00]
·
Logisches, intelligentes Verhalten
„Intelligente“ Systeme haben zumindest einen Teil der folgenden Eigenschaften:
- Sie sind in der Lage, Wissen zu benutzen um Probleme zu lösen;
- Sie können Aktionen vorschlagen;
- Sie beginnen mit grundlegenden Informationen über einen Bereich und erweitern
dieses Wissen.
Bei der Frage ob ein User-Interface-Agent in einem System implementiert werden soll, muss
man sehr genau abwägen. Vorteile sind, dass der Einsatz eines solchen Agenten den
Lernaufwand reduzieren und die Akzeptanz eines Systems erhöhen kann. Durch die
Realisierung von anthropomorphen Verhaltensweisen, wird das Bedienen einer
Benutzerschnittstelle natürlicher und der Benutzer fühlt sich persönlich angesprochen.
Nachteilig könnte es sein, dass das Abnehmen von Entscheidungen den Anwender eher
verunsichert anstatt ihn unterstützt. Zudem wirkt die Unterstützung durch einen Agenten auf
einen Experten eher störend.
Grundsätzlich kann ein Agent eingesetzt werden, wenn ein System häufig von Personen
benutzt wird, die im Umgang mit Computern noch unsicher sind. Durch die natürlichen
Verhaltensweisen und Interaktionsmöglichkeiten kann einem solchen Benutzer die erste
Scheu und Unsicherheit bei der Bedienung eines Systems genommen werden und der Agent
kann ihn zudem lehrend unterstützen.
Agenten sollten so gestaltet werden, dass die Abnahme von Aufgaben und Entscheidung
nicht automatisch erfolgt, sondern beim Anwender erfragt wird. Da selbst dies sehr störend
sein kann, sollte es zudem möglich sein den Agenten auszuschalten.
3.2.7
Akustische Interaktion - Sprache
Betrachtet man die gegenwärtigen weit verbreiteten Betriebs- und Dialogsysteme, so sieht
man, dass der Nutzung von Akustik bisher sehr wenig Bedeutung zukommt. Wenn sie
einmal Einsatz findet, dann meist nur in Form von Geräuschen und Klängen zur
Unterstützung von Warnmeldungen und Hinweisen.
Dabei hat die Entwicklung gerade von sprachlichen Interaktionssystemen heute einen Stand
erreicht, der in verschiedenen Bereichen durchaus sehr sinnvoll anzuwenden ist. Zudem
stellt die Sprache eine wesentlich natürlichere Interaktionsform für den Menschen dar als
beispielsweise die Verwendung von Tastatur und Maus.
Auf dem Gebiet der sprachlichen Interaktion muss man grundsätzlich unterscheiden
zwischen Spracheingabe durch den Benutzer über ein Mikrofon und der Sprachausgabe
durch den Computer.
37
Spracheingabe
Bei der Spracheingabe über ein entsprechendes Spracherkennungssystem wie dem
Programm ViaVoice von IBM, wird das akustische Sprachsignal des Benutzers über ein
Mikrofon aufgenommen und über einen A/D-Wandler digitalisiert. Aus den digitalen Daten
werden Rückschlüsse auf die darin enthaltenen Phoneme gezogen und eine Phonemkette
generiert. Ausgehend von dieser wird dann anhand von Neuronalen Netzen oder MarkovModellen ein Bezug zum entsprechenden Wort oder zur Wortfolge hergestellt [Schukat95].
Spracherkennungssysteme sind gegenwärtig unter bestimmten Bedingungen schon sehr
performant und bieten im Vergleich zu herkömmlichen Eingabeformen einige Vorteile. Zu
diesen Vorteilen zählen [Schukat95]:
·
·
·
·
·
·
Höherer Durchsatz
Per Spracheingabe kann durchaus eine Rate von 120 - 250 Worten pro Minute erreicht
werden. Im Vergleich hierzu schaffen stark geschulte Personen per Tastatur eine Rate
von 100 – 150 Worten pro Minute, während ungeschulte Personen auf eine Rate von 10
– 25 Worten kommen.
Natürliche Interaktionsform des Menschen
Es gibt heute noch sehr viele Menschen, die sich unsicher sind im Umgang mit
Computern. Da die Sprache eine sehr natürliche Interaktionsform des Menschen ist,
schafft eine Sprachschnittstelle Vertrautheit, und hilft Benutzern solche Unsicherheiten zu
nehmen.
Hände und Augen des Benutzers sind zudem frei für weitere Aktivitäten.
Die Bewegungsfreiheit von Anwendern eines Systems wird nicht durch mitzuführende
Geräte eingeschränkt.
Sprache kann einen primären Interaktionskanal ergänzen.
Der akustische Kanal bleibt auch unter erschwerenden Bedingungen, wie Dunkelheit
oder extremen Bewegungseinschränkungen voll funktionsfähig.
Soll Sprache als Interaktionskanal in einem Dialogsystem eingesetzt werden, sind einige
Kriterien zu beachten, die entscheidend sind für den effizienten Einsatz [Schukat95],
[IBMVia01]:
Wortschatz
Zum einen entscheidet der Sprachumfang über die Performanz, also über die Schnelligkeit
und die Genauigkeit der Spracherkennung. Sind wenige Vokabeln im Lexikon des
Erkenners, ist eine Erkennung einfacher durchzuführen. Dasselbe ist der Fall, wenn die
Grammatik der zu erkennenden Teilsprache relativ starr vorherbestimmt ist. Die Grammatik
bestimmt welche Wörter in einer Äußerung aufeinander folgen dürfen, und welche nicht. Sie
schränkt damit die Menge der zu unterscheidenden Wörter ein.
Als Beispiel liegt die Erkennungsgenauigkeit bei einem System zur Bedienung einer
Maschine mit einem Vokabular von ca. 200 Worten wesentlich höher als bei einer
Diktiermaschine, die über einen Wortschatz von ca. 100000 Worten verfügt.
kontinuierlich gesprochene Sprache
Ein anderes Kriterium für den Einsatz von Spracherkennung ist die Art der Darbietung von
gesprochener Sprache. In einigen Anwendungen reicht das Sprechen einzelner Wörter aus.
Bei der Einzelworterkennung muss zwischen den gesprochenen Einheiten eine deutliche
Pause gemacht werden. Dies erleichtert die Erkennung von Sprache.
Ist der Sprachumfang für eine bestimmte Anwendung relativ groß, erscheint es nicht mehr
sinnvoll den Sprecher einzelne Worte sprechen zu lassen. Für Anwendungen, bei denen
man nicht mit wenigen Wörtern, etwa zur einfachen Kontrolle von Prozessen (Start, Stop,
38
Pause...) auskommt, ist kontinuierlich gesprochene Sprache vorzuziehen. Dies führt aber zu
einem Anstieg der Fehlerrate.
Unabhängigkeit vom Sprecher
Wichtig für die Leistungsfähigkeit eines spracherkennenden Systems ist, ob das System die
Sprache eines einzigen Sprechers erkennen soll, oder ob die Spracherkennung
sprecherunabhängig ist. Erkennt das System nur Äußerungen eines Sprechers, sind die zu
modellierenden Varianzen innerhalb der Sprache geringer. Systeme für die Erkennung von
Sprache eines einzigen Sprechers sind daher effizienter, versagen aber bei der Erkennung
von Äußerungen anderer Sprecher. Wie das System nun konzipiert sein sollte, hängt von der
erforderlichen Genauigkeit, Effizienz und vom Zweck des Einsatzes ab.
Umgebungsgeräusche
Nachteilig bei einem Spracherkennungssystem sind Umgebungsgeräusche. Grundsätzlich
sollte die Person, die ein solches System nutzt räumlich getrennt von anderen arbeiten, da
beiderseitige Störungen dadurch vermieden werden.
Anhand der genannten Kriterien ist abzuwägen ob der Einsatz von Spracherkennung bei
einem neu zu gestaltenden Bedienkonzept sinnvoll ist.
Sprachausgabe
Die Erzeugung eines Sprachsignals durch einen Computer besteht aus den 3 Schritten
Antwortgenerierung, Sprachsynthese und der eigentlichen Ausgabe des Sprachsignals
[Hameri00].
Antwortgenerierung:
Die Rückmeldungen des Systems müssen dem Benutzer in einer verständlichen
Form übermittelt werden. Hierbei ist darauf zu achten, dass Daten in gesprochener
Form vom Benutzer anders aufgenommen werden wie die Darstellung dieser in Form
von Tabellen oder Aufzählungen. Zudem sollte mit einem solchen System ein
Feedback über die bisherigen Aktionen gegeben werden, wobei eine
Informationsüberflutung jedoch zu vermeiden ist. Die Antwortgenerierung plant somit
den genauen Output und gibt dann das Ergebnis an die Sprachsynthese weiter.
Sprachsynthese:
Die Sprachsynthese übernehmen sogenannte Text-To-Speech Systeme (TTS) wie
beispielsweise das Programm Realspeak von Lernout & Hauspie (L & H). Diese
wandeln den Output der Antwortgenerierung in ein digitales Sprachsignal und senden
dieses an den Ausgabekanal.
Da TTS-Systeme genauso wie Spracherkenner sprachabhängig sind, d.h. sie
verwenden beispielsweise für deutschen Text die Ausspracheregeln der deutschen
Sprache, führt dies häufig gerade bei Fremdwörtern oder Anglismen zu
Aussprachefehler. Deshalb wird teilweise als Alternative die Technik der
Sprachwiedergabe (reproduktive Sprachsynthese) verwendet. Hierbei werden bereits
aufgenommene Sprachsignale entsprechend verknüpft.
Ausgabe des Sprachsignals
Entsprechend der Umgebungsbedingungen und der Art des Systems erfolgt die
eigentliche Sprachausgabe dann über Lautsprecher, Kopfhörer oder übers Telefon.
39
Sprachausgabesysteme werden bisher hauptsächlich in Telefonsystemen genutzt und
sollten in Dialogsystemen nur eine Ergänzung sein, da sie noch nicht ausgereift sind und das
erzeugte Sprachsignal noch einen sehr künstlichen Klang hat [Hammeri00].
In Bezug zu PMX ist es durchaus vorstellbar die Interaktion per Sprache zu unterstützen.
Das Anlegen verschiedener Objekte könnte beispielsweise per Spracheingabe durchgeführt
werden. Bei den einzugebenden Daten handelt es sich meist nur um einzelne Worte, die
relativ gut erkannt werden. Die Erkennung von Fachbegriffen könnte vor dem Einsatz des
Systems trainiert werden. Eine Benutzerführung könnte zudem durch Sprachausgabe
ergänzt werden.
3.2.8
Gestenbasierte Interaktion
Bei dieser Interaktionsform werden Hand- und Kopfbewegungen über eine Kamera
aufgenommen und interpretiert. Dabei ist es wichtig, dass die Gesten gut voneinander zu
unterscheiden sind und der Benutzer diese ermüdungsfrei und bequem ausführen kann.
Zudem müssen die Gesten so gewählt werden, dass sie sich eindeutig voneinander
unterscheiden
Grundsätzlich werden bei gestenbasierter Interaktion Bildsequenzen aufgenommen und an
den eigentlichen Erkennungsprozess weitergeleitet. Die Erkennung erfolgt dann, ähnlich der
Spracherkennung,
über
Hidden-Markov-Modelle
(HMM).
Die
Zustände
und
Zustandsübergänge einer Geste sind jeweils durch ein HMM repräsentiert. Die
aufgenommen Bildsequenzen werden mit den vorhandenen HMMs verglichen und die
entsprechende Geste mit der höchsten Übereinstimmung erkannt.
Verwendung findet die Gestenerkennung beispielsweise bei Präsentationssoftware, bei der
der Vortragende den Verlauf seiner Präsentation durch Handbewegungen steuern kann. Ein
Beispiel hierfür ist das Projekt BodyTalk an der Universität Dortmund [BodyTa00].
Für das Anlegen und Verwalten von verschiedenen Objekten im PMX-System macht die
Gestenerkennung wohl eher weniger Sinn. Sie könnte aber beispielsweise in anderen
Modulen wie beispielsweise zur Steuerung des Wiegevorgangs im Modul DISY Verwendung
finden.
[Holzin01]
3.2.9
Haptische Eingabegeräte
Der Begriff Haptik steht für den Tastsinn des Menschen. Haptische Eingabegeräte
unterstützen diesen Sinn indem sie Rückmeldungen darüber geben, mit welchen
Materialeigenschaften wie beispielsweise Widerstandsfähigkeit, Beschaffenheit der
Oberfläche oder Temperatur, virtuelle Objekte behaftet sind. Dabei ist es wichtig, dass diese
Eindrücke glaubhaft sind, also den Erfahrungen entsprechen, die der Benutzer mit einem
vergleichbaren realen Gegenstand gemacht hat.
Zu den haptischen Stimulationsmöglichkeiten zählen:
-
Widerstand
Temperatur
Vibration
-
40
elektrische Ströme
Geräte die den Tastsinn bereits unterstützen sind bestimmte Mouse-Arten, Joystick (mit
Vibrationseffekt) oder ein Thermischer Handschuh.
3.2.10 Weitere innovative Interaktionsformen
Neben den vorgestellten neuen Möglichkeiten der Gestaltung von Benutzerschnittstellen gibt
es noch einige weitere innovative Interaktionsformen. Beispielhaft ist hier der Bereich der
Computer-Augmented Reality zu nennen. Hierbei wird das reale physikalische Umfeld des
Benutzers durch allgegenwärtige Interaktionsmöglichkeiten mit dem Computer ergänzt
(Ubiquitous Computing). Sensorik und Gestenerkennung sind für diese Interaktionsform
Schlüsseltechnologien.
Da solche Möglichkeiten für die Gestaltung eines neuen Bedienkonzeptes aber gegenwärtig
nicht relevant sind, wird in dieser Arbeit nicht näher auf sie eingegangen.
3.3 Höhere Qualitäten - Joy of use
Anyone want me to bake them a cake? How about some
cookies?? I just got this mixer a couple of months ago and I
absolutely adore it! First of all, it has a nicely designed body. It's
very sleek with rounded corners, which I find appealing.
Secondly, it is so lightweight. It's very easy to maneuver
around, even in the heaviest batter.
Werbung eines Online-Shop für einen Mixer
[Hassen01] behauptet in seinem Artikel „Engineering Joy“, dass die bisherigen Ziele des
Usability Engineering, ein benutzbares und benutzerfreundliches System zu schaffen, bei der
Entwicklung moderner User Interfaces nicht mehr ausreichen. Benutzer sollen nicht nur ein
System antreffen, das sie leicht verstehen können und das sie bei der Arbeit unterstützt. Das
Bedienen moderner Software sollte dem Benutzer zusätzlich auch Freude bereiten, eben
zum Joy of use führen.
Da es bezüglich des Joy of use verschiedene Ansichten zur Definition und zum Erreichen
dieses Zieles gibt, beschreibt [Hassen01] die folgenden 3 Blickwinkel aus denen dieser
Begriff in der gegenwärtigen Literatur gesehen wird:
-
Reduzierung auf Benutzbarkeit
Hierbei geht man davon aus, dass die Freude am Benutzen letztendlich aus der
Benutzbarkeit einer Software resultiert. Die Frage hierbei ist nicht mehr, wie man
Software entwirft die Spaß macht, sondern wie gut das Usability Engineering umgesetzt
wird, um zu einer exzellent benutzbaren Software zu gelangen. Man geht hierbei davon
aus, dass eine sehr gut zu benutzende Software automatisch auch Freude macht.
-
Reduzierung auf das Design
41
Diese Sicht reduziert die Freude am Benutzen auf eine Qualität, die Designer einer
Software geben. Hier wird Joy of use mehr als oberflächliche Eigenschaft einer Software
gesehen. Tiefere Qualitäten wie die Interaktionsgestaltung und die vorhandenen
Funktionalitäten werden dabei außer Acht gelassen. Das Zusammenspiel von
Visualisierung, Interaktion und Funktionalität bleibt unberücksichtigt.
-
Reduzierung auf das Marketing
Hierbei wird der Gedanke des Joy of use simpel als eine Forderung des Marketing
gesehen. Der Gedanke ist, dass Software die gut aussieht sich auch besser verkauft.
[Hassen01] erwähnt diese Blinkwinkel, sagt aber auch gleich, dass sie für eine genaue
Definition und für das Erreichen des Joy of use nicht ausreichen. Eine Software bei der zum
einen die Funktionalität und zudem auch das Design stimmt, ist zwar angenehm zu
bedienen, führt aber noch lange nicht zur eigentlichen Freude am Benutzen.
3.3.1
Gründe warum Software Freude machen sollte:
Warum die gegenwärtigen Ziele wie Bedienbarkeit und Benutzerfreundlichkeit nicht mehr
ausreichen erscheint auf den ersten Blick nicht nachvollziehbar. Ein Software-System soll
doch in erster Linie dazu dienen Aufgaben durchzuführen und nicht Spaß zu haben.
[Hassen01] nennt hier aber folgende Gründe warum Software zusätzlich auch Freude
bereiten sollte:
·
·
·
·
Akzeptanz und Zufriedenheit mit dem System wird gesteigert
Ein User Interface, das Freude bereitet wird eher als nützlich empfunden
Eine Steigerung der Freude an der Arbeit erhöht auch die Qualität
Bei Lernsystemen wird durch eine Software, die Spaß macht auch der Lernerfolg
gefördert
3.3.2
Hedonistische Qualitäten
Bei der Entwicklung eines User Interfaces reicht es natürlich nicht aus die positiven
Eigenschaften einer Software, die Freude bereiten soll, zu kennen. Um das Ziel des Joy of
use zu erreichen müssen laut [Hassen01] zusätzlich zu guten Interaktionsmöglichkeiten und
guter Funktionalität hedonistische Komponenten in ein System eingebaut werden.
Hedonismus = Auffassung, dass das Streben nach Genuss und Lustgewinn die
Triebfeder menschlichen Handelns sei.
Langenscheidts Fremdwörterbuch online
Hedonistische Komponenten sind somit Eigenschaften einer Benutzerschnittstelle, die mit
dem eigentlichen Ausführen von Aufgaben nichts zu tun haben. Im einfachsten Fall könnte
dies beispielsweise die Verwendung von Grafiken oder der Einsatz von Farbe sein.
Auf dem Weg zum Joy of use ist es allerdings sehr wichtig, dass man sowohl hedonistische
als auch aufgabenbezogene Qualitäten nicht aus den Augen verliert. Eine extrem gut
benutzbare aber langweilig gestaltete Software wird genauso wenig zum Joy of use führen
wie ein aufregend gestaltetes aber völlig unbrauchbares System.
Was führt nun zu hedonistischen Qualitäten einer Software? [Hassen01] nennt hier
beispielhaft die folgenden zwei Eigenschaften:
-
42
Das Bedürfnis nach Neuem und nach Abwechslung
Ein Mensch fühlt sich am wohlsten auf einem optimalen Reizniveau, auf dem weder
Überstimulierung noch Monotonie auftreten. Eine mit einem System durchzuführende
Aufgabe sollte eine Herausforderung darstellen aber für den Benutzer auf jeden Fall
durchführbar sein. Ein solcher Zustand führt dazu, dass ein Anwender von seiner
Aufgabe eingehüllt wird und dadurch Freude empfindet.
Diese Eigenschaft bezieht sich auf das Innere eines Menschen und seinen
Entwicklungsstand. Hierbei ist es wichtig die Vorkenntnisse und Fähigkeiten der Benutzer
zu kennen um bei der Realisierung eines neuen User Interfaces ein solches Niveau zu
schaffen.
-
Das Bedürfnis sich durch Dinge auszudrücken und mitzuteilen
Dieses Bedürfnis richtet sich auf das Äußere eines Menschen und auf die Menschen, die
ihn umgeben. Das Sich-ausdrücken und -mitteilen durch Dinge bedeutet hier, dass
Dinge, wie beispielsweise auch ein Softwareprogramm, bewusst oder unbewusst genutzt
werden um den Status einer Person auszudrücken. Ein Experte zu sein und etwas zu
verstehen was andere nicht verstehen, sich etwas leisten zu können was sich andere
nicht leisten können, oder etwas zu besitzen was andere gerne hätten sind treibende
Kräfte, die nicht unterschätzt werden dürfen.
In Bezug zu User Interfaces wird sich ein Experte eines Systems unterfordert oder
womöglich als unfähig eingestuft fühlen wenn er einen Wizard benutzen soll.
3.3.3
Semantic Differential
Um hedonistische Eigenschaften in einem Softwaresystem zu realisieren nennt [Hassen01]
neben anderen Vorgehensweisen die Technik des Semantic Differential zum Messen
hedonistischer Qualität. Hierbei werden sieben verschiedene Paare von Adjektiven
eingesetzt, die jeweils für das Vorhandensein oder für das Fehlen hedonistischer
Eigenschaften stehen. Ein Prototyp des zu entwickelnden Systems wird verschiedenen
Personen, die die spätere Benutzergruppe repräsentieren, vorgestellt. Eine Bewertung des
Entwurfs findet dann nach dem in Tabelle 3.1 gezeigten Auswertungsbogen statt.
überragend
exklusiv
beeindruckend
einzigartig
innovativ
erregend
interessant
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
zweitklassig
standard
uninteressant
gewöhnlich
konservativ
stumpfsinnig
langweilig
Tabelle 3.1: Semantic Differential [Hassen01]
Nachdem die Teilnehmer den Prototypen bewertet haben, wird ein Hedonic quality value
durch Summieren oder Berechnen des Durchschnitts bestimmt. Während des
Entwicklungsprozesses wird dies wiederholt durchgeführt, bis ein akzeptabler Wert erreicht
wird.
43
3.4 Psychologische Aspekte - Wahrnehmungspsychologie
Die Wahrnehmungspsychologie als Teilgebiet der allgemeinen Psychologie erforscht die
Verarbeitung von Reizen durch die Sinnesorgane sowie die Ergebnisse (Eindrücke,
Empfindungen) dieser Verarbeitung. Aufgabe der Wahrnehmung ist es die oft ungeordneten
Eindrücke von Außen aufzunehmen und zu organisieren. Der Prozess der Wahrnehmung
lässt sich in folgende drei Teilbereiche aufteilen:
1. Sensorische Empfindung
Hier werden physikalische Energien wie Schallwellen und Licht aufgenommen und in
neuronale Aktivität von Gehirnzellen umgewandelt.
2. Wahrnehmung
Das Wahrgenommene wird in eine innere Repräsentation umgewandelt.
3. Klassifikation
Hierbei wird das Wahrgenommene bekannten Kategorien zugeordnet.
Bei diesem Vorgang findet eine Selektion statt und nur bestimmte Informationen werden
letztendlich wahrgenommen [Holzin01], [Jakob01].
In Bezug zur Gestaltung einer ergonomischen Benutzerschnittstelle bieten die
Farbpsychologie und die Gestaltgesetze als Teilgebiete der Wahrnehmungspsychologie
wichtige Erkenntnisse.
3.4.1
Farbpsychologie
Die farbliche Gestaltung einer Benutzerschnittstelle sollte man so wählen, dass ein Benutzer
diesen Dialog als angenehm empfindet. Dies sollte auch nach mehreren Stunden noch
gewährleistet sein. Ein sinnvoller Einsatz von Farbe erlaubt es zudem die Aufmerksamkeit
des Benutzers auf bestimmte Bereiche zu lenken, die Zusammengehörigkeit von bestimmten
Objekten zu visualisieren oder auch Elementen eine bestimmte Bedeutung zukommen zu
lassen und sie zu kategorisieren. Da Farben nicht real existieren sondern erst durch das
Auge zu Farbempfindungen werden, nimmt sie jeder Mensch unterschiedlich war. Zudem
gibt es verschiedene psychologische Einflussfaktoren, die zu einer unterschiedlichen
Farbwahrnehmung führen:
-
individuelle Faktoren
Durch Erfahrungen mit Farben können diese unbewusste Empfindungen hervorrufen. Ein
Beispiel wäre hierbei die Farbe des Autos das man besitzt. Diese Erfahrungen sind
individuell völlig verschieden und führen zu unterschiedlichen Wirkungen.
-
symbolische Faktoren
Manchen Begriffen werden Farben zugeordnet, die real gar keine Farbe haben (Grün ist
die Hoffnung). Durch Überlieferung sind solche Assoziationen entstanden.
-
kulturelle Faktoren
In verschiedenen Kulturkreisen haben Farben eine unterschiedliche Bedeutung. Ist ein
Engländer „blau“, so ist er nicht betrunken sondern melancholisch. Aber auch Farben aus
dem Logo einer großen Firma wie beispielsweise die Farbe „gelb“ der Post führen zu
kulturell unterschiedlichen Assoziationen.
-
politische Faktoren
Farben werden oft mit politischen Einstellungen oder Ideologien verknüpft, wie
beispielsweise die Farbe „rot“ mit dem Kommunismus oder die Farbe „braun“ mit dem
44
Nationalsozialismus. Eine solche Assoziation führt auch zu individuell unterschiedlichen
Empfindungen.
-
traditionelle Faktoren
Manche Farbassoziationen beruhen auf alten Verfahren der Farbgewinnung und der
Färberei. Da grüne Malerfarben früher Arsen enthielten wird diese Farbe oft auch mit
Giftigem assoziiert.
Trotz der genannten Faktoren, die Farben eine unterschiedliche Bedeutung und Empfindung
zukommen lassen, gibt es auch allgemeingültige Begriffe die mit Farben verbunden werden:
Gelb:
Reife, Wärme, Optimismus,
Veränderung, extrovertiert
Vorwärtsstreben,
Rot:
Aktivität, Dynamik, Gefahr, Temperament,
Eroberungswille, Tatendrang, exzentrisch
Heiterkeit,
Zorn,
Wärme,
Freundlichkeit,
Leidenschaft,
Orange: Freude, Lebhaftigkeit, Spaß, Lebensbejahung, Ausgelassenheit, fanatisch, aktiv
Blau:
Harmonie, Zufriedenheit, Ruhe, Passivität, Unendlichkeit, Sauberkeit, Hoffnung
Grün:
Durchsetzungsvermögen, Frische, Beharrlichkeit, Entspannung, Ruhe, lebensfroh,
naturverbunden
Violett:
Selbstbezogenheit, Eitelkeit, Einsamkeit, Genügsamkeit, introvertiert, statisch
Braun:
Sinnlichkeit, Bequemlichkeit, Anpassung, Schwere, zurückgezogen
Weiß:
Reinheit, Sauberkeit, Ordnung, Leichtigkeit, Vollkommenheit, illusionär
Schwarz: Negation,
Auflehnung,
Undurchdringlichkeit,
Trauer,
Einengung,
Abgeschlossenheit, Funktionalität, pessimistisch, hoffnungslos, schwer
Grau:
Neutralität, Trostlosigkeit, Nüchternheit, Elend, Nachdenklichkeit, Sachlichkeit,
Funktionalität, Schlichtheit, unbeteiligt
[Holzin01], [Jakob01]
Farbmodelle
Farbmodelle dienen zur genauen Definition verschiedener Farben durch numerische Werte.
Um nachfolgend Strategien und Grundsätze einer harmonischen und ergonomischen
Farbgestaltung zu erläutern, werden zunächst die wichtigsten Farbmodelle kurz vorgestellt:
·
·
RGB-Modell
Dieses Farbmodell ist im Bereich der Computergrafik das am häufigsten verwendete
Modell. Es ist ein additives Farbmodell, das heißt die Werte der drei Primärfarben Rot,
Grün und Blau werden addiert und ergeben so die entsprechende Farbe. Dieses Modell
wird durch einen Würfel dargestellt, bei dem jede Dimension einer Grundfarbe entspricht.
Die verschiedenen Farben werden aufbauend auf diesem Würfel durch Koordinaten
bestimmt.
HLS-Modell
Im Gegensatz zum RGB-Modell werden bei diesem Modell die Farben durch die drei
Werte Farbton (Hue), Helligkeit (Luminance) und Sättigung (Saturation) definiert. Die
45
Farbe selbst wird durch den Farbton bestimmt, der besagt ob es sich zum Beispiel um
einen Blauton, Grünton oder Gelbton handelt. Die Sättigung bestimmt den Grauanteil
einer Farbe. Wird die Sättigung verringert so erhöht sich der Grauanteil. Hat eine Farbe
keine Sättigung so erscheint jede Farbe als Grau. Die Helligkeit führt bei einem
maximalen Wert zu Weiß und bei minimalem Wert zu Schwarz. Je nachdem wie stark die
Sättigung ist bestimmt der Helligkeitswert die Helligkeit des Farbanteils und des
Grauanteils.
[Crüger00], [Jakob01]
Strategien für die Farbgestaltung
[Holzin01] nennt einige physiologische und ästhetische Gesichtspunkte die beim Einsatz von
Farbe zu beachten sind:
·
Bei der Gestaltung von Benutzerschnittstellen sollten nie Farbtöne mit unterschiedlicher
Sättigung oder unterschiedlichem Helligkeitsanteil eingesetzt werden, da dies auf den
Benutzer sehr unausgewogen wirkt. Werden Farben eingesetzt dessen Sättigungs- und
Helligkeitswerte gleich sind, wirkt dies auf den Betrachter wesentlich ausgeglichener.
·
Die Farbe eines Elementes beeinflusst auch die Größe, mit der es wahrgenommen wird.
Als Beispiel wirkt ein rotes Quadrat größer als ein gleich großes grünes. Dies könnte
dazu führen, dass ein Benutzer einem roten Element mehr Aufmerksamkeit schenkt als
einem grünen.
·
Menschen sind in der Lage auf einen Blick maximal 7 +/- 2 Objekte wahrzunehmen. Zu
viele verwendete Farben würden daher einen Benutzer überfordern.
·
Blickt ein Benutzer längere Zeit auf einen Bereich in dem stark gesättigte Farben
eingesetzt werden, so kann es sein, dass er, nachdem er den Blick auf eine andere
Stelle richtet, ein Nachbild sieht. Dies kann auf den Betrachter beunruhigend wirken und
belastet zudem die Augen. Große Flächen mit satten Farben sollten deshalb vermieden
werden.
·
Bei der Suche nach einem bestimmten Element oder Objekt kann dieses durch
entsprechende farbliche Unterscheidung wesentlich schneller gefunden werden als durch
andere Merkmale. Haben Elemente die gleiche Farbe, können diese auch schneller
gezählt werden als bei anderen Gemeinsamkeiten.
·
Kontrast führt zu einer Veränderung der Wahrnehmung einer Farbe entsprechend der
Partnerfarbe in Richtung des größten Gegensatzes. Dadurch erscheint eine weiße
Fläche auf schwarzem Grund weißer oder eine graue Fläche auf weißem Hintergrund
dunkler. Bei farbigen Partnern bekommt ein Grauton den Anschein die
Komplementärfarbe des Partners anzunehmen. Beispielsweise erscheint Grau auf Gelb
violett, auf Orange blau, auf Rot türkis, auf Purpur grün usw..
·
Der Kontrast beeinflusst zudem auch Farben untereinander. Gelb wirkt neben Grün
wärmer und rötlicher während es neben Orange kälter und grünlicher empfunden wird.
·
Bei der farblichen Gestaltung einer Benutzerschnittstelle sollte diese in seiner
Gesamtheit gesehen werden und Farben sollten sorgfältig überlegt und sparsam
eingesetzt werden. Ein einzelnes Fenster sollte nie mehr als 4 Farben, das ganze
System nicht mehr als 7 Farben aufweisen.
·
46
Eine harmonische Farbgestaltung ergibt sich, wenn mindestens eine der drei
Grundfarben (Rot, Grün, Blau) weggelassen wird.
Schrift und Farbe
Text wird in einem Dialogsystem zumeist als schwarze Schrift auf weißem Hintergrund
dargestellt. Laut [Holzin01] ist dies grundsätzlich auch sinnvoll, da das menschliche Auge
dunkle Schrift auf hellem Hintergrund besser wahrnehmen kann als helle Schrift auf dunklem
Hintergrund.
In manchen Fällen ist es aber auch wünschenswert einem Text einen farbigen Hintergrund
zu geben oder Worte in Farbe darzustellen. Nach [Holzin01] ist hierbei zu beachten, dass
das Auge Schwierigkeiten hat, bei zwei Farben mit unterschiedlicher Wellenlänge beide
scharf zu sehen. Man hat dabei den Eindruck die eine Farbe über der anderen schwebend
zu sehen, was sehr beunruhigend wirkt. Um diesen Chromostereopsie-Effekt zu vermeiden
sollten folgende Farbkombinationen auf keinen Fall eingesetzt werden:
·
·
·
·
·
·
roter Text auf grünem Hintergrund,
blauer Text auf grünem Hintergrund,
roter Text auf blauem Hintergrund,
grüner Text auf blauem Hintergrund,
blauer Text auf rotem Hintergrund und
grüner Text auf rotem Hintergrund.
Die Darstellung von Text mit zu geringem Kontrast zum Hintergrund sollte unbedingt
vermieden werden. Auch die Verwendung von Hintergrundbildern ist nicht empfehlenswert,
da sich der Text nicht deutlich genug abheben kann.
Die Verwendung der Farbe Blau für die Darstellung von Text sollte auch grundsätzlich
vermieden werden. Der Grund hierfür liegt in der Beschaffenheit des Bereiches der
Netzhaut, der für das Scharfsehen verantwortlich ist (gelber Fleck). An dieser Stelle gibt es
kaum blauempfindliche Farbrezeptoren, sodass dieser Bereich fast unempfindlich für blaues
Licht ist. Kleine Objekte in blauer Farbe können deshalb nur sehr schwer wahrgenommen
werden.
3.4.2
Gestaltpsychologie
Dieses Teilgebiet der Wahrnehmungspsychologie entstand gegen Ende des 19.
Jahrhunderts. Christian von Ehrenfels, einer der Begründer dieser Wissenschaft, formulierte
als erster den Begriff der Gestalt als „Das Ganze ist mehr als die Summe seiner Teile“. Er
demonstrierte dies am Beispiel einer Verlaufsgestalt, der Melodie.
Laut [Holzin01] besteht eine Wechselwirkung zwischen den einzelnen Teilen einer Gestalt.
Die Änderung eines Teils führt zur Änderung anderer Teile und somit zur Änderung des
Ganzen.
Bei der Gestaltung von Benutzerschnittstellen kann eine gute Formgebung und Anordnung
von Dialogelementen die Erkennbarkeit und auch die Ergonomie einer Software fördern. Im
Bereich der Gestaltpsychologie beschreiben die Gestaltgesetze die Wirkung von Formen,
ihre Gestaltung und ihre Anordnung. Von den vorhandenen 114 Gestaltgesetzen werden die
wichtigsten hier vorgestellt [Holzin01], [Jakob01]:
·
47
Prägnanz
Das Gesetz der guten Gestalt (Prägnanz) besagt, dass deutliche und prägnante
Gebilde vom Menschen wesentlich leichter wahrgenommen werden. Prägnante Formen,
also Formen die uns täglich begegnen und einfach aufgebaut sind, werden schneller
erkannt und bleiben besser im Gedächtnis. Bei komplexeren Gebilden versucht die
menschliche Wahrnehmung diese zu einfacheren, bereits bekannten Objekten zu
formen.
Für die Gestaltung von Benutzerschnittstellen bedeutet dies, dass Elemente die aus
einfachen Strukturen aufgebaut sind, das Konzentrieren auf die wesentlichen Inhalte
erleichtern.
·
Nähe
Das Gesetz der Nähe zeigt, dass Objekte mit geringem Abstand zueinander als
zusammengehörig empfunden werden. In Abbildung 3.14 wird dies deutlich:
Abbildung 3.14: Nähe
Beim Entwurf von Dialogsystemen sollte diese Erkenntnis zur Abbildung von
zusammengehörigen Elementen genutzt werden.
·
Geschlossenheit
Das Gesetz der Geschlossenheit sagt, dass geschlossene Elemente als
zusammengehörend wahrgenommen werden. Nicht vorhandene Teile einer Abbildung
werden durch die Wahrnehmung ersetzt. In Abbildung 3.15 wird auch deutlich, dass sich
die Gestaltgesetze widersprechen können. Grundsätzlich gilt, dass Geschlossenheit vor
Nähe siegt.
Abbildung 3.15: Geschlossenheit
In Bezug zur Gestaltung von Dialogen lässt sich diese Erkenntnis beispielsweise durch
den Einsatz von Rahmen und Linien umsetzen.
·
Ähnlichkeit
Dieses Gesetz besagt, dass gleich aussehende Elemente als zusammengehörend
wahrgenommen werden. Im folgenden Bild sind schwarze und weiße Kreise zu sehen.
Diese werden als 4 Gruppen wahrgenommen. Das Gesetz der Nähe erlaubt nicht diese
als 2 Gruppen von jeweils 6 schwarzen und 6 weißen Kreisen wahrzunehmen. In diesem
Fall konkurrieren Ähnlichkeit und Nähe.
Abbildung 3.16: Ähnlichkeit
·
48
Kontinuität
Dieses Gesetz wird auch als Gesetz der guten Fortsetzung bezeichnet. Dies besagt,
dass Reize (Linien oder Umrisse), die sich in die gleiche Richtung bewegen als
zusammengehörig empfunden werden.
Abbildung 3.17: Kontinuität
·
gemeinsames Schicksal
Gemäß diesem Gesetz werden Objekte, die eine Bewegung oder Veränderung,
beispielsweise durch Drehen oder Verschieben, in gleicher Form erfahren, als Einheit
wahrgenommen.
Das Verschieben oder Kopieren von mehreren markierten Objekten per Drag and Drop
wäre ein Beispiel für die Umsetzung dieses Gesetzes
·
Symmetrie
Das Gesetz der Symmetrie zeigt, dass symmetrisch angeordnete Objekte als
zusammengehörig empfunden werden. Zudem konzentrieren sich Betrachter eher auf
symmetrische Gebilde.
·
Erfahrung
Gemäß dem Gesetz der Erfahrung, versucht ein Betrachter das Wahrgenommene auf für
ihn bekannte Objekte abzubilden. Dies führt dazu, dass Gegenstände erkannt werden,
die nur teilweise sichtbar sind. Abbildung 3.18 verdeutlicht dies:
Abbildung 3.18: Erfahrung
4 CTM – Clinical Trial Management
CTM ist die PMX-Lösung für das Management klinischer Tests in pharmazeutischen
Unternehmen. Hauptaufgaben bei der Durchführung klinischer Tests sind das Management
der Herstellung von neu entwickelten Medikamenten sowie die Zuteilung dieser
Medikamente an verschiedene Testpersonen (Patienten). Zur Unterstützung dieser
Aufgabenstellungen wurde CTM entwickelt.
Die Vorteile von CTM sind dabei seine Integrierbarkeit in die Unternehmensstruktur als auch
seine spezielle Ausrichtung auf die Bedürfnisse und Vorschriften im Umfeld der
pharmazeutischen Industrie.
Da ein neues Bedienkonzept für diesen Teil von PMX geschaffen werden soll, wird im
folgenden die Funktionalität der CTM-Lösung kurz erläutert. Danach wird das Konzept der
bisherigen Benutzerschnittstelle beschrieben und Schwachstellen werden dargestellt.
4.1 EDB – die Engineering Database von CTM
Das Modul EDB ermöglicht das Anlegen und Verwalten der verschiedenen Objekte, die im
Rahmen des Clinical Trial Management zum Einsatz kommen und die in Bezug zueinander
stehen. Hierzu bietet die EDB folgende Funktionalitäten:
4.1.1
Master Data Management
Die EDB verwaltet alle Stammdaten, die für die Materialverwaltung, Logistik, Studien
(klinische Tests) und Projekte relevant sind. Zu diesen Stammdaten zählen:
·
·
·
·
·
·
·
·
·
·
·
·
Benutzer
Arbeitsplätze
Artikel unterschiedlichen Typs
Adressen
Arbeitspläne
Stücklisten
Herstellungsanweisungen
Etiketten und ihr Layout
textuelle Angaben auf den Etiketten
Länderkennungen
Randomisierungen von Patienten, Intervalle, Medikationen und Medikations-Matrix
Studien oder Projekte und die darauf aufbauenden Aufträge
CTM – Clinical Trial Management
4.1.2
50
Versionskontrolle
Ein Teil der oben genannten Objekte unterliegen der Versionskontrolle. Hierbei müssen die
Objekte verschiedene Zustände, wie beispielsweise „in Bearbeitung“, „gültig“ oder „archiviert“
in ihrem Lebenszyklus durchlaufen. Dies sorgt dafür, dass nur die gültigen Objekte wie
beispielsweise Medikationen verwendet werden können. Jeder dieser Statusübergänge wird
in einer Historie aufgezeichnet.
4.1.3
Herstellungs- und Verpackungsanweisungen
Abbildung 4.1: Herstellungs - und Verpackungsanweisung [PD01a]
Herstellungs- bzw.
Komponenten:
·
·
Verpackungsanweisungen
bestehen
grundsätzlich
aus
den
Arbeitsplan (Routing)
Sie bestehen aus einzelnen Verfahrensschritten (Procedure operations) die die
Ausführung eines Herstellungsschrittes genau beschreiben. Zudem bestimmen sie an
welchem Arbeitsplatz und, wenn notwendig, zu welcher Zeit die Ausführung stattfindet.
Stücklisten (BOM = Bill of Material):
51
In der Stückliste sind die einzelnen Materialien zur Herstellung eines Artikels aufgeführt.
Hier findet auch eine Zuordnung der Bestandteile zum jeweiligen Verfahrensschritt statt,
in dem sie verarbeitet werden.
Die Herstellungs- bzw. Verpackungsanweisung führt diese beiden Komponenten zusammen
und ermöglicht somit auch das Kombinieren beispielsweise eines Routings mit
verschiedenen Stücklisten. Aufbauend auf den Herstellungsanweisungen werden später
Herstellungsaufträge angelegt.
4.1.4
Management von Studien
Studien
Hauptbestandteil der CTM-Lösung ist die Möglichkeit des Verwaltens von klinischen Studien.
Pharmaunternehmen führen Studien durch um die Wirkung eines neu entwickelten
Medikamentes auf eine begrenzte Anzahl freiwilliger Personen zu testen. Solche Studien
können unterschiedlich gestaltet sein. Möglichkeiten der Gestaltung sind hier beispielsweise:
·
·
Durchführung der Studie in einem oder mehreren Ländern.
Offene, einfach-blinde oder doppel-blinde Studie. Dieses Kriterium legt fest ob Patient
und Arzt darüber bescheid wissen was sie einnehmen bzw. verabreichen.
Solche Kriterien können in der Engineering Database von CTM beim Anlegen einer Studie
definiert werden.
Medikationen
Des weiteren ermöglicht die CTM-Lösung Medikationen, die innerhalb einer Studie getestet
werden, zu verwalten. Eine Medikation besteht grundsätzlich aus einem Artikel des
Artikelstammes und stellt somit eine Verbindung zur Herstellungsanweisung und zur
Stückliste her. Diese Medikationen werden im Objekt „Medikationskopf“ zusammengefasst,
welches auf die entsprechende Studie verweißt, in der die Medikationen getestet werden.
Intervalle
Um festzulegen, zu welchem Zeitpunkt welches Medikament an einem Patienten getestet
wird, können Intervalle definiert werden. Diese sind ähnlich wie die Medikationen in einem
Intervallkopf zusammengefasst, der auf eine Studie verweist.
Randomisierungen
Um eine Studie letztendlich durchführen zu können, werden in der Randomisierung jeder
vorgesehenen Behandlungsgruppe (Gruppe von Testpersonen) verschiedene Patienten,
identifiziert durch ihre Nummern, zugeteilt. Diese Zuteilung erfolgt durch eine spezielle
Randomisierungsfunktion. Darauf folgend werden in der Medikations-Matrix die
verschiedenen Medikationen den Behandlungsgruppen zugewiesen.
52
Medikations-Matrix
Abbildung 4.2 zeigt den Snapshot einer Medikations-Matrix. Die Spalten stehen dabei für die
einzelnen Intervalle, während die Zeilen die verschiedenen Behandlungsgruppen („T“ für
Treatment Group) repräsentieren. Durch Auswahl einer Medikation in der Combobox „Matrix
elements“ und Klick auf die Felder der Matrix können diese zugewiesen werden. Der Mfactor definiert lediglich einen Multiplikations-Faktor.
Abbildung 4.2:Snapshot - Medikations-Matrix
Die Randomisierungsfunktion ist ein spezieller mathematischer Algorithmus, der durch die
folgenden Parameter beeinflusst wird:
·
·
·
·
Studientyp, wie cross-over, latin square, ascending dose.
Symmetrische und asymmetrische Randomisierung, definierbar durch den M-Faktor.
Fortlaufende oder nicht-fortlaufende Randomisierung.
Mehrere Patienten-Sätze.
Nachdem eine Studie komplett angelegt und randomisiert wurde, können darauf aufbauend
Herstellungsaufträge erteilt werden. Entsprechend den benötigten Medikamenten werden die
Artikel auf die sie verweisen hergestellt. Wohl bemerkt bietet die CTM-Lösung von Propack
Data keine Funktionalität zur Verwaltung und zur Auswertung der Ergebnisse von Studien.
4.1.5
Design, Pflege und Ausdruck von mehrsprachigen Etiketten
Mit einem in CTM eingebauten Grafikprogramm können die Labels für die Medikationen mit
Codes und Verpackungsdaten erstellt werden. Dieses Programm erlaubt den direkten Zugriff
auf die durch CTM verwalteten Objektdaten (Studiendaten, Patientennummern, usw.).
Auftragsbezogene Daten, medikationsspezifischer Etikettentext sowie Standardtext werden
im Etiketten-Layout zusammengeführt.
Textelemente in verschiedenen Sprachen führen zu einer erheblichen Aufwandsreduzierung
bei der Erstellung und Verwaltung der Labels. Diese Texte sind unterteilt in:
Anwendungshinweise, Hinweise zur Einnahme, Hinweise zur Lagerung, Warnungen, usw..
53
4.2 Analyse
4.2.1
Das bestehende Bedienkonzept
Die gegenwärtige Benutzerschnittstelle für die Engineering Database von CTM bietet im
Grunde nur Sichten auf die einzelnen Tabellen und Datensätze der Datenbank. Um Objekte
wie Stücklisten oder Studien verwalten zu können, müssen diese aus einer Liste, welche die
entsprechende Datenbank-Tabelle darstellt, ausgewählt werden. Die Attribute eines solchen
Datensatzes werden in Dialogfenstern mit häufig zu vielen oder nicht optimal strukturierten
Feldern dargestellt. Zudem ist die Anzahl der verschiedenen Dialogelemente sehr begrenzt.
Hauptsächlich zum Einsatz kommen:
·
·
·
·
·
·
·
·
·
Eingabefelder
Textelemente
Buttons
Listen mit sehr wenigen Möglichkeiten der Manipulierung
Registerkarten mit Reitern
Rahmen und Linien zur Strukturierung der Dialogbestandteile
Comboboxen
Ein Menü im Hauptfenster
Icons auf Buttons
Da alle Objekte bei dem aktuellen User Interface auf die gleiche Weise, eben durch Aufruf
der entsprechenden Liste und Auswahl des Datensatzes, verwaltet werden, ist dieses
Grundkonzept der Bedienung relativ einfach zu erlernen. Da die Aufgabenstellung beim
Anlegen und Verwalten der klinischen Studien aber eine sehr komplexe ist und zudem viele
Abhängigkeiten zwischen den einzelnen Objekten bestehen, gerät der Anwender sehr
schnell in die Situation den Überblick zu verlieren.
Abhängigkeiten der verschiedenen Objekte
Abbildung 4.3 gibt einen ersten Eindruck über die Komplexität der einzelnen in Beziehung
stehenden Objekte. Die Grafik entstammt den Schulungsunterlagen für das Clinical Trial
Management von Propack Data.
54
Abbildung 4.3: Abhängigkeiten der Objekte [PD01a]
Hier nochmals die im zukünftigen Entwurf relevanten Objekte im einzelnen:
Study (Studie)
Hier werden die verschiedenen Eigenschaften, wie das Design der Studie (single-blind oder
double-blind, national oder international, usw.), das Start- und Enddatum oder auch die
Bezeichnung der Studie festgelegt.
Medication header (Medikationskopf)
Er enthält alle Medikationen die bei einer Studie getestet werden. Diese könnten
beispielsweise verschiedene Dosierungen eines Medikaments und ein zusätzliches Placebo
Präparat sein. Für die einzelnen Medikationen muss jeweils eine Stückliste mit den zur
Herstellung notwendigen Bestandteilen bestehen. Im Medikationskopf wird ein Bezug zur
entsprechenden Studie hergestellt.
Interval header (Intervallkopf)
Die verschiedenen Zeiträume (Intervalle) in denen jeweils eine Medikation getestet wird sind
im Intervallkopf definiert. Dieser bezieht sich auf eine entsprechende Studie.
Randomization (Randomisierung)
Eine Randomisierung nimmt Bezug auf eine Studie, einen Medikationskopf sowie einen
Intervallkopf. Hier wird die Gestaltung der Medikations-Matrix festgelegt und die
Randomisierung durchgeführt.
Medication matrix (Medikations-Matrix)
Siehe Kapitel 4.1.4
4.2.2
55
Schwachstellen des gegenwärtigen Bedienkonzeptes
Im folgenden werden nun die Schwachpunkte des bisherigen Systems aufgeführt, die beim
Anlegen und Verwalten von Studien auffallen. Nach der Analyse des bestehenden beginnt
dann die Benutzeranalyse sowie die Analyse der Aufgaben, wie dies im Kapitel 2.2 Usability
Engineering beschrieben ist.
Vergleich mit Richtlinien und Normen:
Tabelle 4.1 zeigt einen Vergleich des gegenwärtigen Benutzerdialoges mit den im Kapitel 2
aufgeführten Grundsätzen der Interaktionsgestaltung wie die VDI- oder ISO-Richtlinien:
Grundsatz
VDI-Richtlinie:
Kompetenzförderlichkeit
VDI-Richtlinie:
Handlungsflexibilität
VDI-Richtlinie:
Aufgabenangemessenheit
ISO 9241:
ISO 9241:
Selbstbeschreibungsfähigkeit
ISO 9241:
Steuerbarkeit
ISO 9241:
Erwartungskonformität
ISO 9241:
Fehlerrobustheit (-toleranz)
ISO 9241:
Individualisierbarkeit
Bezug zu PMX / CTM
Die Handlungskompetenz des Benutzers, also das Wissen
über die Zusammenhänge wird durch das gegenwärtige
System kaum gefördert.
Handlungsflexibilität ist in der Form gegeben, dass der
Benutzer auch bei geänderter Aufgabenstellung seine
Arbeit durchführen kann.
In Bezug zum Kenntnisstand des Benutzers bietet das
System aber keine alternativen Wege zur Erfüllung einer
Aufgabe.
Das Anlegen von Studien und der davon abhängigen
Objekte ist umständlich und unübersichtlich. Bei der
Durchführung der Randomisierung erscheinen meist
Fehlermeldungen, da aufgrund der geringen Übersicht leicht
ein Detail vergessen wird.
siehe VDI-Richtlinie
Rückmeldungen des Systems, die Aufschluss geben über
den aktuellen Zustand eines Dialoges sind kaum
vorhanden.
Der Ablauf beim Anlegen einer Studie ist in dem Maße
steuerbar, dass der Benutzer die Objekte, so lange diese
noch nicht den Status „gültig“ erreicht haben, auch
nachträglich verändern kann. Eine Reihenfolge beim
Anlegen muss eingehalten werden, diese ist aber durch die
Datenbankstruktur bedingt.
Erwartungskonformität ist derart gegeben, dass das Suchen
und Einfügen bzw. Editieren von Objekten immer auf die
gleiche, allerdings recht umständliche Weise erfolgt. Im
Vergleich zu bekannten gegenwärtigen Software Produkten
bietet die CTM-EDB weniger Funktionalität in der
Benutzeroberfläche. Erwartungen werden hier häufig
enttäuscht.
Fehlermeldungen sind meist nicht informativ und die
Fehlerquelle muss mühevoll gesucht werden.
Alternative Wege zur Durchführung einer Aufgabe sind nicht
vorhanden.
ISO 9241:
Lernförderlichkeit
56
Ein mentales Modell des Benutzers wird durch den
gegenwärtigen Dialog in keiner Weise unterstützt. Es ist
keinerlei unterstützende Darstellung vorhanden.
Tabelle 4.1: Vergleich mit Richtlinien und Normen
Weitere grundsätzliche Schwachstellen
·
Beim Start der EDB erscheint das Hauptfenster mit Menüstruktur aber mit leerem
Fensterinhalt. Die zu bearbeitenden Daten müssen grundsätzlich über die Menüstruktur
ausgewählt werden. Ein „Look & Feel“ ist nicht vorhanden. Abbildung 4.4 zeigt dieses.
Abbildung 4.4: Snapshot - Hauptfenster der CTM-EDB
·
·
·
Das Auffinden von Objekten (Studien, Randomisierungen, Medikationsköpfe,
Intervallköpfe, …) aus einer Auswahlliste ist sehr mühsam. Es werden immer nur 100
Zeilen in einer Liste dargestellt. Um zu den nächsten Datensätzen zu gelangen muss
eine Pfeil-nach-unten-Taste gedrückt werden.
Die Auswahllisten bieten sehr wenig Funktionalität. Die Spalten können nicht (wie in
Excel z.B.) vergrößert, verkleinert, ausgeblendet oder vertauscht werden. Zudem ist der
Scrollbar nur eingeschränkt nutzbar.
Die Selektions-Felder für die Auswahllisten belegen die Hälfte des Dialogfensters. Zudem
sind diese nicht einheitlich auf einer Linie ausgerichtet, was unprofessionell wirkt.
Abbildung 4.5 zeigt ein Auswahlfenster für Studien.
57
Abbildung 4.5: Snapshot - Auswahlliste mit Selektionsfeldern
·
·
·
·
Das Anlegen einer Studie und darauf aufbauend das Anlegen von Studien- und
Fertigungsaufträgen, sowie das Auflösen von Fertigungsaufträgen führt zu sehr
komplexen Abhängigkeiten, die kaum überschaubar sind.
Um die CTM-EDB sicher und effizient nutzen zu können, bedarf es einer relativ langen
Einarbeitungszeit. Zudem sollte der Benutzer ständig damit arbeiten, da bei seltener
Anwendung das notwendige Wissen verloren geht.
Eine hierarchische Darstellung, die Bezüge einzelner Objekt zueinander zeigt, gibt es
nicht.
Manche Dialogfenster benötigen mehr Platz als ein 17 Zoll-Monitor mit
Standardauflösung bietet. Dadurch wird es notwendig im Shell-Window zu scrollen um
verdeckte Teile des entsprechenden Fensters sehen zu können.
weitere detailiertere Schwachstellen:
·
·
·
·
·
·
Der Weg um ein Objekt (Studie, Medikationskopf, usw.) anzulegen ist sehr umständlich.
Das entsprechende Auswahlfenster muss zunächst geöffnet werden und in diesem ist
dann der Insert-Button zu drücken.
Um einer neuen Studie ein Medikationskopf-, Intervallkopf- oder Randomisierungs-Objekt
anzufügen, muss dieses Objekt zunächst nach dem im vorigen Punkt beschriebenen
Weg angelegt, dann aber gleich wieder geschlossen (OK-Button) und dann wieder neu
editiert werden, um die restlichen Dateneinträge vorzunehmen. Auf den Anwender wirkt
dies sehr umständlich und benutzerunfreundlich.
Attribut-Namen für das Design einer Studie wie „Design 1“, „Design 3“ sind nicht sehr
aussagekräftig.
Notwendige Eingabe-Felder wie „Planned-Start“ und „Planned-End“ sind in der
Grundeinstellung des Dialogfensters einer Studie nicht zu sehen (Siehe Abbildung 4.7).
Medikationen sind Artikeln aus dem Artikelstamm zugeordnet und diese Artikel haben
jeweils eine Stückliste für die Herstellung. Wird beim Anlegen dieser Stücklisten den
Bestandteilen kein Verfahrensschritt zugeordnet kann später ein Auftrag aufbauend auf
der Studie, die diese Medikationen beinhaltet, nicht ausgeführt werden. Die Folge ist,
dass alle Objekte nochmals angelegt werden müssen.
Innerhalb der CTM-EDB bestehen sehr komplexe Abhängigkeiten der Objekte bezüglich
ihrem Status. Hat ein Objekt beispielsweise noch nicht den Status „gültig“, so ist ein
58
Statusübergang zu „gültig“ für alle abhängigen Objekte nicht möglich. Versucht man
trotzdem einen Statusübergang durchzuführen, erscheint eine Fehlermeldung, die aber
keinen Aufschluss über die Ursache gibt. Abbildung 4.6 zeigt ein Beispiel solcher
Abhängigkeiten:
Randomizierung
Medikationskopf
Medikation
Artikel
Stücklistenposition
Abbildung 4.6: Abhängigkeiten der Objekte in der CTM-EDB
·
Das Dialogfenster einer Studie ist sehr vollgepackt mit Buttons (siehe Abbildung 4.7).
Dies wirkt auf einen Anwender sehr einschüchternd. Diese Buttons führen teilweise zu
weiteren Dialogen, führen aber auch direkt zum Ausführen von Funktionen, die nicht
mehr rückgängig gemacht werden können. Zudem ist das Ergebnis beim Ausführen einer
Funktion nicht direkt zu erkennen. Dies löst Ungewissheit beim Benutzer aus und fördert
nicht das Gefühl etwas erreicht zu haben.
Abbildung 4.7: Snapshot - Dialogfenster einer Studie
·
Beim Neuanlegen einer Randomisierung sind im Dialogfenster im Rahmen
„Randomization“ (Rahmen in Form von Strukturierungselement) 3 Felder von Anfang an
grau unterlegt, erlauben also keine Eingabe. Es scheint als würden diese nicht
veränderbare Daten anzeigen. Hierfür ist ein Eingabefeld nicht sinnvoll.
4.2.3
Analyse der Benutzer
Nachdem die Analyse der gegenwärtigen Benutzerschnittstelle erfolgte wird nun wie im
Kapitel 2.2 Usability Engineering zunächst eine Analyse der Benutzer durchgeführt. Da es in
dieser Arbeit nicht möglich war in Kontakt mit den eigentlichen Benutzern zu kommen,
wurden Mitarbeiter der Abteilung Training & Learning bezüglich den Anwendern der CTMEDB befragt. Anhand folgender Kriterien wurden die Anwender beurteilt:
59
·
Alter, Geschlecht
Das Alter der Anwender kann nicht auf eine bestimmte Altersstufe eingeschränkt werden.
Dieses kann zwischen 25 und 65 liegen. Des weiteren wird das System sowohl von
Männern als auch von Frauen benutzt.
·
Körperliche Fähigkeiten, Behinderung
Grundsätzlich haben die Anwender weder körperliche noch geistige Einschränkungen.
Ein Mitarbeiter der Abteilung Training & Learning berichtete aber von einem Anwender,
der farbenblind war. Dies ist zwar eine Ausnahme, kann aber durchaus bei der
Entwicklung eines neuen Bedienkonzeptes berücksichtigt werden.
·
Ausbildung
- allgemeines Ausbildungsniveau
Das allgemeine Ausbildungsniveau ist sehr unterschiedlich. Die eigentliche
Datenerfassung
erfolgt
häufig
von
weniger
qualifizierten
Anwendern.
Verantwortungsträger, die für das Freigeben erfasster Daten (beispielsweise einer
Studie) zuständig sind, sind dagegen meist hoch qualifiziert (Pharmazeuten,
Chemiker).
- spezifische Schulungen
Vor der Benutzung des Systems erfolgt grundsätzlich eine intensive Schulung der
Anwender.
·
Motivation
Da die Anwender häufig sehr große Mengen an Daten zu erfassen haben, ist die
Motivation zum einen dadurch geprägt, dass sie die Aufgabe, die vor ihnen liegt,
möglichst schnell und effektiv bewältigen wollen.
Zum anderen ist es aber auch sehr wichtig, dass alle Daten korrekt erfasst werden.
Falsch erfasste Daten könnten dazu führen, dass ein Patient ein falsches Medikament
bekommt. Dies führt dazu, dass die Anwender der CTM-EDB sehr stark auf Sicherheit
bedacht sind und erfasste Daten intensiv kontrolliert werden. Ein übersichtliches
Bedienkonzept kann hierbei die Anwender entlasten.
·
Computervertrautheit
Anwender der CTM-EDB benutzen auch andere Software, wie Textverarbeitungs- oder
Tabellenkalkulationsprogramme. Es kann also davon ausgegangen werden, dass sie mit
dem Computer vertraut sind und gängige Dialogkonzepte kennen.
·
Vertrautheit mit dem Problem bzw. dem Anwendungsgebiet
Die Anwender kennen die Aufgabenstellung, sowie den Sinn und Zweck dieser. Ein
zukünftiges Bedienkonzept, muss daher nicht soweit gehen, dass es dem Anwender die
Problemstellung vermittelt.
·
Intensität der Anwendung
Die Häufigkeit der Nutzung der CTM-EDB ist von Anwender zu Anwender sehr
verschieden. Es gibt sowohl den “Power-User”, der das System mehrere Stunden am
Tag bedient, als auch Anwender, die nur selten mit dem System in Berührung kommen.
Eine neue Benutzerschnittstelle, sollte daher verschiedene Modi, wie beispielsweise ein
Wizard-Konzept sowie einen Expertendialog, bereitstellen.
·
Kulturkreis
Das Verwalten klinischer Studien wird fast ausschließlich in den Hauptniederlassungen
der verschiedenen Pharma-Unternehmen durchgeführt. Diese befinden sich in den
wirtschaftlich höher entwickelten Regionen der Erde, also:
- Nordamerika
- Westeuropa
-
4.2.4
60
Süd-Ost-Asien
Australien
Aufgabenanalyse
Parallel zur Benutzeranalyse kann die Aufgabenanalyse erfolgen. Hier ist zunächst zu
analysieren welche Arten von Tätigkeiten mit einem System durchzuführen sind. Wie schon
beschrieben, können diese mittels verschiedener Diagramme dargestellt und beschrieben
werden. Der Task Tree in Abbildung 4.8 gibt zunächst einen Überblick über die
Hauptaufgaben die mit der Engineering Database von CTM durchgeführt werden.
Clinical Trial Management
Management der Masterdaten
Versionskontrolle
Management von Herstellungs- und
Verpackungsanweisungen
Management von Studiendaten
Management von Aufträgen
Abbildung 4.8: Task Tree - Hauptaufgaben von CTM
Der Fokus dieser Arbeit ist auf das Management von Studiendaten gerichtet. Der Anwender
hat hier mit sehr komplexen Datenstrukturen und Abhängigkeiten verschiedener Objekte zu
tun, was eine Herausforderung an ein modernes Bedienkonzept darstellt. Im folgenden wird
deshalb speziell diese Aufgabenstellung genauer betrachtet. Abbildung 4.9 zeigt einen
weiteren Task Tree der die Aufgabe “Management von Studiendaten” weiter unterteilt.
Management von Studiendaten
61
Management von Projekten
Management von Studien
Management von
Medikationsköpfen
Management von
Intervallköpfen
Management von
Randomisierungen
Management von Patienten
Abbildung 4.9: Task Tree - Management von Studiendaten
Zusätzlich zu den einzelnen Aufgaben sind in Abbildung 4.9 auch die Objekte bereits zu
erkennen, die in den Arbeitsprozessen erzeugt oder manipuliert werden. Dies sind im
einzelnen:
·
·
·
·
·
·
Projekt
Studie
Medikationskopf
Intervallkopf
Randomisierung
Patient
Zur Erläuterung ist hier zu erwähnen, dass mit dem Begriff „Studiendaten“ eine komplette
Studie mit den in Beziehung stehenden Objekten Medikationskopf, Intervallkopf und
Randomisierung gemeint ist, während der Begriff „Studie“ sozusagen für einen Datensatz
steht, der über das entsprechende Dialogfenster gepflegt werden kann.
Je nachdem ob es sich zwischen den Objekten um 1-1 oder 1-n Beziehungen handelt, wird
dies im gegenwärtigen System im Dialogfenster eines Objektes entweder durch ein Textfeld
mit Fremdschlüssel (1-1) oder durch einen Pushbutton, der zu einer Auswahlliste führt (1-n),
dargestellt. Welche Beziehungen zwischen den einzelnen Objekten bestehen zeigt das
Datenbankdiagramm in Abbildung 4.10. Besonders die im gegenwärtigen System in einem
Dialogfenster zu sehenden Fremdschlüssel sind oft sehr aussagelos und fördern keineswegs
die Übersichtlichkeit.
62
Projekt
(0,1)
(0,n)
(1,1)
Studie
(1,1)
(1,1)
(0,n)
(0,n)
Medikationskopf
Intervallkopf
(0,1)
(0,1)
(0,n)
(0,n)
Randomisierung
(0,n)
Abbildung 4.10: Datenbankdiagramm der Studiendaten
Die in Abbildung 4.9 gezeigten einzelnen Unteraufgaben können nun wiederum unterteilt
werden in die Bereiche: Neuanlegen, Editieren und Löschen.
Neuanlegen von Studiendaten
Gerade beim Neuanlegen von einzelnen Objekten trifft man auf das Problem, dass
Abhängigkeiten zwischen den Objekten bestehen. Einfach formuliert können manche
Objekte erst angelegt werden, wenn andere Objekte bereits bestehen. Im Fall des Anlegens
von Studiendaten bedeutet dies, dass zunächst eine Studie erzeugt werden muss, bevor die
Objekte Medikationskopf, Intervallkopf und Randomisierung angelegt werden können.
Solche Abhängigkeiten lassen sich mit dem Task Tree nicht mehr darstellen. Um dies
trotzdem modellieren zu können wird hierzu ein Aktivitätendiagramm verwendet. Abbildung
4.11 zeigt ein solches Diagramm, welches das Anlegen einer Studie mit Medikationskopf,
Intervallkopf sowie Randomisierung darstellt.
63
Studie anlegen
Studie
[defined]
Medikationskopf
anlegen
Medikationskopf
[edit mode]
Intervallkopf
anlegen
Intervallkopf
[edit mode]
Randomisierung
anlegen
Randomisierung
[edit mode]
{AND}
Abbildung 4.11: Aktivitätendiagramm - Anlegen von Studiendaten
Soll nach dem Neuanlegen, der in Abbildung 4.11 gezeigten Objekte die Randomisierung
durchgeführt werden, ist darauf zu achten, dass die Objekte Medikationskopf sowie
Intervallkopf im Status „gültig“ sind. Ist dies nicht der Fall können diese dem Objekt
Randomisierung nicht angefügt werden. Das Objekt Randomisierung benötigt aber jeweils
einen Verweis auf die beiden Objekte da ansonsten die Randomisierungsfunktion, also der
Algorithmus, welcher Patienten den verschiedenen Behandlungsgruppen zuteilt, nicht
ausgeführt werden kann. Wohlgemerkt müssen Patienten zu diesem Zeitpunkt noch nicht
vorhanden sein. Vielmehr werden bei der Durchführung der Randomisierungsfunktion
Datensätze für die Anzahl der geplanten Patienten erzeugt. Diese sind dann durch eine
fortlaufende Nummer repräsentiert und können später durch weitere Daten ergänzt werden.
Das Aktivitätendiagramm in Abbildung 4.12 veranschaulicht diesen Ablauf.
64
Medikationskopf
[edit mode]
Intervallkopf
[edit mode]
Statuswechsel des
Medikationskopfes nach
"gültig"
Medikationskopf
[gültig]
Statuswechsel des
Intervallkopfes nach
"gültig"
{AND}
Anfügen von
Medikations- und
Intervallkopf zur
Randomisierung
Intervallkopf
[gültig]
Randomisierung
[edit mode]
Festlegung des Designs
und Definition der
Medikations Matrix
Durchführen der
Randomisierung
Studie
[randomisiert]
Patienten
Abbildung 4.12: Aktivitätendiagramm - Durchführen der Randomisierung
Nachdem die Randomisierung durchgeführt wurde, können, aufbauend auf der
dazugehörigen Studie, Fertigungsaufträge zur Herstellung der verschiedenen Medikationen
erteilt werden. Da spätere Prototypen speziell für das Management von Studiendaten
realisiert werden, wird dieser weitere Schritt in dieser Analyse nicht mehr berücksichtigt.
Vielmehr ist hier noch zu erwähnen, dass die Schritte der bisher dargestellten
Vorgehensweise zum Anlegen einer Studie wiederum unterteilbar sind. Beispielsweise
besteht der Vorgang des Anlegens eines Medikationskopfes aus den Schritten: Erzeugen
der Medikationskopfdaten, Hinzufügen der Medikationen sowie dem Hinzufügen von
65
Medikationskennungen1 zu den Medikationen. Des weiteren besteht beispielsweise das
Hinzufügen einer Medikation zu einem Medikationskopf aus den Schritten: Auswahl einer
eventuell übergeordneten Medikation, Angeben verschiedener Daten sowie der Auswahl
eines Artikels aus dem Artikelstamm der Engineering Database. Ebenso wäre der Schritt
„Hinzufügen von Medikationskennungen zu einer Medikation“ unterteilbar. Abbildung 4.13
zeigt diese weitere Verschachtelung anhand eines Task Trees.
Anlegen eines
Medikationskopfes
Erzeugen des
Medikationskopfes
Hinzufügen von Medikationen
Hinzufügen von
Medikationskennungen zu
den Medikationen
eventuelle Auswahl einer
übergeordneten Medikation
Angabe der Medikationsdaten
Auswahl eines Artikels aus
dem Artikelstamm
Abbildung 4.13: Task Tree - Anlegen eines Medikationskopfes
Abbildung 4.13 soll hier nur beispielhaft zeigen wie die verschiedenen Arbeitsprozesse
untergliedert werden können. Natürlich sind die meisten anderen dargestellten Aufgaben
auch weiter aufteilbar. Dies alles darzustellen und zu erläutern würde den Rahmen hier aber
sprengen. Zudem reicht dies auch aus um eine der Problematiken des Verwaltens von
Studiendaten zu veranschaulichen. Diese Problematik besteht darin, dass die große Menge
an Aufgaben und ihrer Teilschritte beim Anlegen einer Studie sehr schnell zum Verlust des
Überblicks beim Anwender führt. Dadurch, dass fast jeder Teilschritt ein eigenes
Dialogfenster besitzt, sieht sich der Benutzer zudem schnell mit sehr vielen übereinander
liegenden Dialogfenstern konfrontiert, was den Überblick zusätzlich einschränkt. In
Abbildung 4.14 ist eine solche Gegebenheit zu sehen.
1
Beschriftung der Medikation. Einer Medikation können mehrere Medikationskennungen in
verschiedenen Sprachen zugeordnet sein.
66
Abbildung 4.14: Snapshot - Unübersichtlichkeit des bestehenden Systems
Die Aufgabenstellung des Anlegens von Studiendaten fordert vom Benutzer den geistigen
Überblick zu haben, und zu wissen welche Schritte bereits getätigt wurden, welchen Status
die bereits bestehenden Objekte haben und welche Objekte miteinander in Bezug stehen.
Dieser Überblick wird bisher seitens des Systems nicht gefördert.
Anforderungen an ein neues Bedienkonzept
In Bezug zum Neuanlegen von Studiendaten, sollte ein neues Bedienkonzept den Benutzer
bei der Durchführung der einzelnen Aufgaben und Unteraufgaben unterstützen und ihn durch
die Aufgabenfolge führen. Zudem sollte die Übersicht über die einzelnen in Beziehung
stehenden Objekte gefördert werden. Da das Neuanlegen von Studiendaten häufig in
Teilschritten erfolgt, sollte eine zukünftige Benutzerschnittstelle zudem durch eine klare
Darstellung schnellen Aufschluss darüber geben welche Objekte bereits bestehen und wie
deren Status ist.
Editieren von Studiendaten
Mit dem Begriff des Editierens ist im Zusammenhang mit dem Verwalten von Studiendaten
sowohl das Verändern von bestehenden Objekten aber auch das Hinzufügen verschiedener
Objekte zu einer gegebenen Objektstruktur sowie das Entfernen solcher Objekte gemeint.
Beispielsweise kann das Erstellen und Anfügen eines Medikationskopfes zu einer
bestehenden Studie grundsätzlich auch als Editieren bezeichnet werden. In diesem Fall
überschneiden sich die Begriffe Neuanlegen und Editieren. Sind die Aufgabenstellungen des
Neuanlegens und des Editierens in einem zukünftigen Bedienkonzept aber getrennt
voneinander realisiert, ist eine solche Überschneidung durchaus sinnvoll, bietet sie dem
Anwender doch die Wahl zwischen verschiedenen Wegen zum gleichen Ziel. Gerade bei
einer heterogenen Benutzerstruktur ist eine solche Wahlmöglichkeit wünschenswert.
Die einzelnen Objekte der Studiendaten können verändert werden, solange sie nicht den
Status „gültig“ erreicht haben. Ähnlich wie beim Neuanlegen, muss sich hier der Benutzer
67
zunächst einen Überblick darüber verschaffen welche Objekte zueinander in Beziehung
stehen. Will er beispielsweise die in einer Studie verwendeten Medikationen editieren geht er
meist den Weg über die entsprechende Studie zum Medikationskopf und dann zu den
gewünschten Medikationen. Alleine bei diesem Vorgang hat er bereits fünf Dialogfenster
geöffnet, die sich überdecken. Der Überblick geht hier, wie beim Neuanlegen, natürlich sehr
schnell verloren. Grundsätzlich sind die Probleme beim Editieren von Daten mit dem
gegenwärtigen System die gleichen wie beim Neuanlegen.
Der Benutzer sollte nicht wie beim gegenwärtigen System zunächst damit beschäftigt sein
sich einen geistigen Überblick über bestehende Beziehungen von Objekten und deren
Zustände verschaffen zu müssen. Ähnlich wie beim Editieren sollte eine klare Darstellung die
Übersicht fördern. Es sollte vermieden werden, dass sich Dialogfenster überlappen.
Löschen von Studiendaten
Das Löschen einzelner Objekte sollte im Rahmen des Editierens möglich sein. Die
Problematik ist hierbei, gleich wie bei den beiden vorangegangenen Aufgabenstellungen, die
Objektstrukturen zu überschauen und hieraus das gewünschte zu löschende Objekt
auszuwählen.
Diese Anforderungen werden von den Anforderungen beim Editieren abgedeckt.
Designziele
Da beim Neuanlegen zusätzlich zum Problem der Übersicht über die Objektbeziehungen
noch die Problematik des komplexen Aufgabenablaufes kommt, ist ein Ziel des Designs
einen eigenen Modus für das Neuanlegen von Studiendaten zu schaffen, in dem der
Benutzer durch die einzelnen Aufgaben geführt wird.
In einem zusätzlichen Editiermodus sollte durch entsprechende Darstellung vor allem die
Übersicht gefördert werden. In einem zukünftigen System sollte der Benutzer sofort in der
Lage sein, zu überblicken welche Objekte bestehen, welchen Status sie haben und in
welcher Beziehung sie zueinander stehen. Dialogfenster sollten sich in einem zukünftigen
Bedienkonzept keinesfalls mehr überlappen. Zudem sollten Objekte nicht nur in
Auswahllisten und Dialogfenstern zugänglich sein. Eine Darstellung dieser in Form von Icons
oder Metaphern, die zusätzlich über ein Kontextmenü direkt manipulierbar sind, wäre ein
weiterer Schritt in Richtung Benutzerfreundlichkeit.
Auf eine Veränderung oder Verbesserung der Aufgabenstruktur wird in dieser Ausarbeitung
nicht eingegangen, da dies auch eine Veränderung der Funktionalität der CTM-Lösungen mit
sich bringen würde. Da sich diese Arbeit auf die Gestaltung eines neuen Bedienkonzeptes
richtet, würde dies zu weit führen.
5 Design und Implementierung
This can’t be hard, it’s just common sense.
Nachdem die Benutzer und die Aufgabenstellungen analysiert wurden, liegt es nun daran
aus diesen Ergebnissen zu einem Entwurf eines neuen Bedienkonzeptes zu gelangen. In der
Phase des konzeptionellen Designs werden zunächst grundlegende Entscheidungen für die
Gestaltung der Benutzerschnittstelle getroffen, die dann im visuellen Design konkrete Form
annehmen.
5.1 Die Lücke zwischen Analyse und Design
An dieser Stelle zeigt sich, dass der Übergang von der Analyse-Phase in die Design-Phase,
der schwierigste Schritt des Usability Engineerings ist. Resultate der Analyse sind eine
detaillierte Beschreibung der Problematik der Aufgabenstellung sowie die Definition der
Design-Ziele, die realisiert werden sollen. Diese Ziele sind nun in einem konkreten Entwurf
umzusetzen. Da bei diesem Übergang auch ein gewisser Grad an Kreativität gefordert ist
kann hier nicht nach einer festgelegten Methodik vorgegangen werden. Diese Lücke ist
gekennzeichnet durch Fragen wie:
·
·
·
·
·
Wie sehen die hauptsächlichen Bildschirminhalte aus?
Welche Daten sollten dargestellt werden und welche sind eher Attribute?
Welche Interaktionsmuster sind sinnvoll?
Wie sollte der Benutzer durch die Dialogstruktur navigieren?
Auf welche Weise sind Funktionen zugänglich?
Zusätzlich zu den Analyseergebnissen können technische Vorgaben sowie Vorstellungen
von Kunden den Design-Prozess noch erschweren. Solche Schwierigkeiten können aber
auch genutzt werden um neue Techniken für eine optimale Lösung zu entwickeln. [Welie01]
5.2 Konzeptuelles Design
Aufgrund der teilweise unterschiedlichen Problematiken bezüglich des Neuanlegens und
Editierens von Studiendaten sollte für diese beiden Aufgabenstellungen, wie im Kapitel
Analyse schon erwähnt, jeweils ein eigener Bedienmodus realisiert werden. Der Prozess des
Neuanlegens von Studiendaten, sollte aufgrund der komplexen Aufgabenstellung durch ein
Wizard-Konzept unterstützt werden. Für das Editieren ist ein Dialog zu schaffen, der vor
allem durch Übersichtlichkeit geprägt ist.
Design und Implementierung
5.2.1
69
Wizard-Konzept für das Anlegen von Studiendaten
Im Modus für das Neuanlegen von Studiendaten, soll der Benutzer die Möglichkeit haben mit
Hilfe der Funktionen „zurück“ und „weiter“ durch die Aufgaben navigieren zu können. Da
außer der Problematik der komplexen Aufgabenstellung beim Anlegen von Studiendaten
auch die Notwendigkeit besteht zu bereits angelegten Daten zurückzukehren und diese zu
berichtigen, sollte dieser Wizard zusätzlich eine Übersicht über bereits angelegte Daten
bieten. In dieser Übersicht sollte der Benutzer navigieren können und bereits ausgeführte
Aufgaben nochmals durchlaufen können. Da die Anzahl der Aufgaben und Unteraufgaben
beim Anlegen von Studiendaten weit größer ist als zehn, sollte der Wizard eine Unterteilung
besitzen. Aufgrund der Tatsache, dass im Prozess verschiedene Objekte nacheinander
bearbeitet werden, sollte es möglich sein nach der Fertigstellung eines Objektes die Daten
abzuspeichern und den Dialog zu beenden.
5.2.2
Modus für das Editieren von Studiendaten
Da der Dialog für das Editieren vor allem durch Übersichtlichkeit geprägt sein sollte, lag es
hier daran eine geeignete Darstellung zu finden um diese Übersichtlichkeit zu gewährleisten.
Ein neues Konzept sollte vor allem ausschließen, dass mehrere Fenster geöffnet werden
können und diese sich überlappen. Da Benutzer häufig aufgrund der komplexen
Beziehungen der Objekte im gegenwärtigen System die Übersicht verlieren, war es zudem
das Ziel, diese Beziehungen zu visualisieren. Hier wurden zunächst zwei Konzepte
angedacht.
1. Konzept
Die Idee war hierbei zunächst das Hauptfenster der CTM-EDB beim Start nicht leer
erscheinen zu lassen, sondern die verschiedenen Objekttypen in einer Baumdarstellung auf
der linken Seite des Fensters anzuzeigen.
Beschreibung der Funktionalität
Bei der Auswahl eines Objekttyps aus der Baumdarstellung soll eine Liste aller Datensätze
dieses Typs angezeigt werden. Abbildung 5.1 zeigt einen Papierentwurf dieses
Eingangsdialoges. In der Liste soll es möglich sein die Daten zu sortieren, Spalten zu
vertauschen und per direkter Manipulation eines Spaltenkopfes Selektionen durchzuführen.
70
Abbildung 5.1: Papierentwurf - Eingangsdialog
Nachdem ein Datensatz ausgewählt und die Funktion „edit“ aufgerufen wurde, soll der
Editier-Modus angezeigt werden. Ausgehend vom Editieren einer Studie werden in diesem
Modus neben den Daten einer Studie auch die wichtigsten Daten der in Beziehung
stehenden Objekte angezeigt. Abbildung 5.2 zeigt einen Papierentwurf, der hier zunächst
einen ersten Eindruck vermittelt.
Abbildung 5.2: Papierentwurf - 1. Editierkonzept
Um Platz zu schaffen sind die Daten der Studie hier auf mehrere Reiterkarten aufgeteilt. Dies
ermöglicht es die wesentlichen Daten der in Beziehung stehenden Objekte rechts daneben
anzuzeigen. Die Bedienflächen für diese zusätzlichen Daten können zudem geöffnet und
geschlossen werden, was zur Übersicht beiträgt. Da diese Bedienflächen alle ihre
festgelegte Stelle haben kann es nicht passieren, dass sie sich überlappen.
Die Schaltflächen für weitere Daten einer Studie sind durch dieses Konzept nicht mehr
notwendig. Schaltflächen für Funktionen sind nun getrennt von den Studiendaten in der
Toolbar untergebracht.
71
2. Konzept
Auch hier soll wie im ersten Konzept der Eingangsdialog die verschiedenen Objekttypen in
einer Baumdarstellung zeigen. Darauf folgend werden die Beziehungen der einzelnen
Objekte aber durch einen Graph auf der linken Seite des Dialoges dargestellt. Abbildung 5.3
zeigt einen Papierentwurf für eine solche Benutzerschnittstelle.
Abbildung 5.3: Papierentwurf - 2. Editierkonzept
Die Knoten des Übersichts-Graph repräsentieren die verschiedenen Objekte der CTM-EDB.
Idee ist, dass immer ein zentrales Objekt vorhanden ist, welches sich farblich von allen
anderen Objekten unterscheidet, und von dem aus gesehen alle anderen in Beziehung
stehenden Objekte angezeigt werden. Da zu verschiedenen Objekttypen entweder 1:1- oder
1:n-Beziehungen bestehen, also Verweise auf genau ein Objekt aber auch auf eine Menge
von Objekten möglich sind, sollte dies durch eine entsprechende Gestaltung der Knoten
unterscheidbar sein. Ein Mausklick auf einen Knoten führt dazu, dass dessen Daten
angezeigt werden, und dass ein eventuell zuvor vorhandenes Fenster geschlossen wird.
Zudem sollten Knoten, die ein einzelnes Objekt repräsentieren, mit einer textuellen
Bezeichnung für dieses Objekt versehen sein.
Des weiteren sollte der Benutzer das zentrale Objekt des Graphen wechseln und somit
durch die Datenstruktur navigieren können. Folgendes Beispiel verdeutlicht dies:
Ist zentrales Objekt ein Medikationskopf, so sind um diesen die Objekte Studie,
Randomisierungen und Medikationen in Form von Knoten angeordnet. Will der Benutzer die
Beziehungen der entsprechenden Studie einsehen, so kann er per Doppelklick auf den
Knoten „Study“ den Graphen derart verändern, dass die Studie zum zentralen Objekt wird.
Um diese sind dann die Objekte Projekt, Studienaufträge, Medikations- und Intervallköpfe
sowie die Randomisierungen angeordnet. Umgekehrt, ausgehend von der Studie, wird bei
Klick auf den Knoten „Medication headers“ ein Dialogfenster mit einer Auswahlliste
angezeigt. Wählt der Benutzer hier einen Medikationskopf aus verändert sich der Graph
wieder derart, dass der entsprechende Medikationskopf zum zentralen Objekt wird.
72
Zudem sollen die Objekte, repräsentiert durch Knoten, direkt manipulierbar sein. Hierzu
sollte per Klick auf die rechte Maustaste ein Kontextmenü erscheinen, dass das Anzeigen
verschiedener Dialogfenster, aber auch den Aufruf von Funktionen ermöglicht. Hierdurch
können zusätzliche Buttons, die bisher manches Dialogfenster überfüllten, vermieden
werden. Die Menüpunkte eines solchen Kontextmenüs sind zusätzlich über einen Eintrag im
Hauptmenü zugänglich. Dieses passt sich bei Veränderung des Graphen automatisch an.
5.3 Visuelles Design – Implementierung von Prototypen
Nachdem ein Entwurf verschiedener Konzepte gemacht wurde, liegt es daran diese
verschiedenen Konzepte zu konkretisieren, um die Funktionalität realistischer darzustellen.
Der Entwurf für ein Wizard-Konzept sowie das zweite Konzept (Übersichtsgraph) für den
Editiermodus wurden hierbei berücksichtigt. Diese Prototypen werden mit Java-Swing
implementiert, wobei hier der Fokus auf die Funktionalität der Oberfläche gerichtet war und
eine tiefere Anwendungsfunktionalität nicht berücksichtigt wurde. Die Vorgehensweise
entsprach also dem horizontalen Prototyping.
5.3.1
Java Swing
Bei der Auswahl einer geeigneten Programmiersprache für die Implementierung der
Prototypen fiel die Entscheidung auf die grafische Klassenbibliothek Java-Swing.
Die Programmiersprache Java wurde 1998 um die Swing-Klassen, auch bekannt als Java
Foundation Classes (JFC), ergänzt, da die grafische Klassenbibliothek AWT (Abstract
Windowing Toolkit) den gewachsenen Anforderungen an Benutzerschnittstellen nicht mehr
gerecht werden konnte. Swing dagegen bietet alle wichtigen Komponenten um moderne
Dialoge zu erstellen. Zudem gewährleistet Swing Plattformunabhängigkeit derart, dass die
verschiedenen Komponenten auf jedem System gleich dargestellt werden können.
Außer den genannten Vorteilen war ein weiterer Grund Swing zu verwenden, die Aussicht,
dass zukünftige Front-Ends des PMX-Systems aber auch Teile der Anwendungslogik mit
Java realisiert werden sollen. Des weiteren bietet das Java 2D API, über Swing
hinausgehend, Möglichkeiten um Dialoge aber auch eigene Dialogkomponenten grafisch zu
gestalten.
[Schlie99]
Ein weiterer großer Vorteil von Java-Swing ist seine Architektur nach dem MVC-Paradigma.
Da später eine Dialogkomponente neu geschaffen wird, die auf diesem Prinzip aufbaut, wird
das MVC-Paradigma hier kurz erläutert.
MVC – Model, View, Controller
Bei dieser Architektur stehen drei Kommunikationsobjekte miteinander in Verbindung: das
Model, die View und der Controller. Das Model repräsentiert die Daten. Der View stellt die
Information visuell dar, und der Controller übernimmt die Verarbeitung der
Benutzereingaben. Durch diese Dreiteilung ist ein Höchstmaß an Flexibilität gewährleistet.
Da alle Objekte untereinander in Beziehung stehen, werden bei einer Änderung des Models
die mit ihr verbundenen Objekte benachrichtigt. Abbildung 5.4 zeigt das MVC-Konzept in der
Theorie.
73
View
Controller
Model
Abbildung 5.4: MVC-Konzept in der Theorie [Schlie99]
Die Teilung der Datenhaltung und deren Präsentation bringt 2 wesentliche Vorteile:
·
·
Ein Datenmodell kann in mehreren Views auf die verschiedenste Art und Weise
dargestellt werden. Zum Beispiel können Daten dadurch sowohl in Tabellenform als
auch in einer Balkengrafik visualisiert werden.
Es ist möglich eine Ansicht zu ändern, ohne dabei die Datenhaltung zu beeinträchtigen.
Ein View kann beliebig verändert werden, und das darunterliegende Datenmodell bleibt
davon unbeeinträchtigt.
Des weiteren benutzt eine View einen Controller, um auf die Benutzereingaben zu reagieren.
[Schlie99]
Swing und MVC
Die Verwendung dieses Konzeptes ist in Swing etwas anders als in der Theorie vorgegeben.
In Swing wird der Controller und die View in einem Objekt verbunden. Diese Verbindung wird
Delegate genannt und stellt sowohl das Datenmodell dar, wie es ein View machen würde,
und verarbeitet die Benutzereingaben wie ein Controller. Durch diese Kombination der
beiden Objekte vereinfacht sich das Design der einzelnen Komponenten wesentlich.
Abbildung 5.5 verdeutlicht dieses Prinzip von Swing.
74
View
Controller
delegate
Model
Abbildung 5.5: MVC-Konzept von Java-Swing [Schlie99]
5.3.2
Implementierung eines Editier-Konzeptes
Da die Umsetzung eines Editier-Konzeptes die größte Herausforderung darstellte, wurde
zunächst hierfür ein Prototyp realisiert. Die Entscheidung fiel dabei auf das in Kapitel 5.2.2
vorgestellte 2. Konzept für einen Editier-Modus. Im Eingangsdialog werden hierbei die
verschiedenen Objekttypen (Studien, Randomisierungen, usw.) in einer Baumstruktur
dargestellt. Die Auswahl eines bestimmten Typs führt zur Anzeige seiner Instanzen in einer
Liste. Wird in dieser Liste ein Datensatz selektiert und die Funktion „Edit“ aufgerufen führt
dies zum eigentlichen Editier-Modus.
Übersichtsgraph
Das Konzept zeichnet sich vor allem dadurch aus, dass die Beziehungen von Objekten in
einem Graphen auf der linken Seite des Dialoges dargestellt werden und anhand dieses
Graphen durch die Datenstruktur navigiert werden kann. Ein Objekt entspricht einem Knoten.
Die Daten der verschiedenen Objekte werden in Datenmasken rechts neben dem Graph
angezeigt. Um dies zu Veranschaulichen zeigt Abbildung 5.6 hierzu einen Snapshot des
bereits realisierten Konzeptes.
75
Abbildung 5.6: Übersichtsgraph
Eine genaue Beschreibung der Funktionalität erfolgte bereits in Kapitel 5.2.2. Zusätzlich zu
dem dort genannten wurden im Verlauf der Implementierung weitere Eigenschaften des
Übersichtsgraph eingeführt:
1. Ist ein Knoten mit einem Kontextmenü versehen, so soll dies durch ein Maussymbol, bei
dem die rechte Maustaste hervorgehoben ist dargestellt werden.
2. Der Status eines Objektes soll in seinem entsprechenden Knoten ersichtlich sein. Hierfür
wurde ein Ampelsymbol gewählt. Diese Ampel stellt die folgenden drei Zustände dar:
·
kleiner gültig (beispielsweise: edit, verification), mit der Farbe gelb:
·
gültig (valid), mit der Farbe grün:
·
größer gültig (beispielsweise: obsolete, archived), mit der Farbe rot:
Da diese Farben an verschiedenen Stellen in der Ampel angezeigt werden, ist es auch
einem Farbenblinden möglich, den Status eines Objektes anhand von diesem Symbol zu
erkennen.
Der Umfang des Prototypen beschränkt sich auf die Objekte: Studie, Medikationskopf,
Intervallkopf sowie Randomisierung. Zusätzlich können die dem Medikationskopf sowie
Intervallkopf untergeordneten Objekte bearbeitet werden. Auf eine Datenbankanbindung wird
verzichtet. Die Daten der verschiedenen Objekte werden statt dessen in Instanzen der
Klasse Vector zusammengefasst. Um Persistenz zu gewährleisten, werden diese Vektoren
beim Beenden der Applikation abgespeichert und beim Start wieder neu eingelesen.
Funktionen wie „Randomisieren“ oder „Statuswechsel“ werden in den entsprechenden
Menüs angedeutet, Funktionalität steckt hier aber nicht dahinter.
76
Architektur-Konzept
Zunächst werden die Hauptbestandteile (Klassen) der Implementierung und deren
Funktionalität näher erläutert. Anhand von Klassendiagrammen wird ihr Aufbau dargestellt.
Die Sichten, die von bestimmten Klassen realisiert sind, werden zudem in Form von
Snapshots gezeigt. Dies soll zum Verständnis des Konzeptes beitragen.
Datenquelle - <<Datasource>>
Die einzelnen Objekttypen wie Studie oder Randomisierung sind in Form von Klassen
realisiert. Instanzen hiervon werden in Objekten zusammengefasst deren Klassen von der
Klasse Vector erben. Beispielsweise enthält die Instanz der Klasse Studies alle Instanzen
der Klasse Study. Die Klasse Studies implementiert zudem das Interface Serializable, um
das Speichern dieser Daten zu ermöglichen. Die Klasse Datasource enthält wiederum die
Sammlungen der verschiedenen Objekte. Abbildung 5.7 zeigt hierzu das Klassendiagramm.
Dieses enthält nur einen kleinen Teil der verschiedenen Klassen, da alle Klassen hier nicht
darstellbar sind und dies zur Veranschaulichung ausreicht.
Datasource
interv alHeaders : Interv alHeaders
interv alIDs : Interv alIDs
interv als : Interv als
items : Items
languageIDs : LanguageIDs
medHeaders : MedHeaders
medicationIDs : MedicationIDs
medications : Medications
randomizations : Randomizations
studies : Studies
getInterv alHeaders()
getInterv alIDs()
getInterv als()
getItems()
getLanguageIDs()
getMedHeaders()
getMedicationIDs()
getMedications()
getRandomizations()
getStudies()
readInterv alHeaders()
readMedHeaders()
readStudies()
sav eInterv alHeaders()
sav eMedHeaders()
sav eStudies()
readRandomizations()
sav eRandomizations()
Vector
<<interf ace>>
Serializable
Studies
getNumberOf Cols()
getColumnNames()
getStudy ()
Study
project : String
study : String
description : String
status : String
plannedStart : Date
plannedEnd : Date
actualStart : Date
usw....
getListElements()
Abbildung 5.7: Klassendiagramm - Datasource
Die Implementierung aller anderen Objekte erfolgt nach demselben Prinzip.
<<JApplicationFrame>>
Die Klasse JApplicationFrame enthält die main-Methode und erzeugt das
Hauptdialogfenster, stellt aber selbst keine Daten dar. Diese Klasse hat als einzige eine
Beziehung zur Datenquelle. Der JApplicationFrame erzeugt und steuert die verschiedenen
Sichten. Diese sind in Form von JPanels realisiert. Zudem erhalten die Sichten über den
JApplicationFrame ihre Daten. Abbildung 5.8 zeigt die Klassen JApplicationFrame und
Datasource, sowie ihre Beziehung.
77
JFrame
JApplicationFrame
datasource : Datasource
explorer : Explorer
jActualPanel : JGraphPanel
jStudy Graph : JStudy GraphPanel
jRandomGraph : JRandomGraphPanel
jMedicationGraph : JMedicationGraphPanel
jInterv alGraph : JInterv alGraphPanel
jStandardToolbar : JToolbar
jNav igationToolbar : JToolbar
jMenuBar : JMenuBar
tableModel : TableModel
addInterv alHeaderGraph()
addInterv alHeadersTable()
addMedHeadersTable()
addMedicationHeaderGraph()
addRandomizationGraph()
addStudy Graph()
addStudy Table()
getInterv al()
getInterv alID()
getInterv alIDList()
getInterv alList()
getIntHeaderListData()
getIntHeaderListForStudy ()
getItemList()
getLangList()
getLanguageID()
getMedHeaderListData()
getMedHeaderListForStudy ()
getMedication()
getMedicationIDList()
getMedicationList()
getRandomization()
getRandomListData()
getRandomListForIntHeader()
getRandomListForMedHeader()
Datasource
interv alHeaders : Interv alHeaders
interv alIDs : Interv alIDs
interv als : Interv als
items : Items
languageIDs : LanguageIDs
medHeaders : MedHeaders
medicationIDs : MedicationIDs
randomizations : Randomizations
studies : Studies
getInterv alHeaders()
getInterv alIDs()
getInterv als()
getItems()
getLanguageIDs()
getMedHeaders()
getMedicationIDs()
getMedications()
getRandomizations()
getStudies()
readInterv alHeaders()
readMedHeaders()
readStudies()
sav eInterv alHeaders()
sav eMedHeaders()
sav eStudies()
Abbildung 5.8: Klassendiagramm - JApplicationFrame
Sichten
<<Explorer>>
Das Eingangsbild mit der Baumdarstellung der verschiedenen Objekttypen sowie der
entsprechenden Liste der Datensätze wird von der Klasse Explorer realisiert. Abbildung 5.9
zeigt einen Snapshot dieser Sicht.
78
Abbildung 5.9: Eingangsdialog des neuen Konzeptes
Eine Instanz dieser Klasse wird beim Start des Prototypen zunächst vom JApplicationFrame
erzeugt. Zwischen dem Explorer und dem JApplicationFrame besteht eine bidirektionale
Beziehung. Sofern ein Datensatz (z.B. eine Studie) im Explorer ausgewählt ist, führt der
Aufruf der Funktion „edit“ (in der Toolbar des JApplicationFrame) zur Darstellung der
entsprechenden Editier-Sicht. Um die geforderte Sicht darstellen zu können erhält der
JApplicationFrame ein CtmSelection-Objekt mit Informationen über den zuvor selektierten
Datensatz. Abbildung 5.10 zeigt diese Beziehung.
Des weiteren enthält die Klasse Explorer eine Instanz der Klasse CtmTableModel. Diese
Klasse ist von der abstrakten Klasse AbstractTableModel abgeleitet und hält die Daten der
aktuell angezeigten Liste.
79
AbstractTableModel {abstract}
JApplicationFrame
CtmTableModel
cols : int
columnNames : String[]
rows : int
tableData : Object[][]
getColumnCount()
getColumnName()
getRowCount()
getValueAt()
isCellEditable()
setValueAt()
JFrame
JSplitPane
Explorer
ctmTableModel : CtmTableModel
jApplicationFrame : JApplicationFrame
masterdataTable : JTable
masterdataTree : JTree
selection : CtmSelection
sorter : TableSorter
getSelection()
getTableModel()
setTableData()
setTreeData()
CtmSelection
objectKind : String
object : String
selectedRow : int
explorer : Explorer
jInterv alGraph : JInterv alGraphPanel
jMenuBar : JMenuBar
addStudy Graph()
addStudy Table()
getInterv al()
getInterv alID()
getInterv alList()
getItemList()
getLangList()
getLanguageID()
getMedication()
getMedicationList()
getRandomization()
getRandomListData()
Abbildung 5.10: Klassendiagramm - Explorer
Aufgrund des Objektes CtmSelection, wird in JApplicationFrame entschieden welche Sicht
dargestellt wird. Folgendes Codebeispiel aus der Klasse JApplicationFrame zeigt dies:
jEditButton.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {
//get selected dataset and type from explorer
ctmSelection = explorer.getSelection();
tableModel = explorer.getTableModel();
//if the type of selection was a study and if a dataset was
//selected, show view to edit study
if (ctmSelection.objectKind == "Studies"){
if(ctmSelection.object != null){
getContentPane().remove(jStandardToolbar);
getContentPane().add(jNavigationToolbar,
java.awt.BorderLayout.NORTH);
addStudyGraph(ctmSelection.object);
}
}
80
//if the type of selection was a medication header and if a dataset
//was selected, show view to edit medication header
else if (ctmSelection.objectKind == "medHeaders"){
addMedicationHeaderGraph(ctmSelection.object);
}
}
//if the type of selection was a interval header and if a dataset
//was selected, show view to edit interval header
else if (ctmSelection.objectKind == "intHeaders"){
addIntervalHeaderGraph(ctmSelection.object);
}
}
//if the type of selection was a randomization and if a dataset was
//selected, show view to edit randomization
else if (ctmSelection.objectKind == "randomizations"){
addRandomizationGraph(ctmSelection.object);
}
}
}
});
Übersichtsgraph
Nachdem in der Explorer-Sicht ein Objekt ausgewählt und die Funktion „edit“ aufgerufen
wurde, erscheint die Sicht mit dem entsprechenden Übersichtsgraph. In diesem Graph wird
das zuvor selektierte Objekt als zentraler, farblich hervorgehobener Knoten dargestellt.
Zudem werden die Daten dieses Objektes in einer Dialogfläche auf der rechten Seite
angezeigt. Eine Verbindungslinie ordnet dabei die Daten dem jeweiligen Knoten zu. In
Abbildung 5.6 ist der Graph mit einer Studie als zentrales Objekt zu sehen. Diese Sicht wird
von der Klasse JStudyGraphPanel realisiert.
Der Prototyp wurde zum editieren der Objekte: Studie, Medikationskopf, Intervallkopf sowie
Randomisierung entwickelt. Für diese Objekte gibt es jeweils eine Sicht mit dem
entsprechenden Graphen. Diese Sichten sind in den folgenden Klassen realisiert:
·
·
·
·
JStudyGraphPanel
JMedicationGraphPanel
JIntervalGraphPanel
JRandomizationGraphPanel
Da diese Klassen sehr ähnlich aufgebaut sind, wird
JStudyGraphPanel das grundsätzliche Konzept erläutert.
hier
anhand
der
Klasse
In der Methode addStudyGraph() der Klasse JApplicationFrame wird eine Instanz der Klasse
JStudyGraphPanel erzeugt. Diese Methode wird aufgerufen, wenn von einer zuvor
81
angezeigten Sicht zur Studien-Sicht gewechselt wird. Beim Konstruieren des Objektes
JStudyGraphPanel wird eine Referenz, der zuvor selektierten Studie übergeben. Das Objekt
JStudyGraphPanel greift somit direkt auf die Daten der Studie zu. Das folgende Codebeispiel
zeigt die Methode addStudyGraph():
public void addStudyGraph(String selection){
// hide explorer-view if it is visible
explorer.hide();
// delete all additional menus
deleteAddMenus();
// create additional menus
createStudyMenu();
// remove the previous view
remove(jActualPanel);
// create reference to the appropriate study
Study study = datasource.getStudies().getStudy(selection);
// create JStudyGraphPanel
jStudyGraph = new JStudyGraphPanel(study, this);
getContentPane().add(jStudyGraph);
// reference to the actual view, enables deletion afterwards
jActualPanel = jStudyGraph;
validate();
repaint();
}
Realisierung der Datenmasken
Wie die Datenmasken der einzelnen Knoten realisiert sind wird hier am Beispiel der Klasse
JStudyDataPanel erläutert.
Per Klick auf die Knoten des Graph, können die verschiedenen Datenmasken rechts neben
der Graphstruktur angezeigt werden. Gleich wie beim JApplicationFrame verweist die
Variable actualPanel auf die gerade angezeigte Datenmaske. Beim Aufruf eines anderen
Panels wird die gerade aktuelle Datenmaske über diese Referenz gelöscht und das neue
Panel dieser Variablen zugewiesen. Um die Verbindungslinien zwischen Knoten und Panel
richtig positioniert zu zeichnen, ist beim Anzeigen eines Panels der Integerwert
requestedData zu setzen. Dieser wird in der Methode paint() ausgewertet und
dementsprechend die Verbindungslinie gezeichnet. Das folgende Codebeispiel zeigt die
Methode showStudyDataPanel(), in der dies realisiert ist:
public void showStudyDataPanel(){
//set value for paint-Method to draw connection line
requestedData = STUDYDATA;
//remove the previous panel
remove(actualPanel);
//reference new Panel
actualPanel = jStudyDataPanel;
actualPanel.setVisible(true);
validate();
repaint();
}
82
In diesem Code-Beispiel ist ersichtlich, wie zunächst die Variable requestedData auf das neu
anzuzeigende Objekt gesetzt wird. Danach wird das bisher angezeigte Panel gelöscht und
das bereits bestehende JStudyDataPanel der Referenz actualPanel zugewiesen und
visualisiert.
Das Objekt JStudyGraphPanel wird hier nicht neu erzeugt, da es im Konstruktor der Klasse
JStudyGraphPanel bereits angelegt wurde. Der folgende Ausschnitt aus dem Quellcode
zeigt die Instanziierung der Klasse JStudyDataPanel:
jStudyDataPanel = new JStudyDataPanel(studyCopy, this);
add(jStudyDataPanel);
jStudyDataPanel.setVisible(true);
//size and position of jStudyDataPanel
jStudyDataPanel.setBounds(380,20,600,640);
Beim Konstruieren des Objektes JStudyDataPanel werden als Argumente eine Kopie der
Studie sowie die Referenz auf das Objekt JStudyGraphPanel übergeben. Nimmt der
Benutzer Änderungen an der Studie vor und klickt danach Ok so wird hierauf zunächst die
Methode checkData() aufgerufen. Diese überprüft ob alle Einträge in Ordnung sind. Ist dies
der Fall wird darauffolgend die Methode authorization() aufgerufen. Hier wird ein
Dialogfenster zur Autorisierung des Benutzers erzeugt. Fällt dies ebenfalls positiv aus erfolgt
der Aufruf der Methode saveData(), in der wiederum die Methode save() des Eltern-Objektes
JStudyGraphPanel aufgerufen und dieser die veränderte Kopie der Studie übergeben wird.
Hier erfolgt letztendlich die Speicherung der Änderungen in der Datenquelle. Das
Sequenzdiagramm in Abbildung 5.11 veranschaulicht dies.
Die Darstellung aller anderen Datenmasken erfolgt auf dieselbe Weise. Die Klasse
JStudyGraphPanel beispielsweise enthält außer der Methode showStudyDataPanel() auch
die Methoden:
·
·
·
·
showMedHeaderListPanel()
showIntervalHeaderListPanel()
showRandomListPanel()
showLogInfo()
Diese sind für die Darstellung der entsprechenden weiteren Datenmasken zuständig.
Das Objekt JStudyGraphPanel erzeugt alle Datenmasken und Dialogfenster in denen Daten
editiert oder ausgewählt werden können. Diese Datenmasken und Dialogfenster greifen
dabei nie direkt auf die Daten zu sondern erhalten diese von JStudyGraphPanel.
Das Sequenzdiagramm in Abbildung 5.11, soll das Zusammenspiel der einzelnen
Komponenten verdeutlichen. Es zeigt den Ablauf:
-
Anzeigen der Sicht auf eine Studie (Schritt 1 bis 4)
Editieren der Studie (change data)
Speichern der Änderung (Schritt 5 und 9)
Anzeigen der in Beziehung stehenden Medikationsköpfe (Schritt 10 – 12)
Auswahl eines Medikationskopfes (Schritt 13)
Anzeige der Sicht auf einen Medikationskopf (Schritt 14 –16)
JApplicationFrame
83
JStudyGraphPanel
JStudyDataPanel
ListPanel
Datasource
1: getStudy()
2: new JStudyGraphPanel(study)
3: new JStudyDataPanel()
4: setVisible(true)
change
data
5: checkData()
6: authorization()
7: saveData()
8: save()
9: set changes
10: showMedHeaderListPanel()
11: getMedHeaderListForStudy()
12: new ListPanel()
select
dataset
13: ok
14: changeGraph()
15: addMedicationHeaderGraph()
16: remove()
Abbildung 5.11: Sequenzdiagramm - Zusammenspiel der Objekte
Sieht man in dem Objekt JApplicationFrame die Vorgangssteuerung und im Objekt
JStudyGraphPanel die Interaktionssteuerung, so wäre eine Verbesserung des bisherigen
Ablaufes dahingehend vorzunehmen, dass die Interaktionssteuerung grundsätzlich direkt auf
die Datenquelle zugreift und die Vorgangssteuerung nur die Folge der einzelnen Sichten
steuert.
Das Klassendiagramm in Abbildung 5.12 zeigt die Klasse JStudyGraphPanel in Beziehung
zur Klasse JApplicationFrame und zur Datenmaske JStudyDataPanel. Die Klassen der
84
weiteren Editier-Sichten sind angedeutet. Auf Attribute und Eigenschaften wurde bei diesen
aus Übersichtsgründen aber verzichtet.
JFrame
JPanel
JGraphPanel {abstrakt}
announceMenuAction()
changeGraph()
closeLangListFrame()
hidePanel()
JMedicationGraphPanel
JIntervalGraphPanel
JRandomGraphPanel
JStudyGraphPanel
actualPanel : JPanel
study : Study
jApplicationFrame : JApplicationFrame
requestedData : int
requestedData2 : int
INTERVALDATA : f inal int
INTERVALLIST : f inal int
MEDI CATIONDATA : f inal int
MEDI CATIONLIST : f inal int
PROJECTDATA : f inal int
RANDOMIZATIONLI ST : f inal int
STUDY DATA : f inal int
projectNode : JCtmNode
study OrderNode : JCtmNode
study Node : JCtmNode
medHeadNode : JCtmNode
intHeadNode : JCtmNode
randomNode : JCtmNode
jListPanel : JListPanel
jStudy DataPanel : JStudy DataPanel
announceMenuAction()
changeGraph()
closeLangListFrame()
hidePanel()
initPopupMenus()
paint()
showInterv alHeaderListPanel()
showLogInf o()
showMedHeaderListPanel()
showProjectPanel()
showRandomListPanel()
showStudy DataPanel()
JPanel
JDataPanel {abs tract}
sav eData()
JApplicationFrame
explorer : Explorer
jInterv alGraph : JI nterv alGraphPanel
jMenuBar : JMenuBar
addStudy Graph()
addStudy Table()
getInterv al()
getInterv alID()
getInterv alList()
getItemList()
getLangList()
getLanguageID()
getMedication()
getMedicationList()
getRandomization()
getRandomListData()
JStudyDataPanel
study : Study
parent : JGraphPanel
authorization()
checkData()
sav eData()
Abbildung 5.12: Klassendiagramm - Editier-Sichten
Implementierung des Graph
Die Knoten eines Graph sowie die Pfeile, die diese verbinden, sind in der entsprechenden
Sicht (beispielsweise JStudyGraphPanel) an fester Stelle positioniert. Für die Knoten wurde
die Dialogkomponente JCTMNode neu geschaffen, die Pfeile werden von der Komponente
JArrow dargestellt. Im folgenden wird der Aufbau und die Funktionalität der Klasse
85
JCTMNode näher erläutert. Da die Klasse JArrow nur für die Darstellung eines Polygons
zuständig ist, wird auf diese nicht näher eingegangen.
Aufgrund der Tatsache, dass die meisten Dialogkomponenten von Swing auf dem MVCKonzept basieren, wurde dieses Konzept bei der Implementierung der neuen Komponente
JCTMNode ebenfalls umgesetzt. Abbildung 5.13 zeigt das Klassendiagramm für diese
Implementierung
ComponentUI
EventObject
EventListener
CTMNodeModelEvent
<<interf ace>>
CTMNodeModelListener
ctmNodeModelChanged()
<<interf ace>>
CTMNodeModel
addCTMNodeModelListener()
remov eCTMNodeModelListener()
setClicked()
setCenter()
getClicked()
getCenter()
setTitle()
getTitle()
setText()
getText()
setContext()
getContext()
setStatus()
getStatus()
JComponent
DefaultCTMNodeModel
CTMNodeUI
comp : JComponent
node : Image
titleX : int
textX : int
mouseIcon : Image
statusIcon : Image
status : int
BEFOREVALID : f inal int
VALID : int
AFTERVALID : int
paint()
JCTMNode
model : CTMNodeModel
BEFOREVALID : static f inal int
VALID : static f inal int
AFTERVALID : static f inal int
listener : CtmNodeListener
getModel()
ctmNodeModelChanged()
setClicked()
setCenter()
getClicked()
getCenter()
setTitle()
setText()
getText()
setContext()
getContext()
setStatus()
getStatus()
title : String
text : String
center : boolean
clicked : boolean
context : boolean
status : int
BEFOREVALID : f inal int
VALID : f inal int
AFTERVALID : f inal int
_listeners : Ev entListenerList
setClicked()
setCenter()
getClicked()
getCenter()
setTitle()
getTitle()
setText()
getText()
setContext()
getContext()
setStatus()
getStatus()
addCTMNodeModelListener()
remov eCTMNodeModelListener()
f ireChangedEv ent()
Abbildung 5.13: Klassendiagramm - JCTMNode
Die Klassen JCTMNode sowie CTMNodeUI bilden zusammen das UI-Delegate und sind
somit zuständig für das Zeichnen der Komponente (ihr Aussehen) sowie die Behandlung
ihrer Ereignisse (das Verhalten). Die Klasse DefaultCTMNodeModel bildet das Modell der
Komponente und enthält somit die eigentlichen Daten sowie Werte über den Zustand der
Komponente.
86
Pass-Through-Methoden
Damit man beim Abfragen oder Ändern des Zustandes nicht auf das Modell zugreifen muss,
stellt die Komponente JCTMNode Pass-Through-Methoden zur Verfügung. Diese leiten bei
Änderungen Werte an das Modell weiter beziehungsweise holen bei Abfragen die Werte vom
Modell. Das folgende Codebeispiel für die Methoden setCenter() und getCenter() verdeutlicht
dies:
public void setCenter(boolean c){
model.setCenter(c);
}
public boolean getCenter(){
return model.getCenter();
}
5.3.3
Realisierung des Wizard-Konzeptes
Die Gestaltung und die genaue Funktionalität des Wizard-Konzeptes war zu diesem
Zeitpunkt noch nicht definiert. Grund hierfür war, dass zunächst der Editiermodus umgesetzt
wurde und die Gestaltung des Wizards sich an diesem Konzept anlehnen sollte. Ein
einheitliches Erscheinungsbild sollte dadurch geschaffen werden und Erfahrungen und
Verbesserungen bei der Implementierung des Editier-Konzeptes sollten in die Gestaltung
des Wizard-Konzeptes mit einfließen.
Grundsätzlich soll es im Bedienmodus des Wizard möglich sein Studiendaten soweit
anzulegen, dass später darauf aufbauend Studienaufträge erstellt und ausgeführt werden
können. Dies setzt voraus, dass die Objekte Studie, Medikationskopf, Intervallkopf sowie
Randomisierung komplett angelegt und in einem gültigen Zustand sind. Um dies zu
gewährleisten, soll der Wizard den Benutzer durch das Anlegen der verschiedenen Objekte
führen, sowie die notwendigen Statuswechsel veranlassen. Der genaue Aufgabenablauf ist
in Kapitel 4.2.4 Aufgabenanalyse beschrieben.
Im folgenden wird nun die Gestaltung und die genauere Funktionalität des Wizard-Modus
dargestellt.
Bei der Implementierung wurde kein komplett neuer Prototyp geschaffen, sondern auf dem
bereits bestehenden Prototypen für den Editiermodus aufgesetzt. Der darin vorhandene
Eingangsdialog bildet dabei den Ausgangspunkt von dem aus auch der Wizard-Modus
aufgerufen werden kann. Bei der Auswahl des Blattes Studies im Treeview des
Eingangsdialoges und bei Klick des Insert-Buttons in der Toolbar wird der Wizard gestartet.
Da das Anlegen der kompletten Studiendaten aus einer großen Zahl von Aufgaben und
Unteraufgaben besteht, soll es möglich sein, nach dem Erledigen einer Aufgabe abbrechen
zu können und den Anlegevorgang zu einem späteren Zeitpunkt fortzusetzen. Hierzu wurde
der Wizard in mehrere Hauptschritte (Aufgaben) aufgeteilt. Diese Hauptschritte bilden die
Objekte: Studie, Medikationskopf, Intervallkopf und Randomisierung, die nacheinander
angelegt werden sollen. Um ein einheitliches Aussehen und Wiedererkennung zu
gewährleisten werden diese Schritte als Knoten auf der linken Seite des Dialoges
untereinander dargestellt. Ein Knoten steht somit für einen Hauptschritt im Wizard,
repräsentiert aber auch gleichzeitig ein Objekt und sorgt später im Editiermodus für die
Wiedererkennung dieses Objektes. Die Reihenfolge, welche Objekte nacheinander
87
anzulegen sind, wird zudem durch Pfeile zwischen den Knoten visualisiert. Diese Darstellung
soll zum einen Übersicht über die noch zu erledigenden Schritte geben. Zum anderen soll
per Klick auf einen Knoten aber auch zu diesem Hauptschritt zurückgekehrt werden können.
Ein erster Eindruck dieses Konzeptes vermittelt der Papierentwurf in Abbildung 5.14.
Abbildung 5.14: Papierentwurf für das Wizard-Konzept
Die einzelnen Teilschritte (Unteraufgaben) beim Anlegen eines Objektes werden in den
entsprechenden Dialogflächen angezeigt. Gleich wie im Editiermodus ordnet dabei eine
Verbindungslinie die Dialogfläche einem bestimmten Knoten zu. In dieser Fläche werden die
einzelnen Teilschritte wiederum auf der linken Seite durch Buttons dargestellt. Gleich wie die
Hauptschritte des Wizard gewährleistet dies Übersicht, ermöglicht aber auch das Navigieren
durch den Aufgabenablauf. Im Papierentwurf in Abbildung 5.14 ist dies ebenfalls zu
erkennen.
Wiederaufnahme des Anlegevorgangs
Da es der Wizard ermöglichen sollte nach einer Aufgabe abzubrechen und den
Anlegevorgang zu einem späteren Zeitpunkt fortzusetzen, wird die Baumstruktur des
Eingangsdialoges um den Eintrag Incomplete studydata im Verzeichnis Study data ergänzt.
Ein Klick auf dieses Blatt zeigt eine Liste der unvollständig angelegten Daten. Bei der
Auswahl eines Listeneintrages und bei Klick auf Edit wird der Wizard-Modus wieder
angezeigt. Die Knoten der bereits angelegten Objekte sind dabei blau gefärbt während die
noch nicht erfassten Objekte grau dargestellt sind. Ein Snapshot dieses Konzeptes zeigt
Abbildung 5.15.
88
Ampelsymbol für Status
Abbildung 5.15: Snapshot des Wizard-Konzeptes
Visualisierung der Stati
Gleich wie im Editier-Modus werden die Stati der Objekte (Medikationskopf, Intervallkopf und
Randomisierung), sofern sie angelegt sind, mit einem Ampelsymbol neben dem Knoten des
Objektes angezeigt. Die Ampel stellt auch hier die folgenden drei Zustände dar:
·
kleiner gültig (beispielsweise: edit, verification), mit der Farbe gelb:
·
gültig (valid), mit der Farbe grün:
·
größer gültig (beispielsweise: obsolete, archived), mit der Farbe rot:
Realisierung von Wiederholungen (Schleifen)
Jeder Medikationskopf kann mehrere Medikationen beinhalten und diesen sind oft mehrere
Medikationskennungen zugeordnet. Um das Anlegen dieser Objekte mit dem Wizard zu
ermöglichen, muss der Benutzer solange zum entsprechenden Schritt zurückkehren können
bis alle Objekte angelegt sind. Es entsteht somit eine Schleife. Da pro Medikation wiederum
mehrere Medikationskennungen angelegt werden können, wird daraus eine verschachtelte
Schleife. Um dies im Wizard zu realisieren, erfragt eine Dialogfläche am Ende eines
Anlegevorgangs, ob dieser wiederholt werden soll. Abbildung 5.16 zeigt diese Dialogfläche
nach dem Anlegen einer Medikationskennung.
89
Medikationskopf
Abbildung 5.16: Snapshot - Anlegen von Medikationen und Medikationskennungen
Nach demselben Prinzip ist der Intervallkopf mit Intervallen und Intervallkennungen
anzulegen.
Statuswechsel durch den Wizard
Voraussetzung für das Anlegen der Randomisierung im Wizard ist, dass die Objekte
Medikationskopf und Intervallkopf im Status „gültig“ sind. Im gegenwärtigen CTM-System
kann eine Randomisierung zunächst auch ohne diese beiden Objekte angelegt werden. Da
aber im Verlauf des Anlegens diese Objekte der Randomisierung angefügt werden und diese
hierzu im Status „gültig“ sein müssen, wird die Gültigkeit dieser schon von Beginn an
vorausgesetzt.
Vor dem Anlegen der Randomisierung wird deshalb im Wizard erfragt ob der Statuswechsel
für den Medikations- und Intervallkopf durchgeführt werden soll. Klickt der Benutzer No so
kann er mit dem Anlegen der Randomisierung nicht fortfahren. Abbildung 5.17 zeigt diesen
Dialog.
90
Randomisierung
Abbildung 5.17: Snapshot - Statuswechsel
Bei Klick auf Yes wird der Statuswechsel der Objekte Medikationskopf und Intervallkopf
durchgeführt. Darauf folgend kann der Benutzer das Randomisierungsobjekt anlegen. Nach
Abschluss des Anlegens wird dieses ebenfalls auf gültig gesetzt. Die Studiendaten sind dann
komplett angelegt und der Wizard wird geschlossen.
Implementierung
JWizardPanel
Bei der Umsetzung des Wizard wurde der bereits bestehende Prototyp für den Editiermodus
um die Sicht JWizardPanel ergänzt. Ist im Treeview des Explorer das Blatt Studies
ausgewählt führt der Aufruf der Funktion Insert (in der Toolbar des JApplicationFrame) zum
Aufruf der Methode addWizard() des Objektes JApplicationFrame und zur Darstellung des
Wizards. Das folgende Code-Beispiel zeigt diese Methode:
public void addWizard(){
explorer.hide();
deleteAddMenus();
jWizard = new JWizardPanel(this);
jWizard.setVisible(true);
jActualPanel = jWizard;
getContentPane().add(jWizard);
validate();
repaint();
}
Gleich wie bei der Darstellung der Sichten für den Editier-Modus wird hier zunächst der
Explorer verborgen und eventuell zusätzliche Menüs werden gelöscht. Das Objekt
JWizardPanel wird dann erzeugt und dargestellt. Im Konstruktor des JWizardPanel erfolgt
91
der Aufruf der Methode showStudyWizard1(). Diese erzeugt die Datenmaske für den ersten
Schritt des Anlegens der Studie. In Abbildung 5.18 ist diese Darstellung zu sehen.
Abbildung 5.18: Snapshot - Eingangsdarstellung des Wizard
Die Klasse JWizardPanel übernimmt die Steuerung des Ablaufes der aufeinander folgenden
Datenmasken. Wechselt der Benutzer per Klick auf Next von der ersten Datenmaske der
Studie zur zweiten, so löst dies den Aufruf der Methode showStudyWizard2() aus, die die
bestehende Datenmaske löscht und die neue Datenmaske erzeugt und darstellt. Das
folgende Code-Beispiel zeigt diese Methode:
public void showStudyWizard2(){
//set value requestedData for paint-Method to draw connection line
requestedData = STUDY;
actualSubStep = 2;
studyNode.setText(study.study);
//set progress substep
if (incompStudy.progressStep == STUDY &&
incompStudy.progressSubStep < 2){
incompStudy.progressSubStep = 2;
}
int progress;
if (incompStudy.progressStep == STUDY){
progress = incompStudy.progressSubStep;
}
else{
progress = 5;
}
remove(actualPanel);
//Create 2. view for study
JWizardPanel2 jWizard2 = new JWizardPanel2(this, study,
progress);
jWizard2.setVisible(true);
jWizard2.setBounds(380,100,620,440);
actualPanel = jWizard2;
add(jWizard2);
92
validate();
repaint();
}
Progress-Step und Progress-Substep
Da der Wizard zwischenzeitlich abgebrochen werden und zu bereits durchlaufenen Schritten
zurückgekehrt werden kann ist es notwendig den Stand des Fortschrittes zu speichern.
Hierzu dienen die Integer-Variablen progressStep und progressSubstep. progressStep steht
hierbei für einen Hauptschritt des Wizard (beispielsweise das Anlegen des Studienobjektes),
während progressSubstep für die auszuführende Teilaufgabe steht.
Management der Daten
Hier ist zu erwähnen, dass die Klasse JWizardPanel die folgenden zwei Konstruktoren zur
Verfügung stellt:
public JWizardPanel(JApplicationFrame jaf)
Dieser Konstruktor wird aufgerufen wenn komplett neue Studiendaten angelegt werden
sollen, also zuvor im Treeview des Eingangsdialoges das Blatt Studies ausgewählt war und
die Insert-Funktion aufgerufen wurde.
In diesem Konstruktor wird eine Instanz der Klasse IncompleteStudy erzeugt. Sie enthält alle
Datenobjekte, die notwendig sind beim Anlegen der Studiendaten sowie zusätzlich die
Integer-Werte progressStep und progressSubstep. Abbildung 5.19 zeigt das
Klassendiagramm dieser Klasse.
IncompleteStudy
study : Study
medHeader : MedHeader
vectMedicationIDs : Vector
intHeader : IntervalHeader
intervals : Intervals
vectIntervalIDs : Vector
randomization : Randomization
progressStep : int
progressSubStep : int
getListElements()
Abbildung 5.19: Klassendiagramm - IncompleteStudy
Die in Kapitel 5.3.2 bereits beschriebene Klasse Datasource wird um die Klasse
IncompleteStudies ergänzt. Wie alle anderen Attribute der Klasse Datasource erbt auch die
Klasse IncompleteStudies von der Klasse Vector und enthält alle Instanzen der Klasse
IncompleteStudy. Das Objekt IncompleteStudy wird im hier beschriebenen Konstruktor gleich
nach der Erzeugung dem Objekt IncompleteStudies angefügt. Hierzu wird die Methode
saveNewIncompleteStudy() des JApplicationFrame aufgerufen und dieser das Objekt
IncompleteStudy übergeben. Bei Verlassen des Wizard bleibt dadurch dieses Objekt
persistent in der Klasse Datasource mit den aktuellen Werten. Das in Abbildung 5.20
dargestellte Sequenzdiagramm soll diesen Ablauf verdeutlichen.
Klick auf
Insert
JApplication
Frame
93
Explorer
JWizardPanel
Datasource
Incomplete
Studies
1: getSelection()
2: addWizard()
3: new JWizardPanel(JApplicationFrame)
4: new IncompleteStudy()
5: saveNewIncompleteStudy(IncompleteStudy)
6: getIncompleteStudies()
7: add(IncompleteStudy)
Abbildung 5.20: Sequenzdiagramm - Anlegen neuer Studiendaten
Den verschiedenen Datenmasken wird bei der Erzeugung immer eine Referenz auf das
entsprechende Objekt mitgegeben. Die eingegebenen Daten werden somit direkt in die
Objekte eingefügt.
public JWizardPanel(JApplicationFrame jaf, IncompleteStudy is)
Dieser Konstruktor für die Klasse JWizardPanel wird aufgerufen wenn Studiendaten mit dem
Wizard bereits teilweise angelegt wurden und diese weiter vervollständigt werden sollen.
Hierzu wählt der Benutzer im Treeview des Eingangsdialoges das Blatt Incomplete Study
Data aus, selektiert bereits angelegte Studiendaten in der Liste und Klickt Edit. Dies führt
zum Aufruf der Methode addWizard(String stud). Diese Methode holt sich vom Objekt
Datasource eine Referenz auf das entsprechende Objekt IncompleteStudy und übergibt
diese an den Konstruktor des JWizardPanel. Das Objekt IncompleteStudy wird somit in
diesem Konstruktor nicht neu erzeugt sondern nur zugewiesen. Abbildung 5.21 zeigt das
Sequenzdiagramm zum gerade beschriebenen.
Klick auf Edit
94
JApplication
Frame
Explorer
JWizardPanel
Datasource
1: getSelection()
2: addWizard(studienName)
3: getIncompleteStudy(studienName)
4: new JWizardPanel(JApplicationFrame, IncompleteStudy)
Abbildung 5.21: Sequenzdiagramm - Wiederaufnahme des Anlegevorgangs
Die Datenmasken
Wie bereits erwähnt werden den Datenmasken die entsprechenden Objekte als Referenz
zugewiesen. Einträge oder Änderungen können somit direkt am entsprechenden Objekt der
Instanz IncompleteStudy vorgenommen werden.
Neuanlegen und Ändern
Wird ein Objekt mit dem Wizard neu angelegt (Neu anlegen im Sinne von erstmaligem
Durchlaufen der Schritte eines Objektes), wird am Ende des Durchlaufens aller Schritte das
Objekt zusätzlich unter seinem Objekttyp abgespeichert. Einfacher formuliert bedeutet dies,
dass beispielsweise ein Studien-Objekt nach dem Anlegen nicht nur in der Datenquelle unter
IncompleteStudies zu finden ist sondern auch unter dem Objekt Studies. Dies gewährleistet,
dass das Objekt später auch im Editier-Modus bearbeitet werden kann.
Da es der Wizard zudem erlauben soll zu bereits angelegten Objekten zurückzukehren und
deren Schritte nochmals zu durchlaufen, müssen eventuelle Änderungen zusätzlich unter
dem entsprechenden Objekttyp vorgenommen werden (Also Änderungen einer Studie am
entsprechenden Objekt Study unter der Instanz Studies in der Datenquelle). Des weiteren
sollten diese Änderungen nicht automatisch persistent gemacht werden sondern erst nach
einer Anfrage durch das System. Wie dies realisiert ist, wird nun am Beispiel des Anlegens
und Änderns einer Studie dargestellt.
Grundsätzlich implementiert jede Datenmaske des Wizard folgende Methoden:
·
showData()
Diese dient der Anzeige der Daten eines Objektes in den entsprechenden Feldern.
Hierzu ein Codebeispiel aus der Datenmaske JWizardPanel1:
private void showData(){
jTextField1.setText(study.study);
jTextField2.setText(study.description);
jComboBox1.setSelectedItem(study.studyPhase);
95
jTextField3.setText(study.costCenter);
}
·
checkData()
Hier wird überprüft ob Änderungen an den bestehenden Daten vorgenommen wurden.
Hier ist zu erwähnen, dass das Neuanlegen von Daten gleich behandelt wird wie das
Ändern von Daten. Wird ein Objekt neu angelegt ist dies nichts anderes als eine
Änderung der Werte von null oder Leer-String zum entsprechenden Wert. Sofern beim
Neuanlegen also Werte eingegeben werden, stellt dies eine Änderung dar und begründet
später das Speichern des entsprechenden Objektes.
Klickt der Benutzer Next wird zunächst die hier beschriebene Methode aufgerufen.
Sofern Werte verändert wurden, wird mit der Methode setDataChanged() des Objektes
JWizardPanel der Wert dataChanged auf true gesetzt. Aufgrund dieses Wertes wird
später bestimmt ob Änderungen gespeichert werden müssen. Hier wiederum ein CodeBeispiel aus der Klasse JWizardPanel1:
private void checkData(){
if(!study.study.equals(jTextField1.getText())){
dataChanged = true;
}
if(!study.description.equals(jTextField2.getText())){
dataChanged = true;
}
if(!study.studyPhase.equals(jComboBox1.getSelectedItem())){
dataChanged = true;
}
if(!study.costCenter.equals(jTextField3.getText())){
dataChanged = true;
}
if(dataChanged){
setData();
parent.setDataChanged(true);
}
}
·
setData()
Sofern Änderungen in der Methode checkData() festgestellt wurden, werden die neuen
oder geänderten Werte dem entsprechenden Objekt zugewiesen. Folgendes CodeBeispiel zeigt dies:
private void setData(){
study.study = jTextField1.getText();
study.description = jTextField2.getText();
study.studyPhase = (String)jComboBox1.getSelectedItem();
study.costCenter = jTextField3.getText();
}
Nachdem die Schritte des Objekts Studie durchlaufen wurden und im letzten Panel auf Next
geklickt wurde, wird die Methode finishStudyData() des Objektes JWizardPanel aufgerufen.
Aufgrund des boolschen Wertes dataChanged wird hier entschieden ob das Objekt
gespeichert werden muss. Im folgenden Code-Beispiel wird dies ersichtlich:
public
//
//
if
96
void finishStudy(){
if the data of the study have been changed or have been
newly created
(dataChanged){
// if the steps for study-creation are passed the first time
if (incompStudy.progressStep == STUDY){
parent.saveNewStudy(study);
JFinishDialog jFinishDialog = new JFinishDialog(this,
"The data of the study object are saved now.",
true);
jFinishDialog.setBounds(380,100,500,400);
jFinishDialog.setVisible(true);
}
// if study data has been changed
else{
JSaveDialog jSaveDialog = new JSaveDialog(this, "The
data of the study object are modified", true);
jSaveDialog.setBounds(380,100,400,300);
jSaveDialog.setVisible(true);
validate();
repaint();
}
dataChanged = false;
}
else{
showMedWizard1();
}
}
Sofern Änderungen durchgeführt wurden (dataChanged == true) wird anhand der IfBedingung
if (incompStudy.progressStep == STUDY) (siehe obiges Code-Beispiel)
festgestellt ob die Studie neu angelegt wurde oder ob sie bereits besteht und nur verändert
wurde. Wurde sie neu angelegt, wird sie mit der Methode saveNewStudy() der Klasse
JApplicationFrame dem Objekt Studies (in der Datenquelle) angefügt.
Wurden die Schritte der Studie dagegen ein weiteres Mal durchlaufen, wird zunächst ein
Dialogfenster geöffnet, das den Benutzer fragt ob die Änderungen gespeichert werden
sollen. Bestätigt er, führt dies zum Aufruf der Methode saveStudy(). Diese ruft wiederum die
gleichnamige Methode der Klasse JApplicationFrame auf. In dieser wird das bereits
bestehende Studien-Objekt zunächst gesucht und durch das geänderte ersetzt.
Gleich wie beim Studien-Objekt gibt es für die Objekte Medikationskopf, Intervallkopf und
Randomisierung die entsprechenden Methoden.
6 Evaluierung der Prototypen
Nachdem ein Wizard-Modus für das Anlegen von Studiendaten und ein Editier-Modus
implementiert wurden, bestand nun der nächste Schritt darin, diese Konzepte auszuwerten.
Wie in Kapitel 2.2.3 Usability Evaluation beschrieben, sind die Prototypen einer Gruppe von
Testpersonen vorzuführen, die repräsentativ sind für die Benutzer eines späteren Systems.
Deren Reaktion soll helfen Schwachstellen aufzudecken.
Da während dieser Arbeit ein Kontakt zu Benutzern des gegenwärtigen Systems nicht
möglich war, wurde ein Test mit einem Mitarbeiter der Abteilung Training & Learning
durchgeführt. Dieser war mit der Aufgabenstellung des Clinical Trial Managements bereits
vertraut.
Bei der Auswertung wurde die Strategie des Laut denken angewendet. Eine
Aufgabenstellung wurde hierzu aufgestellt und die vom Mitarbeiter formulierten Gedanken
wurden aufgenommen.
6.1 Aufgabenstellung
Die Aufgabenstellung lautete wie folgt:
Teilanlegen von Studiendaten:
Legen Sie zunächst eine neue Studie, sowie einen dazugehörigen Medikationskopf an.
Die folgenden Daten sind zu erfassen:
Studie
· Die Studie soll den Namen „study 42“ bekommen und eine nähere Beschreibung
der Studie soll „Teststudie – Usability Test“ lauten.
· Die Studienphase ist 2.
· Das Design der Studie:
- Design 1: single blind
- Design 3: mono centric
- Design 4: international
- Design 5: controlled
- Purpose: exploratory
· Bei den Artikeldaten ist als Artikelname „Aspirin“ einzugeben.
· Das geplante Startdatum ist der 15.02.2002 das geplante Enddatum ist der
15.03.2002.
Evaluierung der Prototypen
98
Medikationskopf
· Der Name des Medikationskopfes ist „mh1“.
· 2 Medikationen sind anzulegen:
- a1, mit dem Artikel „Aspirin Box“ und den beiden Medikationskennungen „Aspirin
Schachtel“ (Sprache: „german“) und „Aspirin Box“ (Sprache: „english“).
- a10, mit dem Artikel „Aspirin 200mg“ mit der Medikationskennung „Aspirin200“
(Sprache: „german“). Die übergeordnete Medikation sei hier „a1“.
Editieren der Studiendaten:
Nachdem die Objekte angelegt sind, soll das Studien-Objekt editiert werden. Die
Beschreibung der Studie soll auf „Teststudie 42 – Test auf Benutzerfreundlichkeit“
geändert werden. Zudem soll kontrolliert werden ob alle Daten richtig erfasst wurden.
Darauf folgend ist ausgehend von der Studie, der zuvor angelegte Medikationskopf
aufzurufen und die Daten sind ebenfalls zu prüfen.
Vollständiges Anlegen der Studiendaten:
Intervallkopf
Ergänzend zur zuvor angelegten Studie ist ein Intervallkopf mit dem Namen „ih1“
anzulegen. Dem Intervallkopf sind die Intervalle „i1“ und „i2“ anzufügen. Intervall „i1“
erhält die Kennung „woche 1“ (Sprache: „german“) und Intervall „i2“ erhält die Kennung
„woche 2“ (Sprache: „german“).
Randomisierung
Aufbauend auf den bisher erstellten Objekten ist eine Randomisierung anzulegen. Der
Name der Randomisierung sei „randomization 42“. Des weiteren sind folgenden Daten
anzugeben:
· Patienten (geplant)
- Patienten pro Satz: 20
- von Nummer: 1000
- Offset: 500
- Anzahl Patienten Sätze: 1
- Anzahl Rückstellblocks: 1
- Anzahl Endfreigabeblocks: 1
· Design
- Design 2: Cross-over
- Nummerierung: Consecutive
- Anzahl Intervalle: 5
- Anzahl Behandlungsgruppen: 2
- C-Faktor: 1
Darauf folgend ist die Medikations-Matrix mit den Medikationen zu bestücken. Zum
Schluss ist ein Statuswechsel der Randomisierung nach „valid“ durchzuführen.
Vor der Ausführung dieser Aufgabe wurde dem Mitarbeiter das neue Bedienkonzept
zunächst vorgestellt und ihm einige Zeit eingeräumt um sich mit dem System vertraut zu
machen. Speziell wurde dem Mitarbeiter gezeigt wie der Übersichtsgraph im Editiermodus zu
99
bedienen ist, um die Daten der verschiedenen Objekte anzuzeigen. Des weiteren wurde
erwähnt, dass das Neuanlegen von Studiendaten durch einen Wizard unterstützt wird und
dass dieser nach jedem Hauptschritt unterbrochen werden kann. Der Mitarbeiter wurde
zudem darauf hingewiesen, dass die teilweise angelegten Studiendaten im Verzeichnis
Incomplete study data zu finden sind. Wie der Wizard genau zu bedienen ist wurde aber
nicht näher erläutert. Der Benutzer sollte sich intuitiv zurecht finden.
Nach dieser Einführung wurde die Testaufgabe ausgeführt und die Kommentare des
Mitarbeiters wurden in einer Wave-Datei aufgezeichnet.
6.2 Durchführung der Evaluierung
6.2.1
Teilanlegen der Studiendaten
Aufgrund der Aufgabenstellung sollte der Mitarbeiter zunächst vom Eingangsdialog in den
Wizard-Modus gelangen um eine Studie sowie einen Medikationskopf anzulegen. Hierzu war
im Treeview des Eingangsdialoges das Blatt Studies zu finden und anzuklicken, sowie die
Insert-Funktion in der Toolbar aufzurufen. Abbildung 6.1 zeigt den Eingangsdialog mit dem
entsprechenden Treeview.
2. Insert
1. Studies
Abbildung 6.1: Snapshot - Aufruf des Wizard-Modus
Folgender Ausschnitt aus den Kommentaren des Mitarbeiters zeigt den Aufruf des WizardModus:
100
„Ich gehe auf der linken Seite zu Study data. Das ist relativ einsichtig, dass ich
das machen will. Jetzt muss ich mir überlegen was ich darunter aussuche und da
steht Study related data. Das klingt vernünftig. Da geh ich jetzt mal zu Studies.
Da möcht ich eine neue Studie anlegen, deshalb gehe ich auf Insert. Jetzt
wechselt der Bildschirm. Und hier kann ich Basic data eingeben.“
Dieser Kommentar zeigt, dass der Aufruf des Wizard-Modus ohne Probleme durchgeführt
wurde.
Nachdem die Daten des Studien-Objekts im Wizard eingegeben wurden, sollte nun der
Medikationskopf angelegt werden. Die letzte Dialogfläche für die Studie war im Wizard noch
angezeigt. Um Daten für den Medikationskopf eingeben zu können, musste hier noch einmal
Next geklickt werden. Abbildung 6.2 zeigt diese Situation.
Exit
Studien-Objekt
Medikationskopf
Abbildung 6.2: Snapshot - Vorzeitiges Verlassen des Wizard-Modus
Anstatt nochmals Next zu klicken um zum Dialog für den Medikationskopf zu gelangen,
versuchte die Testperson dies mit Doppelklicken auf den Knoten für den Medikationskopf zu
erreichen, was folgender Ausschnitt aus den Kommentaren zeigt:
Also geh ich jetzt auf Medication Header der ist ja hier links auf dem Bildschirm
zu haben. Jetzt würd’ ich da ja noch gerne doppelklicken, aber das scheint nicht
zu funktionieren. Ich vermute mal, dass ich zunächst mal die Studie exiten muss
und dann hier auf den Medication Header gehen kann. Ist das jetzt der direkte
Weg gewesen? Keine Ahnung!
Der Mitarbeiter hat daraufhin Exit geklickt, wonach wieder der Eingangsdialog angezeigt
wurde. An dieser Stelle musste eingegriffen und der Testperson gezeigt werden wie hier
weiter vorzugehen ist.
In diesem Zusammenhang ist zu erwähnen, dass der Button Exit in der Toolbar bei der
Testperson für Verwirrung gesorgt hat. Die Bezeichnung vermittelt den Eindruck, dass
hierdurch das komplette System verlassen wird und nicht zum Eingangsdialog zurückgekehrt
werden kann.
101
Das Anlegen des Medikationskopfes mit Medikation und Medikationskennungen wurde vom
Mitarbeiter erfolgreich durchgeführt. Allerdings sorgten die verschachtelten Schleifen (äußere
Schleife für die Medikationen, sowie innere Schleife für die Medikationskennungen einer
Medikation) für etwas Verwirrung.
6.2.2
Editieren der Studiendaten
Nachdem das Studien-Objekt sowie der Medikationskopf erfolgreich angelegt wurden, sollte
der Mitarbeiter die angelegten Daten im Editiermodus prüfen und teilweise verändern. Hier
zeigte sich ein Fehler in der Implementierung des Prototypen, da die angelegte Studie in der
Auswahlliste nicht zu finden war. Die Testperson löste dieses Problem indem sie die
teilweise angelegten Studiendaten wiederum mit dem Wizard-Modus öffnete und per Klick
auf Next das bereits angelegte nochmals durchlief.
6.2.3
Vollständiges Anlegen der Studiendaten
Darauf folgend wurde der Intervallkopf mit Intervall und Intervallkennung angelegt. Auch hier
bereiteten die verschachtelten Schleifen dem Mitarbeiter einige Probleme.
Als letztes war noch die Randomisierung zu erfassen. Bevor diese angelegt werden kann
wird der Benutzer darauf hingewiesen, dass die Stati von Medikations- und Intervallkopf
zunächst auf „valid“ geändert werden müssen. Hier kann der Benutzer mit Yes oder No
entscheiden, ob der Wizard diesen Statuswechsel durchführen soll. Die Reaktion der
Testperson zeigt der folgende Ausschnitt aus den Kommentaren:
„Hmm… automatische Versionshochsetzung während der Editierphase…
mmhhh.. gefährlich, aber egal, machen wir das einfach mal, damit wir überhaupt
die Randomisierung eingeben können“
Es zeigte sich, dass der Testperson ein Statuswechsel während der Phase des Neuanlegens
nicht sinnvoll erschien. Grundsätzlich kann eine Randomisierung bis zu einem gewissen
Grad auch ohne gültigen Medikations- sowie Intervallkopf angelegt werden. Das Ziel bei der
Entwicklung des Wizard-Konzeptes war es die Studiendaten soweit anzulegen, dass spätere
Studienaufträge darauf aufbauend ausgeführt werden können. Hierzu müssen alle Objekte
den Status gültig erreicht haben. Ob dieses Ziel zu weit gesteckt ist, und im Wizard-Modus
statt dessen auf die Statuswechsel verzichtet werden sollte, ist später zu bewerten.
6.2.4
Schlussfolgerung
Da die Evaluierung des Prototypen nur mit einer Testperson durchgeführt wurde, sind die
Ergebnisse hierbei noch sehr vorsichtig zu bewerten. Aufgrund eines Fehlers im Prototypen
konnte zudem der Editiermodus mit dem Übersichtsgraphen nicht näher ausgewertet
werden. Dieser Editiermodus wurde dem Mitarbeiter im Anschluss noch vorgestellt. Der
Mitarbeiter reagierte auf das neue Konzept sehr positiv. Das bloße Vorführen hat aber nur
sehr geringe Aussagekraft bei der Beurteilung eines Dialoges nach seiner softwareergonomischen Gestaltung.
102
Trotz allem sind aber speziell beim Wizard-Modus einige wesentliche Dinge festzustellen, die
verbessert werden müssen. Zudem soll dieser Test auch grundsätzlich zeigen, wie mit einer
solchen Methodik Schwachstellen aufgedeckt und Verbesserung erzielt werden können.
Schwachstellen:
·
·
·
·
Intuitivität ist im Wizard-Konzept noch nicht gegeben. Die verschachtelten Schleifen zum
Anlegen von Medikationen und deren Medikationskennungen beziehungsweise
Intervallen und deren Intervallkennungen sind zu umständlich.
Die Funktionsbezeichnung Exit für das Zurückkehren in den Eingangsdialog ist
ungeeignet.
Für Benutzer, die mit dem System und der Aufgabenstellung vertraut sind, wirkt der
Wizard-Modus zu starr. Für das Anlegen von Studiendaten sollte deshalb zusätzlich ein
Experten-Modus eingeführt werden.
Ob Statuswechsel vom Wizard durchgeführt werden sollten, muss in einer weiteren
Evaluierung durch mehrere repräsentative Testpersonen geprüft werden. Zudem ist
hierzu auch die Aufgabenstellung nochmals genauer zu analysieren.
6.3 Hedonistische Qualitäten des neuen Konzeptes
Unter dem Begriff des Joy of use (siehe Kapitel 3.3) wurde in dieser Ausarbeitung auch auf
höhere Ziele, eben hedonistische Qualitäten, bei der Entwicklung einer modernen
Benutzerschnittstelle eingegangen. Um bewerten zu können, ob und wie weit das neu
erstellte Dialogkonzept solche Qualitäten erfüllt, wurde die Technik des Semantic
Differentials eingesetzt. Wie bereits beschrieben, werden hier sieben gegensätzliche
Adjektiv-Paare, dem Benutzer vorgelegt, anhand derer das neue Konzept bewertet wird.
Tabelle 6.1 zeigt die Beurteilung des neuen CTM-Dialogkonzeptes durch die Testperson:
überragend
exklusiv
beeindruckend
einzigartig
innovativ
erregend
interessant
ð
ð
ð
ð
ð
ð
X
ð
ð
X
ð
X
ð
ð
X
X
ð
X
ð
X
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
ð
zweitklassig
standard
uninteressant
gewöhnlich
konservativ
stumpfsinnig
langweilig
Tabelle 6.1: Beurteilung nach der Technik des Semantic Differential
Der Hedonic Quality Value würde nach dieser Beurteilung bei 5,57 liegen, wobei 7 der beste
und 1 der schlechteste Wert darstellt. Hier ist anzumerken, dass diese Beurteilung von nur
einer Testperson durchgeführt wurde, die zudem Mitarbeiter ist bei Propack-Data. Obwohl
diese Person gebeten wurde, das Bedienkonzept objektiv und kritisch zu beurteilen, ist eine
Neigung eher zum positiven nicht auszuschließen.
7 Bewertung und Ausblick
Die Ergebnisse dieser Arbeit lassen sich zunächst in zwei Bereiche aufteilen. Im ersten Teil
(Kapitel 2 und 3) wurden die theoretischen Grundlagen für die Erstellung eines neuen
Bedienkonzeptes geschaffen. Der Begriff der Software-Ergonomie wurde anhand der VDIRichtlinien, der ISO 9241 Norm sowie der Regeln von Shneiderman genau definiert. Anhand
des Usability Engineering wurde eine Methodik vorgestellt, um aufbauend auf einer
gegebenen Aufgabenstellung ein entsprechendes ergonomisches Dialogsystem zu schaffen.
Dabei sind die Schritte Analyse, konzeptuelles und visuelles Design sowie Evaluierung
iterativ zu durchlaufen, bis ein Optimum gefunden ist.
Der Abschluss des theoretischen Teils bildete die Aufnahme des Standes der Technik von
Dialogsystemen. Hier wurden verschiedene neue Visualisierungsmöglichkeiten wie FisheyeMenus oder Hyperbolic Browser aber auch moderne Interaktionstechniken wie akustische
oder gestenbasierte Interaktion vorgestellt. Daneben wurden unter dem Begriff Joy of use
hedonistische Qualitäten einer Benutzerschnittstelle erläutert. Zum aktuellen Stand der
Technik von Dialogsystemen gehört auch die Berücksichtigung von psychologischen
Aspekten. Hierbei wurde auf die Bereiche Farbpsychologie und Gestaltpsychologie näher
eingegangen.
Im zweiten Teil der Arbeit (Kapitel 4 und 5) erfolgte die praktische Umsetzung des zuvor
dargestellten anhand von Prototypen. Hierbei wurde zunächst die PMX-Lösung CTM
vorgestellt und die Funktionalität erläutert. Anhand der in Kapitel 2 gezeigten Eigenschaften
ergonomischer Software wurde die bestehende Benutzerschnittstelle bewertet und
Schwachstellen aufgedeckt. Basierend auf der Methodik des Usability Engineering erfolgte
dann die Analyse der Benutzer sowie die Analyse der Aufgabenstellung des Managements
von Studien. Beim Übergang von der Analyse- in die Designphase zeigte sich, dass an
dieser Stelle im Prozess des Usability Engineering eine Lücke besteht. Beim Entwerfen
eines neuen Dialoges ist, neben dem Wissen über die Möglichkeiten der Gestaltung, auch
ein gewisser Grad an Kreativität notwendig. Dieser kann nicht durch eine festgelegte
Methodik ersetzt werden.
Wie sich bei der Analyse zeigte sind die größten Probleme des untersuchten Gebietes, die
komplexe Aufgabenstellung, sowie kaum überschaubare Abhängigkeiten der verschiedenen
Objekte. Beim Design wurde deshalb zum einen ein Wizard-Modus für das Anlegen von
Studiendaten geschaffen. Dieser führt den Benutzer durch die Aufgabenstellung und bewahrt
ihn somit vor der Komplexität der Aufgabe. Des weiteren wurde ein Editier-Modus für das
Ändern und Ergänzen der verschiedenen in Beziehung stehenden Objekte geschaffen.
Dieser Modus zeichnet sich vor allem durch einen Übersichtsgraph auf der linken Seite des
Dialoges aus. In diesem Graph werden die Beziehungen der Objekte visualisiert und
dadurch die Übersichtlichkeit gefördert.
Um den ersten Iterationszyklus des Usability-Engineerings abzuschließen, wurde
anschließend ein Usability-Test anhand der Strategie des Laut denken mit einem Mitarbeiter
der Abteilung Training & Learning durchgeführt. Zudem wurden hedonistische Qualitäten der
Konzepte aufgrund der Technik des Semantic Differential bewertet.
Bewertung und Ausblick
104
7.1 Bewertung der neuen Konzepte
Im folgenden soll nun, als Ergänzung zur bisherigen Evaluierung, geprüft werden, wie weit
die neuen Konzepte die Eigenschaften ergonomischer Software erfüllen. Wie bereits bei der
Analyse der bestehenden Benutzerschnittstelle, findet auch hier ein Vergleich mit den VDIRichtlinien und ISO-Normen statt. Tabelle 7.1 zeigt die Ergebnisse im einzelnen.
Grundsatz
VDI-Richtlinie:
Kompetenzförderlichkeit
VDI-Richtlinie:
Handlungsflexibilität
VDI-Richtlinie:
Bezug zu PMX / CTM
Der Übersichtsgraph im Editier-Modus, fördert beim
Benutzer das Wissen über die Zusammenhänge im System.
Die Möglichkeiten der direkten Manipulation fördern zudem
die Verständlichkeit der Funktionalität.
Im Wizard-Modus ist von Anfang an zu sehen welche
Schritte durchlaufen werden müssen. Der Benutzer bleibt
nicht im Ungewissen.
Dies
alles
führt
im
Vergleich
zur
bisherigen
Benutzerschnittstelle zu einer wesentlichen Steigerung der
Handlungskompetenz des Benutzers.
Das Anlegen neuer Studiendaten ist bei dem entworfenen
Bedienkonzept im Wizard-Modus durchzuführen. Hierzu gibt
es keine Alternativen.
Für das Ändern und Ergänzen kann der Benutzer sowohl
den Editier-Modus wählen, als auch den Wizard-Modus
(nochmals) durchlaufen.
Handlungsflexibilität ist somit nur teilweise gegeben.
Gerade für das Anlegen sollte noch ein Experten-Modus
geschaffen werden.
Der Wizard-Modus ermöglicht es die Aufgabenstellung des
Neuanlegens korrekt zu durchlaufen. Fehler werden hier
ausgeschlossen.
Im Editiermodus gewährleistet der Übersichtsgraph das
schnelle Auffinden in Beziehung stehender Objekte. Zudem
ist durch die Visualisierung der Stati (Ampelsymbol) diese
Information direkt verfügbar.
Des weiteren ist ausgeschlossen, dass mehrere Fenster
geöffnet sind und diese sich überlappen.
Dies alles führt zu einer wesentlichen Steigerung der
Aufgabenangemessenheit.
ISO 9241:
siehe VDI-Richtlinie
ISO 9241:
Der Übersichtsgraph, aber auch das Ampelsymbol zur
Selbstbeschreibungsfähigkeit Anzeige der Stati fördern die Selbstbeschreibungsfähigkeit
des Dialoges.
Die Verfügbarkeit von Kontextmenüs wird zudem durch ein
Maussymbol, bei dem die rechte Maustaste rot gefärbt ist,
visualisiert. Der Benutzer muss dies also nicht durch
Probieren herausfinden.
Die Selbstbeschreibungsfähigkeit kann aber trotz allem
noch erheblich gesteigert werden. Beispielsweise sollten
ISO 9241:
Steuerbarkeit
ISO 9241:
Erwartungskonformität
ISO 9241:
Fehlerrobustheit (-toleranz)
ISO 9241:
Individualisierbarkeit
ISO 9241:
Lernförderlichkeit
105
Prozesse wie die Randomisierungsfunktion noch visualisiert
werden. Aber auch das Anlegen der Objekte eines
Medikations- bzw. Intervallkopfes ist noch nicht soweit
umgesetzt, dass dies für den Benutzer selbstbeschreibend
ist.
Beim Anlegen der Studiendaten mit dem Wizard-Modus
muss der Benutzer zunächst die vorgegebenen Schritte
durchlaufen. Will er aber später noch Änderungen
durchführen kann er im Wizard zum entsprechenden Schritt
zurückkehren und diesen nochmals abarbeiten.
Der Ablauf des Anlegens ist somit teilweise steuerbar.
Die nacheinander zu durchlaufenden Schritte des WizardModus sind gleich wie im Editiermodus durch einen
Graphen auf der linken Seite des Dialoges dargestellt.
Zudem können die Knoten des Graphen in beiden Modi
angeklickt werden, um die entsprechenden Daten der
Objekte, die sie repräsentieren, anzuzeigen. Dies führt zu
Konsistenz und fördert die Erwartungskonformität.
Die meisten gegenwärtigen Softwaresysteme enthalten die
Technik der direkten Manipulation. Diese wurde im neuen
Bedienkonzept ebenfalls realisiert. Auch dies trägt zu einer
Steigerung der Erwartungskonformität bei.
Da die Umsetzung des neuen Bedienkonzeptes nach dem
Prinzip des horizontalen Prototyping erfolgte, wurde die
Funktionalität des Systems fast völlig außer Acht gelassen.
Fehlermeldungen wurden deshalb nicht berücksichtigt.
Verschiedene Bedien-Modi für unterschiedliche Benutzer
sind auch im neuen Konzept nicht vorhanden.
Ist der Benutzer mit dem Anlegen der Studiendaten noch
nicht sehr vertraut, wird er trotzdem vom Wizard durch die
entsprechenden Teilaufgaben geführt. Das Verständnis für
die Aufgabenstellung wird hierdurch gefördert. Allerdings
sollte das System, wie schon erwähnt, zusätzlich über einen
Experten-Modus verfügen, da die Verwendung des Wizard
für einen erfahrenen Benutzer eher umständlich ist.
Der Übersichtsgraph des Editier-Modus fördert ebenfalls
das Verständnis für die Zusammenhänge der einzelnen
Objekte.
Tabelle 7.1: Vergleich des neuen Konzeptes mit Richtlinien und Normen
7.2 Ausblick
Bei der Bewertung des neu gestalteten Bedienkonzeptes anhand der VDI-Richtlinien und
ISO-Normen ist festzustellen, dass unter software-ergonomischen Gesichtspunkten eine
Verbesserung im Vergleich zum bestehenden System erzielt wurde. Trotz allem ist aber ein
Optimum noch nicht erreicht, da einige Prinzipien nur teilweise (Handlungsflexibilität,
Steuerbarkeit) oder noch gar nicht (Individualisierbarkeit, Fehlerrobustheit) realisiert wurden.
106
Bei der weiteren Vorgehensweise sollte zunächst die Evaluierung anhand mehrerer „echter“
Benutzer durchgeführt werden um hier repräsentative Ergebnisse zur Auswertung des neu
gestalteten Bedienkonzeptes gewinnen zu können.
Experten-Modus
In einem weiteren Iterationsschritt des Usability Engineering Prozesses sollte zusätzlich ein
Konzept für einen Experten-Modus für das Anlegen von Studiendaten entworfen werden. Im
Gegensatz zum Wizard-Modus sollte der Benutzer hier den Ablauf des Anlegens soweit
selbst steuern können, wie es die Aufgabenstellung zulässt. Des weiteren sollte dieser
Modus so gestaltet sein, dass die Bearbeitung der verschiedenen Objekte auch über
Shortcuts möglich ist.
weitere Verbesserungen
Die Vorgehensweise beim Anlegen von Medikationen und Medikationskennungen eines
Medikationskopfes, beziehungsweise der entsprechenden Objekte eines Intervallkopfes im
Wizard-Modus, sollte nochmals überdacht werden. Im neu gestalteten Bedienkonzept ist
dies bisher durch eine geschachtelte Schleife realisiert. Bei der Evaluierung durch einen
Mitarbeiter führte dies aber zu Verwirrung.
Des weiteren sollte die Selbstbeschreibungsfähigkeit des Systems noch derart gesteigert
werden, dass ablaufende Prozesse visualisiert werden. Eine entsprechende Rückmeldung
sollte dabei nicht nur anzeigen, dass das System „beschäftigt“ ist, sondern kann durchaus
dazu genutzt werden den laufenden Prozess visuell zu beschreiben.
Da während des konzeptuellen Entwurfs zwei Konzepte für den Editier-Modus angedacht
wurden, ist es zudem sinnvoll, das noch nicht umgesetzte Konzept zusätzlich anhand eines
Prototypen zu realisieren. Die Vorteile beider Konzepte könnten später eventuell
zusammengeführt werden.
Schlussbemerkung
Im Verlauf der Implementierung der Prototypen tauchte die Frage auf, wann das neue
Konzept eingesetzt werden kann. Grundsätzlich sollten Prototypen nicht vorzeitig zum
Produkt gemacht werden. Vielmehr ist hier zu empfehlen die Methodik des Usability
Engineering weiterzuverfolgen, und sich nicht mit ersten Resultaten zufrieden zu geben. Da
die meisten Benutzerschnittstellen heutzutage ohne entsprechende Analyse der Benutzer
und auch ohne Evaluierung durch die Benutzer erstellt werden, besteht die Gefahr dieser
„Strategie“ wieder zu verfallen, stellt sie doch einen wesentlich geringeren Aufwand dar. Will
man aber eine moderne Benutzerschnittstelle schaffen, die bedienbar und
benutzerfreundlich ist und deren Benutzung womöglich noch Freude macht, sollte der
Mehraufwand, den das Usability Engineering mit sich bringt, kein Problem darstellen.
A
Literaturverzeichnis
[Welie01]
Martijn van Welie: Task-based User Interface Design, Dissertation an der
Dutch Graduate School for Information and Knowledge Systems, 2001
[Ferré01]
Xavier Ferré, Natalia Juristo, Helmut Windl, Larry Constantine: Usability
Basics for Software Developers,
http://www.computer.org/software/so2001/pdf/s1022.pdf, 2001
[Preim99]
Bernhard Preim: Entwicklung interaktiver Systeme, Springer Verlag, 1999
[Wessel98]
Ivo Wessel: GUI-Design – Richtlinien zur Gestaltung ergonomischer
Windows-Applikationen, Hanser Verlag, 1998
[inxight02]
Inxight Software Inc. ,Santa Clara, California, www.inxight.com, 2002
[Maybury01]
Mark T. Maybury: Human Computer Interaction, The MITRE Corporation,
2001
[Hudson97]
Scott Hudson & Ian Smith: Toolkit subArctic, GWU Center Georgia Tech,
http://www.cc.gatech.edu/gvu/ui/sub_arctic/sub_arctic/doc/demos.html, 1997
[IBM]
IBM Corporation, Austin, Texas, USA,
http://www.research.att.com/conf/hfweb/proceedings/lisle/
[Sun01]
Sun Microsystems Inc.: Swing Sightings,
http://java.sun.com/products/jfc/tsc/sightings/S03.html, 2001
[HCIL00]
Human Computer Interaction Lab, University of Maryland,
http://www.cs.umd.edu/hcil/, 2000
[Micros00]
Microsoft Corporation, Research, User Interfaces,
http://research.microsoft.com/ui/TaskGallery/index.htm, 2000
[Geisler98]
Gary Geisler: Making Information More Accessible: A Survey of Information
Visualization, University of North Carolina at Chapel Hill,
http://www.ils.unc.edu/~geisg/info/infovis/paper.html, 1998
[Holzin01]
Andreas Holzinger: Basiswissen Multimedia, Band3: Design, Vogel
Buchverlag, 2001
[TUD00]
Technische Universität Darmstadt - Graphische Interaktive Systeme,
http://www.inigraphics.net/publications/topics/2000/SA_2000/topicsSA2000.p
df, 2000
[Schuka95]
Ernst Günther Schukat Talamazzini: Automatische Spracherkennung, Vieweg
Verlag, 1995
Literaturverzeichnis
108
[IBMVia01]
IBM, Via Voice – Spracherkennungssystem, http://www.viavoice.de, 2001
[Hameri00]
Stefan W. Hamerich: Strategien für Dialogsegmente in natürlichsprachlichen
Anwendungen, Diplomarbeit an der Universität Hamburg, http://natswww.informatik.uni-hamburg.de/sada/ps/stefan-hamerich-da.pdf, 2000
[BodyTa00]
Projekt BodyTalk, Universität Dortmund, http://ls7-www.cs.unidortmund.de/bodytalk/, 2000
[Hassen01]
Marc Hassenzahl, Andreas Beu, Michael Burmester, User Interface Design
GmbH: Engineering Joy, http://www.tudarmstadt.de/fb/fb3/psy/soz/veroeffentlichungen_mh/Engineering_joy.pdf,
2001
[Jakob01]
Tanja Jakob-Sula: Wahrnehmungspsychologisch begründete Konzeption
einer Website für Praktiker der Sozialen Arbeit, Diplomarbeit an der
Fachhochschule München, www.willstedrueberreden.de, 2001
[Crüger00]
Ingrid Crüger: Farbentheorie und Farbgestaltung, Ausarbeitung am
Fraunhofer Institut für Integrierte Publikations- und Informationssysteme,
2000
[Schlie99]
Jürgen Schlierf, Rudolf Weber: Programmieren mit Swing, Verlag Hanser,
1999
[PD01a]
Propack Data GmbH: Schulungsunterlagen für CTM
[Mekel01]
Hans-G. Mekelburg: Ergonomie und das WWW,
http://home.nordwest.net/hgm/ergo/index.html, 2001
[Shneid99]
Ben Shneiderman: 8 golden Rules, Department of Computer Science at
University of Maryland, http://www.csc.calpoly.edu/~fkurfess/Courses/COMP675/W00/Slides/Golden-Rules.html, 1999
[Oester98]
Bernd Oestereich: Objekt-orientierte Softwareentwicklung, Verlag
Oldenbourg, 1998
[IBM01]
IBM developerWorks: Crafting a wizard, http://www106.ibm.com/developerworks/library/us-wizard/?article=wir, 2001

Bedienkonzepte für ein zukünftiges PMX.

Transcrição

Documentos relacionados

Strokes Arabisch Serie 20

WIN-911®

¨Ubungsblatt 6 Aufgabe 1: Codebreaker (6 Punkte, B)

AGB herunterladen als PDF-Datei

Phishing und Pharming: Diebstahl im Netz

Benutzerordnung - Albertus Magnus Gymnasium Friesoythe

IServ-Vordruck - der Realschule Georg-Eckert

Nutzungsvertrag IServ zum

Office 365 Admin Center – First Steps - RZ

ALLGEMEINE GESCHÄFTSBEDINGUNGEN