Ozlab-systemet
av John Sören Pettersson (2010, uppdaterad 2013, 2019)
Wizard of Oz-tekniken vid experiment innebär att användaren konfronteras med en layout och en funktionalitet som är ’fullständig’ medan funktionaliteten egentligen bygger på att försöksledaren direkt styr över output. Försöksledaren styr alltså vad som kommer upp på försökspersonens bildskärm. Försökspersonen är inte medveten om att interaktionen sker med en människa. Detta gör det möjligt att testa lämpligheten av olika tänkbara datorresponser utan att behöva programmera före användartest.
Ozlab är ett verktyg för Oz-experimenterande med multimediala gränssnitt, ursprungligen för självständiga program som körs på vanliga persondatorer men tekniken passar förstås för utvärdering av all interaktivitet, på webb ner till grafiska gränssnitt för mobiltelefoner, även om det för enkla navigationsgränssnitt kan vara lika lätt att lägga in riktiga länkar mellan skärmbilder som att simulera med hjälp av wizard.
Det webbaserade Ozlab-systemet (2013-)
Det tidigare Ozlab-systemet var baserat på Macromedia Director, vilket programmerades av Joe Siponen (nu på IT-avdelningen i Kristinehamns kommun). Ett utvecklingsarbete påbörjades 2011 för att befria Ozlab från sitt beroende av Director-filer. Under sommaren 2013 var en första version av ett webbaserat Ozlab på plats. Prof. John Sören Pettersson hanterar processen och dåvarande labingenjör Malin Wik var ansvarig för felsökning samt för utveckling av särskilda krav för nya funktioner. Studenter används i vissa delar av den fortsatta utvecklingen medan den mer avancerade programmeringen lades ut på Motillo.
Ett webbaserat Ozlab gör det möjligt att experimentera interaktivt på smartphones likaväl som på laptops och stationära datorer. I skissen nedan kan testledaren se typ av användarinput i vänstra fönstret medan smartphonen i mitten visar vad försökspersonen ser på sin display medan försöksledaren kan välja andra skärmbilder till höger. Input från mobiltelefon kan också bestå av GPS-data, närhet, ljusförhållanden, läge och rörelse samt ljud.
En tidig presentation av arbetet för ett webbbaserat Ozlab finns i filen Designing through testing (se länk i kolumn).
Wizard of Oz-experiement
Wizard of Oz-tekniken vid experiment innebär alltså att användaren konfronteras med en layout och en funktionalitet som är ’fullständig’ medan funktionaliteten egentligen bygger på att försöksledaren direkt styr över output. Försöksledaren styr vad som kommer upp på försökspersonens bildskärm. Försökspersonen är inte medveten om att interaktionen sker med en människa (se bild; obs avskärmningen! Skulle kunna vara en vägg). Detta gör det möjligt att testa lämpligheten av olika tänkbara datorresponser utan att programmering och testkörning behöver ske före testen med de tilltänka användarna.
Vid språklig MDI (människa–dator-interaktion) kan dessa test utföras enkelt. Vad testpersonen matar in på tangentbordet syns samtidigt på försöksledarens skärm. Försöksledaren kan därmed bestämma vilken respons systemet ska ge. Försöksledaren skriver själv in detta svar, som genast syns på testpersonens skärm. Testpersonen får intrycket att det är datorns svar. Även vid forskning om taligenkänning och utveckling av röststyrda system har detta använts.
Wizard of Oz-metoden kan göra det möjligt att fortsätta ett test även om försökspersonen inte klarar av en viss sak; försöksledaren kan då negligera ett olyckligt utfört input eller låta det falska systemet ta initiativet till vägledning. Explorativa studier kan göras där testledaren tar intryck av testanvändarens problem eller sätt att göra input -- testledaren tillåter sig att utevckla responsmöster som passar användarna.
Interaktivitet i test eller i diskussion
Ozlab-gruppen har funnit att både dolda testledare ("wizards") och synliga kan fungera beroende på vilket slags användarmedverkan det är frågan om. Man kan köra tester där testanvändarna är medvetna om att testledaren övervakar testet. Ibland är det inte frågan om ett regelrätt test utan Ozlabsystemet används i diskussionen mellan interaktionsdesignern och en ämnesexpert eller programmerare. Vi har utvecklar sedan 2016 co-design på distans - Ozlab tillsammans med konferenssystem som Skype och Zoom (eller helt enkelt en telefon) fungerar mycket bättre än att bara använda konferenssystem trots sådana systems skärmdelningsmöjligheter.
Motivering för ett grafiskt (multimedialt) simuleringslaboratorium
Utvecklingen av Ozlabsystemet inriktades ursprungligen på att skapa en testmiljö där wizarden skulle kunna vara en oerfaren gränssnittsdesigner, en ’naiv’ designer (men gärna ’innehålls’-proffs). För att konkretisera tankegångarna utgick vi från barn och behov av multimedialt pedagogiskt material, vilket innebär att de första användarna av Ozlab (inte användarna av de produktidéer som testas i Ozlab) utgjordes av pedagoger, d.v.s. personer som generellt sett saknar programmeringserfarenhet. Förutom problem som hade att göra med att Ozlabanvändingen var beroende av Directoranvänding, såg vi också behovet av att beskriva hur en naiv programdesigner kan gå vidare genom att använda en interaktionsdesigner eller multimediautvecklare till att formulera en kravspecifikation för en eventuell implementering av den egenhändigt uttestade programidén (Molin & Pettersson, 2003). Nedan följer dock några reflektioner om Ozlabtekniken ställd i kontrast mot annan typ av prototyping.
För att utvärdera interaktionsautomatiken i program för yngre barn behövs fullt fungerande prototyper. Det går inte att utvärdera idéerna genom att visa ett litet barn en skiss av en skärmlayout och förklara vad som händer om man klickar här eller släpar en ikon dit. Barnens abstraktionsförmåga räcker inte till för detta. Av samma anledning bör prototypen inte vara för buggig. Det går inte att säga till en 4-åring att "här skulle en ruta med … synas och hade du klickat på … så skulle … hända; nu måste vi trycka på ctrl+alt+… för att hamna där; ska vi göra det? är det där du vill hamna?". Dels förstår inte ett litet barn omfattande villkor, dels kan vi inte förutsätta att barnet har en utvecklad intention över huvud taget.
Det är alltså svårt att jobba med enkla prototyper; istället måste vi ha fullskalemodeller (vilket inte hindrar en modulär uppbyggnad där alla moduler inte finns med från början). Detta kontrasterar mot den utveckling bland MDI-experter (experter på människa–dator-interaktion) där enkla skisser och post-it-lappar används i den första konfrontationen med användarna (se exv. Klee, 2000; även för senare stadier i utvecklingen har enkla prototyper visat sig duga, enligt Virzi & al., 1996).
Uppenbarligen är en approach med skisser inte direkt tillämplig när yngre barns förmåga att förstå den grafiska interaktionen ska undersökas. Själva interaktionsmomentet uteblir. Däremot skulle barn kunna delta i figurutformning och scenutveckling när det gäller ett redan färdigutvecklat program som tillåter tillägg av bildmaterial, text, ljud o. dyl. En väsentlig del av MDI-experternas reaktion mot elaborerade användarstudier med fungerande prototyper i testlab är emellertid att en enklare prototyp medger användarmedverkan från ett väldigt tidigt stadium i utvecklingen av ett nytt system. Alternativet, att låta användare enbart testköra ’riktiga’ prototyper, tillåter systemutvecklarna att bedriva sin verksamhet avskilt från användarna under en inledande fas då kanske många viktiga vägval görs. Tidig användarmedverkan är alltså av godo.
I de fall där själva interaktionsmomentet är viktigt måste man emellertid konstatera att det är dyrt att göra en fullständig produkt bara för att testa om den fungerar. Visserligen finns det redan datorprogram för prototyputveckling, vilka kan användas för att framställa fungerande prototyper och för att producera färdiga produkter. De kräver ibland en hel del programmering eller åtminstone att allt måste bestämmas i förväg. Syftet med Ozlab-projektet är tvärt om att undersöka ramarna för en utvecklingsmiljö där förprogrammering inte är nödvändig.