Betatestning - Solsystem Mikael Ågren, F03 Innehåll 1 Inledning 2 2 Frågorna 2 2.1 Är programmet konsekvent?................... 2 2.2 Behövs genvägar?......................... 2 2.3 Tillräcklig feedback?....................... 2 2.4 Felhantering?........................... 2 2.5 Ångra?............................... 2 2.6 Kontroll över systemet?..................... 3 2.7 Lättbegripligt?.......................... 3 2.8 Övrigt?.............................. 3 3 Resultatet 3 3.1 Sebastian, 19, arbetslös..................... 3 3.1.1 Är programmet konsekvent?............... 3 3.1.2 Behövs genvägar?..................... 3 3.1.3 Tillräcklig feedback?................... 3 3.1.4 Felhantering?....................... 3 3.1.5 Ångra?.......................... 4 3.1.6 Kontroll över systemet?................. 4 3.1.7 Lättbegripligt?...................... 4 3.1.8 Övrigt?.......................... 4 3.2 Jonas, 19, Teknisk Fysik, KTH................. 4 3.2.1 Är programmet konsekvent?............... 4 3.2.2 Behövs genvägar?..................... 4 3.2.3 Tillräcklig feedback?................... 5 3.2.4 Felhantering?....................... 5 3.2.5 Ångra?.......................... 5 3.2.6 Kontroll över systemet?................. 5 3.2.7 Lättbegripligt?...................... 5 3.2.8 Övrigt?.......................... 6 1
1 Inledning En betatestning gjordes då appleten låg i sista fasen av programmeringen. Två testpersoner ck i uppgift att självständigt testa appleten. De ck göra det i lugn och ro utan tidspress och vid sin egen dator. Båda personerna var vana programmerare och hade kunskaper i Java. Under eller efter testningen ck de i uppgift att besvara några frågor. Dessa frågor baserades till stor del på de regler man brukar kalla Eight Golden Rules of Interface Design. Jag valde att inte ge personerna några uppgifter, eftersom jag tyckte att personerna själva skulle få möjlighet att testa alla möjligheterna. Att innefatta alla möjliga funktioner i uppgifter såg jag inte som möjligt. Ändringar visas som fotnoter. 2 Frågorna Skriv ner svar på så många frågor du kan. Om det nns buggar, som ger ett felmeddelande, skriv ner felmeddelandet. 2.1 Är programmet konsekvent? Är utseendet konsekvent (färger, layout etc.)? Används samma terminologi (på knappar, etiketter etc.)? 2.2 Behövs genvägar? Är det något som är för komplicerat att utföra? Behövs det något snabbare sätt att göra något på? Hur kan det förenklas? 2.3 Tillräcklig feedback? Får du tydlig feedback för det du gör? Vet du då du har påbörjat/utfört en handlingssekvens (till exempel zoomning)? Om inte vilken typ av feedback hade du önskat i den situationen? 2.4 Felhantering? Hanteras fel på ett bra sätt? Får du tillräckliga meddelanden om när du gjort fel (behövs det sådana)? Kan programmet krascha? Finns det buggar? 2.5 Ångra? Du har gjort något dumt och önskar ångra detta. Tycker du att det nns tillräckliga möjligheter till detta? Vilka er möjligheter skulle du önska? 2
2.6 Kontroll över systemet? Tycker du att du har kontroll över systemet eller är du en passiv knapptryckare? Vad kan göras för att du skall känna att du har mer kontroll? 2.7 Lättbegripligt? Är det lätt att komma igång med programmet? Är det svårt att komma ihåg något? Bör det stå något i medföljande manual och skall något göras mer lättbegripligt? 2.8 Övrigt? Finns det något för övrigt som du tycker behöver förbättras? 3 Resultatet 3.1 Sebastian, 19, arbetslös Sebastian gjorde anteckningar. Dessa har, med hans tillåtelse, skrivits om. Detta skedde utan att hans åsikter modierats. Sebastian har fått granska omskrivningarna. 3.1.1 Är programmet konsekvent? Sebastian tycker att programmet är konsekvent. 3.1.2 Behövs genvägar? Sebastian tyckte inte att det behövdes några genvägar, men anmärkte dock att han hade vissa svårigheter med att förstå vad som hände och vad han skulle göra. 3.1.3 Tillräcklig feedback? Sebastian tyckte att det var en del otydligheter. Han önskade mer feedback 1. Han föreslog att muspekaren skulle kunna ändras mer 2. 3.1.4 Felhantering? Sebastian undrade om det gick att göra fel. Han ck inga felmeddelanden 3. Han blev fundersam rörande knappar, som blev gråa då man klickade på 1 Meddelanden skrivs ut kontinuerligt i Rymden och beskriver vad som händer 2 Eftersom appleten skulle vara Java 1.1-kompatibel, så kunde er pekare inte användas 3 Fler felmeddelanden lades till. Overow hanterades i högre grad. 3
dem 4. Han hade även funderingar rörande spela- och pausaknapparna, som saknade text 5. Dessutom fungerade appleten inte i webbläsaren Safari 6. 3.1.5 Ångra? Sebastian märkte inga ångrafunktioner. 3.1.6 Kontroll över systemet? Sebastian ville ha live feedback, d.v.s. han ville att ändringarna skulle ske i realtid. Han ville inte klicka mellan ikarna för att se förändringarna 7. Dessutom önskade han skjutreglage för att förenkla redigeringen av planetdata 8. 3.1.7 Lättbegripligt? Sebastian tyckte att det behövdes en manual, för annars var mycket obegripligt 9. 3.1.8 Övrigt? Sebastian hade inget övrigt att anmärka på. 3.2 Jonas, 19, Teknisk Fysik, KTH Anmärkning: Jonas har fått testa programmet vid ett tidigare tillfälle och påpekade då att det var svårt att komma igång med programmet. Därför infördes det Enkla och det Avancerade läget. 3.2.1 Är programmet konsekvent? Ja, i den senaste versionen är allting sammanhängande. Utseendet har genomgått en del städning, vilket behövdes. 3.2.2 Behövs genvägar? Nja. Jag tycker att det är lite onödigt att ha en knapp för play, och en för paus. Det hade väl räckt med en enda för båda sakerna (så fungerar ju play/paus i t.ex. en mediaspelare). Som det är nu så trycker jag hela tiden på fel knapp när jag ska pausa respektive starta simuleringen 10. 4 Färgen byttes till blå. Deras funktion gjordes mer användarvänlig. 5 Gjordes snyggare och lät dem baseras på Canvas istället för Button 6 Laddade ner JDK 1.1 och testkörde appleten i denna och såg till att alla funktioner vara Java 1.1-kompatibla. 7 Låter alla ändringar ske i realtid. Detta gäller då främst ändringar i planetdata. 8 Dessa kunde dessvärre inte införas, eftersom de skulle begränsa möjligheterna till förändringar (p.g.a. deras begränsade värdemängd). 9 Separat manual skrevs. 10 En knapp används numera både till Play och Paus 4
3.2.3 Tillräcklig feedback? Ja, det är bra att zoomfaktorer och liknande skrivs ut, dock skulle jag nna det önskvärt att detta skrevs i en statuslist längst ner i appleten 11. Ett problem med knappen Manuell zoomää är att man måste hitta texten som talar om hur man ska göra för att zoom ut, detta är nämligen inte självförklarande 12. 3.2.4 Felhantering? Jag har inte lyckas krascha appleten! Bra programmerat! Har inte sett till felmeddelanden, dock ingen nackdel (man blir ju överöst med sådana hela dagarna). 3.2.5 Ångra? Jag vet inte riktigt om det behövs, kanske en enkel funktion som tar bort det senaste gjorda. Dock är jag tveksam till om jag skulle använda en sådan funktion. Om man lägger till en planet, som man sedan vill ta bort så är det ju bara att göra det. Enda fördelen med en ångringsfunktion i ett fall som ovan är ju att man kan ha infört störningar i systemet, dessa kan då enkelt tas bort (så slipper man starta om simuleringen när man har hållit på ett par tusen år) 13. 3.2.6 Kontroll över systemet? I det enkla läget så känner jag att jag har full kontroll över allting. Dock så känns det avancerade läget just avancerat, man blir lite överväldigad av alla listor och kryssrutor som man kan använda. 3.2.7 Lättbegripligt? Se förra frågan. Dock är det inte så svårt om man sätter sig ner och lägger ner några minuter på att begripa hur det är tänkt. Det enkla läget är självförklarande, vilket det avancerade är om man har tålamod. Detta för mig över till den viktigaste punkten: DET MÅSTE FINNS EN MANUAL TILL APPLETEN 14, gärna både vid sidan av (html-l) och som en integrerad del. Av typen: högerklicka på en tom yta i varje ik och få upp ett fönster som beskriver vad man kan göra med alternativen i aktuell ik (och hur de hänger samman med andra ikar) 15. 11 Detta kunde dessvärre inte åstadkommas, eftersom era meddelanden ofta behöver skrivas ut parallellt. Detta kan inte åstadkommas med en normal statuslist 12 Nu zoomar man istället genom att dra pekaren upp och ner, med musknappen intryckt. 13 Införde möjligheten att spara sina ändringar temporärt. 14 Manual skrevs i formatet PDF. 15 En kort hjälptext dyker nu upp då man högerklickar. 5
3.2.8 Övrigt? Manual!!! Seg att ladda första gången (visserligen inte ditt fel). Beräkningsfunktionen känns en smula onödig i sin nuvarande form, bara en massa siror som svischar förbi i rasande fart. Det kanske inte skulle vara så dumt med en liten logg, med diverse data från simuleringen. Dessutom skulle man då kunna få med information rörande t.ex. medelhastighet under simuleringen, medelavstånd o.s.v. 16 16 För komplicerat att införa en logg utan att det blir alldeles för svårt att hantera. Föreslår istället pausknappen. 6