| Aktuelle Artikel und Nachrichten rund um die technische Dokumentation finden Sie im Nachfolgemagazin der doculine news, den transline tecNews
Die Potenziale von Online-Hilfe besser ausschöpfen
Artikel erschienen in
Ausgabe Mai 2002
Von Matthias
Hattemer und Michael
C. Enderstein
Inhaltsübersicht:
Warum ruft der Anwender einer Software
eine Online-Hilfe auf? Was will er erfahren? Was interessiert
ihn und was will er nicht wissen? Für technische Autoren,
die Online-Hilfen erstellen, ist diese Frage nach dem Grund und
Hintergrund der Nutzung einer Online-Hilfe eminent wichtig. Denn
je genauer Online-Hilfen auf die Wissens- und Interessenlage des
Benutzers Bezug nehmen, desto besser sind sie.
Dabei können wir – ohne ins Fachliche und damit in
die Besonderheiten jeder einzelnen Online-Hilfe einsteigen zu
müssen – zwei typische Situationen annehmen, die zum
Aufruf eines Hilfetextes führen:
- Der Anwender befindet sich in einem Dialogfenster und weiß
mit einem Feld oder einem Element dieses Kontextes nichts anzufangen.
Ruft er eine Hilfe in diesem Kontext auf, erwartet er Informationen
zu dem Dialogfenster oder einzelnen Feldern.
- Der Anwender steckt irgendwo in einem Arbeitsprozess fest
und weiß nicht, wie er eine bestimmte Aufgabe mit der
Software umsetzen und lösen soll. Wenn er jetzt die Online-Hilfe
aufruft, sucht er Unterstützung und Rat nicht in einem
bestimmten funktionalen Kontext, sondern in einem wesentlich
abstrakteren, globaleren Anwendungsgebiet.
Online-Hilfen [1] haben den großen
Vorteil, dass sie beiden Anwendungssituationen gerecht werden
können: Im ersten Fall dienen sie als Kontexthilfe, die dem
Anwender über die F1-Taste oder über eine Direkthilfe
(Fragezeichen-Schaltfläche) direkt die gewünschte Information
liefert. Im zweiten Fall kann der Anwender in der Hilfe lesen
wie in einem elektronischen Buch und sich über Navigationsleisten,
Inhalts- und Indexbäume oder auch Assistenten schnell an
eine Stelle führen lassen, die ihn interessiert.
Haben technische Autoren damit nun einen Schlüssel in der
Hand, um mit der so entscheidenden Frage "Warum ruft der
Anwender die Online-Hilfe auf?" umzugehen? Nein, denn Kontextanbindung
und Navigationselemente sind nur Rahmenbedingungen von Online-Hilfen.
Ob die Hilfe wirklich eine Hilfe für den Anwender ist, hängt
davon ab, wie der Autor mit diesen Rahmenbedingungen umgeht und
wie er es schafft, Wissen und Informationen darin einzubauen.
Im Folgenden möchten wir in einem ersten Schritt zeigen,
wo die Fallen gerade bei kontextsensitiven Hilfen liegen können
und dabei auf den Begriff der Information zu sprechen kommen.
Im zweiten Schritt wenden wir uns mehr dem Wissen zu, denn gerade
Wissen wird zunehmend in Dokumentationen nachgefragt. Was Wissen
ist, wie es sich von Information unterscheidet und welche Auswirkungen
das Wissen vom Wissen auf technische Dokumentationen haben kann,
sind Fragen, die wir dabei aber nicht nur theoretisch erörtern,
sondern an praktischen Beispielen aus der Arbeit mit Microsoft
Word zeigen wollen.
Fallstricke der Direkthilfe
Schauen wir in einem ersten Beispiel einmal, wie einem Anwender
geholfen wird, wenn er in Word die Direkthilfe zur Zeichenformatierung
aufruft. Zum Schriftschnitt findet man folgenden Hilfetext:
 |
| Kontexthilfe "Zeichen
– Schrift" aus MS Word |
Überspitzt formuliert sagt der Hilfetext: "Wenn Sie
hier auf 'kursiv' klicken, wird der Text kursiv formatiert".
Der Hilfetext enthält damit faktisch keine zusätzliche
Information, sondern wiederholt nur den Inhalt des Dialogfensters.
Diese Hilfe ist, wie Sprachwissenschaftler sagen, eine Tautologie.
Sie entsteht, weil das System vorschreibt, dass zu jedem Feld
ein Hilfetext existieren muss, auch wenn er überflüssig
ist.
In einem zweiten Beispiel – dem Hilfetext zum Setzen eines
Querverweises – sehen wir einen ganz anderen Effekt: Der
Hilfetext kann hier nichts erklären, weil eine Erklärung
in einem einzigen Satz gar nicht möglich ist.
 |
| Kontexthilfe "Querverweis"
aus MS Word |
Hier wird der Teufel mit dem Beelzebub ausgetrieben. Denn ein
an sich schon abstrakter Begriff der Software ("Verweistyp")
musste aus Mangel an Platz durch ein noch abstrakteres Wort ("Elementtyp")
erklärt werden.
Fazit:
Diese beiden Beispiele mögen stellvertretend für die
latente Gefahr bei jeder kontextsensitiven Hilfe stehen. Die Feldbeschreibung
muss als Direkthilfe sehr kurz bleiben und läuft damit Gefahr,
trivial zu sein oder aber abstrakt und inhaltsleer. In beiden
Fällen erfüllt sie ihre Funktion – dem Anwender
weiterzuhelfen – nicht.
Vom passiven Informationsarchiv zum aktiven Wissensinstrument
Kurz und aus sich selbst heraus verständlich zu sein, das
ist das Kennzeichen einer Information. Im Gegensatz zu Wissen
oder Wissenselementen, auf die wir später zu sprechen kommen
werden, brauchen Informationen keinen Kontext, um verstanden zu
werden, sondern tragen als "Rohstoffe des Wissens" [2]
alles Bedeutsame in sich. [3] Auf unsere
obigen Beispiele übertragen ließe sich der Informationsgehalt
etwa wie folgt formulieren:
- Beispiel 1:
Markierter Text kann in seinem Schriftstil verändert werden.
Ob und wann es sinnvoll ist, Texte kursiv zu formatieren, welchen
Einfluss dies auf die Lesbarkeit von Texten hat und was man
sonst bei der Verwendung von Schriftstilen beachten sollte,
steht da nicht. Ein Layouter, ein Redakteur oder eine Schreibkraft
können die Information sofort unmittelbar verstehen, obwohl
jeder für sich diese Information unterschiedlich verwerten
wird.
- Beispiel 2:
Wohin ein Querverweis gerichtet ist, wird über zwei Felder
gesteuert: den Verweistyp, der auf bestimmte Kategorien möglicher
Verweisziele weist, und das Feld "Verweisen auf",
in dem die in einem Dokument vorhandenen Verweisziele enthalten
sind. Beide Felder beziehen sich aufeinander. Der Wissenschaftler
wird diese an sich noch abstrakte Information anders konkretisieren
als ein technischer Autor oder Ingenieur. Trotzdem bleibt die
Information – so gut es Formulierungskunst und Sprachgefühl
zulassen – aus sich selbst heraus verständlich.
Die Vermittlung von Wissen dagegen ist wesentlich komplexer.
Und unsere eingangs gestellten Fragen zielen auf die Vermittlung
und Vermittelbarkeit von Wissen: Warum ruft der Anwender einer
Software eine Online-Hilfe auf? Was will er erfahren? Was interessiert
ihn und was will er nicht wissen?
Die Kognitionswissenschaft, eine Disziplin der Psychologie, die
sich vorrangig mit dem Erwerb von Wissen befasst, hat genau zu
diesem Problem einige interessante Forschungsansätze in die
Diskussion gebracht, die uns weiterhelfen, die Situation des Anwenders
beim Aufruf einer Online-Hilfe zu verstehen.
Eine wichtige Erkenntnis ist: Wissen ist nicht etwas Absolutes,
das losgelöst von demjenigen, der es erwirbt, betrachtet
werden kann. Der Zuhörer oder Leser bringt das Gehörte
oder Gelesene in Beziehung zu dem, was er bereits weiß bzw.
erfahren hat. Eine Person, die Wissen aufnehmen und verstehen
will, bewegt sich also nicht im geistigen Niemandsland, sondern
hat schon eine gewisse Orientierung und räumliche Vorstellung
von dem, was sie erfahren wird. Die Wissenschaftler sprechen hier
von einem kognitiven Rahmen:
"Die kognitive Psychologie hat in den letzten Jahren mehr
darüber erfahren, wie das Gehirn seine Orientierungsaufgabe
zu lösen versucht. Eine wesentliche Erkenntnis ist, dass
es bei neuen Informationen zuerst versucht, einen kognitiven Rahmen
zu finden oder zu konstruieren, in dem die Detailfülle eingeordnet
werden kann. Es ist also keineswegs so, dass wir beim Verstehen
ein Detail nach dem anderen aufnehmen und daraus nach und nach
ein Gesamt entsteht. So arbeitet ein Scanner, nicht das Gehirn.
Vielmehr entwickeln wir bereits nach wenigen Informationen Annahmen
über das Gesamt und ordnen die folgenden Daten in diesen
Rahmen ein." [4]
Um also Wissen in eine Online-Hilfe einzubringen, genügt
es nicht, einfach nur Fakten aneinanderzureihen. Entscheidend
ist, dem Verstehen erst einmal den Boden zu bereiten – oder
in der Sprache der Kognitionswissenschafter: den kognitiven Rahmen
zu spannen. Vereinfacht gesagt: Vor der Erklärung des Wie
steht die Erklärung des Warum!
Ein Anwendungsbeispiel aus der technischen Dokumentation
Als technische Autoren haben wir immer wieder das Problem, unsere
Dokumentationen möglichst redundanzfrei aufzubauen. Ist es
möglich, mit Microsoft Word Dokumente so ineinander zu verschachteln,
dass Redundanzen in der Gesamtdokumentation vermieden werden?
Anhand dieser Fragestellung möchten wir zeigen, wie sich
das Modell der Kognitionswissenschaftler auf die Methoden der
Wissensvermittlung in Online-Hilfen anwenden lässt.
Die kürzeste Antwort
Die kürzeste Antwort auf diese Frage lautet: "Ja!"
Nehmen wir einmal an, Teile aus einem Standardwerk "Referenz.doc"
sollen in ein Projekthandbuch "Projekt_A.doc" referenziert
werden. Dazu gehen Sie folgendermaßen vor:
- In der Referenz.doc markieren Sie die gewünschte Textpassage
und kennzeichnen diese mit Hilfe einer Textmarke.
- In Projekt_A.doc setzen Sie den Cursor an die Stelle, an
welcher der referenzierte Text eingefügt werden soll.
- Öffnen Sie über das Menü "Einfügen/Datei"
das Dialogfenster "Datei einfügen" und wählen
Sie die Datei Referenz.doc.
- Mit einem Klick auf den Button "Bereich" aktivieren
Sie das Eingabefenster "Bereich bestimmen"; hier tragen
Sie die zuvor definierte Textmarke ein.
- Klicken Sie auf den Flyout am Button "Einfügen"
und markieren Sie die Option "Als Verknüpfung einfügen".
MS Word fügt nun den gekennzeichneten Text mit Hilfe der
Feldfunktion "INCLUDETEXT" in Projekt_A.doc ein.
Abschließend noch zwei wichtige Tipps:
- Nutzen Sie relative Pfade, damit die Feldfunktion "INCLUDETEXT"
laufwerkunabhängig funktioniert.
- Nutzen Sie beim Referenzieren von Texten die gleiche Dokumentvorlage
(.dot) für Quell- und Zieldokument, damit die Druckformate
erhalten bleiben.
Direkt drauf los zu schreiben und zu erklären, in welchen
Arbeitsschritten dieses Problem zu lösen ist, führt
zwar zu einer schlanken Beschreibung. Diese Beschreibung läuft
jedoch Gefahr,
- gar nicht erst gelesen zu werden (weil der Anwender glaubt,
das brauche er sowieso nicht) oder
- nicht verstanden zu werden (weil der Anwender glaubt, das
sei ja viel zu kompliziert für so ein einfaches Problem)
Erst wenn der Anwender die Bereitschaft mitbringt, sich auf das
Thema einzulassen und wenn er darüber hinaus das Problem
mit seinen eigenen Erfahrungen in Zusammenhang gebracht hat, dann
fällt die Beschreibung auf fruchtbaren Boden, erst dann findet
das Wissen einen Halt im kognitiven Rahmen.
Bezug zu den Erfahrungen der
Zielgruppe
Das bedeutet also: Die technische Beschreibung benötigt
Verankerungen in der Erfahrungswelt der Zielgruppen. Die Technik
von ineinander verschachtelten Dokumenten kommt im Bereich der
Software-Dokumentation häufig vor, wenn eine Anwenderdokumentation
Teile einer Referenzdokumentation in sich aufnimmt. Im Maschinenbau
werden beispielsweise in eine Beschreibung oft Abschnitte eines
Qualitätsmanagement-Handbuches integriert, das häufig
von ganz anderen Autoren, den Qualitätsbeauftragten, fortgeschrieben
und aktualisiert wird.
 |
| Referenzmodell ineinander verschachtelter
Dokumente |
Haben wir den Anwender so weit bekommen, dass er in der Dokumentation
seine eigene Arbeitswirklichkeit und nicht mehr nur eine Bedienungstechnik
wieder erkennt, dann haben wir seine Neugierde geweckt und damit
die wichtigste Voraussetzung zum Weiterlesen geschaffen.
Unterschiedliche Vorkenntnisse
Aber hier wartet schon die zweite gefährliche Klippe: Dem
Word-Experten würde es genügen, wenn man ihm zwei Stichworte
nennt: Textmarken und Feldfunktionen. Das könnte ausreichen,
um ihm auf der eigenständigen Suche nach einer Lösung
den entscheidenden Hinweis zu geben. Wer Word gut kennt und weiß,
dass das Programm in der Lage ist, nicht nur ganze Dokumente zu
referenzieren, sondern auch über Textmarken definierte Abschnitte,
der braucht in einem Hilfetext keine Kochrezepte und detaillierte
Vorgehensweisen. Unsere kürzeste Antwort wäre in diesem
Fall eigentlich schon zu lang, denn die gedankliche Lösung,
der Wegweiser sozusagen, bringt ihm viel mehr als die detaillierte
Etappenbeschreibung.
Der nicht ganz so versierte Word-Anwender hingegen fühlt
sich durch das Fach-Chinesisch überfordert. Und ein Leser,
der das Gefühl der geistigen Unterlegenheit spürt, ist
für immer verloren. Er wird die gesamte Dokumentation ablehnen
und in keinem anderen Fall mehr zu Rate ziehen.
Steckt der technische Autor also in der Falle, es keiner Zielgruppe
recht machen zu können und damit einen wie auch immer gearteten
Kompromiss eingehen zu müssen?
Strukturieren über Registerkarten
Gerade in Online-Hilfen ist es uns technischen Autoren möglich,
Anwender auf unterschiedlichen Niveaus anzusprechen. Wir müssen
uns also nicht zwischen der gerafften und der ausführlichen
Alternative oder zwischen den unterschiedlichen Anforderungen
unterschiedlicher Zielgruppen entscheiden. Denn Online-Hilfen
lassen sich über Registerkarten so strukturieren, dass Anwender
mit unterschiedlichem Vorwissen nur das aufrufen müssen,
was für sie relevant ist.
 |
Beispiel für den Einsatz
von Registerkarten
(Zum Vergrößern auf das Bild klicken.) |
Neben Registerkarten hat das Online-Medium noch eine Vielzahl
anderer technischer Möglichkeiten, den Anwender aktiv in
den Prozess des Wissenserwerbs einzubinden. Entscheidend an diesen
Techniken ist: Die Online-Hilfe wird aus einem passiven Informationsarchiv
zu einem aktiven Wissensinstrument. Und darin liegen jenseits
von Feldbeschreibung und Kontextanbindung große Chancen
in der Aufbereitung von technischem Wissen.
Praxisbeispiel zum Downloaden
Unter www.dokay.de
finden Sie im Bereich "Demo" das oben dargestellte Beispiel
als Online-Hilfe zum Downloaden vor. Darin sind die wichtigsten
Techniken eingebaut, die eine Online-Hilfe für den Einsatz
als aktives Wissensinstrument vorsehen.
Anmerkungen und Literaturhinweise
[1] Der Begriff der Online-Hilfe ist
weniger fachlich als vielmehr technisch klärungsbedürftig.
Wir unterscheiden beispielsweise RTF-basierte Winhelp-Hilfen von
HTML-basierten Hilfen. Diese werden entweder als reine HTML-Dateien
ausgeliefert und meist unter der Bezeichnung "Intranet-Dokumentationen"
geführt oder es sind kompilierte Hilfen, die unter Windows
als CHM-Dateien oder als Java-Hilfen schon weithin eingeführt
sind.
[2] Schmidbauer, Rodger: Erfolgsfaktor
Wissensmanagement. In: Beutler, Denis (Hrsg.): E-Business &
M-Business. Pulheim, Köln 2001, S. 107-126.
[3] A. Picot und S. Scheuble definieren
sie daher berechtigterweise als bedeutungstragende Zeichen.
Vgl. Picot, A./Scheuble, S.: Die Rolle des Wissensmanagements
in erfolgreichen Unternehmen. In: Mandl, Heinz/Reimann-Rothmeier,
Gabi (Hrsg.): Wissensmanagement. München, Wien 2000, S. 19-37.
[4] Weidenmann, Bernd: Psychologie des
Nichtverstehens. In: tekom Schriften zur technischen Kommunikation
Bd 1: Verständlichkeit und Nutzungsfreundlichkeit von technischer
Dokumentation, S. 41.
Leserbrief schreiben
|
