BACHELORPROSJEKT PROSJEKT NR. 3. TILGJENGELIGHET Offentlig. Telefon: Telefaks:

Transkript

1 PROSJEKT NR. 3 TILGJENGELIGHET Offentlig Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: Telefaks: BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL Kildekritikk DATO PROSJEKTDELTAKERE Simen Arvnes s Simen Berge s Mats Ødegaard Jensen s ANTALL SIDER / BILAG 111 INTERN VEILEDER Torunn Gjester OPPDRAGSGIVER Aller Media AS SAMMENDRAG KONTAKTPERSONER Sondre Husby Rostad Christoph Schmitz Dagbladet ønsker at brukeren skal ha muligheten til å gi kildekritikk på deres artikler. Leserne skal gjennom verktøyet bidra med korreksjoner, fakta, synspunkter og dybde en slags kildekritikk. 3 STIKKORD Javascript PHP Laravel Kildekritikk 1

2 Forord Dette er en rapport som beskriver hvordan planleggingen og utviklingen foregikk under prosjektperioden for Aller Media. Prosjektet er avsluttende i bachelorstudiumet Anvendt Datateknologi ved Høgskolen i Oslo og Akershus. Vår oppdragsgiver Aller Media ønsket en applikasjon som lar brukere sende inn kildekritikk på artiklene presentert på dagbladet.no. Måten vi har arbeidet på i bachelorprosjektet er fra sprint til sprint. Vi valgte derfor å bygge opp rapporten på den samme måten. Leseren får da et mer oversiktlig bilde over hvordan vi har jobbet og hva vi har gjort fra sprint til sprint. Alt arbeid som er gjort blir forklart i detalj under hver sprint. Vi vil først og fremst takke Aller Media AS for at de ga oss muligheten til å jobbe med dette prosjektet. Vi vil også takke Sondre Husby Rostad og Christoph Schmitz, våre veiledere hos Aller, for gode innspill og nyttige idéer i løpet av prosjektet. Vi vil også takke vår veileder hos HiOA, Torunn Gjester, som har kommet med gode innspill underveis. 2

3 Innholdsfortegnelse Forord Innledning Oppdragsgiver Bakgrunn Kapittel 1: Mål for oppgaven Hovedprosjekt 2016 Gruppe 3 Høgskolen i Oslo og Akershus Dagens situasjon Mål Effektmål Resultatmål Læringsmål Kravspesifikasjon Kapittel 2: Prosjektplanlegging Hovedprosjekt 2016 Gruppe 3 Høgskolen i Oslo og Akershus Sammendrag Kapittel 3: Sprint 1 Sammendrag sprint 1 Mål og resultat Markering av tekst Artikkeltekst og struktur Generell databasestruktur Twitter autentisering Forum Filstruktur Erfaringer Forbedringpotensiale Kapittel 4: Sprint 2 Sammendrag sprint 2 Mål og resultat Markering av tekst Twitter autentisering Forum Skjermbilder med forklaring Databasestruktur Erfaringer Forbedringspotensiale Kapittel 5: Test 1 Om test 1 Mål og resultat Statistikk Kapittel 6: Sprint 3 Sammendrag sprint 3 Mål og resultat Markering av tekst Kontrollpanel Databasestruktur Erfaringer Forbedringspotensiale 3

4 Kapittel 7: Test 2 Om test 2 Mål og resultat Statistikk Kapittel 8: Sprint 4 Sammendrag sprint 4 Mål og resultat Markering av tekst Skjermbilder med forklaring Kontrollpanel Databasestruktur Erfaringer Brukertest Kapittel 9: Test 3 Om test 3 Mål og resultat Statistikk Kapittel 10: Konklusjon Konklusjon Kildelister Vedlegg A Vedlegg B Vedlegg C Vedlegg D Vedlegg E Vedlegg F Vedlegg G 4

5 Innledning Beskrivelse av prosjektet Kildekritikk er en applikasjon med hensikt å la brukere komme med sine innspill og kommentarer til artikler. Oppdragsgiver Oppdragsgiver i prosjektet er Aller Media AS. Aller Media er et av de største mediekonsernene i Norge og deres største merkevarer er Dagbladet, Se og Hør og Sol.no. Bakgrunn Vårt første møte med Aller Media var i desember Her fikk vi en introduksjon om hva prosjektet handlet om og hva de ville oppnå med det. Ideen kom fra Jan Thoresen, digitalredaktør i Dagbladet. Derfra fikk Hyper Media oppgaven med å videreutvikle ideen med tanke på hvordan den kunne løses. Den originale planen til Hyper var at brukere skulle laste ned et nettleser tillegg som skulle brukes til å kommentere og sende inn tilbakemeldinger på artiklene. Tilbakemeldingene skulle bli lagret og vist på et forum ala reddit.com. Her skulle andre brukere kunne gi kudos til andre brukere for sine innlegg. Brukere måtte ha en Twitter konto for å bruke verktøyet. Men Hyper fikk aldri satt dette i produksjon. Derfor bestemte de seg for at dette kunne være et fint studentprosjekt. Under møtet med Aller kom det frem at det var viktig at brukere på alle plattformer (mobil/nettbrett/datamaskin) skulle kunne bruke løsningen på en god måte. 5

6 Kapittel 1: Mål for oppgaven Hovedprosjekt Gruppe 3 Høgskolen i Oslo og Akershus 6

7 Dagens situasjon I dagens samfunn er det mer vanlig å lese artikler på internett enn på papir. Derfor er det viktig at nivået på artiklene er høye. Problemet er at journalister er under et stort tidspress med å produsere artikler, noe som ikke er optimalt når artiklene skal publiseres fortest mulig. Det betyr at journalistene får mindre tid til redigering og rettskrivning. Dette øker sannsynligheten for skrivefeil, og/eller andre typer feil i artiklene. I tillegg blir ikke artiklene lest over før de publiseres. Mål Effektmål Senke antall grammatikk og informasjonsfeil i artiklene. Øke kvaliteten på journalistikken. Engasjere lesere til å være kritiske til innhold i artikler. Resultatmål Aller Media ønsker en webapplikasjon som gjør det mulig for Dagbladet s lesere å markere og kommentere et eller flere avsnitt i en artikkel. Kommentarfeltet til Dagbladet ble lagt ned tidligere i år, på grunn av for lite konstruktiv tilbakemelding fra leserne. Kommentarfeltet til Dagbladet fikk en ukultur som ikke gagnet noen; Useriøse diskusjoner og ufint ordbruk. Denne webapplikasjonen skal gjøre det mulig for leserne å sende inn synspunkter eller korrigeringer på avsnitt i en artikkel. Dette gjøres anonymt og uten innlogging, men leseren kan legge ved e post om ønskelig, slik at journalisten kan komme i kontakt med personen. Når leseren har sendt inn kildekritikk, blir en mail sendt ut til journalisten. Mailen inneholder hvilke avsnitt som er kommentert, og hva som er kommentert på avsnittene. Artikler som får mye kildekritikk blir varslet opp i systemet etter hvor mange kildekritikk poster som har kommet inn på den spesifikke artikkelen. Læringsmål Gruppens læringsmål er å jobbe i et større, teknisk prosjekt over lengre tid, i et realistisk scenario. Vi vil også tilegne oss ny kunnskap og kompetanse innenfor nye kodespråk og teknologier. 7

8 Den kompetansen vi har opparbeidet oss gjennom 3 år på HiOA er grunnleggende både når det kommer til prosjektets suksess og vårt læringsutbytte. Kjennskap til utviklingsprosesser, programmering og universell utforming er kompetanse vi tenker er viktig for at dette prosjektet kan overleveres i henhold til kravspesifikasjonen. Kravspesifikasjon Vi utarbeidet en kravspesifikasjon for å det klart for oss hva applikasjonen skulle inneholde. Kravspesifikasjonen fungerte som en avtale mellom oss og oppdragsgiver om hvilke funksjoner applikasjonen måtte ha. Hovedelementer fra kravspesifikasjonen: Brukere skal kunne markere avsnitt. Brukere av dagbladet.no skal kunne sende tilbakemelding på artikler. Brukere skal kunne legge ved egne kilder i form av linker til andre nettsider. En mer detaljert kravspesifikasjon ligger vedlagt som Vedlegg A. 8

9 Kapittel 2: Prosjektplanlegging Hovedprosjekt Gruppe 3 Høgskolen i Oslo og Akershus 9

10 Sammendrag Prosjektplanleggingen startet i Januar Ettersom vi hadde blitt pålagt av oppdragsgiver å bruke PHP Laravel som grunnlaget for applikasjonen, var det opp til oss å velge hvilke andre verktøy vi trengte/ville bruke. Første del av prosjektet brukte vi til planlegging. Prosjektplanleggingen inneholder disse punktene: Gruppen og samarbeidet. Planlegging og metoder Utfordringer Veiledning Verktøy Se Vedlegg B for detaljert forklaring. 10

11 Kapittel 3: Sprint 1 Hovedprosjekt Gruppe 3 Høgskolen i Oslo og Akershus 11

12 Sammendrag sprint 1 All hovedfunksjonalitet skulle være på plass under denne sprinten. Med andre ord var det mange funksjoner som skulle implementeres. Vi måtte: Sette opp den generelle databasestrukturen. Gjøre det mulig å markere tekst fra artikkelen. Hente artikkeltekst og struktur fra Dagbladet. 12

13 Mål og resultat Målet var å få laget en generell databasestruktur, få den viktigste funksjonaliteten til å fungere(markering av tekst), lagre annoteringer/ kommentarer til markert tekst, og å finne ut en måte å hente artikkeltekst og struktur fra Dagbladets nettside. Markering av tekst En av de viktigste funksjonalitetene i applikasjonen er markering av tekst, i og med at det er dette som brukerne forholder seg til i store deler av tiden i applikasjonen. Vi og Dagbladet ville at dette skulle være så feilfritt som mulig. Vi jobbet ut i fra Dagbladets ønsker om å lage et markeringsverktøy for å markere tekst i en artikkel, og dette skulle fungere på alle plattformer. Det betydde at vi måtte gå bort i fra et nettlesertillegg da dette ikke fungerer på mobil. På bakgrunn av dette, bestemte vi oss for å starte utviklingen av verktøyet tidlig i prosjektet. Det ble derfor vår oppgave og finne en god løsning på problemet, selv om vi fikk innspill av Dagbladet underveis. Dagbladets tilbakemeldinger på arbeidet vårt gikk for det meste i at de syntes vi var på rett vei. Vi så på allerede eksisterende løsninger for å markere tekst. Både for å få inspirasjon, men også for å se om det var mulig å bruke et bibliotek til å gjøre jobben enklere for oss. Vi så blant annet på et github repository kalt texthighlighter av mir3z, i tillegg til noen fler. Selv om det virket som gode og solide bibliotek, så manglet det mye funksjonalitet for at markeringen skulle fungere slik den var beskrevet i kravspesifikasjonen. Vi tenkte at det ville ta mye tid dersom vi skulle sette oss inn i de titalls funksjonene, i tillegg til at Javascript kompetansen i gruppen var liten. Videre tenkte vi at vi fra starten av ville ha et utfordrende og praktisk prosjekt. På bakgrunn av at vi ikke fant en eksisterende løsning som kunne fungere godt i prosjektet, bestemte vi oss for å lage markeringsverktøyet fra bunnen av. Utgangspunktet vårt hadde vi fra kravspesifikasjonen. Der var markeringverktøyet definert slik: Mulighet for å markere tekst. Kommentere den valgte teksten. 13

14 På dette tidspunktet tenkte vi ikke mye på design, men heller å få opp noe som fungerte. Mest for å se at vi faktisk kunne klare å lage dette verktøyet fra bunnen av, men også for å få teste løsningen. På denne måten kunne vi teste og få en indikasjon på om dette var en intuitiv og brukervennlig løsning. I første iterasjon av tekstmarkering brukte vi en Javascript funksjon som fanget opp markering av tekst gjort av brukeren. 1. document.selection.createrange Denne funksjonen lager et TextRange object som er en representasjon av tekst i et HTML element. Videre testes dette for om browseren dette gjøres i støtter denne funksjonen. Hvis ikke blir andre funksjoner tatt i bruk. Videre er det tatt hensyn til om brukeren markerer fremover eller bakover. Når brukeren har klikket på et avsnitt opprettes en kommentarboks, deretter finner vi plasseringen av den markerte teksten i artikkelen, og setter inn kommentarboksen i nærheten av denne. Strukturen i HTML koden blir også ivaretatt, når det kommer til linjeskrift og avstand mellom avsnitt. 14

15 Slik så frimarkering ut etter første iterasjon. Under vises koden til løsningen på skjermbildet over: 1. //Wrapa tagaroundselectedtext 2. vara =document.createelement('a'); selectedtext.split('\n').foreach(function(val, index){ 5. if(index!= 0){ 6. a.appendchild(document.createelement('br')); 7. } 8. a.appendchild(document.createtextnode(val)); 9. }); a.style.background = "#ccc"; 12. a.id =commentid; range.deletecontents(); 15. range.insertnode(a); 15

16 16. range.collapse(false); // Createthemarkerelementcontainingasingleinvisible character usingdom methodsandinsertit 19. markerel =document.createelement("span"); 20. markerel.id =markerid; 21. markerel.appendchild( document.createtextnode(markertextchar) ); 22. range.insertnode(markerel); Artikkeltekst og struktur Artiklene vi hentet ut hadde en HTML struktur som det var vanskelig å kode opp mot, da det manglet klare tagger for hva som var de forskjellige elementene i en artikkel (artikkeltekst, reklame, annonser). Vi tok opp dette med oppdragsgiver, og etter litt tid fikk vi tips om å bruke Dagbladets API. Ut i fra API et hentet vi artikkelen med en id og fikk returnert et JSON objekt med flere nøkkel/verdi par; Forfatter(e), tags og artikkeltekst. På denne måten fikk vi filtrert og sortert ut innholdet, som gjorde det enklere å jobbe med. Det ble også enklere å lagre forskjellige deler av en artikkel til databasen. Hvordan vi gjorde det er vist med kode under: /** * Returnarticle asjson object byarticleid *@param$id *@return$this \Illuminate\Contracts\View\Factory \Illuminate\View\View */ public functionarticle($id){ Session::put('instance', true); $json =file_get_contents("dagbladet url/api/?id=". $id); // Ifjsonisfounddecodeit if($json!= null){ $article =json_decode($json); } 16

17 } // Ifjsonisn'tfoundreturnanerror else{ returnredirect('/error/kunneikkefinneartikkel'); } Koden viser hvordan man henter artikkelen. Artikkel objektet i kodesnutten over er et dekryptrert json objekt. Fra det objektet henter vi alt fra tittel til forfattere med PHP og lagrer det i databasen. Generell databasestruktur I den generelle databasestrukturen var det å få lagret så mye data fra artiklene som mulig. Det var også viktig å lagre nye versjoner av artikkelen i tilfeller hvor artikkelen ble redigert. Dette er noe vi løser med Laravel: 1. $article =App\Article::firstOrCreate([ 2. 'artikkel_id' => $artikkelid, 3. 'tittel' => $tittel, 4. 'tekst' => $tekst' 5. ]); Her sjekker Laravel databasen for første eksempel av lignende artikkel, hvis ikke opprettes et nytt objekt. Bildet viser ER modellen av databasen. 17

18 På bildet ovenfor ser man den opprinnelige databasestrukturen. Her lagret vi tittel, ingress, tekst osv. om artikkelen i databasen. Hvis data om artikkel forfatteren var tilgjengelig ble også dette lagret. Artikkel forfatteren ble lagret slik at man kunne finne ut hvilke artikler som ble skrevet av hvilke forfattere, og visa versa. Posts var bindeleddet i strukturen. Når brukeren sendte inn en ny tilbakemelding ville en rad bli satt inn i Posts tabellen. Denne raden inneholdt id til artikkelen og id til brukeren som sendte inn tilbakemeldingen. Det er verdt å merke seg at på dette stadiet var det fortsatt meningen at brukere skulle bruke en twitter konto for å kunne sende inn en tilbakemelding. Etter at vi gikk bort fra dette så ble også databasestrukturen bygd om. Hensikten bak Posts tabellen var å koble hvilke brukere det var som hadde sendt inn hvilke tilbakemeldinger. Twitter-autentisering Aller Media ønsker å forebygge at nettroll tar i bruk tjenesten for å sende useriøse kommentarer til journalistene. Dette vil de gjøre ved å kreve at brukerne av applikasjonen Kildekritikk enten eier eller oppretter en Twitter konto. I følge Aller Media skal dette være med på å filtrere ut personer som ikke er seriøse. Dette begrunner Aller Media med at mange bruker Twitter som en plattform for å uttrykke meninger og synspunkter. Forum Et forum er ønskelig fra Aller Media sin side. Hensikten med et forum skal være å lage en plattform der brukere kan kommentere, stemme opp eller ned tilbakemeldinger på artikler, og kommentere andres tilbakemeldinger. Dette skal bidra til å øke engasjementet blant leserene, åpne for debatt og diskusjon, samt la redaksjonen få vite hvilke artikler de bør prioritere å vurdere, ved hjelp av stemmesystemet. Filstruktur Filstrukturen i dette Laravel prosjektet har vært enkelt å forholde seg til som utvikler. Mappene genereres ved initialisering av et prosjekt. Det tar kort tid å sette seg inn i mappene og filene, og en fordel er at alle utviklerne i teamet jobber ut i fra samme utgangspunkt. 18

19 Vi har jobbet med å være konsistente i å navngi mapper og filer, avhengig av hva slags type fil eller mappe det er. For eksempel starter alle Sass moduler med understrek for at ikke Gulp skal ta filene med i kompileringen. Filer med flere ord skiller av ordene med punktum og filer bør ha korte, selvforklarende navn. Vi opplevde at dette så pent ut, og gjorde det enklere å lese og finne igjen det man leter etter. Dette gjøres for å legge til rette for utviklerne som overtar prosjektet etter at vi er ferdige. Vi ønsker å vise frem noen av mappene og filene, for å visualisere omfanget av prosjektet vårt. Prosjektet består av mange filer og mapper. Mappene vil bli forklart én og én. Filene som ligger under root mappen (bachelor_project) er for det meste config filer, som gjør at kode blir komprimert og kompilert, kobling til database og filer for den virtuelle maskinen som prosjektet kjører på. Kort sagt er det filer som gjør at alt fungerer som det skal, slik at man er i stand til å starte utviklingen. 19

20 .vagrant inneholder filer som setter opp det virtuelle utviklingsmiljøet, slik at prosjektet kan bygges og kjøres hvor som helst. Under app mappen ligger kildekoden til applikasjonen. Bootstrap mappen inneholder filer som klargjør rammeverket, samt en cache mappe som sørger for bedre ytelse og optimalisering. 20

21 Config mappen inneholder applikasjonens konfigurasjonsfiler. Under database mappen ligger filer for å opprette tabeller, samt data som kan settes inn i tabellene ved opprettelsen. Node_modules inneholder verktøy og biblioteker som effektiviserer utviklingen og ytelsen til applikasjonen. 21

22 I public mappen, eller web root, inneholder alle filer som er nødvendige for at applikasjonen kan kjøre på en server. Under resources mappen ligger applikasjonens og ukomprimerte kodefiler. Storage mappen inneholder kompilerte Blade templates, filcache, loggfiler og andre filer generert av rammeverket. 22

23 Under styleguide mappen ligger filene for KSS (Knyle Style Sheets), som gjør det mulig å lage god dokumentasjon av Sass koden. Under tests mappen ligger filer for automatiserte tester. 23

24 Vendor mappen inneholder alle Composer avhengigheter, som gjør det mulig å automatisk installere og oppdatere biblioteker som prosjektet er avhengig av. Erfaringer Gjennom sprinten hadde vi daglige standups slik at alle fikk en oversikt over hva som ble gjort dagen før og hva som skulle gjøres fremover. Vi hadde også et godt samarbeid hvor vi klarte å fordele oppgaver på en god måte. Forbedringpotensiale Det som kunne blitt gjort bedre denne sprinten er flere møter med oppdragsgiver, gjerne i starten av sprinten. Det ble litt uklart hva som skulle gjøres til tider og dette førte til at utviklingsprosessen gikk tregere. Vi tok opp problematikken med veilederen vår hos Dagbladet, for å bli mer effektive under de neste sprintene. 24

25 Kapittel 4: Sprint 2 Hovedprosjekt Gruppe 3 Høgskolen i Oslo og Akershus 25

26 Sammendrag sprint 2 Målet med denne sprinten var å ferdigstille verktøyet til den første testen. Hvordan det så ut var derfor veldig viktig. Store deler av sprinten gikk derfor til utvikling av design og brukergrensesnitt. 26

27 Mål og resultat Det har skjedd mye i sprint 2, men målet for sprinten var å ferdigstille verktøyet til test 1. Dette innebar back end, front end, design og brukeropplevelse. Mye måtte altså ferdigstilles for å kunne gjennomføre den første brukertesten. Mye av funksjonaliteten var raskt på plass. Det vi brukte mest tid på er design og brukeropplevelse. Dette har vært krevende på mange måter: Gruppen har bare diskutert design og brukeropplevelse internt i gruppen og i noen korte møter med oppdragsgiver. Vi har blitt presentert en idé, men visste ikke hvordan verktøyet skulle se ut eller oppføre seg. Vi har ikke gjennomført noen brukertester, og dette har gjort oss usikre på om verkøyet er forstålig og intuitivt nok. Markering av tekst I tillegg til at vi begynte å tenke mer på mobil, startet vi også å se etter andre løsninger for å markere tekst. Vi visste at vi måtte forholde oss til HTML koden som fulgte med JSON objektet, så formatering og strukturen på HTML koden ville fortsatt være et problem. Dette fordi HTML koden varierer fra artikkel til artikkel. Det var nesten ingen gjennomgående artikkelstruktur. Tanken på at applikasjonen skulle fungere like godt på alle plattformer, gjorde at vi begynte å tenke i litt andre baner. Frimarkering på desktop kunne fungert fordi brukeren har mulighet til å bruke touchpad eller mus. Mobile enheter har også denne funksjonaliteten, men er i større grad vanskeligere å utføre, enn om man bruker mus eller touchpad. Uavhengig av plattform, vil en løsning der brukeren får markere hva han eller hun vil, kreve finmotoriske bevegelser. Våre mål gikk ut på å lage noe som var intuitivt, raskt og enkelt å bruke, ha konsistens i brukergrensesnittet uavhengig av plattform (gjenkjennelig brukeropplevelse) og at applikasjonen skal tolerere feil. Kort sagt, en brukeropplevelse der man instinktivt forstår hva verktøyet er, og hvordan man interakterer med det. I tillegg gi en så sømløs brukeropplevelse som mulig, ved bruk av tilbakemeldinger til brukerne, animasjoner, hjelpetekst o.l. 27

28 Vi vurderte å ha en løsning på mobil og en annen løsning på desktop. Men vi fant ut at for vår egen del, og for brukernes del, at det var bedre om vi gikk for den samme løsningen på alle plattformer. Grunnen til dette var først og fremst for gi brukerne så lik opplevelse som mulig uavhengig av plattform, og at den løsningen vi gikk for også passet godt til desktop og mobil; Kommentere avsnitt i artikkelen. Slik så markering av tekst ut etter andre iterasjon. 28

29 Slik så markering av tekst ut etter tredje iterasjon. Med tanke på tiden vi hadde til rådighet, ville det være tidkrevende å skulle forholde seg til ulik Javascript kode. Av erfaring visste vi at frimarkering av tekst hadde sine utfordringer. I tillegg til at vi skulle implementert den samme funksjonaliteten to ganger, men den ene skulle da være tilpasset mobile enheter, og den andre tilpasset desktop. Vi har prøvd å lage verktøyet etter de prinsippene som nevnt over. Resultatet etter flere iterasjoner, er noe vi kan med et godt grunnlag, si at vi er nærme sluttresultatet vi hadde sett for oss. Vi anerkjenner at verktøyet har forbedringspotensiale, men med mer tid og testing kunne vi hatt muligheten til å gå enda mer i detalj enn vi fikk tid til, i forhold til brukernes atferd og ønsker. 29

30 Javascript koden har gjennomgått flere endringer under prosjektet, som for eksempel fiksing av bug s og andre ting. Neste kodesnutt kommer fra tiden der vi bestemte oss for å gå for en avsnitt løsning. Dvs. at brukeren kan klikke på avsnitt og kommentere avsnitt. Denne tekstmarkeringen fungerer sånn at alle tekstnoder (strenger med tekst) i artikkelen blir hentet ut, og lagt i et array (en liste): function gettextnodesin(node, includewhitespacenodes){ vartextnodes =[], whitespace =/^\s*$/; function gettextnodes(node){ if(node.nodetype === 3){ if(includewhitespacenodes!whitespace.test(node.nodevalue)){ textnodes.push(node); } } else{ for(vari = 0, len =node.childnodes.length; i <len; ++i){ gettextnodes(node.childnodes[i]); } } } gettextnodes(node); returntextnodes; } Videre får alle tekststrengene en span tag rundt seg (Html element), hvis tekststrengene møter noen kriterier: for(vari = 0; i <textnodes.length; i++){ if($(textnodes[i]).closest('p').length > 0){ } else if($(textnodes[i]).closest('span').length > 0){ } else if($(textnodes[i]).parent().is('strong') $(textnodes[i]).parent().is('a')){ $(textnodes[i]).parent().wrap('<span>'); } else{ $(textnodes[i]).wrap('<span>'); } } Nå gjennomgås alle span tag ene i artikkelen, og på den måte settes setninger og avsnitt sammen: 30

31 $('#articlespan').each(function(){ varspangroup =[]; varnext = $(this).next(); spangroup.push(this); while(next.length!== 0 && next!== undefined && next[0].nodename === 'SPAN'){ spangroup.push(next[0]); next =next.next(); } $(spangroup).wrapall('<p>'); $(spangroup).contents().unwrap(); }); Det er en del mer som foregår før og etter dette, som blant annet å vaske HTML kode (fjerne unødvendig kode), legge til ikoner, css på avsnitt, og muligheten for å trykke på avsnitt og vise kommentarbokser. Men i all hovedsak er det sånn selve markeringen foregår. Twitter-autentisering Det var opprinnelig planlagt at applikasjonen skulle bruke Twitter autentisering, noe vi jobbet med i sprint 1. Aller Media mente at dette ville hindre nettroll i å bruke verktøyet. I starten av denne sprinten fikk vi beskjed om at de ville at verktøyet skulle være åpent for alle, noe Twitter autentisering hindret. Derfor bestemte de seg for å gå bort fra den ideen. Forum Et forum ble nedprioritert av Aller Media, da det var liten hensikt i å starte på funksjonalitet som de anså som tilleggsfunksjonalitet. Markeringsverktøyet måtte først og fremst være implementert, i tillegg til at Aller Media heller ville peile ut kursen for prosjektet etter hvert; Kunne være at et forum ikke er det dette verktøyet trenger. Isteden for å være fast bestemt på å implementere et forum, heller vurdere resultater fra testene før en beslutning tas. 31

32 Skjermbilder med forklaring Dette ble resultatet til test 1: Prosessen starter med denne knappen. Den skal befinne seg nederst på flere artikler hos Dagbladet. Trykker man på denne blir man ført videre til vaktbikkje domenet hvor man kan markere artikkelteksten og kommentere på den. Bildet man møter etter man har klikket på vaktbikkje knappen hos dagbladet. Fargen som er brukt i headeren er samme fargen som Dagbladet bruker da dette i første omgang er rettet mot dem. Verktøyet er noe nytt som kan være vanskelig å forstå. Derfor valgte vi å ha en SLIK GJØR DU DET boks som forklarer brukeren hvordan det fungerer. 32

33 Informasjonsboksen som forklarer brukeren hva verktøyet er. Denne blir vist når man trykker på informasjonsknappen i headeren. Bildet viser hvordan artikkelen ser ut, hvert avsnitt har en snakkeboks over seg i rødt i tillegg til at avsnittene blir markert med gul farge når man tar musepekeren over. Dette har vi gjort for å gi brukeren inntrykket av at dette er noe man kan trykke på. Vi gikk for disse fargene fordi dette er sterke farger som er mer iøynefallende. 33

34 Bildet viser hva som skjer når man klikker på et avsnitt. Her kan man skrive kommentar til avsnittet og lagre. Ikonene til venstre fra toppen er lagre, slett og legg til lenke. Bildet viser hvordan det ser ut etter man har klikket lagre. Det kommer en grønn boks med beskjeden om at det har blitt lagret for å gi brukeren en indikasjon på at noe har skjedd. I tillegg endrer kommentar boksen seg i en animasjon. Trykker man på rediger ikonet kommer man til det forrige bildet igjen hvor man legger til/endrer kommentar. 34

35 Om man vil slette det man har skrevet kommer det en popup boks hvor brukeren må bekrefte om de vil slette kommentaren. Når man er ferdig med å kommentere avsnitt må man sende inn de lagrede kommentarene. Bildet viser SEND INN knappen som sender inn kommentarene. Man får også en bekreftelsesboks her hvor man blir spurt om man er sikker på om man vil sende inn. 35

36 Bildet viser siden som kommer etter man sender inn. Her kan brukeren sende inn tilbakemelding på hva de synes om verktøyet. Når man har sendt inn tilbakemelding kommer man til neste side hvor vi takker for at brukeren tok seg tid til å bruke verktøyet. Da dette var til den første testen ville vi også ha tilbakemeldinger slik at vi kan forbedre det til neste test. Derfor la vi til et felt hvor man kan si sin mening om verktøyet. Det er store deler av dagbladets lesere som leser nettavisen på mobil. Derfor var det en stor prioritet at verktøyet skulle se bra ut på mobil også. Isteden for en informasjonsknapp la vi til et informasjonsikon på mobil, dette på grunn av mangel av plass på skjermen. 36

37 Vi valgte å ha ikonene over kommentarboksen på mobil. Å ha ikonene på siden er det ikke plass til på grunn av begrenset skjermstørrelse. Derfor valgte vi å ha det slik. Vi synes at dette ble oversiktlig på samme måte som det er på desktop. Databasestruktur Etter å ha bestemt oss for å gå vekk fra brukerautentisering (Twitter), måtte databasestrukturen skrives om. Vi valgte å beholde Users tabellen i strukturen, men under sprint 2 ble den ikke brukt til noe. Vi valgte også å fjerne muligheten for brukere å laste opp egne filer. Det var flere grunner til dette. Vi følte at en slik funksjon ikke ville bli noe særlig brukt, og ville derfor ikke bruke masse tid på lage en sikker løsning på dette. 37

38 Databasestrukturen etter sprint 2 Nå ble også tagsene til artiklene lagret. Tags er ord som kjennetegner artikkelen, hver artikkel kan ha flere tags. Eksempel på tags er kultur, DAB, Hadia Tadjik. Når en tilbakemelding blir sendt inn, hvis dette fører med seg nye tags så vil disse bli lagret i databasen. Uansett vil de bli assosiert med artiklene som blir lagret. Det betyr at hvis vi ønsker, så kan vi filtrere artiklene de tagsene vi ønsker i ettertid. Det samme skjer med artikkelforfatterne. Erfaringer I likhet med forrige sprint var vi flinke til å ha daglige standups som ga oss en oversikt over hva som har blitt gjort og hva som skulle gjøres. Vi jobbet bra som gruppe og vi klarte å gjøre klargjøre verktøyet til test 1. Forbedringspotensiale Vi savnet møter med oppdragsgiver i forkant eller i starten av sprinten, så arbeidsoppgavene ble noe uklare. Det endte med at vi begynte å jobbe med noe vi trodde måtte gjøres, men så skulle ikke det med allikevel. Det ble også ofte slik at de diskusjonene vi hadde innad i gruppa ble ensporet. Dermed ble mye tid bortkastet. 38

39 Til neste sprint må vi sørge for å ha et møte med oppdragsgiver i starten av sprinten slik at arbeidsoppgavene er klare. På den måten unngår vi uklarhet. Vi må også fortsette med å ha møter innimellom hvor vi gir korte oppdateringer slik at vi får tidlig tilbakemelding på hva som er gjort. 39

40 Kapittel 5: Test 1 Hovedprosjekt Gruppe 3 Høgskolen i Oslo og Akershus 40

41 Om test 1 Testen varte i ca. 40 timer hvor vaktbikkjeknappen var på Dagbladets artikler. Det ble kortet ned til kultur og kjendis artiklene. Formålet med testen var å få kartlagt interessen rundt et verktøy som dette. 41

42 Mål og resultat Det som var viktigst for oss og dagbladet var å få tilbakemelding på selve verktøyet. Hva brukerne syntes om det og om det er er en interesse for et slikt type verktøy. Vi håpet også å få tilbakemeldinger på design, utforming og brukeropplevelse da dette er noe vi har jobbet mye med og vil gjøre så bra som mulig. Deretter kan vi forbedre dette til sprint 3. Vi fikk bekreftet at det var en interesse for en slik tjeneste. Planen var at vaktbikkjeknappen skulle bli implementert på dagbladets kultur og kjendis artikler med det første. Da testen skulle gå live var det en hos dagbladet som gjorde en feil slik at knappen var på alle artiklene hos dagbladet. Dette førte raskt til mye trafikk. Når denne feilen ble rettet opp i, bremset trafikken opp ganske kraftig. Testen fikk mange positive tilbakemeldinger fra leserne. Hovedtanken bak verktøyet var opprinnelig kildekritikk, men i denne testen ble det mest brukt til å kommentere skrivefeil med unntak av noen få brukere. Uansett, folk flest var fornøyd med at et slikt verktøy var i utvikling. Vi fikk også noen tilbakemeldinger på hva som kanskje kan gjøres bedre, og dette tar vi med oss i den videre utviklingen. Statistikk Før testen gikk live sørget vi for å implementere Google Analytics slik at vi kunne få statistikk om adferden til brukeren på nettsiden og hvor mange det var som besøkte den. Ut i fra dette fikk vi mye data som hjelper oss videre inn i sprint 3 hvor vi kan gjøre forbedringer til test 2. 42

43 Bildet viser man hvor mange brukere som besøkte siden under testen. Man ser også hvor lenge en bruker er på siden i gjennomsnitt. Man ser at en gjennomsnittlig session er på over 1 minutt. For oss er dette tilfredsstillende i forhold til forventningene våre. Bildet viser hvor mange som besøkte siden på mobil, desktop og tablet. Av 175 brukere var det 33.71% som sendte inn kildekritikk på mobil. Av 175 brukere var det ca % som sendte inn kildekritikk på desktop. Av 175 brukere sendte 7.43% inn kildekritikk på tablet. Generelt er vi fornøyd med tallene, men det er rom for forbedringer, og dette tar vi med oss videre til sprint 3 hvor vi må komme på løsninger til å forbedre verktøyet. 43

44 Bildet viser de forskjellige knappene brukeren kan klikke på og frekvensen av disse. Total Events viser totale klikk. En bruker kan ha gjort flere klikk. Unique Events er filtrert slik at en bruker kun blir tatt med en gang. Som er grunnen til at dette er lavere. Som tallene viser er det gjort 518(20%) klikk på lagre/endre kommentar og 350(13.70%) klikk på sende inn kildekritikk. Det betyr at det ikke er alle som lagrer kommentar som velger å sende inn kritikken sin. Det var også noen som ga tilbakemelding på at send inn knappen var litt skjult i tillegg. Her er det forbedringspotensiale. For å få opp antallet som sender inn kildekritikken sin må vi gjøre noen endringer med brukeropplevelsen til neste test. Et mål var som sagt å få tilbakemeldinger på selve verktøyet for å høre hva brukerne synes. Vi fikk veldig mange bra tilbakemeldinger. Her er noen av dem: En fin mulighet til å kommentere innhold i artikkel., Verktøyet er flott, men det er tilgjengelig på for få artikler. Ser det kanskje på 1 av stykker. Hvis dette skal være noe vits må dere ha den på absolutt alt dere skriver., Genialt! Enklere enn dette kan det vel ikke bli!, Veldig greit å få muligheten til å kunne korrigere detaljopplysninger, når det er feil i artikkelen., Et veldig godt verktøy som jeg er sikker på vi i Språkpolitiet og alle flisespikkere vil like :) Enkelt i bruk. Bra!. Tabellen viser noen tilbakemeldinger fra test 1. Kommentarene er hentet fra databasen. 44

45 Dette er bare noen få av de tilbakemeldingene som kom inn, men brukerne likte muligheten til å kommentere på feil i artikler. 45

46 Kapittel 6: Sprint 3 Hovedprosjekt Gruppe 3 Høgskolen i Oslo og Akershus 46

47 Sammendrag sprint 3 Ut i fra analysen vi gjorde på Google Analytics kom vi fram til noen endringer som skulle gjøres med design og brukergrensesnitt til test 2. Et varslingssystem som varsler journalistene om kommentarer på deres artikler skulle også utvikles. Vi ble enige med oppdragsgiver om at journalistene skulle få beskjed i en oversiktlig epost. Innad i gruppen ble vi også enige om å prioritere å jobbe med rapporten. 47

48 Mål og resultat Målet for denne sprinten var i hovedsak å bedre prosentandelen av brukere som sendte inn kildekritikk på alle plattformer til test 2 ved å gjøre designforandringer som bedrer brukergrensesnittet. Som sagt brukte vi Google Analytics til å finne ut hva som trengte forbedring. Vi kom fram til at en endring i design ville bedre brukeropplevelsen og føre til at flere sendte inn kildekritikk. Vi var ganske fornøyd med endringene og hadde stor tro på at dette ville føre til en generelt høyere prosentandel. Vi kom også et stykke lenger i dokumentasjonen. Markering av tekst For å lage et verktøy som er intuitivt og enkelt å bruke, har vi prøvd å kommunisere til brukeren at de kan trykke på de ulike avsnittene. Ingen av avsnittene ser ut som knapper, men med et lite ikon øverst på hvert avsnitt gjør at avsnittet får mer affordance. Altså at avsnittet fremstår innbydende å klikke på. For å kommunisere dette enda tydeligere skifter bakgrunnen på avsnittet farge om brukeren har musepekeren over et avsnitt. Dette gjelder kun på desktop. Slik så markering av tekst ut etter fjerde iterasjon. 48

49 Slik så markering av tekst ut etter femte iterasjon. Skjermbilder med forklaring Bildet viser det gamle designet. Bildet viser det nye designet. 49

50 Over ser man forskjellen på det nye og det gamle designet (Bildet nederst er det nye designet). Det var noen som kommenterte i test 1 at de ikke skjønte at man måtte lagre kommentaren. Vi la derfor til farger på knappene fordi det skal være lettere for øyet å se at de er der. I tillegg lagres kommentaren når man klikker utenfor boksen, om ikke kommentaren(e) er lagre i fra før. Vi fjernet også legg til lenke knappen da brukerne som regel la til lenken i kommentarboksen. Grunnen til at vi valgte å ha et inputfelt for lenke i det hele tatt er å oppfordre brukeren til å legge ved en lenke for å underbygge påstanden. Bildet viser det gamle designet. Bildet viser det nye designet. Over ser man forskjellen på det nye og det gamle designet når man klikker lagre. Vi la til farge på rediger kommentar knappen også. Det var flere som ikke skjønte at man måtte sende inn kommentarene sine etter man hadde lagret, da denne knappen ble litt gjemt nederst på siden under forrige test. Derfor gjorde vi 50

51 det slik at når du lagrer en kommentar blir en boks nederst i skjermbildet synlig hvor send inn knappen er. På denne måten blir det mer forstålig og tydligere for brukerne hva de skal gjøre. Til venstre ser vi det nye designet på mobil, mens det gamle er på høyre siden. Vi plasserte lagre og slett knappene nederst på boksen fordi det er lettere for fingeren å bevege seg dit fra kommentarboksen. Vi la i tillegg på farger for at det skal være lettere å se knappene. Vi fjernet også legg til link knappen da den ble lite brukt. Isteden er det et permanent felt. Slik det er nå mener vi det er mer oversiktlig og forhåpentligvis blir dette bekreftet under andre test. Vi endret også hvordan det så ut når kommentaren er lagret. Det er ganske likt hvordan det ser ut på desktop bortsett fra at vi også flyttet denne knappen under boksen i likhet med slett og lagre knappene. 51

52 Bildet viser hvordan varslingseposten ser ut. Når man får mye tekst i en mail kan det fort bli rotete og uoversiktlig. Derfor var det viktig å utforme denne mailen så godt som mulig slik at personen som leser den skjønner hva som tilhører hva. Øverst er det en link til hvilken artikkel det er kommentert på. Under det igjen er artikkel id en. Deretter kommer kommentarene hvor man ser hvilket avsnitt det er kommentert på og kommentaren til dette. Koden blir vist i neste sprint. Kontrollpanel Med et varslingssystem under utvikling, ville Aller Media at vi skulle implementere et kontrollpanel med følgende funksjonalitet: Oversikt over kommenterte artikler. Se hvilke artikler som er mest kommentert. Muligheten til å blokkere artikler fra å kunne bli kommentert. Personer med et overordnet ansvar i Aller Media skal kunne logge seg inn på dette kontrollpanelet. Databasestruktur Databasestrukturen var stort sett uforandret under denne sprinten. 52

53 Erfaringer Det som var bra denne sprinten var kontinuerlige møter/kommunikasjon med oppdragsgiver. Slik fikk vi mer oversikt og klarhet i hva som skulle gjøres. Samarbeidet i gruppa var også bra. Dette hjalp oss til å nå målene vi hadde satt oss i starten av sprinten. Forbedringspotensiale Under denne sprinten gikk det aller meste bra, men vi kunne kanskje hatt enda et møte med produkteier nærmere slutten av sprinten for å få bekreftet at de likte endringene vi hadde gjort. 53

54 Kapittel 7: Test 2 Hovedprosjekt Gruppe 3 Høgskolen i Oslo og Akershus 54

55 Om test 2 Testen varte i ca. 70 timer kun på kultur og kjendisartiklene. Grunnen til dette var å få kartlagt interessen rundt et verktøy som dette og at ledelsen ikke ville kjøre det på alle artiklene. 55

56 Mål og resultat Målet med denne testen var å se om forandringene vi hadde implementert i sprint 3 fikk den effekten vi ønsket. Det var å øke prosentandelen som sendte inn kildekritikk, spesielt på mobil. De endringene vi hadde gjort hadde en positiv effekt på prosentandelen som sendte inn kildekritikk. Vi var litt skeptiske i forkant til at det bare skulle være på kultur og kjendissidene, men til tross for det kom det inn mange tilbakemeldinger. Også under denne testen ble verktøyet brukt mest til å rette på skrivefeil, men det kom også inn noen korrigeringer på feilinformasjon i artiklene. Statistikk Her er statistikk hentet fra Google Analytics fra test 2. Bildet viser man hvor mange brukere som besøkte siden under testen. Man ser også hvor lenge en bruker er på siden i gjennomsnitt, ca. 1 minutt. 56

57 Bildet viser hvor mange som besøkte siden på mobil, desktop og tablet. Av 151 brukere som sendte inn kildekritikk var det 84 (55.63%) som sendte inn via mobil. I forkant hadde vi trodd at store deler skulle være på desktop fordi dette var tilfelle under test 1. Det var 55 brukere (36.42%) som sendte inn kildekritikk på desktop. På tablet var det 12 (7.95%) brukere som sendte inn kildekritikk. Under denne testen var den største prosentandelen på mobil, noe som var veldig overraskende, men det betyr at endringen vi gjorde designmessig på den plattformen har hatt en positiv effekt. Bildet viser de forskjellige knappene brukeren kan klikke på og frekvensen av disse. Total Events viser totale klikk. En bruker kan ha gjort flere klikk. Unique Events er filtrert slik at en bruker kun blir registrert en gang. Som er grunnen til at dette er lavere. 57

58 Som du ser er det gjort 414(38.69%) klikk totalt på lagre/endre kommentar og 179(16.73%) klikk på sende inn kildekritikk. Det betyr at det ikke er alle som lagrer kommentar som velger å sende inn kritikken sin. Vi ville gjerne hatt en høyere prosent her, men det er vanskelig å si hva det er som gjør at denne prosenten er lav. Det kan tenkes at det er brukere som klikker seg rundt for å bli kjent med verktøyet. Vi vil videre i prosessen forsøke å utarbeide en løsning som øker denne prosenten. 58

59 Kapittel 8: Sprint 4 Hovedprosjekt Gruppe 3 Høgskolen i Oslo og Akershus 59

60 Sammendrag sprint 4 Etter å ha analysert resultatene fra test 2 med oppdragsgiver kom vi fram til endringer som skulle gjøres med designet, både på verktøyet, utformingen av mailen som ble sendt ut til journalistene, og hvordan mailen så ut i innboksen deres. En ny funksjon i mailsystemet ble også implementert. Fordi vi skal overlevere koden til Dagbladet etter test 3 brukte vi mye tid på kommentering og dokumentasjon av koden. Det ble også satt av tid til å jobbe med sluttrapporten. I tillegg hadde vi en avsluttende brukertest for å bekrefte eller avkrefte teorier angående brukeratferd vi ikke kunne få svar på igjennom Google Analytics. 60

61 Mål og resultat Målet med sprinten er å ferdiggjøre de endringer som skal gjøres og at disse endringene har en positiv effekt på testresultatene i test 3. Et annet mål er at kode skal kommenteres og dokumenteres på en god og oversiktlig måte slik at det blir enkelt for utviklerne som skal ta over prosjektet. I tillegg skal kontrollpanelet implementeres. Markering av tekst Slik ser markering av tekst ut etter siste og endelige iterasjon. Grunnlaget vårt for å kunne påstå at verktøyet lever opp til de designprinsippene nevnt i sprint 1, har vi fra Google Analytics data, synspunkter fra andre ansatte i dagbladet, og brukertester med mennesker i ulike aldre og ulike kjønn. Dette er en applikasjon der gjennomsnittbrukeren til nå bruker ca. 40 sekunder (Google Antalytics) inne i verktøyet. Det dette kan fortelle oss er noe om at brukerne finner raskt ut av hvordan verktøyet fungerer, og hvordan man får sendt inn kildekritikk. Det kan også si noe om at en andel lesere bare er inne på siden uten å foreta seg noe, eller sende inn kildekritikk. Tiden en bruker er inne i applikasjonen indikerer at tiden er knapp, og skal man få meg seg flest 61

62 mulige brukere til å sende inn kildekritikk. Derfor kan det ikke være tvil om hvordan verktøyet skal brukes. Det er derfor viktig at brukerne blir presentert noe de kjenner igjen fra før, slik at de kan forstå konseptet raskere. Så fort en bruker har klikket på et avsnitt, så dukker det opp en kommentarboks. Denne boksen er satt opp som et standard skjemaformat med inputfelter og deretter knapper. Det er også hjelpetekster og ikoner for å kommunisere enda bedre til brukeren på hva de foretar seg. Det er, ut i fra dataene fra Google Analytics, en betydelig andel som kommer på landingsiden, som foretar seg noe. Dette er også noe av grunnen til at vi ønsker å være konsistente med brukergrensesnittet på alle plattformer. Nettopp fordi brukerne er inne i verktøyet for en ganske kort periode. Det er én forskjell på mobil og desktop, og den eneste forskjellen er send inn knappen. Den er skjult til man trykker på en knapp, på grunn av begrenset plass. Med et tidsvindu på ca. 40 sekunder, så tenker vi at det er viktig å gi brukerne noe de gjenkjenner, fremfor å presentere noe helt nytt. Det være seg hvis en bruker skifter fra mobil til desktop, og visa versa. Vi prioriterte også toleranse for feil i applikasjonen. Eller handlinger som ikke brukeren gjør, men som er vesentlig for å få sendt inn kildekritikk. Ta som eksempel; når en bruker trykker utenfor en kommentarboks som inneholder en kommentar som brukeren har skrevet, blir den kommentarboksen lagret automatisk. På den måten sikrer vi at alt brukeren har bidratt med på de forskjellige avsnittene, kommer med. Andre tiltak vi har utarbeidet er å advare brukeren om at de er på vei til å forlate verktøyet, og vil miste alt de har redigert, dersom de velger å navigere vekk fra siden. Dette fordi alt som har med markeringsverktøyet å gjøre foregår på klientsiden. Her kommer vi også litt tilbake til markering av tekst, og finmotorikken som er nødvendig for å markere nøyaktig den teksten man ser for seg. Med avsnitt er man et klikk unna å kommentere. Det er ikke så nøye hvor man trykker, så lenge brukeren trykker et sted på avsnittet. Generelt tror vi dette bidrar til at verktøyet blir mer avslappende å bruke, samt at mennesker som har vanskeligheter med finmotoriske bevegelser, også skal kunne bruke verktøyet uten store problemer. 62

63 Vi har gjort oss noen tanker og erfaringer etter utviklingen av tekstmarkeringen. Ja, det er laget slik funksjonalitet før, men ikke helt på samme måte som vi har gjort. I hvert fall av det vi har sett. På bakgrunn av dette har det vært vanskelig å peile ut en endelig kurs, og jobbe mot det, fordi vi ikke kunne forutse hva slags type løsning som ville være den beste for brukeren. Det kan ikke sammenlignes med en nettbutikk, som er laget hundrevis av ganger, og der man har designmønstre som har blir forbedret i flere omganger på bakgrunn av erfaringer og lærdom. I starten av prosjektet hadde vi heller ingen kontakt med sluttbrukere, annet enn personer i Dagbladet. Mest fordi at prosjektet skulle være litt hemmeligholdt, men det hadde absolutt vært en gode idé å inkludere sluttbrukerne fra starten av. Læringskurven har vært bratt, i og med at ingen av oss hadde noe særlig erfaring med Javascript. Mye av tiden i starten gikk med til å sette seg inn i både Javascript og Jquery biblioteket. Forstå logikken og hvordan Javascript kompilerer og fungerer. Etter hvert som vi ble tryggere på Javascript, var det enklere å modifisere og legge til ny funksjonalitet, samt debugge og derfor enklere å finne bugs raskere og mer effektivt. Etter mye testing og på bakgrunn av de tilbakemeldingene vi har fått både fra lesere og testpersoner i brukertesten, kan vi konstantere at verktøyet er enkelt å bruke. Alle itereasjonene er et produkt av resultater fra brukere. Ingen rapporteringer om bugs i siste versjon (heller ikke som vi har funnet). Men på grunn av at vi forholder oss til artikler kun fra Dagbladet s API, er også verktøyet kun tilpasset disse artiklene. Planene for fremtiden innebærer i følge Dagbladet, og gjøre dette tilgjengelig for alle medier på nett. For de som måtte ønske å ta i bruk dette verktøyet. Da må man kanskje ha en felles database og API, som gjør det mer sikkert at alle artikler blir presentert likt og at verktøyet fungerer som det skal. 63

64 Skjermbilder med forklaring Noen endringer ble gjort med designet denne gangen også. Bildet til venstre viser det nye designet, mens bildet til høyre er det gamle. Det forrige designet var litt utradisjonelt og kunne kanskje være vanskelig å forstå. Derfor valgte vi å gå for et mer tradisjonelt design som brukeren er mer vandt med. Vi la til ikon i tillegg til tekst for å understreke hva knappen gjør. Nå burde det vært klart for brukeren hvilken knapp som gjør hva. Bildet viser hva brukeren ser når man lagrer en kommentar. Siden vi endret lagre og slett knappene måtte vi det med endre knappen også. Vi har lagt til to inputfelter for navn og epost. Dette må brukeren brukeren fylle inn hvis man vil ha en diskusjon med journalisten om en eventuell kildekritikk. 64

65 Bildet viser designendringen på mobil. Den forrige versjonen på mobil lignet veldig på desktop og ble litt smått på en mobilskjerm. I dette designet er det mye enklere å sende inn fordi knappen er gjort større og mer synlig. Når man lagrer en kommentar dukker det en send inn boks nederst på skjermen i tillegg til at endre knappen er stil med slett og lagre knappene(bildet til venstre). Trykker man på send inn knappen nederst på skjermen får man de samme inputfeltene som på desktop(bildet til høyre). Vi implementerte også en ny funksjon i mailsystemet som varsler journalistene. Når en artikkel har blitt kommentert på 5 ganger blir det sendt en mail til vakthavende. Om artikkelen får 20 kommentarer blir det sendt en mail til sjefene. På den måten får sjefene og vakthavende beskjed tidlig om at det må gjøres noe med en bestemt artikkel. På den måten blir en alvorlig feil eventuelt rettet opp raskere. Her er koden for utsending av mail: 1. public functionsendmail($postid, $recipients, $postcount, $articleid) { 2. if(count($recipients) == 0) { 3. array_push($recipients, "db.kildekritikk@gmail.com"); 4. } $article =Article::where('article_id', $articleid) >first(); 65

66 7. 8. /* 9. * Default: Sendonlytojournalists 10. * 5: Sendtocurrentguardianandthejournalist 11. * 20: Sendtoallchiefsinthe'chiefs' array. Thisishandledin 'ArticleController' 12. */ 13. switch($postcount) { 14. case 5: { 15. $maillayout = " s.level5"; 16. $posts = $this >getposts($articleid); 17. $data = [ 18. 'recipients' => $recipients, 19. 'posts' => $posts, 20. 'subject' => "[Kildekritikk] OBS ". $article >title, 21. 'article' => $article 22. ]; 23. break; 24. } case 20: { 27. $maillayout = " s.level20"; 28. $posts = $this >getposts($articleid); 29. $data = [ 30. 'recipients' => $recipients, 31. 'posts' => $posts, 32. 'subject' => "[Kildekritikk] OBS ". $article >title, 33. 'article' => $article 34. ]; 35. break; 36. } 66

67 default: { 39. $maillayout = " s.level1"; 40. $post =Post::find($postId); 41. $data = [ 42. 'recipients' => $recipients, 43. 'post' => $post, 44. 'article' => $article, 45. 'subject' => "[Kildekritikk]". $article >title, 46. ]; 47. } 48. } /* 51. *Send 52. * Layoutisinviews. s 53. * Thislayoutischangedaccordingtopostcountoncurrentarticle 54. */ 55. Mail::send($mailLayout, $data, function($message) use ($data) { 56. $message >from('db.kildekritikk@gmail.com'); //fromkildekritikk 57. if(sizeof($data['recipients']) > 1) { 58. $message >to($data['recipients']); // toreceiver(futurejournalistsetc) 59. $message >cc('db.kildekritikk@gmail.com'); 60. } else { 61. $message >to($data["recipients"]); // toreceiver(futurejournalistsetc) 62. } 63. $message >subject($data["subject"]); 64. }); 65.} Over ser man koden til mailfunksjonen 67

68 Kontrollpanel Kontrollpanelet ble implementert i henhold til ønskene fra Aller Media, i tillegg til ekstra funksjonalitet som viser statistikk om: Antall innsendte kritikker. Antall registrerte brukere. Trender. Siste artikkel som er kommentert. 68

69 Bildet viser hvordan trendene er vist i kontrollpanelet. Databasestruktur Ettersom vi introduserte et kontrollpanel i denne sprinten, måtte databasestrukturen tilpasses dette. ER diagrammet etter sprint 4 viser den endelige databasestrukturen. 69

70 Bildet viser den endelige ER modellen Erfaringer Vi var på bølgelengde med oppdragsgiver hele veien og det var ingen uklarheter i hva som skulle gjøres. Utviklingsprosessen gikk derfor veldig bra. Brukertest Gjennom testene vi har hatt hos Dagbladet har antallet som sender inn kommentarer vært litt lavt i forhold til antall som lagret en kommentar. Vi har diskutert mye innad i gruppa at 70

71 brukerne mest sannsynlig bare tester verktøyet for å se hva det er og at det ikke har noe å gjøre med at send inn knappen ikke er synlig nok. Vi laget derfor en brukertest. Den ligger vedlagt som Vedlegg G. Vi testet 8 personer hvor yngste deltaker var 19 år og eldste deltaker var 35 år gammel. Alle deltakere svarte at verktøyet var enkelt å bruke og vi observerte at ingen av deltakerne slet med å finne send inn knappen, noe som kan bekrefte at brukerne bare tester under første møte med verktøyet. Vi synes selv at send inn knappen er veldig synlig i siste versjon så det var en lettelse å se at ingen hadde problemer med å se den. Oppgavene var forståelige Oppgavene var enkle å utføre Det var enkelt å legge inn en kommentar på et avsnitt Det var enkelt å legge ved en lenke. Det var enkelt å sende inn. Veldig enig Enig Verken enig eller uenig Uenig Veldig uenig Tabellen viser resultatet av brukertesten. Tallene representerer svarene vi fikk. Som tabellen viser hadde vi veldig gode resultater under brukertesten. Alle 8 deltakere syntes at verktøyet var enkelt å bruke. 71

72 Kapittel 9: Test 3 Hovedprosjekt Gruppe 3 Høgskolen i Oslo og Akershus 72

73 Om test 3 Testen varte i 24 timer, men i motsetning til de andre testene ble verktøyet nå testet på alle artiklene hos Dagbladet. 73

74 Mål og resultat Målet med denne testen var å sjekke hva journalistene synes om å få mail når artiklene deres ble kommentert på. Det kan jo komme mye mail og vi tenkte det var lurt å sjekke hva de synes om det. Vi håpet også på å få tilbakemeldinger på selve verktøyet og om endringen hadde positiv effekt. Journalistene ga gode tilbakemeldinger og ville gjerne teste det mer enn 24 timer. Vi fikk også gode tilbakemeldinger på verktøyet av brukere. Statistikk Statistikk hentet fra test 3: Bildet viser antall brukere som har besøkt siden og hvor lenge de er på siden i gjennomsnitt. 74

75 Bildet viser hvor mange som besøkte siden på mobil, desktop og tablet. Av 191 brukere som sendte inn kildekritikk var det 70 (36.65%) som sendte det inn via mobil. Det var 101 (52.88%) som sendte inn på desktop. På tablet var det 20 (10.47%) som sendte inn kildekritikk. I motsetning til forrige test hvor mobil hadde flertallet, ser vi at under denne testen har flertallet vært på desktop. Forskjellen var at denne testen var på alle artikler. Her ser vi antall ganger knapper har blitt klikket. Total Events viser totale klikk. 1 bruker kan ha gjort flere klikk. Unique Events er filtrert slik at 1 bruker kun blir registrert 1 gang. Det er tydelig flere som lagrer/endrer kommentar men ikke sender inn kildekritikk. Dette er mest sannsynlig grunnet at brukerne klikker her og der for å sjekke hvordan ting fungerer. Brukertesten vi hadde bekreftet dette. 75

76 Kapittel 10: Konklusjon Hovedprosjekt Gruppe 3 Høgskolen i Oslo og Akershus 76

77 Konklusjon I starten av prosjektet satt vi oss flere mål innad i gruppen. Vi hadde som mål å bruke bachelorprosjektet til å lære nye teknologier, bli bedre i programmering og også få erfaring med utviklingsprosesser og hvordan man arbeider i en bedrift. Bachelorprosjektet har vært en god opplevelse hvor vi har lært mye nytt. Vi har økt kompetansen i Javascript og vi har også lært Laravel, noe vi ikke visste hva var før prosjektet startet. I tillegg til det har vi også fått et godt innblikk i hvordan man arbeider i en bedrift og også lært mye av hva som er viktig i en utviklingsprosess. En annen viktig ting vi har lært er hvor viktig det er å ha hyppige møter med oppdragsgiver. Det betyr utrolig mye for prosjektets fremgang. I starten var vi litt dårlige på det og da gikk utviklingen tregere enn den gjorde da vi hadde disse møtene. Bildet til venstre viser den første versjonen vi hadde av kommentarboksen, mens bildet til høyre viser den siste versjonen. Som sagt tidligere i rapporten er design noe vi brukte veldig mye tid på. Vi trodde vi hadde et bra og brukervennlig design på den første versjonen. Ut i fra test 1 kom vi fram til at den løsningen var lite intuitiv. Vi prøvde å legge på farger til test 2 men dette var heller ikke optimalt. Til slutt prøvde vi et mer tradisjonelt design, og dette ga positiv effekt under test 3. Vi har lært at når man jobber mye med et design ser man ikke ulempene selv fordi man er så godt kjent med det man jobber med. Derfor er tester utrolig viktige til å komme fram til et godt design. Det skal ikke bare se bra ut men også være enkelt å bruke og lett forståelig. Når det kommer til veien videre av verktøyet vi har utviklet skal som sagt Dagbladet ha det gående og de har også søkt om penger til videre utvikling. Med videre utvikling av verktøyet tenker Aller Media også at det kunne brukes til andre tekstbaserte medier på nett. For 77

78 eksempel at man kanskje kunne brukt det på pdf er eller andre typer dokumenter som er publisert på nett. Det er hvertfall mange muligheter og vi er spente på hva Dagbladet gjør videre. Verktøyet har fungert meget bra og oppdragsgiver er optimistiske til fremtiden. Det er for tidlig å si om verktøyet har den effekten man ønsker, men de har som sagt søkt om penger til videre utvikling og har planer om å la det kjøre på artiklene sine etter vi er ferdig. Aller Media annonserte at de lot verktøyet gå live fra og med 18. mai. 78

79 Kildelister boundless.com (2015) Cognitive Development in Adulthood. psychology textbook/human de velopment 14/early and middle adulthood 74/cognitive development in adulthood ( ) ( ) ( ) is Universal Design/The 7 Principles/ ( ) ( ) 79

80 Vedlegg Vedlegg A Kravspesifikasjon Vedlegg B Prosjektplanlegging Vedlegg C Prosjektskisse Vedlegg D Forprosjektrapport Vedlegg E Milepælsplan Vedlegg F Aktivitetsplan Vedlegg G Brukertest 80

81 Vedlegg A Kravspesifikasjon Hovedprosjekt Gruppe 3 Høgskolen i Oslo og Akershus 81

82 Funksjonelle og -ikke funksjonelle krav Funksjonelle krav Applikasjonen skal gi brukeren muligheten til å markere avsnitt i artikkelteksten. Applikasjonen skal gi brukeren muligheten til å kommentere på flere avsnitt. Journalist skal bli varslet når deres artikler har fått en tilbakemelding. Brukeren skal kunne legge ved en lenke som bevis for deres kildekritikk. Verktøyet skal varsle journalistene via en epost. Applikasjonen skal gi brukeren muligheten til å komme med tilbakemelding på verktøyet. Når en artikkel har fått 5 kommentarer skal applikasjonen sende en mail automatisk til vakthavende. Når en artikkel har fått 20 kommentarer skal applikasjonen sende en mail automatisk til sjefene. Applikasjonen skal ha et kontrollpanel. Man må ha en brukerkonto for å bruke kontrollpanelet. Ikke funksjonelle krav Alle datamaskiner kan brukes til å få tilgang til nettstedet, men hastigheten kan variere. Alle smarttelefoner kan brukes til å få tilgang til nettstedet. Prosjektet skal dokumenteres etter HiOA sine standarder. Personvern Navn og epostadresser som lagres i databasen skal ikke være tilgjengelig offentlig, eller sendes til en tredje part. Krav til kode All kode funksjoner skal kommenteres på en slik måte at andre utviklere raskt forstår hensikten. Tydelige metode navn. 82

83 All kode og kommentarer skal skrives på engelsk. Universell Utforming Applikasjonen skal være lett å bruke. Applikasjonen skal være tilpasset alle skjermstørrelser. Tekniske krav Programmeringsspråk: PHP, Javascript, HTML5, CSS Databasekommunikasjon: MySQL Server med Apache, MySQL og PHP installert. Sikkerhetskrav For å sikre oss at det vi gjør skal være skjult så lenge vi jobber med prosjektet skal selve koden ligge på et privat repo på Github hvor bare gruppemedlemmene skal ha tilgang. Det er Aller Media AS som eier produktet og vi har ikke lov til å dele koden med andre enn dem. Når det kommer til informasjon en bruker eventuelt skulle avgi i kildekritikkverktøyet skal det ikke gis eller selges til den tredje part. Brukervennlighetskrav Brukervennligheten av verktøyet er meget viktig for oss. Dette kommer til å være i bakhodet når besluttelser om utforming og design skal bli tatt. Det er et nytt type verktøy og da kan det være vanskelig å forstå hva det er og hvordan det fungerer. Derfor er det viktig at vi bruker ekstra mye tid på design og utforming. Da brukervennlighet er et stort fokus for oss håper vi å oppnå et design som er så brukervennlig som mulig når prosjektet skal leveres. Fremtidig utvikling I planleggingsfasen gjorde Dagbladet det klart at de skulle videreutvikle verktøyet etter vi hadde levert oppgaven. Dette gikk til tanke da det skulle bestemmes hvilke teknologier som skulle brukes. Det endte med at vi ble pålagt å bruke teknologier som Dagbladet var vandt med for å gjøre det så enkelt som mulig for dem videre. 83

84 Under utviklingsprosessen skal vi ha dette i bakhodet ved å navngi variabler, klasser og funksjoner med forståelige navn. Vi skal også kommentere koden tydelig. Slik skal være så enkelt å forstå hva som gjør hva i programmet. 84

85 Vedlegg B Prosjektplanlegging Hovedprosjekt Gruppe 3 Høgskolen i Oslo og Akershus 85

86 Innholdsfortegnelse: Gruppen og samarbeidet Planlegging og metoder Utfordringer Veiledning Verktøy Gruppen og samarbeidet Gruppen som har jobbet med prosjektet bestod av Simen Arvnes, Simen Berge og Mats Ødegaard Jensen, alle studenter av Anvendt Datateknologi på Høgskolen i Oslo og Akershus. Gruppen bestod bare av medlemmer som hadde samarbeidet tidligere og var godt kjent med hverandre før prosjektet startet. Vi startet med å sende ut e poster til forskjellige bedrifter, høsten Det gikk flere uker før vi fikk respons fra Aller Media og noen andre bedrifter. Vi besøkte alle, men det var Aller Media sin oppgave som vi fant mest interessant, samtidig som de kunne love oss plass hos dem hvor vi kunne sitte daglig og arbeide med oppgaven. Planlegging og metoder Vi hadde bestemt oss for å følge en utviklingsmetodikk allerede før prosjektet var i gang. Aller Media var også tidlig ute med å anbefale oss verktøy og en utviklingsprosess som de er godt kjent med internt. Dagbladet bruker en blanding av Scrum og Kanban, og etter en kort presentasjon bestemte vi oss for å gå for dette. Utviklingen foregår i sprinter, helst med en test etter hver sprint. Deretter evaluerer man sprinten og ser på resultatene, for så å kunne planlegge neste sprint. For å fordele oppgaver under hver sprint, brukte vi JIRA. Et utviklingsverktøy som gjør det enkelt å organisere og fordele arbeidsoppgaver til de forskjellige team medlemmene. JIRA er en webapplikasjon som består av en tavle med ulike kolonner. Hver kolonne representerer et steg i oppgaveprosessen. Hver oppgave representeres ved hjelp av et kort. Dette kortet kan tildeles medlemmer i teamet. Kortene flyttes fra kolonne til kolonne etter hvor i prosessen oppgavene er. 86

87 Bildet viser JIRA tavlen med oppgaver, hvem i teamet som er tildelt hvilke oppgaver, og hvor i prosessen oppgaven er for øyeblikket. På denne måten kan teamet se hvem som jobber med hva, hva slags oppgaver hindrer andre i å fullføre sine egne oppgaver, og hvor langt oppgavene er på vei mot en ferdigstilling/testing. Gruppen så på utviklingsverktøy som Trello og Waffle, men i og med at Dagbladet allerede hadde en bruker, bestemte vi oss for å bruke dette. I tillegg kunne personer i Dagbladet med tilknytning til prosjektet følge med på progresjonen vår. Utfordringer Utfordringene i dette prosjektet har vært å sette seg inn i ny teknologi, samt bruke de verktøyene vi hadde tilgjengelig på en best mulig måte. Gruppen var kjent med design prinsippene, men å finne et design som gjorde brukeropplevelsen best mulig, var en utfordring. Spesielt med tanke på at vi i starten kodet design forslagene, isteden for å tegne grove skisser. Dette ble vi bedre på senere i prosjektet. En annen utfordring var å kartlegge hvilke risikoer vi kunne støte på underveis i prosjektet. Grunnen til dette var å jobbe innenfor et nytt domene, ny teknologi, og at prosjektet var omfattende nok til at vi ikke hadde alt klart for oss da prosjektet startet. 87

88 Veiledning Når det kommer til veiledning i prosjektet har vi fått god hjelp fra veileder på HiOA, Torunn Gjester. Hun kom med gode innspill angående rapporten underveis. Sondre Husby Rostad startet som vår eksterne veileder, men han tok en ny jobb midt i prosjektet. Christoph Schmitz overtok hans rolle. Begge har kommet med gode tips og råd underveis i utviklingen av prosjektet. Verktøy Laravel/PHP Homestead/Vagrant MySQL Javascript/Jquery Sass (CSS) Git/Github Jira Sketch Google Docs Slack IDE/Teksteditor Laravel Laravel er rammeverket hele applikasjonen er bygget på. Dette er et av de mest populære rammeverkene som er laget med PHP. Rammeverket er bygget på MVC (Model View Controller) modellen. Laravel kommer med en rekke fordeler rett ut av boksen. Det er veldig godt dokumentert og har en stor brukerbase, noe som gjør at det blir lettere å finne svar på problemer. De har også gode videoer som gir en god introduksjon til hvordan Laravel er bygd opp og hvilke verktøy rammeverket tilbyr. Laravel kommer med et kraftig kommandolinje verktøy kalt Artisan som gjør det mer effektivt å opprette modeller/kontrollere. Her er et eksempel på hvordan man oppretter en kontroller med Artisan verktøyet: phpartisanmake:controllereksempelcontroller Man har også et kraftig migrasjonsverktøy som gjør det enkelt å jobbe mot f.eks en MySQL database: 88

89 1. classcreateuserstable extendsmigration { 2. public functionup() 3. { 4. Schema::create('users', function (Blueprint $table) { 5. $table >increments('id'); 6. $table >string('name'); 7. $table >string(' ') >unique(); 8. $table >string('password'); 9. $table >remembertoken(); 10. $table >timestamps(); 11. }); 12. } 13. public functiondown() 14. { 15. Schema::drop('users'); 16. } 17.} phpartisanmigrate Dette oppretter tabellen users Laravel har også en kraftig template motor kalt Blade som gjør det enklere å koble HTML/PHP sammen. Eksempel på bruk av blade templating: 1. //Hvisbrukererloggetinn 3. //Visinnholdforinnloggetbruker 5. //Visnoeannetinnhold 89

90 Homestead/Vagrant Vagrant er virtuelle maskiner man setter opp med ønsket programvare. Fordelen med dette er at medlemmene på gruppen da vil ha like utviklingsmiljøer, som senker sannsynligheten for at man møter på unødvendige problemer. Homestead er en ferdig satt opp virtuell maskin av folkene som har laget Laravel. Homestead er satt opp med et utviklingsmiljø som passer perfekt for Laravel applikasjoner. Dette er også noe vi inkluderte i Github repoet, noe som gjorde at man kunne komme fort i gang ved eventuelle nye nedlastninger av prosjektet. MySQL MySQL er et kjent og veldig utbredt databaseadministrasjonssystem. MySQL er veldig mye brukt, og er kjent for å være en vesentlig del av LAMP (Linux, Apache, MysQL, PHP) systemer. Siden vi visste at MySQL fungerer bra med PHP(Laravel), og vi hadde erfaring med MySQL fra skolen valgte vi dette. Javascript/Jquery Javascript er et scriptspråk som ofte brukes til å tilføre dynamiske elementer på nettsider. Det er verdt å nevne at Javascript har hatt en vekst de siste par årene pga forskjellige rammeverk som Node, React og Angular. EcmaScript standarden har også stadig blitt oppdatert, noe som har ført til en modning av språket. Jquery er et meget kjent og populært Javascript biblotek, utviklet for å forenkle klientskriptingen av HTML. Dette bibloteket gjør det også enklere å velge HTML elementer og å lage animasjoner blant annet. En av mange fordeler med å bruke Jquery er måten man kan plukke ut HTML elementer. Her er et eksempel på jquery kode i motsetning til vanlig javascript. 1. //vanligjavascript 2. vardiv =document.findelementbyid('div'); //sammekodeskrevetijquery 5. vardiv =$('#div'); 90

91 Sass Sass er en utvidelse av CSS, som bidrar til økt effektivisering av språket. Med Sass kan man opprette variabler, man kan flette elementer, man kan importere andre stilark inn i et hovedstilark. Funksjonene Sass bidrar til å holde ting organisert, strukturert og det forenkler utviklingen. Under kan man se et eksempel på bruk av variabler i Sass 1. //_farger.scss 2. $red: red; 3. $blue = blue; 4. body { 5. background: $red; 6. color: $blue; 7. } Eksempel på fletting av elementer: 1. //Flettingavelementer 2. nav { 3. background: $blue; 4. ul { 5. display: flex; 6. li { 7. list style: none; 8. a { 9. text decoration: none; 10. } 11. } 12. } 13.} 91

92 Man kan også importere stilark inn i hverandre: 1. //base.scss content { 5. color: $red; 6. background: $blue; 7. } Her importerer vi stilarket _farger.scss. Det gjør at vi kan bruke variablene som er opprettet fra det stilarket i nåværende stilark. Mixins er en Sass funksjon som lar deg opprette stiler som man bruke gjennom hele prosjektet. Under ser man et eksempel på mixins: 1. //_mixins.scss 2. $tablet width: 768px; 3. width:#{$tablet width}){ 7. } 8. } //base.scss 11.@import'mixins'; 12.#main header { 14. height: 40px; 15. } 16.} 92

93 Gulp Gulp er et verktøy for kompilering og komprimering av forskjellige filtyper. Gulp er et verktøy bygget med NodeJS. Gulp brukes til forskjellige oppgaver som å kompilere Sass filene til CSS, komprimere/ optimalisere bilder og komprimere alle Javascript filene til en fil. Dette bidrar til å gjøre applikasjonen så effektiv som mulig med tanke på lastetiden av nettsiden. Eksempel på en gulp task hvor man kompilerer Sass filene til CSS: 1. gulp.task('css', function() { 2. gulp.src(sources.css) 3..pipe(sass()) 4..on('error', function(err){ 5. logerror('anerroroccuredcompilingsass: \n' +err); 6. }) 7..pipe(gulp.dest(destinations.css)) 8. }); Github Github er en nettbasert versjonskontroll tjeneste som lar deg opprette oppbevaringssteder for kodeprosjekter. Med dette verktøyet kunne alle medlemmene i gruppa bidra med kode uten å være redd for at skulle brekke applikasjonen ettersom man kan gå tilbake til eldre versjoner hvis noe slikt skulle skje. Github lar deg også opprette private oppbevaringssteder, det betyr at det er bare medlemmene på gruppen og evt andre vi skulle invitere, kan se prosjektet. Dette var også et krav fra fra Aller Media ettersom det var noe de brukte. Slack Slack er verktøyet vi brukte for å kommunisere internt i gruppen og med vår eksterne veileder. Fordelen med Slack i motsetning til andre lignende chatte programmer, er at man kan opprette egne kanaler for forskjellige emner. Dette sørger for at man kan ha flere diskusjoner samtidig uten at det blir for mye rot. 93

94 Sketch Når vi skal begynne å designe siden er det viktig å lage flere mockups. Sketch er et verktøy som gjør dette veldig enkelt. 94

95 Vedlegg C Prosjektskisse Hovedprosjekt Gruppe 3 Høgskolen i Oslo og Akershus 95

96 Prosjektskisse Anvendt Datateknologi våren 2016 Bacheloroppgave 2016, Høgskolen i Oslo og Akerhus Gruppe 3 Arbeidstittel: Kildekritikk Oppdragsgiver Aller Media AS Adresse: Karvesvingen 1, 0579 Oslo Epost: post@aller.no Kontaktperson Sondre Husby Rostad Epost: sondrehr@gmail.com Christoph Schmitz Epost: Christoph.Schmitz@dagbladet.no Gruppemedlemmer Simen Arvnes Epost: simenarvnes@gmail.com Studentnummer: s Simen Berge Epost: bergesimen@gmail.com Studentnummer: s Mats Ødegaard Jensen Epost: matsjens1@gmail.com Studentnummer: s Prosjektbeskrivelse Oppdragsgiver for vårt bachelorprosjekt er Aller Media AS. Aller er et mediekonsern som omfatter kjente norske merkevarer som blant annet Dagbladet, Se og Hør, KK og SOL. Vårt prosjekt går under navnet vaktbikkjene. Det er et verktøy som skal gjøre det mulig for leserne av Aller s nettaviser å bidra med korreksjoner, fakta, synspunkter og dybde en slags kildekritikk. For at dette skal fungere må en kildekritikk editor aktiveres når leseren klikker på en spesifikk knapp på en artikkel hos Dagbladet. Etter denne knappen er klikket blir man navigert til et nytt domene hvor artikkelen blir presentert. Her kan man markere tekst i artikkelen og deretter kommentere på det man har markert. Dette betyr at vi må ta i bruk både backend og frontend programmering, prototyping, universell utforming og systemutvikling. Nye teknologier og rammeverk for å utføre prosjektet på best mulig måte vil også bli brukt. 96

97 Vedlegg D Forprosjektrapport Hovedprosjekt Gruppe 3 Høgskolen i Oslo og Akershus 97

98 Forprosjektrapport Gruppe 3, Anvendt Datateknologi våren Presentasjon 2. Sammendrag 3. Dagens situasjon 4. Mål og rammebetingelser 5. Løsninger/alternativer 6. Analyse av virkninger 1. Presentasjon Gruppen består av Simen Berge, Simen Arvnes og Mats Ødegaard Jensen. Vi tilhører studiet Anvendt Datateknologi på Høgskolen i Oslo og Akershus. Gjennom studiene har alle gruppemedlemmene fordypet seg i programmering og utviklingsprosesser. Vi har også jobbet sammen tidligere i andre prosjekter. Prosjektet er en utviklingsoppgave for Aller Media AS. Løsningen vil bestå av en backend som kobler sammen bruker feedback og artikkeldata og også en front end løsning. Utførelse av oppgaven vil skje i en periode på rundt 5 måneder. Kunnskaper som kreves i dette prosjektet er programmering(frontend og backend), universell utforming, prototyping og systemutvikling. Oppdragsgiver er Aller Media AS. Aller Media AS er i dag det fjerde største medieselskapet i Norge med en omsetning på ca 2 milliarder kroner. Deres største merkevarer er blant annet Dagbladet, Se og Hør og SOL. Vår oppgave er i førsteomgang rettet mot Dagbladet. Kontaktperson og veileder hos Dagbladet er Sondre Husby Rostad og Christoph Schmitz som er Product Manager s. Veileder tildelt av Høgskolen i Oslo og Akershus er Torunn Gjester. 2. Sammendrag Dagbladet ønsker at brukeren skal ha muligheten til å gi kildekritikk på deres artikler. Leserne skal gjennom verktøyet bidra med korreksjoner, fakta, synspunkter og dybde en slags kildekritikk. Man skal ha muligheten til å markere tekst i en artikkel og deretter rapportere feilkilder og kommentere det man har markert. 3. Dagens situasjon Aller er et av norges største mediekonsern. De største merkevarene er Dagbladet, Se og Hør, KK og SOL. 98

99 Selskapet eies av Aller Holding A/S og har søsterselskaper i Sverige, Danmark og Finland. Konsernet i Norge har totalt ca. 650 ansatte og holder til i attraktive lokaler på Hasle i Oslo. Aller har mange prosjekter på gang. Blant annet er de interressert i å bedre artiklene sine ved å gi leserne muligheten til å gi kildekritikk. Det er her vi kommer inn. Vi skal utvikle verktøyet som skal gi leserne denne muligheten. 4. Mål og rammebetingelser Mål: Målet for prosjektet er å til slutt ha et fungerende system som kan brukes. Dagbladet skal deretter teste det på sin nettside for å kartlegge interessen rundt en slik tjeneste. Teknologier: Gruppen skal bruke Git som versjonskontroll. Gruppen skal bruke Jira for prosjektstyring. Gruppen skal jobbe smidig ved hjelp av både Scrum og Kanban. All kode skal være skrevet og kommentert på engelsk. Kilekritikkeditoren skal utvikles i Javascript. Nettsiden skal utvikles i HTML5, CSS3/Sass og Javascript. 5. Løsninger/alternativer Markeringsverktøy På Dagbladet s sider skal det være en knapp som aktiverer denne editoren. Etter brukeren har klikket på denne skal det være mulig å markere tekst i artikkelen og deretter kommentere dette. Kommentaren blir sendt til forumet hvor andre brukere kan lese og kommentere på innlegget. Teknologier som skal brukes her er for det meste Javascript. 6. Analyse av virkninger Forklar hvilke virkninger det (de) omtalte alternativene vil få Teknologier: Det var viktig at Dagbladet kunne fortsette å videre utvikle systemet etter vi hadde levert. Derfor var det viktig for dem at det skulle brukes php laravel da det er noe de bruker mye av og enkelt kunne fortsette på senere. Læringsutbytte: Et viktig mål for prosjektet er å lære er nye teknologier og også få erfaring i utviklingsprosesser og hvordan man arbeider i industrien. Oversikt: For å jobbe på en oversiktlig og ryddig måte har vi valgt å bruke verktøy for både versjonshåndtering og prosjektstyring. Dette gir oss også erfaring med verktøy som er mye brukt i arbeidslivet. 99

100 Vedlegg E Milepælsplan Hovedprosjekt Gruppe 3 Høgskolen i Oslo og Akershus 100

101 Milepælsplan Gruppe 3, Bachelorprosjekt 2016 Høgskolen i Oslo og Akershus NB! PLANEN KAN ENDRES I LØPET AV PROSJEKTET Fase Varighet Beskrivelse Oppstart Prosjektplan legges, planlegging skal være ferdig 25. januar 2016 Backlog av arbeidsoppgaver til sprint 1 legges til. Sprint Den første sprinten settes i gang. Her vil det være mest fokus på backend delen da dette må være tidlig ferdig. Sprint Andre sprint startes. Oppgavene som skal gjøres blir bestemt i slutten av sprint 1 og på grunnlag av hvordan backlogen ser ut. Milepæl 1 Første test Presentere resultat av test 1 for veileder hos Aller. Sprint 3 Milepæl 2 Andre test Den første testen skal gå live hos Dagbladet Resultatet av test 1 skal vises frem for veileder hos Aller. Tilbakemelding blir skrevet ned. Nye oppgaver tildeles. Tredje sprint starter. Oppgavene som skal gjøres blir bestemt av resultatene fra test Andre test skal gå live hos Dagbladet Påskeferie Presentere resultat av test 2 for veileder hos Aller. Sprint 4 Resultatet av test 2 skal vises frem for veileder hos Aller. Tilbakemelding blir skrevet ned. Nye oppgaver tildeles. Fjerde sprint starter. Oppgavene som skal gjøres blir bestemt av resultatene fra test 2. Milepæl 3 Tredje test Tredje test skal gå live hos Dagbladet. Presentere resultat av test 3 for veileder hos Aller Resultatet av test 3 skal vises frem for veileder hos Aller. Tilbakemelding blir skrevet ned. Nye oppgaver tildeles. 101

102 Forberedelse til levering Milepæl 4 Levering Da dette var siste test skal vi bruke mye tid på å fikse eventuelle bugs, Ferdiggjøre verktøyet, Kommentere og dokumentere kode, Skrive ferdig rapport Ferdiggjøre rapport. Kode skal overleveres til Aller. Rapport skal leveres til HiOA den 24. Presentasjon Muntlig presentasjon av prosjektet. 102

103 Vedlegg F Aktivitetsplan Hovedprosjekt Gruppe 3 Høgskolen i Oslo og Akershus 103

104 n med grønn bakgrunn betyr normal oppgave, c med rød bakgrunn er en kritisk oppgave og d med gul bakgrunn er en oppgave avhengig av andre. 104