Bacheloroppgave våren Av: Jon Vegard Heimlie, Pia Katrine Myrstad, Vijitharan Mehanathan og Preben Hafnor Gruppe 20 ULV

Transkript

1 Bacheloroppgave våren 2013 Av: Jon Vegard Heimlie, Pia Katrine Myrstad, Vijitharan Mehanathan og Preben Hafnor Gruppe 20 ULV

2 Forord Prosjektet Universelt LæringsVerktøy (ULV) beskriverutviklingen av en læringsplattform med fokus på universell utforming. Oppgaven er gitt av firmaet MediaLT, et firma som arbeider med å utarbeide universelt utformede løsninger. Vi har fått god hjelp og det er flere personer vi ønsker å takke. Vi ønsker å takke vår veileder Kirsten Ribu for all hjelp. Hun har vært svært relevant i forhold til vår oppgave og har gitt oss gode tips til forbedringer. Vi ønsker å takke Ronny Ringkilen for gode tips og noe hjelp med koden. Videre ønsker vi å takke alle de som har hjulpet oss med våre undersøkelser, intervjuer, testing og de som har hjulpet oss spre våre spørreundersøkelser. Til slutt ønsker vi å takke MediaLT for at de tok imot oss og ga oss vår bacheloroppgave. Hovedprosjektrapport Gruppe 20 - ULV Side 1

3 Innhold Forord... 1 Sammendrag Innledning Rapportens oppbygging MediaLT Tidligere prosjekter fra MediaLT Oppgaven Oppgavens problemstilling Motivasjon for oppgaven Bakgrunn Læringsplattformer Fronter It s Learning Moodle Universell utforming Diskriminering og tilgjengelighetsloven Hva er motoriske hindringer? Hva er en spesialløsning? Hva er en universell løsning? De syv prinsipper for universell utforming WCAG Hva regnes som god design? Fremgangsmåte og planlegging Risikoplan Milepælsplan Ansvarskart Prosessverktøy Metode Kartlegging Spørreundersøkelser Intervju Skissering UML-Modellering Use-Case Aktivitetsdiagram Prototyping Hovedprosjektrapport Gruppe 20 - ULV Side 2

4 4.7. Personas Brukertesting Forberedende undersøkelser Resultatet fra kartlegging av eksisterende verktøy Resultat fra spørreundersøkelser Resultat av intervjuer Videoundervisning Kravspesifikasjon Skisseringen UML-Modeller Use Case Aktivitetsdiagram Kravspesifikasjon Må, Bør og Fint å ha Funksjonelle krav Løsningen Prototypen Testing med personas Testing med brukere Hva gikk vi vekk fra i ettertid? Løsningen Grensesnitt Hvordan oppfyller grensesnittet kravene til WCAG 2.0? Testing med personas Testing med brukere Diskusjon Reliabilitet Refleksjon Kjernen i et LMS Tekststørrelse og kontrast Tilbakemelding fra oppdragsgiver Prosjektets kvalitet Arbeidet videre Tilbakemeldinger Tilbakemelding fra brukertesten på high-fidelity prototypen Tilbakemelding fra brukertester på ULV Konklusjon Hovedprosjektrapport Gruppe 20 - ULV Side 3

5 10. Referanser Teknisk spesifikasjon Verktøy Programmering Ikke-funksjonelle krav Kodeforklaring Kodestandard Sikkerhet Oppbygning Brukerveiledning Generell brukerveiledning Brukerveiledning for lærer Brukerveiledning for administrator Vedlegg I. Faglig relevans II. Use case-beskrivelser III. Spørreundersøkelser IV. Verktøy til Fronter og It s Learning V. Spørreundersøkelsen til lærer VI. Innholdet i CD-en Hovedprosjektrapport Gruppe 20 - ULV Side 4

6 Sammendrag Prosjektet ULV har handlet om å utarbeide en læringsplattform med et fokus på universell utforming. Noen brukere har i dag behov for en løsning,fordi de ikke klarer å benytte dagens plattformer. Eksempler på grunner erdårlig navigasjon gjennom et rotete grensesnitt og overflødig informasjon. For å unngå dette er det viktig å følge kravene til WCAG 2.0, ettersom dette er en standard som hjelper utviklere å tilpasse system til brukernes behov. Gjennom prosjektet har det blitt benyttet metoder somspørreundersøkelser, prototyp og brukertester for å innhente krav til oppbygging av en kravspesifikasjon. Resultatet fra metodene viser til at det fortsatt er et behov for å utvikle en god læringsplattform. Gjennom å benytte kravspesifikasjonen har vi utviklet en kjørende prototype, ULV. Vårt mål har ikke vært å utvikle en ferdig løsning, men et produkt som vår oppdragsgiver, MediaLT, kan videreutvikle. Læringsplattformen, som med tre forskjellige rettighetsbrukere, er godt på vei til å oppfyllekravene til WCAG 2.0. Produktet ULV er tilgjengelig fra denne linken: Brukernavn og passord for lærer: ola / passord Brukernavn og passord for student: kari / passord Innlogging for administrator er på en separat side og kan hentes fra denne linken: Brukernavn og passord for administrator:admin / passord Hovedprosjektrapport Gruppe 20 - ULV Side 5

7 1. Innledning 1.1. Rapportens oppbygging Oppbyggingen er skrevet slik at leseren skal kunne følge prosjektet fra oppstart, gjennom utvikling og til avslutning. Prosjektrapporten er skrevet med fokus på universell utforming; hvert bilde blir beskrevet med tekst. Kapittel 2, (Bakgrunn): Bakgrunnen for prosjektet presenteres. Forklaring av faglige ord og uttrykk relevante til prosjektet forklares. Kapittel 3, (Framgangsmåte og planlegging): En presentasjon av arbeidsmetoder og prosjektplanleggingen. Styringsdokumenter vises for å forklare prosessen til gruppen gjennom prosjektet. Kapittel 4, (Metoder): En redegjørelse for de metoder vi benyttet for å utarbeide kravspesifikasjonen til produktet. Kapittel 5, (Forberedende undersøkelser): Informasjonsinnhenting for oppbygging av kravspesifikasjon. Kapittel 6, (Kravspesifikasjon):Krav som er må, bør og fint å ha og funksjonelle krav. Kapittel 7, (Løsningen):Hi-fi prototype, beskrivelse av løsning og brukertesting Kapittel 8, (Diskusjon):Diskusjon om arbeidsprosess og resultater. Kapittel 9, (Konklusjon) Kapittel 10, (Referanser) Kapittel 11, (Teknisk spesifikasjon):verktøy og programmeringsspråk brukt. Ikke funksjonelle krav. Kodeforklaring. Kapittel 12, (Brukerveiledning) Vedlegg:Alle dokumenter ikke publisert i rapporten MediaLT Vår oppdragsgiver var Media Lunde Tollefsen A/S, kjent som MediaLT. Bedriften på fem ansatte er et foretak stiftet av daglig leder Magne Lunde og forskningsleder Morten Tollefsen. MediaLT har en visjon om å gjøre begrensninger til muligheter. Bedriften ønsker å endre systemer med dårlige utviklede løsninger og gjøre det mulig for flere å få den samme opplevelsen gjennom nye universelt utformede løsninger. Hovedprosjektrapport Gruppe 20 - ULV Side 6

8 MediaLT tilbyr tjenester og produkter for å forbedre funksjonshemmedes levesituasjon i Norge og i resten av verden gjennom nyskapning og innovasjon. MediaLT både leder og deltar i nasjonale og internasjonale prosjekter, og forskning og innovasjon legger grunnlaget for alt deres arbeid. Bedriften satser på universell utforming og IKT for funksjonshemmede. Bedriften samarbeider med en lang rekke samarbeidspartnere deriblant flere utdanningsinstitusjoner. Høgskolen i Oslo og Akershus er en av samarbeidspartnere og MediaLT har flere ganger hatt forelesninger på skolen, blant annet i faget Menneske Maskin Interaksjon(MMI). Det var gjennom dette faget vi først ble kjent med bedriften. Bedriften holder kurs om universell utforming, design, programvare (Datakortet) og opplæring av datatekniske hjelpemidler Tidligere prosjekter fra MediaLT MediaLT har gjennom årene hatt prosjekter med variasjon i både størrelse og omfang. Et eksempel er KUBA (Kunstige Barnestemmer), et forprosjekt brukt til å finne ut hvordan utvikle en norsk, syntetisk barnestemme og om behovet for dette eksisterer. Et annet prosjekt er FRES (FREmtidens Synstolkning) med mål om å øke tilbudet av synstolket norsk film, sammenlignet med tilbudene fra andre land. Synstolkning er en metode hvor en tolk beskriver handlingen i en film for blinde og svaksynte. Dette gjør at de får oppleve filmens handling selv om synet ikke er mulig å benytte Oppgaven MediaLT ønsket at vi skulle forske videre på en undersøkelse utført av firmaet FunkaNu. Vi skulle se om det var mulig å utvikle en læringsplattform, med bedre tilpasninger enn dagens løsninger og med et større fokus på universell utforming. For at en løsning skal være universelt utformet må den oppfylle kravene til WCAG 2.0. Vår oppgave var å utvikle en kravspesifikasjon, og for å gjøre dette måtte det benyttes diverse metoder, blant annet spørreundersøkelser og brukertesting. Til slutt skulledet utvikles en løsning tilpasset de kravene vi hadde funnet Oppgavens problemstilling Det er et stort potensiale for utbedring av læringsplattformer. Vi ønsket å finne ut om det var mulig å utarbeide en løsning med de verktøy som definerer en læringsplattform, og samtidig sørge for at løsningen blir utformet universelt ved å følge WCAG2.0.Problemstillingen er Hovedprosjektrapport Gruppe 20 - ULV Side 7

9 derfor: Hvordan kan vi i samarbeid med MediaLT utvikle en læringsplattform hvor kravene til universell utforming oppfylles? Motivasjon for oppgaven Vi har nå i flere år benyttet læringsplattformene Fronter og It s Learning og vi mener det er et stort potensiale for forbedring. Fronter, læringsplattformen vi benytter på HiOA i dag kan til tider virke noe rotete og vi har hatt problemer med å forstå hvordan ting er plassert og mener at enkelte verktøy er overflødige. Et eksempeler kontaktlisten som ingen av oss har benyttet.videre gjorde MediaLT oss klar over de eksisterende problemene med tilgjengeligheten. Fronter benytter frames, noe som gjørdet vanskelig å bruke stemmeleser på plattformen.denne typen oppgave er også svært relevant i forhold til hva vi ønsker å arbeide med i fremtiden. Hovedprosjektrapport Gruppe 20 - ULV Side 8

10 2. Bakgrunn I 2011 gjennomførte FunkaNu en undersøkelse av læringsplattformer for Norges Blindeforbund. Utifra informasjonen samlet inn på det tidspunktet kom MediaLT fram til at det ikke var en eneste læringsplattform de kunne anbefale i forhold til universell utforming. Det må påpekes at MediaLT ikke visste omfanget rundt rapporten til FunkaNu og de ønsket at vi skulle gjennomføre en videre undersøkelse. FunkaNu skrev at Fronter var den plattforming med største tekniske problemer, mens PedIT og It s Learning ikke var godt pedagogisk. Ut ifra denne undersøkelsen ble det konkludert med at det er rom for forbedring. MediaLT har hatt et ønske om å arbeide videre med undersøkelsen og har gjort forsøk på å få støtte fra forskjellige universitet med innspill rundt deres situasjon. Resultatene viste seg å være fattige, for flere svarte at de ønsket å vente med å forandre deres plattformer. MediaLT tok kontakt med firmaet Uloba, en bedrift som jobber med å endre samfunnets oppfatning av funksjonshemmede og skape en større mulighet for funksjonshemmedes egne liv. MediaLT sendte en rapport med undersøkelsene de selv hadde gjort videre til Uloba, for å få dem til å satse på en løsning i samarbeid med MediaLT. Uloba viste først interesse, men trakk seg til slutt ettersom de ikke hadde ressurser til å følge opp arbeidet. Oppgaven ble stående uten arbeidsgiver, og MediaLT bestemte seg for selv å være arbeidsgivere, og gjøre oss til arbeidstakerne. MediaLT forklarte at det eksistererforbedringspotensialer på læringsplattformene ettersom de ikke oppfyller kravene til universell utforming. Firmaet ønsket at vi skulle fokusere på læringsplattformene It s Learning og Fronter, ettersom det er de læringsplattformene mest brukt i Norge. I tillegg ønsket MediaLT at vi også skulle teste ut Moodle ettersom dette var plattformen FunkaNu mente at var nærmest tilpasset en universell utforming Læringsplattformer Læringsplattformer (LMS, Learning Management System ), er internettbaserte pedagogiske verktøy, ofte brukt av utdanningsinstitutter som videregående skoler, høgskoler og universiteter. Plattformene som hyppig blir brukt av både elever/studenter og lærere er kun tilgjengelig fra internett. Fronter, benyttet ved høgskolen i Oslo og Akershus (HiOA) og Universitet i Oslo (UiO), og It s Learning, benyttet ved Handelshøyskolen BI, er eksempler på aktivt brukte læringsplattformer. Hovedprosjektrapport Gruppe 20 - ULV Side 9

11 Gjennom læringsplattformer kan elever og lærere samhandle og gjennom beskjeder og forum kommunisere. Studenten skal gjennom plattformen kunne eksempelvis holde seg oppdatert på kurs, levere oppgaver, og senere få tilbakemelding på samme oppgave. Lærere har mulighet til å legge ut beskjeder og oppgaver, og prøver med frister i det spesifikke faget til sine studenter. Læringsplattformene har normalt egne mailservere hvor studentene kan sende mail til lærerne med spørsmål om fag og annet Fronter Fronter (tidligere ClassFronter) er en norskutviklet nettbasert læringsplattform. Fronter blir i dag brukt i over 25 land og finnes på over 25 språk. Det er ca. 1.4 millioner brukere som månedlig logger inn på Fronter. I 2009 ble Fronter kjøpt opp av Pearson, et av verdens største informasjons-, utdannings- og mediekonsern. I dag har Fronter 80 ansatte som arbeider hovedsakelig med utvikling, kvalitetssikring, drift og det nordiske salget av plattformen. I tillegg har Fronter et utviklingsteam på 20 personer It s Learning It s Learning er på lik linje med Fronter også en norskutviklet nettbasert læringsplattform utviklet av en gruppe dataingeniørstudenter som gikk siste året på Høgskolen i Bergen(HiB). Studentene utviklet plattformen i sin bacheloroppgave og det endte som første versjon av It s Learning. Plattformen har i ettertid blitt videreutviklet noe som førte til suksess. Den enorme etterspørselen etter pedagogiske verktøy førte til etableringen av et av verdens raskest voksende teknologiselskaper Moodle I likhet med Fronter og It s Learning så er Moodle også en nettbasert læringsplattform. Moodle skiller seg fra Fronter og It s Learning ved at den er en open-source programvare. Moodle er ikke kopi-beskyttet og alle har derfor muligheten til å kopiere og modifisere Moodle. Moodle brukes av over læresteder og har over 60 millioner brukere på verdensbasis. I Norge så er ikke plattformen kjent og dette er nok grunnen til at veldig få skoler i landet benytter Moodle. Moodle er et LMS som har hatt et noe større fokus på universell utforming. Hovedprosjektrapport Gruppe 20 - ULV Side 10

12 2.2. Universell utforming Universell utforming handler om å utvikle løsninger fungerende for alle, og ikke bare løsninger bygget for de fleste og spesialløsninger for de resterende. FN-konvensjonen har skrevet en definisjon rundt rettighetene til mennesker med nedsatt funksjonsevne: Med universell utforming menes: utforming av produkter, omgivelser, programmer og tjenester på en slik måte at de kan brukes av alle mennesker, i så stor utstrekning som mulig, uten behov for tilpassing og en spesiell utforming. Universell utforming skal ikke utelukke hjelpemidler for bestemte grupper av mennesker med nedsatt funksjonsevne når det er behov for det. - (Frode Eika Sandnes, Universitetsforlaget 2011, side 29). I dag er det et stort problem at mange mennesker ikke klarer å benytte eksisterende løsninger ettersom de ikke er tilpasset deres behov. Et eksempel er blinde mennesker som skal kjøpe billett på billettautomat. I Norge er flere billettautomater utstyrt med touchfunksjonalitet, for en raskere handel. Touchteknologi fjerner følelsen av å trykke på knapper og det blir umulig å navigere systemet uten å benytte synet. Alle reisende som ikke har mulighet til eller ønsker å kjøpe billett i skranke eller ombord er nødt til å handle gjennom disse automatene. Ofte er det også slik at det følges et ombordtillegg i prisen. Bedriften Ruter er en av de som tar i bruk slike automater Diskriminering og tilgjengelighetsloven. LOV nr. 42 I 2008 kom Diskriminering- og tilgjengelighetsloven. Denne loven har et formål om å fremme likestilling og likeverd. Hovedgrunnen til dette er at funksjonshemmede har blitt satt til side av samfunnet og fått utarbeidet spesialløsninger tilpasset deres handikapp. Diskriminerings- og tilgjengelighetsloven definerer universell utforming juridisk: Med universell utforming menes utforming eller tilrettelegging av hovedløsningen i de fysiske forholdene, herunder informasjons- og kommunikasjons (IKT), slik av virksomhetens alminnelige funksjon kan benyttes av flest mulig. (Frode Eika Sandnes, Universitetsforlaget 2011, side 29). Loven gjelder for alle samfunnsområder og takket være denne må offentlig virksomhet arbeide for å gjennomføre løsninger av universelt utformede proporsjoner. Hovedprosjektrapport Gruppe 20 - ULV Side 11

13 Hva er motoriske hindringer? Motoriske hindringer betyr fysiske problemer. Lavere motorikk gjør at et menneske kan oppleve hindringer i det daglige liv. Eksempler er å kunne bevege seg opp trapper, skrive på datamaskiner og lignende. Det kan bli både vanskelig og vondt å utføre de oppgaver som må gjøres. Det er flere mennesker som har sykdommer hvor enhver bevegelse skaper smerte. Derfor er det ønskelig for disse å benytte løsninger hvor en ikke må utføre mye fysisk arbeid. Dette inkluderer særlig mennesker innenfor sykdomsgruppen muskel- og leddsykdommer. Muskel- og leddsykdommer gjør at bevegelser kan bli svært smertefulle, noe som gjør at det tar lenger tid å få utført en handling. Sykdommene kan skape skjelvinger og det kan bli vanskeligere å trykke hvis grensesnittet ikke er utarbeidet riktig. En bruker med skjelvinger kan risikere å skjelve så mye at han trykker feil og dermed blir nødt til å trykke seg tilbake. Brukeren kan videre trykke feil igjen og dette kan pågå en god stund uten noe oppnåelig resultat.multippel Sklerose (MS) er et eksempel på en sykdom innenfor denne gruppen. Om en er lammet av MS er det vanlig å oppleve lammelser og koordinasjonsvansker. Leddgikt er et annet eksempel innenfor denne sykdomsgruppen. Detteer en sykdom hvor bevegelser i ledd gjør vondt og anstrengelse påvirker smerten. Noen opplever problemer hvor de hindres fra å gjøre ting, for eksempel å skrive på datamaskin. Årstidene kan også påvirke sykdommen. Om vinteren drar gjerne mennesker med leddgikt på ferie til varmere strøk fordi kulde gjør smerten verre. Blind- og svaksynthetviser til mennesker med nedsatt eller ingen synsevne. Disse menneskene har større problemer med dagens teknologi enn mange andre fordi samfunnet ikke alltid tilpasser seg deres behov. Hvis synsevnen er for svak velger disse brukerne å benytte hjelpemiddelteknologi for avlesing av tekst og nettsider. Det er viktig for disse brukerne at grensesnittet er utarbeidet godt slik at hjelpemiddelteknologien klarer å gi riktig avlesning og hjelp til navigasjon. Hvis en begynner å undersøke på hva det vil si å ha en nedsatt funksjonsevne, vil en til slutt oppdage at de fleste på en eller annen måte har en nedsatt funksjonsevne. For eksempel er mye teknologi i samfunnet ikke tilpasset skeivhendte ogfolk som er fargeblinde. Hovedprosjektrapport Gruppe 20 - ULV Side 12

14 Hva er en spesialløsning? En spesialløsning er et system bygget for en konkret gruppe mennesker. Løsningen fungerer oftest bare for dem og den er bygget for at mennesker med motoriske problemer skal kunne oppnå den samme muligheten andre mennesker har. Det har blitt drøftet om dette er diskriminerende, noe flere bevegelseshemmede har kjempet for å påpeke. Et eksempel er handicaptoalett bygget for handikappede. Flere mener at spesialløsninger ikke er fullverdige løsninger ettersom de skiller seg ut fra samfunnet. Takket være Diskriminering- og tilgjengelighetsloven bygges det i dag ikke mange flere spesialløsninger, men man har gått over til universelle løsninger Hva er en universell løsning? Universelle løsninger er noe bygget for så mange det lar seg gjøre. En universell løsning går vekk fra spesialløsningen ettersom den kun dekker en spesifikk gruppe, eller et begrenset antall. En universell løsning erstatter derfor to typer løsninger, den vanlige og den spesielle løsningen, og den eksisterer i stedet som en generell løsning. Gjennom universell utforming skal løsningen være forståelig og lett brukbar. En førstegangsbruker skal kunne benytte løsningen og uten noen kvalifikasjoner forstå hvordan den skal benyttes. Et typisk eksempel på en universell løsning er ramper. Dette fungerer som en trapp og samtidig klarer brukere med rullestol å komme seg opp og ned. Det er dermed en og samme løsning De syv prinsipper for universell utforming. Det å skulle gjøre et system tilgjengelig for så mange som mulig er en prosess i seg selv. Det var opprinnelig snakk om at universelle løsninger skulle benyttes til arkitektur og utearealer, men blir nå benyttet på systemer generelt. Det er stadfestet 7 prinsipper for universell utforming: 1. Like muligheter for bruk - uansett ferdigheter skal alle brukere ha lik mulighet til å benytte alle deler av systemet. 2. Fleksibel i bruk- gjelder for alle, uansett hvilke preferanser og ferdigheter brukeren har fra før. 3. Enkel og intuitiv i bruk- Det skal være enkelt for brukeren å benytte systemet. En bruker som aldri før har benyttet systemet skal kunne klare å oppnå ønskede resultater. Hovedprosjektrapport Gruppe 20 - ULV Side 13

15 4. Forståelig informasjon - utformingen skal vise informasjon på en forståelig måte for brukeren. 5. Toleranse for feil - systemet skal håndtere feil på en måte som minimerer faren for skader eller alvorlige konsekvenser. 6. Lav fysisk anstrengelse - brukeren skal kunne benytte systemet med lite anstrengelse og besvær. 7. Størrelse og plass for tilgang og bruk- det skal være nok størrelse og plass på systemet for å gjøre det mulig for brukeren å få tilgang og benytte systemet til det som er ønskelig. Dette er da uavhengig av brukerens mobilitet WCAG WCAG-kravene (Web Content Accessibility Guidelines)definerer hvordan en webside kan gjøres mer tilgjengelig for personer med nedsatt funksjonsevne. Eksempler er løsninger for blinde og svaksynte, døve og hørselshemmede, personer med lærevansker, kognitive funksjonsnedsettelser, nedsatt motorikk og talevansker. Gjennom WCAG kravene øker vi brukervennligheten til webinnhold og samtidig gjøres det mulig for flere å benytte flere områder på internett. I WCAG 2.0 brukes fire prinsipper for tilgjengelig web-innhold: 1. Gjenkjennbart- brukergrensesnittet må være lagt opp slik at brukere som tidligere har benyttet lik teknologi skal kunne kjenne seg igjen i samme type systemer. 2. Anvendelig- brukergrensesnittet skal være oppnåelig for alle. 3. Forståelig - informasjonen og brukergrensesnittet må være forståelig og lett å sette seg inn i. 4. Robust - det skal være mulig å presentere innholdet på ulike plattformer, og gjennom hjelpemiddelteknologi. Det har videre blitt opprettet 12 retningslinjer for å støtte og bedre forklare prinsippene: 1. Gjenkjennbart 1.1Alternativ tekst:gi tekstalternativer til alt av innholdet som ikke inneholder tekst, eksempler er tekst til videoklipp, stor skrift, tale, eller enklere språk Tidsbaserte medier:ha alternativer til medier av type lyd og video Konfigurerbart: Presentere innholdet på alternative måter uten at det går utover struktur og informasjon som oppgis. Hovedprosjektrapport Gruppe 20 - ULV Side 14

16 1.4. Gjenkjennelig: Gjør det enklere for brukeren å kjenne igjen innholdet. 2. Anvendelig 2.1. Tastatur: Skal være mulig å benytte tastaturet til alle funksjonaliteter Nok tid: Brukeren skal ha nok tid til å oppfatte innholdet Anfall: Utform innhold slik at det ikke kan forårsake epileptisk anfall Navigerbart:Ha et oppsett som gjør det lett å navigere og finne innhold. 3. Forståelig 3.1. Lesbart: Teksten på siden er lesbar og forståelig Forutsigbart: Nettsiden skal fungere på forutsigbare måter Input assistanse:tekst hjelper brukere med å unngå feil i deres arbeid. 4. Robust 4.1. Kompatibilitet: Bra kompatibilitet til eksisterende og fremtidige plattformer, og hjelpemiddelteknologi Hva regnes som god design? Det finnes 13 prinsipper for god design og disse er igjen delt opp i 4 grupper: persepsjon, mentale modeller, oppmerksomhet og hukommelse, alt etter hva designet skal støtte. God design brukes for å gjøre siden mer oversiktlig slik at brukeren kan navigere raskt og få en kjapp oversikt. De perseptuelle prinsippene: De perseptuelle prinsippene omhandler hvordan man oppfatter ting. 1. Tydelighet: All tekst skal være forståelig og tydelig. Lydklipp og lyd generelt skal være lett å høre. 2. Unngå bedømming uten noe å sammenligne med: Når noe går over fra en ting til en annen er det ikke like enkelt å få det med seg, for eksempel farger som glir over i hverandre. 3. Design for top-down-prosessering: Legge opp til at ting er slik brukere er lært opp til at det alltid har vært. Hvis noe uforutsett skjer, bør dette støttes med en tydelig forklaring. Hovedprosjektrapport Gruppe 20 - ULV Side 15

17 4. Gevinst gjennom overlapping: Unngå forstyrrelser eller overseelse ved å presentere viktig informasjon gjennom flere kanaler. Et eksempel er om man ikke ser at den røde lampa blinker, hører man ihvertfall alarmen gå av når noe uventet skjer. 5. Unngå forveksling i likheter: Det er viktig at det er stor nok forskjell mellom indikatorer slik at de ikke kan forveksles med hverandre. En indikator er en representant for noe annet, for eksempel en pil på GPS-en representerer deg eller bilen din på kartet. Mentale modeller: Mentale modeller er en beskrivelse av hvordan mennesker ser for seg at noe skal fungere. 6. Utseenderealisme: En indikator skal se ut som den variabelen den skal representere, for eksempel visuelle indikatorer på knapper (en konvolutt for meldinger på mobilen) 7. Bevegelsesrealisme: Minner om forrige prinsipp, men handler i stedet om bevegelse. Et eksempel er en pil på GPS-en som viser hvor du ligger på veien.den bør være så nøyaktig som mulig slik at du vet hvor du er og hvor du skal til enhver tid. Oppmerksomhet: Oppmerksomhet er design laget for å tiltrekke seg oppmerksomhet fra brukeren. 8. Minimer kostnaden som trengs for å skaffe informasjon: En bruker skal slippe å benytte for mye tid på å finne riktig informasjon.informasjonen bør ligge lett synlig og tilgjengelig.et godt eksempel på dette er dashbordet på en bil hvor det gis beskjed om nesten alle bilens behov, noe som sparer føreren for selv å måtte gå ut og sjekke jevnlig at bilen er i stand. 9.Like funksjoner henger sammen: Funksjoner som ofte brukes sammen bør plasseres sammen. Dette er spesielt viktig for funksjoner avhengige av hverandre. De kan kobles sammen på forskjellige måter, og eksempler er fargekoder, symboler eller plassering. Det er viktig at sammenkoblingen ikke går ut over tydeligheten til hver enkelt funksjon. Hovedprosjektrapport Gruppe 20 - ULV Side 16

18 10. Varier typen innhold: Unngå å få for mye tekst uten illustrasjoner. Store mengder tekst kan gjøre det slitsomt å oppta informasjonen for leseren. Det kan også benyttes andre informasjonstyper enn illustrasjoner, for eksempel lyd eller video. Hukommelse: Designet skal ta hensyn til menneskers hukommelse. 11. Kjent kunnskap: Det er enklere å huske og å bearbeide informasjon en kan relatere seg til, da en kan finne likheter fra tidligere erfaringer. 12. Forutsigbar assistanse: Det kan være veldig mye hjelp i å få presentert en klar vei videre fra der en er. Det hjelperå forstå hvordan og hvorfor en skal interagere med systemet slik en gjør. 13. Vær konsistent: Bruk samme symbol eller design brukeren allerede er vant med, ettersom det ellers kan skape forvirring. Hovedprosjektrapport Gruppe 20 - ULV Side 17

19 3. Fremgangsmåte og planlegging Noe av det første utarbeidet av dokumentasjon i prosjektet var styringsdokumentene. Styringsdokumenter er en samling med dokumenter brukt til å beskrive prosessen i et prosjekt. Gjennom styringsdokumenter bestemmes det hvordan arbeidet i prosjektet skal foregå, hva som kan gå galt og forskjellige ansvarsområder deltakerne i gruppen har. Vi har valgt å benytte disse styringsdokumentene: Risikoplan Milepælsplan Ansvarskart Gruppesiden med loggføring er tilgjengelig på Risikoplan Risikoplanen beskriver risikoer en prosjektgruppe ser sannsynlig at kan oppleves i løpet av prosjektperioden. En typisk risikoplan kjennes igjen ved attributtene; risiko, sannsynlighet, konsekvens og tiltak. Risiko: den faktiske risikoen prosjektgruppen kan oppleve. Sannsynlighet: sjansen for risikomomentet. Konsekvens: hva som vil skje ved risikohendelsen. Tiltak: hva som burde gjøres om risikoen forekommer, men også hva en kan gjøre for å forhindre at en risiko inntreffer. Risiko Sannsynlighet Konsekvens Tiltak Sykdom Høy Redusert arbeidsinnsats/arbeidskapasitet, mer arbeid for andre. Mulig misnøye. Medlemmet hjelper til selv når han/hun er syk, eller resten fordeler på arbeidet. Mangler eller Middels-Høy Overtid, kan miste deadline. Mulig Gjennomgå stoff, feil misnøye. eget arbeid og oppgaver nøye og revurder ressurser. Medlemmer Middels-Høy Redusert arbeidskapasitet, fare Passe på å holde Hovedprosjektrapport Gruppe 20 - ULV Side 18

20 møter ikke for overtid. kontakt med medlemmene og gi klare og tydelige beskjeder. Tap av Middels Kritisk for prosjektet, kan føre til at Sørge for alltid å arbeid/data prosjektet ikke kan ferdigstilles. gjennomføre Må gjøre arbeid på nytt. backup og gjerne flere steder. Jobbe overtid Middels-Høy Misnøye og stress. Dele opp arbeidet. Konflikter Middels-Høy Vanskelig med å arbeide sammen, dårlig effektivitet. Eventuelle frafall fra gruppen. Ta tak i problemer tidlig. Benytt Samarbeidsavtale. Medlemmer Middels Fare for overtid eller at God planlegging. gjør ikke avtalt milepælsplanen må endres og vi arbeid. får mindre tid til etterfølgende oppgaver. Rekker ikke innlevering Lav Ikke bestått eller karaktertrekk. God planlegging, fokus på milepæler. Frafall fra Lav Arbeidsmengde øker per medlem. Ha god oversikt gruppen Omprioritere delløsninger, over kvaliteten på oppgaven kan arbeidsoppgaver. reduseres. Manglende Middels Bruker unødvendig tid til å Alle på gruppen må kompetanse komme fram til en løsning. være godt forberedt på oppgaver de blir tildelt. Problemer med Høy Bruke tid på å rette opp Teste koden før vi koding eventuelle feil eller mangler. laster det opp på server. Manglende Middels Vanskelig å fullføre Klare Hovedprosjektrapport Gruppe 20 - ULV Side 19

21 dokumentasjon prosjektrapport. Vanskelig for enkelte å sette seg inn i funksjonaliteten. retningslinjerfor dokumentasjon. Bruk av dagbok Milepælsplan En milepælsplan beskriver forskjellige tilstander i prosjekter. Gjennom milepælsplanen skal det være satt mål til hva prosjektgruppen skal ha oppnådd. Målene er gjennomgående i hele prosjektet og det er derfor viktig at målene satt er relevante og nøye tenkt igjennom. Gode mål kjennes igjen ved at de er SMARTe Spesifikke - Målene skal ha et definert og tydelig resultat som kan vises til senere i prosjektet, eller etter prosjektets slutt. Målbare - Det skal være mulig å gjenkjenne prosessene opp mot det satte mål. Alltid Oppnåelige - Det skal ikke være noen tvil på at målene er oppnåelige. Det er liten vits å sette mål som du selv vet ikke er oppnåelige Relevante - De skal være helhetlig relevante for prosjektet samtidig som de er viktige for utviklerne og oppdragsgiver. Tidsbegrenset - Det må være satt en tidsramme for målene. Fremdriftsplan: M1: Prosjektstart, uke 2 M2: Ferdigstille gruppesiden, uke 3 M3: Ferdigstille forprosjektrapporten, uke 4 M4: Låse resultater fra spørreundersøkelse, uke 13 M5: Levere statusrapport til MediaLT, uke 15 M6: Ferdigstille high-fidelity prototype, uke 16 M7: Ferdigstille kravspesifikasjonene, uke 18 M8: Dokument ferdigstilt, uke 20 M9: Kode ferdigstilt, uke 20 M10: Levere prosjektet, uke 22 Hovedprosjektrapport Gruppe 20 - ULV Side 20

22 Milepæl 1: Aktiviteter: Gruppen møtes og blir kjent Gruppen finner seg navn og prosjekt Gruppen møter veileder Gruppen møter oppdragsgiver Omfatter roller og beskrivelse av prosjektet, hvordan vi jobber og hvilke roller de forskjellige har i gruppa. Milepæl 2: Aktiviteter: Gruppesiden opprettes Ha opprettet en gruppeside hvor de forskjellige dokumentene skal lastes opp. Her står det dessuten litt om gruppemedlemmene og prosjektet. Milepæl 3: Aktiviteter: Gjøre ferdig forprosjektrapporten som omhandler litt informasjon rundt prosjektet ogoppdragsgiver. Leveranse: Forprosjektrapport Milepæl 4: Aktiviteter: Sette opp spørsmål til spørreundersøkelse Sende disse ut til forskjellige skoler Samle data Låse resultatene av spørreundersøkelsen Hovedprosjektrapport Gruppe 20 - ULV Side 21

23 Milepæl 5: Aktiviteter: Ferdigstille en statusrapport til MediaLT Leveranse: Statusrapport Milepæl 6: Aktiviteter: Gjøre ferdig skisser som senere brukes til å fremstille en high-fidelity prototype Ferdigstille high-fidelity prototype Milepæl 7: Aktiviteter: Ferdigstille kravspesifikasjonene Starte brukertesting på prototypen Milepæl 8: Aktiviteter: Dokument ferdigstilt Sende dokumentasjon til rådgiver Milepæl 9: Aktiviteter: Kode ferdigstilt Vise programmet til MediaLT Milepæl 10: Aktiviteter: Levere prosjektet Leveranse: Hovedprosjektet i sin helhet Hovedprosjektrapport Gruppe 20 - ULV Side 22

24 3.3. Ansvarskart Et ansvarskart beskriver de forskjellige ansvarsområdene hvert gruppemedlem har. Vi valgte å benytte et ansvarskart for å stadfeste hva hvert gruppemedlem hadde ansvar for at ble gjort.kartet nedenfor viste fordelingen av ansvar i gruppen: Jon Vegard: Gruppeleder o Delansvarlig for dokumentering. o Delansvarlig for at logg er ført, timer og oppmøte registrert og at plan for neste dag skrevet. Jon ble naturlig valgt som gruppeleder fordi han på tidligere prosjekter har tatt ansvar, og har vist seg å være en pliktoppfyllende person som alltid møter opp. Han har også god kontroll på hva som skal gjøres til enhver tid, og at arbeidsoppgaver er fordelt. Vijitharan: Webansvarlig o Ansvarlig for at gruppesiden alltid er oppdatert. o Assisterende ansvar for koding. Vijitharan tok på seg ansvaret som webansvarlig fordi han liker å jobbe med koding i HTML og CSS. Pia: Dokumentansvarlig o Ansvarlig for at det er kontroll på dokumentene. o Delansvarlig for loggføring. Pia tok ansvaret som dokumentansvarlig ettersom hun er glad i å dokumentere. Gruppen mente hun var ryddig og pliktoppfyllende, noe som er gode egenskaper ved Hovedprosjektrapport Gruppe 20 - ULV Side 23

25 utarbeidelse og vedlikehold av dokumenter og mapper. Hun fikk også delansvar i loggskrivingen sammen med gruppeleder. Preben: Kodeansvarlig o Ansvarlig for ryddig kode og generell kontroll på koding av læringsplattformen. Tok ansvaret som kodeansvarlig fordi han synes programmering er interessant og gøy å jobbe med, og hadde et ønske om å bli bedre på dette. Backupansvarlig: Alle Hovedansvaret: Pia. o Ansvarlig for at alle dokumenter er tilgjengelige fra flere områder. Backup må gjennomføres minst en gang om dagen Prosessverktøy For å kunne liste opp de forskjellige arbeidsoppgavene og fordele arbeid er det viktig å benytte et godt verktøy. Vi valgte å benytte Trello. Gjennom dette nettbaserte verktøyet er det mulig å bedre visualisere de forskjellige fasene i et prosjekt. Videre kan en tilpasse arbeidsoppgaver til hver fase og samtidig fordele ansvar til hver arbeidsoppgave. Det er også mulig i hver fase å sette nivåsteg, slik at en oppgave som har blitt godkjent kan bli satt fra Forslag og over til Godkjent. Slik er det mulig å holde kontroll på alt som skal gjøres i prosjektet og tilpasse prosessen maksimalt. Trello er tilgjengelig på trello.com Hovedprosjektrapport Gruppe 20 - ULV Side 24

26 4. Metode I systemutvikling er det viktig å benytte seg av flere metoder og disse velges utifra midler, omfang og nødvendighet. Det er ikke nødvendigvis lurt å benytte mange metoder om prosjektets frister hindrer dette. Prosjektgruppen må derfor gjøre en vurdering før de begynner å utvikle systemet. Metodene brukes til å bygge en kravspesifikasjon, og kravspesifikasjonen brukes til å utvikle systemet. Vi bestemte metoder utifra hva oppdragsgiver ønsket og hva vi selv så som nødvendig. Ettersom dette var en utviklingsoppgave varbrukertesting viktig, og vi satte det i fokus. Det var også viktig med undersøkelser og en god visualisering av systemet. Vi bestemte oss for å benytte de metodene nedenfor og vi vil i dette kapittelet redegjøre for dem. Kartlegging Spørreundersøkelser Intervju Skisser UML-modellering o Use Case Diagram o Use Case-Beskrivelser o Aktivitetsdiagram High Fidelity Prototype Brukertesting 4.1. Kartlegging Kartlegging er en metode vi benyttet for å utforske læringsplattformene Fronter, It s Learning og Moodle. Både administrasjon-, lærer- og studentbruker på hver plattform ble testet så langt det lot seg gjøre. Alle i gruppen deltok i kartleggingen for å få et inntrykk av hver plattform. Vi benyttet stemmeleserverktøy for å få en opplevelse av hvordan det er å benytte plattformene uten bruk av syn Spørreundersøkelser Vi benyttet også spørreundersøkelser for å få en dekkende tilbakemelding fra studenter om deres bruk av læringsplattformene. Vi utviklet spørreundersøkelser gjennom verktøyet Hovedprosjektrapport Gruppe 20 - ULV Side 25

27 GoogleDocs.Alt av resultater fra spørreundersøkelsen ble statistisk presentert i verktøyet.vi kontaktet HIOA, UIO og BI for å få tillatelse til å sende ut spørreundersøkelsene. I undersøkelsen var fokus på anvendeligheten til plattformene Fronter og It s Learning. Vi prøvde å finne ut hva brukerne benyttet av verktøy i deres læringsplattform slik at vi videre kunne bruke resultatene til å bestemme hvilke funksjoner vi skulle ha i systemet.vi satte også Fronter og It s Learning opp mot hverandre og spurte brukerne om hvem av dem som ble foretrukket Intervju Vi gjennomførte en blanding av en spørreundersøkelse og et intervju. Vi lot lærerne få svare på spørreundersøkelsen for så å intervjue dem. Vi brukte en fokusert intervjuteknikk, noe som betyr at vi avgrenset intervjuet til å innhente informasjon rundt hva intervjuobjektet mente om spesifikke ting. Vi var to personer som utførte intervjuet, en intervjuer og en observatør. Observatørens oppgave var å notere og passe på at intervjuer holdt seg til de spørsmålene satt. Vi hadde laget en kontrakt som sa at intervjuobjektet ville forbli anonymt og dette ble skrevet under av både intervjuer og intervjuobjekt Skissering En skisse er en metode brukt til å samle ideer og tanker og prøve å illustrere dette.en skisse kan gjerne være uferdige og kjappe tegninger. Vi har benyttet spesifikke skisser ettersom de er bedre til å illustrere enn vage skisser er.her ligger et eksempel på en spesifikk skisse. Skissen, tegnet med penn og papir viser en kjapp, men likevel en litt detaljert tegning av en læringsplattform.til endelig skissering benyttet vi Microsoft Paint. Hovedprosjektrapport Gruppe 20 - ULV Side 26

28 4.5. UML-Modellering UML (Unified Modelling Language) er et modelleringsspråk brukt til å illustrere den grafiske helheten av systemet. Det kan benyttes flere forskjellige diagrammer i UML, men vi valgte å benytte: Use Case Diagram (med beskrivelse til hver case) Aktivitetsdiagram Vi mener disse diagrammene dekker prosjektets omfang og at det ville vært overflødig å benytte andre diagrammer. Nedenfor er det illustrert et kart som viser de forskjellige diagrammene vi valgte å benytte. Tegningen har en tittel kalt UML Diagrammer øverst. Fra tittelen er det to streker som peker ned til hver sin diagramtype: Statiske diagrammer og Dynamiske diagrammer. Et dynamisk diagram representerer de diagrammene som har direkte interaksjon med systemet. Det er her objektene som kan samhandle med systemet er plassert. Vi har to typer dynamiske diagrammer, use-case diagram og aktivitetsdiagram. Et statisk diagram representerer selve oppbygging av systemet. Brukeren har ikke interaksjon på samme måte som ved et dynamisk diagram. Vi har valgt å ikke benytte noen statiske diagrammer Use-Case Et use case deles inn i to deler. Et diagram og en beskrivelse. Diagrammet illustrerer aktør som erbrukeren av systemet, og caset som er de forskjellige aktivitetene i systemet. Det er relasjoner mellom aktør og case og disse representerer forholdet mellom dem. Det skal alltid være relasjoner mellom aktøren som benytter det aktuelle caset. Hovedprosjektrapport Gruppe 20 - ULV Side 27

29 En use case-beskrivelse forklarer fremgangsmåten i hver case. En beskrivelse skal inneholde Navn - Navn på caset. Aktør - Hvem som benytter dette caset. Trigger - Hva som gjør at aktøren vil benytte caset. Pre-betingelse - Hva som må ha skjedd før en kan benytte caset. Post-betingelse - Konsekvensen av å ha benyttet caset. Normal Hendelsesflyt - En stegvis beskrivelse av gjennomføringen av caset. Variasjon - En annen måte caset kan gjennomføres på. Feilsituasjoner - Hva som kan gå galt i caset Aktivitetsdiagram Et aktivitetsdiagram viser flyten i en aktivitet. Et aktivitetsdiagram er en effektiv måte å vise alle aktivitetene som må gjøres i en metode.diagrammet viser fremgangen i aktivitetene, men også feilsituasjoner og konsekvensen av disse Prototyping Vi valgte å benytteprototyping som utviklingsmetode ettersom det gjorde det lettere å illustrere produktet. På den måten kunne vi enkelt teste hvordan løsningen skulle se ut, og samtidigfinne feil. Denne tilbakemeldingen ble benyttet til å forhindre problemer i utviklingen, og opprette krav bedre tilpasset brukeren. Vi valgte å benyttehigh-fidelity prototyping ettersom det ga et større innblikk til hvordan produktet ville sett ut ennhva en low-fidelityprototype ville gitt. Testpersoner ser mye klarere det funksjonelle ved systemet og objekter kan være klikkbare, noe som gir en mye større følelse av interaksjon med systemet. Produktet ULV er en utdypet prototype. Denne er ulik high-fidelity prototypen ved at den er en kjørende løsning med fullt utviklet database. Vi valgte å kalle det en prototype ettersom produktet kan videreutvikles. Hovedprosjektrapport Gruppe 20 - ULV Side 28

30 4.7. Personas Personas er en teknikk der fiktive personer skapes for åteste og hjelpe utviklingen av systemet. Det er en effektiv metode om utviklerne har problemer med å få tak i testpersonell.utvikleren setter seg inn i personasens problemstilling og gjennom dem prøves det å fokusere på hvordan produktet burde tilpasses de forskjellige typer brukere. Vi prøvde å sette oss inn i deres situasjon og teste dem på både prototype og produkt, avhengig av hindringen de har. Alle bildene brukt til å illustrere våre personas ble hentet fra freedigitalphotos.net. Bildene er gratis og det er ingen rettigheter nødvendig for å benytte dem Brukertesting Brukertesting er en metode brukt til å finne positive og negative aspekter ved en prototype eller et produkt. Brukertesting foregår ved at en utenforstående observeres samtidig som han eller hun tester. Observatøren gir enkle oppgaver testpersonen skal gjennomføre og resultatene brukes til å tilpasse systemet. Testpersonen kan komme med relevante tilbakemeldinger som er viktige for stadig å finne et forbedringspotensial. Vi valgte å benytte brukertesting som metode for å bygge prototypen og produktet. Vi mente det var en effektiv måte å innhente krav på og gjennom brukertesting kunne vi finne hva brukeren faktisk ønsket og ikke bare hva vi tror brukeren trengte. Vi kan se på det som at testpersonen var med på å forme produktet. Hovedprosjektrapport Gruppe 20 - ULV Side 29

31 5. Forberedende undersøkelser I dette kapittelet presenteres de resultatene oppnådd fra undersøkelsene rundt eksisterende løsninger Resultatet fra kartlegging av eksisterende verktøy De første nye erfaringene fra kartlegging av læringsplattformene kom fra Moodle, etter en anbefaling fra MediaLT. Det ble vurdert åbenytte Moodle sin kildekode til utvikling av systemet ettersom den var open-source. Vi hadde tilgang på kildekoden og vurderte å tilpasse den, men vi valgte likevel å skrive egen kode fra grunn av. Under testingen av Moodleble det opprettet en adminbruker og tre lærerbrukere. Funksjoner og brukervennlighet ble testet. Moodle er en god plattform, men den har litt for mange funksjoner og dette gjorde opplevelsen noe rotete. Det er vanskelig å opprette verktøy og det tar gjerne litt tid før en oppgave blir gjennomført. Testingenav lytteutstyr på plattformen fungerte bra, men uten mulighet til å endre skriftstørrelse og kontraster var den ikke likevel ikke god nok. Den andre læringsplattformen vi testet var It s Learning. Tilgangen til plattformen er tilgjengelig gjennom Brukere med både lærer og elevrettigheter ble opprettet og funksjonene ble testet. Vi fant at læringsplattformen hadde svært mange verktøy, spesielt for lærere. Plattformen er uoversiktlig og det er vanskelig å finne fram til ting. Plattformen har ikke muligheten til å endre skriftstørrelse eller kontraster og den opplevdes som dårlig utformet. Vi fant 20 forskjellige verktøy til denne plattformen og eksempler er lagt nedenfor: Verktøy Brukere Beskrivelse Appbibliotek Lærer Gjør eksterne undervisnings- applikasjoner tilgjengelige for lærere og med mulighet for å lære det direkte via It s Learning. Blogg Alle Her kan man opprette en egen blogg. Bibliotek/ e:plus Alle Tjeneste for å håndtere multimedia som video, lyd og bilder. Det er redigeringsverktøy slik at det er mulig å lage leksjoner. Hovedprosjektrapport Gruppe 20 - ULV Side 30

32 Chat Alle Online nettprat der man kan diskutere. Det er mulig å se hvor mange som er pålogget. Alle verktøy vi fant i It s Learning er listet i vedlegg IV. Den siste plattformen vi testet var Fronter. Vi fikk bare testet ut studentversjonen, og vi måtte bruke vår egen profil. For å få undersøkt lærerversjonen av Fronter spurte vi vår veileder om hjelp oghun viste oss de forskjellige funksjonene. Under undersøkelsen fant vi flere funksjoner gruppen ikke kjente til og vi mener mange er unødvendige.vi fant hele 34 verktøy på Fronter og fire eksempler er lagt nedenfor: Verktøy Brukere Beskrivelse Beskjeder Lærer Dele beskjeder med alle medlemmene i et rom. Blogg Lærer Her kan man opprette en egen blogg. Creaza Lærer Multimedia verktøy der man kan leke seg fram. Dagens Alle Mulighet til å endre din personlige startside Alle verktøy vi fant i Fronter er listet i vedlegg IV. Da vi benyttet stemmeleser på Fronter oppdaget vi at det var vanskelig å navigere og den største grunnen til dette er nok at plattformen benytter seg av frames. Frames er en htmlfunksjon hvor brukeren kan navigere seg inne på et subvindu i samme nettside som han originalt startet på. Dette gjør at en kan beholde informasjon på en side samtidig som andre objekter blir erstattet av for eksempel en nettside.bildet nedenfor er et printscreen fra Fronter og et eksempel på en framefunksjon. Bildet viser et mappesystem helt til venstre i bildet som benytter en scroll-attributt. Til høyre for dette er det enda en scroll-attributt med oversikt over flere mapper. Trykker en her åpner dette for enda flere mapper, helt til høyre i bildet.hele løsningen er veldig uoversiktlig og det er ikke lett å bruke en stemmeleser på dette. Hovedprosjektrapport Gruppe 20 - ULV Side 31

33 Et eksempel på unødvendige funksjoner er «spill» hvor læreren kan legge opp et spill f.eks. «Tetris» i et kurs. Deltakerne i kurset kan videre velge å spille dette. Nok et eksempel ligger i bildet under. Eksempelet viser rom tilgjengelige, når en sist besøkte rommet og hvor mange ganger en besøkte rommet. Det viser også hvor mange egne ting en har lest på rommet og hva av andres dokumenter, linker og diskusjoner en har lest. Vi ser ikke nødvendigheten i å ha en funksjon for å vise slike detaljer og vi mener dette er noe som burde fjernes. Fronter har en kontaktfunksjon hvor brukeren kan legge til andre brukere og sende meldinger til disse.i dag benytter studenter heller Facebook eller mail for å kontakte andre. Erfaringen fra gjennomgangen var at det var mange unødvendige funksjoner tilgjengelige. Enkelte funksjonervar forståelig opplagte, mens andre ikke. Det var mye overflødig og plattformene burde tilpasses det de benyttes til, nemlig skole. Plattformene var ikke spesielt Hovedprosjektrapport Gruppe 20 - ULV Side 32

34 tilgjengelige, enkelte områder hadde linker og knapper med svært liten størrelse og det var ikke mulig å bytte kontrast eller tekststørrelse Resultat fra spørreundersøkelser Vi benyttet resultatene fra gjennomgangen til å utforme spørreundersøkelser. Spørreundersøkelsene hadde et fokus på hva brukerne benyttet og hvor fornøyd de var med deres læringsplattform. De hadde mulighet til å gradere læringsplattformen og fortelle hvem de foretrakk av It s Learning og Fronter. For å få sendt ut til flest mulig valgte vi å kontakte Handelshøyskolen BI, UiO og HiOA. Ettersom ingen av de tre benyttet Moodle, kunne vi ikke bruke spørsmål om den i undersøkelsen. De komplette brukerundersøkelsene er tilgjengelige i vedlegg. Vi kontaktet Handelshøyskolen BI direkte på Nydalen for å få tillatelse til å sende ut en It s Learning undersøkelse på deres nettverk. Vi fikk ikke denne tillatelsen, men vi ble forklart at hvis vi kjente studenter fra BI-Nydalen kunne vi sende ut mail gjennom disse, vi sendte derfor ut ca. 200 mail. Universitetet i Oslo fortalte at vi var nødt til å sende ut en søknad i forhold til spørreundersøkelsen. De fortalte oss videre at reglementet var strengt og sjansen for å få tillatelse til å sende en undersøkelse var liten. Vi fikk ingen godkjenning fra universitetet. Vi fikk en muntlig tillatelse til å sende uten spørreundersøkelse om Fronter på HiOA. Undersøkelsen ble sendt ut til alle studentene på campus Pilestredet, ca studenter. Vi fikk ikke tillatelse til å sende ut brukerundersøkelser til lærerne, men vi kunne intervjue dem på deres kontorer Svarene Av tilbakemeldinger fikk vi 850 om Fronter og 136 om It s Learning. Vi spurte brukere som både hadde benyttet Fronter og It s Learning om hvilket av systemene de foretrakk mest, og It s Learning kom best ut. Hovedprosjektrapport Gruppe 20 - ULV Side 33

35 Tilbakemelding fra brukerundersøkelsen, Fronter: Grafen over viser resultatenetil spørsmålet: hvor ofte sjekker du Fronter? Resultatene ble: 1. Flere ganger om dagen, 122 svar, tilsvarer14 %. 2. Hver dag, 330 svar, tilsvarer39%. 3. Et par ganger i uka, 317 svar, tilsvarer37%. 4. En gang i uka, 54 svar, tilsvarer6%. 5. Sjeldnere, 26 svar, tilsvarer3%. Resultatene viste at Fronter blir hyppig brukt. Grafen over viserresultatene til spørsmålet: «hvor oversiktlig og navigert synes du Fronter er?» Resultatene ble: personer svarte 1, tilsvarer 11% personer svarte 2, tilsvarer 22% personer svarte 3, tilsvarer 29% personer svarte 4, tilsvarer 26% personer svarte 5, tilsvarer 10% personer svarte 6, tilsvarer 2%. Gjennomsnittet viste at brukerne mente Fronter var under middels bra i oversiktlighet. Vi hadde et spørsmål i undersøkelsen om hva brukerne savnet i plattformen. Svarene viste at de ønsket seg færre klikk og lettere navigasjon. Flere ga oss tilbakemelding på at det var Hovedprosjektrapport Gruppe 20 - ULV Side 34

36 funksjoner som manglet på plattformen. Vi fant likevel ut at flere av disse faktisk eksisterte, men at de var dårlig utformet og nesten gjemt. Et eksempel var sendt mail funksjonen. Flere brukere visste ikke at denne eksisterte. For å nå denne må brukeren trykke på plusstegnet til venstre for HiOA e-post, slik som vist i figuren nedenfor. Funksjonen er ikke godt utformet og sørger for at brukeren må gjennomføre et ekstra klikk. Fronter har en mailfunksjon kalt personlige meldinger. Brukere kan velge å sende ut mail til andre brukere, da gjerne gjennom klasser. Mailen kompilerer ikke med den vanlige Frontermailen og derfor er det sjeldent studenter benytter seg av denne funksjonen. Det finnes ingen annen måte å se om vi har mottatt noen personlig mail ettersom de ikke vises på forsiden. Tilbakemelding fra brukerundersøkelsen, It s Learning: Til spørsmålet: hvor ofte sjekker du It s Learning? Resultatet ble med 136 svar: svarte «Flere ganger om dagen», tilsvarer 11,7% svarte «Hver dag», tilsvarer 30,1% svarte «Et par ganger i uka», tilsvarer 36% svarte «En gang i uka», tilsvarer11,7% svarte «Sjeldnere», tilsvarer 8,8%. De fleste har svart at de benytter seg av It s Learning hver dag eller et par ganger i uka som vil si at mange sjekker siden jevnlig. Til spørsmålet: hvor oversiktlig og navigerbart synes du It s Learning er? Resultatet ble med 136 svar: 1. 6 personer svarte 1, tilsvarer 4,4% personer svarte 2, tilsvarer 6,6%. Hovedprosjektrapport Gruppe 20 - ULV Side 35

37 3. 25 personer svarte 3, tilsvarer 18,38% personer svarte 4, tilsvarer 35,2% personer svarte 5, tilsvarer 29,4% personer svarte 6, tilsvarer 5,8%. Brukere av It s Learning syntes plattformen var godt oversiktlig. Vi så at It s Learning fikk høyere rate enn Fronter når det gjelder oversiktlighet, men det må tas hensyn til at vi hadde færre tilbakemeldinger på It s Learning.Til spørsmålet om hva brukerne savnet i It s Learning fikk vi ikke mange svar, men flere ønsket bedre struktur Resultat av intervjuer Vi gjennomførte spørreundersøkelsen og intervjuene på fem lærere ved Høgskolen i Oslo og Akershus og hadde i den anledning hovedfokus på hva læreren mente om Fronter og ønskelige forbedringer. Vi fikk spurt om deres opplevelse av Fronter og meningene var varierende. Vi merket oss spesielt at enkelte mente Fronter erdårlig utformet for lærerrollen, for det er så mange valg at det gjør det vanskelig å få gjennomført sine ønskede oppgaver.vi ble forklart at lærerne benytter seg av svært få funksjoner, og det er gjerne de samme funksjonene de alle benytter. Av de 26 verktøyene benyttet lærerne 3 5 verktøy.dette tyder på at flere funksjoner og verktøy kan fjernes. De mest brukte verktøyene er: Innlevering Dokumenter Arkiv Førsteside Lenker Enkelte av lærerne benyttet noen funksjoner andre ikke benyttet, men likevel var det mange verktøy som ikke ble nevnt. Et resultat som var bemerkelsesverdig var at en lærer heller valgte å utvikle en egen nettside for sitt kurs. Den eneste interaksjonen læreren hadde i Fronter var å legge ut linken til denne nettsiden slik at elevene kunne klikke seg inn. Dette understrekes av våre egne erfaringer i et annet kurs. Hovedprosjektrapport Gruppe 20 - ULV Side 36

38 Videoundervisning Under intervjuet spurte vi de forskjellige lærerne om deres mening rundt videoundervisning.vi spurte om dettefordi MediaLT ønsket denne funksjon. Grunner til at studenter kanønske seg online-undervisning kan være: jobb,reise, sykdom osv. For skolene kan det bety at flere studenter ønsker å gå der selv om de ikke har kapasitet eller mulighet til å bo nær skolen. Resultatene fra lærerne var varierende. En lærer påpekte at elever forventer at det presenterte fagstoffet er korrekt. Skulle læreren ved et tilfelle presentere fakta-feil og ikke legge merke til det,vil ikke studentene få vite dette. De vil dermed kun tenke at dette er riktige fakta og basere seg på dette mot eksamen. Vår mening er at det høres ut som om læreren sitter med frykt for å gjøre feil. Enkelte lærere var veldig opptatt av at det var viktig å fokusere på personvern rundt videoavspilling. Det henvises til personvernloven hvor formålet er å beskytte den enkelte mot at personvernet blir krenket gjennom behandling av personopplysninger. Lov om behandling av personopplysninger, 1 Lovens formål. Ikke alle ønsket å få videoer av seg postet på nettet, de var bekymret for at en slik video kunne misbrukes senere. Andre lærere mente at videoundervisning kunne være til hjelp fordi studentene kunne se forelesningene så mange ganger de ønsket. Et forslag var å kutte ut ren tavleundervisning og bytte dette ut med videoundervisning og mindre gruppetimer, som igjen ville gjøre det lettere for læreren å få kontakt med den enkelte student og skjønne hva studentene synes er vanskelig. Videre påpekte de at selve videoundervisningen må gjøres grundig og oppdateres når forandringer i pensum kommer. De mente dette ville gjøre dem mer tilgjengelig for studentene, både på nett og på skolen. Hovedprosjektrapport Gruppe 20 - ULV Side 37

39 6. Kravspesifikasjon En kravspesifikasjon er en liste over de kravene utvikleren implementere i et system. Kravene definerer hvordan systemet skal fungere og det er viktig for utviklerne å velge et tidspunkt i utviklingen hvor kravene burde fryses og fokuset rettes mot de eksisterende krav Skisseringen Bildet nedenfor viser en skisse fra en av kurssidene. Det valgte kurset er lagt som faner i en bar sammen med de andre kursene. Hvert kurs er klikkbart og det valgte kurset er merket med blått. I den samme baren øverst i høyre hjørne ligger profilbilde med eget bilde og teksten «min profil» er plassert under. Igjen under denne ligger en knapp for epost. Øverst i venstre hjørne ligger teksten «ULV» sammen med logoen og under ligger teksten «tilbake til start», som sender brukeren tilbake til startsiden gjennom å trykke på denne.på midten av siden ligger fire bokser til kursverktøy. Hvert verktøy tilhører hver sin boks og i dette eksempelet ligger verktøyet «forelesning» i en av boksene. Neste tegning viser hvordan vi først så for oss at mailsystemet skulle se ut. Tegningen har baren øverst med alle de samme funksjonene som på forrige bilde. Under baren ligger midtsiden med alle mailfunksjonene. Til venstre ligger funksjonene:innboks, utboks, sendt og slettet. Øverst ligger knappene: ny, slett, flytt, svar og videresend. Midt i bildet ligger mailoversikten og mailvinduet. Den nyeste mailen i mailoversikten blir plassert øverst. Hovedprosjektrapport Gruppe 20 - ULV Side 38

40 Bildet underviser forsiden til læringsplattformen. Igjen er den samme baren øverst med de forskjellige funksjonene og kursene i klikkbare faner. Til venstre i bildet ligger de nyeste mail og nyheter plassert i hver sin boks. Det er tre bokser til nyheter og tre til mail. Dette er for å begrense antall beskjeder på forsiden. Til høyre er det tegnet en kalender og en liste over de førstkommende fristene. Kalenderen er øverst og hver kommende frist på en dato er merket med en rød firkant. Under Kalenderen er de viktige fristene. Oppgavenavnet står først før kursnavn og til slutt dato for fristen. Hovedprosjektrapport Gruppe 20 - ULV Side 39

41 6.2. UML-Modeller Use Case I use case modellen nedenfor presenteres tre aktører: Student, Lærer og Administrasjon. I tillegg er det ti case hvor hver aktør har relasjon til deres anvendte case. Casene er som følger: Last opp fil, Last ned fil, Endre brukerdetaljer, Administrer kurs, Legg til deltaker, Administrer bruker, Administrer studentgrupper, Administrer nyheter, Administrer prøve, Administrer innlevering. Use Case Beskrivelser Eksempler på to use case-beskrivelser. Resten ligger i vedlegg II. Case 1 Usecasenavn: Administrer bruker Aktør: Admin Trigger: Aktør ønsker å legge til bruker Pre-betingelse: Aktør har klar informasjon om ny bruker Postbetingelse: Brukerinfo har blitt registrert og mail er sendt til den nye brukeren Normalhendelsesflyt: 1. Ny bruker ønskes lagt til i systemet. 2. Systemet valider input. 3. Systemet lagrer den nye brukeren i databasen. 4. Mail med brukerinformasjon blir sendt til den nye brukeren. Hovedprosjektrapport Gruppe 20 - ULV Side 40

42 Variasjoner: 2a. Systemet validerer input fra tekstfil Feilsituasjoner: 2b Input er feil og må skrives inn på nytt. 4a Mailserveren er nede og ingen mail blir sendt ut til den nye brukeren. Case 2 Usecasenavn: Administrerkurs Aktør: Admin Trigger: Aktør ønsker å slette et kurs fra systemet. Pre-betingelse: Kurs er tilgjengelig i systemet. Postbetingelse: Kurset er slettet fra databasen Normalhendelsesflyt: 1. Aktør ønsker å slette kurset fra databasen. 2. Systemet sletter kurs og kursdeltakere fra databasen. Variasjoner: (Ingen) Feilsituasjoner: (Ingen) Aktivitetsdiagram Aktivitetsdiagram for administrering av kurs: Hovedprosjektrapport Gruppe 20 - ULV Side 41

43 Diagrammet starter ved at brukerengår inn på «administrer kurs». Videre får brukeren valgmulighetene for nytt, endre eller slett kurs. Ved slett kurs får brukeren opp valgene ja eller nei, og kurset blir enten slettet eller stående, avhengig av hva brukeren ønsker. Ved endring av kurs kan brukeren skrive inn det nye navnet og deretter godkjenner. Ved nytt kurs skriver brukeren inn det nye kursnavnet og velger «legg til». Kurset blir så lagt til og det blir mulig å legge til deltakere i kurset Kravspesifikasjon Må, Bør og Fint å ha Det finnes forskjellige metoder en kan benytte for utarbeidelse av en kravspesifikasjon, men resultatene en oppnår kan brukes til å lage tre forskjellige kravtyper: Må ha-, Bør ha- og Fintå ha krav. Disse kravtypene reflekterer prioriteringsnivået. Etter at utvikleren har utviklet Måkravene burde han fokusere på Bør kravene for så å utvikle de mindre viktige Fint å ha kravene. Etter at vi gjennomførte våre opplistede metoder kom vi fram til hva som trengtes i en læringsplattform. Disse resultatene er presentert under. Kravene ble fryst 5. mai. Må-kravene Må kravene er krav som er satt for at systemet skal kunne fungere. Dette er Må-kravene og hvem som kan benytte disse: Bruker skal kunne logge inn og ut (Bruker: student, lærer og administrator). Bruker skal kunne laste opp og ned fil (Bruker: student og lærer). Bruker skal kunne ha en personlig profil (Bruker: student, lærer og administrator). Bruker skal kunne se en oversikt over medlemmer i et kurs (Bruker: student og lærer). Bruker skal kunne se siste nytt på forsiden, som nyheter og innleveringer (Bruker: student og lærer). Bruker skal kunne benytte inn- og utlevering av obligatoriske oppgaver med gjeldende frist (Bruker: student og lærer). Bruker skal kunne legge ut nyheter (Bruker: lærer). Bruker skal kunne legge ut forelesningsnotater og andre dokumenter (Bruker: lærer). Bruker skal kunne gi tilbakemelding på studentenes innlevering (Bruker: lærer). Hovedprosjektrapport Gruppe 20 - ULV Side 42

44 Bruker skal kunne opprette flersvarsprøver og legge ut disse tilgjengelig for studentene (Bruker: lærer). Bruker skal kunne opprette og slette kurs (Bruker: Admin). Bruker skal kunne administrere andre brukere (Bruker: Admin). Systemet skal etterstrebe kravene til WCAG 2.0. Bør-kravene BØR kravene er utviklernes sekundærkrav og dermed også krav utvikleren burde vurdere. Et system skal kunne fungere uten at disse kravene har blitt implementert i systemet, likevel burde utvikleren vurdere om disse skal utvikles i ettertid. Dette er Bør-kravene og hvem som kan benytte disse: Bruker skal få en beskjed om nye beskjeder eller dokumenter har blitt opprettet i et kurs. (Bruker: student). Fint å ha-kravene Fint å ha kravene er utviklernes tertiærkrav. Kravene er ikke nødvendige, og kan gjerne ses på som ekstrafunksjoner. Dette er krav utviklerne burde fokusere på bare om det er nok tid til overs. Dette er Fint å ha-kravene og hvem som kan benytte disse: Bruker skal kunne laste opp videofiler (eventuelt streame) videoleksjoner og spille av disse. (Bruker: student og lærer) Funksjonelle krav Funksjonelle krav Funksjonelle krav er de kravene som viser hva systemet skal brukes til. Kravene dekker de forskjellige mulighetene innad i systemet. Funksjonelle krav for alle brukere: Krav Beskrivelse Innlogging - Funksjonen som gjør det mulig å entre systemet. - Brukeren skal skrive inn brukernavn og passord for å kunne få adgang til systemet. Hovedprosjektrapport Gruppe 20 - ULV Side 43

45 Utlogging - Det skal være mulig å logge seg helt ut av systemet slik at ny pålogging kreves for å komme inn. Endring av skriftstørrelse - Det skal være mulig å endre skriftstørrelsen etter behov. Skriften skal både kunne minskes, økes og tilbakestilles. Høykontrast - Brukeren skal ha muligheten til å sette fargene på siden til høykontrast. - Brukeren skal også kunne tilbakestille til vanlig kontrast. Profil - Brukeren skal kunne endre personlige brukerdetaljer. Funksjonelle krav - student: Krav Beskrivelse Meny - På menyen skal det være en god oversikt over de valgene studenten kan ta. Her kan brukeren gå inn på profil, kurs og kursverktøy. - I menyen er startsiden tilgjengelig. Karakterer - Systemet skal gi studenten mulighet til å se tilbakemeldinger og eventuelle karakterer som er gitt på prøver og innleveringer. Dokumenter - Det skal være mulig å laste ned dokumenter, slik at det kan bli lagret på studentens datamaskin. - Det skal også være mulig å laste opp dokumenter. Prøver - Det skal være mulig for studenten å ta multiple choice-prøver. Video - Studenten skal kunne spille av / strømme video. Funksjonelle krav lærer: Krav Beskrivelse Meny - På menyen skal det være en god oversikt over de valgene læreren kan ta. Her kan brukeren gå inn på profil, kurs og Hovedprosjektrapport Gruppe 20 - ULV Side 44

46 kursverktøy. - I menyen er startsiden tilgjengelig. Opprett kurs - Læreren skal kunne opprette nye kurs Opplasting av filer - Det skal være mulig å laste opp dokumenter og filer slik at studentene kan se dem. Nedlastning av filer - Skal være mulig å laste ned obligatoriske oppgaver som er levert av studenter og egne dokumenter fra arkiv. Kurs - Skal kunne legge til kurs og legge til deltakere. - Meldinger skal kunne opprettes og slettes på hvert kurs. Prøver - Skal kunne opprette multiple choice-prøver studentene kan gjennomføre. Obligatoriske oppgaver - Skal kunne legge ut oppgaver og ha mulighet til å sette en frist. - Mulighet for å endre fristen. Videoundervisning - Lærer skal kunne laste opp videofiler / utføre videostrøm. Funksjonelle krav Administrator: Krav Beskrivelse Administrer kurs - Brukeren skal kunne opprette et kurs som gjør det mulig å legge til deltakere. - Brukeren skal kunne endre navnet på kurset - Brukeren skal kunne endre deltakerne i kurset. - Brukeren skal kunne slette et kurs fra systemet. Administrer bruker - Administrator skal kunne opprette andre brukere til systemet. - Det skal være mulig å bestemme rettighetsnivået til brukeren (student, lærer og administrator). - Den nye brukeren skal få tilsendt brukernavn og passord. - Det skal være mulig å slette en bruker fra systemet. - Administrator skal kunne endre brukerdetaljer, med unntak av passord. Hovedprosjektrapport Gruppe 20 - ULV Side 45

47 Administrer studentgruppe - Brukeren skal kunne opprette en gruppe som gjør det mulig å legge til brukerdeltakere. - Brukeren skal kunne endre navnet på grupper. - Brukeren skal kunne endre deltakerne i grupper. - Brukeren skal kunne slette en gruppe fra systemet. Hovedprosjektrapport Gruppe 20 - ULV Side 46

48 7. Løsningen 7.1. Prototypen Resultatene fra brukerundersøkelsene, kartleggingen og skisseringen ble brukt til å lage en high-fidelity prototype. Prototypen ble utviklet i programmet Axure RP pro, et effektivt interaksjonsprogram. Alle objekter er hentet fra verktøylisten til Axure og plassert der de egnet seg best. Nedenfor er eksempler på objekter i prototypen. Bakgrunner - Dette er blokker, fylt med egendefinerte farger og strukket til ønskelig størrelse. Knapper - Fungerende knapper som kan sende testpersonen til en annen side. Knappene har ingen andre funksjoner. Tekst Tekstbokser - Bokser med mulighet til å skrive inn tekst. Bildeobjekter Bilder med mulighet til å sette inn egne bilder. Det ble utarbeidet tre forskjellige prototyper. En studentprototype, en lærerprototype og en administrasjonsprototype. Nedenfor følger et utdrag med forklaring fra lærerprototypen. I eksemplet ovenfor vises forsiden av lærerbrukeren til prototypen. Øverst ligger en bar i mørkerødt, hvor det står «Home». Baren har i tillegg knapper for «logg ut», «profil», «mail» og «mitt arkiv» plassert på høyre side. Plassert under denne baren ligger kursoversikten i en ny bar i mørkegult. I dette eksempelet er de klikkbare kursene: finsk, matte og sosiologi. I tillegg på samme oversikt ligger knappen «legg til kurs». På midten av siden vises nyeste mail og nyheter. Disse ligger i egne trykkbare bolker for å kunne lese innholdet. Hovedprosjektrapport Gruppe 20 - ULV Side 47

49 Det neste bildet illustrerer hvordan siden til et kurs ser ut, i dette tilfellet finsk. I den samme baren ligger funksjonene som tidligere, men i den mørkegule står det nå «kurs» og under har det kommet en ny bar i mørk farge hvor innholdet til selve kurssiden ligger. Denne inneholder: «Fagstoff», «Oppgaver», «Innlevering», «Deltakere», «Forum», «Prøve» og «Nytt verktøy». Beskjeder kan legges til via knappen «Ny beskjed» og beskjeder kan slettes gjennom knappen «Slett». Bildet av prototypen over viser mailsiden. Øverst ligger den mørkerøde baren med alle de samme funksjonene som tidligere. Under denne baren i mørkegult ligger oversikten over de forskjellige mailfunksjonene: «Inbox», «Utbox», «Spam» og «Slettet». Helt til høyre er det plassert et søkefelt som skal benyttes til å søke etter mottaker av mailen. Under denne baren Hovedprosjektrapport Gruppe 20 - ULV Side 48

50 er selve mailoppsettet plassert. Her er det tre tekstbokser hvor det skrives inn avsender, emne og tekstboks til mailinnholdet. I tillegg er det plassert en knapp for å sende mailen Testing med personas Ikke alle personas utviklet kunne benytte high-fidelity prototypen grunnet at Axure bare kan benyttes til å navigere seg på. Tre personas ble benyttet til å teste prototypen: Navn: Pål Alder: 32 Yrke: T-banefører, Oslo T-banedrift Pål har hatt leddgikt i ti år. Han sliter med nettsider hvor det kreves mange klikk for å få gjort det han ønsker. High-fidelity prototypen er laget for at brukeren enkelt skal kunne komme seg fra a til b. Det ble ikke nødvendig å benytte mange klikk for å finne fram, noe som gjorde det lettere for Pål. Navn: Kalle Alder: 20 Yrke: Uføretrygdet Kalle har tremor og sliter derfor med rykninger i hendene. Når han skal benytte datamaskiner kan han få problemer med å trykke. Prototypen har store knapper som gjorde det lettere for Kalle å treffe. Navn: Lise Alder: 23 Yrke: Student Lise har vært svaksynt de siste årene. Hun sliter med å benytte internett ettersom det er flere nettsider som har objekter som sitter tett sammen og det virker for henne som om de glir over i hverandre. Knapper og tekst var tydelige. Objekter har en god størrelse og Lise hadde ingen problemer med å skille objektene fra hverandre Testing med brukere Prototypen ble testet på en dame i 50-årene. Hun hadde motoriske problemer grunnet MS og hadde samtidig også nedsatt synsevne. I tillegg hadde testpersonen få erfaringer med Hovedprosjektrapport Gruppe 20 - ULV Side 49

51 bruken av datamaskin og benyttet pc mest til å lese nettaviser. Testingen tok ca. 10 minutter og vi ga henne følgende oppgaver: Vi lot testpersonen starte på logg inn-siden. Hun logget seg inn og kom til hovedsiden. Vi spurte henne om hun kunne komme seg inn på mailen, og denne fant hun lett.videre spurte vi henne om å finne fagstoff gjennom det finske kurset. Det viste seg å være litt vanskelig for henne på grunn av den nedsatte synsevnen, men etter litt tid fant hun det. Deretter ble hun spurt om å forlate den finske kurssiden og gå tilbake til startsiden uten å bruke tilbakeknappen i nettleseren. Dette var vanskelig for henne. Etter å ha brukt langt tid måtte hun gi opp og vi passet på å vise henne hvor denne lå. Vi erfarte at brukeren hadde problemer med å trykke på knapper. Hun slet ikke med å trykke mustasten ned, men da hun skulle slippe på mustasten bommet hun gjerne på grunn av skjelvingen Hva gikk vi vekk fra i ettertid? Produktet vi utviklet måtte tilpasses på grunnlag av erfaringer fra prototypen og andre senere resultater. Dette er det vi kom fram til. Mail:Mail funksjonen ble overflødig og vi valgte derfor ikke å utvikle denne. Meny: For å sikre det ikke-funksjonelle kravet «tre klikk»,så må kursene være tilgjengelig fra alle sidene. Dette var ikke tilfelle i prototypen, der brukeren måtte tilbake til forsiden for å få oversikt over alle kursene. Admin: Denne siden ble designet på nytt fra bunnen av. Brukeren hadde for mange funksjoner enn nødvendig. Profilbilde: Da vi testet ULV på svaksynt kom vi fram til at bildet var vanskelig å oppfatte. Vi valgte derfor å erstatte bildet med teksten «min side». Nyheter:Vi valgte å endre designet på hvordan nyhetene ble presentert. Det ble mer ryddig å ikke knytte bilder til teksten Løsningen Grensesnitt Et grensesnitt tillater oss å kommunisere og samhandle med systemet. Det representerer hva en kan gjøre i et system og hvordan en gjør det. Det grafiske brukergrensesnittet Hovedprosjektrapport Gruppe 20 - ULV Side 50

52 representerer hvordan vi ser systemet. Et grensesnitt inneholder elementer og et eksempel er et ikon som representerer en browser som gjenkjennes er et typisk godt grafisk element. Et godt grafisk grensesnitt burde være tilpasset de som faktisk skal benytte systemet. Å benytte farger for barn, kule tekster for ungdommer og et mer voksent grensesnitt for arbeidslivet er en god praksis. Det varderfor viktig for oss å utarbeide et profesjonelt grensesnitt for både studenter og tilsatte. Grensesnittet skulle være brukervennlig og tilgjengelig. I læringsplattformen har det under utviklingen vært fokus på WYKIWYL (WhatYouKnow Is WhatYou Like). Dette betyr at en bruker foretrekker å benytte det grensesnittet han er vant til fra før. Mennesker ønsker heller å benytte det de kan i stedet for å måtte lære noe nytt hver gang de skal benytte liknende systemer. Vi går derfor vekk fra WYSIWYG (WhatYou See Is WhatYouGet) hvor brukeren må tilpasse seg det grensesnittet utviklerne har bestemt. Grensesnittet utviklet har fokus på følgende kjennetegn: Sikkerhet Det er viktig at sensitiv informasjon på et system ikke er tilgjengelig for uvedkommende. Vi har sørget for at hver bruker har sin egen personlige profil. Dette kan kun endres av administrator og den bestemte bruker. Det er kun den bestemte bruker som kan endre passord. Sensitiv informasjon som innleveringer er det kun den faktiske bruker som har tilgang til. Funksjonalitet Funksjonaliteten i løsningen dekker brukernes behov.vi satte et fokus på hva brukerne benytter i en læringsplattform og begrenset det til kun det mest nødvendige. Eksempler er: Innleveringer og fagstoff. Tilgang Brukeren må ha god tilgang gjennom grensesnittet. Vi har i grensesnittet sørget for at alt er lett å finne. Brukeren vil derfor ikke ha problemer med å finne funksjonalitet på systemet. Effektivitet Arbeid burde kunne utføres raskt. På grunn av få funksjoner går det raskt å navigere. Dette gjelder også med stemmeleser. Implementering av Tre-klikks regelen sørger for høy effektivitet. Brukervennlighet Det handler om hvor lett det skal være for brukeren å lære seg et system og benytte det. Ideelt sett bør brukeren barese på systemet for å forstå hvordan en benytter det. Videre skal brukeren kunne huske hvordan han benytter det. ULV har en gjennomgående meny som sørger for at brukeren kjenner seg igjen og ikke trenger lete etter funksjonalitet. Hovedprosjektrapport Gruppe 20 - ULV Side 51

53 Appell Brukergrensesnittet appellerer til brukeren. ULV har en nøytral design med tanke på fargebruk og former Hvordan oppfyller grensesnittet kravene til WCAG 2.0? I prosjektet har det vært fokus på de fire områdene innenfor WCAG 2.0; gjenkjennelighet, anvendelighet, forståelighet og robusthet. På ULV har vi innenfor hvert av områdenedesignet ut ifra de forskjellige punktene som kreves for å oppfylle kravet til WCAG 2.0. Gjenkjennelighet Vi var nøye med å benytte stor skrift på ULV og at språket var enkelt lagt opp slik at det ikke skulle oppstå noen misforståelser. Vi benyttet ikke tidsbaserte medier og hadde derfor verken lyd eller video på ULV, men hvis dette skulle komme i fremtiden kunne det være lurt å unngå strømmingog heller laste opp videoer slik at man kan spole fram og tilbake på disse selv.de bør også inneholde tekst under videoen eller tale av hensyn til døve og blinde. Nettsiden er konfigurerbar; det er mulig å sette nettsiden til høykontrast. Gjennom å aktivere høykontrast vil fargene endres. Det er også mulig å endre skriftstørrelsen på nettsiden. Disse funksjonene er til enhver tid tilgjengelig. Vi benyttet kjente ikoner og beskrivelser. Anvendelighet Læringsplattform er fullt manøvrerbar gjennom tastatur. Det eksisterer ingen tidsbegrensninger på siden for brukeren har så mye tid som en trenger for å få gjennomført de planlagte oppgaver. Vi har unngått innhold med skiftende og blafrende farger og brukeren vil derfor ikke risikere å oppnå epileptiske anfall. Plattformen er derfor helt trygg å benytte for epileptikere. Fargene brukt på ULV har et godkjent kontrastforhold (etter AAA-standard), noe som betyr at de skal være mulig å skille objektene fra hverandre. Det er hele tiden mulig å navigere seg rundt på siden gjennom få klikk. Hjemmesiden er tilgjengelig fra alle sider, noe som gjør at det er enkelt å komme seg tilbake. Det er også mulig å logge seg ut fra hvilken som helst side på plattformen. Forståelighet Alt av tekst på siden er forklarende slik at brukeren skal forstå hvor han / hun må gå. Grensesnittet på siden er bygget for at brukeren enkelt skal kunne forstå hva han må gjøre. Tekst og ikoner brukt er beskrivende, for at brukeren skal kunne kjenne igjen og enkelt forutsi hva systemet gjør når en benytter det. Hovedprosjektrapport Gruppe 20 - ULV Side 52

54 Robusthet Systemet har fått bygget en god kompatibilitet tilpasset brukeren. Læringsplattformen er utviklet med mulighet til å benytte stemmeleser. Dette gjør at blinde og svaksynte enklere klarer å navigere Testing med personas Tre personas ble valgt til å teste ULV: Navn: Per Alder: 19 Yrke: Student Per er fargeblind. Han har problemer med å se forskjell på forskjellige farger. Det er derfor viktig for han å benytte elementer med gode kontraster. Per var fargeblind, noe også en på vår gruppen er. Dette gruppemedlemmet har vært Per under testingen. Per syntes at fargene i løsningen ikke gled over i hverandre og det var mulig å skille elementene. Han likte at det var mulig å endre til høykontrast og at han ikke var avhengig av fargene på løsningen for å forstå hva han måtte gjøre. Navn: Espen Alder: 50 Yrke: Filosof Espen har vært blind hele livet. Han er derfor vant til å måtte benytte verktøy når han sitter på datamaskinen. Espen klarte å navigere på nettsiden bare ved bruk av tastaturet og stemmeleser. Navn: Trulte Alder: 45 Yrke: Servitør Trulte har ingen spesielle datakjennskaper. Hun har så vidt benyttet en datamaskin før, og kjenner til enkel navigering på internett. Trulte forstod hva hun måtte gjøre for å komme fra a til b og likte at plattformen var bygd for brukere som henne også. Hovedprosjektrapport Gruppe 20 - ULV Side 53

55 Testing med brukere To personer testet ULV. Første brukertest Den første testpersonen var svaksynt og jobbet til daglig med datamaskin. Hun fikk diverse oppgaver som for eksempel å skrive en ny melding i kurset, forandre personopplysninger og laste opp en oppgave. Testpersonen opplevde systemet som veldig enkelt og oversiktlig. Hun påpekte at bilder kunne være litt vanskelig for svaksynte å oppfatte, og dette var grunnen til at hun slet litt med å finne «min-side». Grunnen til dette var at vi benyttet bilde som ikonfor «min side». Hun fortalte videre at brukere som benytter veldig høy forstørrelse kan få problemer om siden er midtstilt, noe ULV er. Resten av systemet syntes hun var fantastisk. Hun likte spesielt knappene som blir brukt på «administratorsiden» og «minside». Hun likte veldig godt at det ble presentert få valg om gangen ettersom det gjorde det mye lettere å navigere. Andre brukertest. Den andre testpersonen var blind, men han var godt kjent med bruken av datamaskin og visste hva en læringsplattform var. Brukeren benytter stemmeleser til all navigasjon og testet ut hvordan studentversjonen var på ULV. Han navigerte raskt og hadde ingen problemer med å finne funksjonene vi spurte etter. Etter å ha prøvd ut systemet konkluderte han med at «systemet er alt for lett». Han fortalte at Front-end koden var god, noe som gjorde det enkelt for han å forstå hvor han var. Han lurte på hva vi mente med ordet melding og vi måtte forklare at dette var nyhetene læreren sendte ut til studenten. Testpersonen syntes det var rart at det ikke var mulig å gå inn på kurssidene fra profilsiden, men vi forklarte at dette ennå ikke var implementert. Hovedprosjektrapport Gruppe 20 - ULV Side 54

56 8. Diskusjon Her diskuteres resultatene av utviklingsprosessen og produktet Reliabilitet I gjennomføringen av prosjektet har vi fokusert på å unngå feilkilder i utformingen. Likevel kan det forventes at noen av de resultateneikke er fullt pålitelige. Vi tenker spesielt på brukerundersøkelsene hvor vi har fått mange svar. Vi har prøvd å utelukke det vi har sett på som ugyldige besvarelser. Eksempler kan være hvor besvarelsen er veldig varierende og svarteksten ikke gir mening i forhold til spørsmålet. Vi har fått god veiledning fra MediaLT, veileder og har benyttet kilder som fagpensum og internettlitteratur. Vi startet med å benytte wikipedia som kilde og siden vi visste dette kunne være usikkert, sørget vi for å benytte referanselisten til wikipedia for å innhente informasjonens originale kilde Refleksjon Kjernen i et LMS Gjennomgående i prosjektet har vi satt fokus på å tilby få funksjoner for å gjøre grensesnittet enkelt, oversiktlig og forståelig. Vi har prøvd å finne ut hva som er kjernen i et LMS. Vi har definert kjernen til å være de verktøyene som gir bedre tilgang til å lære. Det vi anser som helt nødvendig: Innlevering og tilbakemelding Fagstoff og undervisning Info og nyheter Mens disse tre er kjernen i et LMS så har vi i tillegg valgt å ta med multiple-choice test og forum. Nedenfor diskuterer vi andre aktuelle verktøy som ikke er en del av kjernen. Mail: Både Fronter og It s Learning tilbyr dette. Dette er likevel en funksjon vi ikke har med i ULV. Vårt argument for dette er at studenter i dag har gjerne en mail som allerede er i daglig bruk. Dette fører til at epost-kontoen fra læringsplattformen blir glemt. En lærer uttrykte at det er et stort problem å få tak i elever på Fronter sin epost adresse. Hovedprosjektrapport Gruppe 20 - ULV Side 55

57 Mitt Arkiv: Mitt arkiv er en funksjon som gjør det mulig å laste opp egne filer og arkivere de på LMS-serveren. Her har man i dag tjenester som Dropbox og Google drive. Likevel ønsker vi å ha dette med i ULV på grunnlag av tilbakemeldingene vi fikk fra spørreundersøkelsene. Video:Stadig flere lærere tar i bruk videoundervisning og vi ser på det som en helt naturlig utvikling å ha det med i ULV Tekststørrelse og kontrast For å oppfylle WCAG 2.0-kravene må nettsiden ha mulighet til å endre skriftstørrelse og forandre fargene til høykontrast. Vi har diskutert om det er bedre å opplysebrukeren at det finnes software man kan benytte for å oppnå den samme effekten. Fordelen med dette er at disse verktøyene er bedre tilpasset enn hva en nettside, så langt vi har sett, klarer å tilby. For ULV hadde det også betydd enda færre valg som hadde gjort siden enklere. Universell utforming går ut på å tilby løsninger for alle så langt det lar seg gjøre. I dette tilfellet ville man da ikke gjort det og derfor har vi valgt å ta i bruk disse funksjonene på ULV Tilbakemelding fra oppdragsgiver. MediaLT har gjennom hele prosjektet vært positive til prosessen i oppgaven. De gangene vi har vist dem ULV har de uttrykt at resultat var bra så langt. Likevel var det enkelte ting i koden vi måtte ta hensyn til. Et eksempel er «HTML tag-en» label, som gjør det lettere for stemmeleseren å lese bestemte element på siden Prosjektets kvalitet Det har vært mye og gjøre og enkelte funksjoner har vi måttet utelate fordi vi ikke har rukket å utforme dem. Vi skulle gjerne ha testet ULV på flere personer og da gjerne mennesker med kognitive problemer og andre typer motoriske hindringer. Det viste seg å ikke alltid være lett å få tak i mennesker som opplever motoriske hindringer. Vi sendte inn forespørsel til en kontaktperson for studenter i denne gruppen på HiOA og en annen forespørsel til Blindeforbundet. Vi fikk ingen tilbakemelding fra noen av disse og måtte derfor be oppdragsgiver om hjelp til å finne testpersoner. MediaLT hjalp oss å finne testpersoner, men de måtte gi godtgjørelse til en av testpersonene for å gjennomføre testingen for oss. Løsningen vi utviklet endte som en fungerende prototype. Dette betyr en løsning funksjonell med database. Mange av funksjonene som har vært vanlige i læringsplattformer har blitt implementert, eksempler er kurs og fagstoff. Hovedprosjektrapport Gruppe 20 - ULV Side 56

58 Gjennom prosjektet har vi hatt kontakt med MediaLT, men vi kunne gjerne sett for oss at bedriften ga oss noe bedre oppfølging. Etter at bedriften mistet støtten til prosjektet fra Uloba, stod vi ganske fritt i utviklingen av ULV. Vi kunne tenkt oss en bedre oppfølgning fra bedriften, slik at vi kunne ha utarbeidet en tydeligere kravspesifikasjon, noe som igjen kunne ha resultert i en mer fullstendig løsning Arbeidet videre ULV oppfyller Må-kravene, med unntak av ett, satt i kravspesifikasjonen. Likevel rakk vi ikke å utarbeide alle Bør og Fint å ha kravene, selv om det var ønskelig. Vi ønsket mer funksjonalitet i produktet og det var også derfor vi satte disse kravene. Skulle oppdragsgiver finne det ønskelig å fortsette videre med utviklingen av læringsplattformen, så anbefales det å fokusere på punktene nedenfor: Implementere opplasting av innleveringer, da back-end delen er klar. Dette er et MÅkrav. Om det hadde latt seg gjøre ville vi ha gjennomført en mer omfattende testing med forskjellige brukergrupper. WCAG 2.0(AAA). Fullføre administratorsiden, da denne fortsatt mangler noen funksjoner: o Legge til og fjerne brukere i kurs og grupper. o Søke etter brukere. o Fjerne brukerroller (student, lærer og administrator). Lage et alternativtcss ark der siden er venstrestilt. Det hadde gjort det enda enklere for svaksynte å bruke siden. Sørge for at alle transaksjoner med databasen inneholder sikkerhet mot SQLinjection, da noen ikke gjør det nå Tilbakemeldinger Tilbakemelding fra brukertesten påhigh-fidelity prototypen Testpersonen ønsket at vi skulle gjøre knappen for å komme tilbake til startsiden tydeligere. Vi kunne gjerne utforme den som en standard knapp. I prototypen så den mer ut som en overskrift.i ULV likner dette mer på en knapp. Hovedprosjektrapport Gruppe 20 - ULV Side 57

59 Bildet til høyre illustrer knappen formet som et bokmerke. Teksten «startside», som står øverst, og logoen til ULV under, er begge klikkbar. Hun kunne gjerne også tenke seg at skriften enkelte steder kunne vært litt større slik at det ble lettere for henne å lese. Et av WCAG 2.0 kravene er å innføre muligheten for å konfigurere endring av skriftstørrelse og dette ble tatt hensyn til. I tillegg ønsket hun en større musepeker ettersom hun slet med å se hvor denne var gjennom testingen. Dette ville gått utover grensesnittets WYKIWYL (WhatyouKnow Is WhatYou Like) og det ble derfor valgt ikke åimplementere dette. Velger en å tilpasse en slik funksjon kan en ekskludere mange andre brukere. Brukeren var fornøyd med utseende på prototypen. Oppsettet var godt bygget for henne. Hun likte også at knappene var store, slik at de var lette å trykke på. Hun var også fornøyd med at vi benyttet stor skrift på knappene. Dette tok vi med oss og utviklet i ULV Tilbakemelding fra brukertester på ULV. Den første testpersonen syntes det var enkelt og oversiktlig.etter tilbakemeldingen om at bilder ikke er bra for navigering, valgte vi å bytte ut «min side-bildet» med skrift for å gjøre det enklere å oppfatte. Den andre testpersonen ønsket mange flere funksjoner og valgmuligheter.dette strider imot det å unngå for mange og unødvendige funksjoner derfor valgte vi ikke å ta hensyn til dette i løsningen. Hovedprosjektrapport Gruppe 20 - ULV Side 58

60 9. Konklusjon MediaLT sitt utgangspunkt er at læringsplattformene tilgjengelige i dag ikke er godt nok utformet. De er ikke tilpasset blinde og svaksynte, de er vanskelig å navigere og det er ikke lett å få en oversikt. Ingen av de utprøvde læringsplattformene oppfylte kravene til WCAG 2.0 og bedriften ønsket å lage en læringsplattform tilpasset kravene. De ønsket å tilby en enklere løsning som tar hensyn til en bredere kundegruppe enn dagens læringsplattformer. WCAG 2.0 er retningslinjer som hjelper utviklerne å ta hensyn til mennesker som opplever det vanskelig å benytte systemer. Resultatene fra spørreundersøkelsene og intervjuene ble brukt til å utarbeide en kravspesifikasjon. Brukertestingen gjorde det mulig å utforme en løsning og gjøre denne brukervennlig. Vi implementerte kun de viktigste funksjonene for å gjøre alt så enkelt som mulig. Testing viste oss at ULV var godt mulig å benytte for mennesker som var blinde, svaksynte eller hadde motoriske problemer. Vi måtte begrense oss til disse brukergruppene på grunn av økonomi og kapasitet. I ULV har noen vanlige funksjoner blitt utelukket, slik som mailfunksjonen. Studenter benytter ofte Hotmail eller Gmail, noe som betyr at de ofte ikke sjekker mailen som kommer med læringsplattformen. Dette utgjør et problem for andre studenter og lærere som prøver å kontakte dem. De benytter heller ikke chat eller kontaktliste, for disse tjenestene er tilgjengelig gjennom Facebook og Skype. Det er derfor ikke nødvendig å implementere unødvendige funksjonalitet som aldri eller sjeldent blir brukt.resultatet ble en utdypet prototype som gjennom gjenkjennelighet, anvendelighet, forståelighet og robusthet er godt på vei til å oppfylle kravene til WCAG 2.0. Hovedprosjektrapport Gruppe 20 - ULV Side 59

61 10. Referanser Internettlitteratur Hentet 10. januar, Gransking av universell utforming i digitale læringsplattformer df Hentet 23. januar 2013, WCAG Hentet 23. januar 2013, Hjemmeside til MediaLT Hentet 30. januar 2013, It s Learning Hentet 13. februar 2013, Moodle Hentet 27. februar 2013, LMS Hentet 27. februar 2013, fra spesialløsning til generell løsning Hentet 12. mars 2013, Fronter Hentet 25. mars 2013, Tremor Hentet 25. mars 2013, Lov om behandling av personopplysninger Hentet 10. april 2013, UML Hentet 29. april 2013, Uloba Hentet 30. april 2013, Multippelsklerose Hentet 2. mai 2013, Sindrem Hentet 5. mai 2013, Changepassword in php Hentet 24. mai 2013, Stackoverflow Hovedprosjektrapport Gruppe 20 - ULV Side 60

62 Hentet 26. mai 2013, W3C Hentet 26. mai 2013, w3 School Litteratur An Introduction to Human Factors Engineering - Wickens, Lee, Liu og Becker - Pearson-Prentice Hall Year 2004 Applying UML and Patterns, 3.utgave- Craig Larman - Pearson Education 2005 Systemutvikling: applikasjoner og databaser - Thor E. Hasle - Cappelen akademisk forlag 2008 Databasesystemer - Bjørn Kristoffersen - Universitetsforlaget 2009 Webprogrammering i PHP, 3 utgave - Svend Andreas Horgen - Gyldendal Norsk Forlag 2009 Universell utforming av IKT-systemer - Frode Eika Sandnes - Universitetsforlaget 2011 Prosjektarbeid En veiledning for studenter, 3. utgave Erling S. Andersen og Eva Schwenke NKI Forlaget 2001 Hovedprosjektrapport Gruppe 20 - ULV Side 61

63 11. Teknisk spesifikasjon Verktøy Trello - Verktøy til å liste oppgaver og arbeidsfordeling. Axure - Verktøy til utvikling av high-fidelity prototype. Notepad++ - Verktøy til programmering. NET Beans- Verktøy til debugging av kode. APACHE/XAMPP - Verktøy til testing av kode på localhost Programmering HTML og CSS. Danner grunnlaget for alle nettsider. PHP. Danner grunnlaget av ULV. SQL. Brukt til å administrere databasen. JavaScript. Vi brukte det for å gjøre nettsiden mer dynamisk, et eksempel kan være en nedtellingsfunksjon Ikke-funksjonelle krav Ikke-funksjonelle krav er krav tilpasset design og brukervennligheten. Krav Problemtolerant Brukervennlighet Treklikksregelen Sikkerhet Begrunnelse Viser feilmelding hvis det har oppstått en feil. Ingen feil eller strømbrudd skal kunne føre til systemkræsj. Må være lett og oversiktlig slik at så mange som mulig kan benytte det. Maks tre klikk for å komme seg til en hvilken som helst side på systemet uavhengig av hvor en er. Det skal ikke være mulig å få tilgang uten brukernavn og passord. Databasen skal være sikret mot SQL-injection. Utforming Systemet skal ha et fokus på WCAG 2.0 Hovedprosjektrapport Gruppe 20 - ULV Side 62

64 11.4. Kodeforklaring Stammen i koden ligger hovedsakelig i to filer. De befinner seg i mappen "ULV/include" og heter database.php og html.php. database.php:inneholder alle interaksjoner til databasen. Filen er delt opp i 5 klasser: user, course, group, test, file. Objektene kan legge til, hente ut, endre og slette tilhørende attributter fra databasen. Det vil for eksempel si at klassen user kan legge til brukerdetalj, hente ut rettighetsnivå, endre passord og slette bruker. html.php: Har klassen html. Denne klassen inneholder funksjoner som gir ut all html som er brukt på siden. (med unntak av logginn.php og admin.php).konstruktøren inkluderer arket database.php og lager en public variabel som er en instans av klassen course. Funksjonene i klassen html, lager eventuelle instanser av objektene i database.php og kaller på tilhørende metoder, inkluderer html filer eller sender selv direkte ut html. PHP filer i "ULV/", lager en instans av html og bruker funksjonene til å få ut html. Poenget med dette er å skape en modul basert html koding. Som gjør hver enkelt side oversiktlig. Mappe oppbygging: ajax: PHP-script som blir brukt i ajax kall fra javascript. bilder: Bildefiler som blir brukt på siden. data: Systemet bruker den som en temp mappe. forum: En fungerende prototype av forum funksjonalitet. html: Filene som blir inkludert av klassen html fra "ULV/include/html.php". include: PHP-filer med klasser ogphp-filer som validerer forms. js: Alle javascript filer. postback: PHP-sider som brukeren blir sendt til uten å se det. style: Alle style/css ark. PHP-filer: Alle filene som ligger her er tilgjengelig i grensesnittet. Hovedprosjektrapport Gruppe 20 - ULV Side 63

65 11.5. Kodestandard Database Denne er skrevet på norsk. Små bokstaver på tabellene, mens alle attributtene er skrevet med stor bokstav i begynnelsen av ordet. Alle auto-increment attributter avslutter med enten...id eller...nr. Benevning: Gjelder HTML, CSS, Javascript og PHP. Koden er skrevet på engelsk for å unngå æ, ø og å. Klassenavn: små bokstaver. Metodenavn: Begynner med små bokstaver og har stor bokstav for hvert nytt ord. Et eksempel er getusernamefromallusers ( ){}. Variabler: Variabler av type publicbegynner med stor bokstav, mens private variabler begynner med liten bokstav Sikkerhet Pålogging:Når man logger inn opprettes det en session-variabel på klienten, uten denne er det umulig å få tilgang. Systemet tildeler en bestemt session-variabel tilhørende brukers rettighetsnivå (student, lærer og administrator). Dette sikrer systemet mot at brukere utfører endringer som de ikke har rettigheter til. SQL-injection: Input fra databasen går gjennom en metode som sikrer seg imot SQLinjection. Passord: Passordet er kryptert i databasen med sha 256. Hovedprosjektrapport Gruppe 20 - ULV Side 64

66 11.7. Oppbygning Det er tre layouter de fleste funksjonaliteten er tilgjengelig under. Kursnavigasjon Den første og viktigste layoutet danner kursmenyen og eventuelt kursverktøy. Det er her studenten og læreren bruker nesten all tiden. Her kan for eksempel brukeren velge seg inn på et bestemt kurs for å så laste ned fagstoff. Administrasjons meny Dette er layoutet for menyer utenfor kursinnholdet. Denne benytteshovedsakelig for å endre innhold i databasen eller sende brukeren til andre sider som gjør det. I dette eksempelet kan administrator legge til, redigere eller slette kurs. Hovedprosjektrapport Gruppe 20 - ULV Side 65

67 Admin Denne layouten inneholder alle de mer avanserte funksjonen som administrator har. Det er kun administrator som har tilgang til disse sidene. Det skal nevnes at det fortsatt er mangler ved denne layouten.admin kan her markere flere brukere og legge dem til som lærere, studenter eller administratorer. Hovedprosjektrapport Gruppe 20 - ULV Side 66