Vid inloggning som elev kommer man till sin profilsida. Fr˚an sidomenyn kan man sedan n˚a olika ¨amnen/¨ovningar via rubriken ’ ¨Amnen’. P˚a profilsidan finns information om anv¨andaren; elevens namn, vilka ¨amnen man ¨ar tillagd i, vilka uppgifter eleven har gjort och kontots aktivitet precis som i vyn f¨or l¨araren.
9 Anv¨andargr¨anssnitt
Figur 5: Elevens profil
9.4
Flervalsfr ˚aga
N¨ar man som elev vill g¨ora en ¨ovning s˚a v¨aljer man f¨orst ¨amne och sedan ¨ovning under ¨amnet. D˚a kommer man till f¨orsta fr˚agan i ¨ovningen som kan se ut som figur 5. I bilden visas en flervalsfr˚aga d¨ar vi h¨ogst upp ser sj¨alva fr˚agan och nedanf¨or finns alternativen. H¨ogst upp i h¨ogra h¨ornet ser vi hur m˚anga fr˚agor vi har gjort och hur m˚anga som finns i ¨ovningen (i detta fall ¨ar vi p˚a fr˚aga 2 av 3). Nedanf¨or fr˚agan ser vi [H]:et som vid klick ¨oppnar en ruta under d¨ar det kan finnas tips om hur man ska t¨anka n¨ar man l¨oser fr˚agan. Det finns ¨aven st¨od f¨or att l¨agga in bilder i en flervalsfr˚aga.
9 Anv¨andargr¨anssnitt
Figur 6: En flervalsfr˚aga
9.5
Drag-and-drop fr ˚aga
Detta ¨ar en annan typ av fr˚aga som f¨orekommer i v˚ar applikation. Liknande som i fler- valsfr˚agor s˚a ligger fr˚agan h¨ogst upp, nedanf¨or finns [H]:et (h¨ar inte i ¨oppnad form) och l¨angst ner alternativen. I denna ¨ovning ska man dra de gr˚aa rutorna fr˚an v¨anster till r¨att ruta till h¨oger. Om rutorna h¨or ihop s˚a blir det gr˚aa gr¨ont (p˚a liknande s¨att som i fler- valsfr˚agor). Om man parar ihop fel rutor s˚a ˚aker den v¨anstra rutan tillbaka till d¨ar den startade.
10 Utv¨arderingsresultat
Figur 7: En drag-and-drop fr˚aga
10
Utv ¨arderingsresultat
Vi har utv¨arderat v˚art arbete p˚a tv˚a olika s¨att; genom att sj¨alva resonera kring om de krav vi haft ¨ar uppfyllda i slutprodukten med avseende p˚a design och funktionalitet samt genom att utf¨ora anv¨andartester. Vi har dessutom utv¨arderat hur v¨al kriterierna f¨or PWA ¨ar uppfyllda. Samtliga resultat diskuteras och utv¨arderas sedan i avsnitt 11.2.
10.1
Design
N¨ar det kommer till designen s˚a har vi jobbat utifr˚an 8 av 15 riktlinjer som Lorna McK- night tog fram i sin forskningsrapport [14] och som vi n¨amner i detalj i avsnitt 5.3. V¨art att n¨amna ¨ar att alla designval ¨ar baserade p˚a v˚ara egna tolkningar av riktlinjerna. N¨ar vi har valt f¨arger, textstorlek, typsnitt och liknande har resultatet allts˚a till viss del p˚averkats av v˚ara egna slutsatser om McKnights riktlinjer.
Vi tycker att vi har lyckats f¨olja m˚anga av riktlinjerna n¨ar vi utvecklat webbapplika- tionens design och viss funktionalitet. Vi har skapat en minimalistisk design i en ljus f¨argskala och skalat bort allt som inte fyller n˚agon funktion. Allt som finns i applikatio- nen som inte har med att skapa/genomf¨ora ¨ovningar har ist¨allet n˚agot syfte att informera eller f¨ortydliga f¨or anv¨andaren. Allt detta innefattas av den f¨orsta riktlinjen vi skrev om,
10 Utv¨arderingsresultat
i avsnitt 6.1.
Vi anser oss ¨aven v¨al uppfyllt den andra riktlinjen, som vi skriver om i avsnitt 6.2, vil- ken handlar om uppmuntring. Den har implementerats i ¨ovningarna s˚a att det visas en uppmuntrande symbol efter varje avklarad fr˚aga, samt genom visuell feedback i form gr¨on f¨arg vid r¨att svar p˚a en fr˚aga. Vi har aktivt undvikit att ge negativ feedback ge- nomg˚aende vad g¨aller v˚ar design, till exempel genom att inte presentera hur m˚anga fel man hade efter att en ¨ovning ¨ar klar. Om man p˚a en flervalsfr˚aga svarar fel alterna- tiv s˚a tonas det felaktiga alternativet ut och blir mindre tydligt, och man kan svara p˚a fr˚agan igen. Ett alternativ d¨ar designen kan upplevas mer som kritik skulle kunna vara att fel svarsalternativ ist¨allet blir r¨ott, att ett felmeddelande visas eller att man inte f˚ar m¨ojligheten att svara r¨att p˚a fr˚agan om man v¨aljer fel alternativ f¨orsta g˚angen.
Riktlinjen om att ha ett metodiskt uppl¨agg som vi beskriver i avsnitt 6.3 anser vi att vi uppfyllt d˚a vi valt att placera olika delar av inneh˚allet p˚a platser d¨ar den typen av funktionalitet ofta finns. Exempelvis leder ett knapptryck p˚a loggan som ligger h¨ogst upp p˚a sidan tillbaka till startsidan, och en sidomeny ¨oppnas vid klick p˚a en ikon h¨ogst upp till v¨anster.
Riktlinjen vi skrivit om i avsnitt 6.4 anser vi ocks˚a har implementerats som avsett, att vi avgr¨ansat information, genom att anv¨anda ytor med en annan f¨arg ¨an bakgrunden och v¨alja storlek p˚a text beroende p˚a var vi vill att fokus ska hamna. Ett annat exempel p˚a hur vi f¨oljt denna riktlinje ¨ar att text med liten inneb¨ord, som till exempel text i webbap- plikationens footer, har litet typsnitt och dov f¨arg. Denna riktlinje har vi fokuserat extra mycket p˚a i skapandet av rubriker, viktiga knappar och fr˚agor.
I avsnitt 6.5 beskrivs behovet av tydlighet vilket ¨ar en riktlinje vi anser att vi f¨oljt v¨al genom att visa vilken fr˚aga i en ¨ovning man befinner sig p˚a och ha rubriker f¨or de sidor man befinner sig p˚a. F¨or varje ¨ovning st˚ar det en r¨aknare, som visar vilken fr˚aga av det totala antalet fr˚agor som man befinner sig p˚a.
Riktlinjen ang˚aende korta och tydliga instruktioner som n¨amns i 6.6 har vi f¨ors¨okt ha i ˚atanke fr¨amst vad g¨aller att skapa ¨amnen och fr˚agor som l¨arare.
I avsnitt 6.7 beskrivs riktlinjen som behandlar elevers m¨ojlighet att ta pauser. Den rikt- linjen har inte implementerats.
Den sista riktlinjen vi f¨oljde som beskriv i avsnitt 6.8 handlar om att minimera ¨overraskningar, och har implementerats genom att h˚alla designen enhetlig, att h˚alla oss till vissa f¨arger och jobbat med samma metodiska uppl¨agg i hela applikationen. Bland annat placering av fr˚aga och svar, oberoende av fr˚agetyp, har gjorts enhetligt.
10 Utv¨arderingsresultat
10.2
Funktionalitet
Nedan har vi g˚att igenom listan fr˚an avsnitt 8.1 och utv¨arderat varje punkt hur v¨al den ¨ar uppfylld. Den funktionalitet som efterstr¨avats var:
10.2.1 En vy f ¨or eleven och en f ¨or l ¨araren
Tv˚a vyer efter inloggningen har implementerats. Elev-vyn och l¨arar-vyn har olika funk- tionalitet och ¨ar d¨arf¨or inte en trivial l¨osning. Vi anser d¨arf¨or att denna punkt ¨ar uppfylld. Hur som helst s˚a ¨ar implementationen inte s¨arskilt avancerad i nul¨aget och funktiona- liteten f¨or b˚ada vyer har stort utrymme f¨or f¨orb¨attringar f¨or att fungera v¨al med den framtida databasen.
10.2.2 Profilsida f ¨or varje elevkonto
Detta har implementerats s˚a att elever p˚a sin profil kan se vilka ¨amnen de ¨ar anslutna till. Den h¨ar punkten skulle beh¨ovts utvecklas ytterligare f¨or att applikationen skulle komma till sin fulla r¨att vad g¨aller funktionalitet som ¨ar till st¨od f¨or m˚algruppen. Till exempel har vi skrivit om i avsnitt 5.3 att det vore f¨ordelaktigt om elever kan pausa mitt i en ¨ovning och sedan forts¨atta ¨ovningen p˚a samma fr˚aga vid ett annat tillf¨alle. Det hade kunnat implementeras genom att elever via ¨amnen p˚a sin profilsida kan g˚a in i de olika ¨ovningarna och att ¨ovningarnas framsteg lagrats f¨or att visas d¨ar.
10.2.3 Statistik f ¨or utf ¨orda uppgifter p ˚a elevens profil
Den h¨ar funktionaliteten har inte implementerats eftersom det inte finns n˚agon funge- rande koppling till databasen d¨ar data ¨over utf¨orda uppgifter ska sparas. Vi har dock skapat en bas f¨or hur statistikfunktionaliteten ska fungera men som sagt inte kunnat koppla den till databasen d˚a det inte finns n˚agot f¨ardigt API. I webbapplikationen kan man nu se hur vyn ¨over statistiken ska se ut men det ligger ingen funktionalitet d¨ar ¨annu. Hur det ser ut visas i figur 5.
10.2.4 Olika typer av fr ˚agor som kan skapas fr ˚an l ¨ararvyn
Vi har implementerat denna funktionalitet genom att applikationen st¨odjer tv˚a olika sorters fr˚agor: flervalsfr˚agor och drag-and-drop-fr˚agor. Ytterligare en typ som ska im-
10 Utv¨arderingsresultat
plementeras senare ¨ar uppgifter best˚aende av videos med fr˚agor i samt textsvarsfr˚agor, vilket allts˚a inte st¨ods i nul¨aget. Syftet med att ha olika typer av fr˚agor ¨ar att m¨ojligg¨ora f¨or l¨arare att kunna g¨ora varierande ¨ovningar ˚at sina elever. Detta ser vi som ett s¨att att g¨ora applikationen mer individanpassad. Vi anser att syftet f¨or den h¨ar punkten ¨ar uppfyllt p˚a ett meningsfullt s¨att genom v˚ar implementation. ¨Annu fler typer av fr˚agor skulle s˚aklart bidra till ¨annu st¨orre m¨ojlighet f¨or variation. S˚a f¨or den h¨ar punkten finns m¨ojlighet att f¨orb¨attra s˚a l¨ange det finns fler fr˚agetyper att implementera. Vilka typer av fr˚agor som skulle kunna finnas begr¨ansas bara av fantasin och st¨od i API f¨or databasen att kunna lagra den fr˚agetypen.
10.2.5 Inloggningsfunktion f ¨or elever och l ¨arare
Vi har inte hunnit implementera en inloggningsfunktion ut¨over en trivial s˚adan som en- dast best˚ar av en knapp som man trycker p˚a f¨or att simulera en inloggning. Vad vi efter- str¨avade var en inloggningsfunktion d¨ar anv¨andaren kan logga in med Google-login. Vi b¨orjade arbeta med detta men efter att ha st¨ott p˚a mycket problem valde vi att g˚a vidare med en enklare l¨osning. Den enklare l¨osningen vi anv¨ander i nul¨aget ger inte m¨ojlighet att spara data kopplat till ett elevkonto. Vi har allts˚a inte uppfyllt n˚agon meningsfull eller anv¨andbar inloggningsfunktion och d¨arf¨or inte uppfyllt syftet f¨or funktionaliteten f¨or den h¨ar punkten.
10.2.6 H ¨amta data fr ˚an en databas via ett API
Detta har inte implementerats eftersom API som skulle utvecklas av intressenten in- te har levererats i tid. V˚ar slutgiltiga produkt har ist¨allet implementerat en simulering av att h¨amta data fr˚an databasen genom att anv¨anda filer av f¨ardiga objekt med data i samma format som den skulle lagrats i databasen. Denna simulering anv¨ander liknande funktionalitet som f¨or att h¨amta data ur en databas, redo att f¨ardigst¨allas helt n¨ar API ¨ar klart.