BACHELORPROSJEKT. 24. mai Shifter - for Samfunnet Bislett

Transkript

1 PROSJEKTNR: TILGJENGELIGHET: Studieprogram: Anvendt datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo BACHELORPROSJEKT PROSJEKTTITTEL Shifter - for Samfunnet Bislett PROSJEKTDELTAGERE (ALFABETISK) Einar Belck-Olsen s198524, Roger Bløtekjær Johannessen s186571, Helene Juterud s198541, Halvor Rønneseth s172589, Maja Langsrud Sæterstøen s OPPDRAGSGIVER Samfunnet Bislet Telefon: Telefaks: DATO 24. mai 2016 ANTALL SIDER (MED VEDLEGG) 146 INTERN VEILEDER Kirsten Ribu KONTAKTPERSON Sindre Säfvenbom SAMMENDRAG Samfunnet Bislet er en studentforening/pub som er drevet av frivillig arbeid utført av studenter og for studenter, hovedsakelig fra Høgskolen i Oslo og Akershus. Bestillingen var å utvikle et sikkert, intuitivt og brukervennlig system som tillater Samfunnet Bislet å enkelt organisere sine frivillige og å bemanne vakter. Oppgaven tar dermed for seg utviklingen av turnussystemet Shifter - fra idé til ferdig produkt. TRE STIKKORD Systemutvikling, Universell utforming, Brukervennlighet

2 Shifter - for Samfunnet Bislett 1 INNHOLD Forord Om prosjektet Problemstilling Oppdragsgiver Prosjektgruppen Bakgrunn Prosjektstyring Milepælsplan Arbeids og ansvarsfordeling Risikoplanlegging Metodikk Intervju Prototyping Brukertesting Programmering (teknologi og struktur) Programmeringsspråk Standarder og retningslinjer Feilhåndtering Valg gjort i programmeringen Kravspesifikasjon Mål for systemet Funksjonelle krav Prioritert funksjonalitet Ønsket funksjonalitet Ikke-funksjonelle krav Brukervennlighet Universell utforming Tilgjengelighet Estetiske krav Effektivitet Sikkerhet Leveransekrav Endelig leveranse Implementasjonskrav Produktrapport... 18

3 Shifter - for Samfunnet Bislett Web-applikasjon Systemoversikt Modul: Backend Modul: Vaktliste Modul: Profil Modul: Medlemsregister Modul: Dokumenter Modul: Meldinger og avvik Modul: Statistikk Modul: Barbruker Android-applikasjon Applikasjonens innhold Beskrivelse av applikasjonens aktiviteter Valg gjort i utviklingen Applikasjonens programflyt Brukerveiledning Brukerveiledning for frivillige Registrering av brukerkonto og innlogging Landingsside Profilside Vaktliste Dokumenter Avviksmeldinger Frivilligpris-appen Brukerveiledning Barbruker Logg inn Prissjekk Vaktoversikt Avviksmelding Brukerveiledning for administrator Administrere brukere Administrere vaktlisten Administrere dokumenter Administrere meldinger fra styret Behandle avviksmeldinger Statistikk Vedlikehold av systemet... 90

4 Shifter - for Samfunnet Bislett Roller i systemet Spesielle statuser Prosessrapport Forprosjekt Utvikling av ny Kravspesifikasjon Bakgrunn for valg av teknologi i backend Designvalg Facebook-innlogging Frontend-design Fra skisser til prototyper Produksjon Utfordringer ved utvikling av backend Testing Leveranse Evaluering Testrapport Konklusjon Litteratur Figurliste Appendix A: Opprinnelig kravspesifikasjon Oppgaven Konkrete mål for oppgaven vil være: Teknologi Om oppdragsgiver/samfunnet Bislet Appendix B: Kontrakt mellom Prosjektgruppen og Samfunnet Bislet Appendix C: Evaluering fra Oppdragsgiver Appendix D: Intervju med Styret Intervju Guide Generelt: Spørsmål om utførelse av jobb: Spørsmål om arrangement og vakter: Spørsmål om dokumenter og informasjon: Temaer: Rekkefølge: Samtykkeskjema for intervju Transskript Styreleder Transkript Frivilligansvarlig og Styreleder

5 Shifter - for Samfunnet Bislett Appendix E: Diagrammer UseCase-diagram Sekvensdiagram: dbdeleteevent() Appendix F: Eksempel på prototyper Papirprototype Registrer bruker High fidelity prototype Registrer arrangement

6 Shifter - for Samfunnet Bislett 5 FORORD Denne oppgaven er skrevet som en avsluttende del av ett 3-årig bachelorstudie i Anvendt Datateknologi ved Høgskolen i Oslo og Akershus. Oppgaven tar for seg utviklingen av Shifter. Shifter er ett turnussystem, som har som hensikt å holde oversikt over medlemmer og gi medlemmene muligheten til å sette seg opp på vakter. Shifter har blitt vårt hjertebarn, og vi er veldig stolte av hva vi har levert. Vi vil gjerne takke koffein for å ha gjort dette prosjektet mulig, samt Kirsten Ribu for veiledning gjennom prosjektets gang.

7 Shifter - for Samfunnet Bislett 6 1. OM PROSJEKTET 1.1. PROBLEMSTILLING Samfunnet Bislet har i lang tid benyttet seg av plattformer som Facebook og Google for å organisere all aktivitet av de frivillige. Dette arbeidet omfatter blant annet oppføring av vakter på arrangementer og i baren, varebeholdning, samt organisering av arrangementer som holdes i lokalene. Da Samfunnet Bislet velger nytt styret hvert år, ønskes det ett system for organisering og opparbeiding av infrastruktur, slik at drift og styreskifte lettere kan utføres. Problemstillingen vår som utviklere blir derfor: Å lage et system som Samfunnet Bislet kan bruke for å lette arbeidet med å holde orden på arrangementer og frivillige. Motivasjonen bak problemstillingen og denne oppgaven er at vi som gruppe kan bruke kunnskapen vi har tilegnet oss fra studiet til å planlegge, utforme og lage et system for en arbeidsgiver som har forventninger til produktet som skal lages, og som ønsker å ta i bruk produktet. Denne settingen kan være ganske lik den vi kommer til å møte ute i arbeidslivet senere OPPDRAGSGIVER Samfunnet Bislet er en studentforening ved Høgskolen i Oslo og Akershus (HiOA) som driver en studentpub på HiOA Campus Pilestredet. Samfunnet Bislet ble stiftet 8. September 2011 og er en studentforening under Studentsamskipnaden i Oslo (SiO) og har i dag om lag 140 medlemmer (antall medlemmer av Facebookgruppen: Frivillige Samfunnet Bislet ). Foreningen omsetter for omtrent 2.2 millioner kroner årlig. Foreningen er organisert med et styre som er ansvarlig for driften og økonomien i foreningen (Feil! Fant ikke referansekilden.). Dette styret velges av medlemmene (ofte omtalt som frivillige) i foreningen på årsmøtet. Årsmøtet består av de frivillige som har jobbet mer enn et visst antall vakter (8+) i løpet av et år. Studentpuben er åpen tre dager i uken fra på onsdager og torsdager og på fredager. De frivillige jobber i baren og på scene i forbindelse med konserter og andre forestillinger. Åpningstiden deles opp i 2 vaktskift på omtrent 4 timer og med cirka 4 frivillige på hvert skift. Dette utgjør 24 vakter som skal bemannes hver uke. Som nevnt tidligere er antallet medlemmer av foreningen basert på medlemmer i en Facebook-gruppe. Dette er per dags dato den eneste oversikten Samfunnet Bislet har over sine medlemmer. Denne Facebook-gruppen er også verktøyet som frivilligansvarlig bruker til å kontakte frivillige til å jobbe vakter i baren. Styret Leder Nestleder Økonomiansvarlig Teknisk ansvarlig Utleie- og bookingansvarlig Frivilligansvarlig Innkjøpsansvarlig PR- og eventansvarlig Ordinært styremedlem Ordinært styremedlem

8 Shifter - for Samfunnet Bislett 7 Samfunnet Bislet sin bestilling i henhold til den opprinnelige kravspesifikasjonen:... ett internsystem for administrasjon av foreningens medlemmer, vakter og arrangementer samt distribusjon av viktige dokumenter og informasjon til de frivillige. Da kravspesifikasjonen fra oppdragsgiver var lite spesifikk på hva systemet skulle utføre og kan bedre beskrives som en prosjekt-ide med generell ønsker til systemet (se Appendix A: Opprinnelig kravspesifikasjon), ble det derfor nødvendig å utforme en ny og fullstendig kravspesifikasjon av systemet (se kapittel 3) basert på intervjuer med styremedlemmer. Arbeidet med å utvikle denne kravspesifikasjonen er beskrevet i prosessrapporten (se kapittel 0) PROSJEKTGRUPPEN Prosjektgruppen består av fem 3. års-studenter ved Bachelorprogrammet Anvendt Datateknologi. Gjennom de 5 foregående semester har gruppen samlet tilegnet seg faglig kompetanse innen fagområdene systemutvikling, universell utforming, informasjonsarkitektur, brukertesting og programmering. Flere av gruppens medlemmer har deltidsjobber innen IT ved siden av studiene BAKGRUNN Prosjektet med å utvikle Shifter har bestått i å sette seg inn i arbeidet styret til Samfunnet Bislet gjør med å drive studentpub, spesielt det arbeidet som utføres av Frivilligansvarlig i forbindelse med bemanning av baren i åpningstiden. I første omgang har arbeidet bestått i å innhente informasjon om hva de konkrete arbeidsoppgavene består i å se på hvordan dette kan omsettes til et IT-system.

9 Shifter - for Samfunnet Bislett PROSJEKTSTYRING MILEPÆLSPLAN ARBEIDS OG ANSVARSFORDELING Ansvarsområde Dokumentasjon Frontend Backend Design Arkitektur Prototyping Brukertesting Systemtesting Android-applikasjon Hovedansvar Einar Helene Maja Helene Roger Einar Einar Maja Halvor

10 Shifter - for Samfunnet Bislett RISIKOPLANLEGGING Risiko Sannsynlighet Konsekvens Strategi Sykefravær > 3 dager Middels Middels Delegere oppgaver som kan gjøres hjemme. Lengre sykefravær Lav Høy Resterende medlemmer må prøve å dekke arbeidsområdene best mulig seg imellom. Tekniske problemer Middels Stor Finne alternative løsninger på teknologi. Eventuelt vurdere om man skal gå vekk fra påtenkt løsning. Utviklingen blir forsinket Uenighet om beslutninger i prosjektet Middels-høy Middels Gruppen vil fokusere på å utvikle de viktigste funksjonene i systemet først, og deretter det som er ønsket men ikke påkrevd. Høy Stor Har konsekvenser for hva som blir gjort videre i prosjektet. Viktig å holde diskusjonen så faglig som mulig, og unngå at samtalene glir ut. Viktig å komme til enighet på et problem før man går videre til neste for å unngå uløste problemer ved en senere anledning. Frafall fra prosjektet Lav Stor Resterende medlemmer må prøve å dekke arbeidsområdene best mulig seg imellom. Eventuelt vurdere å begrense prosjektet. Kommunikasjons/sa marbeidsproblemer med oppdragsgiver Lokalene (kontor) kan ikke benyttes Middels Middels Oppsøke kontakt på andre måter enn kun epost Høy Middels Finne et annet sted å arbeide.

11 Shifter - for Samfunnet Bislett METODIKK I denne delen vil vi gjøre rede for de ulike metodene vi har benyttet i prosjektarbeidet. Kvalitative og kvantitative forskningsmetoder som intervju og spørreundersøkelse har blitt benyttet for å kunne kartlegge behov så grundig som mulig. Dette kan gjøre at systemets innhold og funksjonalitet oppfyller mest mulig av de forventningene oppdragsgiver måtte ha. I tillegg til kravspesifikasjonen har relevant litteratur for forskningsmetoder blitt benyttet for å forme intervjuene og spørreundersøkelsen. Ifølge Dalland (2007) skiller man mellom kvalitative og kvantitative metoder. Dalland (2007) beskriver kvalitativ metode som en metode som sikter etter å finne data som ikke kan settes i skjema eller omskrives til tall. Kvantitative metoder kan være i form av spørreundersøkelser, og denne dataen er målbar i prosenter og kan sammenlignes i større mengder. Det falt naturlig for oss å benytte intervjuer med tanke på at gruppen mennesker vi skulle hente informasjon fra i starten før utviklingsfasen ikke var stor nok til at spørreundersøkelse var hensiktsmessig INTERVJU I starten av planleggingen ble det utført intervjuer av noen av styrets medlemmer for å kunne kartlegge ønsker og tanker de forskjellige medlemmene har. I følge Sandnes (2011, s. 240) kan intervjuer brukes i starten av et prosjekt for å kunne kartlegge eksisterende praksis, forventninger til prosjektet, og ønsker til hvordan systemet skal fungere. Sandnes (2011) sier også at intervjuer kan være åpne eller fokuserte. Et åpent intervju går bredt ut for å finne hva som er blir betraktet som viktig. Et fokusert intervju tar for seg et begrenset emne for å kartlegge hva intervjuobjektene tenker som det aktuelle emnet (Sandnes, 2011). Intervjuet av styret ble gjennomført på et tidlig tidspunkt i utviklingen, og det kan dermed karakteriseres som et åpent intervju siden intensjonen med intervjuet var å hente ut relevant informasjon fra styremedlemmene. I forbindelse med intervjuene ble det utarbeidet en intervjuguide. Denne ble benyttet for å forhindre at intervjuene skulle spore av. Spørsmålene ble lagt opp slik at intervjuobjektet først ble spurt om hva de het, og hvilken stilling de hadde i styret. Sandnes (2011, s. 242) kaller denne innledende fasen for "bli-kjent-fasen". Denne fasen har som mål å skape en god relasjon mellom intervjuer og intervjuobjekt PROTOTYPING En prototype kan defineres som "en konkretisert dokumentasjon på vår forståelse av brukerens behov og våre ideer til hvordan brukergrensesnittet skal utformes for å dekke disse behovene" (Sandnes, 2011, s. 281). En prototype kan bli utformet når behovene har blitt kartlagt og skisser har blitt utformet. I følge Buxon (2007) er ikke skisser det samme som prototype selv om de begge er instanser av designkonseptet. Skisser er i motsetning til prototyper en kjapp tegning av en tilfeldig ide som dukker opp under diskusjoner. I følge Buxon (2007) kan skisser være kjappe, billige, forkastelige og minimalistiske. Skissene lages dermed ikke til å bli testes på brukere, men for å visuelt vise om en ide er brukbar eller ikke (Sandnes, 2011).

12 Shifter - for Samfunnet Bislett 11 I prosjektarbeidet ble det utformet skisser på tavle under diskusjon over hvordan systemet skulle se ut. Ut fra disse skissene ble det utformet papirprototyper for å kunne teste ideene på brukerne. Papirprototype er en low-fidelity-prototype, og denne typen prototype krever ifølge Sandnes (2011, s. 283) ikke mye tid å utforme, samt at den ikke er kostbar å produsere. Det ble utført brukertest med bruk av papirprototyper for å kunne gi et bedre grunnlag for utforming av en high-fidelity prototype. En high-fidelity-prototype er ifølge Sandnes (2011, s. 283) en mer avansert prototype enn en papirprototype. High-fidelity-prototypene ble laget i Axure og NinjaMock. Dette er programvare som har som mål å gjøre utformingen av funksjonelle prototyper lettere. Det kan diskuteres om bruken av disse kan gjøre at man kun kan teste ved bruk av disse prototypene, da programmene gjør det lett å gjøre endringer i eksisterende prototyper BRUKERTESTING Det ble utført flere runder med brukertesting, med papirprototyper, klikkbare prototyper og etterhvert med tidlige versjoner av systemet. Brukertestene ble gjennomført med en testleder, en observatør. Under testingen av papirprototypene var det nødvendig med et medlem som fungerte som datamaskin. I prosjektet har det blitt lagt vekt på formativ evaluering, som ifølge Sandnes (2011, s. 306) er testing gjennom prosjektet. Ved å gjennomføre tester på ulike stadier har det vært lett å utføre endringer, siden disse endringene igjen da kan testes på et senere tidspunkt. Prosjektet vil også inneholde en summativ evaluering, men denne evalueringen vil ikke bi gjort før systemet er i en beta-tilstand, altså versjonen før utlevering. Brukertestene har forankring i de scenarioene brukerne kan komme ut for i et ferdig produkt. I følge Sandnes (2011) gir en godt planlagt brukertest økt profesjonalitet og det vil være mulig å sammenligne to ulike brukertester mot hverandre. Dette kan bidra til at det blir lettere å finne ut hvordan de forskjellige brukerne løser oppgaven som blir presentert. I følge Sandnes (2011) er det en fordel å forberede seg godt før brukertestingen blir gjennomført, da dette hjelper på den felles forståelsen av hendelsesforløpet testen har. I forbindelse med alpha-testen som ble lagt ut på nett ble det vedlagt en kort spørreundersøkelse til slutt som testobjektene kunne svare på. Spørreundersøkelsen er en kvantitativ metode, og passer ifølge Sandnes (2011) best til å samle inn informasjon fra større mengder av mennesker. Spørreundersøkelsen ble laget som et ledd i utviklingen for å kartlegge feil og mangler ved en brukertest på brukerne som skal benytte seg av systemet PROGRAMMERING (TEKNOLOGI OG STRUKTUR) I denne delen vil det bli gjort rede for programmeringsspråkene brukt i utviklingen, samt retningslinjer og standarder for disse PROGRAMMERINGSSPRÅK Systemet består i all hovedsak av Hyper Text Markup Language (HTML), CSS (Cascade Style Sheets) og JavaScript (Anthes, 2012). HTML og CSS er standard for alle webapplikasjoner, hvor HTML definerer hvilke elementer som skal være på hver enkelt side, mens CSS brukes for å manipulere utseende på HTML Document

13 Shifter - for Samfunnet Bislett 12 Object Model (DOM) (Anthes, 2012). Sammen med HTML og CSS, har javascriptbiblioteker som Angular og jquery blitt benyttet for å kunne vise data fra serveren på klientsiden. Serversiden er basert på JavaScript, og i all hovedsak Node.js. Node.js er et asynkront JavaScript-bibliotek som blir brukt for bygging av skalerbare applikasjoner (Node.js Foundation, u.d.). Dette blir gjort ved kjøring over operativsystemets tråder. I følge Node.js Foundation (u.d.) er trådbasert kjøring over nettverk ganske ineffektivt. Dette blir løst ved at Node.js kjøres asynkront, noe som vil si at forespørslene mot nettverket ikke blir utført som I/O (input/output). Node.js utfører ingen oppgaver som I/O, noe som gjør at det ikke forekommer blokkeringer (Node.js Foundation, u.d.). Node har den egenskapen at man kan laste ned ulike moduler via Node Package Manager (NPM) for å kunne skreddersy serveren slik at man på best mulig måte kan oppfylle kravene systemet skal ha (Aguilar, 2014). Node.js har i de siste årene blitt tatt mer og mer i bruk. Dette kan ifølge Aguilar (2014) være siden Node er basert på JavaScript, og dette gjør at programmerere ikke behøver å sette seg inn i et nytt språk for å kunne utvikle et system i et programmeringsspråk gjennom alle lagene applikasjonen har. Node har også støtte for mange typer databaser, inkludert SQL-databaser, og dette har gjort at Node kan bli implementert uten å måtte overføre data fra relasjons databaser som SQL til dokumentbaserte databaser som for eksempel MongoDB (Aguilar, 2014). I tillegg til webapplikasjonen har det blitt utviklet en Android-applikasjon. Android er i all hovedsak basert på språkene Java og XML. Java er et objektorientert programmeringsspråk fra 1995, og er et av verdens mest brukte programmeringsspråk i 2016 (Oracle, u.d.) (TIOBE software BV, 2016). XML (Extensible Markup Language) er et enkelt og fleksibelt tekstformat originalt designet for å møte utfordringene store elektroniske publiseringer kan medføre, men har også en viktig rolle i å utveksle et stort utvalg av data over internett (Quin, 2015). I Android brukes XML til å holde struktur på regler og rettigheter, samt stilark for hvordan applikasjonens komponenter skal se ut STANDARDER OG RETNINGSLINJER Det finnes standarder for hva som kan karakteriseres som "den beste" måten å programmere i HTML, CSS og JavaScript. Alle disse språkene er godt dokumentert, og det har blitt utformet dokumentasjon for hva som skal være standard for HTML og CSS (World Wide Web Consortium, u.d.). Disse standardene er ment for å gi informasjon om hva som må være med i oppsettet av disse, samt hvordan de skal brukes i praksis alene og sammen med hverandre, og hvordan de skal brukes for å oppnå best mulig tilgjengelighet for mennesker med ulike hemninger og hjelpemidler. I utviklingen har det blitt tatt høyde for hva som er den beste praksisen, og det har blitt lagt vekt på at koden skal være effektiv og lett å vedlikeholde. Med effektiv kode menes at koden ikke bruker unødvendig lang tid på å laste inn når brukere går inn på siden (World Wide Web Consortium, 2012). Dette oppnås ved å kun ha reine HTML-elementer uten CSS-styling i taggene, men heller ha disse i egne CSS-filer men refererer til i starten av dokumentet, og det samme gjelder med JavaScript.

14 Shifter - for Samfunnet Bislett 13 Systemet inneholder i all hovedsak rene HTML-filer, men unntak av kalendermodulen som er en fullskala JavaScript-applikasjon. Alle HTML-taggene som kan avsluttes blir avsluttet, slik som <header></header>. Tagger som <br /> blir avsluttet av seg selv uten å ha en avslutningstagg (World Wide Web Consortium, 2012). I tillegg vil taggene bli gitt egne id-er og klassenavn for å lettere kunne gjøre forskjell på like tagger som <div>. Samtidig opprettholder man struktur ved å gi beskrivende verdier. Dette for at man lettere kan se hvordan taggene henger sammen og hva de skal inneholde hvis dette vises dynamisk ved bruk av enten jquery og Angular. CSS-stilene blir lastet inn i head-taggen på hver side, og inneholder alle regler for hvordan hvert element skal se ut. I kildekoden blir elementene som skal manipuleres definert enten ved HTML-elementenes id- eller klasseattributt. Et eksempel kan være #title {...}, hvor # betyr HTML-element med id lik "title". Innenfor krøllparantesene "{ }" blir stilreglene definert slik, for eksempel background-color: red;, som vil sette bakgrunnen til fargen rødt. Når et element krever flere regler, legges disse under hverandre for å gjøre koden mer lesbar og forståelig. Som nevnt over består alt av arkitekturen mellom brukerens skjerm og databasen av JavaScript. JavaScript er i all hovedsak et scriptspråk utviklet for å kjøre på klientsiden, noe som betyr at koden blir kjørt i nettleseren, uavhengig av serveren (Christensson, 2014). JavaScript blir i systemet brukt både på klientsiden og på serversiden. Dette gjør at de samme retningslinjene og standardene bør følges gjennom alle ledd. Dette for å gjøre vedlikehold lettere og forståelsen bedre. Navngivning av variabler har blitt gjort slik at det ikke skal være tvil om hva de inneholder, og dette bidrar til at man som utvikler klarer å ha kontroll og oversikt (World Wide Web Consortium, 2015). I Java-koden for Android-applikasjonen har det også blitt fulgt retningslinjer for å gjøre koden som blir skrevet mer lesbar og forståelig. Dette har blitt gjort med kommenteringer av avanserte funksjoner. Dette gjør at andre utviklere lettere kan sette seg inn i koden uten å selv måtte finne ut av hva funksjonen gjør (Android Open Source Project, u.d.). Det har også blitt vektlagt å lage metodene så korte som mulig. Noen metoder er lengre enn andre, men det er ingen hard fasit på hvor lange metoder skal være (Android Open Source Project, u.d.). Når det gjelder navngivning av variabler og funksjoner har dette blitt gjort slik at det er lett å forstå hvilke verdier variablene skal inneholde, samt hva hver enkelt funksjon skal gjøre FEILHÅNDTERING En viktig del av programmeringen generelt er feilhåndtering. Dette er viktig for at programmet ikke skal krasje eller henge seg. Feilhåndteringen gjelder i all hovedsak for Java- og JavaScript-koden. I begge applikasjonene testes tilbakesendte resultater og variabler for akseptable verdier før det blir sendt tilbake til brukeren. Hvis verdiene ikke er riktig, eller om programmet har støtt på en uventet feil, vil brukeren få tilbakemelding om dette med en brukervennlig melding. I JavaScript vil koden gjennomføres for så å returnere en feilmelding som verdi, mens i Android vil programmet stoppe opp under kjøring. Dette blir gjort i all hovedsak med if()-setninger. Dermed er det viktig å vite hvor man skal teste og håndtere feil og exceptions. I Java håndteres exceptions i såkalte try/catch-blokker (Android Open

15 Shifter - for Samfunnet Bislett 14 Source Project, u.d.). En exception defineres som en hendelse som forstyrrer normalflyten i et program, og som et resultat vil et objekt bli "kastet" ut i programmet under kjøring (Jaiswal, u.d.). Ved å håndtere kall til en kilde som kan generere en feil, vil denne kodeblokken teste kjøringen først, før den enten returnerer suksessfullt eller med feil. Ved suksess vil resten av koden kjøre som normalt, mens ved feil vil catch-blokken "fange" objektet som ble kastet ut og håndtere feilen. Dette blir gjort der det er hensiktsmessig for flyten av programmet, og dette kan resultere i at brukeren kan få en bedre opplevelse av programmet selv om feil oppstår VALG GJORT I PROGRAMMERINGEN I løpet av utviklingen har det blitt tatt valg i hvordan systemet skal se ut. Disse endringene blir gjort enten ved å legge til, endre eller fjerne kode fra kilden. Det er da det er viktig at strukturer og retningslinjer er opprettholdt fra starten av. Etter hvert som systemet har økt i kompleksitet, har kildekoden blitt lenger og mer flettet sammen. Dermed har kommentering av funksjoner og logiske navn på variabler vært gjennomgående gjennom hele utviklingsprosessen. Ved å lese kommentarer kan det lette arbeidet med å oppnå forståelse for kode andre har skrevet. Dette kan gjøre at endringer og eventuelle forbedringer kan gjøres av andre hvis den som originalt har skrevet koden ikke har mulighet til å gjøre dette selv. Kommentering av koden har vært mest gjennomgående gjennom JavaScript- og Java-koden i Androidapplikasjonen. Dette fordi disse språkene har mulighet til å opprette ulike typer variabler, samt funksjoner som kan bli navngitt etter ønske. Kommenteringen har i all hovedsak dreid seg om å forklare på best mulig måte hvordan en funksjon fungerer. Et eksempel på denne typen kommentering og variabel-navngivning kan se slik ut: FIGUR 1: EKSEMPEL PÅ KOMMENTERING OG NAVIGERING I JAVASCRIPT Som Figur 1 viser står en beskrivende kommentar over funksjonen "generatequickview". Kommentaren beskriver kort og konsist hva denne funksjonen gjør og hvor den gjør endringene. Funksjonen tar inn en parameter "event" som inneholder data om arrangementet som har trigget funksjonen. Variabelen "quickview" inneholder HTML-kode som vises dynamisk på skjermen for brukeren. For en utvikler er det lettvint å se at hvis superfrivillig-attributtet fra "event" ikke er lik "undefined", vil koden sjekke om denne plassen er ledig. Er den det, legges får HTML-taggen klassenavnet "ansvarledig". Ved at variabelnavn og klassenavn er godt avskilt og selvforklarende, kan dette øke lesbarhet og lette arbeidet med å sette seg inn i koden.

16 Shifter - for Samfunnet Bislett 15 Kommentering har også blitt benyttet i HTML-koden, og har i all hovedsak blitt brukt for å gi en klarere oversikt over avslutning over de forskjellige HTML-elementene som finnes på sidene. FIGUR 2: EKSEMPEL PÅ KOMMENTERING I HTML-KODE Som vist i Figur 2 markerer kommentarene slutt på de tilsynelatende like HTML-taggene. Hvis en fil inneholder mange like HTML-tagger, som for eksempel "<div></div>", vil slutten av disse se tilsynelatende like ut. Dermed kan kommentering lette lesbarhet ved å for eksempel sjekke om en tagg ikke har blitt lukket, og det kan også lette lesbarhet. Under utviklingen har det også blitt benyttet innrykk i koden, og dette vises både i Figur 1 og i Figur 2. Innrykkene har som funksjon å gjøre lesbarheten av koden bedre når ulike elementer blir flettet inn i hverandre. Gjennom all kode har tabulator blir benyttet for innrykk. Dette for å gi et mer klarere innrykk og et klarere skille mellom de ulike elementene.

17 Shifter - for Samfunnet Bislett KRAVSPESIFIKASJON 3.1. MÅL FOR SYSTEMET Lage et system som kan gi oversikt over medlemmene av foreningen Samfunnet Bislet, administrere vaktliste for utestedet Samfunnet Bislet, holde oversikt over hvem som har rabatter, produsere statistikk om medlemsmassen og aktiviteten i foreningen og formidle viktig informasjon mellom Samfunnet Bislets styre og dets medlemmer. Lage et oversiktlig, universelt utformet og brukervennlig brukergrensesnitt både på medlemssiden og administratorsiden. Systemet skal være intuitivt og brukervennlig, kreve minimalt med opplæring i forkant og være enkelt å vedlikeholde FUNKSJONELLE KRAV PRIORITERT FUNKSJONALITET WEB-APPLIKASJON Registrering av bruker og innlogging Bruker skal kunne: o oppdatere sin egen brukerinformasjon o se hvor mye og når de har jobbet o se status for Frivilligpris o se meldinger fra styret o se kalender med informasjon om når det er ledige vakter o sette seg på/av vakter o lese dokumenter o levere avviksmeldinger til styret Barbruker skal kunne: o se hvem som jobber på et skift o se oversikt over hvem som har rabatt o levere avviksmeldinger til styret Administrator skal kunne: o godkjenne/avvise nye brukere i systemet o utestenge brukere fra systemet o tildele ulike roller og tilgangsnivåer til ulike brukere o Redigere vaktliste o Sette brukere på vakt Administrator og styre skal kunne: o skrive meldinger til brukerne o laste opp dokumenter o lese og behandle avviksmeldinger o se statistikk over brukere og aktivitet i vaktliste FIGUR 3: APPENDIX E: DIAGRAMMER - USECASE-DIAGRAM ANDROID-APPLIKASJON Bruker skal kunne: o Logge inn på sin bruker o Se informasjon om sin rabatt-status

18 Shifter - for Samfunnet Bislett ØNSKET FUNKSJONALITET WEB-APPLIKASJON Bruker skal kunne: o levere tellelister over varebeholdning i baren Administrator skal kunne: o vedlikeholde oversikt over varebeholdning i bar og på lager o lese tellelister over varebeholdning i baren ANDROID-APPLIKASJON Bruker skal kunne: o Se neste vakt brukeren er satt på 3.3. IKKE-FUNKSJONELLE KRAV BRUKERVENNLIGHET Systemet skal være lett å bruke og ha et enkelt design Systemet skal kreve minimalt med IT-kunnskaper for å administreres Det skal utarbeides en grundig brukerveiledning til systemet UNIVERSELL UTFORMING Systemet skal oppfylle gjeldene krav til universell utforming av IKT-systemer TILGJENGELIGHET Systemet skal kunne brukes på smarttelefoner og nettbrett i tillegg til datamaskiner ESTETISKE KRAV Systemet skal ha et innbydende design Systemet skal ha et design som representerer Samfunnet Bislets merkevare og gjengir studentpubens identitet EFFEKTIVITET Systemet skal ha lav responstid SIKKERHET Systemet skal ivareta og behandle sensitiv informasjon og personopplysninger på en trygg og sikker måte LEVERANSEKRAV Systemet skal være klart for sensur 24. mai ENDELIG LEVERANSE Endelig overlevering til oppdragsgiver skal skje innen 30. mai IMPLEMENTASJONSKRAV Systemet skal installeres på Virtuell maskin anskaffet av oppdragsgiver

19 Shifter - for Samfunnet Bislett PRODUKTRAPPORT 4.1. WEB-APPLIKASJON SYSTEMOVERSIKT Dette systemet er bygget opp i moduler. Hver side er knyttet til en modul, og modulene har forskjellige visninger basert på hvem som aksesserer dem. For eksempel er vaktlistene totalt forskjellige verktøy for Frivilligansvarlig og en ordinær Frivillig. Dette kommer av at databasen har full kontroll over hvilke forespørsler som sendes av hvilke brukere. På denne måten leverer databasen kun sensitiv informasjon og administrative verktøy til medlemmer som har de rette privilegiene.

20 Shifter - for Samfunnet Bislett MODUL: BACKEND LOGISK STRUKTUR Backend består av to hovedkomponenter: en Node.js Express server, og en MySQL database. Node-serveren består igjen av mange underkomponenter. I tillegg krever også serveren at bildemanipulasjons-biblioteket GraphicsMagick er installert, for håndtering av profilbilder. EXPRESS SERVER RAMMEVERK I tillegg til vår egen kode har vi også benyttet oss av flere ferdiglagde offentlig tilgjengelige rammeverk i utviklingen av serveren. Vi har hele tiden hatt som motivasjon at vi ønsker å levere et så profesjonelt og komplett produkt som mulig, til tross for at vi har liten erfaring med JavaScript og ingen erfaring med Node.js fra tidligere. Det har derfor vært naturlig å ta i bruk allerede utviklete rammeverk, som er kjent for å være solide, og som inneholder mange flere funksjoner og muligheter enn det hadde vært mulig for oss å skape i løpet av prosjektperioden. Alle rammeverkene har sine egne filer, og installeres med pakkehåndteringsverktøyet NPM (Node.js package manager). Man kan enten installere et rammeverk globalt, slik at det blir tilgjengelig for alle prosjekter, eller man kan installere de lokalt, slik at de blir tilgjengelige kun for enkeltprosjekter. Rammeverk som installeres lokalt blir lagret i node_modules mappa som blir opprettet i prosjektets rotmappe. Filer som ligger i denne mappa er ikke utviklet av vår gruppe. Når man installerer et rammeverk kan man velge at det skal lagres at prosjektet bruker dette rammeverket, slik at det enkelt kan installeres ved en senere anledning. Dersom man gjør det blir rammeverket og versjonsnummer lagt til i filen package.json, som også ligger i rotmappen til prosjektet. GLOBALE RAMMEVERK FOREVER.JS Rammeverk som benyttes for å starte og holde i gang en server-prosess. Forever sørger for at server-scriptet blir startet igjen dersom noe inntreffer som gjør at det kræsjer eller stopper. Et vitalt rammeverk for å være sikker på at serveren fortsetter å kjøre. LOKALE RAMMEVERK BLUEBIRD Rammeverk for Promises. Gjør det enkelt å kontrollere flyten i asynkrone kall, samt å fange opp eventuelle feil som genereres og som da avbryter hele flyten. BODY-PARSER Hjelper med å hente informasjon som sendes fra klienten, da det oppretter et body-objekt i forespørsels-objektet (request) som mottas. CONNECT-SESSION-SEQUELIZE "Session-store" rammeverk. Bestemmer hvor informasjon om dataøktene, for eksempel hvor lenge en økt varer, lagres med Sequelize i databasen. DEBUG En modul som blir installert når man bygger opp et prosjekt med Express-generator. Brukes av server.js for å logge til konsollen.

21 Shifter - for Samfunnet Bislett 20 EXPRESS Server-rammeverk for Node.js som brukes for å lage nettsider. Konfigurerer mange av de andre modulene til å brukes med serveren. Konfigurerer en Express-app (app.js). EXPRESS-SESSION Brukes med Express-appen til å lagre øktdata på serveren. Øktdata kan lagres til og hentes fra req.sessionobjektet. Må konfigureres med en session store, som sier hvor dataene skal lagres. Vår server bruker Connectsession-sequelize som session store. FORMIDABLE Brukes til å håndtere filopplasting. Tolker form-elementets innhold som blir sendt fra webklienten. GM GraphicsMagick. Brukes ved opplasting av nytt profilbilde til å validere at filen som blir sendt er et bilde. Konverterer også bildet til.jpg ved behov og endrer bildets størrelse. MOMENT Et bibliotek som brukes for å manipulere datoer. MORGAN Brukes av Express-applikasjonen for å logge forespørsler til serveren, statuskoder de resulterer i, og eventuelle feil. MYSQL Kreves av Sequelize for at man skal kunne kommunisere med en SQL-database. PASSPORT Rammeverk som håndterer opprettelse og innlogging av brukere, og validering av brukerforespørsler. I vårt system håndterer det Facebook innlogging og autentisering via OAUTH2.0, i tillegg til at det brukes når man logger inn som barbruker. Passport sørger for at forespørselsobjektet som kommer fra klienten alltid inneholder informasjon om brukeren og dennes roller. PASSPORT-FACEBOOK Nødvendig for at Passport skal fungere med Facebook. PASSPORT-LOCAL Nødvendig for at passport skal fungere med lokal innlogging (barbruker) REQUEST Rammeverk for å sende http-forespørsler til andre servere. Brukes til å hente profilbilder fra Facebook når det opprettes en ny bruker. SEQUELIZE Et Promise-basert ORM som brukes for å kommunisere med MySQL-databasen. Håndterer alle databasetransaksjoner, og sikrer også spørringer mot SQL-injections. SERVE-FAVICON Når nettlesere kobler seg til en server så ber de fleste av de om et favicon.ico, et ikon som vises i nettleseren på fanen for den gjeldende siden. Dette rammeverket sørger for å legge ikonet i hurtigminnet, slik at det raskere kan leveres til klienten. Det gjør også at ikonet er tilgjengelig uavhengig av hvilken side på serveren man går inn på.

22 Shifter - for Samfunnet Bislett 21 UTVIKLINGSRAMMEVERK Enkelte rammeverk brukes kun i utviklingsfasen av en applikasjon, og er ikke nødvendige for at applikasjonen skal settes i produksjon. Disse rammeverkene, hvis de blir installert lokalt, kan lagres i en egen utviklingskategori i package.json, og på den måten skilles ut fra rammeverkene som er nødvendige for å ha applikasjonen i drift. GLOBALE RAMMEVERK Express-GENERATOR Dette er et rammeverk som ble benyttet for å lage en grunnleggende filstruktur. Det oppretter en rekke filer som er ferdig kodet til å kunne kjøre en enkel server, og fungerer som et utgangspunkt en kan jobbe videre på. Den nåværende utgaven av serveren ble opprettet ved hjelp av dette rammeverket. LOKALE RAMMEVERK SEQUELIZE/CLI Brukes for å opprette en grunnleggende Sequelize-modell-filstruktur. Oppretter en index.js fil i models-mappa i prosjektet som henter og synkroniserer alle modellene som ligger i mappa. Synkroniserer også alle modellene for en mot databasen. Gjør at man slipper å håndtere én og én modell. Den nåværende utgaven av serveren har brukt dette verktøyet som et utgangspunkt for database-modellene. MYSQL DATABASE Per i dag benytter Samfunnet Bislet seg av en MariaDB database med versjonsnummer Vårt system er utviklet med en SQL-database i tankene, men MariaDB er basert på MySQL, så det fungerer likevel problemfritt. Dersom det ønskes er det ikke noe problem å endre systemet til at det forventer en annen type database i stedet. Dette er definert i konfigurasjonsfilen for databasen som Sequelize bruker for å koble seg opp mot den. Siden vi benytter oss av Sequelize tar det uansett seg av eventuelle språkforskjeller for spørringene våre. GRAPHICSMAGICK GraphicsMagick brukes som nevnt tidligere til å verifisere at bildefiler faktisk er bilder, og til å konvertere og endre størrelsen på bilder. For å bruke GM kreves det, i tillegg til at det er installert som en node modul, at man har installert GraphicsMagick på serveren, og at installasjonsbanen ligger i PATH variablene slik at det kan kalles fra Node (GraphicsMagick Group, 2016) FILSTRUKTUR OG LOGISK FLYT I følgende seksjon vil vi bruke filbaner for å beskrive hvor filer og mapper befinner seg. En fil som heter test.txt og ligger i rotmappa til prosjektet vil omtales som /test.txt, og hvis den ligger i public-mappa i rotmappa så vil den omtales som /public/test.txt. Startpunktet for serverprogrammet er /server.js. Når denne fila startes så importerer den Express-applikasjonen fra /app.js, setter hvilken port den skal lytte på ved hjelp av miljøvariabelen PORT (eller port 80 hvis miljøvariabelen ikke er satt) og starter en server som lytter på satt port. /app.js er grunnfila for Express. Når den kalles konfigurerer den de andre rammeverkene som behøves for å kjøre serveren. Den: Synkroniserer Sequelize mot databasen ved å importere /models/index.js. Konfigurerer lagring av dataøkter i db og cookies.

23 Shifter - for Samfunnet Bislett 22 Setter opp konsoll-logging av forespørsler og eventuelle feil som oppstår. Konfigurerer tolking av innhold i http-forespørsler. Setter appen til å bruke Passport for autentisering av brukere. Gjør favicon.ico tilgjengelig for forespørsler. Gjør filene i /public tilgjengelig for diverse baner som brukes av serveren. Importerer ruterfila, /routes.js, som brukes for å tolke hva forespørsler til forskjellige baner skal gjøre. Den gjør også Express-appen og Passport tilgjengelig for ruteren. Når serveren mottar en forespørsel fra en klient så skapes det et request-objekt (req), som inneholder data om forespørselen og dataøkten, og et response-objekt (res) som brukes til å sende svar tilbake til klienten. Når /app.js mottar forespørselen fra klienten legger den ved db-en i req-objektet, i tillegg til banen til rotmappa, og banen til /views-mappa i hver sin streng-variabel. Forespørselen blir så behandlet av ruteren. RUTER (/ROUTES.JS) Når forespørselen fra klienten kommer til ruteren, så avgjøres hva som skal gjøres med forespørselen ut fra hva slags http-metode, og hvilken url som er knyttet til forespørselen. For eksempel: en bruker av systemet ønsker å se vaktlista, og klikker på vaktliste-linken. Hvis domenet for serveren er så leder denne linken til shifter.no/calendar/, og http-metoden er GET, fordi man kaller på en side. Ruteren tolker banen som kommer etter rota til serveren, så i denne situasjonen tolker den forespørselen som en GET forespørsel til /calendar/. Måten dette gjøres på er å kalle på app.get() som tar to parametere. «.get» er fordi det er en GET-forespørsel. Den første parameteren er banen som skal tolkes, i dette tilfellet /calendar/. Den andre parameteren er en funksjon som skal behandle selve forespørselen, og som request- og response-objektet sendes videre til. Eksempel på dette vises i bildet Figur 4: FIGUR 4: RUTE FOR GET-FORESPØRSEL TIL /CALENDAR/ Her kan vi se at når ruteren mottar kallet til /calendar/, så har den en funksjon kalt init, som ligger i fila /views/calendar/index.js, som sin andre parameter. Nedenfor ser vi hvordan denne funksjonen ser ut: FIGUR 5: FUNKSJONEN 'INIT' I /VIEWS/CALENDAR/INDEX.JS Her ser vi at req og res kommer som parametere til funksjonen. Det første denne funksjonen gjør er å sjekke om brukeren har rollen Frivilligansvarlig, og dersom dette er tilfelle så blir klienten omdirigert til banen /super/cal/, som er banen frivilligansvarlig har for sin kalender, hvor det er tilgang til flere funksjoner. Dersom

24 Shifter - for Samfunnet Bislett 23 brukeren ikke har rollen Frivilligansvarlig blir de sendt filen /calendar/index.html, som er den kalenderen vanlige frivillige er ment å bruke. Alle baner i applikasjonen er lagd for å være semantisk logiske, slik at man kan ha en anelse om hva funksjonen som banen resulterer i gjør, utfra selve banen og http-metoden knyttet til den. Filer som brukes av ruteren ligger også i mapper som tilsvarer banen de tilhører, i views-mappa. Nettsiden man får opp når man går til /calendar/ ligger i /views/calendar/ som index.html, og javascript-filen som har funksjonene som brukes i banen ligger i /views/calendar som index.js. På samme måte ligger html-filen for /profile/ banen i /views/profile/ som den mappens index.html, og js-filen er /views/profile/index.js. HTTP-METODER Det er brukt fire forskjellige http-metoder i systemet: GET Brukes til å hente data fra serveren. Eksempel er /calendar/. POST Brukes til å sende (nye) data til serveren. Eksempel er /calendar/shift/:shiftid/:responsible. Dette er en bane som brukes av en frivillig for å sette seg på en vakt. Det er to parametere innbakt i banen: shiftid og responsible. Andre POST-metoder har gjerne mer data inkludert i forespørselen enn det som er hensiktsmessig å legge i selve banen. Disse tolkes da med bodyparser-rammeverket. DELETE Brukes når det er noe man ønsker å fjerne. Eksempel er /calendar/shift/:shiftid. Denne banen brukes av en frivillig som vil ta seg av en vakt de er satt opp på. ShiftId er inkludert som parameter i banen. PUT Brukes når man ønsker å endre allerede eksisterende data. Eksempel på dette er /profile/edit. En PUT til denne banen endrer brukerens brukerdata, såfremt dataene kommer gjennom valideringen som foretas. Det er også mulig å sende en http-get til /profile/edit. Da kommer man til selve siden for profilredigering. ALL Brukes for å fange alle mulige http-metoder til banen. Brukes for å sette restriksjoner på hvilke baner brukere kan gå til. Dersom ruteren mottar en forespørsel til en bane som ikke finnes, eller til en bane som finnes, men med en httpmetode som ikke er knyttet til den banen, så vil dette resultere i en 404-respons. ADGANGSKONTROLL Banene er som nevnt ment å være så semantisk intuitive som mulig. Dette medfører at for eksempel alle kall som har noe med vaktlista å gjøre starter med /calendar/ (eller /super/cal/ for frivilligansvarlig), og alle kall som har med brukerens profil å gjøre starter med /profile/. Dette gjør det også veldig enkelt å kontrollere hvilke brukere som har tilgang til hvilke funksjoner, da man kan bruke jokertegn (*) og http-metode ALL for å fange alle baner som har en viss oppbygning. Dette er vist under: FIGUR 6: SJEKK AT BRUKEREN HAR PÅKREVD ROLLE FOR BANE /CALENDAR

25 Shifter - for Samfunnet Bislett 24 Denne koden ligger over alle banene som starter med /calendar/. Her blir request og response objektene først sendt til /views/calendar/index.js sin set_required_role funksjon. Denn funksjonen legger til en requiredrole variabel i request-objektet, som sier at den påkrevde rollen for banen /calendar/ er «Frivillig»: FIGUR 7: SETTER PÅKREVD ROLLE FOR BANEN Deretter kalles next-funksjonen i set_required_role, som gjør at ruteren går videre til det neste kallet som matcher banen. Som vist i Figur 6 kaller den da funksjonen hasroleorredirect. Funksjonen hasroleorredirect er en funksjon som ligger i ruteren, og som sjekker om noen av rollene som nå ligger i req.requiredrole stemmer overens med noen av rollene til brukeren. Den sjekker også om brukeren er bannlyst. Dersom brukeren ikke har påkrevd rolle for banen, i dette tilfellet en bruker som ikke har rollen «Frivillig», eller brukeren er bannlyst, så blir de omdirigert til hovedsiden (/). Dersom brukeren har (en av) rollen(e) som kreves, så kjøres next-funksjonen som hasroleorredirect har fått som parameter i tillegg til req og res, og ruteren går videre, i eksempelet vi brukte tidligere med bane /calendar/: til bilde Figur 4. Denne måten å kontrollere hvilke baner en bruker har tilgang til er brukt på alle baner som ikke er rotbanen. Dette fordi det er mange roller som brukes av systemet, og det er viktig å sørge for at brukere ikke får tilgang til funksjoner som kun er ment for brukere med andre roller. Rollen med flest privilegier er Frivilligansvarlig, og dette er den eneste rollen som har tilgang til å se informasjon om alle brukere. Alle andre roller kan kun se sin egen informasjon, bortsett fra der det er hensiktsmessig at de har tilgang til litt mer. Eksempler på slike unntak er i vaktlista, hvor det vil være ønskelig å se hvem andre som jobber på et skift, da man gjerne setter seg på skift som venner er på; eller hvis man er logget inn som barbruker og ønsker å kontakte noen av de andre som jobber den dagen. «JUKSEKODER» Dersom miljøvariabelen NODE_ENV er satt, og den er satt til enten development eller test, så vil ruteren inkludere en fil med baner som lar en skrive inn «juksekoder». Disse juksekodene lar en innlogget bruker endre rollene sine uavhengig av hvilke roller hun eller han har, og er nyttige å bruke under testing av systemet og dets funksjoner. Uten juksekodene er man avhengig av at en annen bruker er logget inn som frivilligansvarlig for å endre rollene ens, da det ikke finnes noen kombinasjon av roller som gir tilgang til alle baner i systemet samtidig. Når serveren går live forventes det at NODE_ENV settes til production. Alternativt kan det hende at man glemmer å sette den. Det er uansett veldig lite sannsynlig at man setter den i test eller development, så kodene vil ikke være tilgjengelige på en live server.

26 Shifter - for Samfunnet Bislett 25 ANDRE FILER Alle filer som ruteren ruter til ligger under /views/. Det eneste unntaket til dette er når man skal logge inn og Passport skal autentisere brukere, da autentiseres de i /passport.js. Filer som skal være statisk tilgjengelige ligger i /public/. Der ligger blant annet css-filer, js-filer brukt i frontend, og font-filer. Profilbilder ligger også her og er statisk tilgjengelige. Verktøyfiler, med funksjoner som kan være nyttige å ha flere steder i systemet ligger i, eller som ikke har noen annen logisk plassering ligger i /tools/. Eksempler på dette er /tools/filehandler.js som håndterer filer, og /tools/get_missing_pictures.js som må kjøres manuelt fra kommandolinjen, og som henter profilbilde fra Facebook-profilen til alle brukere som mangler bilde. I /tools/ er det også en db-mappe, som inneholder: /tools/db/nuke_db.js En fil som dropper alle tabellene i databasen. /tools/db/init_db Fil som oppretter alle tabellene i databasen, lager instanser av rollene som behøves, og oppretter barbrukeren /tools/db/run_daily.js Fil som skal kjøres daglig av en cron-jobb. Dette scriptet finner alle frivillige som har hatt vakt de siste 30 dagene, og oppdaterer frivilligprisen deres. I tillegg endrer det passordet for barbrukeren. Dokumenter som lastes opp av styremedlemmene lagres i /docs/. Konfigurasjonsfiler som inneholder sensitiv informasjon ligger i /config/. Her ligger: auth.js Fil med informasjon om Facebook-appen, nødvendig for å logge inn og autentisere brukere med Facebook. Vi har benyttet oss av to Facebook-apper. En er en test-app som vi har benyttet når vi har kjørt serveren lokalt. Denne bruker en callback url som går til localhost. Den andre appen er den faktiske appen, og har en callback-url som går til shifter.vlab.cs.hioa.no. Denne brukes kun av serveren som kjører fra dette domenet. Sistnevnte callback-url er kommentert ut, slik at det er mulig å kjøre serveren på localhost. database.json Fil med tilkoblingsinformasjon for database(r). Denne filen brukes av Sequelize for å koble til en db. Hvilken db den kobler til er avhengig av miljøvariabelen NODE_ENV. session_secret.js Inneholder en streng som brukes til å beregne hash for dataøkten. Uten denne strengen får man ikke tilgang til økten. Modeller for database-tabellene ligger i /models/. Her ligger også en index.js fil, som henter og synkroniserer alle filene som ligger i samme mappe mot databasen. /models/index.js definerer også relasjonene mellom de forskjellige tabellene. De andre filene i /models/ representerer alle hver sin db-tabell. Sequelize bygger opp databasen basert på disse filene SEQUELIZE Sequelize er et Promise-basert ORM som brukes for å kommunisere med databaser. Når man kjører spørringer mot db med Sequelize mottar man et resultatobjekt som inneholder en eller flere verdier, avhengig av hva slags spørring som ble gjort. Sequelize sikrer alle spørringer mot sql-injections. I /models/ ligger modell-filer for alle database-tabellene. Disse filene inneholder definisjoner på alle kolonnene en tabell skal ha. En kan også sette egendefinert validering av felter, formatering, og definere metoder for hvordan data skal settes inn og hentes ut. Eksempel på dette kan sees i /models/volunteer.js:

27 Shifter - for Samfunnet Bislett 26 FIGUR 8: UTSNITT AV /MODELS/VOLUNTEER.JS I ovenstående figur ser man hvordan kolonnene lastname og gender er definert i /models/volunteer.js. lastname er en string med lengde opp til 35. Dette resulterer i en varchar kolonne. Den har også satt at den ikke tillater null, ikke skal være tom, og skal matche en regex. Hvis den ikke matcher regexen så kommer det en egendefinert feilmelding på grunn av dette. De andre kravene har ikke egendefinerte feilmeldinger og vil gi feilmeldinger definert av Sequelize. gender har også egendefinert validering, hvor den kun aksepterer 3 forskjellige verdier, og gir en egendefinert feilmelding dersom input ikke matcher en av disse. Den har også en egendefinert setter-metode, som oversetter verdien den får inn dersom det er på engelsk. Dette gjør at når brukeren blir opprettet, og kjønnet hentes fra Facebook, så blir det fortsatt lagret som Mann eller Kvinne i databasen. Dersom input ikke er male eller female så forsøker den i stedet å sette input inn i feltet. Valideringen trigges etter at setter-metoden har kjørt. I modell-filene kan en også definere klassemetoder og instansmetoder for en modell. Eksempel på dette finnes også i /models/volunteer.js. Her er en klassemetode, checkprivilege, som kalles ved å referere til Volunteertabellen, og som sjekker om en bruker har en påkrevd rolle ved å sammenligne to arrays. I tillegg har modellen en instansmetode, checkshifttoday, som kalles på en spesifikk instans av Volunteer. Denne funksjonen sjekker om den gjeldende brukeren er satt opp til å jobbe den dagen. Sequelize er et omfattende verktøy med mange sterke funksjoner. Egendefinert validering lar en skrive valideringsfunksjoner rett i modellen hvor en har definert tabellen, som bidrar til å gi oversikt. Nesten all validering av tekst- og talldatainput gjøres i modellene. Det bør nevnes at det er vesentlig mindre restriktiv validering på modellene som kun styret har tilgang til å endre (eksempel: styremelding (/models/message.js), enn de modellene som alle har mulighet til å endre (eksempel: avviksmelding (/models/deviant.js). Bakgrunnen for dette er at det forutsettes at medlemmer av styret kan stoles mer på enn den gjennomsnittlige brukeren, samtidig som de har en slags administratorrolle som i relativt stor grad skal kunne gjøre som de vil.

28 Shifter - for Samfunnet Bislett 27 TABELLER Følgende tabeller opprettes av Sequelize: Admin Brukes for lagring av daglig kode. Banned Lagrer Facebook-id til bannlyst bruker, navn, og grunnlaget for bannlysningen. Deviants Avviksmeldinger. Documents Lagrer informasjon om dokumentene som er lastet opp. Events Informasjon om arrangementene som er opprettet. Messages Meldinger fra styret. Roles Inneholder rollene som brukere kan ha. Shifts Inneholder skiftene som er på hvert arrangement. Templates Malene som brukes for å hurtigopprette arrangementer. Volunteers Informasjon om de frivillige i systemet. Volunteer_Roles Koblingen mellom Volunteers og Roles. Volunteer_Shifts Koblingen mellom Volunteer og Shifts. Opprettes når et shift opprettes, og representerer antall plasser som finnes på skiftet. I tillegg opprettes det en tabell kalt Sessions, som inneholder informasjon om de forskjellige dataøktene. SYSTEMKRAV BRUKSANVISNING For å kjøre serveren kreves en maskin med Node.js og NPM installert, og tilgang til en MySQL eller MariaDB database. Applikasjonen kan også konfigureres til å jobbe mot andre typer databaser hvis ønskelig. Maskinen som skal kjøre serveren må også ha installert GraphicsMagick, slik at profilbilder kan prosesseres, og GraphicsMagick må ligge i miljøvariablene. Både Node.js og GraphicsMagick kan installeres på en Windows-maskin, men for prosjektets del har det alltid vært en forutsetning at serveren skal kjøres på en Unix-basert VPS. Dersom det installeres på en Windows-maskin må man starte maskinen på nytt for at miljøvariablene skal bli satt. INSTALLASJON AV SERVER OG INITIERING AV DATABASEN. For å installere serveren kopieres prosjektfilene inn i ønsket mappe. Deretter navigerer man til rotmappen for prosjektet i et kommandolinje-vindu, og skriver kommandoen «sudo npm install». Alle nødvendige rammeverk vil deretter bli installert i /node_modules. For at serveren skal starte igjen dersom den stopper er man avhengig av at rammeverket Forever er installert globalt. For å gjøre dette skriver man (i Unix) «sudo npm install forever -g». I windows skriver man de samme kommandoene uten «sudo» først. Dette gjelder alle kommandoer hvor «sudo» blir nevnt. Etter at rammeverkene er installert må man skrive inn info for databasen man ønsker å jobbe mot. Dette gjøres ved å redigere /config/database.json. Det anbefales at man bruker et program som kan tolke filer som inneholder kode til dette, eksempelvis Notepad++. /config/database.json-filen har som standard mulighet til å lagre innstillinger for 3 forskjellige databaser. Hvilken database det kobles til er avhengig av miljøvariabelen NODE_ENV og dens verdi. De tre potensielle verdiene

29 Shifter - for Samfunnet Bislett 28 systemet forventer at denne variabelen har er development, test, eller production. Alternativt, hvis man ikke definerer NODE_ENV så velges innstillingene for development-databasen som standard. For å sette NODE_ENV til, for eksempel production, i et Unix-system, skriver man i kommandolinjen: «export NODE_ENV=production». Det er viktig å skrive det akkurat slik det er skrevet her for at det skal registreres ordentlig. For å sette NODE_ENV til production i et Windows-system skriver man i kommandolinjen: «set NODE_ENV=production». Etter at man har satt NODE_ENV til ønsket verdi må man kjøre følgende kommando for å opprette db-tabeller og sette startverdiene: «node tools/db/init_db» (forutsetter at kommandovinduet er lokalisert i prosjektets rotmappe). (FOR Å SLETTE DATABASEN: Dersom man ønsker å nullstille databasen kan dette gjøres ved å skrive kommandoen «node tools/db/nuke_db». Dette vil nullstille databasen fullstendig, og kreve at man kjører initiering av den igjen, med mindre man har en backup av den man ønsker å importere. Dette må kun gjøres dersom man er helt sikker på at man ønsker å nullstille databasen.) Serveren er nå klar til å kjøre. Dersom man ikke ønsker å kjøre den på port 80 som er standard kan man også gi miljøvariabelen PORT en tallverdi. Da vil serveren kjøre på oppgitt port. STARTE SERVER For å starte serveren som en Forever-prosess skriver man: «sudo forever start o out.log e err.log server.js». Serveren vil nå starte, og hvis den stopper vil Forever sørge for å starte den igjen. Output fra serveren logges til /out.log, og feil logges til /err.log. For at serveren skal starte automatisk etter en omstart forutsettes det at det lages et script som kjøres automatisk etter omstart, og som setter NODE_ENV til ønsket verdi (og eventuelt PORT), og deretter kjører kommandolinjen som starter Forever-prosessen. Det forutsettes også at det opprettes en Cron-job som kjører kommandoen: «node tools/db/run_daily» en gang daglig, slik at barbrukers passord og frivilligpris oppdateres. Vi anbefaler at denne Cron-jobben kjøres tidlig på morgenen, da det er lite sannsynlig at noen brukere bruker systemet, og ingen arrangementer holder på. Når serveren er nyinstallert har den ingen Frivilligansvarlig i databasen som kan akseptere nye brukere og endre roller på dem. Samfunnet Bislet har en Facebook-profil som de utelukkende bruker for å representere frivilligansvarlig, og for å unngå at man må manuelt inn i databasen for å legge til en person som Frivilligansvarlig, har vi bestemt at denne Facebook-profilen som standard vil bli gitt rollen Frivilligansvarlig når den logger på systemet. Dette vil gjøre at man alltid kan forholde seg til kun brukergrensesnittet, selv om serveren kjøres i et produksjonsmiljø. Dette er ikke implementert ennå, da vi ikke har mottatt Facebook-profilens id. Når serveren ikke er i produksjon forutsettes det at den kjører i development eller test, og man kan da benytte seg av juksekoder for å endre rollene sine.

30 Shifter - for Samfunnet Bislett 29 JUKSEKODER Alle juksekoder skrives inn i root i systemet. Eksempel: Hvis serveren kjører på så skriver man for å se alle rollene en har. Liste over koder: /myroles viser alle rollene brukeren har. /opme gir brukeren alle roller unntatt Begrenset bruker, Tidligere styremedlem, og Barbruker. /imnormal setter brukeren til å ha rollen Frivillig. /barme Setter brukeren til å være Barbruker. /imnormalplus Setter brukeren til å ha rollene Frivillig og Superfrivillig. /techme Setter brukeren til å ha rollene Frivillig og Tekniker. /boardme Setter brukeren til å ha rollene Frivillig og Styremedlem. /probateme Setter brukeren til å ha rollen Begrenset bruker. /banme Bannlyser brukeren. /unban Fjerner bannlysning av alle brukere. Feil: KJENTE PROBLEMER / FORBEDRINGSFORSLAG Én bruker har sagt at han får en feilmelding når han prøver å opprette bruker i systemet. Vi har ikke fått innhentet spesifikk informasjon ennå om hva feilmeldingen sier, men den gjelder over forskjellige enheter og nettlesere, og var visstnok også tilstede under den første testfasen, selv om vi ikke fikk vite om den før i den siste testfasen. Forbedring: Endre retired i backend til å reflektere frontend: inactive. Det var usikkert hva denne attributten skulle kalles initielt, og da vi endelig bestemte oss for inactive var den implementert flere steder i backend. Siden den kun forekommer som en string er det vanskelig å automatisk refaktorere den i en IDE, men den burde endres for at backend og frontend skal være mest mulig like i språkbruken. Forbedring: Det kan være ønskelig at verdiene som er lagret i filer i /config/ enten lagres i filer som finnes utenfor systemets struktur, eller at de settes i miljøvariabler før serveren startes og så hentes via de, for å tjene som et ekstra lag med sikkerhet og fleksibilitet.

31 Shifter - for Samfunnet Bislett MODUL: VAKTLISTE OVERSIKT API-ER OG SCRIPT Vaktlisten på sitt mest grunnleggende - baseres på en sterkt modifisert versjon av fullcalendar.js (FullCalendar LLC, 2016), i samarbeid med node.js på serversiden. Dette igjen støttes av flere ulike trejdeparts javacriptbiblioteker, som alle open source. Med noen av API ene følger også tilhørende css-dokumenter. Det er tre nivåer med dependancies, og alle bibliotekene baseres på jquery, med untatt av moment.js, som er frittstående. Hierarkiet ser slik ut: FIGUR 9: VISUALISERING OG FORKLARING ALLE API-ER SOM BENYTTES I VAKTLISTEMODULEN Når noen ber om /calendar inne på Shifter-domenet, gjøres en sjekk på hvilke roller brukeren som gjorde forespørselen har. Dersom brukeren har rolle 8 frivilligansvarlig blir den automatisk sendt til super/cal. Dette er den administrative versjonen av vaktlisten, som benytter seg av alle overnevnte API-er. Dersom du mangler frivilligansvarlig-privilegier, blir du tatt til /calendar. Dette er basisversjonen av vaktlisten, for vanlige brukere, som ikke benytter seg av jquery-datepicker.js, eller jquery-timepicker.js.

32 Shifter - for Samfunnet Bislett 31 I tillegg til overnevnte er det fire originale JavaScript-dokumenter skapt for Shifters vaktliste, og flere globale JavaScript-dokumenter den bruker metoder fra: Shifter_calendar.js o Script med metoder som håndterer alt av GUI-generering i vaktlisten, og opererer som middleware mellom brukeren og database-transaksjoner. Init_calendar.js o Script med én metode som håndterer initialisering av kalenderen. Den spør etter et JSONobjekt fra serveren (som setter dette sammen fra tabeller i databasen), og gjør flere operasjoner mot objektet for å skille det til individuelle oppføringer i kalenderen, og deretter generere en kilde som er lesbar for fullcalendar API-et. For å få dette til må den operere med fire nivåer med nestede løkker, og flere betingede spørringer: FIGUR 10: EKSEMPEL PÅ NØSTEDE LØKKER I INIT_CALENDAR.JS Dette er en kompleks operasjon fordi objektet fra databasen ser slik ut: Et arrangement-objekt er toppnivået, inneholder informasjon om arrangementet, og kan inneholde opptil fire skift-objekter Et skift objekt inneholder informasjon om det individuelle skiftet, og kan inneholde opptil 8 vakter, hvorav én av dem potensielt sett er en ansvarsvakt. I tillegg inneholder skiftet en tabell med påmeldte frivillige tilknyttet skiftet, som muligens er populært. Dersom skiftet har vakter, og vaktene har påmeldte, så man finne hvilke frivillige som hører hjemme på hvilke vakter, og hvorvidt de er ansvarshavende eller ikke. fetch_events.js o Script med metoder for å hente informasjon om et skift som allerede eksisterer i kalenderen. Den gjør ingen operasjoner mot databasen, men heller mot et globalt array av skift som allerede er tegnet i DOM. Når frivilligansvarlig trykker på en dag med inneværende skift, hentes skift-id ut, sammenlignes mot det globale arrayet. Når funksjonen finner en match på id-en mot det globale arrayet, brukes informasjonen til å generere objekter for eventuell lagring, og skift for GUI. fetch-events.js brukes også når man sletter et event, da dette går via event-id, som ligger lagret i hvert skift. templates.js o Script for å håndtere hele template/mal-logikken. Maler hentes som JSON fra serveren, og deles deretter opp i individuelle maler med tilhørende skift. Alle malene ligger i som objekter i et array i runtime. På denne måten kan man slette og legge til nye maler uten å hente kilden om igjen, bare ved å manipulere arrayet. Maler lagres som èn stor sammenhengende JSONstreng i databasen, for å hentes og tolkes i klienten gjennom dette scriptet. I følge Dewson (2008) så går det greit å lagre opptil 8KB med tekst i én kolonne. En veldig kompleks mal, med alle parametere satt er målt til å være på ca. 340 tegn. Dermed kan det lagres over 20 maler i

33 Shifter - for Samfunnet Bislett 32 samme JSON-streng, og fremdeles være innenfor sikkerhetsmarginen for ytelse. Etter drøftinger og samtaler med produkteier, ble det vurdert at 6-8 maler var det maksimale de så behov for å lagre. Dermed ble det avgjort at én sammenhengende JSON-streng var trygt og lagre, og konsekvensen av dette ble en enklere transaksjon med databasen. I tillegg til de spesialiserte scriptene for kalenderen, brukes også flere globale JavaScript-dokumenter. profile.js o Behandler profilinformasjon. Brukes for å hente informasjon om brukeren. dialogs.js o Behandler enkelte globale ting om dialogvinduer, som styling. db_transactions.js o Behandler alle databasetransaksjoner, med unntak av de som gjøres på egen profil (profile.js) og medlemsdatabasen (members.js) members.js o Behandler medlemsdatabasen, med funksjoner for å liste ut og filtrere medlemmer.

34 Shifter - for Samfunnet Bislett SUPER/CAL - INITIERING Når super/cal lastes produseres kun fem DOM-elementer I HTML, deriblant navigasjonen i topp, og en hovedkontainer / wrapper. På dette tidspunktet er elementet som huser kalenderen, bare en tom <div> med calendar som id. Når DOM er lastet, og browseren gir JavaScript grønt lys for on.document.ready begynner selve initialiseringen: GETPROFILE(): Spør etter brukers profildata via profile.js. Den henter brukerens Facebook-id fra en session-variabel som opprettes når man logger inn. getprofile() kaller på serveren, ser etter Facebook-id, og returnerer et objekt til runtime, som representerer brukeren med blant annet dens primærnøkkel fra databasen. FULLCALENDAR({: VIEWRENDER: Dette gjøres for å kunne sjekke hvorvidt brukeren finnes i et klikket skift, hvor vi da skanner alle oppføringer etter matchende id; se punkt 6. Initialiserer kalendermodulen gjennom et kall på konstruktøren via fullcalendar.js. Nå defineres alle knapper og funksjoner som skal være unike for frivilligansvarlig, og diverse parametere for hvordan kalenderen skal oppføre seg. Blant annet så setter defaultview til å være månedsvisning, noe som gir frivilligansvarlig raskere oversikt. Selectable - parameteren gjør dagene i kalenderen klikkbar, noe som er unikt for frivilligansvarlig. Dette gjør opprettelsen av nye arrangementer mer intuitivt, og sørger for at FIGUR 11: PARAMETERE SOM SETTES NÅR VAKTLISTEN OPPRETTES vaktlisten kan håndtere opptatte / ikke opptatte poster i kalenderen; se punkt 4. Da kalenderen har en responsiv størrelse, så vil kalenderen blir gjengitt basert på hva den inneholder. Dette betyr at dersom kalenderen ikke har noen arrangement, så blir den bare noen pixler høy. Her definerer vi en minimumshøyde, dersom visning ikke er måned. Grunnen til ekskluderingen er at hele raden i uke- eller dags-visning, er det samme som én uke i månedsvisning. Dersom en minimumshøyde blir satt på månedsvisning, vil dermed høyden multipliseres med antall uker som vises, og ta opp svært mye plass, uten å ha informasjon å gjengi. SELECT: Når frivilligansvarlig velger en celle i kalenderen returneres et moment-objekt for både start- og sluttid. Starttidspunktet blir formatert med moment.js sitt API, i to omganger: en gang GUI i lesbart format, og en gang i en global variabel, klar for transaksjon med database. Deretter kalles checkifoccupied(), fra shifter_calendar.js. Denne metoden sjekker valgt dato mot det globale arrayet over synlige arrangement. Dersom valgt dato stemmer overens med et eksisterende arrangement returneres true, og hvis ikke returneres false. Basert på hva metoden returnerer, kaller vi på togglebuttons() med en parameter, som setter knappene i riktig modus. For eksempel hvis du trykker på en dag uten arrangementer, så skal knappen for å registrere nytt arrangement være synlig og klikkbar, men knappen for å redigere eksisterende skal være sperret. EVENTRENDER: Avgjør hvordan individuelle arrangement skal se ut inne i kalenderen. Her overstyres alle parametere slik at kalenderen framkommer etter ønsket design. Blant annet styres tiden manuelt, og formateres gjennom moment.js. Det sjekkes om tiden for arrangement som skal tegnes opp er i fortiden, og hvis

35 Shifter - for Samfunnet Bislett 34 det er det så skal det ha en egen klasse for å kunne farges deretter. Hvert event gis en egen klasse basert på hvilken visning man har, for å kunne velge stil etter kontekst. genereatequickview() kalles fra shifter_calendar.js og skiftet som skal tegnes opp sendes med som parameter (event-objekt). Basert på informasjonen som ligger i event-objektet, genereres HTML-kode for en rad med ikoner. Denne raden visualiserer for bruker hvor mange vakter et skift har, og hvilke som er ledige / tatt. En slik quickview legges til alle events, uavhengig av visning, og på månedsvisning er quickview det eneste som vises. EVENTCLICK: Dette kallet avgjør hva som skjer når et event klikkes, og var tidlig i utviklingsfasen unik for hver visning. Dette ble strømlinjeformet underveis og i endelig versjon er klikk-kallet likt for alle visninger. Et eventklikk skal produsere et dialogvindu, med relevant informasjon, og muligheter for interaksjon basert på brukerens privilegier. Som frivilligansvarlig har man imidlertid alle rettigheter, så et klikk vil ikke medføre noen sjekk mot privilegier og roller. Dersom man ikke har frivilligansvarlig-rollen, vil man aldri kunne laste super/cal, så det er trygt og mye raskere å omgå sjekkene. Når klikket blir foretatt starter en initiering av et dialogvindu, og informasjon blir nesten øyeblikkelig lagt til. Her også et eksempel på «jquery chaining» som brukes mye i vaktlisten. Ved å lenke forskjellige manipuleringer i samme streng (text og append i dette tilfellet), trenger jquery bare å hente elementet fra DOM én gang. GETEVENTINFO() FIGUR 12: JQUERY-CHAINING SOM LEGGER TIL TEKST I DIALOGVINDUET Dialoger er <div>-elementer som ligger i HTML-dokumentet, usynlige. Disse gjenbrukes mange ganger i Shifter, så dermed er det første som gjøres å sette tekst-innholdet i dialogen til blank, i fall det allerede er noe der. Deretter kalles jquery.append på dialogen for å legge til eventinfo, gjennom geteventinfo() fra shifter_calendar.js, med klikket event-objekt som innparameter. geteventinfo() opererer på samme måte som generatequickview(), hvor den tar imot et event-objekt og returnerer html generert på bakgrunn av informasjonen i objektet. FIGUR 13: KODEEKSEMPEL FRA GETEVENTINFO() HVOR MAN SER AT ID BLIR GENERERT Funksjonen lager én div per eksisterende vakt i skiftet, i tillegg til informasjon om tittel, tid og et ikon for visualisering. Når <div>-ene for vaktene lages, sjekker funksjonen først om vakten eksisterer inne i objektet, og deretter settes en id sammen basert på informasjon om vakten. Id-en er en viktig del av logikken bak hvordan vaktlisten håndterer vaktoppføringer og består av: skift-id-en hentet fra databasen deretter en understrek som brukes som avgrensning deretter en tekst som representerer hvilken vakt det er på skiftet.

36 Shifter - for Samfunnet Bislett 35 o s1 er en supervakt / ansvarsvakt. I modulens tidligere iterasjoner eksisterte det opptil flere ansvarsvakter, og dermed har den et tall, men i endelig versjon vil det alltid være én eller ingen ansvarsvakter o v1 er vakt nummer en, v2 er vakt nummer to, osv. deretter en ny understrek for avgrensning deretter id-en på personen som er oppført på vakten. o Dersom det ikke er noen der vil id være lik «undefined» Dermed vil en tom ansvarsvakt på skift nummer 14 i databasen ha id = «14_s1_undefined», og id-en til en opptatt vanlig vakt på samme skift vil kunne se slik ut: «14_v3_26». Til sist sjekkes det for om objektet har et navn tilknyttet vakten. Dersom det er ledig vil «_LEDIG» være navnet, og vakten får klassen «emptyshift». Dersom objektet har et navn er vakten tatt, og får klassen «occupiedshift». Etter at skiftene er laget og tilføyd dialogen, så fjernes noen forhåndsbestemte filter fra vaktene, slik at frivilligansvarlig ikke blir hindret i å operere mot dem. Til slutt åpnes dialogvinduet og viser for brukeren all informasjonen som har blitt generert og tilføyd. Konsollmanipulering Ved siden av klassene som representerer vaktens status som opptatt eller ikke, er det også en klasse for ansvarsskift kalt «supervshift», som brukes for å kontrollere klikkrettighetene til brukeren, slik at kun superfrivillige kan melde seg på ansvarsvakter. Dette er dog kun en hindring for påmelding i GUI, men det ligger også en sperre på serversiden. Dersom en bruker ikke har priviligier til å melde seg på en ansvarsvakt, åpner en konsoll i nettleseren sin og sletter «supervshift»- klassen, vil vakten bli klikkbar for oppmelding, men serveren vil likevel nekte for vaktoppføringen AMIINTHISSHIFT() Når dialogvinduet er åpnet og DOM-elementene eksisterer i visning kalles amiinthisshift() fra shifter_calendar.js, med id til bruker og event-objektet som innparametere. Der samles alle <span>elementer inne i dialogen, og så itereres deres ID over. Funksjonen bruker understrekene som avgrensninger, og kan dermed se om id til bruker matcher <span>-id-en, gjennom å sjekke <span>-id sin substring fra enden og inn, der id til potensielt påmeldt bruker ligger. Dersom bruker finnes oppmeldt på skiftet, vil vakten få klassen «own», og et ikon bak navnet. Klassen brukes for å kunne gi vakten en større font, for å tydeliggjøre for brukeren at den er oppmeldt, i tillegg til å feste en klikklytter. Klikklytteren fester en unik funksjon til brukerens egne oppførte vakt, slik at brukeren kan melde seg av vakten om ønskelig, ved å kalle på dbselfreleaseshift() fra db_transactions.js, med egen id som parameter. Når amiinthisshift() er ferdig kjørt kalles paintdialog() fra dialogs.js, med event-objektets klassenavn som parameter, som styler dialogen slik at det er konsistent farge mellom skiftet i kalenderen og tilhørende dialog. Når dialogvinduet og dens innhold har fått stilen de skal ha, letes det gjennom dialogen etter alle <span>-elementer (vakter) for å feste klikk-lyttere til dem. Et klikk på en vakt vil: Først hente ut Id-en på <span>-elementet. Deretter hentes id til eventuelt påmeldt medlem, ved å hente de siste bokstavene i id-en frem mot første understrek. Dersom id er et tall, betyr det at det er et medlem assosiert med- og påmeldt vakten. Dersom id ikke er et tall, betyr det at id er «undefined», som betyr at det ikke er en tatt vakt. Dersom det klikkes på en vakt med oppført medlem, vil en global variabel

37 Shifter - for Samfunnet Bislett 36 kalt «clickeduser» få id-en til medlemmet, og dersom vakten var tom vil «clickeduser» være null. Deretter scannes id-strengen til <span>-elementet (vakten) etter bokstaven «s» eller «v». Dersom det finnes en «s» der er vakten en ansvarsvakt, og med en «v» i id-en er det en vanlig vakt. Deretter knyttes en ny dialog-åpner til hver span, på lik linje med hvordan dialogen elementene befinner seg i ble initiert, men denne får også knapper, hvorav hver av dem har en funksjon tilknyttet seg: o Avbryt abortnewevent() Tar to strenger som parametere, som er dialog-vinduer den leter etter. Den første strengen er det primære vinduet som skal lukkes, og den andre er et vindu som potensielt er åpent samtidig. I dette tilfelle vil den forsøke å lukke både sitt eget vindu, og skift-vinduet. o Sett ledig dbcommandtoreleaseshift() En «dbcommand-funksjon» er en funksjon som bare kan utføres av noen som har frivilligansvar-rollen, for å manipulere informasjon som angår andre. På grunn av at det utføres en privilegiesjekk er den harmløs hvis noen prøver å kalle på den i runtime for å skade applikasjonen. Den sender skift-id og «clickeduser» (id til klikket bruker) med som parametere, og tar bruker av vakten. Dersom vakten er tom vil det logges i konsollen, uten at noen ytterligere feil oppstår. Deretter kalles abortnewevent(). o Meg selv dbattendshift() Tar brukerens id fra session, sender med variabelen for om vakten er ansvar eller ikke, og skift id. Melder brukeren på vakt. Deretter kalles abortnewevent(). o Annet medlem Laster først inn et loading-spinner ikon i en <div> med id «allvolunteerscontainer», for å indikere at det foregår en lasting. Deretter kalles getallmembersfordialog(), med skift-id og ansvars-variabelen som parameter. Dette returnerer en søkbar liste over alle aktive frivillige (frivillige som ikke har status som inaktiv). Hvert av medlemmene på lista blir levert med en egen klikklytter, som basert på skift-id og ansvarsvariabel sendt med ved generering, knytter en frivillig til en vakt. Til sist, etter at klikklytteren er festet til hver vakt - fyller vi dialogen med tidspunkt og gir den farge og stil med paintdialog(). INIT_CALENDAR() Til sist i initieringen av kalenderen kalles togglebuttons(), for at alle knappene skal starte i inaktiv modus - før brukeren har valgt en dag å operere mot. Deretter kalles init_calendar() fra init_calendar.js, som gir kalenderen en event-kilde og tegne opp skiftene fra.

38 Shifter - for Samfunnet Bislett SENTRALE FUNKSJONER, VARIABLER OG KONSEPTER LOGIKKEN MELLOM SERVER OG KLIENT På serversiden lagres et arrangement i en SQL-database via node.js, gjennom et rammeverk kalt sequelize.js. Der ligger det egne tabeller for arrangementer (Events), egne tabeller for skift (Shifts) med primærnøkkelen til arrangement som fremmednøkkel, osv. I vaktlistemodulen hos klienten eksisterer det ikke arrangementer, i praksis. Kalenderen viser hvert skift som et eget individuelt arrangement. Dermed må arrangementer som skal lagres bli dannet av event-objekter, med ett ytterligere skjult event-objekt som håndterer overordnet informasjon. GLOBALE VARIABLER Det ligger flere globale variabler i runtime for å få logikken i systemet til å fungere. EVENT-OBJEKTER Øverst i shifter_calendar.js ligger fem globale variabler: FIGUR 14: EVENT-OBJEKTER LIGGER SOM GLOBALE VARIABLER Disse representerer alle skift som er i visning i GUI. Dersom et mellomskift legges til i new_eventdialogen, vil et objekt opprettes i bakgrunnen, for at skiftet skal kunne lagres. Dersom man for eksempel velger å redigere et eksisterende arrangement, vil det opprettes ett event-objekt per skift som vises i GUI, og være overensstemmelig med typen skift objecttidlig er event-objektet til et tidligskift. objectevent er noe som ligger i bakgrunnen i runtime, og kun får informasjon dersom bruker velger å lagre noe. Da organiseres informasjonen slik at alle skift som lagres tilhører «objectevent», og deretter sendes det til serveren for dekoding og lagring i databasen, i individuelle tabeller. TRACKER-VARIABLER Det ligger globale tracking variabler som lar dialogvinduer og funksjonskall tilpasse sitt innhold gjennom et kall på controldialogcontent(). Dersom «templatetracker = true», skal all informasjon som er unødvendig for konteksten sløyfes, og spesifiserte felter skal legges til. FIGUR 15: GLOBALE TRACKER-VARIABLER

39 Shifter - for Samfunnet Bislett 38 EDITEVENTID En variabel som ligger globalt, og oppdateres hver gang brukeren trykker på edit-knappen. Dette er nødvendig fordi arrangements-id ligger knyttet til skiftene, og det er ingenting som stopper en bruker fra å slette alle skift, i en redigeringsprosess, noe som kan føre til at ID blir tapt. Ved å la id-en ligge globalt i runtime, er det sikkert at eventet som redigeres også er eventet som blir skrevet til. HANDLEOBJECTS() Tar imot et objekt og et typenavn som parameter, og setter innparameter-objektet til riktig globalt skift-objekt. MAKESKIFT() Tar imot et objekt sletter eksisterende skift av samme type gir objektet til handleobjects() for at det skal legges til i et globalt skift-objekt genererer HTML basert på det, og tilføyer HTML-koden til en <div> i et dialogvindu. Hvert skift som genereres får en skjult slett-knapp med en individuelt tilpasset klikk-lytter. Lytteren kaller på tailoredremove() med skiftets klassenavn som parameter. TAILOREDREMOVE() ADDOBJECT() Kalles bare av makeskift(). Tar imot en skift-type, kjører typen gjennom en switch-case, og kaller på deletethistype (), med typen videresendt som parameter. Grunnen til at slett-knappen ikke går direkte til deletethistype (), er at tailoredremove() også har ansvaret for å tilpasse knappetekst, og å slette det eventuelle objektet fra dens globale variabel. Funksjonen som kaller på makeskift() i de fleste tilfeller, og kalles når brukeren legger til eller redigerer et skift manuelt. addobject() tar brukerens input i new_shift-dialogen, lager et objekt av det, og sender det videre til makeskift(), som først gir objektet til handleobjects() og deretter lager skiftet i GUI. STOREEVENT() FIGUR 16: GLOBAL VARIABEL FOR Å HA KONTROLL PÅ EVENTID FOR REDIGERING shifter_calendar.js sin største funksjon på 200 linjer, som manøvrerer databasetransaksjoner for både redigering av event, lagring av nye event, og lagring av maler basert på hvilken «tracker-variabel» som er gjeldende. Håndterer også input-validering. Felles for alle, uavhengig av «tracker-variabel» er at den danner et array kalt «objectarray», og pusher inn alle globale skift-objekter som har fått verdi. I denne prosessen telles en hjelpe-variabel opp for hvert objekt som har verdi, og dersom variabelen er høyere enn 0, lar funksjonen brukeren gå videre, da det betyr at brukeren har lagt til skift i arrangementet. Det gjøres også sjekk på andre felter på lik måte med en hjelpe-variabel, for tittel / mal-tittel og dato. Dersom alle inndata-validering er ok, settes et globalt arrangement-objekt kalt «objectevent» med variabler. Denne metoden vil bli ytterlig beskrevet for hver funksjon som benytter den henholdsvis maler, edit event og new event.

40 Shifter - for Samfunnet Bislett SUPER/CAL KNAPPER Det er fire knapper som er unike for frivilligansvarlig Delete Maler Edit New Alle bortsett fra delete kaller på en dialog for å fylle den med meningsfullt innhold. Maler, edit og new kaller alle på samme dialog, og på samme html-dokument for å populære dialogen. For å håndtere spesifisert informasjon til konteksten dialogen kalles i har alle knappene med unntak av «New» globale «trackervariabler». Dette betyr at rett før «Edit» ber om å åpne dialogen, settes «edittracker = true», og dialogen kan manipulere informasjon på bakgrunn av dette. DELETE Når en dag på kalenderen blir trykket på, oppdateres en global variabel kalt storingdate med trykket dato, i et ISO 8601 format. Dersom checkifoccupied() returnerer true, vil delete-knappen kunne trykkes. Når knappen trykkes på henter og laster funksjonen $.getscript inn fetch_events.js. $.getscript er et asynkront kall, som henter og kjører alle linjer med kode i et JavaScript-dokument. Dersom «deletetracker = true» når fetch_events.js kjøres så vil den overse kode som ber om å hente skift inn i et dialogvindu for redigering. Det som derimot kjøres er geteventsbyfilter(), som setter en global variabel kalt myevents til å inneholde alle skift fra klikket dag. I callback-funksjonen til $.getscript settes «deletetracker = false» igjen, og deretter kalles dbdeleteevent() med to funksjoner som parametere, som igjen tar variabelen myevents som parametere (returnidforremoval(myevents) og returnnameforremoval(myevents)). dbdeleteevent() ber så brukeren om å bekrefte slettingen, med navnet til eventet spesifisert i forespørselen. Dersom brukeren bekrefter slettingen, sendes en «DELETE AJAX-request» til serveren med url som peker på eventet. I successcallback til AJAX-kallet kaller den først på removeeventsources(), for å tømme kalenderens event-kilde, og deretter på reloadsources() som sender en «GET AJAX-request» til serveren med url som peker på alle events. I retur kommer et array, som mates til init_calendar(), som setter kildeobjektet til kalenderen på ny, med den oppdaterte informasjonen. For å visualisere alle JavaScript-filene og funksjonene som er involvert i denne funksjonen, referer til sekvensdiagrammet (se Appendix E: ). MALER Maler-knappen er alltid tilgjengelig, da den ikke er avhengig av valgt dato. Malene i vaktlisten kan lages og slettes inne i maler-dialogen, og kan benyttes når det skal opprettes et nytt arrangement. På lik linje med delete-funksjonen setter funksjonskallet på maler-knappen en «tracker-variabel» til true. I dette tilfellet «templatetracker». Deretter tømmes dialogvinduet, og new_event.html lastes inn i dialogen via ruten./event. I new_event.html kalles controldialogcontent() i første linje, som sjekker hvilken «tracker-variabel» som er gjeldende og skjuler / viser innhold basert på det. I dette tilfellet er «templatetracker» true, så da vil: Tittelen settes til «Maler» «templatetitlediv» som rommer tittelen til en mal blir vist Lukk-knappen får teksten «Lukk» i stedet for «Avbryt» Gjentakelse-, dato- og tittel-boksene skjules Deretter settes en klikk-lytter på valgboksen til malene til å kalle på getfromtemplate(), med verdien i boksen som parameter. Til sist kalles gettemplatesfromdb(), som laster inn alle malene som ligger lagret på serveren. POPULATETEMPLATELIST()

41 Shifter - for Samfunnet Bislett 40 gettemplatesfromdb() sender et AJAX-kall til serveren og får en JSON-streng tilbake, som inneholder alle malene som er lagret. I callback-funksjonen til AJAX-kallet settes objektet fra serveren til en global variabel kalt «alltemplatesjson», som rommer alle templates i runtime. Deretter kalles populatetemplatelist(), med «alltemplatesjson» som parameter. FIGUR 17: POPULATETEMPLATELIST SOM OPERERER MOT OBJEKTNØKLER Ettersom alle malene kommer som en sammenhengende JSON-streng, og bare deles opp til individuelle maler, har ingen av malene en unik id assosiert med seg. Dermed må populeringen av mallisten generere <option>-elementer med objekt-nøklene. Hver <option> får navnet til template både som value, og som tekst. For å sikre at maler ikke lagres flere ganger med samme navn itereres dermed navnene over når man forsøker å lagre en mal, og bruker blir stanset med feedback dersom navnet eksisterer. FIGUR 18: EKSEMPEL PÅ AT BRUKER BLIR STANSET DERSOM DEN FORSØKER Å LAGRE TO MALER MED SAMME NAVN GETFROMTEMPLATE() Det samme gjelder også når skift-listen skal genereres, som skjer når brukeren trykker på en mal. getfromtemplate() kalles og itererer over navnene i alltemplatesjson, og når den finner riktig mal-objekt genereres skiftene via makeskift(), med mal-objektet som parameter. Ettersom at navnene i select-listen er generert fra samme objekter som man itererer over, er det garantert at navnet eksisterer i mal-arrayet. Når bruker velger en mal fra listen, vil den først kalle på emptyobjects(), for å tømme alle globale skift-objekter. Dersom dette ikke blir gjort, risikerer man at verdier fra en mal-lagring bærer over til den neste, fordi det ligger objekter i runtime som storeevent() leser verdier fra. Deretter kalles resetdialog(), som nullstiller alle verdiene i dialogvinduet, for å signalisere for brukeren at verdiene har blitt flyttet fra GUI, og inn i serveren. Dersom «templatetracker = true» betyr det at malen ble klikket på i maler-dialogen, og det tilføyes en slett-knapp med klikk-eventet deletefromtemplateregister(). DELETEFROMTEMPLATEREGISTER(). Denne slett-metoden fungerer asynkront, slik at det er usynlig for bruker når den kontakter server. Den tar heller ikke imot noen parameter, men støtter seg til verdien fra <option>-elementet i <select>boksen, som er navnet til malen på lik linje med getfromtemplate(). Etter å ha hentet navnet på malen som skal slettes, lager den en variabel kalt «index», og setter verdien til 0. Denne skal telles opp

42 Shifter - for Samfunnet Bislett 41 for hver gang funksjonen itererer over alle malene, slik at vi kan vite plasseringen til den respektive malen i arrayet. FIGUR 19: DELETEFROMTEMPLATEREGISTER(), SOM FUNGERER ASYNKRONT Funksjonen spør etter et objekt som har navn lik verdien i <option>-elementet frem til at den kommer over et objekt av forespurte attributter som eksisterer. Deretter splices arrayet basert på indexen, og en fram, for kun å slette den valgte malen. Index må leveres til splice-funksjonen som «index -1», da arrayet begynner å telle fra «0», og index får verdien «1» fra første element. Deretter kalles dbdeletefromtemplate() som sender en «POST AJAX-request» til serveren med url som peker rett inn på JSON-strengen på serveren, og overskriver den. I success-callback til AJAX-kallet kaller den først på resetdialog(), for å signalisere for brukeren at verdiene har blitt flyttet fra GUI, og inn i serveren, og deretter på populatetemplatelist() igjen, som setter kildeobjektet til malene på ny, med den oppdaterte informasjonen. Som nevnt tidligere aksesserer ikke populatetemplatelist() serveren, men heller det globale arrayet over templates, slik at resultatet blir tilgjengelig øyeblikkelig. Til sist kalles emptyobject(), på lik linje som i getfromtemplate(), for å unngå at noen objekter skal bære verdier, og aksesseres bak kulissene. getfromtemplate() itererer til sist over objektene via navnet, på samme måte som deletefromtemplateregister(). Når objektet er funnet settes GUI-elementer som lås og type, til å stemme overens med malen som ble klikket på. Til sist sendes hvert skift fra mal-objektet som parameter til makeskift(), som lister alt ut i GUI og håndterer de globale skift-objektene.

43 Shifter - for Samfunnet Bislett 42 STOREEVENT() TEMPLATETRACKER = TRUE Dersom man trykker på lagre-knappen i maler-dialogen, vil storeevent() kalles med «templatetracker = true». Den første sjekken som blir gjort er om navnet på malen som lagres er unikt. Dette sjekkes i likhet med alle overnevnte metoder, med navn mot det globale template-arrayet. Som forklart under Sentrale funksjoner, variabler og konsepter telles en hjelpe-variabel opp for hver mangel, og en respons på manglene blir produsert i GUI, i form av rød bakgrunnsfarge bak feltet som mangler, og hindring fra å lagre malen. Dersom begge hjelpe-variablene oppfyller kravene betyr det at brukeren har fylt ut nødvendig informasjon, og storeevent() vil iverksette behandling av event-objektet for lagring. Da legges overordnet informasjon om tittel, type, dato og låsestatus. Hvert av skiftene behandles så for å sørge for at datoen som lagres er av ISO 8601-standard, alt legges inn i et array kalt «objectarray», og til sist er det klart for å kalle på dbexporttemplate(), med «objectarray» som parameter. DBEXPORTTEPLATE() Først sjekker funksjonen det globale mal-arrayet etter innhold. Dersom det er ikke er satt med verdi vil det være en tom streng, og da settes den til et tomt array. Deretter nøstes alle malen inn i et større objekt slik at det får sitt navn fra brukerinput. Til siste pushes malen - med navnet inn i det globale mal-arrayet, som også rommer alle andre potensielt eksisterende maler. Når det ferdige objektet er satt sammen, blir det omdannet til en JSON-streng og sendt med en «POST AJAX-request» til serveren. I AJAX-kallets success callback, nullstilles mal-dialogen, og mal-listen blir repopulert med det nye innholdet. FIGUR 20: LAGRING AV EN MAL MED DBEXPORTTEMPLATE

44 Shifter - for Samfunnet Bislett 43 EDIT Edit-knappen er synlig og klikkbar dersom bruker har valgt en dag og checkifoccupied() returnerer true. Ved å trykke på knappen så settes «edittracker = true», og et dialogvindu laster inn new_event.html. Som beskrevet i punktet om «Delete», vil geteventsbyfilter() ta imot Vinduet får innholdet sitt moderert av controldialogcontent(), på samme måte som template-dialogen på bakgrunn av «templatetracker». Fordi «edittracker = true», kjøres en $.getscript, som laster inn fetch_events.js. Fordi «deletetracker = false» vil fetcheditable() kjøres med myevents som parameter (myevents er det globale arrayet som rommer alle events assosiert med valgt dato). Deretter settes tittelen i dialogvinduet lik navneattributtet til det første eventet som står oppført i myevents. FETCHEDITABLE() Itererer over alle elementer i myevents, og fører verdier fra arrayet over i lokale variabler, som deretter brukes til å generere et objekt «returnobject». makeshift() kalles til sist for å lage skift i GUI og sette verdier til de globale event-objektene, med «returnobject» som parameter. fetcheditable() har også ansvaret for å gi «editeventid» en verdi, slik at eventet som redigeres på kan lagres på riktig plass. STOREEVENT() EDITTRACKER = TRUE Dersom man trykker på lagre-knappen edit-dialogen, vil storeevent() kalles med «edittracker = true». Den gjør alle de samme kallene og valideringene som «new event» ville gjort. Det eneste som er unikt for redigering er at dbeditevent() kalles, og tar imot to parametere: objectarray, på lik linje med «templates» og «new event», og den globale variabelen «editeventid». FIGUR 21: DBEXPORTEVENT, UTSNITT AV AT DEN GENERERER OBJEKT FOR LAGRING Funksjonen genererer deretter et arrangement, med «editeventid» som id, og gjør en «PUT AJAXrequest», som ber om å overskrive arrangementet med id-en som blir sendt med. Dersom det er noen ført på en vakt på arrangementet vil oppføringen forsvinne, da dette kallet sletter alle skift med tilknytning til arrangementet, og genererer nye.

45 Shifter - for Samfunnet Bislett 44 NEW Hovedoppgaven til vaktlistemodulen er å opprette arrangementer, som er mulige å manipulere med vaktoppføringer. Knappen for å opprette et nytt arrangement blir tilgjengelig og klikkbar dersom brukeren velger et felt i kalenderen som ikke har noen arrangementer fra før av. Når knappen trykkes initieres et dialogvindu, og new_event.html lastes inn, på lik linje med både edit og templates. Den store forskjellen er at denne ikke setter noen «tracker-variabler», og dermed skjules ingen elementer. New event har muligheten til å opprette hele arrangementer fra forhåndlagde maler, og deretter gjenta eventet i x antall måneder eller uker. LEGG TIL / ENDRE SKIFT Dersom en bruker klikker på «legg til / endre skift» kalles funksjonen openshiftdialog() åpnes nok et dialogvindu, parallelt med new_event-dialogen. Dette stemmer også både for templates og edit event. Den nye dialogen laster inn new_shift.html, som inneholder elementer for at brukeren skal kunne lage skift for å legge til sitt arrangement. Øverst er et input-felt med radio-knapper, der knappene er skjulte. Det som vises er <label> til tilhørende knapper, som er stylet, og som håndterer om knappene blir klikket. Input-validering her er ikke valgt type ikke valgt tid Start-tiden er før slutt-tiden, samtidig som start-tiden er mer en 07:00. o Dette skyldes at en ny dag regnes for å starte kl. 07:00 dagen etterpå. Dette er for å tillate at en vakt for eksempel kan gå fra 22:00 03:00. Ikke valgt hverken ansvar eller frivillig. Også her vil manglende input resultere i en rød bakgrunnsfarge på de elementene med mangler. Når riktig antall skift med riktig informasjon er lagt til, kan bruker velge å lagre eventet. GJENTAKENDE EVENTS FIGUR 22: NEW_SHIFT.HTML

46 Shifter - for Samfunnet Bislett 45 En unik funksjon ved å lage nye arrangementer er når det skal opprettes nye events har brukeren muligheten til å trykke på en knapp for å gjenta oppføringer. FIGUR 24: ELEMENTET FOR GJENTAKELSE ER SKJULT FØR KLIKKING FIGUR 23: ELEMENTET FOR GJENTAKELSE VISES ETTER ET KLIKK Dersom dette valget er på når brukeren trykker «Lagre», vil storeevent() håndtere dette på en interessant måte.

47 Shifter - for Samfunnet Bislett 46 STOREEVENT() INGEN TRACKER-VARIABEL Når storeevent() kalles uten tracker-variabel vil to funksjoner som deklareres i starten av storeevent() bli gjeldene: FIGUR 25: FUNKSJONSKALL FOR Å KUNNE HOPPE FREM I TID VED LAGRING AV GJENTAKENDE EVENTS Det defineres to funksjonskall, en for å hoppe uker frem, og en for å hoppe måneder fram. Funksjonene adderer startdatoen x antall spesifiserte uker eller måneder frem, via innparameteren. Etter at all inputvalidering er gjort, og tid og dato er konvertert til ISO 8601-format, sjekker funksjonen om eventet skal ende etter klokken 00:00. Dersom dette er tilfelle adderes én dag til sluttdatoen. Deretter sjekker storeevent() for om en checkbox med id «repeat» er satt. Dersom den er det betyr det at brukeren ønsker å gjenta arrangementoppføringen. Deretter hentes verdier fra feltene inne i gjentakelseselementet for å avgjøre om det skal gjentas ukentlig eller månedlig, og hvor mange ganger det skal gjentas. Deretter defineres to spesialiserte globale variabler: «globalqueue» - som settes lik antallet ganger brukeren ønsker å gjenta, og et array kalt «globaldbarray», som event-objektet som skal lagres blir pushet inn i. Deretter lages dype duplikater av arrayet, som betyr at den ikke bare kopierer minnelokasjonen til variabelen, men oppretter en helt ny uavhengig lokasjon med samme verdier: FIGUR 26: DYP DUPLISERING AV ARRAY

48 Shifter - for Samfunnet Bislett 47 Dupliseringen lager samme antall kopier som antall ganger brukeren ønsket å gjenta oppføringen, med økende tall i variabelnavnet. Deretter ser storeevent() etter alle potensielt skapte duplikater, for å bruke funksjonene som ble definert tidligere, for å hoppe frem i tid. FIGUR 27: SJEKKER GJENNOM ALLE POTENSIELT SKAPTE DUPLIKATER, OG SKYVER DEM FRAM I TID Hvis objectarray1 eksisterer, skal den hoppe 1 uke frem i tid, hvis objectarray2 eksisterer, skal den hoppe 2 uker frem i tid osv. I funksjonen skipweeksahead() pushes alle mottatte arrays inn i det globale arrayet «globaldbarray». Når alle duplikatene som eksisterer har fått tiden sin stilt fram og blitt pushet inn i arrayet, kalles dbexporteventqueue() med «globaldbarray» og «globalqueue» som parametere. I denne funksjonen kan brukeren potensielt sett lagre 10 komplekse arrangementer, og siden AJAX-kall er asynkrone skjer disse lagringene på uvisse tidspunkt. Dersom serveren får flere AJAX-forespørsler på rappen fra samme klient uten å ha rukket å gi en respons vil serveren bryte oppkoblingen og et uvisst antall forespørsler vil bli avbrutt. For å håndtere dette på en stabil og konsekvent måte har dbexporteventqueue() blitt til. Her brukes en spesiell programmeringsteknikk kalt «promises». «Promises» representerer en handling som enda ikke er gjennomført, men som forventes å bli fullført en gang i fremtiden. Med «promises» kan man dermed iverksette en handling, og vente til løftet er fullbyrdet, før man går videre. Dette fungerer utmerket, og er designet for å fungere med asynkron programmering.

49 Shifter - for Samfunnet Bislett 48 DBEXPORTEVENTQUEUE Det første denne funksjonen gjør er å legge et loading spinner ikon til dialogen, for å vise for brukeren at en databasetransaksjon foregår. Som regel tar denne operasjonen med maksimalt antall inputs under ett sekund, men det er tatt høyde for at serveren kan ha økt responstid utenfor vår kontroll, og dermed gir vi brukeren en visuell tilbakemelding på at det foregår noe. dbexporteventqueue() er en loop som går mellom 3 forskjellige funksjoner. 1. dbexporteventqueue tar imot array med objekter for lagring og den globale telleren. Dersom telleren er høyere enn -1 betyr det at det er eventer igjen i arrayet som venter på å bli lagret. dbexporteventqueue() danner dermed et ferdig arrangement med «objectevent» for overordnet informasjon, sammen med «objectarray» av samme nummer som den globale telleren. Det ferdige objektet sendes deretter til thepromise() gjennom innparameter. 2. thepromise() sender objektet til thecall(), hvor AJAX-kallet finner sted. Her sendes objektet til serveren. thepromise() går deretter IKKE videre, før thecall() har kommet med en responsmelding fra serveren. 3. thecall() sender respons på at objekt er lagret i databasen 4. thepromise() teller ned den globale telleren, og kaller dbexporteventqueue() om igjen, med «globaldbarray» og «globalqueue» som parametere. Ettersom «globalqueue» gradvis telles ned, vil den til slutt bli -1, etter å ha lagret det siste eventet. FIGUR 28: HVORDAN DBEXPORTEVENTQUEUE SIN FUNKSJONSLOOP FUNGERER Når «globalqueue» er -1 blir funksjonsløkken brutt i dbexporteventqueue(), og nettleseren får deretter beskjed om å laste siden om igjen, for å kunne tegne opp de nye eventene på riktig måte.

50 Shifter - for Samfunnet Bislett /CALENDAR Kalendervisningen i /calendar er den grunnleggende versjonen. Denne har ingen funksjonsknapper foruten å navigere seg frem og tilbake i tid. Det den vanlige frivilligkalenderen derimot har er noen sjekker for å håndtere hvilke privilegier brukeren har. EVENTCLICK: Først settes fem variabler til false. Disse kontrolleres for å håndtere hvilket privilegienivå brukeren har, FIGUR 30: VARIABLER SOM SETTES I VANLIG FRIVILLIG SIN EVENTCLICK og hvilken sperre som skal ligge på skiftet. Først kontrolleres brukerens rolle. Dersom brukeren har rolle 4 i databasen settes «teknikerpriv = true» da dette betyr at brukeren har tekniker-rollen og dermed teknikerprivilegier. Dersom brukeren har rolle 5 i databasen settes «superpriv = true» da dette betyr at brukeren har superfrivillig-rollen og dermed super-privilegier. Deretter sjekker klikket klassen til eventet som ble klikket. Som beskrevet i super/cal vil eventrender: avgjøre om skiftet er i fortiden eller i fremtiden, og hvor nært det er. Dersom skiftet har rollen «fortyeight» betyr det at det er mindre enn 48 timer til skiftet starter, og brukere kan dermed ikke melde seg av vakter uten hjelp fra frivilligansvarlig. Dersom skiftet har rollen «past_event» betyr det at det er i fortiden, og brukere kan dermed ikke melde seg på eller ta seg av vakter uten hjelp fra frivilligansvarlig. Dersom skiftet har rollen «started_event» betyr det at skiftet er på samme dag, men allerede påbegynt, og brukere kan dermed ikke melde seg på uten hjelp fra frivilligansvarlig. Over disse sjekkes det også for om skiftet er låst, noe som vil gjøre at brukere ikke har tilgang til oppmelding uten å være et styremedlem. FIGUR 29: 4 SJEKKER SOM AVGJØR OM BRUKEREN KAN MELDE SEG PÅ EN VAKT Til slutt kalles amiinthisshift(), og dersom den returnerer true, eller skiftet er låst, eller skiftet er i fortiden, eller allerede startet, så slettes den klikkbare klassen fra vaktene, slik at brukere ikke kan melde seg på. På lik linje med «supervshift» som ble beskrevet i super/cal er dette bare en front-end sperre. Dersom brukeren manipulerer JavaScript i runtime for å gjøre klassene klikkbare, vil det likevel være en blokkert handling fra serversiden. Til sist påføres 4 varsel-meldinger til brukeren som gir en semantisk tilbakemelding til brukeren dersom det skulle bli forsøkt å trykke på ugyldige vakter. SYNLIGHET PÅ KLASSENE Dersom et skift er låst eller begrenset til teknikere, vil det legges til en tydelig gul boks med ikon og tekst som forklarer at skiftet er avsatt for inviterte. Det kom likevel fram under testing at den gule boksen lett blir oversett, så dermed ligger det et kall i koden som får boksene til å blinke to ganger, slik at øynene til en bruker blir dratt mot endringen. FIGUR 31: KORT KODELINJE FOR Å LA VARSELBOKSER BLINKE TO GANGER

51 Shifter - for Samfunnet Bislett MODUL: PROFIL Denne modulen viser brukerens informasjon, roller, gjennomførte og kommende skrift, samt progresjonsbar for frivilligpris. Visningen for modulen er det samme for alle brukere uavhengig av roller, den eneste forskjellen er hva som blir vist. GENERELL INFORMASJON INFORMASJON OM BRUKEREN Alt av informasjon blir hentet fra databasen om den frivillige. I modellen «Volunteer» ligger all informasjon om brukerne. I motsetning til dokumentene hentes kun et volunteer-objekt fra databasen. Dette gjøres med $.getjson-metoden i getprofile(). I getprofile() trigges setshowvalues(), og denne funksjonen setter verdier til alle HTML-elementene. Dette gjøres ved jquerys.html()-funksjon. I setshowvalues() håndteres alle verdiene hver for seg. Den generelle informasjonen som navn, epost, mobiltelefon og fødselsdato blir ikke endret når det vises på skjermen. ROLLEVISNING For visningen av rollene sjekkes det for mange roller det finnes i arrayet Roles som blir sendt med Volunteersobjektet. Roles inneholder de forskjellige rollene med beskrivelse og id. De ordinære rollene blir fordelt slik: - Frivillig: ID = 3. - Superfrivillig: ID = 5. - Styremedlem: ID = 7. - Frivilligansvarlig: ID = 8. Brukerne kan også bli flagget med tilleggsroller: - Begrenset bruker: ID = 1 - Tidligere styremedlem: ID = 2 - Tekniker: ID = 4 - Barbruker: ID = 6 Rollene blir satt i Frivilligadministrator-modulen, og vil gjenspeiles for brukeren på profilsiden. FIGUR 32: SJEKK FOR Å FINNE BRUKERENS ROLLER Rollene blir sjekket ved å gå igjennom en for-løkke vist i Figur 32. For å klargjøre hvilket rolleikon som skal vises på profilsiden, itereres det over Roles-arrayet for å finne den høyeste id-en.

52 Shifter - for Samfunnet Bislett 51 FIGUR 33: TILDELING AV IKONER OG BESKRIVELSE Som vist på Figur 33 sjekkes «largest» for å tilegne riktige ikoner og tekst. «role» blir så lagt inn i et <div>-element på forsiden med id «rolescontainer». Dette elementet inneholder klasser fra Bootstrap ordner div-en inn i kolonner som setter ikonene ved siden av hverandre hvis brukeren har en ordinær rolle og tekniker, og hvis det kun er ett ikon vil dette bli sentrert. PROGRESJONSBAR Brukernes frivilligpris vises på skjermen ved bruk av Angular UIs progressbar-api. Dette API-et viser en progresjonsbar på skjermen og ved bruk av Bootstrap vil man kunne tilegne attributtene Bootstrap-klasser for diverse stylinger. Frivilligprisen blir hentet asynkront ved $http.get mot databasen, og håndtert før den vises på skjermen. Figur 34 viser hvordan frivilligprisens verdi blir håndtert før visning. Variabelen «type» representerer Bootstraps fargekoder for bakgrunnsfarger, og blir tilegnet etter hvor positivt prisen er imot indikerer permanent frivilligpris og gir automatisk grønn farge på den gjenstående nedtellingen. Hvis prisen er over 20, blir fargen grønn, under 20 blir fargen blå, under 10 blir fargen gul og under 5 så vil fargen være rød. Progressbaren består av to <span>-elementer som dekker hver sin del av selve progressbar-containeren. Maks størrelse på baren er satt til 30, og dermed vil span-elementet til venstre dekke hele ved full frivilligpris. Hvor mye hver span skal dekke blir bestemt ved å finne antall dager igjen av prisen minus maks antall dager. Siden disse verdiene blir hentet av Angular, legges verdiene i $scope.daysgone og daysleft. DaysLeft viser antall dager brukeren FIGUR 34: TILDELING AV BAKGRUNNSFARGE PÅ PRGOGRESSBAR har igjen av frivilligprisen, mens daysgone viser hvor lenge det er siden forrige vakt. I sammenheng med dette vises også tekst inne i span-elementene. Hvis det er under 8 dager igjen av frivilligprisen, eller det har gått mindre

53 Shifter - for Samfunnet Bislett 52 enn 8 dager siden man fikk frivilligpris, vil tekst bli byttet ut kun med tall etter hvilken side progressbaren viser minst. KOMMENDE OG GJENNOMFØRTE SKIFT Skiftene brukeren har satt seg opp på eller gjennomført vises nederst i to egne tabeller inne i en felles container. Denne containeren inneholder kolonne-klasser fra Bootstrap, og dette medfører at gjennomførte skift havner under kommende skift ved visning på mobil. FIGUR 35: SORTERING AV ARRAY MED KOMMENDE SKIFT Skiftene blir hentet fra databasen og håndtert på klientsiden i profile.js. Det opprettes to typer array, en for kommende og en for gjennomførte. Arrayet med kommende skift blir først sortert som vist i Figur 35 slik at det skiftet som er nærmest dagens dato havner øverst, mens den vanlige returen fra $.getjson forblir ubehandlet. Deretter blir begge arrayene iterert over av $.each. Løkkene er nesten identiske, men kommende skift blir lagt til i retnew hvis skiftets sluttid ikke er etter tidspunktet koden kjøres.!moment(now).isafter(end) returnerer da true hvis det er kommende. Denne sjekken blir motsatt på gjennomførte skift, hvor det sjekkes om skiftet er etter tidspunktet koden kjøres. Grunnen til at det blir kjørt igjennom to løkker er at om det hadde blitt iterert igjennom med kun det som ble returnert fra serveren, ville resultatet blitt at det neste kommende skiftet hadde havnet nederst, mens gjennomførte skift ville fått ønsket visning. Motsatt ville det blitt å iterere igjennom det sorterte arrayet for begge tabellene, hvor neste skift ville havnet øverst, mens det skiftet som ble avsluttet sist ville havnet i bunn av tabellen. INAKTIV BRUKER En bruker kan når som helst sette seg selv som inaktiv bruker, og tilbake igjen hvis de skulle ønske det. Knappen «Gå inaktiv» trigger profileretired(), og denne sender et AJAX-kall til serveren. FIGUR 36: ENDRING AV STATUS TIL INAKTIV Som vist på Figur 36 settes feltet til volunteer-objektet til true hvis brukeren setter seg til inaktiv. Den samme koden blir kjørt hvis brukeren er inaktiv, og skal gjøre seg selv aktiv. REDIGERING AV PROFIL Brukerne har mulighet til å endre sin egen profilinformasjon, og dette gjøres i edit.html i mappen «views/profile». Når dokumentet har lastet ferdig kjøres seteditvalues() fra profile.js, og denne funksjonen tilegner alle inputfelt med brukerens data fra databasen, samt brukerens profilbilde. Det er også mulighet for brukeren å endre profilbilde. LAGRING AV DATA

54 Shifter - for Samfunnet Bislett 53 Etter at brukeren har fylt ut feltene med ønsket data, trigges funksjonen edituser(). Innenfor denne funksjonen blir all data validert og kontrollert før det blir sendt med til databasen. Brukeren kan sette seg som student, og ved å gjøre dette vises en <select> og brukeren kan velge skole. Hvis student er huket av, og selecten over skole viser «Velg skole», blir den satt til tom. Det samme gjelder også for fakultet. REGEX-VALIDERING Før editprofile() kjøres, gjennomføres det en RegEx-validering av alle feletene i formen på edit.html. Det er satt inn spesifikke RegEx-sjekker for hvert element som brukeren kan legge inn fritekst. Alle sjekkene må beståes før «Lagre»-knappen kan initialiseres. Hvis RegEx-testen slår feil, vil det aktuelle inputfeltet få en rød ring med en X til høyre, og hvis teksten går igjennom vil det bli en grønn ring med en grønn V til venstre. Liste over alle RegEx-strenger benyttet i valitation.js: Fornavn: /^([\S].{0,28}[\S]) [a-za-zæøåæøå]$/ Validerer hvis forbokstav er stor, kan inneholde mellom 0 til 28 tegn, og inneholde store og små bokstaver fra A til Å. Etternavn: /^([\S].{0,28}[\S]) [a-za-zæøåæøå]$/ Validerer hvis forbokstav er stor, kan inneholde mellom 0 til 28 tegn, og inneholde store og små bokstaver fra A til Å. Telefonnummer: /(^(\+ 00)?([0-9]{8,20})$) ^$/ Validerer hvis telefonnummer er tomt, kan starte med 0047 eller +47, og inneholder 8 til 20 tegn fra 0 til 9. /^([a-za-z0-9_\.\-])+\@(([a-za-z0-9\-])+\.)+([a-za-z0-9]{2,4})+$/ Validerer hvis ord inneholder store og små bokstaver fra A til Z samt tall fra 0 til 9, samme validering samt landskode på domene fra 2 til 4 bokstaver. Postnummer: /(^\d{4}$) ^$/ Validerer hvis teksten inneholder 4 tall fra 0 til 9. HÅNDTERING AV DATA TIL DATABASE Datoen blir i databasen lagret som et date-objekt, og for å øke lesbarheten konverteres måned fra tekst til nummer. Dette gjøres ved å sjekke hvilket tall som ligger i måneds-selecten, og tallet blir lagt i «monthnumber». For å generere hele datoen blir dag, måned og år slått sammen før det videre blir sendt til databasen. En slik sjekk blir også gjennomført på student og om brukeren er mann og kvinne. Videre blir alt lagt inn i et JSON-objekt som blir sendt til databasen via et AJAX-kall. Videre sjekkes det for om det har blitt lastet opp et nytt bilde i fil-inputen. Hvis denne inputen inneholder en verdi vil bildet bli lagt inn i et FormData-objekt for at Formidable kan parse og finne profilbildet i filehandler.js. FIGUR 38: VALIDERING AV SKOLE OG FAKULTET FIGUR 37: MANUELL KONVERTERING AV MÅNED FOR VISNING

55 Shifter - for Samfunnet Bislett 54 FIGUR 39: HÅNDTERING AV FILTYPE OG STØRRELSE PÅ PROFILBILDE Profilbildet blir behandlet og sjekket om filtypen enten er.png og.jpg som vist på Figur 39. Dette er for å forhindre brukere fra å legge inn filer som ikke er bilde. Dette blir gjort ved modulen «gm», som også kan skalere ned bildet til satt størrelse på 250 piksler. Skaleringa blir gjort med gm.resize() og sørger for at bildet ikke tar unødvendig stor plass i databasen, samt at det ikke vil blir forvrengt når det vises på profilsiden. Etter at bildet har blitt komprimert og skalert vil det bli lastet opp på serveren. Bildet får brukerens id som navn, noe som gjør at det blir lettere å hente dette opp når det skal vises. Det gjør det også mulig å finne det igjen og knytte det opp til brukeren når det skal endres MODUL: MEDLEMSREGISTER Medlemsregisteret er en av hovedfunksjonaliteten til frivilligansvarlig på Shifter. Det er her alle medlemmer vises, enten de er godkjente, bannlyste, inaktive eller med begrenset tilgang. Frivilligansvarlig kan velge å godkjenne, arkivere eller slette begrensede brukere, endre roller og sette aktive medlemmer til inaktive, samt vise profilen til alle INFORMASJON OM BRUKEREN Listingen av frivillige skjer i to separate funksjoner, getallmembers() og getexisting(). Hentingen av nye medlemmer skjer ved et $.getjson-kall til serveren som henter ut objektet alle nye medlemmer ligger. Objektet blir så iterert over for å kunne tilegne valg som å vise profil, arkivere, slette eller godkjenne. Knappen for sletting blir kun generert hvis den aktuelle brukeren ikke har kommende skift lagret i sitt objekt. Dette blir sjekket siden alle eksisterende medlemmer havner i denne listen etter å ha blitt gitt begrenset tilgang. Dette for at det ikke skal være mulig å slette brukere som er satt opp på skift.

56 Shifter - for Samfunnet Bislett 55 For å knytte knappene til objektene blir det satt lytter som ser etter om knappen med klassen «member_view» blir trykket, som vist på Figur 40: FIGUR 40: LYTTER FOR Å TILEGNE TILKNYTNING TIL KNAPP OG OBJEKT Brukerobjektet blir funnet ved å iterere over medlemslisten og filtrert ut med id, og lagt i et array hvor all info fra objektet blir lagt inn. Dette arrayet brukes da for å liste info om brukeren i dialog-vinduet som blir initialisert når knappen trykkes. Inne i denne dialogen blir funksjonen setshowvalues() kalt, og lister ut brukerens informasjon som på profilsiden. FIGUR 41: FJERNING AV BEGRENSET BRUKER Samme prosedyre blir gjort når brukeren skal slettes. Brukeren blir da funnet via den nærmeste <tr>-taggen til «this», og deretter filtreres det for å finne teksten til klassen «member_id». Deretter kalles funksjonen dbcommandrejectuser(), som tar objektet til den klikkede brukeren som parameter og sletter den fra databasen i et AJAX-kall med «DELETE» som kalltype. Samme oppsett brukes også for å godkjenne, arkivere og bannlyse medlemmer, hvor brukerens objekt blir sendt med som parameter til henholdsvis dbcommandban(), dbcommandarchive() og dbcommandapprove(). Når en bruker blir godkjent, blir den slettet fra tabellen som inneholder alle brukere med begrenset tilgang, og lagt til i tabellen med godkjente brukere LISTE MED AKTIVE MEDLEMMER Under tabellen for begrensede brukere listes alle aktive medlemmer. Dette blir gjort på samme måte som overnevnte, bare at andre knapper blir assosiert og plassert sammen med navnet på brukerobjektet i listen. I denne listen hentes alle aktive og inaktive medlemmer som en gang har blitt godkjent fra databasen, og objektene blir her filtrert ut etter om de er aktive eller inaktive. SØK ETTER BRUKER

57 Shifter - for Samfunnet Bislett 56 Denne listen har en søkefunksjon som søker igjennom tabellen. Det er lagt inn filtrering på roller, samt fritekst søk på navn, epost og telefonnummer. Filtreringen på roller teller igjennom et array som indikerer hvilke roller som er trykket, vist i Figur 42. Når ikonene for filtrering blir trykket, blir id-en til disse lagt til i filtreringsarrayet som igjen blir filtrert via list.js. Ved å loope igjennom alle objektene i listen i en gjemt <td>-tagg som inneholder personens rolle-id, kan man filtrere ut de objektene som inneholder de samme id-ene fra filtreringsarrayet. Man har også FIGUR 42: TILDELING AV ROLLER FOR FILTRERING mulighet til å søke igjennom listen ved bruk av fritekst, og dette blir gjort på samme måte ved at man har et array med klassenavnet. I denne listen blir fritekstsøken basert på fullt navn, epost og telefonnummer. ENDRE ROLLER En av hovedfunksjonene frivilligansvarlig har er å tildele roller til alle medlemmene i databasen. Dette blir gjort fra hovedlisten hvor alle aktive medlemmer blir listet opp. En ny rad i listen blir lagt til når knappen «Roller» blir trykket. Denne raden blir togglet når knappen trykkes, og blir lagt til under. Alle HTML-attributtene blir da opprettet med id-en til det objektet som blir trykket. Når enten lagre eller avbryt-knappen blir FIGUR 43: LEGGE TIL OG FJERNE RADER MED ROLLEVALG trykket, blir denne raden togglet tilbake, og så slettet for at ikke flere av samme rad skulle dukke opp hvis man trykket flere ganger. Dermed forhindrer man at man i teorien kan få uendelig med slike rader, og man holder opprettelsen av HTML-elementer til et minimum.

58 Shifter - for Samfunnet Bislett 57 Inne i denne listen vil man kunne trykke på checkboxer som er koblet til lyttere som sender AJAX-kall til databasen og oppdaterer brukerens rolle i runtime. For visning av roller, og for å definere hva som er brukerens roller når disse blir vist, blir disse lagt til i to arrayer. Disse blir definert som «currentroles» og «futureroles». CurrentRoles blir satt for alle objektene i listen med å sjekke antall forekomster av roller i objektets Roles-array. CurrentRoles blir definert slik «[0,0,0,0,0]», hvor de ulike plassene er tildelt hver rolle, hvis noen av rollene i rolearray er til stede. For eksempel vil et medlem med tekniker- og superfrivillig-rolle ha CurrentRoles = [0,1,1,0,0]. CurrentRoles og futureroles er delt opp slik: FIGUR 44: TILDELING AV ROLLER I CURRENTROLES - CurrentRoles[0] = Tidligere styre - CurrentRoles[1] = Tekniker - CurrentRoles[2] = Superfrivillig - CurrentRoles[3] = Styremedlem - CurrentRoles[4] = Frivilligansvarlig Sjekken i Figur 44 gjelder for frivillig, superfrivillig og tekniker. Hvis brukeren er tidligere styremedlem, blir alle andre checkbox-er satt av, og kun tidligere styre blir stående igjen som checked. Når rollene til en bruker skal endres, og frivilligansvarlig har valgt de rollene han skal gi brukeren, trykkes «Lagreknappen» og klikklytteren på klassen «.member_roleapprove» trigges. Rollene som har blitt checked blir lagt i futureroles. Denne har samme oppbygningen som currentroles, og settes på samme måte, og objektene har samme plass i begge. FutureRoles tilsvarer rollene brukeren skal ha etter at databasetransaksjonen har blitt gjennomført. Før dette skjer, konverteres currentroles og futureroles til tekststrenger. Disse strengene er hurtige å sammenlikne, og gir rask respons for om arrayene er ulike eller like. Dersom begge er like lukkes bare raden. Dersom de er ulike går funksjonen videre, og begynner sammenligning mellom individuelle roller i arrayene. Hvis plass 1 i currentroles er 1, og den samme plassen i futureroles er 0, vil det tilsvare en nedgradering av den aktuelle rollen. I motsatt ende vil det være en forfremming om den samme plassen i currentroles er 0 og futureroles er 1. FIGUR 45: TILDELING AV ROLLER I FUTUREROLES

59 Shifter - for Samfunnet Bislett 58 Deretter sjekkes currentroles og futureroles mot hverandre for å sjekke om de er identiske. Er de det, vil raden med rolle-visningen bli lukket. Hvis det er forskjeller mellom disse, vil det bli sjekket hvilke plasser som er forskjellige. I Figur 46 blir plassene først sjekket om de er ulike. Er de det, sjekkes det om currentroles er mindre enn futureroles. Dette gjøre for å bestemme om brukeren skal bli forfremmet med den aktuelle rollen, eller om den skal få den fjernet. Grunnen til at dette blir gjort på denne måten er for å unngå å skrive over alle rollene i databasen, men i stedet kun skrive over de aktuelle rollene som har blitt endret. FIGUR 46: SJEKK OM CURRENTROLES[0] ER ULIK FUTUREROLES[0] VISNING AV ARKIVERTE OG INAKTIVE BRUKERE Bannede og inaktive brukere blir som nevnt over lagt i egne variabler, og disse blir generert inn i div-er som ligger skjult til knappene nederst på siden blir trykket. Når «Vis inaktive» blir trykket, vil listen med aktive medlemmer bli byttet ut med listen over inaktive medlemmer. Objektene blir hentet ut på samme måte som getallmembers() og getexcisting() via $.getjson og iterert over med $.each. I listen over inaktive brukere kan frivilligansvarlig kun gi begrenset tilgang til brukere. Arkiverte brukere vises i egen tabell under hovedtabellen med de aktive brukerne. Her vises melding om hvorfor de er bannet. Når listen genereres blir hvert objekt knyttet til en knapp som trigger funksjonen dbcommandunban() som igjen tar det aktuelle objektet som parameter til databasen.

60 Shifter - for Samfunnet Bislett MODUL: DOKUMENTER Denne modulen inneholder visning av alle dokumenter som har blitt lastet opp i systemet av frivilligansvarlig eller av et styremedlem. Dokumentene som behandles på denne siden er Word-, Excel-, PowerPoint- og PDFfiler. Brukeren får vist filene listet nedover med det nyeste opprettede dokumentet først, og brukeren har også muligheten til å filtrere og søke på dokumentene. Dokumentene blir vist i hvert sitt lukkede element med tittel, undertekst, dato for opprettelse og hvem som har opprettet dokumentet til venstre, og med tilhørende knapp for å åpne dokumentet til høyre. Visningen for frivilligansvarlig og styre har i tillegg til generell visning inputfelt for å kunne laste opp dokumenter. I den generelle visningen under opplastningen vises en rød slettknapp til høyre for åpneknappen GENERELL FUNKSJONALITET Den generelle visningen har som nevnt en knapp for å åpne hvert enkelt dokument. Denne knappen er bygget opp av en <button>-tagg inne i en <a>-tagg. <a>-taggens href inneholder linken til dokumentet som vises på skjermen. Dokumentenes attributter blir hentet via AngularJS sin $http.get-metode. Denne metoden tilsvarer jquerys $.getjson metode, og objektene som returneres er av typen JSON. FIGUR 47: $HTTP.GET-METODE FRA DATABASEN I Figur 47henter $http.get informasjon asynkront via kall til databasen via url-strengen "/documents/all", og legger alle dokumentobjektene i $scope.documents, som er en global variabel AngularJS bruker for å laste dynamiske variabler i HTML-kildekoden. Siden alle dokumentene havner i en enkelt variabel, benyttes ngrepeat. Dette er det samme som jquerys $.each, og itererer over alle objektene i variabelen som blir definert i ng-repeat. FIGUR 48: HVORDAN ANGULAR BLIR IMPLEMENTERT I HTML I Figur 48 itereres alle returnerte dokumenter til den midlertidige variabelen "docs" fra $scope.documents. Dokumentobjektenes attributter kan aksesseres via for eksempel {{doc.title}}, som henter dokumentets tittel. Ng-repeat går igjennom "documents" og finner hvert enkelt objekt som ligger i $scope-documents. Siden dette er som en foreach-løkke, vil HTML-elementer innenfor hver ng-repeat bli gjentatt etter så mange objekter som

61 Shifter - for Samfunnet Bislett 60 finnes i variabelen det itereres over. Dette gjør at når funksjonen getalldocuments() trigges, vil listen hele tiden ha en dynamisk visning over hvor mange dokumenter som til enhver tid finnes i databasen FUNKSJONALITET FOR FRIVILLIGANSVARLIG OG STYRE Visningen frivilligansvarlig og styre vil ha innenfor denne modulen er at de har mulighet til å laste opp og slette opprettede dokumenter. Opplastningen blir gjort ved bruk av NPM-modulen Formidable. Formidable håndterer form-element fra HTML på samme måte som man gjør det i PHP, hvor elementene blir sendt med URLstrengen i en POST-operasjon. Formidable blir benyttet på grunn av at filene kan sjekkes for metadata, altså type, størrelse og tittel, noe som er gunstig siden systemet først og fremst sjekker størrelsen på filen som sendes. Dataen fra form-elementet blir sendt igjennom url-strengen "/manage/docs" og denne tar med forespørselen til filehandler.js. FIGUR 49: DOKUMENTOPPLASTNING I FILEHANDLER.JS I Figur 49 håndtertes req-objektet fra Express til et Formidable-objekt. Formidable blir initialisert ved "new formidable.incomingform();". Videre parses alle attributtene fra formen inn i formidable, og derifra kan filens attributter aksesseres og sjekkes ved bruk av variabelen "files". For å få tak i de øvrige feltene fra formen brukes "fields", og verdier fra formen blir hentet ut ved bruk av verdien fra name-attributtet fra inputelementet. FIGUR 50: SJEKK PÅ STØRRELSE, OG OM DOKUMENTET FINNES Før dokumentet blir lastet opp sjekkes størrelsen. For å ikke overbelaste serveren under opplastning og med plass har det blitt satt en maks grense på 50MB. Så sjekkes det etter feil ved filen, og den første error-en som kan oppstå er om filen allerede finnes i opplastningsmappa. Når filen først lastes opp er url-en fra root-mappa fra maskinen som laster opp, men dette blir rettet på ved at fs.rename finner filen, og endrer url-en til destinationpath. Hvis dette ikke går, vil fs kaste en error og filen blir fjernet. Hvis filen ikke har noen konflikter, vil verdiene brukerne skreiv inn i formen bli lagt i databasen. Dokumentene og database-entryen er linket sammen ved den unike URL-en, siden den får dagens tid blir lagt i filnavnet. Tiden hentes ned til millisekunder, og vil kunne gjøre at ingen andre dokumenter ikke får samme url. I tillegg til å utføre databasetransaksjonene låses funksjonen med Promise, og dermed vil ikke andre kall til uploaddocument() bli utført før Promise har resolved eller rejected den eksisterende forespørselen. Frivilligansvarlig og styret kan også velge å slette et dokument, og dette gjøres i administratorvisningen. Knappen "Slett" trigger funksjonen deletedoc(), og for å finne id-en til dokumentet som ble trykket har det blitt

62 Shifter - for Samfunnet Bislett 61 satt opp en lytter som henter id-en fra rel-elementet i <a>-taggen. Verdien rel-attributtet har blir dynamisk satt til det innkommende dokumentets _id når $.each blir kjørt. For da å kunne ha en dynamisk oppdatering av listen må funksjonen først finne ut hvilken knapp som har blitt trykket. Deretter letes det igjennom listen for å finne arrayposisjonen til det aktuelle dokumentobjektet. Derifra sendes et AJAX-kall med metode "DELETE" mot URL-en "/manage/docs/" med dokumentid-en som skal slettes. AJAX-kallet returnerer true eller false avhengig om dokumentet blir slettet eller ikke, og denne verdien blir brukt for å gi en passende melding til bruker VISNING PÅ MOBIL For visning av dokumentene på mobil kjøres det en sjekk for å sjekke at brukeren er på mobil. Er man på en mobil enhet, settes variabelen "mobile" til true. Denne er satt til false som standard. FIGUR 51: SJEKK AV TYPE MOBILENHET Navigator ligger native i JavaScript, og useragent blir brukt til å sjekke om OS-et brukerens enhet tilsvarer noen av de nevnte i if-setningen. Denne sjekken er kun relevant på dokumentsidene, siden fysiske dokumenter ikke kan blir åpnet i mobilens nettleser, men må derimot lastes ned. Dette skyldes at mobilens nettleser kaller på mobilens egen PDF-viser, og dermed trenger den kontakt med databasen. Siden denne PDF-viseren ikke benytter nettleserens session hvor brukerens tilgang er definert, vil man ikke kunne vise dokumentet direkte i PDF-viseren. Dette løses ved å la nettleseren laste ned dokumentet, og la PDF-viseren hente fra nedlastningsmappen lokalt på mobilen.

63 Shifter - for Samfunnet Bislett MODUL: MELDINGER OG AVVIK MELDINGER FRA STYRET Denne modulen tar hensyn til at styret kan sende ut meldinger med relevant informasjon til alle frivillige. HOVEDVISNING FOR SLETTING Denne modulen har sin hovedfunksjonalitet i at medlemmer fra styret kan skrive fellesmeldinger til alle frivillige. Meldingene vil vises på news.html, og kan redigeres i manage/deviants. Det er kun stryet som har tilgang til å redigere meldinger, og dette blir bestemt i routes. I /manage/messages kan meldinger slettes. Dette blir gjort på samme måte som i dokument-modulen, hvor hver melding blir lagt til i listen med et rel-attributt i <a>-taggen. Dermed kan det opprettes lyttere til hvilken av «Slett»-knappene som blir trykket. OPPRETTE NY MELDING Når knappen for å opprette ny melding dukker opp, vil inputfelt for tittel, og melding. Verdiene fra disse feltene blir lagt i et message-objekt som blir lagt i et Ajax-kall med metode «PUT». Før den nye meldingen blir lagt inn i databasen, blir objektet tilegnet et Volunteer-objekt med informasjon om brukeren som publiserte melding. Dette objektet vil bli aksessert og benyttet når meldingen vises på news.html og på manage/messages AVVIKSMELDINGER Denne modulen er programmeringsmessig ganske lik dokumentmodulen og meldingsmodulen. REGISTRERE AVVIK Å registrere avvik blir gjort på akkurat samme måte som når man publiserer meldinger som styre. Et Ajax-kall blir initialisert med et avviksobjekt. Også her blir et Volunteer-objekt lagt til for å kunne definere hvem som skrev meldingen, og når. HÅNDTERE AVVIK Når et avvik håndteres, trigges checkdeviantread(). I denne funksjonen gås det igjennom på samme måte som i dokument-modulen, ved at man finner posisjonen til den trykkede knappen og derifra finner objektets id. Deretter kan objektet settes til fikset, og det blir da sendt et Ajax-kall som sender objektets id til backend som setter objektets solved-attributt til true. Avvik kan ikke bli slettet før det er fikset, og slettingen blir gjort på samme måte som checkdeviantread(), ved at man finner posisjonen til det aktuelle objektet med «Slett»- knappen og sender et «DELETE» Ajax-kall til backend med objektets id.

64 Shifter - for Samfunnet Bislett MODUL: STATISTIKK Statistikk-delen i systemet er et simpelt samarbeid mellom serveren, og et JavaScript-bibliotek som kalles chart.js. Oppå det hele ligger styling fra Bootstrap, noe som gjør statistikksiden til en visuell fornøyelse. Kodemessig er statistikk-delen utviklet for å være så tilgjengelig for videreutvikling som mulig. Det fungerer som et API, med to sentrale funksjonskall: generatechart() og generatelist(). Begge funksjonene tar imot samme type arrayer som parametere, og brukes dermed gjerne etter hverandre. Tar imot 4 parametere GENERATECHART() labelparam et array med labels / tekst som beskriver dataen headerparam tittelen til diagrammet dataparam et array med data type hvilken type diagram som skal produseres Genererer et diagram på bakgrunn av dataen gitt.

65 Shifter - for Samfunnet Bislett 64 Tar imot 2 parametere GENERATELIST() labelparam et array med labels / tekst som beskriver dataen dataparam et array med data Lister ut alle labels og dataverdier i en tabell med id «tablecontainer» De fleste funksjoner tar imot et spesialisert objekt fra serveren og kaller på generatelist() og generatechart(), slik som getstat_faculties(): FIGUR 52: OUTPUT FRA GENERATELIST() FIGUR 53: GETSTAT_FACULTIES, SOM DANNER STATISTIKK PÅ EN SIMPEL MÅTE Her mottas objektet fra serveren, og det opprettes to arrayer. Det itereres over dataen fra serveren som så blir lagt inn i arrayene. Dette sørger for at data og tilhørende label alltid vil finnes på samme index, og kan dermed trygt listes ut sammen i funksjonene. Til sist kalles både generatechart() og generatelist(), og statistikken blir dermed vist i GUI. Det finnes likevel mer spesialiserte funksjoner som har flere operasjoner mot objektet fra server, slik som:

66 Shifter - for Samfunnet Bislett GETSTATS_SHIRTS() I utgangspunktet en simpel funksjon, men for å gjøre data til informasjon må den sorteres. Serveren sorterer størrelser i leksikalsk, og dermed vil rekkefølgen bli helt uten mening. For å kunne sortere skjortestørrelser måtte det lages en egen sorterer: FIGUR 54: SWITCH-CASE OG OBJEKT-PUSH FOR Å SORTERE STØRELSER Sorteringen består av å kjøre en switch-case på hver eneste størrelse i systemet, og oppdatere et objekt kalt «sizesorter» med hver verdi assosiert med størrelsen. Deretter pushes alle verdi-nøkkel-parene som eksisterer i «sizesorter» inn i «labelparam» og «dataparam» i rekkefølge fra lavest til høyest verdi. På denne måten vil arrayene listes ut i generatorfunksjonene i riktig rekkefølge dra den minste størrelsen til den største.

67 Shifter - for Samfunnet Bislett GETSTAT_SHIFTS() Denne funksjonen tar imot to datoer og to mengder. Startdato Sluttdato Mengden frivillige som skal listes Minimum verdi assosiert med frivillige (minimum antall skift gjennomført i perioden) Funksjonen skal lage statistikk over gjennomførte skift innenfor en periode, med valgfrie parametere som avgjør hvor mange frivillige som skal listes, og minimum antall skift som må være gjennomført for å listes. FIGUR 55: GETSTAT_SHIFTS() MED ALLE PARAMETERE SATT Serveren tar bare imot datoene for å hente ut alle frivillige innenfor perioden som har registrerte skift. I funksjonen i klienten håndteres all annen filtrering. Dette gjør den med et par operasjoner mot objektet som blir levert: FIGUR 56: HVORDAN GETSTAT_SHIFTS() SORTERER ET OBJEKT BASERT PÅ PARAMETERE FRA BRUKER Først dytter vi alle verdipar inn i et array kalt «sorter», med semantiske navn (name som nøkkel og antall skift som verdi). Deretter sorterer vi hele arrayet basert på verdien (antall skift). Dette setter arrayet i stigende rekkefølge. Deretter reverserer vi arrayet, slik at de frivillige med høyest verdier kommer først. Dersom det er spesifisert et antall frivillige som skal listes slices alt det overflødige bort, og det bevares kun frivillige fra index 0 til angitt posisjon (mengde-parameter / «amount»). Dersom det er spesifisert et minimum antall skift som skal

68 Shifter - for Samfunnet Bislett 67 være gjennomført slettes alle oppføringer i arrayet som ikke har en verdi som er høy nok. Til slutt pushes alle verdiparene inn i «labelparam» og «dataparam» for sending til generatorfunksjonene MODUL: BARBRUKER Barbrukeren er en unik bruker i systemet som har egne rettigheter og privilegier. For å jobbe i systemet som Barbruker må en først logge ut av sin egen bruker, og deretter logge inn på Barbrukeren med et unikt passord som endres daglig. Dette passordet er synlig for alle som har rolle som styre eller høyere, eller dersom brukeren har en vakt på inneværende dag. For eksempel ville passordet vært synlig den 15. juni for en frivillig, dersom den frivillige har en vaktoppføring den 15. juni. Når trykke på linken for å logge på som Barbruker logges en automatisk ut av ens egen konto, og med passordet en potensielt sett har kan det enkelt logges inn. Den første siden man lander på som Barbruker er prissjekk PRISSJEKK Prissjekk-koden bruker funksjonen getallmembercards() er en kontinuasjon av memberlist.js og fungerer på samme måte. En medlemsliste hentes ned og listes ut i Bootstrap-stil. Forskjellen her er at det eneste av informasjon som er relevant er navn, bilde og prisstatus. Alt dette listes ut i et list.js-enabled søkeelement slik at navnesøk er mulig. I tillegg kan listen filtreres med tre alternativer - alle, kun frivilligpris og kun ordinær pris. Filtreringen oppnås ved at det legges til et skjult felt i hvert list-item som inneholder to av tre tegn: et kolon og en understrek eller et kolon og en bindestrek. FIGUR 57: SKJULTE FILTRERINGSFELT BLIR OPPRETTET Kolon representerer «alle», understrek representerer de med «ordinær pris» og bindestrek representerer de «med frivilligpris». På denne måten filtrerer filteret inn de med angitte tegn, for eksempel vil «Kun frivilligpris»- knappen ignorere alle medlemmer som ikke har en bindestrek i sin price-<div>. Tegnene settes naturligvis basert på prisstatus, som blir levert fra serveren. Til slutt listes alle ut i en <div> med id «cardwrapper». FIGUR 58: HVORDAN MEDLEMSKORT SER UT FOR BARBRUKER

69 Shifter - for Samfunnet Bislett OVERSIKT Oversiktssiden benytter funksjonen gettodaysinfo(), og er også en kontinuasjon av koden fra memberlist.js. Forskjellen fra memberlist er her at mengden informasjon som Barbrukeren har lov til å aksessere om hvert medlem er veldig begrenset. I denne funksjonen skal alle skift som er på inneværende dag listes ut, slik at en bruker på vakt kan se hvem som kommer på jobb. Funksjonen kaller på serveren med en $.getjson-funksjon og får så et komplekst objekt tilbake. Først må det vurderes hvilke skift som blir levert som er gjeldene for tidspunktet de hentes på, og legge de inn i et array. Deretter reverseres arrayet, ettersom serveren leverer objektene i synkende rekkefølge etter tid, slik at man kan lese fra venstre til høyre tidlig til sent. Til slutt må alle skiftene og dets innhold itereres over, på lik linje med init_calendar.js. Her skilles det på returstrenger slik at tidlig-, mellom- og seinskiftene er gruppert sammen, mens tekniker blir listet ut litt på siden for å markere at de er en selvstyrt gruppe. Navn og telefonnummer listes ut inntil hverandre, og navnet har en <a>-tag knyttet til seg med link til den respektive frivilliges Facebook-side. I tillegg styles ansvarsvakten med ekstra fet skrift og avstand til resten, slik at øynene lettere blir dratt mot den viktigste personen å kontakte. LOGIKKEN MED SKIFT SOM GÅR OVER MIDNATT Ettersom en frivillig som står på jobb etter 00:00 på natta, enda regnes som at han står på en vakt fra dagen før må gettodaysinfo() unngå å liste opp vakter for neste dag. Dette gjøres ved å: Levere alle skift som har startdato, eller sluttdato på inneværende dag. sjekke om klokken er før 07:00 (som er klokkeslettet som avgjør dagsskifte). Dersom klokken er før 07:00 skal alle skift fra dagen før, som ender på dagens dato lastes inn. Dersom klokken er etter 07:00 skal bare skift fra samme dato listes ut. FIGUR 59: ET KVELDSSKIFT FRA OVERSIKTSSIDEN TIL BARBRUKER

70 Shifter - for Samfunnet Bislett ANDROID-APPLIKASJON Frivilligpris er en applikasjon som har som mål å lette arbeidet til de frivillige som jobber i baren ved at de lettere kan se hvem som har frivilligpris ved kjøp av drikkevarer. Denne frivilligprisen blir gitt til de som har utført frivillig arbeid på Samfunnet Bislet, og måten denne prisen har blitt sjekket på tidligere har vært ved å gå igjennom en liste med navn manuelt på papir. Frivilligpris sjekker brukeren mot Samfunnets egen database, og hjelper da bartenderen til å kunne se om den som skal kjøpe har frivilligpris eller ikke APPLIKASJONENS INNHOLD Applikasjonen består av følgende filer: 2 aktivitet-filer: o Login.java o Prisvisning.java 2 layoutfiler for visning av elementer på de forskjellige aktivitetene o activity_login.xml o activity_prisvisning.xml BESKRIVELSE AV APPLIKASJONENS AKTIVITETER I denne delen beskrives aktivitetene brukeren interagerer med under applikasjonens bruk LOGIN.JAVA I denne aktiviteten vises Samfunnet Bislets logo samt en logg inn-knapp mot Facebook. I applikasjonen blir Facebook brukt som identifisering av brukeren. Når brukeren trykker på Logg inn, sjekkes det først om brukeren har Facebook på telefonen ved at Facebooks LoginManager sjekker mot allerede lagrede profiler på enheten. Finnes det ikke allerede en bruker logget på enheten, blir brukeren bedt om å logge inn ved bruk av Facebooks egen innloggingsskjerm. Når brukeren har skrevet inn brukernavn og passord, blir de sjekket mot Samfunnets servere for videre innlogging. Dette skjer i en AsyncTask-klasse CheckFaceID. AsyncTask brukes for å hente informasjon via nettet. Siden applikasjonens aktiviteter kjøres som prosesser på enheten, vil en forespørsel mot internett kunne medføre stor trafikk på applikasjonens hovedtråd. AsyncTask-klassen oppretter da en egen tråd hvor disse forespørslene kan gjennomføres og håndteres uten å forstyrre hovedtrådens kjøring (Android Developer, u.d.). Forespørselen kaller en funksjon på serveren via url, og tar brukerens Facebook-ID som parameter. Deretter returneres et JSON-objekt med brukerens frivilligpris eller en melding om at brukeren ikke finnes. Finnes ikke brukeren, blir de værende på innloggingssiden og får en melding på skjermen på hvorfor de ikke kommer seg videre. Brukerne som finnes i databasen blir tatt videre til hovedskjermen PRISVISNING.JAVA I denne aktiviteten vises brukerens profilbilde, navn, hvor lenge de har frivilligpris, samt et bilde som intuitivt viser om brukeren har frivilligpris eller ikke. En stor grønn V vises når brukeren har frivilligpris, mens en rød X vises hvis brukeren ikke har det. Visning av hvor mange dager brukeren har igjen av frivilligprisen, vises i en progressbar. Når brukerne er logget inn vil denne aktiviteten være applikasjonens hovedaktivitet. Det vil si at brukeren kun behøver å trykke på enhetens tilbakeknapp for å gå ut av applikasjonen. Det samme skjer når brukeren skal åpne dette igjen, ved at aktiviteten er det første som vises på skjermen etter at applikasjonen har blitt startet fra startsiden. Hver gang brukeren starter og gjenåpner applikasjonen, blir AsyncTask-klassen GetVolunteerPrice kjørt for å sjekke om brukeren fremdeles har frivilligpris. Dette gjøres på samme måte som i innloggingsaktiviteten, hvor

71 Shifter - for Samfunnet Bislett 70 en forespørsel blir sendt til serveren og en JSON-streng med brukerens frivilligpris blir returnert. Dette gjøres for at applikasjonen hele tiden skal være oppdatert med dataen som ligger på serveren VALG GJORT I UTVIKLINGEN Språket benyttet på variabler, egendefinerte funksjoner og filnavn er engelsk. Dette ble gjort da engelsk er det språket flest mennesker kan snakke og forstå. Applikasjonen har også støtte for engelsk systemspråk, slik at den appellerer til flere brukere. Applikasjonen er også laget slik at den skal være lettest mulig for brukeren å navigere seg i. Det har også blitt lagt vekt på antall klikk som må til for å komme seg fra punkt A til punkt B. Når appen åpnes for første gang, trykker brukeren på Logg inn -knappen. Dermed har brukeren kun benyttet seg av et klikk før han får en respons av appen. Dette vil da enten være at man ikke får logget seg inn, eller at man kommer til hovedskjermen. Brukeren har da benyttet et klikk for å kunne interagere med appen. På hovedskjermen blir applikasjonen automatisk oppdatert når den startes opp. Dette gjøres for at brukeren ikke skal behøve å oppdatere appen manuelt hver gang den åpnes APPLIKASJONENS PROGRAMFLYT FIGUR 60: PROGRAMFLYTEN AV "FRIVILLIGPRIS"

72 Shifter - for Samfunnet Bislett BRUKERVEILEDNING 5.1. BRUKERVEILEDNING FOR FRIVILLIGE REGISTRERING AV BRUKERKONTO OG INNLOGGING FIGUR 61: FORSIDEN AV SHIFTER Shifter benytter seg av Facebook sin innloggingsportal. Dersom du ikke har en Facebook-konto fra før må du gjøre det først. 1. Logg inn på Facebook-profilen din. 2. Åpne Shifter i en nettleser: Klikk på Logg inn med Facebook"-knappen oppe til høyre på forsiden (Figur 61). Du vil nå få opp et vindu (Figur 62) der du må godkjenne at Shifter kan hente brukerinformasjonen din fra Facebook. Informasjonen systemet henter er det som ligger offentlig tilgjengelig på Facebook: a. Navn b. Kjønn c. Epost d. Profilbilde 3. Etter at du har klikket på "Ok" blir informasjonen fra Facebook brukt til å opprette en brukerkonto. 4. Inntil Frivilligansvarlig har godkjent brukeren din har du kun tilgang til din egen Profilside hvor du kan redigere informasjonen om deg selv. FIGUR 62: GODKJENNINJG AV FACEBOOK- TILKOBLING Neste gang du vil logge på Shifter trykker du bare på "Logg inn med Facebook"-knappen igjen og så vil Shifter automatisk logge deg inn via Facebook.

73 Shifter - for Samfunnet Bislett LANDINGSSIDE FIGUR 63: LANDINGSSIDEN Den første siden du kommer til når du logger inn er landingssiden (Figur 63: Landingssiden). OBS! Passordet fro å logge inn i Barbrukeren er kun synlig for styret og de som har vakt den aktuelle dagen.

74 Shifter - for Samfunnet Bislett PROFILSIDE FIGUR 64: PROFILSIDEN Profilsiden (Figur 64) viser informasjonen som er lagret om deg i systemet REDIGER PROFIL For å endre informasjonen din klikker du på "Rediger profil": 1. Fyll ut feltene. 2. Hvis du krysser av for at du er student kommer det opp en liste med skoler i Oslo. (Hvis du ikke studerer ved en av de store institusjonene i listen velger du bare "Annet"). Profilsiden 1. Personlige opplysninger om deg og knapp for å redigere informasjonen. 2. Status for frivilligpris 3. Hvilke roller du har i systemet (se kapittel Brukerroller i Shifter) 4. Knapp for å sette deg selv i inaktiv status 5. Oversikt over kommende og gjennomførte vakter a. Hvis du velger HiOA får du også opp en liste over fakulteter ved HiOA. b. Velg ditt fakultet 3. Ønsker du å bytte profilbilde kan du laste opp et nytt bilde ved å klikke på "Endre profilbilde". a. Det lønner seg å velge et bilde som gjør det lett å gjenkjenne deg og som er relativt kvadratisk (Bildene brukes i Barbruker for å vise hvem som har frivilligpris). b. Shifter godtar kun bilder i JPG eller PNG format (bilde.jpg, eller bilde.png) 4. Når du er fornøyd med profilen din klikker du på "Lagre"

75 Shifter - for Samfunnet Bislett VAKTLISTE FIGUR 65: UKEVISNING AV VAKTLISTEN For å melde deg på en vakt må du klikke på "Vaktliste" i navigasjonsmenyen. I vaktlisten finner du en kalender med oversikt over vaktene. På PC og nettbrett vises kalenderen i ukesvisningen (Figur 65), mens på mobil vises kalenderen i dagsvisning (Figur 66). Det er kun et arrangement pr. dag og disse arrangementene har skift: Vaktlisten 1. Knapper for å bla fram og tilbake, eller gå til dagens dato 2. Dato for utvalget som vises i kalenderen 3. Knapper for å bytte mellom dag, uke og månedsvisning 4. Arrangementene. [grønn] = Tidligskift [gul] = Mellomskift [rød] = Seinskift [blå] = Teknikerskift (kun tilgjengelig for tekniker) Hvert skift har vakter som er delt inn i to typer: Ansvarsvakt: [ledig] / [opptatt] (kun tilgjengelig for superfrivillig) Vanlig vakt: [ledig] / [opptatt] FIGUR 66: DAGSVISNING AV VAKTLISTEN

76 Shifter - for Samfunnet Bislett 75 FIGUR 67: DETALJVINDU FOR ET SKIFT I VAKTLISTEN MELDE SEG PÅ EN VAKT 1. Klikk på det skiftet du vil jobbe på. 2. Detaljvinduet (Figur 67) viser alle vaktene på det aktuelle skiftet. 3. Klikk på en "Ledig vakt" knapper dukker opp øverst i dialogvinduet for å bekrefte, eller avbryte, handlingen (Figur 68). 5. Klikk Meld meg på vakt for å sette deg opp på vakten. 6. Dialogvinduet lukkes og ikonet for vakten oppdateres til opptatt MELDE SEG AV EN VAKT 1. Klikk på skiftet du er satt opp på vakt for. 2. Dialogvinduet med alle vaktene kommer opp. 3. Klikk på navnet ditt i vaktlisten. 4. Det vil nå dukke opp to knapper øverst i dialogvinduet (Figur 69). 5. Klikk på Fjern meg fra vakt for å melde deg av vakten. 6. Dialogvinduet lukkes og ikonet for vakten oppdateres til ledig. FIGUR 68: DETALJVINDU MED KNAPPER FOR Å MELDE SEG PÅ EN VAKT OBS! Fristen for å melde seg av en vakt er 24 timer før dagen for arrangementet. Det vil si at skal du melde deg av en seinvakt på fredag må du gjøre det før midnatt på onsdag. Etter at denne fristen har gått ut må du kontakte Frivilligansvarlig direkte hvis du ikke kan jobbe. FIGUR 69: DETALJVINDU MED KNAPPER FOR Å MELDE SEG AV EN VAKT

77 Shifter - for Samfunnet Bislett DOKUMENTER FIGUR 70: DOKUMENTSIDEN På dokumentsiden kan du finne viktige dokumenter som arbeidsbeskrivelser, referater og sakspapirer til årsmøte (Figur 70). Du kan søke etter spesifikke dokumenter med fritekstsøk, eller filtrere listen etter type dokument. Dokumenter kan være av typen PDF som vil åpnes i nettleservinduet, eller Office-filer (Word, Excel, PowerPoint) som må lastes ned før de kan åpnes.

78 Shifter - for Samfunnet Bislett AVVIKSMELDINGER FIGUR 71: AVVIKSMELDINGSSKJEMA Avviksmeldinger (Figur 71) er beskjeder til styret om ting som mangler, ikke virker eller ødelagt. For å registrere en avviksmelding klikker på "Send inn avviksmelding" på Landingssiden (se kapittel 5.1.2) 1. Skriv inn en tittel på meldingen 2. Velg lokasjon for melding. (hvis problemet ikke er knyttet til et spesifikt sted, eller du ikke finner stedet i listen velger du bare "Annet". 3. Beskriv problemet i Meldingen. 4. Klikk på "Send inn"

79 Shifter - for Samfunnet Bislett FRIVILLIGPRIS-APPEN Det er laget en Android-applikasjon som kan brukes til å sjekke status for frivilligpris. Denne kan lastes ned fra landingssiden INSTALLERE Før du kan installere appen må du sørge for at telefonen aksepterer apper fra ukjente kilder: 1. Åpne innstillinger-appen på telefonen. 2. Trykk på Sikkerhet under "Personlig". 3. Slå på "Ukjente kilder". 4. For mer informasjon om dette besøk: FIGUR 72: MOBILAPPLIKASJON-BOKSEN 5. Hvis man logger inn på Shifter med en mobiltelefon vil en "Mobilapplikasjon"-boks (Figur 72) dukke opp mellom "Meldinger fra styret"-boksen og "Barbruker"-boksen. 6. Klikk på "Installler app". 7. Når telefonen har lastet ned appen vil du få spørsmål om å installere 8. Klikk "OK" 9. Appen blir installert SJEKK FRIVILLIGPRIS Bilde av logg inn og sjekk frivilligpris 1. For å ta appen i bruk åpner du den og klikker på "Logg inn" (Figur 73) 2. Du får nå opp profilbildet ditt og status for frivilligpris 3. Ved å klikke på statusikonet gjøres det en oppdatering mot databasen FIGUR 73: LOGG INN-BILBE OG SJEKK-FRIVILLIGPRIS-VINDU I APPEN

80 Shifter - for Samfunnet Bislett BRUKERVEILEDNING BARBRUKER LOGG INN For å logge på Barbrukeren trenger du "Dagens passord for Barbruker". Dette passordet genereres automatisk av systemet hver dag og dukker opp på Landingssiden (se kapittel 5.1.2) de dagene du har vakt. 1. Kopier, eller skriv ned passordet og klikk på "Logg inn på Barbruker" 2. Du bli nå tatt til innloggingssiden for Barbruker 3. Skriv inn passordet og klikk på "Logg inn" 4. Dette tar deg til Prissjekk PRISSJEKK FIGUR 74: PRISSJEKK I BARBRUKER For å sjekke om en frivillig har rabatt i baren (Figur 74) klikker du på "Prissjekk" i navigasjonsmenyen. 1. Man kan filtrere listen på Frivilligpris eller Ordinærpris 2. Man kan søke opp frivillige med fritekstsøk. 3. Frivillige som har Frivilligpris er merket med grønt i listen.

81 Shifter - for Samfunnet Bislett VAKTOVERSIKT FIGUR 75: OVERSIKT OVER DAGENS SKIFT I BARBRUKER For å se oversikt over dagens skift klikker du på "Oversikt" i navigasjonsmenyen. Her får du opp en oversikt over hvem som jobber på de ulike skiftene denne dagen og telefonnummer til de som har ansvarsvakt slik at de kan kontaktes ved behov. Navnene i vaktoversikten er klikkbare og leder til personens Facebook-profil AVVIKSMELDING For å registrere avviksmeldinger klikker du på "Avviksmelding" i navigasjonsmenyen og følger deretter samme framgangsmåte som i kapittel

82 Shifter - for Samfunnet Bislett BRUKERVEILEDNING FOR ADMINISTRATOR ADMINISTRERE BRUKERE FIGUR 76: FRIVILLIGOVERSIKT På siden for administrasjon av frivillige kan du se alle brukere i systemet (Figur 76) GODKJENNE/AVSLÅ NY BRUKER Nyregistrert brukere får ikke automatisk tilgang til hele systemet (kan kun se og redigere sin egen profil) før Frivilligansvarlig har godkjent brukeren. Man har tre valg: 1. Godkjenne brukeren Brukeren får rollen frivillig og tilgang til funksjonalitetene som hører til under denne rollen 2. Slette brukeren Brukeren slettes fra systemet 3. Arkivere brukeren Les mer om dette i kapittel Frivilligoversikt 1. Symbolkart for de ulike rollene. 2. Oversikt over brukere med begrenset tilgang. 3. Knapp for å se utfyllende informasjon om en bruker. (Ved å klikke på navnet får man opp Facebook-profilen til brukeren) 4. Knapper for å endre status på bruker. 5. Oversikt over aktive brukere 6. Fritekstsøk på medlemmene og knapper for å filtrere listen etter roller 7. Knapp for å sette en bruker i Inaktiv status 8. Knapp for å endre roller for en bruker 9. Knapper for å vise oversikt over: - Inaktive brukere - Utestengte brukere

83 Shifter - for Samfunnet Bislett TILDELE ROLLER FIGUR 77: PANEL FOR Å TILDELE ROLLER Ved å klikke på "Roller" får man opp avkryssningsvalg for å de ulike rollene en bruker kan ha i systemet (Figur 77). For å endre rollene til en Bruker krysser man av/på de ønskede rollene og klikker på "Lagre". Rollen tidligere styremedlem tildeles automatisk når noen blir fratatt rollen styremedlem.

84 Shifter - for Samfunnet Bislett ADMINISTRERE VAKTLISTEN FIGUR 78: VAKTLISTEN FOR ADMINISTRATOR For å redigere vaktlisten må du ha rollen som Frivilligansvarlig. Logg inn og klikk på "Vaktliste" i navigasjonsmenyen. Vaktlisten for Frivilligansvarlig vises i månedsvisning som standard (Figur 78): Vaktlisten 1. Navigasjonsknapper for å bla framover / bakover eller gå til dagens dato 2. Dagens dato 3. Knapp for å slette et arrangement 4. Knapp for å redigere arrangementsmaler 5. Knapper for å opprette / endre arrangement 6. Knapper for å bytte mellom dag- / uke- / månedsvisning

85 Shifter - for Samfunnet Bislett OPPRETTE ELLER ENDRE MALER FIGUR 79: VINDU FOR Å OPPRETTE MALER Arrangementsmaler kan brukes for å opprette arrangement med faste oppsett. Malen inneholder oppsett for skiftene i et arrangement. Ved å klikke på "Maler" får du opp dialogvinduet for å redigere maler (Figur 79). 1. Skriv inn Navn på malen. 2. Valg for Type arrangement (Vanlig eller Utleie). 3. Velg om arrangementet skal være Låst. Dette gjør at kun Frivilligansvarlig kan sette opp personer på vakt (f. eks ved betalte vakter). 4. Datofelt (brukes ikke for å opprette maler) 5. Man kan opprette nye maler basert på allerede eksisterende maler. Velg malen som skal brukes som utgangspunkt. Ønsker du å slette en mal, velger du malen i listen og klikker på "Slett"-knappen som kommer opp vedsiden av listevelgeren. 6. Legg til, eller endre skiftene i arrangementet: I vinduet kan du se skiftene som ligger i malen. For å legge til, eller endre, et skift klikker du på "Legg til / endre skift" (Figur 80). a. Velg type skift du vil legge til eller endre. b. Skriv inn start- og slutt-tidspunkt c. Velg hvor mange superfrivillige (ansvarsvakt) og frivillige som skal jobbe på skiftet d. Klikk på "Legg til" for å legge til skiftet. Om du allerede har et skift av samme type (for eksempel "Tidligskift" vil detaljene på skiftet oppdateres når du klikker på "Legg til" 7. Når du har lagt til ønsket antall skift klikker du på FIGUR 80: VINDU FOR Å LEGGE TI OG REDIGERE SKIFT "Lagre"

86 Shifter - for Samfunnet Bislett OPPRETTE ELLER ENDRE ARRANGEMENT FIGUR 81: VINDU FOR Å OPPRETTE ARRANGEMENT Får å opprette et arrangement i kalenderen klikker man på dagen man ønsker å opprette på og deretter klikker man på "Ny". Dette vil åpne dialogvinduet for å opprette nytt arrangement (Figur 81). 1. Skriv inn Navn på Arrangementet 2. Valg for type arrangement (vanlig eller utleie) 3. Velg om arrangementet skal være låst a. Dette gjør at kun Frivilligansvarlig kan sette opp personer på vakt (f. eks ved betalte vakter). 4. Datofelt (viser datoen som er valgt for arrangementet) 5. Dersom du ønsker at arrangementet skal gjentas krysser du av for "Gjenta" og velger hyppighet og antall gjentagelser. a. "Ukentlig" vil gjenta på samme ukedag b. "Månedlig" vil gjenta på samme dag i måneden c. "Antall" bestemmer hvor mange forekomster som skal opprettes: 1 vil opprette et arrangement, 2 vil opprette to arrangementer, og så videre. 6. Dersom du ønsker å opprette skift med en mal, velger du fra listen over maler. 7. Legg til, eller endre skiftene i arrangementet: I vinduet kan du se skiftene som ligger i malen. For å legge til, eller endre, et skift klikker du på "Legg til / endre skift" (Figur 80). a. Velg type skift du vil legge til eller endre. b. Skriv inn start- og slutt-tidspunkt c. Velg hvor mange superfrivillige (ansvarsvakt) og frivillige som skal jobbe på skiftet d. Klikk på "Legg til" for å legge til skiftet Om du allerede har et skift av samme type (for eksempel "Tidligskift" vil detaljene på skiftet oppdateres når du klikker på "Legg til" 8. Når du har lagt til ønsket antall skift klikker du på "Lagre"

87 Shifter - for Samfunnet Bislett ADMINISTRERE DOKUMENTER FIGUR 82: ADMINISTRER DOKUMENTER For å administrere dokumenter må du ha rollen som Styre, eller Frivilligansvarlig. Ved å klikke på "Dokumenter" i navigasjonsmenyen får du opp siden med dokumenter (Figur 82). 1. Øverst på siden finner du input-felter for å laste opp nye dokumenter 2. Søkefelt for å finne spesifikke dokumenter. Du kan søke etter navn, beskrivelse eller dokumenttype 3. Knapper for å vise, eller slette dokumenter LASTE OPP NYTT DOKUMENT 1. Skriv inn tittel på dokumentet 2. Velg type dokument i menyen 3. Skriv en kort beskrivelse av hva som finnes i dokumentet. Det lønners seg å få med relevante stikkord for dokumentet i beskrivelsen slik at det blir lettere å søke det opp senere. 4. Velg filen som skal lastes opp ved å trykke på "Velg fil" a. Du kan laste opp PDFer, Word, Excel eller PowerPoint-filer OBS! Kun PDFer vil bli vist i nettleservinduet, Office-filene må lastes ned for å leses 5. Når du er fornøyd med det du har skrevet inn klikker du på "Last opp" og filen vil ble lastet opp på serveren.

88 Shifter - for Samfunnet Bislett ADMINISTRERE MELDINGER FRA STYRET På landingssiden finner man en liste med meldinger fra styret. For å administrere denne listen klikker man på "Styremeldinger" i Kontrollpanelet i Navigasjonsmenyen LEGGE UT EN NYHET 1. Klikk på "Opprett melding" oppe til høyre i listen. 2. Skjema for å registrere nyheter kommer til syne. 3. Fyll ut "Tittel" og "Melding" og klikk på "Publiser". 4. Nyheten legges nå til i toppen av listen. OBS! Ønsker du å ha en lenke i nyheten kan du bruke HTML-kode i meldingen: <a href=" For å slette en nyhet klikker du på "Slett"-knappen ved siden av nyheten i listen.

89 Shifter - for Samfunnet Bislett BEHANDLE AVVIKSMELDINGER FIGUR 83: BEHANDLE AVVIKSMELIDNGER For å lese avviksmeldinger som her kommet inn klikker man på "Avvik" i kontrollpanelet i navigasjonsmenyen. Her finner man en liste over avviksmeldingene som er kommet inn. Når en avviksmelding er håndtert klikker man på "Fikset" og meldingen flyttes ned i listen over håndterte avvik. For å slette en avviksmelding klikker man på "Slett"-knappen ved siden av avviksmeldingen. Man kan også opprette nye avviksmeldinger ved å klikke på "Nytt avvik"

90 Shifter - for Samfunnet Bislett STATISTIKK FIGUR 84: STATISTIKKVINDU For å se på statistikk over medlemsmassen og aktiviteten på Samfunnet Bislet klikker du på statistikk i Kontrollpanelet i Navigasjonsmenyen STATISTIKK TIL ÅRSMELDING Statistikk som kan være interessant å ha med i en årsmelding er: ANTALL ÅPNINGSDAGER Eksempel: antall åpningsdager i Skriv inn datoene fra: , til: Klikk på "Se statistikk over" og velg "Antall åpningsdager". HVOR MYE HAR DE FRIVILLIGE JOBBET Eksempel: antall vakter utført av de frivillige i Vaktlisten 1. Inputfelter for å: - søke på statistikk innen et tidsrom. - begrense utvalget som vises. - definere minimum antall vakter 2. Knapp for å søke på: - medlemmers gjennomførte skift - Antall åpningsdager 3. Knapper for å se frivillige fordelt på: - Kjønn - T-skjortestørrelse - Totalt antall frivillige - Antall aktive frivillige - Studentstatus - Skole - Fakultet (kun HiOA) - Roller 1. Skriv inn datoene fra: , til: Klikk på "Se statistikk over" og velg "Medlemmers gjennomførte skift" LISTE OVER HVOR MYE DE FRIVILLIGE HAR JOBBET For å se hvor mye hver enkelt frivillig har jobbet: Fyll inn dato for perioden man vil sjekke på Klikk på "Se statistikk over" og velg "Medlemmers gjennomførte skift" o Om man vil begrense til de 10 som har jobbet mest skriver man "10" i feltet "Antall viste" o Om man vil begrense til de som har jobbet mer enn 4 vakter i perioden skriver man "4" i feltet "Med minimum antall skift"

91 Shifter - for Samfunnet Bislett VEDLIKEHOLD AV SYSTEMET For vedlikehold av systemet se kapittel Bruksanvisning ROLLER I SYSTEMET Brukere i Shifter kan tildeles ulike roller som bestemmer hva en bruker kan gjøre og har tilgang til i systemet. Her er en oversikt over disse rollene: 1. Begrenset bruker Før en ny bruker blir godkjent av frivilligansvarlig får den rollen Begrenset. Denne rollen har kun tilgang til forsiden og sin egen profilside. Frivilligansvarlig kan også sette en bruker tilbake til denne rollen senere ved behov. 2. Frivillig Når en ny bruker blir godkjent av Frivilligansvarlig får den rollen Frivillig, med mindre Frivilligansvarlig gir den flere roller. En Frivillig kan sette seg på vanlige vakter i vaktlista, lese dokumenter og registrere avviksmeldinger. a. Tekniker Frivillige kan få tilleggsrollen Tekniker. Teknikere har samme tilgang og rettigheter som Frivillige, men kan i tillegg sette seg på vakter i teknikerskiftene. b. Superfrivillig Frivillige kan oppgraderes til rollen Superfrivillig. Superfrivillige har samme tilgang og rettigheter som Frivillige, men kan i tillegg sette seg opp på ansvarsvakter. 3. Barbruker Barbrukeren er egen brukerkonto som er ment å brukes på PC-en som står i baren. Denne brukeren har tilgang til noen spesielle funksjoner som a. Liste over alle med frivilligpris b. Avviksmeldinger c. Oversikt over dagens vaktliste 4. Styremedlem Frivillige som sitter i styret kan tildeles rollen Styre. Denne rollen gir tilgang til å: redigere dokumenter, behandle avviksmeldinger og varebeholdning. a. Tidligere styremedlem Når en bruker ikke lenger har styrerollen får den tilleggsrollen Tidligere styremedlem denne rollen gir ingen utvidet tilgang eller rettigheter annet enn permanent Frivilligpris. 5. Frivilligansvarlig Frivilligansvarlig er administratoren av systemet. Frivilligansvarlig har tilgang til alt i systemet og alle rettigheter. Utover det som er nevnt under Styremedlem har Frivilligansvarlig tilgang til å godkjenne/avslå nye brukere, tildele roller til andre brukere og endre på systeminnstillinger SPESIELLE STATUSER 1. Inaktiv Hvis en frivillig ønsker å ta en pause fra Samfunnet kan de sette brukeren sin i Inaktiv-modus. Dette fører til at brukeren ikke tas med i listen over aktive medlemmer og Frivilligansvarlig for ikke brukeren opp i listen når han/hun skal sette brukere på vakt. Frivilligansvarlig kan også sette brukere til Inaktiv-modus hvis de for eksempel har vært inaktive i lang tid 2. Arkivering av brukere: For å arkivere en bruker må Frivilligansvarlig først sette brukeren til begrenset status. a. Anonymisert Hvis en bruker ikke lenger ønsker være registrert i databasen kan Frivilligansvarlig anonymisere brukeren. All identifiserende informasjon om brukeren blir da slettet, men vakthistorikken blir tatt vare på av statistiske hensyn. Denne handlingen er ikke reverserbar. Om brukeren vil registrere seg igjen senere vil det bli opprettet en helt ny bruker som ikke er koblet til tidligere brukere på noen måte.

92 Shifter - for Samfunnet Bislett 91 b. Bannlyst bruker Frivilligansvarlig kan utestenge en bruker fra systemet ved behov. Utestenging fører til at brukeren blir arkivert og Facebook-Iden lagt til i en liste med utestengte brukere. Denne listen blir kontrollert hver gang en ny bruker prøver å registrere seg. Om en utestengt bruker prøver å registrere seg blir den nektet. Ved utestenging må Frivilligansvarlig oppgi en begrunnelse for utestengelsen slik at man ved et senere tidspunkt kan vurdere å oppheve utestengelsen. Om en Facebook-Id blir tatt ut av listen over utestengte brukere kan den opprette en ny bruker igjen.

93 Shifter - for Samfunnet Bislett PROSESSRAPPORT 6.1. FORPROSJEKT UTVIKLING AV NY KRAVSPESIFIKASJON Designarbeidet startet med å kartlegge hva Samfunnet Bislet hadde behov for. Kravspesifikasjonen vi hadde fått var veldig åpen og gav oss en prosjektide, men det var mange ubesvarte spørsmål som vi trengte svar på. Vi tok utgangspunkt i første avsnitt i bestillingen fra Samfunnet som sier: Samfunnet Bislet ønsker i løpet av perioden høsten 2015/våren 2016 å få utviklet ett internsystem for administrasjon av foreningens medlemmer, vakter og arrangementer samt distribusjon av viktige dokumenter og informasjon til de frivillige. Vi tolket dette som at systemet skulle være en kombinasjon av medlemsregister, turnussystem og kommunikasjonsplattform mellom Samfunnet Bislet og foreningens medlemmer. Videre skriver oppdragsgiver at et mål for oppgaven er: "Å opprette en sikker database som lagrer og monitorerer samtlige av systemets registrerte brukere med superbrukere og administratorprivilegier innebygd." På grunnlag av denne informasjonen lagde vi et veldig forenklet UseCase-diagram som et utgangspunkt for en ny kravspesifikasjon (Figur 85). Vi utvidet kravspesifikasjonen med konkrete UseCaser og fikk en mer kompleks modell slik vi ser i Figur 86. Med dette som grunnlag begynte vi å skissere ut hvordan systemet kunne se ut og gjorde noen antagelser basert på erfaring og kunnskap enkelte i gruppen allerede satt på rundt driften av Samfunnet Bislet. FIGUR 85: FORENKELT USE CASE DIAGRAM Etter å ha lagt alle ideene på bordet og dannet et godt bilde av hva slags system som ville svare til Samfunnet Bislet sine ønsker forberedte vi et intervju med Styreleder og Frivilligansvarlig (Appendix D: Intervju med Styret). Vi fikk også observere Frivilligansvarlig mens hun gikk igjennom alle rutinene i forbindelse med oppfølging av de frivillige og vaktlistene. Med informasjonen vi fikk fra intervjuene fikk vi et godt totalbilde av hva systemet skulle inneholde og hva det skulle utføre og startet arbeidet med designet. FIGUR 86: VIDEREUTVIKLET USECASE-DIAGRAM

94 Shifter - for Samfunnet Bislett BAKGRUNN FOR VALG AV TEKNOLOGI I BACKEND Da gruppa skulle velge hva slags teknologi som skulle brukes i prosjektet var det enighet om at vi ønsket å ta i bruk noe vi ikke hadde særlig kjennskap til fra før, slik at vi ville ha høyest mulig læringsutbytte av bacheloroppgaven. Samtidig sa oppdragsgiver at de helst ikke ville ha en løsning som kjørte på PHP, som ville vært det mest naturlige språket å gå for dersom vi ønsket å ta i bruk noe som var kjent, da PHP er et obligatorisk språk å lære på linja for Anvendt Datateknologi, som alle i gruppa går på. Etter å ha slått fra oss å bruke PHP sto valget mellom.net eller Node.js; begge språk som ingen hadde utpreget stor erfaring med. Valget falt til slutt på Node.js, da det er et veldig populært språk for tiden, og det var det språket vi ble anbefalt å benytte oss av alle vi forhørte oss med.

95 Shifter - for Samfunnet Bislett DESIGNVALG FACEBOOK-INNLOGGING Det ble vurdert flere alternativ til løsning for innloggingsportal til Shifter. Det var ønskelig at innlogging i systemet skulle være så enkelt som mulig. Samtidig var det viktig å ivareta sikkerheten til systemet på en god måte. En tradisjonell innloggingsmodul der systemet brukte en intern kontroll av brukernavn og passord mot systemets database ville kreve mye vedlikehold, HTTPS-sertifikat og krypteringsløsninger. Dette ville påføre en del arbeid, kostnader og behov for kompetanse hos Samfunnet Bislet etter leveranse. Derfor så vi etter en effektiv og rimelig tredjepartsløsning. Løsningen som ble valgt var Facebook Login API-et. Dette tilbyr en enkel og sikker innloggingsportal som brukerne allerede er kjent med. Denne løsningen frir Samfunnet Bislet fra å måtte vedlikeholde sertifikater og kryptering. En ulempe med dette valget er at Shifter tvinger medlemmene av Samfunnet Bislet til å opprette en Facebook-konto for å registrere seg som medlemmer av foreningen og sette seg opp på vakter i baren. Dette ble vurdert til ikke å ha så stor betydning siden Samfunnet Bislet allerede baserer seg 100% på Facebook som kommunikasjonsplattform og administrativt verktøy. Det vil i praksis si at betingelsen om å ha en Facebook-profil for å delta i foreningen allerede eksisterer og at det derfor ikke vil få noen konsekvenser for foreningen at Shifter stiller samme krav. Det ble gjennomført en enkel brukerundersøkelse blant foreningens medlemmer for å finne ut hvordan de stilte seg til dette (Figur 87). Spørreundersøkelsen ble gjort med webløsningen Straw Poll og bestod av et enkelt spørmål: "Synes du det er greit om Shifter KUN bruker Facebook-innlogging?" Det kom inn 13 besvarelser på denne undersøkelsen (Figur 88): FIGUR 87: FACEBOOK-POST MED SPØRREUNDERSØKELSE. (SKJERMBILDE FRA LUKKET FACEBOOKGRUPPE) 12 personer svarte JA (92% 1 person svarte NEI (8%) I en kommentar på Facebook-posten (Figur 87) der spørreundersøkelsen ble lagt ut utdypet vedkommende hvorfor: "Stemmer nei av et prinsipp om at det bør være valgfrihet (og en del persondataissues som kan dukke opp)."

96 Shifter - for Samfunnet Bislett 95 FIGUR 88: RESULTATER FRA UNDERSØKELSE OM FACEBOOK-INNLOGGING: Vedkommende har helt rett i at denne måten å løse sikker innlogging på ikke er problemfritt og at det reiser en del spørsmål i med tanke på valgfrihet og personvernsikkerhet. I tillegg fikk vi ikke så mange svar på spørreundersøkelsen (ca. 10% av medlemmene i Facebook-gruppen for Frivillige), noe som gjør det vanskelig å si sikkert at dette resultatet er representativt for brukermassen som helhet. Samtidig var svarene nesten utelukkende positive til løsningen. Kun en person var negativ, og dette av prinsipielle årsaker. Oppdragsgiver hadde heller ingen innvendinger mot at vi gikk for denne løsningen. Et annet problem er at en slik løsning gjør systemet avhengig av Facebook. Hvis Facebook skulle slutte å tilby tredjeparts innlogging, eller deres server skulle være nede vil man ikke kunne logge inn i systemet. Disse scenariene vil føre til svært store konsekvenser for tilgjengeligheten og påliteligheten til systemet, men sannsynligheten for at Facebook slutter å tilby tjenesten, eller at deres servere skulle være offline over lengre tidsperioder ble vurdert til å være minimale. Alt dette tatt i betraktning ble det vurdert at en løsning med utelukkende Facebook-innlogging hadde støtte hos oppdragsgiver og brukergruppen og ikke ville føre til betydelige konsekvenser for Samfunnet Bislets aktivitet.

97 Shifter - for Samfunnet Bislett FRONTEND-DESIGN Å finne balansen mellom funksjonalitet og design er alltid en utfordring når en arbeider med utvikling av nye løsninger, og dette prosjektet er intet unntak. I starten av prosjektet ble det satt to mål for hvordan brukergrensesnittet skulle være og fungere. 1. Bevare identiteten og videreformidle miljøet på Samfunnet Bislet. 2. Oppfylle AA standarden i WCAG SAMFUNNET BISLET IDENTITET Målgruppen til Shifter systemet er studenter som tilbringer tid på Samfunnet Bislet, og som ønsker å bidra aktivt i en studentforening. Miljøet er viktig for å motivere frivillige til å sette seg opp på vakter. Å bevare identiteten og videreformidle miljøet på en god måte har derfor vært svært viktig i forhold til brukergrensesnittet i systemet. Arbeidet startet med å definere hva Samfunnet Bislet sin identitet er, og gjennom den prosessen sørge for at alle i prosjektgruppen hadde en forståelse og kjennskap til stedet og hvordan det driftes. De tre første ukene av prosjektet ble arbeidet utført i Samfunnet Bislet sine lokaler for at alle på gruppen skulle få litt med kjennskap til stedet. To av prosjektmedlemmene har i flere semester arbeidet på Samfunnet Bislet, har god kjennskap til driften og kunne få kontakt med styremedlemmer som senere kunne brukertestes på. Etter de tre første ukene var de første skissene tegnet og det ble bestemt at identiteten til Samfunnet Bislet var sterkt knyttet opp til lokalene og språket som brukes i driften. Språket omhandler i dette tilfelle de ulike rollene som finnes innad på samfunnet som: frivilligansvarlig, superfrivillig, frivillig og teknikker. Dette er begreper som er velkjente innad i miljøet, men som kunne vært forvirrende å forstå for en utenforstående. Begrepene er inkludert i Shifter systemet da det vil være mer gjenkjennelig i miljøet og derfor gi mest mening for disse brukerne. Murstein har også fått en stor rolle i designet, da lokalene til Samfunnet Bislet ligger i kjelleren til ett gammelt mur-bygg og er derfor en gjenganger i lokalet og i allerede eksisterende reklamemateriale. I Shifter systemet er murstein tatt i bruk i form av bakgrunnsmønster på selve siden og i toppmenyen. Fargene rødt, svart og hvitt er gjengående i systemet, og er hentet fra eksisterende reklamemateriale og T-skjortene de frivillige bruker på vakt OPPFYLLING AV WCAG 2.0 Det andre målet var å oppfylle AA standarden i WCAG 2.0, dette er ett nivå høyere enn det som er blitt lovpålagt. Loven sier at alle nettsteder utviklet etter juli 2014 (Direktoratet for forvaltning og IKT (difi), 2016) må oppfylle minst 35 av 61 WCAG 2.0 nivå A krav (Direktoratet for forvaltning og IKT (Difi), u.d.). Shifter har som mål å være enkel i bruk, og formidle mye informasjon på en forståelig og plassbesparende måte. Systemet tar i bruk en kombinasjon av ikoner, tekst og farger for å formidle ulike typer innhold. På kalenderen er det blant annet mulig å endre mellom: dag, uke og måned slik at man får presentert samme informasjon på forskjellige måter (mer om dette i kapittel ). Ett eksempel på oppfylte WCAG krav er: kravet om ikke-tekstlig innhold. Dette er fulgt ved å enten unngå å bruke ikoner alene for å formidle informasjon, tilby en annen visning og/eller legge til klasser som er usynlig for brukere, men leses av skjermlesere. Foruten om dette eksempelet kan også all tekst forstørres 200%, og alle farger er kontrastsjekket i WCAG 2.0 Contrast Checker i Firefox, og oppfyller AA kravet for kontrast forskjell mellom bakgrunn og tekst. Tab-index er også lagt inn slik at det skal være mulig å navigere seg rundt i store deler av systemet med tastatur BRUKERVENNLIGHET Brukervennlighet har vært i stort fokus under utvikling av systemet, og det er gjort en rekke valg for å gjøre systemet så enkelt som mulig å bruke. En av utfordringene som har gått igjen under utviklingen av systemet har vært å tilby brukerne mest mulig funksjonalitet, uten å overvelde de med knapper og alternativer. Dette er oppnådd ved å tildele brukere ulike roller i systemet. På denne måten er det mulig å skille ulike brukere fra hverandre, og tilby brukere akkurat den funksjonaliteten de trenger. Ved å avgrense funksjonaliteten for enkelte brukere øker også sikkerheten, da ingen får tilgang til funksjoner de ikke skal ha tilgang til. Dette gjøres

98 Shifter - for Samfunnet Bislett 97 ved at brukerne blir tildelt ulike toppmenyer basert på hvilken rolle de har i systemet. En person i rollen som frivilligansvarlig vil for eksempel ha tilgang til statistikk, frivilligliste og en rekke administrative funksjoner som for eksempel legge til skift og nyheter. Systemet har en bred og flat informasjonsarkitektur, som betyr at alle undersider er lett tilgjengelig gjennom ett eller to nivåer. Denne informasjonsarkitekturen krever gjerne mindre tastetrykk/museklikk, men det krever også færre undersider. I Shifter systemet ble konsekvensen at mye av funksjonaliteten ble plassert i egne dialogvinduer istedenfor på en separat underside. Brukervennlighet innebærer også at brukerne får tydelig tilbakemeldinger. Ett eksempel er på rediger profil der input feltene får FIGUR 89: EKSEMPEL PÅ TILBAKEMELDING TIL BRUKEREN I SKJEMAER MED FORMATERINGSKRAV tydelig farge og ikon basert på om den utfylte informasjonen er gyldig eller ikke. En vanlig bruker av Shifter systemet vil kjapt besøke systemet for å sette seg opp på vakt. Det er derfor viktig å ha ett brukergrensesnitt som raskt gir bruker oversikt over innholdet slik at de finner det de skal. På enkelte sider er det derfor lagt inn en søkefunksjon og/eller muligheten til å filtrere ut innhold, eksempel på dette er dokument siden eller frivilligoversikten. Forskning viser at de fleste brukere skanner nettsteder i en F-form (Nielsen, 2006), og dette er blitt tatt hensyn til i Shifter systemet. Hvis en bruker skanner Shifter i forhold til F- formen så vil de først se hovedmenyen, overskriftene og deretter hovedinnholdet. Lenkene i hovedmenyen er sortert etter slik at de mest brukte lenkene er plassert lengst mot venstre, slik at disse leses og oppfattes først.

99 Shifter - for Samfunnet Bislett VISUALISERING Det ble lagt mye arbeid i å designe og utvikle vaktlisten. Denne modulen er kjernen i systemet og nesten all brukeraktivitet vil være knyttet opp mot denne. I prosessen med å designe Vaktlisten oppstod det tidlig en utfordring med tanke på plass. Vaktlisten skal kommunisere mye og kompleks informasjon og skjermbildet ble fort overfylt med data. Det ble bestemt at vaktlisten skulle ta form som en tradisjonell kalender med mulighet for å bytte mellom dag, uke og månedsvisning for å tilby visninger som vekslet mellom fokus på overview og detail (Spence, 2007, ss ). Det ble tegnet flere skisser over ulike måter å framstille informasjonen på og noen alternativer ble lagt fram for de frivillige på Samfunnet i en brukertest (Figur 90). Figur 90 viser tre tidlige utkast av vaktlisten: 1. Ren tekst 2. Ikoner og farger 3. Barometeret Det brukerne meldte tilbake var at de foretrakk variantene 1 og 2 og flere foreslo en kombinasjon av disse to. Disse tilbakemeldingene ble tatt med i videreutviklingen av vaktlisten og resulterte i en ny skisse som kombinerte bruk av ikoner og tekst (Figur 91). FIGUR 90: TIDLIGE SKISSER AV VAKTLISTEN FIGUR 91: VIDEREUTVIKLET SKISSE AV VAKTLISTEN

100 Shifter - for Samfunnet Bislett 99 Bruk av encoding ble testet ut på forskjellige måter (Spence, 2007, ss ): Ulike farger for ulike skift Ulike farger for opptatt eller ledig skift Fargenyanser for å skille på Ansvarsvakter og vanlige vakter Ikoner for å ulike arrangement, skift og vakter samt status for vaktene. I den endelige versjonen av Vaktlisten brukes det en kombinasjon av alle disse. FIGUR 92: MÅNEDSVISNING AV VAKTLISTEN Månedsvisningen (Figur 92) er med å gi brukeren et raskt overblikk over vaktlisten med den viktigste informasjonen først: når er det arrangementer og er det ledige vakter. For de frivillige som skal sette seg opp på vakt er det lett å se hvor de kan sette seg opp og Frivilligansvarlig for lett oversikt over hvor det mangler folk. Skiftene er fargekodet slik at man raskt kan se om det er et: o Grønn for tidligskift o Gul for mellomskift o Rød for seinskift o Blå for Teknikerskift Vaktene er representert ved ikoner (stjerner: = ansvarsvakt, sirkler: = vanlig vakt) og disse er enten tomme, eller fylt for å indikere om de er ledige eller ikke.

101 Shifter - for Samfunnet Bislett 100 FIGUR 93: UKESVISNING AV VAKTLISTEN I ukesvisningen (Figur 93) er det plass til å vise mer detaljert informasjon om hvert skift i arrangementet. Ved å klikke på et skift får man ytterligere informasjon om det aktuelle skiftet (Figur 94). På profilsiden og landingssiden får brukeren opp en forenklet liste som viser kommende vakter. I denne visningen er vaktlisten gjort om til en liste med løpende informasjon om kommende skift. FIGUR 95: LISTE OVER KOMMENDE SKIFT FRA PROFILSIDEN FIGUR 94: DETALJVINDU FOR ET SKIFT

102 Shifter - for Samfunnet Bislett FRA SKISSER TIL PROTOTYPER FIGUR 96: TIDLIG SKISSE AV VAKTLISTA Det tidlige skissearbeidet ble gjort hovedsakelig i tegneprogrammet draw.io. Grunnleggende skisser ble laget for hånd og senere videreutviklet digitalt. I Figur 96 ser vi en håndtegnet skisse av vaktlisten. Denne skissen ble jobbet videre med i draw.io (Figur 97). FIGUR 97: DIGITAL SKISSE AV VAKTLISTE

103 Shifter - for Samfunnet Bislett 102 Andre deler av systemet ble skissert direkte i draw.io som for eksempel profilsiden. Profilsider er noe man kjenner godt i fra andre systemer og det var derfor ikke like stort behov for å diskutere utforming av disse. I Figur 98 ser vi en tidlig digital skisse av "Registrer ny bruker". Slike skisser ble produsert for alle de ulike delene av systemet og så bygd ut med interaksjonsmønster. Det ble også laget aktivitetsdiagrammer til disse interaksjonsmønstrene for å gi et bilde av hva som skjedde i back-end. Disse aktivitetsdiagrammene ble brukt som tidlige referansepunkter i programmeringen, men etter hvert lagt til siden. I Figur 99 ser vi et eksempel på en skisse over interaksjonsmønster kombinert med aktivitetsdiagram. For å teste dette på brukere ble det laget enkle papirprototyper ved å skrive ut skissene på papir og skjære ut de enkelte delene (se Appendix F: Eksempel på prototyper). FIGUR 98: DIGITAL SKISSE AV REDIGER PROFIL / REGISTRER NY BRUKER-SIDEN De mer kompliserte modulene, som for eksempel Vaktlisten, ble også testet ut i High Fidelity-prototyper. Et eksempel på en slik prototype ligger vedlagt i Appendix F: Eksempel på prototyper. Denne prototypen ble laget med web-verktøyet NinjaMock og ble brukt i en brukertest med de frivillige på Samfunnet. FIGUR 99: SKISSE OVER INTERAKJSONSMØNSTER MED AKTIVITETSDIAGRAM FOR REGISTRER NY BRUKER

104 Shifter - for Samfunnet Bislett PRODUKSJON Etter brukertesting startet produksjonsfasen av prosjektet, denne fasen inneholder planlegging av programmering og selve programmeringen. I forkant av denne prosessen ble koderegler og kodestruktur bestemt, for å øke lesbarheten i hverandres kode, i tillegg til å gjøre en eventuell videreutvikling av systemet enklere. Starten av produksjonsfasen var preget av planlegging, da det var viktig å få oversikt over nødvendig funksjonalitet. Prosjektet ble på dette tidspunktet delt opp i ulike moduler for å lettere kunne fordele ansvarsområder, og unngå arbeid i samme filer som ville føre til versjons-konflikter. Bitbucket og Tortoise HG ble tatt i bruk for å håndtere kode-historikk og hjelpe med eventuelle versjons-konflikter, da det er vanskelig å unngå mot slutten av prosjektet, når modulene kobles sammen. Bitbucket og Tortoise HG er i likhet med Github ett rammeverk for versjonshåndtering av kode, og en bransjestandard som er nødvendig når grupper jobber med større programmeringsprosjekter. Modulene prosjektet ble delt inn i kan raskt oppsummeres som en enkelt side i systemet. Vaktlisten er den største modulen, med unntak av back-end modulen som blant annet består av server og databasestruktur/metoder. Andre moduler var: Dokumenter Frivillig-liste Profil Facebook innlogging Android applikasjon Statistikk Avviksmeldinger Nyheter Barbruker Det å dele systemet opp i ulike moduler hadde både fordeler og ulemper. Fordelene var at det ble enklere å fordele ansvarsområder, definere viktighetsgraden av hver modul og kartlegge hvilke moduler som var avhengige av hverandre for å fungere. Ett eksempel var profil-modulen som var avhengig av database-modulen for å kunne hente ut og lagre data. Annen fordel er at det ble mulig å teste all funksjonalitet innenfor en modul selv om resten av systemet var under utvikling. En ulempe var at arbeidet med modulplanleggingen førte til utsettelse av selve programmeringen, som var den mest omfattende delen av prosjektet. En annen ulempe var at det kunne være utfordrende å se helheten i systemet, når en jobber konsentrert med en modul. Som tidligere nevnt ble Bitbucket og Tortoise HG benyttet som hjelpemidler underveis i programmeringen, og ble valgt da ett av gruppemedlemmene bruker dette på sin arbeidsplass. Verktøyene hjalp blant annet til med å merge eller sette sammen kode, og gjorde det enklere å dele kode mellom gruppemedlemmene. Release candidates var ett begrep som ble tatt i bruk under produksjonen, og ble sett på som milepæler eller samlingspunkt i programmeringen. Dette var en branch der all kode ble slått sammen og testet på, før utviklingen fortsatte, på denne måten hadde vi alle noen felles samlingspunkt underveis. I løpet av produksjonen ble det totalt tre release candidates som alle ble lastet opp på serveren og testet på av brukergruppen for feil og forslag til forbedring.

105 Shifter - for Samfunnet Bislett UTFORDRINGER VED UTVIKLING AV BACKEND Da ingen i gruppa var kjent med Node.js før vi begynte på prosjektet så tok det ganske lang tid å få oversikt over alle rammeverk som det var ønskelig å bruke med serveren, hvordan serveren skulle struktureres både logisk og filmessig, og å lese seg opp på hvordan vi skulle gå frem for å løse de forskjellige utfordringene vi støtte på. Det ble i begynnelsen laget flere iterasjoner med testservere, basert på forskjellige guider og eksempler funnet på nettet, før vi begynte å nærme oss noe som kunne kalles en ordentlig kandidat vi kunne bygge videre på. Den første iterasjonen av serveren var kun en enkel server som tok imot noen få forespørsler. En senere iterasjon kunne også levere filer statisk, men var fortsatt veldig grunnleggende. Denne læringsprosessen tok lenger tid enn vi hadde beregnet, og medførte at det tok lenger tid før vi kom ordentlig i gang med kodingen, og fikk ut en live testserver som kunne testes av de frivillige på Samfunnet. Vi var heller ikke kjent med hvordan asynkrone funksjoner og Promises virker. Asynkronitet er en av grunnsteinene i Node.js, og Sequelize baserer seg utelukkende på Promises, så dette var også noe vi måtte lære oss, og hvor vi lærte mer ettersom vi fant ut at vi trengte mer avanserte funksjoner TESTING Brukersentrert design har stått i sentrum under produksjonen av Shifter systemet. Det innebærer at systemet regelmessig har blitt testet på den aktuelle brukergruppen underveis i utviklingen. Den aktuelle brukergruppen i denne sammenheng er frivillige som arbeider i baren, dette inkluderer gamle og nye styremedlemmer. Utenom prototype testingen på utvalgte frivillige og styremedlemmer i starten av prosjektet ble det gjennomført blackbox tester på en live server og tester sammen med prosjekteier. Prosjekteier har fått teste og gi tilbakemeldinger gjennom hele utviklingen av systemet, og de siste fire ukene av prosjektet hadde vi ukentlig møter der systemet ble testet på storskjerm. Live testene på server ble gjennomført ved at det ble publisert en link til systemet i Facebook gruppen til de frivillige ved Samfunnet Bislet. Alle med tilgang til linken fikk muligheten til å gå inn å teste systemet, og gi tilbakemeldinger eller stille spørsmål gjennom ett spørreskjema. I løpet av prosjektet ble det foretatt to live tester. Den første testen fokuserte på registrering, redigering av profil, og visning av kalender. Dette var den første testen der systemet ble testet på en større mengde brukere og på ulike enheter som mobil og tablet. Testen avdekket blant annet en stor feil i valideringen på rediger profil siden. Feilen var at ingen født etter 10ende hver måned fikk registrert seg. Dette ble ikke oppdaget under utvikling da tilfeldigvis 4 av 5 gruppemedlemmer er født før 10ende i måneden. Den andre testen var mer en stress test av systemet, der brukere fikk tilgang til hele systemet og ble tildelt rollene de ville hatt i ett ferdig produkt. På denne måten fikk de testet all funksjonalitet som vil være aktuelt for dem å bruke. Denne testen ga oss ett innblikk i hvordan systemet ville takle en større brukermasse og hvordan systemet ville bli tatt i bruk. Under testene ble resultatene fra spørreskjemaet holdt øye med på for å holde seg oppdatert på tilbakemeldingene, og alle påpekt feil under testingen ble raskt rettet opp i for å unngå at flere brukere ble distrahert av samme feil LEVERANSE Endelig leveranse av Shifter systemet til Samfunnet Bislet ble ved prosjektstart satt til 30.mai Kontrakten mellom prosjektgruppen og produkteiere påpeker at tilbakemeldinger på systemet må komme innen 14 dager etter endelig leveranse. Dette betyr i teorien at prosjektgruppen ikke har noen forpliktelser til systemet etter disse 14 dagene. Leveransen skal inneholde full kildekode og brukerveiledning. Systemet skal i tillegg lastes opp på en server som er anskaffet av Samfunnet Bislet, slik at systemet kan tas i bruk høsten 2016 ved semester start. Før endelig leveranse av Shifter systemet ble det gjennomført en akseptsansetest med produkteier. En akseptsansetest skal fungere som en endelig tilbakemelding eller godkjenning av systemet fra produkteier. Underveis i akseptsansetesten ble systemet vist frem i sin helhet og at produkteier fikk fri tilgang

106 Shifter - for Samfunnet Bislett 105 til å teste alle funksjoner. Etter akseptsansetesten ble det skrevet et dokument med tilbakemelding på hele prosjektet fra produkteier, som en bekreftelse på at prosjektet ble gjennomført etter kravspesifikasjonen. (Appendix C: Evaluering fra Oppdragsgiver) EVALUERING Starten av prosjektet var preget av at gruppemedlemmene hadde ulikt eierskap til prosjektet. Noen av gruppemedlemmene hadde vært involvert i planleggingen av prosjektet og var allerede engasjert i studentforeningen Samfunnet Bislet, mens andre var helt ukjente med foreningen og prosjektet. Det ble også brukt mye tid på å finne fram til hvilke rammeverk som skulle benyttes i systemet og diskusjon om sentrale punkter i designet. Dette førte til at produksjonen av systemet kom sent i gang og førte til stort tidspress mot slutten. Likevel har samarbeidet i gruppen og med oppdragsgiver fungert godt og læringsprosessen har vært spennende. Som et team lærte vi etter hvert hverandre å kjenne og hver enkelt fant sin rolle i gruppen. Den siste måneden av prosjektet gikk arbeidet veldig smidig og produktiviteten gikk i taket.

107 Shifter - for Samfunnet Bislett TESTRAPPORT Navn: Live test 1 Mål: 1. Brukere kan uten hjelpemidler forstå hvordan de skal registrere seg. 2. Brukere skal forstå og kunne oppdatere profil uten feilmeldinger. 3. Brukere klarer å skille mellom opptatte og ledige vakter. Deltakere: Ca. 15 frivillige som er medlemmer i frivillig gruppen på Facebook. Deltakerne varierer fra vanlige frivillige, superfrivillige og styremedlemmer innen forskjellige aldersgrupper. Deltakerne er hovedsakelig studenter ved Høgskolen i Oslo og Akershus Utførelse: Testen ble utført ved å legge ut link til systemet i Facebook gruppen til de frivillige. De frivillige fikk deretter gå inn å teste systemet hvor enn de befinner seg og på hvilken enhet de ønsket. Resultat: Resultatet av bruketesten ble samlet gjennom et google spreadsheet. Resultatet viser at svært mange var fornøyd med systemet, og at det ble testet på ulike enheter. Blant annet ble det gitt tilbakemeldinger om at Safari viste nettstedet bedre enn den innebygde nettleseren til Facebook. Det ble også oppdaget en valideringsfeil, slik at ingen født etter 10ende i måneden kunne registrere seg. Videreutvikling basert på resultat av test Valideringsfeil ble raskt rettet opp under testen, og lagt opp på server. Feilen ble ikke rapport igjen og anses som rettet. Forskjeller mellom nettleser vil alltid forekomme i ulik grad, men det ble fikset på Bootstrap klasser i håp om at visningen skulle bli mer lik på tvers av nettlesere. Navn: Live test 2 Mål: 1. Brukere skal kunne tildeles forskjellige roller og skal kun ha tilgang til administrator sider dersom de er administratorer. 2. Brukere skal kunne ta i bruk alle funksjoner uten å få uforklarlige feilmeldinger og/eller risikere å ødelegge noe i systemet. 3. Mange frivillige skal kunne registrere seg og bruke systemet samtidig uten at det oppleves tregt. Deltakere: Utførelse: Resultat: Videreutvikling basert på resultat av test Ca. 30 frivillige som er medlemmer i frivillig gruppen på Facebook. Deltakerne varierer fra vanlige frivillige, superfrivillige og styremedlemmer innen forskjellige aldersgrupper. Deltakerne er hovedsakelig studenter ved Høgskolen i Oslo og Akershus. Deltakerne var også en blanding av personer som testet systemet tidligere og personer som ser systemet for første gang. Testen ble utført ved å legge ut link til systemet i Facebook gruppen til de frivillige. De frivillige fikk deretter gå inn å teste systemet hvor enn de befinner seg og på hvilken enhet de ønsket. Styremedlemmer ble gitt riktige roller i systemet slik at de kunne teste ut administrator funksjoner. Resultatet av brukertesten ble samlet gjennom et google spreadsheet. Resultatet viser at svært mange var fornøyd med systemet og at det fungerte godt på ulike enheter som nettbrett og mobil. Tilbakemeldingene viste også at brukere fant systemet lett forståelig, men at fargene på kalenderen kanskje litt sterke. Diverse småfiks for å gjøre brukeropplevelsen og responstiden i systemet bedre. Kalenderen ble endret slik at arrangement i fortiden får grå farge og skiller seg tydeligere ut fra framtidige og aktuelle arrangement.

108 Shifter - for Samfunnet Bislett KONKLUSJON Etter prosjektets ende og produktets ferdigstilling kan vi se tilbake på en treg men eksponentiell utviklingsfase med et fantastisk sluttresultat. Samfunnet Bislet, representert av produkteier - har understreket at produktet som er levert er av fremragende kvalitet og fullbyrder kravspesifikasjonen. Vi har løst oppgavene vi sto foran på en moderne, sikker og brukersentrisk måte, og føler at vår visjon for produktet har blitt realisert. Videreutvikling av systemet: Siden mange av gruppemedlemmene skal ut i jobb fra høsten av, er det ingen planer om videreutvikling av systemet.

109 Shifter - for Samfunnet Bislett LITTERATUR Aguilar, L. (2014, Juni 19). Why is Node.js so Popular? Hentet Mai 06, 2016 fra DZone.com: Android Developer. (u.d.). AsyncTask. Hentet April 10, 2016 fra Android Developer: Android Open Source Project. (u.d.). Code Style for Contributors. Hentet Mai 07, 2016 fra Android Open Source Project: Anthes, G. (2012, Juli). HTML5 Leads a Web Revolution. Communications of the ACM, Vol 55(No 7), ss doi: / Buxon, B. (2007). Sketching User Experiences: Getting the Design Right and the Right Design (Interactive Technologies). Morgan Kaufmann Publishers. Christensson, P. (2014, August 8). JavaScript Definition. Hentet Mai 16, 2016 fra TechTerms.com: Dalland, O. (2007). Metode og oppgaveskriving for studenter. Oslo: Gyldendal akademisk. Dewson, R. (2008). Beginning SQL Server 2008 for Developers: From Novice to Professional. Dreamtech Press. Direktoratet for forvaltning og IKT (difi). (2016, Mars 19). Kva seier forskrifta? Hentet Mai 20, 2016 fra Universell utforming - Tilsyn for universell utforming av IKT: Direktoratet for forvaltning og IKT (Difi). (u.d.). WCAG 2.0-standarden. Hentet Mai 20, 2016 fra Universell utforming Tilsyn for universell utforming av IKT: standarden FullCalendar LLC. (2016, Mai 23). FullCalendar. Hentet fra GraphicsMagick Group. (2016). GraphicsMagick. Hentet Mai 24, 2016 fra Jaiswal, S. (u.d.). Exception Handling in Java. Hentet Mai 07, 2016 fra Javatpoint: Nielsen, J. (2006, April 17). F-Shaped Pattern For Reading Web Content. Hentet Mai 23, 2016 fra Nielsen Norman Group: Node.js Foundation. (u.d.). About Node.js. Hentet Mai 05, 2016 fra Node.js: Oracle. (u.d.). The History of Java Technology. Hentet Mai 07, 2016 fra Oracle: Quin, L. (2015, Mai 19). Extensible Markup Language (XML). Hentet Mai 16, 2016 fra The World Wide Web Consortium (W3C): Sandnes, F. E. (2011). Universell utforming av IKT-systemer - Brukergrensesnitt for alle. Oslo: Universitetsforlaget. Spence, R. (2007). Information Visualization - Design for Interaction. London: Imperial College.

110 Shifter - for Samfunnet Bislett 109 TIOBE software BV. (2016, Mai). TIOBE Index for May Hentet Mai 16, 2016 fra TIOBE: World Wide Web Consortium. (2012, Mars 2). The web standards model - HTML CSS and JavaScript. Hentet Mai 16, 2016 fra W3C Wiki: _HTML_CSS_and_JavaScript World Wide Web Consortium. (2015, Mai 23). JavaScript best practices. Hentet Mai 16, 2016 fra W3C Wiki: World Wide Web Consortium. (u.d.). HTML & CSS. Hentet Mai 16, 2016 fra The World Wide Web Consortium (W3C):

111 Shifter - for Samfunnet Bislett FIGURLISTE Figur 1: Eksempel på kommentering og navigering i Javascript Figur 2: Eksempel på kommentering i HTML-kode Figur 3: Appendix E: Diagrammer - UseCase-diagram Figur 4: RUTE FOR GET-FORESPØRSEL TIL /CALENDAR/ Figur 5: Funksjonen 'init' i /views/calendar/index.js Figur 6: Sjekk at brukeren har påkrevd rolle for bane /calendar Figur 7: Setter påkrevd rolle for banen Figur 8: Utsnitt av /models/volunteer.js Figur 9: Visualisering og forklaring alle API'er som benytter i vaktlistemodulen Figur 10: Eksempel på nøstede løkker i init_calendar.js Figur 11: Parametere som settes når vaktlisten opprettes Figur 12: jquery-chaining som legger til tekst i dialogvinduet Figur 13: Kodeeksempel fra geteventinfo() hvor man ser at id blir generert Figur 14: event-objekter ligger som globale variabler Figur 15: Globale tracker-variabler Figur 16: global variabel for å ha kontroll på eventid for redigering Figur 17: populatetemplatelist som opererer mot objektnøkler Figur 18: Eksempel på at bruker blir stanset dersom den forsøker å lagre to maler med samme navn Figur 19: deletefromtemplateregister(), som fungere asynkront Figur 20: Lagring av en mal med dbexporttemplate Figur 21: dbexportevent, utsnitt av at den genererer objekt for lagring Figur 22: new_shift.html Figur 23: Elementet for gjentakelse vises etter et klikk Figur 24: Elementet for gjentakelse er skjult før klikking Figur 25: Funksjonskall for å kunne hoppe frem i tid ved lagring av gjentakende events Figur 26: Dyp duplisering av array Figur 27: SJEKKER GJENNOM ALLE POTENSIELT SKAPTE DUPLIKATER, OG SKYVER DEM FRAM I TID Figur 28: Hvordan dbexporteventqueue sin funksjonsloop fungerer Figur 29: 4 SJEKKER SOM AVGJØR OM BRUKEREN KAN MELDE SEG PÅ EN VAKT Figur 30: VARIABLER SOM SETTES I VANLIG FRIVILLIG SIN EVENTCLICK Figur 31: Kort kodelinje for å la varselbokser blinke to ganger Figur 32: Sjekk for å finne brukerens roller Figur 33: Tildeling av ikoner og beskrivelse Figur 34: Tildeling av bakgrunnsfarge på Prgogressbar Figur 35: Sortering av array med kommende skift Figur 36: Endring av status til inaktiv Figur 37: Manuell konvertering av måned for visning Figur 38: Validering av skole og fakultet Figur 39: Håndtering av filtype og størrelse på profilbilde Figur 40: Lytter for å tilegne tilknytning til knapp og objekt Figur 41: Fjerning av begrenset bruker Figur 42: Tildeling av roller for filtrering Figur 43: Legge til og fjerne rader med rollevalg Figur 44: Tildeling av roller i currentroles Figur 45: Tildeling av roller i futureroles Figur 46: Sjekk om currentroles[0] er ulik futureroles[0] Figur 47: $http.get-metode fra databasen Figur 48: Hvordan Angular blir implementert i HTML... 59

112 Shifter - for Samfunnet Bislett 111 Figur 49: Dokumentopplastning i filehandler.js Figur 50: Sjekk på størrelse, og om dokumentet finnes Figur 51: Sjekk av type mobilenhet Figur 52: Output fra generatelist() Figur 53: getstat_faculties, som danner statistikk på en simpel måte Figur 54: SWITCH-CASE OG OBJEKT-PUSH FOR Å SORTERE STØRELSER Figur 55: getstat_shifts() med alle parametere satt Figur 56: hvordan getstat_shifts() sorterer et objekt basert på parametere fra bruker Figur 57: SKjulte filtreringsfelt blir opprettet Figur 58: Hvordan medlemskort ser ut for barbruker Figur 59: Et kveldsskift fra oversiktssiden til barbruker Figur 60: Programflyten av "Frivilligpris" Figur 61: Forsiden av Shifter Figur 62: Godkjenninjg av Facebook-tilkobling Figur 63: Landingssiden Figur 64: Profilsiden Figur 65: Ukevisning av Vaktlisten Figur 66: Dagsvisning av vaktlisten Figur 67: Detaljvindu for et skift i vaktlisten Figur 68: Detaljvindu med knapper for å melde seg på en vakt Figur 69: Detaljvindu med knapper for å melde seg av en vakt Figur 70: Dokumentsiden Figur 71: Avviksmeldingsskjema Figur 72: Mobilapplikasjon-boksen Figur 73: Logg inn-bilbe og Sjekk-frivilligpris-vindu i Appen Figur 74: Prissjekk i Barbruker Figur 75: Oversikt over dagens skift i barbruker Figur 76: Frivilligoversikt Figur 77: Panel for å tildele roller Figur 78: Vaktlisten for administrator Figur 79: Vindu for å opprette maler Figur 80: Vindu for å legge ti og redigere skift Figur 81: Vindu for å opprette arrangement Figur 82: Administrer dokumenter Figur 83: Behandle avviksmelidnger Figur 84: Statistikkvindu Figur 85: Forenkelt Use case diagram Figur 86: Videreutviklet UseCase-diagram Figur 87: Facebook-post med spørreundersøkelse. (skjermbilde fra lukket Facebookgruppe) Figur 88: resultater fra undersøkelse om Facebook-innlogging: 95 Figur 89: Eksempel på tilbakemelding til brukeren i skjemaer med formateringskrav Figur 90: Tidlige skisser av vaktlisten Figur 91: Videreutviklet skisse av vaktlisten Figur 92: Månedsvisning av vaktlisten Figur 93: Ukesvisning av vaktlisten Figur 94: Detaljvindu for et skift Figur 95: Liste over kommende skift fra profilsiden Figur 96: Tidlig skisse av vaktlista Figur 97: Digital skisse av Vaktliste Figur 98: Digital skisse av Rediger profil / registrer ny bruker-siden

113 Shifter - for Samfunnet Bislett 112 Figur 99: Skisse over interakjsonsmønster med aktivitetsdiagram for registrer ny bruker

114 Shifter - for Samfunnet Bislett APPENDIX A: OPPRINNELIG KRAVSPESIFIKASJON BACHELOROPPGAVE SAMFUNNET BISLET OPPGAVEN Samfunnet Bislet ønsker i løpet av perioden høsten 2015/våren 2016 å få utviklet ett internsystem for administrasjon av foreningens medlemmer, vakter og arrangementer samt distribusjon av viktige dokumenter og informasjon til de frivillige. KONKRETE MÅL FOR OPPGAVEN VIL VÆRE: Gjennomføre grundige brukerundersøkelser i forkant av produksjon for å sikre best mulig plattform for videre utvikling tidlig i prosjektet. Smidig metodikk vektlegges. Å opprette en sikker database som lagrer og monitorerer samtlige av systemets registrerte brukere med superbrukere og administratorprivilegier innebygd. Å lage et oversiktlig, universelt utformet og brukervennlig brukergrensesnitt både på medlemssiden og administratorsiden. Systemet skal være intuitivt og brukervennlig, minimalt med opplæring og skolering i forkant skal etterstrebes. Systemet skal være enkelt å vedlikeholde. Å sikre en grafisk pen nettside som innbyr til aktivitet, deltagelse og at de frivillige enkelt kan sette seg opp på vakter. Å produsere en oversiktlig og informativ kalenderløsning som kan lastes ned av de individuelle brukerne. TEKNOLOGI Hvilke teknologier som benyttes for å nå de ovennevnte målene vil ikke for oss være i fokus da vi ønsker et så godt sluttprodukt som mulig. Tredjeparts programvare kan benyttes om gruppen finner det nødvendig. F.eks. på innlogging, kalender ol. Internsystemet skal kunne brukes og administreres fra smarttelefoner, tableter[sic] og ordinære datamaskiner. Hurtig innlastning og respons forventes. Bransjestandard for håndtering av personopplysninger forventes. OM OPPDRAGSGIVER/SAMFUNNET BISLET Samfunnet Bislet er studentforeningen som driver HiOApuben med samme navn. Vi er et naturlig samlingspunkt for studenter ved HiOA og ønsker å gjøre det lettere både å bli frivillig og bidra til drift gjennom å ta på seg vakter.

115 Shifter - for Samfunnet Bislett APPENDIX B: KONTRAKT MELLOM PROSJEKTGRUPPEN OG SAMFUNNET BISLET

116 Shifter - for Samfunnet Bislett 115

117 Shifter - for Samfunnet Bislett 116

118 Shifter - for Samfunnet Bislett APPENDIX C: EVALUERING FRA OPPDRAGSGIVER SLUTTEVALUERING FRA SAMFUNNET BISLET Prosjektgruppens innsats med Samfunnet Bislets internsystem har vært upåklagelig både organisatorisk, resultatmessig og sammarbeidsmessig. Gjennom prosjektet har gruppen opptrådt profesjonelt og reflektert, inkludert sluttbrukerne på alle nivåer og fulgt arbeidsinnstruksen til punkt og prikke. Kommunikasjonen har vært åpen og smidig, gruppen har ikke vært redd for å komme med veloverveide forslag og justeringer til sluttproduktets funksjonalitet der de har ansett dette som nødvendig. Samtlige medlemmer av gruppen har holdt seg seriøse i diskusjon, forståelsesfulle og tålmodige ved henvendelser og profesjonelle i møte med kritikk. Sluttproduktet etterkommer våre forventninger og mer til. Vi som prosjekteiere er storfornøyde med prosessen og implementasjonen og gleder oss til å iverksette bruk av det nye systemet. På vegne av Samfunnet Bislet Sindre Säfvenbom og Torbjørn Stub Jonassen

119 Shifter - for Samfunnet Bislett APPENDIX D: INTERVJU MED STYRET INTERVJU GUIDE GENERELT: Beskriv din rolle i styret. SPØRSMÅL OM UTFØRELSE AV JOBB: Hva slags funksjoner vil du trenge for å utføre jobben din? Hva slags informasjon trenger dere fra frivillige? Hvilke funksjoner vil være de viktigste for styret, og for de frivillige? Hvor lenge skal medlemmene være lagret i databasen? Skal Teknikere og andre typer vakter inn i systemet? Hva med utleie? Skal det inn i systemet? SPØRSMÅL OM ARRANGEMENT OG VAKTER: Hvor ofte er det arrangementer? Er noen faste arrangementer? SPØRSMÅL OM DOKUMENTER OG INFORMASJON: Hvilke typer dokumenter er det snakk om? Skal alle ha tilgang til alt? TEMAER: Ulike tillatelsesnivåer Tanker om Facebook-innlogging Tanker på Barbruker. Avmelding og oppsettelse av vakter. REKKEFØLGE: 1) SKAL DETTE VÆRE EN MEDLEMSDATABASE? a) Info om medlemmer, og tilhørighet. b) Tidsramme c) Tidligere styre og roller d) Privilegier 2) HVEM SKAL ADMINISTRERE? 3) VAKTER/ARRANGEMENT. a) Hvor ofte b) Hvor mange jobber c) utleie d) Andre roller 4) DOKUMENTER/INFORMASJON a) Hva? b) Alt for alle? c) Hvordan? d) Løsning e) Kommunikasjon

120 Shifter - for Samfunnet Bislett 119 5) ANDRE TING: a) Tilgang til sensor b) Telleliste c) Avvik. SAMTYKKESKJEMA FOR INTERVJU I forbindelse med hovedprosjektet vårt i Anvendt datateknologi skal vi utvikle et datasystem for Samfunnet Bislet som skal brukes til «administrasjon av foreningens medlemmer, vakter og arrangementer samt distribusjon av viktige dokumenter og informasjon til de frivillige.» I forbindelse med dette vil vi gjennomføre intervjuer med sentrale personer i organisasjonen. Disse intervjuene tas opp på lyd og transkriberes for senere bruk i utviklingen av systemet og dokumentasjon av denne prosessen. Deltagerne blir anonymisert og selve lydopptakene vil bli slettet når prosjektet er avsluttet. Jeg er innforstått med at det gjøres lydopptak og at disse vil brukes i dokumentasjon av prosjektet. Dato Navn

121 Shifter - for Samfunnet Bislett 120 TRANSSKRIPT STYRELEDER Intervjuobjekt: Styreleder Intervjuleder: Einar Observatør: Helene Einar: Kan du beskrive din rolle? Elin: Min rolle på Samfunnet Bislet er å være styreleder, jeg skal ha kontroll over den daglige driften. Det innebærer å sørge for at alle styremedlemmene gjør jobben sin, ansvar for å holde styremøter, være møteleder, og den viktigste jobben jeg føler jeg har er å være "synlig" for de frivillige. Jeg har da det overordnede ansvaret for driften av Samfunnet. Kontakt utad HiOA, og med nesten alle eksterne parter som ikke eksternansvarlig tar seg av. Einar: I kravspesifikasjonen vi har fått [ ], hva skal systemet egentlig være? Elin: Det skal være et medlemssystem og vaktsystem. For i dag så har vi egentlig bare en Facebook-gruppe med en vaktliste som er linket ut til et annet dokument. Det er liksom det som er. Tidligere har det liksom vært ført antall vakter jobbet per person i et eksternt dokument, i tillegg til det igjen, så det er liksom overalt da. Så det hadde vært fint å få samlet alt i et system. Einar: Er dette for å ha en historikk eller noe? Elin: Det er for å telle antall vakter hver person har hatt, og at man fører hvem som på en måte er berettiget frivilligpris. Hvor mange vakter personen har hatt i året for å ha stemmerett på årsmøte for eksempel. Einar: Hva slags informasjon trenger dere fra de frivillige? Elin: Det som hadde vært interessant er å få med hvilket fakultet de går på, evt hvilken utdanning de tar, for det er liksom basicen, for da kan vi innhente informasjon hvor vi måtte trenge det, og for å kunne hente inn flere frivillige fra de enkelte fakultetene. Også hadde det vært ålreit å hatt med hvilket ansvarsområde de har, sånn at man kan fordele de inn i ansvarsområder etter hvert som man setter seg opp på vakter, f.eks. hvis du er superfrivillig så kan du sette deg opp på begge vaktene, men hvis du er vanlig frivillig kan du kun sette deg opp på "frivilligvaktene" f.eks. Også kan kanskje administrator kanskje gå inn og gjøre deg om til en superfrivillig, og da har du tilgang til alle typer vakter. Einar: Hva er forskjell på frivillig og superfrivillig? Elin: Det er ansvarsområder du har. Hvis du er superfrivillig så har du ansvar den dagen for bl.a. vaktskifte, du har ansvaret for selve pubdriften, du har ansvaret for gjennomføringen av vakten, så du har et litt større ansvarsområde enn en vanlig frivillig, men du har fortsatt de samme arbeidsoppgavene, i tillegg til ekstra ansvarsoppgaver, og ansvar for å ta oppgjør bl.a.

122 Shifter - for Samfunnet Bislett 121 Helene: Er det noen kurs eller noe som må bestås før man blir superfrivillig? Elin: Ikke ha noe kurs, men vi har informasjonsmøter også har vi opplæring, og da skal man egentlig ha minimum 2 opplæringsvakter før man jobber som frivillig, kanskje anbefalt at man kanskje har litt mer. Det er ikke så mange som gjør det, men det hadde vært ideelt at man kanskje hadde hatt 2 tidligvakter og 2 senvakter for eksempel. Einar: Åpningstider, hvor ofte er det oppe? Hvor store variasjoner i tid? Elin: Ordinær åpningstid er onsdag til fredag. Onsdag og torsdag: Vakten begynner og er ferdig ca Fredag: Vakten begynner og er ferdig ca 03.00/ Det kan her også være teknikervakter som også er på vakt, så ideelt sett kunne det vært greit å ha med teknikervaktene innordna liksom som en kode. Teknikervaktene har som ansvarsvaktene en egen kode som gjør at man kan sette seg opp på teknikervakter som blir innordnet inn i den samme vaktlisten. Einar: Har teknikerne et eget system eller? Elin: Nei, de har bare en egen side hvor de sier "Hei, hvem kan jobbe?". Så det kunne vært greit å få opp et vaktsystem der også, enten det er en ekstern vakt eller en intern teknikervakt. Så det kunne vært ideelt. Så er det da på lørdager, så har vi innimellom utleide arrangementer, så der kunne det også vært ålreit fordi vi honorerer, vi kan honorere en person 6000 kr i året, så det kunne også vært greit å få det inn i vaktsystemet, sånn at man også kunne hatt en oversikt der over hvem som har jobbet på disse lørdagene. Einar: Hvem er det som jobber på disse utleiearrangementene? Elin: Alle, men det er jo prioritert da. Helst så skal det være fra styret som kan åpne, også er det de som på en måte er, de som jobber mest, de som er superfrivillige, og så legger man ut til frivillige etterpå. Som regel så vil det fylles opp med at de superfrivillige jobber, men noen ganger er det behov for å gå ut til de frivillige. Styret pleier å dele på det sånn jevnt ut over året, sånn at det er en fra styret på jobb på de vaktene, siden man må ned og låse opp uansett. Også er det superfrivillig som får jobbe på disse vaktene da. Einar: Hvor lenge skal informasjonen om de frivillige ligge i databasen? Elin: Det vet jeg ikke, men det kunne vært lurt at man hadde mulighet til å slette de hvis de ikke er aktive, og informasjonen som ligger der skal ikke bli brukt til noe annet enn interne opplysninger. Det kunne vært greit å gi de mulighet til å slette seg selv, hvis de ikke har mulighet til å være med lenger, eller at man kan sette profilen sin på pause, også blir den automatisk slettet etter to/tre måneder for eksempel. Men man må absolutt ha mulighet til å slette, for det er ikke vits å ha, si, 400 stykker, også er det bare 50 som er aktive. 40 stykker som har permanent frivilligpris à Har vært i styret.

123 Shifter - for Samfunnet Bislett 122 Einar: Hvilke typer dokumenter og hva slags type informasjon er viktige? Elin: I første omgang, så vil det være vedtektene som gjelder for Samfunnet, de skal ligge ute. Generelle rutiner, informasjon om brann, rutiner rundt alt av driften som at man enkelt kan gå inn og lese seg opp. Viktigst: Vedtektene, brannsikkerhet, og rutiner for driften iløpet av en vakt. Men ellers kan det være håndtering av falsk legg, narkotika (hasj, krystallisert metamfetamin, amfetamin, kokain, heroin, kat, sentralstimulerende stoffer, metadon, speed, crack osv), altså situasjoner man kan komme opp i, viktig å ha der ute, samt oppgjørsrutiner, men det er på en måte dokumenter jeg lager da, så det må være enkelt for meg å kunne laste opp et dokument til systemet. Liste med emner, "kartotek", for eksempel "Rutiner BÆM BÆM BÆM BÆM". For det vil jo kanskje være snakk om at det kanskje ligger ute en "vitebok" der da på internsystemet, kanskje det kunne vært lurt å ha f.eks. stillingsbeskrivelse, skjenkebevilling, at den også kan ligge der, at informasjonen er tilgjengelig ut da. Det er ikke noe vits for oss at vi har dette liggende i permer i en web-basert verden. Mye bedre å kunne oppdatere dokumentene ved å laste opp et dokument til, kanskje, jeg veit ikke? Einar: Hvilke kurs skal man ha? Elin: Brannkurs, opplæringskurs, oppgjørskurs, førstehjelpskurs har vi jo hatt en gang, men jeg veit ikke om det kan godkjennes som et kurs, det er ikke et godkjentkurs, men et interntkurs. Einar: Forklarer hvordan vi har tenkt med de forskjellige brukerne. Elin: Men sånn for eksempel jeg som styreleder, vil jeg kunne logge meg inn med min personlige bruker, men med rettigheter enn for eksempel deg som superfrivillig. Einar: Greier mer ut om å gjøre rede for brukerne og generell funksjonalitet. Elin: Hvordan man kan vise seg som frivilligbruker, som den her typ, er dette sånn dere tenker? *Viser Studentappen*. Denne viser veldig tydelig hvem man er. Einar: Er det gunstig med et avvikssystem? Elin: På jobben min har vi noe som kan kalles et avvikssystem, hvor du på en måte logger inn som brukern, og forteller om hva det gjelder, også er det liksom en sånn fane-ting som man kan trykke på, som viser hvilke område det gjelder, så man kan sende til riktig område, f.eks. typ gjelder det scenerommet, gjelder det barromet, teknisk rom, barsystem, bakrom, eller om det gjelder sykdom, dødsfall, altså at man får det inn på riktig. Bør ha med alvorlighetsgrad hvor det liksom står lav, middels, høy, kritisk. Strakstiltak, eller forslag til tiltak. Navn bør være obligatorisk. Begrensning på når man kan melde tiltak, f.eks. hvis noe skjer på onsdag, frist søndag. Einar: Telleliste for barbrukeren. Hovedansvaret for driften av systemet? Elin:

124 Shifter - for Samfunnet Bislett 123 Har ikke peiling. Mest sannsynlig er det noen i styret, og per dags dato regner jeg med at det er Sindre Säfvenbom som kommer til å ha det ansvaret. Videre er det sånn at det blir skiftet styre en gang i året, så ansvaret blir løpende, og det er ikke gitt at de kan systemet nok til å fikse det. Einar: Tilgjengelig for sensor i bacheloroppgaven, kan han få tilgang? Elin: Kanskje man kunne laget en Sensorbruker, som har rettigheter under administrator. Også kan man gi den en periode med tilgang. For min del gjør det ikke noe at en sensor skal ha tilgang til systemet dere lager for å sjekke ut hvordan det funker. Det er bare å kjøre på med en testgruppe etter hvert med frivillige og superfrivillige, og kanskje styret for å kunne gi mer informasjon om hvordan det fungerer. Kanskje det kan være at de vil sette seg opp på vakter oftere. TRANSKRIPT FRIVILLIGANSVARLIG OG STYRELEDER Intervjuobjekt: Frivilligansvarlig og styreleder Intervjuleder: Einar Observatør: Helene Einar: Kunne du sagt litt om din rolle her på samfunnet. Hva du gjør her. Frøydis: Det jeg bruker mest tid på er å finne folk til å jobbe. Fylle vaktlista rett og slett. Legger meldinger ut på Facebook, sender mange meldinger til alle frivillige. I tillegg må jeg holde kontroll på hvor mye alle sammen har jobbet. Jeg må holde kontroll på hvor mye de har jobbet siden siste årsmøte, semesteret som er, og nå semesteret som har begynt. Og hvem som har frivilligpris. Så jeg må finne ut hvem som har jobbet siste måneden. Og bortsett fra det så har jeg frivilligmøter av og til, men det har ikke så mye med det å gjøre. Einar: Disse frivilligmøtene hva er det du informerer om da? Frøydis: Da informerer jeg om driften av samfunnet, hva vi gjør på vakter, litt om skjenkeloven og brannregler og rutiner. Hovedsakelig det. Einar: Hvis du tenker, nå skal jo vi lage et datasystem. Vi skal lage et system som skal hjelpe deg med å gjøre jobben din. Hvilke funksjoner, eller hva trenger du at det systemet kan gjøre for deg. Frøydis: Det hadde vært veldig greit om alle disse vaktene og sånt hadde vært automatisert, sånn at jeg slipper å bruke tid på det. Siden det er ganske mange forskjellige dokumenter som egentlig ikke henger helt sammen, men som man likevel må gjøre om igjen. Einar: Så veldig mye regning på hvor ofte folk har jobbet? Frøydis: Ja. Einar: Andre ting du tenker? Frøydis:

125 Shifter - for Samfunnet Bislett 124 Nei, hovedsakelig det. Det gjelder jo det samme med hvem som har frivilligpris, men det henger jo også sammen med når man har jobbet, ikke bare hvem som har jobbet. Einar: Dette systemet vil jo også fungere litt som en medlemsdatabase, så vi har jo også en oversikt over alle som er medlemmer av foreningen samfunnet bislet. Hvilken informasjon tenker du er viktig at man har over hvert enkeltmedlem? Frøydis: Den viktigste forskjellen er jo hvem som er superfrivillig og hvem som bare er vanlig frivillige. Og det som er veldig vanskelig som jeg ikke vet hvor lett det er å gjøre noe med er når man melder seg inn som frivillig så er man jo ikke bundet til noe i det hele tatt, man må jo på en måte holde kontroll over hvem som faktisk er interessert i å jobbe og hvem som ikke er det. For det kan jo hende at om de melder seg inn i starten av semesteret så bruker de to måneder før de setter seg på en vakt, eller at kanskje om to måneder så har de funnet ut at de er ikke så interessert likevel. Så man må på en måte følge med hele tiden, hvis ikke det bare skal strømme(?) over folk i gruppen som ikke egentlig jobber. Eller er interessert i å jobbe. Einar: Sånn som vi har tenkt dette systemet nå så blir det sånn at man kan gå og komme inn på en side, så er det en logginn side og hvis man ikke har en bruker så kan man opprette en bruker. Og da registrerer man seg, og så får de en brukerkonto i systemet. Men vi har tenkt at det er ikke sikkert at det er ønskelig at alle på internett skal kunne lage seg en konto i systemet, så det vi har tenkt er at når man har opprettet en konto så blir den kontoen bare opprettet som en midlertidig registrering, og så kommer det en beskjed til frivilligansvarlig, som sier at for eksempel "det er 4 stk som har registrert seg nå", også står det for eksempel navn og så må frivilligansvarlig godkjenne før man får tilgang til systemet. Tenker du at det vil være en grei måte å gjøre det på? Frøydis: Ja det høres lurt ut. Einar: Så for eksempel du en gang om dagen får en mail om at nå har det kommet så så mange. Frøydis: Ja. Men tenker dere å ta hele systemet vekk fra Facebook? Einar: Ja. Frøydis: Fordi da trenger jeg en måte å kommunisere, sende meldinger rett og slett. Hvis ikke så må jeg gjøre det på Facebook. Helene: Det som er med løsningen at du godtar folk så er det for deg at du kan sjekke om personen er i Facebook gruppa. Slik at du godtar personen hvis du ser at de er i Facebook gruppa. Einar: Og hvordan dette er koblet til Facebook har vi ikke diskutert så mye. Det kan være sånn at det bare er en lenke til systemet øverst i facebookgruppa. Så det ikke er helt fjerna. Vi kommer ikke til å implementere en chattefunksjon i systemet for å skrive medlinger. Det blir litt mye. Men en admin må godkjenne brukern før de får tilgang, fordi man kan se info om andre. Helene: Men info om frivillig så trenger du navn, hvilken rolle de har, om de er interessert i å jobbe, og hvor du kan finne de og kontakte de på Facebook? Frøydis: Ja, det kommer litt an på. Jeg vet ikke om jeg trenger å ha info om de er superfri eller ikke på den siden. Det trenger jeg nok ikke hvis jeg har en gruppe for det på Facebook. Og så lenge jeg ikke har tenkt å bruke meldinger i systemet så trenger jeg ikke det der. Men det hadde vært greit å få vite hvor lenge en person har vært inaktiv sånn at jeg får en melding om at en person ikke har vært aktiv.

126 Shifter - for Samfunnet Bislett 125 Einar: Ja det er noe vi har tenkt. At hvis en person for eksempel ikke er aktiv på to måneder så blir de flagga som inaktiv. Så får man se hvor lenge det er siden de satte seg opp på vakt. Ene enkel måte å sjekke på er jo de som ikke har frivilligpris. For de har jo da ikke jobba på over en måned. Frøydis: Men det er samtidig ganske vanlig å ikke ha jobbet på en måned hvis man har praksis e.l. Så en måned er ikke så lenge. Einar: Nei, vi kan også ha en oversikt over når jobba man sist. Når logga de seg inn? For hvis de ikke har jobba så er de hvertfall inne i systemet. Frøydis: Ja. Einar: Og det kommer til å være en kobling med Facebook fordi man kan logge seg inn via Facebook. Vi tenker også gjøre det slik at en gang i året så får man en oversikt over de som ikke bruker systemet lenger, ikke har vært logga inn på over ett år for eksempel. Så man kan fjerne de som har slutta på høyskolen for eksempel. Når det gjelder å sette seg opp på vakter. Hva skjer hvis noen ikke kan ta vakta likevel? Hvis man må gjøre endringer. Frøydis: Ofte sender de melding til meg og da ber jeg de legge ut en melding i frivilliggruppa. For da er det ofte litt kortere tid. Ofte får de litt flere napp hvis de sier de må trekke seg enn at det bare er jeg som ikke har funnet noen. Og så hvis det er noen som kan så skriver de sg opp i vaktlista eller jeg gjør det. Einar: Er det noen grense for hvor seint man kan trekke seg? Frøydis: Nei. Einar: Vi har tenkt å legge inn en frist. Frøydis: Ja, det må være lov å være syk og. Helene: Ja, vi tenker at da kontakter de deg direkte. Sånn at du ikke logger deg inn og bare wtf ingen vakter Frøydis: Ja ok. Einar: Prater mer om dette blabla. Frøydis må endre etter frist. Dere har standard åpningstider. Hvor ofte er dere åpent utenom disse? Frøydis: Stort sett åpent lørdager. Sånne private arrangement. Av og til for eksempel fadderuka er det åpent hele uka. Noen ganger enkeltdager i uka. Einar: Det vil jo være mye informasjon i systemet. Skal det være begrenset hva vanlig frivillige har tilgang til? Frøydis: Vanlig åpningsdager skal være synlige. Private arrangement kan være åpent for superfrivillige. Men kanskje at de ikke kan redigere det selv.

127 Shifter - for Samfunnet Bislett 126 Frøydis: De kunne godt vite når de er. Jeg vet ikke når de er. Det er det Trygve som er bookingansvarlig som vet. Han bestemmer når vi skal leie ut på lørdager og han finner vakter som da er betalte vakter. Spør styret først, så superfrivillige om de kan jobbe. Ville spurt vanlige frivillige hvis super ikke kunne. Einar: Dere har konserter her. Har teknikere. Har også backstage. Hvem følger opp backstage rommet? Frøydis: Det skal vanligvis være 2 teknikere under arrangement. En er hovedtekniker som skal holde artistkontakt og følge med på backstage. Einar: Så artistkontakt er noe som er i forbindelse med konserter? Frøydis: Ja. Noen ganger spør vi om artistkontakt som er helt frittstående fra teknikerne men stort sett er det de som tar seg av det. Einar: På vaktene, hvor mange jobber? Frøydis: Det er 6 vakter i uka, 2 hver dag. Mellom 3 og 4 pers på hver vakt. 1 mellomvakt på onsdag som står litt utenom. Og 1 av de 3-4 pers er superfrivillig. Einar: Ang dokumenter og info. Hvilken arbeidsbeskrivelse tenker du er viktigst å ha tilgjengelig? Frøydis: Usikker. Vanlige rutiner. Vaktlista. Einar: Styrereferat legges ut hver uke. Er det noe dere vil ha med som informasjon? Frøydis: Ja. Men kanskje litt separert fra alt annet slik at det andre ikke forsvinner. Einar: Forklarer om barbruker og det vi har tenkt. Forklarer også om avviksmelding vi har tenkt. Er det andre ting du ønsker at systemet skal kunne gjøre for deg? Frøydis: Jeg vet ikke hvor mye du har tenkt på det med teknikere. Jeg har ikke oversitk over hvor mye de jobber. Det er det Kristoffer som følger med på. Så jeg føler at jeg mangler litt info der, og får ikke no svar fra Kristoffer når jeg spør. Jeg tror jeg vet hvem som har jobbet, men det kan være vanskelig å vite når det kommer til årsmøtet. For det teller mot frivilligpris og stemmerett på årsmøtet. Einar: Ja da burde jo det være med i systemet. Helene: Da du tok over rollen du har, hva var det vanskeligste å sette seg inn i? Frøydis: Det gikk ganske greit siden jeg hadde hjulpet til mye før. Egentlig ikke noe som var vanskelig. Noe som er vanskelig er mtp fadderuka. Har en liste med folk som er interessert i å bli frivillige. Der skriver de navnet sitt. Det er ikke alltid man finner de med det navnet på Facebook, eller det finnes flere med samme navn. Og alle er ikke så lette å tyde. Det hadde vært veldig greit å få en lettere måte å melde seg inn på. Og de som ikke skriver seg på lista skal skrive en mail til meg og så kontakter jeg de på Facebook. Og det er litt tungvint. Jeg vil heller at de kontakter meg direkte på Facebook. Eller at det ikke skal være så mange smådeler / prosesser. Det er ganske mye jobb. Etter fadderuka var det 200stk.

128 Shifter - for Samfunnet Bislett 127 Einar: Hvor kommer disse listene fra? Frøydis: Stått på stand etter internasjonal foreningsdag og rekruttert nye frivillige. Einar: Så det kunne vært lettere om man for eksempel hadde med seg en laptop hvor folk skrev seg opp. Frøydis: Ja det hadde det sikkert. Einar: Jeg kom på en ting jeg skulle spurt Elin om også, så nå blir det intervju med både Elin og Frøydis. Einar: Det har vært nevnt det med årsmøter. Regner med at det lages årsmeldinger. Hva slags info er med i den meldingen? Skriver dere hvor mange frivillige som har vært med det siste året? Elin: Ja. Det hadde vi hvertfall med i fjor. Hadde med antall vakter som var jobbet hvertfall. Typ så så mange vakter eller x-antall timer. Det går jo mer på driftsresultater da. Økonomiske. Typ hvor mange kilo øl er solgt. Så mer sånne tall. Nøkkeltall om driften, ikke så mye vakter. Einar: Vi kommer til å jobbe med at man kan hente ut statistikk. Og man kan trykke på en knapp så kan man få årsrapport-statistikk. Hvilke tall ønsker dere da evnt å hente ut? Det har for eksempel vært snakk om hvilke fakultet/institusjon studenter er fra. Har dere kun studenter fra hioa? Frøydis: Nei. Vi har noen som ikke er studenter også. Og fra andre skoler. Einar: Dette er jo også internasjonale studenter. Må systemet være på engelsk? Frøydis: Ja. Einar: Må det være på norsk? Frøydis: Ja. Frøydis: Forresten, jeg hadde syntes at det var greit at det lå ute om man har fripris og hvor mange vakter man har jobbet. Einar: Vi har tenkt å kanskje ha sånn at man ser når man har fripris så ser man countdown hvor lenge det varer. Frøydis: Går på 30-dagers syklus. Elin: For å komplisere det enda litt mer så selv om man har fripris hele tiden så har man ikke gratis inngang hvis det er betalt konsert. Hadde 2 i fjor hvor man måtte det. Man fikk ikke komme inn gratis selv om man hadde vært tidligere styremedlem. Da måtte man ha jobbet. Det er også aktuelt av og til. Einar: Ja, det er noe man kan hente på statistikk. Hente ut hvem som har jobbet siste 30 dager. Elin: Ja, jeg tenker i fargekoder,. Hvis man har jobbet så er det rødt. Og har man jobbet så er det grønt. Uavhengig av om man er i styret eller er frivillig. Og så har du noen som er lilla som er gamle styremedlemmer men som ikke har jobbet siste året eller siden de var i styret. Så grønne får alt mens lilla bare har fripris men ikke det andre. Einar: Ja, og når man har hytteturer så er det de som har jobbet som er prioritert? Elin: Hytteturer er alle som har jobbet det semesteret. Og så er det antall vakter. Og samme med sånn ølkurs hos ringnes så erd et også sånn prioritert. Einar: Ja så vi kan lage liste med synkende prioritet.

129 Shifter - for Samfunnet Bislett 128 Frøydis: og på julebordet så er det jo alle som har jobbet det året. Kriteriene varierer poenget er at man burde kunne fra-til tidsrom. Kan sorteres etter for eksempel alfabetisk, antall vakter, eller annet

130 Shifter - for Samfunnet Bislett APPENDIX E: DIAGRAMMER USECASE-DIAGRAM

131 SEKVENSDIAGRAM: DBDELETEEVENT() Shifter - for Samfunnet Bislett 130

132 Shifter - for Samfunnet Bislett APPENDIX F: EKSEMPEL PÅ PROTOTYPER PAPIRPROTOTYPE REGISTRER BRUKER Side 1 Logg inn

133 Shifter - for Samfunnet Bislett 132 Side 2 Blank registrering

134 Shifter - for Samfunnet Bislett 133 Side 3 Velg dato

135 Shifter - for Samfunnet Bislett 134 Side 4 Velg kjønn

136 Shifter - for Samfunnet Bislett 135 Side 5 velg t-skjorte

137 Shifter - for Samfunnet Bislett 136 Side 6 Student valgt

138 Shifter - for Samfunnet Bislett 137 Side 7 velg skole Side 7

139 Shifter - for Samfunnet Bislett 138 Side 8 HiOA valgt

140 Shifter - for Samfunnet Bislett 139 Side 9 Velg fakultet

141 Shifter - for Samfunnet Bislett 140 Side 10 velg bilde

142 Shifter - for Samfunnet Bislett 141 Side 11 filutforsker

143 Shifter - for Samfunnet Bislett 142 Side 12 bruker registrert

144 Shifter - for Samfunnet Bislett 143 Side 13 Min side

145 Shifter - for Samfunnet Bislett 144 Side 13 Min side i bruk

146 Shifter - for Samfunnet Bislett 145

147 Shifter - for Samfunnet Bislett 146 HIGH FIDELITY PROTOTYPE REGISTRER ARRANGEMENT Prototypen er produsert med NinjaMock og kan testes på denne adressen: