DomänhjälpNils-Erik Gustafsson, Henrry Rodríguez, Kerstin Severinson-EklundhInledningDe allra flesta hjälpsystem innehåller felaktig, ofullständig eller onödig information. Att i förväg veta vilken information som användaren behöver är svårt -- ibland sägs det att man finner 90% av den sökta informationen i 10% av materialet; tyvärr vet man inte i förväg vilka 10% som kommer att vara intressant.Många hjälpsystem fokuserar på lågnivåproblem, t.ex. "Hur får jag det här ordet i fetstil?" och får härigenom karaktären av verktygshjälp. Problem av högre dignitet, som har att göra med verksamheten och uppgifterna, t.ex. "Hur skriver jag ett lättläst dokument?" lämnas oftast därhän. Den senare typen av problemställningar skulle man bättre kunna besvara genom en domänhjälp, med stöd för bidrag till och påverkan av innehållet av användarna själva. För ca 5 år sedan tog utvecklingsbolaget ELLEMTEL fram ett ATM-system, Ericsson Broadband System, varvid stor vikt lades vid att åstadkomma en sömlös integration av systemets användargränssnitt och domänhjälp. Domänen var här den underliggande telekomtillämpningen, och hjälp fanns att få dels i enkelt textformat, dels i ett hypertextformat baserat på SGML. Presentationsverktyget DynaText tillät i viss mån annotering -- en funktion som mottogs mycket väl av användarna. Andra tekniker som användes för att samla användarkommentarer var en inbyggd e-postfunktion, Mailorder Help, samt en dedicerad diskussionsgrupp (news group) på ett intranet. [1], [2] Erfarenheterna från projektet var goda, och väl värda att vidareutveckla. Det föreföll också som om många egenskaper hos ett idealiskt domänhjälpsystem borde kunna vara domänoberoende,varför föreliggande CID-projekt initierades i samarbete med IPLab, Nada, med utgångspunkt från IPLabs mångåriga arbete med stöd inom domäner som skrivande och typografi. KravinsamlingInledande krav på en prototyp genererades i en serie möten med representanter för olika domänområden, såsom drift & underhåll i telekomsammanhang, skrivarbete och typografi. Vi fick även inspiration från närliggande forskningsområden som Digital publicering,m.fl. Det stod tidigt klart att det borde gå snabbt att skapa en tillräckligt realistisk prototyp genom att använda webteknik med underliggande CGI-script.Att studera användning av något befintligt system bedömdes vara mindre meningsfullt, eftersom det tänkta verktyget skulle komma att skilja sig från vad som, såvitt vi kände till, existerade på marknaden. Erfarenheter av återkoppling från användare fanns emellertid genom tidigare arbete på ELLEMTEL. [2] Det valda tillvägagångssättet blev istället att snabbt få en tidig prototyp av Domänhjälpsystemet i drift, och genom praktisk användning med återkoppling (via systemet självt!) iterativt förfina prototypen. PrototypPrototypen fick formen av en "spröjsad" web-sida med fyra rutor, se figur A:Bild A Domänhjälpsprototyp
Till vänster en alltid tillgänglig innehållsförteckning,tänkt att innehålla beskrivande rubriker som fungerar som länkar till motsvarande informationsenhet, t.ex. problembeskrivning, åtgärdsförslag, regel, kapitel eller dokument. Överst till höger själva ursprungsinformationen,t.ex. ett källdokument som valts i innehållsförteckningen. I mitten till höger kommentarer som hör till visad
ursprungsinformation. Kommentarerna visas i strikt kronologisk ordning,
med ett huvud som anger datum, tidoch (optionellt) avsändare.
Underst till höger en ruta med en kommandoknapp märkt "Add
Comment", vilken ger användaren ett tillfälligt dialogfönster
med, rubrik och två inmatningsfält; ett (optionellt) för
avsändarens namn (eller nom de plume/guerre) och ett fritextfält
för kommentarer; se figur B.
Vi diskuterade huruvida användaren skulle ha möjlighet att klassificera kommenterer, via optionsrutor eller radioknappar, t.ex. som "fel", "tillägg", etc. men bestämde oss för att först studera faktisk användning för att bättre kartlägga behovet. En fördel med fritext var också att användargränssnittet blev så enkelt som möjligt -- användaren kunde omedelbart börja skriva sin kommenter utan att först (eller sist) behöva fundera över och klassificera den. När en kommentar har skrivits in i kommentardialogrutan trycker
användaren på knappen "Send", varvid kommentaren omedelbart
skickas via e-post till Domänhjälpsystemet, och kommentaren fogas
till de (ev.) tidigare. Användaren ser genast att kommentaren kom
fram, vilket ger en tydlig återkoppling att systemet fungerar, samt
tjänar som ett incitament. Alltför många system som erbjuder
möjlighet till att ge kommentarer upplevs som "svarta hål" --
det går bra att skicka e-post eller ifyllda web-blanketter, men de
försvinner bara utan att ge någon återkoppling alls, eller
också bara i form av ett (långsamt) e-brev. Hos Domänhjälpsystemet
är återkopplingen omedelbar, se Figur C.
StudieFör att utvärdera prototypen användes den inledningsvis för att publicera och kommentera IPLabs projektbeskrivningar. Syftet var inte bara att prova prototypen, utan fastmer att höja kvaliteten hos och främja en mera enhetlig utformning av dessa projektbeskrivningar. Personalen vid IPLab ombads per e-post att kommentera varandras projektbeskrivningar och att även kommentera prototypen.Prototypen innehöll även en inbjudan till kommentarer till själva verktyget, Domänhjälpsystemet, i form av ämnet "About this prototype". AnalysDe kommentarer som gjordes analyserades med avseende på form och innehåll, med följande resultat.Retoriska nivåerKommentarer gjordes på flera retoriska nivåer:
Fördelning av kommentarerFlest kommentarer gavs till ämnet "About this prototype" -- 48 stycken, varav 18 gavs som svar på andra kommenater.Det totala antalet kommentarer till 11 källdokument (test borträknade) fördelar sig som följer:
ObservationerDet är prototypens och källdokumentens utformning som leder till flest kommentarer. Kan detta bero på att det är mindre kontroversiellt att kommentera form än innehåll?Kommentarer till källdokumenten blir lätt för allmänna. Kan detta bero på att det är svårt att referera till egenskaper hos dokumenten? En kommentar kan hänvisa till en egenskap hos prototypen som inte längre finns. Detta beror sannolikt på att användaren inte har gjort "Reload" av web-sidan på länge. (Prototypen uppdaterades löpande.) En kommentar kan också referera till det tillfälliga dialogfönster i vilket kommentarer skrivs. FrågorNågra frågor som uppstår vid analysen av de gjorda kommentarerna är följande:Varför går det så trögt att kommentera källtexter, men så lätt att kommentera prototypen? Beror det på att prototypen är väldigt konkret, medan en projektbeskrivning är mera abstrakt? Anses det känsligare att kommentera vad någon har skrivit än vad någon annan har programmerat? Behövs ett speciellt dialogstöd, t.ex. för "trådade" kommentarer, i kommentarfunktionen? Vilka strategier kan detta leda till? Hur bör en redaktörsfunktion utformas? Behövs t.ex. olika filter- och sorteringsfunktioner? Vad innebär det att utväxla kommentarer kring multimedia- och hypermediadokument? Intervjustudie18 personer vid IPLab, TCS (Nada) och CID intervjuades personligen när kommentarerna börjat klinga av.MålMålsättningen med intervjustudien var att vinna kunskap om:
MetodIntervjuerna utfördes mestadels i försökspersonernas och i några fall i intervjuarens kontorsrum. En intervjualgoritm användes, liksom en bandspelare. I de fall försökspersonerna inte hade erfarenhet av Domänhjälpsystemet, gavs inledningsvis en demonstration. Varje intervju varade mellan 15-20 minuter. Alla deltagare från IPLab fick frågan om varför inte flera kommentarer hade lämnats, och samtliga blev tillfrågade om deras åsikter om möjligheten att få sitt arbete kommenterat av andra.Resultat och slutsatserDomänhjälpsystemet utvecklades i mars 1997 och har därefter modifierats avseende bl.a. layout och interaktion genom ett iterativt designarbete. Utvärderingen gjordes i slutet av maj samma år. Många av försökspersonerna var dåligt informerade om syftet med Domänhjälpsystemet, och varför eller för vilket syfte systemet kunde användas. Detta kan ha berott på följande:
Uppenbarligen kräver användning av den här typen av verktyg som kommentarverktyg att deltagarna är väl motiverade och är medvetna om den gemensamma nyttan. Domänhjälpsystemet användes generellt sett inte speciellt ofta, utan främst av de deltagare som var relaterade till Domänhjälpsprojektet; se figur 2. Intervjuerna visar också att de flesta deltagarna inte associerade Domänhjälpsystemet med Domänhjälpsprojektets egentliga syfte, utan mera uppfattade systemet som ett kommentarverktyg för dokument som publiceras på WWW. Termerna i figur 3 användes spontant av deltagarna, utan promptning av intervjuaren.
Uppenbarligen fungerade inte ett informellt e-brev med uppmaning att delta som tillräckligt incitament för deltagarna att använda Domänhjälpsystemet för att kommentera varandras projektbeskrivningar. Framförallt var det emellertid tidsbrist som angavs som skäl för att inte fler kommentarer hade lämnats; se figur 4. Två deltagare antog att den inbyggda begränsningen att gjorda kommentarer inte enkelt kunde dras tillbaka bidrog till ett lågt utnyttjande. Denna egenskap var emellertid en medveten begränsning av systemet; en begränsning som har både positiva och negativa effekter. Möjligheten att i efterhand dra tillbaka en gjord kommentar kan leda till "vindflöjelsbeteende" hos deltagarna, och trasslar framförallt till kommentarer som relaterar till andra, tidigare gjorda kommentarer. Om en viss kommentar leder till andra värdefulla kommentarer, vilka refererar till den första, ska då alla refererande kommentarer automatiskt dras tillbaka om den första dras tillbaka? Denna och andra möjliga situationer gjorde att vi, fullt medvetet, valde att ha denna begränsning i systemet.
Vidare diskuterades Domänhjälpsystemets kollaborativa aspekter; se figur 5. Nästan alla deltagare ansåg att det var väldigt bra att kunna få kommentarer från kollegor, men medgav samtidigt att kommentarer skulle kunna leda till problem. Några deltagare ifrågasatte att kommentarer lämnas s.a.s. in plenumoch inte privat. Emellertid tillåter verktyget möjligheten att lämna anonyma kommentarer, vilket hade kunnat lösa detta dilemma. På samma sätt hade den som hellre ville lämna privata kommentarer alla möjligheter att göra så, t.ex. via vanlig e-post, på papper eller muntligt öga mot öga. Kanske var deltagarna helt enkelt inte vana vid att få eller lämna negativ kritik?
Möjliga utvidgningarFöljande förslag till utvidgningar av Domänhjälpsystemets funktioner framkom:
Förslag till användning av prototypenMöjliga användningsområden för Domänhjälpsystemet som nämndes av deltagarna var:
Intervjualgoritm** introduction about the interview **. Do you know about 'Domain Help'? Briefly, What do you know about the 'Domain Help' project? Have you run DHS? YES { How often have run DHS? When was the last time you run DHS? Based on your experience, What would you use DHS for? What kind of information do you expect to find in DHS? What is your opinion about DHS' interface? What would you say are the strengths of DHS? What would you say are the weaknesses? **About your feelings ** What are some of the things that you liked about DHS? What are some of the things that you disliked about DHS? Which features would you add to improve DHS? Have you made any comment? YES { What did motivate you to make a comment? How did you find the interface to make a comment? Please give further comments, if you have any, about the way of providing comments in DHS. } NO { Which was the reason you did not make a comment? } } NO { GOTO X1 } } NO { X1: **Give a quick 'demo' and an abstract of the project.** } **Few feedback from users** Why do you think there have not been many contributions from IPLab in the form of comments on DHS? **Collaborative Design characteristic** What do you think about the possibility of making comments on a colleague's work in this written form which becomes available to the rest of the group?. How do you think people will like the idea to have comments, not only from their supervisor but also from their colleagues? Do you have any question about DHS? YES { ** answer ** } End Interview. Referenser
|