Gør-det-selv: Byg et supportsite!

Syddansk Universitet har taget en ny version af e-læringssoftwaren Blackboard i brug, som med en række nye funktioner selvfølgelig skal udnyttes bedst muligt. Samtidig har universitetet iværksat en række tiltag, som skal få endnu flere brugere til at benytte systemet - og helst også få dem til at bruge det bedre, dvs. til fordel for universitetets kerneydelser undervisning og forskning.
Det blev derfor besluttet at bygge en online supportfunktion til det nye værktøj op fra grunden. Ambitionen var en funktion, der som sidegevinst indlærer brugen af værktøjet. snedal.

Til det nye e-læringssoftware medfølger en manual, som alle brugerne har adgang til. Men vi fandt det smartere, hvis både erfarne og nye brugere kunne få online hjælp til et aktuelt problem, i stedet for at være henvist til at lede i en tyk (amerikansk) manual efter svarene.

Desuden er der naturligvis mange lokale forhold, der ikke er beskrevet i manualen - fx om institutionens e-læringspolitik, og om hvor man kan få yderligere hjælp. For slet ikke at tale om didaktiske overvejelser over brug af e-læringssoftware osv. osv.

I praksis viste det sig, at ingen brugerundersøgelser ville kunne give sikker viden om, hvad der var brug for. Bl.a. af den oplagte grund, at det system, der skulle udvikles support til, er så nyt, at vi kun har haft meget begrænset mulighed for at lade nogle 'almindelige' brugere teste det, inden det skulle tages i brug.

Hermed siger vi naturligvis ikke, at det slet ikke er relevant at gøre sig kvalificerede overvejelser på baggrund af empiriske (bruger)undersøgelser. Vi har blot kunnet konstatere, at virkeligheden i vores tilfælde ikke har levnet megen plads til at leve op til mere eller mindre videnskabelige grundighedskriterier.

Det eneste vi med sikkerhed kunne vide var, at der var behov for en supportfunktion. Vi var - med andre ord - overladt til (kvalificeret) tro, håb og nødvendighed.

Troen gik i vores tilfælde ud på, at vi var overbeviste om behovet for at oprette en online supportfunktion, der kunne hjælpe brugerne til at udnytte mulighederne i det nye værktøj.  Vi kunne ganske vist ikke på forhånd vide præcis, hvilke spørgsmål, der ville blive aktuelle for brugerne, eller hvor mange af dem, der ville være - men der ville helt sikkert blive spørgsmål, der skulle besvares.

Håbet gik i vores tilfælde ud på, at det faktisk ville være gavnligt for brugerne - og dermed for Universitetet og dets aktiviteter - hvis der eksisterede et online supportsite. Dog har vi aldrig været naive nok til at håbe, at vi én gang for alle ville kunne lave en fiks og færdig online supportfunktion, som så blot kunne søsættes og sejle sin egen sø. Vi var heller ikke naive nok til at håbe, at selv den bedst udførte og mest dynamiske online supportfunktion i sig selv kunne være tilstrækkelig.
Først når online tjenesten indgår i en større sammenhæng med mulighed for fx telefonsupport, tilstedeværelseskurser og måske 'erfa-grupper', begynder det for alvor at ligne noget. Og hvis der så også er mulighed for at henvise til en support- eller konsulenttjeneste, der fokuserer på andet end den rent 'betjeningsmæssige' side af sagen, så bliver det måske rigtig godt.

Nødvendigheden gav næsten sig selv: Forkromet supportfuntion med hot-line og døgnbemanding eller ej - en webbaseret hjælpeside skulle  og skal der til, hvis vi skal være os selv bekendt.

Og da der ikke fandtes sådan en i forvejen - så byggede vi en selv.

Det har været et grundlæggende ønske for os, at den webbaserede supportfunktion skulle være så nær på brugerne som muligt. Indholdet i supportfunktionen skulle nøje modsvare de behov for support, som brugerne har.

Der skulle være præcis den hjælp, som brugerne har brug for - hvorved vores supportsite ville adskille sig fra fx en traditionel manual, som i princippet skal beskrive, hvordan man gør alt, og hvad man overhovedet kan gøre i det værktøj, som manualen hører til.
Vi ville udnytte muligheden for at sigte mod en bedre defineret målgruppe, end produktets all-round manual nødvendigvis gør. Vi ville gerne lave en hjælpefunktion, hvor udgangspunktet er brugernes behov snarere end produktets funktioner.

 Supportfunktionen skulle også være nær på brugerne i den forstand, at den altid skulle være lige ved hånden i brugernes daglige arbejde med e-læringsværktøjet. Det skulle være sådan, at brugeren ikke var nødt til at bevæge sig uden for e-læringsværktøjet for at få den hjælp, han eller hun havde behov for. Med 'bevæge sig udenfor' mener vi i denne sammenhæng også at åbne et nyt browservindue for fx at konsultere en manual i.pdf-format.
Vi ville gerne, at hjælpen til e-læringsværktøjet blev givet. Målet var og er, at brugeren gennem sin brug af supportfunktionen ikke 'kun' får løst et eller andet konkret 'hvordan-gør-jeg-det-her'-problem, men at hun samtidig øver sig i at bruge e-læringsværktøjet - og måske støder på måder at bruge det på, som hun ikke selv havde tænkt på.

Det har været et mål for os, at supportsitet ikke blot skulle fortælle, hvordan man kunne og burde bruge e-læringsværktøjet, men også skulle fungere som praktisk eksempel på den anvendelse, som supportsitet handler om.

 
Vi ville altså ikke kun fortælle, at der er fordele ved nogle gange at bruge.htm, andre gange.pdf; at materialet i et Blackboard-kursus sagtens kan indeholde videofiler; og at de elektroniske diskussionsfora kan udnyttes til andet end 'bare at diskutere'.
Vi ville derimod praktisere disse anbefalinger ved (velvalgt!) brug af forskellige filformater, ved at integrere små videofilm, hvor det er hensigtsmæssigt, og ved at bruge e-læringsværktøjets diskussionsfora til at rammesætte kommunikationen mellem brugerne og os.

Hermed giver det også sig selv, at supportsitet måtte blive præget af en vis mangfoldighed:

• Vi bruger.pdf-dokumenter, hvor der er tale om materiale, som vi forventer brugerne vil skrive ud
• Vi har små tekster, som er beregnet til læsning på skærmen, og som er skrevet direkte i e-læringsværktøjets indbyggede web-editor
• Vi bruger.xml-dokumenter med tilhørende.xlst-stylesheets, hvor vi har en lang række informationsmoduler, som skal være lette at vedligeholde, og som skal fremtræde på samme måde hver gang
• Vi bruger små instruktionsvideoer i Flash-format til at beskrive, hvordan man foretager særligt kringlede operationer i systemet
• Vi bruger de elektroniske diskussionsfora til at sætte rammerne for brugernes feedback til systemet - en feedback, der for øvrigt skal bruges i den videre udvikling af supportfunktionen

Og vi ville gerne bruge endnu flere af værktøjets muligheder - fx streaming af videoklip med interviews af forskellige brugere, mulighed for synkron online-support via chat-værktøjet osv.

Et væsentligt succeskriterium for en supportfunktion er, at brugerne rent faktisk bruger den og er tilfredse med den. Det siger næsten sig selv, at det mål kun nås ved at lave en supportfunktion af høj kvalitet.

Hvad er kvalitet i denne sammenhæng, og hvad skal der til for at gøre vores site til et kvalitetsprodukt? Kvalitet kan ikke defineres entydigt, f.eks. er det i opgaven til en underviser på universitetet ikke det samme som i brevet til bedstemor. Og dog. Kvalitet kan være det, at teksten er tilpasset modtageren og opfylder dennes behov.

Supportsitets modtagere er brugerne. De opsøger supportsitet, fordi de har et problem, som ønskes løst. Supportsitet er eksperten.

Opfattelsen af supportsitet som ekspert skal bekræftes og bestyrkes, så brugerne ser det som pålideligt og dermed har tiltro til dets indhold - både indledningsvist og i fremtiden.
Det kan vi opnå ved, at sitet ikke har eller får mangler og aldrig fejler. Og desuden ved, at hjælpen tilbydes hurtigt og er let forståelig. Selvfølgelig er det optimistisk, men man har lov at stræbe. Og det har vi gjort.
Vi tog udgangspunkt i krav, frem for løsningsmuligheder. Det stod os klart, at hvis sitet skal udfylde sin rolle som et sted, brugerne ønsker at konsultere, så skal det leve op til en række krav:

• Overskuelighed: brugeren skal hurtigt kunne få overblik over supportsitets indhold og finde den relevante information
• Afgrænsning: hjælpen skal være afgrænset til enkeltsituationer og kun indeholde relevant information for den enkelte situation
• Klarhed: hjælpen skal være klar og entydig, så misforståelser undgås

Vi mener godt, det kan lade sig gøre at opfylde alle disse krav på én gang, hvis supportsitets informationsstruktur baseres på såkaldte moduliseringsprincipper.

Den helt overordnede idé bag moduliseringsprincipper er, at man skriver sin information én gang og så genbruger den.

Det letter også arbejdet med udvikling af sitet, fordi der blot skal udvikles aktuelle eller slettes uaktuelle moduler, mens resten af informationsmængden, i form af de resterende moduler, kan anvendes uændret. Derudover er den med til at sikre konsistens, fordi brugeren ikke risikerer at støde på samme information præsenteret på flere forskellige måder.

Det er netop brugernes feedback, der skal være den drivende kraft i videreudviklingen af supportfunktionen, både hvad angår form og indhold.

Hvordan er det så gået? Det spørgsmål kan i skrivende stund kun besvares delvist: Det er gået sådan, at vi har udviklet et supportsite, som vi er glade for, og som vi tror på. Vi mener egentlig, at vores forhåbninger - som beskrevet ovenfor - ikke er blevet skuffede. Først i løbet af efteråret 2004, kommer der rigtig tryk på, når brugerne henvises til supportsitet, hvis de har spørgsmål i forbindelse med brugen af det nye Blackboard, der møder dem ved semesterstart.
Så endnu engang må det blive ved håbet: Vi håber, at brugerne vil bruge sitet, og at de vil sige til, når de skuffes - når de fx ikke får svar på de spørgsmål, de opsøgte sitet for at få løst.

1. Syddansk Universitet: www.sdu.dk
2. Blackboard: www.blackboard.com

For at få adgang til det supportsite, der omtales i artiklen, kræves der en brugerkonto til elearn.sdu.dk. Forfatterne kan i meget begrænset omfang udlevere test-konti til særligt interesserede.

Litteratur

3. Horn, R.E. 1993: ”Structured Writing at Twenty-five”. Performance and Instruction 32.
4. Horn 1998:  ”Structured Writing as a Paradigm” i Romiszowski, A.; Dill, C. (red.): Instructional Development: State of the Art, Englewood Cliffs, Educational Technology Publications.
5. Hackos, J. 2002: Content Management for Dynamic Web Delivery, John Wiley & Sons.