Hovedprosjektrapport. Gruppe 21, Våren Patrick Joachim H Christoffer Julius Ozma. Lorenzen Skuggerud Vedaa Yran Zubair

Transkript

1 Hovedprosjektrapport Gruppe 21, Våren 2011 Patrick Joachim H Christoffer Julius Ozma Lorenzen Skuggerud Vedaa Yran Zubair 1

2 PROSJEKT NR. 21 Studieprogram: Anvendt datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Hovedprosjekt TILGJENGELIGHET Åpen Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL Medwear.no DATO ANTALL SIDER / BILAG PROSJEKTDELTAKERE Patrick Lorenzen (s155521) Joachim H Skuggerud (s155557) Christoffer Vedaa (s155528) Julius Yran (s155532) Ozma Zubair (s105324) INTERN VEILEDER Siri Fagernes OPPDRAGSGIVER Mohammed Usman Akram KONTAKTPERSON Siri Fagernes, HiO SAMMENDRAG Dette hovedprosjektet gikk ut på å designe og utvikle en nettbutikk som selger medisinsk utstyr og klær, primært rettet mot medisin- og sykepleierstudenter. Vi har brukt et rammeverk kalt Zen Cart som basis for nettbutikken Vi utviklet tre prototyper av en nettbutikk bygget rundt Zen Cart. For å fatte en kvalifisert beslutning om hvilken prototyp vi ville fortsette å utvikle til ferdig produkt, gjennomførte vi brukertester på Høgskolen i Oslo. Til dette brukte vi en eye tracker i tillegg til intervjuer av testbrukerne. Bruken av eye tracker kunne fortelle oss mye om hvordan en testbruker uten forhåndskunnskap om nettbutikken ville interagere med den. Mot slutten av prosjektet videreutviklet gruppen den prototypen som testbrukerne gav best respons på til en ferdig og fungerende nettbutikk i samsvar med kravene fra vår oppdragsgiver Mohammed Usman Akram. Nettbutikkutvikling Eye tracker Zen Cart 2

3 Forord Denne rapporten inneholder dokumentasjon om hovedprosjektet Medwear.no. Hovedprosjektet er den avsluttende oppgaven etter tre år ved Høgskolen i Oslo, på linjen anvendt datateknologi. Rapporten skal kunne leses av alle, men er av særlig interesse for dem som vil ha et innblikk i hvordan man kan utvikle en nettbutikk fra grunnen av. Oppdragsgiveren til prosjektet heter Mohammed Usman Akram. Han driver en nettbutikk som selger medisinsk utstyr. Han kontaktet HiO med et prosjekt som gikk ut på å utbedre nettbutikken hans. Rapporten inneholder inngående beskrivelser av problemstillingen, valgt løsning og brukertesting. Målet med prosjektet har hele tiden vært å få en fullgod og fungerende nettbutikk. Vi har valgt å la vår prosessdagbok ligge tilgjenglig ute på Her kan leserne av rapporten få ytterligere innblikk i prosessen og gruppen samt møtereferater og styringsdokumenter. Vi vil gjerne takke Tor Krattebøl og Siri Fagernes for viktig og konstruktiv veiledning gjennom prosjektets gang. 3

4 Innhold Hovedprosjekt... 2 Forord... 3 Kapittel 1 Introduksjon Oppgaven Utgangspunkt Ønsket resultat av prosjektet Gruppen Høgskolen i Oslo Anvendt Datateknologi Valg av oppgaven Rollefordeling Kapittel 2 Behovsanalyse Oppdragsgivers krav Våre krav Brukervennlighet Universell utforming Kapittel 3 Prosjektutviklingsfasen Fremgangsmetode Idéskapende arbeid Utviklingsarbeid Ferdigstilling Agile arbeidsmetoder Dokumentasjon av arbeid Kapittel 4 Research Kartlegging av ulike løsninger Lærdom fra nettbutikkene oscommerce: Zen Cart: Magento Bigcommerce Valg av Zen Cart Kapittel 5 Zen Cart Kapittel 6 Prototypene

5 6.1. Hvorfor prototype? Utvikling av prototyper Fokusering på tre prototyper Prototyp Prototyp Prototyp Kapittel 7 Brukertesting Brukertesting Eye tracker Hvorfor bruke Eye tracker til vårt prosjekt? Hypoteser Metode Resultater Intervju Analyse Konklusjon Kapittel 8 Ferdigstilling av produkt Fra brukertesten Nye krav fra oppdragsgiver Ferdigstillelse av layout PayPal Lansering av Debugging Kapittel 9 Refleksjon Kilder: Vedlegg

6 Kapittel 1 Introduksjon 6

7 Kapittel 1 Introduksjon 1.1. Oppgaven Hovedprosjektoppgaven vi skal ta for oss dreier seg om å utforme en nettbutikk. Oppdragsgiver driver et enkeltmannsforetak som importerer og selger klær og utstyr, primært rettet mot medisinstudenter. Oppdragsgiver vil ha en komplett nettbutikk med lagring av kundeinfo og lagerstatus. I nettsiden skal hovedsiden være estetisk designet, og selve utformingen slik at legeklærne ser bra ut på websiden. Vi vil stå fritt til å komme med våre ideer. Vi kan enten bruke nåværende hjemmeside og gjøre endringer på hovedsiden, eventuelt så kan vi se på liknende hjemmesider som vi kan ta utgangspunkt fra. Vi vil også stå fritt til å velge system og verktøy, med hovedfokus på god brukervennlighet Utgangspunkt I skrivende stund er den forrige nettbutikken lagt ned. Årsaken er sikkerhetsbrudd og manglende oppfølging, dermed har nettbutikken ikke blitt gjenoppbygget etter en hackerepisode høsten Det innebærer at vi i utgangspunktet sitter med mer eller mindre blanke ark. Figur 1 viser den forrige nettbutikken etter et sikkerhetsbrudd. Figur 1: medutstyr.no, oppdragsgivers tidligere nettbutikk etter et sikkerhetsbrudd For bedriftens del er det ingen aktivitet før en fungerende nettbutikk er oppe og tilgjengelig på internett. Det er i hovedsak dette som er grunnlaget og motivasjonen for både oss som hovedprosjektgruppe og oppdragsgiveren som eier av bedriften. Dette er også bakgrunnen for oppdragsgiverens ønske om tidlig ferdigstillelse av nettbutikken. 7

8 Den forrige nettbutikken, har vi noe mangelfull informasjon om. Vi vet ikke nøyaktig hvor den hadde serverplass eller hva slags server den var plassert på. Den eneste informasjonen tilgjengelig er at det er gjennom bekjentskaper at oppdragsgiveren har fått plass på en server lokalisert i USA. Denne situasjonen er imidlertid løst ved at oppdragsgiver har anskaffet webhotell hos det danske Web10, med nytt domene, Fra oppdragsgiverens side er det et ønske om at vi benytter oss av et nettbutikkrammeverk som kalles Zen Cart, i og med at oppdragsgiver har gode egenerfaringer med dette. Oppdragsgiveren vår ønsker å få en fungerende nettbutikk opp så fort som mulig. Han har ikke satt så mange krav annet enn at det skal være enkelt å bruke, og at det ser profesjonelt ut. Han har gitt oss linker til forskjellige sider som eksempler på hva han ser for seg Ønsket resultat av prosjektet Vi ønsker å produsere en fungerende nettbutikk for vår oppdragsgiver. Nettbutikken skal være senteret for handel av klær og utstyr egnet for medisinstudenter med hensyn til krav til vår oppdragsgiver og vår veileder til hva som må inngå i nettbutikken og prosjektet, samt dets prosess. Det handler stort sett om funksjonelle krav til hva kunden og administrator kan gjøre (hvilke funksjoner som skal være tilgjengelige), men også andre krav til brukervennlighet, universell utforming og validering. I tillegg stilles det krav til metoder og dokumentasjon av prosjektprosessen. Ønsket vårt er å få laget en nettbutikk hvor vi fokuserer mer på brukervennlighet enn å kode fra grunnen av. Det skal også tas hensyn til retningslinjer og standarder som berører brukervennlighet, design og funksjonalitet Gruppen Medlemmene i gruppen (tabell 1) går på samme studium og kjenner hverandre gjennom alle tre årene på Høgskolen i Oslo, på linjen Anvendt Datateknologi og har jobbet sammen med prosjekter og obligatoriske gruppearbeider. Vi har god kommunikasjon oss i mellom, og kjenner til styrkene og svakhetene til hver enkelt person. Av den grunn kan arbeidsoppgaver fordeles på en god måte slik at vi får en effektiv og produktiv arbeidsprosess. 8

9 Tabell 1: Gruppemedlemmene Navn Klasse Studentnummer e-post Mobilnummer Christoffer Vedaa (3DB) S Joachim H Skuggerud (3DA) S s155557@stud.hio.no Julius Yran (3DB) S s155532@stud.hio.no Ozma Zubair (3DB) S s105324@stud.hio.no Patrick Lorenzen (3DB) s s155521@stud.hio.no Høgskolen i Oslo Høgskolen i Oslo (HiO) er landets største statlige høgskole. Skolen ble opprettet 1. august 1994, har i dag over studenter og 1250 ansatte. Skolen er fordelt over 7 avdelinger og tilbyr 33 bachelorstudier og 20 masterstudier. I tillegg har HiO to doktorgradsprogram. Studietilbudene ved HiO består av: - Estetiske fag - Helse - og sosialfag - Ingeniør teknologi - data - Journalistikk, bibliotek- og informasjonsfag - Lærerutdanning og internasjonale studier - Profesjonsstudier - Samfunnsfag, økonomi og administrasjon - Sykepleierutdanning HiO satser mye på internasjonal utveksling. Forskning er vektlagt, og mye av fag- og forskningssamarbeid skjer på internasjonalt nivå. Flere av utdanningstilbudene ved høgskolen er HiO alene om å tilby i Norge. Et av HiOs satsningsområder er universell utforming. Som eneste høgskole i Norge tilbyr ingeniøravdelingen et emne dedikert til dette fagområdet. Det jobbes også med en mastergrad innen dette. Ellers er innsatsområder profesjonsutdanninger og pedagogisk utviklingsarbeid Anvendt Datateknologi Anvendt datateknologi er et bachelorstudium som gir bred kunnskap om mange fagområder innen IT. Blant annet hvordan du planlegger, utvikler, utformer og evaluerer ulike 9

10 datasystemer og dataløsninger for mennesker med ulike behov. Studiet tilbyr tradisjonelle datatekniske fag som databaser, datanettverk og programmering, men også emner som engelsk, økonomi og ledelse. I mange av fagene står prosjektarbeid veldig sentralt. Og studiet avsluttes med et hovedprosjekt. Dette for å gi studentene erfaring med å samarbeide med andre, da dette er en vanlig arbeidsform i arbeidslivet og studentene har muligheten til å bruke kunnskapen de har opparbeidet seg gjennom studietiden. Studenter ved HiO føler seg forbredt på arbeidslivet ved endt utdanning i anvendt datateknologi Valg av oppgaven Høsten 2010 ble det lagt ut forslag til hovedprosjektoppgaver, og vi begynte å kontakte eiere av de prosjektene vi i fellesskap hadde lyst til å jobbe med. Et av de prosjektene var Medwear.no som gikk ut på å produsere en fungerende nettbutikk. På grunn av gruppens tidlige erfaring innen de fleste fag i anvendt datateknologi mente vi at vi hadde gode nok kvalifikasjoner til å løse oppgaven. Vi tok raskt kontakt med oppdragsgiver, ble tildelt prosjektet etter et kort informasjonsmøte og skrev under prosjektkontrakten Rollefordeling For å nå vårt mål med en ferdigstilt nettbutikk som både fungerer etter oppdragsgivers og våre ønsker og mål, har god struktur og rollefordeling vært viktig. Med ulikt utgangspunkt i tekniske, organisatoriske og autoritære ferdigheter, fordelte vi ansvar. En gruppeleder og en dokumentasjonsansvarlig, samt koding/programmeringsansvarlige. Fordelingen av ansvarsområder har vært viktig for at vi har hatt god struktur og dokumentasjon på utført arbeid. Dobbeltarbeid og andre unødvendigheter er i stor grad unngått. 10

11 Kapittel 2 Behovsanalyse 11

12 Kapittel 2 Behovsanalyse 2.1. Oppdragsgivers krav Oppdragsgiveren ønsker at vi skal lage en nettbutikk med en rekke funksjoner for administrator og kunder. Det innebærer funksjoner som er relatert til produkthåndtering, kundedatabaser, kampanjer, ordre og bestillinger, betalingsløsninger og stort sett alle andre funksjoner som er naturlig å ha med i en nettbutikk. I tillegg er det krav til sikkerhet, design og brukervennlighet. I og med at den forrige nettbutikken til oppdragsgiveren ble offer for et sikkerhetsbrudd, er det naturlig nok stilt krav til sikkerhet. Oppdragsgiver hadde også ønsker om at nettbutikken skulle se bra ut og være lett å bruke, både for administrator og kunder. Det er hovedsakelig to ulike fremgangsmåter for å løse oppgaven. Den ene innebærer at nettbutikken kodes fra grunn av slik at det blir en spesialtilpasset nettbutikk for kunden/oppdragsgiveren, mens den andre går ut på å ta utgangspunkt i et eksisterende rammeverk, for så å endre, tilpasse og videreutvikle dette slik at det når kravene som er satt. Oppdragsgiver hadde et ønske om at det ble benyttet en open source 1 -løsning som heter Zen Cart Våre krav Med oppdragsgivers ønsker og krav til prosjektet som ramme, spesifiserte vi våre krav til det endelige produktet. Vi var blant annet opptatt av å konkretisere kravet om brukervennlighet. W3C (World Wide Web Consortium) har en rekke krav og retningslinjer til hva som definerer god eller riktig nettside kode, struktur og design. Vi valgte å ta utgangspunkt i XHTML 1.0 strict [1], WCAG (Web Content Accessibility Guidelines) [2] og selvfølgelig korrekt kode for andre brukte kodespråk som PHP, CSS og SQL. I tillegg valgte vi å legge vekt på at nettbutikken måtte være universelt utformet i henhold til de lover og regler som trer i kraft fra 1. juli Vi har ingen ambisjoner om å ekskludere noen brukergrupper fra bruk av nettbutikken på grunn av dårlig design. Disse kravene ble satt for å definere og sikre graden av brukervennlighet på siden, i og med at dette i utgangspunktet var et løst definert ønske fra oppdragsgivers side. 1 Åpen kildekode som gjør det tilgjengelig for allmennheten og mulighet for å endre kildekode som en måtte ønske. 12

13 2.3. Brukervennlighet Brukervennlighet handler om at brukeren skal kunne utføre den oppgaven vedkommende ønsker. Dette kan være å finne informasjon, fylle ut et skjema, foreta et kjøp eller lignende. I tillegg ligger det i begrepet at redskapet for å utføre oppgaven skal være mest mulig intuitiv og selvforklarende. En av de mest populære bøkene innenfor faget brukervennlighet heter Don t make me think av Steve Krug *3+ og oppsummerer veldig greit hva det dreier seg om: Enkelt, tydelig og intuitivt. På nettet går alt fort, og som brukere vil vi videre så fort som mulig. Vi har ikke tid til nettsteder som ikke gir oss det vi er ute etter. En bruker som kommer innom et nettsted bruker toppen 4-7 sekunder før han eller hun klikker seg videre til neste sted. Det vil si at oppmerksomheten må fanges med én gang, og interessen vekkes allerede på første siden. Med andre ord må man gjøre alt så enkelt for brukeren som mulig. Her følger noen tommelfingerregler [3] for å skape en god nettside: Hva er formålet med nettsiden? Ha et mål, og fokuser på dette. Hva er det første de besøkende ser? Forsiden er alfa og omega. Ikke bland flere kategorier som tilsynelatende ikke hører sammen. Hvem sikter du deg inn imot? Ikke bland målgrupper. Er det uklart for brukeren hvor han/hun skal ta veien fra forsiden er løpet allerede kjørt. Forsiden vil ofte stå for 20 % 30 % av all trafikken du har og bør dermed vies ekstra mye tid. Husk at forsiden skal fortelle brukeren at han/hun har kommet til riktig sted, uten at brukeren trenger å tenke seg om. Brukere er veldig flinke til å skumlese nettsider [4]. De skanner siden, og merker ord som fanger oppmerksomheten deres automatisk. Eksempelvis kan det være salg, kjøp eller sex. Brukerne skanner også en nettside slik at akkurat det de er interessert i får oppmerksomheten, mens alt det andre blir sløret. Når brukeren trykker på en link, et menyelement, et bilde o.l. forventes det at noe skal skje. Eksempelvis om man trykker på tilbake -knappen i nettleseren forventer man å komme 13

14 tilbake til siden en nettopp var på, da vil mange finne det rart om du har en Tilbake knapp på siden din som tar deg til en annen side enn nettleserens tilbakeknapp ville gjort. Det finnes en hel del kjøreregler for hva som er forventet, og disse bør du følge så langt det lar seg gjøre. Dette går på plassering av knapper, elementer med mer. Om du velger å bytte plassering på Ok og Avbryt knappen i en dialogboks vil du fort merke at brukerne dine ikke greier å gjennomføre dialogboksen da de vil avbryte i god tro om at de har valgt ok. Her følger noen forslag [3] for et hensiktsmessig design: Menyer på topp og i venstre side. Viktige element øverst, nyeste element øverst. Innhold i midtkolonnen. Navigasjonselementer er statiske. Innhold som ikke gir brukeren noe ekstra bør fjernes, og innhold som ikke blir holdt oppdatert/relevant kan også ofte fjernes. Kvalitet fremfor kvantitet, også på nett Universell utforming. "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." (Rådet for funksjonshemmede, 1997 [5]) Figur 2: Det er blant annet viktig med universelt utformede nettsider for at hjelpemidler som talesyntese skal fungere optimalt 14

15 Begrepet "universell utforming" blir brukt synonymt med design for alle, universell design, inkluderende design og tilgjengelighet for alle. Hensikten med dette er å forenkle livet for alle ved å lage generelt gode produkter, kommunikasjonsmidler og bygde omgivelser. De skal kunne benyttes uten eller med små ekstrakostnader til spesialløsninger. Målgruppen for universell utforming er alle mennesker, i alle aldre, størrelser og med ulike ferdigheter. Når vi skal planlegge og utforme for alle, må vi legge til grunn hele befolkningens behov og ønsker: barn, voksne, eldre, kvinner, menn og personer med ulik etnisk bakgrunn. Hensynet til at funksjonsevnen varierer står sentralt når vi skal planlegge og utforme for hele befolkningen. Universell utforming er en tenkemåte i designprosessen som utformes slik at alle mennesker skal kunne bruke dem på en likestilt måte så langt det er mulig, uten spesielle tilpasninger eller hjelpemidler. Denne nye tenkemåten inneholder et sterkere likestillingskrav for personer med nedsatt funksjonsevne. Universell utforming betyr at god design både har et attraktivt utseende og er lett og behagelig å bruke. For å evaluere eksisterende utforming og veilede i designprosessen har en gruppe av amerikanske arkitekter, produktdesignere, ingeniører og forskere utarbeidet sju prinsipper for universell utforming. De er følgende[6]: Enkel og intuitiv i bruk - Utformingen skal være lett å forstå uten hensyn til brukerens erfaring, kunnskap, språkferdigheter eller konsentrasjonsnivå. Siden løsninger skal brukes av mange forskjellige grupper og folk med forskjellige forutsetninger, må alle løsninger være såpass lette å oppfatte at det ikke tar lang tid å skjønne hvordan man skal bruke løsningen. Forståelig informasjon - Utformingen skal formidle nødvendig informasjon til brukeren på en effektiv måte. Fleksibel i bruk - Uansett individuelle preferanser og ferdigheter, skal løsningen være tilgjenglig. Den synshemmede skal kunne høre, den hørselshemmede se og så videre. Utformingen skal tjene et vidt spekter av individuelle preferanser og evner. Det er mange forskjellige funksjonshemminger og aldri noen som er helt like. I henhold til hvert enkelt individs behov er det derfor viktig at alle ting blir utformet slik at det er 15

16 lett justerbart. Hvis ikke kan man ende opp med en løsning som fungerer for noen personer men som er helt ubrukelig for andre. Lav fysisk anstrengelse - Uformingen skal kunne brukes effektivt og bekvemt med minimum besvær. Minst mulig fysisk strev, effektiv og naturlig bruk. Det er viktig at løsningene krever minst mulig fysisk og mental kraft slik at brukeren ikke blir unødvendig sliten og utmattet fordi han eller hun må bruke løsningen. Størrelse og plass for tilgang og bruk - Hensiktsmessig størrelse og plass skal muliggjøre tilgang, rekkevidde, betjening og bruk, uavhengig av brukerens kroppsstørrelse, kroppsstilling og mobilitet. Toleranse for feil - Utformingen skal minimalisere farer og skader, og minimalisere utilsiktede handlinger. Like muligheter for alle - Utformingen skal være brukbar og tilgjengelig for personer med ulike ferdigheter. Poenget med loven er ikke å sette folk i bås. Alle mennesker skal ha like store muligheter til å gjøre hva de har lyst til med livet sitt og det er derfor viktig å fjerne flest mulig hindringer, slik at alle står likestilt. Diskriminerings- og tilgjengelighetsloven trådte i kraft den 1. januar 2009 i Norge. Påbudet omfatter all virksomhet som er rettet mot allmennheten, uavhengig av hva virksomheten gjelder og både offentlig og privat virksomhet er pålagt å ha universell utforming av virksomhetens «alminnelige funksjon». Dette er Norges versjon av en lov som krever universell utforming og likestilling for alle. Formålet med denne loven er å bryte ned hindringer for de med funksjonshemminger og å skape muligheter for et lettere liv. Loven krever at alle nye byggeplaner skal være universelt utformet. Loven omfatter også IKT. For nye IKT-løsninger gjelder plikten til universell utforming fra 1. juli Alle utforminger som ble utviklet før 7. januar 2011 skal være universelt utformet innen 1. januar

17 Kapittel 3 Prosjektutviklingsfasen 17

18 Kapittel 3 Prosjektutviklingsfasen 3.1. Fremgangsmetode Prosjektet krevde at en del ulike prosesser og sykluser måtte avvikles både før, under og etter selve arbeidet med produktet. Alt fra innhenting av informasjon til dokumentering av arbeid har vært viktige deler av prosjektprosessen. I tillegg har det vært nødvendig å definere en struktur på hvordan vi ønsket å løse oppgaven. Riktig fremgangsmetode, gruppestruktur og ansvarsfordeling har spilt en vesentlig rolle i prosjektets fremgang. I første omgang måtte vi komme frem til hva oppgaven innebar og definere noen krav til det ønskede resultatet. Det ble også viktig å avgjøre hvordan vi ønsket å nå disse målene. Vi ble avhengig av å evaluere ulike fremgangsmetoder og ta en avgjørelse basert på oppdragsgivers krav og ønsker, og vår egen vurdering av hva som ville gi best resultat. Denne prosessen resulterte i valg av bruk av en halvfabrikkert nettbutikk som vi ville utvikle videre. Mer om valget av ulike alternativer er beskrevet i kapittel 4. Etter at plattformen og utgangspunktet var funnet, var det behov for ytterligere å konkretisere et ønsket resultat Idéskapende arbeid I utviklingsprosessen av nettbutikken var det viktig å danne noen ulike bilder av hvordan et potensielt produkt skulle se ut i slutten av prosjektet. Enten det gjelder produktet i sin helhet, eller enkeltfunksjoner i produktet. Fra oppdragsgiver sin side lå et ønske om konkrete funksjoner som til sammen, i grove trekk, utgjør en nettbutikk. I tillegg ble det gitt en rekke eksempler på eksisterende nettbutikker med lignende aktivitet, som oppdragsgiver anså som gode eller enda viktigere fine nettbutikker. Vi søkte inspirasjon fra noen nettbutikker oppdragsgiveren likte spesielt godt, for eksempel legebutikken.no, cherokeeuniforms.com eller medicaluniforms.no. I tillegg til disse så vi på andre nettbutikker, for så å evaluere dem helhetsmessig og enkeltfunksjonsmessig. Vi diskuterte innad i gruppen hvilke funksjoner som kunne være hensiktsmessig å ha med i det kommende produktet, samt eventuelle funksjoner eller elementer som vi anså som viktig å unngå. 18

19 Fra vår side, som kompetente fagfolk innenfor feltet, ble det definert en rekke krav til produktet i henhold til brukervennlighet og valideringsstandard på kildekode og sideinnhold (blant annet W3C standarder og retningslinjer). Deretter ble det igangsatt en utforskning og eksperimenteringsprosess for å skape konkrete forslag til utseende. I første omgang ble det diskutert hvilke funksjoner fra Zen Cart som skulle anvendes/beholdes, hva som skal fjernes og hva som eventuelt skal legges til. Deretter ble plassering av elementer på sider og undersider diskutert. Denne funksjonsdesignprosessen resulterte i tre ulike forslag til design (noen endringer ble lagt til for å forsterke forskjellene mellom disse). For å kunne begrunne og argumentere for fordeler og ulemper, bra og dårlige sider ved designforslagene, ble en form for brukertest av de tre prototypene nødvendig. Brukertestingen vil bli beskrevet i kapittel 7. Med utgangspunkt i resultatene fra testingen, ble de funksjonene og designvalgene som viste seg å fungere best, implementert i en ny prototyp. Med funksjonaliteten til siden og plassering av elementer på plass, ble fokuset flyttet over på design av utseende og visuelle detaljer (farger, knapper, bilder og lignende). Som med all design, er det en god del retningslinjer også for utseende og fargevalg hos nettsider. Det er mange brukergrupper som det må tas hensyn til, samt mange feller en kan havne i som svekker helhetsinntrykket til brukerne. Konkrete valg med begrunnelse vil bli diskutert i kapittel Utviklingsarbeid Utviklingsarbeidet foregikk stort sett på skolens lokaler, enten enkeltvis med konkrete problemer, eller gruppevis med løsninger som krevde større avgjørelser eller diskusjon. Under de mer kreative og idémyldrende prosessene, var rask utvikling av enkle forslag og ideer en effektiv metode for å visualisere løsninger og gjorde det dermed lettere å vurdere dem. Det ble gjerne brukt penn og papir og andre enkle visualiseringsverktøy i tillegg til koding. Under utviklingsarbeidet var det essensielt med god forståelse for hvordan Zen Cart er bygget opp. Det er en god del retningslinjer og krav om hvordan komponentene i Zen Cart 19

20 skal være strukturert. For å kunne konstruere egne komponenter og elementer til nettbutikken, krevde det omfattende studering av eksisterende løsninger. I utviklingen av nettbutikken var fremgangsmåten basert på å konstruere løsninger på forslagene fra idéfasen. Dette ble avviklet punkt for punkt, enten å endre innstillinger i Zen Cart eller lage nye løsninger, slik at prototypene til slutt ble forvandlet til representanter for de ulike ideene fra idéfasen. Videre ble resultatene fra brukertesting av de ulike prototypene analysert og evaluert. Informasjonen fra brukertestene indikerte hvilke enkeltløsninger som fungerte. En nærmere beskrivelse av resultatene fra brukertesten kommer i kapittel 7. Ut i fra dette ble de funksjonene som kom positivt ut av testingen, sydd sammen til en ny prototyp. Deretter ble denne evaluert av oppdragsgiver for at han skulle kunne komme med innspill og ønsker, for å sikre hans tilfredsstillelse. Avslutningsvis gjenstod en omfattende prosess med finjustering, feilsøking og debugging 2. Dette er alltid tidkrevende prosesser hvor endringer eller justeringer på ett felt, gjerne påvirker eller ødelegger opptil flere andre elementer i en nettside Ferdigstilling Etter at nettbutikken ble ferdig funksjonelt sett, gjensto en avsluttende prosess som innebar å klargjøre den for ekte kunder og ordre. Oppgaver som blant annet å koble opp nettbutikken mot betalingsløsningen, legge inn produkter og strukturere produktkatalogen krevde en trinnvis gjennomgang med oppdragsgiver. I tillegg var det essensielt å lage en brukermanual slik at oppdragsgiver selvstendig kan drifte nettbutikken videre Agile arbeidsmetoder Vi har, med utgangspunkt i en mindre konkret definisjon av oppdragsgiverens ønsker om ferdig produkt, arbeidet på en dynamisk og lite rigid måte. I forhold til mer konservative produktutviklingsmetoder, har vi ikke hatt et konkret bilde av hvordan det ferdige resultatet skal se ut fra begynnelsen av. Dette har resultert i at fremgangsmetoden og utviklingen av produktet har foregått i kortere sykluser, ofte i form av produksjon, etterfulgt av evaluering og en avgjørelse om det skal beholdes og arbeides videre med, og i så fall eventuelle endringer, eller om det skal forkastes. Denne arbeidsmetoden har blant annet tillatt 2 Validere kildekode og rette opp feil 20

21 oppdragsgiver å komme med ønsker og forslag til detaljer i løpet av utviklingen, i og med at oppgaven i utgangspunktet ikke var konkret i forhold til de designmessige aspektene ved nettbutikken. En dynamisk og agil arbeidsmetode har også tillatt oss å flytte ressurser til arbeidsoppgaver som har vist seg å være mer kompliserte eller tidkrevende enn opprinnelig antatt. En jevnlig oppdatering av styringsdokumenter har sørget for at de stort sett til en hver tid har vært aktuelle og behjelpelige som støtteverktøy i utviklingsprosessen Dokumentasjon av arbeid Det å dokumentere vårt arbeid er viktig av flere ulike grunner. Primært skal prosjektet dokumenteres for å kunne vise hva prosjektet er, har vært og hvordan det har utviklet seg. I tillegg er det viktig å dokumentere selve utviklingen av prototyper og nettbutikken slik at det kan vises til hvilke valg som er tatt og hvor i prosessperioden det ble avgjort. Dette er også viktig i tilfelle det skulle bli nødvendig å rekonstruere nettbutikken i fremtiden. Enda mer aktuelt er det at dokumentasjonen nærmest fungerer som en fremgangsbeskrivelse for hva som må gjøres når den endelige prototypen skal flyttes fra våre lokale arbeidsservere og ut på webhotellet. I tillegg blir det produsert en slags brukermanual for oppdragsgiver, slik at endringer kan gjøres i fremtiden uten nødvendigvis å måtte sette seg fullstendig inn i hvordan nettbutikken er bygget og henger sammen. 21

22 Kapittel 4 - Research 22

23 Kapittel 4 Research 4.1. Kartlegging av ulike løsninger Vi var avhengig av å undersøke og evaluere ulike alternativer av ferdige nettbutikkløsninger. Målet her er altså å finne en slags løsning som vi heller kunne bygge ut i fra, og heller fokusere mer på selve brukervennlighetsaspektet og besøksopplevelsen enn bare å fokusere på å perfeksjonere koding. Vi fant en del forskjellige nettbutikkløsninger, men måtte sile ut en del av dem og endte opp med fire hovedløsninger som vi kunne tenke oss å bruke. Vi kom fram til tre open source løsninger og en kommersiell løsning som koster penger, med forskjellige fordeler og ulemper Lærdom fra nettbutikkene Etter kartleggingen av de ulike nettbutikkene satt vi oss ned og individuelt testet de forskjellige nettbutikkløsningene. Bigcommerce ble ikke testet siden det var en kommersiell løsning, dermed så vi heller på forskjellige butikker som brukte denne løsningen og fokuserte heller på andres brukeropplevelse av produktet oscommerce: oscommerce ("open source Commerce") er en gratis nettbutikkløsning som hvem som helst kan laste ned. OsCommerce kan installeres på servere som har støtte for PHP og tilgang til en MySQL databaseserver. OsCommerce ble startet i mars 2000 i Tyskland. I august 2008 var det over live nettsider som benyttet seg av programmet [7]. Figur 3 viser en demonstrasjonsnettbutikk hentet fra oscommerce.com. 23

24 Figur 3: oscommerce I Tabell 2 er det gitt en oppsummering av fordeler og ulemper av oscommerce. Tabell 2: oscommerce Fordeler: - Gratis, open source - Godt utvalg av add-ins Ulemper: - Utilfredsstillende support - Sikkerhetsproblemer - Vanskelig å designe, ingen templates - Vanskelig å oppgradere Zen Cart: Zen Cart er en nettbutikkløsning og er PHP-basert, med en MySQL database og HTML komponenter. Støtten gis for mange språk og valutaer, og det er fritt tilgjengelig under GNU General Public License. Zen Cart er forgrenet fra oscommerce som et eget prosjekt i I tillegg til noen estetiske endringer, skiller Zen Cart seg ut med arkitektoniske endringer (for eksempel et mal-system) og flere funksjoner inkludert i kjernen. Utgivelsen av 1.3.x-serien differensierte ytterligere Zen Cart ved å flytte mal-systemet fra sin tidligere tabellbaserte layout til en som er i stor grad er CSS-basert [8]. Figur 4 viser standard templaten 3 som følger med Zen Cart. 3 Designmal 24

25 Figur 4: Zen Cart, Classic Template I tabell 3 er det gitt en oppsummering av fordeler og ulemper med Zen Cart-løsningen. Tabell 3: Zen Cart Fordeler: - Gratis, open source - Veldig stabil plattform - Enkel å installere - Enkel å oppgradere - Integrerte add-ins fra oscommerce - Templates, lett å designe - God support - Norsk utvikler, språkpakker - Oppdragsgiver har tidligere erfaring med systemet Ulemper: - Rotete administrasjonsgrensesnitt på enkelte områder - Trenger add-in for betaling med VISA og interaksjon med BBS - Begynner å bli utdatert pga. sosiale medier (Twitter, Facebook) Magento Magento er en ecommerce webapplikasjon som ble lansert den 31. mars Magento kommer i flere ulike utgaver til ulike formål. Magento finnes både som open source og som 25

26 betalingsversjon. Ved den kommersielle løsningen er support og en rekke andre tjenester inkludert. Magento er en av de raskest voksende ecommerce løsningene som finnes på markedet [9]. Figur 5 viser en demonstrasjonsversjon av Magento. Figur 5: Magento, Demo Store Tabell 4 viser fordeler og ulemper med Magento. Tabell 4: Magento Fordeler: - Gratis, open source - Svært jevnlige sikkerhetsoppdateringer - Moderne, strømlinjet - Vakker standard-template - Siste teknologi; HTML/PHP 5, Zend Ulemper: - Enormt mye kode, vanskelig å tilpasse - Lite dokumentasjon, bratt lærekurve - Treg, krever dedikert server 26

27 Bigcommerce Bigcommerce er en nettbutikkløsning som ble lansert i 2003 og har nå over kunder, inkludert Dell, Kraft, Ticketmaster, Wayne Gretzky, Virgin og MediaTemple, samt tusenvis av små og mellomstore bedrifter, gründere og universiteter. BigCommerce er enkelt å bruke og gjør det enkelt og rimelig for deg å selge på nettet uten behov for fulle HTML-kunnskaper eller fancy designferdigheter [10]. Figur 6 demonstrerer standardversjonen av Bigcommerce. Figur 6 Bigcommerce, Demo Store I tabell 5 vises både fordeler og ulemper med Bigcommerce. Tabell 5: Bigcommerce Fordeler: - God support 24/5 - Sørger for enkel kobling til sosiale medier - Ferdig satt opp for transaksjoner med VISA, MasterCard, PayPal - Mange, gode templates, drag n droptilpasning av layoutet Ulemper: - Kommersiell og koster penger, $ 24 og oppover - Vanskelig å håndtere svartelister 27

28 - Lett å få den shippingen du ønsker, mange leverandører - Gode sikkerhetsrutiner 4.3. Valg av Zen Cart Vi endte opp med å basere nettbutikken vår på Zen Cart. Den viktigste grunnen til at vi valgte Zen Cart som vår løsning var på grunn av vår oppdragsgiver. Før vi begynte å undersøke hvilken løsning vi skulle benytte, hadde vi et møte med oppdragsgiver. Her kom det frem at han hadde tidligere erfaring med akkurat denne type nettbutikkløsning. Sånn sett så har vi hatt Zen Cart i bakhodet hele tiden under kartlegging og testperioden siden denne informasjonen kom fram relativt tidlig. Selv om vi visste dette så følte vi at det også var vårt ansvar å se på flere løsninger og sette dem opp mot hverandre for å finne den beste løsningen for vår oppdragsgiver og vårt prosjekt. Det var flere gode grunner til at vi valgte Zen Cart som vår nettbutikkløsning, og en av dem var at vi kunne gjøre mye for å fikse de få ulempene som allerede eksisterte med løsningen i forhold til de andre. I tillegg til dette så var det også mye manglende support på nettet. Det tar for mye tid, så derfor er det heller mer optimalt å kunne utvikle videre på en løsning som ikke har en for bratt læringskurve, ser estetisk bra ut, har mye bra funksjonalitet og har mye support på sitt forum på nettet. Etter at kom frem til at Zen Cart tilfredsstilte våre krav til løsning, så var det også mange andre mindre essensielle, men fortsatt viktige grunner til at vi gikk for denne open source løsningen. For det første så måtte løsningen ha en enkel administrasjonsside hvor vår oppdragsgiver ville støte på minst mulig forvirring og problemer. Det eneste som kan føre til litt forvirring er at Zen Cart har en rekke funksjoner som man egentlig ikke trenger, men dette kan fjernes uten alt for mye problemer. En annen avgjørende og praktisk funksjon med Zen Cart er, siden den er bygd opp på den måten den er, så kan man legge til såkalte add-ins. Dette er open source-funksjoner som man bare kan legge til i butikken relativt enkelt. For å få en mer avansert innloggingsfunksjon for eksempel, så trenger man bare å laste ned en zipfil 4 med alle filene man trenger, og legger dem til i de riktige mappene inne i hierarkiet, og aktiverer funksjonen inne fra administrasjonssidens verktøydel. Det er her den enorme 4 Komprimert filarkiv 28

29 støtten fra Zen Cart sine egne forumer spiller sin rolle. Siden det er open source, kan hvem som helst komme med nyskapende løsninger som de tilbyr andre helt gratis. 29

30 Kapittel 5 Zen Cart 30

31 Kapittel 5 Zen Cart Zen Cart er et såkalt CMS (Content Management System) rettet spesifikt mot nettbutikker. Det betyr at det er et system hvor man kan ha stor kontroll på innholdet på en nettside ved hjelp av et brukergrensesnitt i form av en administrasjonsside (se figur 7). Alt innholdet på nettsiden er lagt inn i egne tabeller i en database, og alt styres i form av SQL-spørringer 5 mot denne. [11] Selve administrasjonssiden til Zen Cart er bygget opp i tabeller og en rekke undersider. Med administrasjonsdelen menes et eget grensesnitt i Zen Cart i selve nettleseren hvor man trenger et eget brukernavn og passord for å logge seg inn. Det aller meste styres her, alt fra plassering av sidebokser 6 til justering av bredde på høyre og venstre sidemarg. Man får opp alle kunder som registrerer seg i nettbutikken og alle bestillingene de sender, og man kan endre på leveringsstatus o.l. Det er også implementert et svært godt e-postsystem, som helautomatisk leverer beskjeder ved evt. endringer ved bestillings- eller leveringsstatus for varer. Helt essensiell er også muligheten for å legge inn nye produkter, og å styre tilbud og kampanjer. Figur 7 - Zen Cart administrasjonsside 5 Et eget språk for å kontakte og utføre kommandoer mot en database 6 Menyer og funksjonalitet rammet inn bokser i sidemargene, som kan slås av og på etter behov 31

32 Figur 7 viser oppsettet til administrasjonssiden til Zen Cart. Siden er enkelt bygget opp med en tabell for å gi god oversikt i de ulike undersidene, og en horisontal hovedmeny med tilhørende undermenyer. Det gjør at vi som brukere av Zen Cart har ganske mange muligheter for tilpasning. Nesten hele layouten på nettbutikken kan styres gjennom administrasjonsdelens forskjellige innstillinger. Zen Cart er også bygget opp rundt templater eller templates. Dette er designmaler som gjør det svært enkelt å endre sidens utseende og hvordan innholdet på de forskjellige undersidene blir presentert. På den måten unngår man å endre selve skjelettet som ligger i bunn. Man kan derfor lage sin egen mal med tilhørende php- 7, css- 8 og bildefiler. Man bygger opp et filtre med kun de filene man ønsker å forandre, mens alle de andre filene blir automatisk hentet inn fra en standardmal som følger med Zen Cart. Det gjør Zen Cart til et skalerbart og svært fleksibelt verktøy. Figur 8 viser standardmalen. Figur 8 - Standardmalen; viser de ulike elementene på siden 7 Programmeringsspråk for dynamisk webinnhold 8 Programmeringsspråk for presentasjon av webinnhold 32

33 Zen Cart har også et eget system for å legge inn produkter i en SQL-database. I denne tidlige fasen av prosjektet la hvert av gruppemedlemmene inn fiktive varer i databasen i hvert vår nettbutikk. Dette for å kunne få visualisert hvordan en endelig løsning vil kunne se ut. Vi valgte å løse oppgaven ved å lage et eget templat, samt endre på noe av funksjonaliteten i Zen Cart. For å oppnå dette, ble vi dermed nødt til å gå inn i kildekoden og endre den manuelt med en tekstbehandler. [12] Det var ikke alt som så ut slik som vi ønsket, så noen endringer i skjelettet ble utført i utvikling av prototypene, som vi kommer tilbake til i et senere kapittel. Men det er noen ulemper å sette fingeren på. Zen Cart består av i overkant filer, noe som krever en bred forståelse av hvordan alt er bygget opp og henger sammen. Men selv om det er et stort system, så er det slik at ikke all funksjonalitet er nødvendig for driften av Medwear.no. Det er med andre ord en del overflødig funksjonalitet, men med tanke på fremtidige oppdateringer er det kanskje ikke noe stort poeng å fjerne dette. 33

34 Kapittel 6 Prototypene 34

35 Kapittel 6 Prototypene 6.1. Hvorfor prototype? En prototype er en foreløpig utgave av et produkt. Prototypen lages før man starter en produksjon av et produkt. Formålet med en prototype er å demonstrere og teste funksjon og design. I vårt tilfelle skal produktet være en nettbutikk som selger medisinsk utstyr og klær. Vi valgte å lage ulike fungerende versjoner av en ferdig nettbutikk. Grunnen til at vi valgte denne tilnærmingen for å løse oppgaven, er fordi vi da kan se ulike versjoner av et produkt med samme hensikt eller formål, nemlig å selge produkter. Å utvikle prototyper er praktisk fordi man på et tidlig stadium, før implementering, kan luke ut feil og mangler. Dette reduserer risikoen for å måtte gjøre potensielt dyre endringer etter at butikken er oppe og kjører. Jo tidligere feil oppdages, desto bedre og billigere. Vi valgte å lage relativt avanserte prototyper fremfor såkalte low-fidelity-prototyper. Lowfidelity-prototyper kan for eksempel bestå av papp og papir som kan representere sider, undermenyer og knapper. Grunnen til at vi valgte å lage prototypene rett på datamaskinen og ikke med papir, var at man da kunne teste i et virkelighetsnært scenario. Vi ville lage lavkvalitetsversjoner av nettbutikkene ved å bruke HTML, PHP, CSS og SQL med én gang. Papir og penn ble dermed kun brukt til å skissere ideer for å hjelpe til med formidling og kommunikasjon innad i gruppen, fremfor å benytte dette som hovedverktøy til prototypene Utvikling av prototyper For å finne ut hvordan en endelig nettbutikk skal kunne se ut i slutten av utviklingsarbeidet, valgte vi å lage hvert vårt forslag til løsninger. Som nevnt i tidligere kapitler har vi valgt å bruke Zen Cart som et rammeverk for nettbutikken. Måten vi gikk frem på i begynnelsen av prosjektet, var at alle gruppemedlemmene installerte Zen Cart på hver sin server og satte seg inn i hvordan Zen Cart var satt opp og hva slags muligheter for tilpasning det hadde. Det viste seg at Zen Cart var ganske plastisk, og vi fant en rekke måter å flytte på sidebokser og knapper og så videre i administrasjonsdelen av Zen Cart. Tidlig i prosjektet gikk mye av tiden til å tilegne oss kunnskap om Zen Cart. Dette var et helt nytt system for oss, med en mengde funksjoner som var helt ukjente. Derfor tok det et par 35

36 uker å bli ordentlig kjent med dette verktøyet. Vi ville antakelig brukt betydelig lengre tid på å bygge en nettbutikk helt fra bunnen av. Samtidig kunne alle fem gruppemedlemmene lære seg systemet på egenhånd, og dermed hjelpe hverandre hvis én kunne noe de andre ikke visste. Dette viste seg å fungere bra, og synergieffekten av en slik arbeidsmetode gjorde at alle etter hvert ble kompetente i Zen Cart Fokusering på tre prototyper Omsider hadde vi utarbeidet fire forskjellige prototyper av en nettbutikk, noen med høyere modningsnivå enn andre. Det virket hensiktsmessig på nåværende tidspunkt å forkaste en eller flere av prototypene, før brukertesting kunne begynne. Brukertesting vil bli beskrevet nærmere i kapittel 7. Etter at vi hadde produsert ulike forslag til nettbutikker, så de slik ut: Figur 9: Prototyp 1 36

37 Figur 10: Prototyp 2 37

38 Figur 11: Prototyp 3 Figur 12: Prototyp 4 Butikkene er i varierende grad estetisk tilfredsstillende. På nåværende tidspunkt fokuserte vi hovedsakelig på funksjon og innhold fremfor utseende. 38

39 Nå var det på tide å fokusere videre på tre prototyper. Vi valgte å slå sammen Prototyp 3 og 4 (senere kalt bare Prototyp 3 (P3)), da disse var ganske like i utseende og funksjon. I tillegg valgte vi å beholde Prototyp 1 og 2 (henholdsvis P1 og P2). Dermed satt vi igjen med tre prototyper. Grunnen til at vi ville redusere antallet prototyper før brukertesting, var at det ville bli for tidkrevende og lite hensiktsmessig å teste mange prototyper. Tre var tilstrekkelig for å kunne trekke ut relevante og målbare data i en brukertest. Færre enn tre mente vi ville bli for få, siden det da ville bli vanskelig å teste ut alle forslagene til funksjoner. Det er viktig å få dekket mest mulig av funksjonalitetsspekteret i brukertestene. Vi ønsket å få et høyere nivå på de tre prototypene vi satt igjen med på nåværende tidspunkt, før vi satt i gang med å teste ut butikkene på testpersoner Prototyp 1 Den første prototypen (P1) bar preg av å være en relativt bred nettside. Margene mellom nettleservinduet og prototypens innhold er liten, slik at alt innholdet på siden trekkes opp i midten. Tanken var at dette reduserte eller fjernet behovet for å scrolle (litt avhengig av nettleservinduets dimensjoner) opp og ned for å få tilgang på nettbutikkens innhold, samtidig som at siden fikk et luftig og oversiktlig preg. I tillegg ble en kolonne plassert til høyre i grensesnittet, hvor en søkefunksjon og lenker ble plassert. Her kunne også tilleggsfunksjoner enkelt plasseres ved senere anledninger. Tanken var å kunne sammenligne resultatene fra brukertestene og vurdere om en høyreplassert meny ville være like intuitiv å bruke som en mer tradisjonell venstreplassert meny. Innloggingsfunksjonen ble plassert lengst opp til venstre, hvor den er synlig uten å ta unødvendig fokus. I og med at handel i en nettbutikk krever personopplysninger, er det krav til en form for innloggingsfunksjon. I og med at dette er et krav, vil brukeren automatisk bli bedt om enten å logge inn eller registrere seg ved forsøk på å gjennomføre en handel, og dette blir dermed ikke en funksjon som er essensiell for kunden i hovedgrensesnittet. Parallelt er det en såpass viktig funksjon at den ikke blir fjernet. En opplisting av produktkategoriene (i form av trykkbare lenker) var sentralt plassert relativt langt opp i midten av skjermbildet. Disse sett sammen med søkefunksjonen utgjør hovednavigeringskontrollene for å søke blant eller se på produktene. I tillegg finnes det en visningsfunksjon, som tilfeldig plukker ut produkter fra produktdatabasen og lister dem opp 39

40 på blant annet hovedsiden. Dette er et konkret ønske fra oppdragsgiver, som vil vise frem produkter for økt mersalg (dette er dermed også implementert i alle prototypene) Prototyp 2 Den andre prototypen (P2) hadde i forhold til den første, generelt større fonter. Primært skulle dette sørge for større grad av lesevennlighet, men det resulterte også i at siden fikk et mer kompakt uttrykk. Generelt for alle prototypene ble det vektlagt å fjerne mest mulig irrelevant og forstyrrende elementer fra grensesnittet. Nødvendigheten av dette ble tydeliggjort i prototyp to, hvor fontstørrelsen risikerte å gi et inntrykk av en overfylt side, hvor informasjon er stappet inn. Valgmenyen ble mer tradisjonelt plassert i en kolonne på venstre side, og inneholder flere valgmuligheter for raskere å gi kunden tilgang til ulike funksjoner eller undersider. I tillegg er det nødvendig å kompensere for fjerningen av søkefunksjonen. Lenkene for innlogging ble i forhold til den første prototypen flyttet over til høyre side for å stå mer på egenhånd. Tanken var at dette skulle gjøre den synligere. I tillegg ble det lagt til en ekstra lenke til innloggingsmiljøet i velkomstteksten som er det første sideinnholdet som møter kunden. Oppdragsgiver forespurte en sentralt plassert bildefremvisning som skal rullere på bilder av produkter fra nettbutikken. I prototypen ble dette plassert øverst på siden slik at det ikke skulle komme for mye i fokus i forhold til resten av butikkens innhold. Som i den første prototypen har denne også en listing av kategorier i midten plassert over sideinnholdet. Tanken er som med innloggingslenkene, at flere veier til samme mål øker effektiviteten til brukeren. Med noe større marg enn den første prototypen, større skrift og en meny på venstreside med flere valgmuligheter, ble nettsiden lengre. Avhengig av brukerens nettleser og zoom var det normalt sett ikke plass til hele grensesnittet i et standard nettleservindu (vertikalt sett). Ulempen er at siden krever litt scrolling, men all relevant informasjon finnes i midten. Informasjonen som er plassert nederst på siden kan sies å være for mer spesielt interesserte. Fordelene er en kompakt og lesevennlig side som ikke har for mye mellomrom mellom elementene og sideinnholdet. 40

41 Prototyp 3 I den siste prototypen (P3) har det rullerende bildeframvisningen en mer sentral plassering på hovedsiden (til gjengjeld er det ikke til stede på andre undersider). Det er også lagt til to kolonner med informasjon på hver sin side av sidens hovedinnhold. På grunn av tradisjonelle menyplasseringer er den viktigste informasjonen lagt i kolonnen til venstre, mens tilleggsinformasjon og lenker er lagt i høyre kolonne. Helt øverst er det plassert en list som innholder innloggingslenken på venstre side, samt et søkefelt på høyre side. Det er tenkt at dette er det logiske utgangspunktet for brukere som ikke finner det de er på jakt etter ved første øyekast. Den siste prototypen har store marger som resulterer i at grensesnittet ligger midt på brukerens skjerm. Unnlatelsen av overflatisk tekst og informasjon, sammen med brede marger sørger for at avstanden mellom elementer er kort og det går derfor raskt å orientere seg på siden. I neste kapittel vil vi redegjøre for hvorfor og hvordan vi gjennomførte brukertestene av de forkjellige prototypene. 41

42 Kapittel 7 Brukertesting 42

43 Kapittel 7 Brukertesting 7.1. Brukertesting Vi har laget tre prototyper. Disse er tre forskjellige nettbutikker med forskjellig design og funksjonalitet. For å finne ut hvilken av prototypene vi ville fortsette å utvikle, var det fornuftig først å gjennomføre en brukertest. Hensikten med brukertesting er å få reell tilbakemelding fra ekte personer. Utviklerne av et produkt sitter ofte inne med mer kunnskap og kompetanse om produktet enn lekmenn. Produktet, f.eks. en applikasjon, eller i dette tilfellet en nettbutikk, kan inneha svakheter som utviklerne selv ikke oppfatter. Grunnen til at utviklerne kanskje ikke oppfatter alle manglene ved produktet sitt, er at de tenker på en annen måte enn mennesker som ikke er vant til samme fagfelt. Utviklerne kan ha "sett seg blinde" på produktet, og overser feil og svakheter. Brukertesting innebærer som sagt at en utenforstående bruker som ikke har tidligere erfaring med det aktuelle produktet/prototypen, bruker denne i et testmiljø. Under en brukertest samler arrangørene data fra testen ved å observere brukerne i aksjon. Avhengig av hva som testes og hvorfor, er det mange mulige ulike måter å gjennomføre brukertester på. En brukertest kan for eksempel ha som hensikt å skaffe statistisk grunndata, hvor kvantitet er en vesentlig faktor (mange brukere). I andre tilfeller kan det være mer relevant med grundigere brukertester av færre brukere, for å skaffe en annen type informasjon. For eksempel i brukervennlighetssammenheng hos nettsider er det viktigere å avdekke elementer som svekker nettsidens helhetlige brukervennlighetsgrad. Jacob Nielsen [4] sier at man ikke trenger veldig mange testpersoner, i motsetning til hva mange kanskje tror. Han sier i Jakob Nielsen's Alertbox, 19. mars, 2000 at man ikke trenger mer enn fem testpersoner for å avdekke brukervennlighetsproblemer. Det er mye bedre å ha få testpersoner på mange tester, enn mange testpersoner på få tester. Ifølge Nielsen [4] lærer utviklerne veldig mye nytt på testperson 1, 2 og 3, men så begynner testpersonene å gjøre de samme "feilene" som de foregående testpersonene. 43

44 Figur 13: Nielsen, Jakob, and Landauer, Thomas K.: "A mathematical model of the finding of usability problems," Proceedings of ACM INTERCHI'93 Conference (Amsterdam, The Netherlands, April 1993), pp ) [19] Figur 13 viser en graf over prosentvis avdekking av brukervennlighetsproblemer i forhold til antall brukere som tester en nettside. Etter fire testpersoner har man avdekket tre fjerdedeler av problemene en nettside har. Etter det vil flere testbrukere riktignok avdekke enda flere mangler, men særlig kostnadseffektivt er det ikke. På grunnlag av dette valgte vi å bruke fire testpersoner til å teste alle de tre prototypene. Under en brukertest er det viktig at situasjonen er mest mulig naturtro. Det faktum at brukeren tester noe ukjent i et brukertestmiljø med observatører kan påvirke testbrukerens prestasjoner og det er derfor viktig at brukertesten er godt forberedt. Det er vanlig at en testleder har rolle som guide eller veileder for testbrukeren gjennom utføringen av testen. Testlederens rolle er med på å sørge for at aktiviteten er relevant og at gjennomføringen belyser relevante felt for brukertestens formål. Det er viktig at testlederen ikke påvirker testbrukeren på en måte som setter spørsmål ved resultatets validitet. For å få ut noen relevante data å analysere, valgte vi å gjennomføre testene på ilaben 9, hvor det var en såkalt eye tracker. Under vil vi beskrive hva en eye tracker er. Senere vil vi redegjøre for hvorfor vi ville bruke den i brukertesten, i et HCI (human-computerinteraction)-perspektiv. 9 Interaksjonslaboratoriet på høyskolens lokaler 44

45 Ved slike brukertester er det avgjørende at rekkefølgen av butikkene blir tilfeldig, siden testpersonene "lærer" av den foregående butikken. Selv om alle prototypene har forskjellig layout, er de bygget over samme lest, nemlig Zen Cart, så visse elementer kan testpersonene gjenkjenne. Derfor gjorde vi det slik at testpersonene ikke fikk prototypene i samme rekkefølge. Ved observasjon under en brukertest generelt er det gjerne benyttet flere ulike midler og metoder for å samle data. Det er vanlig at flere i utviklingsteamet observerer hele brukertesten. I tillegg er dette ofte assistert av elektroniske opptaksenheter som for eksempel kameraer, programmer som kjører i bakgrunnen, polygrafer 10 eller andre instrumenter som måler fysiologiske reaksjoner hos testbrukeren. Disse benyttes for å hente inn ulik relevant informasjon om brukeren ved avviklingen av en brukertest. Figur 14: Testperson på ilab, med eye tracker 7.2. Eye tracker Eye trackeren leveres av Tobii, som er ledende på slik teknologi [13]. Eye trackeren har en rekke bruksområder. Til personer med funksjonshemninger brukes den som et hjelpemiddel for å få tilgang til enheter for kommunikasjon og databehandling, i form av øyestyring. Den kan også brukes til å undersøke øyebevegelser på en dataskjerm for å teste nettsiders eller programmers brukervennlighet og layout. Det er til det sistnevnte formålet vi har benyttet oss av eye trackeren. Eye trackeren er en modul bestående av et kamera med to infrarøde lys, som monteres under en PC-skjerm, og kobles til en standard USB-port. Den fungerer ved at IR-lys sendes direkte inn i testpersonens øyne. Mye av IR-lyset sendes da tilbake fra netthinnen og ut av pupillen igjen. Pupillen oppfattes som en veldefinert, lys sirkel. Refleksjonen som dannes på hornhinnen, måles også av eye trackeren. Metoden kalles for 10 Løgndetektor 45

46 hornhinnerefleksjon/pupillsenter -metoden (se fig. 15), og måler testpersonens fikseringspunkter på en PC-skjerm. Med fikseringspunkter menes hvor på skjermen vedkommende til enhver tid ser. Ved hjelp av et program på PC en (Tobii Studio), kan man generere en god mengde statistikk og skjermvideoer, for på den måten å ha et godt grunnlag for videre analyse. Teknikken brukes til å måle både individets fikseringspunkt, samt i hvilken rekkefølge han/hun fokuserer på forskjellige steder på skjermen. Å spore eller følge en brukers øyebevegelser kan hjelpe HCI-forskere å forstå visuell informasjonsprosessering og faktorene som spiller inn på brukervennligheten av systemgrensesnittet. På denne måten kan opptak av øyebevegelser gi en objektiv grensesnittevaluering, som kan gi utviklere viktig informasjon om hvordan man kan utvikle systemer (herunder nettsider) som er mest mulig brukervennlige. Figur 15: Hornhinnerefleksjon/pupillsenter-metoden 7.3. Hvorfor bruke Eye tracker til vårt prosjekt? Som nevnt over er det nyttig å måle en testpersons øyebevegelser for å få et objektivt innblikk i hva brukeren faktisk ser etter på en nettside. I analysen av eye trackerdataene kan man ramse opp ti aspekter som er interessante [14]. 1. Lange fikseringer (Interesse eller forvirring) 2. Back-track saccade, altså støtvise og uregelmessige øyebevegelser (Muligens forvirring) 3. Ser ikke på elementer på siden 4. Søkende blikk heller enn lesende blikk 5. Frem og tilbake mellom to objekter (foretar valg eller sammenligning? Er noe forstyrrende?) 46

47 6. Første sted bruker ser (hva tiltrakk deres oppmerksomhet?) 7. Siste sted brukeren ser (Hvorfor de mistet interessen?) 8. Når bruker foretar valg, fikseringer tilbake til et objekt, og så et siste skann over siden før han gjør et valg 9. Leser overskrifter og underoverskrifter men ikke mer (Kjedelig?) 10. Interaksjon, f.eks. å følge en asterisk til en fotnote, eller en referanse i teksten til et bilde eller annet element En eye tracker genererer altså hvor og når og i hvilken rekkefølge en person ser på et nettsted. Disse dataene kan visualiseres på en rekke måter. Dette var årsaken til at vi ville bruke eye tracker for å teste personene. Det er viktig å poengtere at eye trackerinformasjonen kommer i tillegg til intervjusvarene. Ved hjelp av eye tracker-dataene ville vi finne ut to ting: 1. Hvor/når/hvordan ser brukeren på siden? 2. Samsvarer det brukeren sier at han/hun gjorde med det han/hun faktisk gjorde? Spesielt i forhold til oppgaven og hva brukeren forsøkte å gjøre/finne Hypoteser Gruppen formulerte tre hypoteser angående layouten på de tre prototypene: 1. Brukervennligheten rundt innlogging er nært knyttet opp mot erfaring fra tidligere nettsteder. Vi mener at det er sannsynlig at når brukere besøker et nettsted for første gang, bruker de erfaringer fra nettsteder de kjenner fra før til å orientere seg. Det er rimelig å anta at brukerne ser etter kjente elementer, som for eksempel en tekstboks til å taste inn brukernavn. Det er også sannsynlig at brukerne av nettstedet leter etter elementene på steder de er vant til at de befinner seg. 2. Navigasjonsmenyen skal være plassert øverst til venstre. Jacob Nielsen har kommet frem til at brukere ofte leser nettsider i en F-form [15]. Figur 16 illustrerer med såkalte heatmaps 11, generert av en eye tracker, hvor fokus hos 11 varmekart som indikerer hvor lenge fokus har vært i ulike områder på skjermen. 47

48 brukere som leter gjennom tekst primært er øverst og horisontalt ut fra venstre mot høyre og vertikalt fra topp til bunn. Figur 16: Heatmaps av søking i tekst, "Eyetracking Web Usability", New Riders Press December 14, 2009 Ut fra Nielsens studier, mener vi at det vil være fornuftig med å ha navigasjonsmenyen øverst til venstre. 3. For mange menyer og for mange elementer på samme side er forvirrende. Dette har med prinsippet med information overload å gjøre, et begrep som først ble brukt av Alvin Toffler i boken Future Shock [16]. Information overload kan gjøre brukeren passiv og hjelpesløs, og kanskje også frustrert. Mye informasjon er ikke god informasjon Metode Her vil vi redegjøre for gjennomkjøringen av brukertestene i kortversjon. For fullstendige intervjusvar og personalia fra de fire testpersonene, se vedlegg. Som nevnt hadde vi tre nettbutikkprototyper. Vi kalte dem henholdsvis Prototyp 1, Prototyp 2 og Prototyp 3. Testpersonene nummererte vi Testperson 1, - 2, - 3 og - 4. Figurene 17, 18 og 19 viser skjermbilder av nettbutikkene rett før brukertestingen startet. 48

49 Figur 17: Prototyp 1 49

50 Figur 18: Prototyp 2 Figur 19: Prototyp 3 50

51 Testen forgikk ved at testlederen leste opp en liste med oppgaver eller scenarioer som testpersonen skulle gå igjennom. Tabell 6 viser scenarioene/oppgavene som testbrukerne skulle gjennomføre og hvorfor. Tabell 6: Brukertestscenarioer Oppgave Detaljer Hensikt 1. Logge inn: Brukernavn: bruker21@gmail.com Passord: passord21 Målet med dette scenarioet er å teste innloggingsknappens plassering for å se hvor enkelt brukerne klarer å finne frem og logge seg inn. 2. Finne legefrakk: Finn legefrakk, dame, medium, hvit Legg i handlekurv 3. Finne Hårnett: Finn hårnett, unisex, medium, sort Legg i handlekurv Gjennomfør handel, med begge varene i handlekurven Målet med dette scenarioet er å se hvor lang tid det tar for brukerne å finne fram til et ønsket produkt og få lagt den til i handlekurven. Målet med scenarioet er videre å belyse produktsøking og om gjennomføringen av handelen går så lett som det burde. 4. Logge ut og så inn igjen, og tømme handlekurv: 5. Finne kontaktinformasjon: Logg ut Logg inn igjen Tøm handlekurven din! Finn kontaktinformasjon til nettbutikken Målet med dette scenarioet er å logge seg ut og inn igjen for å teste prototypenes generelle brukerkontohåndtering og deretter tømme handlekurven som fortsatt husker informasjonen fra forrige økt. Målet med dette scenarioet er å teste hvor lang tid det tar for hver bruker å finne fram til spesifikk informasjon på siden (dens plassering). Vi hadde i tillegg et spørreskjema om personalia og tidligere nettbutikkerfaring. Informasjonen ble brukt til å danne et bilde av den generelle brukeren som deltok i brukertestene. Informasjonen som ble ansett som relevant var: Personalia: Kjønn Alder 51

52 Okkupasjon / yrke Bosted / bydel Følgende spørsmål blir det stilt om deres erfaring i bruk av nettbutikk: Hvor ofte er du på internett? Handler du på nettbutikk? Hvis ja, hvor ofte handler du på nettbutikk? Hva handler du på nettbutikk? Hvorfor handler du på nettbutikk? Vi valgte bevisst ut testpersoner i forskjellige aldersgrupper og internetterfaring. Vi hadde også representanter av begge kjønn blant testpersonene Resultater Tiden testbrukerne brukte på å gjennomføre oppgavene varierte mellom i overkant av ett minutt til nesten seks minutter. For eksakte data, se vedlegg. Dette understreket at erfaringen og kyndigheten rundt nettbutikkbruk varierte ganske kraftig. Tabell 7: Total tid brukt på hver prototyp Testbruker/Prototyp Prototyp 1 Prototyp 2 Prototyp 3 Testbruker 1 2 min 31 sek 1 min 03 sek 1 min 54 sek Testbruker 2 2 min 41 sek 1 min 31 sek 2 min 27 sek Testbruker 3 5 min 57 sek 4 min 12 sek 3 min 22 sek Testbruker 4 3 min 23 sek 2 min 07 sek 3 min 42 sek 52

53 Minutter 7,00 Tidstabell Brukertest 6,00 5,00 4,00 3,00 2,00 1,00 Testbruker 1 Testbruker 2 Testbruker 3 Testbruker 4 0,00 Prototyp 1 Prototyp 2 Prototyp 3 Figur 20: Illustrasjon av tidsfordeling per prototyp Tiden de brukte er et godt mål på hvor bra de forskjellige prototypene fungerte, men gir ikke svar på hvorfor den ene var bedre enn de andre. Her kommer Eye tracker-dataene inn i bildet. Her så vi etter: Hvordan øyebevegelsene til brukerne var Hva de fikserte mest på Hva de overså Hva som tiltrakk oppmerksomheten deres Hvordan brukeren gikk frem for å løse oppgaven En mulig måte å fremstille dette på er heatmaps. Det er en grafisk fremstilling av hvor lenge en eller flere testpersoner har kikket på forskjellige områder på skjermen. Figur 21 er ett eksempel på et heatmap fra en av brukertestene. 53

54 Figur 21: Testperson 3 på Prototyp 2, Scenario; logg inn Fargen indikerer hvor lenge det totalt har blitt fokusert i et område under en gitt tidsperiode i opptakene. Jo varmere og mer intens (rød) fargen er, jo lenger har området vært i fokus. Enkelte grønne prikker viser områder som i flere enn ett tilfelle har hvert i fokus, selv om dette har hvert ytterst korte øyeblikk. Prikkene er gjerne et resultat av saccader som brukeren ubevisst foretar seg ved skanning av sider eller forstyrrelser og støy. Figur 21 viser et heatmap fra brukertesten hvor brukeren skal forsøke å logge seg inn i nettbutikken. Det er normalt at brukerne trenger et par sekunder på å orientere seg i grensesnittet. I tillegg er lasting av siden en mulig kilde til marginale feil. Tiden det tar fra brukeren får oppgaven til vedkommende har forstått og begynner forsøket på å løse den, er også en misvisende faktor. I grove trekk elimineres disse problemene ved hjelp av såkalt segmentering 12 og oppdeling av opptakene i scener. 12 Markering av episoder i opptakene, slik at de kan sammenlignes med andre opptak 54

55 Brukerens oppgave tatt i betrakting, viser figur 21 at det er gitt lite oppmerksomhet til innloggingsknappen øverst i høyre hjørne. Det ble heller ikke viet mye oppmerksomhet til bildeframvisningen øverst i midten av siden. Derimot ligger de fleste fikseringene rundt velkomstteksten og forespørselen om innlogging. De sporadiske grønne prikkene er som sagt resultat av at brukeren orienterer seg på siden. Figur 22 viser et heatmap fra Prototyp 1, hvor brukeren har samme oppgave som i figur 21. Figur 22: Testperson 4 på Prototyp 1, Scenario; Logg inn Figuren viser at brukerens fokus er mer spredt enn hos figur 21. Orientering og lengre fikseringer indikerer at brukerens blikk er flyttet over større avstander, men at søkingen likevel har foregått rundt eller på elementene på siden. Fra logoen øverst i venstre hjørne og mot høyre er det tegn til søkende saccader (her er det riktig nok ikke noe informasjon). Heatmapene sier noe om hvor lenge brukeren ser på et område, men ikke i hvilken rekkefølge. Det kan såkalte gaze-plots 13 gjøre. Figur 23 er ett eksempel på gaze-plots fra en av brukertestene. 13 Viser og nummererer rekkefølgen på fikseringer i et gitt segment. Størrelsen på fikseringene indikerer hvor lenge hver fiksering har vart. 55

56 Figur 23: Testperson 1 på Prototyp 1 (utsnitt) De første fikseringene er som regel litt rotete i og med at brukeren i utgangspunktet for testtilfellene ikke nødvendigvis vet hva deres hensikt er. Brukeren vil gjerne orientere seg raskt og deretter interessere seg for elementer som bilder, bevegelser eller svært tydelig tekst. Bilder er ikke nødvendigvis forstyrrende, selv om de har en tendens til å kreve oppmerksomhet fra brukeren. Brukere identifiserer og registrerer bilder raskt. Når oppgaven er forstått og oppgaveløsningen igangsatt (på grunn av segmentering av opptakene vil det meste av uinteressante opptak ikke inkluderes i verken gaze-plot eller heatmaps) danner gaze-plottene mønster som vitner om søkebevegelser. I tilfellet som figur 23 illustrerer, gjør brukeren mange fikseringer med store avstander seg imellom. Brukeren har mange frem og tilbake saccader og målet (logg inn) nåes relativt sent. Først på fiksering nummer 27 ser brukeren innloggingslinken helt øverst til venstre. Figur 24 og 25 viser gaze-plottene fra samtlige brukertester hos Prototyp 1 og 2 hvor oppgaven var å finne en legefrakk. Figurene har grovt sett like mye innhold og elementer på siden, så forskjellen ligger primært i hvordan innholdet er strukturert og plassert. I tillegg er elementenes utforming noe ulike. Figur 24 viser Prototyp 1. Gaze-plotmarkeringene er delt 56

57 inn i ulike farger for å kunne skille mellom ulike brukere. Gjennomgående for Figur 24 og også brukertestene utført på Prototyp 1, er at brukerne bruker lengre tid og flakker mer med blikket. Figur 24: Alle testbrukerne på Prototyp 1. Scenario; Finn legefrakk Sammenlignet med Prototyp 2 som er illustrert i Figur 25, var det gjennomgående mindre effektive testgjennomføringer på Prototyp 1. I Figur 25 ser vi tydelig at en annen struktur på elementene og en tydeligere struktur på blikkbanen som gaze-plottene markerer. Resultatene viser blant annet også at menystrukturen kjennes igjen hos alle prototypene, som for eksempel kan sees øverst til høyre i Figur 24 og i midten til venstre i Figur

58 Figur 25: Alle Testbrukerne på Prototyp 2. Scenario; Finn legefrakk Intervju Da de fem oppgavene var gjort på alle tre prototypene, stilte vi testbrukeren spørsmålene som kommer frem i tabell 8. Tabell 8: Intervju Spørsmål Svar fra testbrukere Ranger prototypene 1-3 (1 er best). T1 synes P1 var verdt 2, P2; 3 og P3; 1 T2 synes P1 var verdt 3, P2; 2 og P3; 1 T3 synes P1 var verdt 3, P2; 1 og P3; 2 T4 synes P1 var verdt 3, P2; 2 og P3; 1 Var det lett å finne ønsket produkt? T1 svarte ja på alle prototypene. T2 svarte ja for P2 og P3, mens hun ikke fant det like lett i P1, brukte søkefunksjonen. 58

59 T3 brukte lang tid i P1, men fant det relativt enkelt i P2 og P3. T4 svarte ja for P2 og P3, men han syntes det var vanskelig i P1. Var det lett å finne knapper for å logge inn og logge ut? Var det lett å finne kontaktinformasjon? Savnet du noe? Var slideshowene distraherende eller behjelpelige? T1 svarte ja for alle prototypene. T2 svarte ja for alle prototypene, men at det burde vært større skrift i P3. T3 svarte ja for alle prototypene, bortsett fra P1 hvor han syntes at skriften var altfor liten. T4 svarte ja for P2 og P3, men han syntes det var for liten skrift i P1. T1 svarte at det var vanskelig å finne kontaktinformasjon i P3, men at det i P2 var lettere pga. tidligere erfaring fra P3. P1 hadde ikke kontaktinformasjon. T2 svarte ja for alle prototypene. P1 hadde ikke kontaktinformasjon. T3 brukte svært lang tid i P2, men fant det lettere i P3 pga. erfaring fra P2. P1 hadde ikke kontaktinformasjon. T4 svarte ja for alle prototypene. P1 hadde ikke kontaktinformasjon. T1 svarte at han helst ville ha tilbudsvarer på topp, og at rabattkampanjer skulle ha vært mer synlige. T2 hadde ikke noe å nevne. T3 hadde ikke noe å nevne. T4 hadde ikke noe å nevne. T1 la ikke merke til slideshowene verken i P2 og P3. P1 hadde ikke slideshow. T2 sa hun likte slideshowene. 59

60 T3 la ikke merke til slideshowene. T4 la ikke merke til slideshowene. Var det noe annet? (Likte du fargene?) (Likte du layouten?) T1 foreslo utvikling av ny logo. T2 sa at vi burde legge mer tid i logoen. T3 hadde ikke noe å nevne. T4 nevnte at han likte enkle nettsider. T1 svarte ja for alle prototypene. T2 svarte ja for alle prototypene. T3 hadde ikke noe å nevne. T4 svarte ja for alle prototypene. Han bemerket at det var fine kontraster i P2. T1 var fornøyd med prototypene, bortsett fra P1, hvor han syntes at menyen burde vært plassert på venstre side. T2 sa at P1 var for enkel og for bred, og at det var for stor variasjon i skriftstørrelser. P2 var hun fornøyd med. P3 var hun også fornøyd med, bortsett fra at skriften kunne vært større. T3 hadde ikke noe å nevne. T4 nevnte at P1 var fin og bred, men at det var for mye plass mellom tekstene. Om P2 sa han at var en enkel og oversiktlig side. Om P3 sa han kun at han synes P2 var en enklere side enn denne Analyse Det kunne trekkes ut mye informasjon fra brukertestresultatene. Med utgangspunkt i hypotesene våre, er det en rekke spørsmål som lettest ble besvart ved hjelp av intervjusvarene. Dette gjaldt spesielt hva slags informasjon som skal være tilstede, hvor dette skal plasseres og hvor mye oppmerksomhet elementet bør tiltrekke seg. Ved å lage oppgavesett og registrere all øyeaktivitet og tidsbruk, kunne vi tydelig se hvor og hva 60

61 testbrukerne løste raskt og enkelt, samt hva som ikke fungerte optimalt. Mye nyttig informasjon kan også trekkes ut fra opptakene hvor testbrukerne leter etter informasjon eller knapper som de ikke finner. Fra resultatene av eye trackingen og intervjuene virket det som om testpersonene oppfattet menyene og deres funksjon. Det antas at de fleste brukerne vil kjenne igjen en meny i sin helhet uavhengig av hvilken side av grensesnittet den er plassert i. Det er derfor vanskelig å si at det ene er bedre enn det andre, men at det er mer avhengig av menyens innhold og hvilken rolle den spiller i helheten av grensesnittets layout og design. Vi registrerte også at i prototypen uten produktkategorier i sidemenyen, ble søkefunksjonen benyttet. Sammenlignet med de andre prototypene, hvor lenkene/knappen til kategoriene finnes på venstre side, ser vi at dette er det foretrukne valget hos testbrukerne, men at flere kjente igjen og visste hvordan å benytte søkefunksjonen. Altså er søkefunksjonen et nyttig verktøy for brukerne, som dermed vil bli inkludert i videre utvikling. Likevel vil vi si at hypotese 2 er styrket, da det var påfallende at testpersonene søkte til venstremenyen for å navigere blant produktene. I tillegg til menyer, hadde et par av prototypene scriptbaserte, rullerende bildepresentasjoner av produktene. Dette er etter konkret forespørsel fra oppdragsgiver for å få presentert flest mulig produkter for kunden. Fra brukertesten ser vi imidlertid at testbrukerne knapt registrerer bildene. Noen av testbrukerne registrerte bildeskiftene, som førte til flakking med blikket i noen millisekunder, men bildeframvisningen ble aldri brukt som et alternativ til menyene for å finne ønsket produkt. Derfor vil vi påstå at hypotese 3 er styrket. For mye informasjon på én side kan virke forstyrrende. Av intervjusvarene ser vi også at bildeframvisningen ikke ble lagt merke til. En mulig årsak til at slideshowene ble oversett, kan være at testpersonene følte et visst tidspress for å bli fort ferdige med oppgavene gitt av testleder, og dermed ignorerte bildeframvisningene. Når det gjelder plasseringen av innloggingslenkene, virket det mer eller mindre likegyldig hvilken side den var plassert på. Utslagene var derimot synlige i tilfellene hvor fontstørrelse, farge og forstyrrende elementer rundt varierte. Det er tydelig at jo mer dominerende elementet er på siden, desto raskere registrerer testbrukeren hva det er og hvilken funksjon det har. 61

62 Scrolling opp og ned på siden var ikke et direkte hinder for testbrukerne, men er regnet som lite fordelaktig likevel. Testbrukerne gav uttrykk for at det at de måtte scrolle reduserte inntrykket av en helhetlig oversikt. Dette var imidlertid noe som var vanskelig å måle med eye trackeren. Derimot registrerte den at leting etter informasjon nederst på siden, i tilfeller hvor testbrukeren ikke umiddelbart fant frem til riktig informasjon, tok lenger tid Konklusjon Den samlede konklusjonen av intervjusvarene, heatmaps og gaze-plots, samt tid brukt, viser at P2 var den prototypen testpersonene var mest fornøyd med. I intervjusvarene ser vi at to av testpersonene (Testperson 3 og 4) likte Prototyp 2 best. De samme testpersonene mente at Prototyp 1 og Prototyp 3 hadde for liten skrift. Testperson 1 og 2 reagerte ikke negativt på skriftstørrelsen på nevnte prototyper, men med hensyn til at dette er en nettbutikk med universell utforming som ideal, er det mest designmessig korrekt at skriftstørrelsen skal være lesbar for flest mulig. I svarene fra testbrukerne finner vi også at det var enighet om at Prototyp 1 var en for bred/stor nettside. Det virker som dette, kombinert med at Prototyp 1 hadde veldig liten skrift, gjorde det ekstra vanskelig å finne de elementene som var nødvendige for å løse oppgavene gitt av testleder. Spesielt på figur 26 kan man se at testpersonen vingler mye frem og tilbake med øynene. Det er ikke en konsentrert fokusering av blikket slik som på de andre prototypene. Som nevnt kan et slikt mønster (kalt saccades) vitne om forvirring [15]. 62

63 Figur 26: Testperson 2 på Prototyp 1 Som det fremgår av figur 20 i avsnittet om resultater, var Prototyp 2 den butikken testbrukerne brukte kortest tid på til å løse oppgavene. Vi mener at dette vitner om høyest effektivitet på denne prototypen. I testmetoden vår har vi som nevnt over randomisert rekkefølgen prototypene ble vist til de forskjellige testpersonene, for å luke ut læring av erfaring som feilkilde. Da oppdragsgiver ble stilt de samme spørsmålene som testpersonene, uten å vite noe om testpersonenes respons, svarte han påfallende likt. Hans favoritt var også prototyp nummer 2. Han ville imidlertid ikke forkaste ideen om en bildeframvisning, selv om det under brukertestene så ut til at brukerne ikke la nevneverdig vekt på det. Vi mente på grunnlag av testresultatene og ønsket fra oppdragsgiver at det var mest hensiktsmessig å gå videre med P2 som fundament til utviklingen av den endelige nettbutikken. 63

64 Kapittel 8 Ferdigstilling av produkt 64

65 Kapittel 8 Ferdigstilling av produkt Ut ifra resultatene og konklusjonene fra brukertestene utviklet vi en ny og bedre prototyp. Denne skulle utvikles til å bli det endelige produktet og ble derfor satt opp direkte på nettbutikkens endelige adresse. Dette åpnet også for en mer dynamisk evalueringsprosess sammen med oppdragsgiver Fra brukertesten Etter at brukertesten hadde belyst ulike styrker og svakheter hos de forskjellige prototypene, gjennomgikk vi de positive elementene, og forsøkte å samle dem i den endelige prototypen. Ikke alt passet like bra sammen og vi var avhengig av å ta noen valg. Funksjonelt sett valgte vi å beholde en meny med knapper som lister opp produktkategoriene. Denne menyen tilegner vi relativt stor plass, slik at den både er i øyenfallende og intuitivt viktig. Samtidig regner vi både søkefunksjonen og den horisontale listingen av de øverste kategorigruppene også som gode verktøy. Brukertestene viste oss at alle tre elementene er intuitive og lett anvendelige. I og med at alle tjener det samme formålet, å gi tilgang til produktene, var det viktig å sørge for at elementene hver for seg hadde minst mulig unødige forstyrrende elementer inkludert. Hovedmenyen ble plassert på venstre side av grensesnittet, med en listing av kategoriene over sidens innhold, samt søkefunksjonen øverst til høyre. Siden måtte ikke være for vid. Til tross for at dette sørget for lite forstyrrelser rundt enkeltelementer på siden, var resultatet av større avstander på siden, at brukerne hadde problemer med å skaffe et overordnet overblikk. Ytterpunktene på siden fikk ikke den nødvendige oppmerksomheten som de var tiltenkt. I tillegg ble en større font ansett som viktig for tydeliggjøring av tekst. Dette forbedret ikke bare lesbarheten, som sørget også for at essensielle elementer kom mer i fokus. Sammen med fargevalgene utgjør tekstens utforming en av de viktigste faktorene på en nettside. Det er derfor viktig at kontrast på bakgrunn og forgrunn (tekst), og valg av font, sørger for mest mulig leservennlighet. Fargevalget ble basert på hva som passet til nettbutikkens konsept. I medisinens verden står renslighet svært sentralt, det er derfor logisk og viktig å presentere nettbutikkens innhold på en ryddig måte. Farger er svært sentrale i inntrykket og stemningen som dannes i 65

66 interaksjonen med nettbutikken. Derfor ble farger som assosieres med for eksempel medisin, renslighet og sykehus det vi var på jakt etter. Generelt sett lette vi gjennom fargeskalaen fra blåfarger og over imot grønn, og i ulike valører/lysstyrker (figur 27). Figur 27: Blå til grønn, sirkelen indikerer hvor på skalaen de endelige fargene er hentet fra I tillegg lette vi etter komplementærfarger på motsatt side av fargesirkelen (figur 28). Figur 28: Gul til Rosa, komplementærfargene til figur 27 Avgjørelsen ble tatt av oppdragsgiver etter at et par forslag ble lagt frem, og endte på en primærfarge som var mer mot det mørkeblå enn det grønne. Komplementærfargen ble da følgelig mot det oransje området Nye krav fra oppdragsgiver Etter at funksjonalitet og nettbutikkens faktiske innhold (sett bort i fra varene) var på plass, ble fokuset flyttet over mot design og utseende. Oppdragsgiver, som hadde fulgt utviklingsprosessen, hadde en rekke meninger om utseendemessig utforming av elementene som vi hadde besluttet at skulle være med i nettbutikken. En liste med konkrete punkter ble etablert slik at vi kunne tilfredsstille oppdragsgivers ønsker. Punktene gjaldt alt fra utseende på knapper, til overordnede designløsninger som for eksempel gjennomgående struktur hos elementer. De nye kravene endret arbeidsmetoden noe på grunn av at oppdragsgivers ønske ble tydeligere definert enn det hadde hvert tidligere. Vi arbeidet nå for å tilfredsstille oppdragsgiver, fremfor selv å mene noe om utseende. I noen av tilfellene stred oppdragsgivers ønsker med det vi hadde kommet frem til som brukervennlige løsninger, hvor vi diskuterte og argumenterte for og imot, for å komme frem til løsninger som tilfredsstilte alle parter. 66

67 8.3. Ferdigstillelse av layout Noen omfattende endringer, samt noen andre mindre detaljer ble endret i sluttfasen av utviklingen. Visuelle detaljer som runde hjørner og avrundede elementtittelbakgrunner sørger for et litt mykere helhetsinntrykk enn den grunnleggende boksstrukturen som er utgangspunkt for html kode. Figur 29 viser et skjermbilde av nettsiden fra sent i designprosessen. Figur 29: Halvferdig versjon av endelig produkt Andre utseenderelaterte endringer som ble gjort på slutten er for eksempel designing av knappene i kategorimenyen, oppsettet av informasjonen helt nederst i footeren 14, og organiseringen øverst i headeren PayPal Når nettbutikkenes innhold og utseende på de respektive serverområdene var ferdige, måtte vi koble selve butikken til en betalingsløsning. Siden oppdragsgiver hadde brukt PayPal før, valgte vi dette. I prototypfasen av prosjektet var dette egentlig bare for å bli kjent med selve betalingssystemet, og forsikre oss om at det faktisk fungerte i praksis. PayPal er en amerikansk betalingstjeneste på nettet. PayPal er bygd for at pengeoverføring på internett skal kunne skje uten at sensitiv kontoinformasjon skal kunne havne i feil hender. PayPal fungerer som et bindeledd mellom partene i en handel og sørger blant annet for at 14 Tversgående bunnlinje, gjerne med enkel informasjon 15 Tversgående fane på toppen av siden, gjerne med logo eller lignende grafikk 67

68 personlig informasjon knyttet til bankkort og kredittkort forblir hos PayPal og ikke er tilgjengelig for motparten. Hver part har en egen konto hos PayPal som belastes eller krediteres. Hvis man skal gjennomføre en PayPal-transaksjon, og det ikke er nok penger på PayPal-kontoen, vil PayPal automatisk belaste din bankkonto for å betale. Man registrer en PayPal-konto ved å oppgi personlige data som navn, adresse og en e-postadresse. Man kan også motta penger til sin PayPal-konto, hvilket i vårt tilfelle er det viktigste. Oppdragsgiver skal faktisk skulle kunne tjene penger på butikken sin, og da må han kunne motta penger [20]. Vi testet dette betalingssystemet med fiktive produkter som vi hadde lagt inn i butikken. Ett gruppemedlem kjøpte et produkt på en annens butikk, og forsikret at det fungerte. Pengene (i dette tilfellet 5 kr) ble trukket fra kredittkortet som var koblet til PayPal-kontoen til gruppemedlemmet. Pengene kunne tilbakeføres etterpå, fra den som «eide» nettbutikken Lansering av Lansering av nettbutikken gjøres i to faser. Første er rett og slett å legge ut siden på webhotellet og sørge for at den fungerer. Deretter kommer lanseringen, hvor ekte produkter er lagt ut for salg og kunder kan handle normalt. Lanseringen av nettsiden ønsker oppdragsgiver å gjøre på egenhand, det innebærer også at han ønsker på egenhånd å legge ut produkter som han skal selge. Bedriften er i en fase hvor oppdragsgiver skifter ut leverandører og har i den anledning ikke en fullstendig produktkatalog og utvalg tilgjengelig i prosjektperioden. Det blir kompensert for dette ved å legge ut fiktive produkter på samme måte som det ellers ville bli lagt ut ekte produkter. Derimot den første lanseringen av siden ut på nett, innebærer blant annet at den blir tilgjengelig for allmennheten og ikke bare på våre lukkede servere på skolen. Zen Cart er avhengig av å settes opp via en nettleser, hvor riktig input er avgjørende for korrekt oppsett av databaser og filhierarkiet. Deretter følger en omfattende prosess med å implementere tilleggene som skal sørge for ønsket funksjonalitet i endelig produkt. På grunn av Zen Carts kompleksitet, er det en tidkrevende, pirkete og lang prosess å implementere dette riktig. God dokumentasjon på endringer, innstillinger, kilder og egenproduserte filer var derfor essensielt for effektivt å kunne rekonstruere nettbutikken på den endelige serveren. 68

69 8.6. Debugging I enhver lansering som innebærer flytting og installering, regnes det med en rekke uventede problemer. Serverne er ikke nødvendigvis like, feil kan skje under filoverføring eller noen innstillinger glemmes og lignende. Det ble derfor avsatt en periode forbeholdt feilsøking og debugging. Denne prosessen innebærer også validering av kildekode, selv om dette også er blitt gjort fortløpende gjennom hele utviklingsprosessen. 69

70 Kapittel 9 Refleksjon 70

71 Kapittel 9 Refleksjon Ved starten av prosjektet var hovedproblemstillingen hvordan vi skulle løse oppgaven med å lage en nettbutikk. Opprinnelig så vi for oss to tilnærminger: 1. Lage en nettbutikk fra grunnen av, altså kode all HTML, PHP og CSS selv, lage hele databasestrukturen fra bunnen av, skrive SQL-setninger selv, og så videre. 2. Benytte et rammeverk, eller verktøy, som basis for vår nettbutikk. Valget falt på løsning nummer 2. Vi valgte å fokusere på brukeropplevelsen og brukervennlighet, fremfor hvordan å programmere en nettbutikk fra grunnen av. Vi var i utgangspunktet litt usikre på om en slik løsning, med kode skrevet av andre (selv om det var Open Source), var tillatt i hovedprosjektsammenheng. Vi hadde en del spørsmål i så henseende innad i gruppen. Veileding har vært helt avgjørende for visse beslutninger og spesielt denne. Tidlig i planleggingsfasen fikk vi bekreftet av veileder at det var tillatt å bruke ferdige rammeverktøy så lenge vi selv tilpasset det til å møte kravspesifikasjonene. Vi kunne valgt å løse oppgaven ved å programmere nettbutikken fra grunnen av. Dette ville i stor grad endret prosjektets gang og utvikling. Mange problemer ville bli unngått for eksempel problemet med overflødige filer, kode og funksjonalitet, eller læringsperioden, hvor vi brukte lang tid på å sette oss inn i Zen Cart. Til gjengjeld ville andre kjente og ukjente hinder ta deres plass, blant annet ville dette kreve en omfattende planlegging av databasestruktur og filhierarki i forkant av utviklingsprosessen. Ut i fra fordeler og ulemper hos begge metodene, har vinklingen mot brukeropplevelse og brukervennlighet ved bruk av Zen Cart vært en god løsning på oppgaven. Brukertestene av prototypene midtveis i prosessen kunne muligens ha vært enda mer strukturerte. Vi kunne vært enda strengere med tanke på rollefordeling, med testleder, tidtaker, sekretær og programvareansvarlig. Testscenarioene kunne også ha vært enda mer finspisset i formen, slik at ett og ett skjermbilde ble nøyere analysert. Vi brukte imidlertid mye tid på å dele inn testscenarioene i såkalte scenes ved hjelp av eye trackeren sin programvare. Dette gjorde at feilmarginene ble minimert. Når vi ser tilbake, burde kanskje våre opprinnelige hypoteser før brukertesting ha vært enda mer spesifikke. Grunnen til dette, er at da kunne vi målt mer bestemte atferder hos testpersonene, eksempelvis nøyaktig hvor på skjermen handlekurven optimalt sett burde 71

72 plasseres. Når det er sagt, har vi forsøkt å vise at plasseringen av et element ikke er avgjørende, men snarere hvor tydelig det er i en kontekst. Vi har så langt det er mulig forsøkt å møte oppdragsgiverens ønsker gjennom prosessen. I begynnelsen fikk vi frie tøyler til å lage en nettbutikk. I prosjektets gang har det allikevel kommet nye ønsker fra oppdragsgiver, slik at vi har måttet tenke nytt. Vi mener at dette er representativt for hvordan prosjekter kan være i næringslivet. Man må være smidig og tilpasningsdyktig når man utvikler et produkt, og stadig være mottakelig for kritikk og nye krav. Den ferdige nettbutikken ligger på URL-adressen og illustreres i figur 30. Figur 30: Indexsiden til den endelige nettbutikken 72