aktiviteter Usability2
Udviklingen
af prototypen til testen
Udviklingen af prototypen til testen
Prototypen i vores tilfælde adskiller sig væsentligt
fra mere artefakt-prægede tilfælde, hvor man har en
"dims", som man kan se og røre ved. Vores idé
med U2-testen var at lave en prototype, der ville være så
tæt på det færdige spil som muligt, hvad angik
interaktionen med spillet og den kontekst som det skulle foregå
i, for bedst muligt at kunne afteste vores fokuspunkter. hvad angik
interaktionen med spillet og den kontekst som det skulle foregå
i. Derfor valgte vi at lade testen foregå over flere dage,
hvor spillet foregik via sms, præcist som det er tænkt
det "rigtige" spil skal gøre.
Vores prototype kan altså sammenfattes i de ting, der gjorde
det muligt at give spillerne oplevelsen af et spil. Prototypen bestod
således af en hjemmeside, spilfigurer, nogle scenarier og
spil idéer, regler, sms-koder og en sms-central til at afsende
og modtage sms med. Nedenfor gennemgåes forberedelserne af
de enkelte dele i prototypen.
Hjemmeside
En del af konceptet er jo som sagt at spillet har en hjemmeside,
hvor man bl.a. skal kunne: se sin egen figur, søge på
andre spillere, se highscoreliste og kommunikere med andre spillere
fx via chat. Vi overvejede at lave denne hjemmeside selv i ASP.
Fordelen ville være, at vi helt selv kunne bestemme indholdet
og designet af siden. Her er et tidligt udkast til en sådan
side:
Ulempen var dog, som det hurtigt gik op for os, at det ville tage
meget lang tid - det ville nærmest blive et designprojekt
i sig selv. Og da det var selve spillet og interaktionen med sms,
der havde vores fokus i denne test, syntes vi, det ville være
et forkert sats af resourcer. Istedet valgte vi at benytte os af
igroups.dk - en af de mange groupcare-tjenester på nettet.
Vi oprettede således en gruppe www.g13.igroups.dk (prøv
fx at logge ind med User: model Pwd: cosmo) på igroups. Her
havde vi mulighed for at oprette en profil til hver spiller, der
var en chat til rådighed, et besked-system, så spillerne
kunne skrive beskeder til hinanden, en login-forside hvor vi kunne
offentliggøre highscore.
Login-forsiden - forstør
Hjemmesiden efter login - forstør
Denne hjemmeside gav os egentlig den funktionalitet vi havde brug
for. Den gav os mulighed for at teste vores fokusområder omkring
interaktion mellem spillere, der ikke var fysisk sammen både
i forhold til det sociale aspekt og bytteaspektet.
Figurer
Vi havde som sagt valgt ikke at teste selve oprettelsen af figurene.
Vi lavede således nogle figurer som skulle forestille at have
været med i spillet et stykke tid. Vi respræsenterede
figurerne med en historik (en forhistorie), et billede og et netværk
(de personer som figuren allerede kendte).
Figur eksempel - forstør
oversigt over figurer
Skabelsen af figurene og skabelsen af scenarierne var en del af
den samme brainstorming proces - de to ting skulle jo gerne passe
sammen. Det var vigtigt, at der var noget kød på figurerne,
og at de var gode potentielle og ligeværdige med- og modspillere
indenfor scenariets rammer. Fordelen ved, at vi havde fastlagt figurerne
på forhånd, var også, at det gjorde det noget
nemmere at forberede et godt scenarie, der kunne indeholde de ting
vi gerne ville have testet. Hvis brugerne bare selv fuldstændig
kunne have lavet deres figurer (hvilket bestemt kunne have været
interessant i en anden sammenhæng) havde vi haft langt mindre
styring med scenariet. Problemet var, at vi gerne ville have at
brugerne skulle have et personligt forhold til figuren og føle
ejerskab og ansvar for den(jf. tamagochi-effekten), hvilket selvfølgelig
var lidt svært at tilgodese, hvis vi havde lavet alt på
forhånd. Dette problem løste vi ved at lade dem vælge
mellem de forskellige figurer - de havde rent faktisk et valg -
desuden skulle de lave et navn og vælge en alder til deres
figur. Denne løsning var langt fra optimal, men det var den
måde, vi mente, at vi trods alt kunne give brugerne en form
for medindflydelse på deres figur.
Inspirationen til figurerne hentede vi bl.a. i materialet fra workshoppen
på gymnasiet, U1-testen og generelt vores arbejde med scenarier
gennem hele forløbet.
Scenarier
Selve scenariet havde en meget central plads i prototypen. Hele
omdrejnings punktet i selve spillet var jo netop det scenarie, der
ville udfolde sig for spillerne. Det viste sig dog hurtigt også
at være en af de sværeste opgaver i prototypeudviklingen.
Vi havde det overordnede tema for scenariet på plads - nemlig
musik/medie miljøet. Samtidig havde vi også efterhånden
nogle ret veldefinerede figurer - det var jo nødvendigt,
eftersom vi skulle have nogle konkrete figurer at udlevere til brugerne.
Vores første idé var at lave en fuldstændig
træstruktur for scenariet, hvor hver forgrening repræsenterede
et valg for en af figurerne. Dette viste sig dog hurtigt at være
en dårlig idé af flere grunde. Det ville være
utroligt tidskrævende og uoverskueligt, og samtidig ville
der også være en hel masse spildt arbejde, idet at hvert
valg jo ville gøre at hele den fravalgte "gren"
kunne smides væk. Derudover ville det være meget sårbart
overfor uregelmæssigheder og ting vi ikke havde forudset.
Endelig ville en sådan model også være meget ufleksibel
og det ville være svært at inkorporere de idéer,
der ville dukke op undervejs.Vi arbejdede herefter med at skrive
scenariet som en slags drejebog, der beskrev det overordnede plot
og nogle underplots. Den endelige udformning blev, at vi lavede
en planche for hver dag med figurerne påskrevet.
forstør
Med post-its plottede vi nogle store events eller milepæle
ind som pejlemærker for hver dag. Der var fx en seddel udfor
torsdag, der angav, at her skulle et band have mulighed for en tv-optræden.
Derudover lavede vi en brainstorm over mulige events og ting som
man kunne få med samlekort, og dette samlede vi på en
anden planche. Idéen var så, at man havde de overordnede
milepæle at styre efter og så efterhånden på
detaljeniveau kunne dykke ned i event- og samlekortposen og stykke
scenariet sammen.
Under hele processen omkring scenarieudviklingen og også
udviklingen af figurerne havde vi meget glæde af den inspiration
vi havde med fra vores tidligere arbejde fx workshoppen på
gymnasiet, U1-testen og generelt vores arbejde med scenarier gennem
hele forløbet. For eksempel brugte vi under brainstorming
til events og samlekort direkte nogle af post-it'ne fra gymnasieworkshoppen
og førte over som events på vores planche.
Point og Regler
Ligesom ved scenarieudviklingen udviklede vi ikke et komplet point-
og regelsæt på forhånd. Vi lavede den overordnede
ramme for hvordan og for hvad, der skulle gives point. Belært
af U1-testen og workshoppen på gymnasiet var det vigtigt for
os at lave et simpelt og enkelt pointsystem. Rammen for pointgivning
var således følgende:
Point
Det skulle give point at svare rigtigt på quizspørgsmål,
træffe de rigtige valg for ens karakter, aktivere rigtigt
samlekort, tilføje en person til ens netværk og god
udnyttelse af netværk. Man skulle ikke kunne miste point.
Pointscoren var altså et udtryk for ens accumulative præstation
i spillet.
Stjernestatus
Udover point syntes vi at det var vigtigt at have et barometer for
ens umiddlebare berømmelse. Man skulle således kunne
få stjerner i stjernestatus, hvis man fx. havde optrådt
til et stort arrangement. Men samtidig skulle man også kunne
miste sin stjernestatus igen. Stjernestatus skulle altså være
et mål for figurens succes "lige nu".
Netværk
Udover highscore i point og stjernestatus skulle det også
fremgå, hvem der havde flest personer i sit netværk.
Dette ville altså være et udtryk for popularitet og
for ens sociale kompetence.
Sms-central
Det var vigtigt at være i stand til at sende og modtage en
stor del sms'er i løbet af test-forløbet. Det var
således udelukket at sende dem fra mobiltelefon, dette ville
også have været små-dyrt. Vi rettede derfor blikket
mod de mange internetbaserede sms-tjenester. Her havde vi mulighed
for hurtigt og nemt at sende mange sms'er og vi havde samtidig let
ved at føre en log, da vi bare kunne copy-paste beskederne
over i et dokument. Vi afprøvede en række af de sms-tjenester
der findes på nettet - mange af dem har nemlig op til flere
dages forsinkelse, hvilket ville være totalt uacceptabelt
for testen. Vi fandt frem til www.coolsms.dk, der havde nogle meget
fine leveringstider. Desuden var der en række features, der
ville lette arbejdet, herunder bl.a. en telefonbog og en sms-log.
Ved modtagelse af sms'er fra brugerne kunne vi ikke komme uden
om mobiltelefonen. I et rigtigt spil skulle man selvfølgelig
bare kunne besvare sms'erne direkte, hvilket vi ikke havde mulighed
for at simulere i denne test. Vi lod én af vores egne mobiltelefoner
være svartelefon, dvs. den telefon som brugerne ville sende
alle beskeder til i spillet.
Sms-koder (interaktions protokol)
Selve interaktionen med spillet var også en vigtig del i testen.
Omkring interaktionen i spillet lå en række overvejelser
både i forhold til de beskeder vi skulle sende ud og den type
respons vi skulle modtage fra spillerne. I forhold til beskederne
fra spillet til brugerne havde vi at gøre med to forskellige
slags kommunikation, dels de administrative beskeder (info og stats
om point og placering) og dels de deciderede rollespils beskeder
(fx "hey, dette er Agent Arne, jeg har et spændende...").
Det skulle være tydeligt for spilleren hvilke beskeder, der
var info om spillet og hvilke der var en del af selve spillet. Info-beskederne
skulle således være meget formelle og fx have overskriften
"Info" eller underskrives med "Admin". Selve
spilbeskederne skulle derimod være langt mere levende og friske,
men også med en tydelig afsender fx "hey, Agent Arne
her...".
I forhold til kommunikationen den anden vej fra spillerne til spillet
var det vigtigt, at det var entydigt, meningsfuldt og umiddelbart
klart hvordan man som bruger skulle svare. Samtidig skulle det gerne
være svar som skulle kunne forstås og behandles af en
server. Det bruger-interface, som man har at gøre med ved
sms er i princippet en kommandoprompt, hvilket er en temmelig begrænset
interaktionsform. Vi havde som sagt tidligere overvejet at lade
alt respons være i form af en unik kode (fx tag til fest <fes456773>
eller fx aktiver guitar <gui566234>), men for at kunne implementere
flere respons- og handlemuligheder lavede vi istedet nogle forvalgskommandoer,
som så skulle sammensættes med ens valg:
Ved tilføjelse af person til netværk skriv: Ven "navn"
Kæreste "navn"
Ved aktivering af samlekort skriv: Kort "kode"
Ved svar på quizspørgsmål skriv: Quizsvar "svar"
Ved valg af diverse skriv: Valg "svar"
Dette var naturligvis en meget vigtig information for brugerne.
Derfor lavede vi en lille infoguide til spillet med disse og andre
vigtige oplysninger.
Opsamling
Når vi kigger tilbage på forberedelsen af prototypen
er planlægning naturligvis utrolig vigtig. Men samtidig var
det vigtigt ikke at planlægge alt - for i bund og grund ville
det være umuligt for os at forudsige forløbet fuldstændigt.
Og en meget stringent planlægning ville gøre det svært
at lade os inspirerer af idéer og inputs under testen, det
ville være en hæmsko for at lære under processen,
hvis man hele tiden kigger efter noget man har planlagt og regner
med skal være der, og således overser det væsentlige
som rent faktisk dukker op. Det er selvfølgelig en balancegang
og i sidste ende nok meget et temperamentsspørgsmål.
Noget der også kom bag på os var, at der rent faktisk
var så mange valg, der skulle træffes i forbindelse
med forberedelsen af prototypen. Vi var lige pludselig tvunget til
at tænke alle kroge af konceptet igennem. Dette gjorde, at
vi rent faktisk blev meget mere klar over hvad vores produkt skulle
kunne, og at vi fik konkretiseret en masse ting som vi indtil da
havde skubbet lidt til side.
|