Konzeption und Entwicklung eines anwendungskontextorientierten

Transcrição

Universität Paderborn
Fakultät für Elektrotechnik, Informatik und Mathematik
Arbeitsgruppe Mensch-Computer-Interaktion und Softwaretechnologie
Konzeption und Entwicklung eines
anwendungskontextorientierten
Help-Desk-Systems
Prüfender
Hochschulprofessor:
Verfasser:
Datum:
Prof. Dr. Gerd Szwillus
Marco Falkenberg
[email protected]
Paderborn, 12. Mai 2010
Eidesstattliche Erklärung
Ich versichere, dass ich die namentlich kenntliche gemachten Teile der
Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der genannten Quellen angefertigt habe, und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und
von dieser als Teil einer Prüfungsleistung angenommen wurde. Alle
Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind
als solche gekennzeichnet.
Paderborn, den 12. Mai 2010, Marco Falkenberg
Inhalt
Inhalt .......................................................................................................... I
Abbildungsverzeichnis ........................................................................ III
1
Einleitung ..........................................................................................1
1.1 Ausgangssituation und Motivation ..............................................1
1.2 Zielsetzung und Aufbau der Arbeit ..............................................2
1.3 Begriffsabgrenzung .......................................................................3
2
Hilfesysteme ......................................................................................5
2.1 Online-Dokumentation .................................................................7
2.1.1 Assistenzsysteme .................................................................8
2.1.2 Hilfefenster ..........................................................................9
2.2 Benutzersicht .............................................................................. 11
2.2.1 Methoden der Problemlösung ............................................ 12
2.2.2 Paradox des aktiven Benutzers ......................................... 13
2.2.3 Probleme der Benutzbarkeit von Hilfesystemen .............. 13
2.2.4 Probleme beim Zugriff auf Hilfesysteme .......................... 15
2.3 Kontextsensitiver Zugriff............................................................ 19
2.3.1 Definition des Kontextbegriffs ........................................... 19
2.3.2 Bedeutung von Kontext ..................................................... 20
2.3.3 Kontextinformationen in Hilfesystemen ........................... 23
2.4 Zusammenfassung und Optimierungspotentiale ....................... 25
3
Konzept ............................................................................................29
3.1 Zielsetzung .................................................................................. 29
3.2 Prinzip ......................................................................................... 31
I
II
INHALT
3.3 Modellierung der Hilfeinformationen ........................................ 32
3.4 Vorstellung der Komponenten ................................................... 34
3.4.1 Kontextprovider ................................................................. 35
3.4.2 Anwendungskontext .......................................................... 38
3.4.3 Symptom ............................................................................ 39
3.4.4 Problem .............................................................................. 40
3.4.5 Lösung................................................................................ 41
3.4.6 Hilfeartikel ........................................................................ 42
3.5 Flexibilität durch Textvariablen ................................................ 42
3.6 Ermittlung der Hilfeinformationen............................................ 43
3.7 Kritische Würdigung .................................................................. 44
4
Realisierung ................................................................................... 47
4.1 Rahmenbedingungen .................................................................. 47
4.1.1 Diomex Framework Components ...................................... 47
4.1.2 Microsoft .NET Framework............................................... 50
4.2 Integrationsaufgaben ................................................................. 51
4.3 Datenmodell................................................................................ 52
4.4 Pflege der Hilfeinformationen .................................................... 55
4.5 Kontextprovider .......................................................................... 62
4.6 Ermittlung der Hilfeinformationen............................................ 64
4.7 Format der Hilfeartikel .............................................................. 65
4.8 Aufruf der Hilfefunktion ............................................................ 68
5
Bewertung ....................................................................................... 71
5.1 Anwendungsbeispiele ................................................................. 71
5.2 Beurteilung der Ergebnisse........................................................ 75
6
Zusammenfassung und Ausblick ................................................ 79
6.1 Zusammenfassung ...................................................................... 79
6.2 Ausblick ...................................................................................... 80
Anhang..................................................................................................... 83
A.
Informationen zur beigelegten CD.......................................... 83
Literaturverzeichnis ............................................................................. 85
Abbildungsverzeichnis
Abbildung 2.1: Grundlegende Bestandteile eines Hilfesystems (eigene
Abbildung) ...................................................................................................6
Abbildung 2.2: Kategorisierung von Online-Informationen nach
Thiemann (Thiemann, 2008).......................................................................8
Abbildung 2.3: Screenshot des Hilfefensters von Microsoft Office 2007 .. 10
Abbildung 2.4: Screenshots der Suchfunktionen als zentraler Zugang zu
Online-Dokumentationen (oben: integrierte Hilfe von Microsoft Windows
Vista; unten: Hilfe von Mozilla Firefox) ................................................... 17
Abbildung 2.5: Screenshot der Kaufempfehlungen bei „amazon.de“ ....... 21
Abbildung 2.6: Screenshots der angepassten Hilfeartikel der OnlineHilfe von Firefox (oben: Windows; unten: Mac OS) ................................. 22
Abbildung 2.7: Zusätzliche Kontextinformationen in Fragen von Laien an
Experten während eines Problemlösungsprozesses (Pilkington, 1992) ... 24
Abbildung 3.1:Dienste zur Verwaltung und Abfrage von
Hilfeinformationen vom „Diomex Framework Services Server“ (eigene
Abbildung) ................................................................................................. 30
Abbildung 3.2: Prinzip des „Diomex Help-Desk Systems“ (eigene
Darstellung) ............................................................................................... 32
Abbildung 3.3: Modellierung der Hilfeinformationen im „Diomex HelpDesk System“ (eigene Abbildung) ............................................................. 34
Abbildung 3.4: Ausschnitt der Datenstruktur für Kontextinformationen
vom Typ „User Interface“ (eigene Abbildung) .......................................... 36
Abbildung 3.5: Zusammenhang zwischen Problem, Lösungen,
Lösungsvarianten und Lösungsschritten (eigene Abbildung) ................. 42
Abbildung 4.1: Screenshot der Oberfläche des „Diomex Framework
Service Management Studios“ .................................................................. 49
III
IV
ABBILDUNGSVERZEICHNIS
Abbildung 4.2: Darstellung der Komponenten der „Diomex Framework
Components“ (eigene Abbildung).............................................................. 50
Abbildung 4.3: UML-Diagramm der Hilfeinformationen (eigene
Abbildung) ................................................................................................. 54
Abbildung 4.4: Datenbankdiagramm der Hilfeinformationen (eigene
Abbildung) ................................................................................................. 55
Abbildung 4.5: Objekt-Explorers des „Management Studios“ mit
Integration der Help-Desk-Elemente ....................................................... 56
Abbildung 4.6: Pflegeoberfläche für Anwendungskontexte ..................... 57
Abbildung 4.7: Pflegeoberfläche für Hilfeartikel ..................................... 58
Abbildung 4.8: Pflegeoberfläche für Probleme und Lösungen ................. 59
Abbildung 4.9: Bearbeitung von Textparametern ................................... 60
Abbildung 4.10: Pflegeoberfläche für Symptome ..................................... 61
Abbildung 4.11: Verknüpfung von Problemen zu Symptomen mit
Definition eines Textparameterwertes ..................................................... 62
Abbildung 4.12: UML-Klassendiagramm der
Kontextproviderkomponenten .................................................................. 64
Abbildung 4.13: Word-Integration für die Pflege der Hilfe- und
Lösungstexte ............................................................................................. 66
Abbildung 4.14: Anzeige eines Symptoms und des Problems samt
Lösungen im Hilfefenster des DHS‘ (erstes Problem angezeigt) ............. 67
Abbildung 4.15: Anzeige eines Symptoms mit mehreren Problemen samt
Lösung im Hilfefenster des DHS‘ (zweites Problem angezeigt) ............... 68
Abbildung 5.1: „Formeleditor“-Dialog ...................................................... 72
Abbildung 5.2: Hilfe zum „Formeleditor“-Dialog ..................................... 73
Abbildung 5.3: Fehlerreport-Dialog mit Möglichkeit zum Aufruf einer
Hilfe ........................................................................................................... 74
Kapitel 1
Einleitung
1.1 Ausgangssituation und Motivation
Die steigende Leistungsfähigkeit der Computer-Hardware und der Einsatz von modernen Softwarekomponenten eröffnen den Benutzern zunehmende Interaktionsmöglichkeiten. Eine solche Entwicklung ist allerdings nur dann vorteilig zu betrachten, wenn gerade Laien den damit
verbundenen Anstieg an Komplexität handhaben können und bei der
Benutzung des Systems optimal geführt werden. Standardisierung und
die Weiterentwicklung von Benutzerschnittstellen führen zwar zu einer
vereinfachten Handhabe, doch bleibt der Umgang mit diesen für viele
Benutzer immer noch eine Herausforderung.
Grundlegende Merkmale einer effektiven Unterstützung des Benutzers sind eine qualitativ hochwertige Wissensdatenbank und eine geeignete Schnittstelle zu dieser. Die Schnittstelle muss dem Benutzer die
Möglichkeit geben, die richtigen Informationen zum richtigen Zeitpunkt
abrufen zu können oder diese selbstständig bereitstellen (Dey, 2001).
Benutzer schätzen besonders den Aspekt der effektiven Zugänglichkeit
zu relevanten und geeigneten Informationen bei der Unterstützung von
Anwendungsproblemen. Allerdings wird gerade diese Eigenschaft bei
Hilfesystemen laut einer Studie von Novick und Ward (Novick & Ward,
What Users Say They Want in Documentation, 2006) mit am häufigsten
bemängelt.
Die gängigen Hilfesysteme und Methoden der Softwaredokumentation
sind nicht in der Lage den Benutzer adäquat mit der notwendigen Hilfe
zu versorgen (Randall, 1998). Durch die daraus resultierende Frustration
der Hilfesuchenden sinkt das Vertrauen in Softwaredokumentationen
1
2
KAPITEL 1 EINLEITUNG
sogar soweit, dass der Gebrauch faktisch gemieden wird (Novick & Ward,
Why Don’t People Read the Manual?, 2006). Stattdessen wenden sich
Anwender mit Vorliebe an die Hotlines der Kundendienste und Service
Center, von denen ca. 865.000 weltweit 10 Mio. Mitarbeiter beschäftigen
(Li, Vukovi, Pingali, & Lee, 2009). Diese Zahlen verdeutlichen auch das
finanzielle Einsparungspotential eines assistierenden Hilfesystems und
die daraus folgenden Vorteile für die Unternehmen.
Der Trend einer zunehmenden Anzahl von Supportanfragen im Zusammenhang mit einem zunehmenden Funktionsumfang der Software
zeichnet sich auch bei der Firma Diomex, mit derer Kooperation diese
Arbeit entstanden ist, ab. Die Firma Diomex Software GmbH & Co. KG
konzentriert sich vorrangig auf zwei Kernbereiche: Zum einen auf die
Entwicklung neuer, innovativer und nachhaltiger Lösungen für den Austausch von Stamm- und Bewegungsdaten für hoch variantenreiche Artikel und zum anderen auf die zukunftssichere Modernisierung von Hostanwendungen, die für viele Unternehmen besondere Brisanz und hohe
Aktualität hat. Insgesamt arbeiten täglich ca. 3000 Benutzer mit Anwendungen von Diomex.
Aufgrund der Tatsache, dass ein nicht unerheblicher Anteil der Supportanfragen auch mit Hilfe der Softwaredokumentation hätte beantwortet werden können, wurde die Entscheidung getroffen, ein modernes
Hilfesystem zu entwerfen und im Unternehmen zu etablieren. Eine Senkung der Supportanfragen, gerade im Bezug auf die zunehmende Anzahl
an Softwareinstallationen, und eine positive Resonanz vom Benutzer
sind die hauptsächlichen Erwartungen, die an das neue Hilfesystem gestellt werden.
1.2 Zielsetzung und Aufbau der Arbeit
Das Ziel dieser Arbeit ist die Entwicklung eines Hilfesystems, welches
insbesondere der oben erwähnten Diskrepanz entgegenwirkt, indem die
Effektivität des Zugriffs auf die Wissensdatenbank unter Einbeziehung
des Zustands der Anwendung und des Kontextes, in dem die Anwendung
ausgeführt wird, gesteigert wird.
Die Schritte zu dieser Zielerreichung, sowie die daraus resultierenden
Ergebnisse werden in dieser Arbeit wie folgt strukturiert dargelegt. Nach
der Einleitung soll im zweiten Kapitel das nötige Grundlagenwissen zum
Thema „Hilfesysteme“ vermittelt werden. Hierbei werden zunächst die
bekannten Methoden zur Online-Dokumentation vorgestellt, worauf die-
1.3 BEGRIFFSABGRENZUNG
3
se in Bezug zu den Anforderungen der Benutzer kritisch betrachtet werden. Weiterhin wird insbesondere der kontextsensitive Zugriff auf Hilfesysteme vertieft, da diese Art von Zugriff als Ansatz für die Konzeption
des in dieser Arbeit vorgestellten Hilfesystems dienen soll. Die Konzeption wird im dritten Kapitel veranschaulicht, wobei auf die Ziele, den
Entwurf und eine ausführliche kritische Betrachtung eingegangen wird.
Im Kapitel 4 folgt schließlich eine Darstellung der technischen Realisierung des zuvor erwähnten Konzeptes. Eine Analyse von Anwendungsbeispielen zum Zwecke der Beurteilung der erzielten Ergebnisse ist Gegenstand des Kapitels 5. Im Kapitel 6 wird schließlich der Inhalt dieser Arbeit zusammengefasst und ein Ausblick auf eine mögliche Weiterentwicklung gegeben.
1.3 Begriffsabgrenzung
Einige Begrifflichkeiten werden in dieser Arbeit besonders häufig verwendet – teilweise auch schon vor deren Definition. Um bereits an dieser
Stelle eine Vorstellung über deren Bedeutung zu vermitteln, werden diese Begriffe an dieser Stelle kurz vorgestellt.
Kontext
Unter dem Begriff „Kontext“ werden in dieser Arbeit die Parameter, die
eine Softwareanwendung umgeben, verstanden. Der Kontext beschreibt
das Umfeld und die Situation die zu einem bestimmten Zeitpunkt im
Bezug zu einer Anwendung vorliegen. Häufig wird auch der sinngleiche
Begriff „Anwendungskontext“ verwendet. Das Adjektiv „kontextsensitiv“
ist gleichbedeutend mit „den Kontext berücksichtigend“. Eine detailliertere Beschreibung des Kontextbegriffes ist im Abschnitt 2.3.1 zu finden.
Help-Desk
Der „Help-Desk“ ist eine Institution oder ein Dienst der Benutzern mit
technischen Problemen eine zentrale Anlaufstelle zu deren Unterstützung bietet. Die Unterstützung erfolgt dabei durch einen oder mehrere
Experten über unterschiedliche Kommunikationswege (Telefon, E-Mail,
Kontaktformulare, usw.). Das Ziel eines Help-Desks ist die Zufriedenstellung des Kunden durch die effektive und effiziente Lösung der Problemen und Fragen des Benutzers. Zur Erreichung dieses Ziels werden
wohldefinierte Prozesse, Werkzeuge und Strategien eingesetzt (Beisse,
2009, S. 197 ff).
4
KAPITEL 1 EINLEITUNG
In dieser Arbeit grenzt sich der Begriff „Help-Desk“ in folgender Weise
von der in der Literatur üblichen Definition ab. Die Unterstützung des
Benutzers erfolgt im Gegensatz zum üblichen Help-Desk nicht direkt
durch einen Experten sondern vielmehr durch eine automatisierte Bereitstellung von Hilfeinformationen. Der Beitrag des Experten erfolgt
hierbei nicht zum Zeitpunkt der Anfrage, sondern vielmehr während der
Erstellung der Hilfeinformationen. Der Experte legt im Vorfeld, oder
nach dem Auftreten eines Referenzfalles, eine Problemsituation mit den
entsprechenden Lösungen fest. Bei der Definition der Problemsituation
orientiert er sich am Anwendungskontext. Aufgrund der leicht abgewandelten Bedeutung wird an dieser Stelle auf die beschrieben Abgrenzung
hingewiesen.
Kapitel 2
Hilfesysteme
Wie bereits in der Zielsetzung erwähnt, wird in dieser Arbeit die Entwicklung eines anwendungskontextorientiertes Help-Desk-Systems verfolgt. Bevor das Konzept und die Entwicklung dieses speziellen Hilfesystems beschrieben werden, soll dieses Kapitel dem Leser die Grundlagen
aus dem Bereich der Hilfesysteme vermitteln, sowie die Sicht des Benutzers beim Umgang mit diesen Hilfesystemen vertiefen. Der Begriff „Hilfesystem“ wird in dieser Arbeit wie folgt definiert:
Ein Hilfesystem ist eine Komponente die den Benutzer in Problemsituationen oder beim Erlernen neuer Funktionalitäten von Softwareprodukten unterstützt. Die wesentlichen Bestandteile eines Hilfesystems sind zum einen die Datenbasis und zum anderen die entsprechende Schnittstelle zu dieser. In der Datenbasis sind die eigentlichen
Hilfeinformationen, wie z.B. Anleitungen zur Problemlösung oder zu bestimmten Funktionen gespeichert. Über die Schnittstelle werden dem
Benutzer die Hilfeinformationen aktiv oder passiv, d.h. selbstständig
oder auf Anfrage, bereitgestellt. Die Ermittlung der Informationen kann
kontextsensitiv oder kontextfrei erfolgen – d.h. der Kontext zum Zeitpunkt der Anfrage wird beim Informationsabruf einbezogen oder nicht.
5
6
KAPITEL 2 HILFESYSTEME
Hilfesystem
Abbildung 2.1: Grundlegende Bestandteile eines Hilfesystems
(eigene Abbildung)
Hilfesysteme werden in unterschiedlich komplexen Ausprägungen in
den meisten Softwareprodukten eingesetzt. Ein gutes Hilfesystem unterstützt den Benutzer beim Umgang mit der Software und bietet ihm besonders in Problemsituationen die nötige Hilfe. Damit nimmt das Hilfesystem direkten Einfluss auf die Zufriedenheit des Benutzers, die in der
Norm EN ISO 9241-11 als Teil der Anforderungen an die Gebrauchstauglichkeit von Software genannt wird. Ökonomische Vorteile resultieren laut Desmarais et al. aus einer gesteigerten Produktivität des Benutzers, die nicht nur durch kürzere Lernphasen sondern auch durch die
autonome Aneignung von neuem Wissen erzielt wird. Zusätzlich kann
die Arbeitsqualität durch die Vermittlung von standardisierten Abläufen
erhöht werden (Desmarais, Leclair, Fiset, & Talbi, 1997).
Im ersten Abschnitt dieses Kapitels (Abschnitt 2.1) wird zunächst die
„Online-Dokumentation“ als einer der bekanntesten Vertreter von Hilfesystemen vorgestellt. Hier werden nach einer Begriffsklärung die einzelnen Arten von Assistenzsystemen vorgestellt. Danach werden im Abschnitt „2.2 Benutzersicht“ die Methoden und Probleme des Benutzers
beim Umgang mit einem Hilfesystem vorgestellt. Im Abschnitt „2.3 Kontextsensitiver Zugriff“ wird der Einfluss von Kontextinformationen auf
die Interaktion mit dem Hilfesystem beschrieben. Schließlich werden im
Abschnitt „2.4 Zusammenfassung und Optimierungspotentiale“ die vorgestellten Methoden kritisch betrachtet um den Entwurf eines neuen
Konzeptes zu motivieren.
2.1 ONLINE-DOKUMENTATION
7
2.1 Online-Dokumentation
Ein in der Praxis weit verbreitetes Instrument zur Benutzerunterstützung ist die Online-Dokumentation. Sie kommt in den unterschiedlichsten Varianten in nahezu jeder Software zum Einsatz. Im folgenden Abschnitt wird die Definition und Kategorisierung der „Online-Dokumentation“ nach Thiemann vorgestellt.
„Die Online-Dokumentation umfasst alle am Bildschirm anzeigbaren
Informationen, die ein Produkt dokumentieren und zu seinem Gebrauch
anleiten.“ Die Online-Dokumentation hebt sich zur üblichen Dokumentation von Softwareprodukten im Wesentlichen durch das Merkmal ab,
dass sie am Bildschirm angezeigt wird und während der Programmbenutzung aufgerufen werden kann. Bei dieser und den folgenden Definitionen ist anzumerken, dass der Begriff „Online“ in diesem Zusammenhang nicht die weit verbreitete Bedeutung der Verbindung zum Internet
darstellt, und eigentlich eher durch „On-Screen“ zu ersetzen wäre
(Thiemann, 2008, S. 4).
Die Online-Dokumentation gehört neben der Online-Präsentation zur
Gruppe der Online-Informationen. Online-Informationen sind Informationen die in Dateiform vorhanden sind und am Bildschirm angezeigt werden können. Die Online-Dokumentation gliedert sich in die folgenden
drei Kategorien (Thiemann, 2008, S. 5 ff):
1. Assistenzsysteme
Assistenzsysteme unterstützen den Benutzer unmittelbar während
der Interaktion mit der Oberfläche. Dies geschieht zum einen durch
direkt sichtbare Informationen, wie z.B. Beschriftungen für Menüs
oder Buttons (Primärassistenz) und zum anderen durch Informationen, die erst durch eine Benutzeraktion angezeigt werden, wie z.B.
Tooltips (Sekundärassistenz). Thiemann führt weiterhin im Rahmen
der Assistenzsysteme die „Online-Hilfe“ ein, grenzt diese aber nicht
weiter ab. Deshalb wird in dieser Arbeit an Stelle der „Online-Hilfe“
weiterhin der Begriff „Assistenzsystem“ verwendet.
2. Lernprogramme
Mit Hilfe von Lernprogrammen kann der Benutzer Funktionen und
Konzepte der Software durch benutzergeführte Lektionen erlernen.
Beispiele hierfür sind Tutorials oder Lernvideos.
8
3. Bedienungsanleitungen am Bildschirm
Die Bedienungsanleitung am Bildschirm ist die für den Bildschirm
aufbereitete Version der gedruckten Dokumentation. Häufig wird die
elektronische Umsetzung noch um Hypertextverlinkungen und eine
Volltextsuche erweitert. Die Bedienungsanleitung ist unabhängig
vom Produkt zugänglich (z.B. auf CD-ROM oder als Download) und
stellt dem Nutzer frei, welche Passagen und Kapitel er ausdrucken
möchte.
In der nachfolgenden Abbildung wird die Gliederung des Begriffs „Online Information“ noch einmal schematisch dargestellt.
Online-Information
Online-Dokumentation
Assistenzsystem
Online-Präsentation
Lernprogramm
Bedienungsanleitung
Online-Hilfe
Abbildung 2.2: Kategorisierung von Online-Informationen nach Thiemann (Thiemann, 2008)
2.1.1 Assistenzsysteme
Assistenzsysteme sind besonders eng mit der Bedienoberfläche verzahnte Variante der Benutzerunterstützung. Sie wird deshalb oft als Teil
der Software gesehen und kann mit Hilfe der meisten Entwicklungsumgebungen umgesetzt und gepflegt werden. Je nach Entwicklungsumgebung können Texte und somit auch Hilfetexte in RessourcenDateien ausgelagert werden, um Sie unabhängig von der Programmlogik
und in unterschiedlichen Sprachen ausliefern zu können. Ein Assistenzsystem bietet dem Benutzer in erster Linie punktuelle Unterstützung –
soll ihm aber trotzdem die Möglichkeit geben, bereits Erlerntes in gewissem Maße zu vertiefen (Thiemann, 2008).
2.1 ONLINE-DOKUMENTATION
9
Die folgenden Arten von Assistenzsystemen werden in der Praxis häufig eingesetzt (Thiemann, 2008, S. 11 ff):
 Beschriftungen für z.B. Titelzeilen, Schaltflächen, Felder und
sonstige Bedienelemente
 Tooltips / Bubble Help
 Meldungen wie Statusmeldungen, Rückmeldungen oder Fehlermeldungen
 Assistenten und Wizards
 Kontextsensitive Hilfen, wie z.B. Bubble Help, eingebettete Hilfebereiche, Bedienelemente mit Hilfe-Schaltflächen, Direkthilfen
 Kontextfreie Hilfen, wie z.B. eine eigenständige Hilfe-Fenster
das über das Hilfe-Menü geöffnet wird
2.1.2 Hilfefenster
Im Rahmen der Assistenzsysteme soll in diesem Abschnitt das Hilfefenster genauer vorgestellt werden, da bei Realisierung ein ähnliches Konzept zur Anzeige der Hilfeartikel eingesetzt wird (siehe Abschnitt 4.6).
Ein Hilfefenster ist eine Komponente, die bestimmte Hilfeformate darstellen kann und dem Benutzer Navigationshilfen, wie z.B. Inhaltsverzeichnisse und Suchmöglichkeiten bietet. Die meisten Hilfefenster sind
in drei Bereiche aufgeteilt, wie auch das Hilfefenster von Microsoft Office
2007 (siehe Abbildung 2.3). Im oberen Bereich findet man eine Menüleiste mit Navigationselementen und Funktionen, wie z.B. die Druckfunktion. Oben befindet sich auch häufig die Textbox zur Sucheingabe. Links
ist der Navigationsbereich der die Hilfethemen nach einem bestimmten
Organisationsschema gliedert. Die eingesetzten Organisationsschemata
entsprechen denen eines „normalen“ Buches, wie z.B. Inhaltsverzeichnisse, Stichwortverzeichnisse oder Glossare. Rechts befindet sich der Lesebereich, indem die Inhalte dargestellt werden.
In der Navigation und im Text kommen häufig Hypertextverlinkungen zum Einsatz. Sie ermöglichen das direkte Navigieren zu einer Seite
bzw. einem Abschnitt nachdem der entsprechende Hyperlink ausgewählt
wurde. Weitere Instrumente zur Unterstützung der Navigation, wie z.B.
Lesezeichen oder Verlaufshistorien, sind entscheidende Vorteile gegenüber der gedruckten Dokumentation.
Einige Hilfefenster lassen sich auch über eine Programmierschnittstelle ansteuern, so dass sie direkt über die Programmoberfläche geöffnet
10
werden können. Bei dem Aufruf kann meist ein Sprungziel zu einer bestimmten Seite oder einem bestimmten Thema mitgegeben werden. So
kann z.B. aus einem Dialog zum Drucken das Hilfefenster mit der entsprechenden Hilfe zum Drucken angezeigt werden. Dies ist in gewisser
Weise ein kontextsensitives Verhalten doch sind Hilfefenster vom Konzept her eher kontextfrei.
Abbildung 2.3: Screenshot des Hilfefensters von Microsoft Office 2007
Hilfefenster können Teil der Anwendung oder eigenständige Programme sein. In der Regel verfügt aber auch das Betriebssystem über
eine standardisierte Hilfefenster-Komponente. Mit Windows 3.0 führte
Microsoft erstmalig die im Betriebssystem integrierte HilfefensterKomponente namens „Winhelp“ ein. Seit Windows 98 ist der Nachfolger
„HTML-Help“ im Einsatz, der Inhalte in Form von Paketen aus HTMLSeiten speichert. „Winhelp“ und „HTML-Help“ werden von Microsoft
nicht mehr weiterentwickelt. Die aktuellste Hilfefenster-Komponente
von Microsoft, die „Assistance Platform Help“ (AP Help oder Vista Help)
ist seit Windows Vista verfügbar. Hilfetexte werden bei der „AP Help“ in
einer speziellen Auszeichnungssprache namens „Microsoft Assistance
Markup Language“ (MAML) gespeichert. Dokumente und deren einzel-
2.2 BENUTZERSICHT
11
nen Elemente können so in einer strukturierten Form abgelegt werden
und infolgedessen wiederverwendbar und kontextbezogen zu einer dynamischen Ausgabe transformiert werden (Microsoft Assistance Markup
Language, 2009). Allerdings gibt es derzeit leider (noch) keine Programme, SDK’s oder API’s, die es ermöglichen Hilfen in diesem Format zu
erzeugen oder anzusteuern. Lediglich OEM’s, Systemherstellern und
Unternehmenskunden ist es laut der offiziellen Entwicklerplattform
„MSDN“ von Microsoft möglich das entsprechende Hilfefenster für die
„Assistance Platform Help“ anzupassen. (Application Compatibility: Help
Engine Support, 2010)
Weitere bekannte Hilfefenster-Systeme sind „AppleHelp“ oder „JavaHelp“. Die „AppleHelp“ ist das Pendant von Apple zu Microsofts „HTMLHelp“. „JavaHelp“ ist ein Hilfesystem, welches in Anwendungen, die auf
der Java-Plattform basieren, eingesetzt werden kann.
2.2 Benutzersicht
Nachdem die Möglichkeiten der Benutzerunterstützung durch OnlineDokumentationen vorgestellt wurden, soll in diesem Abschnitt der
Schwerpunkt auf die Benutzerinteraktion mit diesen Systemen gelegt
werden.
Viele Studien und Untersuchungen haben bestätigt, dass Anwender
beim Umgang mit einem Hilfesystem mit Problemen konfrontiert werden. Benutzer die Unterstützung von einem Hilfesystem benötigen,
möchten eine prompte Lösung, die passend zu ihm / ihr und zu seiner /
ihrer Situation ist (Vouligny & Rober, 2005). In der Realität stoßen die
Benutzer jedoch auf zusätzliche Probleme (siehe Abschnitt 2.2.3 und
2.2.4), was eine geringe Akzeptanz gegenwärtiger Hilfesysteme zur Folge
hat. Welche Ursachen zu diesem Umstand führen und was der Anwender
wirklich von einer guten Hilfe verlangt, soll in diesem Abschnitt beschrieben werden.
Einleitend wird an dieser Stelle noch ein Eintrag aus dem deutschsprachigen Support-Chat zum Internet-Browser „Firefox“ zitiert. Die
Äußerungen des Verfassers transportieren treffend die Situation eines
hilfesuchenden Benutzers.
12
<gargamel>: bin neu in firefox , wenn was bei mir nicht
so geht werde ich schnell hippelich, danke für die TIps
ihr seid ja freaks und wisst wo man suchen muß vielen
dank erstmal, wenn einer noch einen Tip hat bleibe noch
eine Weile im chat
(Firefox-Support-Chat, 2010)
2.2.1 Methoden der Problemlösung
Eine grundsätzliche Erkenntnis der unternommenen Forschungen ist,
dass Online-Dokumentationen oder übliche Handbücher nicht die erste
Wahl des hilfesuchenden Anwenders sind. Die präferierte Methode zur
Problemlösung ist immer noch die direkte Kommunikation mit einem
Menschen, ob z.B. aus dem Kollegen- bzw. Freundeskreis oder dem Mitarbeiter des Support Centers. Auch Internetplattformen, Chaträume und
Foren, die sich teilweise thematisch auf eine spezielle Software beziehen,
werden häufiger konsultiert als die eigentliche Hilfe, erfordern allerdings
meist eine umfangreiche Recherche. Dieses Verhalten wurde in einer
empirischen Studie von Novick und Ward (Novick & Ward, Why Don’t
People Read the Manual?, 2006) untersucht und belegt. In dieser Studie
wurden 25 Teilnehmer tiefgehend zu ihren alltäglichen Erfahrungen mit
den von ihnen hauptsächlich genutzten Computerprogrammen befragt.
Die Studie besagt weiterhin, dass Anwender den Aufwand eine Lösung
in einer Dokumentation zu finden genauso hoch einschätzen, wie das
Problem selber mittels „Trial and Error“1 zu lösen.
Die verwendeten Problemlösungsstrategien und Vorgehensweisen bei
der Verwendung einer Hilfe hängen auch stark vom Typ des Nutzers ab.
Thiemann erwähnt den „disziplinierten Nutzer“, den „undisziplinierten
Nutzer“, den „Fachmann“ und den „Praktiker“ (Thiemann, 2008, S. 10).
Der am weitesten verbreitete Typ ist der „undisziplinierte Benutzer“. Er
steigt ohne Vorbereitung und mit der Absicht möglichst schnell sein Ziel
zu erreichen in die Problemlösung ein. Er springt oft zwischen den Hilfethemen und liest selektiv, wobei er sich erhofft, möglichst viele Informationen in kurzer Zeit aufzunehmen. Dieser Benutzertyp wird auch weniger negativ als der „aktive Benutzer“ bezeichnet (siehe Abschnitt 2.2.2).
Der „disziplinierte Benutzer“ ist weniger sprunghaft und liest sich systematisch in ein Thema ein. Er macht sich Notizen und Lesezeichen und
Heuristische Methode zur Problemlösung, bei der solange zulässige Lösungen
probiert werden, bis die gewünschte Lösung gefunden wird.
1
2.2 BENUTZERSICHT
13
verfolgt einen linearen Lesestil. Der „Fachmann“ hat eine konkrete Vorstellung und sucht gezielt nach tieferen Informationen. Fachmänner benötigen übersichtliche Hilfeinformationen, wie z.B. Referenzen, da sie im
Gegensatz zu Einsteigern die grundlegenden Funktionen der Software
bereits beherrschen. Der „Praktiker“ hat als wesentliches Ziel die Theorie in die Praxis umzusetzen. Hierzu benötigt er handlungsorientierte
und aufgabenbezogene Anweisungen wie Schritt-für-Schritt-Anweisungen, Beispiele und Tutorials.
2.2.2 Paradox des aktiven Benutzers
Im vorigen Abschnitt wurde bereits der „undisziplinierte Benutzer“ erwähnt, dessen Verhalten unter dem Begriff „Paradox des aktiven Benutzers“ 1987 durch Caroll und Rosson 1987 beschrieben wurde. Die zentrale Aussage dieses Ausdrucks ist die Tatsache, dass Benutzer direkt in
die Benutzung einer Software einsteigen, ohne die Dokumentation zu
lesen. Selbst in Problemsituationen wird zunächst versucht das Problem
durch „Ausprobieren“ zu lösen und dann erst die Dokumentation herangezogen. Der aktive Benutzer ist hoch motiviert und möchte so schnell
wie möglich seine Arbeit beginnen, ohne dabei viel Zeit darin zu investieren, sich in das System einzuarbeiten und initial auf seine Bedürfnisse
anzupassen. Längerfristig betrachtet würde dadurch jedoch viel Zeit eingespart werden, was das paradoxe an diesem rationell geprägten Verhalten ausmacht. Die Autoren bezeichnen dies aber als ein völlig menschliches und natürliches Vorgehen und fordern daher, dass sich das Design
eines Hilfesystems diesem Verhalten anpassen sollte – nicht andersherum (Carroll & Rosson, 1987).
2.2.3 Probleme der Benutzbarkeit von Hilfesystemen
Die Toleranz des Benutzers im Bezug auf Mängel in der Benutzerfreundlichkeit eines Hilfesystems ist gerade in Problemsituationen eine viel
geringere als bei der Software selbst. Dies begründet sich durch die initiale kognitive Belastung, die der Benutzer bereits durch das eigentliche
Problem erfahren hat. Außerdem ist zu beachten, dass Hilfesysteme die
Funktionalitäten einer Software erweitern und sie somit auch zusätzlich
verkomplizieren können, alleine nur durch ihre Existenz. Eine zusätzliche Hilfe für die Benutzung der Hilfe ist ein paradoxes Phänomen, welches gerade bei komplexen Hilfesystemen zu beobachten ist (Nielsen,
1993).
14
In einer Studie von Novick und Ward (Novick & Ward, Why Don’t
People Read the Manual?, 2006) wurden Gründe für die Frustration
beim Umgang mit Hilfesystemen untersucht. In der nachfolgenden Tabelle sind die erforschten Gründe zusammen mit weiteren Erkenntnissen
aus (Houghton, 1984) kategorisiert abgebildet.
Zugänglichkeit
 Hilfe ist nicht verfügbar
 Probleme bei der Navigation
 Schwierigkeiten bei der Verwendung der vorhandenen Suchmethoden
 Schwierigkeiten bei der Formulierung von Suchbegriffen bzw. der Problembeschreibung
 Dokumentation ist zu mächtig und „erschlägt“ den
Benutzer
Darstellung
 Bildschirmhilfen „verbrauchen“ Platz und ermöglichen es nicht Hilfe und Anwendung gleichzeitig zu
zeigen
 Inkonsistenz in der Darstellung
 Große Textblöcke verhindern das „Überfliegen“ von
Inhalten
Inhalt
 Unangemessene Prägnanz und Detailliertheit von
Erklärungen oder Beschreibungen
 Inhalte sind unvollständig
 Inhalte sind nicht aktuell
 Inkonsistenz in der Terminologie
 Anthropomorpher1 Schreibstil
Tabelle 1: Probleme des Benutzers beim Umgang mit Hilfesystemen
Im Folgenden werden die Probleme bei der Zugänglichkeit genauer
beschrieben. Schwierigkeiten die im Zusammenhang mit der Gestaltung
und Formulierung des Inhaltes oder der Darstellung stehen sind nicht
1
Vermenschlichend
2.2 BENUTZERSICHT
15
Gegenstand dieser Arbeit, da sie nicht relevant für das später vorgestellte Konzept sind.
2.2.4 Probleme beim Zugriff auf Hilfesysteme
Benutzer verarbeiten eine Dokumentation auf besonders hohem Niveau.
Sie springen, überfliegen Inhalte und scannen den Text vielmehr als
dass sie nur lesen. Sie möchten sich nicht durch eine mächtige Dokumentation durcharbeiten, sondern erwarten vielmehr einen schnellen
und einfachen Zugang zu den benötigten Informationen. Ein effektiver
Zugang kann durch eine gute Navigierbarkeit innerhalb des Informationsraums erzielt werden. In diesem Bereich treffen die Benutzer in der
Praxis jedoch immer wieder auf Hindernisse. In einer Studie von Novick
und Ward (Novick & Ward, Why Don’t People Read the Manual?, 2006)
gaben 32% der Teilnehmer an, dass sie generelle Schwierigkeiten während der Navigation innerhalb von Online-Dokumentationen hatten.
Orientierung
Der Zugriff auf Informationen einer Online-Dokumentation ist im Falle
des Hilfefensters mit der Orientierung innerhalb einer Webseite zu vergleichen. Eine Webseite bietet ebenfalls verschiedene Themen an, die
über eine Navigation zugänglich sind. Die Navigation im Hilfefenster ist
das Inhaltsverzeichnis. Es stellt eine logische Gliederung des Inhaltes
dar und soll damit dem Benutzer den Zugriff auf einzelne Themenbereiche erleichtern. Die Gliederung erfolgt allerdings nach der Sicht des Autors, die nicht zwangsläufig mit der des Lesers übereinstimmen muss.
Das Stichwortverzeichnis weist ähnlich Mängel auf, da auch hier die
Sprache des Autors verwendet wird. Deshalb sollte der Autor im Stichwortverzeichnis unbedingt Synonyme und Permutationen zusammengesetzter Begriffe aufnehmen und auf die Vollständigkeit achten.
„Lost in Hyperspace“
Das Phänomen des „Lost in Hyperpspace“ tritt ebenso bei Webseiten wie
auch bei schlecht strukturierten Online-Dokumentationen auf (Turk, 96).
Das Phänomen beschreibt die Orientierungslosigkeit in die ein Benutzer
mit voranschreitendem Navigationsverlauf geraten kann. Der Benutzer
weiß nicht mehr wo er sich gerade befindet, wie er dort hingekommen ist
und wie er weiterkommen kann.
Abhilfe schafft eine Einschränkung des Navigationsraums bzw. der
Hypertextstruktur, durch Lesepfade, Hypertrails oder Filter (Thiemann,
16
2008). Lesepfade bieten dem Benutzer eine sequentielle Leserichtung
ähnlich wie in einem Buch an. Mit Hilfe von Hypertrails kann der Hypertextraum auf eine bestimmte Sicht bzw. einen bestimmten Aspekt
eingeschränkt werden. Filter ermöglichen dem Leser die Link-Struktur
anhand von benutzerdefinierten Begriffen einzuschränken.
Textbasierte Suchfunktionen
Ein weiteres zentrales Instrument der Zugänglichkeit vieler OnlineDokumentationen ist die Suchfunktion, die auch in der Oberfläche meist
an prominenter Stelle zu finden ist (siehe 2.4). Sie erlaubt es dem Benutzer bestimmte Suchwörter oder ganze Fragen einzugeben, nach denen in
der Datenbasis gesucht wird. Der Benutzer hat dabei die Möglichkeit
sein Problem in natürlicher Sprache zu formulieren. Die Qualität der
Ergebnisse variiert jedoch selbst bei den einfachsten Suchanfragen sehr
stark.
2.2 BENUTZERSICHT
17
Abbildung 2.4: Screenshots der Suchfunktionen als zentraler Zugang zu
Online-Dokumentationen (oben: integrierte Hilfe von Microsoft Windows
Vista; unten: Hilfe von Mozilla Firefox)
Gründe hierfür sind hauptsächlich die Probleme, die beim Formulieren der Suchbegriffe auftreten. Die exakte Formulierung von komplexen
Problemen ist gerade für Laien eine Herausforderung (Li, Vukovi,
Pingali, & Lee, 2009). Obwohl völlig klar ist, wonach sie suchen, fehlen
ihnen oft konzeptionelle oder technische Grundbegriffe um eine präzise
und adäquate Frage bzw. Menge von Suchbegriffen zu formulieren.
Die kognitive Belastung bedingt durch die Motive des Aufrufs der Hilfe, die sogenannte intrinsische Belastung, schränkt den Benutzer zusätzlich ein, alle relevanten Aspekte für eine schlüssige und umfangreiche
Problembeschreibung einzubeziehen (Nückles & Ertelt, 2006). Eine
18
exakte Problembeschreibung, oder genauer eine exakte Beschreibung der
Symptome des Problems, ist übrigens nicht immer zwangsläufig der
Schlüssel zur passenden Lösung, denn oft können ähnliche Symptome
das Ergebnis unterschiedlicher Problemen sein.
Ein weiteres Hindernis der textbasierten Suche sind Mehrdeutigkeiten in der natürlichen Sprache (Polysemie). Mehrdeutigkeiten können zu
Fehlinterpretationen innerhalb des Suchprozesses und schließlich zu
unerwarteten Ergebnissen führen.
Zugang zu Hilfesystemen
Ein grundsätzliches Hindernis mit dem jeder hilfesuchende Benutzer zu
Beginn konfrontiert wird, ist die Lokalisation der Hilfe – wenn diese
denn überhaupt existiert. Unerfahrene Benutzer wissen oft nicht, wo der
Einstieg zum Hilfesystem zu finden ist. Erfahrene Benutzer hingegen
stehen vor dem Problem, eine Methode aus den ihnen bekannten Methoden auszuwählen. Im Anwendungsbereich haben sich zum Vorteil des
Benutzers einige Methoden als De-facto-Standard etabliert. Zu ihnen
zählt der Aufruf der Hilfe über die F1-Taste, über ein Hilfemenü bzw.
Hilfebutton oder über eine Programmverknüpfung. Weitere Formen der
Hilfe lassen sich oft auch auf den Webseiten der Hersteller finden.
Bietet eine Anwendung mehrere Möglichkeiten eine Hilfe zu erreichen, kann es vorkommen, dass das Hilfeangebot speziell für die entsprechenden Arten des Zugangs angepasst ist. Ein Aufruf mittels der F1Taste könnte z.B. nur punktuelle Hilfe zum aktiven Dialog liefern, wohingegen das Öffnen der Hilfe über das Hilfemenü die komplette Hilfe in
einem Hilfefenster anzeigen könnte. Eine aktuelle Version der Hilfe
könnte der Benutzer auf den Webseiten des Herstellers finden. In einem
solchen Szenario können schnell inhaltliche Inkonsistenzen, oder schlimmer noch Wiedersprüche in den unterschiedlichen Datenbeständen auftreten. Wird dies vom Benutzer bemerkt, ist dieser irritiert und kann
schließlich keine Entscheidung über die „richtige“ Art des Zugangs treffen.
Abgrenzung des Problems
In der Benutzerstudie von Novick und Ward (Novick & Ward, Why Don’t
People Read the Manual?, 2006) gaben 16% der Teilnehmer an, dass sie
häufig Schwierigkeiten damit haben, einen Fehler einzugrenzen – z.B.
auf eine Anwendung oder ein Problem mit dem Betriebssystem. Die
Gründe solcher Probleme liegen laut Novick und Ward in den zunehmenden Kooperationsmöglichkeiten zwischen unterschiedlichen Anwendun-
2.3 KONTEXTSENSITIVER ZUGRIFF
19
gen und der stärkeren Integration in das Betriebssystem. Ein besseres
Zusammenspiel zwischen den Anwendungen untereinander und der einzelnen Anwendung mit dem Betriebssystem ist sicherlich von großem
Vorteil für den Benutzer, doch werden dadurch die Grenzen bei der Problemanalyse zunehmend unklarer. Außerdem beleuchten die wenigsten
Dokumentationen die Interaktionen oder Inkompatibilitäten mit anderen Programmen.
2.3 Kontextsensitiver Zugriff
Der hilfesuchende Anwender wendet sich mit Problemen die bei der Arbeit mit einem Programm auftreten bevorzugt an menschliche Hilfequellen, wie z.B. Kollegen oder Freunde. Dies ist dadurch begründet, dass
Menschen untereinander effektiv kommunizieren und somit ihre Gedanken und Probleme teilen können. Dey nennt folgende Faktoren, die eine
effektive Kommunikation zwischen Menschen ermöglichen: die Reichhaltigkeit der Sprache die sie teilen, eine gemeinsame Vorstellung wie die
„Dinge funktionieren“ und ein implizites Verständnis von alltäglichen
Situationen. Ein weiteres sehr wichtiges Merkmal ist, dass Menschen
implizit situationsabhängige bzw. kontextuelle Informationen herleiten
können um die Kommunikation anzureichern (Dey, 2001).
Leider lassen sich diese Eigenschaften nicht auf die Mensch-Computer-Interaktion übertragen. Ein besonders nachteiliger Aspekt ist, dass
interaktive Computersysteme keinen Zugriff auf den Kontext des Benutzers haben und dieser deshalb explizit über eine meist verarmte Schnittstelle „geliefert“ werden muss (Dey, 2001). Um die Qualität von maschinellen Informationen und Diensten zu steigern, gilt es diesen Zugang zu
Kontextinformationen zu verbessern. Dies trifft auch auf Hilfesysteme
zu, denn eine repräsentative Beschreibung eines Computerproblems sollte zwingend auch eine Beschreibung des Kontextes beinhalten (Nückles
& Ertelt, 2006). Hierzu zählen unter anderem der Zustand des Systems,
sowie der Zustand der gegenwärtigen Aufgabe.
2.3.1 Definition des Kontextbegriffs
In seiner Veröffentlichung (Dey, 2001) definiert Dey die Begriffe „Kontext“ und „kontextsensitiv“ folgendermaßen:
„Als Kontext gilt jede Information um die Situation einer Entität zu
charakterisieren. Als Entität wird eine Person, ein Ort oder ein Objekt
20
verstanden, welches als relevant bezüglich der Interaktion zwischen dem
Benutzer und der Anwendung erachtet wird – der Benutzer und die Anwendung inbegriffen.“
„Ein System ist kontextsensitiv, wenn es den Kontext des Benutzers
einbezieht um relevante Informationen zu liefern, wobei die Relevanz von
der Aufgabe des Benutzers abhängt.“
Diese Definitionen sollen den Anwendungsentwickler dabei unterstützen die einzelnen Kontexte in einem Anwendungsszenario zu erkennen
und zu spezifizieren.
2.3.2 Bedeutung von Kontext
Die Effizienz des Informationsabrufs in Bezug auf Hilfesysteme, oder
Informationssysteme im Allgemeinen, lässt sich unter der Berücksichtigung von Kontextinformationen wesentlich steigern. Hierzu werden im
Folgenden einige Aspekte anhand von Beispielen erläutert.
Intention des Benutzers
Anhand von Kontextinformationen lassen sich Annahmen über die Intentionen des Benutzers herleiten. Auf diese Weise kann z.B. der anfänglich erwähnten Problemstellung der Polysemie begegnet werden. Dieses
Problem tritt besonders im Bereich von textbasierten Suchanfragen auf,
da sich keine signifikante Korrelation zwischen der Anfrage und dem
Nutzungskontext abzeichnet (Li, Vukovi, Pingali, & Lee, 2009). Verwendet ein Benutzer in einer textbasierten Suche den Begriff „Array“, kann
dieser vom System auf unterschiedliche Weise gedeutet werden, da dieser Begriff in den verwandten Bereichen der Informatik und der Elektrotechnik in unterschiedlichen Bedeutungen auftaucht. Werden vorangegangene Sucheeingaben des Benutzers berücksichtigt, kann aber eine
Annahme darüber getroffen werden, welcher Bereich relevanter ist. Die
Suchhistorie des Benutzers ist also in diesem Szenario als Kontext zu
betrachten und wird auch in sogenannten „Recommender Systems“, also
in Systemen die dem Benutzer Vorschläge unterbreiten, ausgenutzt. Eine kommerzielle Variante von Recommender Systems sind Online-Shops
die dem Besucher anhand von früheren Käufen oder eingegebenen Suchbegriffen Kaufempfehlungen präsentieren. Ein schon fast klassisches
Beispiel für den Einsatz von Kaufempfehlungen ist der Online-Shop
„amazon.de“ (siehe Abbildung 2.5).
21
Abbildung 2.5: Screenshot der Kaufempfehlungen bei „amazon.de“
Einschränkung des Suchraums
Zusätzlich können Kontextinformationen dazu verwendet werden, den
Suchraum einzuschränken, da bestimmte Informationen nur in einem
gewissen Kontext gültig oder sinnvoll sind. Sucht ein Anwender mittels
eines Internetdienstes z.B. ein Restaurant anhand des Namens, wäre es
sinnvoll die Suchergebnisse mit Hilfe der IP des Benutzers auf seine Region einzuschränken. Ein weiteres Beispiel hierzu ist die Online-Hilfe
des Firefox-Browsers auf der Webseite des Herstellers Mozilla. Da der
Browser auf unterschiedlichen Betriebssystemen lauffähig ist, existieren
für die meisten Hilfeartikel auch dementsprechend unterschiedliche Versionen (siehe Abbildung 2.6). Da ein Browser bei jeder Anfrage einer
Webseite in der Regel das verwendete Betriebssystem mit sendet, ist die
„richtige“ Version des Hilfeartikels an dieser Stelle bereits voreingestellt.
22
Abbildung 2.6: Screenshots der angepassten
Hilfeartikel der Online-Hilfe von Firefox
(oben: Windows; unten: Mac OS)
Gewichtung von Informationselementen
Ein ähnliches Vorgehen ist das Gewichten von Informationselementen.
Hierbei wird der Suchraum nicht eingeschränkt, sondern die Ergebnisse
des gesamten Suchraumes anhand der Konformität bezüglich des Kontextes gewichtet. So würden sich beim obigen Beispiel der Restaurantsu-
23
che die Resultate nicht auf die Region des Benutzers beschränken, sondern eine Liste aller Restaurants sortiert nach der Entfernung angezeigt
werden.
Die Einschränkung und Gewichtung von Informationselementen ist
allerdings nur dann möglich, wenn eine Kennzeichnung der Elemente
mit bestimmten Bedingungen über Kontexten gegeben ist und diese über
eine Schnittstelle abgerufen werden können.
Automatische Aktivierung von Diensten
In kontextsensitiven Systemen werden Kontextinformationen auch häufig dazu verwendet, bestimmte Aktionen beim Auftreten gewisser Vorbedingungen automatisch auszuführen. Diese Methode wird oft im Bereich
des „Ubiquitous Computing“, also dem allgegenwärtigen Vorhandensein
von computergestützten Einheiten, eingesetzt (Samulowitz, 2002). Hierzu zählt der berühmte sich selbst auffüllende Kühlschrank oder der Rasensprinkler, der mittels Wetterprognosen aus dem Internet vorzeitig für
eine optimale Befeuchtung sorgt. Aber auch alltäglichere Erscheinungen
wie z.B. das Handy, das automatisch das Display sperrt, wenn es zum
Telefonieren ans Ohr gehalten wird oder das Notebook, das die Tastaturbeleuchtung bei Dunkelheit automatisch einschaltet, ergeben sich
durch die Einbeziehung des Kontextes.
2.3.3 Kontextinformationen in Hilfesystemen
Im Abschnitt 2.1.1 wurde im Rahmen von Assistenzsystemen bereits
kurz die „kontextsensitive Hilfe“ vorgestellt. Als „kontextsensitive Hilfe“
wird eine Hilfefunktion verstanden, die sich an den Nutzungskontext
anpasst, welcher sich in der Regel auf die Oberfläche und deren Elemente beschränkt. Es wird zwischen kontextsensitiver Hilfe auf Elementebene (Direkthilfe) und auf Dialogebene unterschieden (Thiemann, 2008, S.
14). Wenn man allgemein von „kontextsensitiver Hilfe“ spricht, sollte
diese allerdings mehr Aspekte berücksichtigen, als sich lediglich auf die
Oberfläche zu beschränken.
Das Umfeld, in dem Softwareprodukte zum Einsatz kommen, ist sehr
vielfältig. Hierzu zählen z.B. die Hardwarekonfiguration, das verwendete
Betriebssystem und weitere Umgebungsparameter wie Benutzerrechte
oder weitere installierte Softwarekomponenten. Ein Problem üblicher
Hilfesysteme ist, dass die von ihnen bereitgestellten Informationen und
Lösungen aufgrund des komplexen Umfelds oft zu allgemeingültig sind
um sie in der tatsächlichen Benutzersituation einsetzen zu können
24
(Vouligny & Rober, 2005). Die Adaption einer generischen Lösung an ein
bestimmtes Szenario erfordert außerdem ein grundlegendes Verständnis,
welches gerade Laien oft nicht aufweisen können. Aber auch versierte
Benutzer sind aufgrund der zusätzlichen Belastung durch die Problemsituation kognitiv eingeschränkt und können der Problemlösung nicht ihre
volle Aufmerksamkeit entgegen bringen. Deshalb sollte das Angebot von
verallgemeinerten Hilfeinformationen weitestgehend eingeschränkt werden.
Eine Herausforderung benutzerfreundlicher Hilfesysteme ist die Anpassung an den gegenwärtigen Anwendungskontext, um gezielte Unterstützung bieten zu können. Dass der Anwendungskontext bei der Problemlösung eine bedeutende Rolle spielt, hat unter anderem auch die Studien von Pilkington (Pilkington, 1992) gezeigt. In dieser Studie wurden
die Dialoge zwischen Experten und Laien während eines Problemlösungsprozesses analysiert und ausgewertet. Eine generelle Beobachtung
war, dass in den meisten der Fragen und Aussagen (mehr als 2/3) der
Laien auch eine Art von Kontextinformation beinhaltet war – zum Teil
auch auf Anfrage der Experten. Die Verteilung der unterschiedlichen
Arten von den insgesamt 74 Kontextinformationen sind in der Abbildung
2.7 dargestellt. Die zusätzlichen Informationen waren nach Angabe der
Befragten nötig, um die Absichten der Laien zu konkretisieren und beeinflussten die Intentionen der Fragen oft maßgeblich.
Zusätzliche Kontextinformationen
30
25
20
15
10
5
0
Benutzeraktionen
Ziel
Aufgabenzustand
Dialog
Systemzustand
Abbildung 2.7: Zusätzliche Kontextinformationen in Fragen von Laien an
Experten während eines Problemlösungsprozesses (Pilkington, 1992)
2.4 ZUSAMMENFASSUNG UND OPTIMIERUNGSPOTENTIALE
25
Die Notwendigkeit von kontextbezogenen Informationen in einer repräsentativen Problembeschreibung wurde auch von Nückles und Ertelt
untersucht. Neben der Aufgabenbeschreibung sollte eine Problembeschreibung auch kontextbezogene Informationen wie den Zustand des
Systems und der Schnittstelle, sowie eine Beschreibung des Aufgabenzustandes beinhalten. Nückles und Ertelt nennen weiterhin einige Gründe
für die Schwierigkeiten, die mit der Beschreibung von angemessenen
Kontextinformationen verbunden sind. Benutzer machen häufig den
Fehler, dass sie die Angabe von wichtigen Schlüsselinformationen für
eine präzise Problembeschreibung vergessen. Hierzu zählen z.B. die Angaben über das verwendete Programm oder das eingesetzte Betriebssystem. Außerdem nehmen Benutzer oft an, dass der Experte die mentale
Repräsentation der Problemsituation mit dem Benutzer teilt. Es werden
z.B. häufig Äußerungen wie „Ich habe auf diesen Button geklickt, aber
nichts ist passiert…“ gemacht, obwohl der Experte den Bildschirm des
Benutzers nicht sehen kann. Häufig wird auch anstatt einer Problembeschreibung eine vermutete Ursache des Problems angegeben, was für die
Problembehebung eher irreführend ist (Nückles & Ertelt, 2006).
2.4 Zusammenfassung und Optimierungspotentiale
In diesem Abschnitt werden die wichtigen Aspekte dieses Kapitels noch
einmal zusammengefasst. Weiterhin wird kurz erläutert, welche Erwartungen der Benutzer an eine gute Dokumentation stellt und welche Möglichkeiten zur Zufriedenstellung dieser Erwartungen bestehen.
Im Abschnitt 2.1 wurden die allgemein bekannten Arten von OnlineDokumentationen vorgestellt. Online-Dokumentationen werden als Gebrauchsanweisung und Hilfestellung bei Problemen in den meisten Softwareprodukten eingesetzt. Beobachtungen aus der Praxis und aus verschiedenen Studien haben allerdings gezeigt, dass die Akzeptanz der
Online-Dokumentation (aber auch der gedruckten Dokumentation) gering ist, da der Benutzer beim Gebrauch dieser Hilfen auf unterschiedlichste Probleme stößt (siehe Abschnitt 2.2.3). Diese Situation ist bisher
leider immer noch vorherrschend, was darauf schließen lässt, dass die
breite Masse der Softwarehersteller die Notwendigkeit einer ausgereiften Benutzerunterstützung (noch) nicht erkannt hat. Auch im Bereich
der mittlerweile häufig eingesetzten Analysetechniken zur Gebrauchstauglichkeit wird die Softwaredokumentation wenn überhaupt nur untergeordnet einbezogen (Yeats, 2004). Um diesem Dilemma entgegenzu-
26
wirken und die Akzeptanz beim Benutzer zu verbessern, gilt es die Effektivität und Effizienz von Hilfesystemen zu steigern.
Was der Benutzer von einer guten Dokumentation erwartet und wie
diese Erwartungen erfüllt werden, wurde in einer Studie von Mitchell
(Mitchell, 1993) untersucht. Die Ergebnisse sind in der Tabelle 2 zusammengefasst und wurden später innerhalb einer Studie von Novick &
Ward (Novick & Ward, What Users Say They Want in Documentation,
2006) erneut belegt. Um die Akzeptanz der Hilfesysteme zu steigern,
sollten besonders die Attribute mit einer hohen Erwartungshaltung und
einer geringen Zufriedenheit betrachtet werden. Mitchell identifizierte
die Zugänglichkeit zu hilfreichen Informationen als ein besonders verbesserungswürdiges Merkmal. Auch in der Umfrage aus der Studie von
Novick & Ward wurde eine gute Navigierbarkeit (die mit einer guten
Zugänglichkeit einhergeht) von 80% der Teilnehmer als ein besonders
wichtiges Attribut eines Hilfesystems genannt.
Erwartung
Hoch
Gering
 Genauigkeit & Korrektheit
 Vollständigkeit
 Organisation
 Schreibstil
 Design & Layout
Gering
Zufriedenheit
Hoch
 Zugänglichkeit
 Übersichtlichkeit
 Beispiele & Szenarien
 Aufgabenorientiertheit
 Übersetzungen
Tabelle 2: Erwartungen und Zufriedenheit bei den Eigenschaften von
Softwaredokumentationen nach Mitchell (Mitchell, 1993)
Eine Verbesserung der Zugänglichkeit von Hilfesystemen kann, wie
im Abschnitt 2.3 beschrieben, durch den Einsatz von Kontextinformationen erzielt werden. Allerdings existieren in der Praxis zu wenige Ansätze, die kontextuellen Informationen effektiv einsetzen, um die Benutzerfreundlichkeit von Hilfesystemen zu steigern (Baltrunas, 2008). Schwierigkeiten bei der Kontexterfassung, gesteigerter redaktioneller Aufwand,
erhöhte Abstimmung zwischen Entwickler und Redakteur und fehlende
Standards sind einige Gründe für diesen Mangel. Bei der Kontexterfassung spielen z.B. Aspekte des Datenschutzes und softwaretechnische
Barrieren eine Rolle. Ferner ist der Aufwand beim Verfassen von Hilfein-
2.4 ZUSAMMENFASSUNG UND OPTIMIERUNGSPOTENTIALE
27
formationen in kontextsensitiven Hilfesystemen höher, da der Kontext
mit einbezogen werden muss und so allgemeingehaltene Lösungen bzw.
Beschreibungen durch spezielle, kontextabhängige Versionen abgelöst
werden müssen.
Wird der Aufwand für ein kontextsensitives Hilfesystem nicht gescheut, sollte darauf geachtet werden, dass der Benutzer den Zusammenhang zum Kontext erkennt und die kontextsensitiven Informationen
der Problemsituation entsprechend sind. Ansonsten kann Unmut beim
Benutzer aufkommen und die Hilfe wird ignoriert (Thiemann, 2008).
Kapitel 3
Konzept
Unter Einbeziehung der dargestellten Grundlagen und Probleme bei der
Interaktion mit Online-Dokumentationen wurde im Rahmen dieser Arbeit ein Konzept für ein Hilfesystem entwickelt, welches insbesondere
eine Optimierung im Bereich der Zugänglichkeit verfolgt. In diesem Kapitel sollen die Ziele, Prinzipien und Bausteine dieses Konzeptes vorgestellt werden.
Wie bereits in der Einleitung beschrieben, wurde das Hilfesystem in
Kooperation mit der Firma Diomex entwickelt und wird als „Diomex
Help-Desk System“ (kurz DHS) bezeichnet.
3.1 Zielsetzung
Das DHS soll die von Diomex entwickelten Anwendungen in die Lage
versetzen, eine dem Anwendungskontext entsprechende Hilfe anzuzeigen. Das DHS soll den Benutzer auf zwei Arten unterstützen. Zum einen
durch kontextsensitive Hilfeinformationen und zum anderen durch kontextsensitive Informationen speziell zur Problemlösung, z.B. beim Auftreten eines Anwendungsfehlers.
Die Hilfeinformationen sollen auf dem zentralen Server von Diomex
(Diomex Framework Services Server) gespeichert und verwaltet werden.
Die Ermittlung und Bereitstellung soll über Webservices erfolgen. Der
Server muss deshalb einen abgesicherten Dienst zur Verwaltung und
einen öffentlichen Dienst zur Abfrage von Hilfeinformationen bereitstellen. Der Verwaltungsdienst wird vom Hilferedakteur zur Pflege der Da-
29
30
KAPITEL 3 KONZEPT
ten verwendet und der Abfragedienst wird durch die Benutzeranwendung konsumiert.
Die beschriebene serviceorientierte Struktur gilt als Rahmenbedingung für die Integration des Hilfesystems in die Softwarearchitektur der
von Diomex entwickelten „Diomex Framework Components“. Die „Diomex Framework Components“ umfassen Dienste und Anwendungskomponenten, die sowohl dem Unternehmen als auch dem Benutzer bei der
Entwicklung, Verwendung und Wartung von Softwareprodukten unterstützen. Die „Diomex Framework Components“ werden im Rahmen der
Realisierung des Konzeptes im Abschnitt 4.1.1 genauer beschrieben.
Anwender
Hilferedakteur / Experte
Hilfeanfrage
Verwaltung
Diomex Framework
Services Server
Abbildung 3.1:Dienste zur Verwaltung und Abfrage von Hilfeinformationen vom „Diomex Framework Services Server“ (eigene Abbildung)
Da Server und Anwendung auf zwei unterschiedlichen Systemen betrieben werden sollen, muss der Anwendungskontext beim Aufruf des
Abfragedienstes mitgeliefert werden. Das bedeutet auch, dass die Anwendung für die Ermittlung des Kontextes zuständig ist. Hierfür sollte
eine einfach zu integrierende Komponente entwickelt werden, die möglichst flexibel und erweiterbar ist.
Um die Ergebnisse des Abfragedienstes in der Anwendung darstellen
zu können, muss eine Anzeigekomponente bereitgestellt werden. Das
Format der Hilfe sollte Formatierung und die Verwendung von im Text
3.2 PRINZIP
31
eingebetteten Bildern zulassen. Diese Komponente wird im folgenden
Kapitel im Abschnitt 4.6 beschrieben.
Bei der Verwaltung der Hilfeinformationen sollte außerdem die Möglichkeit der Wiederverwendbarkeit von Informationen durch eine Parametrisierung gegeben sein.
Abschließend ist noch zu sagen, dass das DHS den bisherigen Support
(meist Telefon und Fernwartung) nicht vollständig ersetzen soll und
auch kann. Es soll vielmehr die Supportanfragen reduzieren die sich inhaltlich häufig wiederholen. Die bisher eingesetzte OnlineDokumentation wurde mit „HTML-Help“ umgesetzt und soll nach dem
Einsatz des DHS‘ und der Übernahme des Inhaltes komplett abgelöst
werden.
3.2 Prinzip
Grundlegend arbeitet das DHS nach folgendem Prinzip (siehe Abbildung
3.2). Auf Seiten der Anwendung werden beim Hilfeaufruf Informationen
über den Anwendungskontext durch sogenannte „Kontextprovider“ (siehe Abschnitt 3.4.1) gesammelt. Ein Kontextprovider liefert eine bestimmte Klasse von Kontextinformationen, wie z.B. Informationen über
den Dialogzustand (angezeigte Elemente, Dialoghierarchie, u.Ä.), das
System (Architektur, Betriebssystem, u.Ä.) oder den aufgetretenen Fehler (Fehlernachricht, Fehlertyp, Stacktrace, u.Ä.).
Die gesammelten Werte der Kontextprovider werden dann zum Server
übertragen. Die dort gespeicherten Hilfeartikel, (siehe Abschnitt 3.4.6)
Probleme und Lösungen (siehe 3.4.5) sind mit bestimmten Kontextwerten gekennzeichnet, so dass diese „passend“ zum übermittelten Anwendungskontext selektiert werden können. Die Zuordnung erfolgt durch
logische Ausdrücke über den Kontextwerten und ist ein bedeutendes
Merkmal des entwickelten Konzeptes (siehe Abschnitt 3.4.2).
Der Server wertet schließlich die Bedingungen an den Informationselementen aus und gibt die passenden Elemente sortiert nach der Anzahl
der zutreffenden Bedingungen zurück (siehe Abschnitt 3.6). Die Ergebnisse werden dann in einem Hilfefenster auf Seiten der Anwendung angezeigt.
32
KAPITEL 3 KONZEPT
Anwendung
Server
Kontext
Kontextinformation
Kontext-Provider
Hilfeinformation
Kontextverknüpfung
Abbildung 3.2: Prinzip des „Diomex
Help-Desk Systems“ (eigene Darstellung)
3.3 Modellierung der Hilfeinformationen
In diesem Abschnitt wird die Modellierung der Hilfeinformationen dargestellt, da diese ebenfalls ein bedeutendes Merkmal des Konzeptes sind
(siehe Abbildung 3.3). Bei der Modellierung wurde besonders darauf geachtet, die Hilfeinformationen möglichst verständlich für den Benutzer
zu strukturieren.
Wie bereits unter den Zielvorgaben definiert, gibt es zwei unterschiedliche Situationen, in denen ein Benutzer das Hilfesystem benötigt. Zum
einen kann während der Arbeit mit der Anwendung ein Fehler auftreten,
der den Arbeitsablauf des Benutzers unterbricht. Bisher war es üblich,
dass die Fehlernachricht auf dem Monitor angezeigt wurde. Die Fehlernachricht vermittelt dem Benutzer allerdings oft nicht, was die möglichen Ursachen (im Folgenden als „Probleme“ bezeichnet) dieses Fehlers
sind, und am wichtigsten, wie dieser behoben werden kann. Eine problemgekennzeichnete Situation kann nicht nur im Fehlerfall auftreten
sondern auch durch andere Symptome, die eine Problemlösung erfordern
hervorgerufen werden, z.B. wenn der Benutzer eine bestimmte Funktion
über einen Button ausführen möchte, dieser aber deaktiviert ist. Ein
3.3 MODELLIERUNG DER HILFEINFORMATIONEN
33
Symptom kennzeichnet die für den Benutzer „spürbaren“ Auswirkungen
des Problems und ist somit der für den Benutzer natürlichste Ausgangspunkt der Problemlösung (siehe Abschnitt 3.4.3). Die Detektion möglicher Symptome erfolgt durch die bereits erwähnten Kontextprovider.
Bei der Modellierung der Symptom-Problem-Beziehung wurde darauf
geachtet, dass ein Symptom durch unterschiedliche Probleme hervorgerufen werden kann. Z.B. kann ein Fehler beim Zugriff auf eine Datei auftreten, wenn diese nicht vorhanden ist oder wenn diese durch ein anderes Programm gesperrt ist (siehe Abschnitt 3.4.4).
Ähnlich verhält es sich bei der Problem-Lösung-Beziehung. Ein Problem lässt sich oft auf unterschiedliche Arten lösen, die auch abhängig
vom gegenwärtigen Kontext seien können. Die Änderung einer Systemeinstellung als Teil einer Lösung erfordert z.B. unter Windows XP andere Abläufe als unter Windows 7. Aus diesem Grund können für ein Problem mehrere Lösungen mit unterschiedlichen Lösungsvarianten (z.B.
Windows XP und Windows 7) definiert werden, die zusätzlich mit bestimmten Kontextmerkmalen gekennzeichnet werden können.
Die einzelne Lösung setzt sich schließlich noch aus mehreren Lösungsschritten zusammen, die während der Problemlösung nacheinander bearbeitet werden müssen (siehe Abschnitt 3.4.5). Die Lösungsschritte stellen eine weitere Anpassung an die Bedürfnisse der Benutzer dar,
da der Benutzer ein handlungsorientiertes Vorgehen bei der Problemlösung bevorzugt (Nielsen, 1993, S. 150).
34
KAPITEL 3 KONZEPT
Wie funktioniert…?
Ich habe das
Problem, dass…!
Symptome
Hilfeartikel
Probleme
Lösungen
Verknüpfung zu Anwendungskontexten
Abbildung 3.3: Modellierung der Hilfeinformationen
im „Diomex Help-Desk System“ (eigene Abbildung)
Es treten aber auch Situationen auf, in denen der Aufruf des Hilfesystems nicht durch ein Problem motiviert ist, sondern der Benutzer vielmehr generelle Hilfeinformationen in Form von Beschreibungen oder
Konzepterläuterungen sucht. Deshalb werden vom DHS neben den Problemlösungen zusätzlich Hilfeartikel unterstützt (siehe Abschnitt 3.4.6).
Ein Hilfeartikel beschreibt ein bestimmtes Konzept oder die Funktionsweise einer bestimmten Bedienkomponente. Der Kontextbezug wird, wie
bei den Symptomen auch, durch die Verknüpfung zu bestimmten Kontextwerten hergestellt. So können die Hilfeartikel auf der Grundlage der
kontextuellen Gegebenheiten ermittelt werden. Die Hilfe zu einem Steuerelement ist z.B. besonders dann wichtig, wenn es im aktiven Dialog
angezeigt wird.
3.4 Vorstellung der Komponenten
In diesem Kapitel werden konzeptuelle Details der grundlegenden Komponenten des DHS‘ und deren Zusammenhänge vorgestellt. Neben der
„aktiven“ Komponente des „Kontextproviders“ (siehe Abschnitt 3.4.1)
existieren weiterhin noch die Bestandteile, die maßgeblich für die Abbil-
3.4 VORSTELLUNG DER KOMPONENTEN
35
dung und Speicherung der Hilfeinformationen sind und im Abschnitt 3.3
bereits kurz vorgestellt wurden. Zu ihnen zählen der „Anwendungskontext“ (siehe Abschnitt 3.4.2), das „Symptom“ (siehe Abschnitt 3.4.3), das
„Problem“ (siehe Abschnitt 3.4.4), die „Lösung“ (siehe Abschnitt 3.4.5)
und der „Hilfeartikel“ (siehe Abschnitt 3.4.6).
3.4.1 Kontextprovider
Bevor eine Hilfeanfrage an den Server gesendet werden kann, müssen
zunächst die Informationen über den Kontext gesammelt werden. Hierfür sind die Kontextprovider zuständig. Ein Kontextprovider liefert eine
bestimmte Klasse von Kontextinformationen. Diese können aus dem
Prozess der Anwendung selbst (Dialoginformationen, aufgerufene Funktionen oder Fehlernachrichten), aber auch aus dem umgebenden System
(Betriebssystem, Hardware oder andere Anwendungen) akquiriert werden. Die Ermittlung anwendungsexterner Informationen ist aufgrund
technischer Gegebenheiten eingeschränkter als bei anwendungsinternen
Informationen.
Die Merkmale des einzelnen Kontextproviders sind neben der Definition der Informationsklasse die Spezifikationen der unterstützten Kontextmerkmale. Für die Formulierung der Anwendungskontexte (siehe
Abschnitt 3.4.2) umfasst die Spezifikation auch eine Typisierung der
Kontextmerkmale.
Da das DHS ein Grundgerüst für die Entwicklung von Kontextprovidern bereitstellt, lassen sich neue Kontextprovider einfach durch den
Programmierer realisieren (siehe Abschnitt 4.4). Dieser muss lediglich
die vom Kontextprovider unterstützte Informationsstruktur definieren
und eine Methode implementieren, die für die Ermittlung der definierten
Merkmale sorgt. Für die Ermittlung sämtlicher Kontextinformationen
wird diese Methode neben denen der weiteren verfügbaren Kontextprovider automatisch durch das DHS aufgerufen. Die flexible Erweiterbarkeit zu neuen Kontextprovidern ist sehr wichtig für den erfolgreichen
Einsatz des DHS‘, da sie eine Schnittstelle zu neuen Klassen von Kontextinformationen ermöglichen und somit der Umfang der Kontextermittlung ausgeweitet werden kann.
Struktur der Kontextinformationen
Nachdem der Kontextprovider die Kontextinformationen ermittelt hat,
müssen diese in einem Speicherobjekt abgelegt werden. Dieses Speicherobjekt wird dem Kontextprovider zunächst noch leer durch das DHS be-
36
KAPITEL 3 KONZEPT
reitgestellt und hat als grundlegende Datenstruktur eine Kombination
aus einem eindimensionalen und zweidimensionalen, assoziativen Array
(siehe Abbildung 3.4). Somit können auch zugrundeliegenden Informationen vom Kontextprovider abgelegt werden, die eine hierarchische
Struktur aufweisen (bis zu zwei Ebenen).
2. Ebene
1. Ebene
„User Interface“
Bedienelementwerte
TxtFileName
„Export-1.csv“
BtnOk
null
Aktiver Dialogtyp
„FileExportDialog“
CbxOpenFileAfterExport
true
Abbildung 3.4: Ausschnitt der Datenstruktur für Kontextinformationen
vom Typ „User Interface“ (eigene Abbildung)
Typen
Nachfolgend werden die Eigenschaften und die unterstützten Kontextmerkmale der derzeit im DHS implementierten Typen von Kontextprovidern vorgestellt.
Machine
Informationen über die Hardwareumgebung und das Betriebssystem.
OSVersion
string
Version des Betriebssystems
Bsp.: Microsoft Windows NT 5.1.2600.0
Architecture
Betriebssystem- / Rechnerarchitektur
string
32-Bit / 64-Bit
Processes
Index  Prozessname
Laufende Prozesse
Bsp.: 12  winword.exe
User
Informationen über den Anwender.
IsAdmin
boolean
Ist der Benutzer aus Sicht des
Betriebssystems ein Administrator
UserTasks
Index  Name des UserTasks
Aktive UserTasks
Bsp.: 4  ExportingFile
Exception
Informationen über einen Anwendungsfehler.
Type
string
Fehlertyp
Bsp.: System.IO.FileNotFoundException
TargetSite
string
Methode die den Fehler ausgelöst hat
Bsp.: void LoadFile(string fileName)
ExceptionHash
string
Ein Wert, der den Fehler anhand seines Typens und
des Stacktraces eindeutig identfiziert
Bsp.: 94RF98IU7382GFW
UI
Informationen über die Benutzerschnittstelle (Dialog und Dialogelemente).
DialogType
string
Typ des gewählten Dialoges
Bsp.: Diomex.Product.UI.ExportFileDialog
Controls
Index  Typ
Typen der Bedienelemente des gewählten Dialogs
Bsp.: 64  System.Windows.Forms.TextBox
Components
Index  Typ
Typen der Komponenten des gewählten Dialogs
Bsp.: 3  <…>.UI.ValidationProvider
ControlValues
Name Wert
Werte der Bedienelemente des gewählten Dialogs
Bsp.: <…>.UI.TxtFileName  Export-1.csv
ControlEnabledStates
Name Aktiviert?
Aktivierungszustände der Bedienelemente des
gewählten Dialogs
Bsp.: <…>.UI.BtnOk  false
37
38
KAPITEL 3 KONZEPT
UIFocus
Informationen über das fokussierte Bedienelement.
ControlType
string
ControlName
string
Value
string
ControlHierarchy
Index Type
Typ des fokussierten Bedienelementes
Bsp.: System.Windows.Forms.TextBox
Name des fokussierten Bedienelementes
Bsp.: <…>.UI.TxtFileName
Wert des fokussierten Bedienelementes
Bsp.: Export-1.csv
Typen der übergeordneten Elemente des fokussierten
Bedienelementes
Bsp.: 3  System.Windows.Forms.TabControl
UserTask
Über den Anwendungscode definierbarer Aufgabenbereich.
UserTaskName
Index Name
Namen der aktiven UserTasks
Bsp.:
var u1 = UserTask.Start(„DoThis“);
// do this part 1
var u2 = UserTask.Start(„DoThat“);
// do that
u2.End();
// do this part 2
u1.End();
3.4.2 Anwendungskontext
Um die Hilfeinformationen des DHS‘ für den kontextsensitiven Zugriff
vorzubereiten, müssen diese zunächst mit dem jeweiligen Kontext verknüpft werden. Diese Verknüpfung wird durch sogenannte Anwendungskontexte hergestellt die im Zusammenhang mit den Kontextprovidern die Kernkomponenten des Konzeptes darstellen. Ein Anwendungskontext modelliert einen bestimmten Kontextzustand bzw. eine bestimmte Anwendungssituation mit Hilfe eines logischen Ausdrucks über
den Werten der Kontextprovider. Es wird angenommen, dass eine Anwendungssituation dann eingetreten ist, wenn der Ausdruck des Anwendungskontextes wahr ist. Wird ein Informationselement mit einem Anwendungskontext verknüpft, stellt der durch den Anwendungskontext
definierte Kontextzustand die Bedingung für die Gültigkeit des Informationselementes dar.
39
Formulierung von Bedingungen
Da eine bestimmte Anwendungssituation in der Regel sehr komplexe
Merkmalszusammenhänge aufweist, muss sich Definition der Bedingung
des Anwendungskontextes möglichst flexibel gestalten lassen. Um diese
Flexibilität zu erreichen, werden im DHS Formeln eingesetzt, die je nach
Granularität der Bestandteile eine mehr oder weniger spezielle Situation
beschreiben. Als Ergebnistyp der Formeln ist ein Wahrheitswert erforderlich, da die Formeln eine Bedingung präsentieren. Die textuelle Darstellung einer Formel könnte wie folgt aussehen:
„Der aufgetretene Fehler ist ein Dateizugriffsfehler und das Betriebssystem ist Windows XP oder Windows Vista und die Systemarchitektur
unterstützt nicht 64 Bit.“
Wie man sieht, kann bei der Definition einer Formel auf die (typisierten) Werte der Kontextprovider zugegriffen werden. Für die Formulierung von komplexeren Bedingungen werden neben den erforderlichen
logischen Operatoren zusätzlich folgende Eigenschaften unterstützt:

Numerische Operatoren

Verschachtelte Bedingungen

Funktionen, wie z.B. „Text-beginnt-mit“

Benutzerdefinierte Operatoren, wie z.B. „Beinhaltet-Wert“ für
Arrays
Um einen einmal definierten Anwendungskontext mit unterschiedlichen Hilfeinformationen verknüpfen zu können, kann der Anwendungskontext unter einem aussagekräftigen Namen, wie z.B. „Fehler beim Zugriff auf eine Datei im „Datei laden“-Dialog“ abgespeichert werden. Die
zentral definierten Anwendungskontexte können dann im Sinne der
Wiederverwendbarkeit von mehreren Hilfeartikeln und Symptomen referenziert werden.
3.4.3 Symptom
Der Begriff „Symptom“ (griechisch symptoma „Zufall, Begebenheit, Begleiterscheinung“) stammt eigentlich aus dem medizinischen bzw. psychologischen Bereich, und beschreibt dort ein Anzeichen, das auf eine
Erkrankung oder Verletzung hinweist. Deutliche Symptome werden
meist vom Patienten selbst bemerkt und geben Anlass, medizinischen
oder psychotherapeutischen Rat zu suchen (Symptom). Im Rahmen des
DHS‘ wird der „Symptom“-Begriff sinnbildlich für ein Anzeichen, das auf
40
KAPITEL 3 KONZEPT
ein Benutzungsproblem hinweist verwendet. Diese Metapher soll dem
Benutzer einen Eindruck von der Bedeutung dieses Bausteins vermitteln.
Symptome im Bereich von Softwareanwendungen lassen sich jedoch
weniger eindeutig und verständlich durch den Benutzer beschreiben als
im Vergleich zu medizinischen Symptomen (siehe Abschnitt 2.2.4). Dies
liegt zum einen daran, dass der Benutzer nicht in der Lage ist, die Symptome inhaltlich adäquat zu beschreiben. Weiterhin können Probleme bei
der Benutzung der Schnittstelle auftreten, durch die dem Hilfesystem
die Symptombeschreibungen übergeben werden müssen.
Ein Symptom ist hauptsächlich durch auffällige Zustände von bestimmten Umgebungsparametern gekennzeichnet, wie z.B. ein Button
der deaktiviert ist und sich nicht drücken lässt oder ein Anwendungsfehler der in bestimmten Situation auftritt. Diese Kennzeichen lassen sich
automatisch durch die Kontextprovider ermitteln und mittels der Anwendungskontexte zu einer Symptombeschreibung zusammenfassen.
Durch dieses Prinzip muss der Benutzer die Symptome nun nicht
mehr selber beschreiben, sondern erhält eine Auswahl möglicher zutreffender Symptombeschreibungen aus denen er nur noch wählen muss.
Voraussetzung hierfür ist natürlich, dass die Symptome bereits durch
einen Experten im DHS definiert worden sind. Hierfür benötigt der Experte Referenzfälle oder eine „Vorahnung“ welche Symptome zu Problemen führen könnten.
Das Symptom beinhaltet neben den Assoziationen zu bestimmten
Anwendungskontexten noch eine textuelle Beschreibung, wie z.B. „Sie
haben den Dialog zum Importieren einer Datei geöffnet, können den Dialog aber nicht mit OK bestätigen, da der Button deaktiviert ist.“. Diese
Beschreibungen sollen dem Benutzer helfen, mögliche Symptome mit
seiner gegenwärtigen Situation abzugleichen um dann den Lösungsprozess für das zutreffende Symptom zu beginnen.
3.4.4 Problem
In der Praxis findet man häufig eine Modellierung von Hilfeinformationen die sich aus „Problemen“ und „Lösungen“ zusammensetzt. Bei dieser
Modellierung werden die Symptome und die damit verbundenen Problemen unter dem allgemeinen Begriff „Problem“ zusammengefasst. Das
Konzept des DHS‘ sieht es allerdings vor diese Aspekte zu trennen, um
dem Benutzer einen klaren Überblick über die Zusammenhänge zu ge-
41
ben. Deshalb beschreibt die Problem-Komponente in diesem Konzept
nicht das Anwendungsproblem des Benutzers, sondern vielmehr die Ursachen der beim Benutzer aufgetretenen Symptome, wie z.B. „Die Datei
kann nicht geladen werden, da sie durch ein anderes Programm blockiert
ist.“, oder „Die Datei kann nicht geladen werden, da sie nicht gefunden
werden konnte.“.
Um zu definieren, welche Symptome durch welche Probleme hervorgerufen werden können, kann im DHS ein Symptom mit einem oder
mehreren Problemen verknüpft werden. Das Problem selbst beinhaltet
eine oder mehrere Lösungen und stellt somit eine semantische Verbindung vom Symptom zur Lösung her.
Neben den Verknüpfungen kann für das Problem auch eine passende
Beschreibung für den Benutzer angegeben werden. Gibt es zu einem
Symptom mehrere Probleme kann der Benutzer diese anhand der Beschreibungen eingrenzen, bevor er mit der Problemlösung beginnt. Erfahrene Benutzer können ihr Problem oft dann alleine anhand der Problembeschreibung lösen, wenn sie die Lösung bereits kennen. Somit bleibt
ihnen das Verarbeiten der Lösungsinformationen erspart.
3.4.5 Lösung
Die Lösung umfasst alle Informationen die zur Lösung eines Problems
benötigt werden. Sie wird genau einem Problem zugordnet und beinhaltet verschiedene Lösungsvarianten, z.B. für die unterschiedlichen Betriebssysteme. Die verschiedenen Varianten unterscheiden sich durch
die Zuordnung zu unterschiedlichen Anwendungskontexten. So lassen
sich bestimmte Lösungsversionen für bestimmte Kontexte definieren.
Hat eine Lösung keine verschiedenen Varianten, muss mindestens eine
„Standardvariante“ angelegt werden. Eine Lösungsvariante besteht wiederum aus mehreren Lösungsschritten, die handlungsorientierte Anweisungen zur Problemlösung enthalten. Die folgende Abbildung stellt die
erläuterten Zusammenhänge noch einmal schematisch dar.
42
KAPITEL 3 KONZEPT
Problem
Lösung I
Lösung II
Variante A
Variante B
Standardvariante
Schritt 1
Schritt 2
Schritt 3
Schritt 1
Schritt 2
Schritt 1
Schritt 2
Schritt 3
Verknüpfung zu Anwendungskontexten
Abbildung 3.5: Zusammenhang zwischen Problem, Lösungen, Lösungsvarianten und Lösungsschritten (eigene Abbildung)
3.4.6 Hilfeartikel
Neben den Informationen zur Problemlösung gibt es im DHS noch Hilfeartikel. Ein Hilfeartikel bezieht sich nicht auf ein bestimmtes Problem
sondern beinhaltet vielmehr Beschreibung und Konzepterläuterungen,
z.B. zu bestimmten Dialogen oder Bedienelementen. Ein Hilfeartikel ist
genauso wie eine Lösungsvariante mit mindestens einem Anwendungskontext verknüpft, der aussagt, in welcher Situation der Hilfeartikel benötigt wird. Wird im Hilfeartikel z.B. ein komplexes Bedienelement beschrieben, kann im entsprechenden Anwendungskontext definiert werden, dass der Hilfeartikel dann angezeigt wird, wenn dieses Bedienelement im aktiven Dialog verwendet wird. Dieses Prinzip ähnelt der bekannten kontextsensitiven Hilfe, hat aber durch die formelorientierten
Anwendungskontexte eine höhere Flexibilität bei der Formulierung der
Vorbedingungen.
3.5 Flexibilität durch Textvariablen
In diesem Abschnitt soll beschrieben werden, wie durch die Verwendung
von Textvariablen die Wiederverwendbarkeit und Flexibilität von Prob-
3.6 ERMITTLUNG DER HILFEINFORMATIONEN
43
lemen und Lösungen erhöht werden kann. Zunächst wird dargestellt an
welchen Stellen eine Parametrisierung stattfinden kann.
Wie bereits im Abschnitt 3.3 erklärt wurde, können Problem und deren Lösungen unabhängig von den Symptomen definiert werden. Erst
durch eine Verknüpfung eines oder mehrerer Probleme zu einem Symptom wird ein Zusammenhang definiert. Es ist häufig sinnvoll oder notwendig diesen Bezug auch innerhalb der Texte und Beschreibungen der
Probleme und Lösungen herzustellen. Folgendes Beispiel soll diesen
Sachverhalt veranschaulichen:
Im DHS ist ein Problem mit folgender Beschreibung definiert worden
„Auf die Datei konnte nicht zugegriffen werden, da sie durch einen anderen Prozess blockiert ist.“. In den Lösungstexten könnte ein Satz, wie
„Um die blockierte Datei freizugeben, müssen Sie …“ verwendet werden.
Weiterhin existieren zwei Symptome, die mit diesem Problem verknüpft
sind. Das erste Symptom beschreibt das ein Dateizugriffsfehler beim Export aufgetreten ist. Das zweite Symptom beschreibt den gleichen Fehler
nur beim Importvorgang. Durch die Verwendung von Textparametern
kann nun die Problem- und Lösungsbeschreibung wie folgt parametrisiert werden (der Textparameter wir mit P gekennzeichnet: „Auf die
Pdatei konnte nicht zugegriffen werden, da sie durch einen anderen Prozess blockiert ist.“ und „Um die blockierte Pdatei freizugeben, müssen
Sie …“. An der Verknüpfung vom Problem zum Symptom kann schließlich für diesen Textparameter der entsprechende Dateityp („Import“ oder
„Export“) festgelegt werden, der dann anstelle des Parameters eingesetzt
wird.
Die Textparameter können mehrfach in allen Texten und Beschreibungen der Probleme, Lösungen, Lösungsvarianten und Lösungsschritten eingesetzt werden. Außerdem besteht die Möglichkeit für einen
Textparameter einen Standardwert festzulegen. Dieser wird dann verwendet, wenn kein Wert an der Symptomverknüpfung definiert wurde.
3.6 Ermittlung der Hilfeinformationen
In diesem Abschnitt soll beschrieben werden, nach welcher Strategie die
Hilfeartikel und Problemlösungen vom Hilfeanfragedienst ermittelt werden.
Der Anfragedienst benötigt für die Ermittlung als einzige Eingabe die
Werte der Kontextprovider. Diese Werte werden in die definierten Formeln der Anwendungskontexte eingesetzt, um schließlich das Ergebnis
44
KAPITEL 3 KONZEPT
der Formeln berechnen zu können. Ein Anwendungskontext ist dann
gültig, wenn dessen Berechnung den Wert „Wahr“ liefert. Zur Veranschaulichung folgt ein kurzes Beispiel:
Ein Anwendungskontext der das Vorhandensein eines Windows NT
Betriebssystems (egal welche spezielle Version) beschreibt, könnte durch
die folgende Pseudo-Formel spezifiziert sein „Der Wert OSVersion des
Kontextproviders Machine beginnt mit Microsoft Windows NT“. Wird als
Wert „Microsoft Windows NT 3.5.8.13“ bzw. „Microsoft Windows 98
5.25.625“ übermittelt ist der Anwendungskontext gültig bzw. nicht gültig. Für den Fall, dass in einer Formel der Wert eines Kontextproviders
verwendet wird, dessen Werte nicht verfügbar bzw. nicht übertragen
wurde, ist das Ergebnis der Formel „Falsch“.
Nachdem alle Anwendungskontexte validiert wurden, können die gültigen Hilfeartikel und Symptome bestimmt werden. Ein Hilfeartikel bzw.
Symptom ist dann gültig, wenn alle referenzierten Anwendungskontexte
zu den gültigen Anwendungskontexten gehören. Die gefundenen Hilfeartikel werden sofort zum Ergebnis hinzugefügt. Im Falle der Symptome
werden zunächst noch die verknüpften Probleme ermittelt. Da die Lösung eines Problems Lösungsvarianten besitzt und diese wiederum kontextabhängig seien können, werden auch bei diesen die Verknüpfungen
zu gültigen Anwendungskontexten untersucht. Dann wird das Ergebnis
mit den Symptomen, den entsprechenden Problemen und gültigen Lösungen komplettiert.
Die Hilfeinformationen werden schließlich noch absteigend nach der
Anzahl der verknüpften Anwendungskontexte sortiert, da davon ausgegangen wird, dass die Anzahl der zutreffenden Anwendungskontexte ein
Maß für die Übereinstimmung mit der Anwendersituation darstellt.
3.7 Kritische Würdigung
In diesem Abschnitt soll das entwickelte Konzept abschließend kritisch
betrachtet werden.
Es wurde bereits mehrfach erwähnt, dass Anwender in Problemsituationen oft auf Schwierigkeiten bei der Beschreibung des Problems treffen, z.B. bei der Formulierung von Suchbegriffen in einer Volltextsuche
(siehe Abschnitt 2.2.4). In diesem Punkt wird der Anwender durch das
DHS entlastet, da keine Problembeschreibung benötigt wird und diese
im weitesten Sinne automatisch ermittelt wird (siehe Abschnitt 3.2, 3.4.1
3.7 KRITISCHE WÜRDIGUNG
45
und 3.4.2). Diese automatische Ermittlung ist allerdings aus folgenden
Gründen kritisch zu betrachten.
Technische und rechtliche Grenzen der Kontextprovider
Für die Ermittlung der Kontextinformationen sind die im Abschnitt 3.4.1
beschriebenen Kontextprovider zuständig. Die Kontextinformationen, die
auf dem Anwendersystem gesammelt und zum Server übertragen werden, können neben unbedenklichen Daten, wie z.B. der Typ des aktiven
Bedienelementes auch sensible Daten, wie z.B. die Inhalte von Textfeldern oder die Namen der laufenden Prozesse enthalten. Abgesehen davon, dass die Daten verschlüsselt übertragen werden und auf dem Server
nur verarbeitet und nicht persistiert werden, sollte der Benutzer auf diesen Sachverhalt hingewiesen werden, sowie ein rechtlicher Rahmen für
den Datenschutz von Kontextinformationen geschaffen werden.
Neben dem Aspekt des Datenschutzes kann die Funktionsweise der
Kontextprovider auch aus technischer Hinsicht eingeschränkt werden.
Dies ist besonders dann der Fall, wenn Informationen von außerhalb der
Anwendung benötigt werden, wie z.B. vom System oder von anderen
Programmen. Dies hängt zum einen damit zusammen, dass der Autorisierungskontext in dem die Anwendung ausgeführt wird, den Zugriff auf
bestimmte Systeminformationen einschränken kann. Zum anderen bieten fremde Programme in den seltensten Fällen eine passende Schnittstelle zur Ermittlung der benötigten Kontextinformationen.
Aktualität und Entwicklung der Hilfeinformationen
Im Abschnitt 3.4.3 wurde die Symptom-Komponente beschrieben, mit
deren Hilfe potentiell problematische Anwendersituationen charakterisiert werden können. Die Symptome werden vom Hilferedakteur bzw.
vom Experten angelegt. Dies geschieht in der Regel, wenn z.B. eine telefonische Supportleistung als Referenzfall dienen kann oder wenn eine
problematische Situation bereits im Vorfeld für den Hilferedakteur absehbar und definierbar ist. Das bedeutet, die Hilfeinformationen entwickeln sich mit der Anzahl der Supportanfragen und können je nach Vorarbeit zu Beginn nur in geringem Maße vorhanden sein. Der Benutzer
kann also gerade während der Startphase, in der sich das System beim
Benutzer unter Beweis stellen muss, durch mangelnde Hilfeinformationen ernüchtert werden. Da allerdings die Hilfeinformationen des DHS
von einem zentralen Server stammen, sind diese sofort nach der Neuanlage für den Anwender zugänglich.
46
KAPITEL 3 KONZEPT
Umgang mit Anwendungskontexten
Die Symptome, wie auch die Hilfeartikel und die Lösungsvarianten sind
mittels der Anwendungskontexte mit einer bestimmten Anwendungssituation gekennzeichnet (siehe Abschnitt 3.4.2). Die Anwendungssituation wird vom Hilferedakteur im Anwendungskontext durch eine Formel
kodiert. Die Beschreibung einer Situation anhand einer Formel kann
insbesondere bei komplexeren Situationen eine gewisse Schwierigkeit für
den Redakteur darstellen. Die Probleme für den Redakteur treten dabei
an verschiedenen Stellen auf. Zunächst muss der Redakteur in der Lage
sein, eine Situation durch bestimmte Kontextwerte eingrenzen zu können. Hierbei können falsche Annahmen gemacht werden, so dass die
Anwendungssituation nicht richtig abgedeckt wird. Außerdem müssen
die benötigten Kontextwerte durch die entsprechenden Kontextprovider
unterstützt werden. Eine weitere Schwierigkeit kann die Formelsyntax
darstellen, nach der die Formeln aufgebaut werden müssen. Diese ist
stark an die Formelsyntax von Excel angelehnt und sollte deshalb für
einen Benutzer mit Office-Kenntnissen kein Problem darstellen.
Laufzeit des Ermittlungsprozesses
Im Abschnitt 3.6 wurde die Vorgehensweise des Anfragedienstes bei der
Ermittlung der passenden Hilfeinformationen erläutert. Für jede Suchanfrage müssen auf dem Server zunächst die Formeln aller Anwendungskontexte ausgewertet werden. Hier besteht die Gefahr, dass bei
einer großen Anzahl von zu überprüfenden Anwendungskontexten die
Verarbeitungszeit einer Suchanfrage auf ein unangemessenes Maß ansteigt. Da hier noch keine Erfahrungswerte bestehen, sollte das Suchverhalten bei wachsenden Hilfeinformationen und einer ansteigenden
Anfragelast beobachtet und gegebenenfalls optimiert werden, z.B. mittels Caching-Strategien. Die restlichen Operationen während einer
Suchanfrage belaufen sich auf einfache Datenbankabfragen und stellen
deshalb kein derartiges Risiko dar.
„Stöbern“ in Hilfeinformationen
Ein Ziel dieses Konzeptes war die Optimierung des Zugriffs auf Hilfeinformationen, indem potentiell benötigte Hilfeartikel und Problemlösungen automatisch anhand des Kontextes ermittelt werden. Dieser zielgerichtete Zugriff ermöglicht es dem Benutzer jedoch nicht in den Hilfethemen zu „stöbern“ und sich durch Neugier und Interesse geprägt weiter zu informieren. Um diesem Nutzungsaspekt entgegenzukommen,
könnten dem Benutzer im Ergebnis zusätzlich auch „verwandte“ Hilfeinformationen zur Verfügung gestellt werden.
Kapitel 4
Realisierung
Nachdem im vorigen Kapitel die Entwicklung des Konzeptes vorgestellt
wurde, soll dieses Kapitel die Realisierung und Umsetzung des DHS‘
beschreiben. Zunächst wird im ersten Abschnitt das Softwareumfeld für
die Integration dargestellt, worauf eine Übersicht der durchzuführenden
Aufgaben folgt. Später im Kapitel werden diese Aufgaben im Detail beschrieben. Zu ihnen zählen die Entwicklung des Datenmodells, die Integration der Verwaltung der Hilfeinformationen in die Pflegeoberfläche, die
Implementierung der Kontextprovider, sowie der Entwurf eines Formates für die Hilfeartikel.
4.1 Rahmenbedingungen
Bevor die Details der Realisierung dargestellt werden, sollen in diesem
Abschnitt zuerst die „Diomex Framework Components“ als Softwareumfeld für die Implementierung vorgestellt werden. Als eine weitere Grundlage wird die eingesetzte Softwareplattform „Microsoft .NET“ kurz gekennzeichnet.
4.1.1 Diomex Framework Components
Diomex Framework
Die Firma Diomex führte schon in den frühen Zeiten der Unternehmensgründung eine systematische Sammlung von selbstentwickelten Softwarekomponenten ein, die im Laufe der Zeit durch die wachsenden Anforderungen stetig weiterentwickelt wurden. Zunächst setzte sich diese
47
48
KAPITEL 4 REALISIERUNG
Sammlung aus einigen Klassenbibliotheken zusammen, in denen häufig
verwendete Funktionalitäten und generelle Softwarebestandteile zentral
verwaltet wurden, um diese in unterschiedlichen Anwendungen wiederverwenden zu können. Diese Klassenbibliotheken werden als das „Diomex Framework“ (kurz DFW) bezeichnet. Sie kommen in nahezu jedem
Softwareprojekt von Diomex zum Einsatz, da sie essentielle Bestandteile
für jede Software bereitstellen. Zu diesen zählen Komponenten zur Unterstützung der Lizensierung, der serviceorientierten Client-ServerKommunikation, der Prozessparallelisierung und des Fehlerreportings,
sowie einige hilfreiche und oft benötigte Bedienelemente, um an dieser
Stelle die Wichtigsten zu nennen.
Diomex Framework Services
Mit der steigenden Anzahl an Softwareinstallationen stieg schließlich
auch der Verwaltungsaufwand, der ausschlaggebend für die Entwicklung
der Client/Server-basierten Anwendung „Diomex Framework Services“
(kurz DFW-Services) im Jahr 2007 war.
Die Verwaltungssoftware DFW-Services wurde speziell für die Unterstützung typischer administrativer Aufgaben aus dem Bereich der Softwareentwicklung entworfen. Zu diesen Aufgaben zählt zum einen die
Stammdatenpflege von Kunden, Produkten und Vertriebspartnern, sowie
Benutzern und Entwicklungsteams. Weiterhin stellen die DFW-Services
spezielle Dienste für z.B. Updates, Lizenzprüfungen und den Versand
von Fehlerprotokollen für die Kundeninstallationen zur Verfügung.
Die Bereitstellung dieser Dienste und auch die Speicherung der erwähnten Stammdaten erfolgt durch die Server-Komponente, den „Diomex Framework Services Server“ (kurz DFW-Services Server). Dieser
Server ist für die Kundeninstallationen über das Internet erreichbar. Die
Administration der Daten und Dienste erfolgt durch die Verwaltungsoberfläche „Diomex Framework Services Management Studio“ (kurz
„Management Studio“). Die folgende Abbildung 4.1 zeigt einen Screenshot dieses Verwaltungs-Clients.
4.1 RAHMENBEDINGUNGEN
49
Abbildung 4.1: Screenshot der Oberfläche des
„Diomex Framework Service Management Studios“
Die Gestaltung der Oberfläche ist MDI3-typisch. Im linken Teil ist der
„Objekt-Explorer“ zu finden, der die Datensätze der einzelnen Verwaltungsbereiche über eine Baumstruktur zugänglich macht. Ein ausgewählter Datensatz lässt sich als eigenes Fenster im Hauptbereich auf der
rechten Seite öffnen und bearbeiten. Häufig benutzte Funktionen können
über Tool-Leisten im oberen Bereich aufgerufen werden.
Da die Funktionen und Dienste der DFW-Services nicht speziell auf
Diomex zugeschnitten sind, sondern vielmehr die allgemeinen Anforderungen eines Softwareherstellers abdecken, wurde beim Entwurf der
DFW-Services die Mandantenfähigkeit von Anfang an berücksichtigt.
Somit sind neben Diomex auch weitere unabhängige Softwarehersteller
in der Lage von den Vorteilen der DFW-Services zu profitieren.
Nachdem neben dem „Diomex Framework“ auch die Bestandteile der
„Diomex Framework Services“ zu den Kernanwendungen von Diomex
hinzugekommen waren, wurden diese unter dem Begriff „Diomex Framework Components“ (kurz DFW-Components) zusammengefasst (siehe
Multiple-Document-Interface: Eine grafische Oberfläche, die durch die Möglichkeit des simultanen Öffnens von mehreren Dokumenten gekennzeichnet ist.
3
50
Abbildung 4.2). In diese Softwarearchitektur gilt es nun das bereits vorgestellte Konzept des Diomex Help-Desk-Systems zu integrieren.
Diomex Framework Components
Diomex Framework Services Server
• Updates
• Lizenzen
• Fehlerprotokolle
Anwendungen
•Administration
Management Studio
Server-Dienst
Diomex Framework Klassenbibliothek
Abbildung 4.2: Darstellung der Komponenten der „Diomex Framework
Components“ (eigene Abbildung)
4.1.2 Microsoft .NET Framework
Die Firma Diomex setzt seit jeher auf die Produkte von Microsoft und
somit fiel die Wahl der im Unternehmen deklarierten Programmiersprache auf die Software-Plattform Microsoft .NET. Die Plattform besteht
aus einer objektorientierten Laufzeitumgebung und einer Sammlung von
Klassenbibliotheken. In der Gesamtheit aller Komponenten wird sie
auch als .NET Framework bezeichnet. Das .NET Framework ist derzeit
in der Version 4.0 verfügbar und für den Einsatz in Windows-Systemen
ausgelegt. Durch das Mono-Projekt lassen sich Programme unter bestimmten Umständen auch auf Unix basierenden Betriebssystemen ausführen (.NET, 2010).
Ein Merkmal von .NET ist die Möglichkeit der gemischtsprachigen
Programmierung. D.h. bei der Programmierung von .NET Code können
verschiedene Programmiersprachen, wie z.B. C#, Visual Basic oder J#
4.2 INTEGRATIONSAUFGABEN
51
eingesetzt werden. Deshalb wird an dieser Stelle C# als die von Diomex
verwendete Programmiersprache erwähnt. Code-Abschnitte die später in
diesem Kapitel folgen sind also entsprechend in C# verfasst.
4.2 Integrationsaufgaben
Im vorigen Abschnitt wurden die „Diomex Framework Components“ als
Plattform für die Integration des zu entwickelnden Help-Desk-Systems
vorgestellt. Dieser Abschnitt soll die einzelnen Aufgaben, die für die Integration notwendig sind, aufzeigen.
Erweiterung des DFW- Services Servers
Zur Speicherung der im Konzept beschriebenen Bestandteile der Hilfeinformationen gilt es zunächst die Datenbank des DFW-Services Servers
um die entsprechenden Tabellen für Hilfeartikel, Symptome, Probleme,
Lösungen, Lösungsvarianten, Lösungsschritte und deren Relationen zu
erweitern (siehe Abschnitt 4.3).
Da die Datenbank auf einem Server betrieben wird und die Verwaltung über die Client-Anwendung „Management Studio“ erfolgt, muss
eine entsprechende administrative Service-Architektur entworfen werden. Für diese Teilaufgabe kann eine von Diomex entwickelte Software
zur Codegenerierung eingesetzt werden. Mit dieser Software, dem „Code
Generation Studio“, können anhand von Datenbankdefinitionen automatisch Grundgerüste für Dienste und Dienstfunktionen zur Bearbeitung
der entsprechenden Datenbankobjekte erstellt werden. Weiterhin lassen
sich Klassen für die Client-Anwendung generieren, die vorimplementierte Geschäftslogiken für die Pflege der Datensätze beinhalten. Diese werden für die Erweiterungen der Pflegeoberflächen des „Management Studios“ benötigt. Eine genauere Betrachtung dieser Integrationsaufgabe
wird in dieser Arbeit nicht gegeben.
Erweiterung des Management Studios
Die Pflege der Hilfeinformationen soll mittels eines weiteren Verwaltungsbereiches in das „Management Studio“ integriert werden. Hierzu
müssen der Objekt-Explorer erweitert und die Oberflächen zur Bearbeitung der entsprechenden Datensätze entwickelt werden. Diese Erweiterungen lassen sich zu Gunsten der vorhandenen Erweiterungsschnittstellen des „Management Studios“ effizient umsetzen (siehe Abschnitt
4.4).
52
Entwicklung der Kontextprovider
Für die Kontextermittlung müssen die im Abschnitt 3.4.1 erwähnten
Typen von Kontextprovidern implementiert und in die „Diomex Framework“-Klassenbibliothek eingebunden werden (siehe Abschnitt 4.5). Da
diese Bibliothek generell von allen Anwendungen eingebunden wird, ist
die Kontextermittlung somit innerhalb jeder Anwendung möglich.
Help-Desk-Dienst
Neben der Erweiterung für die administrativen Operationen muss für
den DFW-Services Server ein weiterer Dienst für die Bereitstellung der
Hilfeinformationen entwickelt werden. Dieser Anfragedienst ist für die
Ermittlung der anwendungskontextbezogenen Hilfeinformationen zuständig. Hierzu müssen die nötigen Hilfeinformationen aus der Datenbank anhand der Formeln und der übermittelten Werte der Kontextprovider bestimmt werden (siehe auch Abschnitt 3.6). Die Implementierung
dieser zentralen Operation wird im Abschnitt 4.6 detailliert dargestellt.
Format, Darstellung und Übermittlung der Hilfeinformationen
Nachdem die Hilfeinformationen ermittelt wurden, müssen diese schließlich beim Benutzer angezeigt werden. Hierzu muss zunächst ein Format
definiert werden, welches umfassende Textformatierungen inklusive im
Text eingebetteter Bilder erlaubt (siehe Zielsetzungen im Abschnitt 3.1).
Dieses Format muss sowohl bei der Editierung im „Management Studio“
als auch bei der Anzeige auf Seiten der hilfeaufrufenden Anwendungen
einsetzbar sein. Weiterhin sollten die Informationen samt Bildern so zusammengefasst werden können, dass sie als ein „Paket“ übermittelt werden können. Für die Anzeige beim Benutzer muss schließlich noch ein
spezielles Hilfefenster entwickelt werden, welches die formatierten Hilfeinformationen übersichtlich darstellen kann (siehe Abschnitt 4.6).
4.3 Datenmodell
Die Modellierung der Hilfeinformationen wurde bereits im Abschnitt 3.3
als ein wichtiger Aspekt des Konzeptes hervorgehoben. Dieser Abschnitt
beschreibt, wie das Modell auf die Datenbankstruktur des DFW- Services
Servers überführt wird.
Einleitend wird an dieser Stelle zunächst die Datenbankumgebung
kurz spezifiziert. Als Datenbank wird vom DFW-Services Server ein Microsoft SQL Server 2008 (auch kurz MSSQL Server) eingesetzt. Der
4.3 DATENMODELL
53
MSSQL Server ist eine hochentwickelte relationale Datenbank und verwendet für Datenbankabfragen die SQL-Variante Transact-SQL
(Bauder, 2008). Der Einsatz der Vorgängerversion MSSQL Server 2005
ist ebenfalls möglich.
Bevor die Komposition der benötigten Datenbanktabellen erfolgt, soll
zunächst ein Diagramm in UML-Notation die Zusammenhänge zwischen
den einzelnen Komponenten der Hilfeinformationen veranschaulichen.
Das nachfolgende Diagramm (Abbildung 4.3) soll vor allem dabei helfen,
die einzelnen Tabellen mit deren Primär- und Fremdschlüsseln zu identifizieren. Dabei kann aus jeder Entität eine Datenbanktabelle abgeleitet
werden. Bei Entitäten, die eine n:m-Beziehung aufweisen, wird eine zusätzliche Datenbanktabelle benötigt, die die Primärschlüssel beider Tabellen als Fremdschlüssel enthält. Für die folgenden Beziehungen wird
eine solche n:m-Tabelle benötigt: „Symptom tritt auf bei Problem“,
„Symptom tritt auf bei Anwendersituation“, „Variante ist gültig in Anwendersituation“ und „Hilfeartikel ist gültig in Anwendersituation“. Der
Tabellenname solcher „Verknüpfungstabellen“ setzt sich aus den Namen
der zu verknüpfenden Tabellen gefolgt durch den Begriff „Assignment“
zusammen. Für die Beziehung „Symptom tritt auf bei Problem“ wird also
eine Tabelle mit dem Namen „SymptomProblemAssignment“ angelegt.
54
Abbildung 4.3: UML-Diagramm der Hilfeinformationen
(eigene Abbildung)
Nach der oben beschriebenen Vorgehensweise ergibt sich schließlich
das nachfolgende Datenbankdiagramm. Dieses Datenbankdiagramm
zeigt alle Tabellen, mit deren Spalten, Primär- und Fremdschlüsseln und
den daraus resultierenden Relationen. Die Werte der Textparameter
(siehe Abschnitt 3.5) werden in der Tabelle „SymptomProblemAssignmentTextParameterValue“ abgespeichert, die an die Relationstabelle zwischen Problem und Symptom geknüpft ist. Somit lassen sich bei
4.4 PFLEGE DER HILFEINFORMATIONEN
55
jeder Zuordnung eines Problems zu einem Symptom die Werte für die
verfügbaren Textparameter setzen. Diese Tabelle wird explizit erwähnt,
da im UML-Diagramm keine Entsprechung vorhanden ist. Auf die weiteren Tabellen und deren Spalten wird im Laufe dieses Kapitels an entsprechender Stelle Bezug genommen.
Abbildung 4.4: Datenbankdiagramm der Hilfeinformationen
(eigene Abbildung)
4.4 Pflege der Hilfeinformationen
Wie bereits im Abschnitt 4.2 erwähnt, soll die Pflege der Hilfeinformationen mittels eines weiteren Verwaltungsbereiches in das „Management
Studio“ integriert werden. In diesem Abschnitt werden die Details dieser
Integration vorgestellt.
56
Erweiterung des Objekt-Explorers
Der Objekt-Explorer des „Management Studios“ bildet die zu verwaltenden Objekte der einzelnen Bereiche in einer Baumstruktur ab. Der Benutzer kann so zu den einzelnen Elementen navigieren und sie öffnen,
löschen oder neu anlegen. Wie bereits erwähnt, ist das „Management
Studio“ in der Lage auf Basis mehrerer Mandanten zu arbeiten. Der aktuell angemeldete Mandant samt Benutzer wird als Wurzel des ObjektExplorers dargestellt. Neben den Hauptbereichen „Verwaltung“, „Fehlerprotokolle“, „Updates“, „Lizenzen“ und „Ressourcenplanung“ soll nun
der Bereich „Help Desk“ hinzugefügt werden.
Abbildung 4.5: Objekt-Explorers des „Management Studios“ mit
Integration der Help-Desk-Elemente
Unter dem Bereich „Hilfeartikel“ sind die einzelnen Hilfeartikel zu
finden. Die Probleme samt Lösungen, Lösungsvarianten und Lösungsschritten sind im Bereich „Probleme & Lösungen“ eingeordnet. Weiterhin
57
werden die Symptome im Bereich „Symptome“ und die Anwendungskontexte im Bereich „Anwendungskontexte“ gepflegt. Die Verknüpfung der
Datensätze, z.B. der Anwendungskontexte zu den Symptomen oder Hilfeartikeln erfolgt in den Bearbeitungsoberflächen der jeweiligen Elemente. Diese sollen nachfolgend vorgestellt werden.
Anwendungskontexte
Der Anwendungskontext (Datenbanktabelle „ApplicationContext“, siehe
Abbildung 4.4) hat, wie fast jedes Element, einen Namen und eine Beschreibung (Datenbankspalten „Name“ und „Description“). Der Name ist
zwingend notwendig und wird zur Identifizierung im Objekt-Explorer
verwendet. Die Kernkomponente des Anwendungskontextes stellt die
Bedingung dar (Datenbankspalte „Condition“). Sie wird über ein Textfeld
eingegeben, welches einen Mechanismus zur automatischen Vervollständigung von Anwendungskontexttypen und Funktionen anbietet (siehe
Abbildung 4.6). Dadurch wird der Benutzer bei der Einhaltung der korrekten Formelsyntax unterstützt. Auf die Werte eines Kontextproviders
kann über die folgende Notation zugegriffen werden:
Kontextproviderbezeichnung.Wertbezeichnung
Ist der Wert ein Array von weiteren Werten kann auf diese wie folgt
zugegriffen werden:
Kontextproviderbezeichnung.Wertbezeichnung[Schlüssel]
Fehlerhafte oder fehlende Eingaben werden direkt in der Oberfläche
angezeigt und müssen behoben werden, bevor der Datensatz gespeichert
werden kann.
Abbildung 4.6: Pflegeoberfläche für Anwendungskontexte
58
Hilfeartikel
Ebenso wie der Anwendungskontext hat auch der Hilfeartikel (Datenbanktabelle „HelpItem“, siehe Abbildung 4.4) einen Namen sowie eine
Beschreibung. Der eigentliche Text der Hilfe (Datenbankspalte „HtmlCodePartXml“) wird mittels einer Integration des Textverarbeitungsprogramms „Microsoft Word“ bearbeitet, die im Abschnitt 4.6 genauer beschrieben wird. Die Verknüpfung zu den benötigten Anwendungskontexten erfolgt unter dem Reiter „Anwendungskontexte“. Hervorzuheben ist,
dass hier auch direkt eine Bedingung für einen Anwendungskontext eingegeben werden kann. Somit wird der Benutzer nicht gezwungen zunächst einen Anwendungskontext anzulegen, wenn dieser nur im Zusammenhang mit diesen einem Hilfeartikel verwendet wird. Ein Hilfeartikel muss eine direkt definierte Bedingung oder mindestens eine Verknüpfung zu einem bereits vordefinierten Anwendungskontext haben.
Eine Kombination ist an dieser Stelle auch möglich.
Abbildung 4.7: Pflegeoberfläche für Hilfeartikel
59
Probleme & Lösungen
Die Bearbeitung der Probleme und deren Lösungen (Datenbanktabellen
„Problem“, „Solution“, „SolutionItem“, „SolutionItemStep“, siehe Abbildung 4.4) erfolgt über eine einzelne Oberfläche, da diese Informationen
auch in der Modellierung eng miteinander verbunden sind. Neben den
Eigenschaften eines Problems, wie Name und Beschreibung lassen sich
unter dem Reiter „Lösungen“ die jeweiligen Lösungen zum Problem definieren. Ist eine Lösung ausgewählt können die entsprechenden Varianten in einer weiteren Liste verwaltet werden. Nachdem eine Variante
selektiert worden ist, können rechts unten die entsprechenden Anwendungskontexte zur Variante zugeordnet werden. Die Pflege der Lösungsschritte erfolgt schließlich im linken unteren Bereich. Der Text eines
Lösungsschrittes (Datenbankspalte „HtmlCodePartXml“) lässt sich, genau wie der eines Hilfeartikels, mittels der Word-Integration bearbeiten.
Abbildung 4.8: Pflegeoberfläche für Probleme und Lösungen
60
Ein weiteres Merkmal im Bereich der Probleme und Lösungen ist die
Wiederverwendbarkeit durch Textparameter (siehe Abschnitt 3.5). Ein
Textparameter lässt sich in sämtlichen Texten und Beschreibungen einsetzen und wird nach folgender Syntax aufgebaut:
@[Name|Standardwert]
Der Benutzer kann den Textparameter direkt im Text eingeben oder
einen speziellen Dialog (siehe Abbildung 4.9) verwenden, der über das
Tastaturkürzel STR+P aufgerufen werden kann. Die verwendeten Textparameter werden zur Übersicht unter dem Reiter „Textparameter“
noch einmal aufgelistet (siehe Abbildung 4.8).
Abbildung 4.9: Bearbeitung von Textparametern
Symptome
Bei der Bearbeitung eines Symptoms (Datenbanktabelle „Symptom“, siehe Abbildung 4.4) können wie üblich ein Name und eine Beschreibung
angegeben werden. Der Name soll das Symptom bzw. die Symptome
möglichst eindeutig und für den Benutzer verständlich beschreiben. Ähnlich wie bei den Hilfeartikeln lassen sich verschiedene Anwendungskontexte verknüpfen und / oder eine Bedingung direkt angeben.
61
Abbildung 4.10: Pflegeoberfläche für Symptome
Außerdem lassen sich noch die Probleme festlegen, welche das Symptom hervorrufen können. Hierzu können unter dem Reiter „Probleme“
einer Liste ein oder mehrere Probleme hinzugefügt werden. An dieser
Stelle können auch die Werte der verfügbaren Textparameter gesetzt
werden (siehe Abbildung 4.11).
62
Abbildung 4.11: Verknüpfung von Problemen zu Symptomen mit Definition eines Textparameterwertes
4.5 Kontextprovider
Für die Kontextermittlung müssen die im Abschnitt 3.4.1 erwähnten
Typen von Kontextprovidern implementiert und in die „Diomex Framework“-Klassenbibliothek eingebunden werden. Bei der Implementierung
ist darauf zu achten, dass sich neue Kontextprovider einfach realisieren
lassen. In diesem Abschnitt werden die Merkmale der entwickelten
Klassenstruktur beschrieben. Zum besseren Verständnis kann das UMLKlassendiagramm aus Abbildung 4.12 herangezogen werden.
Für die Entwicklung einer Kontextprovider-Klasse stehen zwei abstrakte Oberklassen zur Verfügung – ContextProviderWithState und ContextProviderWithoutState. Der ContextProviderWithState wird dann
4.5 KONTEXTPROVIDER
63
verwendet, wenn der Kontextprovider externe Zustandsinformationen
benötigt, um die von ihm unterstützten Werte zu ermitteln. Ein Beispiel
hierfür ist der Kontextprovider für Fehlerinformationen (ExceptionContextProvider), der für die Ermittlung ein gefangenes Fehlerobjekt
benötigt. Da diese Zustandsobjekte von beliebigen Typen seien können,
ist diese Oberklasse generisch bezüglich des Zustandstypens. Die zweite
Oberklasse, der ContextProviderWithoutState, benötigt für die Kontextermittlung kein weiteres Zustandsobjekt und besitzt deshalb auch keinen generischen Parameter.
Die beschriebenen Oberklassen erben wiederum selber von der abstrakten Oberklasse ContextProvider, die gemeinsame Eigenschaften und
Methoden zusammenfasst. Hervorzuheben ist hier die abstrakte Methode DefineProperties, die bei der Entwicklung eines Kontextproviders implementiert werden muss. In dieser Methode wird definiert, welche Werte vom Kontextprovider unterstützt werden. Eine Wertdefinition beinhaltet einen Namen und einen Wertetyp für den Formelinterpreter. Außerdem verlangt der Konstruktor der ContextProvider-Klasse die Angabe
einer ID, eines Namens und einer Beschreibung. Unter diesem Namen
kann der Kontextprovider bei der Formulierung einer Bedingung angesprochen werden.
Weiterhin muss beim Entwurf eines Kontextproviders durch die Vererbung der ContextProviderWithState- bzw. ContextProviderWithoutState-Klasse die Methode SetApplicationContextPropertyValues implementiert werden. In dieser Methode wird die eigentliche Aufgabe des
Kontextproviders durchgeführt – und zwar das Ermitteln der Werte für
die unterstützten Kontexteigenschaften. Diese Methode bekommt ein
ApplicationContext-Objekt übergeben, welches die ermittelten Werte
aufnimmt. Erbt der Kontextprovider von der ContextProviderWithStateKlasse bekommt die Methode noch zusätzlich das Zustandsobjekt übergeben.
Beim Entwurf eines neuen Kontextprovidertypen muss also lediglich
eine Klasse mit der entsprechenden Oberklasse entwickelt werden, welche eine Methode zur Definition und eine Methode zur Ermittlung der
unterstützten Kontexteigenschaften implementiert.
64
Abbildung 4.12: UML-Klassendiagramm der
Kontextproviderkomponenten
4.6 Ermittlung der Hilfeinformationen
Bereits bei der Erläuterung des Konzeptes wurde im Abschnitt 3.6 die
Strategie zur Ermittlung der Hilfeinformationen vorgestellt. Nachfolgend soll diese Strategie und die nötigen Schritte zur Ermittlung vertieft
werden. Dabei wird nicht auf den konkreten Quellcode eingegangen, da
dieser zu viele technische Details aufweist. An Stelle dessen wird vielmehr der generelle Ablauf in Form von durchzuführenden Schritten
verdeutlicht.
1. Formelparser instanziieren
Als erstes wird eine Instanz des Formelparsers erzeugt. Dieser ist für
die Validierung der Formeln zuständig und benötigt für die Ersetzung der Kontextprovider-Referenzen die tatsächlich übermittelten
4.7 FORMAT DER HILFEARTIKEL
65
Werte. Der Formelparser ist eine Komponente aus der DFWKlassenbibliothek und musste deshalb nicht neu entwickelt werden.
2. Potentielle Hilfeartikel und Symptome ermitteln
Hilfeartikel als auch Symptome können eine direkt definierte Bedingung besitzen. Deshalb können die vorhandenen Hilfeartikel/Symptome auf die Instanzen eingeschränkt werden, für die entweder keine Bedingung definiert wurde, oder diese bei der Validierung durch den Formelparser den Wert „Wahr“ ergeben.
3. Anwendungskontexte auswerten
Nachdem die potentiellen Hilfeartikel/Symptome ermittelt wurden,
müssen schließlich noch die Formeln der mit ihnen verbundenen Anwendungskontexte ausgewertet werden. Hierfür wird ebenfalls der
Formelparser eingesetzt. Nur die Hilfeartikel/Symptome bei denen
die Validierung aller Anwendungskontexte zutrifft werden weiterverarbeitet. Die Validierungsergebnisse der Anwendungskontexte werden in einer Liste zwischengespeichert, da diese sonst durch die
mehrfachen Verknüpfungen auch mehrfach überprüft werden müssten.
4. Ermittlung der Probleme, Lösungen und Lösungsvarianten
Zu den ermittelten Symptomen müssen schließlich noch die verknüpften Probleme aus der Datenbank geladen werden. Zu diesen müssen
wiederum die entsprechenden Lösungen und deren unterschiedliche
Varianten ermittelt werden. Da auch die Lösungsvarianten Verknüpfungen zu Anwendungskontexten enthalten, muss hier ebenfalls die
Gültigkeit mit Hilfe des Formelparsers und der bisher ermittelten
Ergebnisse überprüft werden.
5. Transformierung des Ergebnisses
Zum Schluss gilt es noch die Ergebnisse für den Transport und die
Ausgabe aufzubereiten. Hierfür wird ein spezielles Format erzeugt,
welches im folgenden Abschnitt beschrieben wird.
4.7 Format der Hilfeartikel
Bei der Entwicklung eines jeden Hilfesystems gilt es ein geeignetes Format für die Hilfeartikel zu definieren. Hierbei sollten die Aspekte der
unterschiedlichen Möglichkeiten zur Formatierung, Transportierbarkeit
66
oder Verlinkung betrachtet werden. Bei der Entwicklung des DHS‘ galten die Anforderungen, dass sich Texte samt Bilder über das „Management Studio“ pflegen und für die Anzeige zum Benutzer transportieren
lassen. Da genau diese Merkmale durch HTML-Dokumente unterstützt
werden, fiel die Wahl des Formates der Hilfeartikel auf diese Auszeichnungssprache. In diesem Abschnitt soll die Realisierung der Pflege, des
Transports und der Darstellung nur knapp dargestellt werden, da diese
Themen nicht zum Kern dieser Arbeit gehören.
Die Pflege der Hilfeinformationen im HTML-Format erfolgt über das
Textverarbeitungsprogramm „Microsoft Word“, welches eine Bearbeitung
von HTML-Texten erlaubt. Das Programm kann für die Pflege der Hilfeartikel und Lösungsschritte direkt aus dem „Management Studio“ gestartet werden (siehe Abbildung 4.13). Nachdem die Bearbeitung in
Word angeschlossen ist, werden die Inhalte nach der Speicherung in das
„Management Studio“ übernommen.
Abbildung 4.13: Word-Integration für die Pflege
der Hilfe- und Lösungstexte
Für die Speicherung in der Datenbank und den Transport zum Benutzer werden die HTML-Dateien und die darin verwendeten Ressourcen,
wie z.B. Bilder oder CSS-Dateien, zu einer einzigen XML-Datei umgewandelt. In dieser Datei sind die Quelltexte im Klartext und sämtliche
Ressourcen in serialisierter Form abgelegt. Für die Anzeige beim Benutzer wird die Datei komprimiert übertragen und auf dem Benutzersystem
wieder entpackt. Die Anzeige selbst erfolgt in einem Browserbedienelement welches im Anzeigefenster eingebunden ist (siehe Abbildung 4.14).
4.7 FORMAT DER HILFEARTIKEL
67
Abbildung 4.14: Anzeige eines Symptoms und des Problems samt Lösungen im Hilfefenster des DHS‘ (erstes Problem angezeigt)
Da im Hilfefenster mehrere Hilfeartikel, Symptome, Lösungen und
Lösungsvarianten angezeigt werden können, lassen sich sämtliche Elemente für eine bessere Übersicht durch den Benutzer ein- und ausklappen (vgl. Abbildung 4.14 und Abbildung 4.15).
68
Abbildung 4.15: Anzeige eines Symptoms mit mehreren Problemen samt
Lösung im Hilfefenster des DHS‘ (zweites Problem angezeigt)
4.8 Aufruf der Hilfefunktion
Um die Hilfe des DHS‘ innerhalb einer Anwendung aufrufen zu können,
muss zunächst die Klassenbibliothek des DFW’s in Form einer DLLDatei eingebunden werden. Danach stehen die nötigen Funktionen zum
Verbindungsaufbau, sowie zum Absenden und Anzeigen einer Hilfeanfrage zur Verfügung. Ob die Hilfe über das Menü, die F1-Taste oder eine
andere Methode aufgerufen wird, ist von der jeweiligen Anwendung abhängig. Eine geeignete Stelle für die Implementierung einer Hilfefunktion ist das OnHelpRequest-Event welches von der .NET-Dialog-Klasse
unterstützt wird. Dieser Event wird dann aufgerufen, wenn der Benutzer
4.8 AUFRUF DER HILFEFUNKTION
69
den Hilfe-Button eines Fensters auswählt, oder die F1-Taste betätigt.
Nachfolgend sollen die nötigen Schritte zum Aufruf einer Hilfe anhand
von Codebeispielen aufgezeigt werden.
1. Herstellen einer Serververbindung
var serverConnection = new Diomex.Framework.Services.Client.ServerConnection();
2. Erzeugen einer Hilfeanfrage
var helpRequest = serverconnection.CreateHelpRequest();
3. Hinzufügen von Kontextprovidern mit Zustandsinformationen (optional)
var exceptionContext = Diomex.Framework.HelpDesk.ApplicationContextType.Exception.Create(someException);
helpRequest.AddApplicationContext(exceptionContext);
4. Hilfeanfrage absenden
var result = helpRequest.GetHelpDeskHtmlPackageResponse();
5. Ergebnis anzeigen
var dialog = new Diomex.Framework.UI.WinForms.HelpDesk.HelpItemsViewer(result);
dialog.ShowDialog();
Kapitel 5
Bewertung
In diesem Kapitel soll eine Bewertung des Konzeptes und der Realisierung erfolgen. Hierfür wäre eine Evaluierung der ersten Erfahrungen
aus dem Praxiseinsatz notwendig. Das DHS‘ ist bereits auf dem DFWServices Server installiert und auch die Administration über das „Management Studio“ ist möglich. Rein technisch ist der Einsatz des neuen Hilfesystems zum jetzigen Zeitpunkt möglich. Für ein Pilotprojekt wurden
bereits ein Produkt und ein Kunde abgestimmt, allerdings konnte der
Start aufgrund von strategisch wichtigeren Projekten bisher noch nicht
koordiniert werden. Deshalb sollen in diesem Kapitel konkrete Anwendungsbeispiele mit Bezug zu den im Einsatz befindlichen Produkten analysiert werden, um schließlich eine Beurteilung der Ergebnisse vorstellen
zu können.
5.1 Anwendungsbeispiele
Die folgenden Anwendungsbeispiele sollen die Einsatzmöglichkeiten des
DHS‘ aufzeigen.
Erweiterte kontextsensitive Hilfe zu Bedienelementen und Dialogen am Beispiel „Formeleditor“
Durch den „UI-“ und den „UIFocus-Kontextprovider“ (siehe Abschnitt
3.4.1) lässt sich eine Form der Hilfe realisieren, die vergleichbar zur
klassischen kontextsensitiven Hilfe (siehe Abschnitt 2.1.1) ist. Hierbei
wird eine Hilfe angeboten, die sich nach dem aktiven Bedienelement
bzw. dem aktivem Dialog richtet. Da durch die Kontextprovider auch
eine Betrachtung der Zustände der Bedienelemente erfolgen kann, lässt
71
72
KAPITEL 5 BEWERTUNG
sich die Hilfe an dieser Stelle sogar noch verfeinern. Nachfolgend soll
diese Methode am Beispiel des „Formeleditors“ vorgestellt werden.
Abbildung 5.1: „Formeleditor“-Dialog
Der „Formeleditor“-Dialog (siehe Abbildung 5.1) wird in vielen Anwendungen von Diomex eingesetzt. Im Produkt „XcalibuR“ lassen sich
z.B. anhand einer Formel Daten zur Überführung umformatieren, um sie
so dem Format des Zielsystems anzupassen. Hierbei kann auf eine Vielzahl von Funktionen zurückgegriffen werden, die in der Hilfedatei zum
Produkt beschrieben sind. Um dem Benutzer hier einen direkten Zugriff
auf die Funktionsreferenz geben zu können, soll das DHS eingesetzt
werden. Hierfür muss lediglich ein entsprechender Hilfeartikel angelegt
werden, der über die folgende Bedingung dem „Formeleditor“-Dialog zugeordnet wird:
UI.DialogType = "Diomex.Framework.UI.WinForms.
EditFormulaDialog"
Eine Verfeinerung der Hilfe kann erfolgen, indem überprüft wird,
welche Funktionen bereits im Textfeld eingegeben worden sind. In der
Abbildung 5.1 wären dies z.B. die Funktionen PadLeft und Str. Legt
man für jede Funktion einen eigenen Hilfeartikel an, überprüft die folgende Bedingung, ob eine bestimmte Funktion verwendet wird:
IndexOf(UI.ControlValues["txtFormula"],
"Name Der Funktion") != -1
5.1 ANWENDUNGSBEISPIELE
73
Das Ergebnis der Hilfeanfrage ist in der folgenden Abbildung zu sehen.
Abbildung 5.2: Hilfe zum „Formeleditor“-Dialog
Allgemeine Programmhilfen und Konzepterläuterungen
Allgemeine Programmhilfen und Konzepterläuterungen lassen sich ähnlich wie die erweiterten kontextsensitiven Hilfen zu Bedienelementen
und Dialogen umsetzen. Hierbei wird die Hilfe nicht an ein bestimmtes
Bedienelement sondern an die Hauptanwendung gekoppelt, die sich über
die Dialoghierarchie des „UI-Kontextproviders“ ermitteln lässt.
Direkte Hilfe bei Ausnahmefehlern
Unbehandelte Fehler die in Anwendungen auftreten können sollten
grundsätzlich angezeigt und protokolliert werden. Diomex verwendet
74
KAPITEL 5 BEWERTUNG
hierfür einen eigenen Dialog, der den aufgetretenen Fehler anzeigt und
dem Benutzer die Möglichkeit gibt, dem Report zusätzliche Informationen anzuhängen (siehe Abbildung 5.3). In der Regel werden solche Fehler durch das nächste Programmupdate behoben. In einigen Fällen kann
die Behebung des Fehlers allerdings ein umfangreicheres Update erfordern. Bis dahin sollte der Benutzer eine entsprechende „erste Hilfe“ zur
Ursache und Behebung bzw. Vermeidung des Fehlers erhalten, falls diese vorhanden sind. Zu diesem Zweck kann das DHS eingesetzt werden,
indem die entsprechenden Symptome mit ihren Problemen und Lösungen angelegt werden. Diese können über die Eigenschaften des
„Exception-Kontextproviders“ (siehe Abschnitt 3.4.1) gekennzeichnet
werden. Über die Eigenschaft „Type“ kann eine allgemeine Hilfe zum
Fehlertypen formuliert werden. Mittels der „Exception-Hash“Eigenschaft lässt sich ein bestimmter Fehler auch eindeutig identifizieren.
Abbildung 5.3: Fehlerreport-Dialog mit Möglichkeit
zum Aufruf einer Hilfe
Adaptierte Hilfeinformationen am Beispiel „Dienst neu starten“
Eine Hilfestellung ist für einen unerfahrenen Benutzer besonders dann
gut zu handhaben, wenn sie ihm Schritt für Schritt und anhand von
Screenshots erklärt, was zu tun ist. Dies ist allerdings genau dann nicht
5.2 BEURTEILUNG DER ERGEBNISSE
75
möglich, wenn die Hilfe auch Aktionen mit dem Betriebssystem beinhaltet, denn diese können je nach Version unterschiedliche Abläufe und
Screenshots aufweisen. Um eine Anpassung der Hilfe an das Betriebssystem zu erzielen, können verschiedene Versionen von Hilfeartikeln mittels der „OSVersion“-Eigenschaft des „Machine-Kontextproviders“ zugeordnet werden.
In der Hilfe zum Produkt „Stardust“ existiert z.B. ein Artikel, der beschreibt, wie man einen Neustart des Druckwarteschlangen-Dienstes
von Windows durchführt. An dieser Stelle ließe sich mittels des DHS‘
eine zum Betriebssystem konsistente Version der Hilfe bereitstellen, um
dem Benutzer nicht durch falsche Anweisungen und Screenshots zu irritieren.
Unterstützung von Symptomen am Beispiel „Formeleditor“
Im DHS lassen sich neben den Hilfeartikeln auch Symptome mit ihren
Probleme und Lösungen definieren. Hierzu werden die Symptome eines
potentiellen Problems anhand der Anwendungskontexte beschrieben. Als
Beispiel kann hierfür ebenfalls der oben beschriebene Formeleditor herangezogen werden. In diesem Dialog lässt sich ein Problem bei der Formeleingabe anhand des Fehlertextes unter der Textbox identifizieren
(siehe Abbildung 5.2). Ist ein Fehlertext vorhanden, könnten dem Benutzer sogar unterschiedliche Lösungsvarianten anhand bestimmter Schlüsselwörter aus dem Fehlertext angeboten werden, wie z.B. eine Lösung
bei inkorrekter Klammerung wenn das Schlüsselwort „brackets“ im Fehlertext vorhanden ist.
5.2 Beurteilung der Ergebnisse
Neben der ausführlichen kritischen Betrachtung und Beurteilung des
Konzeptes aus Abschnitt 3.7 sollen in diesem Abschnitt weitere Ergebnisse dargestellt werden.
Zunächst ist die Flexibilität des hier entwickelten Hilfesystems anzumerken, die anhand der Vielfältigkeit der vorher in diesem Kapitel
beschriebenen Einsatzmöglichkeiten deutlich wird. Mit Hilfe des DHS
lassen sich sowohl eine (erweiterte) kontextsensitive Hilfe als auch allgemeine Programmhilfen und Konzepterläuterungen umsetzen. Weiterhin bietet das DHS eine Unterstützung für eine „erste Hilfe“ bei Programmfehlern und eine Möglichkeit problembehaftete Situationen und
deren Lösungen zu beschreiben. Die Einsatzmöglichkeiten lassen sich
76
KAPITEL 5 BEWERTUNG
sogar durch die Entwicklung neuer Kontextprovider weiter ausweiten.
Außerdem ist durch die Kombination der Werte verschiedener Kontextprovider in einer formulierten Bedingung eine Beschreibung von sehr
komplexen hilfeerfordernden Situationen möglich. Durch diese Flexibilität kann dem Benutzer einerseits eine gezielte und andererseits eine
weitgefasste und allgemeinere Unterstützung angeboten werden.
Mit dieser Flexibilität steigt allerdings auch der administrative Aufwand bei der Erstellung und Pflege der Hilfeinformationen. Neben den
eigentlichen Hilfeinformationen müssen noch weitere Datensätze, wie
z.B. Symptome, Probleme, Lösungen und Anwendungskontexte angelegt
und definiert werden. Bei dieser Aufgabe könnte der Redakteur durch
den Einsatz von Wizards unterstützt werden (siehe Abschnitt 6.2).
Außerdem ist darauf zu achten, dass die Kopplung der Hilfeinformationen, die durch die Formulierung bestimmter Bedingung erzielt wurde,
nicht verloren geht. Dies ist z.B. dann der Fall, wenn in einer Bedingung
mittels des Namens ein bestimmtes Bedienelement angesprochen wird,
und dieser Name später z.B. innerhalb eines Re-Engineering-Prozesses
geändert wird. In solchen Situationen sollten die Bedingungen der involvierten Hilfeinformationen ebenfalls aktualisiert werden.
Eine weitere Aufgabe des Hilferedakteurs besteht darin, die Hilfe „zu
testen“, denn die verfassten Hilfebeiträge werden nur dann beim Benutzer angezeigt, wenn deren Bedingungen passend definiert worden sind.
Deshalb sollte der Hilferedakteur die entsprechende hilfeerfordernde
Situation „nachstellen“ und das Ergebnis des Hilfeaufrufs validieren.
Für diese Aufgabe könnte ein spezieller Testmodus eingeschaltet werden
(siehe Abschnitt 6.2).
Bei der Gestaltung der Hilfetexte kommt das Textverarbeitungsprogramm „Word“ zum Einsatz, welches durch seine Bekanntheit für die
meisten Redakteure keine Einarbeitung erfordert. Außerdem ist „Word“
im Vergleich zu den Gestaltungskomponenten anderer Hilfesysteme sicherlich eine gute Alternative. Als einzige Einschränkung ist hier der
„Weblayout-Modus“ zu nennen, indem „Word“ bei der Bearbeitung ausgeführt wird und durch den einige Funktionen des Programms nicht verfügbar sind.
In Punkto „Aktualität“ wird durch die Ablösung der bisher eingesetzten Hilfedateien durch das DHS ebenfalls ein Vorteil für den Benutzer
erzielt, da die Hilfeinformationen online vom DFW-Services Server abgerufen werden. Somit erhält der Benutzer stets die aktuellste Fassung der
Hilfe und auch Diomex muss nicht dafür Sorge tragen, dass neue Versionen der Hilfe zum Kunden ausgeliefert werden müssen. Ein Nachteil
5.2 BEURTEILUNG DER ERGEBNISSE
77
kann dann entstehen, wenn der Benutzer die gesamte Hilfe benötigt, um
sie z.B. zu speichern oder „offline“ zu studieren. Die Erkenntnisse aus
den Grundlagen haben jedoch gezeigt, dass die meisten Benutzer eine
Hilfe nur dann aufrufen, wenn sie eine Frage oder ein Problem haben.
Das Ziel ein System zu entwickeln, welches anhand von automatisch
identifizierter Kontextinformationen eine angepasste Hilfe ermittelt, um
somit die bisher eingesetzten „HTML-Help“-Dateien zum Vorteil für den
Benutzer abzulösen, wurde zumindest im Rahem der vorgestellten Anwendungsbeispiele in vollem Umfang erfüllt. Da die erwähnten Anwendungsbeispiele vom Prinzip den Großteil der geplanten Einsatzmöglichkeiten abdecken, wird auch dem Praxiseinsatz positiv entgegengesehen.
Kapitel 6
Zusammenfassung und Ausblick
Innerhalb dieses Kapitels werden die wichtigsten Aspekte dieser Arbeit
noch einmal abschließend zusammengefasst. Zusätzlich wird ein kurzer
Ausblick über eine mögliche Weiterentwicklung des hier vorgestellten
Konzeptes gegeben.
6.1 Zusammenfassung
Die grundlegende Motivation dieser Arbeit bestand darin, ein Hilfesystem zu entwickeln, welches dem Benutzer eine bessere Unterstützung
gegenüber herkömmlicher Hilfemethoden bieten kann.
Zu diesem Zweck wurden zunächst die bekannten Hilfemethoden vorgestellt um sie schließlich aus Sicht des Benutzers kritisch betrachten zu
können. Hierbei stellte sich heraus, dass Benutzer unter anderem den
Aspekt einer guten Zugänglichkeit zu hilfreichen Informationen besonders schätzen. Gerade diese Eigenschaft wird sichtens der Benutzer von
den derzeitigen Hilfesystemen nicht zufriedenstellend erfüllt. Aufgrund
dieser Unzufriedenheit tendieren die meisten Benutzer dazu, in Problemsituation auf eine menschliche Unterstützung zurückzugreifen.
Selbst Microsoft rät in schwierigen Fällen: „Fragen Sie einen Freund“.
Der Vorteil der menschlichen Kommunikation ist die Eigenschaft, dass
situationsabhängige bzw. kontextuelle Informationen implizit hergeleitet
werden können, um die Kommunikation anzureichern. Unter dieser Erkenntnis wurde die Verwendung von Kontextinformationen als Optimie79
80
KAPITEL 6 ZUSAMMENFASSUNG UND AUSBLICK
rungspotential für die Entwicklung eines neuen Konzeptes herangezogen.
Das Konzept basiert darauf, dass Hilfeinformationen bei ihrer Erstellung mit bestimmten Kontextinformationen „markiert“ werden. Die einzelnen Kontextinformationen können mittels einer Formel zu einer Bedingung kombiniert werden, die ausdrückt, in welcher Situation die entsprechende Hilfe benötigt wird. Durch diese Formulierung und die Verwendung unterschiedlichster Typen von Kontextinformationen können
sehr komplexe aber auch einfache Situationen formuliert werden. Durch
diese flexible Gestaltung kann das DHS in vielen Bereichen eingesetzt
werden.
Eine weitere Erkenntnis aus der Literatur ist, dass die Benutzer in
Problemsituationen oft auf Schwierigkeiten bei der korrekten Beschreibung des Kontextes stoßen. Deshalb werden die Kontextinformationen
beim Aufruf der Hilfe automatisch durch die Anwendung ermittelt. Hierzu wurde das Konzept der Kontextprovider entwickelt. Der Kontextprovider ist eine leicht zu erweiternde Programmkomponente, die für die
Ermittlung unterschiedlicher Kontextinformationen, wie z.B. Informationen über das System oder den Zustand der Programmoberfläche zuständig ist.
Nach der Konzeption wurde die Implementierung des DHS‘ vorgestellt. Hierbei wurde insbesondere auf die Integration in die bestehende
Softwareumgebung „Diomex Framework Components“ eingegangen. Es
wurde beschrieben, wie die Hilfeinformationen verwaltet, gespeichert,
ermittelt und angezeigt werden. Außerdem wurden die Implementierung
der Kontextprovider und deren Erweiterbarkeit vertieft.
Abschließend wurden die Ergebnisse des entwickelten Systems anhand von Anwendungsbeispielen beurteilt, da Ergebnisse aus dem Praxiseinsatz zum Zeitpunkt dieser Arbeit noch nicht vorlagen. Es stellte
sich heraus, dass das System durch seine Flexibilität in vielen Anwendungsfällen einsetzbar ist, und die bisherige Hilfe vollständig ablösen
kann.
6.2 Ausblick
Obwohl das Ergebnis die zuvor definierten Anforderungen vollständig
erfüllt, ergaben sich durch die Analyse der erzielten Ergebnisse weitere
Aufgaben, die zur Verbesserung und Ausweitung des DHS‘ führen. In
6.2 AUSBLICK
81
diesem Abschnitt werden die Aspekte einer möglichen Weiterentwicklung vorgestellt.
Ein Teil der möglichen Verbesserungen bezieht sich auf die Pflege und
Verwaltung der Hilfeinformationen. Bei der Verwaltung der Hilfedatensätze im Objekt-Explorer (siehe Abbildung 4.5) sollte die Möglichkeit
geschaffen werden, diese in einer Ordnerstruktur zu arrangieren, damit
bei einer Vielzahl von Datensätzen eine Kategorisierung vorgenommen
werden kann. Außerdem sollten für bestimmte Aktionen, wie z.B. das
Anlegen einer neuen Problemlösung, Wizards entwickelt werden, die den
Redakteur bei der Erledigung dieser Aufgaben unterstützen. Zusätzlich
sollte die Hilfeanfrage um einen „Testmodus“ erweitert werden. Ist dieser Testmodus aktiviert, sollte sich der Benutzer vor dem Absenden der
Hilfeanfrage die Werte der Kontextprovider anzeigen lassen können,
sowie diese ggf. nachträglich anpassen können. So erhält der Redakteur
die Möglichkeit seine Hilfe mit unterschiedlichen Werten der Kontextprovider zu „testen“.
Eine weitere wünschenswerte Funktion wäre die Protokollierung der
Hilfeanfragen zu Analysezwecken. Somit ließen sich z.B. nicht abgedeckte Hilfethemen ermitteln, indem die Suchanfragen analysiert werden,
die zu keinem Ergebnis geführt haben. Weiterhin könnten durch eine
Statistik besonders problematische Dialoge oder Bedienelemente identifiziert werden.
Zur weiteren Unterstützung des Benutzers wäre es denkbar, bestimmte Hilfeanweisungen mit Aktionen zu hinterlegen, die auf Wunsch
die beschriebene Anweisung automatisch ausführen, wie z.B. das Öffnen
eines bestimmten Dialoges, wenn dies in der Hilfeanweisung beschrieben
wird. Weiterhin wäre es aus Sicht des Benutzers hilfreich, wenn sich die
Hilfeartikel untereinander zu einer Hierarchie verknüpfen ließen, wie
man sie in den Kapiteln und Abschnitten eines Buches vorfindet. So hätte der Benutzer die Möglichkeit verwandte Hilfethemen anhand der Verknüpfungen aufzurufen, um so von der punktuellen Information zur Gesamtheit eines Themas zu gelangen.
Würde sich in Zukunft ein derartiges Konzept zur Hilfeermittlung
durchsetzen, wäre es auch denkbar, wenn eine standardisierte Schnittstelle zur Abfrage von Kontextinformationen bestünde. Diese könnte
dann nativ vom Betriebssystem sowie von den ausgeführten Anwendungen unterstützt und durch unterschiedliche Hilfesysteme verwendet
werden. Dies ist ein sehr hypothetischer Gedanke, allerdings wird davon
ausgegangen, dass ein hochentwickeltes Hilfesystem nicht ohne die Verwendung von Kontextinformationen auskommt.
Anhang
A. Informationen zur beigelegten CD
Auf der Innenseite des Buchrückens befindet sich eine CD mit folgenden
Materialien zu dieser Diplomarbeit:
1. Die Ausarbeitung dieser Arbeit als PDF-Datei
2. Eine Windows-Anwendung zur Demonstration der Funktionen des DHS‘
Führen Sie zur Installation der Demo-Anwendung die Datei „DMXInstaller.exe“ im Verzeichnis „Framework Demo“ aus. Da bei der Installation die aktuellsten Dateien vom Update-Server geladen werden, muss eine Verbindung zum Internet bestehen. Bei den einzelnen
Schritten der Installation können die Standardeinstellungen beibehalten werden und Sie können jeden Schritt mit „Weiter“ bestätigen.
Eine eventuelle Fehlermeldung über die Registrierung der Lizenz
können Sie ignorieren. Nach der Installation können Sie die Anwendung über den Startmenüeintrag Start  Programme  Diomex
Software  Framework Services  Framework Demo starten.
Hinweis: Im Installationspaket ist das „Management Studio“, welches für die Administration der Hilfeinformationen benötigt wird,
nicht enthalten. Dieses kann jedoch bei Bedarf per E-Mail unter
[email protected] angefragt werden.
83
Literaturverzeichnis
.NET. (2010). Abgerufen am 5. Mai 2010 von Wikipedia:
http://de.wikipedia.org/wiki/.NET
Application Compatibility: Help Engine Support. (2010). Abgerufen am
22. März 2010 von MSDN: http://msdn.microsoft.com/enus/library/bb757030.aspx
Baltrunas, L. (2008). Exploiting Contextual Information in Recommender
Systems.
Bauder, I. (2008). Microsoft SQL Server 2008 für Administratoren.
Beisse, F. (2009). A Guide to Computer User Support for Help Desk and
Support Specialists.
Carroll, J. M., & Rosson, M. B. (1987). Paradox of the active user.
Desmarais, M. C., Leclair, R., Fiset, J.-Y., & Talbi, H. (1997). CostJustifying Electronic Performance Support.
Dey, A. K. (2001). Understanding and Using Context.
Firefox-Support-Chat. (2010). Abgerufen am 17. März 2010 von
irc://irc.mozilla.org#firefox.de
Houghton, R. C. (1984). Online Help System: A Conspectus.
Li, H., Vukovi, M., Pingali, G., & Lee, W.-C. (2009). SolutionFinder:
Intelligent Knowledge Integration and Dissemination for Solution
Retrieval in IT Support Services.
Microsoft Assistance Markup Language. (25. Juni 2009). Abgerufen am
12. März 2010 von Wikipedia:
http://en.wikipedia.org/wiki/Microsoft_Assistance_Markup_Language
Mitchell, G. E. (1993). What Do Users Really Want From Computer
Documentation?
Nielsen, J. (1993). Usability Engineering.
Novick, D. G., & Ward, K. (2006). What Users Say They Want in
Documentation.
Novick, D. G., & Ward, K. (2006). Why Don’t People Read the Manual?
85
86
LITERATURVERZEICHNIS
Nückles, M., & Ertelt, A. (2006). The problem of describing a problem:
Supporting laypersons in presenting their queries to the Internet-based
helpdesk.
Pilkington, R. M. (1992). Question-Answering for Intelligent On-Line
Help : The Process of Intelligent Responding.
Randall, N. P. (1998). Who exactly is trying to help us? The Ethos of Help
Systems in Popular Computer Applications.
Samulowitz, M. (2002). Kontextadaptive Dienstnutzung in Ubiquitous
Computing Umgebungen .
Symptom. (kein Datum). Abgerufen am 15. April 2010 von Wikipedia:
http://de.wikipedia.org/wiki/Symptom
Thiemann, P. (2008). Benutzerfreundliche Online-Hilfen.
Turk, K. L. (96). Online Help Systems: Technological Evolution or
Revolution?
Vouligny, L., & Rober, J.-M. (2005). Online Help System Design Based on
the Situated Action Theory.
Yeats, D. (2004). Revising Documentation Deliverables Based on
Usability.

Konzeption und Entwicklung eines anwendungskontextorientierten

Transcrição

Documentos relacionados

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

Phishing und Pharming: Diebstahl im Netz

Benutzerordnung - Albertus Magnus Gymnasium Friesoythe

Office 365 Admin Center – First Steps - RZ

Netzlaufwerk(e) verbinden – Alt- und KIT- Welt

Bedeutung von Peer-to-Peer Technologien für die

serveTM 600 - Bibliotheca

vSFTPd-Handbuch

Abstract

Übung 1