DigitaleFestivalarmbånd

IT-Universitetet i KøbenhavnAarhus Vocal Festival

I samarbejde med

Emil Blædel NygaardSimon Westh Henriksen

Et bachelorprojekt af

Et projekt om udførelsen af et designprojekt i en organisation medfrivillige, samt brugen af RFID-tekonologi til adgangskontrol.

Maj 2013

Side 1 af 64

Indhold

Abstract ........................................................................................................................................... 4

1. Indledning ................................................................................................................................... 5

1.1 Baggrund ............................................................................................................................... 5

1.1.1 Organisationen ................................................................................................................ 5

1.1.2 Bestyrelse og drift ........................................................................................................... 6

1.2 Projektets problemformulering ............................................................................................. 6

1.2.1 Projektets grundlag ......................................................................................................... 6

1.3 Afgrænsning .......................................................................................................................... 7

2. Relateret arbejde ......................................................................................................................... 8

2.1 “Obstacles to design in volunteer based organisations”........................................................ 9

2.2 “Collecting location-based voice messages on a TalkingBadge” ....................................... 11

2.3 “CAVEAT Examplar: Participatory Design in a Non-Profit Volunteer Organisation”...... 11

2.4 Delkonklusion ..................................................................................................................... 12

3. Planlægning af designfasen....................................................................................................... 13

3.1 Overordnede valg til designfasen ........................................................................................ 13

3.1.1 Future Workshop .......................................................................................................... 13

3.1.2 Frivillige-session og evaluering af prototype ............................................................... 14

3.2 Tidsrammen ......................................................................................................................... 15

3.3 Prototypen ........................................................................................................................... 15

3.4 Plan for design ..................................................................................................................... 17

Side 2 af 64

3.4.1 Future Workshop .......................................................................................................... 17

3.4.2 Frivillige-sessions ......................................................................................................... 18

3.4.3 Afprøvning på festival .................................................................................................. 18

4. Forskningsmetoder .................................................................................................................... 19

5. Designfasen ............................................................................................................................... 22

5.1 Future workshop med AAVF arbejdsgruppen .................................................................... 22

5.1.1 Kritik ............................................................................................................................. 22

5.1.2 Fantasi ........................................................................................................................... 23

5.1.3 Realisme ....................................................................................................................... 24

5.1.4 Forslag vi har taget med fra workshoppen ................................................................... 24

5.2 Frivillige sessions ................................................................................................................ 25

5.2.1 Generelt om de frivillige............................................................................................... 25

5.2.2 Test af prototype ........................................................................................................... 26

5.2.3 Opfølgende spørgsmål til frivillige og generel feedback ............................................. 26

5.2.4 Forslag vi har taget med fra frivillige-sessions ............................................................ 27

6. Implementation ......................................................................................................................... 28

6.1 Udgangspunkt (prototype)................................................................................................... 28

6.2 Implementering af forslag ................................................................................................... 28

6.2.1 Årsag til afvisning ........................................................................................................ 28

6.2.2 Mulighed for at se hvor mange der er til stede på en workshop ................................... 28

6.2.3 Information om workshop-deltagelse til senere statistik og markedsføring ................. 29

6.2.4 “Sådan scannes et armbånd” ......................................................................................... 29

Side 3 af 64

6.2.5 Håndtering af tekniske fejl ........................................................................................... 29

6.3 Datamodel ........................................................................................................................... 30

6.4 Implementation af Flexminds API ...................................................................................... 30

6.5 Færdigt produkt ................................................................................................................... 32

7. Diskussion ................................................................................................................................. 33

7.1 Design forløb ....................................................................................................................... 33

7.1.1 Anvendte metoder ......................................................................................................... 33

7.1.2 Tyvstart på implementations fasen ............................................................................... 35

7.2 Forskningsmetoder/research................................................................................................ 36

7.2.1 Valg af action research metode .................................................................................... 36

7.2.2 Dagbog.......................................................................................................................... 36

7.3 Erfaringer fra festival .......................................................................................................... 37

7.3.3 Check-ind...................................................................................................................... 37

7.3.4 Workshop-adgangskontrol............................................................................................ 38

7.3.5 Samarbejdspartnere (Flexminds) .................................................................................. 40

7.4 Anbefalinger ........................................................................................................................ 41

7.4.1 Til designforløbet ......................................................................................................... 41

7.4.2 Til forskningsmetoder................................................................................................... 42

8. Konklusion ................................................................................................................................ 42

8.1 Perspektivering .................................................................................................................... 43

9. Litteraturliste ............................................................................................................................. 44

Side 4 af 64

Abstract

Organizing a festival can be a huge task to take on, even if the festival is relatively small.

Organizing a festival where all the guests can attend their own unique combinations of

workshops and doing access control at the workshops, sounds almost impossible. In this

bachelor thesis, we will try to uncover the difficulties involved with designing a solution for a

volunteer based festival organization, using standard participatory design principals and action

research. We see that tools like “future workshop” and “prototype evaluation” can be very

useful, when modified to take the heteropraxiality of the volunteers into account.

Parallel with researching the use of participatory design in this complex organization, we have

developed an Android application for testing and deployment at Aarhus Vocal Festival 2013.

From this we concluded that the design is actually possible in a festival organization, but also

that you can never be 100% certain of stability, when you cannot test in a realistic environment

beforehand.

Side 5 af 64

1. Indledning

Dette projekt er udarbejdet i foråret 2013 som bachelorprojekt for Simon Westh Henriksen og

Emil Blædel Nygaard på IT Universitetet i København. Projektet, der udføres i samarbejde med

Aarhus Vocal Festival (AAVF) har til formål at kortlægge mulighederne for brug af RFID

teknologi i festivalarmbånd, og samtidig hjælpe AAVF med at finde den bedste løsning i

samarbejde med deres leverandør Flexminds.

1.1 Baggrund

1.1.1 Organisationen

Aarhus Vocal Festival er en organisation som blev grundlagt i maj 2005, af en gruppe

musikinteresserede der ønskede at sprede kendskabet til acapella-musik i Danmark.

Siden grundlæggelsen har organisationen stået bag afviklingen af selve festivalen Aarhus Vocal

Festival i 2006, 2009, 2011 og nu også 2013, samt en mindre støttefestival i 2010.

Festivalen er Nordeuropas største festival af sin slags tilgodeser både eliten og den brede

befolkning. Sangere og musikere kan deltage aktivt i festivalen på workshops med internationale

instruktører og kan sammen med almindelige koncertgæster overvære etablerede såvel som nye

kunstnere optræde. Derfor er det også vigtigt i dette projekt at skelne mellem festivaldeltagere og

koncertgæster. Festivaldeltagerne er solister, korsangere og musikere der ønsker at deltage i

workshops, få coaching eller optræde til nogle af de mindre arrangementer. Koncertgæsterne er

den almene offentlighed som kan købe sig adgang til nogle af de større koncerter.

Festivalen og organisationens grundlag kommer fra en generel tendens i “vokalmijøet” hvor der i

højere grad gennem de senere år har været fokus på Danmark og “The Scandinavian Way”. Aarhus

er i dette miljø anset som en metropol for vokalmusikken.

AAVF har selv defineret en række værdier som de selv har fokus på (Appendix A - “Beskrivelse

af AAVF”):

● At styrke og udvikle det i forvejen høje niveau inden for rytmisk vokalmusik i Danmark

med Aarhus som et af kraftcentrene.

● At inspirere sangere, kor og vokalgrupper til at bidrage til en fortsat videreudvikling og

fornyelse af genren.

● At fremme den generelle sangglæde i Danmark.

● At skabe de optimale rammer for international kulturudveksling på vokalmusikkens

område.

Side 6 af 64

● At tilgodese såvel bredden som kvaliteten, og lade deltagere og publikum blive inspireret

ved mødet med udenlandske verdensnavne.

1.1.2 Bestyrelse og drift

Organisationen består af en bestyrelse som også selv varetager meget af det daglige arbejde.

Efter en vellykket festival i 2011 er det dog blevet muligt for festivalen at ansætte vores kontakt,

Thomas Mathiesen, som professionel producent af festivalen 2013.

Bestyrelsen består af følgende medlemmer ifølge AAVF (2013):

● Jens Johansen (Aarhus Universitet) Bestyrelsesformand

● Jim Daus Hjernøe (Musikkonservatoriet) Kunstnerisk leder og bestyrelsesmedlem

● Anders Bæk Eriksen (Musiker og musikunderviser) Bogholder og bestyrelsesmedlem

● Kim Bisgaard (Bestyrer af Godsbanen) Bestyrelsesmedlem

● Thue Thesbjerg (Gymnasielærer i musik og sangkonsulent) Suppleant

● Line Groth Riis (Sanger og musikunderviser) Suppleant

Størstedelen af disse medlemmer har også haft deres egne funktioner på festivalen, men langt

størstedelen af arbejdsopgaverne er nu blevet tildelt producenten Thomas Mathiesen.

Organisationen er derfor meget gennemsigtig, og de fleste beslutninger ligger hos Thomas, der

også er hovedansvarlig for billetsystemet og adgangskontrol.

Thomas Mathiesen har mere end 20 års erfaring med produktion af festivaler, og har løbende i

processen bidraget med egne erfaringer og professionelle holdninger til projektet.

1.2 Projektets problemformulering

1.2.1 Projektets grundlag

Festivaler i dag har et stort arbejde i at organisere arbejdsgange og processer (Appendix G -

Spørgsmål til Thomas Mathiesen), da mange af disse skal udføres af frivillige medarbejdere med

forskellige baggrunde og begrænset tid til oplæring. Mange festivaler har også forskellige typer

adgangsgivende armbånd til specifikke områder og dage. Samtidig er der oftest stor forskel på

hvilke deltagere der skal have hvilke serviceydelser betalt af festivalen og hvem der skal betale

selv.

AAVF er ikke en “klassisk” festival på en mark, med teltpladser og scener som gæsterne

bevæger sig frem og tilbage imellem. Det betyder dog ikke at festivalen ikke oplever mange af

Side 7 af 64

de samme problematikker som andre festivaler, og måske endda endnu flere. Derfor mener vi at

AAVF er en interessant samarbejdspartner for projektet, så der ikke bare kan findes en specifik

løsning, men også viden der kan gavne andre festivaler.

Ud over adgangskontrol har AAVF også en udfordring i specielle events/ydelser og kontrol

heraf. Deltagerne kan på forhånd have købt adgang til specifikke workshops og specifikke

bespisninger. Det er dog op til den enkelte festivaldeltager at beslutte hvilke specifikke

kombinationer de ønsker, og derfor umuligt for festivalen at lave et unikt armbånd for hver

middag / workshop. Alternativt har festivalen mulighed for at lave gæstelister til

arrangementerne, eller udstede enkeltstående madbiletter til den enkelte bespisning.

Administrationsarbejdet omkring dette er dog utrolig stort og fejlmargen er desværre også

derefter (Appendix G - Spørgsmål til Thomas Mathiesen). Derfor ønsker vi med dette projekt at

klarlægge hvordan, og om, festivaler generelt kan drage nytte af RFID teknologien i armbånd,

med specifikt fokus på hvordan AAVF kan benytte sig af det.

AAVF har allerede et digitalt tilmeldings- og billetsystem udviklet af firmaet Flexminds. Vi vil

derfor benytte os af Flexminds som samarbejdspartner på projektet, til at få afklaret de mere

tekniske og implementations-specifikke aspekter af projektet.

Vores problemformulering og forskningsspørgsmål er derfor blevet defineret som følger:

Projektet vil omhandle brugen af RFID teknologi i forbindelse med især adgangskontrol på

festivaler. I projektet vil vi undersøge hvilke udfordringer der er ved at bruge analoge midler til

håndtere publikum og vi vil, ved hjælp af principperne i participatory design, gå i dybden med

hvordan RFID armbånd kan forbedre festivalen. Vi ønsker at undersøge mulighederne for digital

adgangskontrol, statistik og evt. betaling.

Forskningsspørgsmål

Hvordan kan man udføre et designprojekt til en festival-organisation der som udgangspunkt er

radikalt anderledes end en “normal” virksomhed? Her tænkes især på den store mængde af

frivillige, med meget forskellige baggrunde og erfaring, som ender som slutbrugere af et system.

Hvilke principper og værktøjer fra participatory design kan benyttes i denne anderledes

virksomhedsstruktur?

1.3 Afgrænsning

I samarbejde med festivalen har vi valgt at afgrænse projektet til muligheder med digitale

armbånd, helst med RFID teknologi. Det er derfor ikke interessant at se på armbånd med

stregkoder, eller anden brug af de eksisterende systemer på festivalen.

Side 8 af 64

Samtidig er vi i kraft af samarbejdet med Flexminds, afgrænset til at bruge deres tilmeldings-

platform, som udgangspunkt for en adgangs database til et eventuelt system.

Med hensyn til organisationen ligger vores primære fokus på produktionen og de personer der

tager sig af denne. Herunder kommer især de personer som vil skulle betjene systemet under

afviklingen af festivalen, både frivillige og ansatte.

2. Relateret arbejde

Forandring i organisationer er altid en udfordring, og når IT er en del af denne forandring bliver

udfordringen typisk endnu mere kompleks og risikabel. Der er mange ting at tænke på når man

skal implementere ny IT i en organisation der rækker udover IT-systemet selv; undersøgelse af

behov, arbejdsprocesser, oplæring osv. Og der er stor forskel på hvordan man bør tilgå

udviklingen og implementeringen af et IT-system afhængig af organisationens udformning. Et IT

design projekt handler om hvordan man planlægger og introducere et nyt IT projekt for en

organisation. Bødker (2004, p. 13) definerer et IT design projekt således:

A project conducted at a company that reveals goals, defines problems, and indicates

solutions, with the aim of designing sustainable uses of IT based on a specific problem

within the company. The IT design project produces a decision-making basis for the

company regarding the potentials and opportunities implementing IT usage that solve the

problems. The result of the design project provides a point of departure for subsequent

call for tenders and an implementation of the design project’s visions.

Participatory design er en indgangsvinkel der forsøger at inddrage miljøet og menneskerne

omkring selve projektet i designforløbet. Der er fokus på at alle interessenter skal deltage i

processen og at man på denne måde får den mest optimale løsning for alle.

I Bødker (2004) beskrives grundigt hvordan man kan angribe et IT design projekt med

principperne fra participatory design. Metoden der udvikles kaldes MUST metoden og er et sæt

fornuftige retningslinier om hvordan man skal udføre sit IT design projekt.

Vi har valgt at benytte participatory IT design/MUST-metoden, da vi mener det er den metode

der passer bedst til en frivillige-organisation som AAVF. Vi mener det er vigtigt for projektets

success at organisationen undersøges og alle de relevante parter inddrages. En succesfuld

implementering er meget afgørende for festivalens afvikling. Da vi har at gøre med en

organisationsstruktur der er forskellig fra de organisationer der normalt laves IT design projekter

for, vil vi bruge Bødkers IT designmetoder som inspiration og udvælge dem vi mener passer

bedst til en organisation med frivillige og vores specifikke projekt.

Side 9 af 64

IT design projekter beskriver plan for implementeringen, men rækker i sig selv sjældent længere

end selve planlægningen og udformningen af projektet. I dette projekt benytter vi principperne

fra participatory IT design til at planlægge vores projekt. Herefter realiserer vi planen, tager IT-

systemet i brug og evaluerer til sidst den benyttede fremgangsmåde.

Nedenfor vil vi gennemgå de forskellige videnskabelige artikler vi har læst. Der er skrevet få

artikler om frivillige, participatory design og festivaler i en kombination som har været

interessant for os. Vi har udvalgt en række artikler som kommer nærmest vores emne og som vi

har fundet relevante.

2.1 “Obstacles to design in volunteer based organisations”

Som omtalt i problemformuleringen er der her tale om et “Participatory design” projekt, som

udføres af undertegnede med relevante parter medtaget i designprocessen. Projektet adskiller sig

dog fra størstedelen af participatory design-projekter, da slutbrugerne i projektet er frivillige

medarbejdere og ikke fastansatte.

For at imødekomme og forebygge eventuelle udfordringer ved denne anderledes designproces,

har vi valgt at kigge på hvad der tidligere har været lavet af lignendende projekter. Her er det

især værd at kigge på artiklen “Obstacles to Design in Volunteer Based Organisations”

(Bertelsen 2005), der beskriver nogle konkrete problematikker der kan være ved netop arbejdet

med frivillige.

Artiklen omtaler det såkaldte “Festival project” der stammer fra Bertelsens egen ph.D.

afhandling “Elements to a theory of design artefacts: a contribution to critical systems

development research” (Bertelsen 1998), hvilket er et projekt fra midten af 1990’erne hvor

Bertelsen selv prøvede at lave et designprojekt for en festival baseret på frivillig arbejdskraft.

Projektetet er især relevant for vores arbejde, da det bliver omtalt som et “one shot” project

(Bertelsen 2005, s. 94), hvilket kendetegner festival-relaterede projekter. Der er ikke mulighed

for at teste produktet under realistiske omstændigheder, før selve festivalen bliver afviklet.

Generelt taler artiklen også meget om de fundamentale forskelle på designerne og slutbrugerne.

Det er vigtigt at der fra starten af projektet er en bred enighed blandt designerne,

samarbejdspartnere og ikke mindst slutbrugere om hvad det endelige produkt skal understøtte, og

hvor stor rolle projektet spiller for den samlede organisation. I forhold til festivaler er dette

relevant, da der også kan være stor forskel på hvad ledelsen ønsker, og hvad den frivillige

medarbejder egentlig har brug for i sidste ende. Derfor er det vigtigt at man som designer både

bruger tid på at sætte sig ind i organisationsstrukturen, og de beslutnigner der er taget her,

samtidig med at man sætter sig ind i slutbrugerens (de frivillige) behov og arbejdsopgaver.

Side 10 af 64

Dette er netop en del af den “normale” praksis i participatory design - at designe ud fra et stort

samlet billede af organisationen. Arbejdet med frivillige adskiller sig dog ved at man som

udgangspunkt ikke har adgang til de frivillige under designprocessen, som man ellers ville have

det med medarbejdere der skulle være slutbrugere.

Selvom det er muligt at få enkelte frivillige med i designprocessen af projektet, er dette ikke

nødvendigvis det samme som at have medarbejdere i en virksomhed. Bertelsen bruger udtrykket

“heteropraxiality” om de frivilliges arbejdskraft (Bertelsen 2005, s. 95). Det er en stor blandet

gruppe mennesker, der alle arbejder mod samme mål, men kan have vidt forskellig baggrund og

motivation for at udføre arbejdet. Derfor vil input fra enkelte frivillige skulle ses i lyset af

hvilken arbejdsfunktion de prøver at udføre (målet), og ikke ud fra deres baggrund og

eksisterende viden om arbejdet der skal udføres. En stor forskellighed blandt arbejdskraften er

primært en styrke for festivalen og festivalmiljøet, men kan samtidig være en stor udfordring i

forhold til et vellykket designprojekt (Bertelsen 2005).

Generelt kræver designprojekter at regler og arbejdsgange bliver afklaret og nedskrevet. Det kan

give problemer når der arbejdes med frivilligt arbejde hvor der typisk et meget åbent miljø og

tankegang og stor forskellighed i hvordan arbejdsopgaver bliver håndteret af forskellige personer

(Bertelsen 2005, s. 96). Dette kan skabe modstand mod designprojektet og er noget vi skal være

opmærksomme på i forhold til AAVF.

I artiklen bliver der også omtalt “The Collaborative Writing Tool” (Zander 2005), som et andet

projekt med frivillig arbejdskraft. Dette projekt kan også findes meget relevant da det også var et

“action research project” på samme måde som projektet med AAVF. Et action research project,

er et projekt hvor researcherne selv er en aktiv del af organisationsændringer, samtidig med at de

forsker i ændringerne som et projekt.

Ud fra det projekt konkluderer Bertelsen og Zander meget konkret på problematikken omkring

videre support af en løsning. I deres tilfælde var der en decideret IT-afdeling der kunne tage

over, men som ikke forstod ideen bag projektet, og derfor ikke kunne løse opgaven

tilfredsstillende for brugerne. Det er er derfor yderst vigtigt at vi i vores egen designprocess

overvejer hvorledes systemet kan overleve fra år til år. Det er ikke sikkert at der er nogle

fastansatte som har tid og viden til at tage sig at projektet næste år, og det skal derfor være muligt

at sætte en anden til at styre projektet - eventuelt ud fra grundig dokumentation.

I festivalprojektet valgte Bertelsen at bruge interviews og en række workshops med deltagelse af

forskellige aktørgrupper til at få feedback på hans designløsninger. Efter den første workshop

indskrænkede festivalen projektets scope radikalt. Bertelsen reflekterer over dette og mener det

kan være fordi der er blevet brugt for meget af de frivilliges tid da de synes det var vældig

interessant, samtidig med at der i de foreslåede løsninger blev lagt op til nogle politiske

Side 11 af 64

beslutninger omkring åbenhed og der muligvis blev skabt forventninger om introduktionen af

dyrt IT-udstyr i organisationen (Bertelsen 2005, s. 95).

2.2 “Collecting location-based voice messages on a TalkingBadge”

Et andet projekt vi har valgt at kigge på, stammer fra IT Universitetet i København, hvor John

Paulin Hansen og Arne John Genstrp med flere har arbejdet med en pervasive computer-

teknologi kaldet TalkingBadge (Hansen 2012).

Dette projekt er relevant, da slutbrugerne heller ikke her var ansatte i en virksomhed, men dybest

set kunne være alle mennesker der for eksempel skulle igennem en lufthavn. Ligesom med

frivillige er der altså her tale om hetropraxiality, hvor brugerne har samme mål, men forskellig

baggrund og motivation.

Her benyttede forskningsgruppen sig også af en design-workshop, men i stedet for at præsentere

slutbrugerne (som kunne være hvemsomhelst) med mulige designs, valgte de at involvere

deltagerne og bede dem tegne deres egne skitser at det system de bedst kunne forestille sig at

bruge. Herefter blev der udviklet en prototype ud fra de fælles ideer som designerne kunne

udlede af workshop-deltagernes skitser. Prototypen blev derefter grundigt gennemtestet med

diverse testpersoner under meget kontrollerede forhold. Den endelige model blev derefter

udviklet ud fra observationer gjort under forsøgene.

2.3 “CAVEAT Examplar: Participatory Design in a Non-Profit Volunteer

Organisation”

I en opgave lavet af en gruppe studerende på University of Toronto (McPhail 1998) er der fokus

på hvordan participatory metoder kan bruges i forbindelse med designprojekter i organisationer

med mange frivillige. De fremhæver også hvordan den store forskellighed i de frivilliges

baggrunde og motivationer er en positiv ting for organisationen (McPhail 1998, s. 233), og

samtidig forklarer de hvordan de frivillige, til gengæld for den tid de ofrer, forventer faste

rammer og metoder at arbejde ud fra (McPhail 1998, s. 224).

Projektgruppen valgte at benytte sig af Future Workshop teknikken som også er beskrevet i

Bødker (2004), men valgte at udelade implementationsfasen pga. tidsmangel. Projektgruppen

fortæller hvordan workshoppen både hjalp dem selv til at forstå organisationens ønsker, men

også hjalp organisationen med at tage ejerskab over den løsning der var under udvikling. En

Side 12 af 64

fælles forståelse mellem organisationen og projektgruppen blev etableret og gav en god

baggrund for fremtidige diskussioner (McPhail, s. 229).

I artiklen fremhæves også vigtigheden af at tilpasse sig de begrænsninger i ressourcer der typisk

spiller ind i en organisation af frivillige. Der er sjældent råd til at købe dyrt udstyr og meget er

blevet doneret til organisationen. Det er vigtigt at man i sin process har for øje at der er her ligger

en begrænsninger der ofte ikke er lige så prominent i for-profit organisationer (McPhail, s. 234).

De beskriver også den korte vej fra idé til handling i denne type af organisationer. Hvis idéen

bidrager til den fælles agenda, bliver den ofte mødt med entusiasme. Organisationens formål har

det med at overskygge andre faktorer (McPhail, 234). De beskriver også hvordan ledelsen, i

frivillige organisationer, meget ofte også deltager i det daglige, praktiske arbejde.

2.4 Delkonklusion

Ud fra de ovennævnte artikler, er det blevet klart for os at der er nogle ting vi også må tage højde

for i projektet med AAVF.

For det første er det vigtigt at vi får ankret vores visioner hos især arbejdsgruppen (afsnit 2.1), da

det er disse som kan være de værste modstanderne i vores projekt. Det er ikke lige så nødvendigt

at gøre med de frivillige, da disse som nævnt er vidt forskellige, og bare skal have tildelt en

simpel arbejdsopgave når de møder op. Det er også vigtigt for projektets overlevelse næste år, at

en del af arbejdsgruppen forstår nogle grundlæggende ting om det, så man undgår situationen fra

“The collaborative writing tool” (Zander 2005).

Vi kan ikke gøre som McPhail (2005), hvor vi afholder mange workshops med iterative mock-

ups, og må derfor finde en anden løsning. Fordi vi arbejder med et one-shot projekt er det vigtigt

at vi får mest muligt ud af de få møder vi har med arbejdsgruppen og frivillige.

I forhold til de frivillige, er vigtigt at huske på “heteropraxiality” blandt de frivillige (Bertelsen

2005). Vores samarbejde med de frivillige skal være som i Hansen 2012, hvor vi får frivilliges

respons på noget vi selv har forsøgt os med.

I det følgende kapitel vil vi gå mere i dybden med vores valg af værktøjer i design-processen.

Både konkret hvilke værktøjer vi vil benytte, og hvorfor vi mener at det er de rigtige valg.

Side 13 af 64

3. Planlægning af designfasen

3.1 Overordnede valg til designfasen

Som omtalt kort i det tidligere afsnit, er der visse elementer ved projektet som vi især skal være

opmærksomme på i dette projekt. Vi arbejder specifikt med heteropraxiality - udtrykket for at

organisationen vi arbejder med er baseret på frivillige der har forskellig motivation og baggrund.

Derudover er projektet yderst tidsbegrænset. Både i forhold til tiden vi har med de frivillige

(Bertelsen 2005, s. 97), men også i forhold til hvornår det skal være klart til festivalen. Sidst,

men ikke mindst, kan projektet ikke gennemløbes i test-iterationer. Der er tale om one-shot, hvor

vi kun har mulighed for at afprøve i et realistisk miljø, i samme situation som systemet skal

anvendes.

Festivalen afholdes i dagene 17. til 20. maj 2013, hvilket er med til at begrænse vores tidsramme

væsentligt. Da vores projekt er et one-shot projekt har vi, for at være sikre på at have et brugbart

system under festivalen, startet udviklingen af et prototype-system før den egentlige

designproces var begyndt. Prototypen er udarbejdet på baggrund af både egen og

produktionslederens tidligere erfaringer med festivaler, samt samtaler med en RFID-ekspert1.

Produktionslederen, Thomas Mathiesen, har tidligt i forløbet kommet med egne ideer til hvordan

løsningen kunne udformes, hvilket selvfølgelig har haft stor indflydelse på designet af

prototypen.

Beslutningen om at lave et system der minder om prototypen er taget af produktionslederen, og

er selvfølgelig taget i forhold til den meget stramme tidsramme der er for projektet.

3.1.1 Future Workshop

Vi har valgt at afholde en future workshop med AAVF arbejdsgruppen. Det har vi valgt på

baggrund af den heteropraxiality som de frivillige på festivalen har. De har ikke en baggrund og

erfaring med festivalen, og ville derfor ikke kunne give os relevant input på en future workshop.

Arbejdsgruppen er derfor de eneste interessenter vi har til rådighed, som kan være med til at se

problemstillingerne i et mere overordnet perspektiv, både ud fra deres egne erfaringer og

konkrete ønsker til netop AAVF.

Selvom vi har en prototype der kan fremvises for arbejdsgruppen, ønsker vi at de selv får

formuleret problemerne ved de nuværende systemer, samt kan være frit kreative i fantasi-fasen,

uden at have en forudindtaget ide om hvad vi har arbejdet med. Vi håber på at den frie kreativitet

1 Rita Westergaard fra rfid-specialisten.dk

Side 14 af 64

kan bringe nogle ting på banen, som vi ikke selv har tænkt på, men som stadig vil kunne

integreres i det allerede tænkte system.

En future workshop vil give os input i forhold til problemstillinger, som vi ikke nødvendigvis

selv havde tænkt over. Herefter vil vi have muligheden for, alt efter hvad tiden tillader, at

forsøge at løse nogle af disse problemstillinger med den tidligt udviklede prototype-løsning.

3.1.2 Frivillige-session og evaluering af prototype

Fordi vores projekt med festivalen er et one-shot projekt, er det vigtigt at vi får snakket med de

frivillige og afprøvet vores prototype tidligt så vi kan være så sikre som muligt på at få et

succesfuldt projekt.

På baggrund af Hansen (2012), kan vi se at det kan være rigtig konstruktivt at give sine

testpersoner en reel prototype de kan forsøge med, og derefter arbejde med det feedback denne

giver.

Derfor ønsker vi at udføre en kort test af prototypen med de frivillige, hvor de også tænker højt

om hvad de foretager sig og tænker om systemet. Herefter vil vi interviewe dem med uddybende

spørgsmål til deres oplevelse med systemet og deres baggrund.

Mødet kommer - igen på grund af tidsrammen, men også den fysiske afstand til Aarhus - til at

foregå samme dag som workshoppen med arbejdsgruppen

Valget om at gennemføre interviews og ikke en future workshop med de frivillige, bunder i den

heteropraxiality som Bertelsen (2005) omtaler. De frivillige har ikke nødvendigvis kendskab til

festivalen på forhånd, og selvom de har været med før er det ikke sikkert de kender til / kan

huske procedurerne omkring adgangskontrol. Samtidig kan de have forskellig motivation for at

være frivillige på festivalen, og har derfor ikke nødvendigvis en interesse i hvordan tingene

fungerer på et overordnet plan, men vil bare gerne have deres billet.

Derfor valgte vi at bruge vores meget begrænsede tid med de frivillige, til at se hvordan de

reagerede på en eksisterende løsning, hellere end at bede dem tænke på en helt selv.

Vores fokus på design af prototypen har derfor været på at denne skulle kunne fungere i vores

“one-shot-heteropraxielle-miljø”. Meningen med prototypen er, at den skal være så brugervenlig

at enhver frivillig kan tage den i hånden til festivalen, og begynde at bruge den efter maksimalt 5

minutters introduktion.

Side 15 af 64

3.2 Tidsrammen

Projektes tidsramme bliver omtalt en del i både det ovenstående, og også i kommende afsnit. Der

er tale om en meget skarp deadline d. 17. maj, hvor AAVF forventer en fungerende løsning der

kan bruges til festivalen. Armbånd med RFID-chip indbygget er blevet trykt og leveret til

festivalen, og der er en forventning om at systemet kører. Det har, som tidligere nævnt,

medvirket at arbejdet med udviklingen har måtte påbegyndes før den egentlige designfase.

Fig. 1 giver et overblik over hvordan forsknings- og designfasen har kørt sideløbende med

udviklingen:

3.3 Prototypen

Som tidligere nævnt blev der tidligt i forløbet taget en beslutning med produktionslederen fra

AAVF, om at arbejde videre med RFID-teknologien i armbånd. På baggrund af samtaler med

førnævnte og en RFID-ekspert med erfaring med adgangskontrol, valgte vi tidligt at udvikle en

prototype af en mobil applikation til Android telefoner med NFC-læser.

Ved hver workshop, vil den frivillige i døren have en Android-telefon med NFC og app’en

installeret. App’en skal forbinde sig til det eksisterende workshop-tilmeldingssystem

(backenden) udviklet af Flexminds, og herfra hente data om hvilke personer der må komme ind

til den valgte workshop. I backenden er der registreret hvilket UUID (Universal Unique ID) den

Figur 1 - Tidsplan for projektet

Side 16 af 64

enkelte gæsts armbånd har, og dermed kan systemet oplyse os om hvilke UUID’er der må lukkes

ind til de enkelte workshops og koncerter.

Under udviklingen af denne prototype har vi ikke haft adgang til API’et fra Flexminds backend,

og derfor ikke haft mulighed for at hente reel data til app’en. Derfor er prototypen implementeret

med en “Loading”-skærm der simulerer en download af data. Dermed giver vi den frivillige

testperson et indtryk af at der bliver hentet data, samtidig med at alle tilladte UUID’er er gemt

direkte i app’ens kode.

For at registrere UUID’et i systemet

skal gæsten, når han/hun ankommer

med sin billet, have udleveret et

armbånd. Ved check-ind boden på

festivallen står minimum 1 computer

som en frivillig betjener. I systemet

Flexminds leverer vil den frivillige

kunne slå en billet op i systemet og se

gæstens informationer. Flexminds har

lovet at der på denne side vil være et

felt hvor et armbånds UUID kan

indskrives og gemmes ved et tryk på

enter. Vi har, ved hjælp af en USB

NFC-læser, skrevet et program der

kan læse et NFC tags UUID, skrive

Figur 2 - Screenshots af prototype

Figur 3 - Scanning af RFID armbånd

Side 17 af 64

det ind på computeren (simulerer at en person skriver på keyboardet) og trykker enter. I denne

simple udformning er integreringen med et andet program eller webapplikation ligetil.

3.4 Plan for design

I afsnit 3.1 diskuterede vi hvilke værktøjer vi havde tænkt os at gøre brug af i forbindelse med

designet af systemet, og hvorfor disse passede godt til projektet. I det følgende vil vi gå mere i

dybden med hvorledes designprocessen skal forløbe.

3.4.1 Future Workshop

Fredag d. 12 april 2013 mødes projektgruppen med AAVF’s arbejdsgruppe, og senere på dagen

med fire enkeltpersoner der har meldt sig som frivillige. På denne dag vil vi gennemføre en

future workshop med arbejdsgruppen, hvorigennem vi ønsker at danne os et overblik over hvilke

problematikker gruppen selv ser, og hvilke ønsker de har til at få disse løst.

En future workshop består af tre faser, som vi også vil arbejde med d. 12 april; kritik-fasen,

fantasi-fasen og realisations-fasen. Arbejdsgruppen bliver inddelt i mindre grupper, som arbejder

sammen i de enkelte faser.

I første fase beder vi grupperne om at udvælge tre problemstillinger ved den nuværende måde at

håndtere adgangskontrol på. De vil blive bedt om at fremlægge disse problemstillinger for de

andre grupper på en kreativ måde (sang, dans, skuespil, tegninger).

I anden fase skal grupperne så tage disse problemstillinger og prøve at komme med

løsningsforslag. Anden fase hedder “fantasifasen”, da det netop er meningen at alle

løsningsforslag må opstå fra fri fantasi, og derfor ikke må være begrænset til viden om

mulighederne, økonomiske aspekter, eller sågar fysiske love.

Den sidste fase er realisations-fasen, hvor det bliver gruppernes opgave i fællesskab at kigge på

de forslag der er kommet under anden fase, og vurdere hvor realistiske de er. Målet med denne

sidste fase er at få grupperne til at nå til enighed om nogle konkrete ideer der kan bruges til at

løse de eksisterende problemer.

Efter de klassiske faser fra future workshop, vil vi gå videre med at vise den nuværende

prototype af systemet, samt at give en kort forklaring om denne. På baggrund af denne

præsentation, tager vi en dialog med arbejdsgruppen omkring den nuværende retning, og

hvordan denne eventuelt kan kombineres med nogle af de ideer der er kommet frem under

workshoppen. Arbejdsgruppen ser først prototypen, og skal først forholde sig til den, efter den

Side 18 af 64

afholdte future workshop. Dette gøres for ikke at påvirke deres egen kreativitet, til især den

anden fase af vores future workshop.

3.4.2 Frivillige-sessions

Efter mødet med arbejdsgruppen, er der planlagt 4 individuelle møder / interviews med frivillige.

På disse møder vil den frivillige modtage en kort skriftlig briefing med teksten:

“Din arbejdsopgave på festivalen er adgangskontrol. Du skal sørge for at kun tilmeldte får adgang til koncerterne

og workshopsne.

Du står nu i indgangen til workshoppen “Just sing it!”. Du har fået udleveret en telefon som du skal bruge til at

kontrollere deltagernes armbånd. Om få øjeblikke bliver døren åbnet og deltagerne begynder at ankomme. Du skal

starte med at forberede telefonen til at checke armbånd på denne workshop og tage imod de første tre gæster”

Herefter bedes den frivillige om at tænke højt mens vedkommende gør telefonen klar. Det hele

videofilmes til senere dokumentation. Med denne process ønsker vi at observere om der er

specifikke arbejdsopgaver som de frivillige føler sig utrygge ved, eller ikke kan finde ud af, ud

fra det nuværende design. Efter testen af app’en, vil den frivillige blive stillet nogle spørgsmål.

Spørgsmålene omhandler både generel data, som alder, køn, baggrund, men også en række

spørgsmål om deres indtryk af systemet, og hvad de eventuelt kunne være nervøse for ved at

bruge det.

Da vi har begrænset tid til vores sessions med frivillige er det vigtigt for os at være meget

koncentrerede og få det mest mulige ud af disse mens de forløber. Det betyder det bliver svært

for os at skrive noter samtidig. Vi har derfor valgt at vi vil videooptage vores sessions med de

frivillige. Det gør vi både for at få en optagelse af vores samtaler, men også for at se deltagernes

kropssprog og udtryk.

Efter workshop og frivillige-sessions i Aarhus, vil den indsamlede feedback samt observationer,

blive brugt til at optimere og ændre på prototypen, for at tage højde for relevant input. I denne

fase vil der især blive lagt vægt på brugervenligheden af systemet, så netop de frivillige kan

bruge det uden oplæring.

3.4.3 Afprøvning på festival

Som en konkluderende del af projektet, har vi kort før afleveringsfristen, muligheden for at se

det endelige produkt afprøvet direkte på festivalen. Selvom projektet som udgangspunkt er et

one-shot projekt, må vi alligevel se festivalen som sted hvor løsningen også bliver testet, om ikke

andet i forhold til fremtidige projektet af samme type.

Side 19 af 64

Det er som udgangspunkt planen at systemet skal køre i “full production” på festivalen, og være

den primære løsning til adgangskontrol, men det kan næsten ikke undgås, at vi også her vil

opdage fejl og mangler som kun viser sig i et festival miljø.

Vi må altså se festivalen som en del af vores designprocess, i forhold til senere lignende

projekter.

4. Forskningsmetoder

Vi vil i rapporten, som beskrevet i vores forskningsspørgsmål, forsøge at undersøge hvilke

participatory design-principper der passer på en organisation med frivillige som AAVF. For at

undersøge dette har vi, i kapitel 3, udvalgt nogle specifikke designmetoder vi vil forsøge os med.

Projektet tager udformning som et “action research” projekt. For at kunne evaluere vores valg af

participatory design og vores designmetoder har vi valgt at dokumentere udviklingen af vores

projekt ved hjælp af en række metoder og værktøjer:

Action Research

Med action research forløber research og problemløsning parallelt og ikke i forlængelse af

hinanden. Man forsker i det problem man samtidig er ved at løse og kan, fordi selve

problemløsningen foregår samtidig, få hurtig feedback og erfaringer. Det er vigtigt for os at

kunne skifte mellem problemløsning og forskning for at få de bedste resultater i begge felter i

den korte tidsramme vi har til projektet.

Netop muligheden for at skifte mellem forskning og problemløsning, gør at vi kan afprøve

participatory design metoder, reflektere over dem i vores research og gøre et nyt forsøg hvis vi

konkluderer at det ikke var en egnet metode at bruge.

Som beskrevet af i Checkland (1998) kommer researchgruppen med et framework af idéer (F),

som vi ved hjælp af metode (M) vil anvende på vores problemstilling og forskningsspørgsmål

(A). Vores framework af idéer tager udgangspunkt i hvad vi har lært om festivalen fra

eksempelvis Thomas Mathiesen, i kombination med den litteratur vi har læst om emnet.

Metoderne gennemgås senere i afsnittet.

I projektets forløb vil vi følge den cirkulære model der er opsat i Checkland (1998), som også

kan ses herunder (Figur 4). Som figuren viser er vi researchere der indgår i det eksisterende

arbejde hos organisationen (AAVF). Vi vil, ved hjælp af vores framework (F) og metode (M),

Side 20 af 64

tage del i problemløsning i selve organisationen og hjælpe med arbejdet omkring udviklingen af

noget nyt (adgangskontrol systemet), hvoraf vi kan reflektere over vores oplevelser, både

løbende og bagefter i forhold til vores valgte framework og metode.

Checkland gør i artiklen “Action Research: Its nature and validity” (1998) opmærksom på

vigtigheden i, som researcher, at definere sit “exit” fra organisationen. Dette er ud fra ideen om

at man indgår i en kortvarig periode i en organisation som fortsætter deres arbejde - måske med

et nyt system - når projektet er gennemført.

I vores tilfælde er vores exit meget tydeligt defineret, da festivalens afvikling fungerer som en

afslutning på hele projektet - også for festivalen. Dog skal vi være opmærksomme på det vi også

omtalte i kapitel 2 om “Relateret arbejde”, at festivalen helst skal kunne være i stand til at bruge

systemet igen næste gang de afvikler festivalen.

Figur 4 - Checkland 1998

Side 21 af 64

Action Research vs. Design Research

Der er flere overlap mellem de to forskningsmetoder; de har begge til formål at producere et

relevant resultat eller produkt, mens de samtidig udvikler og oplyser den eksisterende teori om

emnet.

Design research er karakteriseret ved fokus på design af selve produktet, eksempelvis “Hvordan

designer man en webapplikation der kan understøtte synshandicappede?”.

Vi har valgt action research som forskningsmetode pga. vores fokus på process og metode i

modsætning til selve designet. Vores projekt går ud på at indføre ændringer i organisationen og

observerer hvilke resultater det producerer og action research lægger op til denne form for

iterative arbejdsgang med researchen.

Herudover har tidsrammen for vores projekt haft stor indflydelse. Det er vigtigt for festivalen, og

yderst gavnligt for os, at have et fungerende system klar til festivalen. Det mener vi bedst kan

imødekommes af en iterativ process hvor ændringer og research foretages løbende og parallelt.

Fokus for dette forskningsprojekt er ikke at lave en perfekt designet løsning, men i stedet at se

hvordan processen kører med en organisation bygget på frivillig arbejdskraft. Selvom festivalens

interesse selvfølgelig hovedsageligt er på design af løsningen, har de accepteret at vores fokus

ligger på forskningen.

Dagbog

Efter hver dag skriver vi en dagbog om dagens hændelser. Vi skriver heri både hvordan dagen er

forløbet samt vores refleksioner omkring dagen. Det vil hjælpe os når vi i slutningen af forløbet

skal evaluere hvordan projektet er forløbet. Dagbogen vil kunne bruges til at vurdere specifikt

hvor i vores process vi har taget en vigtig beslutning, der enten kan have påvirket projektet

positivt eller negativt.

Derudover kan dagbogen fungere som et værktøj der kan bidrage som en log over den

information vi har modtaget, og som vi arbejder ud fra.

Video- og lydoptagelser

Vi har valgt at optage så meget vi kan af vores møder med festival-arbejdsgruppen, frivillige og

samarbejdspartnere. Vi vil bruge optagelserne som et kompliment til dagbogen. Optagelserne

kan også bruges når vi, efter refleksioner over et møde, måske opdager at vi har fokuseret for lidt

på et emne. Her er det relevant at gå tilbage og “genopleve” mødet for at fornemme hvilken

stemning der var omkring et bestemt emne.

Side 22 af 64

5. Designfasen

5.1 Future workshop med AAVF arbejdsgruppen

Fredag d. 12. april afholdte vi en future workshop med AAVF arbejdsgruppen i Aarhus.

Workshoppen havde til formål at engagere arbejdsgruppen samt at høre deres kritik, idéer og

input før vi præsenterede dem for vores prototype. Vi vil i dette afsnit gennemgå de punkter og

idéer vi fandt mest interessante.

5.1.1 Kritik

Kritikfasen går ud på at forklare og kritisere det nuværende system med det mål at identificere

problemerne.

Ingen kobling til navn og deltagelse i workshops

Flere af arbejdsgruppedeltagerne forklarer hvordan man, med det nuværende papirbilletsystem,

“mister” informationen omkring en festivaldeltager, eksempelvis navnet. Navnet står på

festivalbilletten, men så snart den er afleveret og der er overrakt diverse billetter, er det ikke

muligt at identificere personen. Man kan ud fra en billet, eller et armbånd for den sags skyld,

ikke identificere hvem den registrerede ejer er. Det betyder at det ikke er muligt at registrere

hvem der har deltaget (og lige nu deltager) i hvilke workshops, en information der kan være

nyttig både under og efter festivalen (Nygaard 2013, #00:01:01; Nygaard 2013, #00:03:04). Det

betyder også at finder man et tabt armbånd kan man ikke ud fra dette finde kontaktoplysninger

på ejermanden.

Differentieret adgang besværligt

Skal man give forskellige personer adgang til forskellige områder tager det tid og er besværligt.

Som det fungerer nu klippes billetter ud til de forskellige workshop som udleveres til deltagerne

og det er et omstændigt arbejde (Nygaard 2013, #00:03:04). Problemet viser sig også i

forbindelse med madbilletter som fungerer på samme måde og er svære at holde styr på og

kontrollere (Nygaard 2013, #00:03:49). VIP-deltagere er også et specialtilfælde hvor der skal

differentieres, de har nemlig adgang til alle workshops. Derfor skal de have en speciel

billet/armbånd der identificere dem som VIP og det kræver ekstra ressourcer (Nygaard 2013,

#00:01:45).

“Zappere” svære at forhindre

Det beskrives hvordan “zappere”, folk der går fra workshop til workshop imens de er igang, er et

problem der skal stoppes (Nygaard 2013, #00:03:15). VIP’s har denne rettighed, men de

Side 23 af 64

almindelige deltagere må ikke. Problemet er især opstået efter en workshop har været sat i gang,

hvor zappere har kunne dukke op og påstå at de havde afleveret en papirbillet en gang, eller

måske bare er gået ind uden at blive tjekket. Det er dog ikke kun et problem med processen

omkring adgangskontrol, men også bare et problem med om de frivillige skal tjekke folk der

kommer ind efter evt. toiletbesøg.

Hygiejne og stofarmbånd

En af deltagerne beskriver en problematik omkring brugen af stofarmbånd. Der har ikke været

brugt armbånd før på AAVF, men det er på baggrund af erfaring andre steder at han nævner

dette. Problematikken går ud på at hygiejnen i forhold til stofarmbånd bliver kritiseret af

Fødevarestyrelsen i forbindelse med håndtering af mad. Deltageren mener at om end ikke i år, så

næste år, vil der komme et forbud mod brug af stofarmbånd på festivaler (Nygaard 2013,

#00:02:19).

5.1.2 Fantasi

I fantasifasen lægger vi op til fri leg og fantasi. Formålet er at deltagerne tænker kreativt og ud af

boksen. Vi har valgt de idéer og forslag som er mest interessante i forhold til projektet, helt

urealistiske forslag (som at piske en stregkode på ryggen af folk) er sorteret fra.

Det er vigtigt at pointere at fantasifasen var tydeligt påvirket af, at arbejdsgruppen allerede

kendte til ideen om et armbånd med chip. Dette var selvfølgelig fordi de havde godkendt budget

til indkøb af disse armbånd. Det viste sig ved at forslagene hovedsageligt omhandlede en form

for chip, og også konkret chippen i armbåndet.

Udstyr deltagerne med chips på alle led og kanter

Foreslaget går på at alle deltagere, på en eller anden måde, skal udstyres med en eller flere chips.

Formålet der fremhæves er muligheden for at scanne lynhurtigt uden voldsom kødannnelse

(Nygaard 2013, #00:08:20). Der drømmes også om en gate-scanner (som man f.eks. kender fra

lufthavne og konkurrenceløb) hvor chippen registreres når den går igennem (Nygaard 2013,

#00:08:30).

Fejlfri kontrol

Det fremhæves at det er meget vigtigt at der ikke er fejl ved scanning af f.eks. en chip. Det er

vigtigt at man kan stole på den information scanneren/chippen indeholder. Fejl i billetter er noget

som deltagere kan blive meget sure over (Nygaard 2013, #...).

Mulighed for at ændre adgangs-privilegier under festivalen

Side 24 af 64

I forbindelse med en snak om at der helst ikke skal være fejl i chip’en / hvem der måtte komme

ind blev det ønsket at kunne ændre/omkode en chip undervejs (Nygaard 2013, #00:08:47-6).

Mulighed for at se hvor mange der er til stede på en workshop og evt. alarm

Ved at kunne se hvor mange deltagere der har checket ind på en workshop kan

workshopafviklerne finde ud af om de skal gå igang eller vente på flere. Det kunne også bruges

til at give en påmindelse/alarm til de deltagere som er skrevet på listen, men endnu ikke er

dukket op (Nygaard 2013, #00:10:26).

Information om deltagernes workshopdeltagelse til markedsføring

Der drømmes om at have information til rådighed om de enkelte deltageres deltagelse i

workshops, hvilke de var tilmeldte og hvilke de rent faktisk deltog i. Med disse informationer vil

man kunne målrette og forbedre markedsføringen markant (Nygaard 2013, #00:09:46).

Betaling med en chip

Ønsket er at deltagerne skal kunne betale mad og evt. andre betalte arrangementer med deres

chip/armbånd. Det skulle evt. virke ved at de kunne sætte penge ind på en festivalkonto som der

så kunne trækkes fra i kantinen ved at en deltager kan “bippe” sin chip. Restbeløbet på kontoen

kunne overgå til velgørenhed, blive tilbagebetalt eller noget andet (Nygaard 2013, #00:10:40).

5.1.3 Realisme

Fasens formål er at, ud fra de kreative forslag i fantasifasen, at tilvejebringe en mere realistisk

diskussion omkring idéerne og hvordan de eventuelt kan føres ud i virkeligheden.

Arbejdsgruppen begyndt selv meget hurtigt at diskutere realistiske løsninger i forlængelse af

fantasifasen. Der kom en masse gode ting på banen og vi valgte derfor at lade dem fortsætte

direkte fra fantasifasen og ind i realismefasen uden den planlagte pause og introduktion.

Gruppen er igennem de sidste to faser langsomt blevet enige om at en chipløsning af en slags er

den løsning de helst ser.

5.1.4 Forslag vi har taget med fra workshoppen

Vi har udvalgt en række idéer og forslag som var nogle af de forslag der blev forespurgt og

diskuteret mest, samt de forslag vi finder mest realistiske at implementere.

Årsag til afvisning

Side 25 af 64

Til workshoppen var der en enighed om at det var vigtigt at personen i døren kunne give en

grund til hvorfor systemet nægter en person adgang. Det er muligt at der kun er én grund (nemlig

at personen ikke er på gæstelisten), men det skaber en sikkerhed for den frivillige hvis systemet

skriver det ud på skærmen og han/hun evt. kan vise det til gæsten der forsøger at komme ind. Vi

har valgt dette forslag ud fordi vi mener at det er en vigtigt feature der kan gøre den frivillig

mere sikker i hans/hendes arbejde. (Nygaard, 2013, #19:40 - #21:40)

Mulighed for at se hvor mange der er til stede på en workshop

Forslaget blev både set som et værktøj til at give en oversigt over deltagernavne der var

ankommet, men også til at se antal ankomne i forhold til tilmeldte. Vi mener at begge

funktionaliteter vil gavne den frivillige og gøre personen mere oplyst og beslutningsdygtig. Der

blev også diskuteret muligheden for at give deltagere der ikke var dukket op en påmindelse, men

denne funktionalitet har vi valgt at nedprioritere.

Information om workshopdeltagelse til senere statistik og markedsføring

Dette forslag er ikke noget der vil gavne festivallen her og nu, men er derimod en indsamling af

information og erfaring de kan drage nytte af til kommende festivaler. Pga. festivalens

ambitionsniveau i fremtiden finder vi det vigtigt at de allerede nu begynder at indsamle denne

slags data.

5.2 Frivillige sessions

Samme dag som ovenstående workshops blev gennemført, havde vi også fire interview- og

testsessions med fire personer der alle havde meldt sig som frivillige på AAVF i år. Som

beskrevet i afsnit 3.3 blev de frivillige præsenteret for en prototype (beskrevet i 3.2) af systemet,

og derefter stillet en række spørgsmål om det.

5.2.1 Generelt om de frivillige

Blandt vores fire deltagere var der 3 kvinder og 1 mand i alderen 24 til 28 år. Alle deltagere læste

på Musikkonservatoriet i Aarhus, hvilket også er der store dele af festivalen afholdes - det er

derfor også her den største rekruttering er sket. På trods af gruppens ensformige

uddannelsesmæssige baggrund, oplever vi dog stadig stor adspredelse på andre springende

punkter for dette projekt. Det gælder især når vi spørger ind til deres generelle IT-kundskaber og

tekniske viden. Én frivillig ejer ikke selv en smartphone, og er efter eget udsagn “slet ikke inde i

det sprog” - her i forhold til udtrykket “app” (Interview med frivillige, Mette, #00:00:07). En

anden frivillig har selv en smule erfaring med programmering og har en Android telefon som han

Side 26 af 64

måske vil prøve at udvikle til selv. En komplet oversigt over de frivillige og deres besvarelser

kan findes i Appendix F - “Interview med frivillige”.

Alle fire deltagere har ønsket at være frivillige af interesse. Det er deres generelle interesse for

musik, og især vokalmusik, der har gjort dem interesserede i festivalen. Mange af dem mener

dog at det er for dyrt at deltage som studerende, og derfor ligger motivationen for at være

frivillig, selvfølgelig også i at modtage en gratis billet.

5.2.2 Test af prototype

Alle de frivillige blev efter nogle korte indledende spørgsmål givet en skriftlig briefing, som kan

ses i afsnit 3.3. Efter de havde læst briefingen og modtaget en telefon at prøve med, blev de bedt

om at tjekke 2-3 armbånd, siddende på projektgruppens håndled. Dette handlingsforløb blev

filmet, for at se hvorledes de frivillige reagerede.

Generelt gik det let for alle de frivillige at starte app’en op og komme i gang med at hente en

gæsteliste til deres workshop. Der opstår dog forvirring ved flere af de frivillige om selve

scanningsprocessen. Mange har tydeligvis ikke arbejdet med NFC-teknologi i telefoner før, og

ved derfor af gode grunde ikke hvor scanneren sidder.

Det er også tydeligt at se, at de enkelte frivillige ikke nødvendigvis forstår konceptet i RFID /

NFC teknologi, og derfor ikke nødvendigvis kan regne ud at telefonen skal ned og røre ved

armbåndet.

5.2.3 Opfølgende spørgsmål til frivillige og generel feedback

Som opfølgning på testen af prototypen stillede vi de frivillige en række ekstra spørgsmål om

deres oplevelse med app’en og systemet. Komplette interviews og svar kan findes i Appendix F.

Ligesom det blev set i afsnit 5.2.2, blev det også nævnt under de opfølgende interviews at selve

scannings-processen skulle forklares bedre end på nuværende tidspunkt. Der blev blandt andet

foreslået at opdatere billedet i app’en, som også ses på figur 2, eller med en mere specifik tekst

om hvor på telefonen scanneren sad.

En generel observation ved systemet, var den manglende information når en gæst blev afvist og

telefonen viste et stort rødt kryds. Flere af de frivillige meldte tilbage at de ønskede at kunne se

årsagen til at gæsten ikke var godkendt - især fordi de var i tvivl om det betød fejlscanning eller

at gæsten ikke var på listen. Sammenhængende med dette var et generelt ønske om noget

information om hvordan man skulle forholde sig i tilfælde af at en gæst f.eks. ikke var på

gæstelisten. App’en fik dog på dette punkt også ros for at give den frivillige en chance for at

Side 27 af 64

lægge noget af ansvaret for sig, i forbindelse med at skulle afvise en gæst (Appendix F -

Interview med frivillige, Anja, #00:01:45).

Da de frivillige blev spurgt til hvordan de ville håndtere en situation hvor telefonen gik ud og

ikke kunne tændes igen, var der to ting der var gennemgående for deres svar: Enten ønskede de

at kunne få fat i en ny telefon hurtigt, for at kommer hurtigt videre med scanningen, eller også

ville de gerne have mulighed for at få en papirliste de kunne falde tilbage på.

Generelt var brugerne positivt stemte overfor systemet, og de af dem der havde været på

festivalen for 2 år siden, så mange fordele ved at bruge dette system i stedet for papirbilletter.

5.2.4 Forslag vi har taget med fra frivillige-sessions

Ligesom med workshoppen har vi udvalgt nogle specifikke ting fra de frivilliges workshop som

vi vil arbejde videre med i færdiggørelsen af systemet.

Fra vores workshop havde vi blandt andet det med videre, at det var vigtigt for den frivillige at

kunne se en årsag til hvorfor en gæst blev afvist. Eftersom dette også var et punkt som blev bragt

op af flere frivillige, ser vi det som yderst relevant at tage med i den endelige løsning. Når der er

så bred enighed mellem ledelse og brugere, som i dette tilfælde, ser vi ingen grund til ikke at

implementere dette.

Ud fra videoerne og de efterfølgende interviews kan vi også se at der er stort behov for en bedre

forklaring af hvordan man skal scanne armbåndet. Dette bliver vi også nødt til at have med

videre i processen.

Sidst, men ikke mindst, skal vi sørge for at lave en løsning for hvordan den frivillige forholder

sig til tekniske problemer, som f.eks. en ødelagt telefon.

Side 28 af 64

6. Implementation

6.1 Udgangspunkt (prototype)

Implementationen tager udgangspunkt i prototypen beskrevet i afsnit 3.2. Prototypen ligger en

base, både teknisk og erfaringsmæssigt, som vi kan bygge videre på og konstruere vores endelige

produkt ud fra.

6.2 Implementering af forslag

6.2.1 Årsag til afvisning

Både vores workshopdeltagere og frivillige interviewpersoner gjorde os opmærksomme på

vigtigheden af at give den frivillige i døren en årsag til hvorfor en person bliver afvist. For at

håndtere dette, vælger vi at skrive direkte på skærmen der viser det røde “afvist-kryds”, samt på

“Klar til at scanne”-siden som man komme tilbage på. På begge sider skriver vi en årsag, som

f.eks. “Gæsten er ikke på listen til denne workshop”. Som tidligere omtalt, er dette faktisk den

eneste fejl systemet kan komme til, men det giver den frivillige muligheden for at refererer til

systemet og fejlbeskeden, og dermed fralægge sig ansvaret overfor at gæsten ikke må komme

ind.

Hertil er det også vigtigt at have informeret de frivillige om at de, i tilfælde af at måtte afvise en

gæst, skal henvise til informationscenteret, så de kan fortsætte med adgangskontrollen af de

andre gæster.

Derudover vil vi implementere en tredje svarmulighed med en advarselstrekant, der gør

opmærksom på at en person allerede er tjekket ind til en workshop. Dette gør det muligt for

deltagerne at forlade lokalet og komme tilbage ind igen under en workshop. Samtidig forhindrer

det snyd med armbånd, hvor to gæster f.eks. har klonet UUID fra ét armbånd, i det at den

frivillige kan vurdere om det er sandsynligt at personen har været ude (under workshoppen) eller

om der er tale om to gæster med samme id (ved workshoppens åbning).

6.2.2 Mulighed for at se hvor mange der er til stede på en workshop

Arbejdsgruppen ønskede sig muligheden for at se hvor mange der var til stede på en enkelt

workshop / hvor mange der var checket ind og hvor mange der stadig manglede. Dette bliver løst

på to forskellige måder, der dog komplimenterer hinanden.

Side 29 af 64

Den ene del, er at vi i app’en giver mulighed for at se en gæsteliste for den enkelte workshop,

med en markering af de personer der er checket ind til workshoppen. Hertil vil vi selvfølgelig

også skrive total-tal der viser samlet antal indtjekkede og hvor mange der mangler.

Den anden del bruger det samme data som listen, men sender det løbende tilbage til backend

systemet, hvor Flexminds gør det muligt at holde øje med indtjekkede gæster fra ét centralt sted.

Første del er dog vigtig, da vi ikke er garanteret internet hele tiden til en workshop, og da den

frivillige også kan gavne fra at kunne se listen.

6.2.3 Information om workshop-deltagelse til senere statistik og markedsføring

Denne funktion har vi valgt at løse med samme løsning som i 6.2.2. Det er ikke en garanti at

telefonerne er online hele tiden, så vi laver en mulighed for at synkronisere listen tilbage til

backenden på et senere tidspunkt, hvor der er internetforbindelse til telefonen.

6.2.4 “Sådan scannes et armbånd”

Ud fra de erfaringer vi gjorde os under vores sessions med de frivillige har vi valgt at gøre

følgende 3 ting for at sikre forståelsen:

1 Sætte et mærkat på bagsiden af telefonen der indikere hvor scanningsområdet er, evt.

med teksten “Scan her”

2 I briefingen til arbejdsopgaven (Appendix D) indsætte teksten: “For at scanne et armbånd

skal mærkatet på telefonens bagside berører armbåndets bredde del.”

3 At vise en demonstration af en scanning til minimum første sæt af frivillige der skal

betjene indchecknings-poster.

6.2.5 Håndtering af tekniske fejl

Ved “tekniske fejl” menes at telefonen går ud og ikke kan tændes, eller på anden måde går i

stykker så den ikke kan bruges. Af gode grunde kan dette ikke håndteres teknisk i app’en, så her

er der behov for at informere de frivillige tydeligt om hvordan man forholder sig i en sådan

situation. Vi foreslår at den frivillige tager kontakt til det centrale informationscenter, hvor de

kan få udleveret en ny telefon. I tilfælde af at der ikke er flere telefoner til rådighed, må

informationscenteret have papir-gæstelister, men dette ses som en absolut sidste udvej.

Side 30 af 64

6.3 Datamodel

I applikationen arbejder vi altid med én workshop ad gangen. Det betyder at vi begrænser os til

at håndtere den valgte workshop samt workshoppens tilmeldte deltagere. Datamodellen er derfor

meget simpel. I figur 5 vises de to entiteter, Workshop og Deltager, samt deres attributter.

Workshop Deltager

● Navn

● Liste af tilmeldte deltagere

● Armbånds-UUID

● Navn

● Indchecket-status (har personen

checket ind)

● Checkind tidspunkt

Figur 5 - Datamodel

Data’en hentes fra Flexminds API som beskrevet i næste afsnit. Ved indcheckning af en deltager

markeres personen som indchecket. Informationen bruges til at give feedback ved indcheckning,

beskrevet i 6.2.1, samt til vise en oversigt over allerede indcheckede deltagerere, beskrevet i

6.2.2.

6.4 Implementation af Flexminds API

Flexminds er et dansk firma der leverer softwareløsninger, heriblandt et online billetsystem

kaldet FlexBillet. AAVF benytter FlexBillet til modtage billetbestillinger online og håndtere

tilmeldinger til workshops. Kunderne kan selv tilmeldte sig ønskede workshops online, og

kundernes billetter scannes ved ankomst og de får udleveret armbånd. Flexminds har udvidet

deres system til at kunne gemme et NFC-UUID i deres database.

Vi benytter FlexBillets API til at trække data omkring hvilke workshops der findes, samt hvilke

deltagerer der er tilmeldt.

Side 31 af 64

De API kald vi har til rådighed er:

Sessionlist Returnerer en liste med “sessions” (i vores

terminologi “workshops”)

Attendee Givet et sessionid returnerer den tilmeldte

deltagere for den session.

checkinasync Ved at sende en liste med UUID’s og

checkind-tider kan vi registrere dem centralt i

systemet.

Figur 6 - API kald

I Android app’en hentes alle workshops fra start af ved hjælp af sessionlist. Herefter vælger den

frivillige en workshop hvorefter deltagerne hentes med attendee kaldet.

I figur 7 er applikationens transitioner mellem online og offline illustreret. Applikationen er

intensiv online i starten af programforløbet i det der skal nedhentes en del data. Til gengæld

betyder det at vi under selve indscanning og check ind af deltagere kan være helt offline. Det har

fra start af været en vigtigt designbeslutning at applikationen under selve indtjekningen skal

fungere offline. Det skal den fordi der ingen sikkerhed er for internettets tilstedeværelse eller

stabilitet i de bygninger og lokaler hvor de mange forskellige workshops afholdes. Samtidig også

for at sikre den hurtigste svartid på den enkelte scanning. Vi får først et billede af internet-

situationen samme dag som festivalen starter. Om nødvendigt vil de frivillige blive briefet om at

Figur 7 - App'en kommunikation med server

Side 32 af 64

de skal gå et bestemt sted hen for at downloade workshops og gæsteliste, for derefter at vende

tilbage til workshoppen de skal lave adgangskontrol for.

6.5 Færdigt produkt

Den endelige app der blev udviklet byggede meget på de grundlæggende tanker fra prototypen.

Dette blev besluttet på grund af den gode respons som vi fik på prototypen fra både

arbejdsgruppen og de frivillige, men også fordi at det feedback der kom, kunne implementeres

direkte i den allerede tænkte model.

Blandt ændringerne i den endelige app, er der blandt andet implementeret muligheden for at se

hvorfor en gæst bliver afvist. Det vises nu også når man kommer tilbage fra at have scannet, om

den senest scannede gæst blev godkendt eller afvist.

Som noget nyt kan app’en nu også vise en gul advarselstrekant, der indikerer at gæsten allerede

er checket ind én gang. Dette kan bruges til når gæster skal på toilettet undervejs, men samtidig

indikere hvis der er fusk med armbåndene ved workshoppens åbning.

Figur 8 - Screenshots af endelig app

Side 33 af 64

7. Diskussion

I det følgende vil vi gennemgå de valgte design- og forskningsmetoder fra projektet, og

reflektere over hvorledes disse har fungeret i vores projekt. Der vil også blive en kort diskussion

af andre mulige metoder, og om disse havde fungeret bedre end det valgte.

7.1 Design forløb

7.1.1 Anvendte metoder

Future Workshop

Vores valg om at afvikle en future workshop med festival-arbejdsgruppen bundede i teorien

omkring participatory design og vores idé om at det ville passe godt ind i dette projekt.

Selve workshoppen blev langt fra ’efter bogen’. Arbejdsgruppen var pressede på tid, og gav os

derfor kun omkring en time til at gennemgå det hele, hvilket resulterede i en meget hurtig

workshop. På trods af dette, viste arbejdsgruppen stor interesse i projektet, og var så engagerede

under workshoppen, at den begrænsede tid ikke blev synderligt synlig i det endelige resultat. Der

blev ikke tid til at bede dem om at tegne eller fremføre problemer som skuespil, men gruppen

havde i stedet et stort fokus på at komme med konkrete og brugbare problemstillinger og

løsningsforslag.

Gruppen havde også på forhånd hørt til nogle af grundideerne i projektet (RFID-chip i armbånd)

og deres ideer til løsninger blev derfor hurtigt sporet ind på denne løsning. Dette begrænsede den

åbne kreativitet vi havde håbet på i fantasifasen, hvor vi helst havde set et væld af science-

fiction-inspirerede ideer.

På nuværende tidspunkt må vi dog alligevel erkende at workshoppen som helhed forløb på bedst

mulige vis i forhold til dette konkrete projekt. Arbejdsgruppen på AAVF består af en række

mennesker der alle har fuldtidsstillinger andre steder, og kun mødes én gang om ugen i to timer

for at snakke sammen om festivalen. Derfor er der også tale om en arbejdsgruppe der arbejder

specifikt og løsningsorienteret. I deres øjne var vi ansvarlige for denne løsning, og de havde stor

tiltro til at vi ville levere en fungerende løsning.

Under workshoppen brugte gruppen derfor deres tid på at komme med feedback og ideer til

konkrete løsninger, med RFID-armbånd. Dette var også positivt for os, da vi derfor kunne

koncentrere os mere om den konkrete løsning bagefter, i stedet for at skulle behandle en masse

arbitrere ideer om hvordan løsningen kunne laves anderledes.

Side 34 af 64

Sidstnævnte var også medvirkende til at arbejdsgruppen gik fra workshoppen med en følelse af,

at de havde haft personlig indflydelse på projektet.

På nogle punkter kan man sige at arbejdsgruppen var mere som frivillige end vi først havde

antaget: Det er set ud fra at de også lavede andre ting ved siden af festival arbejdet, og dermed

havde begrænset tid til arbejdet, og dermed også projektet. De kan dog på ingen måde ligestilles

direkte med de frivillige. Arbejdsgruppen er stadig lønnet og har dermed en helt anden

motivation end de frivillige. Samtidig kan man også se arbejdsgruppen som “homopraxielle” i

modsætning til de frivilliges heteropraxialitet.

En future workshop skal ikke afholdes med frivillige, selvom disse er slutbrugerne af systemet.

Dette skyldes deres homopraxiality, hvilket ville være skyld i at de ikke nødvendigvis kan sætte

sig ind i det store overblik over festivalen.

Frivillige sessions

Efter workshoppen valgte vi at afholde individuelle interviews med tilmeldte frivillige som vi

havde fået lov til at indkalde. Vi var meget interesserede i hvordan de frivillige ville håndtere

vores prototype og hvilke kommentarer og forslag de havde til denne. At se de frivillige i aktion i

det opstillede scenarie har været meget vigtig og deres reaktioner har haft stor indflydelse på

hvordan vores endelig produkt er blevet, især i forhold til usability og funktionalitet.

Vi valgte at videooptage deltagerne i en simulation af en adgangskontrol-situation. Materialet var

til stor gavn for os, da vi senere kunne se det igennem og bemærke nogle af de reaktioner som de

frivillige ikke selv havde nævnt i deres opfølgende interviews. Her tænkes især på hvordan den

frivillige brugte telefonen til at scanne, som var noget mange af dem ikke tænkte nærmere over

da de først havde fundet ud af hvordan det skulle gøres. Dog kan vi se på videoerne at flere var

meget i tvivl om hvorledes dette foregik i deres første forsøg.

Valget om at lave en konkret med test-situation med de frivillige efterfulgt af et interview, virker

stadig som at have været det rigtige valg. Det var med til at underbygge den implementation som

vi havde startet tidligt (omtalt i 7.1.2), samtidig med at det har givet os mest muligt brugbart

feedback fra de frivillige.

Havde vi i stedet valgt at lave en workshop med de frivillige, havde det krævet meget mere tid af

den enkelte, og det er langt fra sikkert at vi kunne have fået samme engagement, som når der kun

var fokus på dem i 20 minutter. Til en eventuel workshop havde vi muligvis kunne gavne af

heteropraxialiteten mellem de frivillige, og få nogle forskellige nye ideer på bordet. Det er dog

stadig ikke en garanti at der ville komme noget konstruktivt ud af workshoppen, da deres

manglende kendskab til festivalen og festival-sammensætning kunne have arbejdet imod os.

Side 35 af 64

Vores simulationer efterfulgt af feedback har givet os præcis den information vi havde brug for -

netop at se hvordan en frivillig reagerede med systemet i hånden.

Igennem vores optagelser og feedback, så vi tydeligt de frivilliges heteropraxialitet, og hvorfor

det var godt at vi prøvede at tage hensyn til denne. De frivillige havde, omend ikke så blandet

uddannelsesmæssig baggrund, så en forskellig baggrund af både interesser, IT-evner og

motivation for at være på festivalen. Dette bekræftede os endnu engang i at vi ikke kunne have

brugt frivillige til en future workshop, men også at vores løsning blev nødt til at være simpel og

lige til at bruge.

Det har vist sig at være rigtig praktisk at komme med noget konkret når man arbejder med

frivillige. På denne måde har vi kunne se hvordan de reagerede med den tænkte løsning, og har

kunne bruge deres reaktioner til at forbedre løsningen før festivalen.

7.1.2 Tyvstart på implementations fasen

Som beskrevet tidligere tog vi et valg om at “tyvstarte” på implementeringen og udarbejde en

prototype. Valget blev taget pga. projektets meget korte tidsramme.

Ved at bygge prototypen fik vi en forståelse for hvad der, rent teknisk, kunne lade sig gøre. Det

gjorde os meget bedre forberedte på at diskutere løsninger med arbejdsgruppen til workshoppen.

Det var meget produktivt at, efter future workshoppen, kunne fremvise en prototype og kunne

have en samtale omkring denne i relation til de idéer deltagerne i workshoppen havde fremlagt.

Det kan dog vise sig at være farligt at gøre for meget ud af en prototype tidligt. Hvis

arbejdsgruppen var fundet frem til at en anden løsning var bedre og slet ikke var enige med os

om prototypen, så kunne vi have blevet nødt til at skrotte den. At have forberedt en prototype så

tidligt i projektforløbet som vi havde gør også at det kan være svært at sætte sig ud over

prototypen og tænke nye løsninger. Denne forudindtagethed er noget man hele tiden skal være

opmærksom på når man diskuterer mulige løsninger.

For os var prototypen dog meget vigtig og gavnende. Den gav os først og fremmest den

nødvendige viden til at deltage i en diskussion om mulige løsningen med workshoppen, og sidst,

men ikke mindst gjorde den det muligt for os at holde vores meget stramme tidsplan for

projektet.

Side 36 af 64

7.2 Forskningsmetoder/research

7.2.1 Valg af action research metode

Det har været en interessant oplevelse at indgå i “The cycle of action research” (Checkland,

1998). Vi gik ind til projektet med en række forskningsmetoder og temaer vi ville undersøge,

blandt andet hvordan man laver participatory design i en organisation med hovedsageligt frivillig

arbejdskraft. Undervejs har vi brugt meget tid på at arbejde med selve projektsituationen og løse

problemer heri, men har også haft mulighed for at stoppe op og reflektere over vores

forskningsspørgsmål i henhold til vores oplevelser med projektet.

Eksempelvis har vi haft mulighed for at planlægge vores interview med de frivillige, udvælge

designmetoder vi mener ville passe bedst og herefter udføre dem i projektet. Efter dette har vi

kunne tage hjem, samle resultater og i direkte forlængelse heraf reflektere over vores valg af

designmetode. På grund af tidsrammen har vi desværre ikke haft mulighed for at køre flere

iterationer i forhold til vores valg af designmetoder. Det kunne have været interessant at

gennemføre eksempelvis endnu et interview med de frivillige der byggede på de erfaringer og

refleksioner vi havde gjort os fra første interview, som action research lægger meget op til.

En del af action research forskningsmetoden er at gennemtænke ens exit-strategi, altså hvordan

virksomheden skal overtage og videreføre den ændring researchgruppen har deltaget i at skabe. I

vores tilfælde har det været relevant at tale med Flexminds, som er festivalens faste

samarbejdspartner til billetsystemet, omkring overtagelse og videreførelse af vores udførte

arbejde. Var vi af teorien ikke blevet gjort opmærksomme på vigtigheden af exit-strategien er det

tænkeligt at det ikke var blevet taget op.

Vi mener at valget af action research som forskningsmetode har bidraget positivt til vores projekt

og har hjulpet os med at opnå et godt resultat i både selve festivalprojektet såvel som vores eget

forskningsprojekt.

Action research har givet os muligheden for at indgå aktivt i projektet, så vi har kunne overholde

vores one-shot tidsramme, samtidig med at vi har en dybdegående forståelse for

problemstillingen og organisationen.

7.2.2 Dagbog

I projektets forløb har vi løbende ført en dagbog for de dage vi har arbejdet, og mod slutningen

af projektet, mest kun for de dage hvor der er sket lidt større ting eller taget vigtige beslutninger.

Den komplette dagbog kan findes i appendix B - “Dagbog”.

Side 37 af 64

Beslutnignen om at skrive dagbog blev lavet med det henblik, at vi som en del af vores action-

research løbende ville kunne kigge på hvad der var gjort, i forhold til hvordan vi skulle gøre det

for fremtiden.

Dagbogen har ikke vist sig specielt nyttig for lige præcis dette projekt, og det er også vores

manglende behov for den, der har gjort at mængden af “indlæg” i den er faldet over tiden. Havde

vores projekt strukket sig over en længere periode, hvor vi ville have haft mulighed for at køre

mere iterativt, havde dagbogen dog nok været meget brugbar i forhold til historik over hvilke

metoder der blev prøvet hvornår.

I stedet for dagbogen har vores optagelser af møder med diverse interessenter, ageret som vores

log af hvilke informationer vi har fået hvornår. Forløbet har været så tidsmæssigt kort, at vi ikke

har haft problemer med at huske diverse ting, og derfor har dagbogen ikke været meget brugt.

7.3 Erfaringer fra festival

Projektet har under hele forløbet været påvirket af vores meget omtalte tidsbegrænsning. Denne

har dog også medvirket til at vi her, kort for projektskrivningens afslutning har haft det

privilegium at se vores system “i aktion” på AAVF 2013 i dagene 17.-20. maj. I dette afsnit vil

vi kort beskrive nogle af vores oplevelser og observationer fra projektet, samt hvorledes disse vil

kunne bruges til at forbedre et evt. fremtidigt system.

7.3.3 Check-ind

Den første arbejdsfunktion vi oplevede var check-ind af gæsterne. Vi ankom om torsdagen for at

forberede check-ind skranken. 1 medarbejder fra Flexminds ankom også for at opstille

computere og stregkodescannere. For at forberede os på torsdagens rykind af gæster, valgte vi at

pre-indchecke alle VIP’s ved at printe deres vouchers, scanne dem og tilknytte armbånd. Det var

I løbet af denne process at vi for første gang fik afprøvet check-ind flowet i sin helhed. Vi

observerede følgende uforudsete problematikker:

● Deltagerne havde fået udleveret 2 vouchers pr. person med en stregkode på.

Billetsystemet kunne kun scanne den éne af slagsen og det skabte forvirring hos folk der

kun havde den “forkerte” type med.

● Ved check-ind spørger systemet først efter en stregkode i den første dialog, og herefter et

armbånds-UUID i den anden dialog. Begge dialogbokse tillod den anden type kode blev

indtastet og gemt. Det vil sige at hvis den frivillige kom til at scanne en stregkode to

gange i træk, blev stregkoden gemt som armbånds-UUID’et. Og herefter ville de være i

en forkert rytme hvor de scanner armbånd derefter stregkode, i stedet for omvendt. I den

Side 38 af 64

stressede arbejdssituation kunne der gå flere indcheckninger før den frivillige opdagede

at der var sket en fejl.

Begge problematikker har rod i Flexminds indchecknings system. Under “Samarbejdspartnere”

diskuterer vi om disse problematikker kunne være undgået.

Fredag var den store indcheckningsdag og vi fik her indchecket omkring 700 deltagere. Det var

de samme to problemstillinger vi oplevede i løbet af fredag og lørdag, men efterhånden som de

frivillige fik flere indcheckninger under huden skete der færre og færre fejl.

Vi estimerer at vi havde omkring 40 fejlindcheckninger i løbet af hele festivallen, ud af samlet

750 gæster. Altså cirka 5,3%. Ud fra festivalens størrelse er det en håndterbar fejlmargin, men i

vores øjne ikke acceptabel til fremtidige festivaler.

7.3.4 Workshop-adgangskontrol

Den løsning vi selv havde udviklet til AAVF, kom først i spil fredag eftermiddag kl. 16, hvor de

første workshops skulle afvikles. Her mødtes vi med de frivillige kort inden de skulle ud på

workshops og lave adgangskontrol, for at give dem en kort introduktion til systemet - heriblandt

at gøre opmærksom på hvordan scanning fungerede. Herfra blev de sendt ud til deres workshops,

og påbegyndte adgangskontrollen af gæsterne.

Langt størstedelen af gæsterne der dukkede op til workshops, så et grønt flueben på telefonen og

blev lukket direkte ind. Dog var der også, nogle som blev afvist adgang til workshoppen.

Årsagerne til afvisningen var altid den samme, at gæstens armbånds UUID ikke optrådte på

gæstelisten til den enkelte workshop. Årsagen til dette var dog forskellig fra gæst til gæst.

Enkelte gæster oplevede at være gået til den forkerte indgang, og blev derfor først opmærksom

på dette da de blev afvist i døren. Her må man sige at systemet bestemt har hjulpet alle parter.

Dog kunne en del af de gæster, som blev afvist, fremvise et udprint fra workshop-tilmeldingen,

hvor de kunne bevise at de havde købt adgang til denne workshop. Herfra blev de frivillige

instrueret i at lukke gæsten ind, og bede gæsten kigge forbi informationen bagefter, for at få

rettet fejlen med deres armbånd.

Side 39 af 64

Vi identificerede følgende årsager til at en gæst blev afvist, på trods af at de havde tilmeldt sig

workshoppen:

● Som omtalt i 7.3.3 har check-ind processen været gået galt med flere gæster, hvor deres

armbånds-UUID ikke er blevet registreret rigtigt til deres person i databasen, og derfor

bliver UUID’et afvist i døren. Dette kunne dog hurtigt løses ved at scanne gæstens billet

igen og registrere armbåndet rigtigt på gæsten denne gang.

● Nogle gæste havde først tilmeldt sig workshops en time før denne startede, og de var

derfor ikke nået ind i API’et vi trak data fra, når gæstelisten blev hentet ind 15-30

minutter før workshopstart. Dette var yderst uforudset, og Flexminds kunne ikke selv

give en forklaring på den store forsinkelse, og havde ikke mulighed for i løbet af

festivalen at fejlsøge og rette dette.

Efter at have identificeret problematikkerne, og set at hovedansvaret for begge - samt mulighed

for løsninger - lå ved Flexminds som ikke havde tid til at rette dem, måtte vi improvisere andre

process-baserede løsninger i forhold til de frivillige der udførte kontrollen. Løsningen blev lavet

ud fra den gæsteliste vi havde implementeret som en af de sidste funktioner i app’en. Her bad vi

de frivillige tjekke efter gæstens navn, hvis armbåndet blev afvist. Dette afhjalp 9/10 af de

problemer som de frivillige oplevede, da gæsten som oftest var registreret, men deres UUID ikke

var blevet registreret rigtigt i databasen.

Den sidste 1/10 gæst der blev afvist, havde for det meste tilmeldt sig så sent, at Flexminds API

ikke var nået at blive opdateret med registreringen. Det var dog desværre ikke muligt at lukke for

denne tilmelding, da informations-medarbejderne stadig løbende skulle have mulighed for at

tilmelde enkelte gæster på workshops med åbne pladser - og Flexminds kunne ikke lukke for

nogle, og åbne for andre.

En af de ting vi lærte fra afviklingen af workshops (på festivalen) var, hvor vigtigt det er at give

klare instruktioner til de frivillige, især omkring uforudsete situationer. De frivilliges

heteropraxiality gør at de har en meget begrænset indsigt i selve organisationen, og kan derfor

ikke forventes at kunne håndtere uforudsete situationer alene medmindre de får meget specifikke

instruktioner.

Det kom især til udtryk i en bestemt situation vi oplevede. En frivillig ved workshop-check-ind

var kommet til at gå ud af applikationen på telefonen, og kunne pga. manglende internet ikke

komme ind i den igen. Hun gik i panik, råbte og løb efter hjælp. Hun var bange for at de 100

personer der stod og ventede blev sure og hun vidste ikke hvordan hun skulle forholde sig i

forhold til dem. Havde hun haft en indsigt i organisationen, ville hun have håndteret situationen

meget mere roligt. I dette tilfælde kunne hun have vurderet at den bedste løsning blot var at

lukke dem ind til deres workshop og undgå at skabe uro.

Side 40 af 64

7.3.5 Samarbejdspartnere (Flexminds)

Projektet har hele tiden været kraftigt afhængigt af vores samarbejdspartner Flexminds, i og med

vi skulle bruge deres data om workshoptilmeldinger i vores løsning. Flexminds var som

udgangspunkt vores eneste mulighed, da de allerede var blevet hyret til at udvikle billetsystemet

for AAVF, da vores projekt startede.

Dog kan det være at ordet “samarbejdspartner” burde have været overvejet bedre fra vores side.

Vi så fra starten Flexminds som en samarbejdspartner der ligesom os kunne drage nytte af

projektet, og måske endda nogle vi ville kunne arbejde sammen med senere. Det virkede dog

som om at Flexminds mere så det som værende dem der hjalp os med vores projekt - og ikke

meget mere end dette.

I månederne op til festivalen havde vi svært ved at komme i kontakt med vores kontaktpersoner

fra Flexminds, og bare adgangen til API’et var utrolig svær at få. Da denne først kom, var der

ikke tale om den rigtige data fra AAVF, men i stedet var der sat et testmiljø op. Vi så derfor først

den konkrete AAVF data i API’et dagen før vores ankomst til festivalen.

Firmaet virkede heller ikke til at have sat sig egentligt ind i vores løsning, og hvordan vi havde

tænkt den. Vi måtte løbende bekræfte at bestemte features var til stede, og minde dem om at vi

kun behøvede meget begrænset data fra dem, og at de derfor ikke skulle overkomplicere deres

system.

Et helt konkret eksempel på dårlig kommunikation blev synliggjort efter de første workshops

blev afholdt fredag eftermiddag. Her opdagede vi pludselig at API’et (hvorfra vi hentede listen

over workshops) ikke viste workshops der var påbegyndt. Dette bevirkede at hvis en workshop

var forsinket, eller blevet udsat - skulle dette være rettet i Flexminds system, for at vi kunne se

workshoppen i listen. En workshop der startede kl. 16, kunne altså ikke ses i API’et kl. 16:00:01.

Dette gjorde det også umuligt for os at fejlsøge på den konkrete bruger og workshop-

kombination - efter problemet var opdaget. Den eneste hjælp vi kunne få her, var Flexminds der

satte alle starttider 2 timer frem i databasen - manuelt - da de mente det ville tage for lang tid at

fjerne begrænsningen.

Både torsdag og fredag havde Flexminds sendt henholdsvis én og to medarbejdere til at hjælpe

med systemet. Disse var dog taget afsted før den første workshop, og var svære at få kontakt til

resten af weekenden. Begge medarbejdernes tid om fredagen, gik da også hovedsageligt til at

lave konkrete løsninger omkring deres system med workshop-tilmelding.

Vi havde en forhåbning om at en ekstern partner, kunne være med til at sikre at systemet ville

køre på en ny festival næste år, uden nødvendigvis at være afhængig af os. Dette er set ud fra

Side 41 af 64

Zander, 2005 (også omtalt i afsnit 2.1), hvor vigtigheden af at kunne videregive systemet

beskrives.

Igennem vores kommunikation med Flexminds, virker det dog ikke til at de har tænkt at de

skulle overtage løsningen til senere drift. Samtidig virker det heller ikke nødvendigvis til at

festivalen ønsker at benytte Flexminds som leverandør senere hen.

Der er i organisationen ikke den tekniske kundskab til at kunne overtage systemet selv, og da den

eksterne partner ikke har vist interessen, har det ikke været muligt for os at arbejde med en

konkret overdragelse af systemet.

Set i bakspejlet, er det ikke lykkedes os at engagere Flexminds på samme niveau som AAVF og

os selv. Et større engagement havde muligvis givet os et tættere samarbejde, hvor vi ville kunne

have prøvet flere ting af på et tidligere tidspunkt. Et større engagement kunne måske have været

opnået, hvis vi på et tidligt tidspunkt havde gjort et større økonomisk perspektiv klart for

Flexminds.

7.4 Anbefalinger

I dette afsnit vil vi opstille en række anbefalinger som vi, udfra vores erfaringer i dette projekt,

vil give videre til andre designere og researchere, især med fokus på organisationer med

frivillige.

7.4.1 Til designforløbet

● Future workshops virker rigtig godt til at engagere organisationen der laves designprojekt

for og kan selv på kort tid skabe ejerskabsfornemmelse hos organisationen hvis gjort

rigtigt.

● At præsentere en prototype efter en future workshop virker rigtig godt til at faciliterer en

god og mere konstruktiv samtale om den endelige løsning, dog kun hvis prototypen kan

understøtte nogle af de pointer der er blevet diskuteret på workshoppen.

● At udføre videofilmet sessions med de frivillige/slutbrugerene bestående af et interview

om deres baggrund, en brugertest af prototypen samt et afsluttende interview om

oplevelsen med systemet hjælper på flere ting:

○ Forståelse af projektets heteropraxiality - de frivilliges motivation for deltagelse

kan være meget forskellig og det er vigtigt at få afklaret.

○ At forstå hvordan de frivillige anvender systemet ud fra samme grundlag.

Videoen hjælper til at bagefter kunne opfange kropssprog man ikke har fokus på

under selve brugertesten.

Side 42 af 64

○ At få nye idéer og input fra personerne der ender med at bruge systemet.

● Frivillige er utilregnelige og inputtet de kan komme med kan være af svingende kvalitet

pga. deres ofte meget korte involvering i organisationen. Derfor; tænk på implementation

tidligt - det er en god idé at komme med et udgangspunkt eller en prototype at arbejde ud

fra.

7.4.2 Til forskningsmetoder

● Action research forskningsmetoden er interessant når man arbejder med research af

processer og metoder. Har man muligheden for at deltage aktivt i organisationen, foretage

ændringer løbende og et mål om iterativt at finde frem til sine resultater via observation

af reelle ændringer er action research en god mulighed.

● Varer projektet længe nok til at foretage iterationer, mener vi at det kan være til stor gavn

at føre dagbog, for at have en historik over hvilke metoder der er forsøgt, og hvordan.

8. Konklusion

Da projektet nu er afsluttet er det muligt at konkludere på hvorvidt forskningsspørgsmålet er

blevet besvaret i et tilstrækkeligt omfang.

Vores projekt har vist hvordan man gennem redskaber fra participatory design kan arbejde med

et designprojekt for en organisation af frivillige, eksempelvis en festival. Med udgangspunkt i

den allerede eksisterende litteratur om participatory design og arbejde med frivillige, har vi

udvalgt, tilpasset og afprøvet forskellige værktøjer og teknikker. Vi har herefter diskuteret vores

praktiske erfaringer og fundet frem til en række anbefalinger vi gerne vil videregive.

Vores valg af action research som forskningsmetode har tilladt os en dyb involvering i projektet

og muligheden for at lave research og samtidig være en del af projektgruppen. Det mener vi har

bidraget positivt til resultatet af både forskningen og produktet. Vi har dog ikke udnyttet action

researchs iterative egenskab i forhold til designmetoder pga. vores tidspres selvom det ville have

været ønskeligt.

Valget om at afvikle en future workshop med arbejdsgruppen bundede i teorien omkring

participatory design og vores idé om at det ville passe godt ind i dette projekt. Selvom selve

workshoppen ikke forløb fuldstændig efter bogen mener vi at workshoppen har bidraget meget

til projektet. Workshoppen udvidede både vores forståelse for festivalen, men også

arbejdsgruppens forståelse og indsigt i problemstillingen og mulige løsninger. Det var første

gang vi så de fleste af arbejdsgruppens medlemmer, men på trods af det, følte vi at alle gik fra

workshoppen med en fornemmelse af personlig medvirken i projektet.

Side 43 af 64

Vi mener at vi med vores projekt har vist, at man ved at tage udgangspunkt i participatory design

værktøjer, tilpasse dem og indtænke heteropraxiality, kan komme frem til redskaber og

arbejdsmetoder der virker godt i en organisation med frivillige. I forhold til festival-projekter

især, mener vi dog at det vil give mening at tænke over implementations-muligheder tidligere i

processen, end ved “normalt” participatory design.

8.1 Perspektivering

Systemet har uden tvivl vist sit potentiale på AAVF i år, og også vist at det kan fungere i et stort

levende miljø. Vi har selvfølgelig gjort os nogle erfaringer omkring især menneskelige og

procesmæssige fejl, og hvordan man eventuelt kan forebygge disse i et større miljø.

Det er ikke utænkeligt på sigt at kunne lave en lignende løsning for en større festival med mange

tusinde gæster. Umiddelbart vil det dog på en større festival give mening at have telefonerne

online hele tiden, så gæsteliste opdateringer kan sendes direkte. Samtidig vil det være oplagt at

begynde at tænke en betalingsløsning ind i armbåndet også, for at kombinere adgangskontrol

med andre muligheder i NFC/RFID-teknologien.

Side 44 af 64

9. Litteraturliste

AAVF (2013). The Board of Directors. Lokaliseret 12/04/2013 på: “http://aavf.dk/sample-

page/the-aavf-board-of-directors/”

Bertelsen, O. W. (1998). Elements to a theory of design artefacts: a contribution to critical

systems development research. Department of Computer Science, Aarhus University.

Bertelsen, O. W., & Zander, P-O. (2005). Obstacles to Design in Volunteer Based Organisations.

In Proceedings of the 5th Danish Human-Computer Interaction Research Symposium. (pp. 93-

98). Copenhagen Business School.

Bødker, K., Kensing, F., & Simonsen, J. (2004). Participatory IT design: designing for business

and workplace realities. MIT press.

Checkland, P., & Holwell, S. (1998). Action research: its nature and validity. Systemic Practice

and Action Research, 11(1), 9-21.

Hansen, J. P., Glenstrup, A. J., Wusheng, W., Weiping, L., & Zhonghai, W. (2012). Collecting

location-based voice messages on a TalkingBadge.

McPhail, B., Costantino, T., Bruckmann, D., Barclay, R., & Clement, A. (1998). CAVEAT

exemplar: Participatory design in a non-profit volunteer organisation. Computer Supported

Cooperative Work (CSCW), 7(3), 223-241.

Nygaard, E., Henriksen, S. (Interviewer) & AAVF Arbejdsgruppe. (Workshopdeltagere).

(12/04/2013). Future workshop [Transkribering]. Transkribering i Appendix E. Lydfil:

http://goo.gl/EKkex og på vedlagt CD.

Zander, P.-O. (2005b). The role of collective subjects in appropriation - an evaluation of a

collaborative writing project. In Kinshuk (Ed.), CELDA2005 (pp. 285-293). Porto, Portugal:

IADIS Press.

Side 45 af 64

Side 46 af 64

Side 47 af 64

Appendix B: Dagbog

11. marts

14.00 - Samtale med Ritta fra rfid-specialisten

Rfid-specialisten har lavet flere løsninger med adgangskontrol og RFID. Ritta fortæller at hun

mener deres almindelige håndscannere er for dyre i forhold til vores projekt, men at hun synes vi

skal undersøge om vi kan bruge telefoner med NFC scannere indbygget (Windows Phone, flere

Samsung...). Hun fortæller om diverse apps som vi kan hente og teste NFC/rfid chips med.

Rfid-specialisten sælger også armbånd og Ritta oplyser os om en pris på armbånd på 3,48 stk.

samt et trykpris på 550 kr. i opstart og 0,37 kr. stk. Det er en studenter/non-profit pris og vi har

tilbudt hende billet til festivallen som tak.

Tanker

Idéen med at benytte telefoner er interessant og den vil vi prøve at gå videre med. Har en

bekymring om at scanningen bliver for besværlig/langsom idet chippen skal meget tæt på

telefonen for at det registreres (vi har afprøvet med Emils telefon og rejsekortet).

15.00 - Mail afsendt til FlexMinds om møde

12. marts

12.00 - Mail afsendt evt. samarbejdspartnere

Mail sendt til Jon Bille (Ansvarlig for Windows Phone) fra Microsoft om et evt. samarbejde hvor

de låner os telefoner imod reklame på festivallen.

Mail sendt til Morten Jørgensen (Social Media Manager) fra 3 omkring lån af mobiltelefoner og

reklame.

13.00 - Vejledermøde med Yvonne

Side 48 af 64

Vi fortalte Yvonne at vi gerne ville have mere styr på hvad vi skulle skrive og hvornår. Herefter

gennemgik Yvonne hvordan en bachelor-opgave normalt skrives (V-form) samt gennemgik

hvordan videnskabelige artikler er bygget op og hvordan vi kan finde dem.

Vi blev enige om at vores fokus ligger på dels at komme videre med vores

research/designprojekt og dels begynde at finde relaterede artikler vi kan læse og benytte os når

vi skal skrive om vores research method.

Vi aftalte at vi til i næste uge skulle have et udkast til en tidsplan klar til hende. Vi optog også

hele mødet.

17. marts

Vi har fundet 3 artikler der kan være interessante for vores projekt. To af dem er skrevet af Olav

W. Bertelsen fra Aarhus universitet:

● Obstacles to design in volunteer based organisations

● Appropriation in the development of information systems for voluntary organisations

Den sidste vi har fundet er skrevet af Pär-Ola Zandar som også er medforfatter på “Obstacles to

design in volunteer based organisations”. Artiklen citerer begge Olavs artikler:

● Collaborative Process Change by Inscription

20. marts

Møde med Yvonne omkring vores tidsplan.

25. marts

Gennemlæsning af “Obstacles to design in volunteer based organisations”.

Vi skrev et afsnit til “Related work” omkring den ovenstående artikel.

Side 49 af 64

26. marts

Til idag havde vi læst McPhail 1998 og vi skrev et tilhørende afsnit om den i vores related work

kapitel.

I fredagens (d. 15) forelæsning om participatory design læste vi en artikel om “Talking Badge”

skrevet af forskere fra ITU. Her var nogle interessante sammentræf med vores projekt; f.eks. et

produkt der skulle bruges af en stor målgruppe.

Midt på dagen hentede var vi oppe og tale med PitLab, som var venlige at låne os en usb RFID-

læser. De vil også prøve at skaffe os telefoner hvis de kan finde penge til det.

I løbet af eftermiddagen og aftenen fik vi lavet en virkende prototype af de to store dele systemet

består af:

● Check-ind læseren der scanner RFID og skriver UID’et på computeren efterfulgt af et

“Enter”

● Mobilapplikationen til android der kan læse RFID uids og vise en besked om personen

må komme ind eller ej.

2. april

Idag har vi forberedt workshop med arbejdsgruppen der finder sted fredag d. 12. april. Vores

plan er at lave en future workshop med arbejdsgruppen inden vi præsentere dem for vores

prototype, så vi kan få nogle “rene” tanker uden at de alle tænker på den prototype vi lige har

præsenteret.

Vi har også forberedt de interviews/forsøg vi vil lave med de frivillige efter arbejdsgruppe-

workshoppen. Vores plan er at sætte dem ind i en situation hvor de står i døren til en workshop

og skal modtage gæster. Så vil vi se om de kan finde ud af det, og derefter interview dem

omkring det.

Side 50 af 64

3. april

I dag havde vi møde med Yvonne omkring vores related work afsnit. Vi talte om hvad der

manglede og vi fik uddybet hvad vi skulle skrive under design methods og research methods. Vi

viste også Yvonne prototypen.

4. april

I dag har vi skrevet videre på vores afsnit om related work. Vi har uddybet principperne i

participatory design og hvorfor vi har valgt denne metode.

Så er vi begyndt at skrive i detaljer omkring designprocessen. Det inkluderer hvilke værktøjer vi

har valgt at benytte os af, hvordan vi vil udføre workshops osv. Der er også blevet skrevet kort

omkring den udviklede prototype.

I dag fik vi også sikret os at ITU PitLab vil låne os 3 RFID usb-læsere. Vi mangler stadig at få

styr på telefonerne.

5. april

Vi har arbejdet videre kapitlet om designprocessen og så er vi begyndt at skrive om research

methods.

12. april

Workshop i Aarhus, først med arbejdsgruppe, og derefter interviews med frivillige.

Workshoppen blev lidt kort, men det virker som om at alle var tilfredse, og vi fik meget god

feedback fra arbejdsgruppen!

Side 51 af 64

De frivillige var ligeledes gode til at give os et indtryk af hvad der skulle gøres bedre!

19. april

Sebastian skriver at vi får telefoner - dog kun 7 stk.

Efter en kort dialog med ham, finder vi ud af at vi kan låne en ekstra - de sidste to skaffer vi selv

andetsteds.

23. april

I dag modtog vi endelig dokumentation om FlexMinds nye API. Vi har dog ikke modtaget

nødvendige keys og adgang til endpointet, så vi kan ikke teste endnu.

24. april

I dag fik vi de nødvendige detaljer for at vi kunne kommunikere med API’et. FlexMinds har

oprettet testdata som vi indtil videre kan bruge.

26. april

I dag har vi arbejdet på implementationen af FlexMinds API i vores app. Under tests fandt vi en

fejl i API’et: Brugerens UUID var ikke universelt, men skiftede fra workshop til workshop.

FlexMinds er blevet gjort opmærksomme på fejlen.

Vi har en tæt på fungerende app klar nu, med få mangler.

6. maj

Vi har hentet telefoner hos PITlab er har uden problemer fået app’en til at køre på dem, samt

testet NFC-funktionaliteten. De ser ud til at virke upåklageligt allesammen, og skærmen er

heldigvis ikke for lille til vores design.

Side 52 af 64

App’en er blevet udvidet med en “gæsteliste” så man kan se hvem der har tjekket ind og ud, samt

med muligheden for at sende checkind-data tilbage til flexminds.

8. maj

Vi har arbejdet videre på diskussionen, men løb ind i problemer omkring definitionen af Action

reasearch, design research og participatory design - og især hvordan de adskilles.

Det blev dog afklaret godt på 10 minutter med Yvonne, og vi er back on track.

10. maj

I dag har vi arbejdet videre på rapporten og arbejdet på at få færdiggjort og afrundet flere afsnit.

Side 53 af 64

Appendix C: Plan for workshop med arbejdsgruppe

Introduktion af workshop.

Kritik-fase

Vi deler deltagerne op i nogle grupper, f.eks. med 2 i hver gruppe. Herefter fortæller vi dem kort

hvad kritikfasen går ud på og vi giver hver gruppe et ark papir hvor de kan skrive “3 dårlige

ting” ned.

Herefter samler vi sedlerne ind og vi gennemgår fælles hvilke problemer der er blevet nævnt

mest samt diskuterer. Er alle enige i de problemstillinger der bliver bragt op? Er der

problemstillinger der ikke er blevet nævnt?

Til slut udvælges 1-2 problemstillinger som vi fokusere på i resten af workshoppen.

Fantasi-fase

Grupperne får at vide at de nu skal forsøge at løse de problemstillinger vi er blevet enige om er

de største. De skal bruge deres frie fantasi og skal ikke føle sig begrænset af teknik, økonomi

eller lign.

Grupperne præsenterer deres løsningsforslag og vi vælger fælles nogle forslag vi vil gå videre

med (max 1 per gruppe).

Realisme-fasen

Grupperne får tildelt et løsningsforslag som de skal arbejde videre med. Deres opgave er at tage

de realistiske briller på og se, helt lavpraktisk, på hvordan det kan føres ud i virkeligheden. De

skriver stikord ned.

Hver gruppe får lidt tid til at præsentere deres plan. De andre grupper må gerne komme med

input og tanker. Når alle grupper har præsenteret laver vi en håndsoprækning om hvilken plan

folk er mest tilhængere af.

Præsentation af vores plan

Efter workshoppen præsenterer vi vores plan. Vi får input fra workshoppen om hvad de synes

om vores plan, sammenligner med de planer de lige selv har fundet på og prøver at kombinere til

en fælles plan.

Side 54 af 64

Side 55 af 64

Appendix D: Plan for frivillige-session

Briefing

Din arbejdsopgave på festivalen er adgangskontrol. Du skal sørge for at kun tilmeldte får adgang

til koncerterne og workshopsne.

Du står nu i indgangen til workshoppen “Just sing it!”. Du har fået udleveret en telefon som du

skal bruge til at kontrollere deltagernes armbånd. Om få øjeblikke bliver døren åbnet og

deltagerne begynder at ankomme. Du skal starte med at forberede telefonen til at checke

armbånd på denne workshop og tage imod de første tre gæster.

Interview

Generel information

● Navn

● Alder

● Bopæl

● Uddannelse

● Beskæftigelse

● Motivation for at være frivillig

● IT-evner fra 1-10

Spørgsmål

● Hvad var din umiddelbare oplevelse af at bruge systemet?

● Følte du dig sikker ved at bruge løsningen?

● Der sker et teknisk problem og telefonen dør. Hvordan vil du håndtere situationen?

● Telefonen siger at en gæst ikke er på listen, men det påstår han selv at han er. Hvordan vil

du håndtere situationen?

Briefing af arbejdsopgave

Din arbejdsopgave på festivalen er adgangskontrol. Du skal sørge for at kun tilmeldte får adgang

til koncerterne og workshopsne.

Side 56 af 64

Du står nu i indgangen til workshoppen “Just sing it!”. Du har fået udleveret en telefon som du

skal bruge til at kontrollere deltagernes armbånd med. Om få øjeblikke bliver døren åbnet og

deltagerne begynder at ankomme. Du skal starte med at forberede telefonen til at checke

armbånd på denne workshop og tage imod de første tre gæster. På telefonen skal du bruge app’en

“AAVF adgang”.

Side 57 af 64

Appendix E: Transkriberinger fra workshop

#00:01:01-8# [Deltager 1] Registrering af navn, du kan ikke ehhh, du har jo oftest navnet på

biletten, så forsvinder den i forhold til at du har ikke nogen registrering, eller du har ikke nogen

identitet på den der nu har det pågældende armbånd.åå

#00:01:18-7# Det vil sige, nr du gr ind og ud, du har ikke styr på hvor folk er, det er ikke fordi

man skal ha' det, men det kan godt være gavnligt.

#00:01:28-9# Så er der check-in/check-ud ved forlad plads, eller gå ind på plads. Vi har jo et

sted hvor folk de går ind eller ud mange gange, dvs. så skal du have en ekstra resource til

adgangskontrollen. Det tager længere når der skal stå en og rykke i armbånende, og det i hele

taget tjekke om man får lov til at gå ind, eller ikke.åå

#00:01:45-6#

Og det er det samme gælder hvis man har noget V.I.P registrering, så skal du have forskellige

armbånd, det kan ikke lægge i det samme. Igen skal du have resourcen til at tjekke det.ææ

#00:02:04-8#

Og du kan ikke bruge det til pre-betaling. Så skal du have et armbånd der viser du har betalt. Det

kan ikke lægge i det samme armbånd, eller så skal du have et klippekort eller en madbillet hvis

du har pre-betalt. åå

#00:02:19-7#

Så er der en sidste ting, som faktisk ikke ret mange tænker over, og det er hygiejne. Man kan

selvfølgelig bruge plastikarmbånd, men i løbet af, måske ikk i år men næste år, så vil

fødevarestyrelsen ikke acceptere stofarmbånd, af hygiejnehensyn.åå

[Interviewer] Det var mange gode ting, er der andre der har noget andet?

#00:03:04-7#

[Deltager 2] Ja, vi har ikke styr på hvem der går ind til hvilke workshops. Vi sad og klippede

nogle biletter ud til dem, som de så kunne aflevere, men det var et værre system. ææ

#00:03:15-5#

[Deltager 3] Og jeg vil lige tilknytte en kommentar til det der, fordi de der "zappere", altså de

zappere som alligevel snuser lidt for meget og går rundt, det skal vi have stoppet.åå

Side 58 af 64

#00:03:33-8#

[Deltager 4] Vi har så nogle V.I.P'ere som er lovlige zappere, så dem skal vi lige have styr på. åå

#00:03:49-1#

Tilsvarende havde vi sådan nogle udklippede madbiletter, som man bare skulle lægge i en eller

anden skål, og det var også temmeligt besværligt at holde styr på.åå

#00:08:20-7#

[Deltager 3] De skal kunne scannes, lynhurtigt. Altså, det skal fungere bare sådan, så det ikke

danner kø, ligesom en skilift.

#00:08:30-3#

[I forbindelse med snak om brug af chip-teknologi]

[Deltager 5] .... men de skal g igennem sådan en scanner ligesom i lufthavnen.

#00:08:32-4#

[Deltager 6] - Ja! Det ville være super fedt!

#00:08:35-9#

Og så, altså, det giver jo sig selv, men meget meget vigtigt at der ikke er fejl i den enkeltes chip,

fordi jeg kan godt lige se det for mig: Så kommer man til en eller anden workshop og "Jeg har

adgang", og så har de ikke alligevel - det er sådan noget folk kan blive rigtig pissed over.

#00:08:47-6#

- Ja, og på den måde er det også nødvendigt at vi kan gå ind og ændre, altså at omkode et

armbånd ret let, ik?

#00:09:46#

Jeg tænker sådan lidt på… Efter festivallen, det der med at man har nogle informationer på de

forskellige deltagere man kan bruge, målrette noget kommunikation og markedsføring og andre

ting. Det kunne være interessant!

#00:10:26#

Side 59 af 64

… Jeg har arbejdet med RFID i nogle år rent logistik mæssigt. Det her med at man kan spørge

"hvor mange er til stede nu?", det kan være til en workshop eller det kan være til en koncert, og

så kan man give resten besked om at "nu starter" det med en alarmfunktion.å

#00:10:40#

[Snak omkring mulighederne med RFID]

Man kan bruge det til forudbetalt mad og drikke, så man bare kan bippe det i baren, så får du

udleveret din mad. Så har du betalt den og så bliver det trukket for din konto. Restbeløbet hvis du

ikke forbruger alle dine penge, så kan det overgå til velgørenhed eller et eller andet. Man kan

smide det ned i en eller anden pulje.

Side 60 af 64

Appendix F - Interviews med frivillige

Mette Rasmussen

25 år

Bor i Århus

Almene musikpædagogik

Ønskescenarie er ansat på musikskole med elever, kor, orkester…

Arbejder i Føtex (kassedame)

Motivation

Har selv kor, interesseret i det. Samme sted som hun læser og meget fleksibelt.

IT-evne: 5. Har ikke selv smartphone.

Interview

Skulle lige ind i det. Finde app’en, vidste ikke helt hvad det var.

I forhold til gæsteliste, føler sig tryg. Men hvis der bliver nægtet adgang, kunne være rart at man

kan fortælle personen hvor man så skal hen. Smart hvis den kunne det.

Telefonen dør. Vil gerne vide hvor man skal finde en anden – eller hvor den skal oplades.

Oplader. Backup løsning med papir indtil workshoppen er i gang?

Hvis person ikke er på gæsteliste, så send ham ned til information.

Generelle tanker

Måden at scanne på. Tænkte først det var ude på kanten og ikke inde på midten.

#00:00:07”

[Interviewer] Hvad var din umiddelbar oplevelse af det her? Hvad tænkte du?

Side 61 af 64

[Mette] Jeg tænkte jeg skulle lige ind i det, men det fungerer meget godt. Man skal jo lige finde

det, men det tænkte jeg ikke over - som sagt, jeg er ikke, jeg har ikke sådan noget, så det med

app’en og sådan, jeg er slet ikke inde i det sprog.

Sebastian Hatt

28 år

Bor i Aarhus

Almene musikpædagogik

Undervise i forskellige sammenhænge. Arbejder som korleder. Normalt at have lidt af hver slags

undervisninger

Har et kor og synger i et kirkekor

Motivation

Gratis med til en masse ting man ellers skulle betale for. Var frivillig for 2 år siden. Var fint i

forhold til arbejdsbyrden.

IT-evne: 9. Har arbejdet med programmering. Lavede nogle småspil og hjemmesider, lidt til TI-

83 lommeregner. Arbejder på at lave en app. Har en android.

Interview

Usikker på hvad ”kryds” betyder – hvorfor?. Det er svært at stå som frivillig og afvise en person

medmindre man er helt sikker.

God idé – stod i dør sidste gang. Der var bøvl med billetterne.

Anja Poulsen

24 år

Bor i Aarhus

Side 62 af 64

Alemene musikpædagogik. Skriver om amatørorkester musik.

Motivation

Kormusik interesserer hende. Var der også for 2 år siden, var godt. Glad for det hele er gratis.

IT-evner: 5-6.

Interview

Virkede umiddelbart lige til. Vidste ikke at den skulle helt ned til. Skal måske stå. På billedet

ligner det armbåndet er vendt omvendt? Ellers smart, nemt i forhold til lister.

Skriv at ”den skal røre ved armbåndet og cirka midt på telefonen”.

Følte sig sikker i forhold til gæsteliste. Mindre ansvar på en måde.

Ved fejl:

Vil gerne ringe til nogen. Lukker alle folk ind og løser problemet imens workshoppen løber

afsted. Evt. låne telefon fra anden workshop hvis de er færdige med at bruge den.

Vil spørge ”Hvilken workshop er du tilmeldt?”. Måske hvis man kunne se listen på telefonen? Så

kunne man finde ud af om det var chippen der er gået i stykker.

#00:04:45#

[Interviewer] Følte du dig sikker ved at bruge telefonen i stedet for en normal gæsteliste?

[Anja] Ja, fordi så skal min ikke selv holde styr på det og registrere det. Man skal ikke selv tage

ansvar.

Ida Olesonen

24 år

Bor i Aarhus, men flytter tilbage til Finland i juli.

Studere rytmisk halvt bachelor/master

Side 63 af 64

Finland fokus på undervisning. 1-9 klasse og gymnasie. Vil meget gerne fokusere på vokalmusik

og hendes finske vokalensemble.

Undervises på FOF Aarhus og har en rytmisk sanggruppe.

Motivation

”Vokalnørd”. Interesseret, prøvede at komme med i konkurrence – men kom på reserveplads.

Spare lidt penge. Ved meget om vokalmusikken og håber at kunne få mere ud af det på den

måde.

IT-evner: 6-7 stykker. 95 ord i minuttet!

Interview

Reliable. Giver en god mening. Men hvad hvis det ikke virker? En papirliste er mere foolproof.

Sikker efter at have scannet et par gange.

I stykker

Kontakter supervisor. Det er ikke hendes ansvar.

Ved fejl

Vigtigt at man briefer de frivillige. Forskel på ”Du må ikke komme ind” og ”Vi checker lige igen

– nej desværre, du kan desværre ikke komme ind”.

Har prøvet på andre festivaller hvis nogen er meget påtrængende at de bare må komme ind. Vil

meget gerne høre hvordan det kommer til at være på AAVF.

”Synes det er smart”

Måske lidt bange for at have ansvaret for en telefon.

Side 64 af 64

Appendix G – Spørgsmål til Thomas Mathiesen

D. 19/2-2013 sendte vi fire følgende spørgsmål til producent Thomas Mathiesen, producent på

AAVF 2013. Hans svar er markeret med grøn farve herunder:

Hej Thomas,

Vi har et par spørgsmål vi håber du kan uddybe, de er indsat herunder. Du kan bare svare når du

mener du har god tid til det - vi forventer ikke at have svarene i aften :) Fortsat god tirsdag! -

Simon og Emil

● Er det rigtigt forstået at du fungere

som hovedansvarlig for hele afvikling af festivalen, og at bestyrelsen i organisationen er

med på et mere overordnet plan? JA

● Hvordan har festivallen tidligere håndteret. Man

har gjort alt manuelt. Solgt billetter til koncerter via Musikhusets

billetsalg, hvorimod festival billetter er blevet håndteret manuelt. Det

har også indbefattet manuel håndtering og fordeling på workshops og

coachings.

adgangskontrol? Hvilket arbejde er forbundet med dette, både for den

driftsansvarlige og for de frivillige? Hvad er evt. din erfaring fra

andre festivaller? På andre festivaler er det ikke så komplekst, idet man der blot sælger

adgangsbilletter.

● Hvordan foregår oplæring af frivillige? Det gøres på dagen og ved den konkrete opgave

de skal løse. Forbruget af frivillige er meget begrænset. Max 50 personer.

Hvor meget tid har de til at lære deres arbejdsopgaver? Se svar herover.

● Hvilke fordele og ulemper ser du ved

den eksisterende løsning til håndtering af adgangskontrol, tilkøb af eksempelvis

bespisning osv.?

Jeg ser faktisk udelukkende fordele, idet systemet meget er at betragte

som et modulært system hvor vi kan bygge extra funktioner på løbende.

Det kunne ex. også være tilkøb af mad, bar etc.