Hovedprosjekt Høgskolen i Oslo og Akershus. Gruppe 11. Mohamed el Morabeti, s Hotan Nejad, s Arlen Syver Wasserman, s193956

Transkript

1 Hovedprosjekt 2017 Høgskolen i Oslo og Akershus Gruppe 11 Mohamed el Morabeti, s Hotan Nejad, s Arlen Syver Wasserman, s Studentparlamentet - HiOA 1

2 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo PROSJEKT NR Telefon: Telefaks: TILGJENGELIGHET Åpen BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL: Studentparlamentet DATO ANTALL SIDER (inkl. vedlegg) 192 PROSJEKTDELTAKERE (ALFABETISK) Arlen Syver Wasserman (s193956) INTERN VEILEDER Boning Feng Hotan Nejad (236770) Mohamed el Morabeti (s198748) OPPDRAGSGIVER Studentparlamentet, HiOA KONTAKTPERSON Einar Belck-Olsen SAMMENDRAG Oppdragsgiver for hovedprosjektet er Studentparlamentet, HiOA (videre referert som Studentparlamentet). Studentparlamentet er HiOAs øverste studentorgan, og jobber for å følge opp studentenes faglige, økonomiske og sosiale interesser ved å sikre at deres stemmer blir hørt i saker som angår de. Prosjektet vi skal utføre for Studentparlamentet består av tre utviklingsoppgaver. Vi skal forbedre deres nettsted med tanke på design og informasjonsarkitektur, samt utvikle digitaliserte interne arbeidsverktøy som skal erstatte dagens arbeidsverktøy. 3 STIKKORD Informasjonsarkitektur, systemutvikling, C# Studentparlamentet - HiOA 2

3 Innholdsfortegnelse Innledning..4 Kravspesifikasjon.. 5 Prosessdokumentasjon.. 17 Produktdokumentasjon Kildeliste. 151 Dataordbok Vedlegg #1 - Opprinnelig kravspesifikasjon. 155 #2 - Arbeids- og fremdriftsplan #3 - Prosjektdagbok #4 - Datainnsamling #5 - Low-fidelity prototype av nettsted..174 #6 - High-fidelity prototype av nettsted.175 #7 - Samtykkeskjema for intervju med ordstyrer #8 - Samtykkeskjema for brukertest av prototyper #9 - Samtykkeskjema for fokusgruppeintervju. 192 Studentparlamentet - HiOA 3

4 Innledning Forord Denne prosjektrapporten har til hensikt å dokumentere arbeidet og produktene vi har utviklet i forbindelse med vårt hovedprosjekt ved Høgskolen i Oslo og Akershus, våren Rapporten er bygd opp ved hjelp av en rekke enkeltstående deler som danner en helhet, og er ment å gi leserne innsikt og forståelse av prosessen og systemene som har blitt utviklet. I forbindelse med dette prosjektet ønsker vi å takke vår oppdragsgiver, Studentparlamentet og deres kontaktperson Einar Belck-Olsen for godt samarbeid, og nyttige tilbakemeldinger. Vi ønsker også å rette en takk til vår veileder Boning Feng for våre veiledningsmøter, og for nyttige tips og innspill vi har mottatt underveis i prosessen. Til slutt ønsker vi å takke alle foreleserne vi har hatt for alt de har lært oss gjennom studietiden. Leserveiledning Sluttrapporten er hovedsakelig rettet mot sensor og oppdragsgiver, og er delt inn i enkeltstående dokumenter som tar for seg prosjektets ulike deler. Hver del kan leses hver for seg, men vi anbefaler imidlertid at rapporten leses i sin helhet i henhold til vår fremstilling for optimal forståelse og innsikt. Rapportens struktur tar utgangspunkt i høgskolens dokumentasjonsstandard (Høgskolen i Oslo og Akershus), men med hensyn til lesbarhet og naturlig rekkefølge har vi organisert rapportens deler noe annerledes der vi har funnet det hensiktsmessig. Til tross for at det ikke kreves inngående teknisk kunnskap for å lese denne rapporten, så er det allikevel en fordel om leseren har et visst teknologisk utgangspunkt. For å bidra til en god leseropplevelse har vi utformet en felles dataordbok for hele rapporten som forklarer eventuelle ukjente begreper og forkortelser. Denne kan man finne ved å se i innholdsfortegnelsen. Studentparlamentet - HiOA 4

5 Kravspesifikasjon Hovedprosjekt - Gruppe 11 Høgskolen i Oslo og Akershus Studentparlamentet - HiOA 5

6 Innholdsfortegnelse for kravspesifikasjon Presentasjon Om bakgrunnen....7 Forord Leserveiledning Systembeskrivelse...9 Nettsted.,,,,.9 Mål. 9 Brukergrupper av nettstedet.. 9 Funksjonelle krav.10 Ikke-funksjonelle krav...10 Talerliste Use-case diagram Funksjonelle krav...12 Ikke-funksjonelle krav...13 Dokumentbehandling Funksjonelle krav...13 Rammekrav til systemet Logisk datamodell...14 Krav til systemkonstruksjon...15 Krav til dokumentasjon Krav til manuelle funksjoner..16 Studentparlamentet - HiOA 6

7 Presentasjon Oppdragsgiver: Prosjekttittel: Oppgave: Studentparlamentet, HiOA Studentparlamentet Forbedring av nettside og utvikling av IT-systemer Periode: Januar - Mai 2017 Gruppenummer: 11 Gruppemedlemmer: Mohamed el Morabeti, s Hotan Nejad, s Arlen Syver Wasserman, s Talsmann: Intern veileder: Ekstern veileder: Hotan Nejad Boning Feng Einar Belck-Olsen einar.belck-olsen@studentparlamentet.no Jannicke Døvre/Edvard Wølner Bjørnson Tlf.: orgkons@studentparlamentet.no Prosjektside: Om bakgrunnen Oppdragsgiver for hovedprosjektet er Studentparlamentet, HiOA (videre referert som Studentparlamentet). Studentparlamentet er HiOAs øverste studentorgan, og jobber for å følge opp studentenes faglige, økonomiske og sosiale interesser ved å sikre at deres stemmer blir hørt i saker som angår de. Prosjektet vi skal utføre for Studentparlamentet består av tre utviklingsoppgaver. Vi skal forbedre deres nettsted med tanke på design, innhold og universell utforming, samt utvikle to digitaliserte interne arbeidsverktøy som skal erstatte dagens arbeidsverktøy. Studentparlamentet - HiOA 7

8 Nettstedet skal utvikles til å bli mer visuelt tiltalende, enklere å finne fram i, samt mer tilgjengelig og relevant for nasjonale og internasjonale studenter med tilpasningsbehov. De digitaliserte interne arbeidsverktøyene vi skal utvikle består av et talerliste-system og et system for dokumentbehandling. Talerliste-systemet skal benyttes under deres møter for å hjelpe ordstyrer til å enklere holde oversikt over hvem som skal snakke. Denne vil også tillate møtedeltakerne å melde seg opp på listen på en mer effektiv og oversiktlig måte, enn gjennom «roisalen.no»-løsningen de benytter i dag. Systemet for dokumentbehandling skal digitaliseres fra dagens ineffektive løsning med Google docs som arbeidsverktøy til et eget system som skal forenkle og effektivisere prosessen med å motta og behandle elektroniske endringsforslag. Forord Hensikten med en kravspesifikasjon er å utarbeide en beskrivelse og enighet med oppdragsgiver om prosjektets krav og rammer. Dette er et sentralt dokument da det sikrer at partene er innforstått med forventningene om hva som skal gjøres, slik at man unngår eventuelle misforståelser og uenigheter. Dokumentet er beregnet for alle prosjektets interessenter da den gir sensor, veileder og oppdragsgiver et raskt overblikk over prosjektets utvikling, og tjener som en rettesnor for utviklerne gjennom hele prosjektet. Kravspesifikasjonen har gitt vårt prosjekt retning og hjulpet oss til å bedre forstå oppdragsgivers behov og ønsker. Dokumentet har også bidratt til å veilede oss i utarbeidelsen av prosjektet i henhold til forventningene som vi ble enige om. Mer om hvordan dette fungerte i praksis har blitt plassert i prosessdokumentasjonen. Leserveiledning Kravspesifikasjonen har blitt organisert med tanke på å forenkle og effektivisere lesingen av et omfattende dokument. Den er ment til å gi leseren en bedre oversikt og forståelse for prosjektrapporten, samt valg som har blitt gjort i forbindelse med utviklingen. For å bidra til leserens forståelse av teksten har vi utarbeidet en dataordbok som forklarer eventuelle ukjente ord og uttrykk vi tar i bruk. Studentparlamentet - HiOA 8

9 Systembeskrivelse Prosjektet er delt inn i 3 under-prosjekter; nettsted, talerliste, og dokumentbehandling. Under presenterer vi systembeskrivelsen for de tre ulike delene. Nettsted Oppdragsgiver har allerede et nettsted. Vårt oppdrag er å re-organisere informasjonsarkitekturen, gjøre den tospråklig, samt gjøre nettsiden mer tiltalende designmessig. Oppdragsgiver ønsket at vi skulle benytte WordPress. Mål: Forbedre brukeropplevelsen til nettsidens ulike brukergrupper, ved å gjøre navigering til relevant informasjon enklere og mer intuitiv, samt forbedre den visuelle utformingen. Brukergrupper av nettstedet: - Studenter ved HIOA, deriblant: - Utvekslingsstudenter - Engelsktalende studenter - Tillitsvalgte studenter - Representantene for Studentparlamentet (inkludert Arbeidsutvalget) Informasjon som må være tilgjengelig for studenter: - Hva er Studentparlamentet (SP)? - Hvilken rolle spiller SP i studentdemokratiet? - Hvordan kan man engasjere seg? - Hvordan kan en student engasjere seg i studentdemokratiet gjennom Studentparlamentet, eventuelt henvise til andre organisasjoner. - Verv - Nyheter - Resolusjoner - Dokumenter i alle kategorier Brukergruppe: Engelsktalende studenter/utviklingsstudenter - Nettside må også tilbys på engelsk gjennom en tospråklig løsning. Studentparlamentet - HiOA 9

10 Brukergruppe: Tillitsvalgte - Verv - Dokumenter i alle kategorier - Verktøykasse for tillitsvalgte - Informasjon rundt møtene - Når er neste møte? - Hva skjedde forrige møte? - Hva ble vedtatt? Brukergruppe: De valgte representantene i Studentparlamentet - Informasjon rundt møtene - Når er neste møte? - Hva skjedde forrige møte? - Hva ble vedtatt? - Saksdokumenter Design: - Nettsiden skal ha et rent design med få farger, og enkel menystruktur Funksjonelle krav: - Søkefelt; nettsiden skal tilby at bruker kan søke etter informasjon på hele nettsiden. - Kalender; bruker skal kunne se kalender med informasjon om kommende hendelser. - Bruker skal kunne finne relevant informasjon. - Nettstedet skal tilbys på engelsk for studenter som ikke kan norsk. Ikke-funksjonelle krav: - Brukervennlighet - Nettstedet skal være lett å bruke og ha en brukervennlig design. - Nettstedet skal være enkelt å administrere. - Universell utforming - Nettstedet skal ta hensyn til krav om universell utforming av IKT-systemer. - Tilgjengelighet - Nettstedet skal kunne brukes på datamaskiner, smarttelefoner og nettbrett. - Estetiske krav - Nettstedet skal ha en minimalistisk og stilren design. Studentparlamentet - HiOA 10

11 - Sikkerhet - Nettstedet skal ha nødvendig sikkerhet. - Leveransekrav - Nettstedet skal være ferdig for sensur 24. mai Talerliste I forbindelse med møtene SP holder, vil man at deltakerne skal selv kunne melde seg til innlegg, replikk (og dagsorden), samt visning av en liste over hvem som taler, kommende talere og estimert tid det tar for at alle på listen er ferdig snakket. Via mobiltelefoner og laptop kan møtedeltakerne melde seg som deltakere i møtet. Derfra kan man melde seg til innlegg, replikk (og dagsorden). Dersom man ikke har med seg mobiltelefon eller laptop, kan man via ordstyreren gjøre dette. Ordstyreren har utvidede muligheter; manuelt legge til deltakere, manuelt melde deltakere til innlegg, replikk (og dagsorden) m.m. Studentparlamentet - HiOA 11

12 Use-case diagram Figur 1. Use-case diagram Funksjonelle krav - Brukere skal selv fylle inn navn og om de er representanter eller studenter. Dette skal lagres lokalt på klienten slik at man ikke trenger fylle ut dette hver gang. - Det gis adgang til 2 replikker etter hvert innlegg, og representanter er prioritert hvis det er flere enn 2 som melder seg til replikk. Antall replikker tillatt skal kunne forandres på via ordstyrer. - Ordstyrer markerer når en taler er ferdig å snakke, for å iterere til neste taler. - Ordstyrer skal kunne stenge muligheten for oppmelding til innlegg og/eller replikk. - Ordstyrer skal kunne forandre rekkefølgen på talere som ikke har talt. - Det skal estimeres hvor mye tid det vil tar før alle på listen har snakket, med hensyn til replikker osv. Studentparlamentet - HiOA 12

13 Ikke-funksjonelle krav: - Si ifra til søkemotorer at denne løsningen ikke skal indekseres. - Ordstyrer rollen skal være sikret med et passord. Dokumentbehandling SP har mange dokumenter og de mottar endringsforslag til disse dokumentene. SP vil ha en egen løsning knyttet til dette med å motta endringsforslag og ha god oversikt over disse. Et endringsforslag består av type (tillegg, endring, strykning), forslagsstiller, sidenummer, linjenummer og forslagstekst/beskrivelse. Funksjonelle krav: - Studentparlamentet skal kunne laste opp nye dokumenter til systemet. - Alle brukere skal kunne oversikt over dokumenter og deres endringsforslag. Og forslagene skal være organisert etter linjenummer. - Studenter ved HIOA skal kunne sende inn nye endringsforslag for et dokument. - Studentparlamentet skal ha muligheten for å slette et endringsforslag. - Si ifra til søkemotorer at denne løsningen ikke skal indekseres. Rammekrav til systemet Tilgjengelighet: Ved en eventuelt systemkrasj eller tap av strøm skal systemet av seg selv komme tilbake til operativ tilstand uten tilsyn. Sikkerhetskopier: Det skal tas sikkerhetskopier av databasen hver dag. Skalerbarhet: Nettsiden skal kunne håndtere 5000 brukere. Talerlisten skal kunne håndtere 50 brukere, dokumentbehandling skal kunne håndtere 50 brukere. Personvern: Systemet skal ivareta personvern ved at de skal gå ann å slette sitt navn fra løsningene, enten ved å sende mail til SP eller å slette selv. Studentparlamentet - HiOA 13

14 Sikkerhet: Sterke passord, sikker forbindelse mellom klient og server (TLS) Kvalitet (brukskvalitet): Ved å teste systemet grundig og møte de kravene som er satt. Dokumentering: Dokumenter for brukere og videreutvikling skal være tilgjengelig hos de ansvarlige for systemet. Robusthet: Sikre systemet så godt som mulig slik at det ikke har noen sårbarheter. Vedlikeholdbarhet: Ved å kommentere i kildekoden og dokumentere skal systemet skal være lett å videreutvikle. Platform kompatibilitet: Løsningene er nettbaserte og vil kjøres i nettlesere. Produktkrav: Nettleser krav: Microsoft IE(10+), Google Chrome, Mozilla Firefox, Apple Safari. Logisk datamodell fk = forreign-key; feltet refererer til en annen tabell. Talerliste Organisasjon - Navn Deltaker - Organisasjon (fk: Organisasjon) - Nummer - Navn Studentparlamentet - HiOA 14

15 - Kjønn Talerliste - Organisasjon (fk: Organisasjon) - Deltaker (fk: Deltaker) - Rekkefølge - Nåværende taler (sant eller ikke sant) - Replikker (fk: Replikker) Replikker - Replikk for (fk: Talerliste) - Replikant (fk: Deltaker) - Rekkefølge Dokumentbehandling Dokument - Navn - Fil sti - Dato opplastet Endringsforslag - fk: Dokument - Navn - Type - Sidenummer - Linjenummer - Forslagstekst - Dato opplastet Administratorer - Login - Passord Krav til systemkonstruksjon - Nettstedet må benytte WordPress. Studentparlamentet - HiOA 15

16 Krav til dokumentasjon Det er et krav om å legge til rette for dokumentasjon, som skal kunne gi innsikt i hvordan systemet fungerer og hvordan det kan videreutvikles. Det vil derfor bli tilgjengeliggjort en systemdokumentasjon og brukerdokumentasjon. Sistnevnte skal være tilgjengelig på Studentparlamentets nettsider. Den skal bistå sluttbrukere i forbindelse med samhandling med brukergrensesnittet, samt inneholde informasjon som er nødvendig for å anvende vår applikasjon. Systemdokumentasjonen skal beskrive systemets hovedfunksjoner, blant annet arkitektur, design og egen PDF som inneholder forklaringer i forhold til databasen, front og back-end. Krav til manuelle funksjoner - Arbeidsutvalget kan igjennom WordPess oppdatere nettsiden sin. - Arbeidsutvalget skal kunne slå av og restarte servere. Studentparlamentet - HiOA 16

17 Prosessdokumentasjon Hovedprosjekt - Gruppe 11 Høgskolen i Oslo og Akershus Studentparlamentet - HiOA 17

18 Innholdsfortegnelse for prosessdokumentasjon Forord 20 Innledning.20 Forberedelser og planlegging 21 Valg av oppgave.21 Definisjon av oppgave/omfang.21 Teknologier og verktøy..22 Ny læring..23 Valg av utviklingsmetodikk 24 Ansvarsfordeling.24 Risikoplanlegging 25 Arbeidsprosess Arbeidsplass Kommunikasjon Møter Logg/dagbok.. 27 Fremdriftsplanen og dens rolle...27 Utviklingsmiljø Utviklingsprosess Oppstart...28 Nettside Innsiktsfase...28 Kompetansetilegning...30 Oppsett..31 System for dokumentbehandling Innsiktsfase...31 Kompetansetilegning...31 Oppsett..32 System for talerliste Innsiktsfase...32 Kompetansetilegning...33 Studentparlamentet - HiOA 18

19 Oppsett..33 Utviklingsfaser. 33 Nettsted...33 Utviklingsfase Utforming av prototyper Presentasjon av ferdige prototyper for oppdragsgiver.. 36 Designendring...37 Utviklingsfase Utvikling av nettsted i Wordpress Justeringer og ferdigstilling av nettstedet System for dokumentbehandling Fase 1 - Utkast av brukergrensesnitt Fase 2 - Implementere funksjonalitet Fase 3 - Autentisering, brukere og sikring 56 Fase 4 - Tilleggsfunksjonalitet og justeringer Fase 5 Testing og bugfiksing...57 System for talerliste..57 Utviklingsfase Utviklingsfase Utviklingsfase Dokumentasjonsfase Kravspesifikasjonen og dens rolle 62 Nettsted 62 System for dokumentbehandling.63 System for talerliste...63 Brukertesting 63 Brukertesting av low-fidelity prototype 64 Walk-throughs...64 Brukertesting av high-fidelity prototype...64 Fokusgruppeintervju..65 Oppsummering og evaluering Studentparlamentet - HiOA 19

20 Forord Denne delen av dokumentasjonen skal beskrive hvordan gruppen har arbeidet med hovedprosjektet. Her skal vi beskrive hvordan vi har gått frem fra prosjektets oppstart og planlegging, til utvikling og ferdigstillelse, samt vurdering av de endelige resultatene. Vi skal forklare tankeprosessene rundt våre beslutninger, gjennomføring, og løsninger på utfordringer som ikke kommer direkte til syne i selve produktene. Målet med prosessdokumentasjonen er å forenkle leserens forståelse for arbeidsprosessene gruppen har gjennomgått. Prosessdokumentasjonen er i hovedsak rettet mot sensor, ettersom den skal gi leseren en forståelse for bakgrunnen for våre valg, og innsatsen vi har lagt ned i utarbeidelsen av prosjektet. Innledning Prosjektet vi ble satt til å utføre for Studentparlamentet gikk ut på å utvikle et nytt nettsted, og to digitale arbeidsverktøy som skal brukes i forbindelse med deres interne arbeider. Nettstedet de har i dag er ifølge oppdragsgiver «overmoden for en overhaling», har et uinspirert design, og en lite brukervennlig informasjonsarkitektur. Med dette som utgangspunkt, er målet med hovedprosjektet å re-designe nettstedet til å bli mer brukervennlig, estetisk tiltalende og moderne. Oppdragsgiver ønsket at de ulike brukergruppene av siden skulle klare å finne frem til relevant informasjon på en mer logisk måte, oppleve siden som mer tiltalende å bruke, og som et resultat av dette få mer utbytte av informasjonen de formidler. Tospråklighet var også en prioritet da Høgskolen og Studentparlamentet får stadig flere engelsktalende studenter, og som en følge av dette ønsker å være en representant for alle. Målet vårt i denne sammenhengen har vært å ta hensyn til disse behovene, og utvikle en nettside som studenter kan få glede av, og som er enkel å administrere. En av de interne oppgavene til Studentparlamentet er å behandle saksdokumenter i forbindelse med deres parlamentsmøter. Løsningen de benytter i dag for å motta og behandle endringsforslag av dokumentene består av penn og papir, og Google Docs. Dette opplever de som lite effektivt, og som en følge av dette ønsket de at vi skulle utvikle en digital løsning som kan bidra til å effektivisere og forenkle dette arbeidet. Det andre interne arbeidsverktøyet de benytter er et talelistesystem som blir brukt av møtets Studentparlamentet - HiOA 20

21 ordstyrer til å holde orden på hvem som skal snakke under parlamentsmøtene, og som tillater møtedeltakerne å melde seg opp på listen. Systemet de bruker tilhører roisalen.no, og oppleves som lite optimalt. De ønsket følgelig en ny digital løsning som er mer brukervennlig, effektivt og sikkert. Vårt mål med utviklingen av disse digitale arbeidsverktøyene har vært å utvikle løsninger som oppfyller behovene deres på best mulig måte. Forberedelser og planlegging Valg av oppgave Vi startet planleggingen av hovedprosjektet allerede i september 2016, ved å diskutere hva slags type prosjekt vi kunne tenke oss å gjennomføre. To av gruppemedlemmene var interesserte i prosjekter som omhandlet mest mulig programmering, mens tredjemann var mest interessert i design-aspektet ved et fremtidig prosjekt. Med dette som utgangspunkt startet vi prosessen med å sende ut søknader til potensielle oppdragsgivere per epost og ved telefonoppfølging. Denne prosessen endte med at vi landet på Studentparlamentet som endelig oppdragsgiver, da deres prosjektrammer samsvarte med våre kriterier, og preferanser for type oppdrag. Definisjon av oppgave/omfang Da vi kom i kontakt med Studentparlamentet hadde de annonsert at de hadde en rekke konkrete prosjekter de ønsker å få gjennomført, og vi kunne velge hvilke vi ønsket. Vi bestemte oss for å lage et nytt nettsted basert på oppdragsgivers eksisterende nettsted, og utvikle digitale arbeidsverktøy for dokumentbehandling og talerliste. Oppdragsgiver hadde beskrevet hva produktene skulle gjøre, men oppga vage og uspesifiserte krav til hvordan produktene skulle se ut. Dette innebar at vi hadde relativt frie tøyler til å definere, og spesifisere produktenes design og funksjonalitet. Denne friheten hadde imidlertid en pris, da vi ikke fikk full oversikt over prosjektets omfang før vi hadde analysert resultatene fra ulike typer datainnsamling. Ettersom vi også hadde hørt at oppdragsgivere ofte oppdager først senere i prosessen hva de virkelig ønsker, hadde vi fokus på å involvere og holde tett kontakt med dem da vi definerte oppgaven og dens omfang. Denne tilnærmingen opprettholdt vi etter beste evne gjennom hele prosjektperioden. Studentparlamentet - HiOA 21

22 Teknologier og verktøy Google Docs Har blitt brukt til å ha oversikt over våre dokumenter, og jobbe parallelt og mer effektivt da flere kan jobbe på samme dokument samtidig, se endringer og holde seg oppdatert på hva som har blitt gjort, uavhengig om de sitter hjemme eller sammen. Microsoft Word Ble brukt til å formatere innholdet i den endelige rapporten som vi skrev i Google Docs. Vi valgte å benytte Word til dette da vi opplever deres redigeringsverktøy som bedre til dette formålet. Facebook Ble brukt til å kommunisere med hverandre når vi ikke hadde møter. Outlook Ble brukt til å holde kontakt med oppdragsgiver, veileder og hverandre vedrørende spørsmål knyttet til hovedprosjektet, avtale om møte eller brukertesting. Powerpoint Ble brukt til å lage de første skisseutkastene til nettsiden. Ble brukt som verktøy ettersom det gjorde det mulig å simulere interaksjon mellom de ulike sidene ved å lenke sidene sammen. Dette lot oss lage en visuell og klikkbar presentasjon av hvordan det endelige nettstedet kunne se ut i Wordpress. Youtube Ble brukt til å se «tutorials» i forbindelse med læring av Wordpress og Angular. Wordpress Ble brukt, etter krav fra Studentparlamentet, til å lage den endelige nettsiden. Wordpress er et CMS (Content Management System) og Studentparlamentet - HiOA 22

23 rammeverk for å bygge nettsider. XAMPP I forbindelse med utviklingen av nettsiden, må Wordpress kjøres på en server som kan eksekvere PHP, i tillegg må det være en SQL server tilgjengelig for Wordpress. XAMPP programvaren tilbyr dette, som kjøres som en lokal webserver. Visual studio Utviklingen av løsningene Dokumentbehandling og Talerliste foregikk i utviklingsverktøyet Visual Studio som er en IDE (Integrated development environment). Angular Ble brukt i forbindelse med utviklingen av både vårt dokumentbehandlingssystem og talerlistesystem. Både AngularJS og Angular2 ble kombinert under utviklingen. Ny læring I forbindelse med utviklingen av nettstedet, var det krav fra Studentparlamentets at utviklingen ble gjort i «Wordpress». Vi hadde ingen erfaring med WordPress fra før, men lærte oss det ved å se på «tutorials» (læringsvideoer) på «YouTube», og ved hjelp av egeninnsats i form av prøving og feiling. I forbindelse med utviklingen av de to digitale arbeidsverktøyene falt valget på «Angular» som ønsket teknologi. Ettersom vi ikke kunne dette godt nok fra før så bestemte vi oss for å lære det ved hjelp av «tutorials» på YouTube, og betydelig egeninnsats. For utviklingen av talerliste systemet var det viktig å bruke "divide and conquer" metoden. Ved å dele opp problemene i flere små problemer kom vi frem til at det beste var å bygge Studentparlamentet - HiOA 23

24 opp prosjektet slik at hver del av problemet ble et slags eget "element" som kunne bli tatt hånd om. Dette gjorde det slik at vi konkluderte med å bruke Angular 2. Sistnevnte er et JavaScript basert open-source front-end web applikasjon rammeverk. Angular implementerer MVC mønsteret for å separere presentasjon, data og logiske komponenter. Valg av utviklingsmetodikk I valget av utviklingsmetodikk har vi brukt scrum da detaljene i kravspesifikasjonen vi fikk tildelt av oppdragsgiver i begynnelsen av prosjektperioden ikke var klart definerte. Scrum er som mange vet et smidig rammeverk for iterativ og inkrementell utvikling. Dette betyr at den baserer seg på korte intervaller (sprinter), med jevnlig justering av krav og prioriteringer (Sommerville, 2010, s. 72). Vi hadde ikke de klassiske «stand-up» møtene, med en offisiell scrum-master som man typisk assosierer med scrum, men vi hentet vår inspirasjon fra den. Dette betød at vi ved starten av våre gruppemøter, som vi hadde en til to ganger i uken, pleide å gå igjennom det vi hadde gjort med prosjektet siden sist, hva vi skulle gjøre under møtet, og hva som måtte gjøres til neste gang. Denne måten å jobbe på fungerte godt for oss, da den bidro til godt samarbeid og en helhetlig oversikt over prosjektets detaljer og fremdrift. Vi innså at en smidig metode var en effektiv måte å jobbe på da vi ikke hadde tilstrekkelig med informasjon om oppgavens omfang og innhold, og at vi ville bli nødt til å finne veien samtidig som vi gikk den. Valget falt på denne formen siden vi tidlig innså at det ikke ville være mulig å samle alle krav til våre løsninger før vi begynte. Vi var også klar over at krav kunne endre seg underveis, og at vi da måtte finne nye løsninger som ville samsvare med oppdragsgivers ønsker og krav. Denne utviklingsmetodikken med dens iterative utviklingsprosesser gjorde det enklere for oss å kontinuerlig legge til, fjerne, prioritere og implementere ulike krav. Ansvarsfordeling I løpet av prosjektperioden innså vi at det var hensiktsmessig med tanke på effektiv og god progresjon å fordele hovedansvaret for prosjektets tre ulike deler mellom oss på følgende måte; - Nettsted: Hotan - System for dokumentbehandling: Arlen Studentparlamentet - HiOA 24

25 - System for talerliste: Mohamed - Dokumentasjon: Hotan, Arlen, Mohamed - Design: Hotan Dette innebar at vi jobbet med hvert vårt ansvarsområde utenfor våre møter, og samarbeidet om å utføre nødvendige endringer i fellesskap under møtene. Risikoplanlegging Risiko Sannsynlighet/ Konsekvens Strategi Risikograd Sykefravær Lav Andre må ta ansvar for oppgaver utenfor deres område Jobbe hjemmefra Tekniske Middels Uheldige Grundige problemer utsettelser og forundersøkelser unødvendig prokrastinering Data tap Lav Forsinkelser Backup, Skylagring Kontorer kan ikke Høy Unødvendig tap av Bestille rom lokaler benyttes tid god tid på forhånd Tabell 1. Oversikt over risikoer Arbeidsprosess Arbeidsplass I forbindelse med utarbeidelsen av hovedprosjektet har vår arbeidsplass vært HiOA når vi har hatt interne gruppemøter, og våre hjem når vi har jobbet med prosjektet hver for oss. Når vi har jobbet på Høgskolen har vi alltid bestilt grupperom i forkant av hvert møte. Studentparlamentet - HiOA 25

26 Kommunikasjon Gruppen har benyttet forskjellige kommunikasjonskanaler for ulike aspekter ved prosjektarbeidet. Våre kommunikasjonskanaler: - Facebook og SMS: - Har blitt brukt til å formidle praktiske beskjeder og tips utenfor våre møter. - Epost: - Har blitt brukt til å holde kontakt med oppdragsgiver og veileder, samt videreformidling av informasjon innad i gruppen. - Google Docs: - Har blitt brukt til å holde oss oppdatert på hverandres arbeid, og jobbe med prosjektet uavhengig av om vi har sittet sammen eller hver for oss. Møter Interne møter Interne møter ble gjennomført en til to dager i uken, ved at vi satte av hele dager til å jobbe sammen. Av hensyn til hverandres skiftende timeplaner, grunnet deltidsarbeid ved siden av studiene, og prosjektarbeid i andre fag hadde vi ikke faste dager vi møttes. En løsning som fungerte bra for oss var å avtale neste møtedag og tidspunkt ved slutten av hvert møte. Vi avtalte også hvilke arbeidsoppgaver som skulle utføres av alle gruppemedlemmene til neste møte. Møter med oppdragsgiver Vi har stort sett hatt regelmessige møter med oppdragsgiver. Vi har innkalt, og blitt innkalt til møter pr epost ved behov. Møtene har blitt holdt ved deres kontor i Pilestredet 40. I begynnelsen av prosjektperioden var det svært enkelt å komme i kontakt, og avholde møter da vår hovedkontaktperson, Einar Belck-Olsen i Studentparlamentet viste stor entusiasme for prosjektet. Deretter opplevde vi en periode der dette ble vanskeligere da våre epost-henvendelser med spørsmål om prosjektet og møteinnkalling ofte ikke ble besvart før det hadde gått lang tid. Etter en stund kom vi i kontakt med deres nye konsulent, Edvard Bjørnson, som informerte at Einar var utilgjengelig. Under denne perioden hadde vi kontakt med den nye konsulenten, som i løpet av prosjektperioden hadde erstattet vår sekundær-kontaktperson, Jannicke Døvre. Vi fikk dessverre ikke mye ut av disse nye møtene da beslutninger om prosjektets Studentparlamentet - HiOA 26

27 videre retning måtte gå gjennom Einar. Dette bidro til å forsinke oss i vårt prosjektarbeid, og påvirket vår fremdriftsplan. Mot slutten av prosjektperioden da Einar var tilbake, bedret denne situasjonen seg imidlertid betraktelig da vi fikk gjenopprettet en effektiv kommunikasjonskanal, og avholdt møtene vi hadde behov for. Møter med veileder Møter med veileder har blitt avholdt ved behov. Vi har hatt statusmøter ved hans kontor, og kommunisert via e-post når vi har hatt spørsmål som han har kunnet hjelpe oss med. Møter med IT-seksjonen Møter med IT-seksjonen har blitt avholdt i forbindelse med muligheten for å få en server å installere løsningene på. Ettersom Studentparlamentet er nært knyttet HIOA, har det vært naturlig å kommunisere med IT-seksjonen. Disse møtene foregikk ved deres kontor i Pilestredet 40. Logg/dagbok Vi har loggført vår møteaktivitet i en prosjektdagbok. Her har vi etter hvert møte oppsummert, og skrevet ned relevant møteinformasjon som har vært nyttig å huske til perioden vi skulle skrive prosessdokumentasjonen. Ettersom alle skulle ha tilgang til filen, har dagboken blitt skrevet i et felles Google Docs dokument på skytjenesten til Google. I utarbeidelsen av prosessdokumentasjonen har dagboken har vært et verdifullt hjelpemiddel, og kilde til informasjon. Dagboken er lagt som vedlegg, og ligger også tilgjengelig ute på nettsiden hvor man finner sluttdokumentasjonen. Fremdriftsplanen og dens rolle I forbindelse med forprosjektet laget vi en fremdriftsplan som vi skulle følge i prosjektperioden. I begynnelsen fulgte vi denne til punkt og prikke da den var en god pådriver for å få ting gjort, og for å få oversikt over ting som måtte gjøres. Underveis i prosjektet endret imidlertid omstendighetene, kravene og ønskene seg såpass mye at det ble vanskelig å følge tidsestimatene vi hadde beregnet for igangsetting og ferdigstilling av prosjektets ulike deler. En av årsakene til at det skled ut var det faktum at oppdragsgiver i en periode utilgjengelig for å besvare sentrale spørsmål vi hadde. Fremdriftsplanen har i praksis blitt brukt til å ha oversikt over ulike deler som må ferdigstilles, Studentparlamentet - HiOA 27

28 hvor rekkefølgen og tidsrommet for utviklingen av disse har blitt tilpasset våre prioriteringer og omstendigheter. Utviklingsmiljø Dokumentbehandling og talerliste systemet ble utviklet via en Solution i Visual Studio. For å kunne samarbeide og utvikle oss imellom benyttet vi Team Foundation Server hvor arbeidet/koden ble lagret i skyen hos Microsoft. Hver av oss kunne da laste ned den siste versjonen av arbeidet via Team Foundation Server i Visual Studio. Utviklingsprosess Utviklingsprosessen beskriver de ulike fasene av utviklingen. Den er delt inn i tre hovedfaser: oppstart, utviklingsfase og dokumentasjonsfase, som beskriver prosessen, våre valg og utfordringer knyttet til utviklingen. Av hensyn til en ryddig fremstilling av utviklingsprosessen til de tre prosjektene vi har utviklet (nettsted, system for dokumentbehandling og system for talerliste), vil de tre fasene bli beskrevet separat der vi finner det hensiktsmessig. Oppstart I forbindelse med prosjektstart måtte vi som følge av uklare og uspesifiserte kravspesifikasjoner begynne prosessen med en innsiktsfase. Denne gikk ut på å kartlegge og konkretisere oppdragsgivers ønsker, samt brukernes behov for prosjektene vi skulle utvikle. Neste oppgave var å tilegne oss den nødvendige tekniske kompetansen for å komme i gang med prosjektene på en god måte. Den siste oppgaven vi utførte i oppstartsperioden var å opprette nødvendige filer og mapper for videre utvikling. Nettsted Innsiktsfase Målet med denne fasen var å lage en mer detaljert kravspesifikasjon, ved å tilegne oss en detaljert forståelse av oppdragsgivers ønsker, krav og behov for prosjektene vi skulle utvikle, samt brukernes informasjonsbehov. For å oppnå denne innsikten ble det prioritert å utføre datainnsamling i form av: Studentparlamentet - HiOA 28

29 - analyse av oppdragsbeskrivelse / opprinnelig kravspesifikasjon - møter og e-postkorrespondanse med oppdragsgiver - analyser av eksisterende nettsted - spørreundersøkelse. Innsiktsfasen begynte med at vi leste oppdragsbeskrivelsen med de generelle kravene og ønskene som oppdragsgiver hadde til den nye siden. Disse kravene listet bare opp generelle ønsker om hva de ønsket nytt, hva de ønsket å beholde fra deres eksisterende nettsted, og krav om at Wordpress ble brukt som plattform. Ut over dette hadde de i begynnelsen ingen spesifiserte formeninger om utformingens detaljer. Dette resulterte i at vi sendte de eposter med konkrete spørsmål, forslag og avholdt møter for å få bedre oversikt over deres behov. Der fikk vi blant annet tilsendt et dokument med konkrete krav til designelementer, som fargevalg og bruk av logo som vi måtte ta hensyn til For å få en oversikt over informasjonsarkitekturen og innholdet til det eksisterende nettstedet, brukte vi betydelig med tid til kartlegging, analyse og utforskning. Deretter utformet vi, og sendte ut en online spørreundersøkelse ved hjelp av Google Forms til både vanlige studenter, og representanter fra Studentparlamentet. En spørreundersøkelse er en kvantitativ metode, som passer best til å samle informasjon fra en større mengde mennesker (Sandnes, 2011). Der stilte vi en rekke åpne og lukkede spørsmål om hva de blant annet bruker Studentparlamentets nettsted til, hva de synes om dagens nettsted, og hva de følte manglet. Vi skrev en analyse av svarene som bidro til at vi fikk dannet oss en bedre forståelse for brukernes behov, og nettstedets forbedringspotensialer. Spørreundersøkelsen og analysen av denne kan ses i vedlegg under datainnsamling. Bildet under illustrerer ett av svarene vi mottok fra et åpent spørsmål vi stilte. Figur 2. Eksempel på svar fra spørreskjema Studentparlamentet - HiOA 29

30 Vår lærdom fra denne fasen: - Nettstedet er lite brukervennlig og har en ulogisk informasjonsarkitektur. - Bortimot samtlige respondenter av spørreundersøkelsen kommenterte at det er vanskelig å finne relevant informasjon på en effektiv måte. - Det er tre typiske brukere; studenter, tillitsvalgte og representanter med ulike informasjonsbehov. - Studenter: - Leter typisk etter nyttig informasjon om hva Studentparlamentet kan gjøre for de, og hvordan de kan engasjere seg. De er typiske exploratory seekers, det vil si at de ikke nødvendigvis vet helt hva de ser etter. De har en vag ide, men håper å finne noe nyttig ved å utføre en rekke søk (Rosenfeld, 2015, s. 44). - Tillitsvalgte og representanter: - er typiske known-item seekers, det vil si at de vet hva de ser etter når de oppsøker nettstedet, og har en grunnleggende god forståelse for hvor de skal starte sitt søk (Spencer, 2006). Kompetansetilegning Ettersom oppdragsgiver hadde bestemt at vi måtte videreføre bruken av Wordpress som plattform i den nye nettsiden ble det nødvendig for oss å lære oss dette publiseringsverktøyet ettersom vi ikke hadde brukt det før. Kompetansetilegningen ble gjennomført ved at vi opplærte oss selv ved hjelp av selvstudier. Opplæringsmetodene vi benyttet var: - Videolæring: Vi fant en rekke informative og nyttige kilder til opplæring ved å se på «tutorials» fra YouTube. Disse videoleksjonene forklarte hvordan vi kunne beherske bruken av Wordpress.org, og dens utviklingsmuligheter. Disse videoene ble brukt hovedsakelig før utviklingen startet. - «Learning by doing»: Etter at MySQL databasen var opprettet, og «tutorials» gjennomført satt vi i gang med å utforske de ulike funksjonalitetene Wordpress tilbyr. Ved hjelp av mye prøving og feiling lærte vi «sten for sten» hvordan vi kunne lage nettstedet vi så for oss. - Google: Ved å utføre internettbaserte Google-søk etter konkrete ting vi lurte på fant vi gode kilder til ny kunnskap.. Studentparlamentet - HiOA 30

31 Oppsett For å kunne begynne utviklingen av nettsiden i WordPress måtte vi først laste ned WordPress filen. Deretter måtte vi opprette en MySQL-database ved hjelp av web-server programvaren XAMPP. System for dokumentbehandling Innsiktsfase For å utdype og finne ut av hva kunden faktisk trengte med dette systemet studerte vi først oppdragsbeskrivelsen nøye. Vi analyserte den eksisterende løsningen (som kun var en dokumentmal de brukte) og var også med på ett av Studentparlamentets avstemnings møter hvor vi fikk se den praktiske betydningen av et slikt system. Studentparlamentet hadde også saksdokumenter med protokoller knyttet til det å motta endringsforslag for dokumentene deres, som vi brukte. Etter den første analysen, formulerte vi en rekke spørsmål. Via e-post korrespondanse og flere møter ble disse spørsmålene besvart. Målet med løsningen var å forenkle og automatisere mange funksjoner knyttet til det med å motta endringsforslag fra studenter for dokumentene som Studentparlamentet har tilgjengelig på nettsidene deres. Ettersom de brukte e-post korrespondanse til å motta endringsforslag kunne dette bli en stor byrde om det var mange forslag, og om mange av forslagene var like. Det ble kartlagt de forskjellige brukerne av systemet, hvilken informasjon som skulle behandles av systemet og hvilke funksjoner systemet skulle utføres på denne informasjon. Kompetansetilegning Vi ble enige om at løsningen skulle være nettbasert som skal fungere gjennom nettleseren. For å kunne lage en moderne web-applikasjon med dynamiske nettsider ble vi enige om å benytte et rammeverk for visningen av informasjon på klient siden / nettleseren. Nærmere spesifisert ble vi enige om rammeverket AngularJS laget av Google. For servering av løsningen og lagring av data bruker vi nettserver rammeverket Microsoft Studentparlamentet - HiOA 31

32 .NET Core og Entity Framework Core. For å lære AngularJS rammeverket ble det først og fremst brukt dokumentasjon og eksemplene deres hos Andre kilder som ble brukt var søkemotoren hvor mange av søkestrengene ledet til nettstedet For å lære.net Core og Entity Framework Core ble dokumentasjonen og eksemplene hos brukt. Ellers så var det søkemotoren Google og som var gode kilder. Oppsett Det ble først opprettet en nytt prosjekt i Visual Studio 2017 av typen ASP.NET Core Web Application. De første filene i løsningen ble knyttet opp til en Team Foundation Server repository via Løsningen var nå tilgjengelig for alle gruppemedlemmer ved bruk av Visual Studio 2017 og dets integrerte verktøy for kommunikasjon med Team Foundation Server. De nødvendige filene for å bruke AngularJS ble lastet ned ifra og inkludert i prosjektets www mappe (der.net Core serverer statiske filer til nett klientene) System for talerliste Innsiktsfase For å få et bedre overblikk over talerliste-systemet vi skulle utvikle dro vi på et av Studentparlamentets faste møter og observerte hvordan dagens løsning fungerte i praksis og hvordan selve møtet foregikk. Dette gav oss verdifull informasjon om deres behov og Studentparlamentets arbeid. Etter at vi gjennomførte observasjonen på deres møte innså vi at det er Studentparlamentets ordstyrer som vil ha mest nytte av talerliste-systemet, og at det ville være hensiktsmessig å gjennomføre et semi-strukturert intervju med denne personen. Vedkommende signerte på et samtykkeskjema før vi startet intervjuet. Her stilte vi spørsmål som vi hadde forberedt på forhold, samt oppfølgingsspørsmål. Svarene vi mottok gav oss verdifull informasjon om deres behov og ideer til funksjonalitet. Se vedlegg. Studentparlamentet - HiOA 32

33 Kompetansetilegning Mye av det vi lærte under utviklingen av dokumentbehandlingsystemet kom til nytte under utviklingen av talerlistesystemet. Angular ble brukt som hovedrammeverk, men denne gangen bestemte vi oss for å bruke Angular 2, som er en forbedret versjon av AngularJS. For å bruke Angular 2 måtte vi lære oss TypeScript som er programmeringsspråk utviklet av Microsoft. For å lære Angular2 rammeverket ble både dokumentasjon og eksemplene hos brukt. For å lære TypeScript brukte vi Oppsett For å sette opp prosjektet ble følgende link brukt: For å sette opp et lokalt utviklingsmiljø på maskinen måtte vi klone quickstart prosjektet som lå ute på Angular sin Github repository, link: Dermed ble NPM dependencies installert, etter en testkjøring bestemte vi oss for å migrere prosjektet over til Visual Studio hvor prosjektet kunne bli koblet opp mot TFS, slik at alle kunne jobbe på prosjektet. For å gjøre akkurat det måtte vi installere angular-cli, link: i tillegg til.net core sdk og runtime binær filene, link: Utviklingsfaser Vi har av hensyn til en ryddig fremstilling, beskrevet utviklingsfasene for nettstedet, systemet for dokumentbehandling og talerlistesystemet hver for seg. Nettsted Utviklingen av nettstedet har vært iterativ, og vi har delt prosessen inn i to hoveddeler; fase 1 og fase 2. Disse fasene beskriver våre valg, utfordringer som oppstod under utviklingen, og hvordan gruppen kom frem til de forskjellige løsningene. Studentparlamentet - HiOA 33

34 Utviklingsfase 1 Innsikten vi tilegnet oss i oppstartsfasen gjorde det blant annet klart for oss at nettstedet har tre typiske brukergrupper; studenter, tillitsvalgte og representanter, som har ulike behov og motiver for å besøke nettstedet. Vi brukte resultatene og våre vurderinger fra datainnsamlingen vi utførte i innsiktsfasen som utgangspunkt da vi startet utviklingsfase 1. Utforming av prototyper Ifølge (Blomkvist, 2014) brukes prototyper for å forbedre foreslåtte ideer og løsninger. Videre hevder de at prototyping er en iterativ prosess, hvor ideer og løsninger blir testet og videreutviklet. Vi ønsket derfor å lage prototyper før vi begynte med utviklingen av nettstedet. Vi startet med å lage enkle og minimalistiske skisser av hvordan vi så for oss forsiden og menystrukturen til nettstedet. Basert på skissene, utviklet vi en lo-fidelity prototype. Denne lofidelity prototypen ble laget raskt og enkelt, tidlig i prosjektet ved hjelp av penn og papir. Denne ble brukt til å gjennomføre en brukertest som ga oss et bedre grunnlag for å lage en mer avansert high-fidelity prototype. Brukertestingen er beskrevet nederst i prosessdokumentasjonen, og prototypen kan ses i vedlegg. Etter at vi hadde diskutert lo-fidelity prototypen, og fått tilbakemeldinger på disse bestemte vi oss for å lage en klikkbar, hi-fidelity prototype av nettstedet som kunne simulere funksjonaliteten vi ønsker for det endelige nettstedet. Dette innebar at vi strukturerte innholdet og informasjonsarkitekturen basert på informasjonskildene vi hadde fra innsiktsfasen, og laget et komplett sett av mockups for hele nettstedet. Dette arbeidet var omfattende og kom til å inneholde flere iterasjoner for å få det til å ligne noe vi kunne være fornøyde med. Verktøyet vi benyttet for å gjøre dette var Powerpoint, da gruppens hovedansvarlig for dette prosjektet var komfortabel med dens funksjonalitet. Vedkommende mente at den kunne gi oppdragsgiver et godt visuelt inntrykk av hvordan det endelige nettstedet kunne se ut i Wordpress, da det var mulig å simulere interaksjon mellom de ulike sidene ved å lenke sidene sammen. Studentparlamentet - HiOA 34

35 Figur 3. Prototype - forside Nettstedets forside, som vi har illustrert i figuren over viser hvordan vi organiserte valgmulighetene i hovednavigasjonsmenyen. Her har vi tatt utgangspunkt i analysen av spørreundersøkelsen fra innsiktsfasen som fortalte oss at det finnes tre ulike brukergrupper med ulike informasjonsbehov. Dette valget ble tatt for å gjøre siden mer brukervennlig og logisk. Studentparlamentet - HiOA 35

36 Figur 4. Nettstedets menystruktur I bildet over kan man se menystrukturen og underkategoriene til «Om oss». Her adresserte vi hovedinnvendingen, som bortimot samtlige respondenter fra spørreundersøkelsen hadde mot dagens nettside. Nemlig at dagens nettsted ikke er brukervennlig, det vil si at det er tungvint å finne relevant informasjon effektivt. I vår prototypeløsning organiserte vi all relevant informasjon om Studentparlamentet på en oversiktlig måte, i henhold til kravene i kravspesifikasjonen. Bildet over er kun ett eksempel på måten vi ønsket å organisere innhold og arkitektur. For komplett sett, se vedlegg av prototypen. Brukertestingen av prototypen er beskrevet nederst i prosessdokumentasjonen. Presentasjon av ferdig prototype for Studentparlamentet Vi hadde opprinnelig tenkt å vise frem vår prototype for oppdragsgiver med en gang de var ferdig. Dette lot seg imidlertid ikke gjøre da vår kontaktperson, og beslutningstaker i Studentparlamentet var utilgjengelig under denne perioden. Vi fikk først vist de frem senere i prosjektperioden. Dette var for øvrig en av faktorene som bidro til at bruken av fremdriftsplanen gled ut underveis. Da vi omsider fikk vist de frem for oppdragsgiver fortalte de oss at de var fornøyde med organiseringen av innhold og arkitektur, så lenge vi gjorde Studentparlamentet - HiOA 36

37 enkelte justeringer. Vårt design og layout var de imidlertid ikke fornøyde med, da de syntes den var for rotete og fargerik. Til tross for at vi tidligere hadde spurt de om de hadde noe konkrete preferanse når det kom til design, og det faktum at oppdragsbeskrivelsen var så vag, viste det seg allikevel at de hadde konkrete tanker om hvordan nettstedet burde seg ut. Det de faktisk viste seg å ønske var et renere og enklere design med mer nøytrale farger da høgskolen muligens får universitetsstatus neste år. Vår fargebruk hadde tatt utgangspunkt i fargepaletten de hadde sendt oss i krav-designelementene. Resten av vårt møte gikk med til å ta detaljerte notater over konkrete endringer de ønsket, og hvordan de så det for seg. Designendring Selv om vi syntes det var litt dumt at de ikke gav oss grønt lys til å starte selve utviklingen tok vi det ikke så tungt ettersom vi ikke hadde begynt å implementere i WordPress enda. Dette viser hvor fordelaktig det er å lage prototyper av nettstedet før man starter med utviklingen, ettersom det er enkelt å raskt å gjøre endringer. Endringene de ønsket at vi skulle gjøre medførte ikke store mengder merarbeid da deres innvendinger omhandlet designet, og ikke informasjonsarkitekturen som ville vært en mye større jobb. På neste gruppemøte diskuterte vi tilbakemeldingene vi hadde fått fra Studentparlamentet vedrørende nytt layout, og kom frem til endringene som måtte til. Vi ble enige om å ikke lage flere prototyper, og heller starte selve implementeringen i WordPress. Utviklingsfase 2 Etter at vi i utviklingsfase 1 hadde blitt enige med oppdragsgiver, og oss selv om de nye endringene som måtte til var det på tide å starte utviklingsfase 2. Denne fasen innebar å utvikle selve nettstedet i WordPress, og brukerteste den. Utviklingsmiljøet for å gjøre dette var allerede satt opp i prosjektets oppstartsfase, hvor vi hadde nedlastet programvaren fra internett, og opprettet en MySQL-database ved hjelp av web-serverprogramvaren XAMPP. På forhånd hadde vi i tillegg også lært oss hvordan WordPress fungerer og brukes. Utvikling av nettsted i WordPress WordPress hadde som tidligere nevnt blitt valgt av oppdragsgiver som utviklingsplattform ettersom deres eksisterende nettsted brukte det, de allerede hadde betalt for det, og følgelig Studentparlamentet - HiOA 37

38 ønsket å bruke det videre. Da vi startet utviklingen av nettstedet i WordPress ved hjelp av verktøyets kontrollpanel hadde vi fra tidligere i prosjektet tilegnet oss kjennskap til dens funksjonalitet og utviklingsmuligheter. Dette sammen med det faktum at vi på forhånd også hadde utformet informasjonsarkitekturen i form av prototyper gjorde det mulig for oss å begynne rett på utviklingen av nettstedet. Hovedansvarlig for utviklingen av nettstedet var Hotan. Valg av «theme» Første steg i utviklingen var å gå til programmets kontrollpanel å laste ned en designmal som stemte overens med de nye ønskene til oppdragsgiver. Designmaler i Wordpress er kjent som «themes», og definerer hvordan sidene vil se ut på nett. De definerer også alt fra hvordan navigasjonen på sidene vil fungere, til design, farger og fonter som blir brukt. Designmalen vi opprinnelig gikk for heter «GeneratePress» og kan ses i bildet under. Figur 5. Opprinnelig designmal Den er minimalistisk med en enkel navigeringsstruktur som vi planla å skreddersy til å få et rent design og relevant funksjonalitet. Denne designmalen gikk vi imidlertid bort fra underveis da det ikke var mulig å formatere den i henhold til våre ønsker. Et av problemene, som vi også kommer tilbake til senere i rapporten, gikk ut på at det ikke gikk an å utføre nødvendige endringer av bildekarusellen som var integrert i malen. Designmalen vi til slutt gikk for kan ses i bilde under, og heter «Evolve». Denne malen tillot oss å utføre de ønskede endringene. Studentparlamentet - HiOA 38

39 Figur 6. Gjeldende designmal Organisasjonsstruktur Vi tok utgangspunkt i at nettstedet skulle ha en hierarkisk organisasjonsstruktur med komplementerende hypertekst. En slik form for organisering er kjent som en «top-down» metode, og er noe som innebærer at nettstedet skal bygges opp etter «foreldre-barn» prinsippet, der barn (undersider) ligger under sidene til foreldre. En slik oppbygning hjelper brukere til å enkelt forstå hvordan nettstedet henger sammen, og bidrar til at de kan danne seg en mental modell av dets struktur. Hypertekst kobler informasjon på nettstedet sammen ved hjelp av lenker (Rosenfeld, 2015, s. 117). Bildet under illustrerer nettstedets hierarkiske oppbygning etter «foreldre-barn» prinsippet. Der kan man se hvilke nivåer i menystrukturen som vises når brukeren skal navigere seg fra forsiden, og inn på en av hovedkategoriene. Nettstedet har totalt seks hovedkategorier å velge mellom i bredden, hvor man skal kunne navigere seg til det dypeste nivået i hierarkiet ved hjelp av tre klikk. Tanken bak dette er at dersom det kreves mer enn tre klikk i dybden kan man risikere at brukerne ikke finner ønsket informasjon effektivt, og som en konsekvens muligens gir opp og forlater siden (Rosenfeld, 2015, s. 121). Dette skal også gjøre det enklere for administrator av nettstedet å endre, og legge til fremtidig innhold uten å måtte utføre større restruktureringer av nettstedet. Slik kan man i tillegg unngå å skade det mentale bildet brukere har dannet seg av nettstedet over tid. Studentparlamentet - HiOA 39

40 Figur 7. Nettstedets organisasjonsstruktur Opprettelse av sider I bildet under kan man se måten vi opprettet sidene i WordPress på. Ettersom alt forarbeid Studentparlamentet - HiOA 40

41 hadde blitt gjort på forhånd i utviklingsfase 1, da vi utformet prototypen, så var det bare å overføre innholdet (bilder og tekst), og formatere det til ønsket resultat. Bildene ble lagt til ved hjelp av media-biblioteket som vi hadde overført bildene til. I utviklingsfase 1 hadde vi kartlagt alt av innhold som skulle med, og organiserte det i henhold til informasjonsbehovene til de ulike brukergruppene som tar i bruk nettstedet; studenter, tillitsvalgte og representanter. Der hadde vi også fjernet gjentagelser av informasjonsbruddstykker som lå spredt over flere sider på en ulogisk måte. I utformingen av nettstedets bloggside konfigurerte vi den annerledes enn i de andre sidene vi opprettet. Dette innebærer at for bloggsiden så publiseres innleggene i omvendt kronologisk rekkefølge, altså de ferskeste innleggene øverst. De andre sidene ble utformet på vanlig måte. Figur 8. Skjermbilde av "Legg til ny side" Navngivning/labels Det har vært viktig for oss å bruke klare og tydelige labels (merkelapper) på nettstedet, for å tydeliggjøre hva og hvor brukerne kan forvente å finne det de ser etter. Dette vil kunne bidra til en enklere, mer effektiv og forutsigbar søk- og navigasjonsprosess (Tidwell, 2005). I oppdragsgivers nåværende nettsted benyttes det mange tvetydige merkelapper som kan forvirre brukere. I bildet under neste avsnitt kan man se nettstedets forside hvor vi har brukt meningsfulle lenketekster som; «Om oss», «For studenter», «For tillitsvalgte», «Dokumenter» og «Blogg». Her kan man også se at vi har benyttet lett gjenkjennelige og familiære ikoner som merkelapper for; sosiale medier (Facebook, Twitter, Instagram), søk (i form av et Studentparlamentet - HiOA 41

42 forstørrelsesglass), og språk (i form av en jordklode). Det globale og lokale navigasjonssystemet Nettstedets globale navigasjonsmeny er utformet med tanke på at den skal være synlig og tilgjengelig på alle sidene til nettstedet. Logoen er likeså klikkbar, og gir bruker mulighet til å navigere seg raskt tilbake til nettsidens forside. I bildet under kan man se hvordan det globale navigasjonssystemet ser ut. Figur 9. Globale navigasjonssystemet Etter at vi hadde definert og opprettet menyen med de tilhørende undersidene brukte vi innstillingen i kontrollpanelet til å sette den som primærmeny. Dette innebar at den ble definert som nettstedets navigasjonssystem. Se bilde under. Figur 10. Innstilling for "primærmeny" I bildet under har vi illustrert hvordan navigasjonssystemet ser ut når brukeren holder musepekeren over «Om oss». Her vises underkategoriene («Studentparlamentet», «Arbeidsutvalget og sekretariatet», «Representanter» og «Kontakt oss») vertikalt. Ved å organisere navigasjonsmenyen slik ønsket vi å fokusere på at brukervennligheten skal oppleves som oversiktlig, forståelig, tilfredsstillende- og effektivt å bruke. I dette arbeidet har vi tatt utgangspunkt i ISO 9241 standarden. Forøvrig benyttet vi en sticky header for å gjøre navigasjonssystemet synlig når man scroller nedover på sidene slik at den alltid er tilgjengelig. Studentparlamentet - HiOA 42

43 Figur 11. Musepeker holdes over "Om oss" Søkefelt Søkefeltet har blitt plassert lett tilgjengelig i det globale navigasjonssystem og er synlig på alle sidene til nettstedet. Søkefeltet, med et gjenkjennelig forstørrelsesglass-ikon, er et supplement til hovednavigeringen, og er en alternativ måte for brukerne å uttrykke sine informasjonsbehov på. Brødsmulesti En brødsmulesti er et nyttig navigasjonshjelpemiddel, som viser en bruker hvor på nettstedet han/hun befinner seg i forhold til resten av nettstedet. Dette gjøres ved at den viser hvert nivå i hierarkiet, frem til brukerens posisjon (Tidwell, 2005, s. 78). I bildet under kan man se at vårt nettsted har en lineær brødsmulesti (markert i grønt) som vi installerte via en plugin. Disse inneholder klikkbare linker som skal hjelpe brukeren til å navigere mellom hierarkiets ulike sider. Figur 12. Nettstedets brødsmulesti Studentparlamentet - HiOA 43

44 Logo Logoen som vi valgte å implementere fant vi i krav-designelementene som vi fikk tilsendt av oppdragsgiver. Der hadde de en rekke varianter som vi kunne velge mellom. Logoen vi gikk for ble formatert til ønsket størrelse, og plassert øverst på nettstedet. Begrunnelsen for at vi valgte å gå for en logo som er mindre enn den oppdragsgiver benytter i dag var at vi ikke ønsket at den skulle bli for dominerende, og ta opp unødvendig plass. Dette valget ble tatt etter vår vurdering, og på grunnlag av tilbakemeldinger vi mottok fra spørreundersøkelsen om at nåværende logo er altfor stor. Figur 13. Logo Snarveier Etter ønske fra oppdragsgiver laget vi tre snarveier som vi plasserte i midten av nettstedets forside. Her plasserte vi linker til informasjon på nettstedet som brukergruppene skal få rask tilgang til. Den første snarveien var til sakspapirer, som er noe representantene i Studentparlamentet hovedsakelig oppsøker nettstedet for. Den andre snarveien er ment for studenter som ønsker å lese om Studentparlamentets politiske dokumenter, og den tredje snarveien er til en kalender som alle brukergrupper vil kunne ha nytte av. Snarveiene ble opprettet i kontrollpanelet, og linket til sider knyttet til navigasjonsmenyen. Se bilde av konfigurasjon på neste side. Studentparlamentet - HiOA 44

45 Figur 14. Konfigurasjon Konfigurering av «bildeslider» Figur 15. Nettstedets bildekarusell I arbeidet med å konfigurere «bildeslideren», som er en «bildekarusell» som viser bilder med lenker til spesifikke sider opplevde vi formateringsutfordringer når vi skulle gjøre dette i den gamle designmalen, «GeneratePress». Denne funksjonaliteten var allerede integrert i designmalen vi hadde valgt, og viste seg å ha begrensede muligheter for manuell tilpasning. Det vi ønsket for vårt design var at den skulle ha samme bredde som Studentparlamentet - HiOA 45

46 hovednavigasjonsmenyen over, uten tomrom mellom meny og «slider». Dette mente vi ville gi et mye bedre visuelt inntrykk. Bildet under viser hvordan slideren så ut i den gamle designmalen. Bildet over viser hvordan det så ut etter at vi fikk formatert den nye designmalen ( evolve: Carousel slider ). Figur 16. Det tidligere nettstedets bildekarusell Fargevalg Ettersom oppdragsgiver ønsket et rent design med få farger valgte vi å bruke få fargeinnslag i vår utforming. Bakgrunnsfargene vi benyttet var hvit og offwhite for å gi et lett og luftig preg, mens navigasjonsmenyen fikk fargen rød som er høgskolens farge. Vår strategi var å la bildekarusellens bilder stå for hoved-fargeinnslaget slik at nettstedet ikke fremstår som kjedelig. De eneste sterke fargene vi benyttet, i tillegg til rødfargen for navigasjonsmenyen, var for: - Studentparlamentets logo, som måtte være rød. - Jordklode-ikonet slik at den kunne synliggjøres ytterligere. - Lenkeknappene til snarveiene vi hadde opprettet midt på forsiden. - Facebook-ikonet til feeden nederst på forsiden. I valg av farger benyttet vi fargepaletten som oppdragsgiver sendte oss som en del av kravdesignelementene i begynnelsen av prosjektperioden. Studentparlamentet - HiOA 46

47 Figur 17. Fargepalett Ikoner for sosiale medier og RSS feed Disse ble plassert øverst i høyre hjørne av den globale navigasjonsmenyen, og ble opprettet i kontrollpanelets tilpasningsfunksjon. Se bilder under. Figur 18. Oppretting av ikoner i kontrollpanel Studentparlamentet - HiOA 47

48 Figur 19. Ikoner for sosiale medier på nettstedet Plugins Det finnes tusenvis av tilgjengelige plugins i WordPress som kan utvide funksjonalitet og mulighetene. De vi brukte i utviklingen av nettstedet kan ses under. Sikkerhet WordFence Figur 20. WordFence dashboard I henhold til oppdragsgivers opprinnelige kravspesifikasjon vedrørende sikkerhet, ble det en prioritet for oss å sørge for at nettstedet fikk nødvendig beskyttelse. I forbindelse med dette lastet vi ned en sikkerhets plugin som heter WordFence. Dette er den mest populære av sitt slag i WordPress, da den håndterer login-sikkerhet, IP blokkering, sikkerhets-skanning, Wordpress brannmur og overvåkning. WordFence skanner nettstedet daglig, og gir tilbakemeldinger på nødvendige handlinger som må utføres for å holde nettstedet sikkert. Den informerer også om nødvendige oppdateringer som må utføres for å holde benyttede plugins oppdatert. Dette forhindrer at uvedkommende får uønsket tilgang til eldre og mer sårbare versjoner. Bildet over viser dashbordet til WordFence som administrerer sikkerheten. Studentparlamentet - HiOA 48

49 Facebook feed -> Custom Facebook Feed Vi benyttet en Facebook plugin (utvidelse) for å lage en nyhetsfeed nederst på forsiden, ved siden av en blogg-feed. Denne knyttet vi opp til deres Facebookside ved hjelp av Wordpresskode som vi plasserte inn i en tekstboks. Tekstboksen ble så plassert i widgets-området til Sidebar 1. Se bildet under. Figur 21. Sidebar 1 Kontaktskjema - Contact Form 7 Vi har implementert et kontaktskjema for brukere som ønsker å komme i kontakt med Studentparlamentet. Her brukte vi samme tilnærming som for Facebook-feeden. Kontaktskjemaet ble plassert i underkategorien til «Om oss» da det virker som et logisk sted å ha den der. Se bilde under. Studentparlamentet - HiOA 49

50 Figur 22. Kontaktskjema Kalender - Event Calendar WD Vi opprettet en kalenderfunksjon for nettstedet ved hjelp av en plugin, hvor brukere kan få oversikt over kommende hendelser som administrator oppretter. Kalenderen plasserte vi i undermenyen til Om oss i hovednavigasjonsmenyen, og på midten av siden som en av tre snarveier. Bildet under illustrerer hvordan den ser ut etter at en hendelse har blitt opprettet. Figur 23. Kalender Studentparlamentet - HiOA 50

51 Tospråklighet - GTranslate Et tospråklig nettsted er noe oppdragsgiver per dags dato ikke har, og er noe de følgelig ønsket seg i den nye løsningen. Dette var en prioritet for oppdragsgiver da det blir stadig flere engelsktalende studenter ved høgskolen og blant representantene i Studentparlamentet. I dagens nettsted må oppdragsgiver manuelt skrive engelske versjoner av det de ønsker å oversette. Dette er svært tungvint og medfører at engelske versjoner svært sjelden blir laget. Det vi gjorde var å installere en «plugin»(utvidelse) som oversetter alt innhold automatisk til engelsk dersom en bruker ønsker dette. Se bilde på neste side. Figur 24. GTranslate plugin Vi valgte å benytte et lett gjenkjennelig flagg-ikoner som man kan trykke på for å få valget mellom språkene norsk og engelsk. Denne løsningen plasserte vi i det globale navigasjonssystem som er synlig på alle sidene til nettstedet. Se bilde under. Studentparlamentet - HiOA 51

52 Figur 25. Nettstedets språkvalg Justeringer og ferdigstilling av nettstedet Etter at vi hadde gjennomført fokusgruppeintervjuet, satt vi igjen med en rekke tilbakemeldinger vedrørende nettstedet som vi ønsket å gjøre noe med. For en mer inngående forståelse av våre valg, henviser vi til delen for brukertesting som er beskrevet nederst i prosessdokumentasjonen. Språkinnstilling Vi valgte å gjøre ikonet for tospråklighet mer intuitivt. Vi vårt opprinnelige designvalg med et jordklode-ikon som ble til et engelsk og norsk flagg når det ble trykket på, til et design med kun ett flagg-ikon som var synlig. Det vil si at når man ønsker engelsk tekst trykker man på det engelske flagget, og norsk flagg når man ønsker det motsatte. Facebook-feed Basert på tilbakemeldingene valgte vi å gjøre skriften i Facebook-feeden mindre og dele området nederst på forsiden i to. Den ene delen hadde Facebook feeden med tre synlige nyhetsinnslag, istedenfor fem som vi opprinnelig hadde. Den andre delen ble til en bloggfeed med tre synlige nyhetsinnslag. Til tross for at deltakerne likte at vi hadde plassert en Facebook-feed nederst på forsiden av nettstedet var det allikevel et par negative kommentar vedrørende designet. hadde alt for stor tekst, tok opp alt for stor plass, og det faktum at to av deltakerne også ønsket en bloggfeed på forsiden Sentrering av logo og overskrift I headeren var logoen og overskriften, Studentparlamentet ikke sentrert. Ved hjelp av CSS klarte vi å midtstille disse, og skape et penere visuelt design. Ferdigstilling Da alle endringer var implementert presenterte vi det endelige resultatet for oppdragsgiver Studentparlamentet - HiOA 52

53 som fortalte oss at de var fornøyde med det endelige resultatet. Ved prosjektslutt overleverte vi prosjektfilene til oppdragsgiver. System for dokumentbehandling Fase 1 - Utkast av brukergrensesnitt Første utkast: Etter første omgang med datainnsamling og når kravspesifikasjon var skrevet lagde vi et utkast på hvordan brukergrensesnittet ville se ut. Noen av knappene på grensesnittet fungerte ikke, de var kun for å symbolisere handlinger en bruker kunne gjøre. Figur 26 - Skjermbilde av dokumentvisning Studentparlamentet - HiOA 53

54 Figur 27 - Skjermbilde av forslagvisningen Det første utkastet består av 2 forskjellige skjermbilder. Et skjermbilde for visning av alle dokumentene som Studentparlamentet har lagt til i systemet, og et annet for visningen av endringsforslag knyttet til et dokumentet. Utkastet ble laget ved hjelp nettsted-styling rammeverket Bootstrap, hos Det ble holdt et møte i forbindelse med presentasjon og tilbakemelding av dette første utkastet, for å høre om de likte designmessig retningen vi gikk i. Vi fikk gode tilbakemeldinger og vi utvekslet tanker og ideer om videre utvikling. Andre utkast: Etter møte med Studentparlamentet, implementerte vi endringene på brukergrensesnittet som vi ble enige om. Studentparlamentet - HiOA 54

55 Figur 28 - Skjermbilde som viser endringene gjort på dokumentvisningen Figur 29 - Forslag visning Endringene viser at dokumentene kan nå bli delt inn i kategorier, og at forslagene er fordelt på hvilken side de tilhører. Hvert dokument har fått en nedtrekksmeny med handlinger som Studentparlamentet - HiOA 55

56 kan utføres; rediger, flytt, arkiver og slett. Fase 2 - Implementere funksjonalitet Etter at vi hadde blitt enige om hvordan brukergrensesnittet vil ta seg ut og om hvilke funksjoner en bruker kunne utføre, startet arbeidet med å lage server applikasjonen som skal servere løsningen og lagre data. AngularJS ble også integrert i utkastet av brukergrensesnittet. Kravspesifikasjonen og de nye ideene vi hadde kommet fram til på de siste møtene var grunnlaget. Etter implementasjon var det mulig å: laste opp dokumenter, redigere data knyttet til dokumentene (navn, kategori, beskrivelse), opprette nye kategorier for dokumenter, flytte dokumenter mellom kategoriene, arkivere dokumenter, legge til og slette endringsforslag for et dokument. Fase 3 - Autentisering, brukere, og sikring Vi var blitt enige med Studentparlamentet om at løsningen skulle sikres mot misbruk som spam og useriøse brukere. Vi kom fram til at vi skulle utforske mulighetene for å bruke Feide som en login løsning, slik som også HIOA bruker Feide til å autentisere studenter. Ifølge dokumentene til Studentparlamentet er det kun studenter som kan komme med endringsforslag til dokumenter, så om vi fikk til å benytte oss av Feide ville dette løse mange problemer. Vi kontaktet Feide via e-post, men fikk beskjed om at vi heller skulle kontakte Dataporten for å finne en løsning. Etter e-postkorrespondanse med Dataporten fikk vi instrukser på hvordan man kunne implementere student autentisering via I tillegg til autentisering via Dataporten, lagde vi også funksjonalitet for login utenom Dataporten som i første omgang er ment for administratorer, men administratorer kan også legge til ikke-admin kontoer senere om det er ønskelig. Etter at login var implementert gikk vi igang med å sikre api kallene på serveren som var egnet kun for administratorer eller ordinære innloggede brukere. Vi skjulte også administrator Studentparlamentet - HiOA 56

57 funksjoner for ordinære brukere i visningen. Fase 4 - Tilleggsfunksjonalitet og justeringer Etter møter med Studentparlamentet hvor vi viste fram en fungerende løsning, kom vi fram til mangler og justeringer som måtte gjøres. Administrator måtte ha mulighet for stenge for nye forslag på et dokument, funksjonalitet for å printe ut alle forslagene for et dokument, like funksjon på endringsforslag. Muligheten for å stryke endringsforslag slik at de vises med gjennomstrek, istedenfor at de slettes. Nummerering av endringsforslag; endringsforslag gis et eget nummer som er unikt innenfor dokumentet. Fase 5 - Testing og bugfiksing Vi ble enige med Studentparlamentet at vi skulle teste løsningen i en fokusgruppe test. Studentparlamentet stilte med i alt 4 personer for testingen. Før testingen installerte vi serveren slik at den var tilgjengelig for alle brukerne samtidig. Dette gjorde vi ved å bruke en av våre hjemme-maskiner, gjøre maskinen tilgjengelig for internett og benytte tjenesten en gratis DNS tjeneste for å peke til IP adressen til maskinen vår. Vi oppdaget en rekke feil i systemet som vi noterte oss. Noen av feilenene System for talerliste Utviklingsfase 1 - brukergrensesnitt Etter samtaler med ekstern veileder angående hvordan de hadde ønsket seg at nettsiden skulle se ut, bestemte vi oss for å lage et første utkast av siden. Vi viste dem en skisse over hvordan vi så for oss at løsningen kunne se ut. Og det var de svært fornøyde med siden det var veldig nærme hva de hadde sett for seg. Figur 30. Forslag - Forside Studentparlamentet - HiOA 57

58 Figur 31. Forslag - Opprette nytt møte Figur 32. Forslag - Liste over møter Figur 33. Forslag - endre møte Figur 34. Forslag - Legge til representant Studentparlamentet - HiOA 58

59 Figur 35. Forslag - Registrerte representanter Figur 36. Forslag - Endre representant Figur 37. Forslag - Taler siden Figur 38. Forslag - Taler siden Studentparlamentet - HiOA 59

60 Utviklingsfase 2 - valg av utviklingsmiljø Den andre utviklingsfasen ble brukt til å få et overblikk over hvordan systemet skal funke teknisk. Hovedfunksjonene til talerlistesystemet er å la administrerende ordstyrer styre ordet, representanter må få lov til å gi to replikker og et innlegg til taleren dersom de måtte ønske det. Dette resulterte i at prosjektet ble delt opp i komponenter (eng: Components) noe Angular2 er bygd med støtte for. Det ble bestemt at for hver spesifikk oppgave så skulle det være en samsvarende komponent, eks. komponent for å legge til et møte, en komponent for å legge til en representant osv. Hver komponent har funksjoner som kan kalles, såkalte services som injiseres i komponenten, disse funksjonene er knyttet til DOM'en og kan manipulere sistnevnte. Utviklingsfase 3 - brukere og implementasjon Vi ble enige om at nettløsningen i starten kun skulle være egnet for administrator, og at funksjoner for andre eventuelle brukere skulle bli implementert senere, dette var rett og slett fordi oppgavens omfang ble veldig stor og oppdragsgiver prioriterte dokumentbehandlingssystemet, i tillegg måtte vi ferdigstille andre deler av prosjektet i tide. For at vi skulle fortsette i samsvar med den originale tidsplanen vi hadde ført opp, så bestemte vi oss for å ferdigstille en prototype av talerlistesystemet egnet kun for administrator brukeren. Dette med samtykke fra ekstern veileder. Grunnen til dette valget er at vi i utgangspunktet kun skulle ta to prosjekter for arbeidsgiver, vi referer til dagboken, dato 18 og 21 oktober der både Einar og Jannicke informerte oss om at vi var veldig ambisiøse med valg av tre prosjekter, men at det fort kunne bli ressurskrevende med tanke på veldig kort tid. Vi referer også til mailer med ekstern veileder nedenfor. Vår interne veileder ble også informert om denne potensielle situasjonen, da fikk vi den tilbakemeldingen om at det var best å utvikle den prototypen vi endte opp med i dag. Denne prototypen vi har ferdigstilt virker, og har stort potensiale for videreutvikling. Studentparlamentet - HiOA 60

61 Figur 39. Mail fra oppdragsgiver Dokumentasjonsfase Ettersom prosjekt handlet om å utvikle tre prosjekter for oppdragsgiver, og vi hadde blitt enige oss imellom om å være hovedansvarlige for hver vår del, bestemte vi at denne fordelingen av ansvaret også skulle gjelde for dokumentasjonsarbeidet. Dette innebar at vi jobbet med hver vår del av dokumentasjonsarbeidet til ulike tider ut i fra våre prioriteringer. Vi involverte hverandre i vårt arbeid når vi hadde felles gjennomgang av vår fremdrift. Arbeidet med dokumentasjonen har foregått ved at vi har lagt alt vårt arbeid, og relevante dokumenter inn i skytjenesten til Google Drive. Der har alle i gruppen hatt tilgang, og skrevet på et fellesdokument, slik at vi har unngått kopi-konflikter. Dette har latt oss holde oss oppdaterte på hverandres arbeid. Vi har kommentert og utført endringer i fellesskap under-, og utenfor møtene våre. Google Drive har vært et meget nyttig verktøy. Selv om vi har forsøkt å skrive kontinuerlig under prosjektperioden, ble mesteparten av dokumentasjonen av naturlige årsaker skrevet mot slutten av prosjektperioden. Da vi følte oss ferdige med dokumentasjonsarbeidet ble det overført fra Google Drive til Microsoft Word for ferdigstillelse. Der formaterte vi dokumentet, leste korrektur, utførte endringer hvor det var nødvendig og fikset ferdig kildene vi hadde brukt. Oppsummert kan vi si at dokumentasjonsfasen har vært lærerik, mer krevende enn vi forestilte oss, og at vi er fornøyde med sluttresultatet. Studentparlamentet - HiOA 61

62 Kravspesifikasjonen og dens rolle Kravspesifikasjon vi utarbeidet, basert på oppdragsbeskrivelsen og resultatene fra vår datainnsamlingsprosess, er i praksis tredelt da vi utførte tre prosjekter for oppdragsgiver. Vi kommer som en følge av dette til å beskrive kravspesifikasjons rolle for hvert av prosjektene separat. Nettstedet Kravspesifikasjonen vår for nettstedet samsvarer med produktet som er beskrevet da vi har implementert og tatt hensyn til alt vi hadde fastsatt. Vi har reorganisert informasjonsarkitekturen for å gjøre navigeringsmulighetene mer brukervennlig, gjort den tospråklig, mer universelt utformet, og utviklet et mer tiltalende design. Rammekravene vi detaljerte har også blitt fulgt da nettstedet er utviklet i Wordpress, og er følgelig plattform kompatibel da den kan kjøres i alle nettlesere, og digitale enheter (datamaskin, samt nettbrett og mobil). Vi har tatt hensyn til oppdragsgivers ønske om et nettsted som er sikkert ved nedlasting av en sikkerhetsplugin som beskytter nettstedet. Vi har også fulgt kravet om manuelle funksjoner da vår «foreldre-barn» organisering av menystrukturen har gjort det enkelt og logisk for administrator å vedlikeholde og videreutvikle nettstedet ved behov. Kravspesifikasjonen hadde størst betydning for reorganiseringen av nettstedets informasjonsarkitektur. I systembeskrivelsen av kravspesifikasjonen hadde vi definert nettstedets ulike brukergrupper og hva slags type informasjon som var relevant for dem. Med dette som utgangspunkt gjorde vi relevante implementeringsvalg. Som tidligere nevnt måtte vi lage en kravspesifikasjon basert på oppdragsbeskrivelsen som bare nevnte grunnleggende ting som var viktige for oppdragsgiver, uten å gå i detalj. Detaljene fant vi frem til på egenhånd gjennom omfattende datainnsamling fra flere kilder. På denne måten ble vår kravspesifikasjon til. Underveis har det ikke blitt store endringer av hovedrammene for kravspesifikasjonen da vi tidlig stadfestet behovet for en reorganisering av informasjonsarkitekturen i kravspesifikasjonen. Den eneste store endringen som hadde betydning for vårt prosjekt forekom underveis i slutten av utviklingsfase 1, da vi presenterte våre ferdige prototype som vi ønsket å implementere i Wordpress. Oppdragsgiver, som ikke hadde gitt uttrykk for at de hadde et spesifikt design i tankene under prosjektperioden, ønsket at vi gjorde noen endringer i designet, ettersom de ikke syntes den var tilstrekkelig minimalistisk. De ønsket et renere design med få farger. Vi hadde basert vårt design på våre vurderinger, og tilbakemeldingene vi mottok fra spørreundersøkelsen. Oppdragsgivers innvending mot vårt design medførte til at vi måtte endre det vi hadde skrevet i Studentparlamentet - HiOA 62

63 kravspesifikasjonen vedrørende dette, og forandre vårt design til å passe deres nye ønsker. System for dokumentbehandling Kravspesifikasjonen for systemet for dokumentbehandling har blitt til underveis i prosjektet. Dette vil si at vi ved prosjektstart mottok en kravspesifikasjon fra oppdragsgiver som kun beskrev hva de ønsket utviklet. Se vedlegg. Etter avklaringsmøter og datainnsamling utformet vi en mer utfyllende kravspesifikasjon som vi bestemte oss å jobbe etter. Underveis i prosjektet hadde vi fremdriftsmøter med oppdragsgiver, hvor det kom frem at de ønsket flere funksjonaliteter. Dette har ført til justeringer, flere funksjonaliteter, og justeringer i den endelige endelige kravspesifikasjonen. Dette er hoved funksjonalitetene som har blitt lagt til etter kravspesifikasjonen var ferdigstilt. Funksjonalitet for at kun studenter ved HIOA skal kunne opprette endringsforslag, dette krever at vi benytter FEIDE som autentiseringsløsning for studenter. At en ordstyrer kan opprette voteringsorden for endringsforslagene, dette innebar en ny rolle i systemet Ordstyrer med utvidede tilganger, men som ikke var en full administrator rolle. Vi implementerte også Lik funksjon på endringsforslagene, men denne ble senere fjernet etter en fokusgruppe testen da Studentparlamentet ble enige om at funksjonen var upassende og udemokratisk for systemet. Man skulle også kunne endre sine egne forslag i tilfelle skrivefeil. System for talerliste Her spilte kravspesifikasjonen også rollen som en murstein for hvordan vi måtte legge til rette for implementering og utvikling. Men etter proaktive møter med ekstern veileder ble det presentert frem nye ideer fra begge sidene noe som gjorde at vi kunne gå inn med nye funksjoner. Brukertesting Brukertesting har blitt gjennomført fortløpende gjennom prosjektperioden for å kunne evaluere anvendbarhet, effektivitet og brukeropplevelse. Målet med brukertestingen var å teste om løsningene var enkle å bruke, om det gikk raskt å bruke løsningene, og hvordan brukskvaliteten opplevdes. Det har blitt gjennomført flere iterasjoner med brukertesting av våre målgrupper både i planleggingsfasen og i implementeringsprosessen, ved hjelp av papirprototyper, klikkbare prototyper, og nettstedet vi utviklet i Wordpress. I dette arbeidet har vi vektlagt bruken av formativ evaluering, som ifølge (Sandnes, 2011, s. 306) er testing gjennom prosjektet. Studentparlamentet - HiOA 63

64 Testing på ulike stadier har gjort det enklere for oss å avdekke mangler, og utføre endringer som igjen har kunnet bli testet ved et senere stadiet. Brukertest av low-fidelity prototype Vi viste vår low-fidelity prototype av nettstedets forside og menystruktur til fire studenter, hvor vi forklarte hva hensikten med prototypen var og spurte de hva deres inntrykk var. Ettersom papirprototypene var en rask og enkel fremstilling av designet, fungerte testleder som datamaskin som forklarte hva som ville skje om en «knapp» for eksempel ble trykket på. Vi mottok positive tilbakemeldinger på hvordan vi hadde tenkt i forhold til menystruktur. Tilbakemeldingene vi mottok fra denne testingen ga oss et bedre grunnlag og bekreftelser for å lage en mer avansert high-fidelity prototype. Walk-throughs I forbindelse med utviklingen av papirprototyper til nettstedets menystruktur, og oppbyggingen av arbeidsverktøyene vi utviklet, benyttet vi en metode for testing som heter walk throughs. Vi brukte denne metoden til å raskt gå gjennom hvilke oppgaver som en bruker skal kunne gjøre, og til å avdekke eventuelle feil før vi igangsatte videre utvikling. Denne metoden inkluderte ikke sluttbrukere, hadde en uformell tone og struktur, og ble blant annet brukt som et supplement til brukertestingen av vår lo-fidelity prototype (Rubin, 2008). Brukertest av high-fidelity prototype For å få tilbakemeldinger på våre high-fidelity prototyper, lot vi tre studenter teste prototypene ved hjelp av en tenk-høyt-metode («think aloud method») (Nielsen, 2012). En av gruppemedlemmene hadde rollen som testleder, og forklarte deltakerne hva vi har laget, gav de pre-definerte oppgaver, det vil si lukkede oppgaver, og lot de prøve seg frem i nettstedets ulike sider ved hjelp av Powerpoints klikkbare lysbildefremvisning. Under testingen ba testleder deltakerne tenke høyt og kommentere hva de gjorde, mens to observatører satt bak og observerte uten innblanding. Etter at oppgavene ble utført hadde vi en kort refleksjonsdel. Alle tre klarte å gjennomføre oppgavene vi hadde laget uten større problemer, og uttrykte at de syntes prototypen virket meget lovende. En av deltakerne mente imidlertid at nettstedet muligens kunne bli litt tung å laste i et ekte nettsted. En fordel ved å bruke tenk-høytmetoden var at vi i tillegg til å se hva deltakerne gjorde, fikk innsikt i hva de tenkte. Metoden var nyttig for å forstå brukernes forventninger og identifisere aspekter av nettstedet som potensielt kunne være forvirrende. Studentparlamentet - HiOA 64

65 Fokusgruppeintervju Etter at vi hadde utviklet og implementert nettstedet i Wordpress, og systemet for dokumentbehandling måtte vi brukerteste det. Vi hadde opprinnelig tenkt å brukerteste med tenk-høyt-metoden («think aloud method») ettersom vi hadde gode erfaringer fra tidligere i prosjektet. Dette gikk vi imidlertid vekk fra ettersom brukertesting med en person om gangen er svært tidskrevende. Vi fant det mer hensiktsmessig å holde en fokusgruppe slik at vi kunne få mer informasjon fra flere kilder på kortere tid. Et fokusgruppeintervju er et strukturert intervju med en uformell og fleksibel form, hvor en eller to personer leder et intervju med seks til ti deltakere (Konsmo). Dette er en kvalitativ metode som kan gi dyptgående informasjon om et tema. Metode benyttes for å undersøke personers erfaringer, følelser, oppfatninger, meninger, ønsker, bekymringer og holdninger (Bjørklund). Fokusgruppen bestod av fire brukere fra vår målgruppe. Den ble gjennomført i et stort møterom som vi hadde bestilt på forhånd, og varte rett i underkant av to timer. Vi hadde opprinnelig planlagt å ha seks deltakere, men to av de påmeldte meldte forfall i siste liten. Møtedeltakerne ble ønsket velkommen, og tilbudt muffins og juice ved ankomst for å forsøke å skape en god atmosfære. De ble informert om testingens hensikt, og at vi planla å ta i bruk lydopptak som ville bli slettet med en gang vi hadde transkribert det. Dette samtykket de til, og undertegnet samtykkeskjemaene som vi hadde laget og presentert for de. Ettersom vi skulle teste to ting (nettstedet og dokumentbehandlingssystemet) hadde vi på forhånd bestemt at fokusgruppen måtte ha to deler. Hotan påtok seg oppgaven med å være moderator for testingen av nettstedet, mens Arlen tok ansvar for dokumentbehandlingssystemet. Mohamed var tilstede i rommet, observerte, tok notater og hadde ansvaret for båndopptakeren. Selve intervjuet begynte med at ordstyrer forklarte hva vi hadde utviklet. Deretter fikk deltakerne oppgaven med å utforske det, mens de snakket løst og fast seg imellom. Dette ble gjort for å tak i spontane tanker og meninger. Deretter ledet vi diskusjonen inn på spesifikke temaer som vi ønsket å finne ut av. Her presenterte vi de for spesifikke navigasjonsoppgaver, og stilte spørsmål som vi hadde forberedt på forhånd. Oppgavene ble gjennomført av deltakerne mens de utvekslet erfaringer og kommenterte hverandres synspunkter. Moderator holdt seg passiv mens diskusjonene pågikk, men oppfordret passive deltakere til å ytre seg, og ledet de inn på nye temaer som vi ønsket at de skulle utforske. Fokusgruppen viste seg å være svært velegnet til å få konkrete tilbakemeldinger på hva brukerne opplever eller savner, samt ideer til hva som burde gjøre annerledes. Vi fikk Studentparlamentet - HiOA 65

66 inntrykk av at vi fikk mer informasjon fra deltakernes samtaler, enn om vi hadde intervjuet ett og ett gruppemedlem. Resultater fra fokusgruppeintervjuene: For nettsiden: Tilbakemeldingene vi mottok vedrørende nettstedet var hovedsakelig positive. Deltakerne opplevde informasjonsarkitekturen som svært brukervennlig, og designet som tiltalende. Under er noen kommentarer deltakerne kom med: - Nettstedet ser tidsriktig ut nå. - Det er mye enklere å finne frem til informasjonen på nettsiden nå. Til tross for at deltakerne uttrykte at de likte nettstedet vi hadde utviklet, fikk vi også noen kommentarer som vi måtte adressere i ferdigstillingen av nettstedet. I teksten under har vi beskrevet hva disse kommentarene gikk ut på. Språkinnstilling En av deltakerne ikke forstod ikonet for tospråklighet. Vedkommende mente at løsningen vår med et jordklode-ikon som man måtte trykke på for å se ikoner av et engelsk og norsk flagg ikke var intuitiv nok. Deltakerne mente at det ville vært bedre om vi benyttet et engelsk flaggikon i menyen når man ønsket å se innholdet på engelsk, og et norsk når man ønsket å bytte tilbake. Facebook-feed Til tross for at deltakerne likte at vi hadde plassert en Facebook-feed nederst på forsiden av nettstedet var det allikevel et par negative kommentar vedrørende designet. Det ble nevnt at feeden hadde alt for stor tekst, tok opp for mye plass. Det ble foreslått at vi heller burde delt området nederst på forsiden i to deler, hvor vi også implementerte en blogg-feed. Tilbakemeldingene og forslagene til endringer tok vi til oss, og endret designet da vi skulle justere og ferdigstille nettstedet. For systemet for dokumentbehandling: Systemet for dokumentbehandling fikk gode tilbakemeldinger av deltakerne i fokusgruppen. Deltakerne mente at systemet trolig ville bli svært verdifullt for Studentparlamentet og dets studentrepresentanter ettersom de har behov for en mer digital løsning. Studentparlamentet - HiOA 66

67 Hovedtilbakemeldingene gikk ut på at systemet var svært intuitivt og deltakerne klare å utføre oppgavene vi hadde forberedt. Til tross god mottakelse avdekket intervjuet noen bugs i systemet som vi noterte ned, og adresserte i ferdigstillelsen av prosjektet. Vi oppdaget feil da vi brukertestet og diskuterte Lik funksjonen. Feilen vi oppdaget var at noen brukere ikke kunne logge inn. Ved å se feilloggene så viste det seg at brukere med ÆØÅ i navnene sine hadde problemer, dette fordi vi sendte navnet i HTTP header. Systemet krasjet fordi det kun er gyldig med ASCII tegnsettet i HTTP headere. Deltakerne diskuterte også lik funksjonen og kom fram til at det var en forstyrrelse og udemokratisk i den forstand at stemming på endringsforslagene kun skal gjøres på møtene til Studentparlamentet hvor alle er til stede. Oppsummering og evaluering Prosjektperioden har vært utfordrende og lærerik. Vi har lært mye om hva et prosjekt av dette omfanget innebærer med tanke på planlegging, tid, gjennomføring og forventninger. Erfaringene vi har tilegnet oss fra dette prosjektet har vært verdifulle, og er noe vi tar med oss videre når vi skal ut i arbeidslivet. Prosjektsamarbeidet har fungert godt, og gruppemedlemmene har utvist initiativ, ansvarsfølelse og en seriøs tilnærming til prosjektet. Årsaken til at samarbeidet har fungert såpass bra mener vi skyldes bruken av gode kommunikasjonsverktøy, regelmessige møteaktivitet, og eierskapsfølelse til det vi utviklet. Oppdragsgiver har uttrykt at de er fornøyde med prosjektet vi har gjennomført, og at de ønsker å benytte våre løsninger. Vi har også blitt informert om at andre studentparlamenter rundt om i Norge har fått vite om vårt system for dokumentbehandling, og at de muligens vil ta kontakt vedrørende utvikling av tilsvarende løsninger for dem. For veien videre vil oppdragsgiver ta over prosjektene vi har utviklet. Arlen fra prosjektgruppen har stilt seg til disposisjon for oppdragsgiver dersom de trenger ytterligere hjelp. Studentparlamentet - HiOA 67

68 Studentparlamentet - HiOA 68

69 Produktdokumentasjon Hovedprosjekt - Gruppe 11 Høgskolen i Oslo og Akershus Studentparlamentet - HiOA 69

70 Innholdsfortegnelse for produktdokumentasjon Forord Nettsted Hensikt Valg av teknologi Teknologiske utfordringer og problemstillinger..72 Design og utforming Forsiden..75 Fargevalg 75 Den globale navigasjonsmenyen 76 Logo.76 Menystruktur..76 System for dokumentbehandling..82 Prosjektstruktur...82 Systembeskrivelse Brukergrensesnitt Database Autentisering Autorisering Talerlistesystem...98 Prosjektstruktur...98 Systembeskrivelse Brukerveiledning 109 Nettsted..109 System for dokumentbehandling System for talerliste. 142 Studentparlamentet - HiOA 70

71 Forord Produktdokumentasjonen tar for seg de viktigste elementene i de tre løsningene (nettsted, system for dokumentbehandling, system for talerliste) vi har utviklet gjennom prosjektperioden, og skal formidle en helhetlig forståelse av vårt arbeid. I dette dokumentet har vi forklart funksjonalitet og hensiktene til de endelige produktene ved hjelp av tekstlige beskrivelser og beskrivende skjermbilder. Dette dokumentet vil ta for seg de tre løsningene separat. Det forutsettes at leser har grunnleggende kjennskap til objektorientert programmering for å forstå systemet for dokumentbehandling, og systemet for talerliste vi har beskrevet. Med dette menes kompetanse innen C#,.NETCore, MCV og JavaScript. For nettstedet kreves det ingen spesifikk kompetanse utover grunnleggende kjennskap til funksjonaliteten til WordPress sin utviklingsplattform. For hvert av de tre produktene vi har utviklet, har vi også utformet brukerveiledninger som skal hjelpe bruker til å administrere, vedlikeholde og videreutvikle disse produktene. Nettsted Hensikt Nettstedet vi har utviklet for oppdragsgiver har til hensikt å erstatte deres eksisterende nettsted, som de mener er overmoden for en overhaling. Som HiOAs øverste studentorgan er nettstedet deres ansikt utad som formidler studierelatert informasjon som skal ivareta studentenes faglige, økonomiske og sosiale interesser. Målet vårt med utviklingen har vært å re-organisere informasjonsarkitekturen, og dets design for å gjøre den mer estetisk tiltalende, brukervennlig og enkel å administrere. Nettstedets brukergrupper ( stakeholders ) som vi definerte i kravspesifikasjonen på bakgrunn av vår datainnsamling består av studenter, tillitsvalgte, representanter og arbeidsutvalget. De tre første skal kunne finne relevant informasjon mer effektivt ved hjelp av en mer intuitiv menystruktur, mens arbeidsutvalget skal kunne få en enklere jobb med å administrere nettstedet. Dette vil kunne føre til at interessentene av nettstedet vil kunne oppleve større glede og utbytte av informasjonen som formidles. Studentparlamentet - HiOA 71

72 Valg av teknologi Wordpress Oppdragsgiver hadde bestemt at vi måtte benytte Wordpress som utviklingsplattform. Wordpress er verdens mest populære publiseringsverktøy for å lage dynamiske nettsider. Det tekniske aspektet ved dette verktøyet er at det er skrevet i PHP og benytter en MySQLdatabase. Dette betyr at PHP-kodene brukes til å hente inn data fra databasen, og dermed endres sidene etter behov. Det er altså et allsidig verktøy for webutvikling som ikke krever noe programmeringskunnskap, med mindre man ønsker å skreddersy etter egne ønsker. Wordpress tilbyr både muligheten for manuell HTML-koding, og et mer brukervennlig redigeringsverktøy. Wordpress finnes i utgavene Wordpress.com som kjøres direkte i nettleseren og som ikke trenger ingen installasjon, og Wordpress.org, som kan installeres på webhotell, egen PC, eller hvilken som helst lagringsenhet. Nettstedet til Studentparlamentet har blitt utviklet gjennom kontrollpanelet til Wordpress.org, da den tilbyr flere muligheter for skreddersydde løsninger. XAMPP I forbindelse med utviklingen av nettsiden, måtte Wordpress kjøres på en server (Apache i vårt tilfelle) som kan eksekvere PHP, i tillegg måtte det være en SQL server tilgjengelig for WordPress. XAMPP programvaren tilbyr dette, som kjøres som en lokal webserver. Teknologiske utfordringer og problemstillinger I utviklingen av nettstedet har vi benyttet designmalen Evolve. Dette temaet er gratis å laste ned og bruke, men har enkelte begrensninger når det kommer til funksjonalitet og formatering. Dette vil si at enkelte utviklings- og formateringsmuligheter ikke er tilgjengelig da komplett tilgang kun gis til de som har kjøpt betalversjonen av Evolve temaet. Dette har resultert i enkelte tekniske utfordringer som vi har løst etter beste evne. Disse utfordringene er beskrevet nedenfor. Sentrering av logo og tekst i header Figur 40. Logo og tekst Studentparlamentet - HiOA 72

73 I den statiske globale navigasjonsmenyen opplevde vi utfordringer med å sentrere logoen med teksten; Studentparlamentet. Se bildet over. Løsningen fant vi imidlertid ved å tilpasse css manuelt. Se utdrag av vår løsning i bildet under. Figur 41. Tilpasning av css Figur 42. Sentrering av logo Studentparlamentet - HiOA 73

74 Fargen på sticky header logo Figur 43. Fargevalg - header Sticky header er den globale navigasjonsmenyen som følger siden når man scroller nedover på sidene. Vi ønsket å forandre fargen på logoen da denne hadde svært lite kontrast i forhold til rødfargen som brukes i headeren. Vi har forsøkt alle tenkelige løsninger for å gjøre logoen mer hvit. Vi har konkludert med at dette trolig skyldes begrensningene satt av designmalens utgiver, og at det vil være i oppdragsgivers interesse å betale for fullversjonen for å løse denne og eventuelt fremtidige utfordringer. Design og utforming Ettersom målet med utviklingen var å overhale det gamle nettstedet til oppdragsgiver for å gjøre det mer brukervennlig, har vi reorganisert informasjonsarkitekturen, design og plasseringen av innholdet basert på informasjonsbehovene til brukergruppene som vi definerte i kravspesifikasjonen. Nettstedet har gjennomgått flere designrevisjoner, og runder med lo- og high-fidelity-prototyping før vi kom frem til det endelige grensesnittet som vi har utviklet i kontrollpanelet til Wordpress. Nedenfor vil vi vise det endelige nettstedets design og utforming ved hjelp av en rekke skjermbilder og beskrivende overskrifter. Studentparlamentet - HiOA 74

75 Forsiden Figur 44. Nettstedets forside I bildet over har vi markert sentrale elementer i nettstedets forside som vi kommer til å forklare under. I tillegg kommer vi til å beskrive overordnede strukturer og andre relevante designvalg. Fargevalg Riktig bruk av farger er en viktig del av design. Som man kan se på bildet over har vi forsøkt å skape et rent og harmonisk design ved hjelp av nærliggende farger på fargespekteret som er behagelig for øyet å se på. For å lede fokuset til spesifikke steder i designet har vi på en sparsommelig måte benyttet farger som er direkte kontraster. Vi har benyttet hvit og lysegrå som bakgrunnsfarger, sort til skrift, og rødt til navigasjonsmenyen, samt lenketekster. Fargen rød matcher forøvrig Studentparlamentets logo, og er høgskolens offisielle farge. Fargen blå har blitt brukt for det gjenkjennelige Facebook-ikonet. Studentparlamentet - HiOA 75

76 Den globale navigasjonsmenyen Figur 45. Nettstedets globale navigasjonsmeny Den globale navigasjonsmenyen er synlig på alle sidene i nettstedet, er utformet i nettstedets header, og består av: Logo Logoen er utformet som en lenke-knapp som tar brukeren tilbake til nettstedets forside. Vi valgte denne logoen blant alternativene vi fikk tilsendt av oppdragsgiver i kravdesignelementene. Vi har formatert størrelsen og gitt den funksjonalitet. Menystruktur Figur 46. Nettstedets menystruktur Nettstedet har seks hovedkategorier å velge mellom, med tilhørende undermenyer (dersom man holder musepeker over kategorinavnet) som illustrert i bildet over. Kategoriene med tilhørende sideinnhold er utviklet med tanke på informasjonsbehovene til nettstedets brukergrupper. Innholdet i kategoriene Om oss og For studenter er tiltenkt vanlige studenter, mens For tillitsvalgte og Dokumenter er tiltenkt tillitsvalgte, samt studentrepresentantene. Under kategorien Blogg finnes innhold som er relevant for alle Studentparlamentet - HiOA 76

77 brukere. Oppdelingen og organiseringen av informasjon i kategorier skal bidra til økt følelse av brukervennlighet. I bildet under kan man se hvordan menyene og undermenyene er utviklet etter foreldre-barn prinsippet, i kontrollpanelet til WordPress. Figur 47. Organisering av informasjon i kategorier Denne måten å strukturere menyen på gjør det svært enkelt for administrator å få oversikt og utføre ønskelige endringer på struktur og innhold. I bildet over kan man også se at vi har tatt i bruk to plugins som vi er enkle å konfigurere, og en Sticky Header Navigation som gjør at headeren og dens informasjon er synlig uansett hvor man er på de ulike sidene. Se bilder under av kalender- og kontaktskjema-plugins. Studentparlamentet - HiOA 77

78 Figur 48. Kalender- og kontaktskjema I kalenderen kan man enkelt legge til kommende hendelser. Figur 49. Kontaktskjema Studentparlamentet - HiOA 78

79 Kontaktskjemaet er utformet med tanke på at det skal være enkelt å ta kontakt med Studentparlamentet. Lenker til dette skjemaet ligger på en rekke sider på nettstedet. Ikoner for sosiale medier Lenke-ikonene for sosiale medier fører brukeren til Studentparlamentets sider på Facebook, Twitter og Instagram. Her finnes også et ikon for RSS feeden. Ikon for søkefelt > Ved å trykke man på søkefelt-ikonet kan brukeren skrive inn og søke etter ønsket informasjon på nettstedet. Ikon for språkinnstillinger Ved hjelp av en plugin har vi sørget for at nettstedet har blitt tospråklig. Språk kan byttes ved å trykke på flagg-ikonene. Her kan brukeren bytte frem og tilbake mellom språkene dersom ønskelig. Brødsmulesti Figur 50. Nettstedets brødsmulesti Studentparlamentet - HiOA 79

80 Brødsmulestien er en del av menystrukturen, og gir god orienteringsstøtte. I bildet over kan man se hvor man er i strukturen, hvordan den er bygd opp, og hvordan man har kommet til siden ved hjelp av brødsmulestien. I tillegg til de beskrevne elementene i headeren (den globale navigasjonsmenyen) så består nettstedets forside også av en bildekarusell, snarveier og en Facebook feed, som vi skal beskrive under. Bildekarusell Figur 51. Bildekarusell Bildekarusellen, eller slider som det heter i WordPress, består av tre bilder som roterer automatisk. Den kan også styres manuelt ved hjelp av pilene nederst til venstre. Bildene og teksten, samt lenkene som tar brukeren til andre deler av nettstedet, kan byttes og oppdateres enkelt i kontrollpanelet av administrator. Snarveier Figur 52. Nettstedets snarveier Snarveier har blitt opprettet på nettstedets forside for informasjon som brukerne skal kunne finne frem til på kortest mulig tid. Trykker brukeren på en av disse lenkede merkelappene Sakspapirer, Vår politikk eller Kalender, føres vedkommende til lokasjonen informasjonen Studentparlamentet - HiOA 80

81 befinner seg på nettstedet. Facebook- og blogg feed Figur 53. Nettstedets Facebook- og blogg feed Ettersom Facebook er det sosiale mediet som oppdragsgivers brukere benytter flittigst, har vi lagt til en facebook feed nederst til høyre på forsiden av nettstedet. Til venstre for denne har vi plassert nettstedets bloggside som en blogg feed, ettersom denne også er populær blant brukerne. For å tydeliggjøre Facebook feeden ytterligere har vi benyttet det gjenkjennelige Facebook-ikonet markert i blått. Bloggene publiserer tre nyhetsinnlegg om gangen, hvor det fjerde overskriver det første. På bildet har blogg feeden kun ett nyhetsinnlegg per dags dato. Studentparlamentet - HiOA 81

82 System for dokumentbehandling Prosjektstruktur Prosjektet består av klient programmet basert i AngularJS, og server programmet basert i.net Core. Klient applikasjonen befinner seg i mappen wwwroot hvor.net Core serverer klient applikasjonens statiske filer. Klient applikasjonen er en SPA, Single Page Application. Det vil si at når klienten henter index.html, som den alltid gjør, lastes alle de nødvendige filene for alle å vise alle skjermbilder for applikasjonen. wwwroot mappestrukturen er delt inn: res og views. Res inneholder de nødvendige javascript bibliotek filene for klient applikasjonen: - JQuery - AngularJS - jsondiffpatch.js Gjør det mulig å oppdatere JSON objekter fra serveren uten å måtte overskrive hele objektet. Views mappen inneholder de forskjellige skjermbildene for applikasjonen, den er delt inn slik at hvert skjermbilde får en html fil og en tilhørende javascript fil. Man konfigurerer så AngularJS ruteren til å bruke disse filene når URL feltet i nettleseren forandres. AngularJS javascript skjermbilde-ruter i filen: wwwroot/views/router.js Alle filene i Res og Views må refereres til i index.html om de skal lastes inn i klient applikasjonen. Server programmet laget i.net Core rammeverket ligger hovedsakelig i Controllers mappen. Startup.cs filen (som ligger utenom Controllers mappen), har ansvaret for å Studentparlamentet - HiOA 82

83 konfigurere serveren ved oppstart og benytter Middleware Pattern for konfigureringen. Vi benytter følgende middleware: StaticFiles - Middleware laget av Microsoft for servering av statiske filer i wwwroot mappen. TokenAuthentication - Custom middleware vi har laget for å autentisere brukere. Authorization - Middleware laget av Microsoft for autorisering. MCV - Middleware laget av Microsoft slik at man kan benytte MCV pattern i applikasjonen. ForwardedHeaders - Hvis applikasjonen serveres bak en annen server (såkalt reverseproxy server), så finn brukerens faktiske IP adresse i headeren X-Forwarded-For. I tillegg benyttes Dependency Injection gjennom hele server applikasjonen.vi legger til klassene som brukes via Dependency Injection til i Startup.cs sin ConfigureServices funksjon: AppSingleton - vi legger til en verktøy klasse kalt AppSingleton som en Singleton. Dette vil si at det opprettes kun 1 instans av klassen for hele server applikasjonen. Vi gjør dette fordi det ligger funksjonalitet i klassen som må være persistent mellom hver HTTP forespørsel. Databasen - vi legger DbContext til som injectable. System variabler: filen appsettings.json inneholder blant annet API nøkler for tredje parts tjenester serveren benytter. Systembeskrivelse Studentparlamentet laster opp dokumenter og studenter kan komme med endringsforslag på dokumentene. Endringsforslagene gjennomgåes og stemmes over ved møtene Studentparlamentet har. Endringsforslag kan være 1 av 3 typer: Tillegg, Endring, Strykning. Forfatteren av et endringsforslag oppgir sidenummer, linjenummer og endrings tekst hvis forslaget er av typene tillegg og endring. Studentparlamentet kan opprettet kategorier for dokumentene sine slik at dokumentene ligger organisert. Noen eksempler på kategorier er Saksdokumenter, Politiske dokumenter, Parlamentsmøte. Ved møtene til Studentparlamentet så skal forslagene stemmes over, ordstyreren på møte kan da trekke et endringsforslag om det det ikke gikk gjennom. Ordstyreren kan opprette en voteringsorden før møtet og printe ut forslagene i voteringsorden rekkefølgen. Studentparlamentet - HiOA 83

84 Figur 54. Brukerhandlingene i systemet Brukergrensesnitt Forsiden: Alle kategoriene og tilhørende dokumenter er i grønt. Tittelen på et dokument linker til siden med endringsforslag. Studentparlamentet - HiOA 84

85 Siden med endringsforslag: Endringsforslagene er organisert på sider og linjenummer. Fanene benytter sider, i tillegg er det fane for Alle forslagene og en fane med Mine forslag (om man er innlogget). Skjema for opprettelse av endringsforslag. Om forfatteren av et endringsforslag ikke oppgir sidenummer og linjenummer blir forslaget generelt for dokumentet. Det eneste feltet som er påkrevd er Type. Studentparlamentet - HiOA 85

86 Figur 55. Opprettelse av endringsforslag Detaljert visning for et endringsforslag. Man kan bla gjennom endringsforslagene ved hjelp av de 2 knappene øverst Forrige og Neste Figur 56. Endringsforslag Studentparlamentet - HiOA 86

87 For administratorer vises det ved siden av navnet en link til administrative innstillinger, illustert i bildet under: Administratorinnstillinger - Studenter - her kan man legge til studenter som skal få flere privilegier. Administratorinnstillinger - Lokale brukerkontoer - Her man legge til, slette og oppdatere lokale brukerkontoer. Studentparlamentet - HiOA 87

88 API kall Klient applikasjonen henter data fra serveren via AJAX kall til API. API oversikten nedenfor er beskrevet med: <relativ URL> - <beskrivelse> - <krever innlogget rolle> Hoved API for dokumenter. I filen Controllers/DokumenterController /API/Dokumenter/Hent - Henter all dokumenter gruppert på kategori /API/Dokumenter/HentForslag - Henter alle dokumenter og forslag i en kategori /API/Dokumenter/LagreKategorier - Lagrer nye endrede kategorier (Admin) /API/Dokumenter/EndreDokument - Endre navn, beskrivelse og kategori for et dokument (Admin) /API/Dokumenter/FlyttDokument - Flytt et dokument til en annen kategori (Admin) /API/Dokumenter/ArkiverDokument - Merk dokument som arkivert (Admin) /API/Dokumenter/SlettDokument - Merk et dokument som slettet (Admin) /API/Dokumenter/ToggleStengt - Steng eller åpne et dokument for nye endringsforslag Studentparlamentet - HiOA 88

89 (Ordstyrer) /API/Dokumenter/LastOpp - Last opp et nye dokumenter (Admin) Hoved API for endringsforlag. I filen Controllers/EndringsforslagController /API/Endringsforslag/Hent - Hent endringsforslag gruppert på side og linjenummer /API/Endringsforslag/HentForslag - Hent endringsforlsag uten gruppering /API/Endringsforslag/HentDokument - Hent et dokument med en id /API/Endringsforslag/Opprett - Opprett et endringsforlsag (Innlogget bruker) /API/Endringsforslag/Endre - Endre sitt eget endringsforslag (Innlogget bruker) /API/Endringsforslag/ToggleTrukket - Merk et endringsforslag som trukket (Ordstyrer) /API/Endringsforslag/ToggleSlettet - Merk er endringsforslag som slettet (Admin) /API/Endringsforslag/LagreVoteringsOrden - Ordstyrer kan lagre voteringsorden for alle endringsforslagene i et dokument (Ordstyrer) /API/Endringsforslag/FjernSortering - Ordstyrer kan fjerne voteringsorden sortering (Ordstyrer) API for autentisering. I Filen Controllers/AuthController /API/Auth/NonDataportenLogin - Gjør et login forsøk med en Lokal Bruker /API/Auth/isBlocked - Sjekk om man har gjort for mange feil login forsøk /API/Auth/GetDataportenDetails - Hent info nødvendig for å utføre innlogging via Dataporten /API/Auth/DataportenRedirect - Etter fullført innlogging hos Dataporten, så redirectes brukeren til dette API kallet. /API/Auth/GetUserDetails - Hent detaljer for innlogget bruker /API/Auth/Logout - Logg ut lokal bruker API for administrator instillinger i Controllers/SettingsController Studentparlamentet - HiOA 89

90 /API/Settings/HentAdminstudenter - Henter admin studenter (Admin) /API/Settings/OppdaterAdminstudenter - Oppdaterer administrator studenter. Man kan legge til, oppdatere og slette. (Admin) /API/Settings/HentLokalebrukere - Henter de lokale brukerkontoene (Admin) /API/Settings/OppdaterLokaleBrukere - Oppdaterer de lokale brukerkontoene. Man kan legge til, oppdatere og slette. (Admin) /API/Settings/HentLogg - Henter alle rader i systemloggen (Admin) For API kallene som er beskyttet så må det oppgis en gyldig Token i HTTP headeren sammen med API kallet. Token valideres automatisk hver gang man gjør et API kall gjennom klassen Controllers/TokenAuthentication. Dette blir beskrevet i nærmere detalj senere. Database Tabeller: Dokumentkategorier - Dokumentene Studentparlamentet laster opp er kategorisert. Dokumenter - Alle dokumentene som er lastet opp. Endringsforslag - Alle endringsforslagene for et dokument. LokaleBrukere - Lokale brukerkontoer. Både ordinære, ordstyrer og administrator kontoer. Sesjons - Inneholder login sesjon for lokale brukere. Studenter - Tabellen inneholder studentnummere med spesielle tilganger, som for eksempel administrator eller ordstyrer. Logg - Inneholder loggen av exceptions og feilmeldinger. Noen API funksjoner logges også. Studentparlamentet - HiOA 90

91 Entity Framework Core støtter mange database tilbydere (Mysql, Microsoft SQL Server, SQLite mm.). Applikasjonen benytter seg av PostgreSQL. Autentisering Det er 2 ulike måter å logge seg inn på systemet, via lokal bruker eller via Dataporten Dataporten Det er i prinsippet kun studenter ved HIOA som kan komme med endringsforslag. Dataporten ( tilbyr tjenester for å finne ut om en bruker er student ved HIOA. Om en bruker velger å logge inn igjennom Dataporten, så sendes brukeren videre til Dataporten sine sider hvor brukeren må oppgi studentnummer og passord for FEIDE brukeren sin. Om innloggingen hos Dataporten gikk bra sendes brukeren tilbake til applikasjonen som validerer innloggingen som skjedde hos Dataporten. Studentparlamentet - HiOA 91

92 Variabler: state: Klienten/brukeren oppretter en hemmelig variabel som den bruker som et motmiddel mot Cross Site Request Forgery (CSRF). Klienten validerer denne variabelen når den mottar data fra Dataporten og applikasjonsserveren. code: Når brukeren har logget inn hos Dataporten får brukeren tilbake en engangskode, som applikasjonsserveren bruker til å hente en mer langvarig Token. Token: En lang streng som tilhører en bruker. Ved å oppgi Token til Dataporten så vil man få svar tilbake som tilsvarer bruker informasjon som tilhører eieren av Token. client_id: Offentlig nøkkel som man får fra Dataporten når man registrerer applikasjonen sin. Brukes i forbindelsene med Dataporten for å identifisere hvilken applikasjon som henvender seg. Studentparlamentet - HiOA 92

93 client_secret: Privat nøkkel som man får fra Dataporten når man registrerer applikasjonen sin. Kun applikasjonsserveren bruker denne variabelen i forbindelsene med Dataporten. Bruker data: Inneholder Fullt navn, bruker id, og link til profilbilde. Gruppe data: inneholder en liste med alle grupper brukeren er medlem av. Man må søke gjennom listen etter HIOA student gruppen for å avgjøre om brukeren er student. Ettersom kontakten med Dataporten kan ta lengre tid (rundt 200 millisekunder), så kan man ikke kontakte Dataporten for hvert API kall en bruker gjør. Brukerdata fra Dataporten caches da i en ConcurrentDictionary (i klassen AppSingleton) med Token som nøkkel i 24 timer. Hver gang en bruker gjør et API kall til applikasjonsserveren sender den også med Token i HTTP header slik at man kan sjekke om brukeren er student via cache eller Dataporten. For å logge inn med Dataporten så starter prosessen egentlig først med at klient applikasjonen mottar client_id og addressen til Dataporten ifra serveren. Klienten oppretter så en lang streng kalt state som den lagrer i localstorage. Klient applikasjonen redirecter så brukeren til Dataporten addressen sammen med state og client_id variablene. Etter at brukeren har logget inn hos Dataporten, så redirectes brukeren tilbake til serveren til API-kallet /API/Auth/DataportenRedirect, sammen med variabelen state og code. Serveren kontakter så Dataporten og oppgir client_id, client_secret og code for å hente ut en Token. Når serveren har fått tilbake en Token så settes denne i cookie og brukeren redirectes videre til /#/result sammen med state variabelen. Her ifra Controllers/AuthController i funksjonen DataportenRedirect Når brukeren kommer til /#/result (i filen wwwroot/view/login/result.js), så sjekkes state variabelen imot den som sitter i localstorage, om disse variablene stemmer så hentes Token ut ifra cookie. Token lagres så i localstorage for videre bruk. Token legges nå til i hvert API kall til serveren. I filen wwwroot/views/factories.js så opprettes det en service som har ansvar for å legge til token ved hvert API kall: Studentparlamentet - HiOA 93

94 Lokale brukerkontoer Det er lagt til funksjonalitet slik at også brukere som ikke er studenter skal kunne bruke systemet. Studentparlamentet har ansvaret for å opprette og administrere disse kontoene og anonyme brukere kan ikke opprette lokale brukerkontoer. En brukerkonto kan være av typene administrator, ordstyrer eller ordinær og passord lagres i databasen sikkert ved hjelp av industristandarden for lagring av passord; PBKDF2. I filen Controllers/AuthController ligger en statisk metode HashPassword: Studentparlamentet - HiOA 94

95 Når brukere logger inn, opprettes det en sesjon i database og en token som sendes tilbake til brukeren. En lokal brukerkonto token er gyldig i 7 dager uten aktivitet. Beskyttelse mot automatisert passordgjetting For å beskytte systemet mot Bruteforce-angrep, er det implementert en robot test etter 3 mislykkede innloggingsforsøk fra en IP-adresse. Klassen BruteforceProtector i filen Controllers/AppSingleton benyttes for å logge forsøkene. Hvis IP-adressen er merket som blokkert, krever systemet at man løser en robot test. Systemet benytter tjenesten Google recaptcha til dette. Figur 57. Mislykket innloggingsforsøk Bildet over viser at etter 3 mislykkede innloggingsforsøk, bes brukeren om å løse en utfordring før man kan gjøre et nytt innloggingsforsøk igjen. Klassen BruteforceProtector er laget med disse hensyn: En IP addresse skal ikke tilgis fullstending om forsøket var vellykket. Jo mer en IP addresse mislykkes, jo lengre varer blokkeringen. Studentparlamentet - HiOA 95

96 Autorisering API kallene på applikasjonsserveren sikres med den innebygde autorisasjons funksjonaliteten i.net Core. Ved oppstart av applikasjonen så konfigureres autorisasjonen med Policies. Her ser man Admin og Ordstyrer policyene bli lagt til som tilgjengelige roller. Dette er fra filen Startup.cs i funksjonen ConfigureServices. Man beskytter så priviligerte API kall med enten Ordstyrer eller Admin policy via et Filter. Når.NET Core ser disse filtrene over et API kall så legger man til ekstra funksjonalitet som blir utført ved API kallet. Her aktiverer man Authorize filteret hvor rollen Ordstyrer er et krav til brukeren. For å legge til riktige roller til brukeren, så legger man til Claims til brukeren. Når brukeren oppgir en gyldig Token i HTTP header så valideres denne i Controllers/TokenAuthentication og passende roller blir lagt til. I koden under så leter man i databasetabellen Studenter om studenten er administrator eller ordstyrer, og legger til Claims til brukeren. Studentparlamentet - HiOA 96

97 I Startup.cs sin funksjon Configure så ser vi her at middleware TokenAuthentication blir brukt og kjørt før MVC ruten api slik at vi får lagt til riktige roller til brukeren før API kallet utføres. Beskyttelse mot Token gjetting Både Dataporten og de lokale brukerkonto bruker Token, en lang tilfeldig streng, til å identifisere en bruker for serveren. Uten beskyttelse er det ingenting som stopper noen fra å gjette etter gyldige Tokens konstant døgnet rundt. For forhindre dette er det implementert Token signering, slik at en Token som blir presentert til serveren må ha en gyldig signatur for å regnes som gyldig. I filen Controllers/AppSingelton er det 2 funksjoner som brukes for opprettelse og validering av en Token; GenerateSignedToken og VerifySignedToken. Studentparlamentet - HiOA 97

98 Når man oppretter Token som skal sendes til brukeren, så brukes GenerateSignedToken. Når serveren mottar en Token ifra bruker, verifiserer token med VerifySignedtoken. Det benyttes HMAC SHA256 for å signere token, og den hemmelige nøkkelen genereres ved oppstart. Talerlistesystem Prosjektstruktur Klient siden er skrevet i Angular2, alle filene ligger under src mappen, her ligger bla.a. TypeScript filene, JavaScript filene og HTML/CSS filene. Under node_modules mappen ligger node package dependencies filene, dette er filer Angular trenger for å kunne kjøre prosjektet og sette opp en lokal lite dev-server der siden kan kjøres. I hovedmappa ligger følgende filer: -bs-config.json Browsersync Lite nodeserver som serverer en webapplikasjon, åpner den i nettleseren, oppdateres når HTML eller JS endres, injiserer CSS-endringer ved hjelp av sockets og har en fallback side når en route Studentparlamentet - HiOA 98

99 ikke er funnet. -package.json package.json gir oss metadata om en pakke i npm registeret. package.json brukes som det som tilsvarer et manifest om applikasjoner, moduler, pakker og mer - det er et verktøy som brukes til å gjøre moderne utvikling modulært og effektiv. -tslint.json er der i tilfelle prosjektet kjøres på CLI eller andre tredje-part verktøy for å bestemme hvilke regler som blir satt. -.editorconfig EditorConfig hjelper utviklere med å holde konsistente koding stiler mellom forskjellige editorer. I src mappen ligger det en mappe, app mappen det er her selve prosjektet sitter. I tillegg til main.ts, index.html, og andre media bilder. -tsconfig.json Tilstedeværelsen av en tsconfig.json-fil i en katalog indikerer at katalogen er roten til TypeScript-prosjektet. -system..config.js Konfigurerbar modullaster som muliggjør dynamiske ES modul-arbeidsflyter i nettlesere og NodeJS. Under app mappen ligger all koden. For hver mappe ligger det minst en.component.ts fil, og en.component.html fil, i tillegg en.js og.js.map fil som blir generert automatisk når TypeScript filen transpileres. App mappen har noen spesielle filer som ikke ligger noen andre steder som app.routing.ts og app.module.ts, app.routing.ts styrer routingen i systemet, og bestemmer hvor du blir videreført når du trykker på en link i prosjektet. Studentparlamentet - HiOA 99

100 Routes app.module.ts er modul filen, en modul klasse beskriver hvordan applikasjonsdelene passer sammen. Hver applikasjon har minst en Angular modul, rotmodulen du starter opp for å starte programmet. Det kan kalles hva som helst. Det konvensjonelle navnet er AppModule. Studentparlamentet - HiOA 100

101 Importeringer dekoratoren forteller Angular at AppModule er en modul klasse (også kalt NgModule klasse i tidligere tar et metadataobjekt som forteller Angular hvordan den skal kompilere og starte programmet. -Imports - importerer filer som er nødvendige for at denne applikasjonen kan bli kjørt -Declarations - Hvilke komponenter må tas med -Bootstrap - Rot komponenten som Angular oppretter og legger inn i index.html vertssiden. Mer om moduler i Hver komponent har en selector, som rendrer komponentets tilsvarende html fil i Studentparlamentet - HiOA 101

102 app.component sin router outlet. En router outlet fungerer som en plassholder som Angular fyller dynamisk basert på gjeldende route tilstand. Når nettleserens nettadresse for vår programmet blir / selector, matcher ruteren den URLadressen til routeren /selector og viser den samsvarende component.ts filen. <router-outlet> </ router-outlet> <! - Routed visninger gå her -> For at dette skal funke riktig må vi inkludere <base href="/"> i index.html app.component.html <base href= / > må være med my-app selektoren i indeks.html Studentparlamentet - HiOA 102

103 selecktoren i app.component.ts Videre er det en fil som finnes i de andre mappene og det er.service.ts filen, grunnen til at det ikke finnes en i app mappen er at den rett og slett ikke trengs her. Service er objekter som knyttes sammen for å organisere og dele kode i prosjektet, dette gjøres via dependency injection hvor vi bare injekter eller sender med servicen som et argument i konstruktøren til komponentet der det skal brukes, videre kan servicens funksjoner kalles i komponentet via objektet som ble injektert. dekoratoren lar Angular vite at en klasse kan bli brukt med dependency injektoren. Studentparlamentet - HiOA 103

104 Eksempel hvor representant.service.ts blir satte inn i komponentets konstruktør dermed blir den videre kalt derfra Systembeskrivelse Administrator skal kunne: -Legg til og slette talere -Lage og slette møter -Registrere og slette representanter -Gi replikk og innlegg på vegne av en representant dersom vedkommende ikke har en smarttelefon eller pc tilstede. -Trekke tilbake innlegg og replikker. Studentparlamentet - HiOA 104

105 Figur 58. Use-case diagram Use case Studenten skal kunne: -Gi et innlegg -Gi to replikker -Melde seg til tale Studentparlamentet - HiOA 105

106 Figur 59. Use-case diagram Figur 60. UML diagram Init-representanter skal initialisere representanter, her kan representanter enten hentes fra en database eller fra local storage. Servicen håndterer funksjoner. Komponenten kaller metodene i servicen. Studentparlamentet - HiOA 106

107 Figur 61. UML diagram Figur 62. Aktivitetsdiagram Når tiden starter har representanten 2 minutter på å snakke. Dersom de blir ferdige skal de sjekkes om noen vil gi et replikk, dersom ingen vil gi et replikk sjekkes det om noen vil gi et innlegg. Dersom ingen vil gi hverken replikk eller innlegg, skal neste taler få snakke. Studentparlamentet - HiOA 107

108 Figur 63. Diagram Studentparlamentet - HiOA 108

109 Brukerveiledning Nettsted Innlogging for administrator Figur 64. Innloggingsside Studentparlamentet benytter Wordpress sin innloggingsportal. For å få tilgang til nettstedet må administrator gjøre følgende: 1. Skrive inn brukernavn eller e-postadresse 2. Skrive passord 3. Trykke på «Logg inn» knappen. 4. Dersom man har mistet eller ikke husker passord må man trykke på lenken, «Mistet ditt passord?» for å få tilsendt dette. Studentparlamentet - HiOA 109

110 Kontrollpanelet - forside Figur 65. WordPress kontrollpanel Figur 65 viser forsidebildet av kontrollpanelet i WordPress, og er den første siden man kommer til når man logger inn. I kontrollpanelet kan administrator: administrere nettstedets utseende og funksjonalitet ved hjelp av den vertikale menyen til venstre. få oversikt over aktivitet på siden. få oversikt over nettstedets utseende ved å holde musepekeren over lenketeksten: «Studentparlamentet», som ligger i venstre hjørne av kontrollpanelet ved siden av hus-ikonet, og trykke på lenken. Studentparlamentet - HiOA 110

111 Funksjonalitet i «Utseende» Figur 66. Den vertikale menystrukturen For å kunne utføre endringer eller videreutvikle nettstedet er den vertikale menyen til venstre i bildet over svært sentral. Mesteparten av funksjonaliteten utføres ved hjelp av merkelappen «Utseende» og dens undermeny. I bildet over kan man se at denne menyen uthevet. Forklaring av undermenyene til «Utseende» i kontrollpanelets vertikale meny: «Temaer» Temaer i Wordpress er en designmal som definerer hvordan sidene vil se ut på nett. De definerer alt fra hvordan navigasjonen på sidene vil fungere, til design, farger og fonter som blir brukt. Temaet som dette nettstedet benytter heter «Evolve», og har blitt skreddersydd ved hjelp av tilpasningsmulighetene i «Utseende»-menyen. Studentparlamentet - HiOA 111

112 «Tilpass» Figur 67. Tilpasningsmuligheter i "Evolve" Trykker man på knappen «Tilpass» i «Utseende»-menyen får man mange tilpasningsmuligheter i «Evolve» temaet. Disse mulighetene er illustrert i bildet over. Her kan man endre nær sagt alt på nettstedet, og få en forhåndsvisning av hvordan endringene vil se ut på nettstedet, før man eventuelt trykker på knappen «Lagre og publisere». Under er en beskrivelse av hvor man finner relevant funksjonalitet i «Tilpass», og dens valgmuligheter: Studentparlamentet - HiOA 112

113 Bredden på nettstedet: Utseende -> Tilpass -> General -> Layout. Figur 68. Nettstedets bredde Søkefelt (aktivering/deaktivering) og posisjonen til bildekarusellen (slider): Utseende -> Tilpass -> Header -> Header. Figur 69. Bildekarusell Studentparlamentet - HiOA 113

114 Sticky header (synlig menyen ved scrolling): Utseende -> Tilpass -> Header -> Sticky header. Figur 70. Sticky header Logo (opplasting og plassering): Utseende -> Tilpass -> Header -> Logo. Figur 71. Logo Studentparlamentet - HiOA 114

115 Avstand (padding) mellom menyobjektene: Utseende -> Tilpass -> Header -> Menu. Figur 72. Avstand mellom menyobjekter Fontstørrelse til meny: Utseende -> Tilpass -> Typography -> Menu. Figur 73. Menyens fontstørrelse Studentparlamentet - HiOA 115

116 Fontstørrelse til widgets: Utseende -> Tilpass -> Typography -> Widgets. Figur 74. Widgets fontstørrelse Forandre teksten ved siden av logo: Utseende -> Tilpass -> Nettstedsidentitet. Figur 75. Endring av tekst ved siden av logo Aktivere/deaktivere brødsmulestien: Utseende -> Tilpass -> Page Title/Breadcrumbs/Page Title Bar. Studentparlamentet - HiOA 116

117 Figur 76. Innstillinger for brødsmulesti Farge på navigasjonsmeny og bakgrunnsfarge: Utseende -> Tilpass -> Styling -> Menu. Figur 77. Farge (bakgrunn og navigasjonsmeny) Tilpasse snarveiene på forsiden: Utseende -> Tilpass -> Front Page Content Boxes -> General»/»Content Box. Studentparlamentet - HiOA 117

118 Figur 78. Snarveier Tilpasse bildekarusellen: Utseende -> Tilpass -> Bootstrap slider -> Slides. Figur 79. Tilpasning bildekarusell Studentparlamentet - HiOA 118

119 Plassering av meny: Utseende -> Tilpass -> Menyer -> Menylokasjoner. Figur 80. Plassering av meny «Widgeter» Ved å gå til Widgets i undermenyen til Utseende, kan man bruke widgetene man har lastet ned ved å aktivere eller deaktivere de, og plassere de i widgets-områdene som er definert ved hjelp av «drag-and-drop». I tilfellet til Studentparlamentets nettsted har det blitt plassert en Facebook-feed kode i en tekstboks som har blitt lagt i «Sidebar 1». Dette har resultert i en synlig Facebook-feed nederst på forsiden av nettstedet. Figur 81. Widgeter Studentparlamentet - HiOA 119

120 «Menyer» Her kan man redigere og definere hvordan menystrukturen til nettstedet skal se ut. Her kan man plassere sider som man har opprettet. Her skaper man menyer og undermenyer ved hjelp av «foreldre-barn» prinsippet. Undermenyer opprettes ved å trykke på en side, holde knappen inne, og lage et lite innrykk under hovedmeny-merkelappen. Figur 82. Menystruktur Studentparlamentet - HiOA 120

121 Beskrivelse av annen relevant funksjonalitet i kontrollpanelets vertikale meny: «Sider» I bildet under har vi uthevet hvor man går for å legge til nye sider eller administrere eksisterende sider. Figur 83. Kontrollpanel - Sider Trykker man på knappen «Sider» eller «Alle sider», kommer man til bildet under. Her får man oversikt over alle eksisterende sider, deres redigerings- og slettemuligheter, og deres «foreldre-barn» relasjoner. Her ser man for eksempel at «Dokumenter» er en forelder, mens Styringsdokumenter er et barn. «Forretningsorden er barnebarnet. Dette indikerer dybden i menyvalget. Studentparlamentet - HiOA 121

122 Figur 84. "Legg til ny" Trykker man på «Legg til ny» får man muligheten til å opprette en ny side. Bildet under illustrerer oppsettet for å legge til ønsket innhold, og bilder som man henter fra «Media» i kontrollpanelet. Media er et bibliotek over alle nedlastede bilder. Figur 85. "Legg til ny side" Studentparlamentet - HiOA 122

123 «Utvidelser» Figur 86. Utvidelser Dersom man trykker på Utvidelser i den vertikale menyen får man oversikt over alle widgets og plugins man har lastet ned og tilgang til, samt muligheten for å laste ned nye. Se bildet under. Disse kan man forandre innstillingene til dersom ønskelig ved å trykke på settings/innstillinger. En rekke av disse utvidelsene er også synlige i den vertikale menyen. De som er sentrale for nettstedet er: WordFence: WordFence er en sikkerhets-plugin som administrerer nettstedets sikkerhet. Den håndterer login-sikkerhet, IP blokkering, sikkerhetsskanning, Wordpress brannmur og overvåkning. Den skanner nettstedet en gang om dagen og gir deg tilbakemeldinger på nødvendige handlinger som må utføres for å holde nettstedet sikkert. Den informerer også om nødvendige oppdateringer som må utføres for å holde benyttede plugins ajour. Dette forhindrer at uvedkommende for uønsket tilgang til eldre og mer sårbare versjoner. Bildet på neste side viser menystrukturen til pluginen som er synlig i kontrollpanelets vertikale meny. Studentparlamentet - HiOA 123

124 Bildet under viser WordFence sitt dashboard i kontrollpanelet. Her får man oversikt over nettstedets beskyttelsesstatus. Figur 87. WordFence Dashboard Trykker man på Scan i menyen til WordFence kommer man til bildet på neste side. Her kan man utføre en skanning av nettstedet ved å trykke på knappen START A WORDFENCE SCAN. Når skanningen er utført får man en liste av saker nederst på siden. Studentparlamentet - HiOA 124

125 Figur 88. Skanning fullført Andre utvidelser som er nyttige og enkle å administrere i den vertikale menyen er: - Custom Facebook feed: Er koblet til Studentparlamentets Facebook side - Contact form 7: Lar brukere ta kontakt med Studentparlamentet - Event Calender WD: Gir oversikt over kommende hendelser - GT Translate: Sørger for tospråklighet. Studentparlamentet - HiOA 125

126 Innstillinger Figur 89. Generelle innstillinger Her kan man forandre på innstillingene til nettstedet. I bildet under er vi inne på generelle innstillinger («Generelt»). Her kan man blant annet knytte ønsket e-post adressen til nettstedet, angi dato- og tidsformat som skal benyttes og mye annet. Veldig enkelt og forståelig. «Brukere» Her kan man legge til, og fjerne brukere som skal ha administrative rettigheter til nettstedet. Figur 90. Administrering av brukere Studentparlamentet - HiOA 126

127 Brukerveiledning - System for dokumentbehandling Installasjon (Installasjon instrukser for Ubuntu 16.04) Dataporten Autentisering 1. Registrer applikasjonen Studentparlamentet - HiOA 127

128 OAuth 2.0 Redirect Url: domene/api/auth/dataportenredirect Inne i konfigurering av applikasjon vi akkurat registrerte, så må det legges til flere rettigheter. Studentparlamentet - HiOA 128

129 Disse blir vist til brukeren når brukeren logger inn via Dataporten, og kan da se hvilke informasjon applikasjonen får tilgang til. Vi trenger tilgang til Grupper og eventuelt Longterm om man vil slippe å logge inn ofte. Vi må nå konfigurere applikasjon via filen appsettings.json i applikasjons mappen. Vi henter den nødvendige informasjonen fra konfigurerings panelet i Dataporten Sett så inn korrekt data i appsettings.json Da skal alt være konfigurert! Studentparlamentet - HiOA 129

130 Database 1. Installer PostgreSQL sudo apt-get install postgresql 2. Lag bruker med CREATEDB rettigheter sudo su - postgres psql CREATE ROLE brukernavn WITH CREATEDB; ALTER ROLE brukernavn WITH LOGIN; \password brukernavn \q exit 3. Oppdater appsettings.json med brukernavn og passord til databasen "DbContextSettings": { "ConnectionString": "User ID=brukernavn;Password=passord; Installer databasen dotnet restore dotnet ef migrations add InitialMigration dotnet ef database update Google recaptcha For å sikre innlogging imot automatisert passord gjette angrep, sikres innlogging med en anti-robot test etter 3 login feil. Google recaptcha tilbyr denne tjenesten. Studentparlamentet - HiOA 130

131 Her må man taste inn domene man bruker for applikasjonen. Vi legger til Site key og Secret key til applikasjon vår via appsettings.json filen. Studentparlamentet - HiOA 131

132 .NET Core todo 1. Installer.NET Core 1.1 på Ubuntu Compiler prosjektet dotnet restore dotnet publish -c Release Dette blir kompilert til bin/release/netcoreapp1.1/publish/ 3. Opprett systemd Service sudo nano /etc/systemd/system/kestrel-dokbeh.service [Unit] Description=Example.NET Web API Application running on Ubuntu [Service] WorkingDirectory=/applikasjon mappe/bin/release/netcoreapp1.1/publish ExecStart=/usr/bin/dotnet /applikasjon mappe/bin/release/netcoreapp1.1/dokumentbehandling.dll Restart=always RestartSec=5 SyslogIdentifier=dotnet-dokbeh User=www-data Environment=ASPNETCORE_ENVIRONMENT=Production [Install] WantedBy=multi-user.target Studentparlamentet - HiOA 132

133 sudo systemctl enable kestrel-dokbeh.service sudo systemctl start kestrel-dokbeh.service Reverse proxy sudo apt-get install nginx sudo nano /etc/nginx/sites-available/default sudo service nginx start Studentparlamentet - HiOA 133

134 Brukerveiledning - Ordinære brukere Generell navigering av dokumenter og endringsforslag 1. Dokument kategoriene som Studentparlamentet har organisert dokumentene sine i. Trykk for å velge kategori. 2. Tittelen på dokumentet. Trykk for å se endringsforslagene for dokumentet 3. Indikator på hvor mange endringsforslag på dette dokumentet 4. Åpen lås indikerer at dokumentet er åpent for motta nye endringsforslag 5. Åpne et nytt vindu med print-visningen for kategorien som er valgt 6. Her kan man velge sorteringen av dokumentene; dato eller alfabetisk Studentparlamentet - HiOA 134

135 1. Linjenummer. Om forslaget er uten sidenummer og linjenummer er forslaget generelt. 2. Trykk her for å vise detaljene til forslaget. 3. Forslagene kan vises i forskjellige organiseringer. Opprette endringsforslag - logg inn 1. Logg inn som student, via Dataporten 2. Logg inn med lokal brukerkonto Studentparlamentet - HiOA 135

136 Opprette endringsforslag Man kan velge å utelate sidenummer og linjenummer, da blir endringsforslaget generelt. Redigere sine egne endringsforslag Studentparlamentet - HiOA 136

137 For å endre sine egne forslag så kan man gjøre dette via fanen Mine forslag. Endringsforslagene får nå en egen knapp for å endre forslaget sitt. Trykk så på denne. Her kan man endre alt ved forslaget sitt. Man kan til og med trekke sitt eget forslag. Utforske endringsforslag Ved å trykke på forstørrelsesglasset så kan man få se flere detaljer om endringsforslaget. Studentparlamentet - HiOA 137

138 1. Man kan bla igjennom forslagene ved hjelp av disse 2 knappene. 2. Knapp for å lukke visningen Brukerveiledning - Ordstyrere Som ordstyrer kan du utføre noen fler funksjoner En ordstyrer kan åpne og stenge dokumentet for nye endringsforslag. Studentparlamentet - HiOA 138

139 I tillegg kan en ordstyrer trekke et forslag. Brukerveiledning Administratorer 1. En administrator kan opprette nye kategorier. Trykk på denne knappen for å redigere kategoriene. 2. Trykk her for å laste opp nye dokumenter. 3. Trykk her for å gå til administrator innstillingene. 4. En administrator kan redigere dokumentene som er lastet opp. Studentparlamentet - HiOA 139

140 5. Her er menyen for dokument-redigeringen. Redigere kategorier Man kan slette kategorier ved å trykke på det røde krysset, men kun om det ikke er noen dokumenter i kategorien. Man må da først slette dokumentene i kategorien før man slette hele kategorien. For å opprette nye kategorier så trykker man på den blå knappen. Trykk deretter Lagre for å lagre endringene. Laste opp dokumenter Man kan laste opp flere filer på en gang, og filene som blir lastet opp til kategorien som er valgt. Trykk på Last Opp knappen for å velge filer. Arkivere dokumenter Om filene / dokumentene ikke lenger er relevante, kan man velge å arkivere dokumentene. Disse forblir i kategorien men flyttes nederst på siden til Arkiv. Administratorinnstillinger - Studenter Studentparlamentet - HiOA 140

141 Man kan legge til studenter med spesielle roller for studenter som logger inn via Dataporten. Den røde knappen fjerner og det grønne plusstegnet legger til en ny student. Trykk Lagre for å lagre endringene Administratorinnstillinger - Lokale brukerkontoer Man kan legge til og slette lokale brukerkontoer. Den første administrator kontoen kan ikke bli slettet eller gjort til en ikke administratorkonto, for å sikre mot utlåselse. Administratorinnstillinger - Systemlogg Om det har oppstått feil i systemet, så logges dette. Administratoren kan se i loggene for å se nærmere på feilen og vurdere å kontakte system administratorene. Studentparlamentet - HiOA 141

142 Brukerveiledning Talerlistesystem Installasjon Sjekk at følgende er installert før du starter: Siste versjon av.net rammeverket: Siste versjon av C++ redistributable for VS2015: Viktig! Siste verson av Node.js: Viktig! Siste versjon av TypeScript: Kan gjøres gjennom et terminal dersom npm er installert: npm install -g typescript Først start med å laste ned skjelettet for programmet. Dette er filer som er nødvendiger for å få programmet til å kjøre. Den enkleste måten å gjøre dette er ved å bruke git. git clone SpioApp Man kan kalle mappen hva som helst, men for demonstreringens skyld kaller vi den for SpioApp. cd SpioApp For å skifte til katalogen vår. npm install For å laste ned node packages, kopier over følgende mapper til app/ addmeeting, addrepresentant, hjem, og stud-exists. I tillegg må disse filene oppdateres med de nye: -app.component.html -app.component.ts -app.module.ts -app.routing.ts Under src/ må følgende filer oppdateres: -index.html Slett ikke-essensielle filer: For OS/X: SpioApp xargs rm -rf < non-essential-files.osx.txt rm src/app/*.spec*.ts rm non-essential-files.osx.txt Studentparlamentet - HiOA 142

143 For Windows: for /f %i in (non-essential-files.txt) do del %i /F /S /Q rd.git /s /q rd e2e /s /q Nå kan den lokale serveren startes ved å skrive inn følgende i en terminal: npm start Serveren vil som standard kjøre på localhost port 3000 dette kan lett endre ved å endre bs-config.json filen, sett inn følgende: { "server": { "port": ønsket port nr, "basedir": "src", "routes": { "/node_modules": "node_modules" } } } Administrator Legge til representant For å legge til en representant trykker du på Administrer representanter i navigasjons baren eller Legg til representant under snarveien. Figur 91. Knappene som tar deg videre til representant siden Da kommer du til følgende side: Studentparlamentet - HiOA 143

144 Figur 92. Legg til en representant Trykk på «Legg til representant», og fyll inn all nødvendig info. Figur 93. Representant skjema Dersom alle feltene blir blanke igjen betyr det at representanten nå er registrert, det kan du dobbeltsjekke under listen for representanter. Figur 94. Bekreftelse i konsollen Studentparlamentet - HiOA 144

145 Figur 95. Representant liste Figur 95 viser representanten som er registrert som nr. 5 i listen. Alle nye representanter havner nederst i listen. Nå kan representanten endres, du kan endre info på representanten og dette blir oppdatert i real-time så endringene du gjør vises til deg direkte. Figur 96. Endre representant Studentparlamentet - HiOA 145

146 Styre møte Fra hovedsiden velg styr møte fra navigasjonsbaren eller fra snarveien. Figur 97 Knappene som tar deg videre til styringssiden Dette tar deg videre til siden hvor ord styringen skjer, her vil alle representanter bli lastet opp etter den rekkefølgen de er i listen. Det vil si slik du la dem inn. For demonstreringens skyld er det gjort slik at hver representant kan kun snakke i 2 sekunder, men som standard snakker h*n i 2 minutter. Figur 98. Styr møte Nå kan førstemann som er Hotan snakke i 2 minutter. Mens han snakker kan andre gi en replikk eller innlegg. For å starte timeren trykk på den grønne play knappen. Studentparlamentet - HiOA 146

147 Figur 99. Play knapp Figur 100. Innlegg og replikker Arlen og Mohamed ligger i replikk køen, mens Ola og Boning ligger i replikk køen. Det vil si at når Hotan sin tid er over vil Arlen talen. Når Arlen sin tid er over vil Mohamed tale igjen. Nå er innlegg køen tom, det vil si at vi går over til replikk køen, der kommer Ola til å snakke først før ordet går over videre til Boning. Studentparlamentet - HiOA 147

148 Figur 101. Arlen snakker Vi ser at vi får en bekreftelse i konsollen om at Hotan er ferdig med å snakke. Påminnelse fra konsoll Figur 102. Arlen ferdig med å snakke Studentparlamentet - HiOA 148

149 Figur 103. Mohamed ferdig med å snakke Figur 104. Ola ferdig med å snakke Når Boning er ferdig med å snakke vil Arlen automatisk bli lagt som taler etter Boning siden Arlen var Hotan og det er sånn vi vil ha det! Studentparlamentet - HiOA 149

150 Figur 105. Boning ferdig med å snakke For å legge til en ny taler kan en bare trykke på legg til neste taler knappen og den vil automatisk legge til neste taler fra listen. Figur 106. Legg til neste taler Studentparlamentet - HiOA 150

151 Kildeliste Bjørklund, O. (u.d.). nofima.no. Hentet Mai 9, 2017 fra Fokusgruppe Noen metodiske betraktninger: Blomkvist, J. S. (2014, September 1). Benefits of external representations in service design: A distributed cognition perspective. The Design Journal. doi: / x Google Forms. Brukt til spørreundersøkelse. Hentet 25. januar 2017 fra Høgskolen i Oslo og Akershus. (u.d.). Bachelorprosjekt. Hentet Januar 23, 2017 fra Dokumentasjonsstandard: Lovdata. (2013). Forskrift om universell utforming av informasjons- og kommunikasjonsteknologiske (IKT)-løsninger. Hentet 16. mars 2017, fra Konsmo, T. (u.d.). regjeringen.no. Hentet Mai 9, 2017 fra Fokusgruppeintervju: Nielsen, J. (2012, Januar 16). Nielsen Norman Group. Hentet Februar 10, 2017 fra Thinking Aloud: The #1 Usability Tool: usability-tool/ Rosenfeld, M. &. (2015). Information Architecture: For the Web and Beyond. United States of America:: O'Reilly Media, Inc. doi: Rubin, J. C. (2008). Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests. Indianapolis, USA: Wiley Publishing, Inc. Sandnes, F. (2011). Universell utforming av IKT-systemer: brukergrensesnitt for alle. Oslo: Universitetsforlaget. Sommerville, I. (2010). Software Engineering (9. utg.). USA: Addison-Wesley Publishing Company. Spencer, D. (2006, Mars 14). boxes and arrows. Hentet April 25, 2016 fra Four Modes of Seeking Information and How to Design for Them: Tidwell, J. (2005). Designing Interfaces. Beijing: O'Reilly Media. Studentparlamentet - HiOA 151

152 Dataordbok Uttrykk Agile AngularJS 1.X API Bash Bootstrap Code review fk MS Visual Studio MVC MySQL PHP Plugin Scrum SP Tema Beskrivelse Smidig utvikling som innebærer utvikling i sykluser og prioriteringer av implementasjon framfor planlegging av hele systemet. Asynkront frontend-rammeverk for dynamiske nettsider, med støtte for MVC. Utviklet av Google. Application programming interface, en måte for programmer å prate med hverandre. En interaktiv terminal på UNIX-lignende systemer. Vi bruker i vårt prosjekt dette for å automatisere enkelte oppgaver. Et designrammeverk for webapplikasjoner, laget av Twitter. Inneholder mye brukte komponenter, som knapper, menyer og lignende. En gjennomgang av kode som ofte skal inn i en kodebase. forreign-key; refererer til en annen tabell. integrert utviklingsmiljø (IDE) for Microsofts.NET platform. Designmønster anvendt i programvareutvikling. Er en relasjonsdatabase. Er et programmeringsspråk som brukes til å lage nettsider. Plugins er ferdig designede kodelinjer i PHP som du kan installere for å gjøre forskjellige oppgaver på din side. Er en smidig utviklingsmodell. Studentparlamentet HIOA er en mal for design og grunnleggende funksjonalitet i Wordpress. Studentparlamentet - HiOA 152

153 TFS TLS Widgeter Wordpress XAMPP Kildekode håndtering og versjonskontroll. Transport Layer Security. Ved å kjøpe et TLS sertifikat kan man sikre forbindelse mellom servere og brukere. er et område på sidene dine hvor du kan putte inn de tilleggene du har installert. Et rammeverk for å lage nettsteder. Er en web-serverprogramvare som inneholder alt du trenger for å kunne hoste egne nettsider fra egen PC. Studentparlamentet - HiOA 153

154 Vedlegg Hovedprosjekt - Gruppe 11 Høgskolen i Oslo og Akershus Studentparlamentet - HiOA 154

155 Opprinnelig kravspesifikasjon Studentparlamentet - HiOA 155

156 Arbeids- og fremdriftsplan Arbeidsplan faser Planlegging/design Ferdiggjøre kravspesifikasjon, skissering og tegning av hvordan vi ser for oss nettstedet og appen, i tillegg oppsett av database. Forberedelser Sette opp og konfigurere servere med tanke på versjonskontroll og test servere. Vi har blitt enige om å bruke versjonskontroll systemet Microsoft Team Foundation Server, som må installeres på en server vi alle kan få tilgang til. I tillegg sørge for at hver av gruppemedlemmene har hva de trenger av programvare og utstyr. Implementering Vi implementerer hvert av systemene ifølge kravspesifikasjonen. Hvert av systemene (nettside, talerliste, dokumentbehandling) implementeres til forskjellige tider slik at vi kan fokusere på et system av gangen. Det er bestemt at implementeringen av appen for talerliste systemet skal skje sist. Brukertesting Etter implementasjonen av et system (eller mot slutten av implementasjonen) legger vi opp til brukertesting. Da gjør vi løsningen tilgjengelig for Studentparlamentet, slik at de kan se hvordan resultatet er blitt. Vi kan dermed få tilbakemeldinger på hva som er bra og hva som burde vært annerledes. Vi implementerer og dokumenterer disse endringene. Testing Testing skal foregå under hele utviklingsperioden for å sikre effektivitet, produktivitet og minimere antall bugs. Det er ønskelig at systemet skal fungere på alle weblesere (Microsofts IE, Mozillas Firefox, Googles Chrome, Opera, Apples Safari). Det vil bli utviklet en testmetode for hver metode/funksjon slik at vi kan ajourføre logging av all bugs og metodesvakheter/sikkerhetshull. Studentparlamentet - HiOA 156

157 Dokumentasjon Løsningen skal være dokumentert nøye slik at dersom Studentparlamentet har behov for fremtidig videreutvikling så skal dokumentasjonen være til hjelp (det blir også skrevet en brukerveiledning, evt. flere brukerveiledninger). Dokumentasjonen skal skrives jevnlig under hele utviklingsperioden for å fordele arbeidsmengden. Fremdriftsplan Gruppen og intern veileder har en felles avtale om å møtes annenhver uke. Dersom vi har spørsmål eller sitter fast kontakter vi vedkommende per e-post. Vi har skrevet kontrakt med oppdragsgiveren. Gruppen har regelmessige gruppemøter hver uke. Kommunikasjon utenfor skolens premisser foregår via Slack, som er en plattform der utviklere kan kommunisere. Frister 1. Uke 4: Forprosjekt Uke 21: Prosjektrapport Uke 23: Presentasjon Studentparlamentet - HiOA 157

158 Prosjektdagbok - Hovedprosjekt Bachelor Gruppe 11 Første planleggingsmøte: Dato Under vårt første møte diskuterte vi hvordan vi ønsket at samarbeidet skulle foregå, og hva som var våre forventninger til oss selv og hverandre. Vi diskuterte hva slags type hovedprosjekt vi kunne tenke å utføre, og potensielle bedrifter som kunne være interessante. Vi bestemte oss for å tenke mer på dette til neste møte. Søknader sendt ut: Dato I dag har vi sendt unna forhåpentligvis siste runde med søknader til bedrifter. Vi har dannet oss et bilde av hva slags type bedrift og prosjekt vi kan tenke oss. Vi har mottatt et par tilbakemeldinger om potensielt samarbeid, men ingenting konkret enda. I mellomtiden smører vi oss med tålmodighet. Første møte med Studentparlamentet: Dato I dag hadde vi første møte med Studentparlamentet for å diskutere potensielt samarbeid. Deres representanter fra Arbeidsutvalget, Einar Belck-Olsen og konsulent, Jannicke Døvre fortalte oss hva de driver med, og hva de trenger hjelp med. De informerte at det er totalt fire utviklingsoppgaver de ønsker at en eller flere bachelorgrupper skal utføre for de. De lurte på om vi kunne tenke oss å utføre en eller to av de. Vi ble glade for invitasjonen til samarbeid, og svarte at vi skulle diskutere hvilke av oppgavene vi kunne tenke å påta oss. Vi avtalte å møtes på nytt i slutten av uken, og gi de et endelig svar. Statusrapport sendt inn: Dato Studentparlamentet - HiOA 158

159 I dag har vi innlevert statusrapporten som beskriver vår fremdrift. Her har vi beskrevet hva vi har gjort til nå, og at vi trolig er i ferd med å sikre oss en samarbeidsavtale med en interessert oppdragsgiver. Vi skal møte Studentparlamentet for andre gang senere i dag, og krysser våre fingre for at det går i boks. Andre møte med Studentparlamentet: Dato I dag inngikk vi en avtale med Studentparlamentet om å skrive hovedprosjektet for dem. Vi informerte at vi ønsker å utvikle tre av de fire prosjektene de ønsket å få utført. Det vil si, overhale deres nettside, utvikle et digitalt dokumentbehandling-system og et digitalt talerlistesystem de kan benytte i forbindelse med sine møter. De stilte seg positive til dette, og ønsket vårt samarbeid velkommen. Vi vurderte opprinnelig å velge to av disse prosjektene, men vi syntes de virket såpass interessante og lærerike at vi bestemte oss for å være ekstra ambisiøse. Vi er klar over at dette vil kreve mer av oss, men vi ønsker utfordringen velkommen. Etter at dette ble avklart diskuterte vi kravspesifikasjonen, og stilte spørsmål rundt dette. Vi ble enige om å kommunisere via epost frem til prosjektstart dersom det var behov for det. Vi gleder oss til å begynne! Utforming av prosjektskisse og research Dato I dag drev vi med datainnsamling i form av å utforske og sette oss inn i løsningene Studentparlamentet benytter seg av i dag for å forstå omfanget og deres behov i løsningene vi senere skal utvikle. Vi ser at nettsiden deres er overmoden for et designmessig løft og bedre informasjonsarkitektur, og at de interne arbeidsverktøyene kan utvikles til å bli digitale, enklere og mer effektive å bruke. Deretter gikk vi gjennom og diskuterte kravspesifikasjonen vi fikk tilsendt per eposten den 30. Oktober. Der hadde de skrevet generelle krav til hva som måtte være med, men ingen detaljer om hvordan prosjektene måtte se ut. På slutten av dagen begynte vi å planlegge og skrive prosjektskissen som har innleveringsfrist 2.desember. Prosjektskisse levert Dato Studentparlamentet - HiOA 159

160 I dag har vi levert prosjektskissen som beskriver oppdragsgiver og prosjektet vi skal utføre for de. Her har vi også beskrevet teknologiene vi tenker å benytte. Fristen var i morgen. Planleggingsmøte med Studentparlamentet Dato I dag gikk Einar fra Studentparlamentet mer i detalj med tanke på hva de ønsker fra det vi skal utvikle. Vi stilte oppfølgingsspørsmål og tok notater slik at vi senere kan diskutere, og lage ideer. Vi takket ja til deres invitasjon om å overvære Studentparlamentets parlamentsmøte den 24 januar, slik at vi kan sette oss inn i hvordan deres møter foregår, og utvikle en bedre forståelse for hva som bør være med i et talerliste-system. Vi spurte om de kunne sende oss designelementene som vi må ta hensyn til i utviklingen av den nye nettsiden, og en kopi av sakspapirer de benytter for å få ideer til systemene for talerliste- og dokumentbehandling. Gruppemøte Dato I dag gikk vi gjennom e-posten fra Studentparlamentet med designelementene som må være med i den nye nettsiden vi skal utforme. Der var det krav til bruk av farge, logo og annet som vi må ta hensyn til. Vi mottok også et eksemplar på sakspapirer som de bruker i forbindelse med sine møter. Disse papirene gav oss ideer til hvordan vi kan utvikle systemet for å motta og behandle elektroniske endringsforslag. dokumentbehandling. Første møte med veileder Dato I dag har vi hatt vårt første møte med vår veileder, Boning Feng. Vi fortalte han om vårt bachelorprosjekt, og hvordan vi planlegger å gå frem for å realisere det. Vi fikk et par tips til hvordan vi burde tilnærme oss prosessen med å skrive sluttrapporten, og at det er viktig å jobbe parallelt med utvikling og dokumentasjon. Utforming av forprosjektrapporten Dato Studentparlamentet - HiOA 160

161 I dag har vi sittet hele dagen og arbeidet med forprosjektrapporten. Vi har blant annet blitt enige om fremdriftsplan, fremgangsmåten, funksjonaliteter og teknologier vi ønsker å benytte, og fått dette ned skriftlig i rapporten. Forprosjektrapport levert Dato I dag har vi levert forprosjektrapporten. Dette er en mer detaljert utvidelse av prosjektskissen som forklarer mer konkret hvordan vi skal utføre prosjektet. Vi har også gått igjennom tilbakemeldingen på forprosjekt-utkastet vi sendte Studentparlamentet for et par dager siden, hvor vi ba de om å komme med innspill. Tilbakemeldingen var positiv og at det virker som et spennende prosjekt. Den positive feedbacken er noe vi tar med oss videre i prosessen. Observasjon av Studentparlamentsmøte Dato I dag så vi hvordan deres møter fungerer i praksis. Vi hadde møtets sakspapirer foran oss, tok notater, og fulgte med på hvordan dagens talerlistesystemet fungerer. Vi så viktigheten av rollen til ordstyreren da han i denne sammenhengen er øverste autoritet som styrer alt, og som vil få mest nytte av talerlistesystemet. Vi forsto at det vil være viktig og verdifullt for oss å spørre han om et intervju med tanke på utviklingen av systemets funksjonalitet. Etter møtet snakket vi med Einar fra Studentparlamentet om å fasilitere for dette. Gruppemøte Dato I dag sendte vi mail til Einar fra Studentparlamentet vedrørende hva slags tanker de har om sikkerhet med tanke på innlogging til talerlistesystemet, og hva slags type beskyttelse de ønsker. Deretter diskuterte vi hvordan vi kan gå til anskaffelse av en virtuell maskin på clouden i HiOA. Vi sendte en mail til veileder, Amir fra HiOA, og Einar fra Studentparlamentet vedrørende dette. Ansvarsområder: Av hensyn til effektivitet og god progresjon har vi har blitt enige om å fordele hovedansvaret for de tre utviklingsprosjektene på følgende måte: Arlen har overordnet ansvar for utviklingen av systemet for dokumentbehandling. Studentparlamentet - HiOA 161

162 Hotan har overordnet ansvar for utformingen av den nye nettsiden. Mohamed har overordnet ansvar for utvikling av talerlistesystemet. Dette innebærer at vi utifra det vi har bestemt i plenum, og kravspesifikasjonen som vi har blitt enige om å utforme sammen jobber med de ulike prosjektene på egenhånd mellom våre møter. Når vi møtes går vi gjennom det vi har gjort, kommer med innspill og utfører endringer der det trengs. Gruppemøte Dato I dag ble Arlen og Mohamed enige om å bruke Angular 2 i utviklingen. Ettersom de ikke vet nok om dette har de brukt dagen på å lære seg det ved hjelp av tutorials på nettet. Vi mottok også svar fra Amir fra HiOA vedrørende anskaffelse av en virtuell maskin. Han skrev at dette er noe vi må ta opp med BIT. Hotan brukte dagen på å kartlegge nettstedets arkitektur, og lage skisser. Se vedlegg. Møte med veileder Dato I dag har vi hatt møte med veileder vedrørende vår fremdrift. Vi oppdaterte han om hva vi arbeider med for tiden. Det vil si datainnsamling (research, intervju, spørreundersøkelser, mailutveksling), og kravspesifikasjonen. Vi delte kravspesifikasjonen-dokumentet som er under arbeid med veileder slik at han kan se over og gi oss tilbakemeldinger før vi ferdigstiller dokumentet. Intervju med ordstyrer Dato I dag gjennomførte vi et semi-strukturert intervju med Studentparlamentets ordstyrer. Før intervjuet kunne begynne presenterte vi vedkommende for et samtykkeskjema som han signerte. Deretter hadde en av oss hovedansvaret for å stille spørsmålene som vi hadde forberedt på forhånd, mens resten tok notater. Underveis i intervjuet ble det stilt oppfølgingsspørsmål. Svarene vi fikk gav oss verdifull informasjon som vi tar med oss videre i prosessen. Etter møtet renskrev vi intervjuet, og diskuterte svarene vi fikk. Se vedlegg. Studentparlamentet - HiOA 162

163 Analyse av spørreundersøkelsen Dato I dag gikk vi gjennom svarene vi mottok fra spørreundersøkelsene om Studentparlamentets nettside, og skrev en analyse av spørreundersøkelsen. Vi hadde benyttet Google Forms, og stilt en rekke lukkede og åpne spørsmål. Av de seksten svarende så fikk vi mange verdifulle tilbakemeldinger som vi vil ta hensyn til i utformingen av kravspesifikasjonen og senere nettsiden. Fellesnevneren for nesten samtlige svarende var at det var for vanskelig og tungvint å finne frem til relevant informasjon. Dette er noe vi vil ta spesielt hensyn til i vår videre utvikling. Ferdigstilling av kravspesifikasjon Dato I dag begynte vi møtet med å diskutere mailen til Einar vedrørende muligheten for en.netserver fra seksjonssjefen for IT. Seksjonssjefen for IT ønsket et møte med oss vedrørende dette, og foreslo et tidspunkt vi kunne møtes for å diskutere dette. Deretter gikk vi over all innsamlet data, og ferdigstilte kravspesifikasjonen bruke fremover. Resten av møtet diskuterte vi hvordan nettsiden som vi skal pusse opp skal se ut. Etter at vi hadde diskutert vår analyse av svarene fra brukerundersøkelsen, gikk vi over skissene som Hotan hadde laget og kom med forslag til enda bedre arkitektur og design. Møte med IT-seksjonen Dato I dag hadde vi møte med sjefen for IT-seksjonen ved HiOA vedrørende muligheten for.netserver. Vi forklarte vårt prosjekt for han og vårt behov. Vi viste han systemet for dokumentbehandling som vi har begynt å utvikle, og forklarte for han vårt behov for hosting. Han syntes prosjektet virket spennende, men hadde betenkeligheter på om dette var noe de kunne fasilitere med. Møtet endte med at han fortalte oss at han må diskutere dette med en annen IT-sjef ved høgskolen, og kalle oss inn til nytt møte i løpet av neste uke. Studentparlamentet - HiOA 163

164 Gruppemøte Dato I dag gikk vi gjennom hva vi har gjort hver for oss i henhold til våre ansvarsområder. Hotan viste frem skissene for hele nettstedet som han hadde laget i powerpoint. Han har i tillegg satt seg inn i Wordpress som er utviklerverktøyet Studentparlamentet ønsker at vi skal benytte, og sier at han er klar til å implementere skissene i Wordpress så raskt han får tommelen opp av de andre gruppemedlemmene, og Studentparlamentet. Arlen viste frem systemet for dokumentbehandling som han har hatt hovedansvaret for å utvikle. Det så veldig profesjonelt ut, og vi gleder oss å vise det frem for Studentparlamentet. Mohamed viste frem sine skisser for talerlistesystemet, og sparret litt med Arlen med tanke på faktisk gjennomføring og funksjonalitet. På slutten av møtet kunne vi være enige med at vi er på god vei mot et godt resultat. Nytt møte med IT-seksjonen Dato Under dagens møte var den andre IT-sjefen som ble referert til under forrige møte også tilstede. Vi presenterte vårt prosjekt og behov på nytt, og ble fortalt at de ikke har kapasitet til å administrere vedlikeholdet av serveren, men at de allikevel kan fasilitere for dette dersom Studentparlamentet påtar seg dette ansvaret. Representanten fra Studentparlamentet som også var til stede under møtet, sa at han skulle ta dette videre og diskutere det med de andre i Studentparlamentets arbeidsutvalg. Statusmøte med Studentparlamentet Dato Møtet i dag begynte med at vi fikk beskjed om at Studentparlamentet skal påta seg ansvaret for administreringen av serveren som IT-seksjonen kan fikse for oss. Etter at dette ble avklart viste vi frem dokumentbehandlingssystemet som vi har utviklet. Vi demonstrerte hvordan det fungerte, og spurte de hva de syntes om det. Einar fra Studentparlamentet var meget entusiastisk og syntes det så bra ut. De kom imidlertid med innspill til ting de ønsket noe annerledes for å passe deres behov optimalt. Tiden gikk raskt, og vi rakk ikke å vise de skissene til nettstedet vi hadde laget. Vi avtalte derfor å møtes til nytt møte neste uke. Studentparlamentet - HiOA 164

165 Statusmøte #2 med Studentparlamentet Dato I dag viste vi frem skissene til nettstedet. Vi hadde laget skissene med utgangspunkt i analysen fra spørreundersøkelsen, og trodde vi muligens skulle få bedre respons. De likte informasjonsarkitekturen, hvor vi hadde delt inn i tre primærbrukergrupper; studenter, tillitsvalgte og representanter. De var enige med at dette ville gjøre det enklere for studentene å finne relevant informasjon. Selve designet til nettstedet falt imidlertid ikke helt i smak da de syntes den virket for rotete, og med for mange farger. De fortalte oss at de heller ønsker et enklere og renere design. Vi fortalte de at dette kan vi fikse relativt greit da det kun er snakk om layout, og ikke arkitekturen som er en mer omfattende jobb. Gruppemøtet Dato I dag diskuterte vi layouten til nettstedet, og tilbakemeldingene vi hadde fått fra Studentparlamentet. Vi ble enige om de nye endringene som måtte til, og Hotan følte at han nå kunne nok Wordpress til å sette i gang med selve implementeringen. Dette drev han med i resten av møtet, mens Arlen og Mohamed fokuserte på talerlistesystemet og endringene til systemet for dokumentbehandling. Gruppemøtet Dato I dag har vi sittet sammen og arbeidet med prosjektet. Vi begynte møtet med å oppdatere hverandre på hva vi hadde gjort siden sist. Hotan som hadde begynt å utvikle nettsiden i Wordpress viste sitt forslag til designlayout. Da dette var svært sentralt brukte vi en del tid på å diskutere om valget av theme i Wordpress var det beste for oss eller om det fantes bedre varianter som vi kunne velge. Arlen kom med et godt forslag som resten av gruppen like svært godt. Hotan brukte resten av møtet til å implementere denne endringen i Wordpress, mens Arlen og Mohamed jobbet med detaljene i systemet for dokumentbehandling som oppdragsgiver ønsket endringer på. På slutten av møtet bestemte vi at vi måtte begynne å skrive rapporten, og delte følgelig inn deler som vi kunne arbeide med i Google Drive frem til neste møte. Studentparlamentet - HiOA 165

166 Gruppemøtet Dato I dag viste Hotan frem det han hadde gjort med nettsiden siden sist. Utviklingen hadde kommet svært lang da alt av innhold var på plass, og funksjonalitet lagt til. Det som gjenstod var formateringsarbeid da det flere plugin s i Wordpress som ikke hadde lagt seg der han ønsket. Arlen sa at han kunne se på det etter møtet ettersom vi hadde blitt enige om å jobbe med rapporten i dag. Gruppemøtet Dato I dag viste Arlen frem det han hadde formatert i Wordpress. Disse små endringene løftet inntrykket betraktelig og det ble bestemt at nettsiden var ferdig, og klar til brukertesting så snart de andre utviklingsprosjektene var ferdigstilte. Arlen og Mohamed brukte resten av dagen til å jobbe med dette, mens Hotan skrev på rapporten. Gruppemøtet Dato I dag begynte vi møtet med å diskutere møtet vi skal ha med oppdragsgiver i morgen vedrørende fremdriften av prosjektet. Der skal vi diskutere status for de ulike modulene vi utvikler, brukertestingen vi planlegger å gjennomføre på fredag, samt leveranse og implementering. Vi kom frem til at vi ønsker å gjennomføre tenk-høy-brukertesting ( think aloud method ) med lukkede testoppgaver. Vi utformet en rekke oppgaver vi tenker å benytte på fredag, og ble enige om å vise disse til oppdragsgiver i morgen for tilbakemelding. Deretter diskuterte vi hva hadde skrevet i sluttrapporten frem til nå, og fordelte oppgaver som må gjøres fremover. Resten av møtet gikk med til å jobbe med talerlistesystemet da vi opplevde problemer med å kontakte serveren fra prosjektet vårt. Etter endel prøving og feiling i Angular løste vi problemet, og er følgelig ett steg nærmere ferdigstillelse. I morgen har vi nytt møte med veileder hvor vi skal fortelle hvor langt vi har kommet og spørre om råd i forbindelse med arbeidet med sluttrapporten. Studentparlamentet - HiOA 166

167 Møte med veileder Dato I dag har vi hatt møte med veileder hvor vi har gitt en oppdatering på hvordan vi ligger ann. Vi fikk en del tips som kan komme godt med i innspurten. Veileder ba oss sende et utkast av det vi har til nå slik at han kan lese gjennom og gi oss tilbakemelding. Statusmøte med oppdragsgiver Dato I dag har vi også oppdatert oppdragsgiver på de ulike modulene vi har utviklet, og diskutert brukertestingen vi skal ha fredag og tenk-høyt-testen vi planlegger. Oppdragsgiver var svært positiv til det vi hadde laget. Vedrørende brukertestingen diskuterte vi om tenk-høyt var det beste valget da dette er svært tidkrevende. Vi kom frem til at et fokusgruppeintervju er bedre da man får tilbakemeldinger fra flere på kortere tid. Vi gikk gjennom hvilke temaer som vi burde ta opp, og bestemte oss å utforme opplegget på neste gruppemøte. Gruppemøte Dato I dag har vi jobbet med fokusgruppeintervjuet vi skal ha på fredag. Vi laget samtykkeskjemaer til deltakerne og printet ut disse. Vi planla hvordan vi skulle gjennomføre det og konkretiserte temaene vi ønsket at de skulle gjennomføre. For å skape en god start og stemning på brukertestingen ble det også bestemt at vi skulle kjøpe inn juice og muffins til deltakerne. Vi bestemte oss også om hvem som skulle være ordstyrer. Brukertesting Dato I dag har vi gjennomført vårt fokusgruppeintervju. Av de seks deltakerne som hadde sagt at de skulle komme så kom det fire personer. Disse ble ønsket velkommen med drikke og muffins, og presentert med et samtykkeskjema som de signerte. Vi opplyste også at vi kom til å benytte lydopptak, men at dette ville bli slettet så snart vi hadde notert informasjonen fra møtet. Deretter begynte vi brukertestingen med opplegget vi hadde laget på forhånd. Fokusgruppeintervjuet varte rett i underkant av to timer og ga oss mange verdifulle tilbakemeldinger som vi bestemte oss for å gjøre noe med etter møtet. En av disse tilbakemeldingene fikk ut på at bilde-ikonet vårt for tospråklighet ikke var tilstrekkelig intuitivt. Etter møte bestemte vi oss for å gå gjennom lydopptaket og notere ting som var av verdi for oss. Notatene vedrørende justeringer av modulene ble delegert mellom Studentparlamentet - HiOA 167

168 gruppemedlemmene for videre implementering frem til neste møte. Det ble også bestemt å jobbe videre med sluttrapporten frem til neste møte. Gruppemøte Dato I dag gikk vi gjennom de siste endringene vi hadde gjort på modulene etter fokusgruppeintervjuet. Vi kom frem til at vi var ferdige, og at vi kunne fokusere på ferdigstilling av sluttrapporten. Vi begynte arbeidet med formatering av sluttrapporten, ettersom dette ofte er mye mer tidkrevende enn antatt. Vi overførte det vi hadde skrevet i fellesdokumentet i Google Drive til et Microsoft Word dokument. Der la vi til kildene vi hadde brukt, leste igjennom rapporten og gjorde endringer der det var nødvendig. Vi satt oss som mål å levere prosjektet senest 23 mai, dvs en dag før fristen, da ett av gruppemedlemmene har eksamen på innleveringsdagen. Ferdigstilling av prosjektet og levering Dato I dag leste vi over rapporten en gang til, rettet skrivefeil og utføre de siste justeringene. Deretter leverte vi. Studentparlamentet - HiOA 168

169 Datainnsamling Analyse av spørreundersøkelsen Spørreundersøkelsen som vi sendte ut elektronisk ved hjelp av Einar fra Studentparlamentet ble utformet i Google Forms og kan ses i lenken under: NQmZw/edit Basert på analyser av svarene i spørreundersøkelsen har vi trukket følgende konklusjoner: Av de som svarte på brukerundersøkelsen, så svarte to tredjedeler at hensikten med besøket til Studentparlaments sider var å finne og lese sakspapirer, samt politiske dokumenter og informasjon knyttet til deres verv i Studentparlamentet. Resten oppga at de besøker nettstedet for å lære om hva Studentparlamentet driver med, finne lister over tillitsvalgte, finne ut hvordan de kan engasjere seg, og lese nyttig informasjon. Over halvparten av de spurte oppga at de fant frem til ønsket informasjon, mens en fjerdedel ikke fant frem i det hele tatt. 18% prosent fant frem til slutt. Majoriteten synes det imidlertid er vanskelig å finne frem til ønsket informasjon. Angående hva folk synes om designet til nettstedet så oppga 82% at de syntes det var «midt på treet». 12% gav nettstedet dårligste karakter, kun 6% gav nest høyeste karakter, mens ingen ga høyeste «score». Basert på tilbakemeldingene om hva som var bra og/eller dårlig med nettstedet så gikk de fleste av kommentarene ut på at nettsidens design var kjedelig og utdatert. Mange kommenterte også at selv om det finnes mye nyttig informasjon på nettstedet så er det vanskelig å finne frem grunnet for mange underkategorier og nødvendige klikk som må utføres. Det ble også nevnt at enkelte sider ikke var oppdatert og at ikke alt fungerte. Noen få synes imidlertid at nettstedet er oversiktlig, enkel å forstå og har grei brukervennlighet. Angående forslag til forbedring av nettstedet så kommenterte mange at de ønsker et nettsted som er enklere å navigere i, med en mer oversiktlig menystruktur og bedre plassutnyttelse. Andre kommentarer gikk på at nettstedet burde være mer fargerikt og visuelt tiltalende. Det svært mange foreslo omhandlet imidlertid hvordan Studentparlamentet kan formidle Studentparlamentet - HiOA 169

170 informasjon på en bedre måte enn de gjør i dag. En par av forslagene gikk ut på at man burde være flinkere til å formidle hva Studentparlamentet står for og driver med slik at man kan bli bedre kjent de. Andre kommenterte at man burde ha en bedre oversikt over alle verv, og tydeliggjøre hvordan studenter kan engasjere seg. Det ble også nevnt at man burde fjerne utdatert informasjon og lage et samlet arkiv for eldre dokumenter. Data ifra brukerundersøkelsen: Vanskelig å finne: - Finne saksdokumenter - Sakspapirer - Liste over tillitsvalgte - Informasjon om Verv og sakspapirer - Politiske og organisatoriske styringsdokumenter - Sakspapirer fra AU-møter Siden bør deles inn i "for studenter", "for tillitsvalgte" og "for representanter". Med nyttig informasjon for de ulike målgruppene Intervju med Ordstyrer Hva består ordstyrerjobben av og hvilke oppgaver har man som ordstyrer? Vi er som regel to ordstyrere og en referent. Referenten har ikke noe med ordstyring å gjøre. Hun bare skriver ned hva som skjer på møte. Det er kun en ordstyrer som er aktiv, mens den andre bare sitter der og passer på. Disse rollene bytter de på under møte. Halve møtet hver. Ordstyrerjobben består i å lede møte innenfor de rammene og sakene som er satt. Møte er satt ut i fra en forretningsorden som man vet er en gang i året. Det er regler for hvordan møter skal foregå, og det er ordstyrers rolle å sørge for at man holder seg til sak, holder seg til tidsplan og de type tingene. Og at folk forholder seg til folkeskikk. Hvor mye og hva gjør ordstyrerne for å forberede seg før møtene? Studentparlamentet - HiOA 170

171 Vi pleier å gå gjennom sakspapirene på forhånd slik at vi vet hva som kommer, også snakker vi med de som har forberedt sakspapirene og med kontrollkomiteen hvis vi vet at vi kan komme til å trenge mer tid, hvor de eventuelt kan flytte ting, hvor de kan hente tid i fra. Det er det vi planlegger mest i forkant av møtene. Hvilke utfordringer møter man / kan man møte på som ordstyrer? Det kommer an på hva slags saker som kommer. De største problemene er hvis det kommer noe som er i grenseland for hva som er innenfor vedtektene eller forretningsorden som de ikke vet helt reglementet rundt. Men det er derfor vi har kontrollkomiten i tillegg til ordstyrerne som kan komme og dobbeltsjekke hva vi gjør og hva parlamentet foretar seg. Men ordstyrermessig så er det ganske rett frem hva vi gjør, så det i tilfeller hvor mange tegner seg til innlegg/replikk samtidig, der det er mye aktivitet samtidig og folk ikke helt forholder seg til at vi ønsker å ha det rolig i salen Hvordan løser man disse utfordringene i dag? Vi må prøve å ta det så rolig som mulig. Det skjer ikke noe før vi sier at noe skjer. Så hvis vi sier at «nå må alt falle til ro» så gjør det det. Under møtet er det vi som har høyeste autoritet. Hva er arbeidsprosessen for en ordstyrer når man skal styre et møte (tidlinje)? Det kommer et forslag til tidsplan fra innstillende organ til møtet. I det tilfellet her er det arbeidsutvalget. Dette sendes ut et par uker i forkant av hvert møte. Der får både ordstyrere og alle som skal være involvert i møte denne tidsplanen som er et forslag. Også kan denne eventuelt endres på før eller i løpet av møte. Hva og hvem er man avhengig av når man skal styre ordet (personer, systemer, ressurser)? Sånn egentlig er vi ikke avhengig av noen andre enn oss selv. Men vi er avhengige at det er sakspapirer på plass, og at det er nok mennesker i parlamentet slik at vi får gjennomført sakene på den måten den skal. Men vi kan gjøre alt vi som sitter der, men vi er veldig glad for at vi har dette «roisalen»-digitalsystemet vi kan bruke for å få litt bedre kontroll. Hadde vi ikke hatt det hadde vi sittet og ført alt for hånd. Eller vi kunne ha overført det på PC selvfølgelig. Men det at vi har muligheten til å få det opp på storskjerm sånn at alle ser hva som skjer i salen er veldig praktisk. Studentparlamentet - HiOA 171

172 Ro i salen: Hvordan bruker ordstyrerne systemet roisalen.no Det er et ganske enkelt system. Mens vi gjør forberedelser så vet vi sånn ca hvem som kommer på møtene i og med at det er påmelding. Så vi pleier å legge inn alle navnene i forkant av de vi vet kommer og har det klart, og det som eventuelt endrer seg, endrer vi på møte. Men det er ikke et problem. Stort sett er det den som styrer ordet i den delen av møte som sitter med kontrollen over «roisalen» der man kan skrive innlegg og endre overskrift etter hvilken sak vi er på, ta replikker, fjerne replikker, flytte folk etter hva som trengs. Hva er de fornøyd med i roisalen og hva er utfordringene ved «Roisalen» Jeg synes Roisalen er helt kurant siden det er enkelt. Men ett problem er at hvem som helst kan «highjacke» det i og med at det ligger åpent på nettet. Hadde det vært så lite som en liten sikkerhetskode så hadde det gjort at ordstyrer hadde litt større sikkerhet. De som sitter i salen kan gå inn og endre på listen. Men det er ingen av de som vet hvordan de gjør det så det går fint sånn stort sett. Ellers er mye basert på innlegg eller replikk så er det veldig enkelt sånn som det ligger nå. Det er også en klokke i det systemet, så den som styrer har alltid den foran seg i forhold til taletid. Det er veldig fint. Hva er det roisalen mangler? Noe som kunne gjort det lettere for oss, ettersom det er satte tidsrammer for hver sak, hadde vært om man hadde en klokke i tillegg til den vanlige klokken som sier hvor mye tid det er igjen av behandlingen av saken slik at man har bedre oversikt. De som er på talerstolen aner ikke hvor mye tid de har igjen ettersom det er kun ordstyrerne som har denne klokken. Det hadde vært verdifullt for talerne om de kunnet se en klokke slik at de kan passe tiden bedre, stresse mindre og slippe å bli ferdige før tiden i frykt av å gå over tiden. Med andre ord så mener jeg to klokker. En som Hvordan prioriterer dere om det er flere enn to som ønsker å melde seg til replikk? Stort sett tar vi de to første vi ser, beklager til resten, og ber de tegne seg til innlegg i stedet. Enten det eller så spør vi om noen kan trekke seg dersom noen allerede har snakket mye Studentparlamentet - HiOA 172

173 tidligere. Av og til kan vi bruke skjønn og slippe til de som er litt for sent ute hvis de andre i salen ikke får det med seg og de var først allerede har snakket mye. Med tanke på ideen om 2 klokker så tenker jeg en klokke som nullstiller seg hver gang noen snakker, og en klokke som viser hvor mye tid man har per sak. Akkurat nå så endrer dere manuelt sakene som skjer, også forandrer saksoversikten seg. Hadde det vært en ide om dere skrev inn alle sakene først og fikk noe statistikk på hver sak? Det hadde vært veldig enkelt for da kan vi bare hoppe videre til neste sak bare automatisk i systemet istedenfor å drive å endre. Å ha alt på forhånd hadde vært «smooth». Stemmer det at ordstyrerne ikke har så mye å gjøre med de som melder seg til sak på forhånd før møtene? Ordstyrerne er bare ansvarlig for det som skjer på selve møtet. På møtene er vi avhengige av to PC er. En å styre ordet fra og en som screener det. En stasjonær PC brukes til å screene, også styrer jeg fra min Mac. Det fungerer helt greit. Har ordstyrerne en vare? Hva skjer om en/flere er syk? Vi er en base på 4-5 stk som vi prøver å rullere på. Så vi har flere å spille på. Studentparlamentet - HiOA 173

174 Low-fidelity prototype av nettstedet Forside Menystruktur til undersider Studentparlamentet - HiOA 174

175 High-fidelity prototype av nettstedet Bilde 1: Forside Studentparlamentet - HiOA 175

176 Bilde 2: Om oss -> Studentparlamentet Studentparlamentet - HiOA 176

177 Bilde 3: Om oss -> Arbeidsutvalget og sekretariatet Studentparlamentet - HiOA 177

178 Bilde 4: Om oss -> Representantene Studentparlamentet - HiOA 178

179 Bilde 5: For studenter -> Studentdemokratiet. Studentparlamentet - HiOA 179

180 Bilde 6: For studenter -> Engasjer deg. Bilde 7: For studenter -> Engasjer deg -> Råd og utvalg. Studentparlamentet - HiOA 180

181 Bilde 8: For studenter -> Verv Studentparlamentet - HiOA 181

182 Bilde 9: For studenter -> Still til valg Studentparlamentet - HiOA 182

183 Bilde 10: For studenter -> Studentforeninger Studentparlamentet - HiOA 183

184 Bilde 11: For studenter -> International students Studentparlamentet - HiOA 184

185 Bilde 12: For tillitsvalgte -> Tillitsvalgt. Bilde 13: For tillitsvalgte -> Verktøykassa. Studentparlamentet - HiOA 185

186 Bilde 14: Dokumenter -> Studentparlamentets dokumenter. Bilde 15: Dokumenter -> Styringsdokumenter. Studentparlamentet - HiOA 186

187 Bilde 16: Dokumenter -> Politiske dokumenter. Studentparlamentet - HiOA 187

188 Bilde 17: Dokumenter -> Sakspapirer, protokoller og årsrapporter. Studentparlamentet - HiOA 188

189 Bilde 18: Dokumenter -> Documents in english. Studentparlamentet - HiOA 189

190 Samtykkeskjema for intervju med ordstyrer Det utfylte skjemaet ble ikke lagt ved av hensyn til anonymitet og personvern. Studentparlamentet - HiOA 190