En interaktiv webbapplikation för elever med inlärningsproblematik

Sj ¨alvst ¨andigt arbete i informationsteknologi

14 juni 2018

En interaktiv webbapplikation f ¨or

elever med inl ¨arningsproblematik

Caroline Algvere

Victoria Bull

Matilda Trodin

Vanja Wallner

Institutionen f ¨or informationsteknologi Bes ¨oksadress: ITC, Polacksbacken L ¨agerhyddsv ¨agen 2 Postadress: Box 337 751 05 Uppsala Hemsida: http:/www.it.uu.se Abstract

En interaktiv webbapplikation f ¨

or elever med

inl ¨arningsproblematik

Caroline Algvere Victoria Bull Matilda Trodin Vanja Wallner

Almost one out of five Swedish students finish 9th grade without the op-tion to continue their educaop-tion due to not passing compulsory courses. Unfortunately, students with ADHD or autism often fall into this cate-gory. The opportunity to get extra support for the students who are at risk of not passing their courses is guaranteed by law, but the schools often fail to fulfill these rights. Todays education is seldom adjusted to meet the needs of the individual. Our ambition was to create a web ap-plication to be used as a mean of supporting teachers in their teaching and students in their learning. The functionality of the application is divided into two different views; the one of the teachers and the one of the students. The teachers can create assignments with different types of questions for their students. Some examples are multiple choice ques-tions, drag-and-drop quesques-tions, questions that require a written answer and questions based on images. The teachers can in that way vary their assignments depending on what suits the student. They can also pro-vide leads on how to solve a question which the students can activate if they want the question explained more thoroughly step-by-step. The resulting product has a lot of potential for development and needs to be connected to a data base before it can be used in a big scale.

Handledare: Mats Daniels, Anne Peters och Bj¨orn Victor Examinator: Bj¨orn Victor

Sammanfattning

N¨astan var femte elev i Sverige g˚ar idag ut h¨ogstadiet utan gymnasiebeh¨orighet. Elever med diagnoser som ADHD och autism faller tyv¨arr ofta inom den kategorin. Skollagen ska garantera att elever som riskerar att inte uppn˚a m˚alen kan f˚a det st¨od de beh¨over, men ofta brister skolorna i att uppfylla detta. Dagens undervisning ¨ar s¨allan anpassad till individens behov. V˚ar ambition var att skapa en webbapplikation f¨or att st¨odja l¨arare i sin undervisning och elever i sitt l¨arande. Den funktionalitet som finns kan delas upp i tv˚a olika vyer, en f¨or l¨arare och en f¨or elever. L¨arare kan logga in p˚a hemsidan och skapa olika sorters uppgifter f¨or sina elever. N˚agra exempel ¨ar flervalsfr˚agor, drag-and-drop-fr˚agor, fr˚agor som kr¨aver textsvar och fr˚agor baserade p˚a bilder. L¨arare kan d¨armed vari-era sina uppgifter beroende p˚a vad som passar eleven. De kan ¨aven l¨agga in f¨orklaringar som eleverna kan aktivera f¨or att stegvis f˚a hj¨alp att f¨orst˚a en fr˚aga. Den resulterande webbapplikationen har stor utvecklingspotential och beh¨over kopplas till en databas f¨or att kunna anv¨andas i stor skala.

Inneh ˚all

1 Introduktion 2

2 Bakgrund 3

2.1 ADHD . . . 3

2.2 Autism . . . 3

2.3 ADHD och autism i skolan . . . 4

2.4 Anpassad undervisning och s¨arskilt st¨od . . . 4

2.5 Inkluderande design . . . 5

2.6 Progressive Web Application . . . 5

2.7 Integritet . . . 6

2.8 Uppdragsgivare/Intressent . . . 6

3 Syfte, m˚al och motivation 7 3.1 Syfte och motivation . . . 7

3.2 M˚al . . . 7

3.3 Avgr¨ansningar . . . 8

4 Relaterat arbete 8 4.1 Liknande digitala verktyg . . . 8

4.2 Massive Open Online Courses . . . 9

4.3 Blandade l¨armilj¨oer . . . 9

5 Metod 10 5.1 Spr˚ak och ramverk . . . 10

5.3 Implementering av inkluderande design f¨or ADHD . . . 11

5.4 Implementation av st¨od f¨or svag central koherens . . . 12

5.5 Integritet . . . 13

6 Riktlinjer f¨or inkluderande design 13 6.1 Tillhandah˚all en rogivande milj¨o . . . 13

6.2 Bel¨ona och uppmuntra till slutf¨orda uppgifter . . . 14

6.3 Ha ett metodiskt uppl¨agg . . . 14

6.4 Avgr¨ansa viktig information . . . 15

6.5 Hj¨alpa eleverna h˚alla reda p˚a sina framsteg . . . 15

6.6 Anv¨and korta och tydliga instruktioner . . . 15

6.7 Till˚at eleverna att ta pauser . . . 16

6.8 Minimera ¨overraskningar . . . 16

7 Krav och utv¨arderingsmetoder 16 7.1 Progressive Web Application . . . 16

7.2 Design . . . 17 7.3 Funktionalitet . . . 17 7.4 Anv¨andartester . . . 17 8 Systemets uppbyggnad 18 8.1 Overgripande systemstruktur . . . .¨ 19 8.2 Kodstruktur . . . 21 9 Anv¨andargr¨anssnitt 23 9.1 Startsidan . . . 23 9.2 L¨ararvyn . . . 24

9.3 Elevvyn . . . 25 9.4 Flervalsfr˚aga . . . 26 9.5 Drag-and-drop fr˚aga . . . 27 10 Utv¨arderingsresultat 28 10.1 Design . . . 28 10.2 Funktionalitet . . . 30

10.2.1 En vy f¨or eleven och en f¨or l¨araren . . . 30

10.2.2 Profilsida f¨or varje elevkonto . . . 30

10.2.3 Statistik f¨or utf¨orda uppgifter p˚a elevens profil . . . 30

10.2.4 Olika typer av fr˚agor som kan skapas fr˚an l¨ararvyn . . . 30

10.2.5 Inloggningsfunktion f¨or elever och l¨arare . . . 31

10.2.6 H¨amta data fr˚an en databas via ett API . . . 31

10.3 Anv¨andartester . . . 31

10.4 Progressive Web Application . . . 32

11 Resultat och diskussion 33 11.1 Resultat . . . 33

11.2 Diskussion . . . 34

11.2.1 Funktionalitet . . . 34

11.2.2 Design . . . 34

11.2.3 Anv¨andartester . . . 35

11.2.4 Progressive Web Application . . . 36

12 Slutsatser 36

13.1 Delar vi inte implementerat . . . 37 13.2 Inloggning f¨or f¨or¨aldrar . . . 37 13.3 Maskininl¨arning . . . 38

Begreppslista

Tekniska begrepp

React Ett JavaScript-bibliotek specifikt till f¨or att enkelt kunna utveckla interaktiva och effektiva anv¨andargr¨anssnitt.

DOM Document Object Model. Anv¨ands f¨or att dynamiskt uppdatera ett dokuments inneh˚all och struktur.

MOOC Massive Open Online Courses, kurser som ges gratis online p˚a di-stans.

PWA Progressive Web Application, en typ av webbapplikation som bland annat kan uppfattas som en mobilapplikation p˚a en mobil enhet. CSS Cascading Style Sheets, ett programspr˚ak som anv¨ands i syfte att

redigera utseende p˚a till exempel hemsidor och dokument.

JavaScript Ett programspr˚ak som anv¨ands mycket inom web- och applikations-utveckling, fr¨amst vid utveckling av klientsidan.

Open source Ett begrepp som anv¨ands f¨or datorprogram eller k¨allkod som ¨ar tillg¨angliga f¨or alla att anv¨anda.

Lighthouse Ett open source verktyg utvecklat av Google som anv¨ands f¨or att analysera och f¨orb¨attra prestandan och kvaliteten p˚a hemsidor. API Application Programming Interface, ett gr¨anssnitt f¨or hur andra

pro-gram kan kommunicera med en viss mjukvara. API kan definieras som kopplingen mellan en viss mjukvara och andra program. GDPR General Data Protection Regulation, en europeisk f¨orordning f¨or att

st¨arka s¨akerheten kring hantering av personuppgifter.

¨

Ovriga begrepp

NPF Neuropsykiatriska funktionsneds¨attningar, ett samlingsbegrepp f¨or diagnoser som syftar till hur hj¨arnan och nervsystemet bearbetar in-formation. Diagnoser som ADHD och autism r¨aknas till NPF [25].

1 Introduktion

ADHD Attention Deficit Hyperactivity Disorder, en diagnos som inneb¨ar att man har sv˚arigheter med uppm¨arksamhet, ¨overaktivitet, initia-tivf¨orm˚aga och impulskontroll [23].

Autism Autism ¨ar en utvecklingsneurologisk funktionsneds¨attning som p˚averkar hj¨arnans s¨att att hantera information. [27]

1

Introduktion

N¨astan var femte elev som gick ut grundskolan i juni 2017 var ej beh¨orig till gym-nasieskolan [20]. Denna elevgrupp p˚a n¨astan 20% gick d¨armed miste om framtida m¨ojligheter d˚a de har s¨amre f¨oruts¨attningar f¨or fortsatta studier och arbetsm¨ojligheter. Att s˚a m˚anga elever inte uppfyller de m˚al som kr¨avs f¨or vidare studier p˚a gymnasiesko-la ¨ar ett stort samh¨allsproblem som skolverket, kommuner och skolor arbetar mycket med [20]. Elever med diagnoser som autism eller elever med ADHD har s¨arskilt sv˚art att n˚a skolans m˚al d˚a traditionell undervisning s¨allan passar de elevernas s¨att att l¨ara sig och hantera ny information [23].

Med ambitionen om att v¨anda denna trend har vi skapat en webbapplikation som ¨ar t¨ankt att fungera som ett st¨od i undervisningen. Applikationen har tv˚a olika vyer, en f¨or l¨arare och en f¨or elever. Det huvudsakliga syftet ¨ar att l¨arare ska kunna skapa ¨amnen och l¨agga in fr˚agor som eleverna sedan ska kunna ta del av. V˚ar applikation har st¨od f¨or en variation av fr˚agor med till exempel textsvar, flera svarsalternativ, drag-and-drop och bildfr˚agor.

Att erbjuda en variation av metoder f¨or inl¨arning g¨or att undervisningen blir mer indi-vidanpassad. Detta d˚a varje elev sj¨alv kan v¨alja det inl¨arningss¨att som passar dem b¨ast. V˚ar m˚algrupp ¨ar h¨ogstadieelever med diagnoser som faller inom kategorin NPF, neu-ropsykiatriska funktionsneds¨attningar, framf¨orallt ADHD och autism. D¨armed har vi utvecklat applikationens design och funktionalitet utifr˚an slutsatser fr˚an tidigare forsk-ning om hur personer med diagnoser som ADHD och autism tar till sig information. Id´en till projektet kom fr˚an f¨oretaget Hyperkonkret, som planerar att vidare forts¨atta utveckla den slutprodukt vi utvecklat. Det slutgiltiga m˚alet, som str¨acker sig utanf¨or det h¨ar projektet, ¨ar att skapa ett s˚a individanpassat verktyg som m¨ojligt.

2 Bakgrund

2

Bakgrund

I denna del beskrivs bakgrunden till v˚art projekt, vilket f¨orhoppningsvis ger en b¨attre bild av behovet som finns. H¨ar f¨orklarar vi hur situationen f¨or barn med neuropsykia-triska funktionsneds¨attningar ser ut i skolan idag och hur programvaruutvecklare kan ha mer inkluderande design i ˚atanke. Vi ger ¨aven en bild av vad f¨or slags applikation vi har skapat. Slutligen presenteras ¨aven v˚ar externa uppdragsgivare som har motiverat hela projektet.

2.1

ADHD

ADHD, Attention Deficit Hyperactivity Disorder, ¨ar en typ av NPF som inneb¨ar att ens hj¨arna och nervsystem bearbetar information p˚a ett annat s¨att ¨an hos personer utan ADHD. Symptomen kan sammanfattas av koncentrationssv˚arigheter, impulsivitet och ¨overaktivitet. Begreppet ADHD omfattar ¨aven ADD som inneb¨ar att man har samma symptom f¨orutom ¨overaktiviteten. ADHD kan i skolsammanhang inneb¨ara att man har koncentrationssv˚arigheter eller har sv˚art att komma ig˚ang med arbete [23].

2.2

Autism

Autism ¨ar en NPF som p˚averkar hj¨arnans s¨att att hantera information. Central koherens syftar p˚a en individs f¨orm˚aga att f¨orst˚a sammanhang [12]. M˚anga individer diagnosti-serade med autism ¨ar detaljfokudiagnosti-serade, det vill s¨aga utg˚ar fr˚an information i form av detaljer. Det kan g¨ora det sv˚art att f¨orst˚a st¨orre sammanhang och forma en helhet av de-taljerad information. Det kallas att de har svag central koherens. I den text om autism, av Monica Klas´en McGrath, som det h¨ar stycket refererar till beskrivs hur m˚anga forskare ¨ar ¨overens om att individer med autism har sv˚art att koppla samman information fr˚an olika k¨allor till en helhet f¨or att f¨orst˚a ett sammanhang. Detta g¨or att det kan bli sv˚art f¨or elever med autism i skolsammanhang d˚a det vid inl¨arning i skolan kr¨avs att elever kopplar samman fakta och kunskap fr˚an flera olika k¨allor och drar slutsatser utifr˚an det. Det kan inneb¨ara att man till exempel har sv˚art att f¨orst˚a abstrakta koncept och spr˚akliga otydligheter [12].

2 Bakgrund

2.3

ADHD och autism i skolan

I skollagen st˚ar det att skolor ska erbjuda st¨od och stimulans f¨or att elever ska utvecklas s˚a l˚angt som m¨ojligt [19]. D¨ar st˚ar det ¨aven att elever som beh¨over extra st¨od ska kunna f˚a det. Om extra st¨od inom ramen f¨or ordinarie undervisning inte r¨acker s˚a ska specia-lanpassat st¨od ges med beslut fr˚an skolans rektor. Yvonne Gustafsson, examinerad l¨arare vid Lunds universitet, har behandlat ¨amnet i sin rapport Individanpassad undervisning och menar att detta inte uppfylls som det b¨or g¨ora [6]. Som tidigare n¨amnt i avsnitt 1 s˚a har elever med diagnoser som autism och ADHD s¨arskilt sv˚art att n˚a skolans m˚al. Sven B¨olte, professor vid Karolinska institutets kompetenscentrum (KIND), f¨orklarar att minst 10% av alla barn idag har s¨arskilda behov vilket utg¨or flera i varje klass [3]. Som Gustafsson beskriver i sin rapport s˚a uppfyller inte alla skolor de lagar som finns f¨or att ge st¨od till dessa elever [6].

Den h¨ar problematiken kan ibland skapa problem i elevens utbildning som kommer av att eleven inte kan f˚a det st¨od hen beh¨over. M˚anga l¨arare upplever att det ¨ar sv˚art att tillgodose dessa elevers behov [3]. 19 av 20 l¨arare uppger att de var helt of¨orberedda p˚a att de kanske skulle jobba med elever med diagnoser som ADHD eller autism. Tv˚a av tre l¨arare uppger att skolan de arbetar p˚a inte kan m¨ota behoven elever med de diagnoserna har. L¨arare och skolor i stort har allts˚a sv˚art att tillgodose de behov som finns bland elever i skolan idag.

2.4

Anpassad undervisning och s ¨arskilt st ¨

od

De tv˚a former av st¨od som skollagen fastst¨allt som r¨attigheter, i de fall en elev riskerar att inte n˚a m˚alen fastst¨allda i l¨aroplanen f¨or grundskolan, kallas anpassad undervisning och s¨arskilt st¨od [21]. Anpassad undervisning sker inom ramen f¨or ordinarie undervisning och kan vara att till exempel f˚a en uppgift f¨orklarad p˚a ett annat s¨att, att f˚a tydligare instruktioner eller att f˚a st¨od i att komma ig˚ang med en uppgift. S¨arskilt st¨od ges of-tast av utbildad specialpedagog och kan innefatta samma metoder som den anpassade undervisningen n¨amnd ovan men ¨aven omfatta mer, som till exempel anv¨andandet av individuellt anpassade strategier och n˚agot som kallas tydligg¨orande pedagogik [22]. Tydligg¨orande pedagogik inneb¨ar att man ¨ar v¨aldigt tydlig i sin planering och att ele-ven ¨ar delaktig i planeringen. Man f¨ors¨oker besvara fr˚agor som kan uppkomma under en skoldag. Till exempel “Var ska jag vara?”, “Vem ska jag vara med?”, “Vad ska jag g¨ora?”, “N¨ar?”, “Hur l¨ange?” och “Vad h¨ander sen?”. Det kan beroende p˚a individen till exempel vara att man har ett visuellt dagsschema eller veckoschema, eller att eleven p˚a annat s¨att blir v¨al informerad om vad som kommer h¨anda under dagen eller veckan. Syftet ¨ar att skapa en bra l¨armilj¨o genom att g¨ora omgivningen begriplig och hanterbar.

2 Bakgrund

Specialpedagogiska skolmyndigheten, som erbjuder st¨od i form av kunskap och kom-petensutveckling till alla f¨orskolor och skolor ¨over hela Sverige, menar att det inte finns ett pedagogiskt tillv¨agag˚angs¨att som passar f¨or till exempel alla elever med ADHD och elever utan ADHD utan att den m˚aste vara individuellt anpassad till varje elev [24]. P˚a s˚a vis ¨ar st¨odet som specialpedagoger redan ger till elever kopplad till den applikation vi utvecklar. Den fokuserar p˚a elevens behov och ger till exempel m¨ojlighet f¨or eleven att f˚a tydliga instruktioner stegvis vid en fr˚aga som ¨ar sv˚ar att f¨orst˚a. Specialpedagogiken idag inneb¨ar initialt, d˚a en elev blivit beviljad s¨arskilt st¨od, att en grundlig pedagogisk kartl¨aggning g¨ors. D¨arefter ska undervisningen anpassas efter de behov som fastst¨allts vid kartl¨aggningen. Specialpedagogiska myndigheten anser att man d¨arefter b¨or anpas-sa undervisningen efter den enskilda elevens s¨att att tolka sinnesintryck och koncentrera sig. Webbapplikationen vi utvecklar ¨ar allts˚a ett verktyg som kan anv¨andas f¨or att reali-sera delar av den pedagogik som s¨arskilt st¨od kan inneb¨ara f¨or elever.

2.5

Inkluderande design

Lorna McKnight ¨ar forskare vid University of Central Lancashire i Storbritannien [15]. Hon har en bakgrund inom m¨anniska-dator interaktion med en doktorsexamen i datave-tenskap och psykologi. Hon har arbetat med flera olika projekt f¨or att unders¨oka barns interaktiva f¨orm˚aga. McKnight har skrivit en forskningsrapport om hur programvaru-utvecklare kan anv¨anda sin befintliga kunskap om anv¨andbarhetsfr˚agor f¨or att utfor-ma programvara som undviker att exkludera barn med ADHD [14]. Hon ins˚ag att det fanns otillr¨acklig information om hur just programvaruutveckling b¨or ske med h¨ansyn till barn med ADHD. McKnight valde d¨arf¨or att fokusera p˚a att hitta allm¨anna riktlinjer f¨or hur man b¨ast f¨orh˚aller sig, som l¨arare eller f¨or¨alder, till barn med ADHD. Utifr˚an detta s˚a sammanst¨allde hon en lista med 15 riktlinjer som hon ans˚ag mest relevanta och ˚aterkommande i sin studie. Vi ˚aterkommer till desssa riktlinjer i avsnitt 6. I sin rapport diskuterar McKnight hur dessa generella riktlinjer kan appliceras p˚a just programvaru-utveckling.

2.6

Progressive Web Application

Ett ¨onskem˚al fr˚an intressenten var att anpassa webbapplikationen till kriterier f¨or Pro-gressive Web Application (PWA). En PWA ¨ar en hybrid mellan en vanlig hemsida och en mobilapplikation. Begreppet PWA myntades 2015 av bland annat en Google Chrome-utvecklare vid namn Alex Russell [18]. Applikationer som ¨ar PWA n˚as via en webbl¨asare, men kan ¨aven laddas ned p˚a enheten och upplevas och anv¨andas som en mobilapplikation. D˚a sparas inneh˚allet p˚a enheten s˚a att det ¨ar tillg¨angligt offline och

2 Bakgrund

kan n˚as precis som en vanlig mobilapplikation via en ikon p˚a till exempel hemsk¨armen. Google Developershar definierat tio egenskaper som karakt¨aristiska f¨or PWAs, bland annat att de ¨ar progressiva, responsiva, applikationsliknande, installerbara och l¨ankbara [9]. Progressivitet inneb¨ar att applikationen utvecklats med s˚a kallad Progressive Enhance-ment[16]. Det inneb¨ar att den fungerar oavsett val av webbl¨asare och att utseende samt funktion anpassas beroende p˚a webbl¨asare och internetuppkoppling. Det g¨ors f¨or att ga-rantera anv¨andare tillg˚ang till grundl¨aggande funktionalitet och inneh˚all. D¨aremot kan utf¨orandet och viss funktionalitet begr¨ansas av webbl¨asare eller uppkoppling. Respon-sivitet inneb¨ar att applikationen anpassar sig till enheten p˚a vilken den k¨ors oavsett om det ¨ar p˚a en laptop eller en smartphone, med bibeh˚allen anv¨andarv¨anlighet.

En hemsida kan uppfylla kriterierna f¨or att vara en PWA mer eller mindre, vilket ¨ar m¨atbart. Google Developers har utvecklat verktyget Lighthouse som bland annat kan anv¨andas f¨or att m¨ata hur v¨al en hemsida uppfyller kriterierna.

2.7

Integritet

I och med dataskyddsf¨orordningen General Data Protection Regulation (GDPR) som tr¨ader i kraft den 25 Maj 2018 s˚a sk¨arps reglerna kring hur personlig data ska lag-ras [2]. Eftersom vi g¨or en hemsida och kommer lagra information om anv¨andarna s˚a ¨ar det relevant f¨or oss att ha detta i ˚atanke. GDPR inneb¨ar att bolag, myndigheter och andra organisationer har fler skyldigheter vad g¨aller lagring av personlig data. De ¨ar en-ligt f¨orordningen exempelvis skyldiga att vid dataintr˚ang meddela b˚ade de personer det g¨aller och datainspektionen om informationen kan leda till att personer uts¨atts f¨or dis-kriminering, id-st¨older, bedr¨ageri eller finansiella f¨orluster. De har ¨aven skyldighet att g¨ora en konsekvensbed¨omning vad det g¨aller dataskydd om de har f¨or avsikt att hantera personuppgifter p˚a ett riskfyllt s¨att. GDPR inneb¨ar fr¨amst att de tv˚a ovan n¨amnda skyl-digheterna f¨oljs, men inneb¨ar ocks˚a att Datainspektionen ska g¨ora f¨orhandskontroller av riskfylld hantering av personuppgifter och dela ut b¨oter ifall f¨orordningen inte ef-terf¨oljs [1].

2.8

Uppdragsgivare/Intressent

Projektet g¨ors i samarbete med startup-f¨oretaget Hyperkonkret, vilka hade id´en till den webbapplikation detta arbete haft syftet att skapa. Bakom f¨oretaget st˚ar Jessica Stigsdot-ter Axberg och Calle Hellberg. Jessica ¨ar artdirector, webdesigner, f¨orfattare samt grun-dare och VD av MrsHyper AB. Hon ¨ar ¨aven mamma ˚at tv˚a barn med ADHD respektive

3 Syfte, m˚al och motivation

Aspergers syndrom, vilket ¨ar en typ av autism. Calle ¨ar systemarkitekt, civilingenj¨or och innovat¨or inom edutech med spetskompetens inom dyslexi. Han ¨ar ¨aven grundare av glosboken.se, en webbapplikation som anv¨ands vid inl¨arning av glosor. F¨oretagets vision ¨ar att webbapplikationen ska bli ett verktyg som finns p˚a varenda skola i hela v¨arlden.

3

Syfte, m ˚al och motivation

I detta avsnitt f¨orklarar vi vad som motiverat v˚art projekt, varf¨or id´en om projektet upp-kom, vad vi och v˚ar uppdragsgivare ville uppn˚a med projektet samt vilka avgr¨ansningar vi har beh¨ovt g¨ora.

3.1

Syfte och motivation

Som vi beskriver i avsnitt 2 ¨ar undervisningen i skolan i dagsl¨aget inte anpassad till elever p˚a individniv˚a, utan ¨ar samma f¨or alla. Det inneb¨ar problem f¨or de elever som har sv˚art att ta till sig information p˚a det f¨orutbest¨amda s¨attet, vilket utg¨or motiva-tionen f¨or detta projekt. M˚algruppen ¨ar h¨ogstadieelever med diagnoser som p˚averkar deras f¨orm˚aga att l¨ara sig utifr˚an metoder som anv¨ands i skolan idag. Vi har valt just m˚algruppen h¨ogstadieelever d˚a det f¨or dem ¨ar extra viktigt att klara m˚alen i skolan ef-tersom deras prestation ¨ar betygsgrundande. Deras betyg ¨ar i sin tur avg¨orande f¨or vidare studier vilket ¨ar varf¨or vi anser att m˚algruppen h¨ogstadieelever ¨ar viktigare att fokusera p˚a ¨an yngre ˚arskurser.

Id´en till produkten grundar sig i behovet av st¨od i skolan f¨or elever med NPF och kom-mer utvecklas d¨arefter. Vi tror dock att produkten komkom-mer vara till god anv¨andning ¨aven f¨or elever utan dessa diagnoser, och att den kan anv¨andas som ett allm¨ant kompletteran-de verktyg vid inl¨arning.

Det ¨overgripande syftet med projektet var att fler elever ska kunna n˚a m˚alen i skolan. Det har vi f¨ors¨okt angripa genom att skapa en individanpassad webbapplikation som kan erbjuda olika s¨att att ta till sig information.

3.2

M ˚al

M˚alet med v˚art projekt var att skapa en teknisk l¨osning som ska komplettera den nu-varande undervisningen. Tanken ¨ar att v˚ar applikation i framtiden ska finnas tillg¨anglig

4 Relaterat arbete

b˚ade i skolor och i hemmet. Att l¨arare b¨orjar anv¨anda v˚art hj¨alpmedel kommer f¨orhoppningsvis inneb¨ara att varje l¨arare b¨attre och l¨attare klarar av att ge st¨od till ett st¨orre antal elever ¨an tidigare och d¨armed i f¨orl¨angningen leda till att fler elever uppn˚ar m˚alen i skolan.

3.3

Avgr ¨ansningar

Data som anv¨ands i uppgifterna samt anv¨andardata kommer sparas i en databas, som inte utvecklas som en del av det h¨ar projektet och d¨arf¨or ¨ar en avgr¨ansning. Intressenten Hyperkonkret tog p˚a sig att utveckla databasen och API genom vilket vi f˚ar tillg˚ang till data i databasen. Vi valde att inte utveckla databasen eftersom vi f¨oruts˚ag att sj¨alva webbapplikationens funktionalitet skulle kr¨ava nog mycket tid.

I b¨orjan av utvecklingen avgr¨ansade vi ¨aven vilka typer av fr˚agor l¨arare ska kunna ska-pa till flervalsfr˚agor, drag-and-drop-fr˚agor och textsvarsfr˚agor. Vi ans˚ag att tiden be-gr¨ansade v˚ar f¨orm˚aga att implementera fler typer av fr˚agor under det h¨ar projektet.

4

Relaterat arbete

Vi har valt att presentera tre olika typer av relaterat arbete under detta avsnitt. F¨orst introducerar vi digitala verktyg som finns idag och hur de skiljer sig samt liknar v˚ar ap-plikation. Vi har med denna del f¨or att visa p˚a mer tekniska likheter och hur vi f¨orh˚aller oss till redan befintligt material. Sedan ber¨attar vi om n¨atbaserade kurser och blandade l¨armilj¨oer. Dessa delar har vi valt eftersom det relaterar till v˚ar id´e om att skapa fler alternativ till traditionell undervisning.

4.1

Liknande digitala verktyg

Det finns idag m˚anga digitala verktyg som kan anv¨andas vid inl¨arning av till exem-pel glosor, instuderingsfr˚agor eller liknande med hj¨alp av flashcards. N˚agra exemexem-pel ¨ar glosor.eu [4], goconqr [5] och k¨orkort.se [8]. Dessa verktyg liknar den applikation vi utvecklar eftersom de allihop g˚ar ut p˚a att ge en m¨ojlighet att f¨orh¨ora sig sj¨alv inom n˚agot omr˚ade. De flesta applicerar n˚agon form av flervalsfr˚agor, och ¨ar ofta inriktade p˚a ett specifikt ¨amne som exempelvis k¨orkort.se som f¨orh¨or en p˚a teori som kr¨avs f¨or att ta k¨orkort.

V˚ar produkt ska till skillnad fr˚an ovan n¨amnda och liknande verktyg best˚a av olika anv¨andarvyer med olika funktionalitet f¨or l¨arare respektive elever. Endast l¨arare ska ha

4 Relaterat arbete

m¨ojlighet att skapa ¨ovningar med fr˚agor och elever ska kunna ta del av dessa fr˚agor. En annan viktig skillnad fr˚an konkurrenterna ¨ar att det i v˚ar applikation ska finnas m¨ojligheten att l¨agga in flera olika typer av fr˚agor och svar (drag-and-drop, flervals-fr˚agor, textsvar och s˚a vidare). Detta ¨ar en viktig del av arbetet d˚a vi inte vill tvinga eleverna att anpassa sig, utan erbjuda alternativ som passar f¨or alla. Det ska ¨aven finnas m¨ojlighet f¨or l¨arare att skriva en f¨orklaring till fr˚agorna f¨or att eleverna ska f˚a en tydli-gare bild av exakt vad som efterfr˚agas. Denna funktion finns inte heller implementerat hos liknande digitala verktyg.

4.2

Massive Open Online Courses

Massive Open Online Courses (MOOCs) ¨ar avgiftsfria n¨atbaserade kurser som l¨ases p˚a distans, ofta tillg¨angliga efter en enkel registrering p˚a den plattform som kursen ges p˚a. Ett exempel ¨ar Khan Academy [7]. Kurserna kan best˚a av inspelade videolektioner, teoretiska texter och n˚agon typ av uppgifter, ibland interaktiva. Plattformen som kursen ges p˚a ¨ar ofta en hemsida som ¨ar specifikt anpassad f¨or den eller de kurser som man vill g¨ora tillg¨anglig. MOOCs ¨ar p˚a s˚a vis kopplat till v˚art arbete, eftersom vi ocks˚a utvecklar en webbapplikation som ger m¨ojligheten att l¨ara sig n˚agot p˚a distans (eller i klassrummet). En sak som skiljer v˚ar webbapplikation fr˚an de flesta MOOCs ¨ar att materialet p˚a sidan inte ¨ar h¨amtat externt, utan att l¨arare skapar det sj¨alva f¨or just sina elever. P˚a s˚a s¨att kan l¨ararna anpassa uppgifter och ¨amnen efter sin specifika l¨aroplan eller elev. Ut¨over det ¨ar v˚ar webbapplikations syfte att vara individanpassad vilket inte ¨ar fallet f¨or de flesta MOOCs.

4.3

Blandade l ¨armilj ¨

oer

Blandade l¨armilj¨oer ¨ar ett koncept som syftar till anv¨andandet av en blandning av tradi-tionella s¨att att undervisa i klassrum, och datorassisterad undervisning. Ett exempel p˚a en metod f¨or en blandad l¨armilj¨o ¨ar The flipped classroom.

The flipped classroominneb¨ar att l¨araren ger webbaserade genomg˚angar i till exempel videoform som l¨axa att g¨ora inf¨or ett lektionstillf¨alle, och anv¨ander sedan tiden i klass-rummet till genomt¨ankta aktiviteter f¨or att st¨odja elevernas l¨arande [13]. Exempel p˚a detta ¨ar praktiska uppgifter, analys eller diskussion. Detta kan uppn˚as med webbappli-kationen vi utvecklar om l¨araren v¨aljer att anv¨anda verktyget p˚a det s¨attet, och ¨ar d¨arf¨or relaterat till v˚art arbete.

5 Metod

5

Metod

I utvecklingen av webbapplikationen har vi anv¨ant flera programspr˚ak, bibliotek och verktyg, samt f¨ardiga komponenter f¨or delar av funktionaliteten. Vi utvecklar ¨aven ne-dan hur vi arbetat med de riktlinjer f¨or inkluderande design som n¨amns i avsnitt 5.3.

5.1

Spr ˚ak och ramverk

Vi anv¨ander programspr˚aken JavaScript och CSS. JavaScript ¨ar ett programspr˚ak som fr¨amst anv¨ands i webbl¨asare. Vi har anv¨ant det f¨or att implementera funktionaliteten i v˚ar webbapplikation. CSS ¨ar ett programspr˚ak som anv¨ands f¨or att best¨amma en hem-sidas utseende med avseende p˚a f¨arger, typsnitt, placering av olika element med mera. Eftersom applikationen ska vara interaktiv s˚a har vi ¨aven valt att anv¨anda ett JavaScript-ramverk vid namn React. Det finns flera andra alternativ f¨or att kunna uppn˚a samma funktionalitet; till exempel andra JavaScript-ramverk som Angular och Vue, och ¨aven m¨ojligheten att g¨ora applikationen i ren JavaScript utan att anv¨anda n˚agot komplette-rande ramverk. Vi valde att anv¨anda React dels f¨or det finns mycket tidigare utvecklat material som l¨att kan integreras i projektet, vilket vidare beskrivs i avsnitt 5.2. React ¨ar ocks˚a ett v¨aldigt popul¨art ramverk just nu vilket gjorde att vi blev inspirerade att l¨ara oss det. D˚a ingen av oss hade anv¨ant React innan blev det en rolig gemensam utmaning. React anv¨ander sig ¨aven av n˚agot som kallas Virtual DOM. DOM st˚ar f¨or Document Ob-ject Model, ett gr¨anssnitt som ¨ar plattforms- och spr˚akoberoende. Gr¨anssnittet ger spr˚ak m¨ojligheten att dynamiskt uppdatera ett dokuments inneh˚all och struktur och ˚aterfinns bland annat i HTML. Reacts Virtual DOM j¨amf¨or vilka objekt i DOM:en som f¨or¨andrats n¨ar n˚agot i systemet uppdateras. P˚a s˚a s¨att beh¨over bara de objekt som f¨or¨andrats upp-dateras i den icke-virtuella DOM:en som p˚averkar vad som visas p˚a sk¨armen. Den h¨ar typen av selektiv uppdatering leder till b¨attre prestanda f¨or applikationen, vilket ¨ar ¨annu en anledning till att vi valt att anv¨anda React.

5.2

F ¨ardiga komponenter och verktyg

Vi har anv¨ant oss av m˚anga olika bibliotek i React, samt f¨ardiga komponenter i den m˚an vi kunnat. Med f¨ardiga komponenter och bibliotek menas till exempel Google-login som anv¨ands f¨or att utveckla en funktion f¨or inloggning och biblioteket React-Dragula f¨or utveckling av drag-and-drop-funktioner. Vi anv¨ande dessa f¨ardiga komponenter och bibliotek f¨or att kunna fokusera p˚a att utveckla den funktionalitet som s¨arskiljer v˚art

5 Metod

arbete fr˚an liknande webbapplikationer som redan finns idag. Det vill s¨aga funktionalitet f¨or inloggning till olika vyer, att skapa olika sorters fr˚agor och att besvara fr˚agor. Vi anv¨ander oss ¨aven av verktyget Lighthouse [10] fr˚an Google Chrome Developer Tools. Lighthouse ¨ar ett open-source verktyg skapat f¨or att st¨odja utvecklingen av hem-sidor. Det kan anv¨andas p˚a vilken hemsida som helst f¨or att utv¨ardera bland annat dess prestanda, tillg¨anglighet och anpassning till kraven f¨or PWA.

Vi anv¨ander oss ¨aven av verktyget Postman [17] f¨or att testa kopplingen mot API. Post-man ¨ar skapat av f¨oretaget Postdot Technologies och anv¨ands vid API-utveckling. En av dess funktioner ¨ar automatiserad testning av ett API, vilket ¨ar den del som ¨ar relevant f¨or oss. Det som testas ¨ar att anv¨anda API f¨or att h¨amta data ur databasen och f¨ora in data i databasen, till exempel n¨ar vi skapar en ny anv¨andare eller en uppgift i ett ¨amne s˚a ska data sparas i databasen. Vi kan d˚a via Postman anropa respektive tabell med data f¨or att se om det faktiskt sparades. P˚a samma s¨att kan vi se om den data vi vill h¨amta till v˚ar ap-plikation ¨ar vad vi avsett. Till exempel om vi vill h¨amta uppgifter om en viss anv¨andare vill vi f¨ors¨akra oss om att v˚ar applikation endast f˚ar tillg˚ang till datan om den anv¨andare vi s¨oker. Detta ¨ar extra viktigt av s¨akerhetssk¨al och av respekt f¨or personuppgifter.

5.3

Implementering av inkluderande design f ¨

or ADHD

Som n¨amns i avsnitt 2.5 s˚a har forskaren McKnight tagit fram riktlinjer att arbeta efter f¨or att inte exkludera m¨anniskor med ADHD. Riktlinjerna ¨ar i sig inte specifika f¨or programvaruutveckling och d¨arf¨or ¨ar alla riktlinjer inte helt relevanta f¨or v˚art projekt. Dessa riktlinjer har McKnight presenterat i sin rapport:

• Utforma material s˚a att utseendet ¨ar enkelt

• Tillhandah˚all en rogivande milj¨o utan starka f¨arger, dekorationer och distraktioner • Bel¨ona och uppmuntra slutf¨orda uppgifter

• Ha ett metodiskt uppl¨agg

• Avgr¨ansa viktig information genom att uttrycka den i fetstil, stort typsnitt eller f¨arg

• Anv¨and stor skrift och n˚agot sans-serif typsnitt som till exempel Arial

• Hj¨alp studenten att f¨olja texten genom att skriva eller markera alternerande rader med olika f¨arger

5 Metod

• Om studenten beh¨over arbeta sig genom en rad fr˚agor, hj¨alp dem att h˚alla reda p˚a sin position genom att anv¨anda en mark¨or

• Anv¨and korta och tydliga instruktioner

• Ha en avgr¨ansad plats att jobba p˚a, i en ljudisolerad milj¨o med f˚a distaktioner • Till˚at eleverna att ta pauser

• H˚all teknik borta om den inte anv¨ands

• H˚all dig till en rutin, till exempel genom att inte byta l¨arare • Minimera ¨overraskningar

• H˚all ¨ogonkontakt

Av dessa 15 riktlinjer s˚a har vi valt ut de som vi k¨anner att vi kan ha anv¨andning av n¨ar vi utvecklar v˚ar webbapplikation. Vi har valt bort riktlinjer som vi som utvecklare inte kan p˚averka, det vill s¨aga att h˚alla ¨ogonkontakt, att vara i en avgr¨ansad och ljudisolerad milj¨o, att h˚alla teknik borta och att h˚alla sig till en rutin genom att till exempel inte byta l¨arare. Vissa riktlinjer har vi ¨aven valt bort f¨or att vi anser tv˚a riktlinjer f¨or lika varandra. Av de riktlinjer som n¨amns i punkt ett och tv˚a har vi valt en av de eftersom b˚ada handlar om enkel, tydlig och minimatistisk design. Vi har av samma anledning, att de ¨ar lika varandra, valt en av de riktlinjer som n¨amns som punkt fem och sex. Riktlinjen som handlar om att hj¨alpa eleven att f¨olja texten genom alternerande f¨arger p˚a rader har vi valt att inte f¨olja p˚a grund av att vi inte har l˚anga l¨opande texter d¨ar detta skulle beh¨ovas. Hur vi arbetat med de resterande 8 riktlinjer beskriver vi n¨armre i avsnitt 6.

5.4

Implementation av st ¨

od f ¨

or svag central koherens

Som beskrivet i avsnitt 2.2 har m˚anga som ¨ar diagnostiserade med autism svag central koherens. Detta g¨or att man har sv˚art att f¨orst˚a sammanhang och medf¨or hos en del sv˚arigheter med probleml¨osning [26]. F¨or att hj¨alpa de elever som har dessa sv˚arigheter har vi implementerat ett st¨od f¨or tydligare beskrivning av de fr˚agor som st¨alls i ¨ovningarna. F¨or varje fr˚aga som st¨alls i webbapplikationen har eleven som ska svara m¨ojlighet att f˚a minst ett f¨ortydligande av fr˚agan, till exempel en omformulering av fr˚agan eller tips p˚a hur man ska t¨anka. F¨or att ta del av st¨odet trycker eleven p˚a en symbol och f¨ortydligandet visas d˚a i textform. Hj¨alpsymbolen ¨ar placerad intill fr˚agan f¨or att den ska vara enkel att hitta och anv¨anda.

6 Riktlinjer f¨or inkluderande design

5.5

Integritet

Som vi skrivit i avsnitt 2 s˚a tr¨ader en ny f¨orordning vid namn General Data Protection Regulation [2] i kraft i maj 2018 som behandlar datas¨akerhet. I och med anv¨andning av v˚ar applikation s˚a lagras data, antingen lokalt eller i en databas, vilket g¨or att den nya lagen m˚aste tas i beaktande f¨or den data som lagras. Hur som helst s˚a har databasen inte utvecklats fullst¨andigt till den funktionalitet som beh¨ovs f¨or anv¨andning av produkten. D¨arf¨or sker lagring av data i nul¨aget p˚a ett s¨att som m˚aste modifieras av intressenten efter det ¨ar projektet avslutats. Eftersom databasens utveckling ¨ar intressentens ansvar s˚a ligger ¨aven ansvaret f¨or laglig hantering av data p˚a intressenten n¨ar tiden ¨ar kommen f¨or den slutgiltiga implementationen.

6

Riktlinjer f ¨

or inkluderande design

I f¨oljande avsnitt presenterar vi de riktlinjer vi har valt att arbeta med och hur vi f¨orh˚aller oss till dem. Alla rubriker ¨ar riktlinjer framtagna av McKnight, ¨oversatta av oss [14].

6.1

Tillhandah ˚all en rogivande milj ¨

o

McKnight f¨orklarar att en rogivande milj¨o utan starka f¨arger, dekorationer och distrak-tioner kan till¨ampas f¨or en mjukvarumilj¨o ¨aven om den ¨ar framtagen f¨or hem- eller klassrumsmilj¨oer. Hon menar att anv¨andning av en minimalistisk design med f˚a dis-traktioner kan vara bra f¨or alla anv¨andare eftersom det hj¨alper till att undvika f¨orvirring och on¨odiga fel gjorda i brist p˚a uppm¨arksamhet. Som tidigare n¨amnt s˚a blir personer med ADHD l¨att distraherade och f¨orlorar uppm¨arksamheten [23]. D¨arf¨or tycks denna riktlinje framf¨orallt viktig f¨or v˚ar m˚algrupp j¨amf¨ort med den allm¨anna anv¨andaren. Vi hade ambitionen att f¨olja denna riktlinje genom att h˚alla oss till en f¨argskala och en minimalistisk design. Vi har f¨ors¨okt undvika skrikiga f¨arger helt och valt dova f¨arger till detaljer och delar av webbapplikationen med liten inneb¨ord. Att allt som finns i webbapplikationen ska ha ett tydligt syfte ¨ar n˚agot vi ocks˚a t¨ankt p˚a i och med denna riktlinje f¨or att fokus ska vara p˚a det av vikt.

6 Riktlinjer f¨or inkluderande design

6.2

Bel ¨

ona och uppmuntra till slutf ¨

orda uppgifter

Att bel¨ona utf¨orda uppdrag ¨ar ett vanligt inslag i spel, n¨ar man g¨or framsteg eller klarar av en ny niv˚a. McKnight menar att uppmuntran och anv¨andandet av ett ¨overdrivet posi-tivt spr˚ak ¨ar bra f¨or den generella anv¨andaren men i vissa fall kan det f˚a ett program att framst˚a som l¨ojligt, beroende p˚a m˚algrupp och syfte med programmet.

Vi f¨orst˚ar McKnights tanke kring att uppmuntran ibland kan bli l¨ojligt i mjukvarusam-manhang. Om man till exempel har en kalender d¨ar det kommer upp ”Snyggt jobbat!” n¨ar man l¨agger in ett nytt m¨ote kan den uppmuntran nog upplevas som on¨odig och lite l¨ojlig. Men eftersom v˚ar webbapplikation handlar om att elever ska utf¨ora uppgifter och klara ¨ovningar kunde uppmuntran implementeras n¨ar en uppgift eller ¨ovning avslutats. D˚a elever med koncentrationssv˚arigheter ¨ar en del av v˚ar m˚algrupp ¨ar uppmuntran ¨aven en metod f¨or att h˚alla dessa elevers fokus kvar p˚a ¨ovningen.

I en artikel, d¨ar k¨anslor hos barn med ADHD beskrivs, st˚ar det hur barn kan komma att influeras av f¨orutfattade meningar g¨allande ADHD och att det kan medf¨ora att barn k¨anner sig dumma, lata och som “det d˚aliga barnet” [11]. D˚a ADHD ofta ¨ar en utmaning i inl¨arningssammanhang ¨ar uppmuntran ett bra s¨att att ta bort det negativa fokus m˚anga unga har kring sin diagnos [23].

M˚alet med att implementera denna riktlinje var att fokus endast skulle l¨aggas p˚a positiv feedback och inte p˚a felaktiga svar. Det h¨ar f¨or att ¨oka sj¨alvs¨akerheten hos eleverna och minska den negativa syn m˚anga har p˚a sin diagnos. [11] Vi valde att anv¨anda oss av denna riktlinje p˚a flera olika s¨att. Vi ville implementera att varje r¨att svar ska bem¨otas med positiv respons som ”Snyggt jobbat!”, ”R¨att svar!” eller liknande och att positiv feedback ges ¨aven d˚a man klarat av en hel ¨ovning eller ett helt ¨amne. Fokus ska vara att uppmuntra genom visuell feedback och inte kritisera.

6.3

Ha ett metodiskt uppl ¨agg

Att ha ett metodiskt gr¨anssnitt ¨ar ett viktigt koncept n¨ar man talar om anv¨andarv¨anlighet. Det ¨ar sj¨alvklart viktigt f¨or alla anv¨andare att det ska vara enkelt att hitta det man letar efter. Men om man ser bortom allm¨anna anv¨andare och fokuserar p˚a elever med ADHD s˚a ¨ar det av ytterligare vikt att ha ett metodiskt uppl¨agg. Det minskar risken f¨or distrak-tioner vilket ¨ar viktigt f¨or m˚algruppen f¨or att bibeh˚alla koncentration och intresse. V˚ar tolkning av denna riktlinje ¨ar att se till att det man letar efter i applikationen ska finnas d¨ar det ”f¨orv¨antas” finnas. M˚alet ¨ar allts˚a att n¨ar man som anv¨andare till exempel vill hitta sin profilsida s˚a ska man inte beh¨ova leta runt i applikationen, utan enkelt hitta

6 Riktlinjer f¨or inkluderande design

den. Med detta s˚a tar vi d¨aremot f¨or givet att alla anv¨andare t¨anker likadant, vilket inte beh¨over vara fallet. Vi f¨ors¨oker dock att ha ett uppl¨agg som efterliknar mallen f¨or andra hemsidor och applikationer n¨ar vi skapar menyer/undermenyer f¨or att anv¨andarna ska k¨anna igen uppl¨agget.

6.4

Avgr ¨ansa viktig information

McKnight beskriver att det ¨ar viktigt att avgr¨ansa viktig information genom att uttrycka den i fetstil, stort typsnitt eller f¨arg, likt tv˚a tidigare n¨amnda riktlinjer i avsnitt 6.1 och 6.3, handlar om hur barn med ADHD beh¨over ha saker tydligt och organiserat. Att markera n˚agot i fetstil eller i f¨arg g¨or det enklare att hitta och anv¨andaren identifierar det d˚a som viktigt.

Den h¨ar riktlinjen ¨ar viktig i v˚ar webbapplikation f¨or att elever ska ha fokus p˚a r¨att saker. V˚ar ambition ¨ar att anv¨anda fetstil p˚a den viktigaste texten f¨or att g¨ora den extra tydlig, till exempel rubriker.

6.5

Hj ¨alpa eleverna h ˚alla reda p ˚a sina framsteg

Om eleven beh¨over arbeta sig genom en rad fr˚agor ¨ar det viktigt av att eleven kan h˚alla koll p˚a vad som h¨ander och sina framsteg. Det kan hj¨alpa till att h˚alla motivationen uppe. I v˚art fall hade vi m˚alet att implementera detta med avseende p˚a framsteg i olika ¨amnen och ¨ovningar. I varje ¨ovning ska eleven kunna veta vilken fr˚aga den befinner sig p˚a och hur m˚anga fr˚agor ¨ovningen best˚ar av. Vi vill ¨aven visa elevens framsteg i olika ¨amnen och ¨ovningar samlat ¨oversk˚adligt p˚a profilsidan, till exempel hur m˚anga ¨ovningar i ett ¨amne man utf¨ort.

6.6

Anv ¨and korta och tydliga instruktioner

Att formulera korta och tydliga instruktioner ¨ar inte en riktlinje vi k¨ant att vi beh¨over l¨agga s˚a mycket fokus p˚a d˚a det ¨ar l¨ararna som formulerar fr˚agor samt beskrivning-ar till ¨amnen, ¨ovningbeskrivning-ar och fr˚agor. Dock ¨beskrivning-ar det delvis n˚agot vi planerade att t¨anka p˚a i utvecklingen d˚a vi beh¨over beskriva en del funktionalitet f¨or framf¨or allt l¨arare som anv¨ander webbapplikationen, till exempel hur man skapar en ¨ovning. Det ska inte va-ra n˚agva-ra sv˚arigheter att skapa ett ¨amne, en ¨ovning eller vava-ra sv˚art att anv¨anda andva-ra funktioner p˚a hemsidan. F¨or elever ville vi ¨aven implementera kortare beskrivningar av bland annat rubriker f¨or att det ska bli l¨attare att navigera i webbapplikationen. Ut¨over

7 Krav och utv¨arderingsmetoder

detta gjorde vi ett antagande om att anv¨andarv¨anligheten i webbapplikationen kommer r¨att s˚a naturligt om vi f¨oljt de andra riktlinjerna f¨or inkluderande design som beskrivs. L¨angre beskrivningar av hur funktioner anv¨ands ans˚ag vi att vi d¨arf¨or inte borde beh¨ova implementera.

6.7

Till ˚at eleverna att ta pauser

McKnight framh˚aller hur viktigt det ¨ar om man har ADHD att kunna ta pauser i det man h˚aller p˚a med. Ett s¨att att implementera denna riktlinje ¨ar att l˚ata elever ta en paus mitt i en ¨ovning och sedan forts¨atta fr˚an samma fr˚aga vid ett senare tillf¨alle, vilket ¨ar det vi efterstr¨avat att implementera. M˚alet med att f¨olja denna riktlinje ¨ar att finna en balans s˚a att regelbundna pauser ger ¨okad motivation och fokus hos eleverna.

6.8

Minimera ¨

overraskningar

I designen planerade vi att f¨olja denna riktlinje genom att h˚alla utseendet i applikationen enhetligt. Anv¨andaren ska k¨anna igen sig ¨overallt och inte f¨orv˚anas ¨over att applikatio-nen pl¨otsligt har ett annat utseende. Till exempel ville vi anv¨anda samma f¨arger i hela applikationen f¨or ett enhetligt intryck, samt jobba med ett metodiskt uppl¨agg som n¨amns i 6.3 vilket ¨ar detsamma i hela applikationen. ¨Aven om funktionaliteten m¨ojligg¨or att det finns olika sorters fr˚agor, till exempel flerval och drag-and-drop, s˚a har m˚als¨attningen varit att dessa fr˚agor ska presenteras p˚a ett s˚a likartat s¨att som m¨ojligt.

7

Krav och utv ¨arderingsmetoder

Den slutgiltiga produkten kommer utv¨arderas med avseende p˚a design, funktionalitet och anpassning till att vara en PWA. Design och funktionalitet har utv¨arderats p˚a tre s¨att. Dels med hj¨alp av anv¨andartester och dels genom att sj¨alva resonera kring hur v¨al vi anser att kraven har uppfyllts.

7.1

Progressive Web Application

Som tidigare n¨amnt anv¨ander vi oss av verktyget Lighthouse f¨or att utv¨ardera kriterierna f¨or PWA. Lighthouse utf¨or flera automatiserade tester och sammanst¨aller en rapport ¨over hur v¨al en hemsida ¨ar anpassad till PWA-kriterierna. Resultatet presenteras dels

7 Krav och utv¨arderingsmetoder

f¨or de olika kriterierna individuellt och dels en sammanst¨alld rankning p˚a en skala fr˚an 0 till 100 f¨or hur mycket av en PWA en hemsida ¨ar. Vi anv¨ander oss ¨aven av verktyget Postman, som beskrivits utf¨orligare under avsnitt 5, f¨or att testa kopplingen mot API f¨or backend.

7.2

Design

V˚art projekt g˚ar ut p˚a att skapa grunden f¨or den digitala plattformen. Eftersom v˚ar m˚algrupp ¨ar h¨ogstadieelever med neuropsykiatriska funktionsneds¨attningar (NPF) s˚a har stort fokus legat p˚a en anv¨andarv¨anlig design. I avsnitt 5.3 har vi skrivit om inklu-derande design utifr˚an Lorna McKnights studie som bland annat behandlar hur design kan anpassas f¨or att inte exkludera m¨anniskor med ADHD. N¨ar vi sj¨alva utv¨arderar v˚ar produkt med avseende p˚a design har vi f¨or varje riktlinje vi arbetat efter l¨ast vad McK-night anser vara av vikt, vad vi planerade implementera f¨or att uppfylla detta och tagit st¨allning till hur v¨al det st¨ammer ¨overens med v˚ar slutgiltiga design.

7.3

Funktionalitet

Den funktionalitet vi implementerat utv¨arderar vi sj¨alva genom att, f¨or varje punkt i listan under avsnitt 8.1, utv¨ardera huruvida funktionen ¨ar anv¨andbar p˚a det s¨att som av-setts. I utv¨arderingen av funktionaliteten resonerar vi kring hur implementationen har m¨ojliggjort att uppfylla m˚alet f¨or webbapplikationen, som vi definierade i avsnitt 3.1. Det vi tar st¨allning till ¨ar allts˚a huruvida den implementerade funktionaliteten g¨or det m¨ojligt f¨or l¨arare att anv¨anda v˚ar webbapplikation som ett komplement till resterande undervisning. Vi v¨arderar ¨aven hur v¨al de olika delarna av funktionalitet ¨ar implemen-terade.

7.4

Anv ¨andartester

Anv¨andartesterna vi har gjort har utformats f¨or att utv¨ardera anv¨andarupplevelse i f¨or-h˚allande till design och funktionalitet. Vi har dessv¨arre inte haft m¨ojlighet att g¨ora anv¨andartester f¨or den t¨ankta m˚algruppen p˚a grund av tidsbrist. Vi har ist¨allet testat p˚a personer som studerar p˚a instutitionen f¨or informationsteknologi p˚a Uppsala universitet och som inte har n˚agon av de diagnoser som ¨ar relevanta. D¨arf¨or ¨ar anv¨andartesterna som vi gjort inte fullt s˚a relevanta som de skulle kunna vara, men kan ¨and˚a ge oss en indikation p˚a hur en anv¨andare upplever webb-applikationen. Vi har ¨aven valt att utf¨ora anv¨andartesterna p˚a personer i olika ˚aldrar och med olika teknisk bakgrund.

8 Systemets uppbyggnad

Testerna gick till s˚a att vi gav en anv¨andare uppgifter att utf¨ora p˚a applikationen och st¨allde fr˚agor efter uppgifterna utf¨orts. Uppgifterna som testarna ombads utf¨ora ¨ar kopp-lad till den funktionalitet som n¨amns i punktform i avsnitt 8.1. Specifikt bads testarna att logga in som b˚ade l¨arare och elev. Inloggad som l¨arare skulle testarna skapa en ¨ovning inneh˚allande en fr˚aga. Som elev ombads testarna att g˚a in och utf¨ora tv˚a olika typer av fr˚agor, flervals och drag-and-drop. Vi st¨allde fr˚agorna:

• Vad ¨ar ditt generella intryck av anv¨andarv¨anlighet? • Vad ¨ar ditt generella intryck av designen?

• Hur var det att navigera p˚a sidan?

• F¨orekom n˚agra st¨orande moment eller otydligheter?

Anv¨andarna fick ¨aven ta st¨allning till fyra p˚ast˚aenden hur v¨al de ans˚ag att detta st¨ammer p˚a en skala av inst¨ammer helt, inst¨ammer delvis, inst¨ammer inte alls. P˚ast˚aendena togs fram med utg˚angspunkt i de riktlinjer f¨or inkluderande design vi f¨oljt. Vi gav p˚ast˚aendena:

• Designen ¨ar minimalistisk • Designen ¨ar enhetlig

• Funktionaliteten ¨ar placerad d¨ar jag f¨orv¨antat mig • Jag tycker om f¨argvalen

Val av fr˚agor och p˚ast˚aenden gjordes mot bakgrund av de riktlinjer vi f¨oljt f¨or design. Eftersom vi inte utf¨orde tester p˚a m˚algruppen s˚a har fr˚agorna och p˚ast˚aendena inte an-passats f¨or h¨ogstadieelever. Det hade kunnat g¨oras genom att f¨orklara begrepp som till exempel vad anv¨andarv¨anlighet betyder.

8

Systemets uppbyggnad

Nedan beskriver vi vilka delar systemet best˚ar av, b˚ade ¨overgripande och mer detaljerat hur systemets kodstruktur ¨ar uppbyggd.

8 Systemets uppbyggnad

8.1

Overgripande systemstruktur

¨

Webbapplikationen best˚ar av flera olika delar. Grundl¨aggande finns ett grafiskt gr¨anssnitt (frontend) som inneh˚aller logiken f¨or hur uppgifter kan skapas, presenteras och utf¨ors. Frontend kopplas mot en databas, en del av backend d¨ar uppgifterna lagras. API:et kan definieras som l¨anken mellan frontend och backend och anv¨ands f¨or att h¨amta in-formationen fr˚an databasen som ska presenteras f¨or anv¨andaren i webbl¨asaren. Den grundl¨aggande funktionalitet som finns i systemet ¨ar:

• En l¨arar-vy och en elev-vy • Profilsida f¨or varje elevkonto

• Statistik f¨or utf¨orda uppgifter p˚a elevens profil • Olika typer av fr˚agor som kan skapas fr˚an l¨arar-vyn • Inloggningsfunktion f¨or elever och l¨arare

• H¨amta data fr˚an en databas via ett API

Webbapplikationen st¨odjer allts˚a tv˚a olika typer av anv¨andare, l¨arare och elever. De tv˚a typerna av anv¨andare har olika syfte och d¨arf¨or ¨aven olika funktionalitet i sin vy i systemet. Som l¨arare kan du skapa nya ¨amnen och ¨ovningar, och som elev kan du ta del av de ¨amnen och ¨ovningarna. Som vi beskrivit i avsnitt 3.3 s˚a ¨ar databas och API en avgr¨ansning i v˚art projekt som intressenten tog p˚a sig att utveckla. Den sista punkten handlar d¨arf¨or om implementation av anv¨andningen av det API:t. Det inneb¨ar till exempel att kunna spara text och filer som fyllts i av en l¨arare i ett formul¨ar, formatera det p˚a det s¨att API kr¨aver och spara som en fr˚aga eller att h¨amta data fr˚an databasen att visa p˚a elevens profilsida.

8 Systemets uppbyggnad

Figur 1: Ett ¨oversiktligt schema ¨over v˚art system. Fr˚an en startsida v¨aljer en anv¨andare att logga in som elev eller l¨arare. Anv¨andaren f˚ar d˚a tillg˚ang till ¨amnens inneh˚all med mera, som h¨amtas via en server fr˚an en databas. Servern och databasen ¨ar inte en del av

8 Systemets uppbyggnad

8.2

Kodstruktur

Filerna som webb-applikationen best˚ar av ¨ar uppbyggt efter en tr¨adstruktur som utg˚ar fr˚an filen index.js som rot. Index.js enda jobb ¨ar att skapa ett App-objekt. Det ¨ar App.js som ¨ar kopplat till en CSS-fil f¨or generell styling av hela webb-applikationen, och ¨aven skapar ett objekt, som har en egen CSS-fil f¨or styling. Eftersom sideBar-objektet ska vara synligt i alla vyer av systemet s˚a valde vi att det sideBar-objektet f˚ar rendera de ¨ovriga inneh˚allet. S˚a sideBar.js i sin tur renderar olika sidor av inneh˚all, som sedan skapar ytterligare objekt f¨or det inneh˚all som ska visas p˚a respektive sida. Sidebar ren-derar ocks˚a mer statiska objekt som header och footer som ¨ar samma f¨or alla sidor i applikationen.

8 Systemets uppbyggnad

Figur 2: Systemets ¨overgripande filstruktur. Inte alla systemets filer finns med i schemat.

Vi har ¨aven sidor som h¨amtar information fr˚an databasen (bland andra ’studentPage’ i elev-vyn) samt sidor som b˚ade h¨amtar och uppdaterar information fr˚an databasen (bland andra ’ ¨Amnen’ i l¨arar-vyn). Som man kan se i figur 2 s˚a har course.js m˚anga filer under sig i tr¨adstrukturen. Det inneb¨ar att course.js anropar den modul som finns under, som i sin tur anropar den under och s˚a vidare. Modulerna f¨or att hantera de sidor som h¨amtar data fr˚an och/eller uppdaterar databasen ¨ar mer komplexa p˚a det s¨attet ¨an de som endast presenterar information utan att beh¨ova kontakt med databasen. Det beror p˚a att data m˚aste skickas mellan de olika modulerna f¨or att sedan samlas upp och sammanst¨allas till r¨att format f¨or databasen.

9 Anv¨andargr¨anssnitt

9

Anv ¨andargr ¨anssnitt

V˚ar webbapplikation ¨ar uppdelad i n˚agra olika anv¨andargr¨anssnitt. Att webbapplika-tionen ¨ar uppdelad ¨ar n¨odv¨andigt d˚a den kommer att anv¨andas av olika m˚algrupper (bland annat l¨arare och elever). Dessa m˚algrupper har olika anledningar till att anv¨anda webbapplikationen och d¨armed kr¨avs olika funktionalitet f¨or olika anv¨andare. H¨ar pre-senteras de olika anv¨andargr¨anssnitten. I designen har vi jobbat p˚a att f˚a med tydliga avgr¨ansningar, enkla f¨arger och att minimera distraktioner. I kapitel 10.1 f¨orklarar vi mer om hur vi uppfyllt riktlinjerna f¨orklarade i kapitel 6.

9.1

Startsidan

Som anv¨andare kommer du till en startsida med namnet Hyperkonkret, inneh˚allande en kort v¨alkomnande text och tv˚a knappar f¨or att logga in, en f¨or l¨arare och en f¨or elever. L¨angst upp i v¨anstra h¨ornet finns en symbol/knapp, som vid knapptryck genererar en meny p˚a v¨anster sida av sk¨armen ¨over resterande inneh˚all. Sidomenyn f¨oljer med till vyn f¨or l¨araren och vyn f¨or eleven men dess inneh˚all varieras beroende p˚a vy. I menyn p˚a startsidan finns rubrikerna ’Hem’ och ’Om oss’. Vid tryck p˚a rubrikerna i menyn s˚a minimeras sidomenyn igen till symbolen i v¨anstra h¨ornet och inneh˚allet visas p˚a sk¨armen. ’Hem’ visar sidan f¨or inloggning medan ’Om oss’ visar en sida med informa-tion om f¨oretaget Hyperkonkret, vilka som skapat det och hur man kan komma i kontakt vid fr˚agor eller liknande.

9 Anv¨andargr¨anssnitt

Figur 3: Startsidan

9.2

L ¨ararvyn

Som l¨arare kommer du n¨ar du loggar in f¨orst till din profilsida, figur 4 som ger en ¨oversikt ¨over dina ¨amnen med m¨ojlighet att redigera ¨amnena. Du kan ocks˚a se hur m˚anga elever som ¨ar anslutna till respektive ¨amne och om de gjort ¨ovningarna som finns till ¨amnet. Varje ¨amne kan inneh˚alla en till flera uppgifter som skapats av l¨araren via ett formul¨ar p˚a en annan del av hemsidan. P˚a profilen kan man ocks˚a se kontots aktivitet, till exempel n¨ar man var inloggad senast. Ut¨over profilen har l¨ararvyn en sida med ¨amnen l¨araren skapat, d¨ar l¨araren ¨aven kan skapa ett nytt ¨amne. P˚a varje ¨amne kan man navigera sig vidare till de ¨ovningar som finns under respektive ¨amne. P˚a sidan med ¨ovningar kan l¨arare ¨aven skapa nya ¨ovningar.

9 Anv¨andargr¨anssnitt

Figur 4: L¨ararens profil

9.3

Elevvyn

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 alternaalterna-tivet 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 implemenin-terat 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.

10.3

Anv ¨andartester

Vi bad fem olika personer agera som testare. Personerna tillh¨orde inte den m˚algrupp webbapplikationen riktar sig till d˚a vi inte hade m¨ojlighet att n˚a ut till n˚agra inom v˚ar m˚algrupp. Dessa personer hade ingen f¨ordjupad kunskap om ADHD eller autism men vi ans˚ag det b¨attre att g¨ora anv¨andartester med dessa personer ¨an att inte g¨ora n˚agra alls. Som beskrivet i avsnitt 7 s˚a bad vi testarna logga in som l¨arare och elev.

Upp-10 Utv¨arderingsresultat

giften var att skapa en ¨ovning med en fr˚aga respektive utf¨ora en flervalsfr˚aga och en drag-and-drop-fr˚aga. Efter utf¨orandet fick de svara p˚a fr˚agor och p˚ast˚aenden ang˚aende sin anv¨andarupplevelse. Dessa beskrivs mer detaljerat i avsnitt 7 som handlar om ut-v¨arderingsmetoder.

Sammantaget hade testarna en positiv bild av anv¨andarv¨anligheten och att det var en-kelt att navigera p˚a sidan. ¨Aven designen hade anv¨andarna en sammantaget positiv bild av, f¨orutom en testare som tyckte att f¨argvalen var tr˚akiga och att fonterna var tr˚akig. Han f¨oreslog en f¨arg till bakgrunden ist¨allet f¨or gr˚askala. Testarna var ¨overens om att designen var minimalistisk och tydlig.

Ang˚aende st¨orande moment och otydligheter framkom flera olika synpunkter. En testare tyckte att ikonen f¨or sidomenyn inte var sj¨alvklar f¨or att f¨orst˚a att det fanns en sidomeny d¨ar. En annan testare tyckte att det var sv˚art att f¨orst˚a vad ’H’ betydde vid utf¨orande av uppgifter i elevvyn. Symbolen ’H’ ¨ar en knapp som kan tryckas p˚a f¨or att f˚a en tydligare beskrivning eller f¨orklaring av fr˚agan. En tredje testare tyckte att det borde vara tydligare att man ¨ar inloggad och att han inte f¨orstod vad han skulle g¨ora intuitivt n¨ar han skulle utf¨ora en drag-and-drop-fr˚aga.

10.4

Progressive Web Application

Vi har anv¨ant oss av verktyget Lighthouse f¨or att utv¨ardera kriterierna f¨or PWA. En sammanfattning av utv¨arderingen visas i figur 8 nedan. Resultatet av v˚ar utv¨ardering med hj¨alp av Lighthouse, som ¨ar ett v¨arde mellan 0 och hundra, gav oss v¨ardet 55. F¨or de elva tester som gjordes f¨or att utv¨ardera kriterierna s˚a blev 5 godk¨anda och 6 icke godk¨anda. Resultaten f¨or alla dessa tester ¨ar inte relevanta, till exempel handlar tv˚a av testerna om s¨akerhet med avseende p˚a om hemsidan anv¨ander sig av protokollen HTTP eller HTTPS. Detta ¨ar inte relevant eftersom att hemsidan ¨annu inte har en URL och d¨arf¨or varken anv¨ander sig av HTTP eller HTTPS utan vid testningen k¨ors lokalt. Ett av dessa tester som avser HTTP/HTTPS blev godk¨ant och ett blev icke godk¨ant, vilket vi tagit h¨ansyn till vid tolkningen av resultatet i avsnitt 11.2.4. De ¨ovriga godk¨anda testerna handlade om att v˚ar sida har inneh˚all ¨aven n¨ar JavaScript inte ¨ar tillg¨angligt och att den ¨ar responsiv och s¨aker. De ¨ovriga icke godk¨anda testerna handlade fr¨amst om att vi inte implementerat en s˚a kallad service worker, en komponent som ska g¨ora att hemsidan ¨ar tillg¨anglig offline och nedladdningsbar.

Enligt vad som tidigare planerats s˚a skulle vi f˚a tillg˚ang till ett API av v˚ara intressenter. Vi skulle sedan utv¨ardera hur v¨al vi lyckades anv¨anda oss av detta API med hj¨alp av verktyget Postman. Eftersom vi aldrig hann f˚a n˚agot API av v˚ar intressent s˚a har vi just nu inget s¨att att h¨amta/lagra information i n˚agon databas. D¨arf¨or gick det inte att g¨ora

11 Resultat och diskussion

n˚agon teknisk utv¨ardering av detta slag. V˚ar l¨osning har, i v¨antan p˚a API:et, varit att skapa filer med h˚ardkodade fr˚agor som vi sedan h¨amtar (p˚a liknande s¨att som vi skulle ha h¨amtat information fr˚an databasen).

Figur 8: Resultatet av Lighthouse med avseende p˚a kriterierna f¨or PWA

11

Resultat och diskussion

Vi presenterar h¨ar resultatet av v˚art projekt samt diskuterar alla delar av resultatet.

11.1

Resultat

V˚art projekt resulterade i en enkel och anv¨andbar webbapplikation med delar av den funktionalitet vi ville f˚a med i b¨orjan av projektet. Det finns en vy f¨or l¨arare och en f¨or elever d¨ar de kan f˚a en ¨oversikt ¨over sina ¨amnen och uppgifter. Som l¨arare kan du skapa flervalsfr˚agor best˚aende av text och bild. Som elev kan du utf¨ora flervalsfr˚agor, textsvarsfr˚agor och drag-and-drop-fr˚agor. Designen ¨ar enkel och minimalistisk i en och samma f¨argskala. Vi har utvecklat mycket funktionalitet, men inte just den som anv¨ands mellan frontend och backend eftersom vi inte f˚att tillg˚ang till databasen och dess API. Fr˚agor som kan utf¨oras fr˚an elevvyn ¨ar h˚ardkodade i egna filer, men h¨amtas d¨arifr˚an p˚a ett liknande s¨att som fr˚an en databas. Fr˚agor och ¨ovnignar kan skapas fr˚an l¨ararvyn, men inte sparas i databasen. L¨araren kan d¨aremot v¨alja vilken typ av fr˚aga hen vill skapa