Wiki inside – Neue Nutzungsformen von Wikis am Beispiel einer ...

Wiki inside – Neue Nutzungsformen von Wikis am Beispiel einer communitybasiertenKontexthilfeGunnar Stevens, Torben WiedenhöferZusammenfassungWikis als eigenständige communitybasierte Informationssysteme sind spätestens durch Wikipediaallgemein bekannt. Mittlerweile werden sie auch als kommerzielle Knowledge-Management-Systeme in Unternehmen verwendet und finden zunehmend Beachtung in derWissenschaft. Aus diesem Grund soll in diesem Beitrag eine Arbeit vorgestellt werden, dieein communitybasiertes Hilfesystem mittels eines Wikis realisiert hat.Nach einem Abriss über die Entwicklung computerbasierter Hilfesysteme, wird auf das Problemsituativer und kultureller Dekontextualisierung eingegangen, dem sich Hersteller vonHilfesystemen gegenüber sehen. Vor dem Hintergrund wird die Idee von Wikis als „embeddedsystems“ vorgestellt, die in das User-Interface eingewebt werden, um so als Diskursmediumfür die Nutzercommunity zu fungieren.Die konzeptionelle Idee von Wiki inside greift dabei auf die Ergebnisse der Aneigungsforschungzurück, wo Computersysteme als soziale Artefakte verstanden werden, die von denNutzern ko-konstruiert werden. Zudem wurde die Idee des Wiki inside stark von der Auffassunggeprägt, dass die Mensch Computer Interaktion durch einen semiotischen Prozess beschriebenwerden kann. Beides zusammen hat zu einem neuartigen Konzept communitybasierterKontexthilfe geführt.Neben den konzeptionellen Ideen wird auch eine erste Umsetzung des Konzepts und dessenEvaluierung vorgestellt. Vor dem Hintergrund der dabei gesammelten Erfahrung werden abschließendeinige Zukunftsszenarien entwickelt.Zur Interpretationsbedürftigkeit bei ComputernutzungComputersysteme stellen soziale Artefakte dar, die in mannigfaltiger Weise interpretiert, angeeignetund genutzt werden können bzw. müssen (Wulf und Rohde 1995; Pipek 1999; Törpel,Pipek et al. 2003; Pipek 2005). Peter Brödner spricht deshalb auch von Orgware bzw.semiotischen Maschinen (Brödner 2005), um den interpretationsoffenen Charakter bei derComputernutzungen herauszustreichen.Daneben wurden verschiedene Versuche unternommen Giddens Strukturationstheorie auf denBereich von Computersystemen zu übertragen (vgl.: Orlikowski 1992; DeSanctis und Poole1994). Die wechselseitige Strukturation von Techniknutzung und Technikgestaltung wirddabei als Aneignung (appropriation) verstanden, wobei es geschehen kann, dass Systemejenseits der Intention des Entwicklers genutzt werden. Interpretation und Nutzung eines Artefaktswerden dabei in einen sozialen Prozess geprägt und weiterentwickelt. 11 Dabei werden häufig (implizit) die Aneignungsprozesse aus dem Blickwinkel des Herstellers bzw. Managementsbetrachtet. Interessant wäre hier ein Vergleich zwischen den gewonnenen Erkenntnissen und der Aneig-1

Unter der Perspektive der Aneignung als sozialer Prozess wollen wir Hilfesysteme als Metaartefaktevon Artefakten verstehen, die ein Angebot bzgl. der Interpretation eines Artefaktsunterbreiten.Wie wir im Folgenden sehen werden, haben diese Metaartefakte von der traditionellen linearenBedienungsanleitung - als eine spezielle Form eines Gebrauchstextes - verschiedene Entwicklungendurchlaufen, so dass wir heutzutage eine Fülle von Hilfesystemansätzen vor unshaben. Diese lassen sich am besten vor dem Hintergrund des Wechselspiels von Produktionspraktiken,software-technischen Eigenschaften und Nuzungspraktiken verstehen.Kurzer Abriss über die Geschichte von Bedienungsanleitungen im Digitalen ZeitalterDokumentenzentrierte Hilfesysteme bilden den ältesten Hilfeansatz und kommen in nahezuallen Betriebssystemen oder Softwarepaketen vor. Vor allem in den Anfängen waren Computersystemengedruckte Bedienungsanleitungen beigelegt, die als lineare Texte verfasst wurden.Diese waren darauf ausgelegt, dass Nutzer sich vor Inbetriebnahme eines technischenGerätes die Bedienungsanleitung komplett durchlesen, um anschließend zu wissen wie dasGerät richtig zu bedienen ist.In Folge wurden jedoch auch die neuen Möglichkeiten interaktiver Computersysteme aufgegriffen,so dass heutzutage auch Online-Handbücher, Hypertext Systeme oder sich selbst beschreibendeObjekte, durch Tooltipps und andere Formen von Interpretationshilfen eine wichtigeRolle spielen.Bei der Entwicklung dieser neuen Formen interaktiver Hilfesysteme spielten vor allem dieempirischen Untersuchungen von John Carroll (vgl.: Carroll, Smith-Kerker et al. 1986; Carrollund Rosson 1987) eine wichtige Rolle, weil er sich insbesondere für die Nutzungspraktikenvon Hilfesystemen interessierte.Bei seinen Untersuchungen zeigte sich, dass Nutzer sich anders verhielten, als es die Form derBedienungsanleitungen nahe legte. Statt durch das Schmökern in der Bedienungsanleitung dierichtige Bedienung des Geräts zu erlernen, verwendeten die Nutzer das System und griffenerst bei Problemen auf die beigelegte Information zurück. Carroll greift mit seinem Minimalism-Ansatzdieses Nutzungsverhalten auf und versucht diesen durch einen aktionsorientiertenHilfeansatz auf Hilfeartikel zu übertragen. Vor dem Hintergrund des beobachteten Nutzungsverhaltenshat sich auch die Gestaltung von Dokumenten zentrierten Hilfesystemen gewandelt.In Folge haben sich neue Formen der Hilfetexte bzw. deren Einbettung in den Nutzungskontextentwickelt. Diese Formen lassen sich z.B. bei der integrierten Standardhilfe von WindowsXP erkennen. (Shneiderman 1997) beschreibt das Windows Hilfesysteme als Ansammlunguntereinander verlinkter Hilfetexte. Durch Auswahl eines so genannten Topic kann derNutzer aus einer Liste von zugehörigen Hilfeartikeln wählen. Diese Hilfeartikel sind aufgabenorientiertaufgebaut und können schrittweise abgearbeitet werden.nungsforschung der Cultural Studies (Gay, Hall et al. 1997; Hepp 1999; Eglash, Crossiant et al. 2004), die dasPhänomen der Aneignung häufig unter einer gesellschaftskritischen Position untersuchen.2

Wird aber die lineare Form des Textes erst einmal aufgebrochen, ergibt sich fast unmittelbardas Nachfolgeproblem, wie der Text bzw. die Einstiegspunkte in die Textteile zu organisierensind. So merkt z.B. Shneiderman an, dass die unüberschaubare Menge an Hilfeartikeln geradefür Anfänger zur Herausforderung wird - wobei immer noch davon ausgegangen wird, dassim Prinzip der richtige Hilfeartikel vorhanden ist, die Schwierigkeit aber darin besteht diesenzu finden.Indirekt spricht Shneiderman das Problem an, dass im Produktionskontext von der konkretenProblemsituation dekontextualisiert werden muss, was umkehrseitig zur Rekontextualisierungim Nutzungskontext einhergeht (Rolf 2004). Das Problem der Dekontextualisierung soll unsim Folgenden als Referenzpunkt dienen, um hierüber die verschiedenen Hilfesystemansätzeals idealtypisch zu bestimmen und die in den Ansatz anlegte Arbeitsteilung zwischen Hersteller– Computer – Nutzer zu rekonstruieren. Innerhalb der Hilfesystemansätze lassen sich unseresErachtens drei drei Idealtypen identifizieren:• Von Wissenswerkzeugen und Wissensarbeitern• Avatare, Agenten und andere nützliche Helfer• Telesupport mittels Computer vermittelter KommunikationAbb. 1: Schematische Darstellung einesDokumenten zentrierten Hilfesystems(DZH) und die Rolle des NutzersVon Wissenswerkzeugen und WissensarbeiternEin möglicher Umgang mit Dekontextualisierung bestehtdarin, nicht nur eine Menge von Hilfetexten auszuliefern,sondern auch Werkzeuge aus dem Bereich desInformation Retrieval in das Metaartefakt Hilfesystemzu integrieren (vgl. Abb. 1). Damit soll der Nutzer inder Lage versetzt werden, sich das in den Hilfetextenvorhandene Wissen zu erschließen.Dadurch tritt die traditionelle Bedienungsanleitung demNutzer nicht mehr als ein einfacher linearer Gebrauchstext,sondern als ein interaktives Gebrauchswerk(zeug)gegenüber.Im Verhältnis Hersteller - Computer – Nutzer wird dabei eine neue zusätzliche Kompetenzzugemutet. Neben der Kompetenz Hilfetexte zu lesen und in Hinblick auf sein Problem richtigzu interpretieren, wird ihn auch die Kompetenz zugeschrieben bzw. übertragen, mit demWerkzeug Hilfesystem richtig umzugehen, um die richtigen Texte zu finden. D.h hinsichtlichder Arbeitsteilung übernimmt der Nutzer die Position des Wissensarbeiters, wie umkehrseitigdie Softwaretechnik für die Bereitstellung geeigneter Wissenswerkzeuge verantwortlich ist.Die Rolle des Herstellers liegt in der Befüllung der Hilfesystem-Datenbank mit einer geeignetenMenge von Texten.An der Gestaltung der integrierten Hilfe von Microsoft XP (vgl. Abb. 2) lassen sich verschiedeneStrategien des Zugangs erkennen:• IndexEine alphabetisch sortierte Liste von Themengebieten. Diese Art der Organisation bemächtigtsich zum einen der allgemeinen Kulturtechnik, die Reihenfolge des Alphabets zu kennen, zum3

anderen geht es von der Heuristik aus, dass die Hilfesystemredakteure das Problem des Nutzersunter den richtigen Begriff verschlagwortet haben.• VerweiseMittels Hyperlink-Struktur kann der Nutzer seineKompetenz zur Assoziation nutzen, um sich zumrichtigen Artikel zu klicken.• ThemengliederungAbb. 2: Hilfesystem mit integriertemWerkzeug, den richtigen Hilfetext zufinden.Eine hierarchische Gliederung von Themen mitdirekten Verweisen auf Hilfeartikel. Diese Art derOrganisation beruht quasi auf der gegensätzlichenHeuristik, dass der Nutzer sein Problem einen derdargebotenen Themen zuordnen kann und so durchimmer genauere Themengliederungen sukzessive zudem passenden Hilfetext kommt.• SucheAnhand von Schlüsselwörtern kann in allen Hilfeartikeln eine Volltextsuche ausgeführt werden.Hierbei muss der Nutzer die Kompetenz besitzen, auf seine Problemsituation treffendeSchlüsselwörter abzuleiten, die ein Autor in einem Hilfeartikel verwendet haben könnte, welchereine Lösung für sein Problem beschreibt.• AntwortassistentDer Antwortassistent erlaubt es, natürlichsprachig formulierte Fragen zu stellen. Dabei filtertder Assistent alle relevanten Schlüsselwörter heraus und bietet eine Liste mit passenden Themendem Hilfesuchenden an, die in drei Kategorien unterteilt ist. "Wie mache ich …", "Erkläremir …" und "Programmier- und Sprachreferenz".Im Wort Assistent wird schon eine Verlagerung der Kompetenzzuschreibung - weg vom Nutzerhin zur Maschine - sichtbar. Insofern hätten wir den Antwortassitenten auch in die nächsteKategorie einordnen können. Hieran erkennt man, dass die idealtypische Kategorisierung primärdazu dient, unsere Analyse zu strukturieren und nicht die Differenziertheit der Praxiswiedergeben kann.Avatare, Agenten und andere nützliche anthropomorphe HilfeystemeIn der KI nahen Forschung wird der Technik die Rolle bzw. die Kompetenz eines weisen A-genten zugeschrieben. Wie im Begriff Avatar konnotiert 2 besitzt diese übermenschliche Kräfte,die im Dienste der Menschheit gestellt werden. Je nach dem weltanschaulichen Vorzeichen2 Avatar (v. Sanskrit Avatara, „Herabkunft“) bezeichnet: die körperliche Manifestation eines Gottes, etwa inMenschen- oder Tiergestalt (Wikipedia, 23.3.2007)4

wird der Nutzer dabei von lästiger Arbeit befreit oder – unter kulturpessimistischen Vorzeichen– in seiner Unmündigkeit gefangen gehalten. 3Bei den Hilfesystemen unterscheiden Preece (1994) und Dix et al (1998) drei Arten intelligenterSysteme, die auf die Erfassung und Interpretation von Nutzungsdaten abzielen:• Kontextsensitive HilfeDer Hauptgedanke bei kontextsensitiven Hilfesystemen ist, den Kontext des Nutzers zu beobachtenund zu deuten, um ihm die Hilfe anzubieten, die aus dessen Arbeitskontext abgeleitetwurde. Diese Möglichkeit stellt einen der wichtigsten, wenn auch einen der schwierigstenSchritte in der Entwicklung von Hilfesystem dar. Die Risiken liegen dabei zum einen in derBestimmung der zu erfassenden Informationen (Art, Umfang, Zeitraum, Priorität, etc.) und inder Interpretation der erfassten Daten. Z.B. können die unterschiedlichen psychischen Situationendes Nutzers zu Fehlinterpretationen führen. Der einfachste Weg den Kontext zu erfassenist die Position des Cursors zu beobachten und Hilfe zu den unter dem Cursor befindlichenObjekten zu liefern.• Anpassbare HilfeAnpassbare Hilfe stellt ebenso wie die aktive Hilfe eine Art der kontextsensitiven Hilfe dar.Dabei wird durch das System der Hilfeinhalt an die Interessen des Nutzers angepasst. DieInteressen wurden vorher entweder manuell durch den Nutzer eingegebenen oder durch Interpretationder Nutzungsdaten bestimmt. Dabei wird z.B. auf Grund von vorab spezifiziertenNutzermodellen eine Klassifikation in Nutzertypen vorgenommen. Beispielsweise würde einsolches System die Hilfe an den Expertisegrad des Nutzers anpassen.• Aktive HilfeDie Initiative zum Aufruf passender Hilfe kann durch den Nutzer selbst geschehen, aber auchdurch die Anwendung bzw. durch das Hilfesystem selbst erfolgen. Bei der aktiven Hilfe versuchtdas System die Handlungen des Nutzers auf Grund der zur Verfügung stehenden Informationenzu deuten und dem Nutzer - ohne dessen bewusste Anforderung - Hilfe zur Verfügungzu stellen.Eine softwaretechnisch affine Interpretation des Konstrukts ‚Kontext’ wurde dabei von (Dey,Abowd et al. 2001) geliefert. 4 Für sie ist ein Kontext “any information that can be used tocharacterize the situation of an entity. An entity is a person, place, or object that is consideredrelevant to the interaction between a user and an application, including the user and theapplications themselves“.3 Wobei die Unmündigkeit wieder als Motivation herangezogen werden kann, intelligentere Maschinen zu entwickeln,um der Trägheit der Masse entgegenzuwirken.4 Dass die Deutung des Konstrukts ‚Kontext’ dabei nicht allein von den softwaretechnischen Möglichkeiten,sondern auch von Denkschulen der Wissenschaftler abhängt, hat unter anderen Leonardo Ramirez in seiner Aufarbeitungdes Diskurses um kontextbewusstes Rechnen im aktuellen Forschungsfeld des Ubiquitous Computingdargelegt. Vgl.: (Ramirez 2007)5

Das sehr unspezifische any markiert dabei aber auch schon die grundsätzlichen Schwiergkeitenbei der Gestaltung kontextbewusster Systeme. (Preece, Rogers et al. 1994) und (Dix, Finlayet al. 1998) fassen dies in einer Menge grundsätzlicher Fragen zusammen:• Welche Art von Informationen soll gesammelt werden?• Wie viele Informationen sollen gesammelt werden?• Welche Teile der Anwendung sollen zusammenhängend betrachtet werden?• Welche zeitlichen Rahmen sind zu berücksichtigen?• Etc.Sind diese Fragen beantwortet, stellt sich schon das nächste Problem, wie aus den gesammeltenDaten auf die Problemsituation geschlossen werden kann.Hinzu kommt noch der Punkt, dass Nutzer sich verunsichert fühlen können, wenn klar wird,dass Informationen über sie gesammelt werden, sie aber nicht genau wissen, welche dies sindund wofür sie verwendet werden (Herrmann 1988).Zusammenfassend lassen sich Konzepte von kontextbewusster Hilfe dadurch charakterisieren,dass sie den Kontext des Nutzers und der Applikation beobachten und zu verstehen versuchen,um ihm im richtigen Moment Hilfe anzubieten. Damit wird die Lösung des Dekontextualisierungsproblemsprimär im Bereich der Technik verortet.Die Geschichten rund um den wohl berühmtesten Avatar, Karl Klammer von Microsoft Word- der als lästig, unterhaltsam, aber auch von manchen als hilfreich empfunden wird 5 – zeigtdabei die ambivalenten Haltungen gegenüber solchen kontextbewussten Ansätzen.Telesupport mittels Computer vermittelter KommunikationAls nächsten Idealtypus wollen wir Ansätze des Telesupportmittels Computer vermittelter Kommunikation vorstellen. Beidiesem Idealtypus steht nicht die direkte Bereitstellung vonHilferessourcen durch Computersysteme, sondern die computervermittelteMensch-zu-Mensch Interaktion im Vordergrund(vgl. Abb. 3). Hierbei fungiert ein Computersystem als Kommunikationsmedium.Abb. 3: Die Rolle des MetaartefaktHilfesystem bei Computervermittelter KommunikationAckerman 1995).Das Hilfesystem kann dabei asynchrone (Email, Newsgroups,Foren, etc) oder synchrone Kommunikationstechniken wieInstant Messaging bereitstellen, um zwischen dem Nutzer unddem professionellen Hilfeanbieter zu vermitteln (Covi undFragen können z.B. in Emails geschrieben werden und diese an einen oder mehrere Expertenversandt werden. Somit weisen kommunikationsorientierte Hilfesysteme den Vorteil auf, dass5Man lese hierzu auch die Diskussion über das Verschwinden von Karl Klammer unter:http://blogs.msdn.com/inside_office_online/archive/2007/01/30/yes-clippy-is-dead.aspx6

Individuen innerhalb kürzester Zeit den persönlichen Kontakt zu einem oder auch mehrerenHilfeanbietern aufbauen können.Dadurch, dass die Akteure im Dialog treten können, besteht zudem die Chance, dass nicht nurder Computerlaie vom Fachmann lernt, sondern der Fachmann ein Feedback über Problemein der Praxis bekommt und etwas über Erfolg bzw. Misserfolg von Problemlösungen erfährt.Durch das Feedback kann so der Hersteller sein Wissen über praxisgerechte Gestaltung erweiternund in den Entwicklungsprozess einfließen lassen.(Covi und Ackerman 1995) stellen dabei fest, dass kommunikationsorientiere Hilfesysteme zuden erfolgreichen und populären Techniken gehören, nicht zuletzt bei unvorhersehbaren odermehrdeutigen Problemsituationen. Die Probleme dieses Ansatzes sind jedoch in den hohenBereitstellungskosten zu verorten. Neben zusätzlich bereitgestellten Fachkräften müssen auchdie Hilfsbereitschaft und die Kompetenz von Experten vorhanden sein, genervten Computernutzernzum wiederholten Male geduldig das System zu erklären.Produktionsbedingte Schwachstellen und Nutzungspraktiken Hersteller zentrierter HilfesystemeIm vorigen Abschnitt haben wir verschiedene Formen moderner Hilfesysteme vorgestellt, diesich vor dem Hintergrund der Komplexität heutiger Anwendungssysteme entwickelt haben,um so den Anstieg des Lernaufwandes des ‚richtigen’ Gebrauchs zu verringern. Dabei habenwir die Ansätze als Lösungsstrategie auf das Problem interpretiert, dass Bedienungsanleitungenzu dicken mehreren hundertseitigen Schwarten angewachsen sind, die von Nutzern nichtauf Vorrat gelesen, sondern vor dem Hintergrund praktischer Probleme zu Rate gezogen werden.Hieraus erwächst das allgemeine Problem der Dekontextualisierung, das wir an dieser Stelleweiter in das Problem der situativen Dekontextualisierung und der kulturellen Dekontextualisierungaufspalten wollen.Mit situativer Dekontextualisierung ist gemeint, dass das Hilfesystem samt der Hilfetexte vorAuslieferung der Anwendung erstellt werden muss und somit die oben genannte Schwierigkeitaufwirft, Problemsituationen künftiger Nutzer mit den komplexen Systemen voraussagenzu können (Suchman 1987) und Aneigungsphänomene im Vorhinein zu antizipieren (Stevens,Quaisser et al. 2006).Hinsichtlich der situativen Dekontextualisierung hat insbesondere die ethnomethodologischorientierte Arbeit von Suchman gezeigt, dass auf Grund der Situiertheit menschlichen HandelnsKI-orientierte Hilfesysteme prinzipielle Schwierigkeiten haben, den Nutzungskontextzu erfassen (Suchman 1987). In dem von ihr untersuchten Fall – die Bedienung eines neuenKopierertyps mit integrierten intelligenten Hilfesystem – zeigte sich, dass die, von den Entwicklernvorgenommene und durch den Algorithmus umgesetzte, Antizipation im konkretenNutzungskontext zu unpassenden bzw. verwirrenden Hinweisen des Hilfesystems führte. Dieshatte zur Folge, dass die Nutzer workarounds angewandt haben, um an die richtige Antwortauf ihre Fragen zu kommen.Die Versprechungen der künstlichen Intelligenz, dem Problem durch immer exaktere Vermessungdes Kontexts mittels intelligenteren Algorithmen und einer immer umfangreicherenDatensammelung Herr zu werden, klingen wie der Wunsch der Wirkungsforschung durch7

immer exaktere Messung detaillierte Nutzermodelle zu erhalten. Die kritischen Anmerkungenvon Ien Ang in Bezug der Wirkungsforschung lassen sich dabei fast eins zu eins auf den Bereichder Technikgestaltung übertragen:„Die Paradoxie des elektronischen Zuschauerzählersliegt aber darin, dass er den Wunsch ausdrückt, einer detaillierten Landkarte der sozialenWelt tatsächlicher Sehgewohnheiten. Diese fortschreitende Annäherung von Repräsentationsstrategienan das Soziale muss, wie ich meine, letztlich das Chaos statt Ordnung enthüllen.“(Ang 2003).Mit der kulturellen Dekontextualisierung ist gemeint, dass die Ersteller von Bedienungsanleitungenmeist einen anderen kulturellen Hintergrund haben, als die Nutzer des Systems. InZeiten der Globalisierung bezieht sich dies auch auf geographisch unterschiedliche Kulturräume,was man manchmal an ins Deutsche übersetzten Bedienungsanleitungen chinesischeroder schwedischer Herkunft erkennen kann.Zudem, und hierauf wollen wir genauer eingehen, macht sich die soziokulturelle Kluft auchim technischen Duktus der Bedienungsanleitungen bemerkbar. Sie stellt zwar dem Nutzereine Vielzahl von Informationen bereit, die die Nutzer aber größtenteils nicht mit ihren Arbeitskontextin Verbindung bringen können. Zur Illustrierung dieser Art von kultureller Dekontextualisierungwollen wir auf die Arbeiten von (Hinds und Pfeffer 2003) aus dem Bereichdes organisatorischen Lernens zurückgreifen. Sie haben den Wissensaustausch zwischen Expertenund Novizen in Organisationen untersucht.(Hinds und Pfeffer 2003) fassen den Wissensaustausch zwischen Experten und Novizen primärals kognitives Problem auf. Bezug nehmend auf (Sternberg 1997) gehen sie davon aus,dass Experten tendenziell zu mehr abstrakterem und vereinfachtem Wissen neigen. BeimWissensaustausch führt die Vereinfachung der Aufgabe dazu, dass Experten weniger denSchwerpunkt auf Details legen und somit weniger spezifizierte Schritte in der Aufgabenbearbeitungbesitzen. Dieses hingegen benötigen Personen mit geringerem Erfahrungsschatz, umsich so durch Details und Hintergrundwissen ihr Verständnis zu bilden. Auf Grund verschiedenerExperimente kommen Hinds und Pfeffer dabei zu den Schluss, dass es sich bei den Expertenum kognitive Barrieren (cognitive limitations) handelt, die sie daran hindern, ausreichendkonkrete und detaillierte Erläuterungen zu geben, „even when they know their explanationsare intended for novices“ (Hinds und Pfeffer 2003).Ein weiter Umstand, der im wissenschaftlichen Diskurs meist übersehen wird, ist dass heutigeSoftwareprojekte durch sehr eng kalkulierte zeitliche und finanzielle Rahmenbedingungengeprägt sind. Deswegen kann am Projektende die nötige Auseinandersetzung mit der Hilfeund dem Schreiben geeigneter Hilfetexte nur beschränkt oder mitunter gar nicht wahrgenommenwerden.Nachdem wir einige Aspekte der Produktion von Hilfesystemen dargelegt haben, wollen wirdie Nutzungspraktiken heutiger Hilfesysteme betrachten. Hierzu sollen einige Ergebnisse einerOnline Umfrage über das ‚Rezeptionsverhalten’ der Nutzer vorgestellt werden. Eine genauereDarstellung der Umfrage findet man in (Wiedenhöfer 2006).Bei der Umfrage ging es darum, den Umgang mit den integrierten Standardhilfen von Softwareproduktenzu untersuchen. Hierzu wurden per Email Personen aus unterschiedlichen Bereichenangeschrieben. Diese setzten sich größtenteils aus Studenten unterschiedlicher Fachrichtungen,Verwaltungsangestellten und Mitarbeitern produzierender Unternehmen zusam-8

men. Wir bekamen von 58 Personen eine Antwort, was einer Rücklaufquote größer Eins entsprach.Dies hing damit zusammen, dass die angeschriebenen Personen die Umfrage an Bekannteund Freunde weiterleiteten.Die Befragung, die per E-Mail an die Befragten versendet wurde, erhebt keinen Anspruch aufRepräsentativität im statistischen Sinne. Trotzdem gibt sie doch ein interessantes Bild überdie (Nicht-)Nutzung von Standardhilfen ab und illustriert in schöner Weise, was mit Dekontextualisierungin der Praxis gemeint ist.Die Untersuchung zeigte, dass 74% der Probanden Probleme im Umgang mit einem Softwareproduktinnerhalb des letzten Monates hatten. Im Allgemeinen zogen aber 86% der Nutzerdie integrierte Standardhilfe nur selten oder gar nicht zur Problemlösung heran. Diese Ergebnisseuntermauern die Tatsache, dass Anwender die Nutzung traditioneller Hilfesystememeiden, obwohl die Notwendigkeit nach Unterstützung besteht und nach Hilfe gesucht wird.Diese Abneigung wird dadurch forciert, dass 62% der Nutzer angeben, in nur geringem Maßepassende Hilfe durch das integrierte Hilfesystem zu erhalten. 71% beklagen zudem den hohenAufwand, Hilfeartikel in Bezug auf deren Problemkontext zu finden. Darüber hinaus zeigtsich eine Unzufriedenheit bei 68% der Personen über den Inhalt dieser Hilfeartikel. Die kulturelleDekonxtualisierung spiegelt sich ebenfalls in der Studie wider. 58% der Probanden gabenan, Verständnisprobleme mit den Hilfetexten zu haben, die z.B. mit unverständlichemVokabular einhergehen.Diese negativen Erfahrungen mit traditionellen Hilfesystemen führten bei den Befragten dazu,andere alternative Hilferessourcen zur Problemlösung heranzuziehen. 84% der Befragten bevorzugen,Freunde oder Bekannte zu Rate zu ziehen. Dies stellt dabei die am häufigsten genutzteHilfe dar. Das Internet und speziell Suchmaschinen werden von ca. 61% zur Hilfesuchegenutzt. 92% vertrauten dabei eher Hilfetexten, die nicht vom Hersteller, sondern vonNutzern selbst verfasst worden sind. Dies zeigt sich z.B. auch bei der Suche nach thematischpassenden Diskussionsforen, in denen Nutzer ihr Wissen austauschen. Gedruckte Fachliteraturoder der Supportdienst werden hingegen von ca. 80% gemieden.Vor den Schwierigkeiten bei der Produktion und den beobachteten Nutzungspraktiken kannes auch für die Hersteller von Anwendungssystemen attraktiv sein, sich in das Reich der Ungewissheit(Ang 2003) einzulassen und die Entwicklung und Pflege von Hilfesystemen ganzoder teilweise an die Nutzercommunity outzusourcen.Abb. 4: Integrierung communitybasierter Hilfe beiWindows WordCommunity Help - Zwischen MontessoriPädagogik und Tom-Sawyer-PrinzipEin Beispiel für diesen Trend, den Supportfür ein Produkt an die Nutzercommunityauszulagern, findet sich z.B. in den aktuellenOffice 2003 Produkten von Microsoft. Hierwurde das integrierte Hilfesystem an ein, vonMicrosoft bereitgestelltes, Communitysystemgekoppelt, mittels dessen die Nutzerihr Wissen austauschen und Fragen zu Bedienungstellen können.9

Neben der traditionellen Suchfunktion nach Hilfeartikeln, die von Microsoft bereitgestelltwerden, wird dem Nutzer ebenfalls die Möglichkeit gegeben, in Foren der Word-Communitynach passender Hilfe zu suchen. War die Suche in Foren und in der traditionellen Hilfe vonWord erfolglos, kann der Nutzer sein Problem an die Community formulieren (vgl. Abb. 4).Dadurch integriert die Word-Hilfe das Feature, in konkreten Problemsituationen auf das Wissender Community direkt aus dem integrierten Hilfesystem zuzugreifen. Dies hat den nettenNebeneffekt, dass die auf dem Communitysystem geführten Diskurse zwischen den Nutzernzu einer Befüllung der Datenbank des Hilfesystems führen.Je nach politischem Standpunkt kann man darin eine software-technische Umsetzung desMontessori Prinzips der Hilfe zur Selbsthilfe oder die Anwendung des Tom-Sawyer-Prinzips,Tätigkeiten die man selbst nicht leisten kann oder möchte anderen Leuten zu übertragen 6 ,erkennen.Wir denken, dass der Idee von produktspezifischen Communitysystemen beide Interpretationengleichermaßen eingeschrieben sind. Diese Gleichzeitigkeit kann zur Skepsis wie Begeisterungdes Konzept von Herstellern und Nutzer gleichermaßen führen, Auf Seiten des Herstellerskönnte bzgl. des Konzept communitybasierter Hilfesystemen skeptisch angemerktwerden, dass durch die Öffnung dem Missbrauch durch konsumkritische Aktivisten, Scherzkekse,Spam, Werbekampagnen der Konkurrenz, etc. Tür und Tor geöffnet wird. Ebenso könnenKäufer die Technologie ablehnen, weil sie es z.B. für eine Zumutung halten, dass - wennetwas bei der Applikation nicht intuitiv bedienbar ist, sie bei schlechter Software dem Herstellerauch noch aus der Patsche helfen und anderen Leuten mitteilen sollen, wie man das Problemumgeht.Die semiotische Überlegungen zum Konzept des Wiki inside„Zeichen ist alles, was zum Zeichen erklärt wird, und nur was zum Zeichen erklärt wird. Jedes beliebige Etwaskann (im Prinzip) zum Zeichen erklärt werden.“ (Bense 1967)Das Konzept des Wiki inside greift die Idee communitybasierter Hilfesysteme auf und verbindetdie Idee mit der Vorstellung von objektbezogener Annotation. Dabei gehen wir davon aus,dass die Mensch Computer Interaktion als ein semiotischer Prozess beschrieben werdenkann. 7 Bei unseren semiotischen Überlegungen spielt dabei die Nutzerschnittstelle user interfaceeine zentrale Rolle, da sie der Ort ist, an dem der Nutzer mit einer Anwendung interagiert.Im Laufe der Zeit wurden verschiedene Typen von Interfaces entwickelt. In den Frühzeitender Computertechnologie herrschte die Bedienung mittels Kommandozeilen Interpreter(Command Line Interfaces bzw. CLI) vor, bei denen der Nutzer durch seine Shell Komman-6 Vgl, dazu auch den Beitrag auf Wikipedia unter http://de.wikipedia.org/wiki/Tom-Sawyer-Prinzip (Stand31.12.2006). Der Hinweis „Dieser Artikel wurde zur Löschung vorgeschlagen“ entbehrt dabei nicht einerunfreiwilligen Selbstironie.7 In der Forschung wurde diese Vorstellung z.B. durch Frida Nake, Peter Borg Anderson bzw. der Forschungsgruppeum De Souza und Barbosa entwickelt. Jedoch kann nicht von der Computersemiotik gesprochen werden,da die einzelnen Wissenschaftler sich auf ganz unterschiedliche Semiotikansätze berufen.10

dos eingeben, bzw. die Ausgaben des Computers lesen konnte. Heutzutage haben sich grafischeNutzerschnittstellen (Graphical User Interface bzw. GUI) durchgesetzt, so dass nahezualle modernen Desktopcomputer auf der Verwendung von grafischen Nutzerschnittstellenbasieren.Ben Shneiderman hat den Erfolg graphischer Nutzerschnittstellen auf die Direkte Manipulationzurückgeführt: „The central ideas seemed to be visibility of the object of interest; rapid,reversible, incremental actions; and replacement of complex command language syntax bydirect manipulation of the object of interest – hence the term ‘direct manipulation’.”(Shneiderman 1983).Semiotisch lässt sich Shneidermans Aussage in der Weise interpretieren, dass der Computerbildschirmuns nicht als ein Haufen darauf abgebildeter Pixel erscheint. Vielmehr findet ein -durch Ein- und Ausgabe vermittelter - semiotischer Prozess statt, bei dem die Interaktion derartstrukturiert ist, dass uns die Pixel auf dem Monitor als Zeichen erscheinen, die auf etwasanderes verweisen. Nach Schneiderman sind dies - bzw. sollte dies sein – die “object of interest”,die wir durch die Eingabewerkzeuge direkt manipulieren können.Shneidermans Interpretation hat dabei auch Eingang in die Standardisierung der Ergonomieder Mensch-System-Interaktion gefunden: „Bei der Dialogführung mittels direkter Manipulationlösen Nutzer Operationen dadurch aus, dass auf dem Bildschirm angezeigte Objekte ähnlichwie physikalische Gegenstände behandelt werden.“ (DIN_9241 1999).Die sich in Anschluss an Shneiderman aufdrängende Frage lautet nun, wie diese objects ofinterest bestimmt werden. Hier konnotiert die Direkte Manipulation eine substantialischeVorstellung, bei der sowohl vermittelnde Zeichenträger - als auch die objekt of interest fixeAtome darstellen. An dieser Stelle unterscheiden wir uns und greifen die Überlegung einerstrukturalistischen Semiotik auf. Demnach besitzen Zeichen zwar eine materielle Gebundenheit,sie sind aber als relative, oppositiv aufeinander bezogene Größen innerhalb einer Lebenspraxiszu verstehen, die sich wiederum in einen historisch-materiellen Prozess herausgebildethaben.Bei der Analyse eines Zeichensprozesses greifen wir auf Charles Sanders Peirce zurück (siehez.B.: Hoffmann: 2005 ), der ein Zeichen durch ein triades Verhältnis von Objekt - Repräsentamen- Interpretant bestimmt sieht: “A Sign, or Representamen, is a First which stands insuch a genuine triadic relation to a Second, called its Object, as to be capable of determininga Third, called its Interpretant, to assume the same triadic relation to its Object in which itstands itself to the same Object. The triadic relation is genuine, that is its three members arebound together by it in a way that does not consist in any complexus of dyadic relations.”(Peirce 1903, in: Houser und Kloesel 1998, EP 2:272-3) Dabei muss man beachten, dass Zeichennicht atomar sind, sondern in einem rekursiven Verhältnis zueinander stehen. D.h. dasman sich ein einzelnes Zeichen am Besten als einen Schnitt im Kontinuum (Zink 2004)einerSemiose denken sollte, die sich relativ zu einer Lebenspraxis vollzieht. Die Festlegung einzelnerZeichenentitäten stellen dabei (notwendige) Heuristiken vor einen pragmatischen Hintergrunddar.Nach diesen Vorbemerkungen wollen wir die Wiki inside zu Grunde liegende Idee anhandeines fiktiven Beispiels aus der Realwelt illustrieren. Das Foto in Abb. 5. wurde in einer Dis-11

count Kette aufgenommen und mit der erstbesten Frage versehen, die uns bei betrachten desBilds eingefallen ist.Damit haben wir versucht exemplarisch die Idee von Virtual PostIt 8 zu illustrieren, die einegestalterische Umsetzung des Konzepts eines Community orientierten Hilfesystems darstellt.Um nun die Idee der Virtual PostIt besser zu verstehen, sollte man deren Prinzip von der Physikin die Semiotik übertragen. Unter dieser neuen Perspektive ist das PostIt ein indexikalischerZettel, der aber nicht mehr an einen physikalisch bestimmten, sondern an einen semiotischbestimmten Objekt klebt.Im Folgenden soll das Bild nun aus einer solchensemiotischen Perspektive analysiert werden,um die Grundprinzipien einer objektbezogenenAnnotierung aufzuzeigen. Die Frage„Wie backe ich eigentlich einen Hefezopf?“lässt sich dabei als Interpretant auf das in Abb. 5abgebildete Foto lesen. D.h. umkehrseitig bildetdas Foto den Repräsentamen für diesen Interpretant.Nachdem wir also Repräsentamen undInterpretant bestimmt haben, können wir unsfragen auf welches Objekt sich das Repräsentamenbezieht. Nun erkennen wir ein Regal mitAbb. 5: Frag am besten Deine Mutter ;)diversen Packungen in einen Supermarkt undverschiedene Packungen, die aus quaderartigen Pappkartons zu bestehen scheinen. Danebenist das blau-weiß-rote Dr. Oekter Logo zu erkennen. Rechts auf der Packung ist ein angeschnittenerMarmorkuchen zu erkennen. Es ist also anzunehmen, dass das Bild in der Backabteilungeines Supermarkts aufgenommen worden ist. Es bietet sich also an, Backabteilungeines Supermarkts als Objekt des Zeichens anzunehmen. Mittels dieser Überlegung haben wiralso eine mögliche Triade (Backabteilung eines Supermarkts, Foto, Wie backe ich eigentlicheinen Hefezopf) rekonstruiert, die das Zeichen bestimmt. Nun wollen wir die Akteurebestimmen, die in dem Bild objektbezogene Annotierungen hinterlassen haben. Auf dem Bildlassen sich hier drei verschiedene Typen von Akteuren ausmachen:• die verschiedenen Hersteller der im Regal dargebotenen Produkte• die Supermarktbetreiber• derjenige, der das Bild mit dem ‚gelben Zettel’ versehen hatVersuchen wir jetzt aus der Perspektive der verschiedenen Akteure noch deren Annotierungsmöglichkeitenzu bestimmen.Auf der Ebene des Herstellers bietet es sich an, sein Produkt im Regal als das antizipierteObjekt der Zeichen-Triade zu nehmen, was verkauft werden soll. Ebenfalls bietet sich an,dass die Verpackung als Repräsentamen der Zeichen-Triade antizipiert wird. Insbesondereweil hier der Hersteller die Gestaltung des so antizipierten Repräsentamen beeinflussen kann.So kann er z.B. versuchen, auf den Interpretant der Zeichen-Triade dadurch Einfluss zu nehmen,dass er – wie es z.B. bei Weinflaschen üblich geworden ist – einen passenden Verwen-8 Zur der Idee der Virtual PostIt siehe auch (Grüttner 2007).12

dungszweck für das Produkt auf der Verpackung gleich mit abdruckt. Er kann auch versuchendie Interpretation in seinem Sinne zu beeinflussen, indem er z.B. auf der Verpackung einenperfekt gelungenen Mamorkuchen abbildet. Jedoch ist der Hersteller genauso, wie die Entwicklervon Hilfesystemen der situativen und kulturellen Dekontextualisierung unterworfen,so dass er zwar die Verpackung als antizipierten Repräsentamen mitgestalten kann, er jedochweder sicher sein kann, dass die Verpackung in seinem Sinne wahrgenommen, geschweigedenn interpretiert wird. Die situative Dekontextualisierung erkennt man z.B. daran, dass mancheHersteller zum Zeitpunkt der Abfüllung nicht wissen in welchem Land das Produkt verkauftwird, weshalb sie z.B die Inhaltstoffe auf der Verpackung in mehreren Sprachen abdrucken.9Auf der Ebene des Supermarktbetreibers lässt sich auf dem Bild erkennen, dass bei der objektbezogenenAnnotierung der räumliche Kontext des Supermarkts und der Waren ausgenutztwurde, um so die Waren in Form von orangefarbenen Preisschildern zu annotieren. Aufdem Weg zu den Virual PostIt können wir aber die interessante Beobachtung machen, dasszwar mit den Preisschildern das einzelne physikalische Objekt ausgezeichnet wird, die Annotationsich aber auch auf das Objekt des Produkttyps bezieht. Insbesondere ist die Beziehungzum einzelnen physikalischen Objekt doppelt kodiert: Einmal mittels eines räumlichen Index– das Ding in der näheren Umgebung – und zur Sicherheit noch mittels eines symbolischenIndex – das Ding mit der gleichen Produktbezeichnung.Um auf der nächsten Ebene nun den gelben Marker auf dem Bild – ein Fake um die Designideeder Virtual PostIt zu kommunizieren – zu analysieren, stellen wir uns einen Augenblickvor, dass derjenige der das Bild mit einer Anmerkung versehen hat, eine neuartige Handykamerabesitzt und wir das Bild ebenfalls durch eine solche Handykamera betrachten. Die neuartigeHandykamera besteht darin, dass sie erlaubt im Bild semiotisch bestimmte Objekte mitvirtuellen PostIts zu annotieren bzw. sich die PostIts anderer Leute anzeigen zu lassen. In demsich so vorgestellten Zukunftsszenario könnte die Bildunterschrift von Abb. 5 nun die Antwortdarstellen, die wir per SMS an das eingeblendete virtuelle PostIt schicken, so dass aufdem PostIt ein Diskussionsthread entsteht.Die software-technische Herausforderung der so eben skizzierten Gestaltungsidee bestehtdabei darin, Verfahren zur Konstruktion geeigneter semiotischer Objekte zu entwickeln, damitdie durch das Verfahren ausgezeichneten Objekte als Träger für die virtuellen PostIts fungierenkönnen. Für eine algorithmische Konstruktion der Objekte haben wir dabei in (Stevensund Wiedenhöfer 2006) drei Forderungen aufgestellt:1. Der Algorithmus soll einen über die Zeit stabilen Träger auszeichnen.2. Durch den Algorithmus sollen nur für den Nutzungskontext sinnhafte Objekte als Trägerfür PostIts konstruiert werden, d.h. insbesondere sollte der Algorithmus derart transparentsein, dass – im Idealfall – der algorithmisch bestimmte Träger mit den lebensweltlich bestimmtensemiotischen Objekt zusammenfällt.9 Eine andere Lesart, die dies nicht auf eine zeitliche Deskontextualisierung zurückführen würde, könnte darinaber auch einen Ausdruck sehen, dass der Hersteller damit seine internationale Bedeutung kommunizierenmöchte.13

3. Der Algorithmus sollte es erlauben, die - an den Träger gehängten - PostIts möglichst einfachzu finden bzw. wieder zu finden.Auf der semiotischen Ebene unterscheidet sich das fiktive Beispiel, eines auf einen Wiki basierendenvirtuellen PostIt, das in die Realität eingeflochten wird, nicht grundlegend von demim nächsten Abschnitt vorgestellten, in eine Anwendung integrierten, Hilfesystem auf Wiki-Basis. Es ist jedoch anzunehmen, dass sowohl die technischen Bedingungen der Objektkonstruktion10 , als auch dessen, was sinnvolle semiotisch bestimmte Objekte darstellen, sich unterscheiden.11KontextsensitiveHilfeWiki insideVirtual PostItAuszeichnung vonObjekten- vor Auslieferung- durch Hersteller- vor Auslieferung- durch Hersteller- während der Laufzeit,- durch heuristischeAlgorithmenAnnotationObjektenvon- vor Auslieferung- durch Hersteller- nach Auslieferung- Communityorientiert- nach Auslieferung- CommunityorientiertTabelle 1: Unterscheidung Community- und Hersteller-zentrierte deiktische HilfesystemansätzeIm Folgenden wollen wir uns aber nur auf den Bereich der in Applikationen integrierten Hilfesystemebeschränken. Diese eben angestellten semiotischen Überlegungen helfen jedoch dieFunktionsweise unseres Verfahrens besser zu verstehen. Insbesondere lässt sich durch diesemiotische Interpretation eine Binnendifferenzierung Kontext spezifischer Hilfesystemansätzevornehmen. Kontextbewusste Ansätze, die auf KI-Algorithmen basieren, lassen sich dadurchcharakterisieren, dass sie möglichst gut den Kontext auf der pragmatischen Ebene einesZeichnens zu erfassen suchen. Die unter dem Label kontextsensitive Hilfe gefasste Technikenwie Tooltips oder die Windows F1 Hilfe verzichten jedoch im Allgemeinen auf einer solchenErfassung des Kontexts auf der pragmatischen Ebene. Sie versuchen stattdessen auf der Ebeneder semiotischen Objekte, diese am Interface zu identifizieren und bzgl. dieser Objekteerläuternde Hilfetexte einzublenden. stellen vielmehr indexikalische bzw. genauer deiktischeHilfesystemansätze dar. Innerhalb dieser deiktischen Anätze lassen sich auch unsere Arbeitenverorten.Aufgrund unserer intensivern Auseinandersetzung mit der Thematik und der softwaretechnischenUmsetzung haben durch den Abgleich zwischen unseren Ansatz und den bisheri-10 Z.B. ließen sich GPS Daten, von Hersteller bereitgestellte Produktinformation (Name, Barcode, etc.) oderbiometrische Daten (Kopfform, Gesten, …) zur Objektkonstruktion heranziehen.11 Z.B. könnte man sich vorstellen, dass Produkte um verbraucherkritische Informationen angereichert werden,oder jemand der Kassiererin mit Kopftuch einen virtuellen Zettel „Islamistin - nicht rechnen“ anklebt, um andieser Stelle alle Klischees einer nicht gewünschten Aneignung zu bedienen.14

gen Ansätz, wie er z.B. bei Tooltips bzw. F1 Hilfe zu finden ist, zwei Ebenen identifiziert,mittels dessen sich die verschiedenen Ansätze klassifizieren lassen:Beim traditionellen Verfahren der kontextsensitiven Hilfe fügen die Entwickler in den Sourcecodespezielle Help-Identifier ein, die User Interface Elemente, so genannte Widgets, zugeordnet werden. An einer anderen Stelle im Source-Code bzw. in ausgelagerten Dateien,schreiben dann die Entwickler dazugehörige Hilfetexte (dies wäre dann der Fall KontextsensitiveHilfe: in Tabelle1). Während der Laufzeit liest dann das Hilfesystem den Help-Identifieraus und zeigt den zugeordneten Hilfetext an.Im ersten Schritt lassen sich die Herstellerabhängigkeiten dadurch verringern, dass zwar dieAuszeichnung der Objekte mittels spezieller Help-Identifier noch durch den Hersteller geschieht,aber es der Nutzercommunity möglich ist, die so bestimmten Objekte zu annotieren(dies wäre dann der Fall Wiki inside: in Tabelle1).Bei der Umsetzung im BSCWeasel Projekt 12 , bei dem unsere Applikation aus weiten Teilenaus Komponenten von Drittanbietern besteht, zeigte sich leider, dass die Hersteller der anderenKomponenten gar keine oder nur rudimentär Help-Identifiers eingefügt hatten. Deshalbmussten wir von Außen Zeichenträger durch Inspektion des Systemszustands mittels heuristischerAlgorithmen erzeugen, die die oben genannten drei Anforderungen möglichst gut umsetzen(dies wäre dann der Fall Virtual PostIt: in Tabelle1).(a) Bestimmung von Objekten durch Nutzer(b) Bestimmung mittels algorithmischer VerfahrenTabelle 2 Simulation der Bestimmung semiotisch bestimmter Objekte mittels heuristischer VerfahrenOhne hier auf die technische Details eingehen zu können (siehe dazu: Stevens und Wiedenhöfer2006; Wiedenhöfer 2006; Grüttner 2007), wollen wir kurz das Vorgehen skizzieren, mittelsdessen wir ein semiotisch orientiertes Verfahren entlang den obigen drei Anforderungenentwickelt haben. Dieses konstruiert algorithmisch Objekte in der GUI, auf die dann in einemNutzungsdiskurs Bezug genommen werden kann.Hierzu haben wir in einem ersten Schritt Nutzer gebeten, in einem Snapshot jene Stellen einzukreisen,die sie interessieren. Im nächsten Schritt haben wir versucht eine Grammatik inden Auszeichnungen zu erkennen und im dritten Schritt diese mittels algorithmischer Verfah-12 Vgl. http://www.bscweasel.de15

en zu simulieren. Hierbei haben wir insbesondere davon profitiert, dass Entwickler heutzutagebei der software-technischen Umsetzung des Direct Manipulation Konzepts auf standardisierteWIMP-Programmbiblioteken 13 zurückgreifen und sich so Muster im Aufbau heutigerAnwendungssystemgestaltung wieder finden lassen, an denen unsere heuristische Verfahrenansetzen können.Community Help in Context: Realisierung einer Wiki basierten HilfeAn dieser Stelle wollen wir eine prototypische Referenzimplementierung darstellen. Ziel diesesPrototyps war unter anderem entscheidende Erkenntnisse über die Brauchbarkeit und dieNutzbarkeit unseres Konzeptes zu gewinnen. Die Herausforderung bei der Realisierung lag,neben der Umsetzung eines guten Verfahrens zur Bestimmung der semiotischen Objekte undderen Annotierbarkeit, in der Umsetzung einer generischen Lösung die sich gut in das Interfacebestehender Anwendungen integriert. ???Zweimal Umsetzung in einem Satz???Um diesen Anforderungen gerecht zu werden, wurde die zu Grunde liegende Architektur indie drei Module CBHS (Community Based Help System), AIM (Application Integration Module)und CAM (Context-Aware Adaptation Module) aufgeteilt. Diese Architektur basiert aufunserer Einschätzung, dass komponentenbasierte Systeme den Aufwand bei Anpassbarkeitund Veränderungen entscheidend verringern und es die Integration in jedes Anwendungssystemerleichtert. Das AIM (Application Integration Module) integriert die zu einem Objektgeführten Diskurse der Community direkt in die vom Nutzer verwendete Applikation. Er interagiertdabei über das AIM Modul mit dem Hilfesystem und erhält Hilfeinformationen imKontext seiner Arbeit auf seine Anforderung bereitgestellt. Drei Eigenschaften werden dabeidurch das AIM – Modul realisiert:1. Integration in den Arbeitskontext des NutzersZiel des Moduls ist, trotz der Anwendungsunabhängigkeit, dem Nutzer den direktenZugriff auf Hilfeinformationen innerhalb seines Arbeitskontextes zu gewähren. Trittwährend der Bearbeitung einer Aufgabe beim Anwender ein Problem auf, so ist gewährleistet,dass der Hilfesuchende das Hilfesystem innerhalb seiner momentanen Arbeitssituationenaufrufen kann und nicht durch das Verlassen des Anwendungskontextesden Bezug zum eigentlichen Problem verliert.2. Einfacher und schneller Zugriff auf HilfeartikelNeben der direkten Integration in die Applikation geht die Implementation darüber hinaus,dass der Zugriff auf Hilfeinformationen mit möglichst geringem Aufwand geschieht.So muss die Usability der Nutzeroberfläche des Hilfesystems gewährleisten,dass der Nutzer durch einen einfachen Klick die Hilfeinformationen bereitgestellt bekommt,die ihn bei der Problemlösung am effektivsten unterstützen.3. Anwendungsunabhängiges HilfesystemAIM realisiert die Integration des Hilfesystems in beliebige Anwendungssysteme. Somuss gewährleistet sein, dass sowohl eine direkte Integration in den Arbeitskontext13 WIMP steht für Windows, Interface, Mouse, Pointer. Im Kontext der Eclipseprogrammierung werden WIMP-Funktionalitäten durch einige Basiskomponenten bereitgestellt, auf die dann Anwendungsentwickler aufsetzen.16

des Anwenders gegeben ist, als auch ein anwendungsunabhängiges Framework geschaffenwird, das für beliebige Softwareprodukte verwendbar ist.Das CAM (Context-Aware Adaptation Module) ermittelt die semiotisch bestimmten Objektebzw. eine Referenz darauf, die zum Nachrichtenaustausch herangezogen werden kann. Mankann sich das Modul auch als die Berechnung eines objektspezifischen Funkkanals vorstellen.Es fungiert dabei als Vermittler zwischen den Nutzungskontext und dem allgemeinen WikiSystem. Die Kunst des Moduls besteht darin sinnvolle und über die Zeit stabile Referenzenbereitzustellen (siehe Diskussion im vorherigen Abschnitt).Das CBHS – Modul stellt dabei die Communityfunktionalitäten bereit, d.h. den Punkt, an demNutzer zusammentreffen, um objektbezogene Messages auszutauschen oder eine Erläuterungzum referenzierten Objekt zu hinterlassen. Dabei liegt hier die Flexibilität in der Auswahl vonCommunitysystemen. Das Modul gewährleistet die Verwendung traditioneller Communitysysteme,jedoch bestückt mit speziellen Funktionalitäten, die für die Bereitstellung von kontextsensitivenHilfen nötig sind. In unserem Fall haben wir für dieses Modul ein Wikisystemausgewählt, das genau unsere Anforderungen trifft.In der konkreten Umsetzung wurde das am Lehrstuhl für Wirtschaftsinformatik und NeueMedien der Universität Siegen entwickelte Goupware System BSCWeasel 14 verwendet.BSCWeasel stellt als Desktopanwendung einen alternativen Zugang zum weit verbreitetenBSCW Groupware System bereit und diente als Basisanwendung für unser Hilfesystem. AlsVorteil erweist sich hier, dass das System auf dem Eclipse Framework aufbaute und so nützlicheFunktionen, wie die Standardhilfe und kontextsensitive Hilfe, genutzt und an unsere Anforderungenangepasst werden konnten.Abb. 6: Ablauf des Hilfeaufrufs in der ReferenzimplementierungZur Realisierung des CBHS-Moduls wurde das WikisystemAtlassian Confluence 15 eingesetzt,weil es Webservice API,die einen algorithmischenZugriff auf das System erlauben,und die anpassbare Nutzeroberflächebesitzt. Beides zusammenerlaubte es uns, das System harmonischin das Hilfesystem vonEclipse 16 zu integrieren und nötigeMethoden zur deiktischenReferenzierung bereit zustellen.Abb. 6 zeigt die prototypischeRealisierung des Konzeptes und14 Siehe: http://www.bscweasel.de (31.3.2007)15 Siehe: http://www.atlassian.com/software/confluence/ (31.3.2007)16 Siehe: http://www.eclipse.org (31.3.2007)17

den Ablauf des Hilfeaufrufs. Nach Aufruf des Hilfesystems (1) durch drücken der Taste F1oder entsprechenden Symbol- oder Menüeinträgen, werden dem Nutzer, passend zu seinerProblemsituation, die entsprechenden Hilfeartikel bereitgestellt (2). Die Idee, die hinter derObjekterfassung steht, ist das das am Interface selektierte Objekt ermittelt wird (vgl.: Wulfund Golombek 2001).Die Herausforderung lag hier in der Generierung einer Referenz, die ein Objekt im Sinne derdrei obigen Anforderungen semiotisch bestimmt 17 und mit den entsprechenden Hilfeinformationenverknüpft. Im Falle des CHiC-Prototyps, der an die kontextsensitive Hilfe gekoppeltwurde, wurde auf die so genannte View-ID zurückgegriffen, die die Entwickler zur AllgemeinenVerwendung öffentlich zugänglich gemacht haben und deshalb stabil gehalten werdenmuss. Für den Nutzer sieht es dabei so aus, als ob die Hilfe sich auf die angeklickte Sicht ausSchritt 1 bezieht.Nach Aufruf des Hilfesystems werden dem Nutzer die Überschriften der zu dem referenziertenObjekt verfassten Hilfeartikel angezeigt. Klickt der Nutzer im Schritt 2 auf eine der alsLink hinterlegten Überschriften gelangt er zum entsprechenden Hilfetext. Diese Hilfeartikelsind dabei Produkte der Community einzelner Nutzer oder des Herstellers, der diese (nachAuslieferung) erstellt hat. Da es sich bei den Hilfeartikeln um eine normale Wikiseite des zuvorbeschriebene Wikisystem handelt kann jeder (je nach Konfiguration des Wikisystems)den Hilfeartikel bearbeiten, bewerten oder kommentieren.Erfahrung mit dem CHiC PrototypenAufbauend auf dieser prototypischen Implementierung des CHiC-Konzeptes konnte das Systemeiner ersten Evaluation unterzogen werden. Jedoch sind neue Konzepte äußerst schwer zuevaluieren, gerade wenn es sich um communitybasierte Systeme handelt, dessen volle Auswirkungerst nach der Etablierung einer aktiven Community überprüfbar ist, weshalb die hiervorgestellten Ergebnisse nur tentativen Charakter haben.Die Erfahrungen mit dem CHiC Prototpyen beruhen auf Beobachtungen der alltäglichen Nutzungvon CHiC als integriertes Hilfesystem des BSCWeasel. Das BSCWeasel ist eine Desktopanwendungdie einen alternativen Zugang zu dem populären Groupwaresystem BSCWerlaubt und steht eine Reihe von Funktionen bereit, die kollaboratives Arbeiten besser unterstützensollen. Genutzt wird das BSCWeasel primär an einer Forschungsgruppe in Siegen, ander das BSCWeasel als Open Source Projekt in Projektarbeiten maßgeblich entwickelt wurde.Die hier vorgestellte Evaluation bezieht sich jedoch primär auf eine Usability Studie, in derdas Hilfesystem einer Reihe von Benutzungstests auf Basis der prototypischen Referenzimplementierungunterzogen worden ist. Die Usability Studie fokussierte dabei auf die Nutzbarkeitund Brauchbarkeit des Konzeptes. Die Untersuchung teilte sich in die Phasen, Benutzungstestmittels eines aufgabenorientierten Walkthroughs und in eine Interviewphase. Mittelsdes szenarienbasierte Walkthrough sollten möglichst authentische Nutzungssituation geschaffenwerden, um vor diesen Hintergrund den praktischen Umgang mit dem Hilfesystemim Anwendungskontext von BSCWeasel zu beobachten.17 D.h. dass die Referenz zeitlich stabil sein musste und der Nutzer zu jeder Zeit in der Lage ist, die Referenzierungsbedingungenreproduzieren zu können, um z.B. auf bereits gelesene Hilfeartikel zurückgreifen zu können.18

Um die aufgedeckten Handlungsmuster besser zu verstehen und weitere Erkenntnisse zur Akzeptanzdes Konzeptes zu gewinnen, wurden im Anschluss narrative Interviews durchgeführt.Während der 1 bis 1 ½ stündigen Untersuchungen zeigte sich, dass die direkte Integration desHilfesystems in die zugrundeliegende Applikation einen kritischen Punkt darstellt. Die visuelle„Verschmelzung“ des Hilfesystems mit BSCWeasel führte dazu, dass das Hilfesystemdurch den Nutzer nur als traditionelles Hilfesystem interpretiert wurde. Zwar wurde durch dieIntegration die Usability deutlich verbessert. Doch symptomatisch war die Aussage eines Nutzers,trotz der Benutzung der CHiC Hilfe während des Test im anschließend Interview überdas System und Hilfesysteme im Allgemeinen von sich uns den Rat gab, dass es doch einetolle Idee wäre, Wiki-Systeme als Hilfesystem einzusetzen, weil doch dann Hilfetexte kooperativerstellt und bearbeitet werden könnten. Diese Aussage zeigte, dass der Wiki Aspekt derintegrierten Wiki-Hilfe unseres Systems nicht wahrgenommen wurde. D.h. auf Grund dertraditionellen Nutzung von Hilfesystem wurde zwar Wiki gewünscht, aber nicht erwartet unddeshalb auch nicht entdeckt.Des weitern zeigte unsere Untersuchung noch ein anderes Problem, dass unser communitybasiertesHilfesystem noch eine weitere Altlast traditioneller Hilfesysteme ‚erbte’. Da die Nutzerwurden nicht direkt beauftragt, das Hilfesystem zu nutzen, konnten wir den Effekt beobachten,dass Probanden bei auftretenden Problemen gar nicht versuchten, mittels des Hilfesystemseine Lösung zu finden. In den anschließenden Interviews begründeten die Nutzer ihrNutzungsverhalten mit den negativen Erfahrungen, die zuvor mit Hilfesystemen gemachtwurden. Frustration durch erfolglose oder aufwendige Suche nach passenden Problemlösungenführte zu einer allgemeinen ablehnenden Haltung gegenüber eingebetteten Hilfen und zueiner Skepsis gegenüber neuen Konzepten.Zusammenfassend konnten wir aus unserer Untersuchung drei wichtige Erkenntnisse gewinnen:1. Usability Probleme bei der prototypischen Umsetzung des KonzeptTrotz der frühen Phase der Entwicklung verhielt sich, aufgrund der Integration in die Standardhilfe,das System bei der Nutzung als traditionelle Kontexthilfe erwartungskonform. Eslässt sich jedoch deutlich erkennen, dass dem Prototyp noch wichtige Funktionalitäten, wieeine Indexsuche fehlen bzw. die Gebrauchstauglichkeit an einigen Stellen, wie z.B. bei derErstellung von Texten, noch verbesserungswürdig ist.2. Intensivere Kennzeichnung der Communityaspekte durch Community EngineeringWährend der Untersuchung ließ sich erkennen, dass die fehlende Präsenz des Communityaspekteine kritische Größe darstellte. Auf technischer Ebene sollte eine bessere Präsenz sowohlinnerhalb des Metaartefakt Hilfesystem (z.B. durch Herausstreichung der Communityfeaturesauf den Wikiseiten), als auch das in dem eigentlich Artefakt (z.B. durch Anzeigen,wie viele Nutzer gerade online sind, oder das einblenden neuer Fragen in der Statusleiste)geschehen. Auf der nichttechnischen Ebene sollte überlegt werden, Methoden des CommunityEngineering anzuwenden, indem man z.B. Präsente (gratis T-Shirts) oder Ehrungen (User desMonats) für eine aktive Teilnahme auslobt.3. Integration in verschiedene Anwendungsfelder19

Die ursprüngliche Zielgruppe des CHiC-Konzept waren die Nutzer, denen durch die Weiterentwicklungdes Hilfesystems ein Diskursmedium zur verbesserten kooperativen Aneignungbereitgestellt werden sollte. In der Realisierung des Systems zeigte sich, dass das CHiC-System auch für Hersteller und Entwickler auf Grund der direkten Annotierbarkeit aus demNutzungskontext Vorteile gegenüber der traditionellen Erstellung kontextsensitiver Hilfe bietet.D.h.. technischen Funktionen die eigentlich für aktive Nutzer gedacht waren, können auchnur von den Softwareherstellern selbst beansprucht werden, um z.B. im Usability Test aufGrund von Interpretationsproblemen mit den Nutzern gemeinsam unmittelbar geeignete Erläuterungzu den Objekt zu schreiben oder nach Auslieferung auf Grund gemeldeter Nutzungsproblemedas Hilfesystems eines Softwareprodukt zu erweitern.SchlussbetrachtungWir haben versucht in diesen Beitrag den Weg von einer Idee nachzuzeichnen: von ihrer Entstehung,der kritischen Interpretation wissenschaftlicher Arbeiten im Lichte der neuen Ideen,der technischen Gestaltung zu den ersten praktischen Erfahrung ihrer Aneignung.Stellt man dabei die, in den semiotischen Überlegungen zum Konzept, dargelegten Potentialeder Idee mit den Erfahrungen der Aneignung der technischen Umsetzung in der Praxis nebeneinander,könnte man zu den Schluss kommen, dass die Realität die Technikgestalter wiederauf den Boden der Tatsachen geholt hat.Spannender finden wir in diesen Zusammenhang aber die Frage, worin sich die Nichtbeteiligungan einem communitybasierten Hilfesystem von der Nichtbeteiligung an einem nichtcommunitybasierten Hilfesystem unterscheidet. Bzw. die prinzipielle Frage nach methodologischenGrundlagen zur Erforschung des Zusammenhangs von den in neu entwickelten Artefakteneingeschriebenen Nutzungspotentialen, der Antizipation der Aneignung neuer Konzepteund deren tatsächlichen Nutzung.So zeigte die Evaluation zwar, dass der CHiC-Prototyp nicht dazu animierte eine aktive Communityzu etablieren und Hilfetexte zu generieren. Begründen lässt sich dies jedoch durchzwei entscheidende Faktoren. Zum einen konnte das CHiC-System nur in eine noch kleineund vorwiegend aus Entwickler bestehende, Community integriert werden, da sich dasBSCWeasel selbst noch in einer Alpha-Phase befindet und so noch eine aktive Gemeinschaftfehlte. Zum anderen lässt sich die fehlende Beteiligung auf die konkrete Umsetzung der Ideezurückführen. So zeigte die Evaluation, dass die Communityaspekte den Nutzern des Systemsnicht präsent sind und sie durch die Gestaltung nicht darauf aufmerksam gemacht werden.Zudem tauchten in der Umsetzung neue Nutzungspotentiale auf, die neben der eigentlichenIdee „Nutzer helfen Nutzern“ andere mögliche Aneignungspfade des Ansatzes von des Wikiinside Konzept in die Praxis aufzeigen. So zeigte sich, dass das System eine neue Infrastrukturfür die Hersteller von Softwaresystemen bereitstellt, die hinsichtlich der Gebrauchstauglichkeitgegenüber traditionellen Hilfesystemen eine komfortablere Erstellung von Kontexthilfebietet.Eine solche Aneignung des Konzepts könnte wiederum dazu führen, dass auf der Wiki insideIdee beruhende Systeme wiederum von einer Nutzercommunity aktiv genutzt werden. Dieswürde zwar sicherlich in einer anderen Art und Weise geschehen als wir uns das vorstellen,interessant wäre dies aber alle mal.20

LiteraturAng, I. (2003). Im Reich der Unsicherheit. Das Globale Dorf und die kapitalistische Postmoderne.Die Cultural Studies Kontroverse. A. Hepp and C. Winter. Lüneburg, zu Klampen:84-110.Bense, M. (1967). Semiotik. Allgemeine Theorie der Zeichen.Brödner, P. (2005). Software is Orgware – A Semiotic Perspective on Computer Artifacts.Proc. of the International Conference on User-driven IT Design and Quality Assurance(UITQ 05), Stockholm.Carroll, J. M. und M. B. Rosson (1987). Paradox of the active user. Interfacing Thought:Cognitive Aspects of Human-Computer Interaction. J. M. Carroll, BradfordBooks/MIT Press: 80-111.Carroll, J. M., P. L. Smith-Kerker, J. R. Ford und S. A. Mazur-Rimetz (1986). The MinimalManual, IBM Research Report.Covi, L. und M. Ackerman (1995). Such easy-to-use systems: How organizations shape thedesign and use of online help systems. Proceedings of conference on Organizationalcomputing systems, Milpitas, California, US, ACM Press.DeSanctis, G. und M. S. Poole (1994). Capturing the Complexity in Advanced TechnologyUse: Adaptive Structuration Theory. Organization Science 5(2): 121–147.Dey, A. K., G. D. Abowd und D. Salber (2001). A conceptual framework and a toolkit forsupporting the rapid prototyping of context-aware applications. Human Computer Interaction16(2-4): 97-166.DIN_9241 (1999). Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten –Teil 16: Dialogführung mittels Direkter Manipulation, Beuth-Verlag.Dix, J., E. Finlay, G. Abowd und R. Beale (1998). Human-Computer Interaction, PrenticeHall.Eglash, R., J. Crossiant, G. D. Chiro und R. Fouché, Hrgs. (2004). Appropriating Technology:Vernacular Science and Social Power, University of Minnesota Press.Gay, P. d., S. Hall, L. Janes, H. Mackay und K. Negus (1997). Doing Cultural Studies: TheStory of the Sony Walkman. London, Sage Publications.Grüttner, M. (2007). Entwicklung eines generischen Visualisierungs- und Interaktionskonzeptsfür kontextsensitive Hilfesysteme und prototypische Implementierung für dasEclipse RCP-Framework. Wirtschaftsinformatik. Siegen, Universität Siegen.Hepp, A. (1999). Cultural Studies und Medienanalyse. Wiesbaden, VS Verlag.Herrmann, T. (1988). Probleme bei der Konstruktion und beim Einsatz von Hilfesystemen.Einführung in die Software-Ergonomie. H. Balzert and H. U. Hoppe, de Gruyter.Hinds, P. J. und J. Pfeffer (2003). Why Organizations Don’t ‘Know What They Know’: Cognitiveand Motivational Factors Affecting the Transfer of Expertise. Sharing Expertise– Beyond Knowledge Management. M. S. Ackerman, V. Pipek and V. Wulf. Cambridge,MIT Press: 3 - 26.Hoffmann:, M. H. G. (2005 ). Erkenntnisentwicklung: Ein semiotisch-pragmatischer Ansatz.Frankfurt a.M., Klostermann.Houser, N. und C. Kloesel, Hrgs. (1998). Peirce, Charles Sanders: The Essential Peirce. SelectedPhilosophical Writings (1893-1913), Indiana University Press.Orlikowski, W. J. (1992). The duality of technology: rethinking the concept of technology inorganizations. Organization Science 3(3): 398-427.Pipek, V. (2005). From Tailoring to Appropriation Support: Negotiating Groupware Usage.Department of Information Processing Science. Finnland, University of Oulu.Pipek, V. W., V. (1999). A Groupware’s Life. Proceedings of the Sixth European Conferenceon Computer Supported Cooperative Work (ECSCW ’99), Kluwer, Dordrecht.Preece, J., Y. Rogers, H. Sharp, D. Benyon, S. Holland und T. Carey (1994). Human ComputerInteraction, Addison Wesley.21

Ramirez, L. (2007). Social construction of end user adaptations in context awareness systems.Sankt Augustin.Rolf, A. (2004). Von der Theoriearbeit der Informatik zur Gestaltung. Informatik zwischenKonstruktion und Verwertung - Materialien der 3. Arbeitstagung ,,Theorie der Informatik``Bad Hersfeld 3. bis 5.4.2003. F. Nake, A. Rolf and D. Siefkes, UniversitätBremen Fachbereich Mathematik & Informatik: 115-121.Shneiderman, B. (1983). Direct manipulation: A step beyond programming languages. IEEEComputer 16(8): 57-69.Shneiderman, B. (1997). Designing the user interface: strategies for effective humancomputerinteraction. Massachusetts, Addison-Wesley.Sternberg, R. J. (1997). Cognitive conception of expertise. Expertise in context. P. J. Feltouich,K. M. Ford and R. R. Hoffman. Cambridge, MIT Press: 45-62.Stevens, G., G. Quaisser und M. Klann (2006). Breaking it up: An Industrial Case Study ofComponend-based Tailorable Software Design. End User Development. H. Liebermann,F. Paterno and V. Wul, Springer.Stevens, G. und T. Wiedenhöfer (2006). CHIC - A pluggable solution for community help incontext. Proc of the 4th NordiCHi.Suchman, L. A. (1987). Plans and situated actions. The problem of human-machine communication.Cambridge, University Press.Törpel, B., V. Pipek und M. Rittenbruch (2003). Creating Heterogeneity - Evolving Use ofGroupware in a Network of Freelancers. Special Issue on Evolving Use of Groupware,Computer Supported Cooperative Work: The Journal of Collaborative Computing(JCSCW) 12(1-2).Wiedenhöfer, T. (2006). Help in Context Konzeption und Umsetzung eines communityunterstütztenHilfesystems. Wirtschaftsinformatik. Siegen, Universität Siegen.Wulf, V. und B. Golombek (2001). Direct activation: A concept to encourage tailoring activities.Behaviour & Information Tech. 20(4): 249-263.Wulf, V. und M. Rohde (1995). Towards an Integrated Organization and Technology Development.ACM Proceedings of the Symposium on Designing Interactive Systems.Zink, J. (2004). Kontinuum und Konstitution der Wirklichkeit. Analyse und Rekonstruktiondes Peirce’schen Kontinuum-Gedankens. Seminar für Philosophie, Logik und Wissenschaftstheorie.München, Ludwig-Maximilians-Universität München.22