RSS
Language:

Bachelorprojekt

(14 uger, Q1-Q2, 3. år af IT, 2010)

Så er vi blevet færdige med vores bachelorprojekt, og vi kan nu, efter mange lange arbejdsdage, tage det lidt med ro igen og se tilbage på processen. Selve projektet gik godt, og vi endte op med to prototyper samt en rapport. I det følgende blogindlæg har vi klippet og klistret dele af rapporten sammen, for at give et indblik i hvad vi har lavet. Den fulde rapport kan læses her.

Resume

Frivillige organisationer uddelegerer ofte opgaver til geografisk distribuerede, frivillige arbejdere. Til dette bruges ofte forskellige typer af opgavelister, som er dårligt synkroniserede og gør samarbejde til en udfordring.
I projektet undersøgte vi hvordan en konkret brugergrænseflade, vha. perifer information, kan gøre en opgaveliste lettere at overskue, og lette samarbejdet, gennem løbende feedback, mellem en ekstern, frivillig opgaveløser og den person som definerer og giver opgaven.

Gennem vores designproces fokuserede vi på, og samarbejdede med en frivillig organisation (UNITY). Opgaveløseren er også blevet involveret i processen igennem empiriske undersøgelser og afprøvning af low-fidelity prototyper.

Baseret på vores resultater og tidligere studier på dette område, konstruerede og vurderede vi to prototyper; en til opgavelederen og en til opgaveløseren. Disse prototyper er håndgribelige brugergrænseflader (TUI), hvoraf den ene er henvendt mod at opdatere opgavegiveren, mens den anden forsøger at motivere opgaveløseren til at opdatere hvor langt han/hun er med opgaven.

Vi skelner i følgende imellem to personer; en opgaveløser og en opgavegiver, hvor opgaveløseren i vores tilfælde er en ekstern person der har modtaget en opgave af opgavegiveren, som løbende ønsker at modtage feedback om opgavens status.

Research question

For at holde fokus og have et mål for projektet udarbejdede vi et research question. Dette gjorde vi på baggrund af en indledende undersøgelser omkring opgavestyringsdomænet, og efter at have haft kontakt til og interviewet UNITY, som var vores målgruppe/samarbejdspartner i projektet. Efter et par iterationer på vores research question endte det med at være følgende:

How can TUI provide peripheral visibility to a task list, and facilitate collaboration through continuous feedback from an external, voluntary task solver to the task leader?

Processen

Følgende illustration giver et overblik over vores proces i projektet:

Efter at have valgt opgavestyring som vores fokusområde, indhentede vi bl.a empiri vha. online spørgeskemaer. UNITY blev valgt som samarbejdspartner igennem projektet, og på baggrund af et kvalitativt interview med dem, færdiggjorde vi vores research question. Efter en brainstorm, udvalgte vi tre af vores koncepter vi evalueret i samarbejde med UNITY.
Efter prototypekonstruktion og en første test af denne, lavede vi yderligere en pluralistic walthrough i konteksten med UNITY.

Konceptet

Dataflow i prototypen


Konceptet går kort fortalt ud på, at vi giver opgaveløseren mulighed for automatisk at melde tilbage med statusopdateringer på opgaven. Dette gjorde vi muligt på følgende måde: Opgavegiveren giver, ved overlevering af opgaven, opgaveløseren en kagedåse. De aftaler, at opgaveløseren må spise kager fra kagedåsen mens han/hun er i gang med at løse opgaven – således at det passer med at alle kagerne er spist, når opgaven er løst. Kagedåsen som opgaveløseren har, melder løbende tilbage til opgavegiveren om hvor mange kager der er spist, og opgavegiveren kan på den måde få et skøn over hvor langt opgaven er kommet.

Det bør nok her påpeges at der ikke behøver at være kager i kagedåsen, men at dette også kunne være en dåse med delikate chokolader eller nødder.

Illustrationen til højre beskriver grundlæggende hvordan dette fungerer.

Prototyperne

Vi endte med at realisere vores ide om en digital kagedåse med indbygget vægt, samt en installation (en opgaveskinne) til opgavestyrerens kontor.

Cake Tin Prototype

Kagedåsen

Selve kagedåsen består af to dele. En dåse hvori kagerne kan gemmes, samt en base. Selve basen udførte vi i blå skum. På fronten af basen placerede vi en stribe rød/grøn dioder, som vi brugte til at vise opgavens status og på undersiden placerede vi fire strain gauges, vi brugte til at udregne basens samlede vægt og dermed se hvor langt en bruger er kommet med en opgave. For at kunne kontollere sensorer og LEDs indbyggede vi en elektronisk styring baseret på en ATMEL ATMega8 chip. Desuden hackede vi en USB til RS232 converter og byggede den ind i basen. Dette gjorde det muligt for os at trække strøm direkte fra computeren og sikrede at vi kunne sende basens målinger til en computer og kontrollere basen fra en applikation på computeren.

Opgaveskinnen

Opgaveskinnen er realiseret i Lego, og har til funktion at vise hvor langt en opgave er kommet. Dette gøres vha. et lille papstykke, hvorpå man kan placere fx en post-it note, der beskriver hvilken opgave der vises. Skinnen er ligesom kagedåsen styret af en ATMega8 MCU, der sørger for at kommunikere med et lille Java program på den tilsluttede computer, og derved få den opdaterede status på opgaven direkte fra Google Docs.
Når kagedåsen opdaterer opgaven online, vil opgaveskinnen registrere dette, og fysisk flytte post-it noten henover væggen vha en Legomotor. Afstanden opgaven er flyttet måles ultralydsafstandsmåler, der gør MCU’en i stand til at flytte opgaven præcis i forhold til hvor langt opgaven er. Samtidig opdateres den indbyggede progress bar (en række LEDs henover opgaven), der hjælper opgavestyreren til at se om opgaven følger tidsplanen.

Softwaren

Til at styre de to dele af projektet skrev vi to Java applikationer. Hhv. en applikation til opgaveløseren og en applikation til at styre opgaveskinnen (på opgavegiverens kontor).

Til opgaveløseren lavede vi en applikation, der kan kommunikere serielt med kagedåsen for at aflæse vægten. Når vægten blev aflæst, opdaterede denne en entry i et Google Docs Spreadsheet. Denne værdi kunne vores applikation til opgavegiveren så hente og indstille opgaveskinnen efter. Applikationen på opgavegiverens kontor gør det desuden muligt at registre nye opgaver til systemet.

Til de to ATMega MCU’er skrev vi også et mindre stykke software, i sproget BASIC, til styring af delene på prototyperne, samt til at kommunikere med Java applikationerne på computerne.

Konklusionen

Vi konkluderer, at der eksisterer et behov for at holde styr på opgaver, og at vores produkt til opgavegiveren løser dette behov. Vores produkt til opgaveløseren skal dog udvikles yderligere (da den nuværende prototype muligvis er for upraktisk og ikke testet godt nok endnu), og det næste trin i projektet ville være at gennemføre yderligere feltundersøgelser med begge prototyper.

Læs den fulde rapport her