Utvikling av nettsted for Bypakke Nedre Glomma

Transkript

1 Utvikling av nettsted for Bypakke Nedre Glomma (Bacheloroppgave ITF32012) Forfattere: Eugen Anstensrud, Jon Martin Filberg og Håvard Ramstad Avdeling for informasjonsteknologi, Høgskolen i Østfold, studiested Halden

2

3 HØGSKOLEN I ØSTFOLD Avdeling for Informasjonsteknologi Remmen 1757 Halden Telefon: URL: BACHELOROPPGAVE Prosjektkategori: Informasjonsteknologi Omfgang i studiepoeng: 20 Fagområde: Informasjonssystemer X Fritt tilgjengelig Fritt tilgjengelig etter Tilgjengelig etter avtale med oppdragsgiver Tittel: Utvikling av nettsted for Bypakke Nedre Glomma Forfatterere: Eugen Anstensrud, Jon Martin Filberg og Håvard Ramstad Avdeling / Program: Avdeling for Informasjonsteknologi Oppdragsgiver: Østfold Fylkeskommune Dato: 22.mai 2014 Veileder: Gunnar Misund Prosjektnummer: BO Kontaktperson hos oppdragsgiver: Lars Husvik Ekstrakt: Rapporten tar for seg utviklingen av en prototype for nettstedet Bypakke Nedre Glomma. Rapporten inneholder teori rundt relevante temaer knyttet til utvikling av et universellt utformet nettsted som skal være funksjonelt på ulike medier. Rapporten ble utarbeidet våren 2014 i samarbeid med Østfold Fylkeskommune. 3 emneord: Webutvikling Universell utforming Responsiv design

4 Sammendrag Østfold Fylkeskommune inngikk den en samarbeidsavtale om areal- og transportutvikling i Nedre Glomma. I den anledning er det ønsket et nettsted som skal tilby innbyggerene i regionen informasjon om utviklingen. Det er prosjektgruppens oppgave å utvikle en prototype av nettstedet. Prosjektgruppen har i prosjektperioden benyttet ulike metoder for å gjennomføre oppgaven. Som en del av forundersøkelsen ble det utført analyser av nettsteder med lignende formål i andre kommuner. Intervjuer av representanter fra oppdragsgvier var viktig for utformingen av prosjektet. Innledningsvis ble det også innhentet relevant teori rundt sentrale temaer i prosjektet. Forundersøkelsen ga prosjektgruppen grunnlaget for utviklingen av prototypen. Tett samarbeid med oppdragsgiver under utvikling av prototypen sørget for enighet om resultatet. Avslutningsvis ble det gjennomført en brukertest, hvor representanter fra Nedre Glomma regionen utførte utvalgte oppgaver på nettstedet. Resultatet av brukertesten ga prosjektgruppen indikasjoner på at prototypen fulgte god informasjonsarkitektur. Brukertesten ga svar på prototypens tilgjengelighet for brukere med nedsatt syn. Resultatet av bacheloroppgaven er denne rapporten, samt en prototype av et nettsted som er tilpasset ulike medier og som også følger kravene om universell utforming. i

5 Takk Til Vi i prosjektgruppen vil takke Østfold Fylkeskommune for et godt samarbeid igjennom prosjektperioden, og for alle ressurser vi har fått til disposisjon. En spesiell takk rettes til Lars Husvik, Tor Stabbetorp og Fredrik Norland som har behandlet oss med respekt og ivaretatt våre interesser. Prosjektgruppen ønsker også å takke prosjektgruppens veileder, Gunnar Misund, for veiledning. Videre vil vi takke Høgskolelektor Håkon Tolsby som har kommet med konstruktive tilbakemeldinger til prosjektet. ii

6 Innhold Sammendrag Takk Til Figurliste i ii vi Tabelliste 1 1 Introduksjon Prosjektgruppen Oppdragsgiver Oppdraget Oppdragsformulering Avgrensinger Rapportstruktur Analyse Mål og visjon Informasjonsarkitektur og webdesign Brukere av nettstedet Analyse av lignende nettsteder Universell utforming WCAG 2.0 gjeldende krav Accessible Rich Internet Applications (WAI-ARIA) Visuelle tilpasninger Kulturelle tilpasninger Responsiv Design Metode Kvalitativ intervju Utviklingsprosessen Brukertest Resultater Intervju av Tor Stabbetorp Intervju av Fredrik Norland Idémyldringsmøte Brukertest iii

7 iv INNHOLD 5 Utforming Wireframe Utforming av protoype Iterasjon Iterasjon Iterasjon Merketabell, metadata og sitemap Oppfylling av suksesskriterier i WCAG Utførelse av responsiv design Diskusjon Brukertest Nettstedets mål Utforming Videre arbeid Refleksjoner Konklusjon 93 Bibliografi 95 8 Vedlegg Vedlegg A - Møtereferat Vedlegg B - Forprosjektrapport Vedlegg C - Analyse av Bypakka.no Vedlegg D - Intervju med Tor Stabbetorp Vedlegg E - Intervju med Fredrik Norland Vedlegg F - Kortsortering Vedlegg G - Brukertest vedlegg H - CD med prototype Register 157

8 Figurer 2.1 Søkeprosessen [15] Informasjonsarkitekturens tre kjente sirkler [20] Illustrasjon på førstegangsbrukere av et nettsted Variasjoner av Tab-design Skjermbilde av Bypakke.no Skjermbilde av miljøpakken.no Skjermbilde av apt-samarbeidet.no Skjermbilde av hoppoverbommen.no Tradisjonell utforming Flytende utforming Grid-System Sammenhengen mellom metode og intervjuform Designsyklus Prosesshendelser i prosjektperioden Kartløsning fra miljopakken.no Wireframe Wireframe Wireframe Nettstedets forside Nettside for kategorien Sykkelvei Nettstedets forside Innhold i bannerboks 1 etter tilbakemelding fra oppdragsgiver Global meny etter tilbakemeldinger fra oppdragsgiver Nettstedets hovedside for Sykkelvei Lokalmeny før tilbakemelding fra oppdragsgiver Lokalmeny etter tilbakemelding fra oppdragsgiver Forside før Forside etter Hovedside før Lokalmeny etter tilbakemelding fra oppdragsgiver Kartoversikt over tiltak i Nedre Glomma Publikums innspill til tiltak Innsending av innspill til tiltak, versjon Innsending av innspill til tiltak, versjon v

9 vi FIGURER 5.20 Logo fra oppdragsgiver Logo etter behandling av prosjektgruppen Bannerboks Kollektiv med introduksjonstekst, slide Bannerboks Kollektiv med lenke til kampanje hos Østfold kollektivtrafikk, slide Bannerboks Sykkel med lenke til reisevaneundersøkelse hos TØI, slide Bannerboks Sykkel med lenke til sykkelplanlegger, slide Forhåndvisning av tiltak under planlegging. Kategori Bil Enkel thesauri for begrepet Bil Sitemap for nettstedet Tabell over oppbyggningen av WCAG Forhåndsvisning av tiltak Hovedtittel.Side for Sykkel Lokal meny, tekststørrelse 100% Lokal meny, tekststørrelse 200% Lokal meny, tekststørrelse 400% Innspillskjema til tiltak Nettstedet fra ulike enheter Header og navigasjon. 1366px. PC/MAC Header og navigasjon. 1024px. Nettbrett Header og navigasjon. 640px. Mobil Header og navigasjon. 640px. Mobil. Brukeren har klikket på menyikonet og menyvalgene er synlig Lokal meny, 1366px. PC/MAC Lokal meny, 1024px. Nettbrett Lokal meny, 640px. Mobil Dataflyt for innspill på nettstedet Kortsortering utført av Fredrik Norland Kortsortering utført av Tor Stabbetorp Kortsortering utført av Lars Husvik Felles kortsortering utført av Fredrik Norland, Tor Stabbetorp, Lars Husvik og prosjektgruppen

10 Tabeller 2.1 Aldersfordeling i Sarpsborg, Fredrikstad og Hvaler kommune Aldersfordeling i Nedre Glomma regionen Oversikt over merker i den globale menyen Oversikt over farger og kontrastforhold

11 Kapittel 1 Introduksjon Dette kapittelet presenterer prosjektoppgaven, oppgavens bakgrunn, formål og avgrensninger. Kapittelet introduserer prosjektgruppen og prosjektets oppdragsgivere, det gir også en oversikt over rapportens struktur. 1.1 Prosjektgruppen Prosjektet ble gjennomført av studentene Eugen Anstensrud, Håvard Ramstad og Jon Martin Filberg i tidsrommet Samtlige medlemmer av prosjektgruppen studerer bachelorstudiet informasjonssystemer og IT- ledelse ved Høgskolen i Østfold. Studiet tar for seg informasjonsog kommunikasjonsteknologi (IKT) i forhold til individer, grupper, organisasjoner og samfunn. Faget fokuserer på forholdet mellom teknologien og menneskene som skaper og benytter seg av kunnskapen og informasjonen.[11] Gruppemedlemmene har god erfaring av å jobbe sammen etter å ha gjort prosjektarbeid sammen i forbindelse med flere kurs i studiet. 1.2 Oppdragsgiver Østfold Fylkeskommune har omtrent 2500 ansatte. Disse er fordelt på avdelinger og virksomheter i Østfold. Østfold fylkeskommune leverer tilbud som går på tvers av kommunegrensene og har blant annet ansvar for den regionale samfunnsutviklingen. Det vil si at de arbeider for utviklingen av arbeidsplasser gjennom å legge til rette for nyskapning og innovasjon. Under prosjektet samarbeider prosjektgruppen med Lars Husvik, Tor Stabbetorp og Fredrik Norland som alle er representanter for Østfold Fylkeskommune. Tor Stabbetorp er prosjektleder i koordineringsutvalget, som består av representanter for samarbeidspartene i bypakke for Nedre Glomma. Fredrik Norland er kommunikasjonsrådgiver i Kommunikasjonsstaben hos Østfold fylkeskommune. Lars Husvik jobber som rådgiver i samferdselsseksjonen 1.3 Oppdraget På grunn av befolkningsøkning, økonomisk utvikling og økt samhandling i Nedre Glomma, forventes en økning av transport i regionen. Økningen vil by på utfordringer innenfor fremkommelighet, transport, miljø og sikkerhet. For å løse disse utfordringene ble det den inngått 2

12 1.4. Oppdragsformulering 3 en 5-årig samarbeidsavtale om areal- og transportutvikling i Nedre Glomma. Partene i samarbeidsavtalen er Østfold Fylkeskommune, Statens Vegvesen region Øst, Fredrikstad kommune og Sarpsborg kommune. Samarbeidets hovedmål er å utvikle Nedre Glomma som en attraktiv og konkurransedyktig region på en bærekraftig måte basert på virkemidler innen areal- og transportsektoren. Gjennom avtalen skal det de neste årene benyttes betydelige midler på utrustning av gang- og sykkelvei, bilvei og offentlig transport i og mellom byene Fredrikstad og Sarpsborg. 1.4 Oppdragsformulering Østfold Fylkeskommune (ØFK) ønsker en nettbasert informasjonskanal der de kan informere om ferdige, pågående og planlagte tiltak for utbedring av samferdselsrelaterte saker i Nedre Glomma regionen. Oppgaven til prosjektgruppen vil være å kartlegge målet med nettstedet, hva nettstedet skal inneholde og hvordan informasjonen skal presenteres. Det skal lages en prototype av nettstedet, som også skal være tilgjengelig for alle på alle medier. Med tilgjengelighet for alle menes en universell utforming(uu) som tar hensyn til ulike forutsetninger hos brukerne. Tilgjengelighet på alle medier betyr at nettstedet skal være funksjonelt på ulike enheter, som mobil, nettbrett og PC. Prototypen skal utvikles på bakgrunn av informasjon som prosjektgruppen tilegner seg gjennom prosjektperioden. 1.5 Avgrensinger Det ble satt avgrensinger på oppgaven i samarbeid med Østfold Fylkeskommune for å begrense omfanget på prosjektet. Det ble enighet at utvikle prototypen ikke skulle utvikles i et Content management system (CMS). Det var dermed opp til oss hvordan vi ønsket å utvikle prototypen. Vi har valgt å utvikle prototypen i HTML5, siden vi har mer erfaring innen webutvikling med HTML5, CSS3 og JavaScript, enn hva vi har av erfaring med et CMS. Samtidig bidro det med at vi fikk gjennomført løsninger på en raskere og enklere måte enn hva vi hadde fått gjort i et CMS. Oppdragsgiver vil ha tilgang til kildekodene. Det gjør at hvis oppdragsgiver ønsker å benytte seg av et CMS, er det enklere å senere implementere prototypen i et CMS. Programkode som ligger til grunn for at funksjonalitet som kontaktskjema og innspill skal sende informasjon til nettstedets administrator(er) er ikke implementert i nettstedet, eller dekket av prosjektoppgaven. Videreutvikling av denne funksjonaliteten er relevant først når oppdragsgiver har bestemt om det skal benyttes et CMS, og eventuelt hvilket. Tekstlig innhold i tiltak har gruppen hentet fra kilder som Østfold Fylkeskommune og Vegvesenet for å vise hvordan informasjon kan bli presentert på nettstedet. Sammen med oppdragsgiver ble det enighet om at vi skulle lage en prototype for en nettløsning for Nedre Glomma prosjektet. Det tekstlige innholdet i prototypen var derfor ikke avgjørende for oppdragsgiver, og er derfor ikke lagt stor vekt på i prosjektet Formål Rapporten skal være et godt utgangspunkt for (videre)utviklingen av et nettsted for Bypakke nedre Glomma. Hovedmål: Å utforme en prototype av et nettsted som støtter opp under oppdragsgivers ønsker og også møter kravene om universell utforming og tilgjengelighet på ulike medier.

13 4 Kapittel 1. Introduksjon Delmål 1: Utviklet prototype av nettsted for Bypakke Nedre Glomma. Delmål 2: Gjøre prototypen tilgjengelig ved å oppfylle krav om uu. Delmål 3: Sørge for god tilgjengelighet på ulike medier Leveranser Ved avsluttet prosjekt skal det leveres en prototype av nettstedet for Bypakke Nedre Glomma. Det skal også leveres en prosjektrapport med mer detaljert informasjon rundt utviklingen av prototypen. Dato for leveranse er satt til Rapportstruktur Rapporten er delt inn i kapitler som tar for seg analyse, metode, resultater, utforming, diskusjon og konklusjon. Analysekapittelet vil blant annet ta for seg relevant teori knyttet til utvikling av et universelt utformet nettsted som skal være funksjonelt på ulike medier. Valg av metoder for gjennomføring av prosjektet er beskrevet i kapittel 3, Metode. Deretter presenteres resultatene av blant annet intervju og brukertest i kapittelet Resultater. I kapittel 5, Utforming, beskrives hvordan prototypen er utviklet. Videre vil prosjektgruppen, i kapittel 6 Diskusjon, drøfte resultater av undersøkelsene, og diskutere funn gjort underveis i prosjektperioden. Konklusjonen er et sammendrag av diskusjonen, hvor det legges vekt på prosjektoppgavens mål.

14 Kapittel 2 Analyse 2.1 Mål og visjon Østfold Fylkeskommune (ØFK) ønsker en nettbasert informasjonskanal der de kan informere om ferdige, pågående og planlagte tiltak for utbedring av samferdselsrelaterte saker i Nedre Glomma regionen. Oppgaven til prosjektgruppen vil i hovedsak være å lage en prototype av et nettsted for visning av tiltak i Nedre Glomma regionen. Prototypen skal utvikles med bakgrunn i informasjon som prosjektgruppen har tilegnet seg gjennom prosjektperioden. Målet med nettstedet er todelt. Det ene målet er å øke målgruppens kunnskap om hvilke tiltak som gjøres gjennom bypakken. Det andre målet er å bidra til en positiv holdning til alternativ transport hos målgruppen. Med alternativ transport menes reisemåter som reduserer personbiltrafikken i Nedre Glomma regionen. Alternativ transport er gjerne bruk av kollektivtransport, sykkel, gange og også samkjøring. Med et nettsted som skaper økt kunnskap og informasjon rundt tiltakene som gjøres i regionen, ønsker oppdragsgiver å nå målet om å bidra til en positiv holdning til alternativ transport. Prosjektgruppens fokus vil være å utvikle et nettsted som informerer målgruppen, oppdragsgiver vil selv stå for den motiverende faktoren Forretningsidé Det er inngått en samarbeidsavtale mellom Østfold fylkeskommune, Statens Vegvesen region Øst, Fredrikstad kommune og Sarpsborg kommune. Partene skal samarbeide om areal- og transportutvikling i region Nedre Glomma. Et av hovedmålene bak prosjektet er å bedre fremkommelighet, miljø og helse ved å dempe veksten i biltrafikken. På lengre sikt har samarbeidet et mål om nullvekst i biltrafikken, med 2013 som referanseår. Som en del av kommunikasjonsstrategien for samarbeidsavtalen, skal det opprettes et nettsted som skal fungere som en kommunikasjonskanal for bypakkeprosjektet. Nettstedet skal formidle prosjekter og tiltak som gjøres i Nedre Glomma regionen Målgruppe Nettstedets målgruppe er innbyggere i Nedre Glomma regionen. Særlig vil det være trafikanter og beboere i Nedre Glomma regionen, samt næringsliv med transportbehov, som har interesse for eller blir berørt av areal- og transportutvikling i Nedre Glomma regionen. Hovedoppgavene til brukerne av nettstedet vil være innhenting av informasjon rundt tiltak i Nedre Glomma regionen. Informasjonen vil hovedsakelig være tid og sted for pågående og kommende tiltak. De vil også få informasjon som skal påvirke brukeren til å tenke på reisealternativer til bil. 5

15 6 Kapittel 2. Analyse Kommunikasjon All offentlig informasjon skal være tilgjengelig for alle, samtidig ønsker ØFK å gi muligheten for en 2-veis kommunikasjon på nettstedet. Med dette menes tilbakemeldinger på publiserte tiltak på siden. Tilsvarende prosjekter andre steder i Norge har opplevd at bruk av sosiale medier har ført til at motstandere av prosjektene har spammet kommentarfeltene med useriøse henvendelser. Dette er noe ØFK ikke ønsker skal skje med deres løsning. Det finnes ulike måter å håndtere et slikt problem. En måte å løse dette på kan være å gå bort fra Facebook som kommunikasjonsløsning, og heller bruke et kontaktskjema på nettstedet. Et kontaktskjema kan lages slik at alle henvendelser først må godkjennes av nettstedets administrator, før de publiseres. Kort oppsummert vil nettstedet Bypakke Nedre Glomma oppfylle rollen som et kommunikasjons-bindeledd til målgruppen. 2.2 Informasjonsarkitektur og webdesign Informasjonsarkitektur legger grunnlaget for informasjonsorganisering, merkesystemer, navigasjonssystemer, søkesystemer og metadata for nettstedet Informasjonsorganisering Det er ingen fasit på hvordan en kommer frem til organiseringen av et nettsted. Det finnes flere måter dette kan gjennomføres på. En god informasjonsarkitektur burde gi brukerne mulighet til å velge denne organiseringen selv. Utfordringen ligger i hvordan brukeren tolker ord og elementer. Det en må ta høyde for er at det ikke er alltid brukeren og redaktøren for nettstedet har samme oppfatning av navn og kategorier Merkesystemer Merkesystemer er visualisering av organisasjonen og navigasjonen på et nettsted. Dette omfatter navnevalg, fargebruk og ikoner. Fargebruk og ikoner er forklart nærmere under kapittelet webdesign. Navnevalg er mer omfattende dekket under kapittelet merkesystemer Navigasjonssystemer Dette skal kunne gi svar til brukeren om hvor de befinner seg på nettstedet, hvor de har kommet fra og hvor de kan gå videre. I følge Morville og Rosenfield er breadcrumbs med på å fortelle brukeren om hvor på siden en befinner seg. Det er i tillegg med på å bringe brukerne tilbake til startsiden Søkesystem Det er vesentlig å definere om det søkes i hele databasen eller utvalgte områder, om søket skal være basert på fritekst eller indeksert. I følge Krug er alle sider avhengig av søkefunksjoner og han peker på at en må ha en løsning for de brukerne som ikke klarer å finne frem til det de leter etter. Figur 2.1 illustrerer rekkefølgen i en søkeprosess, fra brukeren taster inn et søk, til søkeresultatene vises. Illustrasjonen viser også sammenhengen mellom søk og metadata. En må ta hensyn til at brukeren ikke alltid vil kunne treffe på søket første gangen og behovet kan endre seg underveis som gjør at en endrer fremgangsmetoden for hvert søk. Det vil si at hvis en starter med et bredt søk, så burde søkeresultatene en får være spesifikt. [15]

16 2.2. Informasjonsarkitektur og webdesign 7 Figur 2.1: Søkeprosessen [15] Definisjon på et godt nettsted I følge Morville og Rosenfeld finnes det 8 faktorer som kjennetegner et godt nettsted. Disse 8 faktorene er: 1. Virkningsfullt. 2. Effektivt. 3. Sikkert å bruke. 4. God funksjonalitet. 5. Lett å lære. 6. Lett å huske. 7. Lett å finne frem. 8. Pent å se på. For å kunne dekke faktorene, vil det kreve en struktur med et grunnleggende rammeverk, et slikt rammeverk er ikke fast. Rammeverket vil være unikt for hver situasjon. Informasjonsarkitekturens tre kjente sirkler brukes for å oppnå et godt rammeverk for å kunne kartlegge hva en har behov for og hvorfor en skal ha det i rammeverket for det aktuelle nettstedet. [15] Figur 2.2: Informasjonsarkitekturens tre kjente sirkler [20]

17 8 Kapittel 2. Analyse Kontekst er forretningsmål, finansiering, politikk, kultur, teknologi og menneskelige ressurser. Innhold på nettstedet betyr hvilken type data som skal kunne være tilgjengelig. Brukere er de som skal benytte seg av nettstedet. Det kan være vesentlig å spørre seg om hvilke oppgaver, behov, søkeadferd, erfaringer, vokabular, alder og kultur brukeren har Webdesign Funksjonen til et webdesign er å være forklarende og til enhver tid illustrere hvor brukeren befinner seg på nettstedet. Webdesignet gjør det mulig å oppnå de 8 faktorene beskrevet av Rosenfield og Morville. En kan si at webdesignet setter ansikt på informasjonsarkitekturen, den gjør det presentabelt for leserne av nettstedet. Steve Krug skriver i sin bok Don t Make Me Think at et nettsted må være selvforklarende, og ikke bestå av omfattende instruksjoner om hvordan nettstedet virker. Dette kan føre til at flertallet av brukere vil heller prøve og feile helt til de gir opp og forlater siden i frustrasjon, enn å lese instruksjoner. Hovedgrunnen til at design er vesentlig på websider i dag er at webbrukere vil ha fakta med engang og ikke er nødt til å lese igjennom en stor mengde av tekst. Når en skal utvikle et webdesign er det viktig å huske på at enhver webbruker er unik, derfor finnes det ikke rett eller galt i et design. Steve Krug skriver at et det er et bra design hvis det oppfyller et behov, det er gjennomført og testet. Figur 2.3: Illustrasjon på førstegangsbrukere av et nettsted Figur 2.3 illustrerer hvordan en førstegangsbesøkende kan oppleve en nettside. Den viser trinn for trinn hva en førstegangsbesøkende gjør på et nettsted. Figur 2.4 illustrerer tab design slik Krug beskriver i sin bok. Han skriver at tabs i menyen gir en fysisk metafor som virker i et grensesnitt. Det er fire grunner til dette:

18 2.3. Brukere av nettstedet 9 Figur 2.4: Variasjoner av Tab-design De er selvforklarende. Det er ingen som undrer på hva en slik tab gjør. Det er vanskelig å ikke se de, mange brukere har en tendens til å ikke se knapper, men tabs ser de alltid og de er vanskelig å tolke som noe annet enn navigasjon. En webdesigner skal kunne få inn dette i et design uten problemer. De skaper en illusjon av et fysisk rom. Brukeren vil føle at det aktive taben alltid flyttes til forsiden og at man har kontroll. En tab navigasjonsbar fungerer best med et kontrastfylt område under taben, slik at man ser at det er en større fysisk kobling. 2.3 Brukere av nettstedet For å gi et bedre inntrykk av hvilke behov nettstedet dekker, har vi laget fiktive brukere som vi ser for oss vil kunne ha nytte av nettstedet. Brukerprofilene som vi har laget skal gjenspeile nettstedets målgruppe. Grunnlaget for de fiktive brukerne har vi hentet inn statistikk over befolkningen i nedre Glomma regionen. Det er gjort siden det vil gi grunnlaget for hvor stort hvert segment i målgruppen er i virkeligheten. Vi så derfor på alder som en vesentlig inndeling, siden vi tror brukermønster for bruk av nettet er noe forskjellig fra ulike aldersgrupper Tabellen under viser befolkningstall fra de ulike kommunene Fredrikstad, Hvaler og Sarpsborg slått sammen for å gi en oversikt over befolkningen i Nedre Glomma regionen som en enhet. Av tabellen ser vi at aldersgruppene og år er særlig godt representert og står tilsammen for omtrent 61% av befolkningen. Deretter er personer som er 67 år eller eldre den 3. største gruppen, og utgjør omtrent 15% av befolkningen. Det er viktig at brukerprofilene til en viss grad gjenspeiler aldersfordelingen i nedre Glomma regionen Demografi Folkemengden i Nedre Glomma regionen, fordelt på de tre kommunene Sarpsborg, Fredrikstad og Hvaler. Folkemengden er også aldersgruppert innenfor hver av kommunene. Dataene i tabell 2.1 er sist oppdatert [17]

19 10 Kapittel 2. Analyse Antall personer Sarpsborg år år år år år år eller eldre Fredrikstad år år år år år år eller eldre Hvaler år år år år år år eller eldre 760 Tabell 2.1: Aldersfordeling i Sarpsborg, Fredrikstad og Hvaler kommune

20 2.3. Brukere av nettstedet 11 Tabellen 2.2 viser data fra de ulike kommunene slått sammen for å beskrive befolkningen i Nedre Glomma regionen som en enhet. Nedre Glomma regionen Antall personer 0-5 år år år år år år eller eldre Tabell 2.2: Aldersfordeling i Nedre Glomma regionen Brukerprofiler Kåre er 39 år og bor i Sarpsborg. Han er opptatt av jobben sin som industriansatt på Borregård. Han føler at hans helse begynner å bli dårligere, det ønsker han å gjøre noe med. Guro er 53 år og bor i Ski. Hun arbeider i på kontor i Fredrikstad. Siden hun bor i Ski, er hun avhengig av å pendle til jobben med bil. Emil er 67 år og bor i Fredrikstad. Han ser meget dårlig som skyldes en arbeidsulykke og er nå pensjonist. Markus er 20 år og bor i Sarpsborg. Han har akkurat begynt å jobbe som lærling som vekter på Torvbyen Storsenter. Annette er 42 og bor 1.5 mil fra arbeidsplassen i Fredrikstad sentrum. Hun er interessert i sine reiseutgifter til og fra jobben Bruker-scenarioer Brukernes behov og bruk er ulike avhengig av hvilke personer innenfor målgruppen som bruker nettstedet. Brukerscenarioene viser brukerne i tenkte situasjoner og demonstrerer deres behov for nettstedet og dets funksjonalitet. Kåre: Det er ettermiddag etter arbeidet på Borregård for Kåre. På jobben fikk de ansatte beskjed om at de vil innføre et sykkeltiltak for å aktivere de ansatte i Nedre Glomma regionen. Kåre bor et stykke unna jobben og sykkelveien fra huset hans er ennå ikke ferdig. Når blir det ferdig undrer Kåre. Kåre tar frem nettbrettet sitt og går inn på nettstedet han har hørt om som viser prosjekter for Nedre Glomma regionen. Han finner området han bor i og ser at utbyggingen vil være ferdig om en måned. Så legger han fra seg nettbrettet og fortsetter dagens gjøremål. Guro: Det er tidlig morgen og Guro sitter i bilen på vei til jobben i Fredrikstad. Det er lang kø fra Borg Amfi. Det skyldes trafikkarbeidet som foregår litt lengre frem i køen hun sitter i. Når skal denne veien bli ferdig? Det er stillestående kø, så hun bestemmer seg for å ta opp mobiltelefonen og søke etter veiarbeid i Østfold. Det fører henne til nettstedet, som lister

21 12 Kapittel 2. Analyse opp alle veiprosjekter som pågår i nærheten av der hun befinner seg. Hun ser at et prosjekt er i nærheten av der hun befinner seg og trykker på markøren. Hun ser at det veiprosjektet er forventet fullført om 2 uker. Hun legger fra seg mobilen og den stillestående køen begynner å flytte på seg. Emil: Det er kveld og Emil sitter foran sin datamaskin og surfer på internett. Det synes han er en stor utfordring siden han har et svekket syn. Samtidig ønsker han å finne ut hvorfor de har startet opp å grave i veien utenfor huset sitt. Han får hjelp av sin kone å går inn på et nettsted for forteller om prosjekter i Nedre Glomma regionen. Her han mulighet til å tilpasse siden slik at han ser hva som står skrevet og mulighet til at en stemme leser opp for han hva som står. Han finner lett veiprosjekter siden og taster inn hvor han bor. Nå ser han klart og tydelig at det har startet et byggeprosjekt utenfor hjemmet hans og at det vil være ferdig og noen måneder. Markus: Arbeidsgiveren har tidligere den uken lest om nedre Glomma prosjektet på nettstedet, og fikk inspirasjon til å lage en konkurranse for å endre sine ansattes reisevaner. Markus har nettopp blitt informert på jobben at det skal være en konkurranse mellom Torvbyen Storsenter og Fredrikstad Storsenter om hvem som er best til å benytte seg av alternativ transport til og fra jobben. Markus vet at dette ikke er noe problem for han å gjennomføre da han har mindre enn 15 min gange til jobb. Dessuten har han hørt av flere kolleger at det er kommet en ny sykkelvei mellom boligområdet der han bor og Sarpsborg sentrum. For å motivere de ansatte til å la bilen stå hjemme har Markus sin arbeidsgiver lagt til rette for sykkelparkering under tak, de betaler halvparten av kostnader til busskort. Etter en måned leder Torvbyen konkurransen noe som motiverer de ansatte til å la bilen bli hjemme. Annette: Det er mandag morgen og Annette skal på jobb. Hun bor 1.5 mil unna jobben, så sykkel er uaktuelt. Det går heller ikke busser i utkanten der hun bor. Det har i det siste blitt innført parkeringsavgift utenfor arbeidsplassen hennes. I tillegg har det kommet to bomringer på veien til jobb, som det ikke er mulig å komme utenom. Hennes reiseutgifter tur/retur arbeidsplassen utgjør i dag 145,- kr. Dette har fått Annette til å vurdere andre alternativer, så denne mandagen går hun inn på østfoldløftet.no som hun har hørt om gjennom en kollega. Hun søker på Grålum hvor jobben ligger og finner ut at det åpnes en innfartsparkering om en uke like i nærheten av jobben hvor det er gratis å parkere, i tillegg går det buss mellom innfartsparkeringen og arbeidsplassen hennes. Annette gleder seg til neste mandag da denne åpner for dette sparer hun mye penger på. 2.4 Analyse av lignende nettsteder Det første prosjektgruppen gjorde var å se på eksisterende nettsteder fra lignende prosjekter i andre kommuner. Alle disse sidene har som mål og opplyse befolkningen, det samme målet har nettløsningen for Bypakke Nedre Glomma. Under dette kapittelet følger en kort gjennom gang av hva gruppen opplevde av struktur, design og innhold på de relevante sidene Bypakka.no Gruppen mener at nettstedet vi har evaluert er et godt og funksjonelt nettsted som innehar en ryddig informasjonsarkitektur. Målet med nettstedet er å gi informasjon om prosjekter som er relatert til kollektivtransport, gang/sykkelvei og bilvei i Grenlandsområdet. Prosjektgruppen henter støtte i

22 2.4. Analyse av lignende nettsteder 13 sin mening gjennom spørreundersøkelsen vi har foretatt ved at brukerne i testen fant store deler av informasjonen der de forventet å finne den. Hele analysen av nettstedet er lagt ved som vedlegg A. Figur 2.5: Skjermbilde av Bypakke.no Miljopakken.no Prosjektgruppen har sett på innhold og funksjonalitet på nettstedet miljopakken.no og synes at informasjonen er organisert på en måte som gjør det oversiktlig for brukeren samtidig som designet er tiltalende. Nettstedet presenterer miljøpakken og dets prosjekter. Prosjektgruppen likte særlig godt kartfunksjonen i visningen av prosjekter.

23 14 Kapittel 2. Analyse Figur 2.6: Skjermbilde av miljøpakken.no ATP-samarbeidet Prosjektgruppen så også tidlig på nettstedet atp-samarbeidet.no. Forsiden er inneholder alle nyhetssaker helt tilbake til 2008, noe som gjør forsiden svært lang. Prosjektgruppen synes designet er tradisjonelt og noe kjedelig. Menyen virker lite interessant og kalenderen, som også ligger på forsiden, fungerer dårlig. Figur 2.7: Skjermbilde av apt-samarbeidet.no Hopp over bommen Prosjektgruppen fant nettstedet hoppoverbommen.no som vi syntes virket friskt og moderne. Hoppoverbommen.no er en kampanjeside drevet av blant annet atp-samarbeidet. Designet er moderne

24 2.5. Universell utforming 15 ved at det er spreke farger og flat design. Forsiden inneholder stort sett en beskrivelse av kampanjen, samt en meny. Prosjektgruppen mener designet på menyen ser bra ut, men menyelementene, som bare er ikoner, sier lite om hvor og hva de linker til og vi er nødt til å klikke oss videre for å forstå hva som menes med menyikonene. De underliggende sidene inneholder, i likhet med forsiden, svært lite informasjon. Figur 2.8: Skjermbilde av hoppoverbommen.no 2.5 Universell utforming Begrepet universal design har sin opprinnelse fra The Center for Universal Design ved North Carolina State University på slutten av 1980-tallet [19]. Universell utforming ble opprinnelig brukt innenfor arkitektur og planlegging som en beskrivelse av tilgjengeliggjøring av utearealer, tilgang til byggninger og skilting [6]. I Norge var det Statens råd for funksjonshemmede som i 1997 introduserte begrepet universell utforming brgjennom publikasjonen Universell utforming - planlegging og design for alle [19]. Siden den gang har begrepet fått stor utbredelse blitt brukt i flere politiske dokumenter, regelverk og retningslinjer(universell Utforming dokument). Universell utforming er et begrep som brukes om utvikling av produkter og tjenester som er tilrettelagt på en måte som gjør det tilgjengelige for så mange mennesker som mulig. Mange produkter og tjenester er utviklet på en måte som gjør de utilgjengelige for enkelte individer. Personer med funksjonshemninger må ofte benytte tilrettelagt teknologi og tilleggsløsninger for å kunne benytte seg av tjenester. Med et universellt utformet produkt vil det ikke være behov for kompenserende tilleggsløsninger for at alle skal kunne bruke det, det er én løsning, som fungerer for alle.

25 16 Kapittel 2. Analyse Definisjoner Det finnes flere definisjoner av hva begrepet universell utforming betyr. Klima- og miljødepartementet bruker en definisjon av universell utforming som er direkte oversatt fra The Center for Universal Design ved North Carolina State University sin opprinnelige definisjon: Universell utforming er utforming av produkter og omgivelser på en slik måte at de kan brukes av alle mennesker, i så stor utstrekning som mulig, uten behov for tilpassing og en spesiell utforming[13]. Universell utforming er også definert gjennom FN-konvensjonen om rettighetene til mennesker med nedsatt funksjonsevne: Med universell utforming menes utforming av produkter, omgivelser, programmer og tjenester på en slik måte at de kan brukes av alle mennesker, i så stor utstrekning som mulig, uten behov for tilpassing og en spesiell utforming. Universell utforming skal ikke utelukke hjelpemidler for bestemte grupper av mennesker med nedsatt funksjonsevne når det er behov for det[2]. Diskriminerings- og tilgjengelighetsloven (DTL) har som formål å fremme likestilling uavhengig av funksjonsevne. Loven definerer universell utforming slik: Med universell utforming menes utforming eller tilrettelegging av hovedløsningen i de fysiske forholdene, inkludert informasjons- og kommunikasjonsteknologi (IKT), slik at virksomhetens alminnelige funksjon kan benyttes av flest mulig[1] De syv prinsipper Felles for definisjonene av universell utforming er at de bygger på syv grunnleggende prinsipper som opprinnelig var beregnet på utforming av bygninger og arealplanlegging. Prinsippene ble utarbeidet av The Center for Universal Design ved North Carolina State University. 1. Like muligheter for bruk: Utformingen skal være brukbar og tilgjengelig for personer med ulike ferdigheter. 2. Fleksibel i bruk: Utformingen skal tjene et vidt spekter av individuelle preferanser og ferdigheter. 3. Enkel og intuitiv i bruk: Utformingen skal være lett å forstå uten hensyn til brukerens erfaring, kunnskap, språkferdigheter eller konentrasjonsnivå. 4. Forståelig informasjon: Utformingen skal kommunisere nødvendig informasjon til brukeren på en effektiv måte, uavhengig av forhold knyttet til omgivelsene eller brukerens sensoriske ferdigheter. 5. Toleranse for feil: Utformingen skal minimalisere farer og skader som kan gi ugunstige konsekvenser, eller minimalisere utilsiktede handlinger. 6. Lav fysisk anstrengelse: Utformingen skal kunne brukes effektivt og bekvemt med et minimum av besvær.

26 2.5. Universell utforming 17 [19] 7. Størrelse og plass for tilgang til bruk: Hensiktsmessig størrelse og plass skal muliggjøre tilgang, rekkevidde, betjening og bruk, uavhengig av brukerens kroppsstørrelse, kroppsstilling eller mobilitet Regelverket Forskriften for universell utforming av IKT har gjeldt fra 1. juli Selve kravene til universell utforming av nye IKT-løsninger gjelder ett år etter at forskriften har tråd i kraft, fra 1. juli Difi viser til at selve målet med denne forskriften er at utforming av IKT-løsninger slik at den er tilgjenglig for alle, uavhengig av funskjonsevne. IKT- løsninger som er kjøpt eller bestilt etter 1. juli 2014 skal være universelt utformet fra lansering. Avtaler som blir inngått før 1. juli 2014 er det ikke lovpålagte om universell utforming. Unntak Forskriften gjelder ikke der utformingen reguleres av en annen lovgivning, et eksempel som difi trekker frem er løsninger innenfor bygg- og undervisningssektoren. I tillegg for unntak av automater, forskriften vil ikke gjelde for samferdselssektoren. Løsninger som ikke blir omfattet av forskriften er: Sosiale mediaer som blogger, Facebook og Twitter brukt i privat sammenheng. Tilpasning eller tilrettelegging av IKT-løsninger for enkeltpersoner IKT i skoler og utdanningsinstitusjoner TV-medier, inklusive film og nett-tv Forskriften gjelder ikke på Svaldbard og Jan Mayen, det er på grunn av at disse stedene ikke regnes som et livsløpssamfunn. Forskriftene gjelder heller ikke på installasjoner og fartøy i virksomhet på norsk kontinentalsokkel eller på norske skip og luftfartøyer uansett hvor de befinner seg. Dispensasjon Virksomheter kan få dispensasjon fra tidsfristene, men dette gis bare hvis det er tungtveiende grunner. DIFI viser til følgende Person Sikkerhet At utviklingsforløpet for en anskaffelse ikke lar seg tilpasse tidsfristene i forskriften Dersom tidsfristene påfører en virksomhet urimelige kostnader Dispensasjonsbestemmelsen skal praktiseres slik at hensynet til lovens formål om ikke- diskriminering veier tungt, og slik at praktiseringen ikke fører til konkurransevridning.

27 18 Kapittel 2. Analyse Offentlige krav til nettløsninger fra DIFI Offentlige nettløsninger skal følge kravene i Retningslinjer for tilgjengelig webinnhold (WCAG) på nivå AA, med visse unntak. WCAG 2.0 står for Web Content Accessibility Guidelines, den norske oversettelsen var godkjent i 2011 og ble formelt godkjent som internasjonal standard i oktober Forskrift om universell utforming av IKT-løsninger stiller krav om at nettsider må oppfylle 35 av i alt 61 suksesskriterier i WCAG 2.0. Den forklarer hvordan innhold på nettsider kan gjøre mer tilgjengelige for personer med nedsatt funksjonsevne. Slikt innhold omfatter blant annet tekst, bilder, lydklipp, video og hvordan nettsiden er kodet. WCAG standarden er teknisk og er rettet mot designere, utviklere og andre med erfaring innen webutvikling. WCAG 2.0 er bygd opp av fire hovedprinsipper, som støtter opp under av 12 retningslinjer og 61 testbare suksesskriterier. Alle suksesskriteriene er tildelt etter nivå A, AA og AAA. A viser til det laveste nivået for tilgjengelighet og AAA er det høyeste nivået. De samme kravene kan finnes i suksesskriterier på ulike nivåer. Noen forutsetninger må være overholdt for å oppfylle WCAG. For å oppnå ett nivå må alle kravene være oppfylt på ett nivå. Det vil si for å oppfylle kravene på nivå AA må både kravene på nivå A og AA oppfylles. Et annet krav er at alt av innholdet på nettstedet oppfylle kravene. I tillegg skal nettsider som inneholder i en prosess, eksempel en nettbutikk, disse sidene må oppfylle kravene. Nedenfor er det listet opp prinsippene og retningslinjer for å oppnå kravene.[5] Prinsipp 1: Mulig å oppfatte Innholdet på siden og brukergrensesnittkomponenter må presenteres på en slik måte at alle brukere kan oppfatte hva som vises. Det vil si at informasjonen ikke kun lar seg bruke ved hjelp av en enkelt sans. For å kunne se grafikk trengs for eksempel en skjerm og menneskets synssans. WCAG krever dermed at bilder skal inneholde en alternativ tekst. Dette kan løses på flere måter, blant annet som punktskrift, leses opp med syntetisk tale, tolkes som tegnspråk og vises som symboler. WCAG krever derfor at tekst skal brukes som alternativ til andre medier som lyd, film og bilder. Prinsipp 2: Mulig å betjene. Det skal være mulig å betjene brukergrensesnittkomponenter og navigeringsfunksjoner. Det essensielt at brukere kan navigere, velge knapper, sette haker i avkryssingsfelt osv. med det utstyret de benytter. Noe som tilsier at det ikke kun skal være mulig å bruke mus, men også bruke tastaturet og trykk-skjerm osv. Prinsipp 3: Forståelig Det må være mulig å forstå informasjon og betjening av brukergrensesnitt. Dette prinsippet handler om forutsigbarhet, enkelt språk, god hjelpefunksjonalitet. Noen retningslinjer og suksesskriterier som knyttes til dette prinsippet handler også om riktig koding, det kan være at sidespråket er oppgitt slik at teksten blir lest opp på rett måte for dem som bruker talesyntese. Prinsipp 4: Robust Innholdet må være robust nok til at det kan tolkes på en pålitelig måte av brukeragenter, inkludert kompenserende teknologi. Dette prinsippet omhandler koding, og at tilgjengelighet må ivaretas

28 2.6. WCAG 2.0 gjeldende krav 19 når man introduserer ny teknologi. Det vil si i praksis at nettsider valideres og at koden er riktig. Dette er som regel i ved bruk av standardelementer i HTML. Det skal legges merke til at WCAG 2.0 ikke løser alle problemer, men er et godt verktøy for å lage nettsider som er tilgjengelige og brukervennlige for personer med nedsatt funksjonsevne, men bruk av den garanterer ikke universell utforming. 2.6 WCAG 2.0 gjeldende krav Forskrift om universell utforming av IKT-løsninger stiller krav om at nettsider må minst oppfylle 35 av 61 suksesskriterier i WCAG 2.0. Disse 35 kravene er nesten alle kriteriene på nivå A og AA i WCAG Liste over krav i WCAG Ikke tekstlig innhold Alt ikke tekstlig innhold som presenteres for brukeren, har et testalternativ som har samme formål, med unntak av noen situasjoner. Disse situasjonene er: Kontrollelementer, inndata: Hvis det ikke tekstlige innholdet er et kontrollelement eller hvor det godtar inndata fra brukere, har det et navn som beskriver formålet. Tidsbaserte medier: Hvis det ikke tekstlige innholdet er tidsbaserte medier, må tekstalternativene som et minste krav gi en beskrivende identifikasjon av det ikke tekstlige innholdet. Test: Hvis det ikke tekstlige innholdet er en test eller øvelse som ikke ville gitt mening hvis den ble presentert med tekst, må tekstalternative som et minimum gi en beskrivende identifikasjon av det ikke tekstlige innholdet. Sanseopplevelse: Hvis formålet med det ikke tekstlige innholdet først og fremst er å skape en spesifikk sanseopplevelse, må tekstalternativene som et minstekrav gir en beskrivende identifikasjon av det ikke tekstlige innholdet. CAPTCHA: Hvis formålet med det ikke tekstlige innholdet er å bekrefte at innholdet brukes av en person, og ikke av en datamaskin, skal det gis tekstalternativer som identifiserer og beskriver hensikten med det ikke tekstlige innholdet. Det skal dessuten legges til rette for ulike typer funksjonsnedsettelser ved at det finnes alternative former for CAPTCHA som bruker utdataformater beregnet på ulike typer sensorisk persepsjon. Dekorasjon, formatering, usynlig: Hvis det ikke tekstlige innholdet er ren dekorasjon, hvis det utelukkende brukes til visuell formatering, eller hvis det ikke presenteres for brukeren skal det implementeres på en slik måte at det kan ignoreres av kompenserende teknologi. [4] 2. Bare lyd og bare video For forhåndinnspilt innhold som bare er lyd eller video gis det tilgang til alternativer, bortsett fra når lyden eller videoen utgjør et medie-alternativ til tekst og er tydelig merket som det. 3. Teksting Det gis tilgang til teksting for alt forhåndinnspilt lydinnhold i synkroniserte medier, bortsett fra når mediene fungerer som medie-alternativer til tekst og er tydelig merket som det. 4. Informasjon og relasjoner Informasjon, struktur og relasjoner som formidles via presentasjonen, kan bestemmes programmeringsmessig eller gjøres tilgjengelig som tekst.

29 20 Kapittel 2. Analyse 5. Meningsfylt rekkefølge Når rekkefølgen som innholdet presenteres i påvirker meningsinnholdet, kan en korrekt leserekkefølge bestemmes programmeringsmessig. 6. Sensoriske egenskaper Instruksjoner som gjelder forståelse og betjening av innhold, er ikke utelukkende avhengige av komponentenes sensoriske egenskaper, for eksempel form, størrelse, visuell plassering, orientering eller lyd. 7. Bruk av farge. Farge blir ikke benyttet som det eneste visuelle virkemiddelet for å formidle informasjon, angi en handling, be om respons eller skille ut et visuelt element. 8. Styring av lyd Hvis lyd på en webside spilles av automatisk i mer enn 3 sekunder, finnes det enten en mekanisme for å stoppe lyden helt eller midlertidig, eller mekanisme som kan regulere lydstyrken uavhengig av det generelle systemvolumet. 9. Kontrast Den visuelle presentasjonen av tekst og bilder av tekst har et kontrastforhold på minst 4.5:1, Unntatt i noen tilfeller som Stor tekst: Stor skriftstørrelse og bilder av stor skriftstørrelse har et kontrastforhold på 3:1. Uvesentlig: Tekst eller bilder av tekst som utgjør en del av en inaktiv brukergrensesnittkomponent, som er ren dekorasjon, som ikke er synlige for noen, eller som utgjør en del av et bilde som inneholder annet vesentlig visuelt innhold, er ikke underlagt kontrastkrav. Logoer: Tekst som utgjør en del av en logo eller et varemerkenavn, er ikke underlagt kontrastkrav. 10. Endring av tekststørrelse Med unntak av teksting og bilder av tekst kan tekst forstørres opp til Bilder av tekst Hvis teknologien som brukes kan håndtere den visuelle presentasjonen, brukes det tekst i stedet for bilder av tekst for å formidle informasjon unntatt i 2 tilfeller. Kan tilpasses: Bildet av teksten kan visuelt tilpasses til brukerens krav. Nødvendig: En bestemt presentasjon av tekst er nødvendig for informasjon som formidles, 12. Tastatur All funksjonalitet i innholdet kan betjenes via et tastaturgrensesnitt uten at det er behov for tidsberegning av de enkelte tastetrykkene, unntatt hvis den underliggende funksjonen krever inndata som er avhengige av rekkefølgen på brukernes bevegelser, og ikke bare av sluttpunktene. 13. Ingen tastaturfelle Hvis tastaturfokus kan flyttes til en av komponentene på siden ved hjelp av et tastaturgrensesnitt. Hvis det er behov for noe annet enn standard pil- eller tabulatortaster eller andre standardmetoder for navigering, får brukeren informasjon om hvilken metode som må benyttes for å flytte fokus. 14. Justerbar hastighet For hver tidsbegrensning som er angitt av innholdet, gjelder minst ett av følgende punkter: Man kan slå av, justerer eller forlenge begrensingen, eller begrensingen er en nødvendig del i sann tid, en forlengelse skulle gjøre handlingen ugyldig eller tidsbegrensingen varer lengre enn 20 timer. 15. Pause, stopp, skjul. For bevegelse, blinking, rulling eller automatisk oppdatering av informasjon finnes det en mekanisme som brukeren kan benytte til å sette den på pause, stoppe eller skjule den.

30 2.6. WCAG 2.0 gjeldende krav Terskelverdi på maksimalt tre glimt. Websider har ikke innhold som glimter mer enn tre ganger i løpet av ett sekund, eller glimt er innenfor terskelverdien for generelle glimt og røde glimt. 17. Hoppe over blokker Det finnes en mekanisme for å omgå blokker med innhold som gjentas på flere websider. 18. Sidetitler Websider har titler som beskriver den aktuelle sidens emne eller formål. 19. Fokusrekkefølge Hvis en webside kan navigeres sekvensielt og navigeringssekvensen påvirker betydning eller betjening, får fokuserbare komponenter fokus i en rekkefølge som ivaretar betydningen og betjeningen. 20. Formål med lenke (i kontekst) Formålet med hver lenke kan fastslås ut fra bare selve lenken eller ut fra lenketeskten kombinert med programmeringsmessig bestemt lenkekontekst. Unntaket er hvis formålet med lenken ville vært flertydig for alle brukerne. 21. Flere måter å finne frem Det finnes mer enn én måte å finne frem til en webside på innenfor et sett av websider. Unntaket er hvis websiden utgjør resultatet av, eller et trinn i, enn prosess. 22. Overskrifter og ledetekster Overskrifter og ledetekster beskriver emne eller formål. 23. Synlig fokus Tastaturbetjente brukergrensesnitt har en betjeningsmodus der fokusindikatoren for tastaturet er synlig. 24. Språk på siden Standard naturlig språk på hver webside kan bestemmes programmeringsmessig. 25. Språk på deler av innhold Naturlig språk i de enkelte avsnittene eller setningene som innholdet består av, kan bestemmes programmeringsmessig. Unntaket er egennavn, tekniske termer, ord av ubestemmelige språklig opphav samt ord eller uttrykk som har blitt en del av språket i den omkringliggende teksten. 26. Fokus Når en komponent kommer i fokus, medfører det kontekstendring. 27. Inndata Endring av innstillingene til en brukergrensesnittkomponent medfører ikke automatisk kontekstendring med mindre brukeren er blitt varslet om det før bruk av komponenten. 28. Konsekventnavigering Navigeringsmekanismer som gjentas på flere websider innenfor et sett av websider, opptrer i samme relative rekkefølge hver gang de gjentas, med mindre brukeren selv foretar en endring. 29. Konsekventidentifikason Komponenter som har samme funksjonalitet innenfor en samling av websider identifiseres på en konsekvent måte. 30. Identifikasjon av feil Hvis en inndatafeil oppdages automatisk, identifiseres elementet som feilen berører og brukeren får en tekstbeskrivelse av feilen. 31. Ledetekster eller instruksjoner Det vises ledetekster eller instruksjoner når innholdet krever inndata fra brukeren. 32. Forslag ved feil Hvis en inndatafeil oppdages automatisk og det finnes forslag til hvordan den kan rettes presenteres forslagene for brukeren, med mindre dette innebærer risiko for sikkerheten eller formålet med innholdet.

31 22 Kapittel 2. Analyse 33. Forhindring av feil (juridiske feil, økonomiske feil, datafeil) For websider som medfører juridiske forpliktelser eller krever økonomiske transaksjoner fra brukeren, som endrer eller sletter brukerstyrte data i datalagringssystemer, eller som sender svar på tester utført av brukeren, gjelder minst et av følgende punkter: reverserbarhet, kontroll og bekreftelse. (a) Reverserbarhet: Senderprosesser kan reverseres. (b) Kontroll: Det kontrolleres om data som angis av brukeren, inneholder inndatafeil, og brukeren gis mulighet til å rette opp eventuelle feil (c) Bekreftelse: Det finnes en mekanisme for gjennomgang, bekreftelse og oppretting av informasjon før den sendes. 34. Parsing (Oppdeling) I innhold som implementeres ved hjelp av oppmerkingspråk, har elementene fullstendige start- og sluttkoder, elementene er nøstet i henhold til spesifikasjonene, elementene inneholder ikke dupliserte attributter, og eventuelle ID-er er unike. Unntaket er hvis spesifikasjonene tillater disse funksjonene. 35. Navn, rolle og verdi For alle brukergrensesnittkomponenter (skjemaelemetner, lenker og komponenter som genereres ved hjelp av skript), kan navn og rolle bestemmes programmeringsmessig. Tilstander, egenskaper og verdier som kan angis av brukeren, kan angis programmeringsmessig, og informasjon om endringer i disse elementene er tilgjengelig for brukeragenter, inkludert kompenserende teknologi. 2.7 Accessible Rich Internet Applications (WAI-ARIA) Web Accessibility Initiative - Accessible Rich Internet Applications, WAI-ARIA, definerer en måte å gjøre webinnhold og webapplikasjoner tilgjengelige for personer med funksjonsneddsettelser. Når hjelpemiddelteknologi brukes mot webapplikasjoner, fungerer WAI-ARIA som en optimalisering av integreringen mellom hjelpemiddelteknologi og webgrensesnitt. Standarden er beregnet på dynamisk innhold og avanserte brukerkontoller utviklet i Ajax, HTML, JavaScript og andre teknologier. Innhold og funksjonalitet på nettsteder er ikke alltid tilgjengelig for personer med funksjonsnedsettelser, særlig de som er avhengige av skjermlesere eller som ikke kan bruke mus. WAI-ARIA er en standard for utviklere, slik at de kan lage avanserte webløsninger, samtidig som at løsningene er tilgjengelige for personer med funksjonsnedsettelser. [9] WAI-ARIA løser utfordringer rundt tilgjengelighet av: Dynamiske oppdateringer Dokumentstruktur Egendefinerte kontroller Tastaturstøtte Dynamiske oppdateringer Ved bruk av skjermlesere kan dynamiske oppdateringer ofte skape problemer for brukeren. Skjermlesere og skjermforstørrere viser ofte kun et utsnitt av innholdet, og dersom innholdet automatisk oppdateres et annet sted, utenfor utsnittet, kan det være vanskelig for brukeren å få det med seg. Et eksempel kan være at dersom brukeren snakker med noen i et chatvindu gjennom en skjermleser.

32 2.7. Accessible Rich Internet Applications (WAI-ARIA) 23 En venn logger seg på tjenesten, uten at brukeren får beskjed om dette. Denne problematikken kan løses ved bruk av live-regioner. Når Live-regioner funksjonaliteten brukes, kan hjelpemidler som skjermlesere få med seg viktige oppdateringer som skjer utenfor området brukeren ser, i det tempoet brukeren selv ønsker. Live-regionene har ulike innstillinger som forteller hjelpemiddelet hvor viktig de dynamiske oppdateringene er og hvordan brukeren skal oppdateres. Live-regionene kan ha tre forskjellige nivåer, off, polite og assertive. Off deaktiverer Live-regioner, mens assertive aktiveres idet nytt innhold dukker opp. Polite er høffligere ved at den bare aktiveres dersom ikke noe annet leses opp. Under følger tt kodeeksempel på bruk av live-regioner i en brukerliste til en chat: <div id="brukerliste" aria-live="off" > Her er aria-live satt til off, og skjermleseren vil derfor ikke lese opp eventuelle oppdateringer i brukerlisten. Det kan være nyttig å bruke off der hvor oppdateringer ikke er viktige, eller i situasjoner der det ville blitt irriterende på grunn av hyppige oppdateringer. Sammen med live-regioner, kan man bruke aria-atomic. Aria-atomic fungerer sammen med live-regioner og bestemmer hvorvidt hele live-regionen skal leses opp, eller kun det innholdet som oppdaterer seg innenfor live-regionen. Aria-atomic kan settes lik true eller false. Verdien true bidrar til at hele live-regionen blir opplest ved en oppdatering, mens false gjør at det kun er den nye oppdateringen som blir lest opp.[22] Dokumentstruktur I HTML5 brukes ulike tagger for å definere elementer som for eksempel heading, meny og bunntekst på en nettside, i tidligere versjoner manglet slik funksjonalitet. WAI-ARA har definert landemerker (landmarks) som skal gjøre det lettere for brukere av skjermlesere å manøvrere seg på nettsiden. Bruk av landemerker sørger for et tydelig skille mellom de ulike elementene på nettsiden og gjør det lettere for brukere av skjermlesere å navigere raskt, og med få tastetrykk hoppe over elementer etter behov. Et HTML dokument kan deles inn i flere logiske ARIA-roller, under er noen av de viktigste beskrevet. Banner er en region som hovedsaklig inneholder generell informasjon for hele nettstedet fremfor innhold spesifikt for hver enkelt nettside. Dette er informasjon som vanligvis ikke endrer seg, og er lik på hele nettstedet. Den generelle informasjonen kan være en logo eller identiteten til nettstedets eier(e) og eventuelt et søkeverktøy for nettstedet. Banneret er vanligvis plassert øverst på siden, og strekker seg over hele sidens bredde. Main markerer hovedinnholdet på en nettside. Det er innhold som er direkte relatert til hovedtemaet for nettsiden. Det kan for eksempel være en artikkel man har klikket seg inn på i en nettavis. Det bør kun være én region markert som main for hver nettside. Navigation regionen brukes til navigasjonselementer. Navigation inneholder gjerne en meny med linker. Search er en region som brukes for å markere søkefelt på nettsiden. Form markerer et område hvor det finnes felter med mulighet for bruker-input eller det er editerbare verdier som kan sendes videre til en server for bearbeiding. Et skjema for registrering eller inlogging er eksempler på bruksområder for landemerket form.

33 24 Kapittel 2. Analyse Complementary brukes for områder som er relatert til hovedinnholdet på nettsiden. Landemerket kan brukes på informasjonsbokser som viser relaterte saker eller lignende. [3] Noen av elementene i HTML5 overlapper med landemerkene i WAI-ARIA, ved at de begge beskriver noenlunde samme funksjon. Et eksempel er navigasjon som i HTML5 beskrives med en nav tag, men som i WAI-ARIA kan merkes med navigation. Foreløpig støtter ikke alle nettlesere og skjermlesere all funksjonalitet i HTML5. Det kan derfor være lurt å bruke både landemerker og HTML5 for å strukturere nettsider. Under følger eksempler på bruk av HTML5 og landemerker for å definere navigasjon på en nettside: [14] HTML5: <nav>...</nav> WAI-ARIA: <div role="navigation">...</div> HTML5 og WAI-ARIA: <nav role="navigation">...</nav> Egendefinerte kontroller På nettsteder brukes det ofte egendefinerte kontroller som er lite tilgjengelige for de som bruker skjermlesere eller er avhengige av tastatur. Ved bruk av WAI-ARIA attributter kan slike kontroller bli tilgjengelige. Koden til en knapp kan se slik ut: <p>knapp uten WAI-ARIA merking:<br /> <span style="background-color: #ddd; border: medium outset white;" onclick="alert( Du aktiverte knappen med mus! );"> En knapp </span> </p> Denne knappen aktiveres ved museklikk, men vil ikke kunne nås med tastaturet. For at knappen skal kunne nås med tastatur kan følgende kode benyttes: <p>knapp uten WAI-ARIA merking:<br /> <span style="background-color: #ddd; border: medium outset white;" role="button" tabindex="0" onkeydown="if(event.keycode==13 event.keycode==32) alert( Du aktiverte knappen med tastatur! );" onclick="alert( Du aktiverte knappen med mus! );"> En knapp </span> </p>

34 2.8. Visuelle tilpasninger 25 Her brukes role= button for å markere at det er en knapp. Tabindex satt til 0 gjør at knappen kan nås med tastaturet. Dersom brukeren trykker på enter eller mellomromstasten aktiveres knappen. [19] Tastaturstøtte På nettsider kan man bruke tab for å flytte fokus rundt på nettsiden, uten bruk av mus. Problemet er at det kun er linker og standardkontroller (som søkefelt) som får fokus. Med WAI-ARIA kan en legge til tabindex på elementer for at de skal få fokus. Tabindex som er satt lik 0 får fokus basert på plasseringen i HTML dokumentet. Tabindex større enn 0 får fokus basert på nummeret, mens tabindex satt til mindre enn 0 får ikke fokus. 2.8 Visuelle tilpasninger Når det snakkes om universell utforming er det ofte stort fokus på å tilrettelegge for blinde. Det er viktig å ikke glemme at det visuelle er betydningsfullt for de fleste, inkludert de svaksynte. Enkle visuelle tilpasninger kan bedre brukeropplevelsen av nettstedet Tekst Mange nettsteder preseneterer informasjon i form av tekst. Det er ofte tekst i menyelementer, knapper, overskrifter og artikler. Bevisste vag knyttet til tekst er derfor viktig for brukeropplevelsen av nettstedet. Det er viktig å ta hensyn til tekststørrelse når en utvikler et nettsted. For at teksten skal være universelt utformet, må teksten være stor nok. Størrelse på tekst er ikke like lett å presisere på en skjerm, som på papir. På papir kan tekststørrelsen måles, mens tekstsørrelsen på en skjerm avhenger av en rekke faktorer som utvikleren ikke har kontroll over. Størrelsen på teksten som vises på en skjerm avhenger blant annet av innstillinger i nettleser og perativsystem, skjermens oppløsning og størrelse. En absolut størrelse for universellt utformet tekst på nett er derfor vanskelig, det er viktigere å la brukeren selv bestemme. Brukeren kan selv bestemme størrelsen ved å zoome ut eller inn på teksten. Da er det viktig at teksten plasserer seg godt, selv når brukeren har zoomet inn på nettstedet. Dersom brukeren zommer inn på nettstedet for å få større tekst, bør bredden av nettstedet tilpasses slik at brukeren slipper sidescrolling. Dette løses med responsivt design, som er beskrevet under kapittel Kapittel beskriver krav om tekststørrelse. [19] Det er ikke en bestemt font som er foretrukket for universell utforming av et nettsted, men det er viktig at fonten er lesbar. Skrifttyper deles hovedsaklig inn i to kategorier, skrifttyper med seriffer og skrifttyper uten seriffer. Fonter dekorert med små fnutter på bokstavene er såkalte serif fonter, mens fonter uten denne dekorasjonen kalles sans-serif. Serif brukes nesten utelukkende i bøker, mens den på skjerm kan fremstå uklar og hakkete ved lav skjermoppløsning. Sans-serif fremstår som renere og enklere og kan være lettere å lese på skjerm, dersom oppløsningen er lav. [19] Kontrast For å skille ulike elementer på et nettsted, er kontrast et viktig virkemiddel. Det er kontrasten som gjør det mulig å se forskjell på tekst og bakgrunn. Det finnes tre typer kontraster, disse er: Fargekontrast

35 26 Kapittel 2. Analyse Metningskontrast Lyshetskontrast En fargekontrast oppnås ved å bruke to forskjellige farger, som for eksempel rød og grønn, mens mettet blå og umettet blå utgjør en metningskontrast. Lyshetskontrast er to farger med ulik lyshet, det kan for eksempel være lyserødt og mørkerødt. Alle kontrasttypene kan kombineres ved å for eksempel bruke en lys signalrød farge mot grumsemørk grønn. En kombinasjon av flere kontrasttyper kan være lurt, ettersom enkelte brukere har nedsatt fargesyn, og eldre er mindre sensitive for lys. Det er verdt å nevne at 7,5% av alle menn og kvinner har en eller annen form for fargeblindhet [6]. Krav til kontrast er beskrevet i kapitel Kulturelle tilpasninger Når man utvikler en løsning som skal være universellt utformet, er det ofte fokus på brukervennlighet for personer med ulike varianter av funksjonsnedsettelser. Det er også en av de viktigste elementene ved universell utforming. Samtidig er det viktig å ikke glemme at om løsningen skal passe for flest mulig må man huske at det er personer som møter på utfordringer som ikke har bakgrunn i funksjonsnedsettelser. En stadig mer globalisert verden byr på utfordringer rundt det med å ta hensyn til andres kulturelle bakgrunn. Behovet for å forstå andre kulturer er viktig, også innenfor utviklingen av nettsteder Språk Det finnes mange kulturforskjeller, hvorav språk er et element det er viktig å ta hensyn til for å nå ut til flest mulig. Selv om verden stadig blir mer globalisert og engelskkunnskaper eksisterer over store deler av verden, er språk fremdeles et hinder for kommunikasjon i ulike sammenhenger. Flere nettsteder tilpasser seg brukerens språk automatisk. Nettstedet kan ved å hente informasjon fra innstillinger hos brukerens nettleser, tilpasse språk som er foretrukket av brukeren. Nettstedet kan også bruke IP-adressen til brukeren finne ut hvor i verden forespørselen kommer fra, for så å tilpasse innhold til egnet språk. Denne tilnærmingen kan by på problemer da brukeren surfer på internett utenlands, og nettstedet blir presentert på et språk som baserer seg på brukerens lokasjon. Eventuelt kan det være at brukeren ikke ønsker at innhold skal oversettes til nettleserens språkinnstillinger. Et alternativ kan være å la brukeren bestemme språket manuelt. Ved bruk av flagg som ikon for språkvalg, hvor hvert flagg representerer ulike språk. Sitt eget flagg er lett gjenkjennbart selv om man ikke kan lese teksten. Bruk av flagg kan være problematisk fordi i et land kan det snakkes flere ulike språk, samtidig kan ett språk snakkes i flere ulike land. Eventuelt kan språkvalg være listet opp som tekst og skrevet på det aktuelle språkets språk.. Brukeren kan da ignorerer språkvalgene som den ikke forstår og enkelt finne sitt eget. Når tekst skal oversettes er det flere faktorer som er avgjørende for at resultatet bli godt. Ofte skaper tvetydige ord problemer ved oversetting. Et tvetydig ord kan for eksempel være meny. Et automatisk oversettingsprogram har ikke kunnskap om tekstens kontekst, og vet derfor ikke om det er i sammenheng med mat eller et begrep innenfor brukergrensesnitt. Oversettelsen kan da blir feil ettersom begrepet meny brukes ulikt fra språk til språk. Det er viktig at teksten som skal oversettes er klar, tydelig og gramatisk korrekt. Selv om teksten er kvalitetssikret og oversettelsen er riktig, kan det være at teksten ikke passer inn i den kulturelle sammenhengen. Mens vi i Norge ofte er direkte i kommunkasjonsformen, er det andre kulturer, blant annet i sørøst-asia, der man er mer indirekte. [6]

36 2.10. Responsiv Design Symboler Symboler er lett gjennkjennelige og kan gi mening for brukeren, uavhengig av brukerens bakgrunn. Samtdig kan symboler og ikoner skape problemer ved at de oppfattes forskjellig avhengig av kulturell bakgrunn. Det finnes symboler som har en spesiell betydning i forskjellige kulturer og som for noen kan oppfattes som negative. I Norge kan gris brukes som dekorasjon rundt juletider og det spises marsipangriser. Fremhevingen av gris kan være uheldig da grisen i den muslimske delen av verden blir sett på som uren. Det er viktig å tenke over hvilke ikoner og symboler man bruker på nettet, og forsøke å bruke ikoner og symboler som er så kulturnøytrale som mulig. Dette er illustrasjoner som ikke har tilknytting til noen kulturelle særegenheter. [6] 2.10 Responsiv Design Responsiv design går ut på at nettstedet tilpasser seg de ulike skjermstørrelser slik at den kan leses like godt på mobil, nettbrett og PC. Noen av grunnene til lage et nettsted som er responsivt er at det skaper et helhetlig inntrykk av nettstedet, det skaper mindre behov for oppdateringer fordi den samme informasjonen vises enten man innhenter den fra PC, nettbrett eler mobil. Det medfører ofte mindre kostnader å lage et responsivt nettsted fremfor en løsning for hver enhet nettstedet skal leses på. Figur 2.9 illustrerer tradisjonell utforming. Figur 2.9: Tradisjonell utforming Når man skal designe et responsivt nettsted er det mange elementer som bør tas i betraktning. Noe som er viktig er å kartlegge hvilke behov brukerne av nettstedet har når ser på den fra PC, nettbrett eller mobil. Om man lager et nettsted f.eks. for et tannlegekontor vil sannsynligvis brukerne fra mobil ha behov for informasjon om åpningstider samt kontaktinformasjon og adresse men fra PC det være behov for utfyllende informasjon. Figur 2.10 illustrerer hvordan det er mulig ved hjelp av flyende design å plassere bolkene med informasjon i den rekkefølgen man ønsker å presentere for brukerne. Flytende design går ut på å benytte seg av ulike egenskaper i CSS. Her er bolkene satt til float:left; og width: 33% som standard. For at nettstedet skal vises slik vi ønsker det på nettbrett og mobil må vi legge til media queries. Media queriesene vi legger her går ut på å legge til nye egenskaper til bolkene når nettstedet vises på en enheten med mindre skjerm. For nettbrett setter vi bolk 1 og 2 til å være 50% og bolk 3 til 100%. For mobil settes alle bolkene til 100% og de vises hierarkisk etter hvor viktig innholdet er. x For å kunne oppnå et flytende-design er gir bruken en prosentverdier i stylesheet for å definere størrelsen på elementer. [8] Media queries Mobile first er et nytt begrep som har dukket opp de siste årene. Som begrepet antyder går det ut på å lage en nettløsning med tanke på brukerne på mobiltelefoner først, for så å skalere seg

37 28 Kapittel 2. Analyse Figur 2.10: Flytende utforming oppover til nettbrett og PC. Behovet for dette har bakgrunn i at mange firmaer etterspør nettsteder som er tilgjengelige for alle medier ettersom nett-trafikken har endret seg betydelig de siste årene. For å legge til rette for dette kreves en ny type tankegang i forhold til planlegging når man utvikler nettsidene. Man må legge opp til en strategi som sørger for at alle brukerne får en like god brukeropplevelse uansett enhet de benytter. Ettersom Mobile first i økende grad blir benyttet for utvikling av nettsteder kan man si at det har vært et paradigmeskifter. Før lagde man nettsteder som var desktop-versjon som tilpasset seg skjermstørrelser uten større endringer, mens i dag ser man at brukerne får mer og mer skreddersydde løsninger som passer til behovene rundt det å innhente informasjon fra de forskjellige mediene.[7] Mobile first Mobile first er et nytt begrep som har dukket opp de siste årene. Som begrepet antyder går det ut på å lage en nettløsning med tanke på brukerne på mobiltelefoner først, for så å skalere seg oppover til nettbrett og PC. Behovet for dette har bakgrunn i at mange firmaer etterspør nettsteder som er tilgjengelige for alle medier ettersom nettrafikken har endret seg betydelig de siste årene. For å legge til rette for dette kreves en ny type tankegang i forhold til planlegging når man utvikler nettsidene. Man må legge opp til en strategi som sørger for at alle brukerne får en like god brukeropplevelse uansett medie de benytter. Ettersom Mobile first i økende grad blir benyttet for utvikling av nettsteder kan man si at det har vært et paradigmeskifte. Før lagde man nettsteder som var desktop-versjon som tilpasset seg skjermstørrelser uten større endringer, mens i dag ser man at brukerne får mer og mer skreddersydde løsninger som passer til behovene rundt det å innhente informasjon fra de forskellige mediene Grid-system Grid er en struktur bestående av en serie horisontale og vertikale linjer, disse brukes til å sette innhold på et nettsted i ordnede forhold. Et grid-system funger som en retningslinje for designere kan jobbe med å strukturere og presentere innhold og bilder i en lesbar og håndterlig måte. Ved å bruke et gridsystem blir en hjulpet inn i rammer og definerte bredder som hjelper til med å opprettholde en viss fast struktur. Grid-systemet fungerer som en base som en kan bygge designet

38 2.10. Responsiv Design 29 på, det hjelper designere og utviklere å lage et oppsett for et design. På nettet finnes det en rekke grid-framework, et eksempel på det er Bootstrap som er laget av Twitter. Et alternativ er å lage et grid-system på egenhånd. Fordelene ved å bruke et grid-system er at det kan være et utgangspunkt for utvikling av designet på et nettsted. Samtidig kan det vær til hjelp å benytte når en skal videreutviklingen nettsteder for fremtidens medier. En fordel er at grid -system tillater en å designe i proporsjoner, balansering mellom alle de ulike elementene som en ha i sitt design. Figur 2.11: Grid-System Figur 2.11 illusterer et grid-system. Systemet består av kolloner med prosentbasert bredde. Et eksempel, hvis en lager et nettsted med en 1000px grid som består av seks kolonner, hver er 150px bred. En så deler 150 med 1000 for å få en prosentbasert bredde. En 150px kolonne inne i en 1000px container er 15%.

39 Kapittel 3 Metode Prosjektgruppen har vært avhengig av å tilegne seg informasjon for å kunne gjennomføre prosjektet. Det er ingen fasit på hvordan informasjon skal innhentes, men det finnes gode metodebeskrivelser for hvordan en bør gå frem i innhentingen av informasjon. Olav Dalland beskriver metoden slik: Metoden er redskapet i vårt møte med noe vi vil undersøke. Metoden hjelper oss til å samle inn data, det vil si den informasjonen vi trenger til undersøkelsen vår. [?] I samfunnsvitenskapen blir det ofte trukket et skille mellom to undersøkelsesmetoder, kvantitative og kvalitative metoder. Kvantitative metoder innhenter informasjon i form av målbare enheter som for eksempel tall og mengder. Informasjonen kan brukes i regneoperasjoner, og resultatet av metoden kan fremstilles statistisk. Kvalitative metoder innhenter informasjon som ikke lar seg måle, det kan for eksempel være tanker og opplevelser.[10] Prosjektgruppen har brukt en kombinasjon av ulike kvalitative metoder for innhenting av informasjon i prosjektet. I dette kapittelet beskrives hvilke metoder som prosjektgruppen har brukt, og hvordan de ulike metodene ble gjennomført. 3.1 Kvalitativ intervju Et intervju er en samtale mellom forsker og respondent. Et kvalitativt intervju kan beskrives som å samle informasjon, med den hensikt å forstå et fenomen. Metoden brukes når det ønskes å kartlegge hendelser som en ikke har mulighet til å selv observere. Et kvalitativt intervju brukes for å samle informasjon dersom en skal utvikle et produkt og det er nødvendig med dybdeinformasjon. Et kvalitativt intervju kjennetegnes ved at forskeren bruker en intervjuguide som skal lede respondenten innom ønskede temaer, mens man i kvantitive undersøkelse gjerne bruker et fastsatt spørreskjema. Et intervju der kun temaet er forhåndsbestemt kalles for et ustrukturert intervju. Et semistrukturert intervju kjennetegnes ved at både tema og spørsmål er bestemt, men intervjuet ikke nødvendigvis er låst til de forhåndsbestemte spørsmålene. Figur 3.1 beskriver sammenhengen mellom metode og intervjuform. [16] Prosjektgruppen gjennomførte to personlige intervjuer i prosjektperioden. Det var viktig for prosjektgruppen å tidlig innhente informasjon om hva slags tanker oppdragsgiver hadde rundt prosjektet, og intervjuet derfor to av prosjektets oppdragsgivere. Gjennomføringen var inspirert av en semistrukturert form. Prosjektgruppen hadde på forhånd laget en intervjuguide med flere spørsmål 30

40 3.2. Utviklingsprosessen 31 Figur 3.1: Sammenhengen mellom metode og intervjuform som skulle brukes, samtidig som det ble gjort åpent for digresjon under intervjuet. Valget av semistrukturert intervju ble gjort fordi det var enkelte spørsmål som prosjektgruppen var avhengige av å få svar på, samtidig som at det ikke var sikkert at intervjuguiden dekket alt som kunne være av relevant informasjon for prosjektet. Prosjektgruppen var interessert i å åpne for samtale rundt nye temaer som eventuelt skulle dukke opp under intervjuet. Intervjuene ble gjennomført med intervjuobjektet og alle tre av prosjektgruppens medlemmer. Det ble på forhånd avtalt hvilke oppgaver hvert gruppemedlem skulle ha under intervjuet. To av gruppemedlemmene noterte, mens et av gruppemedlemmene stilte spørsmål. Det var åpent for at de som noterte kunne komme med spørsmål og innspill dersom de ønsket det. For å sikre seg at all informasjon ble notert, ytret prosjektgruppen et ønske om å ta lydopptak under intervjuene. Noe begge intervjuobjektene tillate. 3.2 Utviklingsprosessen Utviklingen av nettstedet er inspirert av utviklingsmodellen som Sharp, Rogers og Preece beskriver i boken Interaction design: beyond human-computer interaction [18]. Modellen beskriver livssyklusen til et brukersentrert utviklingsprosjekt, hvor en rekke prosesser gjentas til produktet er ferdig. Prosessene består i å først kartlegge krav og behov hos kunde eller brukere, deretter skisseres og designes produktet. Det lages så en interaktiv versjon av designet, før det testes og evalueres [18]. Figur 3.2: Designsyklus Prosjektgruppen har gjennom hele prosjektperioden lagt stor vekt på god kommunikasjon med oppdragsgiver. Gjennom god kommunikasjon har prosjektgruppen hatt som mål å minske rom for

41 32 Kapittel 3. Metode misforståelser mellom prosjektgruppen og oppdragsgiver. Prosjektgruppen har involvert oppdragsgiver mest mulig i utviklingsprosessen gjennom regelmessige møter underveis i prosjektperioden. Involvering av oppdragsgiver er noe begge parter har hatt god nytte av, ved at det alltid har vært en felles enighet i hvilken vei prosjektutviklingen har gått. Figur 3.3 beskriver prosjektgruppens utviklingsprosess under prosjektperioden.

42 3.3. Brukertest 33 Prosjektgruppen valgte å utvikle en prototype etter å ha fremvist ulike wireframes som vi hadde skissert på bakgrunn av forundersøkelsene vi har foretatt. Vi så dette som et nødvendig grep for å gi oppdragsgiver en ramme for hva vi så for oss av løsning på oppgaven. En annen faktor vi la til grunn for valg av denne metoden var at oppdragsgiver ikke innehar noe særlig kunnskap om hvilke muligheter som finnes innen nettløsninger og vi mener denne formen for utvikling vil kunne bidra til å opplyse oppdragsgiver for de muligheter som finnes samt at de kan komme med konkrete tilbakemeldinger til oss. Fra 24. Mars begynte utviklingen av prototypen, samtidig ble det lagt ut en live-versjon av nettløsningen som var tilgjengelig for oppdragsgiveren, slik at de underveis i utviklingsprosessen kunne se hva som ble gjort og komme med tilbakemeldinger. 3.3 Brukertest Brukertesting er en evaluering av et produkt gjennom tester med representative brukere. Det er vanlig at brukerene skal forsøke å gjennomføre oppgaver, mens en observatør ser på, og noterer. Målet med brukertesting er å finne problemer ved produktets brukervennlighet, innhente data og finne ut om brukerens opplevelse av produktet. [21] Prosjektgruppen gjennomførte en brukertest for å innhente informasjon om målgruppens opplevelse av nettstedet. Prosjektgruppen har brukt mye tid på prototypen og kjenner nettstedet godt. Derfor er det viktig å hente inn utenforståendes opplevelse av nettstedet. Utenforstående vil kunne se på nettstedet fra et annet perspektiv, både ved at de ikke kjenner til nettstedet, og at deres buk av internett varierer fra prosjektgruppens Testplan For å oppnå et godt resultat ble det på forhånd laget en testplan. Planen beskriver hvorfor og hvordan prosjektgruppen gjennomførte brukertesten Formålet Formålet med brukertesten er å teste nettstedets brukervennlighet. Med brukervennlighet menes brukerens forståelse av nettstedets navigasjon, merker og struktur samt hvordan de opplever brukerterskelen. Et annet viktig aspekt med å utføre denne testen er at vi som utviklere av nettstedet skal forstå brukernes behov Problemstilling Ved gjennomføring av brukertesten ønsket gruppen å få svar på følgende: 1. Navigasjon: Er dette nettstedet er at den er enkel å bruke slik at brukerne finner frem til dit de ønsker uten hjelp. Gir ikoner og titler på nettstedet brukerne assosiasjoner som hjelper de å navigere. Hvor godt klarer testpersonene å navigere på siden? Klarer brukeren å løse oppgaven på første forsøk eller må det flere forsøk til for å komme frem til riktig destinasjon på nettstedet. 2. Informasjonvisning: Presentasjon av tiltak i Nedre Glomma: Opplever brukerene at nettstedet presenterer tiltak på en god og oversiktlig måte. Finner brukerene tiltakene som de blir bedt om å finne.

43 34 Kapittel 3. Metode 3. Design: Formidling av nettstedet sitt budskap gjennom nettstedets oppbygging og grafiske profil. Liker testpersonenen designet på siden? Er fargene gode i forhold til lesbarhet og brukervennlighet på nettstedet? Testpersoner Prosjektgruppen ønsket å teste potensielle brukere av nettstedet, og vi har derfor forsøkt å finne testpersoner som gjenspeiler målgruppen for nettstedet. Med god hjelp fra oppdragsgiver fikk prosjektgruppen tak i 5 personer fra Nedre Glomma regionen. Alderen til deltakerene er godt spredt og representerer flere aldersgrupper Metodologi Metoden som ble benyttet under denne testen baserer seg på innhenting av kvalitative data gjennom observasjoner av testobjektene. Videre innhentet vi brukernes subjektive meninger ved at vi stilte spørmål knyttet til oppgavene de hadde gjennomført på nettstedet. Gjennomføringen av brukertesten er besto av fire deler. 1. Deltakerbakgrunn: Første del gikk ut på at prosjektgruppen hilste på deltakeren og tilegnet seg bakgrunnsinformasjon om deltakeren. For at testobjektene skulle føle at de kunne si sin mening ble de tilbudt om å signere en avtale om anonymitet før testen. 2. Orientering: Vi orienterte testpersonene om hvordan testen skulle foregå og om vår rolle som observatør. Vi forklarte at de skulle bruke nettstedet på en måte som er komfortabel og typisk for deltakeren. Vi ga testobjektene beskjed om at de skulle tenke høyt, og kunne kommentere underveis og/eller etter hver utførte oppgave, dersom det var noe de ønsket å legge til. 3. Utførelse av testen: Deltakeren skulle utføre en rekke oppgaver på nettstedet. Vi hadde med en PC med Windows 8 operativsystem. Testen ville ikke kunne kreve kunnskaper eller brukerferdigheter for et Windows 8-system. Testobjekt 5 hadde svekket syn og tok med sitt eget utstyr, iphone og MAC. 4. Debriefing: Etter at alle oppgaver var gjennomført, stilte prosjektgruppen deltakeren spørsmål om deres opplevelse av nettstedet. Etter debriefingen takket vi testobjektet for deltakelsen Observatørrollen Gruppen valgte å forholde oss mest mulig nøytrale i forhold til brukertesten ved at vi ikke ga testobjektene noe informasjon om nettstedet som skulle testes. Vi gjorde følgene: En observatør satt bak testobjektet, noterte og leste opp oppgavene. Den andre observatøren satt i bakgrunn, ved siden av testpersonen, og noterte. Denne personen behøvde ikke å si noe, slik at testpersonen kun hadde én observeratør å forholde seg til. I tre av fem brukertester gjennomførte prosjektgruppen med tre observatører. Disse tre brukertestene ble gjennomført med kort tids mellomrom. Ved å ha tre observøterer forsikret gruppen seg at alt ble dokumentert. En tredje observatør sitter i enden av bordet og noterer testobjektes svar, kommentarer og sitt inntrykk av kroppspråket.

44 3.3. Brukertest Testomgivelse Brukertestens omgivelser lignet et hjemmekontor og bestod hovedsaklig av et bord og en stol. Testene ble gjennomført på fylkeskommunen i Sarpsborg og på Høgskolen i Østfold, Remmen. Testrommet bestod av et bord med en PC med Windows operativsystem. Ved siden av PC en var det plassert en datamus. PC en var slått på og viste nettstedets forside i nettleseren Chrome. Testobjekt 5 benyttet Safari-nettleser på iphone med skjermleser og Mac med innebygget verktøy for tilpasset kontrast og forstørring.

45 36 Kapittel 3. Metode Figur 3.3: Prosesshendelser i prosjektperioden

46 Kapittel 4 Resultater 4.1 Intervju av Tor Stabbetorp Prosjektgruppen gjennomførte 31.Januar 2014 et intervju med Tor Stabbetorp, som er prosjektleder i koordineringsutvalget. Koordineringsutvalget er et utvalg sammensatt av representanter fra de ulike partene i samarbeidsavtalen om areal- og transportutvikling i Nedre Glomma. Formålet med dette møte var å kartlegge mål, behov og begrensinger for løsningen. Prosjektgruppen stilte følgende spørsmål: 1. Hva er bakgrunnen for nettstedet? 2. Hva er forretningsideen og målet med nettstedet? 3. Hvem er målgruppa, og hvilke oppgaver skal de utføre på nettstedet? 4. Hvilken informasjon på nettstedet ønsker dere hovedfokus på? Prosjekter eller holdningsendring? 5. Hva er budsjettet for nettløsningen? 6. Når vil lanseringsdatoen være? 7. Hvilke delprosjekter ønsker dere å henvise til på nettstedet? 8. Har dere tenk å involvere andre aktører enn de som er med i samarbeidsavtalen? 9. Hvorfor er universell utforming viktig for denne løsningen? 10. Hva legger dere i begrepet universell utforming? Under intervjuet kommer det fram at det er samarbeidsavtalen i Nedre Glomma regionen som er bakgrunnen for prosjektet og at det er behovet for kommunikasjon som er utgangspunktet for å utvikle nettstedet. Med nettstedet ønsker de å kommunisere målet med samarbeidsavtalen og hvordan målet skal bli nådd. Det kom frem at målgruppen for løsningen er hele befolkning av hele Nedre Glomma regionen og Tor ønsker en 2-veis kommunikasjons løsning. Lanseringsdatoen er ikke fast, det er opptil oppdragsgiveren når de ønsker en lansering. Tor fortalte at han så for seg at budsjettet ville ligge på ,- omtrent. 37

47 38 Kapittel 4. Resultater Det kommer i tillegg frem at Østfold Fylkeskommune ikke har en stor informasjonsgruppe, så det vil kunne være nødvendig å ansette en person til oppfølging av den nye løsningen. Prosjektgruppen blir tipset om å snakke med Fredrik Norland som jobber i informasjonsgruppen om hva slags type innhold løsningen bør kunne dekke. Det blir fortalt at universell utforming er viktig for Østfold Fylkeskommune fordi informasjonen skal være tilgjengelig for alle. Dette er er offentlig informasjon, derfor er krav fra DIFI viktig å ta hensyn til i løsningen. 4.2 Intervju av Fredrik Norland Den 14 februar avholdt prosjektgruppen et intervju med Fredrik Norland som en del av forundersøkelsen. Fredrik er ansatt som kommunikasjonsrådgiver og er involvert i Nedre Glomma samarbeidet. Under intervjuet ble følgende spørsmål stilt: 1. Hvilke behov skal nettstedet møte? 2. Hvem er målgruppa, og hvilke oppgaver skal de utføre på nettstedet? 3. Er det mange i Nedre Glomma regionen som har etterspurt en slik tjeneste? 4. Hvem skal videreutvikle løsningen? 5. Hvordan skal den driftes? Hvem har ansvar? 6. Hvem skal lage innholdet og vedlikeholde det? Informasjonsgruppen? 7. Hvilken informasjon på nettstedet bør det være hovedfokus på? Prosjekter eller holdningsendring. 8. Hvilke delprosjekter ønsker dere å henvise til på nettstedet? 9. Hvilke dokumenter bør publikum ha tilgang til? 10. Har dere en standard for design og utforming av nettsteder hos ØFK? 11. Hva legger dere i begrepet universell utforming? 12. Hvorfor er universell utforming viktig for denne løsningen? 13. Hvilke hensyn tas det til brukere med funksjonsnedsettelser i dag? 14. Har dere merket dere noen utfordringer ved å ta slike hensyn? 15. Bruker dere et publiseringssystem til dagens nettsider, hvilket? 16. Er det viktig for dere at vi benytter oss av samme publiseringssystem? Fredrik ser for seg at løsningen dekker lesernes behov for forståelse av hvorfor fylkeskommunen, Statens Vegvesen og de to kommunene gjennomfører et prosjekt. De bør også få vite hva bommene vil koste og hvor skal bommene stå. Det pekes på at nettstedet skal nå ut til en bred målgruppe, men at det muligens er et poeng å fremheve holdningsendrende kampanjer mot de nedre aldersgruppene. Når det kommer til etterspørsel av en slik løsning er det mest de som jobber

48 4.3. Idémyldringsmøte 39 med prosjektet Nedre Glomma Samarbeidet som ser behovet for å informere publikum om hva som skjer i regionen frem til 2017, når det skal komme flere bomstasjoner. Dette er for å skape en åpenhet rundt bompenger og hva pengene går til. Dokumenter som ligger til grunn for alt man gjennomfører i bypakken bør ligge tilgjengelig for publikum. Det er viktig med åpenhet, det er også et krav om offentlighet i forvaltningen. Når det kommer til administrasjon av nettløsningen ser Fredrik for seg at det blir ansatt en person med hovedansvar for nettstedet. Videre snakkes det om at ØFK er villige til å bruke de penger som trengs for å få til en god løsning, enten den blir utviklet internt eller hos en ekstern tredjepart. Oppdragsgiver opplyser at de er pilotfylke for UU, noe som betyr at de har vært med helt fra starten av. Det har vært ansatt en person som har jobbet med dette prosjektet for fylkeskommunen i 2 år, men som nylig har sluttet. Det blir nevnt at det foreligger en rapport på dette feltet, men det blir henvist til fylkeskommunens nettsider. Oppdragsgiver sier at grunnen til at dette er viktig er todelt. Det ene er krav fra det offentlige som må følges. Det andre er tilgjengelighet for alle, det finnes ingen grunn for at det ikke skal tas hensyn til alle brukergrupper. Målet er å nå ut med informasjon til alle og da må det også være tilgjengelighet for alle. Når det kommer til bruk av CMS system for løsningen er ikke dette viktig for oppdragsgiver da de har et eget publiseringssystem for sine nettsteder. Det viktigste er at det benyttes HTML/CS- S/JavaScript standarder slik at nettstedet kan integreres med det eksisterende publiseringssystemet. 4.3 Idémyldringsmøte Den gjennomførte prosjektgruppen et idémyldringsmøte sammen med oppdragsgiver, hvor vi blant annet gikk gjennom følgende punkter. Bruk-scenarioer for nettstedet Evaluering av funksjonalitet og innhold hos relevante nettsteder Kortsortering Oppdragsgiveren har tidligere sett på prosjektgruppens forslag til bruk-scenarioer, og var fornøyde med disse. Under idémyldringen kom det fram at å kutte ut bil som transportmiddel ikke er hensiktsmessig for alle brukere og at det derfor er viktig med et scenario der brukeren ikke nødvendigvis slutter å bruke bil, men fortsetter bilbruken og benytter sykkel en gang i blant. Eventuelt at pendlere setter fra seg bilen på innfartsparkeringer, og reiser kollektivt inn til sentrum. Oppdragsgiver mente et scenario der det økonomiske aspektet ved å la bilen stå også var relevant. Det ble enighet om at kartløsningen og kartets funksjonalitet hos nettstedet miljopakken.no var en god løsning for å gi en oversikt over prosjekter i Nedre Glomma regionen. Kartet viser hvor alle prosjekter finner sted i området og gir brukeren muligheten til å filtrere visningen. Brukeren kan filtrere visningen ved å huke av for ønsket prosjekttype (Kollektiv, Veg, Sykkel, Trafikksikkerhet, Miljø) og hvorvidt prosjektet er planlagt, påbegynt eller ferdig. Det kommer frem at det er viktig å også å gi informasjon rundt fotgjengere. Oppdragsgiver ønsker at prosjekter skal inneha mer informasjon enn det som er på miljopakkens nettsider, deriblant bilder, fremdriftsstatus etc. og at det kan linkes til eksterne nettsteder, som for eksempel vegvesenet, der det allerede finnes informasjon. Det bør også være en oversiktlig liste over alle prosjekter, som blant annet hjelper med å gjøre nettstedet universelt utformet.

49 40 Kapittel 4. Resultater Figur 4.1: Kartløsning fra miljopakken.no Det kommer fram at viktigheten av å vise publikum hva pengene går til er stor, at det vises hvor mye penger som er brukt på de forskjellige prosjektene. Det ønskes å gi tilgang til dokumenter som gir bakgrunnsinformasjon. Det kan være politiske vedtak, presentasjoner og andre relevante dokumenter. En FAQ (frequently asked questions) blir også nevnt som en god måte å gi informasjon på. Oppdragsgiverne liker at utformingen av hoppoverbommen.no er litt mer interaktiv og ikke følger det typiske rammeverket for nettsteder. Dette nettsteder mangler mye informasjon, blant annet om prosjekter. En blanding av hoppoverbommen.no og miljopakken vil gi nødvendig informasjon samtidig som den kan inneholde interaktive elementer. En idé til et interaktivt element er en kalkulator som viser både økonomisk og helsemessig gevinst ved for eksempel samkjøring. Oppdragsgiver ønsker at kommunikasjonen gjennom nettstedet gir muligheter for tilbakemeldinger fra publikum. Det diskuteres løsninger som blant annet Facebook, kommentarfelt og kontaktskjema. Oppdragsgiver ønsker ikke å starte en debatt om bompenger, det er ikke hensikten med nettstedet. Det kommer fram en idé om at en kan prøve å styre kommentarene ved at det under hvert prosjekt er en link hvor det for eksempel står Lurer du på noe mer angående prosjektet, spør oss på Facebook. 4.4 Brukertest Etter utviklingen av prototypen, gjennomførte gruppen en brukertest for å innhente informasjon om brukerens opplevelse av nettstedet. Metoden er beskrevet i kapittel 3.

50 4.4. Brukertest Pilottest: I forkant av testene gjennomførte gruppen en pilottest. Det var gjort for å luke ut mulige feil og problemer med testen, for å kunne rette på eventuelle mangler før vi testet mot testpersonene. Etter gjennomført pilottest fjernet vi følgende spørsmål: Hva synes du om nettstedets design? Prosjektgruppen opplevde at spørsmålet kunne oppfattes som svær likt spørsmålet om brukerens opplevelse av nettstedets utforming Oppgaver 1. Finn en oversikt over alle utførte sykkel-tiltak. 2. Klikk på Kollektiv, hvilke valg er det mulig å foreta nå? 3. Uten å trykke på noe, hva tror du skjuler seg bak menyknappen kart? 4. Vi tar brukeren til siden for tiltaket FV 109 Alvim Torsbekkdalen Hvor på nettstedet er du nå? 5. Klikk på Kollektiv og finn tiltaket FV 109 Alvim Torsbekkdalen. 6. Finn startdato for dette tiltaket. 7. Legg til et innspill til dette tiltaket. 8. Gå til forsiden, uten å bruke nettleserens tilbakeknapp. 9. Tenk deg at du ønsker å kontakte bypakken, hva gjør du? 10. Finn samarbeidspartnerne som står bak dette nettstedet. 11. Forestill deg at du bor på Grålum, du ønsker å finne ut om hvilke tiltak som er aktuelle for ditt nærområde. Hvordan ville du funnet informasjon om aktuelle tiltak? 12. Finn prisinformasjon fra bomselskapene Spørsmål til brukerenes meninger Hva opplever du at nettstedet prøver å fortelle/formidle? Synes du nettstedets budskap kommer tydelig frem? Hva synes du om nettstedets utforming (Design og struktur)? Hva synes du om presentasjonen av tiltakene? Synes du de klikkbare elementene på nettstedet er tydelig merket? Hvordan synes du det var å navigere på nettstedet? Synes du titlene og ikonene på navigasjonen til nettstedet er beskrivende for innholdet du kommer til?

51 42 Kapittel 4. Resultater Føler du at du vet hvor du er på nettstedet til en hver tid? Synes du det er nyttig å kunne legge til innspill til tiltakene? Har du gjort deg noen bemerkninger ved bruk av nettstedet? Er det noe du savner på nettstedet? Resultater fra testobjektene Testobjekt 1: 57 år, bruker 1 time daglig på internett og benytter PC på jobb og ipad til hjemmebruk. Testobjekt 1 navigerer raskt på nettstedet, løser navigasjonsoppgavene uten problemer og ser hvilke elementer som er klikkbare. Testobjektet forteller at han vet hvor han er til enhver tid og opplever at nettstedet er tydelig og at det har en logisk oppbygning. På oppgave nr. 3 forventet han å finne et kart over Nedre Glomma som viser bussruter eller lignende. I prototypen viser kartet hvor de ulike tiltakene finner sted. Testobjektet forventet seg noe annet enn hva gruppen har lagt inn i kartet. På oppgave nr. 4 forstod testobjektet raskt hvor han befant seg på nettstedet, men han visste ikke om tiltaket var under kategorien påbegynt-, kommende-, planlagt- eller utført-tiltak. Testobjektet synes den lokale menyen er logisk, men lurer på hvorvidt den er logisk for utenforstående. Testobjekter ser at siden automatisk viser påbegynte tiltak og nevner at det kanskje kunne være bedre å først vise hva som er ferdig og fungerer i dag, og at man deretter kan finne ut hva som kommer. Testobjektet liker at det er likt sideoppsett. Det gjør at dersom man har vært på én side, vet man hvordan ting gjøres på en annen side. Testobjektet nevner at det var lett og tydelig å komme med innspill på nettstedet. Testobjektet ville ha brukt kontaktskjemaet hvis han skulle kontakte Bypakke Nedre Glomma. Det ble nevnt at bannerboksen er tydelig og lett å se, og at det er positivt at innholdet blir værende når man har musepekeren over. Gruppen observerte at testobjektet tok seg tid til å se alt på hver side, kommenterte også at kanskje Bypakke Nedre Glomma ikke var et godt tittelnavn, siden han ikke visste hva navnet innebar. Testobjekt 2: 20 år, bruker 10 timer daglig på internett og benytter PC. Testobjektet navigerer raskt på nettstedet, løser navigasjonsoppgavene uten problemer og ser hvilke elementer som er klikkbare. Testobjekt lurer på hva som menes med utførte tiltak. På oppgave nr. 3 forventer testobjektet at menyelementet Kart viser et kart med oversikt over sykkelstier og turstier. Testobjektet ville ha benyttet kontaktskjemaet fremfor Facebook hvis han skulle kontakte Bypakken. For å finne et spesifikt tiltak benyttet testobjektet søkefunksjonen. På spørsmål om nettstedets budskap leser testobjektet opp hva som står i bannerboksen på forsiden. Testobjektet forteller at han liker designet, det er enkelt og oversiktlig. Samtidig trodde testobjektet at bildene i presentasjonen av tiltakene var klikkbare. Gruppen observerte at testobjektet navigerte se veldig raskt rundt på nettstedet. Testobjekt 3: 58 år, benytter internett hovedsakelig i jobbsammenheng og bruker omtrent 30 minutter til 1 time daglig på PC. Testobjektet forteller at han synes det er greit å navigere på nettstedet og ved hjelp av ikoner og tilhørende titler forstår han hvor han befinner seg på nettstedet. Nettstedets innhold er tydelig og klikkbare elementer er lett å få øye på. Ved oppgave nr. 3 forventer testobjektet et kart over Nedre Glomma Regionen med en oversikt over stoppesteder for bussene i regionen, og kanskje en reiseplanlegger for kollektivtransport. For å kontakte Bypakke Nedre Glomma mener testobjektet at det er mer naturlig for han å velge kontaktskjemaet enn å benytte seg av Facebook. Når testobjektet skulle finne et bestemt tiltak brukte testobjektet

52 4.4. Brukertest 43 søkefunksjonen. I de tre siste oppgavene velger testobjektet å søke for å finne frem. Testobjektet forteller at han opplever at nettstedet uttrykker et tydelig budskap og at nettstedets farger gjør at informasjonen blir fremhevet. Logoen var ingen selvfølge å trykke på for å komme til forsiden. Testobjektet synes han måtte scrolle noe for å finne frem, det var noe uventet. Testobjekt 4: 70 år, bruker omtrent 30 minutter daglig på surfing fra PC. Testobjektet tar seg tid til å lese hva som står skrevet på hver side på nettstedet gjennom testen. Hun forteller at bannerboks-teksten forsvinner noe kjapt, men at hun samtidig finner informasjonen her veldig interessant. På oppgave nr 3. forventer testobjektet å finne et kart over Nedre Glomma og bussruter. Testobjektet nevner at hun er usikker på om tiltaket FV 109 Alvim Torsbekkdalen finnes i kategorien påbegynte-, kommende-, planlagte- eller utførte tiltak. Det nevnes at faktaboksene er lette å få øye på og har relevant informasjon. Samtidig finner ikke testobjektet innspill til tiltaket lett, hun forventer at denne befinner seg i bunn av teksten. Testobjektet ville tatt i bruk kontaktskjemaet, men opplyser samtidig at dersom Facebook-kunnskapene hadde vært større ville hun ha brukt det. Testobjekt gav opp å finne samarbeidsparter, selv om hun befant seg på riktig side, det måtte scrolles en gang for å finne samarbeidspartnerne. For å finne konkrete tiltak ville testobjektet benyttet seg av søkefunksjonen. Testobjektet forteller at hun liker nettstedets struktur, det hjelper at elementer er repeterende for å navigere seg rundt. Testobjektet føler hun vet hvor hun er til enhver tid og nevner at hvis hun ikke skulle vite det, så ville hun klikket på logoen og startet på nytt. Testobjekt 5: 23 år, bruker omtrent 3 timer daglig på internett og benytter hovedsakelig iphone til nettbruk. Testobjekt 5 har nedsatt synsevne og har derfor behov for å bruke skjermleser og zoom-funksjon ved surfing på nett. Under testen brukes den innebygde skjermleseren til iphone i oppgaveløsningen. Til spørsmål som handler om universell utforming brukes en MAC, med nettleseren Safari. iphone skjermleseren fungerer ved at den leser opp elementer i nettsidens HTML dokument. Derfor ble denne brukertesten gjennomført på en noe annerledes måte enn de fire andre testene og det ble også stilt spørsmål angående universell utforming. Testobjektet forklarer at han, og flere med nedsatt synsevne, foretrekker sans-serif fonter, og at det derfor bør velges en annen font på forsiden. Nettstedet er gjennomført lyst og derfor brukervennlig med tanke på fargeinverteringen forteller testobjektet. Fargevalgene er gode, særlig på les mer linkene til tiltakene. Et problem var at han måtte gå igjennom alle bannerboks-tekstene ved hjelp av skjermleseren før han kom til den lokale menyen. Samtidig stoppet skjermleseren å lese ved hver span - tagg, noe som gjorde at innholdet ikke virket sammenhengende og kunne forvirre. Han forsto ideen med bannerboksen, men for hans vedkommende ville det vært nyttig å ha denne informasjonen plassert annerledes. Testobjektet opplever at nettstedets budskap kommer tydelig frem Oppsummering av brukertestene I disse brukertestene kom det frem at navigasjonen var forstående og brukervennlige, ingen av de 5 testobjektene hadde store vansker å forstå den globale menyen. Det kommer frem at alle synes at ikonene og titlene samsvarer med hvilken side de kommer til. 1 av testobjektene stusset over menyelementet bil og kommenterte at han ikke følte det passet inn på nettstedet. Hans oppfatning var at nettstedet skulle motivere til kollektiv-transport. 4 av 5 testobjekter fortalte at nettstedet var enkelt å navigere, de forstår hvilke elementer som er klikkbare og hvor de befinner seg på siden. For 1 av 5 testobjekter var det ingen selvfølge at logoen var klikkbar for å komme til forsiden, og testobjekt

53 44 Kapittel 4. Resultater 5 savnet at alternativt navn til linken i logoen enn index. Testobjekt 5 synes det var vanskelig å finne den lokale menyen siden skjermleseren måtte igjennom alt innhold i bannerboksen først. 3 av 5 ville hovedsakelig ha benyttet seg av kontaktskjemaet på nettstedet for å kontakte Bypakke Nedre Glomma. Testobjekt 4 fortalte at dersom Facebook egenskapene hadde vært bedre, ville hun ha benyttet seg av Facebook. For Testobjekt 5 var det ingen forskjell for han å bruke kontaktskjemaet eller å bruke Facebook. Vedrørende presentasjonen av tiltakene fortalte alle at utformingen av tiltakene var god, 2 av 5 savnet at bildene i tiltak-presentasjonen var klikkbare. 2 av 5 undret seg over inndelingen i den lokalemenyen; Påbegynte tiltak, Kommende tiltak, Tiltak under planlegging og Utførte tiltak. De fortalte at disse kategoriene ikke fortalte hva de ville finne ved å klikke på disse elementene. 3 av 5 valgte å bruke søkefeltet da de skulle finne et bestemt tiltak. Testobjekt 5 valgte å lete rundt på nettstedet, for han likte ikke å bruke søkefunskjoner. Testobjekt 1 valgte å bruke kartet for å finne område tiltaket handlet om. 2 av 5 fortalte at det å scrolle på siden var uventet, selv om det holder med å scrolle 1-2 ganger for å komme nederst på siden. En av testobjektene fant ikke samarbeidspartnere, testobjektet fant frem når observatøren fortalte at for å finne det måtte det scrolles en gang nedover siden. Alle testobjektene forventet seg å finne et kart over Nedre Glomma regionen når de trykket på menyelementet Kart. Testobjekt 5 fortalte at det var utelukkende for han å bruke kart, siden det var veldig krevende å benytte seg av for en med svekket syn. Når det gjaldt hva de forventet at kartet skulle vise av informasjon kom det frem at; 2 av 5 forventet bussruter, 1 av 5 forventet sykkelstier og turstier, 1 av 5 forventet stoppesteder og reiseplanlegger for ferdsel med kollektiv-transport. Testobjektene fortalte at de likte designet. Enkelte fortalte at nettstedet ga et tydelig budskap og at fargene gjorde at informasjonen ble fremhevet. En annen fortalte at nettstedet så ordentlig og profesjonelt ut. Testobjekt 5 fortalte at han ikke likte times-fonten som er benyttet på forsiden, derimot foretrakk han sans serif-fonter. Kontrasten for testobjekt 5 var god og bidro til at det var enklere å benytte seg av nettstedet uten å måtte bruke fargeinverteringen ofte.

54 Kapittel 5 Utforming Kapittelet tar for seg prosessen rundt utformingen av prototypen, fra skissering av wireframes, til endelig løsning. 5.1 Wireframe En wireframe lages for å vise hvordan en individuell side eller et tema kan se ut fra et arkitekturens perspektiv. Hensikten med wireframe er å visualisere nettsidens struktur, organisering og navigasjon, før man begynner på den tekniske løsningen. Wireframes blir laget i mange former og størrelser, og detaljnivå kan variere. Morville og Rosenfeld skiller mellom tre typer wireframes: Lavt-detaljnivå. Middels-detaljnivå. Høyt-detaljnivå. En lavt detaljnivå wireframe er en enkel skisse av nettstedets sidestruktur. Skissen skal fungere som en mal for sidene på nettstedet. Når man lager skissen, ser man vekk fra tekniske løsninger og designelementer som form, farge og typografi. Middels-detaljnivå er en mellomting mellom en lavt-detaljnivå wireframe og en høyt-detaljnivå wireframe. Det vil si at en middels-detaljnivå wireframe inneholder, mer detaljer, flere forklaringer og innholdet er mer unikt av de ulike elementene enn hva en lavt-detaljnivå wireframe er. Høy-detaljnivå wireframe, kan være skrevet i HTML eller være tegnet i et tegneprogram som for eksempel Adobe Illustratur. Fordelen med en høy-detaljnivå wireframe er at den kommer til live og bidrar til i større grad at klientene kan gi en bedre respons enn en lavt-detaljnivå wireframe til utvikleren. [15] Utvikling av wireframes Prosjektgruppen kalte inn oppdragsgiver til et utviklingsmøte for å presentere de ulike wireframes vi hadde skissert. Hensikten med dette møtet var at vi skulle komme frem til en utforming som prosjektgruppen og oppdragsgiver ville være med på å fremme formålet med nettstedet på en brukervennlig måte. 45

55 46 Kapittel 5. Utforming Wireframe 1 Wireframe 1, illustrert i figur 5.1, består av en førsteside som skal gi et tydelig inntrykk av hva nettstedet handler om. Det er plassert en logo øverst til venstre med et relevant bannerbilde til høyre for logoen. Menyelementene består av store ikoner med tilhørende titler. F.eks.: Sykkel, Gangvei, Bilvei etc. Med det kan brukeren kun blir presentert nettstedets hovedvalg og at brukeren deretter blir presentert en lokal meny etter at hovedvalget er foretatt. Figur 5.1: Wireframe 1 Tilbakemeldinger fra oppdragsgiver til wireframe 1 Oppdragsgiver synes det er en god idé og kun presentere hovedvalgene for brukeren da dette kan være med på å fremheve målene med nettstedet. Prosjektgruppen fikk tilbakemeldinger på at det burde ha vært en kort ingress som forteller om formålet med Bypakke Nedre Glomma med en lenke til mer utfyllende bakgrunnsstoff. Videre var oppdragsgiver usikker på om bannerbildet kommer godt nok til syne for brukerne Wireframe 2 Wireframe 2, illustrert i figur 5.2, har logo og søkefelt i headeren. Navigasjonen befinner seg i en egen kolonne til venstre. Navigasjonen er global og har en drop-down funksjon med undermeny slik at brukeren finner all informasjonen på et sted. Det er et relevant bannerbilde med en beskrivende ingress om hva nettstedet går ut på. I footeren er det lenker til innhold på nettstedet. Eksempler på dette kan være lenke til sitemap og kontaktinformasjon.

56 5.1. Wireframe 47 Figur 5.2: Wireframe 2 Tilbakemeldinger fra oppdragsgiver til wireframe 2 Oppdragsgiver synes utformingen til wireframe 2 var for tradisjonell. Prosjektgruppen fikk tilbakemeldinger på at det virket rotete og samle alt på et sted. Oppdragsgiver likte at det er et stort bannerbilde som kommer godt til syne. De likte også godt at det var en ingress som forteller brukeren om hva Bypakke Nedre Glomma går ut på Wireframe 3 På toppen i headeren i wireframe 3, illustrert i figur 5.3, er det plassert logo og hovedmeny (global meny). Videre følger det et stort relevant bannerbilde med en tekstboks i midten med en informativ tekst om hva bypakke Nedre Glomma går ut på. I footeren er det to seksjoner hvor den ene er til kontaktinformasjon og den andre er en oversikt over innholdet på nettstedet. Forskjellen på denne og wireframe 2 er at denne har en mer oppdelt menystruktur. Her har vi valgt å fokusere på tiltak som skal fremheves i løsningen ved at hovedmenyen tar brukeren til egne sider for Sykkelvei, gangvei, kollektiv, og bilvei. Menyelementene Prosjektkart og Om er også en del av den globale menyen. Tilbakemeldinger fra oppdragsgiver til wireframe 3 Oppdragsgiver likte denne utformingen best i forhold til de to andre wireframene som ble fremlagt. Grunner til det er at wireframe 3 består hovedmenyen kun av de elementene som er nødvendig for å fremme målet med nettstedet. De liker også at det er lagt opp til at hver hovedside skal ha hver sin lokale meny, noe de tror vil være med på å gjøre nettstedet oversiktlig for brukerne. Prosjektgruppen får også tilbakemeldinger på at det ser bra ut med et relevant bannerbilde i midten av forsiden med en ingress i midten av bannerbildet. Oppdragsgiver synes det er en god idé å ha tilleggsinformasjon i footeren, under Kontakt og Informasjon. Det kommer også et forslag om å lenke til samarbeidspartnere for Bypakke Nedre Glomma fra delen som kalles Informasjon. I tillegg gjør oppdragsgiver prosjektgruppen oppmerksom på at det ikke er noen synlig søkefunksjon på forsiden, noe de synes bør være plassert som en del av den globale menyen.

57 48 Kapittel 5. Utforming Figur 5.3: Wireframe Utforming av protoype På grunnlag av intervjuer og samtaler med oppdragsgiverene, samt skissering av wireframes, startet prosjektgruppen utviklingen av en prototype for nettstedet. Designet for nettstedet er blant annet inspirert av Steve Krug sin bok Don t make me think. Boken diskuterer mange viktige elementer ved design og innhold på et nettsted, med et mål om å øke nettsteders brukervennlighet. God brukervennlighet er viktig også for vårt nettsted, og vi vil videre begrunne designvalg for første prototype av nettstedet utviklet i HTML5, CSS3 og JavaScript. Generelt er plasseringen og utfomingen av et nettsteds elementer og informasjon svært viktig for brukerens opplevelser. Med elementer menes typiske inndelinger for et nettsted, deriblant nettstedets logo og tittel, globale menyer, lokale menyer, overskrifter og tekst Forside En god utforming av nettstedets forside er viktig. En forside er ofte ikke lik de andre nettsidene som den linker til. Prosjektgruppens forside, illustrert ved figur 5.4, inneholder en logo nummerert som 1, en global meny nummerert som 2, en bannerboks med informativ tekst nummerert som 3 og en footer nummerert som 4. Bak bannerboksen er det et bakgrunnsbilde. Plasseringen av elementer i prototypens forside er ikke tilfeldig. Det er svært typisk at nettsider plasserer logo eller tittel øverst til venstre på skjermen og at menyen plasseres høyt oppe eller helt mot venstre. Footeren på sin side blir plassert nederst på siden. Prototypen er inspirert av nettopp disse typiske nettstedene. Plasseringen har med brukerens vane å gjøre. Enten vi leser bøker, magasiner eller aviser, så begynner vi å lese øverst til venstre, og mot høyre. Dersom man en dag kjøper en bok og ser at første kapittel har overskriften nederst på siden, under teksten, blir man satt ut og fokuserer ikke på sidens innhold, men det faktum at overskriften er plassert nederst.

58 5.2. Utforming av protoype 49 Figur 5.4: Nettstedets forside Logo Forsiden er designet for å være forståelig og enkel. Derfor er nettstedets logo, markert med 1, plassert øverst til venstre i figur 5.4, fordi det er der brukeren forventer å se den. Logoen sier noe om hva nettstedet handler om, i dette tilfellet Bypakke Nedre Glomma. Tittelen er stor, i en lettlest font. Logoen i seg selv fungerer som en del av navigasjonen, ved at den er klikkbar og sender brukeren til nettstedets forside. Logoen vil vises på alle undersider, og gir derfor brukeren en rask vei tilbake til forsiden. I tillegg til å være et navigasjonselement, er logoen holdepunkt for hvor brukeren befinner seg. Ved å alltid ha logoen synlig på nettsiden brukeren er på, er det klart for brukeren hvilket nettsted han/hun befinner seg på. Dersom brukeren klikker på en link og blir sendt til Statens Vegvesens nettsider, er logoen borte og brukeren vet at han/hun nå befinner seg på et annet nettsted. Global meny Den globale menyen, markert som nummer 2 figur 5.4, består av 6 valg. Hvert valg er en kombinasjon beskrivende tekst og tilhørende ikon. Prosjektgruppen har valgt en kombinasjon av disse for at menyen best mulig skal være både informativ og visuelt attraktiv. Ikoner alene er ikke like brukervennlige og beskrivende for brukere som er avhengige av skjermlesere eller lignende verktøy. Tekst alene er ikke like visuelt attraktivt som ikoner, samtidig som ikoner tilbyr en forståelse for brukere som ikke er trygge på det norske språket. Den globale menyen er plassert øverst på siden, til høyre for logoen. Det er flere grunner til at den globale menyen er plassert høyt på siden. Akkurat som med logoen, er det forventet å se en meny øverst på siden. Menyen er som regel enten plassert som en vertikal liste under nettsidens logo, eller horisontalt, slik som i vår prototype. En annen grunn til at den globale menyen er plassert øverst er at den er viktig, både for brukeren og for nettstedet. Samtidig som at brukeren er avhengig av å se den for å kunne navigere seg videre på nettstedet, er den med på å beskrive

59 50 Kapittel 5. Utforming nettstedets innhold gjennom merkene og ikonene den inneholder. En god forside bør inneholde sidens identitet og oppgave, altså tydelig vise hva nettstedet handler om [12]. Bannerboks 1 Flere av elementene på prototypens forside er med på å støtte opp under hva nettstedet handler om. Bannerboks 1, markert med nummer 3 i figur 5.4, sin hensikt er nettopp å gi brukeren en forklaring av hva Bypakke Nedre Glomma omfatter. Teksten i bannerboksen er som følger: Transporten i Nedre Glomma vil øke kraftig i årene som kommer. For å håndtere dette må vi bygge ut veinettet, men også sette inn tiltak for å redusere biltrafikken. Det betyr blant annet å legge bedre til rette for gange, sykkel og kollektivtransport. Tiltakene vil gi bedre framkommelighet, øke byenes attraktivitet og bidra til bedre sentrumsmiljøer og bomiljøer. Nøkkelord i bannerboksen er uthevet for å gjøre brukeren nysgjerrig, samt gjøre skumlesing lettere. Under teksten er det en link til mer informasjon om Bypakke-prosjektet. Footer Footeren er plassert nederst på nettstedet, marker med nummer 4 i figur 5.4, da dette er vanlig for dette elementet. Footerens innhold i prototypen er uferdig, typisk informasjon som en footer kan inneholde er blant annet: Kontaktinformasjon. Logo, gjerne med link til forsiden. Link til sosiale medier som Facebook og Twitter. Navigasjon med linker til det som anses som viktig innhold Nettside for kategorien Sykkelvei Klikker man på Sykkelvei i den globale menyen kommer brukeren til en side for prosjekter som kategoriseres som Sykkelvei. Denne siden inneholder i likhet med forsiden en logo, global meny, en footer og en bannerboks med bakgrunnsbilde, dog innholdet i bannerboksen nå er endret. I tillegg inneholder nettsiden for sykkel en lokal meny som navigerer brukeren videre på nettstedet, samt forhåndsvisninger av prosjekter. Plasseringen av elementer som logo, global meny, bannerboks, bakgrunnsbilde og footer henger igjen fra forsiden og er lik på siden for sykkelvei. Siden for sykkelvei er ment som en mal for sidene til Gangvei, Kollektiv og Bilvei, da disse sidene også vil inneholde de samme elementene, men med ulikt innhold. Figur 5.5 viser nettsiden for kategorien Sykkelvei. Bannerboks 2 Bannerboks 2 er markert med tallet 1 i figur 5.5. Bannerboksen minner om den på forsiden, men her er innholdet endret. Bannerboks 2 har en tittel lik menyvalget i den globale menyen og er tenkt at skal inneholde en kortere tekst som skal inspirere brukeren til å lese mer om for eksempel fordeler ved bruk av sykkel. Tilsvarende tekst vil være under Gangvei og Kollektiv, mens under Bilvei vil teksten kanskje inspirere til å la bilen stå, eventuelt samkjøre. Bannerboks 2 vil tidvis skifte innhold, til ny informativ tekst. Små sirkler under teksten vil være klikkbare og fungere som navigasjon for de ulike tekstene som dukker opp i bannerboksen.

60 5.2. Utforming av protoype 51 Figur 5.5: Nettside for kategorien Sykkelvei. Lokal meny Den lokale menyen er markert med tallet 2 i figur 5.5. Den lokale menyen består av tre klikkbare linker som er beskrevet med hhv. Påbegynte Prosjekter, Kommende Prosjekter og Planlagte prosjekter. Påbegynter prosjekter er tenkt at skal inneholde prosjekter som er startet, Kommende prosjekter skal inneholde prosjekter som er vedtatt, men ikke startet. Til sist skal Planlagte prosjekter vise prosjekter som ikke er vedtatt enda. Når brukeren kommer til nettsiden er menyelementet Påbegynte prosjekter aktivert. Det vil si at menyelementets bakgrunnsfarge er endret, og en liten pil er lagt til. Dersom brukeren klikker på et annet element i den lokale menyen, er det dette elementet som får ny bakgrunnsfarge og liten pil. Dette gjør at brukeren enkelt skal se hvilket menyelement som er aktivert. Den lokale menyen skal være utformet og plassert likt for sidene Sykkelvei, Gangvei, Kollektiv og Bilvei. Forhåndsvisning av prosjekt Markert med tallet 3 i figur 5.5 er en boks som skal inneholde informasjon om hvert enkelt prosjekt. Boksen skal inneholde et bilde, en kort og beskrivende tekst. Siden boksen inneholder begrenset

61 52 Kapittel 5. Utforming med informasjon, inneholder den en link til siden for det aktuelle prosjektet som omtales i boksen, med vesentlig mer utfyllende informasjon. Annet Elementer som anses som viktigere enn andre vil plasseres høyere, sentreres og være større enn andre, særlig ved hjelp av størrelsen på overskrifter. Nettstedet har tydelige skiller mellom de ulike elementene på nettstedet. Det skal for eksempel være enkelt å skille den lokale menyen fra resten av innholdet på nettstedet. Alle klikkbare elementer gir en beskjed om at de er klikkbare. Det kan være at når musepekeren er over elementet, så skifter elementet farge, en kantlinje legges til eller musepekeren blir til en pekefinger. Linker og menyvalg er beskrivende og sender brukeren til en side med overskrift lik menyvalget. Farger og utforming og plasseringer er relativt likt uavhengig av hvilken nettside brukeren befinner seg på på nettstedet. 5.3 Iterasjon 1 Den 02.april hadde prosjektgruppen og oppdragsgiver ved Lars Husvik og Tor Stabbetorp et utviklingsmøte med formål om å utvikle og komme med innspill i forhold til prototypen som var under utvikling. I forkant av dette møtet hadde vi utviklet en prototype basert på forundersøkelsene vi hadde gjennomført. Under møtet ble det fokusert på overordnet design og arkitektur. Prosjektgruppen tok opp følgende temaer: Forside Bannerboks 1 Global meny Merkesystemer Titler Innhold Hovedsiden for Sykkelvei Bannerboks 2 Lokal meny Titler Side for visning av prosjekter Kostnader Kommunikasjonsstrategi Forsiden Figur 5.6 viser et bilde av nettstedets forside med enkelte elementer nummerert og markert i rødt.

62 5.3. Iterasjon 1 53 Figur 5.6: Nettstedets forside Bannerboks 1 Bannerboks 1, markert som nummer 1 i bildet 5.6. Markeringen viser en boks midt på bakgrunnsbildet til nettstedets forside. Boksen inneholder generell informasjon om Bypakke Nedre Glomma. Oppdragsgiver gav tilbakemeldinger på at teksten var for lang og burde kortes ned for å gi et tydeligere inntrykk over fordeler med Bypakken. Det kom frem et forslag om å endre teksten til: Tiltakene i Bypakke Nedre Glomma vil gi bedre framkommelighet, øke byenes attraktivitet og bidra til bedre sentrumsmiljøer og bomiljøer. Etter å ha kuttet ned på teksten i bannerboksen, ble resultatet som følger: Figur 5.7: Innhold i bannerboks 1 etter tilbakemelding fra oppdragsgiver. Global meny Den globale menyen består av 6 valg, hvor alle valgene er en kombinasjon beskrivende tekst og tilhørende symbol. Den globale menyen er markert med nummer 2 i figur 5.6.

63 54 Kapittel 5. Utforming Merkesystemer Oppdragsgiver gav tilbakemeldinger på at ikonene prosjektgruppen hadde valgt var passende og at de er med på å gi brukerne et tydelig inntrykk av hva formålet med nettstedet er. Prosjektgruppen fikk tilbakemelding på at ikonene også burde gjøres klikkbare da det kun var linken under ikonene som var klikkbar. Titler Videre kom det frem at titlene som stod under ikonene burde endres fra Sykkelvei, Gangvei og Bilvei til Sykkel, Gang, og Bil. Dette er med på å ha et bredere innhold under disse kategoriene slik at tiltak som F.eks: Trygg trafikk deler ut refleksvester til syklister i Nedre Glomma også vil falle naturlig under Sykkelkategorien. Resultatet av endringen er vist i figur 5.8. Figur 5.8: Global meny etter tilbakemeldinger fra oppdragsgiver Hovedsiden for Sykkelvei Figur 5.9 viser et bilde av nettstedets hovedside for tiltak i kategorien Sykkelvei. Av hensyn til enklere referanse, er enkelte elementer i bildet nummerert og markert i rødt. Bannerboks 2 Bannerboks 2, markert med tallet 1 i figur 5.9, er en boks midt på bakgrunnsbildet til nettstedets hovedside for Sykkelvei. Prosjektgruppen kom frem til at det burde legges til piler på hver side av teksten slik at brukerne lettere kan oppfatte at det er flere slidere. Prosjektgruppen mener at denne boksen kan brukes til forhåndsvisning av tiltak som har blitt publisert. Det kommer også forslag om å lenke til andre relevante nettsteder som F.eks: sykkelplanleggeren.no fra denne boksen. Lokal meny Den lokale menyen under siden Sykkelvei er markert med tallet 2 i figur 5.9. Den lokale menyen inneholder titlene; Påbegynte prosjekter, Kommende prosjekter og Planlagte prosjekter. Sammen med oppdragsgiver diskuterer om det burde benyttes benevnelsen prosjekter eller tiltak og blir enige om at det høres bedre ut med tiltak, da det gir et inntrykk av å være en del av et mål, noe som kan engasjere publikum. Ordet prosjekter kan gi et inntrykk av at tiltakene er enkeltstående, uten et felles mål. Videre burde det legges til et nytt element som kalles Utførte tiltak slik at det kan vises informasjon knyttet til dette. Figurene 5.10 og 5.11 viser den lokale menyen før og etter tilbakemeldinger fra oppdragsgiver.

64 5.3. Iterasjon 1 55 Figur 5.9: Nettstedets hovedside for Sykkelvei Annet I forundersøkelsen kom vi frem til at oppdragsgiver ønsker en generell åpenhet rundt kosnader i forhold til tiltakene som skal utføres. Både med tanke på finansieringsfordeling og kostnader tilknyttet de forskjellige tiltak. Prosjektgruppen finner ut at det kan bli vanskelig å forskuddsbudsjettere de ulike tiltak og kommer frem til at denne informasjonen skal vises først når tiltaket går over til kategorien Utførte tiltak. Kommunikasjonsstrategi Slik prototypen fremvises legges det opp til kommunikasjon med publikum i form av facebook og kontaktskjema som det lenkes til nederst på nettsiden. Det kommer et forslag fra prosjektgruppen på å knytte kommunikasjonen med publikum opp mot de ulike tiltakene. Dette kan gjøres ved at det legges inn en mulighet for å komme med innspill til tiltak der det er interessant for oppdragsgiver. Vi diskuterer i fellesskap om dette kan være en løsning for å engasjere publikum og samtidig legge til rette for at det kommer relevante innspill.

65 56 Kapittel 5. Utforming Figur 5.10: Lokalmeny før tilbakemelding fra oppdragsgiver. Figur 5.11: Lokalmeny etter tilbakemelding fra oppdragsgiver Iterasjon 1 før og etter Fiugrene under viser hvordan prototypen var før vi kom til ØFK og hvordan prototypen ble seende ut etterkant. Forside før: Figur 5.12: Forside før.

66 5.3. Iterasjon 1 57 Forside etter: Figur 5.13: Forside etter.

67 58 Kapittel 5. Utforming Hovedside for sykkel før: Figur 5.14: Hovedside før.

68 5.3. Iterasjon 1 59 Hovedside for sykkel etter: Figur 5.15: Lokalmeny etter tilbakemelding fra oppdragsgiver.

69 60 Kapittel 5. Utforming 5.4 Iterasjon 2 Den 10.april hadde prosjektetgruppen et oppfølgningsmøte med oppdragsgiver Lars Husvik og Tor Stabbetorp etter utviklingsmøte for prototypen. I forkant av dette møte hadde gruppen tatt med seg endringene som det ble enighet om i forrige møte. I dette møtet var formålet å få bekreftelse og tilbakespill på de endringene som var gjort. Deretter å drøfte hvordan nettstedet skal presentere kartet, da med farge-koder og ikoner i kartet. Samtidig få drøfte muligheter for å publisere en kommentar i løsningen under tiltakene. Vi tok opp følgende temaer: Kart Hva som skal vises på kartet (Tiltak, Bomplassering, innfartsparkeringer) Innhold på nettstedet Hva slags informasjon det skal være om tiltakene Hva skal det linkes til fra andre nettsteder Kommunikasjon med publikum Logo Kart Innspill til tiltak mot Kontaktskjema og facebook. Skal innspill publiseres på nettstedet Figur 5.16 viser hva gruppen viste til oppdragsgiver, hvor kartet er markert med rødt. Kartet er hentet fra Google Maps. Figur 5.16: Kartoversikt over tiltak i Nedre Glomma Når brukeren åpner siden vil alle tiltakene vises på kartet i form av ikoner. Ikonene vil ha forskjellige farger avhengig av om det er tiltak som går under kategorien Sykkel, Gang, Kollektiv

70 5.4. Iterasjon 2 61 eller Bil. Til venstre for kartet finner man ikonene som også brukes i den globale menyen. Fargene på disse vil reflektere fargene på markørene i kartet, for å vise hvilken kategori tiltakene hører under. Tanken er at ikonene til venstre for kartet skal være klikkbare og la brukeren skjule uønskede tiltakskategorier. Prosjektgruppen mener at med en slik oversikt er det enkelt og oversiktlig å vise brukerne hvor tiltakene vil finne sted. Oppdragsgiver fortalte at dette var noe de synes var en meget god løsning. Samtidig ble det poengtert at Østfold Fylkeskommune ønsket at ikonene til venstre for kartet, og de tilhørende markørene i kartet, skulle følge deres fargeprofil. Fargen på sykkelikonet burde byttes fra rød til grønn, som er fargen for sykkelbyen i Nedre Glomma regionen. De nye biogassbussene i Nedre Glomma regionen er røde og derfor burde ikonet for kollektiv, som er en buss, også være rødt. Ikonet Gang en vandrende person som bør kunne være blå, siden skiltet for gangfelt er blått. På møtet ble det foreslått at fargen for bil kunne være gul eller sort. Sammen med oppdragsgiver ble det også drøftet å vise innfartsparkeringer i kartet og hvor bomringen skal ligge. I tillegg bør ferje-leiene i Fredrikstad vises på en enkel måte Innhold For at tiltakene skal kunne ha den profilen som appellerer godt til publikum, ble det drøftet om hvordan type informasjon og hvordan den ble skrevet diskutert. Prosjektgruppen ønsker å kunne vise til noen reelle tiltak som kan vises i nettløsningen. Fylkeskommunen forteller at Spikerbukta bru kan benyttes til å utfylle en sak på tiltaksiden. For å kunne fylle den motiverende faktoren som løsningen skal bære preg av vil det på Fredrikstad kommunes hjemmesider (https : // redrikstad.kommune.no/no/t jenester/v ei og traf ikk/sykkelbyen/) finnes motiverende informasjon som gruppen kan benytte seg av. Den informasjonen som blir vist i løsningen kan for eksempel fortelle om helsegevinster og økonomiske gevinster som kommer med å velge å bruke sykkelen. Videre blir det diskutert hvordan nullvekst i biltrafikken skal fremmes noe som er et av målene med løsningen. (Se Mål og visjon). Et forslag som kommer frem er at informasjon om fordeler ved samkjøring for pendlere bør vises på nettstedet, noe som Bannerboks2 kan brukes til under kategorien Bil. Det blir også diskutert om hvordan kostnader rundt tiltakene skal vises til publikum. Vi blir enige om at det passer best å trekke inn slik informasjon når et tiltak har gått over til kategorien: Utførte tiltak under den lokale menyen. Argumenter for dette er at kostnadene rundt et tiltak som F.eks en sykkelvei blir vanskelig å estimere på et tidlig tidspunkt, da det ofte påløper ekstra kostnader underveis. Vi blir da enige om at det er mest hensiktsmessig å vise kostnader når tiltaket er fullført Kommunikasjon med publikum På bakgrunn av diskusjon med oppdragsgiver under iterasjon 1 la gruppen til en 2 veis kommunikasjon med publikum. Dette ble gjort i form av en funksjon hvor det er mulig for publikum å komme med innspill rettet mot tiltakene. Innspill fra publikum ønskes på kategoriene: Påbegynte tiltak, kommende tiltak og tiltak under planlegging. Når tiltaket er gått over til utførte tiltak vil det ikke lengere være mulig å komme med innspill. Funksjonen innspill til tiltak legges til den lokale menyen som er knyttet til tiltakene. For å skape engasjement hos publikum la gruppen til tittelen: Har du innspill til dette tiltaket? Når brukeren trykker på denne knappen vises de innspill som er publisert på nettstedet. I tillegg er det et skjema med overskriften: Registrer ditt innspill her. Dette skal oppfordre brukeren til å sende inn sin egen mening om tiltaket. Slik prototypen viser på dette tidspunkt er det slik at alle innspill

71 62 Kapittel 5. Utforming Figur 5.17: Publikums innspill til tiltak som sendes inn skal vises på nettstedet. Under skjemaet står det: * Ved å sende inn ditt innspill samtykker du til at ditt navn blir publisert på dette nettstedet. Vi diskuterer fordeler og ulemper med dette og kommer frem til at for å få med alle innspill fra publikum skal det heller legges opp til at brukeren får to valg: 1. Publiser mitt innspill på nettstedet. 2. Ikke publiser mitt innspill på nettstedet, sendes kun til administrasjonen. I tillegg snakker vi om at det bør være villkår for bruk av denne funksjonen. Villkårene bør opplyse brukeren om personvernregler og regler for innsending av innspill. Figur 5.18 viser utforming før møte med oppdragsgiver, mens?? viser utformingen etter tilbakemeldinger.

72 5.4. Iterasjon 2 63 Figur 5.18: Innsending av innspill til tiltak, versjon 1.

73 64 Kapittel 5. Utforming Figur 5.19: Innsending av innspill til tiltak, versjon Logo Oppdragsgiver ønsket seg en logo som skaper en tydelig identitet for nettstedet. Oppdragsgiver opplyser om at de har en aktuell logo som brukes til noe annet i dag, og den må gjøres endringer på om den skal brukes for nettsiden: Bypakke Nedre Glomma. Prosjektgruppen får tilsendt en fil med logoen slik den er i dag og tilpasser den til nettstedes formål. Figur 5.20 viser den tilsendte logoen, mens resultatet vises i figur 5.21.

74 5.5. Iterasjon 3 65 Figur 5.20: Logo fra oppdragsgiver. Figur 5.21: Logo etter behandling av prosjektgruppen. 5.5 Iterasjon 3 Den hadde prosjektgruppen et siste utviklingsmøte for å diskutere noen siste elementer på prototypen før vi skulle foreta brukertestene. Under dette møtet tok vi opp følgende temaer: Bannerbokser og innhold i disse. Tiltakene vi har lagt inn i prototypen Bannerbokser På nettstedet er det lagt inn bannerbokser under sidene for kategoriene sykkel, gange, kollektiv og bil. Prosjektgruppen legger frem for oppdragsgiver at bannerboksene er tiltenkt innhold som har med motivasjon til holdningsendring, noe oppdragsgiver er meget positiv til. Hver bannerboks består av 5 slides som bytter automatisk hvert 4 sekund. Hovedformålet er å fylle innholdet i bannerboksene med en kort informativ tekst som avsluttes med en lenke. Innholdet kan være både internt og eksternt. Dvs. lenker som lenker i (inbound links) og utenfor nettstedet (Outbound links). Videre snakker vi om hva slags innhold som er nyttig å ha med på dette stadiet og vi kommer frem til å prosjektgruppen skal legge inn noen eksempler for å sjekke responsen på dette under brukertesten.

75 66 Kapittel 5. Utforming Figur 5.22: Bannerboks Kollektiv med introduksjonstekst, slide 1. Figur 5.23: Bannerboks Kollektiv med lenke til kampanje hos Østfold kollektivtrafikk, slide 2.

76 5.5. Iterasjon 3 67 Figur 5.24: Bannerboks Sykkel med lenke til reisevaneundersøkelse hos TØI, slide 4. Figur 5.25: Bannerboks Sykkel med lenke til sykkelplanlegger, slide Tiltak som er lagt inn i løsningen Prosjektgruppen har siden siste utviklingsmøte lagt inn noen eksempler på tiltak inn i løsningen. Vi fikk tilsendt en liste med en oversikt over samferdslesrelaterte tiltak og prosjekter som er i Nedre Glomma regionen. Under arbeidet med dette har vi merket oss at mange av tiltakene som er på denne listen er veldig store prosjekter som kan falle inn under flere enn én kategori. Et eksempel på dette er: FV 109 Alvim -Torsbekkdalen. Dette er et omfattende prosjekt som kan settes under flere kategorier da det har planer for utbedring av bilvei, kollektivfelt, sykkel og gangvei. Vi dikuterer hvordan denne problematikken kan løses og vi kommer til enighet om at det vil være hensiktsmessig å dele slike store tiltak inn i flere små, for å få frem nytteverdien av hvert enkelt tiltak under de ulike kategoriene. Bildet under viser tiltak under planlegging for kategorien bil.

77 68 Kapittel 5. Utforming Figur 5.26: Forhåndvisning av tiltak under planlegging. Kategori Bil.

78 5.6. Merketabell, metadata og sitemap Merketabell, metadata og sitemap Tabell 5.1 illustrerer bruk av merker og tilhørende ikoner i prototypen. Tabellen viser at bruken av merker er konsistent ved at de finnes i overskrifter og i destinasjonens title merker. Ikonene reflekterer merkene, som er med på å beskrive menyelementets destinasjon. Merke Ikon Destinasjons overskriftmerke Destinasjons title merke Sykkel Sykkel Sykkel - Bypakke Nedre Glomma Gange Gange Gange - Bypakke Nedre Glomma Kollektiv Kollektiv Kollektiv - Bypakke Nedre Glomma Bil Bil Bil - Bypakke Nedre Glomma Kart (Ingen) Kart - Bypakke Nedre Glomma Om Om Om Bypakke Nedre Glomma Søk (Ingen) (Ingen) Tabell 5.1: Oversikt over merker i den globale menyen Alle begrepene i den globale menyen kan beskrives med varianter av begrepene. Variantene kan være for vide, for avgrensende, relatert men ikke dekkende eller kun en omformulering. Figur 5.27 viser enkel thesauri for menyelementet Bil.

79 70 Kapittel 5. Utforming Figur 5.27: Enkel thesauri for begrepet Bil. Metadata er data som brukes for å beskrive annen data. I HTML brukes metadata for å beskrive innhold. Metadata gjør at dokumenter med få ord blir søkbare. Metadata som legges inn i html dokumentets metatag vises ikke på nettsiden, men er tilgjengelige for bruk av søkemotorer. Det er ønskelig at brukere som bruker begrepet Bilvei under nettsøk, blir henvist til vårt nettsted. Derfor bør begrepet Bilvei implementeres som metadata i HTML dokumentene på nettstedet. Metadata er også viktig for søking internt på nettstedet. Begreper som er varianter av nøkkelbegreper på nettstedet bør tas hensyn til under sammensetningen av metadata-fraser. Nettsiden for Kart inneholder få ord og det kan derfor være vanskelig for søkemotorer å forstå innholdet på nettsiden, derfor er det spesielt viktig å implementere metadata for dette dokumentet. Under følger et kode-eksempel på implementering av metadata i HTML-dokumentet for Kart. <head> <meta name="title" content="kart"> <meta name="description" content="kart med oversikt over alle tiltak i Bypakke Nedre Glomma"> <meta name="keywords" content= "Kart, Bypakke Nedre Glomma, Tiltak, Prosjekter, Sykkel, Bil, Kollektiv, Gange, Sykkelvei, Sykkelsti, Bilvei, Kollektivfelt, Gangvei"> </head> Metadata i HTML dokumenter legges også inn som beskrivelser av menyer, linker og bilder for å blant annet fortelle brukeren hva som skjer dersom brukeren klikker på et element, linker eller for å forklare innholdet i et bilde. Alle elementer på et nettsted kan tilføyes en title-tag. Effekten av title-taggen kan diskuteres. Et viktig poeng er at brukere av mobil og nettbrett ikke kan se tilleggsinformasjonen som title-taggen tilbyr, da den vises ved mouse over, altså nå musepekeren er plassert over det aktuelle elementet. Søkemotorer har, i motsetning til brukere av mobile enheter uten mus, tilgang til alle title-taggene i et HTML dokument. God bruk av nøkkelbegreper, blant annet i title-tagger, kan øke nettstedets treffrate hos eksterne søkemotorer, avhengig av søkemotorens søkealgoritme.

80 5.7. Oppfylling av suksesskriterier i WCAG Bilder på nettsteder er lurt å beskrive med ord. Dersom bildet bruker lang tid på å lastes inn, eller bildet ikke lastes inn i det heletatt, bør det stå noen beskrivende ord som forklarer bildets innhold. Dette gjør også at en kan søke etter bilder, ved bruk av ord. Begreper som går igjen i flere av nettstedets nettsider er også metadata. Begrepene er med på å beskrive hovedinnholdet og essensen ved nettstedet. Dette inkluderer all tekst på nettstedet, blant annet menyer, linker og tekst i artikler og innlegg. Med bakgrunn i kategoriseringen av begreper i samarbeid med oppdragsgiver, har gruppen laget et sitemap som illustrerer nettstedets arkitektur.5.28 Figur 5.28: Sitemap for nettstedet 5.7 Oppfylling av suksesskriterier i WCAG 2.0 Kapittelet setter nettstedet opp mot alle retningslinjer som trengs for å oppnå minimumskravet for universell utforming (nivå A). Kapittelet følger strukturen illustrert i figur 5.29.

81 72 Kapittel 5. Utforming Figur 5.29: Tabell over oppbyggningen av WCAG Prinsipp 1, Mulig å oppfatte Kapittelet tar for seg alle retningslinjer som må følges for å oppnå prinsipp 1; Mulig å oppfatte. Retningslinje 1.1, Tekstalternativer Retningslinjen sørger for å gi tekstalternativer til alt ikke-tekstlig innhold Ikke-tekstlig innhold - nivå A Vi sørger for at ikke-tekstlig innhold på nettsiden i dette tilfellet bilder har en tekstforklaring med samme formål. Et eksempel på dette er bildet som blir benyttet for forhåndsvisning av tiltakene: For å følge anbefalinger fra difi ang. universell utforming blir det i dette tilfellet nødvendig å benytte alt-tekst som beskriver bildets motiv. I dette tilfellet benyttes alt-teksten: Byggestart for sykkelfelt langs RV109, Ferdig høsten Dette kan ses på som et supplement til teksten under da bildet er en del av artikkelen.

82 5.7. Oppfylling av suksesskriterier i WCAG Figur 5.30: Forhåndsvisning av tiltak Retningslinje 1.2, Alternativer for tidsbaserte medier Krav Bare lyd og bare video(forhåndsinnspilt) og krav Teksting (forhåndsinnspilt) er ikke relevante for prototypen da den ikke inneholder tidsbaserte medier, slik som videoer og animasjoner. Retningslinje 1.3, Innhold kan tilpasses Retningslinjen sørger for at innhold kan presenteres på forskjellige måter, uten at informasjon og struktur går tapt Informasjon og relasjoner Nettstedets informasjon, struktur og relasjoner er tilgjengelig som tekst i form av nettstedets html dokumenter. Nettstedet dekker kravet ved at det gjennomgående følger god html-struktur med korrekt bruk av HTML5 tagger. Presentasjon er skilt fra utseendet ved at utseendet er stylet av et separat css-dokument, noe som gir brukerne mulighet for å endre presentasjonen etter eget behov. Tekst og struktur På nettstedet er det benyttet elementet < h1 > for hovedinnholdets titler. Eksempel på dette er: <h1>sykkel</h1>. Dette forteller at brukeren har kommet til siden som inneholder informasjon som har med sykkel å gjøre. Vi plasserer alle titteloverskriftene vi benytter elementet <h1> til, øverst på siden slik at det blir visuelt informativt for brukerne hvor de har kommet. I tillegg til å bruke en fontstørrelse som skiller seg ut har vi trukket inn relevante ikoner som vi bruker gjennom hele nettstedet, figur 5.31 viser et eksempel på dette.

83 74 Kapittel 5. Utforming Figur 5.31: Hovedtittel.Side for Sykkel På startsiden bruker vi elementet <h1> til logoen. Denne formidler til brukeren hvilken virksomhet de har kommet til. Dette er gunstig både for brukere som benytter hjelpemidler og for søkemotoroptimalisering.et eksempel på dette er: <h1 class = "logo"><a href="index.html">bypakke Nedre Glomma</a></h1>. Det blir benyttet en struktur hvor rekkefølgen på de ulike <h1> - <h5> elementene er satt sammen på en hierarkisk måte. Et eksempel på dette er: <h1>hovedtittel</h1> <p>tekst tekst</p> <h2>undertittel</h2> <p>tekst tekst</p> <h3>under_undertittel</h3> <p>tekst tekst</p> På nettstedet benyttes elementet <p> for brødtekst. For optimal universell utforming er det anbefalt å unngå elementene <div>, <span>, <br>, <hr> for å skape avsnitt i teksten. Skille innhold og presentasjon Nettstedet blir kodet ved hjelp av HTML5, CSS3 og JavaScript noe som sørger for et skille mellom informasjon og utforming. Videre blir det lagt opp til en struktur som gjør at det blir funksjonelt å benytte tastatur for å navigere på nettstedet. Helhetlig utforming Gjentagende objekter, som menyer, søkefelt, språkvalg og lignende er konsekvent plassert på nettstedet. Forstørring Nettstedet skal fungere med en tekstforstørring opp til 200 % av ordinær størrelse uten tap av innhold eller funksjonalitet. Minstekravet for forstørring er 200 % i følge difis WCAG 2.0 krav. Prototypen fungerer med en tekstforstøring på opp til 400%. Figur 5.32, 5.33 viser den lokale menyen i en tekststørrelse på hhv. 100%, 200%: Figur 5.32: Lokal meny, tekststørrelse 100% Meningsfylt rekkefølge Suksesskriteriet sørger for god bruk av navigasjon og rekkefølge av innhold.

84 5.7. Oppfylling av suksesskriterier i WCAG Figur 5.33: Lokal meny, tekststørrelse 200% Figur 5.34: Lokal meny, tekststørrelse 400% Alternative navigasjonsmetoder For å gi brukerne tilgang til ulike navigasjonsmetoder har vi i tillegg til global og lokale menyer også disse elemenetene: Søk på nettstedet. Dette er plassert godt synlig som en del av den globale menyen, øverst til høyre. Nettstedskart som presenterer sidene ut fra deres plassering i menystrukturen. Link til nettstedskartet er plassert under tittelen Innhold som er en del av elementet footer, denne er global. Konsekvent navigering Konsekvent plassering og forutsigbarhet er viktig for god brukervennlighet. Global meny For å følge en konsekvent navigering og et forutsigbart grensesnitt på nettstedet har vi valgt å plasserere den globale menyen øverst til høyre på siden. Titlene på navigasjonen står også i samsvar med titlene på siden brukeren kommer til etter å ha foretatt et valg. I tillegg til å ha tydelige titler har vi relevante ikoner som gjenspeiler innholdet på siden man kommer til. Lokal meny Den lokale menyen er plassert under tittelen på siden den gjelder for. Den går igjen på alle sidene, men valgene man kan foreta på den er forskjellig avhengig av hvor på nettstedet man befinner seg.

85 76 Kapittel 5. Utforming Sensoriske egenskaper Nettstedet har et skjema hvor brukere kan komme med innspill til enkelttiltak. For å støtte brukerens utfylling av skjemaet er element i skjemaet beskrevet med title attributtet i HTML5. Elementene i skjemaet inneholder også en tekst, som beskriver hva som skal fylles inn i det aktuelle elementet. Skjemaet følger kravet om å gi feilmelding ved mangelfull utfylling og viser brukeren hvilket felt som må fylles ut. Figur 5.35: Innspillskjema til tiltak Koden som genererer skjemaet forteller også at feltet for epost er obligatorisk å fylle ut, ved bruk av required attributted. Videre følger et eksempel på kode for e-post feltet: <input type="text" maxlength="50" name=" " size="19" placeholder="epost" required="required" title="epost"> Retningslinje 1.4, Innhold er identifiserbar Retningslinjen sørger for at det er enklere å se og høre innhold Bruk av farge Der hvor farge er brukt for å formidle funksjonalitet, slik som i linker, er det supplert med andre

86 5.7. Oppfylling av suksesskriterier i WCAG metoder for at brukeren skal forstå at det er klikkbart. Derfor er linker, i tillegg til å være lilla, også markert med en linje under teksten når musepekeren føres over Styring av lyd Prototypen inneholder ingen form av lyder så dette kravet er utelukket Kontrast Tabell 5.2 viser fargebruken på nettstedet og kontrastforholdet mellom nærliggende farger. Samtlige kontrastforhold følger standarden for WCAG 2.0 nivå AA eller høyere. Ved fargevalg brukte gruppen nettstedet http : // c ontrast/colour.html for å finne kontrastforhold mellom farger. Fargekode Farge Bakgrunnsfargekode Farge Kontrastforhold WCAG 2.0 #8E44AD #FFFFFF 5.87 AA # #FFFFFF 4.7 AA # #FFFFFF 7.94 AA + AAA # #f0f3f AA + AAA Tabell 5.2: Oversikt over farger og kontrastforhold Endring av tekststørrelse Kravet er dekket under punkt Informasjon og relasjoner Bilder av tekst Kravet er ikke relevant for prototypen da den ikke inneholder bilder av tekst, kun i nettstedets logo, som er et unntak Prinsipp 2, Mulig å betjene Kapittelet tar for seg alle retningslinjer som må følges for å oppnå prinsipp 2; Mulig å tjene. 2.1 Tastaturnavigering Retningslinjen sørger for at all funksjonalitet er tilgjengelig med tastatur Tastatur I følge krav må all funksjonalitet på nettstedet må være mulig å benytte ved hjelp av tastatur alene, og med tastatur sammen med hjelpemiddel. Nettstedet vi har laget følger dette prinsippet. Brukeren kan enkelt navigere på netttstedet ved å benytte tab-tasten som. Siden nettstedet vi har laget følger en logisk struktur når det kommer til oppbygging av kildekoden, blir det ikke nødvendig å benytte tab-index, da tab-rekkefølgen gir mening for brukeren.

87 78 Kapittel 5. Utforming Ingen tastaturfelle Hvis det er behov for noe annet enn standard pil- eller tabulatortaster eller andre standardmetoder for navigering, må brukeren få informasjon om hvilken metode som må benyttes for å flytte fokus. Dette punktet er ikke relvant for prototypen vi har laget fordi. Retningslinje 2.2, Nok tid Retningslinjen sørger for å gi brukeren nok tid til å lese innhold Justerbar hastighet Nettstedet innholder en tidsbegrenset slider på kategoriene; Sykkel, Gange, Kollektiv og Bil, som skifter innhold hvert 5 sekund. Slideren er mulig å stoppe ved å holde muspekkeren inne i slideren. Det gjør at nettstedet dekker krav med justering av hastighet (se. analyse 2.2.1) Pause, stop, skjul Alle bevegelser, rulling og automatisk oppdatering av informasjon har en mekanisme som gjør det mulig og slå den av. Det gjøres ved å føre musepekeren over elementet. Derfor oppfyller nettstedet kravet (se. analyse 2.2.2). Retningslinje 2.3, Unngå anfall Retningslinjen sørger for at det ikke utformes innhold på en måte som kan forårsake anfall Terskelverdi på maksimalt tre glimt Nettstedet har ikke innhold som glimter mer enn tre ganger i løpet av ett sekund, og oppfyller derfor kravet. Retningslinje 2.4, Navigerbar Retningslinjen sørger for at brukere kan navigere, finne innhold oh vite hvor de befinner seg Hoppe over blokker Kravet, som er beskrevet i (kap analyse-wcag-krav-241 hoppe over blokker XXX), dekkes ved å implementere en link til hovedinnholdet på siden som kun er synlig ved tastaturfokus. Figur X viser et eksempel, hentet fra nettstedet til difi(kilde dit), på implementeringen Sidetitler Nettstedet inneholder sidetitler som blir presentert konsekvent. Brukeren får presenter tittelen på den aktuelle siden, samtidig vises tittelen i fanen på alle støttende nettlesere. Derfor dekker nettstedet kravet Fokusrekkefølge Nettstedets navigering følger ingen navigering sekvens. Det vil si at brukerne ikke må følge et visst navigasjonsmønster for å finne frem på nettstedet. Dette gjør at krav er utelukket for nettstedet.

88 5.7. Oppfylling av suksesskriterier i WCAG Formål med lenke (i kontekst) Formålet med lenken kommer tydelig fram av lenketeksten. Et eksempel er lenken Sykkelplanleggeren som tar brukeren til en sykkelplanlegger Flere måter På nettstedet finnes det alternative måter å komme frem til en bestemt webside. Brukerne kan enten ved hjelp av menyer finne frem til bestemte sider eller benytte seg av søkefunksjonen. Det gjør at krav er dekket med at det er flere enn én måte å finne frem til en nettside Overskrifter og ledetekster Nettstedet dekker kravet ved at overskrifter og ledetekster beskriver emne og formål Synlig fokus Nettstedet oppfyller kravet ved at det fokusindikatoren til tastaturet er tydelig, illustrert i figur X Prinsipp 3, Forståelig Kapittelet tar for seg alle retningslinjer som må følges for å oppnå prinsipp 3; Forståelig. Retningslinje 3.1, Leselig og forståelig Retningslinjen sørger for at innhold er leselig og forståelig Språk på siden Standard naturlig språk på websiden kan bestemmes programmeringsmessig Språk på deler av innhold Kravet er ikke relevant for prototypen. Retningslinje 3.2, Forutsigbarhet Kravet sier at man skal sørge for at websidene presenteres og fungerer på forutsigbare måter. Dette dekkes på nettstedet ved at elementer går igjen på sidene. Eksempler på dette er: header, footer, global og lokal meny og titler Fokus Når en komponent kommer i fokus, medfører det ikke kontekstendring, noe som er dekket av kravet Inndata Nettstedets inndata medfører ingen automatisk kontekstendring. Kravet er derfor dekket Konsekvent navigering Navigeringsmekanismer som gjentas på flere websider innenfor et sett av websider, opptrer i samme relative rekkefølge hver gang de gjentas, med mindre brukeren selv foretar en endring. Dette er dekket ved at det er en global meny som følger alle nettsidene med konsekvent rekkefølge.

89 80 Kapittel 5. Utforming Konsekvent identifikasjon Komponenter som har samme funksjonalitet innenfor en samling av websider, identifiseres på en konsekvent måte. Eksempler på dette er hovedoverskriften på nettsidene som består av lik fontstørrelse, farge og plassering. Retningslinje 3.3, Unngå og rette opp feil Retningslinjen sørger for å hjelpe brukere med å unngå feil og å eventuelt rette opp i feil Identifikasjon av feil Dekkes av krav Sensoriske egenskaper Ledetekster eller instruksjoner Kravet dekkes ved at elementene i skjemaet inneholder en tekst som beskriver hva som skal fylles inn i det aktuelle elementet Forslag ved feil Dekkes av krav Sensoriske egenskaper Forhindring av feil (juridiske feil, økonomiske feil, datafeil) Nettstedet består ikke av juridiske forpliktelser eller krever økonomiske transaksjoner fra brukerne. Kravet er derfor ikke relevant for nettstedet Prinsipp 4, Robust Kapittelet tar for seg alle retningslinjer som må følges for å oppnå prinsipp 4; Robust. 4.1 Kompatibilitet Retningslinjen sørger for god kompatibilitet med kompenserende teknologi Parsing (Oppdeling) Kravet er at innhold som implementeres ved hjelp av oppmerkingsspråk, har elementene fullstendige start- og sluttkoder, elementene er nøstet i henhold til spesifikasjonene, elementene inneholder ikke dupliserte attributter, og eventuelle ID-er er unike. Dette er dekket ved at vi konsekvent har benyttet html5 elementer og IDer og klasser der det er hensiktsmessig. Elementer som header, nav, footer blir kun benyttet èn gang pr. side for å følge en semantisk oppbygning. Videre er det benyttet klasser for elementer som brukes flere ganger og ID på unike elementer Navn, rolle og verdi Kravet er ikke relevant for prototypen. 5.8 Utførelse av responsiv design Et viktig poeng med nettløsningen er at den skal være tilgjengelig for alle medier. Prosjektgruppen mener at det er mest hensiktsmessig å legge opp til et responsivt design (se kapittel 2.10) kontra det å lage forskjellige versjoner av nettstedet. Hovedfordelen med responsivt design er at det medfører mindre vedlikehold og oppdateringer enn det å ha flere versjoner av nettstedet. Det er også en

90 5.8. Utførelse av responsiv design 81 kostnadseffektiv måte å sørge for tilgjengelighet på alle medier, da det medfører lavere kostnader knyttet til utvikling og administrasjon av innhold. For å legge til rette for et responsivt design er det nødvendig å ta høyde for dette fra starten av utviklingsprosessen ved å benytte seg av flytende elementer på nettstedet. Et annet viktig poeng er å benytte seg av % fremfor px når man definerer størrelsen på elementer. Et eksempel på dette er headeren på nettstedet som settes til 100%, noe som vil sørge for at denne alltid tilpasser seg bredden av skjermen. Det er ikke alle elementer hvor størrelsen er definert i %. Elementer som er avhengig av å ha en fast størrelse defineres i px og vi lar de flyte ved å bruke: float:left; eller float:right;. For å lage et responsivt design benytter vi oss av CSS media-queries. Før vi går i gang med utførelsen av media-queries må vi fastsette ulike breaking-points. Breaking-points er en grense hvor skjermstørrelsen til brukeren er måleenhet. På nettstedet her vi gått ut i fra følgende breaking-points: PC/MAC: 1024px > Nettbrett: 640px > 1080px Mobiltelefon: > 640px Figur 5.36: Nettstedet fra ulike enheter Under følger noen eksempler på hvordan implementeringen av responsiv design fungerer i praksis Global meny Den globale menyen på nettstedet ligger plassert øverst til høyre på skjermen. Denne er flytende slik at menyelementene drar seg mot venstre og tilpasser plasseringen etter skjermstørrelsen til

91 82 Kapittel 5. Utforming brukeren. Når skjermstørrelsen minsker og det ikke lengre er plass til menyelementene vil de erstattes med et menyikon (se figur 5.39). Når brukeren klikker på menyikonet vil menyvalgene dukke opp under som vist i figur Figur 5.37: Header og navigasjon. 1366px. PC/MAC Figur 5.38: Header og navigasjon. 1024px. Nettbrett Figur 5.39: Header og navigasjon. 640px. Mobil

92 5.8. Utførelse av responsiv design 83 Figur 5.40: Header og navigasjon. 640px. Mobil. Brukeren har klikket på menyikonet og menyvalgene er synlig Lokal meny Hvert av valgene i lokalmenyen tar 25% av skjermbredden ved mediene PC/MAC og nettbrett. På mediet mobiltelefon velger vi å sette valgene til 50% av skjermbredden slik at elementene kommer tydelig frem. I tillegg fjerner vi pilene som peker nedover. Figur 5.41 og 5.42 viser valgene i 25% størrelse. Figur 5.43 viser mobilversjon med valgene i 50% størrelse. Figur 5.41: Lokal meny, 1366px. PC/MAC. Figur 5.42: Lokal meny, 1024px. Nettbrett.

93 84 Kapittel 5. Utforming Figur 5.43: Lokal meny, 640px. Mobil Forhåndsvisning av tiltak Forhåndsvisningen av tiltak er plassert 3 i bredden under visningen for PC/MAC. For nettbrett setter vi de til 2 i bredden og for mobiltelefon settes de til 1 i bredden Footer Informasjonen i footeren står plassert 3 i bredden under visningen for PC/MAC. For nettbrett setter vi de til 2 i bredden og for mobiltelefon settes de til 1 i bredden.

94 Kapittel 6 Diskusjon Prosjektgruppen har valgt å dele diskusjonen opp i fire underkapitler. 6.1 Brukertest, 6.2 Nettstedets mål, 6.3 Utforming og 6.4 Videre arbeid. I kap 6.1 Brukertest, drøftes resultatene prosjektgruppen fikk av brukertestene som ble gjennomført. I kap 6.2 Nettstedets mål, drøftes nettstedets mål, innhold og kommunikasjonstrategi. Kapittel 6.3 Utforming diskuterer valg prosjektgruppen har gjort i forhold til universell utforming og responsiv design. I kap 6.4 Videre arbeid, diskuteres elementer på nettstedet som ikke er ferdigutviklet. 6.1 Brukertest Det vi fikk ut av testen at nettstedet var at navigasjonen på nettstedet var brukervennlig, ikonene var tydelige og oversiktlige. Alle testpersonene fortalte at de opplevde nettstedet som enkelt og oversiktlig å navigere på. Det kom også fram at noen forbedringer kunne ha vært gjort med tilrettelegging for tilgjenglighet. På bakgrunn av brukertesten mener prosjektgruppen at utforming og plassering av den globale og den lokale menyen er god. Dette fordi samtlige testpersoner fant menyene raskt, og forstod at det var mulig å klikke på de ulike elementene. Enkelte forstod ikke betydningen av enkelte begreper i den lokale menyen; påbegynte-, kommende-, planlagt- eller utført-tiltak. Gruppen tolker dette som at begrepene i lokalmenyen kan være noe uklare og ikke forteller hvor brukerne hvor de ville komme. En ny test med hovedfokus på lokalmenyen kan være et alternativ for videre arbeid. Prosjektgruppen merker seg også at dette kan ha noe med brukernes manglende forståelse av hva Bypakke Nedre Glomma er. Prosjektgruppen hadde ikke regnet med at noen hadde hørt om bypakke prosjektet, siden det per dags dato ikke er lansert eller promotert. Prosjektgruppen mener det er behov for en kampanje for å bevisstgjøre målgruppen om Bypakke Nedre Glomma. En av testpersonene greide ikke å navigere seg tilbake til forsiden, uten å bruke nettleserens tilbakeknapp. Det var ikke åpenbart for testpersonen at nettstedets logo var klikkbar. Derfor kan det være lurt å tilby et alternativ i den globale menyen som tar brukeren tilbake til forsiden. Et slikt menyvalg kan kalles Hjem, og ha et lite hus som tilhørende ikon, da dette er typisk også for andre nettsteder. Ved spørsmål om hva budskapet til nettløsningen var, fikk gruppen flere svar som dekket nettstedets mål. Det kan tolkes slik at nettløsningen har oppnåd sitt mål med å få frem budskapet til Bypakke Nedre Glomma. Nettstedets design gir brukeren god oversikt og strukturen kommer tydelig frem for testpersonene. Klikkbare elementer kommer tydelig frem ved god plassering og bruk av farger, noe som kan bekreftes ved at vi observerte lite feilklikk og at oppgavene ble løst på en rask og effektiv 85

95 86 Kapittel 6. Diskusjon måte. Testobjekt 5 oppdaget under brukertesten at det manglet alternativ tekst på enkelte bilder. Etter brukertesten sørget gruppen for at alle bilder hadde en alternativ tekst i form av <alt>-tag. At nettstedet opplevdes som tilfredstillende og ikke bøy store på vanskeligheter for testobjekt 5, kan være på grunn av at nettstedet bruker adekvat HTML5 syntaks på alle av nettstedets elementer. Alle testpersonene var positive til nettstedet, ingen bemerket seg noe konkret negativt på nettstedet. Vi kan tyde det på to måter: at vi har laget et godt nettsted, eller at vi ikke testet nettstedet tilstrekkelig. 6.2 Nettstedets mål Etter gjennomføringen av intervjuene kom det frem at det var delte meninger blant oppdragsgiverene om hva nettstedets hovedbudskap burde være. En av oppdragsgiverene så for seg at nettstedet hovedsaklig skulle dekke behovet om å gi befolkningen i Nedre Glomma regionen informasjon om tiltakene i Bypakke Nedre Glomma prosjektet. En annen representant av oppdragsgiver så for seg et motiverende budskap og holdningsendring som nettstedets hovedbudskap. Oppdragsgiverene var ikke helt enige om målet med nettstedet, og det virket som om idéen om et nettsted ikke var helt konkret og var preget av at hele bypakke prosjektet ikke er vedtatt. Det kommer tidlig frem i intervjuperioden, se kapittel 4, Intervju av Tor Stabbetorp, at oppdragsgiver ser for seg en samleside hvor brukeren velger seg frem til ønsket informasjon om sykkel, kollektiv, areal og byutvikling Delmål 1: Motivasjon og Holdningsendring Oppdragsgiver hadde ikke et klart konsept for hvordan de gjennom nettstedet skulle motivere beboerne i Nedre Glomma regionen til å velge alternative reisemåter. Hvordan holdningsendring skulle komme fram gjennom nettstedet, var det derfor opp til prosjektgruppen å komme frem til. Det kom fram av intervjuene med oppdragsgiver at de ønsket å endre innbyggerenes reisevaner, og at dette blant annet ville skje gjennom etablering av bomring rundt Nedre Glomma regionen, tilrettelegging for syklister og gående, samt bedret kollektivtilbud. Prosjektgruppen mener at det er vanskelig fra et webutviklers ståsted å endre målgruppens holdning til transport gjennom utviklingen av arkitekturen for et nettsted. Nettstedet som prosjektgruppen har utviklet legger rammer for hvordan informasjon skal presenteres, men avgjør ikke innholdet i artiklene. For at nettstedet skal bidra til en positiv holdning til alternativ transport, mener prosjektgruppen at det bør være innholdet i artiklene som motiverer målgruppen. Tiltakene i seg selv må være motiverende og være med på å endre holdning hos målgruppen. Under intervjuene i forundesøkelsen kom det fram at det muligens må ansettes en kommunikasjonsansvarlig som jobber dedikert med innholdet på nettstedet. Innholdet i løsningen blir det derfor kommunikasjon samsvar log i ØFK sin jobb å utforme, som vil være å legge inn informerende og motiverende innhold som kan skape engasement hos leserne. Prototypen er kun et rammeverk, derfor har ikke prosjektgruppen lagt stort fokus på innholdet i tekster på nettstedet, men derimot hvordan tekstene kan presenteres i form av struktur, tekst-størrelse, fonter, faktabokser, linker og bannerboks, se kapittel 5 Utforming Delmål 2: Informasjonkanal Bypakke Nedre Glomma er et omfattende prosjekt som består av flere store tiltak som skal bedre samferdselen i Nedre Glomma regionen, med et mål om null-vekst i personbiltrafikken innen

96 6.2. Nettstedets mål 87 utgangen av Nettstedet er et ledd i kommunkasjonsstrategien for samarbeidsavtalen, og skal blant annet brukes for å informere målgruppen om Bypakke Nedre Glomma og prosjektene i bypakken. Presentasjon av tiltak Tidlig i prosjektet ble vi oppmerksomme på at begrepet prosjekter var for lite dekkende med tanke på hva nettstedet skal inneholde. Etter å ha diskutert i gruppen, tok vi dette opp med oppdragsgiver under et av møtene vi gjennomførte i oppstartfasen. I fellesskap kom vi frem til at begrepet tiltak gir en større omfang enn prosjekter. Begrunnelsen for dette er at et prosjekt er noe konkret og enestående, men tiltak gir en mer følelse av å være en del av noe mer omfattende. Det finnes allerede en del vedtatte tiltak som kan knyttes til Nedre Glomma regionen. Et eksempel på dette er tiltaket: RV109 Alvim - Torsbekkdalen. Dette er et stort tiltak som går over mange år med mange delprosjekter innen kategoriene: Sykkel, kollektiv, gange og bil. Informasjonen som allerede er tilgjengelig om dette tiltaket går ikke inn på alle delprosjektene som dette omfatter, men er mer generell. Prosjektgruppen mener det vil være mer hensiktsmessig å presentere de ulike delprosjektene for målgruppen, noe som kan være med på å tydeliggjøre nytteverdien av alle tiltakene dette omfatter. Videre mener vi at ved å dele opp tiltak på denne måten, kan det være med på å gi brukerne tilrettelagt informasjon om de temaene som engasjerer de. Ved å dele opp tiltakene på denne måten vil det også bli mer innhold på nettstedet, noe som kan gi en bedre brukeropplevelse på nettstedet. Gruppen presenterte denne ideen under utviklingsmøtene, noe som oppdragsgivere støttet. Noe vi også har diskutert med oppdragsgiver er at det i tillegg skal linkes til eksterne sider som inneholder informasjon og tjenester av relevant art. I prototypen har vi satt av plass til dette formålet to steder. Det ene i bannerboksen og i footeren under eksterne lenker. Vi fremviste dette forslaget til oppdragsgiver under utviklingsmøtene, hvor vi i fellesskap ble enige om hva slags informasjon det bør lenkes til. I prototypen er det linker til sykkelplanlegger, informasjon fra bomselskapene, vegvesenet og Østfold kollektivtrafikk, noe som reflekterer hvordan disse områdene på nettstedet kan benyttes. Valg av Kommunikasjonstrategi Under forundersøkelsen prosjektgruppen har foretatt (se. Intervju med Tor Stabbetorp) har det kommet frem til at det er viktig for oppdragsgiver at det skal legges opp til en 2-veis kommunikasjon med publikum. Etter å ha diskutert hvordan vi best mulig skal legge til rette for at det både blir interessant for publikum og at oppdragsgiver får noe ut av det. Prosjektgruppen kom frem til følgende løsning: For tiltak som er under kategoriene: Påbegynte tiltak, kommende tiltak og tiltak under planlegging som legges ut på nettstedet skal være mulig for publikum å komme med egne innspill. Dette er markert med: Har du innspill til dette tiltaket? Når brukeren klikker på denne knappen lastes det en side som består av følgende elementer. Publikums innspill og Send inn ditt innspill her. Delen hvor brukeren kan fylle inn sitt innspill består av et skjema hvor man må fylle inn sitt navn, epost og sitt innspill. Videre må brukeren velge om innspillet skal publiseres på nettstedet eller og det kun skal sendes inn til oppdragsgiver før han trykker send. For å sørge for at det kun postes relevante innspill på nettstedet foreslår prosjektgruppen at innspill som blir sendt inn skal leses og godkjennes av en moderator hos oppdragsgiveren. I tillegg bør det legges til villkår for bruk av tjenesten, noe som ikke er lagt til på prototypen. Det som vi mener at skiller denne løsningen fra et vanlig kommentarfelt er nettopp det at vi ber om brukerens innspill mot tiltakene og at både plassering og formulering av denne funksjonen kan være med på å engasjere de personene som har noe relevant å legge til fremfor de som er

97 88 Kapittel 6. Diskusjon motstandere av bypakka og bomstasjonene de medfører. Vi testet denne funksjonen under brukertesten vi foretok av prototypen og fikk gode tilbakemeldinger på denne måten å kommunisere med publikum på. En av kommentarene vi fikk var at det finnes mye lokalkunnskap og at denne kunnskapen kan komme oppdragsgiver tilgode gjennom en slik funksjon. Figur 6.1: Dataflyt for innspill på nettstedet Figur 6.1 illusterer dataflyten for hvordan innspill vil kunne fungere i en ferdig løsning. Når brukeren sender innspillet må han velge mellom å publisere innspillet på nettstedet eller ikke. Administratoren som mottar innspillet vil dersom ja til publisering på nettstedet: Lese innspillet og sende bekreftelse på mottak. Administratoren må deretter ta stilling til om innspillet er innenfor reglene for publisering. Hvis nei, får innsenderen av innspillet en forklaring om at innspillet ikke vil bli publisert. Hvis ja, puliseres innspillet på nettstedet og innspillet blir sendt til rette vedkommende i ØFK. Administratoren som mottar innspillet vil. dersom nei til publisering på nettstedet, sende bekreftelse på mottak av innspill, deretter sender han innspillet til rette vedkommenede i ØFK. På nettstedet i footeren finnes overskriften Kontakt oss. På prototypen slik den ble fremvist under brukertesten var det lagt opp til at brukeren kan henvende seg til Bypakke Nedre Glomma ved å benytte seg av et kontaktskjema eller en lenke til Facebook. I undersøkelser med oppdragsiver kommer det frem at de ikke er sikre på om de ønsker å bruke Facebook for å kommunisere med publikum. Vi ønsket å teste hvilke av de to kontaktformene som var foretrukket. 4 av 5 foretrakk å benytte seg av kontaktskjemaet fremfor å bruke Facebook. Dette viser at nytteverdien for bruk av kontaktskjema er stor for at Bypakke Nedre Glomma skal kunne få så mange tilbakemeldinger som mulig. 6.3 Utforming Kapittelet drøfter utformingen av responsiv design og universell utforming. Funn gjort under brukertesten er sentralt for diskusjonen rundt elementer i universell utforming.

98 6.3. Utforming Universell utforming Prosjektgruppen har valgt å legge vekt på universell utforming i nettløsningen. Gjennom utføringen av dette har vi satt oss inn i krav til nettløsninger (WCAG 2.0) gitt av DIFI. Det er ikke alle krav som er relevante for prototypen vi har utviklet og vi har etter beste evne satt kravene i forhold til elementer i prototypen, se kapittel 5.7, Oppfylling av suksesskriterier i WCAG 2.0. Regelverket fra DIFI har til dels vært vanskelig å tolke, men vi mener at det mest relevante er tatt høyde for under utvikling av prototypen. Fordeler med uu kommer særlig frem under brukertesten ved at testpersonen med nedsatt synsevne kunne innhente informasjon fra nettstedet på en tilfredstillende måte ved å benytte de hjelpemidler han var vant med i hverdagen (Se Resultater fra testobjektene i kapittel 4). Det var likevel enkelte elementer som i brukertesten viste seg å ikke være optimale for å oppnå et godt utformet nettsted Bruken av SPAN-tag Brukertesten avslørte at bruken av <span> tagger i tekst, bryter opp flyten til skjermleseren ved at hver gang skjermleseren nådde en <span> tag, stoppet den opp, og behandlet innholdet i taggen som et nytt element. Taggene er brukt for at enkeltord i teksten skal være skrevet i fet skrift. Prosjektgruppen forsøkte å løse dette ved å bytte ut <span>-taggen med <div>-tag og <h>-tagger, uten at dette hadde virkning på skjermleseren, da samme problem oppstod. Prosjektgruppen ser ingen måte å endre på koden for å unngå dette problemet. Et alternativ vil være å fjerne <span> taggene, og dermed også fjerne muligheten til å vise deler av teksten i uthevet skrift. På denne måten vil vi fjerne den visuelle effekten av å fremheve nøkkelord, men til gjengjeld øke brukervennligheten for brukere av skjermlesere. På en annen side vil det være til hjelp for mange brukere med konsentrasjonsvansker å benytte grep som å fremheve nøkkelord i teksten, og den mest semantisk korrekte måten å gjøre dette på er ved å benytte <span> Utforming av bannerboks Informasjonsboksen, beskrevet i kapittel 5.3 Iterasjon 1, som stadig endret innhold skapte problemer for testobjekt 5. Blant annet inneholder boksen tekster med <span> tag, som tidligere er beskrevet. Testobjektet var også nødt til å navigere seg gjennom alle slidene, før han fant den lokale menyen. Dette tok unødvendig lang tid. Samtidig byttet slideren tekst hvert femte sekund, uavhengig av om testobjektets skjermleser hadde fokus på innholdet eller ikke. Dersom testobjektets skjermleser hadde fokus i bannerboksen, ble det lest opp ny tekst hver gang nytt innhold ble fremvist i boksen. Prosjektetgruppen forsøkte en løsning hvor vi implementerte aria-live= off i slider-koden, som beskrevet i kapittel Dynamiske oppdateringer. Selv etter implementasjonen, leste skjermleseren fortsatt opp nytt innhold hvert 5. sekund. En løsning på de nevnte problemene er å gjøre slideren statisk og samtidig la samme informasjon være presentert et annet sted på nettstedet. På denne måten kan brukeren selv avgjøre om han skal lese de ulike slider-tekstene, og trenger ikke da å navigere gjennom disse, på vei til den lokale menyen. Samtidig vil ikke slideren være automatisk, slik at skjermleseren ikke avbryter hver gang nytt innhold vises, slik som under brukertesten. Prosjektgruppen implementere en løsning slik som beskrevet i suksesskriteriet Hoppe over blokker i kapittel Brukeren vil da kunne hoppe over slideren, og komme rett til hovedinnholdet.

99 90 Kapittel 6. Diskusjon Valg av font, farger og kontraster Resultatene fra brukertestene viste at fargene og kontrasten var god for personer med svekket synsevne. Det kom frem under brukertesten at svaksynte ofte bruker fargekonvertering når de bruker internett. Nettstedet er gjennomført lyst, det gjør at personer med svekket synsevne ikke trenger å invertere farger kun på utvalgte områder på nettstedet. Dette er med på å øke brukervennligheten for svaksynte. Fargen lilla blir brukt på alle klikkbare elementene. Av brukertesten kommer det frem at dette bidrar til at brukerne forstår hva som er klikkbart også de med svekket syn. Bruken av Sans-serif bør være gjennomgående på nettstedet, da det kommer fram av brukertesten at dette er foretrukket font-type blant personer med nedsatt synsevne. Tekst-fonten som er brukt i informasjonsteksten i footeren og i bannerboksene på nettstedet bør derfor byttes til en font av typen Sans-serif Bruken av WAI-ARIA Av brukertesten kom det fram at bruken av WAI-ARIA på nettstedet ikke utgjorde noen forskjell for testobjektet, samt at testobjektet hadde svært lite kunnskap om WAI-ARIA. Prosjektgruppen mener at en av grunnene til dette er at nettstedet er statisk, og følger god HTML5-struktur, mens virkningene av WAI-ARIA kommer tydeligere frem på nettsteder hvor det er hyppig bruk av widgets som styres av JavaScript og Flash. Prototypen innholder ikke widgets, og informasjon er derfor ikke på noen måte gjemt for brukeren. Derfor anser prosjektgruppen bruk av WAI-ARIA som overflødig på nettstedet. Dersom det i fremtiden skal implementeres webapplikasjoner som er styrt at JavaScript eller Flash, bør det brukes WAI-ARIA for at disse også skal være tilgjengelige for brukere med nedsatt synsevne Utforming av responsiv design Gjennom utvikling av prototypen har prosjektgruppen tatt høyde for at oppdragsgiver ønsker seg en løsning som er tilgjengelig for alle medier. Vi har derfor benyttet oss av mobile-first tankegangen når det kommer til prototypen. Elementer på nettstedet har blitt utformet med tanke på at det skal være like brukervennlig å innhente informasjon fra PC, nettbrett eller mobiltelefon. Måten vi lagde nettstedet responsivt på ble gjort ved hjelp av CSS - Media Queries. Vi mener at dette er en god måte å sørge for tilgjengelighet for alle medier, da denne teknikken gir oppdragsgiver det de er ute etter, uten at det medfører ekstra administrasjon og vedlikehold av flere løsninger fordi det kun er ett innhold. Som et videre arbeid mener vi at det vil være hensiktsmessig å utføre brukertester fra mediene nettbrett og mobil for å kvalitetsikre utformingen av denne. 6.4 Videre arbeid Kapitelet diskuterer elementer ved nettstedet som ikke er ferdig utviklet Kart Nettstedets kartfunksjon er ikke komplett. Innholdet i kartet er brukt for å demonstrere hvordan det skal fungere. Derfor inneholder det kun ett tiltak under kategorien Sykkel. Videre ser vi for oss at kartet skal inneholde en oversikt over samtlige tiltak innenfor kategoriene sykkel, gange, kollektiv og bil, som forgår i Nedre Glomma. På bakgrunn av forundersøkelsen kommer det også

100 6.4. Videre arbeid 91 frem et ønske fra oppdragsgiver om at kartet skal opplyse brukerne om hvor bomplasseringene er og hvor det finnes innfartsparkeringer. Prosjektgruppen valgte først å implementere Google Maps sin kartløsning, men det er nå Leaflet som ligger til grunn for kartfunksjonen. Leaflet er et JavaScript bibliotek som baserer seg på open source kartet OpenStreetMap. Fordelen ved å bruke en open source løsning er at en står fritt til å kopiere, distribuere, overføre og tilpasse kartet og data, så lenge en krediterer OpenStreetMap og dens bidragsytere Innspill Det kom fram under møte med oppdragsgiver at brukeren bør ha mulighet til å komme med innspill til enkelttiltak, uten at det publiseres på nettstedet. Derfor bør det være et avkrysningsvalg i skjemaet for innspill, hvor brukeren velger hvorvidt innspillet skal publiserer eller ikke. Denne funksjonaliteten må implementeres før en eventuell lansering av nettstedet Kontaktskjema Kontaktskjemaet på nettstedet eksisterer ikke. Kontaktskjemaet er kun presentert som en link, som ikke tar brukeren noe sted. Videre arbeid med nettstedet innebærer derfor utvikling av et fungerende kontaktskjema innen nettstedets lanseringsdato Nettstedskart Videre arbeid med nettstedet vil være å utvikle et nettstedskart som et alternativ til navigering gjennom den globale menyen. Nettstedskartet bør være godt kategorisert og utformet på en oversiktlig måte, slik at brukeren enkelt kan ta seg direkte til flere av nettstedets underliggende nettsider Søkefunksjon Videre arbeid med nettstedet vil være å ferdigstille utvikingen av søkefunksjonen. En søkefunskjon på et slikt nettstedet er nødvendig siden den er laget for å inneholde store mengder med innhold. Brukertesten viste at 3 av 5 ville ha benyttet søkefunksjonen på nettstedet. Det viser behovet for en søkefunksjon på nettstedet. Videre arbeid blir å avgjøre hvordan presentasjon av søkeresultatene skal presenters Kostnader ved ferdigstilte tiltak Under et av utviklingsmøtene vi hadde med oppdragsgiver kom vi frem til at det kunne vært interessant å gi brukerne informasjon om hvor mye kostnader det har vært i forhold til utvikling av tiltaket. Vi kom frem til at det er mest hensiktsmessig å publisere denne informasjonen når tiltaket er ferdig utført og befinner seg i kategorien utførte tiltak. Vi foreslår derfor å legge informasjon om kostnader som et valg i den lokale menyen for utførte tiltak, i de tilfeller det er et tiltak hvor kostnadene er av betydelig størrelse. I tilegg til størrelsesorden mener vi det også vil være riktig å vise hvor finansieringen kommer fra.

101 92 Kapittel 6. Diskusjon 6.5 Refleksjoner Gjennom prosjektperioden har prosjektgruppen gjort seg flere erfaringer knyttet til det å arbeide mot en ekstern arbeidsgiver. I dette prosjektet har prosjektgruppen lært at det å følge en iterativ utviklingsprosess har vært et viktig virkemiddel for å skape et godt resultat. Gjennom god dialog og samarbeid har vi i prosjektgruppen og oppdragsgiver kommet frem til en løsning på oppgaven. Metoden gjorde at oppdragsgiver, som til tross for liten kompetanse innefor webutvikling, kunne ta del i utviklingen av nettstedet. Metodevalget var vellykket i den forstand at det i utviklingsprosessen stadig dukket opp forslag til endring og forbedring av produktet. Prosjektgruppen merket seg at oppdragsgiver ikke hadde en tydelig visjon for nettstedet. Gjennom en iterativ prosess var det rom for at oppdragsgiver kunne bearbeide sin visjon underveis i utviklingsprosessen. Prosjektgruppen opplevde at dette bidro til å konkretisere oppdragsgivers krav og ønsker for nettstedet. Prosjektgruppen vurderte å foreta en brukertest i forkant av utvikling av nettstedets prototype. Intensjonen var å finne ut av målgruppens krav, ønsker og behov for nettløsningen. Etter å ha vurdert muligheten for dette, avgjorde prosjektgruppen at det ikke ville gi et brukbart resultat. Grunnen til dette var at Bypakke Nedre Glomma prosjektet ikke er kjent for målgruppen. Prosjektgruppen antok at det ville være vanskelig for målgruppen å komme med krav, ønsker og behov for en nettløsning og et prosjekt de ikke har forkunnskaper om. Prosjektgruppen så det derfor vanskelig å lage en konstruktiv test på dette stadiet og valgte derfor å heller gjennomføre brukertestene etter at prototypen var utviklet. Prosjektgruppen har i prosjektperioden opplevd å kunne benytte seg av kunnskap tilegnet gjennom studietiden. Vi har gjennom utviklingsprosessen dratt nytte fra teorikunnskapene og satt de i en praktisk sammenheng. Særlig har kunnskap om prosjektstyring, webutvikling, informasjonsarkitektur og akademisk skriving vært med på å styrke denne oppgaven. Det at dette var en praktisk oppgave som kunne føre til et konkret produkt var et viktig element for valg av oppgave. Et praktisk prosjekt har vært en god avslutning på studietiden.

102 Kapittel 7 Konklusjon Prosjektgruppen har utviklet en prototype av nettstedet Bypakke Nedre Glomma som presenterer informasjon om ferdige -, pågående -, kommende - og planlagte tiltak for utbedring av samferdselsrelaterte saker i Nedre Glomma Regionen. Prototypen oppfyller oppdragsgivers ønske om å informere og å endre holdning ved å vise et forslag på hva nettstedet kan inneholde og hvordan informasjonen kan presenteres. Prototypen legger opp til en 2-veis kommunikasjon med publikum. Gjennom muligheten til å komme med innspill rettet mot tiltakene, er det tatt hensyn til oppdragsgivers ønsker om kommunikasjon med publikum. Nettstedet følger kravet om universell utforming fra DIFI, ved at 35 av 61 krav er oppfylt. Selv om nettstedet oppnår nivå AA, bør enkelte elementer på nettstedet, slik som bruk av span tag og sliderboks, revurderes for å optimalisere brukeropplevelsen for personer med nedsatt funksjonsevne. Implementering av WAI-ARIA for å øke tilgjengeligheten er ikke nødvendig for prototypen, da den ikke inneholder webapplikasjoner som er styrt med JavaScript eller Flash. Prosjektgruppen har utviklet et nettsted som er tilgjengelig på forskjellige medier som PC, nettbrett og mobil. Ved bruk av media-queries, tilpasser nettstedet seg avhengig av skjermstørrelsen til brukeren. Brukertesten konkluderer med at alle testpersonene løste oppgavene vi gav de på en tilfredstillende måte. Det betyr at prosjektgruppen har laget et godt nettsted på bakgrunn av resultatene fra testene vi utførte. 93

103 Bibliografi [1] Likestillings-og Inkluderingsdepartementet Barne. Diskriminerings- og tilgjengelighetsloven, , Kapittel 3. [2] Likestillings-og Inkluderingsdepartementet Barne. Konvensjonen om rettighetene til mennesker med nedsatt funksjonsevne, [3] James Craig and Michael Cooper. Accessible rich internet applications (wai-aria) 1.0: The roles model, Lest [4] DIFI. Ikke-tekstlig innhold, [5] Difi. Krav til nettløsninger, [6] Frode Eika Sandnes. Universell utforming av IKT-systemer: Brukergrensesnitt for alle. Universitetsforlaget, [7] Riley Graham. Mobile first: What does it mean, [8] Mari L. Gregersen. Hva er responsiv design?, [9] Shawn Lawton Henry. Wai-aria overview, Lest [10] Bernt Krohn Holme, Idar Magne & Solvang. Metodevalg og metodebruk. TANO, [11] Høgskolen i Østfold. Studieplan uten emnebeskrivelse: Bachelorstudium i informasjonssystemer, [12] Steve Krug. Don t Make Me Think: A common sense approach to web usability. Sebastopol, California: O Reilly Media, [13] Miljøverndepartementet. Universell utforming: Begrepsavklaring, [14] Clarissa Peterson. Accessibility in html5, Lest [15] Peter Morville & Louis Rosenfeld. Information Architecture. O Reilly Media, Inc, 3 edition, [16] Kjetil Sander. Kvalitative intervjumetoder for datainnsamling. Hentet [17] Statistisk Sentralbyrå. Tabell: 07459: Folkemengde, etter kjønn og ettårig alder. 1. januar (k), [18] Helen Sharp, Yvonne Rogers, and Jennifer Preece. Interaction Design: Beyond humancomputer interaction. Chichester, England: John Wiley & Sons Ltd,

104 BIBLIOGRAFI 95 [19] Morten Tollefsen, Trond Ausland, Rudolph Brynn, Jo Herstad, Harald Holone, Magne Lunde, and Frode Eika Sandnes. WEB OG UNIVERSELL UTFORMING. Universitetsforlaget, [20] Håkon Tolsby. Informasjonsarkitektur: planlegging og design av store nettsteder, Hentet 14. April [21] usability.gov. Usability testing. Udatert, Hentet [22] WAI-AIRA-GUIDEN. Live-regioner, Lest

105 Kapittel 8 Vedlegg 8.1 Vedlegg A - Møtereferat 96

106 Møtereferat Dato 19. desember 2013 Tid 09:00 Tilstedet HiØ: Eugen Anstensrud, Håvard Ramstad, Jon- Martin Filberg. (til kl 10:45). ØFK: Lars Helge Husvik, Tor. Fredrik Sted og tid Sarpsborg, Fylkeskommunen Møtets formål - Skal bli enige om rammene om prosjektet. - La de komme med sine krav. - Sier om hva vi faktisk for til. - Bli enige om hva som skal leveres. - Se på konkurrenter. - Kartlegging av bruker. - Spørreundersøkelse. Kvantitv og kvalitiv. - Informasjonsarkitektur. Agenda Møte fra 09:00 09:45 Fra 09:45, busstur Fra møte: Presentasjon av Universell utforming i Nedre Glomma Regionen. Universell utforming: på bussholdeplasser for de nye biogass bussene. Dette gjør at bussen er tilgjengelig for alle. Prosjektet - Lage grunnlaget for en nettbasertinformasjonkanal, oppdragsgiver forteller at alle bør ha tilgang i form av universell utforming. - Informasjonskanalen skal gi bakgrunnsinformasjon for prosjektet Bypakke Nedre Glomma. - Løsningen bør bygge under på at bomringene kommer og bør vise til at folk får noe igjen pengene. Annet: Gruppen var med på åpningen av busstopp som er universell utformet. Videre arbeid: Finne ut om Bypakke Nedre Glomma. - Analyse av tilsvarende nettsteder - Finne potensielle brukere. - Kartlegge muligheter for intervjuer Neste møte: Neste møte: 13.jan kl 09 på fylkeskommunen

107 98 Kapittel 8. Vedlegg 8.2 Vedlegg B - Forprosjektrapport

108 Forprosjektrapport Nettløsning for samferdselstiltak i Nedre Glomma regionen Gruppenr. 11 (Foto: Østfold Fylkeskommune[1].) Eugen Anstensrud, Jon Martin Filberg og Håvard Ramstad 17. Januar 2014

109 Innhold 1. Prosjektgruppen Gruppemedlemmer Prosjektveileder Prosjektnettside Oppdragsgiver Oppdraget Innledning Oppdragsformulering Formål Mål og delmål Leveranser Metode Prosjektplan Teori-innsamling Risikoanalyse Gjennomføring Roller og ansvar Referanseliste Figurliste...14

110 1. Prosjektgruppen Valget av denne oppgaven ble gjort ved at gruppen møttes og hadde en felles gjennomgang av de mulige oppgavene som var tilgjengelige for valg av bacheloroppgave. Gruppen hadde et ønske om en oppgave som vil kunne bidra til noe positivt for oppdragsgiveren, samtidig var det viktig for gruppen å få et reelt læringsutbytte. Avgjørelsen falt på Nettside for Nedre Glomma regionen. Beskrivelse og gjennomføring av prosjektet er beskrevet i denne forprosjektrapporten. Gruppen består av 3 medlemmer, hvor alle studerer Informasjonssystemer, et 3-årig studie. Bachelorstudiet i informasjonssystemer tilhører fagdisiplinen informasjonsvitenskap, som tar for seg informasjons- og kommunikasjonsteknologi (IKT) i forhold til individer, grupper, organisasjoner og samfunn. Faget fokuserer på forholdet mellom teknologien og menneskene som skaper og benytter seg av kunnskapen og informasjonen. Informasjonsvitenskapen studerer dermed hvordan behandling av kunnskap, informasjon og data kan bli, bør bli og faktisk blir støttet av IKT, der IKT kan være informasjonssystemer, programmer, databaser, datamaskiner, datanettverk og internett. I løpet av dette studiet skal studenten ha kompetanse i følgende kunnskaper: Webutvikling PHP MySQL Markedsføring Bedrift økonomisk analyse Organisasjonsteori Testing og evaluering av programvare IT -Ledelse IT i virksomheter Databaseadministrasjon [2]. I tillegg har gruppemedlemmene noen forskjellige valgfag. Dette står beskrevet under beskrivelse av hver gruppemedlem. 1.1 Gruppemedlemmer Her står det skrevet noen opplysninger og medlemmenes valgfag og interesser. Slik at en vil kunne få en forståelse av de ulike medlemmene. Eugen Anstensrud, 23 år fra Skiptvet i Østfold. Studieretning IT og ledelse. Har valgfag som logistikk, datakommunikasjon og informasjonsarkitektur. Har tidligere arbeidet med alle i denne gruppen og oppnådd gode resultater. Håvard Ramstad: 32 år fra Langhus i Ski kommune. Studieretning IT og ledelse. Har valgfag som: Dokumenter & Web, Informasjonsarkitektur og logistikk. I samtlige fag har vi jobbet sammen om større prosjekter og oppnådd gode resultater. Jeg har planer om å jobbe med utvikling av webløsninger i fremtiden, da jeg er interessert i dette feltet. Jon Martin Filberg: 22 år fra Oslo. Studieretning IT og ledelse. Har valgfag som Datakommunikasjon, Informasjonsarkitektur og Objektorientert Programmering.

111 1.2 Prosjektveileder Veileder for dette prosjektet er Gunnar Misund, førstelektor ved avdelingen for informasjonsteknologi. 1.3 Prosjektnettside Et krav for bachelor-prosjektert er at gruppen må ha en egen nettside som forteller om prosjektet. Denne siden finnes her: 2. Oppdragsgiver Prosjektgruppen vil under prosjektet samarbeide med Lars Husvik, Tor Stabbetorp og Fredrik Norland som alle er representanter for Østfold Fylkeskommune. Østfold fylkeskommune har omtrent ansatte. Disse er fordelt på avdelinger og virksomheter i Østfold. Østfold Fylkeskommune leverer tilbud som går på tvers av kommunegrensene. I tillegg har de ansvar for den regionale samfunnsutviklingen. Det vil si at de arbeider for utviklingen av arbeidsplasser gjennom å legge til rette for nyskapning og innovasjon. Østfold fylkeskommune sine oppgaver kan deles inn i følgende kategorier: Videregående opplæring Kollektivtrafikk Tannhelse Samferdsel og næringsutvikling Kultur og kulturminnevern Internasjonalt arbeid Plan, areal og miljø Folkehelse Fylkesveier Friluftsliv Forskning Forvaltning av elver og fosser.

112 Figur 2.1: Organisasjonskart Østfold fylkeskommune Figur 2.1 viser Østfold Fylkeskommunes organisasjonskart. Den viser de forskjellige avdelingene i organisasjonen. Denne oppgaven tilhører under Regionalutviklingsavdelingen, samferdselsseksjonen. En utdypende beskrivelse av dette prosjekt er skrevet under kapittel 3. Oppdraget.

113 3. Oppdraget 3.1 Innledning Den ble en samarbeidsavtale inngått om areal- og transportutvikling i Nedre Glomma. Partene i samarbeidsavtalene er Østfold Fylkeskommune, Statens vegvesen region Øst, Fredrikstad kommune og Sarpsborg kommune. Denne av avtalen ble gjort siden region opplever befolkningsøkning, økonomisk utvikling og økt samhandling, derfor er det forventet økt transportmengde i Nedre Glomma. Dette er bakgrunnen til at den 5-årige samarbeidsavtalen ble inngått mellom partene. Målet for dette samarbeidet er at partene er med på å bidra til å utvikle Nedre Glomma som en attraktiv og konkurransedyktig region på en bærekraftig måte basert på virkemidler innen areal- og transportsektoren. 3.2 Oppdragsformulering Østfold Fylkeskommune (ØFK) ønsker seg en nettbasert informasjonskanal hvor de kan informere innbyggerne om pågående tiltak, kommende tiltak og hvilke planer Nedre Glomma samarbeidet har for utbedringer av samferdselsrelaterte saker i regionen. De neste årene skal det benyttes betydelige midler på utrustning av bilvei, sykkelvei og offentlig transport av buss, tog og ferge i og mellom byene Fredrikstad og Sarpsborg. ØFK ønsker en nettbasert informasjonskanal tilgjengelig for alle på alle medier for Nedre Glomma regionen. Oppdraget til prosjektgruppen vil i hovedsak gå ut på å lage en kravspesifikasjon for løsningen gjennom innhenting av informasjon fra ØFK, brukere og eventuelle lignende prosjekter som bypakka.no. Prosjektet vil fokusere på at nettsiden skal være tilgjengelig for alle, på alle medier. Med tilgjengelighet for alle menes en universell utforming som tar hensyn til alle uansett kultur, bakgrunn og eventuelle funksjonshemninger. Prosjektet vil også fokusere på løsninger for at nettsiden skal være like funksjonell på ulike medier som mobil, nettbrett og PC. Oppgaven består også i å lage en prototype av nettsiden, hvor det teoretiske settes i en reel sammenheng. Prototypen skal lages på bakgrunn av informasjonen prosjektgruppen har tilegnet seg gjennom prosjektperioden. Prosjektet går også ut på å komme frem til en konseptuell idé om hva løsningen skal inneholde. Med dette skal vi definere målene med løsningen og hvilken rolle løsningen skal ha / ikke ha. Hvilket budskap skal den sende. Hva skal fremheves av informasjon. Og på hvilken måte innholdet skal presenteres. Dette er for å bygge opp under de overordnede målene til Glomma samarbeidet om å ikke øke trafikkbelastningen i regionen de neste årene og ønsket om å kunne påvirke publikum med positive holdninger til offentlig transport. Under følger hovedpunkter for hva vi skal konsentrere oss om gjennom prosjektet for å oppnå de målene som er satt. Kvalitative intervjuer hos ØFK. Brukertest av responsgruppe Innbyggere i Nedre Glomma regionen

114 Analyse av eksisterende sider (bypakka.no). Prototype o Arkitektur, design, oppsett og innhold Teoriinnsamling o Webdesign / arkitektur. Responsiv utforming. o WAI / Aria. Tilgjengelighet for svaksynte. o Spørreundersøkelser (Kvantitativ og kvalitativ metode) 3.3 Formål Formålet med prosjektoppgaven er at den, som et ledd i fylkeskommunens kommunikasjonsstrategi, skal skape et grunnlag for utvikling av det nettbaserte publiseringssystemet. Med prosjektoppgaven vil vi utvikle en forståelse for og kartlegge ulike interessenters behov og krav til bruk av publiseringssystemet. ØFK skal sitte igjen med kunnskap om hvordan systemet kan være universelt utformet slik at den er tilgjengelig for alle og på ulike medier. Prosjektgruppen har som formål å presentere et prosjekt som har direkte nytteverdi for ØFK, og fungerer som et springbrett for (videre)utvikling av publiseringssystemet. 3.4 Mål og delmål Liste over prosjektets mål og delmål. Hovedmål: Å utforme en prototype av et nettsted som møter kravene om universell utforming og tilgjengelighet på ulike medier. delmål 1: Gjøre nettstedet tilgjengelig ved å oppfylle krav om uu. delmål 2: Sørge for god tilgjengelighet på ulike medier. 3.5 Leveranser Denne oversikten viser hvilke leveranser som skal leveres i løpet av prosjektperioden. Leveranse Hjemmeside Forprosjektrapport Hoveddokument Refleksjonsnotat Prosjektplakat Presentasjon Frist 10. Januar 17. Januar 22. Mai 22. Mai 2. Juni 04. Juni 3.6 Metode Kommunikasjonen mellom ØFK og prosjektgruppen vil være dynamisk ved at møter avtales etter behov. Prosjektgruppen ønsker møter med ØFK underveis i prosjektet for å få tilbakemeldinger på oppgaven med jevne mellomrom.

115 Prosjektgruppen ønsker å benytte seg av kvalitative metoder som intervju og bruketest i prosjektet. Resultatet av undersøkelsene vil ligge til grunn for diskusjonen i oppgaven og beslutninger som tas. Ved analyse av både kvalitativ og brukeundersøkelse ønsker prosjektgruppen å oppnå kunnskap om interessenters behov og ønsker knyttet til publiseringsløsningen. Prosjektgruppen vil analysere en eksisterende publiseringsløsning fra et lignende prosjekt, som for eksempel bypakka.no. Formålet med analysen er å kunne ta med seg gode idéer inn i prosjektgruppens løsning og la mindre gode løsninger utebli. For å nå disse målene vil vi innhente informasjon fra ulike personer hos fylkeskommunen, og evaluere svarene og knytte dette opp mot det reelle løsningen.

116 4. Prosjektplan Prosjektplanen forteller om hvilke arbeidsoppgaver som skal gjennomføres i prosjektperioden. Aktivitetens nummer indikerer rekkefølgen oppgavene skal prioriteres. I beskrivelse står det skrevet kravene for en godkjent gjennomføring av milepælen. Start viser når aktiviteten skal påbegynne og slutt når gruppen avslutter arbeidet med aktiviteten. Leveranse er når dokumentet er tilgjengelig prosjektets nettside. Bemanning forteller om hvilke gruppemedlemmer som har hovedansvaret for gjennomføring av aktiviteten. Denne planen vil kunne endre seg underveis i prosjektperioden. Kolonnen ansvarlig forteller hvem som har hovedansvaret for aktiviteten under prosjektet. Nr Aktivitet Beskrivelse Start Slutt Leverans e Ansvarli g 1. Hjemmeside Sette opp hjemmeside med kontaktinfo og beskrivelse av prosjektet. Prosjektdokumenter vil legges til underveis HR 2. Forprosjekt Beskrivelse av prosjektgruppen, prosjektoppgaven, formål med oppgaven, leveranser, metode, prosjektplan og gjennomføring av prosjekt EU, HR, JMF 3 Analyse av eksisterende nettløsning Analysere nettstedets informasjonsarkitektu r og gjennomføre brukertesting JMF 4. Intervju. Intervju av personer som drifter og publiserer gjennom nettstedet EU 5. Kravspesifikasjo n Definert dokumentet om krav og behov for løsningen for EU

117 oppdragsgiver og brukere. 6. Prototype Lage prototype HR 7. Brukertest Brukertest av prototype med potensielle bruker JMF 13. Hoveddokument Hoveddokument med vedlegg pluss prototype EU 14. Presentasjon Endelige presentasjon av hele prosjektet med oppdragsgiver og veileder JMF 4.1 Teori-innsamling Gruppen har sammen sett for seg en rekke temaer som studeres for å gi tyngde i argumentasjonen. Disse temaene vil gruppen sette seg inn i prosjektperioden og vil være en del av teori kapittelet i hovedrapporten. Temaene er: Webdesign Informasjonsarkitektur WAI/Aria. Tilgjengelighet for svaksynte Gruppen tar høyde for at det vil kunne oppstå nye temaer underveis i prosjektperioden, men det er disse temaene som er sentrale for dette prosjektet. 4.2 Risikoanalyse Sannsynlighetskode S: Aktuell bedømmelse av sannsynlighet for at hendelsen inntreffer dersom planlagte tiltak ikke gjennomføres. 5. Svært stor sannsynlighet (80%-100%) 4. Stor sannsynlighet (60% - 80%) 3. Middels høy sannsynlighet (40% - 60%) 2. Lav sannsynlighet (40% - 20%) 1. Usannsynlig (mindre enn 20%) 0. Risikoen finnes ikke

118 Konsekvenskode K: Bedømmelse av konsekvensene om hendelsen inntreffer: 5. Svært alvorlig: Hele(del) prosjektet er i fare 4. Alvorlig: Hele (del) prosjektets planer må gjøres om 3. Moderat: Hele (del) prosjektets planer påvirkes, men totalrammen av prosjektet kan holdes. 2. Lav: Planer for (del)prosjektet påvirkes, men totalrammen holdes. 1. Ubetydelig: Begrenset virkning, kan innhentes. Hendelse S K Konsekvenser Tiltak Prosjektleder blir syk 4 1 Mindre arbeidskraft Den som var prosjektleder uken før går inn som prosjektleder. Intern uenighet/konflikter 4 2 Dårlig arbeidsmiljø Kritikk gjøres konstruktivt. Prosjektleder styrer ordet og legger vekt på det positive. Oppdragsgiver trekker seg Uklare rammer for oppgaven 1 5 Ingen prosjektoppgave 2 4 Resulterer i et dårlig produkt. Holde oppdragsgiver interessert, finne ny eventuell oppgave. Avtale grensene for oppgaven på et tidlig tidspunkt. Sykdom 4 3 Mindre arbeidskraft Gjenværende medlemmer tar på seg flere arbeidsoppgaver. Tap av data 1 3 Mangler i prosjektoppgaven Regelmessig backup. Arkivarens ansvar for gjennomføring av backup. 5. Gjennomføring I dette prosjektet vil gruppen benytte av en flat struktur, der flertallet av gruppemedlemmene bestemmer avgjørelser som tas. Gruppen vil under prosjektperioden benytte seg av en prosjektleder, roller og ansvar er beskrevet i avsnittet under. Gruppen gjennomfører ukentlig møter ved høgskolen i Østfold, Remmen. Disse møtene er arbeidsmøter, hvor gruppen arbeider, diskuterer og fordeler oppgaver. Veiledning vi være tilgjengelig en gang i uken med veileder. Til dokumentasjon og lagring, benyttes Google DOCs for samskriving av dokumenter. Ferdigstilte dokumenter vil bli lagret i dropbox.

119 5.1 Roller og ansvar Prosjektleder: Ansvarlig for styring av prosjektet og planlegging. Sørge for at det blir avholdt avtalte møter. Møteledelse. Etterfølge at arbeidsoppgaver blir gjennomført til avtalt tid. Sekretær: Skrive referater. Møteinnkalling, finne tid og sted. Arkivar: Sørge for at dokumenter, kalender og arbeidsplaner er oppdatert til enhver tid. Organiserer og strukturere dokumenter.

120 6. Referanseliste 1. Østfold Fylkeskommune. Bilde. Hentet fra 2. Studieseksjonen ved Høgskolen i Østfold. Studieplan med emnebeskrivelse, Hentet fra informasjonsteknologi/it_studier/informasjonssystemer/?&function=dumpbeskrivelse& module=studieinfo&type=studieme&key= Figurliste Figur 2.1. Organisasjonskart av Østfold Fylkeskommune, Henter fra:

121 112 Kapittel 8. Vedlegg 8.3 Vedlegg C - Analyse av Bypakka.no

122 Analyse av Bypakka.no Evalueringsrapport 1. Nettstedet bypakka.no. 2. Analyse av nettstedets informasjonsarkitektur. 2.1 Navigasjonssystemer 2. Informasjonsorganisering 3. Heuristisk evaluering 4. Brukertesting 5. Resultater 6. Andre observasjoner 7. Konklusjon 8. Referanseliste

123 1. Nettstedet bypakka.no. Dette er et nettsted som presenterer ulike samferdselsprosjekter som er under utvikling i samarbeid mellom Telemark fylkeskommune, Siljan, Skien og Porsgrunn kommune, Jernbaneverket og Statens vegvesen. Det overordnede målet til bypakka grenland er å følge opp nasjonale klimamål og skape en attraktiv og konkurransedyktig byregion. Ved å gi informasjon til innbyggerne om de ulike prosjektene mener Telemark fylkeskommune at det skal bli enklere og tryggere for syklende og gående. Det skal føre til et mer brukervennlig kollektivtilbud. Samt økt effektivitet for næringslivet. (Forsiden, Landingpage)

124 2. Analyse av nettstedets informasjonsarkitektur. 2.1 Navigasjonssystemer Den globale navigasjonen på bypakka.no (1) deler informasjonen på nettstedet inn i nettstedets nøkkelområder. Disse områdene er prosjekter, om Bypakke Grenland, aktuelt og presse. Den