Konzeption und Entwicklung eines anwendungskontextorientierten
Transcrição
Konzeption und Entwicklung eines anwendungskontextorientierten
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 KAPITEL 2 HILFESYSTEME 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 KAPITEL 2 HILFESYSTEME 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 KAPITEL 2 HILFESYSTEME <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 KAPITEL 2 HILFESYSTEME 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 KAPITEL 2 HILFESYSTEME 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 KAPITEL 2 HILFESYSTEME 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 KAPITEL 2 HILFESYSTEME 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). 2.3 KONTEXTSENSITIVER ZUGRIFF 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 KAPITEL 2 HILFESYSTEME 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- 2.3 KONTEXTSENSITIVER ZUGRIFF 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 KAPITEL 2 HILFESYSTEME (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 KAPITEL 2 HILFESYSTEME 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. 3.4 VORSTELLUNG DER KOMPONENTEN 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. 3.4 VORSTELLUNG DER KOMPONENTEN 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- 3.4 VORSTELLUNG DER KOMPONENTEN 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 KAPITEL 4 REALISIERUNG 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 KAPITEL 4 REALISIERUNG 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 KAPITEL 4 REALISIERUNG 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 KAPITEL 4 REALISIERUNG 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 4.4 PFLEGE DER HILFEINFORMATIONEN 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 KAPITEL 4 REALISIERUNG 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 4.4 PFLEGE DER HILFEINFORMATIONEN 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 KAPITEL 4 REALISIERUNG 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. 4.4 PFLEGE DER HILFEINFORMATIONEN 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 KAPITEL 4 REALISIERUNG 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 KAPITEL 4 REALISIERUNG 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 KAPITEL 4 REALISIERUNG 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 KAPITEL 4 REALISIERUNG 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.