Eksperimentel Systemudvikling 2009/2010

Transkript

1 Eksperimentel Systemudvikling 2009/2010 Philip Kristoffersen ( ) Thor Prentow ( ) Lasse Staal ( )

2 2 Abstract Aarhus Katedralskole is a Danish high school located in Århus, Denmark. The school plans to start a new line of education next year called International Baccalaureate (IB). Students taking IB will be required to complete at least 150 hours of volunteer work. This work will have to be reported by the activity leaders (e.g. description of activity and length of duration), written and reflected on by the students (e.g. journal of activities), and confirmed and accepted by the students' counselors. Because of this, the Aarhus Katedralskole would like to find a digital solution to this problem. This report is about our efforts to find a design proposal to such a system. At first, we will use an array of methods to analyze what the user requirements are. We will use contextual inquiry to explore how the school's existent systems are used. A Pact analysis will be performed to get an overview of the situation. Personas will be developed to help us with creating scenarios, but also understanding the users. Finally, we will define our found requirements. After performing our analysis it is clear that many of our first given requirements, such as "the system must be in-lined in the systems all ready used by the school", are not what the user actually wants. The user simply wanted the system to be easy to use for someone who already uses the school's systems. It is found that one of the key requirements for the system is that it must inspire the students to reflect on the work they have done, and how it has affected them. Prototyping is used to find further requirements and to narrow in on the functionality and design that the users want. First, a lo-fi prototype is used to find the basic design and functionality of the system, then a hifi prototype is implemented to prevent false findings from the first prototype, and to evaluate and test the findings from the first prototype. In our first prototype we tried to inspire reflection through implementing a reflection points (RP) system. However, during one of the user meetings it was found that the students thought it would turn out to be too competitive of an environment to be useful. We also try to support reflection by creating dynamic prompts with questions that inspired the students to reflect, this time with greater success. We then evaluate on the methods used, and discuss that personas did not work for us, as we did not have time enough for them. Still, our scenarios are found to be successful and useful. We further discuss that our prototypes are also successful, however, we used too much time on the physical appearance of the prototype (i.e. making it look pretty), which took time. Furthermore, we discuss that we should have included the future workshop in our method catalog, and that more user interaction would have been optimal. Finally, we conclude that we are satisfied with our final design solution and that we feel that the users were happy about the process too. Practical information In the project we developed a web based high fidelity prototype which is available at: This project can be found at:

3 3 Indhold Abstract... 2 Practical information... 2 Indledning... 4 Problemformulering... 4 Analyse... 5 Metodeanalyse & kravspecificering... 5 Contextual Inquiry... 5 PACT... 7 Personas Kravspecifikation Scenarier Opsamling Prototyping Lo-fi prototypen Hi-fi prototype Opsamling Reflektion Projektplanlægning Brugerinddragelse Metodevalg Fremtidsværksted Projektets fremtid Konklusion Bibliografi Bilag Lo-fi prototypen Figurer Hi-fi prototypen Figurer Guide til hi-fi prototypen... 37

4 4 Indledning Aarhus Katedralskole er et gymnasium beliggende centralt i Århus. Skolen har et ønske om at udvide sine studieretninger med en International Baccalaureate (IB). For nyligt blev skolen certificeret til dette og har nu påbegyndt arbejdet med at integrere denne uddannelse i deres nuværende struktur. Ud over at have de samme krav som en traditionel gymnasial uddannelse, skal en IB-elev over en periode på 2 år (2. og 3. g), gennemføre mindst 150 timers frivillige aktiviteter. Disse aktiviteter skal være ligeligt fordelt mellem de 3 kategorier, aktivt, service og kreativt. Aktivt dækker over fysisk aktiviteter, såsom at være hjælpetræner, vindsurfe eller klatre. Service dækker over f.eks. at hjælpe på et center for hjemløse, mens en kreativ aktivitet kan være indenfor reklamebranchen, eller et sted hvor der skabes noget kreativt. Da disse frivillige aktiviteter er obligatoriske for at kunne bestå sin IB studentereksamen, ønsker skolen en måde at kunne holde styr på hvor meget af de frivillige aktiviteter den enkelte elev har udført. Uddannelsen lægger stor vægt på at eleverne gennemgår en personlig udvikling, og reflekterer over de udførte aktiviteter. Det er derfor vigtigt at systemet inspirerer til reflektion og kreativitet. Eleven skal nedskrive sine erfaringer og tanker omkring de aktiviteter han/hun udfører. Dele af elevens noter skal afleveres og gennemlæses af en tilknyttet vejleder. Dette kunne foregå i et hæfte med papir og blyant, men skolen har interesse i at flytte det over til et elektronisk system i stedet. For at sikre at eleven har udført de frivillige aktiviteter, skal dette system også kunne give mulighed for at en eventuel koordinator på aktivitetssted kan indrapportere, når eleven har udført en række aktiviteter. Skolen benytter allerede, i høj grad, 2 IT systemer, Ludus og FirstClass. Ludus er skolens kalender- og skemaværktøj og FirstClass er skolens kommunikationsværktøj. På FirstClass er det muligt at sende beskeder til hinanden samt diskutere på diverse forums. I dette projekt vil vi komme med et løsningsforslag til skolens problemstilling; hvordan kan et system udformes så det er bedst muligt at benytte for IB-elever? Da projektets omdrejningspunkt er brugere vil vi udvikle løsningen i samarbejde med skolen. Vores primære kontaktperson er Eva Mejnertz der er ansat som lærer på skolen. Hun vil i fremtiden kunne komme til at repræsentere en vejleder i systemet. Problemformulering Den konkrete opgave er, at komme med et løsningsforslag til et system til IB-elever, vejleder og koordinator. Systemet skal for eleverne bruges til nedskrivning og aflevering af reflektioner over frivillige aktiviteter. Vejlederen skal kunne læse og kommentere disse reflektioner. Koordinatoren skal kunne godkende og indrapportere hvor længe den enkelte elev har brugt på en given aktivitet. Hvordan kan et system udformes for at opfordre eleverne til at reflektere over deres aktiviteter? Det er et nøglespørgsmål til opgaven, da løsningen skal lægge vægt på at inspirere til reflektion og perspektivering. Systemet skal, så vidt muligt, være integreret i et af skolens eksisterende systemer. Er det derfor muligt at integrere en løsning i de eksisterende systemer? Da projektet omhandler brugerdreven udvikling, vil vi se på hvilken indflydelse det har i forhold til normal udvikling. For at komme frem til den bedst mulige løsning, har vi brug for en analyse til at afdække kravene til systemet. Hvilke metoder vil i dette projekt være mest effektive til at afdække brugernes behov?

5 5 Analyse Vores analyse er baseret på en iterativ proces. Derfor kan vores analyse ikke læses som en sammenhængende udvikling da vi har været nødt til at vende tilbage til tidligere metoder og revidere disse. Selve analysen består af to dele, vores metodeanalyse og kravspecificering som hovedsageligt er baseret på indsamlet materiale inden vores prototypeudvikling blev igangsat. Dette afsnit ligger til grund for vores designforslag i den anden del af analysen, vores prototypeudvikling og evaluering. Da vi har benyttet brugerdrevet udvikling har processens omdrejningspunkt været vores brugermøder. Alle fire møder er kort beskrevet i nedenstående tabel. Til 0. møde havde vi en uformel samtale med vores kontaktperson Eva, der forklarede os skolens problemstilling samt hendes personlige tanker om hvordan en løsning kunne se ud. Dette tog vi med os tilbage og inden det første reelle møde lavede vi en mængde brainstorms over den ønskede funktionalitet og vores brugergrupper. Dette brugte vi som en basis for vores analyse. Den grove analyse åbnede op for en masse nye spørgsmål som vi havde med os til det første møde. Da et indledende krav var at løsningsforslaget skulle integreres i ét af skolens eksisterende systemer lavede vi et contextual inquiry over brugen af disse systemer samt et semistruktureret interview. Dette møde hjalp os til at forfine vores analyse og derved skærpe vores kravspecifikation. Op til 2. møde forberedte vi vores første prototype. Vi fik elever og vejledere til at gennemspille scenarier og evaluere prototypen. Dette ledte til vores sidste prototype, hi-fi prototypen, som er hjemmesidebaseret. Begge møder hvor vi benyttede vores prototyper har også skærpet vores krav til systemet yderligere. Møde Brugere Mål Metoder Prototype 0 Eva, vejleder 1 Eva, vejleder 2 Eva, vejleder Anders, IBkoordinator 4 3.g elever, 3 piger og 1 dreng. Få bedre kendskab til problemstillingen, brugerne, samt eksisterende systemer. Viden om eksisterende systemer. Kravspecificering. Evaluering af designvalg i prototypen. Semistruktureret interview Contextual Inquiry Scenarie gennemspilning Prototype evaluering Ingen Ingen Lo-fi prototype (papir) 3 Eva, vejleder 4 3.g elever, 3 piger og 1 dreng. Evaluering af ændringer af prototype Evaluering af vores møder. Scenarie gennemspilning Prototype evaluering Hi-fi prototype (web) Metodeanalyse & kravspecificering Contextual Inquiry Et contextual inquiry (CI) bruges typisk til at afdække hvordan et eksisterende system fungerer og anvendes, eventuelt med henblik på at forbedre det. Et CI foregår der hvor systemet bruges. Den daglige brug af systemet observeres og noteres. Rent praktisk kan det gøres ved hjælp af papir og blyant, eller mere avancerede teknologier kan tages til hjælp, såsom kamera og mikrofon. 1 Idéen er at den der udfører et contextual inquiry skal samarbejde med brugerne af systemet. Det skal gerne udføres ved hjælp af et "master-apprentice" (mester-lærling) forhold mellem brugeren og den der udfører CI. Det vil sige at brugeren skal "uddanne" udvikleren. Det kan foregå ved at brugeren stilles spørgsmål om hvordan forskellige dele af systemet anvendes. Men det kan også gøres ved at lade brugeren selv vise hvil- 1 BTT s.456

6 6 ke funktioner der er relevante. Samtidigt kan eventuelle nye ideer og ideer til redesign diskuteres med brugerne. 2 Det er vigtigt at personen der udfører CI sørger for ikke blot at observere, men også analyserer på de ting brugeren foretager sig, og spørger ind hvis det ikke er klart hvorfor brugeren anvender systemet som han gør. Det er samtidigt vigtigt at holde fokus på det system der skal analyseres, og få brugeren tilbage på rette spor hvis diskussionen bevæger sig væk fra det relevante. 3 Vi lavede et contextual inquiry i forbindelse med vores første rigtige brugermøde. Vi benyttede contextual inquiry til at få overblik over de to systemer skolen benytter i forvejen, hvordan de bliver brugt, og hvilke funktionaliteter de har. Det er vigtigt for os at kende til de to systemer da det nye system skal være intuitivt at anvende for brugere af de eksisterende systemer. Desuden bør vi undgå at lave funktionalitet der allerede er i de anvendte systemer. Det hjælper os desuden med at få afdækket krav til det system vi designer. Vi lavede det contextuelle inquiry som en blanding af observation og interview. Vi spurgte ind til hvilke funktioner der fandtes i systemerne, og bad brugeren udføre visse opgaver for at se hvordan det blev gjort i systemet. Vi havde en ordstyrer der ledte interviewet, en notar der tog noter, samt en tredjemand til at have overblik og sørge for vi fik alt med. Vores interviewform var løs. Vi spurgte ofte brugeren hvad der ville være relevant for os at se, samtidig med at vi selv spurgte ind til bestemte funktioner. De to systemer hedder Ludus og FirstClass. Nedenfor beskrives de oplysninger vi fik ud af den contextuelle inquiry. Ludus Ludus' primære funktion er som kalendersystem. Systemet tilgås som en hjemmeside ved hjælp af en browser. I Ludus kan eleverne se deres ugentlige skema, samt eventuelle ændringer i det. Alle lærere skal indtaste lektier og afleveringsfrister i Ludus, som eleverne så kan se. Lærerne kan også se de lektier andre lærere har givet eleverne, og kan dermed undgå at eleverne får for mange lektier der skal laves samtidigt. Afleveringer kan afleveres gennem Ludus, hvor læreren så vil have et overblik over hvilke elever der har afleveret til tiden. Filer og lignende kan uploades i forbindelse med lektier eller lektioner, og eleverne kan så hente dem derinde. Hvis der skal arrangeres noget på skolen, kan Ludus fungere som tilmeldingssystem, hvor elever og eventuelt lærere kan gå ind og melde sig på aktiviteterne. Lærerne kan indkalde eleverne til møde hvis det bliver nødvendigt. FirstClass FirstClass er skolens kommunikationssystem. Her sendes mails, filer og lignende. Både elever og lærere skal sætte sig ind i hvordan FirstClass fungerer, og det er forventet at de læser mails dagligt. FirstClass er organiseret i grupper/konferencer, hvor der er grupper for forskellige ting, såsom en gruppe for en klasse, for lærerne i en årgang, for udvalg osv. Man kan sende mails eller filer til enkeltpersoner, eller til hele grupper ad gangen. FirstClass har også chat funktion integreret. Brugerens anvendelse Eva anvender primært FirstClass til kommunikation. Hun anvender mest Ludus til at sende information til eleverne, altså læsestof i forbindelse med lektioner. Hun anvender det ikke som sit primære kalendersystem, hun foretrækker et andet system, der ikke er forbundet med skolen. Eva føler at hun bliver bombarderet med information og beskeder, primært i FirstClass. Hun er lærer for flere klasser, sidder i diverse udvalg og arrangerer frivillige aktiviteter. Sammenlagt betyder det at hun får 2 BTT s BTT s.455

7 7 rigtigt mange beskeder, som hun ikke synes er nemme at få overblik over i FirstClass. Hun har afhjulpet det lidt ved at afmelde visse grupper, og organisere resten fornuftigt. Chat delen i FirstClass bliver næsten aldrig benyttet, med mindre andre tager kontakt til hende først. For ikke at få samme funktionalitet flere steder, vil vi i det omfang det er muligt, benytte de eksisterende systemer, når de har funktionalitet der opfylder krav til det nye system. Eksempelvis er det værd at se på afleveringssystemet, idet eleverne skal dele visse sider fra deres dagbog inden en bestemt dato. Mødeindkaldelsesdelen kunne eventuelt bruges i forbindelse med at vejlederen skulle mødes med eleverne. Funktionen med aktivitetstilmelding kunne muligvis bruges i forbindelse med at eleverne skal ud til de forskellige aktivitetssteder. RP-systemet Da et af de vigtigste krav til systemet er at det opfordrer eleverne til at reflektere over deres oplevelser lavede vi en brainstorm over dette. På basis af vores indsamlede viden fra brainstorm, vores CI, samt idéer fra [Tay] og [Lin et al] kom vi frem til et system vi har navngivet RP-systemet (reflektionspointsystemet). Lee Sheldon fra Indiana University har med succes benyttet et system hvor eleverne får erfarings point for at løse opgaver, hvilket forhøjede elevdeltagelsen [Tay]. Ifølge [Lin et al.] er en meget god måde at få eleven til at reflektere over sine handlinger, at vise eleven at han/hun har fremskridt.4 En mulig måde at vise dette er ved at eleven hurtigt kan se hvor meget denne har rykket sig i forhold til i starten. Denne funktionalitet vil vi implementere med RP-systemet, hvor idéen er at eleven får reflektionspoint for at benytte systemet. Alle handlinger giver point, det vil altså sige at både det, at dele materiale, men også det, reelt at benytte materialet giver points. Når en elev får en speciel mængde points stiger han/hun et RP-niveau, og låser en række belønninger op. Det skal ikke give ekstra funktionalitet i forhold til brugen af systemet, men kan være små belønninger i form af for eksempel at kunne ændre tema i systemet. Når en elev har opnået et af en række specielle mål tildeles denne et trofæ som kan ses på statistik siden, hvilket igen er en måde at se eleven har rykket sig i forhold til starten. PACT PACT står for People, Activities, Context & Technology og er et framework til at forstå den nuværende brugssituation for en problemstilling og dermed få et overblik, så man kan se hvor der kan laves forbedringer. 5 Folk benytter teknologi til at udføre aktiviteter i bestemte kontekster. Alle fire dele er vigtige at have med. Der kan være forskellige brugere at tage højde for, hvad enten der er tale om fysiske eller psykiske forskelle. Disse brugere kan have forskellige mål når de benytter systemet og kan derfor anvende det forskelligt. Egenskaberne for aktiviteterne er også vigtige, for eksempel afhænger designløsningen meget af hvor tit en given aktivitet udføres. Når disse aktiviteter udføres, bliver det altid gjort i en bestemt kontekst, hvilket igen har en indflydelse på designløsningen. Her kan nævnes fysiske omgivelser. Til sidst har vi teknologi, hvor der her fokuseres på for eksempel input og output metoderne. 6 Efter en PACT-analyse er udført kan man sammensætte de forskellige elementer fra P, A, C og T der er mulige. Disse kombinationer kan herefter benyttes til at lave detaljerede brugsscenarier. Der kan være kombinationer der er i modstrid med hinanden, hvorfor designeren kan blive nød til at vurdere løsningsforslag imod hinanden. 7 Vi udførte en PACT-analyse over vores problemstilling, hvor informationen er baseret på brainstorming samt vores møder med Eva. People Der er 3 brugergrupper inden for det system vi skal udvikle. Der er elever, vejledere og frivillige koordinatorer. 4 Lin et al., P47 5 BTT s BTT s BTT s. 37

8 8 Koordinatorer Denne gruppe består af de personer der har ansvaret for at indrapportere hver gang en elev har udført en frivillig aktivitet. De vil ofte være direkte i kontakt med eleven ude på aktivitetsstedet og har derfor et relativt godt kendskab til eleven. Deres erfaringer med IT systemer kan variere meget. Elever Elevgruppen består af alle de IB elever, som skolen har på et givent tidspunkt. De går enten i 2. eller 3. g på gymnasiet og har tilvalgt IB linjen af forskellige grunde. Det må antages at de elever der vælger linjen er mere konkurrenceprægede og har et vist overskud i forhold til andre elever, da den er frivillig og der stilles større krav til eleverne end på standardlinjen. Der kan være sprogforskelle da det er en international bachelor. Eleverne benytter allerede skolens eksisterende IT systemer FirstClass og Ludus. Vi kan derfor antage at eleverne, som minimum, har lidt IT erfaring. Vejledere Vejlederne er ansatte lærere på skolen, der står for at guide en gruppe elever igennem IB forløbet. Enhver elev har en specifik vejleder og en vejleder har højest omkring 10 elever tilknyttet ad gangen. Ligesom eleverne, benytter lærerne også Ludus og FirstClass. Activities Hvilke aktiviteter der skal udføres i systemet, afhænger meget af hvilken gruppe personer der er med at gøre. Koordinatoren står for at indrapportere når eleven har udført en aktivitet. Dette skal kunne gøres på en sådan måde at eleven ikke kan snyde med det udførte arbejde. Hvor ofte og hvor mange gange en koordinator skal gøre dette afhænger af aktiviteten og aktivitetsstedet. Hvis eleven er færdig efter et enkelt forløb benyttes systemet kun én gang, hvorimod systemet benyttes mange gange hvis eleven gennemgår et forløb over flere måneder på aktivitetsstedet. Eleven skal igennem IB forløbet reflektere over de frivillige aktiviteter, der er blevet udført. Dette skal gøres igennem et dagbogs-lignende system og kan være af meget personlig karakter. Dagbogen skal derfor være privat. Eleven kan have behov for at vise dele af materialet til sin vejleder. Hvis dette er tilfældet skal det være meget tydeligt for eleven. Der vil igennem IB forløbet være flere afleveringer hvor eleven skal vise et uddrag fra sin dagbog. Dette uddrag skal vise at eleven reflekterer over det arbejde der bliver udført og at der sker en personlig udvikling. En anden grund til at vise vejlederen et stykke fra dagbogen kan være hvis eleven ønsker reel vejledning til en problemstilling han/hun er i. Som et eksempel nævnte vores kontaktperson at en elev kan have problemer med at skulle forholde sig til fysisk handikappede. Vejlederen skal kunne læse de sider eleven har delt samt give respons på disse i form af kommentarer. Vejlederen skal have mulighed for at sende beskeder til eleverne samt se statistik over elevens aktiviteter. Da eleven som nævnt har flere deadlines hvor der skal afleveres dagbogssider, skal vejlederen kunne specificere disse deadlines samt have et overblik over hvem der har afleveret. Der kan senere hen blive behov for flere vejledere, og der skal derfor også være mulighed for at vejlederne kan kommunikere med hinanden. Context Fysiske omgivelser Det endelige system skal bruges i mange forskellige former for fysiske omgivelser. Et sted er på skolen, hvor vejledere og elever har adgang til computere som de kan bruge til at tilgå systemet. Dertil kommer de steder hvor eleverne er ude for at udføre frivillige aktiviteter. Det kan være alt fra en genbrugsbutik til en teltlejr i en skov. Omgivelserne er meget forskellige, og stiller dermed meget forskellige krav til systemet. Vi kan for eksempel ikke regne med at eleverne, eller koordinatorerne af aktiviteterne, altid har adgang til internet. Selv ting som strøm er ikke en selvfølge, hvis de eksempelvis er af sted på en langvarig kajaktur.

9 9 Hjemmet og skolen udgør dog en stabil base, hvor vi godt kan regne med at der altid er adgang til et sted at arbejde, samt strøm, internet, osv. Social kontekst Elever og vejledere har nem adgang til at få kontakt med hinanden når de er på skolen. Det er derfor oplagt at eleverne i vid udstrækning kan bruge vejlederne og hinanden til at få inspiration til reflektion og dagbogsskrivning. Hvis de har behov for det kan de vende deres oplevelser med hinanden for at få et nyt perspektiv på det de har oplevet, og dermed en dybere reflektion. De kan nemt dele erfaringer om de steder de har været, og på den måde sørge for at flest muligt elever kommer af sted til de steder der giver mest udbytte erfaringsmæssigt. Da dagbøgerne kan indeholde ting som kan være meget private for den enkelte elev, er det vigtigt at de har et sted hvor de kan sidde og skrive i fred, uden nogen der kigger over skulderen eller lignende. Der er ikke enkeltrum på skolen, men de bør have rig mulighed for at skrive i fred i hjemmet. På skolen er det sandsynligvis ikke velset at sidde i fællesrum og arbejde med ting der larmer. Det kan derfor være et problem for eleven f.eks. at redigere video med lyd på skolen. Organisatorisk kontekst Med hensyn til elev-lærer hierarkiet på skolen, er det vigtigt at vores endelige system sørger for at overholde både de skrevne og de uskrevne regler der er omkring forholdet mellem elev og lærer. Det er blandt andet vigtigt at fortroligheden mellem vejleder og elev overholdes, så det ikke er muligt for andre at få adgang til eksempelvis en mail korrespondance mellem elev og vejleder. Det skal selvfølgelig også være umuligt for eleverne at "snyde", ved eksempelvis at registrere frivilligt arbejde som de ikke har udført. Technology Et af de vigtigste mål for teknologien bag systemet er at facilitere effektiv kommunikation mellem de forskellige brugergrupper. Da brugerne kan befinde sig mange forskellige steder er internettet en oplagt teknologi at basere systemet på. Systemet vil så kunne tilgås fra de mange systemer der allerede findes til at tilgå internettet, såsom computere, mobiltelefoner og håndholdte computere. Koordinatoren For koordinatoren er det vigtigt at systemet ikke tager for meget af hans tid. Af teknologiske muligheder findes computer og mobiltelefon, hvor eksempelvis mobilt internet vil gøre det muligt for ham at indrapportere elevernes aktiviteter med det samme. Det er vigtigt at den teknologi vi bruger, ikke er besværlig, samt at den er intuitiv at bruge. Det skal altså gerne være noget han er vant til at bruge. Derfor er mobiltelefon eller computer et oplagt valgt, da en typisk leder til daglig benytter sig af begge dele. Input til systemet fra koordinatoren kommer i form af informationer om hvilke elever der har arbejdet for ham, og på hvilke tidspunkter. Der er ikke som sådan noget output til lederen, ud over en besked om at hans info er registreret. Vejlederen For vejlederen er det overblik der er relevant. Igen er den mest oplagte teknologi en computer, da vejlederen til daglig er nødt til at anvende computere alligevel. For vejlederen er mobiltelefoner sandsynligvis ikke relevant, da det er besværligt at få et godt overblik på en lille mobilskærm. Input til systemet fra vejlederen er i form af digitale artikler, billeder og video, samt respons på elevernes dagbøger. Output til vejlederen er i form af statistik over hvor eleverne har været, hvor meget de har arbejdet, samt de sider fra elevernes dagbog, de har delt med vejlederen. Eleven Det vigtige her er at den underliggende teknologi giver eleven mulighed for at udtrykke sig frit. Det er vigtigt at eleverne reflekterer over de oplevelser de har haft, og derfor fungerer det ikke hvis systemet begrænser dem i deres udtrykskraft. Igen er computere en oplagt teknologi at bruge, da der så er nærmest uendeligt mange muligheder for at bygge systemer der fremmer reflektion.

10 10 Input til systemet fra eleven kommer i form af erfaringer fra elevernes aktiviteter, hvilket kan være udtrykt i form af tekst, billeder, video osv. som de har taget på deres aktivitetssted. Output til eleven kommer i form af respons fra vejlederen samt statistik over det arbejde de har udført. Personas Personas er fiktionelle personer, baseret på virkelige brugere, som hver især repræsenterer en brugertype. Personas bruges ment til at forstærke andre metoder 8, som f.eks. scenarier hvor de kan optræde som aktørerne i scenariet. Det er nemmere at forudse hvad en persona vil gøre i en given situation/scenarie. De forskellige personas kan laves ud fra enkelte rigtige brugere, og/eller statistik om rigtige brugergrupper 9. Vi har baseret vores personas på de informationer vi har fået af Eva om brugergrupperne, og har så igennem vores proces revideret dem, når ny information er kommet frem. F.eks. nægtede vores vejleder persona, i en tidlig udgave, at bruge computer systemet, men vi fik at vide af Eva at det var et krav for ansatte på skolen. Vi har også opdateret vores elev persona før møde 3, så hun stemmer mere overens med de rigtige brugere. Ud over at forstærke andre metoder kan personas også bruges internt som faste holdepunkter. De gør det nemmere at relatere sig til brugerne, tale om brugertyperne, forudse hvordan en bruger reagerer eller finde et scenarie med en persona i. 10 Vi har hovedsageligt brugt personas til at finde scenarier, og til udviklingen af den første lo-fi prototype. Da vi på det tidlige stadie ikke havde adgang til rigtige elever, var det nemmere at bruge vores persona for eleverne som et diskussionsemne, da alle så vidste hvem og hvad vi snakkede om. Der laves gerne 3 eller 6 personas. Da vi har 3 bruger typer, har vi valgt at lave 3 personas, der hver især dækker en brugertype. Eleven Sofia, anden års elev, 17 år. Bruger meget Facebook til at holde styr på sine venner. Nettet bruges primært til social interaktion men også fagligt. Hun er ambitiøs, med karakterer over gennemsnittet. Hun nyder at være sammen med sine venner, og vægter derfor sin fritid ret højt. P.t. arbejder hun hos red barnet hvor hun tager på weekendcamps med unge der har problemer. Hun har en moderne telefon, men benytter den ikke på internettet. Hun tjekker sin skole dagligt, da skolen kræver det. Hun har også en privat Hotmail som hun ikke tjekker regelmæssigt. Ellers bruger hun mest Facebook som en service. Vores persona Sofia er lavet til at være en person med meget overskud, det har vi gjort ud fra antagelsen af at personer der vælge IB, bevidst vælger et ekstra stykke arbejde oven i deres uddannelse. De fleste unge ved hvordan man bruger en web applikation, og det kan Sofia også, så vi får dækket brugere med en mere teknisk kunnen. Vejlederen John, 52 år Underviser i Engelsk og Matematik John er konservativ med hensyn til teknologi, han skriver ikke særligt hurtigt på computer, og kan egentligt ikke så godt lide det. Han synes det er nemmere at rette opgaver på papir, og kan i det hele taget bedre lide at arbejde med papir. Skal han arbejde med noget digitalt så printer han det ud. Det er nemmere for ham at arbejde med. Han har flere gange prøvet at miste digitalt data, og tager nu regelmæssigt backup. 8 Pruitt & Grudin s.3 l.4 9 Pruitt & Grudin s.5 10 Pruitt & Grudin s.7 l.7

11 11 Han har lært at bruge skolens systemer, men bruger det kun hvis han absolut skal. Han har en hjemmecomputer men den er gammel, og han bruger den kun fordi han skal ifølge skolen, han bruger ikke skolens systemer til at snakke med de andre lærere, men giver lektier for igennem skolens systemer. John kan godt lide at undervise, og er glad for sine elever. John er designet til at dække vores IT besværede brugere. Han dækker over den bruger gruppe som ikke kan lide IT systemer, fordi de ikke føler de kan stole på dem. John er blevet revideret løbende for at overholde de regler som Katedral Skolen har for sine lærere. John har ikke meget til fælles med vores kontakt person, som ellers er vejleder. Eva er ret IT kompetent, og vi havde brug for en persona som ikke var det. Koordinatoren Anders, 35 år Anders arbejder for Red Barnet, hvor han indgår i en lederstilling. Han er et meget optimistisk og positivt menneske der sætter opgaven at hjælpe andre meget højt. Hans tidsplan er generelt meget presset og har derfor ikke meget tid til hver enkelt opgave. På grund af dette skal mindre vigtige opgaver overstås hurtigt. Anders har ikke altid mulighed for at tilgå nettet når han, for eksempel, er på en weekend camp med belastede børn. Når han ikke er på camp bruger han tit internettet og tjekker hyppigt sin . Anders er lavet til at dække den bruger gruppe der har meget lidt tid til at bruge systemet. Han skulle være typen der ikke acceptere at noget er unødvendigt langsomt. Vi har ikke haft adgang til en rigtig bruger gruppe med Anders, så vi måtte basere ham udelukkende på vores egne brainstorms. Disse personas er designet til at holde os, som udviklere, i ørerne. De har mange træk som vi ikke har, de får derfor os til at tænke over hvordan andre brugere end os selv, vil forholde sig til vores løsningsforslag. Kravspecifikation De helt basale krav blev afdækket ved møde 0. Derefter har vi afdækket yderligere krav ved hjælp af et contextual inquiry på møde 1. Udviklingen af scenarier samt arbejdet med at planlægge lo-fi prototypen har også tilføjet krav til vores kravspecifikation. Funktionelle krav De fleste basale funktionelle krav kom forholdsvis hurtigt frem ved møde 1. Krav i forbindelse med elevens del af systemet: Hver elev skal have sin egen side, hvor de kan skrive dagbog og reflektere over udførte frivillige aktiviteter. Det skal være delt ind i de tre aktivitetskategorier: Creativity, Activity, Service. De skal være delt ind i undergrupper, hvor hvert aktivitetssted har hver deres gruppe. Visse dagbogssider skal kunne udvælges og deles med vejlederen. De skal kunne se hvor mange timers aktiviteter de har udført. Der skal udføres 50 timer inden for hver kategori. Eleverne må ikke kunne se hinandens dagbogssider, da dagbøgerne er personlige. Systemet skal kunne hjælpe eleverne med at finde aktivitetsstederne. For vejlederen har vi samlet disse krav: Det skal være muligt at se de sider eleverne har delt. Vejlederen skal kunne uploade artikler og lignende og sende dem til eleverne. Det skal være muligt at sende beskeder til eleverne. Der skal kunne oprettes en deadline eller lignende, hvor eleverne skal have delt en dagbogsside. Vejlederen har brug for at kunne se hvor meget arbejde eleverne har udført.

12 12 For koordinatoren er det følgende krav der gælder: Koordinatoren skal have en liste over de elever der er tilknyttet. Det skal være muligt at registrere at en elev har udført frivilligt arbejde på et bestemt tidspunkt. Det skal være muligt at tilknytte en kommentar til det arbejde eleven har udført Desuden var et af de første krav vi blev præsenteret for at det system vi lavede skulle kunne integreres i et af deres to nuværende systemer, Ludus og FirstClass. Dette lignede derfor helt klart et rent funktionelt krav. Efter at have undersøgt mulighederne for dette fandt vi dog at begge systemer var meget lukkede, så det ville være umuligt at udvide deres funktionalitet. Vi tog derfor kravet op med brugeren igen da vi udførte contextual inquiry, og vi fandt at det brugeren egentlig ville have, var at systemet var nemt og intuitivt at bruge for en bruger der var bekendt med de to systemer de allerede brugte. Det viste sig derfor at dette egentlig var et ikke-funktionelt krav. Ikke-funktionelle krav Ideen bag de frivilligt udførte aktiviteter er at eleven skal udvikle sig og lære noget om sig selv. Derfor var et vigtigt krav lige fra starten at systemet skal inspirere eleven til at reflektere. Der skal gerne være værktøjer i systemet der gør det enkelt for eleven at lave dagbogslignende sider, og det skal gerne være meget frit og op til eleven hvordan siden skal opsættes, igen for at fremme elevens reflektion, og for at eleven har mulighed for at udtrykke sig kreativt uden begrænsninger. Både eleverne og vejlederen skal i forvejen sætte sig ind i to systemer som skolen bruger. Derfor var det som nævnt et vigtigt krav at systemet minder om disse systemer, og er nemt og intuitivt at benytte for en bruger der er vant til at bruge disse systemer. For koordinatoren er det vigtigt at systemet er nemt at lære at benytte for en førstegangsbruger, da vi ikke kan antage at koordinatoren har specielt meget IT erfaring. Det er vigtigt, at det er nemt at lære, da der kan være mange koordinatorer på mange forskellige aktivitetssteder, det duer derfor ikke hvis de hver især skal bruge lang tid på at sætte sig ind i systemet. Desuden skal det være nemt for ham at finde de elever han skal registrere, og registreringen af eleverne skal også kunne foregå hurtigt, så han ikke bliver træt af at have frivillige elever af den grund. Scenarier Scenarier beskriver en situation hvor en eller flere personer skal udføre en opgave ved hjælp af det system eller produkt der skal udvikles. De er typisk skrevet som en form for historie, hvor det beskrives hvad der foregår. De kan indeholde forskellige ting, så som billeder og video, eller blot tekst. 11 Scenarier har typisk mange forskellige anvendelser i en designproces. I de første faser er scenarier i form af user stories nyttige til at finde ud af hvordan brugerne anvender et system, og hvad de gerne vil have. Konceptuelle scenarier er en abstraktion af user stories, og er nyttige til eksempelvis at afdække krav der viser sig i mange user stories. Derefter kommer konkrete scenarier, der typisk anvendes i forbindelse med evaluering af prototyper. Til sidst er der use cases der typisk bruges som en form for dokumentation for at systemet opfylder kravene. 12 Den type scenarie vi har valgt at bruge her er det konkrete scenarie, der beskriver en specifik interaktion med systemet. Scenarierne hjælper os primært på to områder. De hjælper os med at holde styr på funktionaliteten af systemet, og opdage manglende funktionalitet. Under arbejdet med at udvikle scenarierne opdagede vi flere funktioner der manglede for at scenarierne kunne fungere, som vi uden scenarierne muligvis først ville have opdaget senere. Desuden er scenarierne oplagte til at bruge til at gennemteste vores prototyper, da vi så kan se om brugerne kan finde ud af at gennemspille scenarierne på prototyperne. 11 BTT s BTT s.195

13 13 Vi har beskrevet et antal scenarier der sammenlagt gerne skulle dække over al den funktionalitet der er krævet af vores system. Sophia reflekterer over udført arbejde Context: Sophia vil skrive dagbog over dagens udførte arbejde, samt have overblik over udførte aktiviteter. Actor: Sophia, elev Location: Hjemme Situation: Sophia er netop kommet hjem fra et par timers arbejde fra Røde Kors. Hun beslutter sig med det samme for at skrive sine oplevelser ned. Da hun har taget et par billeder på sin telefon, sætter hun den til sin computer og overfører dem. Hun logger derefter ind på sin IBlog og uploader sine billeder og lægger dem ind i den rette kategori. Hun modtager RP point for at markere billederne med den rette kategori. Hun opretter et tekst område og begynder at skrive om dagens oplevelser. Halvvejs kommer hun i tanke om et passende billede, hun trykker derfor på billede-værktøjet der viser hende de sidste billeder hun har lagt op. Hun vælger det rette billede og trækker det op på siden. Da hun indsætter billedet åbner der en popup på skærmen, med en besked der spørger om hvorfor hun finder dette billede relevant. Denne besked er tidligere tilføjet af Sophias vejleder. Det svarer hun på, og teksten hun har skrevet indsættes automatisk under billedet. Da hun er godt tilfreds med dagens arbejde, vælger hun at dele det med sin vejleder da hun ifølge systemet har en deadline. Det gør hun ved at trykke på del knappen. Efterfølgende vil hun gerne have overblik over hvor mange timers frivillige aktiviteter hun mangler. Hun ser at Røde Kors allerede har opdateret oplysningerne fra dagens arbejde. Dermed er hun færdig med Service kategorien, men mangler 30 timer i Activity kategorien. Det vil hun gerne have udført, så hun går ind på oversigten over arbejdssteder i IBlog. Hun ser at Aarhus klatreklub har fået mange gode kommentarer, så hun beslutter sig for at sende en besked til dem for at høre om de har plads til hende. Desuden tilføjer hun en kommentar under Røde Kors, og beskriver sin oplevelse med dem. Dette scenarie dækker over den vigtigste funktion i systemet, elevernes reflektion over det frivillige arbejde. Det er derfor meget vigtigt at dette scenarie fungerer godt i det endelige system, og at det er nemt at gennemspille det. Scenariet dækker også over den funktionalitet der skal til for at kunne uploade billeder og video, hvilket også er en vigtig funktion, da det hjælper eleverne med at reflektere over deres erfaringer. Det beskriver også hvordan eleven modtager RP for at markere billeder, samt popups med relevante spørgsmål, hvilket vi håber, vil få eleverne til at reflektere mere. Desuden dækker det over den mere praktiske del af elevens system, det der holder styr på antallet af udførte arbejdstimer. Det er vigtigt at eleven nemt kan få overblik over det udførte arbejde, og derfor er dette relevant at inkludere i scenariet. John læser sine elevers reflektioner Context: På arbejdspladsen da det er en del af hans arbejdsgang. Muligvis i et travlt miljø, men sandsynligvis på et stille kontor eller lærerværelset. Actor: John, vejleder Location: På arbejdspladsen Situation: Eleverne har haft en aflevering hvor de skulle dele mindst én side der viser hvordan deres tanker er om-

14 14 kring den nuværende arbejdsplads de er på. Denne aflevering havde deadline dagen før og John vil nu læse afleveringerne igennem. Han logger ind på systemet og kan hurtigt se på overview skærmen at alle har afleveret rettidigt. Han klikker på den første elev og på elevens delte sider finder han den senest delte der har den rette overskrift. Mens han læser dem igennem ser han flere steder han kan tilføje vejledende spørgsmål og kommentarer. Han benytter "Tilføj popup" knappen og indtaster nogle beskeder der så vil dukke op næste gang eleven benytter systemet. Dette scenarie dækker over vejlederens funktionalitet. Vejlederen skal nemt kunne få overblik over de sider eleverne har delt, og skal kunne tilføje vejledende beskeder/popups som eleverne vil få. Anders indrapporterer Sophias tider Context: På aktivitetsstedet, er noget der skal ske hurtigt, stresset miljø Actor: Anders Location: På aktivitetsstedet Situation: Sophia har lige hjulpet Anders i 2 timer, og Anders vil indrapportere at hun har været der. Han logger ind på systemet og får en liste over alle elever der er tilknyttet ham. Han finder Sophia da han genkender hende på billedet. Han klikker på Sophia og får et overblik over hvilke dage han kan indrapportere for. Han begynder at taste tallene ind, og da han er færdig lukker han programmet ned og fortsætter med sit arbejde. Dette scenarie dækker over den funktionalitet der skal være tilgængelig for koordinatoren. Det er vigtigt at det ikke bruger for meget af hans tid, da det kan afskrække ham fra at være tilknyttet skolen. Opsamling Vi har udført et contextual inquiry over brugen af de aktuelle systemer. Denne metode, sammen med brainstorms, har været grundlaget for vores indledende PACT-analyse. Denne analyse var igen grundlaget for vores personas. De tre metoder har ledt os frem til en foreløbig kravspecifikation af det system vi skal fremstille. Disse krav er vores basis for vores prototyper som bliver beskrevet i næste afsnit. For at have et udgangspunkt til prototyping, har vi udviklet en række scenarier der skal benyttes til at gennemspille brugen af prototyperne.

15 15 Prototyping Prototyper er manifestationer af det endelige design. Hver prototype bliver designet, så den filtrerer/viser de kvaliteter som man er interesseret i, uden at forstyrre forståelsen af helheden. 13 En prototypes manifestation er hvordan den er lavet, eller hvad den er lavet med. To prototyper kan have samme filter men forskellig manifestation. Det fører til forskellige oplevelser af det filtrerede og derfor forskellige erfaringer. To prototyper kan også have samme manifestation men forskellige filtre, de erfaringer man gør sig vil være meget forskellige, da det er forskellige kvaliteter prototyperne repræsenterer. 14 Vi har valgt at lave to prototyper, med samme filter, men med forskellig manifestation. Vores filter er brugernes interaktion med klient siden af systemet, og den funktionalitet systemet skal have for dem. Vores første prototype er en low fidelity prototype, vores manifestation er tegninger på karton. Målet med denne prototype er at få styr på det basale layout af siderne i systemet. Det er nemt for os at ændre denne prototype og vores personlige erfaringer med andre lo-fi prototyper har vist at brugerne forstår at det ikke er et færdigt produkt. Brugeren er derfor mere kritisk, og kommer med flere forslag. I forhold til [Lim et al.]'s kategorisering af prototyper 15 er denne prototype af typen "understanding of user experience, needs, and values" og til dels "idea generation". Vores anden prototype er en high fidelity prototype, hvor vores manifestation er et computer system. Målet med denne prototype er at få styr på designet af siderne, den er af typen "evaluation and testing". Vi har 2 forskellige manifestationer for at undgå falske erfaringer, som er relateret til materialet prototypen er lavet med (altså manifestationen). 16 Falske erfaringer er erfaringer som brugerne gør sig ved brug af prototypen, men disse erfaringer viser sig kun at gælde for prototypen og ikke det endelige produkt. Lo-fi prototypen Selve systemet har vi delt op i 3 dele. Disse dele er elevens del, vejlederens del og koordinator delen. Vores grundlayout for eleven og vejlederen er en navigationsbar i toppen, hvor man kan se hvor på siden man p.t. er samt andre nyttige informationer. I bunden har vi endnu en bar, hurtigbaren, der giver adgang til de forskellige værktøjer/genveje du vil benytte på den side du er på. Se Fejl! Henvisningskilde ikke fundet.. I toppen af hurtigbaren er der en statusbar vi har kaldt RP-baren. Denne er en del af det tidligere beskrevne RP-system (se afsnittet om contextual inquiry). Formålet med baren er at vise hvor langt eleven er fra at stige et RP-niveau, og derved give dem en fornemmelse af fremskridt. 13 The Anatomy of Prototypes s The Anatomy of Prototypes s The Anatomy of Prototypes s The Anatomy of Prototypes s.22

16 16 Figur 1 Elevens system På forsiden ses de tre kategorier, aktivt, socialt og kreativt. Da eleven skal udføre 50 timers arbejde indenfor hver kategori har vi tilføjet en bar der viser hvor langt i forløbet eleven er for den respektive kategori. Når der trykkes på denne bar åbnes vinduet op hvor den totale tid er nedbrudt i enkelte aktiviteter. Dette dækker kravet om overblik over hvor mange aktivitetstimer der er udført. Dette vindue kan ses på Figur 8 vedlagt i bilaget. På forsiden har man adgang til 4 genveje; artikler, medier, forum og beskeder. De første to tager eleven til en side der viser alle ressourcer som han/hun har adgang til. Forum og beskeder går direkte til skolens eksisterende beskedsystem FirstClass. Vi har valgt at gøre det muligt for læreren at dele relevante artikler med eleverne. Det fremmer reflektion for den enkelte elev at kunne sammenligne sine egne erfaringer og oplevelser med eksperterfaringer. 17 Trykker man på en af de 3 aktiviteter, går man til den enkelte kategoris underside. I hurtigbaren på kategori-siden, har man adgang til de samme genveje som på forsiden. Der er dog tilføjet en knap til at åbne vinduet med hvor mange timer man har brugt på den givne kategori. Top baren er den samme men er nu opdateret med hvor på siden man er. Det er designet således at trykker man på en af de forrige sider så kommer man tilbage til denne, hvilket gør det let at komme tilbage til for eksempel forsiden. Da elevernes dagbogsbeskeder som oftest vil være korte tekster, måske med et tilhørende billede har vi lavet et koncept kaldet sider. En side er en samling korte tekster, billeder, lyd og videoklip der er sat sammen af eleven og er gemt med et unikt navn. Det er så op til eleven at arrangere materialet på disse sider, hvad enten eleven ønsker én side pr. dag, eller grupperer materialet på siderne på en anden måde. Herved får eleverne mere frie hænder til at være kreative. 17

17 17 På selve kategorisiden har vi gjort det muligt at gruppere disse sider. For eksempel ses det at eleven har en gruppe kaldet "Wind Surf" som kunne være et aktivitetssted eller en anden hjemmelavet gruppe. Herunder kan eleven gemme sider så det er let at finde frem til dem igen. Ud over sider er det også muligt at gemme diverse medier under disse grupper for at holde overblikket. Når musen (i evaluering af prototypen svarede en finger til musens markør) kører over en gruppe, foldes denne ud og viser de 10 sidste sider lagt under gruppen samt oprettelse af en ny side og upload af materiale. Et eksempel på en udfoldet gruppe ses på Fejl! Henvisningskilde ikke fundet.. Ved et klik på gruppen går man til en side der lister alt materiale under den pågældende gruppe. På siden har vi lavet 3 statiske grupper, "Sider", "Billeder & Video" samt "Artikler". De første to grupper indeholder hhv. alle sider og medier delt under den aktuelle kategori og det er muligt at uploade og tilføje nyt materiale direkte til disse to grupper. Man kan så senere vende tilbage og gruppere materialet. Figur 2 Klikker man på en ny side åbnes denne op og ser ud som Fejl! Henvisningskilde ikke fundet.. Siden har et standard navn, "Sidens navn" samt et tag. En side kan have flere tags og beskriver hvilke grupper den respektive side hører under (dette gælder også for medier). Man kan nu tilføje materiale til siden ved at trykke på f.eks. "Tilføj Billede" knappen viser en bar med de ti sidste tilføjede billeder (eller video hvis man ville tilføje video), og det er muligt at gå endnu længere tilbage. Denne bar kan ses på Figur 8 i bilaget. Man kan nu trække i det ønskede billede og placere det direkte på sin side.

18 18 Figur 3 Da vores løsningsforslag skal forsøge at fremme reflektion hos eleven kommer der engang imellem et vindue op med vejledende spørgsmål. Denne måde at stille vejledende spørgsmål, kan være en god måde at fremme reflektion og perspektivering på. 18 Et eksempel på et sådan vindue er vedlagt som Figur 8 i bilaget, som nogle gange åbnes op efter man har tilføjet et billede men endnu ikke noget tekst. Det må ikke være hver gang da det således hurtigt bliver trivielt. Disse beskeder har vi også tænkt kunne indeholde tekst som vejlederen har skrevet. Et eksempel på en færdig side i systemet er vedlagt som Figur 9 vedlagt i bilaget. Da det skal fremgå meget tydeligt om en bestemt side er delt med vejlederen er det vores tanke at "Del Side" knappen er grøn når siden er delt og ellers er den hvid. Den sidste elev side er statistik siden. Denne er vist på Fejl! Henvisningskilde ikke fundet. og er tilgængelig ved at trykke på statistik knappen på for eksempel forsiden. Her vises et nedbrud over aktivitet på siden samt en kalender over året hvor de forskellige deadlines til afleveringer er specificeret. Oppe i højre hjørne har vi trofæerne som er en del af RP-systemet. 18

19 19 Figur 4 Vejlederens system Vejlederens system starter på en side hvor alle vejlederens elever listes i venstre side og alle nye begivenheder står i højre side. Dette er vist på Fejl! Henvisningskilde ikke fundet.. Begivenheder dækker her over hver gang en elev deler et stykke materiale med vejlederen. I hurtigbaren har vejlederen adgang til artikler og medier, hvor han/hun kan uploade nyt materiale til eleverne. Derudover er der adgang til FirstClass systemet gennem knapperne "Forum" og "Beskeder". Ved et klik på en specifik elev åbnes denne op (se Figur 10 i bilaget) og der vises statistik over elevens brug af systemet. Listen til højre opdateres til kun at vise begivenheder specifikke for den markerede elev. Knappen "Statistik for elev" går til statistik siden beskrevet i elev systemet. Ved et tryk på de 3 status barer til højre for elevens billede åbnes vinduet med nedbrud over elevens aktiviteter. Til sidst er der et felt som kun er synligt for vejlederen, hvor der kan skrives elevspecifikke kommentarer til senere brug. Koordinatorens system Koordinatorens system er meget simpelt i forhold til de to andres. Det skal være let at indrapportere en elevs aktiviteter da en koordinator som oftest også selv udfører aktiviteterne frivilligt. På forsiden (se Fejl! Henvisningskilde ikke fundet.) er der en liste over alle de elever som den respektive koordinator har noget med at gøre, samt en kalender. Han trykker blot på en elev og vælger den dato aktiviteten er udført og indtaster hvor mange timers aktiviteter der er udført. Hvis der kommer mange elever i systemet for en koordinator er det muligt at søge blandt eleverne i søgefeltet over listen af elever. Det er muligt ved et tryk på ugenummeret at skifte mellem en ugekalender og en månedskalender.

20 20 Figur 5 Figur 6

21 21 Hi-fi prototype For at følge op på vores lo-fi prototype, valgte vi at lave en hi-fi prototype. Vi havde kun et møde ekstra til rådighed og for at komme uden om eventuelle fejlfund ved lo-fi prototypen, besluttede vi os for ikke at iterere mere på den, men at lave en hi-fi prototype. Vores valg blev også bekræftet da brugerne til møde 2, gentagne gange sagde at de "glædede sig til at se det køre". Implementeringsforslag Da en eventuel endelig løsning skal være en webbaseret applikation, valgte vi at vores hi-fi prototype skulle køre på en computer. Vi overvejede følgende forskellige teknologier at implementere prototypen i. Flash Flash er kendt for at være nemt og hurtigt til at få det visuelle look som man gerne vil have, men vi har dårlige erfaringer med Flash når det kommer til at implementere logik. Selvfølgelig skulle prototypen ikke være en færdig implementering, men vi forudså at det ville tage lang tid at sætte sig ind i og derefter implementere i Flash. Med Flash, ville systemet se meget fremmet ud for brugere af de andre systemer. Flash kræver et plugin, og det var vigtigt for os, at brugerne skulle kunne tilgå prototypen let, så de også kunne give feedback i deres egen tid. Java / C# En desktop applikation i enten Java eller C# var hurtigt oppe og vende. Det ville være let at implementere logikken, men det ville tage lang tid at få et look der lignede en webapplikation. Det ville også blive svært at få brugerne til at bruge prototypen i deres fritid, og få dem til at forholde sig til prototypen som en web applikation. GWT og Appengine Vi valgte at bruge Google Web Toolkit 19 (GWT) i kombination med Google App Engine 20 (App Engine). GWT giver et udviklingsmiljø der er nemt at vedligeholde og kode i. Koden bliver oversat til JavaScript og HTML, som giver et web applikation look, som brugeren er vant til. GWT kommer med et stort API som gør at mange af de simple ting er gjort for os (i modsætning til en simpel JavaScript løsning). I GWT lavede vi en server del og en klient del. Klient delen bestod af de elementer som brugeren så, og server delen serverede data som klienten skulle præsentere. I vores prototype var klient delen tæt på en færdig implementering, mens server delen altid gav de samme testdata. For at gøre vores prototype lettilgængelig uploadede vi den til App Engine 21. På den måde har vi gratis hosting, og let tilgængelighed. Ændringer i forhold til lo-fi Vi fik ved 2. møde ikke mange store ændringer, men små forslag til nye funktioner. Den grundliggende struktur i prototypen er den samme som i lo-fi prototypen. Vi har lavet følgende ændringer til prototypen: En af eleverne nævnte at det ville være rart at have adgang til de elementer som man sidst havde arbejdet med. Dermed skulle man ikke trykke så mange gange for at komme i gang med at skrive. Vi lavede en lille aflang bar på forsiden. Den er ikke påtrængende, men stadig synlig. Se Figur 12 i bilaget. Eva kunne tænke sig at eleverne havde en side med overblik over nuværende og mulige aktivitetssteder. Vores implementering lader en elev vælge et aktivitetssted (til venstre) og man kan så se kontakt information og en kort beskrivelse til højre

22 22 Når et sted er valgt kan man også se andre brugeres kommentarer. Vi inkluderede også et vurderingssystem af stederne, som senere skulle vise sig at være problematisk. Se Figur 14 i bilaget. I vores lo-fi prototype havde vi flere steder forestillet os at en drag and drop løsning ville være optimal. Men mens vi udviklede det, oplevede vi at vi ikke selv synes det var særligt intuitivt at benytte. De fleste steder blev drag and drop afløst af simplere klik løsninger. Se Figur 15 og 16 i bilaget. Brugerne synes at de små popups der kom, når man holdte musen over en gruppe på gruppesiden, var svære at finde ud af. Vi ændrede det til at være en enkelt popup der klart adskilte indhold fra handlinger. Se Figur 15 i bilaget. En af de store ændringer vi gjorde var at afskaffe RP systemet. Da vi ved møde 2 nævnte RP systemet var der meget blandede reaktioner. Et af de store kritik punkter var at det ville gøre frivilligt arbejde til en konkurrence. Eleverne mente at IB elever var meget konkurrenceprægede. Vi måtte derfor finde en løsning hvor eleverne kunne se deres fremgang, som så inspirerer dem til at reflektere over hvad de har lært, samtidig med at den fremgang ikke skulle kunne være et konkurrenceelement. Vi valgte derfor at afskaffe RP systemet, men at beholde trofæ systemet. Alle elever skal når de er færdige med deres uddannelse have fået alle trofæer. På den måde kan eleverne se deres fremgang, men vil ikke kunne konkurrere, da de alle vil opnå samme resultat. En mindre ændring, som viser at det ikke altid er nemt afdække brugernes krav, er at vi opdagede at CAS stod for de tre aktiviteter, Creativity, Activity og Service. Vi havde på vores forside sat de tre kategorier i forkert rækkefølge og kaldt dem forkerte navne. Vi fandt først ud af fejlen, da vi snakkede med en tidligere IB elev. Han forklarede at der er meget klare krav og veldefinerede definitioner for CAS. Noget vi ikke havde fået at vide til møde 0,1 eller 2. Se Figur 14 i bilaget. Evaluering af Hi-fi prototype Til møde 3 fik vi god feedback på vores hi-fi prototype. Brugerne var generelt glade for prototypen, men havde nogle forslag til ændringer. Siden møde 3 lå sent, kunne vi ikke nå at implementere disse ændringer i vores prototype og teste den igen. Vi vil her beskrive hvad vi havde tænkt os at ændre, havde vi haft tiden. Eva påpegede at en simpel point vurdering for hvert aktivitetssted ikke var tilstrækkeligt, og endda misvisende. Hun gav som eksempel at et sted kunne være godt for en, men samtidig være meget hårdt. Ens første reaktion ville være at give stedet en lav vurdering, selvom stedet måske var godt set fra et udviklingsmæssigt perspektiv. Skulle vi ændre dette, ville vi tilføje flere vurderingspunkter, som var mere præcise, sådan at situationer som den Eva beskrev, ville blive afspejlet korrekt. Eksempelvis et punkt der var elevens vurdering af hvor godt stedet havde været for elevens personlige udvikling. Eva lagde vægt på at vurdering af aktivitetsstederne ikke var en dårlig ide. Det skulle være mere klart og præcist hvad det var man gav en vurdering af. Både Eva og eleverne enige om at kommentarerne om aktivitetsstederne skulle administreres, så der ikke blev skrevet uhensigtsmæssige ting om det enkelte sted. Det kunne eventuelt løses ved kun at vise kommentarer som er accepteret af vejlederne, eller af en ekstern administrator. I vores prototype er det kun muligt at indrapportere aktivitetstimer for én elev ad gangen. Eva ville gerne have at koordinatorerne kunne indrapportere for flere elever ad gangen, da elever ofte ville lave aktiviteter i grupper. Ved at kunne indrapportere for flere elever, ville være det være nemmere for koordinatorerne, der således kun at skulle skrive tider og kommentarer ind en gang. En løsning til dette ville være at tilføje en checkbox ud for hver elev, sådan at man kunne afkrydse checkboxen for hver elev man ville indrapportere for. Det skulle selvfølgeligt også vises hvem man indrapporterede for i det vindue man skriver tiderne i. Både beskeder og forum knapperne tager brugeren til FirstClass, blot to forskellige steder. Brugerne var enige om at det var smartere at lave én kombineret knap der ledte til FirstClass. De fleste rettelser havde med valg af navne i vores prototype at gøre.

23 23 Vi havde f.eks. valgt at kalde siden hvor man kan se aktivitetssteder for "Workplaces", fordi vi så det som en side hvor man fandt et sted at finde frivilligt arbejde. Eva mente dog ikke at det var passende, da eleverne ikke udfører arbejde, men en aktivitet. Der var flere små navne ting, som vi ikke havde fanget i lo-fi prototypen, men fik fanget i denne hi-fi prototype. Opsamling Vi fik til sidst produceret nogle prototyper som vi var meget tilfredse med. Det var vores indtryk at brugerne også var glade for prototyperne, og at de synes om det system som prototyperne repræsenterer.

24 24 Reflektion Projektplanlægning Igennem projektet har vores dagbog været en vigtig del af vores arbejdsproces. Vi gennemgik flere forskellige måder at skrive dagbogen på for at finde den optimale for os. Til at starte med skrev vi dagbogen sidst på dagen. Dette forsagede at, til en af vores sessioner missede vi at skrive dagbog, da vi ikke nåede det. Derfor gik vi over til at skrive dagbog samtidig med at vi udførte de forskellige aktiviteter, hvilket virkede overraskende godt. Dertil begyndte vi at tilføje vores dagsorden for at have et overblik ligesom [Jepsen et al.] foreslår (deres forslag går på tjeklister). At have dagbogen som holdepunkt, gør det muligt at få flere detaljer med, som man ellers ville glemme. Som et eksempel, har vi i dagbogen foreslået os selv, at vi bør tage kontakt til en gruppe koordinatorer på aktivitetssteder, for at få dem bedre repræsenteret: Dagbogs uddrag d. 11/3 Tanke: Opsøg frivillig organisation som kunne skulle indberette og få dem til at gennemspille et scenarie hvor de skal indrapportere en elevs aktiviteter. Hvis man bliver i tvivl om hvorfor man har taget et givent valg, kan dagbogen også være til hjælp. Vores vejleder persona blev igennem forløbet opdateret, fra ikke at ville benytte IT, til at benytte det til de mest basale ting. Det var en nødvendig opdatering, da vi til første møde fandt ud af at det er et krav at lærerne på skolen benytter skolens IT systemer: Dagbogs uddrag d. 13/4 Vi fik at vide at alle lærerne SKAL bruge systemet, så vi reviderede vores vejleder persona, så den passer til den nye information. Ved at have det nedskrevet i dagbogen, kan der ikke senere opstå tvivl om hvorfor denne rettelse blev lavet. Vi havde i starten af projektforløbet lidt problemer med at få skrevet dagbogen, men senere i forløbet bliver det tydeligt hvor effektivt et redskab det er. Brugerinddragelse Hele projektets omdrejningspunkt har været brugerdrevet udvikling. Det har haft den konsekvens at brugermøderne kom til at diktere vores fremskridt. Disse brugermøder satte en række naturlige deadlines igennem forløbet. Ofte oplevede vi omvendt også, at vi nåede til et punkt, hvor vi ikke kunne komme videre, før efter næste brugermøde. Når man udfører brugerdrevet udvikling, afhænger ens resultat meget af brugermøderne. At have brugere inde over udviklingsprocessen har en række konsekvenser, både gode og dårlige. Vores primære begrænsning i den brugerdrevne udvikling har været længden på møde 2 og 3. Disse var begrænset af de deltagende elevers skema, da eleverne deltog i vores møder i deres egne pauser. At have adgang til sine brugere i så korte tidsrum, kan gøre det svært at benytte bestemte metoder. Vi synes vi har fået mest muligt ud af situationen, ved at have en fast dagsorden. Vi har ikke haft adgang til IB-elever. Det har været en større begrænsning i vores forløb. Da uddannelsen endnu ikke eksisterer på skolen, var vi begrænset til ordinære elever. De ville, hvis de kunne, have valgt at tage IB forløbet. Eleverne havde derfor ingen eller meget få erfaringer har indenfor området. Dog havde Eva skaffet os fire meget engagerede elever. De virkede alle interesserede i IB-forløbet og havde sat sig ind i sagerne på forhånd.

25 25 Vi spurgte ved slutningen af møde 3, hvordan brugerne synes det havde været at først have en lo-fi og så en hi-fi prototype. Specielt om de hellere ville have haft kun én type prototype, og flere iterationer på denne, eller de synes det var godt med to forskellige slags prototyper. Der var en del forvirring over lo-fi prototypen da vi først introducerede den for eleverne, men efter en kort introduktion synes eleverne det var nemmere at give kritik på lo-fi prototypen, da fokusområdet lå mere på det funktionelle end på det æstetiske. Derfor mente de at kombinationen af vores to prototyper havde været god. Det at udvikle i samarbejde med brugere giver også en række udfordringer med hensyn til kommunikation. Vi fangede os selv i flere gange at snakke om tekniske emner vores brugere ikke er bekendte med. Man bliver således tvunget til at blive klar i sine formuleringer således at alle er enige om hvad der er blevet kommunikeret. Dette er en god erfaring at gøre sig, og forbereder os klart til fremtidige projekter. Brugerne blev hurtigt enige om at de synes hele prototypeprocessen havde været god, og at de var glade for først at have en lo-fi prototype, de begrundede det med at de følte sig mere kreative når det var på papir. De var også glade for at have en hi-fi prototype fordi de følte at de bedre kunne forholde sig til den, og at det derfor var nemmere at finde "små fejl". Dette stemmer overens med teorien. 22 Metodevalg Igennem projektforløbet har vi benyttet flere forskellige metoder til at analysere skolens problemstilling. Heriblandt contextual inquiry og PACT-analyse. Disse to metoder faldt godt i spænd med projektets form og hjalp os med at specificere kravene til et løsningsforslag. Vi har også personas, scenarier og prototyping som metoder til vores analyse. Vi har haft en række problemstillinger med disse metoder. Vi har derfor valgt at beskrive disse problemer i de følgende afsnit. Afsnittet afsluttes med en evaluering af vores brugte metoder (vores metodekatalog) og en diskussion af hvad vi kunne have forbedret. Personas Det har været mere naturligt for os at tale om de rigtige brugere, i stedet for personas. Personas har ikke haft den store rolle som vi havde forventet. Det kan være fordi vi ikke har været flittige nok, til at bruge dem i vores diskussioner om systemet. Vi har måske designet dem godt nok, så de ikke er interessante og relevante. Personas er en stor metode at bruge i en så lille og kort udviklings proces som vi har lavet. Vi er kun 3 udviklere, og vi har haft 3 måneder til rådighed. Det anbefales at bruge langt længere på at udvikle sine personas. 23 Efter man har brugt lang tid med at udvikle personas, bliver de som en "personer man kender". Den oplevelse havde vi aldrig. Personas blev i vores projekt lavet på nogle få dage, og ikke 10 måneder som for Pruitt & Grudin. Vi vurderer selv at dette er årsagen til at vi ikke har kunnet bruge det til ret meget. Pruitt & Grudin foreslår i deres tekst at personas bliver inkorporeret i så mange udviklings metoder som mulig, og at man laver ekstra materiale som beskriver personas. 24 Vi har ikke haft tid til, hver gang vi har lavet noget, til at stoppe op og tænke hvad vores personaer ville gøre. Vi har heller ikke haft tid til at lave ekstra materiale der kun skulle forbedre vores forståelse og forhold til personas. Vi har haft en stram deadline, så prototypen og analysen har fået første prioritet. Begrundelsen bag vores valg af personas, som metode, var at de skulle hjælpe os med at finde scenarier og beskrive vores brugergrupper. På den måde kunne de hjælpe os til at beskrive den givne problemstilling. Vores personas har til dels hjulpet os med scenarierne, men vi kunne have lavet tilsvarende gode scenarier uden. Derudover har vi ikke benyttet vores personas til meget. Vi må derfor indse at vi har brugt for meget energi på personas. Energi som vi kunne have brugt andre steder. 22 The Anatomy of Prototypes s Pruitt & Grudin s Pruitt & Grudin s.8

26 26 Skulle vi lave et projekt af tilsvarende størrelse og tidsplan, ville vi formentligt ikke bruge personas igen. Skulle vi lave noget større, ville personas blive overvejet. Scenarier Det primære mål med scenarier var at gennemspille dem til evaluering af prototyperne. Vi brugte dem til at støtte os op ad da vi testede prototyperne, ved at bede brugerne udføre de ting vi havde beskrevet i scenarierne. Scenarierne fungerede godt til dette formål. De fungerede som en rød tråd igennem evalueringen, og hjalp os til at sikre at vi fik testet al den funktionalitet der var beskrevet. Dermed fik vi set om brugerne kunne finde ud af at udføre scenarierne som tænkt, hvilket de kunne. Under udarbejdelsen af scenarierne opdagede vi desuden diverse funktionaliteter der manglede. Scenarierne hjalp med at sikre et naturligt flow igennem systemet, således at alle funktionaliteter kan tilgås. Eksempelvis opdagede vi, da vi var i gang med at udarbejde et scenarie, et problem med vores upload funktionalitet. Vi havde funktionalitet til at indsætte et tidligere uploadet billede på en side, men der var ingen steder man kunne uploade billeder til at starte med. Det opdagede vi under udførelsen af scenarierne, og kunne derefter tilføje det. Alt i alt fungerede scenarier rigtigt godt for os, og var et godt supplement til designprocessen. I forbindelse med vores scenarier havde vi tænkt os at lave storyboards. Idéen var at storyboards skulle hjælpe os med at visualisere scenarierne, og hjælpe med at gøre scenarierne mere overskuelige overfor brugeren. Efter at vi havde lavet scenarierne og den første lo-fi prototype, følte vi dog ikke at der længere var noget behov for at lave storyboards. Scenarierne og prototypen supplerede hinanden fint, uden at det var nødvendigt med storyboards til at give overblik. At supplerer med storyboards ville derfor blot forstyrre, og give mere rod, i stedet for at hjælpe med at skabe overblik. Da vores lo-fi prototype var papirbaseret, kunne storyboards også komme til at ligne vores prototype meget, og vi kunne risikere at vores storyboards var tæt på en duplikering af vores lo-fi prototype. Havde vi lavet storyboards over det endelige system kunne det have været nyttigt, men dette valgte vi ikke at fokusere på. Storyboards kan være praktiske til at udtrykke brugen af et system i en bestemt kontekst eller lignende. Hver bruger type i vores system kan kun udføre én handling hver. Det er derfor ikke svært at danne sig et overblik over systemet. Skulle vi lave et system hvor hver bruger type kunne udføre mange handlinger, kunne storyboards give et overblik. Et overblik som kunne være svært at danne med scenarier, uden at lave mange af dem. Prototyper Prototypen i forhold til scenarier Vores prototyper er bygget meget op i forhold til scenarier. Vi har ofte tjekket om vi har kunnet spille vores scenarier igennem, med vores nuværende design. Vores endelige prototype er derfor meget tæt på hvad vi har beskrevet i scenarierne. Der er dog enkelte forskelle, som vi måtte lave i forhold til scenarierne, da brugerne bedte om det. Den største forskel er at vi valgte at afskaffe RP systemet. Generelt har scenarierne været en stor hjælp til prototyperne, specielt som gennemspilning ved møde 2 og 3. Scenarierne har været et godt holdepunkt. Vi udviklede vores scenarier samtidig med vores første prototype, det har derfor været lettere sørge for at vores scenarier og prototyper stemte overens. Lo-fi prototypen Vi brugte meget lang tid på at få lo-fi prototypen til at se så pæn ud som muligt. Vi tegnede den med lineal og brugte en kopi maskine for at være sikre på at elementer der skulle være ens, var helt ens. Vi havde først tegnet nogle hurtige skitser, men gik så igennem de forskellige sider og gjorde dem pæne. Vi nåede ikke at gøre leder siderne pæne, det tog simpelthen for lang tid. Da vi viste prototypen til brugerne, så det ikke ud til at det gjorde den store forskel, de forholdte sig ens overfor alle siderne.

27 27 Vi må derfor konkludere at vi har brugt for lang tid på at gøre vores lo-fi prototype nydelig. Vi kunne i princippet have tegnet prototypen i hånden, foran brugerne, så de virkeligt kunne se at alt kunne ændres, men så de stadig ville få en fornemmelse af hvordan layoutet af systemet ville være. Hi-fi prototypen Vores valg af GWT som implementerings metode, viste sig at have fordele og ulemper, som vi ikke havde forudset. GWT hjalp os meget med at få en meget modul baseret struktur, på den måde kunne vi genbruge komponenter og hurtigt skifte vores layout hvis vi ville. Dette var dog også det største problem ved GWT, det er svært bare at lave en hurtig implementering, der ser ud som om den virker men uden at have funktionaliteten. Vores prototype endte derfor med at være meget tæt på en færdig implementering, hele klient delen opfører sig stort set som det færdige produkt ville, men server delen giver kun test data. Vores hi-fi prototype tog lang tid at lave, i vores tilfælde var det ikke et stort problem, da vi havde tiden til rådighed imellem møde 2 og 3. Men generelt, brugte vi for lang tid på at holde kodebasen i prototypen genbrugelig, og generisk. Vurdering I retrospekt kan vi se at vi har forbrudt os mod den første prototype regel, at prototypen skal vise/filtrere de ønskede kvaliteter i deres mest økonomiske/simple form. 25 Vi oplevede at brugerne sjældent havde store ændringer til funktionaliteten eller layoutet af prototyperne, dette kan skyldes at vores prototyper ikke formidlede at dette var et produkt under udvikling men mere at det var et system der ikke kunne ændres meget. Vi spurgte brugerne om de ville ændre på layoutet, og de ønskede de ikke. Dette kan skyldes høflighed over for os, da de kunne tro at det tog lang tid at ændre. Vi oplevede at prototypernes filtre var for store, og systemet kunne virke uoverskueligt for brugerne. Systemet skal bruges af tre bruger typer, og har derfor tre forskellige tilstande det kan være i. I vores prototype har vi adskilt de tilstande, med en falsk login side, så man altid ved hvilken del af systemet man ser på, men man har stadig fornemmelsen af at ændrer man en del, ændrer man også de andre. Havde vi haft flere møder til rådighed, vil vi have delt hver del op i hver sin prototype. På den måde kunne vi fokusere på en del af systemet af gangen. Vi skulle dog være påpasselige med ikke at få for lille et filter, da hver del af systemet hænger sammen, og prototypen skal undgå at forvrænge den helhed den er i. Skulle vi lave prototyper igen, ville vi forsøge at gøre dem så simple som det er muligt, men så de stadig repræsenterer de ønskede kvaliteter ved det endelige design. Fremtidsværksted Vi havde forventet at brugerne ville komme med større ændringsforslag til møde 2. Det skete ikke. Vores første layoutforslag var baseret på vores erfaringer med andre web applikationer, og med inspiration fra Apple (da Eva er glad for deres design). Brugerne accepterede layoutet og funktionaliteten uden de store ændringer. Det kan være at vi har ramt plet i første forsøg, men mere sandsynligt er det at elevernes fantasi ikke blev stimuleret nok. Havde vi haft mere tid, ville et fremtidsværksted have været godt inden møde Fremtidsværkstedet ville have sikret at så mange af brugernes ideer kom med i den første prototype som muligt. På den måde ville vi ikke være begrænset af vores egne ideer. Det ville sørge for at brugerne ikke sent kom på funktionalitetsforslag, som til den tid ville være svære at integrere med den fundne løsning. Projektets fremtid Hvis vi skulle fortsætte projektet herfra er der flere ting vi kunne gøre for at forbedre systemet yderligere. 25 Pruitt & Grudin s Kensing et.al s.298

28 28 I vores metodekatalog medtog vi ikke et fremtidsværktsted. Det er senere gået op for os at dette kunne have været nyttigt. Idéer til funktioner og design af systemet er primært kommet fra os selv, i form af brainstorms og lignende. Vi har fået input fra brugerne under anvendelsen af prototyperne, de er kommet med ideer til forbedringer og kommentarer til designet. Men når de var tilfredse med det de så, var det som om de ikke tænkte videre over hvordan det kunne forbedres. Det burde et fremtidsværksted kunne hjælpe med, idet det sætter brugerne i en situation der lægger op til at alle ideer og kritik er velkommen, hvilket ville hjælpe os med at få flere ideer og kommentarer fra brugerne. Der vil det desuden være nyttigt at finde brugere der i forvejen går på en IB-linje. De brugere vi har benyttet i projektet har været et godt eksempel på eventuelle brugere af systemet, men for at få flere ideer til udvikling af systemet vil det være godt at have brugere der faktisk har prøvet at skrive dagbog, indregistrere arbejde og lignende. Et fremtidsværksted vil kræve mere tid end vi har haft mulighed for at få med eleverne under projektet, da det skulle passes ind i deres pauser. Hvis projektet skulle køres videre ville det derfor være nødvendigt at benytte elevernes fritid til at lave fremtidsværksted, da der gerne skulle være langt mere tid til rådighed. I og med at dette har været et projekt som skolen frivilligt har lavet med os har vi ikke kunnet tillade os at kræve mere tid med eleverne. Men hvis projektet skulle køres videre, ville det blive som en "rigtig" udviklingsproces, hvor målet var et fuldt implementeret anvendeligt system. Både fra vores side og katedralskolen ville det være på et mere professionelt plan, og det ville derfor sandsynligvis være nemmere at få mere tid med eleverne. I projektet har vi ikke haft mulighed for at teste koordinatordelen på en bruger. Denne del af systemet mangler derfor at blive gennemtestet af en relevant bruger. Her vil det derfor også være oplagt at samle en lille flok af koordinatorer fra de frivillige aktivitetssteder, og lave et fremtidsværksted. Med den erfaring de har med at udføre frivilligt arbejde og samtidig registrere udførte timer for elever, så vil de kunne komme med en masse gode ideer og kommentarer til systemet. For alle dele af systemet gælder det foruden fremtidsværksted, at der skal køres mange flere iterationer på designet. Det vil sige at vi skal have implementeret alle de nye ideer i prototyperne, hvorefter det skal afprøves på brugerne. Derefter analyserer vi på ideerne, implementerer og afprøver igen. Således skal der fortsættes til vi har et system både vi og katedralskolen er tilfredse med. Selvfølgelig kan tid gå hen og blive en begrænsning her, da et system jo i princippet kan forbedres i en uendelighed.

29 29 Konklusion Vi har i samarbejde med Århus Katedralskole designet et løsningsforslag der giver mulighed for at eleverne kan reflektere over udførte aktiviteter, samt for indrapportering af de frivillige aktiviteter. Vi har igennem projektet fremstillet et produkt i form af en high fidelity prototype. Selve prototypen har vi lavet som en webapplikation, da det giver høj tilgængelighed for brugerne af systemet, og vi kom frem til at det endelige produkt skulle være en webapplikation. Igennem vores analyse fik vi afdækket kravene til systemet. Her erfarede vi at indledende krav fra brugerne kan afdækkes til at betyde noget andet end hvad brugerne giver udtryk for. Et eksempel på dette var kravet om integration i eksisterende systemer, der blev afdækket til at betyde at det skulle være let at benytte løsningen for en bruger med kendskab til de eksisterende systemer. Vi har kigget på 4 måder til at få eleverne til at reflektere over de frivillige aktiviteter. Vejledende spørgsmål, visuelt fremskridt, ekspertartikler samt diskussionsforum. Baseret på dette kom vi med et løsningsforslag der inkluderede et RP system, hvor eleverne får points for at benytte systemet. Det var en succes hos den mandlige elev, men efter flere overvejelser omkring at løsningen kunne blive for konkurrencepræget valgte vi det fra igen. Vi lærte at det ikke er alle forslag som udviklerne ser som gode der nødvendigvis kan benyttes, selv efter en længere analyse og kravspecificering. Vejledende spørgsmål endte som den primære metode til at få eleven til at reflektere over udførte aktiviteter. Vi har benyttet flere forskellige analytiske metoder undervejs, hvoraf nogle fungerede bedre end andre. Specielt personas og storyboards faldt uden for dette projekts rammer. De vil helt sikkert kunne benyttes i andre sammenhæng, specielt større projekter. Som et alternativ foreslår vi fremtidsværksted, der kunne være nyttigt til at fremme brugernes kreativitet. Hele processen har været baseret på brugerinddragelse. Det har betydet en del organisatorisk set. Det kræver en anden form for planlægning igennem projektet, da man afhænger så meget af brugerne. Det er for eksempel er ikke altid muligt arbejde på projektet, da eventuelle møder med brugerne afhænger af hvornår de har tid. En anden erfaring med brugerinddragelse har været at blive tvunget til at være klar i sin formulering. Det at brugerne ikke har samme tekniske baggrundsviden, gør det vigtigt at formulere sig på en måde så alle parter er enige. I sidste ende kom vi frem til et godt løsningsforslag, som begge parter var tilfredse med. Det har været en spændende arbejdsproces, at arbejde med brugerinddragelse, som både vi og brugerne har lært meget af.

30 30 Bibliografi [Lim et al.] Lim, Y., Stolterman, E., and Tenenberg, J The anatomy of prototypes: Prototypes as filters, prototypes as manifestations of design ideas. ACM Trans. Comput.-Hum. Interact. 15, 2 (Jul. 2008), [Pruitt & Grudin] Pruitt, J. and Grudin, J Personas: practice and theory. In Proceedings of the 2003 Conference on Designing For User Experiences (San Francisco, California, June 06-07, 2003). DUX '03. ACM, New York, NY, 1-15 [BTT] Benyon, D., Turner, P. and Turner, S Designing Interactive Systems. Addison-Wesley. [Tay] Tay, L. Employers: Look to gaming to motivate staff, 2010, Web article from: [Lin et al.] Lin, X., Hmelo, C., Kinzer, C. K. and Secules, T. J. Designing technology to support reflection, Educational Technology Research and Development, Volume 47, Number 3 / September, Pages: (Found at: ) [Kensing et al.] Kensing, F., Bødker, K., & Simonsen, J. (2008). Professionel IT-forundersøgelse. Grundlag for brugerdrevet innovation, Samfundslitteratur 2. udgave, pp

31 31 Bilag Lo-fi prototypen Figurer Figur 7: Diverse vinduer i systemet Figur 8: Værktøjer til at skabe en "side"

32 32 Figur 9: Et eksempel på en færdig "side" Figur 10: Vejlederens system, detaljeret overblik over elev

33 33 Hi-fi prototypen Figurer Figur 11: Login side Figur 12: Elev Forsiden