4.3 Pilotstudie
4.3.1 Korrigeringar efter pilotstudie
Under pilotstudien noterades ett antal svårigheter och oklarheter. Dessa kan vara potentiella felkällor och bör därför korrigeras inför den riktiga studien. De svårigheter och oklarheter som uppkom var att testpersonerna hade för lätt för att lösa uppgifterna med endast sin syn, att instruktionerna för testerna var något otydliga vilket ledde till flera mindre missuppfattningar, formulärfrågorna var något otydliga och att navigeringsmenyn var för lätt att förutse då menyerna för Cars, Boats och Planes hade elementen i samma ordning (samma hierarki). Utöver detta beslutades att en lösning för att automatiskt tilldela webbapplikation A respektive B till testpersoner skulle vara användbart inför den riktiga studien.
Genom att förändra det filter som används för Glaucoma-simuleringen är det möjligt att påverka intensiteten av simuleringen. För att simulera en gravare synnedsättning minskades området där filtret är helt genomskinligt (i mitten av skärmen) och området med nedsatt syn gjordes större. Det svg-filter som används för att simulera försämrad synskärpa förändrades också för att göra text svårare att läsa.
style.css .glaucoma{
background-image: -webkit-radial-gradient(circle, transparent 10%, black 55%);
}
visual-impairment-simulator.php
<svg width="0" height="0"
xmlns="http://www.w3.org/2000/svg"xmlns:xlink="http://www.w3.org/1999/xlink">
<filter id="blur">
<feGaussianBlur in="SourceGraphic" stdDeviation="3" />
</filter>
</svg>
Figur 21 Korrigeringar av synnedsättningssimulering
9. Förändrade värden är fetmarkerade. Figuren kan jämföras med Figur 13 och 14 som innehåller deurpsrungliga värdena.
Testpersonerna i pilotstudien tenderade att glömma att tidtagningen började när knappen
‖Start task‖ trycktes på, kanske eftersom uppgiftsinstruktionen visades i det övre vänstra hörnet och således inte behövde läsas och kommas ihåg från instruktionens startskärm. Hur detta skall lösas är inte helt uppenbart. En eventuell lösning hade kunnat vara att inte visa instruktionen i det övre vänstra hörnet under tiden en uppgift löses men detta riskerar att vara ännu en felkälla eftersom testpersoner kan komma att glömma instruktionerna efter att uppgiften påbörjats. Därmed fyller instruktionen i det övre vänstra hörnet en viktig funktion genom att att agera minnesstöd om det skulle behövas. Det hade också varit möjligt att hindra testpersonerna att starta uppgiften före x antal sekunder gått genom att exempelvis inaktivera ‖Start task‖-knappen ett x sekunder. Detta riskerar att irritera testpersoner som läser snabbare än tiden x. Den bäst lämpade lösningen bedöms därför vara att göra det så tydligt som möjligt när tidtagningen börjar dels i instruktionen som visas inför testet samt i de instruktioner som visas inför varje ny uppgift.
Om instruktionerna för experimentet är för tydliga med experimentets syfte (att undersöka om och i så fall hur ljud i menyer kan användas som stöd för personer med synnedsättning) finns det en risk att utfallet påverkas. Om instruktionerna är för vaga finns en risk att testpersonerna inte förstår syftet med ljuden och utfallet påverkas åt andra hållet. I en riktig implementation (för en verklig hemsida, inte som del av ett experiment) bedöms det som troligt att användaren är medveten om ljudens funktion vid besök av sidan. En lösning på detta kan vara att låta testpersoner göra testet två gånger där de den första gången inte får veta syftet med ljuden. Inför den andra omgången informeras testpersonerna om hur ljuden kan användas för att underlätta navigering. Denna lösning bedöms inte som lämplig för detta experiment men en modifierad version kan användas. Istället för att testpersonerna får göra experimentet två gånger blir de informerade om ljudens syfte efter att halva experimentet genomförts10 (fem av tio uppgifter). Ett exempel på hur detta ser ut under experimentets gång kan ses i Figur 22.
9 https://github.com/c14jonfr/Examensarbete/commit/ae7a00c
Figur 22 Förtydligande av ljudets syfte i experimentet.
Testpersonerna i pilotundersökningen fick i formuläret i slutet av experimentet frågan ‖How much effort did it take you to navigate with the menu and solve the tasks?‖. En av testpersonerna ställde då frågor gällande vilken typ av ‖effort‖ som efterfrågades. Med
‖effort‖ menades en svårighet, alltså hur svårt (eller lätt) det var för testpersonen att genomföra experimentet. För att förtydliga vad som menas byttes frågan ut mot
‖Did you find it difficult to use the navigation menu?‖11. För webbapplikation A fanns också en fråga gällande irritation på grund av ljudet, ‖Did you find the audio annoying?‖. Med hypotesen att ljud kan vara irriterande men fortfarande hjälpsamma ändrades denna fråga till ‖Did you find the audio distracting?‖ eftersom frågan kunde upplevas som något tvetydig.
Ljud kan upplevas irriterande av ett flertal olika anledningar varav i vissa fall ljuden trots detta kan vara hjälpsamma. Distraherande ljud bedömdes inte ha samma tvetydighet.
Testpersonerna i pilotstudien hade inga större problem att navigera endast med hjälp av det grafiska gränssnittet. Detta gjorde att den testperson som använde sig av webbapplikationen med ljud inte förstod eller tog nytta av ljuden. Detta korrigeras dels genom att simuleringen förändrades (detta har beskrivits tidigare i rapporten) men kan också korrigeras genom att förändra ordningen på de olika menyelementen12. Ursprungligen användes ordningen Cars, Boats, Planes med undermenyerna Company A, Company B, Company C med undermenyerna Blue, Red, Green. Huvudkategorierna (Cars, Boats, Planes) återkommer endast en gång i menyerna och läts därför bestå i den ordning som urprungligen använts.
Eftersom earcons måste läras in lämnas även hela Cars-menyn i sin ursprungliga ordning (Cars -> (Company) A, B, C -> Blue, Red, Green). Cars är den meny som finns längst åt vänster och är också den meny som används för den första uppgiften (‖Find the green car by company B and click the ―Buy‖-button‖). För Boats och Planes förändrades ordningen. För Boats används ordningen Boats -> (Company) B, C, A -> Green, Red, Blue och för Planes används ordningen Planes -> (Company) C, A, B -> Red, Green, Blue. Ordningen för färger läts vara samma för samtliga företag (Company) under en huvudkategori. Att använda helt unika ordningar för samtliga undermenyer bedömdes som för förvirrande.
11 https://github.com/c14jonfr/Examensarbete/commit/b607c00
Efter vidare testning och diskussioner bedömdes användande av Company A, B, C som olämpligt, eftersom dessa kan anses ha en ‖inneboende‖ ordning. På grund av detta kunde d upplevas som förvirrande när ordningen förändrades. Därför byttes Company A ut mot Bob‘s, Wow‘s och Pop‘s (A -> Bob‘s, B -> Wow‘s, C -> Pop‘s). Dessa företagsnamn bedömdes inte ha samma ge upphov till samma förväntade ordning och var därför mer lämpade för applikationen.
I pilotundersökningen deltog endast två personer och det var därför enkelt att tilldela dem webbapplikation A (med ljud) respektive webbapplikation B (utan ljud). I den riktiga undersökningen kommer ett större antal personer att delta och det kommer då inte vara lämpligt att tilldelningen sker manuellt. Förslagsvis skall tilldelningen ske med hjälp av en länk som omdirigerar användaren till webbapplikation A eller B. Denna tilldelning kan baseras på antalet inkomna svar, om ett jämnt antal svar (0, 2, 4, 6 o.s.v.) skickats in dirigeras användaren till webbapplikation A och annars till webbapplikation B13. Detta bör göra att lika många personer tilldelas webbapplikation A respektive B vilket är fördelaktigt när analys skall göra på insamlad data. En nackdel med denna metod är att dirigeringen baseras på antalet svar när testpersonen påbörjar experimentet. Om ett stort antal personer påbörjar experimentet samtidigt kommer samtliga av dessa personer att tilldelas samma webbapplikation vilket kan leda till att mycket data samlas in för en av webbapplikationerna och väldigt lite data samlas in för den andra webbapplikationen. Risken för att detta inträffas bedöms som relativt liten då experimenten kommer att göras under en till två veckor.
För att implementera detta skapades en ny fil start.php. Denna fils uppgift är endast att läsa filen där insamlad data finns och beroende på om antalet svar i filen är jämnt eller udda tilldela webbapplikation A eller B. För att detta skall vara möjligt ändrades också webbapplikationernas Thanks.php-fil där data skrivs till en fil. I pilotundersökningen skrev webbapplikation A respektive B till olika filer (dataA.json respektive dataB.json). Detta ändrades så att båda webbapplikationerna skriver till filen data.json samt att att nytt värde
‖application‖ innehållande A eller B skrivs med i datan som skrivs till filen. Hur den automatiska dirigeringen implementeras kan ses i figur 23.
<?php
Figur 23 Implementation av automatisk tilldelning av webbapplikation.
Tidigt under studiens gång hände det som nämnts tidigare, att flera personer gjorde experimentet samtidigt och således blev tilldelade samma version vilket gjorde att det skapades en viss obalans i den insamlade datan. Två testpersoner gjorde experimentet samtidigt med version B av webbapplikationen. När dessa personer skickat in sin data fanns alltså ett ojämnt antal svar (antal A: n, antal B: n+1) vilket gjorde att även nästa person skulle tilldelas webbapplikation B. När detta upptäcktes beslutades att göra en mindre förändning i start.php-skriptet som istället tilldelade de olike versionerna beroende på hur många svar från webbapplikation A respektive B som fanns i den insamlade datan. Detta jämnar ut antalet svar från de olika webbapplikationerna (förutsatt att tillräckligt många svar samlas in för att utjämningen ska kunna genomföras). Hur detta implementerats se i if($array[$x]["application"] == "A") $A++;
if($array[$x]["application"] == "B") $B++;
}
Figur 24 Korrigerad implementation av automatisk tilldelning av
webbapplikation. Tilldelningen baseras nu på antalet inkomna svar frånwebbapplikation A respektive B.