BACHELORPROSJEKT. Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo

Transkript

1

2 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo BACHELORPROSJEKT PROSJEKT NR TILGJENGELIGHET Offentlig Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL DATO 24. mai 2017 Chatnodes ANTALL SIDER / BILAG 209 PROSJEKTDELTAGERE Adam Asskali s Anmer Seif s Sara Khan s INTERN VEILEDER G. Anthony Giannoumis OPPDRAGSGIVER Webnodes ( KONTAKTPERSON Vidar Langberget SAMMENDRAG En live kundeservice-chat som skal benyttes av Webnodes sine kunder. Løsningen vår består av to sider, en for kundene som skal kommunisere med kundeservice og en for chatassitentene som arbeider i bedriften. Brukergrensesnittet for løsningen er utviklet i React.js mens det servere siden er laget i.net ved bruk av kodespråket C#. TRE STIKKORD Chat.Net React 2

3 Forord Denne sluttrapporten handler om utviklingen av en chat-løsning for bruk av kundeservice i ulike bedrifter. Oppgaven har blitt gitt til oss av selskapet Webnodes AS og har blitt utviklet av bachelorgruppe 32 fra Høgskolen i Oslo og Akershus. Rapporten er delt inn i 6 deler, og disse er som følger: Presentasjon av Prosjektet o I presentasjonen introduseres prosjektet vi har utviklet, de ulike interessentene i prosjektet og en bakgrunn for oppgaven. Prosessdokumentasjon o Prosessdokumentasjonen går gjennom selve utviklingen av løsningen vår og prosessen bak. Produktdokumentasjon o Produktdokumentasjonen tar for seg det utviklede produktet i mer detalj. Testdokumentasjon o Testdokumentasjonen inneholder dokumentasjon av de ulike testene som har blitt utført på applikasjonen. Brukerveiledning o Brukerveiledningen tar for seg hvordan brukeren kan handle for å oppnå sine mål Vedlegg o Kravspesifikasjon, risikoanalyse, brukerkrav, testplan, ordliste og intervju Vi ønsker å takke alle som har hjulpet oss gjennom denne prosessen. Vi retter en stor takk til vår oppdragsgiver Webnodes og alle de ansatte der for å ha bidratt til vår oppgave samt å skape et godt arbeidsmiljø for oss. Takk til Vidar Langberget, vår kontaktperson i Webnodes, for regelmessige møter. Vi retter en stor takk til Espen Zaal for hans engasjement i vår oppgave, varmende ord og konstant støtte gjennom hele bachelorarbeidet. We also wish to thank G. Anthony Giannoumis, for his moral support, enthusiasm and his incredibly valuable feedback. 3

4 Presentasjon av Prosjektet Chatnodes Bachelorprosjekt 2017 Gruppe 32 4

5 Innholdsfortegnelse 1 Innledning... 6 Gruppen... 6 Oppdragsgiver... 7 Kontaktinformasjon... 8 Oppgaven Hva er oppgaven? Hvorfor valgte vi denne oppgaven? Hybrid prosjekt: Kombinasjon av design og systemutvikling Hvem skal benytte seg av løsningen? Dagens situasjon Markedets behov for en chat-løsning Eksisterende forventning blant kunder Effektivisering av kundeservice Den yngre generasjonen Avgrensninger Teknologier Front-end React.js Sass Back-end SignalR Asp.Net C# Node.js WebRTC & Peer.js Verktøy Visual Studio Visual Studio Code Git gjennom GitHub Trello Slack Axure

6 1 Innledning I denne delen av rapporten vil vi introdusere de ulike interessentene for vår oppgave samt oss selv og oppgaven. Vi vil også gå gjennom bakgrunnen for oppgaven for så å gå gjennom de ulike teknologiene og verktøyene vi har benyttet oss av under prosjektarbeidet. Gruppen Prosjektgruppen består av studentene Adam Asskali, Anmer Seif og Sara Khan. Alle tre går bachelorstudiet dataingeniør ved Høgskolen i Oslo og Akershus. Medlemmene har arbeidet sammen med både obligatoriske oppgaver og prosjektoppgaver siden andre året med gode resultater, som er grunnen til at vi valgte å utføre bacheloroppgaven sammen. Alle i gruppen har tatt et fag som benyttet seg av.net, og fikk også muligheten til å bruke React i sammenheng med den siste prosjektoppgaven i faget. Disse to teknologiene er hoved teknologiene som benyttes i vår bacheloroppgave og er derfor svært relevant i henhold til prosjektet. Da vi fikk oppgaven, som vi vil komme tilbake til litt senere, bestemte vi oss for å ikke kun fokusere på programvareutvikling, men også benytte oss av en brukersentrert utviklingsprosess så langt det lar seg gjøre. Som figur 1.1 under illustrerer befinner dette prosjektet seg i midten av en sammenkomst av programvareutvikling og brukersentrert utvikling. Vi som gruppe var enige om at ved å inkludere brukeren vil vi oppnå en oppgave som vil oppfylle ønskene til produkteier i mye høyere grad enn om vi kun ble enige i krav for så å utvikle løsningen helt uavhengig av selskapet. Vi har bakgrunn fra både programvareutvikling og design, samt å skape et brukervennlig grensesnitt, og det er nettopp disse ferdighetene vi bringer til denne prosjektoppgaven. 6

7 Figur 1.1 Venn-diagram som illustrerer hvor dette prosjektet befinner seg Oppdragsgiver Prosjektet utføres i samarbeid med selskapet Webnodes. Webnodes er et programvareutviklings selskap som har spesialisert seg på e-handel og Web Content Management (CMS). De tilbyr et Content Management system også kalt en webpublisering løsning, til sine kunder. En slik løsning håndterer webpublisering samt data som befinner seg på nettsiden. I Webnodes CMS vil du kunne endre utseendet til nettsiden og strukturere data samt navigering av denne. Webnodes er et mindre selskap og består av kun fire utviklere. For oss har dette vært en positiv opplevelse ettersom det har vært langt lettere for oss å få kontakt med de ansatte og mulighetene for å spørre om hjelp er bedre. I tillegg så har dette ført til at Webnodes har investert mye tid i å følge opp vårt prosjekt ettersom løsningen blir en viktig komponent i Webnodes sin egen løsning, mens i et større selskap ville det kanskje ikke vært satt et like stort fokus på vår applikasjon. I tillegg har vi på grunn av størrelsen klart å skape et miljø innenfor selskapet som har bidratt positivt både når det gjelder arbeidsmiljø og engasjement i oppgaven. 7

8 Kontaktinformasjon Gruppemedlemmer: Navn: Adam Asskali Studentnummer: s E-post: Tlf: Navn: Anmer Seif Studentnummer: s E-post: Tlf: Navn: Sara Khan Studentnummer: s E-post: Tlf: Veileder: Navn: G. Anthony Giannoumis E-post: Tlf: Webnodes veileder: Navn: Vidar Langberget Tlf: Oppgaven I denne seksjonen skal vi gå gjennom hva oppgaven vi har fått av Webnodes går ut på, og hvilke mål vi som en gruppe skal oppfylle når vi lager en løsning for denne oppgaven. Vi vil også forklare hva det er som førte til vår beslutning om å akseptere denne oppgaven Hva er oppgaven? Vi har fått i oppgave å utvikle en chat-modul for Webnodes. Dette innebærer at kundegruppen til Webnodes skal ha muligheten til å inkludere denne modulen på sine egne sider. Modulen skal brukes som et verktøy for kundeservice til de ulike bedriftene og det er derfor viktig at funksjonaliteten er lagt opp til kundeservice sitt behov. 8

9 Chatten skal være enkel å ta i bruk samtidig som de mest nyttige funksjonene for kundeservice skal være implementert. Det er viktig at det kreves minimalt til ingen opplæring for å ta i bruk løsningen. Chatten skal kunne legges til på en hvilken som helst nettside uten å påvirke resten av siden. Det er viktig at standard versjonen av chatten er designet på en slik måte hvor den kan inkluderes på en side uten å skille seg ut for mye. I tillegg til dette er det satt et stort fokus på design av chat-løsningen, spesielt på kundesiden. Utseendet må være appellerende samtidig som det skal være nøytralt nok til å ikke trekke til seg for mye oppmerksomhet. En annen grunn til å ha et nøytralt utseende er at den skal passe inn på de fleste nettsider også før selskapene gjør sine egne tilpasninger Hvorfor valgte vi denne oppgaven? Vi hadde muligheten til å velge mellom et par ulike oppgaver, men det var noen vesentlige aspekter som gjorde at vi til slutt besluttet oss for å velge denne oppgaven hos Webnodes. Først så var det muligheten til å bruke nye teknologier som fristet oss til å velge denne oppgaven. Det å kunne benytte seg av relativt nye teknologier slik som React og SignalR for å lage en løsning er relevant ikke bare for vår egen utvikling, men også for arbeidsmarkedet. Å benytte oss av nye teknologier som vi ikke har erfaringer med fra tidligere skaper også en mer utfordrende oppgave som er et ønske fra vår side. Videre så var skalerbarhet en viktig årsak for å velge denne oppgaven. En chatløsning kan man konstant videreutvikle med flere funksjonaliteter, samtidig som det er mulig å lage en fullverdig løsning uten å kreve spesielt mange funksjonaliteter. Muligheten til å kunne tilpasse oppgaven etter vårt eget behov er en mulighet som bidro til beslutningen om å ta denne oppgaven. Da vi fikk høre at dette var en løsning de faktisk ønsket å implementere i sitt eget CMS system og som da kunne havne på markedet så ble vi motiverte til å takke ja til denne muligheten. Tanken om at det vi lager faktisk vil brukes av ulike bedrifter er en svært appellerende tanke som påvirket oss i beslutningsprosessen Hybrid prosjekt: Kombinasjon av design og systemutvikling Som nevnt i seksjon 1.1 besluttet vi at prosjektet vårt skulle kombinere programutvikling med en brukersentrert utvikling. Flere studier slik som studiet «A Survey of User-Centered Design Practice» (Vredenburg, Mao, Smith, & Carey, 2002) 9

10 konkluderer med at brukersentrert utvikling fører til et produkt som er mer brukervennlig og som bedre oppfyller behovene til produkteier. Ved å involvere brukeren i utviklingsprosessen vil vi få en løsning som er bedre tilpasset faktisk bruk, istedenfor teori basert på våre antagelser om hva kundeservice behøver. Ved å legge opp løsningen for brukerne vil bedriftene kunne øke deres effektivitet ettersom fokuset har vært på å forenkle brukerens opplevelse. Å fokusere på programutviklingen er også en viktig del ettersom effektivitet er viktig i enhver digital løsning. Uansett hvor bra designet er lagt opp vil det ha lite å si om systemet er laget på en slik måte at alt tar lang tid, eller at det er så mange bugs i systemet at løsningen blir umulig å bruke. I tillegg til dette så er det i systemutviklingen ting som sikkerhet må vurderes, noe som er spesielt viktig i en chat-løsning Hvem skal benytte seg av løsningen? Chat-løsningen utvikles for Webnodes med tanke på at den senere skal benyttes av deres kunder. Av den grunn utvikles denne løsningen med hensyn på at det er disse kundene som til syvende og sist skal være brukere av chat-løsningen. For å kunne tilpasse løsningen til brukernes behov og ønsker har vi i løpet av denne prosessen undersøkt og intervjuet ulike selskaper. Blant disse var det både selskaper som benyttet seg av en eksisterende chat-løsning og de som ønsker en chat-løsning. Selskapene som ønsker en chat-løsning var de som benytter seg av Webnodes og som potensielt kunne vært interessert i å implementere chat-løsningen. Innad i disse selskapene finnes det ulike roller som har ulik interesse i chatløsningen. De mest sentrale rollene er listet opp i figur 1.2 og inneholder hva hoved ønsket for denne rollen er. 10

11 Figur 1.2 Ulike roller og deres hoved ønsker av chat-løsningen For dette prosjektet trenger vi å ta hensyn til at vi har begrenset med tid og ressurser. Vi vil derfor i første omgang fokusere på å tilpasse chat-løsningen for klient, chatassistent og IT-ansvarlig. Dette er de tre mest sentrale rollene og det er de som i høyest grad vil benytte seg av løsningen. Dagens situasjon Vi er den første bachelorgruppen til Webnodes, ettersom selskapet tidligere ikke har hatt et behov for å rekruttere en bachelorgruppe. Webnodes har sett at behovet for en chat-løsning er i stadig økning og noen av kundene deres har allerede implementert chat-løsninger laget av andre selskap. Dette blir en tapt businessmulighet for Webnodes ettersom at de ikke har en integrert chat-løsning som de kan tilby sine kunder. Hvis kundene deres ville blitt tilbudt en chat-løsning integrert i Webnodes systemet ville det vært en høy sannsynlighet for at de ville valgt dette istedenfor å kjøpe en tilsvarende løsning fra et annet sted. selskap. Denne tapte muligheten er grunnen til at Webnodes ønsker å skape sin egen løsning. Chat-løsningen har vært i selskapets tanker en stund nå, men har grunnet andre høyere prioriterte prosjekter ikke hatt muligheten til å utvikle dette selv. Derfor har de valgt å benytte seg av muligheten til å rekruttere en bachelorgruppe og la disse utvikle en løsning for dem. Markedets behov for en chat-løsning Behovet for en kundeservice chat er økende av flere grunner. Vi har vært i intervjuer med et par selskap for å samle informasjon om deres chat-løsninger. Gjennom disse 11

12 intervjuene (se vedlegg 6.3 og 6.4) og undersøkelser på nett har vi kommet fram til at det er spesielt tre grunner til at en live chat-løsning har blitt så ettertraktet: Eksisterende forventning blant kunder Effektivisering av kundeservice Den yngre generasjonens preferanse mot chat Eksisterende forventning blant kunder Det første argumentet til selskapene vi intervjuet var den allerede eksisterende forventningen til chat blant kundene. Ettersom flere og flere aktører implementerer en slik chat-løsning har det også blitt flere kunder som forventer en lik løsning fra andre aktører. For å unngå en negativ reaksjon fra kundene har det derfor blitt viktig å tilby en chat for å oppfylle forventningene samt måle seg med konkurransen Effektivisering av kundeservice Kundeservice gjennom chat er også mer effektivt enn alternativer som e-post og telefon. Når det gjelder e-post er grunnen for høyere effektivitet at e-post gir deg mulighet til å kommunisere med flere på en gang, men begrenser deg ved at du er nødt til å vente på kundens respons som tar vesentlig lenger tid enn både telefon og chat. Ved bruk av telefon kan du løse kundens problem raskt ettersom du konstant kan stille oppfølgingsspørsmål uten ventetid, men samtidig er en begrenset til å hjelpe en kunde om gangen. Chat kombinerer det beste fra begge disse to. Med chat får du dokumentert samtalen og arbeidet med flere kunder på en gang, samtidig får du også vært effektiv og kommunikasjonen skjer umiddelbart. Det muntlige språket vil også skape et mer personlig preg enn i en formel e-post. En annen fordel ved å ta i bruk chat er også at du får dokumentert kommunikasjonen på samme måte som med e-post. Effektiviseringen av kundeservice vil også resultere i lavere kostnader for kundeservice ettersom man behøver færre ansatte for å behandle samme kundemengde. I figur 1.3 ser vi hvordan kundeservice chatten kan øke inntektene til bedriftene. Mer effektiv kundeservice, som også er lettere tilgjengelig for kundene vil føre til at de får hjelpen de behøver for å gå videre med kjøpet sitt, som igjen vil føre til at flere handler eller at flere transaksjoner fullføres. Chatassistent Chat Mer effektiv kundeservice Kort ventetid + lettere tilgang Flere salg Høyere inntekt for bedriften Figur 1.3 Kjedereaksjon av chat-løsning 12

13 1.6.3 Den yngre generasjonen Et av de andre argumentene som har blitt brakt opp er at den yngre generasjonen viser seg å være langt mer åpne for å chatte med kundeservice sammenlignet med å kontakte dem gjennom telefon eller e-post. Årsaken til dette er at dagens generasjon for det meste kommuniserer gjennom chat og beveger seg vekk fra løsninger som e- post og telefon. Et studie gjort av Gallup i USA (Newport, 2014) viser hvordan personer mellom 18 og 29 år ringer mindre sammenlignet med bruken av SMS-er og sosiale medier. Selv de som er mellom 30 og 49 år viser at kommunikasjon ved bruk at tekst er mer populært enn å ringe med telefonen. Avgrensninger I seksjon forklarte vi at en av grunnene til at vi valgte denne oppgaven er dens skalerbarhet. Å ha en skalerbar oppgave kommer ikke uten sine egne negative sider. Det er veldig lett å bli oppslukt i alle muligheten man har og alt man kan lage, vi var derfor nødt til å sette oss ned og sette våre egne begrensninger før vi startet å utvikle løsningen. Det var i hovedsak to måter vi avgrenset oss på, og disse var som følger: Ved å se på eksisterende chat-løsninger på nettet Ved å intervjue bedrifter som allerede hadde chat-løsninger eller som har planlagt å implementere det Vi startet med å se på andre chat-løsninger, og der fikk vi mye inspirasjon for hva vi kunne implementere i vår egen løsning. Med utallige chat-løsninger ute varierte hvilke funksjonaliteter de hadde implementert betydelig. Vi startet først med å skrive opp de ulike funksjonene som var felles for alle de ulike chat-løsningene som listet i figur 1.4. Først etter at vi hadde skrevet ned alle disse begynte vi å se på videre funksjonalitet. Her var det ting som filoverføring, smileys og videosamtaler. Som tidligere nevnt bestemte vi oss senere for å intervjue noen bedrifter som allerede hadde implementert en chat-løsning. Her fikk vi mye tilbakemeldinger som bidro til å endre på vår egen prioritetsrekkefølge. For eksempel gjorde alle bedriftene vi intervjuet et stort poeng av muligheten til å lagre ferdigskrevne svar som man enkelt kunne sende til kunden. Videre var det viktig for dem at man kunne snakke med flere kunder samtidig, en funksjonalitet vi var usikker på om vi ønsket å implementere. 13

14 Figur 1.4 Prioritering av funksjonalitet 2 Teknologier Webnodes har gitt oss en stor grad av frihet når det gjelder teknologiene vi tar i bruk. De har også foreslått teknologier for oss som vil gjøre det enklere for dem å integrere vårt program inn med deres system senere. Vi har valgt å følge deres anbefalinger ettersom vi ønsker å gjøre det så enkelt som mulig for dem når vi er ferdig med å lage chat-løsningen, slik at de vil velge å ta dette i bruk. I dette kapittelet tar vi for oss hvilke teknologier vi valgte å benytte oss av under prosjektarbeidet samt hvilke verktøy vi brukte for både utvikling og prosjektarbeidet i sin helhet. I seksjon 2.1 går vi gjennom hvilke teknologier det er vi bruker for å lage selve grensesnittet brukerne skal interagere med. I seksjon 2.2 går vi gjennom teknologiene vi bruker på back-end delen av applikasjonen, altså det som skjer bak kulissene. Til slutt runder vi av med å skrive om ulike verktøy vi har brukt i arbeidet. Front-end Front end er delen av applikasjonen brukerne ser og interagerer med. Denne delen av applikasjonen er utrolig viktig ettersom det hovedsakelig er basert på denne en bruker danner seg en formening om applikasjonen. Denne seksjonen tar for seg hvilke teknologier vi bruker for å få orden på front-end. Ettersom dette prosjektet er 14

15 et hybrid prosjekt som benytter seg av både brukersentrert utvikling og produktutvikling blir front-end svært viktig. Det er her ting skal gjøres enkelt og forståelig for brukeren, og også her man kan se om funksjonalitet vil passe inn i løsningen eller om det for eksempel blir for innviklet eller for mye React.js For å forstå hva React.js er må man først forstå hva JavaScript er. JavaScript ble laget i 1995 under navnet Mocha. I 1996 ble programmeringsspråket bragt til Ecma, som er et standardiserings selskap for å bli et standard programmeringsspråk for nettlesere (Web Education Community Group, 2012). I dag er dette tilfellet og alle større nettlesere støtter dette programmeringsspråket. Resultatet av dette er at man kan gjøre endringer og utføre mer kompliserte oppgaver direkte i nettleseren uten å gå gjennom serveren, noe som fører til at vi kan lage dynamiske nettsider som reagerer på hva brukeren gjør. React.js er da et JavaScript bibliotek. Et JavaScript bibliotek gjør det enklere å kode JavaScript, og ulike biblioteker spesialiserer seg på ulike ting. React er laget av Facebook og ble laget fordi de ønsket et JavaScript bibliotek som spesialiserer seg på å gjøre oppdateringer basert på data som endrer seg over tid. I en chat-løsning er dette svært gunstig ettersom dataen konstant vil endre seg ved hver ny melding man mottar. Vi bruker React.js til å lage brukergrensesnittet og all funksjonalitet knyttet til denne. React vil motta data fra serveren og vil enkelt oppdatere kun den spesifikke delen av siden som endret seg, istedenfor å laste inn hele siden på nytt (Facebook, 2013). For en chat melding er dette perfekt ettersom hvis siden skulle oppdateres med hver eneste melding så ville dette blitt svært lite brukervennlig Sass Sass ble først laget i 2006 og ble laget for å gjøre CSS enklere. For å gå videre er det nødvendig med en forståelse av hva CSS er. CSS står for Cascading Style Sheets og benyttes for å tilpasse utseendet på brukergrensesnittet eller nettsiden som er laget. Det ble i 1994 foreslått å gjøre CSS til internettets standard stilark, og i 1996 ble dette iverksatt. Etter et par år støttet de fleste nettlesere CSS og CSS ble da standarden for å tilpasse utseendet sitt slik man ønsker det skulle være. (Bos, 2016) Man kan bruke CSS til å justere posisjonen til ulike elementer på en nettside, endre farger, størrelser, sette inn bilder og mye, mye mer. Mesteparten av nettsidens utseende gjøres gjennom CSS og det er rett og slett essensielt for å kunne lage en webapplikasjon som ser appellerende ut. 15

16 Sass er et skriptspråk som gjør det mulig å skrive mer strukturert og lett leselig CSS. Sass gir oss også muligheter som CSS mangler, men disse mulighetene hadde vært verdiløse hvis man ofret kompatibilitet med nettlesere. Det som gjør det mulig å bruke Sass istedenfor CSS er at Sass konverteres til helt vanlige CSS filer som støttes i enhver nettleser. Noen av funksjonene Sass tilbyr som gjorde at vi bestemte oss for å bruke det er for eksempel å lage konstanter som kan brukes flere steder i koden. Et enkelt eksempel er hvis man har en farge som brukes på flere knapper på siden, så kan man kalle denne fargen «Knapp farge» og kunne bruke denne flere steder istedenfor å lære seg kompliserte fargeverdier utenat. I tillegg gir Sass oss muligheten til å splitte opp koden i mindre biter uten å kreve en stor mengde ressurser fra serveren for å sette disse bitene sammen. Dette gjør det enklere å holde oversikt over hvilken kode som påvirker hvilken del av siden. Sass gir oss også muligheten til å lage funksjoner som resulterer i at vi kan gjøre ting som overhodet ikke er mulig i CSS. Back-end Back-end består av kode som ikke direkte vises til brukeren, men som behandler data og utfører ulike handlinger. Disse handlingene er alt fra å gjøre utregninger på ulik data til å behandle hvordan en kunde og chatassistent skal kobles sammen. I denne seksjonen skal vi gå gjennom de ulike teknologiene vi bruker i back-end delen av vår applikasjon SignalR Kommunikasjonen mellom front-end og back-end vil bli utført av SignalR. SignalR er et Asp.Net bibliotek utviklet av Microsoft som gjør toveiskommunikasjon mellom server og klient mulig. SignalR benytter seg av den beste måten å kommunisere basert på hva klientens nettleser støtter. Dette betyr at den støtter den best mulige kommunikasjonsprotokollen i de nyeste nettleserne, samtidig at den kan nedgradere til eldre protokoller for å støtte et større antall nettlesere. Vi har valgt å benytte oss av SignalR fordi den gjør det enkelt for oss å støtte flere ulike typer nettlesere. Vi må ikke endre vår kode for å ta høyde for ulike typer nettlesere, ettersom SignalR tilpasser seg selv ettersom hva kundens nettleser støtter eller ikke støtter. SignalR gjør det også mulig for serveren å oppdatere klienten selv, noe som er essensielt for en chat-applikasjon. I tillegg har SignalR mange funksjoner som er svært relevante for en chat-løsning slik som muligheter til å gruppere ulike tilkoblinger samt muligheten til å aktivere metoder i React koden fra server. Dette gjør det mulig for oss å lage en løsning som kan håndtere ulik problematikk både hos chatassistenten og kunden fra serveren. 16

17 2.2.2 Asp.Net Asp.Net ble lansert av Microsoft i 2002 (we3schools, n.d.). Microsoft gjorde et stort arbeid for å promotere denne teknologien og videreutvikling har fortsatt jevnt siden da. Denne videreutviklingen har resultert i en svært stabil teknologi med mange ulike hjelpemidler som gjør det enklere å utvikle et godt produkt. Vi har valgt å benytte oss av Asp.Net først og fremst fordi Webnodes benytter seg av Microsoft sine teknologier. Ettersom vår løsning skal knyttes opp mot Webnodes etter hvert er det derfor nødvendig at vi også utvikler vår løsning ved hjelp av Microsoft sine teknologier og teknologier som fungerer i sammenheng med disse. ASP.Net er utviklet av Microsoft og er et open-source web rammeverk som brukes til å utvikle dynamiske webapplikasjoner og webservicer. ASP.Net gjør det mulig å ta i bruk ulike rammeverk og å kode i ulike programmeringsspråk samtidig som det tilbyr en rekke funksjoner som gjør det lettere å utvikle en webapplikasjon som er på et nivå hvor de kan benyttes av bedrifter. Innenfor Asp.Net benytter vi oss også av det som blir kalt Asp.Net Identity. Identity er en påloggingsteknologi innenfor Asp.Net og brukes til å holde oversikt over ulike typer brukere og deres rettigheter. I tillegg til dette støtter Identity pålogging gjennom Facebook, Twitter og Google samtidig som den gir oss muligheten til å registrere egne brukere. Ved å bruke Identity som allerede er en del av Microsoft sine teknologier er det enkelt å bruke dette igjennom hele chatapplikasjonen C# C#, opprinnelig kalt Cool som stod for «C-like Object Oriented Language», et navn Microsoft vurderte å beholde, men ble nødt til å endre grunnet problemer med opphavsrett, ble laget under utviklingen av Asp.Net (Hjelsberg, 2008). Målet var å ta det som fungerte godt med andre programmeringsspråk, og legge til ting for å gjøre dette enda bedre. Asp.Net gjør det mulig å utvikle i flere ulike typer programmeringsspråk som alle har ulike fordeler og ulemper. De to hovedspråkene som benyttes er C# og Visual Basic.Net. Forskjellene mellom disse to språkene er i hovedsak hvordan de skrives. C# er et programmeringsspråk som er svært nært ulike språk vi har benyttet oss av i løpet av studiet, slik som Java, samtidig som vi har benyttet oss av C# i forrige semester. Grunnet dette valgte vi å benytte oss av C# ettersom det virkelig ikke er noen fordeler ved å bruke Visual Basic, og dette ville krevd at vi tilpasset oss et nytt kodespråk. 17

18 2.2.4 Node.js Node.js ble utviklet i 2009 for å kunne håndtere flere pågående brukere på en gang og for å skape muligheten til å skrive kode som kan kjøre asynkront, altså hvor hver kode bit ikke må vente på at den forrige utføres (Dahl, 2011). JavaScript har vært kjent som et programmeringsspråk for nettlesere. Node.js benytter seg av Googles JavaScript-motor for å benytte seg av språket på server siden. Videre så tilbyr også Node ulike pakker gjennom deres Node Package Manager som brukes til å implementere ulike mindre verktøy og hjelpemidler i utviklingen WebRTC & Peer.js Google lanserte WebRTC i 2011 for å kunne gjøre det mulig for nettlesere i mobiler, PCer, osv. å kommunisere i sanntid. Det er et åpent gratis prosjekt og støttes av blant annet Google, Mozilla og Opera. Alle store navn blant nettlesere (WebRTC, n.d.). WebRTC er en teknologi som gir oss tilgang til APIer som gjør det mulig å kommunisere i sanntid med andre nettlesere. Den gir oss mulighet til å bruke mikrofon og kamera fra PCer uten å måtte kreve at du har installert en såkalt plugin på nettleseren din. WebRTC gjør det mulig for to nettlesere å kommunisere med hverandre direkte uten å måtte gå gjennom en server. For å benytte oss av WebRTC bestemte vi oss for å ta i bruk JavaScript biblioteket Peer.js. Peer.js simplifiserer bruken av WebRTC fra koderens perspektiv. Hver nettleser har egne måter å implementere WebRTC, som fører til at vi kodere er nødt til å skrive den samme koden gjentatte ganger på ulike måter. Ved å ta i bruk Peer.js slipper vi dette ettersom denne gjør disse oversettelsene for oss. Verktøy I denne seksjonen skal vi gå gjennom ulike verktøy vi har tatt i bruk for å gjennomføre dette prosjektet. Verktøyene har vært nødvendige ikke bare for utviklingen av løsningen, men også for å holde styr på prosjektarbeidet, for å samarbeide med oppgaven og for planlegging av arbeidet. 18

19 2.3.1 Visual Studio Visual Studio er et utviklerverktøy for ASP.Net applikasjoner. Programmet tilbyr en rekke verktøy for å gjøre utvikling av denne typen applikasjoner enklere og tar seg av integreringen av.net rammeverk. Vi har benyttet oss av Visual Studio ettersom dette kommer med innebygget mulighet til å kjøre løsning lokalt på PCen. Visual Studio er det beste verktøyet til å arbeide med Microsoft sine egne løsninger, men har sine svakheter når det gjelder andre kodespråk slik som React Visual Studio Code Microsoft laget Visual Studio Code for å kombinere et enkelt, men samtidig kraftig utviklerverktøy. De gjorde dette verktøyet tilgjengelig på alle de store operativsystemene i motsetning til Visual Studio og har gjort det mulig for hver bruker å tilpasse løsningen etter sine egne behov. Grunnen til at vi har brukt Visual Studio Code er at dette verktøyet tilbyr langt bedre støtte for React og andre kodespråk som brukes i front-end utviklingen. I tillegg så er programmet lettere i bruk som gjør at den oppfører seg bedre og er raskere i bruk Git gjennom GitHub GitHub baserer seg på Git som er et Versjon Kontroll System. Dette betyr at Git holder oversikt over endringene som blir gjort i det man lager. Denne oversikten gjør det mulig å arbeide sammen på et prosjekt ettersom den holder styr over hvem som gjør hvilke endringer og kan si ifra om disse endringene er i konflikt med hverandre. GitHub bruker Git, men tilbyr en rekke funksjoner som gjør det end enklere å samarbeide eller publisere det man lager. GitHub gir oss et sted å oppbevare løsningen vår og gjør det veldig enkelt å laste det ned igjen hvis et uhell skulle oppstå. 19

20 2.3.4 Trello Utviklingen av Trello begynte i 2010 for å løse vanskeligheter med planlegging i et høyere nivå. Løsningen ble lansert i 2011 og økte raskt i popularitet. Trello er et prosjektstyringsverktøy hvor man kan dele opp oppgaver og delegere disse til de ulike gruppemedlemmene. Vi valgte å bruke Trello fordi det er svært enkelt å bruke, har gode mobilapplikasjoner og oppfyller de behovene vi har i gruppeprosjektet. Vi ønsket å unngå noe med for mange funksjoner ettersom vi ikke følte et behov for dette da vi er en så liten gruppe Slack Slack er et samarbeids verktøy som startet som et internt verktøy i selskapet Tiny Speck mens de utviklet med å skape et spill. Når det gikk dårlig med spillet så stod de fortsatt igjen med et avansert samarbeids verktøy som de selv hadde laget og istedenfor å kaste bort alt arbeidet de hadde gjort valgte de å satse på denne løsningen. Vi valgte å bruke Slack fordi vi hadde behov for et kommunikasjonsverktøy som tilbød litt mer funksjonalitet enn Facebook og Whatsapp. Slack gjør ting som å sende filer, kode snutter, lage grupper og til og med kommunikasjon med bedriften enklere for oss Axure Axure er et verktøy som brukes for å lage wireframes og prototyper av brukergrensesnitt. Prototypene kan da brukes for å vise flyten til programmet, slik at man slipper å programmere et helt brukergrensesnitt som man så må endre på. Etter å ha sammenlignet og testet ut et par andre verktøy for å designe wireframes falt valget for Axure. Axure har fordelen med at man kan kjøre prototypene som HTML filer og dermed få dynamisk innhold og animasjoner på siden. I Axure finnes 20

21 det også en mulighet til å designe prototypene slik at de er skalerbare og kan tilpasses ulike skjermstørrelser. Disse fordelene fører til at vi enkelt kan presentere det vi har utviklet og at det samtidig er enkelt å utføre endringer det samtidig er enkelt. 21

22 Prosessrapport Chatnodes Bachelorprosjekt 2017 Gruppe 32 22

23 Innholdsfortegnelse 1 Beslutninger Kunnskap Hvilke teknologier Learning by doing Arbeidsmetodikk Agile: Vi vil være tilpasningsdyktige Scrum: Ikke for oss Crystal Clear Elementer fra Scrum Datainnsamling Selskap med implementerte Chat-løsninger Involvering av ulike parter i planleggingsprosessen Planlegging Arbeidsrutine Kravspesifikasjon Utarbeidelse av kravspesifikasjon Endringer av kravspesifikasjonen Design av brukergrensesnitt Brukersentrert utviklingsprosess Hva er UI- og UX-design og hvorfor trenger vi det? UX-design kurs Utarbeidelse av funksjonalitet Design av low-fidelity wireframes Utviklingsmiljø Utviklingsprosess Dokumentasjon Prosjektdagbok Møtereferater Wireframes & Prototyper Risikoanalyse Kravspesifikasjon Tidslinje Product Backlog Arbeidsprosess Arbeidsfordeling Læring om nye teknologier Beslutning om intervjuer Forberedelse av wireframes til intervjuene Parallelt arbeid med intervjuer Tilpasninger av brukerønsker Førsteutkast av high-fidelity wireframe React struktur Første prototype Starten på klient siden av chatten Ikoner, lagrede svar, profil-side Tilpasninger av kravspesifikasjon

24 Mobil versjon Klient siden av chatten Tilkobling av database Siste wireframe iterasjon, sanntids-side Webpack migrasjon fra versjon 1 til Forsinkelse, bug fiksing, siste funksjonalitet Testing Resultat Egenevaluering av arbeidsprosess Samarbeid Arbeidsmetodikk Kunde- og Kundeservice-sidene Back-end Videreutvikling Neste iterasjon Framtidig utvikling Prikken over I-en Konklusjon

25 1 Beslutninger Da vi fikk vår oppgave innså vi raskt at mulighetene for hva vi kan lage i praksis er uendelige. Funksjonene vi kan implementere i en chat er endeløse, men det er ikke tiden vår. Det var derfor viktig å finne ut av hvordan vi ønsker å prioritere underveis i prosjektet. Prosjektet vårt kombinerer brukersentrert design og programvareutvikling for å skape en løsning som ikke bare fungerer godt, men som også brukeren vil være fornøyd med og finner enkel i bruk. Det er visse ting som er lettere på system siden enn på design siden og omvendt. Det er derfor viktig at når det skal besluttes om man ønsker å implementere en funksjon så vurderer hvorvidt det er mulig og hvor enkelt det er fra både programvareutvikling og design siden. Noen funksjoner vi tenkte å implementere var lite forståelig for brukeren, eller ikke så relevant som vi opprinnelig trodde og ble derfor droppet, og andre ting var for kompliserte å utvikle på system siden med vår tidsramme. I seksjon 1.1 går vi gjennom beslutninger vi har tatt både når det gjelder hva vi skal lære og hvordan vi tror vi lærer best. Videre i 1.2 tar vi for oss hvordan vi kom fram til arbeidsmetodikken vi har valgt å benytte oss av for så i 1.3 å gå gjennom et valg som har vært svært viktig for oss, nemlig å intervjue bedrifter som tar i bruk eller ønsker å ta i bruk en chat-løsning. Kunnskap Det var åpenbart at for å skrive en bacheloroppgave ville det være nødvendig å bearbeide en omfattende mengde kunnskap. Istedenfor å bare hoppe ut i det og lære underveis ønsket vi å ha dannet i hvert fall noen tanker om hvordan vi skulle håndtere nye teknologier. Det var også viktig for oss å danne en oversikt over hva det er vi behøvde å lære så tidlig som mulig. Noen ting må man selvsagt lære underveis, det er en del av hverdagen som programmerer, men nye teknologier er det viktig å sette seg inn i før man starter å implementere teknologien i oppgaven Hvilke teknologier I vårt første møte med Webnodes ble vi introdusert til oppgaven og skapte oss en liten oversikt om hva et slikt prosjekt vil innebære. Til neste møte hadde Webnodes forberedt et tidlig utkast av en kravspesifikasjon, og det var nettopp denne som førte til at vi begynte å tenke gjennom hvordan vi skulle prioritere arbeidet. Fra møtet og fra kravspesifikasjonen ble vi introdusert til en rekke teknologier som var anbefalt. Det vi så på som en stor utfordring, og samtidig gjorde oss spente var at vi manglet erfaring i nesten alle disse teknologiene. 25

26 De to viktigste anbefalingene vi fikk var å ta i bruk SignalR for kommunikasjon mellom klient og server, samt å bruke React for selve brukergrensesnittet. Å benytte oss av disse var kun anbefalinger fra Webnodes sin side, men de fortalte oss at dette er teknologier de tenker å ta i bruk videre. Vi skjønte da raskt at hvis vår oppgave noen gang skulle tas i bruk så burde vi lytte til deres anbefalinger. Det var også et ønske fra vår side å ta i bruk nye teknologier som var relevante i arbeidsmarkedet. Vi ville også ha en utfordring i bacheloroppgaven og det var til syvende og sist av disse grunner at vi besluttet å prioritere de nye teknologiene framfor effektiviteten som hører med om man arbeider med teknologier man allerede er kjent med. Vi var alle fornøyde med beslutningen ettersom det resulterte i utfordringer, relevant kunnskap for arbeidsmarkedet samt en større sannsynlighet for at vårt produkt til slutt ville ende opp på markedet Learning by doing Learning by doing handler om å lære av erfaringer, altså utføre aktiviteten man skal lære slik at man ved å erfare denne danner en bedre forståelse av det man forsøker å forstå. For å få utbytte av erfaringen er det svært viktig å reflektere over det man har gjort enten for seg selv eller i gruppe. Vi i vår gruppe har en felles tro på at dette er den beste måten å lære på. Å lese om de ulike teknologiene er relevant, men vi synes det fungerer best å lese seg opp på disse teknologiene mens man arbeider med dem. I sin rapport om aktiv læring konkluderer Michael Prince (2004) (s. 7) med at alle former for aktiv læring forbedrer læringsutbytte sammenlignet med tradisjonelle læringsmetoder. I rapporten til (Freeman et al., 2014) konkluderer de også med at studenter som benytter seg av aktiv læring framfor vanlige forelesningsteknikker gjør det bedre under vurderingssituasjoner. Med bakgrunn i dette har vi under prosjektet brukt en del tid på å lage demoer som benytter seg av de ulike teknologiene, slik at vi har en bedre forståelse av disse før vi implementerer de i vår løsning. Ved å lage disse demoene unngår vi å skrive mye kode til oppgaven for så å ende opp med å, som etter tidligere erfaringer å dømme, måtte restrukturere hele prosjektet eller ende opp med kode vi ikke forstår fordi teknologien vi bruker fortsatt er fremmed for oss. Valget vi tok førte til at vi så smått begynte å forberede oss for bacheloroppgaven i god tid før offisiell prosjektstart. Vi snakket med foreleseren vår i et av våre fag om muligheten til å benytte oss av React istedenfor Angular i den siste prosjektoppgaven, ettersom vi allerede da visste at vi kom til å bruke React i 26

27 bachelorprosjektet. Han var positiv til dette og dermed fikk vi et forsprang på prosjektarbeidet. Vi brukte også deler av tiden før offisiell prosjektstart til å lage en demo i SignalR, så når prosjektstart omsider kom stod vi allerede klare med noe kunnskap å bygge videre på. Den viktigste delen av å lage slike demoer var at vi etter å ha fullført demoene sammen gikk gjennom hver av våre løsninger. Ettersom vi alle hadde løst problemet på ulike måter resulterte dette i en enda dypere forståelse av teknologien vi arbeidet med å lære oss. Noen ganger lærte vi noe nytt som en av oss hadde funnet ut av som resten ikke hadde sett, og andre ganger så vi nye måter å bruke ting vi allerede visste om. Arbeidsmetodikk Metodikk er et viktig punkt for prosjektarbeidet. Metodikk bestemmer hvordan vi skal arbeide med prosjektet og tilbyr ofte nyttige verktøy for å forsikre oss en høy kvalitet på løsningen vår. Derfor var det viktig å undersøke hvilken metodikk vi trodde ville passe oss best. Det er mange ulike faktorer som kan påvirke hvilken metodikk som passer best til et prosjekt, og disse måtte tas hensyn til i denne beslutningen. I denne seksjonen går vi går vi gjennom Agile også kalt Smidig arbeidsmetodikk og hvorfor vi valgte å bruke akkurat dette. Vi går også gjennom arbeidsmetodikken Scrum og Crystal Clear. Vi forklarer hvilke valg vi tok og begrunner disse Agile: Vi vil være tilpasningsdyktige Vi ble tidlig enige om å benytte oss av en smidig, også kalt agile, arbeidsmetodikk. Smidig arbeidsmetodikk fokuserer på individer og interaksjoner, fungerende programvare, samarbeid med produkteier og fleksibilitet ("Manifesto for Agile Software Development," 2001). Disse fokusområdene er svært relevante for oss av flere grunner. Vår gruppe har arbeidet sammen i flere måneder nå og prosjektet vårt var helt avhengig av at dette samarbeidet fungerte. Derfor er det viktig, slik som det er lagt vekt på i smidig arbeidsmetodikk, å fokusere på individer i gruppen. Det å skape et godt arbeidsmiljø hvor alle trives er viktig for motivasjonen og vil ha en effekt på kvaliteten til det endelige produktet vårt. Emmanuel kom i sitt studium (Ajala, 2012) fram til at åpen kommunikasjon på arbeidsplassen resulterer i et høyere nivå av produktivitet. Punktet som omhandler det å arbeide med produkteier er svært viktig når man lager et produkt for noen andre, slik tilfellet er for vår bacheloroppgave. Ved å arbeide på denne måten resulterer det ifølge Sari Kujalas rapport (Kujala, 2003) at produkteier 27

28 blir mer fornøyd med produktet som utvikles. Det å involvere brukeren i arbeidsprosessen er krevende, men lønner seg til slutt. I vårt prosjekt har vi da involvert Webnodes gjennom hele prosessen, mens to av selskapene som mest sannsynlig vil benytte seg av produktet ble inkludert helt i starten av prosessen. Vi skulle gjerne involvert disse mer, men det lot seg ikke gjøre. Fleksibilitet er en svært viktig faktor ettersom i teknologiens verden kan ting endre seg hele tiden. I tillegg så er det alltid slik at når man lager et produkt for andre så kan det hende at de vil ønske endringer eller at de vil endre kravene til applikasjonen man utvikler underveis. Man kan også ha misforstått hverandre og ikke finne ut av dette før på et senere tidspunkt, og da er det viktig å kunne tilpasse seg de endringene som måtte dukke opp. Punktet om fungerende programvare handler om at man skal ha et program som i teorien skal være klart til å kunne selges ofte. Fordelen med dette er at du da vil kunne vise fram det nåværende produktet, og produkteier vil kunne teste dette og se om det samsvarer med han eller hennes ønsker Scrum: Ikke for oss Den første arbeidsmetodikken vi vurderte var Scrum. Gjennom studiet har vi hørt mye om nettopp denne måten å arbeide på og den er også tatt mye i bruk i arbeidslivet. Det er tre ulike roller i et scrum team og disse er: Produkteier Utviklingsteam Scrum Master. Produkteier er da selvforklarende nok de som eier produktet som utvikles. Som nevnt tidligere så er det viktig i smidig metodikk å samarbeide med de som ønsker produktet, slik at produktet blir slik de ønsker det skal være. Det er enkelt å falle i fellen hvor man utvikler det man selv synes er best, når dette ikke nødvendigvis samsvarer med eierens ønsker. Produkteiers hovedoppgave er derfor å holde seg oppdatert på hvordan utviklingen foregår og se om dette faktisk samsvarer med det ønskede resultatet til bedriften eller enkeltpersonen. De skal også passe på at det som kalles product backlog er sortert i riktig rekkefølge. En product backlog er en liste over ting som skal legges til i løsningen, og denne listen er essensiell for at utviklerne skal utvikle det kunden faktisk ønsker. Utviklingsteamet består av alle som tar del i den faktiske utviklingen at løsningen. Dette er da ikke kun de som programmerer, men også designere og alle andre som er nødvendige for arbeidet. Utviklingsteamet skal være selvorganiserende og ingen 28

29 andre kan fortelle dem hvordan de skal utføre sine oppgaver. De arbeider basert på product backlog, ved å implementere ting i den prioriterte rekkefølgen. Scrum master har et ansvar ovenfor utviklingsteamets produktivitet. Scrum master skal sørge for at det er et godt arbeidsmiljø, holde oversikt over hvordan arbeidet går og beskytte dem fra forstyrrelser utenifra så godt som det lar seg gjøres. Figur 1.1 viser hvordan Scrum prosessen foregår. Prosessen er delt inn i perioder som kalles Sprinter. En sprint starter med en runde Sprint Planning. Her planlegger man målene for en sprint, og som figur 1.1 viser så hentes de prioriterte kravene fra product backlog. Kravene velges etter prioritering og basert på hva som er realistisk for en sprint. Disse legges så inn i Sprint backloggen. Sprint backlog er en liste som definerer hvilke krav som skal arbeides med under den tilhørende sprinten. Det er ikke et krav å fullføre hele Sprint backlog, men det er heller en indikasjon på hva gruppen planlegger å fullføre. Figur 1.1 Scrum prosessmodell Etter scrum planning begynner selve sprintet. En sprint er kun en tidsperiode og er som regel mellom 1 uke og en måned lang. Da jobbes det med de kravene som er spesifisert i sprint backlog, og hver dag møtes man under det som kalles Daily Scrum. Et Daily Scrum møte varer i omtrent 15 minutter og her går alle i teamet gjennom hva de gjorde i løpet av forrige arbeidsdag, også setter man sammen en plan for de neste 24 timene. Når en sprint avsluttes så har man slik det er vist i figur 1.1 en Sprint Review. Her går man gjennom hele prosessen med produkteier og alle andre med interesse i produktet. Man ser hva som har blitt gjort fra Product Backlog og produkt eier får da mulighet til å se at arbeidet går mot det ønskede produktet. Her justeres også Product Backlog og man starter å planlegge videre arbeid. Til slutt har man det som kalles Sprint retrospective. Her diskuterer teamet hva som har gått bra i sprinten, 29

30 hva som kan bli bedre og hva er det vi skal gjøre bedre i neste sprint. Etter dette så starter prosessen på nytt slik som vist i figur 1.1. Det er veldig mange gode verktøy i Scrum, men etter å ha gått gjennom arbeidsmetodikken og diskutert med veilederen vår så kom vi fram til at å bruke Scrum ville krevd mer tid enn vi tenker er nødvendig for å styre prosjektet. Ettersom vi er en liten gruppe på tre medlemmer så trenger vi ikke en arbeidsmetodikk fullt så avansert som det Scrum er. Allikevel er det visse hjelpemidler fra Scrum som vi besluttet å ta med oss i arbeidet Crystal Clear Etter å ha gått gjennom Scrum innså vi at vi ønsket en mer fleksibel arbeidsmetodikk som allikevel skaper visse rammer vi må arbeide innenfor. Vi startet å titte på andre arbeidsmetodikker og la raskt merke til Crystal Clear. Crystal Clear benyttes generelt av små grupper og er derfor fleksibel, og legger opp for tett kommunikasjon mellom gruppemedlemmene. Metodikken legger hovedfokus på tre punkter: Hyppig levering av brukbar kode til brukeren. o Skape kode som kan leveres til brukeren eller produkteier så ofte som mulig. Reflekterende forbedring. o Utviklerne tar pauser fra utviklingen for å reflektere over måten arbeidet utføres på og se om det er noe som kan forbedres. Osmotisk kommunikasjon. o Gruppen arbeider i samme rom og får informasjon til å flyte i rommet. Det er også noen andre punkter som er mulige å benytte seg av ved bruk av Crystal Clear: Personlig trygghet. o Det skal være et åpent miljø hvor alle tør snakke og stille spørsmål. Fokus. o Fokus på individuelle arbeidsoppgaver, gi utviklerne tid til å virkelig komme i gang med arbeidet sitt og unngå for mange avbrytelser slik som møter og liknende. o Fokus på prosjektets retning. Enkel tilgang til en ekspert bruker. o Ha en ekspert tilgjengelig så mye som mulig. Dette kan være utfordrende i mange situasjoner. 30

31 Teknisk utviklingsmiljø med automatiske tester, konfigurasjonsstyring og hyppig integrering. o Skaper det best mulige arbeidsmiljøet ved at tester gjøres hyppig slik at feil oppdages tidlig og unngår dermed å sette prosjektet langt tilbake. Disse punktene er valgfrie og vi valgte å inkludere dem i så stor grad som det lot seg gjøre i prosjektarbeidet. Når det gjelder punktet om tilgang til en ekspert bruker så fikk vi dekket behovet i visse deler av prosjektet vårt, men noe av teknologien vi benyttet oss av var også nytt for bedriften og her måtte vi altså klare oss på egenhånd Elementer fra Scrum Vi syntes at rammene Crystal Clear setter rundt oppgaven var viktige og svært praktiske for prosjektarbeidet, men vi ønsket allikevel å ta i bruk noen av verktøyene fra Scrum metodikken som Crystal Clear vanligvis ikke benytter. Vi valgte å benytte oss av Daily Scrum som da er et kort møte på starten av dagen hvor man går gjennom hva man har gjort dagen før, hva man skal gjøre i dag og om man ser noen problemer som vil hindre gruppen i å nå målene sine. Dette er en fin måte å gjøre det mulig for gruppemedlemmene å holde oversikt over hverandre, se til at alle arbeider og at alle arbeider med noe relevant. Vi valgte også å ha en Product backlog som da er en liste med krav til systemet sortert etter hvor viktige de er for løsningen under utvikling. Vi har da brukt denne for å forsikre oss om at vi arbeider med det som er mest relevant for prosjektet vårt slik at vi er sikre på å ha den nødvendige funksjonaliteten klar ved slutten av bachelor perioden. Når vi laget denne product backlog så la vi også opp til videreutvikling av løsningen ettersom dette er noe Webnodes planlegger å arbeide med videre. Datainnsamling Vi som gruppe besluttet etter de første par ukene å benytte oss av «Participatory Design Approach» for å utvikle denne løsningen. Det Participatory Design Approach går ut på er å involvere alle ledd i design prosessen. Med ledd menes da ulike interessenter, aktører med interesse i vår løsning, som da eiere, sluttbrukere, partnere, osv. Disse skal da involveres så mye som mulig, og hvor stor involveringen blir varierer da fra interessent til interessent. Arbeidet med Webnodes var allerede i orden ettersom vi arbeidet i samme kontor og hadde regelmessige møter. I tillegg til disse ønsket vi å inkludere sluttbrukerne. Sluttbrukerne ville da være selskapene som kom til å benytte seg av løsningen, og 31

32 de ansatte som kom til å arbeide som kundeservice. I studiet kalt «Empirical investigation of the impact of using co-design methods when generating proposals for sustainable travel solutions» (Mitchell, Ross, May, Sims, & Parker, 2016) konkluderes det med at ved å samarbeide om design viser utviklere et høyere nivå av kreativitet. Denne kreativiteten fører også til mer innovative løsninger, ikke fordi kvaliteten på ideene øker, men fordi antall ideer øker som resulterer i noen ideer med et høyere nivå av innovasjon. Vi bestemte oss for å intervjue disse sluttbrukerne av løsningen vår, og vise dem en prototype for så å ta deres tilbakemeldinger med oss tilbake til Webnodes hvor vi kunne videreutvikle våre planer for applikasjonen vår. Videre så var det også viktig for oss å samle informasjon om allerede eksisterende chat-løsning. Det var nødvendig for oss å ha et utgangspunkt å gå ut ifra, og ved å se på allerede eksisterende løsninger så kan vi utforske hva som fungerer bra, hva som kan gjøres bedre og hva som ikke fungerer. For å samle informasjon om eksisterende løsninger var det i hovedsak to ting vi gjorde. Først brukte vi nettet til å undersøke så mange chat-løsninger som vi kunne finne. Vi tok notater av disse og tok inspirasjon fra ting vi synes så ut til å virke godt, og unngikk alt annet. I tillegg til dette besluttet vi å prøve å arrangere intervjuer med selskap som allerede har implementert kundeservice gjennom chat på siden deres. Dette så vi kunne få mer konkret informasjon om de ansattes side av chatten, ettersom vi ikke kan få sett dette ved å besøke nettsider Selskap med implementerte Chat-løsninger Da vi begynte vi å kontakte bedrifter som tilbød kundeservice gjennom chat var det ingen spesifikke typer bedrifter vi gikk etter. Grunnen for det var at Webnodes sin kundebase i seg selv er utrolig variert, derfor hadde vi tro på at uansett hvilken type bedrift vi kom i kontakt med så ville dette bidra positivt til vår oppgave. I løpet av et par dager og mange avvisninger fikk vi til slutt arrangert møter med to selskap. Et av disse er et detaljhandelsselskap og det andre en mobiloperatør. Begge disse bedriftene er store innenfor sine respektive felt som gjorde faktumet at vi skulle møte dem veldig spennende. Fra møtene fikk vi viktig tilbakemelding som resulterte i noen endringer i planleggingen. Vi var så heldige å få se selve chatløsningen til begge bedriftene i bruk. Fra møtene fikk vi se hvilke funksjoner som var viktigst for selskapene, og hvorfor en chat i seg selv var viktig. Muligheten til å snakke med flere kunder på en gang var noe begge chat-løsningene tilbød, og noe som var viktig for begge vi intervjuet. Den 32

33 funksjonaliteten som ble påpekt som aller viktigst var det som kalles lagrede svar. Dette kan da være en lagret velkomst melding, eller et lagret svar på ofte stilte spørsmål. Noe som overrasket oss var mangelen innenfor design, begge løsningene var lite appellerende for øyet noe som gjorde oss mer selvsikre når det gjelder vår egen planlagte løsning. Begge disse møtene finnes dokumentert i Vedlegg 6.3 og Involvering av ulike parter i planleggingsprosessen En utfordring vi møter på ved å utvikle en kundeservice løsning for Webnodes er at vi ikke utvikler for en spesifikk gruppe brukere. Kundene til Webnodes består av mange ulike typer bedrifter, og det blir derfor umulig for oss å skreddersy vår applikasjon til alles behov. Istedenfor er vi nødt til å finne behovene som er felles for de aller fleste og fokusere på nettopp disse essensielle funksjonene. Hvis vi i motsetning til vår situasjon hadde arbeidet direkte med en spesifikk bedrift som skulle benytte seg av chatten, ville det vært langt enklere for oss å personalisere løsningen når det gjelder både utseendet og funksjonalitet. Istedenfor er vi nødt til å prøve å skape et så nøytralt design som mulig som kan fungere på nettsider flest. Ved videreutvikling vil det være nødvendig å skape muligheten for at kundene selv skal kunne endre farger og ikoner for løsningen, men dette er utenfor vår prioritering. For å involvere de ulike interessentene i så høy grad som mulig besluttet vi å samarbeide med dem på to ulike måter. Når det gjelder Webnodes så har vi regelmessige møter med dem, omtrent ukentlig. Her går vi gjennom hvordan den nåværende løsningen ser ut samt diskuterer endringer som kan gjøres og hva som skal gjøres videre. I tillegg diskuterer vi hvilket arbeid som skal prioriteres. For å involvere sluttbrukerne bestemte vi oss for å arrangere møter med noen av selskapene som benytter seg av Webnodes sitt produkt, og intervjue disse. Etter at vi besluttet å kontakte ulike bedrifter tok vi raskt kontakt med vår daværende kontaktperson i Webnodes, og spurte om det var akseptabelt for dem at vi kontaktet deres kunder for å arrangere noen møter. Han sa at dette var en utmerket idé, men han ønsket å arrangere møtene for oss. Det tok litt tid fra Webnodes sin side, men etter en uke så hadde vi fått arrangert møter med to av selskapene som benytter seg av Webnodes og som var interesserte i en chat-løsning. Webnodes ønsket å selv være tilstede på disse møtene, selv om dette var en litt skremmende tanke så var det også velkomment ettersom de da kunne bidra med å stille spørsmål vi muligens ikke hadde tenkt over selv. 33

34 Vi tok med oss kunnskapen vi hadde fått fra selskapene med eksisterende chatløsninger til disse møtene, nå når vi hadde sett hva som allerede eksisterer var det viktig å bygge videre for å finne ut hvordan vi kunne gjøre det enda bedre. Møtet var også viktig for Webnodes ettersom de til slutt vil videreutvikle det vi har laget i løpet av prosjektet. Disse selskapene hadde mange meninger, og det er ved dette punktet i prosjektet det ble viktig å prioritere ulike funksjonaliteter. Forslag som en chatbot med kunstig intelligens som automatisk svarer på spørsmål og en betalingsløsning i chatten er utrolig spennende funksjonaliteter, men vi bestemte oss for å prioritere de mest nødvendige funksjonene først, også se hva tiden vil la oss implementere. Ønsker som lagrede svar, timer Begge disse møtene finner du dokumentert i vedlegg 6.1 og Planlegging Planlegging er en svært viktig del av et prosjekt av vår størrelse. Vi ble selv overrasket over hvor krevende denne prosessen var og grunnet vårt ønske om å involvere bedriftene som ønsker å ta i bruk produktet vårt ble denne prosessen et stykke lenger enn det som opprinnelig var tenkt. Allikevel tror vi at vi fikk mye igjen for dette forarbeidet. Vi starter seksjonen med å gjennomgå hvordan vi planla å arbeide, som da involverer sted og arbeidstid. I seksjon 2.2 går vi gjennom kanskje det viktigste som kom ut av planleggingsfasen, nemlig kravspesifikasjonen. I neste seksjon som er 2.3 tar vi for oss planleggingen av et brukervennlig og brukertilpasset design før vi runder av med å presentere prosjektets utviklingsmiljø i 2.4. Arbeidsrutine Vi tok valget om å bli enige om hvilke tider vi skulle arbeide i god tid før prosjektstart. Når alle hadde informasjonen og timeplanene som var nødvendige for å planlegge snakket vi sammen og kom fram til at vi skulle arbeide 8 timer hver dag fire dager i uken. Oppmøte skulle da være klokken 10:00 og vi avsluttet da dagen klokken 18:00. Etter litt over en måned ble dette tidspunktet endret til at vi startet dagen klokken 9:00 og avsluttet klokken 17:00. Ettersom to av gruppemedlemmene hadde forelesninger på onsdager, samt at en av dem arbeidet denne dagen så bestemte vi at onsdag skulle være dagen vi ikke 34

35 arbeidet med bachelor oppgaven. Samtidig ble vi enige om at man gjerne skulle bruke et par timer på bachelor oppgaven i løpet av helgen, men da individuelt. Ettersom vi var så heldige at vi fikk et kontor hos Webnodes så ble dette arbeidsplassen vår. Skolen fungerte som en back-up når det oppstod tekniske problemer hos Webnodes og til arbeid under helgene hvis det var ønsket. Kravspesifikasjon Kravspesifikasjon er et av de desidert viktigste dokumentene i et systemutviklingsprosjekt. I et slikt dokument står ønskene produkteier har for produktet. Det er også i dette dokumentet man finner ulike krav til løsningen, slik som hvilke teknologier som skal brukes, hva som skal støttes og lignende. Ettersom prosjektet vårt er et hybrid prosjekt som kombinerer programvareutvikling og brukersentrert design vil kravspesifikasjonen omhandle både brukergrensesnitt samt det tekniske ved systemet. I vår oppgave har det vært fokus på «User Centered Design». Enkelt forklart betyr dette at under prosjektet har vi lagt stort fokus på å tilpasse utseendet og funksjonaliteten i oppgaven vår basert på brukernes behov. Involvering av kunder kan tilpasses etter hva som er mulig eller føles nødvendig. I vår situasjon var det vanskelig å inkludere sluttbrukeren ettersom disse er utenfor selskapet Webnodes, men Webnodes fikk vi involvert i høy grad gjennom hele prosessen Utarbeidelse av kravspesifikasjon Kravspesifikasjonen vår ble i første omgang laget av Webnodes ettersom dette er et produkt de håper å kunne ta i bruk og selge videre til deres kunder. Vi gikk gjennom denne under møtet i november. Her kom det fram at for Webnodes var det viktigst at klient siden var arbeidet mest med, dette grunnet at mye i back-end delen vil måtte erstattes ettersom Webnodes er midt i en massiv omstrukturering av deres løsning, som dessverre gjør det umulig å koble vårt prosjekt sammen med deres system i vår prosjektperiode. De mest sentrale punktene av den opprinnelige kravspesifikasjonen er listet opp i følgende figur

36 Kunde - Enkelt design - Brukervennlig - Kompatibel med PC, nettbrett og mobil - Ikke for visuelt dominerende Kundeservice - Mye informasjon tilgjengelig - God bruk av skjermareal - Basis funksjonalitet på plass Back-end - Ryddig datamodell - Ryddig API - Raskt og effektivt - Utvidbart Figur 2.1 Sentrale krav i den opprinnelige kravspesifikasjonen Hele applikasjonen må kobles sammen, og med flere ulike komponenter er det viktig å vite hvordan de ulike delene skal kobles sammen. Vi laget en enkel skisse som viser hvordan de ulike delene er koblet sammen, dette vises i figur 2.2. Figuren viser hvordan alle de ulike delene kommuniserer igjennom SignalR teknologien. I tillegg så er det visse tilfeller hvor back-end og de to andre delene må kommunisere utenom SignalR. Et eksempel på dette er helt i starten når man logger på siden, da er det nødvendig for back-end å gi noe informasjon direkte til kunden eller kundeservice. 36

37 Klient Kundeservice SignalR Back-end Figur 2.2 Viser hvordan de ulike delene av løsningen er koblet sammen Endringer av kravspesifikasjonen Kravspesifikasjonen er et dokument som må holdes oppdatert med eierens ønsker. Underveis gjennom utviklingen må man derfor være forberedt på at endringer vil oppstå. Ved å ta i bruk smidig metodikk som forklart i seksjon 1.2 er vi mer forberedt på å håndtere slike endringer ettersom dette er noe smidig metodikk utmerker seg på. Da vi tok beslutningen om å møte bedriftene som kom til å ta i bruk applikasjonen så antok vi at det kom til å resultere i endringer i kravspesifikasjonen, noe som viste seg å stemme. Ting vi hadde valgt å sette lenger ned på prioriteringslisten ble satt høyere oppe. Et av de beste eksemplene er muligheten til å ha svar på spørsmål som blir stilt ofte enkelt tilgjengelig. Dette var noe selskapene som allerede har implementert en chat synes var en av de viktigste, om ikke den viktigste, funksjonaliteten i chat-løsningen deres. Bedriftene som ønsker en chat-løsning var også helt enige i at denne funksjonen var svært viktig. I løpet av prosjekt perioden fikk vi en ny kontaktperson hos Webnodes. Da dette skjedde så tok vi en ny titt på kravspesifikasjonen. Vi endte opp med å tilpasse kravspesifikasjonen på et par punkter etter kontaktpersonens ønsker og noen av disse resulterte at vi måtte gjøre endringer i det allerede eksisterende prosjektet for å oppfylle de nye kravene. Noen av de viktigste endringene som ble innført er at utseendet til applikasjonen kun skal endres gjennom CSS og at siden for 37

38 chatassistenter også skulle tilpasses mobiler, noe vi tidligere hadde fått beskjed om at ikke var relevant. Den endelige kravspesifikasjonen finnes som vedlegg 1. Design av brukergrensesnitt Dette er et prosjekt som er en hybrid mellom programvareutvikling og brukersentrert utvikling. Både for oss og for oppdragsgiver var det viktig å utvikle et produkt som er brukervennlig, da dette er en applikasjon som sluttbruker fysisk skal interagere med. Applikasjonen vil bli tatt i bruk i servicebransjen for å tjene kunder. Den viktigste faktoren er da at sluttbrukerne skal være tilfredsstilte. Et mål er at både klient og chatassistent selv skal ønske å ta i bruk produktet (Psychogios, 2014). For å få til dette har vi valgt å tilpasse oss sluttbrukernes behov og har gjennom denne prosessen inkludert sluttbrukerne. Som en av de første stegene ved utarbeiding av et brukergrensesnitt er det viktig å planlegge og å lage wireframes (Lana, 2016). Designet skal kunne skaleres og være tilpasset eventuelle utvidelser. I denne delen vil vi ta for oss utviklingsprosessen, alle forberedelser som ble gjort før wireframes ble utviklet, vi vil komme innom noen av de mest sentrale begrepene innenfor design og hvordan de første wireframene ble utformet Brukersentrert utviklingsprosess Vi har valgt å sette brukeren i sentrum og ønsker å ta utgangspunkt i brukerens behov og ønsker under utviklingen. For å få til dette har vi tatt i bruk ulike metoder. Vi har gjort undersøkelser av eksisterende chat-løsninger som finnes på markedet, intervjuet selskaper som benytter seg av en slik løsning og intervjuet potensielle kunder. Vi har kontinuerlig under denne prosessen gjort tilpasninger og endringer som vil gi mest mulig utbytte til brukerne. For å kunne sette brukerne i sentrum har vi benyttet oss av en brukersentrert utviklingsprosess. Brukersentrert utvikling involverer kundene i utviklingsprosessen hvor fokuset er brukskvalitet. Det første steget er å involvere brukerne så tidlig som mulig i prosessen (Abras, Maloney-Krichmar, & Preece, 2004). Når man har de første prototypene klare har man muligheten til å få disse evaluert, og man kan utføre endringer basert på disse tilbakemeldingene. Ved å kontinuerlig presentere prototyper vil det kontinuerlig kunne gjøres endringer og tilpasninger, og man kan sikre seg at man utvikler noe kunden ønsker. Mot slutten av en slik prosess er det viktig med brukertesting. På dette stadiet får man testet om produktet lever opp til forventningene og hvordan produktet vil bli tatt imot av en faktisk bruker (Psychogios, 2014). 38

39 For å kunne gjennomføre en slik prosess hvor vi gjør undersøkelser, utvikler prototyper, får tilbakemelding og så gjør tilpasninger valgte vi å ta i bruk modellen Build-Measure-Learn Dette er en modell for å kontinuerlig forbedre nye produkter på en rask og kostnadseffektiv måte. I praksis fungerer modellen som en syklus hvor man utvikler noe, lar brukerne teste det, måler deres reaksjon og til slutt lærer man av resultatene (Ries, 2011). Ved å benytte oss av denne modellen kan vi hele tiden passe på at vi får tilbakemeldinger og gjør nødvendige endringer og tilpasninger. Ved å kombinere Build-Measure-Learn modellen med en brukersentrert utviklingsprosess får vi en modell som er effektiv og som tar hensyn til både bruker og brukers behov eller ønsker. Figur 2.3 under illustrerer hvordan disse iterasjonene vil foregå i praksis. Figur 2.3 Brukersentrert utviklingsprosess med Build-Measure-Learn I den første fasen som består av «Build» vil vi fokusere på å utforme skisser og prototyper. I brukersentrertutvikling er dette et sentralt punkt og det er vanlig at man utvikler prototyper underveis i prosessen (Sinkevičiūtė, 2015). Det finnes flere grunner for at det er lønnsomt å utvikle prototyper. Skisser og ideer av design kan ofte vike mye fra hvordan produktet kommer til å bli i virkeligheten. For å unngå en prosess hvor det man utvikler ikke samsvarer med brukerens behov er det lønnsomt å utvikle noe som fysisk kan bli vurdert (Upton, 2010). Dette vil skje i neste fase som består av «Measure». I denne fasen tar man mål av de prototypene man har utviklet til nå. Målene er i form av tilbakemeldinger eller undersøkelser som man for eksempel får fra kunder og produkteier. Deretter kan man lære av disse tilbakemeldingene i fasen «Learn». Her vil man ta til seg de tilbakemeldingene man 39

40 har fått og vurdere om det er ønskelig å utføre endringer eller tilpasninger (Ries, 2011). I vårt tilfelle gjennomførte vi fem slike iterasjoner før vi endte opp med en ferdigstilt prototype i form av wireframe. Prototypene i fasen «Build» utviklet vi i form av lowfidelity og high-fidelity wireframes. Low-fidelity wireframes er det første man utvikler. Disse skal ikke inneholde mange detaljer eller farger, de skal være enkle og kun fokusere på den viktigste funksjonaliteten (Natoli, 2016). Slik som figur 2.4 illustrerer så er high-fidelity wireframes en videreutvikling av en low-fidelity wireframe som innholder flere detaljer, viser interaksjon og hvordan komponentene skal opføre seg. Figur 2.4 Utviklingen fra low-fidelity til high-fidelity wireframe For de tre første iterasjonene utviklet vi low-fidelity wireframes før vi gikk over til å designe high-fidelity wireframes for de to siste iterasjonene slik som illustrert i figur 2.5. I hver iterasjon gjennomgikk vi de tre fasene fra Build-Measure-Learn modellen. Figuren inneholder mer detaljer om hvordan vi målte tilbakemeldinger på wireframene og hvilke endringer det vi lærte førte til. Figur 2.5 Prosessen for utvikling av low-fidelity og high-fidelity wireframes i form av Build-Measure- Learn modellen 40

41 Ved å følge en slik prosess fikk vi samlet inn mange brukerønsker fra både kunder og produkteier. Vi hadde dermed muligheten til å forbedre våre prototyper med hensyn til tilbakemeldingene vi fikk. Tilbakemeldingene fikk vi blant annet ved å ha hyppige statusmøter med både veileder og oppdragsgiver, arrangere intervjuer med selskaper og ved å gjøre undersøkelser på nett. Etter et endt møte eller intervju tok vi en vurdering på om forslagene til endringer var noe vi ønsket å forholde oss til eller ikke. De nødvendige endringene ble utført før neste iterasjon slik at vi igjen kunne få tilbakemeldinger på arbeidet vårt. Videre i denne seksjonen men også videre i seksjon 3.2 om arbeidsprosess kommer vi nærmere inn på de ulike iterasjonene illustrert i figur 2.5 over. Det beskrives i detalj hva som ble endret fra en iterasjon til neste, hvordan vi kom frem til disse endringene og hvordan resultatet ble til Hva er UI- og UX-design og hvorfor trenger vi det? Det er flere elementer man må tenke på når man skal utvikle brukergrensesnitt med brukeren som fokus. UX- og UI-design handler om brukeropplevelser og brukergrensesnitt som er to sentrale deler for dette prosjektet. I følge Usability.gov som er en ledende ressurs for veiledning når det kommer til brukeropplevelser så handler det om å ha en dyp forståelse for brukerne (U.S. Department of Health & Human Services, u.d.). UI-design går ut på å skape et brukergrensesnitt som legger til rette for at interaksjon mellom systemet og brukeren kan utføres så enkelt som mulig. Dette vil si at grensesnittet inneholder elementer som er lett tilgjengelig, lette å forstå og å bruke (ibid). Det er viktig å tenke over hvordan farger, font og plassering av elementer kan være med på å påvirke hvilke valg en bruker vil ta. Design av brukergrensesnitt handler derfor om hva brukeren ser og hvordan det påvirker hvilke handlinger de tar. Et brukergrensesnitt med god design vil være med på å styrke brukeropplevelsen (Galitz, The Essential Guide to User Interface Design: An Introduction to GUI Design, 2007). Brukeropplevelsen avhenger av ulike faktorer og skiller seg fra de faktorene som er viktige for design av brukergrensesnitt. Dette er illustrert i figur 2.6 som fremstiller de mest sentrale forskjellene på UX- og UI-design. 41

42 Figur 2.6 Sentrale faktorer for UX- og UI-design og ulikhetene mellom disse. Ikoner hentet fra « av Nikita Golubev og Freepik Det finnes ingen fast definisjon på hva UX-design er men det handler om hvordan elementer påvirker brukeren med tanke på hvordan de reagerer og oppfatter det som skjer. Slike elementer inkluderer hva brukeren ser og kan interagere med (Unger & Chandler, 2012). Fra figur 2.6 ser vi at en av faktorene for å skape gode brukeropplevelser er å utføre brukerundersøkelser. Noe som bidrar til å skape enda bedre brukergrensesnitt og bedre brukeropplevelser er interaksjonsdesign. Interaksjonsdesign går i hovedsak ut på hvordan en bruker kan interagerer med et program eller en tjeneste. Fordelene med god interaksjonsdesign er at brukerne kan får vite hvilke funksjonaliteter som er tilgjengelige, forutse hva som kommer til å skje eller hva som har skjedd, hva som skal til for å få utført det man ønsker og hindre brukerne i å gjøre for mange feil (Natoli, 5 principles of interaction design, 2014). For å oppnå dette finnes det fem prinsipper som bør fokuseres på. Disse prinsippene er beskrevet i figur 2.7 under. 42

43 Figur 2.7 Sentrale elementer ved interaksjonsdesign Det første prinsippet går ut på at designet skal være konsistent. Man skal alltid tenke over om noe trenger å være annerledes. Dersom det ikke har en spesifikk funksjon at et element skal skille seg ut så er dette noe man bør unngå. Brukeren skal kunne ha hovedfokuset sitt rettet mot innholdet på siden og ikke de visuelle elementene og av den grunn er det viktig å unngå å skape for mange distraksjoner. For å skape konsistens kan man benytte seg av gjenkjennelige komponenter, gruppere elementer som oppfører seg likt og også bruke samme stiler. Ved at noe er gjenkjennelig er det enklere for brukerne å lære seg og å huske hva som kommer til å være resultatet av ulike interaksjoner (Natoli, UX & Web Design Master Course: Strategy, Design, Development, 2016). Prinsippet om læring går ut på å sette opp en side slik at brukerne optimalt kan bruke systemet, lære seg det og deretter kommer til å huske det. I praksis vil det kreves at systemet tas i bruk et par ganger først men målet er å bidra til at brukeren kan lære seg systemet så raskt som mulig. Dette kan oppnås ved å designe et intuitivt brukergrensesnitt også kalt single-trial learning. Dette vil si at etter å ha gjort noe første gang kan man få det til igjen som tyder på at komponenter var tydelige, konsistente og synlige (Natoli, 5 principles of interaction design, 2014). 43

44 Prinsippet om forutsigbarhet innebærer å oppfylle forventningene til brukerne. Brukerne skal kunne forutse hva som kommer til å være utfallet før en interaksjon. Dersom de kan gjøre dette vil det si at handlingen som utføres er forståelig, tydelig og logisk. Derom en bruker ikke forstår hva man kan gjøre på siden vil de prøve å trykke på alt mulig på skjermen. For å unngå dette kan man bruke etiketter, ikoner og bilder som hjelpemidler for å kunne skape forståelse (ibid). Som vist i figur 2.7 handler prinsippet om synlighet om å synliggjøre at interaksjonsmuligheter er tilgjengelige. Det må være en balanse mellom hva som gjør noe tilbyende og hva som gjør det lett å forstå. For å oppnå dette er det nødvendig å fremheve valgmuligheter som blant annet ved bruk av farger og ikoner (ibid). Farger og ikoner skal brukes med en bevissthet om at brukeren tror det er et element for interaksjon (Natoli, UX & Web Design Master Course: Strategy, Design, Development, 2016). Siste prinsipp handler om tilbakemeldinger. Tilbakemeldinger er med på å skape en mer positiv brukeropplevelse. Resultater av interaksjon trengs i form av tilbakemeldinger. Brukeren trenger et "bevis" på av noe har skjedd og en bekreftelse på om det ble utført korrekt eller galt. Som satt opp i figur 2.7 så vil tilbakemeldinger være med på å svare på spørsmålene hva vil skje, hva skjer, hva skjedde og hva gikk galt for brukeren (Natoli, 5 principles of interaction design, 2014). I følge David Hogue som er en UX- og interaksjonsdesigner så bør det være en synlig og forstående reaksjon for hver handling (Hogue, 2012) UX-design kurs Før vi satte i gang prosessen med å utvikle wireframes ønsket vi å tilegne oss mer kunnskap om hvordan en slik prosess bør gjennomføres og hvordan vi kan anvende UX- og UI-design prinsippene i praksis. UX-design går ut på å skape et design som gir gode brukeropplevelser. Ved å ta utgangspunkt i disse prinsippene vil vi kunne skape et enkelt og brukervennlig design, som er ønskelig fra oppdragsgiver. I og med at vi ikke hadde mye forkunnskaper om UX-design eller hvordan en designprosess bør gjennomføres valgte vi at gruppens design ansvarlig skulle ta et UX-design kurs. Ved å gjennomføre et slikt kurs vil dette gi oss et bedre grunnlag for hvordan en slik prosess kan gjennomføres enn hva vi har hatt muligheten til å lære gjennom våre fag på studiet. Kurset gikk gjennom prosessen for å skape et brukervennlig design med gode brukeropplevelser med hensyn til design prinsippene. Kurset er delt inn i fire faser, hvor den første fasen tok for seg definisjonen av hva UX-design er og hva det går ut 44

45 på. I denne delen ble det også gått gjennom hvordan utviklingsprosessen skal planlegges. Det er tre viktige spørsmål å tenk over, hva er verdt å gjøre? Hva skal vi utvikle? Hvilken verdi skaper det? Deretter er det viktig å starte å utføre undersøkelser som skal resultere i å identifisere brukerkrav. Til slutt i denne fasen planlegges front-end brukertesting. Det settes opp en detaljert plan hvor man tenker over alle aspektene av produktet og hva som er relevant å teste. Planen er en generell plan som ble gjennomgått i kurset og det er ikke sikkert alle de ulike delene vil være relevante for oss. Planen finnes som vedlegg 4. og vil senere bli benyttet i testfasen av prosjektet. Til slutt skal dette resultere i wireframes som er en visuell guide som representerer hvordan det endelige produktet vil se ut. Kurset inneholdt en brukerveiledning på hvordan slike wireframes kan utvikles med Axure Pro. I fasen som omfattet design ble det lagt stor vekt på UI-design prinsippene. Disse ble gjennomgått i detalj med vektlegging på hva det er som skaper et tidløs design. Det ble også lagt vekt på interaksjonsdesign med fokus på at det skal være konsistent, synlig, lærbart, forutsigbart og gi tilbakemeldinger til brukeren. Den siste fasen av dette kurset var utvikling. Denne delen inneholdt informasjon om strukturering av filer, kode samt demoer hvor det ble utviklet websider med ulike formål Utarbeidelse av funksjonalitet Som i første fasen av UX-design kurset trengte vi å definere hvilken funksjonalitet som var prioritert og hvordan vi kan dele disse inn komponenter. Det var viktig å fastslå dette tidlig i prosessen slik at vi hadde et grunnlag og utgangspunkt når vi så skulle beveger oss over til fasen for å designe de første prototypene. Selv om vi på dette tidspunktet visste at det ville forekomme endringer med tanke på funksjonalitet, var det fortsatt nødvendig å komme i gang med dette så raskt som mulig. Vi kom frem til en metode vi hadde lyst til å prøve ut som kombinerer brukerkrav og wireframes (O'Sullivan, 2016). Metoden hjalp oss med å komme frem til den viktigste funksjonaliteten for chatassistent sin side av chatten. Frem til dette punktet hadde vi brukt tid på å gjøre undersøkelser av eksisterende chat-løsninger som tilbys. Vi testet også ut et par stykker for å danne oss en ide av hvordan en ideell chat-løsning skal fungere. Med denne informasjonen i bakhodet fulgte vi stegene som beskrevet i metoden og startet med å dele en whiteboard inn i tre deler. Den første delen bestod av funksjonalitet som vi ønsker skal bli inkludert på siden. Den andre delen bestod av beregninger som er hvilke data vi ser for oss som nødvendige å ha en oversikt over, og den siste delen bestod av navigasjon. Vi skrev individuelt ned alt vi kunne komme på å inkludere for hver av de tre delene på post-it lapper og plasserte de under tilhørende kategori på whiteboarden slik som vist i figur

46 Figur 2.8 Planlegging av funksjonalitet Deretter diskuterte vi behovet for alle de ulike punktene vi kom frem til og plukket ut de vi mente var mest relevante. Disse punktene brukte vi for å strukturere et oppsett for chatassistent siden av chatten, slik som vist i figur 2.9. Figur 2.9 Struktur for chatassistent chat 46

47 Strukturen ble til ettersom vi grupperte funksjonalitet etter bruksområde. Vi ønsket at funksjonaliteten og informasjonen som en bruker vil ha behov for skulle være tilgjengelig og presentert på en oversiktlig måte. Neste steg var dermed å navngi disse ulike gruppene av funksjonalitet, og vi ble sittende igjen med komponentene oppført i tabell Komponent Meny Brukere Åpne samtaler Chat kø Chat Kunde informasjon og historikk Funksjonalitet Inneholder navigasjonsmuligheter, notifikasjon fra teamleder, navigasjon til profil-side og logg-ut knapp. Inneholder en liste over chatassistenter samt informasjon om deres påloggingsinformasjon. Er en egen liste for hver chatassistent med en oversikt over en chatassistents pågående chat-samtaler. Er en kø-liste bestående av alle besøkende på en side som ønsker å starte en chat-samtale med kundeservice. Denne kolonnen inkluderer også en teller som oppdaterer seg basert på antallet som er i køen. Chat-vindu som tilhører den chat-samtalen som er valgt fra Åpne samtaler. Inneholder i tillegg en tidtaker som tar tiden på hvor lenge en chat-samtale har pågått. Vil inneholde informasjon om kunden som besøker siden. Slik informasjon kan være personalia, en logg over tidligere aktivitet på det relevante nettstedet eller kjøpshistorikk Tabell 2.10 Tabell med inndelingen av komponenter og deres funksjonalitet Vi var klar over at funksjonaliteten og komponentene som vi kom frem til mest sannsynlig ville endre seg etter videre arbeid med prosjektet. Dette arbeidet førte til at vi nå kunne starte en ny prosess som er utarbeiding av prototyper i form av wireframes. Resultatet av dette arbeidet brukte vi som utgangspunktet til å starte å utvikle wireframes som etterhvert kunne presenteres til oppdragsgiver. 47

48 2.3.5 Design av low-fidelity wireframes For å sikre oss at produktet vi utviklet kom til å være tilpasset brukernes behov utviklet vi prototyper i form av wireframes som vi kan få tilbakemeldinger på. Slik som beskrevet i seksjon om brukersentrert utviklingsprosess gjennomførte vi fem iterasjoner av Build-Measure-Learn metoden. De aller første wireframene utvikles med utgangspunkt i kravspesifikasjonen og undersøkelser som vi har utført. Videre førte møter og intervjuer til neste iterasjon som illustrert i figur Denne seksjonen tar for seg hvordan vi gikk fra versjon 1 av low-fidelity wireframe (LF.W 1) til versjon 2 (LF.W 2). Figur 2.11 Første iteasjon av wireframe design prosessen i form av Build-Measure-Learn modellen Med utgangspunkt i oppsettet vi kom frem til tidligere med bruk at post-it lapper startet vi arbeidet med å utvikle et førsteutkast av wireframes for siden. Wireframen avbildet i figur 2.11 inneholder alt av funksjonalitet som ble fastsatt og som var spesifisert i kravspesifikasjonen. Etter å ha presentert wireframen til Webnodes fikk de et positivt førsteinntrykk men kommenterte at noen av de ulike komponentene tar opp for mye plass. Etter å ha diskutert dette videre kom vi frem til et forslag om å gjøre komponentene justerbare ved at man skal kunne vise og skjule den informasjonen man ønsker. 48

49 Figur 2.11 Low-fidelity wireframe versjon 1 I løpet av denne tiden av utviklingsarbeidet hadde vi fått arrangert et par møter med noen selskaper som benytter seg av en chat-løsning. Vi fikk blant annet se brukergrensesnittet til de ulike selskapene og observerte meget stor variasjon med tanke på funksjonalitet, brukervennlighet og design. Et av selskapene hadde begrenset med funksjonalitet men det var viktig for dem at de kunne chatte med opptil tre kunder av gangen. Dette passet fint med hva vi har satt som «Åpne samtaler» hvor man kan veksle mellom de ulike kundene man har en pågående samtale med. Et av brukergrensesnittene vi så på var heller ikke veldig brukervennlig da det kun var et lite vindu plassert øverst i høyre hjørne som var tilgjengelig for å chatte med en kunde. Vi opplevde det veldig motiverende å kunne se på disse selskapenes chat-løsninger for så å kunne sammenlikne dette med vårt design og valg av funksjonalitet. Selv om dette er store og velkjente selskaper var det likevel mange likheter med vår løsning. Dermed kunne vi kunne føle oss tryggere på at vi har kommet frem til et relevant utvalg av funksjonalitet. Ut ifra denne informasjonen vi til nå hadde samlet og hva som videre ble diskutert på møter så ble det arbeidet videre med wireframene. I denne perioden ble det konstant utført oppdateringer og justeringer og valg ble tatt med hensyn til UI- og 49

50 UX-design prinsippene (Natoli, UX & Web Design Master Course: Strategy, Design, Development, 2016). Det ble til slutt laget en wireframe versjon som i figur 2.12 som ble presentert på de ulike intervjuene med selskaper som er kunder av Webnodes. Figur 2.12 Low-fidelity wireframe versjon 2 presentert til kunder av Webnodes Ved å vise frem wireframes på intervjuene fikk vi mye god tilbakemelding samt informasjon om hva som var viktig for dem å inkludere i en chat-løsning. På dette tidspunktet satt vi nå igjen med mye mer kunnskap enn tidligere om hva som er ønskelig og brukbart å inkludere i en chat-løsning. Vi ønsker å utvikle et produkt som vil være tilpasset brukerens behov og legger derfor stor vekt på tilbakemeldingene vi fikk på intervjuene. Med denne informasjonen kan vi nå gjøre tilpasninger i vår løsning for å skreddersy produktet til en potensiell sluttbruker. Selv om denne prosessen har vært tidkrevende har det vært et viktig steg for brukersentrert utvikling. Utviklingsmiljø Å investere tid i å bygge opp et ordentlig utviklingsmiljø er essensielt for å kunne samarbeide i et prosjekt. Ikke bare det, men det er også viktig for at det skal være mulig å videreutvikle applikasjonen videre. Et lite gjennomtenkt utviklingsmiljø vil 50

51 kun være forståelig for personen som utvikler det, og selv da så vil man sjeldent kunne komme tilbake til løsningen og fortsatt forstå hvordan alt er satt sammen. Første valget var svært enkelt å ta og det gjaldt hvilket verktøy vi skulle benytte oss av for å dele koden med hverandre. For dette benyttet vi oss av GitHub. GitHub er noe vi alle har erfaring med ettersom vi alle har brukt det for prosjektarbeid i løpet av studiet. GitHub er et flott hjelpemiddel ettersom den selv passer på at vi ikke endrer på hverandres kode samtidig og lar oss også hente tilbake eldre kode i tilfeller hvor noe går galt. Videre delte vi opp prosjektet i flere deler. Vi har to ulike deler som står for front-end delen av utviklingen. Disse er kunde delen og chatassistent delen, og disse kodes da i React i motsetning til resten av prosjektet. Resten av prosjektet består av DAL som er databaselaget, BLL som tar seg av prosjektets logikk, API som tar seg av kommunikasjonen mellom server og klient samt Model som vil inneholde modellene vi bruker i prosjektet. Når det kommer til front-end laget så ønsket vi å strukturere alt i moduler. Dette vil si komponenter som enkelt kan fjernes eller endres på separat uten at det påvirker hele applikasjonen. For å få til dette, samt å gjøre det lettere for oss å jobbe i prosjektet, har vi delt selve GUI delen inn i felles komponenter for applikasjonen og konteinere. Nedenfor i figur 2.13 vises strukturen vi har laget. Det minste nivået vi har er en individuell komponent. En slik komponent inneholder en JSX fil hvor React koden skrives, og en SCSS fil hvor utseendet justeres. Som vi ser i figur 2.14 så er komponenter deler av det som kalles konteinere. En slik konteiner inneholder underkomponenter, og den kan igjen holde flere underkomponenter og slik fortsetter det. KOMPONENTER Components Component JSX File SCSS File Figur 2.13 viser strukturen til en enkelt komponent i applikasjonen vår 51

52 KONTEINERE Containers Components SCSS File JSX File Component Components SCSS File JSX File Figur 2.14 viser strukturen til en konteiner i applikasjonen vår 3 Utviklingsprosess Utviklingen av denne applikasjonen har vært lang og det har gått mye arbeid inn i den. I dette kapittelet skal vi gå gjennom denne utviklingsprosessen og i 3.1 starter vi med å forklare hvilke former for dokumentasjon vi har ført underveis før vi går videre med å forklare selve arbeidet vi har gjort underveis i del 3.2. Dokumentasjon I løpet av vårt prosjekt som kombinerer både front-end design og back-end utvikling har det i løpet av prosessen blitt skrevet dokumentasjon. Å dokumentere informasjon vi samler inn er svært viktig, spesielt for å kunne skrive en rapport slik som under en bacheloroppgave. Dokumentasjon kan også være svært relevant for videreutvikling av løsningen, slik at det blir mulig å danne seg en forståelse av løsningen uten å måtte bruke timer på å studere koden. 52

53 I denne seksjonen skal vi gå gjennom de ulike formene for dokumentasjon vi har ført i løpet av prosjektet, og hva disse omfatter Prosjektdagbok Den første formen for dokumentasjon vi begynte å føre ned var prosjektdagboken. Helt i starten foregikk dette i Google Docs før vi senere fikk ferdigstilt prosjektsiden vår. Når denne var klar gikk vi over til å skrive prosjektdagboken her. Her skrev vi opp hva vi arbeidet med hver dag, både felles og hver for oss. Prosjektdagboken var viktig for å holde oversikt over hva vi hadde gjort til ulike tider, ettersom å huske dette når man begynner med rapportskrivingen er i realiteten umulig. Vi brukte også dagboken for å kunne holde oversikt over hva andre har gjort, selv om vi også gikk gjennom dette under våre daily meetups. Vi valgte også å legge til bilder for hver dag ettersom dette innimellom var en artig aktivitet samt at det vil være underholdende for oss å kunne se tilbake på disse bildene i framtiden Møtereferater En viktig form for dokumentasjon for prosjektarbeidet er møtereferatene. Vi hadde møter med Webnodes, HiOA sin veileder og ulike selskap i sammenheng med oppgaver, og når man sitter i et møte er det vanskelig å fokusere på det alle sier ettersom man ofte er opptatt med å forberede sine egne tanker og spørsmål samt å delta i samtalen. Derfor ble møtereferatene utrolig viktig for at vi skulle kunne ta informasjonen vi fikk under møtene og benytte disse for å gjøre prosjektet vårt enda bedre. Hvem som skrev referatene varierte, men vi nådde en enighet om at vi skrev ned ting som ble tatt opp under møtet som punkter, også etter møtet oppsummerte vi de viktigste elementene Wireframes & Prototyper Under utviklingen av prosjektet har vi brukt mye tid på å arbeide med designet til applikasjonen. I denne sammenhengen har vi utviklet mange wireframes og prototyper for å illustrere hvordan applikasjonen skal se ut. Dette har da blitt en viktig del av dokumentasjonen vår og illustrerer utviklingsprosessen vår når det gjelder både funksjonalitet og utseendet til applikasjonen. I første del av prosessen benyttet vi oss av wireframes for å lage en generell illustrasjon av hvordan siden kom til å være satt opp. Disse var da i svart hvitt og var veldig minimalistiske. Videre lagde vi noen litt mer high-fidelity wireframes som de kalles, som hadde farger og ikoner og viste et førsteutkast av hvordan siden ville se ut. Disse brakte vi med oss til ulike selskap samt Webnodes, og etter mye feedback begynte vi å utvikle prototyper. Her satte vi et mer endelig design hvor det kom frem hva som ville skje om man trykket på ulike knapper og hvordan de ulike sidene ville 53

54 se ut. Det ble gjort mange mindre endringer i løpet av prosessen, og etter hvert ble prototypen arbeidet med ved siden av utviklingen av prosjektet Risikoanalyse Under planlegging av prosjektet så lagde vi en risikoanalyse. En slik risikoanalyse går ut på å analysere sannsynligheten og alvorligheten av ulike risikoer, for så å planlegge hvordan man håndtere disse på best mulig måte. Å være forberedt på risikoene hjelper svært mye når og om de inntreffer. I løpet av vårt prosjekt så er det flere av tilfellene som er nevnt i vår risikoanalyse, slik som sykdom og tekniske problemer, som har inntruffet. I disse tilfellene har det forebyggende arbeidet vi har gjort grunnet risikoanalysen hjulpet mye. Risikoanalysen finnes som vedlegg Kravspesifikasjon Kravspesifikasjon er et dokument som er svært vanlig å ha med under systemutviklingsprosjekter. Denne beskriver bedriftens behov for løsningen som skal utvikles. Under utviklingen av løsningen så brukes dette dokumentet som en veiledning, slik at man alltid kan sjekke at man arbeider med oppgaver som er relevante for systemet. Kravspesifikasjonen har i vårt tilfelle endret seg litt underveis, og etter hvert som tiden har gått har den blitt mer konkret. Opprinnelig var kravspesifikasjonen mer en retningslinje for oppgaven vår, men etter hvert som vi har diskutert mer med Webnodes og de ulike selskapene vi har intervjuet har vi lagt til mer konkrete krav og mye annen informasjon. 54

55 3.1.6 Tidslinje Tidslinjen viser vår progresjon og arbeidsflyt gjennom hele prosjektperioden. I utgangspunktet var planen vår å bli ferdig med alt av utvikling i slutten av april. Da vi fikk en ny veileder fra Webnodes ble det gjort endringer i kravspesifikasjonen som førte til forsinkelser i utviklingsarbeidet Product Backlog Product backlog er en liste over krav som skal implementeres i løsningen som utvikles. Denne er sortert i en prioritert rekkefølge slik at det som er viktigst for produkteier å implementere står øverst. Vi laget en første versjon helt i starten av prosjektet, men den har gradvis blitt større etter hvert som vi har lært mer om ønskene for chatten og kommet på flere mulige funksjoner. Det har aldri vært tanken at vi skal fullføre product backlog, men komme så langt som mulig for så å gjøre resten til en del av videreutviklingen av applikasjonen. Arbeidsprosess I denne seksjonen skal vi gå gjennom hvordan vi har arbeidet med oppgaven, og om ulike deler av prosessen. Prosjektet vårt er som nevnt tidligere et hybrid prosjekt som kombinerer brukersentrert utvikling med systemutvikling. Denne kombinasjonen betyr at det har blitt lagt like stor vekt på utviklingen av et fungerende og brukervennlig design som utviklingen av løsningen selv. I denne seksjonen deler vi 55

56 prosessen inn i separate seksjoner, men i virkeligheten så har det vært mye fram og tilbake i arbeidet ettersom man ofte må tilbake å tilpasse noe man har laget tidligere, eller finner bugs i tidligere implementerte funksjoner Arbeidsfordeling Da vi skulle begynne å arbeide så var det viktig for oss å vite hvilke roller vi skulle inneha under prosjektarbeidet. Vi diskuterte oss imellom og med veileder, og kom fram til at det var viktig å bygge på våre styrker slik at alle fikk gjøre det de var best til. Samtidig så ønsket vi at alle tre skulle ha noe forståelse for alle deler av prosjektet, i tilfelle sykdom eller annen problematikk oppstod. Vi bestemte oss for å ha en hovedansvarlig for back-end, en for front-end og en for dokumentasjonen. Alle skulle da utvikle seg spesielt innenfor sin spesialitet, men med prinsippet til Crystal Clear, som vi har snakket om i seksjon 1.2.3, om fri flyt av informasjon ville alle holdes oppdatert på hverandres arbeid slik at man kunne ta over for hverandre hvis det ble nødvendig Læring om nye teknologier Da vi startet med prosjektet fikk vi tidlig en forbedret kravspesifikasjon av vår daværende veileder fra Webnodes. Vi begynte straks å lese oss opp på nye teknologier som var relevante for prosjektet. Det var veldig mye ny teknologi som skulle benyttes, og vi følte at det var viktig å ha en forståelse for denne før vi startet prosjektarbeidet, slik at vi ikke endte opp med mye arbeid som var for dårlig til å brukes. Vi lagde flere demoer for å få prøve ut teknologien uten å påvirke prosjektet vårt. Allerede i løpet av perioden før bachelorprosjektet startet så vi litt på teknologien SignalR. De første par dagene i prosjektperioden brukte vi på å dykke dypere i denne teknologien samt å få SignalR til å fungere med React i motsetning til vanlig JavaScript. Etter at vi fikk implementert dette gikk vi videre til å implementere flere funksjonaliteter ved bruk av SignalR, slik som for eksempel en kø for chatten. Vi lastet også ned demo programvaren til Webnodes og brukte denne til å lære hvordan Webnodes sin løsning er strukturert, slik at vi kunne legge opp vår løsning til denne så godt vi kunne. Et eksempel på tilpasninger vi gjorde basert på deres demo løsning er at vi laget samme cookie som de bruker for pålogging, slik at systemet vil kunne fungere med deres type pålogging. Når vi tok opp det med pålogging under et møte med Webnodes foreslo de at vi kunne benytte oss av Microsoft sin løsning kalt Identity ettersom dette er noe Webnodes har tenkt til å flytte seg mot etter hvert. Ettersom vi er svært opptatte av å tilrettelegge løsningen vår for Webnodes bestemte vi oss for å benytte oss av 56

57 denne teknologien. Vi brukte da tid på å lage et demoprosjekt som benytter seg av Identity. Den siste teknologien vi så på i første omgang var mobx som brukes i React. Mobx er en måte å håndtere data i React applikasjonen som sørger for å automatisk oppdatere siden når data i systemet endres. Dermed slipper man å ha metoder som konstant sjekker om noe har endret seg, og istedenfor vil endringen selv starte en metode som resulterer i at siden oppdaterer den spesifikke komponenten som har endret seg. Gruppen satte sammen opp et demoprosjekt og gikk gjennom hvordan dette fungerte for å forstå hvordan vi skal bruke dette i vårt eget prosjekt Beslutning om intervjuer Vi tok tidlig en viktig beslutning i sammenheng med vårt fokus på brukersentrert utvikling. Vi bestemte oss for å komme i kontakt med bedrifter som benytter seg av Webnodes og som er interessert i å implementere en chat-løsning. Grunnen til dette er at Webnodes er produkteiere, men ikke de som skal benytte seg av løsningen. Vi besluttet oss også for å intervjue selskap som allerede har en chat-løsning ettersom disse vil ha mye kunnskap om hva som er essensielt i en slik løsning. Erfaringene de har fra sine egne chat-løsninger er også uvurderlig ettersom de vil kunne kommentere på ting som ikke fungerer samt funksjoner de ikke klarer seg uten. Vi kom raskt i gang med å kontakte ulike bedrifter for å forsøke å arrangere et møte hvor vi kunne lære om ulemper og fordeler med deres chat-løsning. Eneste kravet vi satt for bedriftene vi valgte å kontakte var at bedriften tilbød kundeservice gjennom chat, og at denne chatten var av en viss kvalitet. Dette kravet ble som forventet oppfylt av svært mange bedrifter og vi startet å kontakte alle vi kom innom. Til slutt hadde vi kontaktet omtrent 20 bedrifter og spurt om det var mulig å arrangere et intervju. Typen bedrifter varierte og etter mange forsøk og et stort antall avvisninger eller rett og slett mangel på svar fikk vi arrangert to intervjuer. Disse intervjuene var da med et internasjonalt detaljhandelsselskap med over 200 butikker globalt, og et av Norges raskest voksende mobiloperatører. Størrelsene på disse selskapene betyr at chatløsningen deres må fungere godt for å kunne håndtere mengden kunder de har. Vi snakket også med Webnodes om å kontakte noen av deres bedrifter, men dette er noe de heller ønsket å gjøre for oss. Etter en kort periode hadde de arrangert møter med to av deres kunder som begge var større veldedighetsorganisasjoner Forberedelse av wireframes til intervjuene Før vi skulle i møte med selskapene som ønsket å ta i bruk Webnodes sin chatløsning var det viktig å ha noe konkret å vise dem slik at de kunne danne seg et 57

58 bilde av den faktiske chat-løsningen. Basert på dette behovet startet vi å designe wireframes for applikasjonen vår. En slik wireframe skulle da vise funksjonaliteten vi planla å implementere i løsningen samt gi et inntrykk av det generelle designet. I sammenheng med wireframe arbeidet begynte gruppens design ansvarlig å se et kurs om hvordan man kan skape gode brukeropplevelser gjennom design ved bruk av det som kalles UX-design. Kurset gikk gjennom fire faser om hvordan å skape gode brukeropplevelser. Disse fasene tok for seg definisjonen av hva UX-design er, arkitektur, UI-design prinsippene og utvikling. I løpet av denne perioden ble det utarbeidet en plan for brukertesting, en modell for informasjonsarkitektur og et førsteutkast av wireframes. Kurset er beskrevet i mer detalj i seksjon Med kunnskapen vi nå hadde om UX-design og hvordan man skal gå frem i prosessen med å skape et funksjonelt brukergrensesnitt startet utviklingen av de første wireframene. Denne prosessen, som også er beskrevet mer i detalj i seksjon 2.3.5, resulterte i de wireframene vi valgte å presentere på de ulike intervjuene med selskapene Parallelt arbeid med intervjuer Beslutningen om å kontakte bedrifter resulterte i en kraftig endring av tidsplanen vår. Vi ønsket at utviklingsprosessen skulle fortsette å gå fremover selv om vi var i en prosess med å intervjue ulike selskaper. Vi var nødt til å finne noe som ikke kom til å bli fullstendig endret etter tilbakemeldingene fra intervjuene. Vi ønsket ikke å starte med en prototype før vi hadde lært av andre bedrifters erfaring og ønsker. Hvis vi startet å programmere løsningen før disse intervjuene ville det vært en stor risiko for at mesteparten av koden ville måtte rekonstrueres, noe som igjen ville resultert i mye unødvendig tidsbruk. Vi kom frem til at å implementere noe av grunn funksjonaliteten og å designe databasen var noe vi kunne arbeide med parallelt med intervjuprosessen. Før vi kunne starte arbeidet med å designe databasen var det nødvendig å finne ut av hvilken metode vi ønsket å bruke for å lage databasen. Det er i hovedsak tre måter å lage databaser i.net; «Model First», «Database First» og «Code First». Det er fordeler og ulemper med hver av disse måtene, men vi valgte å gå for «Code First». Code first er tilrettelagt for programmerere, og baserer seg på klasser man koder for å bruke i løsningen. Databasen generes da automatisk utfra klassene man lager som gjør at databasen allerede er lagt opp for koden som brukes. Code First gir oss også mer kontroll over databasen ettersom det ikke auto genereres filer slik det gjøres i de andre løsningene. Disse auto genererte filene kan være vanskelige å forstå og det kan være lett å skape problemer i databasen når man forsøker å endre noe. 58

59 Med tanke på at vi allerede hadde brukerkrav som uansett skulle implementeres uavhengig av resultatene fra intervjuene var det ikke noe problem å starte med å implementere disse. Hovedsakelig så innebar dette å lage det som kalles hub innenfor SignalR. Det som ble kodet hadde hovedsakelig med kommunikasjon mellom kunden og chatassistenten. Vi begynte også å lage log-in funksjonene og koble disse opp mot rettighetene klienter og ansatte skal ha i SignalR huben. I tillegg til dette så er brukerhistoriene som ble arbeidet med som følger: Brukerhistorier #1 En bruker skal kunne sende melding til admin #2 En kunde skal kunne motta melding fra admin #3 En chatassistent skal kunne sende melding til kunder #4 En chatassistent skal kunne motta meldinger fra kunder #5 Som en chatassistent skal jeg kunne starte en samtale med neste kunde i køen #6 Som en chatassistent skal jeg kunne logge inn på applikasjonen #7 Som en chatassistent skal jeg kunne logge ut av applikasjonen #8 Som en chatassistent skal jeg kunne avslutte en samtale #10 Som en kunde ønsker jeg å kunne laste inn siden på nytt uten å miste chatten #11 Som en kunde ønsker jeg å kunne bytte side uten å miste chatten Tabell 3.1 Brukerhistorier Det meste av disse brukerhistoriene har allerede blitt gjort i ulike demoer, men det å sette det opp på best mulig måte som også var så effektiv som mulig var tidskrevende. Samtidig så kunne vi ikke starte å koble funksjonene opp mot en faktisk front-end enda ettersom vi fortsatt ventet på å fullføre intervjuene. På grunn av at vi ikke kunne gå fullt i gang med å kode så lenge vi ikke hadde fått utført alle intervjuene, brukte vi resten av denne tiden til å fortsette å lære om teknologier. Vi gjennomførte dette ved å lage ulike demoer slik at det ville være raskt å komme i gang med programmeringen etter at intervjuene var fullført. I slutten av denne perioden hadde vi vårt siste møte med selskapene. Møtene har lært oss mye både når det kommer til funksjonalitet og utseendet. Ting vi ikke har tenkt på som viste seg å være veldig viktige for løsningen har nå blitt satt høyere 59

60 opp på backloggen. Det beste eksemplet på dette er lagrede svar funksjonen. Lagrede svar er da en funksjon hvor du har ferdigskrevne meldinger som du enkelt kan velge blant. Vi hadde satt det opp på listen over funksjonaliteter vi ønsket å implementere, men relativt langt nede ettersom vi tenkte det ikke var det viktigste å implementere. Etter å ha snakket med bedriftene har vi innsett at dette er veldig mye mer brukt enn det vi først trodde. Avskrift av disse møtene er lagt til som vedlegg Tilpasninger av brukerønsker Etter å ha intervjuet de ulike selskapene fikk vi et tydeligere bilde av hva det er en potensiell bruker ønsker av funksjonalitet. Disse tilbakemeldingene førte til at vi ønsket å gjøre endringer i vårt design slik at vi kunne tilpasse designet til deres behov. Dette resulterte i andre iterasjon av prosessen beskrevet tidligere i seksjon om brukersentrert utviklingsprosess. Figur 3.2 gir en oversikt over hvordan vi beveget oss fra versjon 2 (LF.W 2) til versjon 3 (LF.W 3) av low-fidelity wireframes og i denne seksjonen vil vi ta for oss en mer detaljert beskrivelse av denne iterasjonen. Figur 3.2 Andre iterasjon av wireframe design prosessen i form av Build-Measure-Learn modellen Som første steg trengte vi å vurdere tilbakemeldingene vi fikk fra de ulike sluttbrukerne vi intervjuet. En fellesfaktor for disse selskapene var at de ikke kom til å ha ansatte som bemanner chatten til enhver tid. Dette er selskaper som ikke har så stor pågang at dette er nødvendig, og av den grunn vil de kunne dra på møter og gjøre andre arbeidsoppgaver under chattens åpningstider. Med dette fikk vi bekreftet 60

61 at det er viktig for kundeservice å enkelt kunne endre sin påloggingsstatus. Med hensyn til behovet valgte vi å inkludere funksjonalitet for påloggingsstatus på forsiden av chatassistent sin side av chatten. Denne funksjonaliteten skal være lett tilgjengelig og det skal gå relativt raskt å endre påloggingsstatus. Ettersom vi nå hadde flyttet endring av påloggingsstatus fra profil-siden til forsiden hadde vi ikke lengre behov for en egen profil-side. En chatassistent skal ha begrensede muligheter til å se og g g redigere informasjon og kommer ikke til å ha nytte av å se sin egen informasjon. Dette førte til at funksjonaliteten for å kunne logge seg ut også må være tilgjengelig fra forsiden, og resulterte i at vi la til en logg ut knapp. Figur 3.3 Påloggingsstatus og logg ut knapp på forsiden til chatassistent siden Noe som ble påpekt av kundene under intervjuene var seksjonen for «Brukere», da det var flere som var usikre på om dette var kunder som benyttet seg av chatten eller de som arbeidet med å bemanne chatten. Vi innså at det er viktig å bruke tid på navnevalg. Navnene må være forklarende, konsistente og lette å forbinde med tilhørende funksjonalitet eller informasjon. Etter å ha tatt en revurdering av hvilken funksjonalitet som er høyest prioritert så kom vi frem til at «Brukere», altså listen over andre påloggede chatassistenter, er noe vi ikke ønsker å prioritere i første omgang. Etter å ha sett på et stort antall chat-løsninger har vi observert at det er stor variasjon i om det brukes en knapp for å sende meldinger eller om det kun er lagt opp til bruk av enter-tasten. Med tanke på at vi ønsker at vår løsning skal være så brukervennlig som mulig gjorde vi flere undersøkelser i sammenheng med dette. Vi så på flere store chat-systemer som har et stort antall brukere og observerte hva som er vanlig. Vi kom frem til at de største løsningene tilbyr en mulighet for å skru av eller på om man ønsker å sende meldingen med enter-tasten eller ikke, og det var en slik løsning vi valgte å implementere. Figur 3.4 Alternativer for å sende meldinger fra forsiden til chatassistent chat Et annet tema som ble tatt opp var avslutt knappen i chat-vinduet. Denne knappen benytter chatassistentene seg av for å avslutte en pågående samtale. Fra tidligere design så denne slik ut: 61

62 Figur 3.5 Avslutt knapp, versjon 1 Vi ønsket å finne et bedre alternativ for denne funksjonaliteten slik at det ikke kan misforstås med å avslutte hele applikasjonen. Utfordringen var å gjøre det klart at det kun er samtalen som avsluttes og ikke hele chatten. Vi ønsket å benytte oss av noe som er universelt og som enkelt kan forstås av de fleste brukere. Vi kom frem til at vi kan benytte oss av en rød knapp med et kryss for å symbolisere at noe lukkes. Vi valgte å ha en rød bakgrunnsfarge på denne knappen slik at den lett kan kobles opp mot en lukke knapp for en nettleser. Denne knappen skal ha lik funksjonalitet som en lukke knapp for en nettleser ved at en chatassistent lukker den pågående samtalen. Figur 3.6 Lukk knapp, versjon 2 Etter at disse endringene har blitt utført sitter vi igjen med et brukergrensesnitt (se figur 3.7) som er mer funksjonelt, brukervennlig og bedre tilpasset sluttbrukerens behov. Figur 3.7 Low-fidelity wireframe versjon 3 etter tilbakemeldinger fra kunder 62

63 3.2.7 Førsteutkast av high-fidelity wireframe Når vi nå endelig hadde fått samlet all informasjonen vi trengte fra de ulike bedriftene kunne vi begynne å planlegge et endelig design for applikasjonen vår. Neste iterasjon av design av wireframes var da vi gikk fra å ha en low-fidelity wireframe til å ha et førsteutkast av en high-fidelity wireframe. Som illustrert i figur 3.8 er denne iterasjonen oppsummert i form av Build-Measure-Learn modellen som også er beskrevet i seksjon Figur 3.8 Tredje iterasjon av wireframe design prosessen i form av Build-Measure-Learn modellen Vi startet å lage wireframes basert observasjoner vi gjorde av to chat-løsninger som er i bruk. Vi begynte å arbeide med å utvikle en high-fidelity wireframe. En highfidelity wireframe er en videreutvikling av en low-fidelity wireframe som det er beskrevet mer om i seksjon For å tenke gjennom hvordan hver eneste komponent skal oppføre seg utviklet vi flere wireframes som gjenspeiler de ulike funksjonene på siden. Det ble utført flere iterasjoner for dette arbeidet ettersom vi brakte endringene vi gjorde videre til veileder hos Webnodes og HiOA for å forsikre oss om at disse var så gode som de kunne bli. Under første møte som ble avholdt med Webnodes etter at wireframe i figur 3.7 var ferdig utviklet ble det diskutert muligheten for å ha flere chat-vinduer åpne samtidig. Dette vil ikke bare si at man kan snakke med flere kunder parallelt, men at man også kan se alle meldingene samtidig. Ved å implementere denne muligheten kan det gå fortere å bytte mellom de ulike samtalene og man vil enkelt kunne ha et overblikk over alle de pågående samtalene. Vi endte opp med flere grunner for hvorfor dette ikke ville ha vært en ideell løsning. For det første ville det ha tatt opp mye mer plass og oppmerksomhet på skjermen og 63

64 eventuelt andre komponenter måtte ha blitt flyttet. Et annet problem vil være kunde informasjon og historikk som er noe som trenger å være koblet til hver enkelt chat. Det vil si at det kommer til å være mye informasjon som kontinuerlig vil endre seg på skjermen som kan føre til at man er mindre oppmerksom eller fokusert på hver enkelt chat-samtale. Det skal ikke være for mange elementer på en side som konkurrerer om oppmerksomheten til brukeren (Natoli, 2016). Brukeren skal kunne fokusere på det som er hoved funksjonaliteten på siden, uten å bli distrahert av for eksempel animasjoner eller modaler. For å få til dette er det viktig at brukeren ikke trenger å anstrenge seg for å finne ut av hva som er hoved funksjonaliteten på siden. Det skal være enkelt å se og skal gjerne være det første man legger merke til når man kommer seg inn på siden (ibid). Hoved funksjonaliteten til chat-applikasjonen er å kunne føre en samtale med en kunde. For å få dette til å være mer i fokus ville vi først og fremst gjøre chat-vinduet større og mer synlig. En annen teknikk man kan bruke for å få noe til å være et blikkfang er å bruke kontraster. Desto høyere kontrasten er mellom to komponenter desto lettere er det å se komponenten (Farley, 2009). Ved å ha høy kontrast mellom det som er rundt chat-vinduet og selve chat-vinduet vil det trekke mer oppmerksomhet. Vi bestemte oss for en relativt mørk blå farge som et utgangspunkt, og brukte denne fargen som base i menyen. Det finnes ulike typer kontraster og hvordan man oppfatter farger er definert av tre typer kontraster som forklart i figur 3.9 (Natoli, UX & Web Design Master Course: Strategy, Design, Development, 2016). Figur 3.9 Ulike typer fargekontraster 64

65 Vi ønsket å ha en applikasjon med et rent og enkelt design og bestemte oss for å bruke value contrast for applikasjonens hovedkomponenter med en mørk blå farge som base og som illustrert i figur 3.10 under gikk vi for ulike toner av denne fargen. Figur 3.10 Fargepalett med HEX verdier For komponenter som trenger å skille seg ut har vi benyttet oss av farger med hue contrast. Slik som diskutert i seksjon om UI- og UX-design prinsippene er det sentralt at det er tydelig at interaksjonsmuligheter er tilgjengelige. Dette kan fremheves ved bruk av blant annet farger som skiller seg ut. I versjonen av wireframen som er avbildet i figur 3.11 under så er chat-vinduet mer dominant og synlig. Det er en høy fargekontrast mellom chat-vinduet og elementene som finnes rundt som gjør det til et blikkfang. Likevel er ikke chat-vinduet for dominant og bryter ikke med resten av designet. Slik som diskutert i seksjon om UI- og UX-design prinsippene så er det viktig at designet er konsistent og at man helst velger å gjenbruke komponenter, farger og ikoner. Dette fører da til at systemet blir enklere å lære seg samtidig som det er forutsigbart. 65

66 Figur 3.11 High-fidelity wireframe versjon 1 For å teste om man har kommet frem til riktig valg av fargekontraster finnes det ulike verktøy og metoder man kan benytte seg av. En av disse metodene som ble nevnt i UX-design kurset er å legge en sort-hvit effekt over bildet og dersom man fortsatt kan skille alle komponentene og lese alt av tekst så er kontrasten bra nok (Natoli, UX & Web Design Master Course: Strategy, Design, Development, 2016). Av resultatet i figur 3.12 over så er de fleste komponentene og mye av teksten fortsatt synlig og leselig. Det kan fortsatt gjøres forbedringer for å gjøre kontrastene enda tydeligere, blant annet i chat-vinduet. I tillegg til dette så vil vi forholde oss til WCAG og alle farger er testet opp mot WebAIM sin kontrastsjekker. Her kan man sjekke om kontrasten til bakgrunn og tekst er godkjent i forhold til WCAG. Det vil kontinuerlig gjennom resten av denne prosessen bli testet opp mot WCAG. 66

67 3.2.8 React struktur Figur 3.12 High-fidelity wireframe versjon 1 i sort-hvitt Nå som utseendet på chatten begynte å ta form, var det på tide å sette opp utviklingsmiljøet for front-end delen av chatten. Mye av koden var allerede skrevet i tidligere arbeidsperioder, men vi følte at den manglet en klar struktur. Vi innså at vi måtte bli enige om en felles struktur på filene for å kunne kode sammen uten å skape problemer for hverandre. Detaljer om hvordan vi delte det opp står det mer om i seksjon 2.4, men kort oppsummert så deler vi applikasjonen i konteinere og felles komponenter. En React komponent er da en fil som representerer en del av applikasjonen. Hver konteiner har sine egne komponenter og logikk, og hver komponent har to filer, en fil som representerer selve komponenten og en fil til som tar seg av utseendet. Vi hadde også en egen mappe for felles komponenter, komponenter som brukes av flere konteinere, slik som input felt og knapper. Å implementere en slik struktur fører med seg en rekke fordeler. Først og fremst har tidligere prosjektoppgaver vist at det er langt lettere å arbeide sammen når man har en enighet om hvordan prosjektet skal struktureres. Videre så ønsket vi å strukturere prosjektet vårt på denne måten for å bedre tilrettelegge for endringer Webnodes kan ønske å gjøre i framtiden. Ved å strukturere prosjektet vårt i moduler vil det i framtiden være svært enkelt for Webnodes å bytte ut hele komponenter med sine egne, og for bedrifter å fjerne komponenter de ikke ønsker å ha på sin versjon av chatten. Slik løsningen er nå er det kun nødvendig å fjerne en linje med kode for å fjerne en hel komponent fra løsningen. 67

68 3.2.9 Første prototype Når strukturen var på plass var det mulig å starte på prototypen. Vi bestemte oss for å starte med statisk data, altså data vi selv skriver inn i løsningen istedenfor å koble løsningen opp mot databasen med det første. Denne måten å starte på blir anbefalt av Facebook selv (Facebook, 2013). Etter hvert så gjorde vi dette mer dynamisk hvor dataene var lagret i React sine egne datanivåer, nemlig det som kalles state. State kan holde på ulike variabler for et React komponent. Dette involverte også å koble dataen opp mot serveren gjennom både WebAPI og SignalR. Et WebAPI er da noe React kan kontakte for å hente ut data og SignalR sender data fram og tilbake med vår React løsning, et eksempel på dette er meldingene som sendes mellom kunder og ansatte. Ettersom vi nå skulle overføre all funksjonalitet over til denne nye strukturen bestemte vi oss samtidig for å gjøre en overhaling av koden som kjører i bakgrunnen. Dette valgte vi å gjøre for å optimalisere koden slik at den vil kjøre raskest mulig, og også for å få dette til å samsvare med den nye strukturen. Dette ble den siste overhalingen av allerede eksisterende kode, og etter dette bygget vi kun videre på det vi hadde. Når vi fikk satt sammen alt vi hadde utviklet tidligere var vi endelig på et punkt hvor vi kunne gå gjennom backloggen og fortsette å implementere nye funksjoner i rekkefølgen disse var satt opp. Vi delte oss slik at en av oss arbeidet med kunde siden av chatten, mens de to resterende arbeidet med chatassistent sin side. Inntil dette punktet hadde vi latt kunde siden av chatten stå som et inputfelt ettersom den mest kompliserte delen av løsningen var chatassistent siden, men for å skape en fullstendig prototype var det nødvendig å arbeide med denne siden av chatten også. I første omgang var det følgende nye brukerhistorier som ble arbeidet med. Brukerhistorier #9 Som en chatassistent ønsker jeg å kunne chatte med flere kunder på en gang #12 Som en chatassistent skal jeg kunne hente en chat #16 Som en chatassistent ønsker jeg å kunne velge et lagret svar og sende det til kunden. #20 Som en chatassistent ønsker jeg å kunne endre min påloggingsstatus #21 Som en chatassistent ønsker jeg å se hvor lenge en samtale har vart Tabell 3.13 Brukerhistorier arbeidet med i denne delen 68

69 Starten på klient siden av chatten Ettersom dette er første gang vi startet å fokusere på kundesiden i form av både wireframes og utvikling ble det mange tilbakemeldinger fra veileder hos Webnodes og Høgskolen. Resultatet av dette er mange revisjoner av utseendet på kundesiden. I tillegg til dette så er utseendet til kunde chatten den viktigste ettersom den er nødt til å virke appellerende for at kunder lettere vil velge å ta den i bruk. Før vi startet å designe wireframes for klient chatten laget vi derfor en oppsummering av krav og ønsker for klient chatten. Disse har vi samlet inn fra møter, intervjuer og undersøkelser som vi har gjort av eksisterende chat-løsninger. Etter å ha diskutert og tenkt igjennom hva vi kan få til å implementere i løpet av denne perioden kom vi frem til disse punktene i prioritert rekkefølge: Enkelt og brukervennlig design - Designet skal passe websidene til de fleste kundene uten at det må gjøres for mange endringer. Brukergrensesnittet skal også være brukervennlig og ikke kreve noen form for opplæring Mulighet for tilpasninger - Dersom det er ønskelig å legge til, endre eller fjerne elementer skal designet ta hensyn til dette. Det vil si at elementene enkelt kan byttes ut eller endres uten at det påvirker resten av designet. Kunne sende epost - Kunden skal ha muligheten til å sende en kopi av samtalen på epost til seg selv. Kunne gi tilbakemelding om samtalen - Kunden skal kunne gi en vurdering på hvor tilfedsstillte de er etter endt samtale Kunne sende vedlegg, emoji og eventuelt ha video samtale Når vi hadde fått satt opp et førsteutkast av wireframes for kunde siden av chatten startet vi å sette opp en struktur for klient siden av chatten. Startfasen for utviklingen av kunde chatten har vært smertefri, slik ting ofte er regel i starten. Vi fikk raskt opp noe som lignet på wireframen med en footer med send knapp, et 69

70 inputfelt for å skrive inn meldinger, et felt hvor meldinger vises og en header. Vi benyttet oss av det som kalles flexbox for å strukturere CSS utseendet til de ulike komponentene noe som fungerte svært bra i starten, men etter å ha arbeidet en stund med dette i Chrome så bestemte vi oss for å teste utseendet i FireFox og Edge. Der møtte vi på overraskelsen at flexbox tolkes ulikt av Chrome sammenlignet med andre nettlesere, men etter litt arbeid fikk vi tilpasset scss koden slik at den fungerte på tvers av nettlesere Ikoner, lagrede svar, profil-side Frem til nå har vi vært gjennom tre iterasjoner av design prosessen hvor vi har forbedret designen av brukergrensesnittet. Prosessen har hjulpet oss med å utvikle noe som er mer tilpasset sluttbrukers behov og ønsker. Under denne prosessen har vi kontinuerlig tilegnet oss mer kunnskap og vi har fått mer kjennskap til hvordan en chat-løsning bør fungere. Av den grunn vet vi at det på dette stadiet fortsatt er endringer og forbedringer som kan tilføyes designet for å øke brukeropplevelsen og gjøre applikasjonen mer brukervennlig. I løpet av neste og fjerde iterasjon har vi tilegnet oss mye kunnskap som resulterte i mye læring og mange forbedringer slik figur 3.14 oppsummerer. I denne seksjonen kommer vi nærmere inn på hva disse endringene er og hvorfor de er med på å øke brukeropplevelsen og brukervennligheten. Figur 3.13 Fjerde iterasjon av wireframe design prosessen i form av Build-Measure-Learn modellen 70

71 For å øke brukeropplevelsen er det ønskelig å unngå det som kalles visual noise. Dette vil si at man unngår bruk av komponenter som trekker for mye oppmerksomhet og kun skaper rot og forvirring for brukeren. En måte å unngå slik forvirring på er å kun inkludere innhold som er absolutt nødvendig for at programmet skal kunne brukes (Natoli, UX & Web Design Master Course: Strategy, Design, Development, 2016). Når det kommer til ikoner legger man først og fremst vekt på at de øyeblikkelig skal gi mening til brukeren. Hvordan en bruker oppfatter ikoner baserer seg på hva de er vant med fra andre applikasjoner og programmer som de har benyttet seg av. Når man skal velge ikoner er det sentralt å tenke over at ikonet skal være en representasjon av en funksjon som brukeren kan utføre. Ikonet må gi en klar indikasjon på hva som vil skje når man trykker på det eller tilhørende knapp (Harley, 2014). Dette er noe vi tok i betraktning når vi skulle velge ut ikoner til applikasjonen. For at ikonene som brukes skal være til nytte er det nødvendig at de har en tilhørende tekst etikett (ibid). De fleste ikonene vi har brukt i applikasjonen har en tilhørende tekst etikett som er forklarende slik som illustrert på bildene i figur 3.14 under. Figur 3.14 a) Ikoner fra chat-vindu, b) ikoner fra meny Når vi skulle velge ikonene tok vi i betraktning at de skal øke brukervennligheten. Ikonene skal som nevnt tidligere være gjenkjennelige og vi valgte derfor ikoner som er så forklarende som mulig for det de representerer. Det er få ikoner som er globalt kjent blant brukere. Grunnen for at det kun er noen få er at ikoner som for eksempel hamburger meny ikonet blir brukt for blant annet menyer og lister. Det vil si at man ikke alltid kan være sikker på om et ikon kun har en betydning (ibid), men ikonet av et forstørrelsesglass, som avbildet i figur 3.15, blir derimot gjenkjent av de fleste 71

72 brukere som søk. Dette er et ikon som ikke trenger en forklarende etikett(natoli, 2016). Vi benyttet oss av dette ikonet for søkefeltet for lagrede svar. Figur 3.15 Forstørrelsesglass ikonet for «søk» Tidligere nevnte vi at gjennom intervjuene lærte vi at lagrede svar var et større behov enn vi hadde tenkt. Vi valgte da å inkludere denne funksjonaliteten. Vi gjorde en knapp tilgjengelig fra chat-vinduet som åpner et vindu som vist i figur Figur 3.16 Vindu for lagrede svar, versjon 1 Vinduet har en forklaring av navigasjonsmuligheter øverst til høyre. Hensikten med å inkludere dette er at det skal være enkelt for brukeren og forså hvordan man kan navigere seg rundt i dette vinduet. Ved å inkludere instruksjoner øker vi brukervennligheten og en bruker vil bruke mindre tid på å lære seg de ulike funksjonalitetene. 72

73 Noe annet som øker brukervennligheten er søkefeltet. Ved å inkludere et søkefelt kan man raskt søke etter det man ønsker å finne uten å måtte bla igjennom alle spørsmål og svar. Søkefeltet har også en knapp med et kryss som blanker ut det man allerede har skrevet inn. Dette effektiviserer arbeidet og gjør funksjonen enda mer brukervennlig. Under denne prosessen ønsket vi kontinuerlig å tenke over hvordan vi kunne forbedre applikasjonen og gjøre den mer brukervennlig. I løpet av en ny iterasjon med møter utviklet vi versjon 2 av vinduet for lagrede svar som vist i figur 3.17 under. Figur 3.17 Vindu for lagrede svar, versjon 2 En stor del av endringene som har blitt gjort siden versjon 1 av lagrede svar vinduet er at navigasjonen har blitt fjernet. Dette var et ønske fra oppdragsgiver da han påsto at å inkludere instruksjoner for navigasjon ikke er vanlig i de fleste applikasjoner. Som et kompromiss valgte vi å fjerne instruksjonene, men heller legge til en velg knapp for hvert svar man kan velge fra vinduet. Ved å gjøre det slik vil det fortsatt være brukervennlig og brukeren kan enkelt finne frem til hvordan man kan hente et lagret svar. I dette tilfellet er det å velge et svar den primære handlingen. Det vil si at det er dette som er hovedoppgaven til brukeren når de har trykket på lagrede svar 73

74 knappen. Det er ønskelig å fremheve det som er den primære handlingen på siden og brukeren skal ikke være i tvil om hva de skal gjøre (Natoli, 2016). Som tidligere nevnt er det å skape kontraster en måte å fremheve noe på. Ved å ha en farge med mye kontrast på velg knappen fremstår denne som den primære handlingen for lagrede svar funksjonaliteten. Dette er noe vi også har brukt for andre knapper i grensesnittet for å tydeliggjøre at det er primære handlinger som for eksempel den røde lukk knappen i figur Figur 3.18 Lukk knapp for å avslutte en samtale med klient For at brukeren skal bruke minst mulig tid på å finne ut av hva de ulike knappene kan føre til er det en fordel om man også navngir knappene (Hausler, 2015). Selv om en knapp med et rødt kryss i de fleste tilfeller symboliserer at man kommer til å avslutte eller lukke noe så kom vi frem til at dette ikke var forklarende nok i dette tilfellet. Siden knappen sin funksjon er å avslutte en samtale med en kunde synes vi dette ville være mer forklarende for en ny bruker av applikasjonen. Vi valgte også å endre plasseringen fra toppen av chat-vinduet til bunnen slik som i figur 3.19 under, for at det skal gå raskere å avslutte en samtale etter at man har skrevet ferdig meldingene. Figur 3.19 Plassering av avslutt samtale knapp i chat-vindu Når det kommer til hvor raskt man kan bevege seg i et brukergrensesnitt for å utføre en oppgave, er det slik at desto raskere man får utført noe desto bedre blir brukeropplevelsen (Natoli, UX & Web Design Master Course: Strategy, Design, Development, 2016). Det finnes en lov for dette kalt Fitt s law som sier at tiden det tar å bevege seg til en bestemt komponent er en funksjon av avstand og størrelsen til komponenten (IDF Instructor in The Interaction Design Foundation, 2016). For å ta hensyn til Fitt s law tok vi en revurdering av hvordan de ulike komponentene er plassert i forhold til hverandre i brukergrensesnittet. 74

75 I forrige versjon av chat-vinduet hadde vi en kolonne til høyre med åpne samtaler og chat kø. Dette var ikke en ideell plassering da dette trengs å aksesseres hyppigere og trengs derfor å være lettere tilgjengelig. Vi ønsket også å endre på hvordan åpne samtaler fremstilles da det ikke er tydelig nok hvilken klient man snakker med. Etter å ha tilføyet disse endringene ser kolonnen nå ut som i figur 3.20 under. Figur 3.20 Kolonnen for mine samtaler og chat kø Når vi så på andre chat-løsninger observerte vi at det er vanlig å skille mellom mottaker og sender i et chat-vindu med farger. Mottaker og sender har gjerne ulike farger på chat-boblene. Med inspirasjon fra hvordan Apple har gjort det for meldinger på iphone så valgte vi å skille dette ved å la sender ha en grønn farge og mottaker ha en grå-hvit farge som på figur Ved å la det være høy kontrast mellom de to fargene er det enklere for en bruker å skille disse og også for de som er fargeblinde (WebAIM, 2013). 75

76 Figur 3.21 High-fidelity wireframe versjon 2 Slik som man kan se i figur 3.21 over så har vi valgt å flytte påloggingsstatus til sin egen side i menyen. Vi har brukt mye tid på å observere andre chat-løsninger som blant annet Skype. Vi observerte at det ofte er egne sider for å endre påloggingsstatus og for å logge ut. For å forholde oss til prinsippet om at det kun er det som er absolutt nødvendig som trenger å være synlig på en side så kom vi frem til at vi flytter dette til en egen side. Vi antok at en chatassistent kun vil behøve å aksessere denne siden 2-3 ganger om dagen for å logge ut og for å endre sin status hvis de skal ha lunsjpause. Vi ønsket fortsatt at det skal være enkelt og raskt å endre statusen sin så vi valgte å ikke ha det i en nedtrekksliste, men synlig (Holst, 2010). Som figur 3.22 viser så har siden et veldig enkelt design og få komponenter. Med tanke på eventuelle skaleringer på et senere tidspunkt så er det en fordel å ha en profil-side hvor ekstra informasjon kan legges til. 76

77 Figur 3.22 Profil-side Tilpasninger av kravspesifikasjon Under et av møtene med kontaktpersonen vår i Webnodes oppstod det et par endringer i kravspesifikasjonen. Opprinnelig var det ikke nødvendig for oss å få applikasjonen for chatassistenter til å fungere på mobil ettersom det var trygt å anta at de ville jobbe på en datamaskin til alle tider, men dette ble nå endret. Samtidig så hadde vi opprinnelig planlagt å gi den ansvarlige for applikasjonen mulighet til å endre utseendet på chatten, men veileder fra Webnodes var bestemt på at dette skulle gjøres gjennom CSS og ikke noe annet. Disse endringene førte til at vi måtte gå gjennom kravspesifikasjonen på nytt og tilpasse denne etter vår nye veileders ønsker. De fleste punktene ble stående slik de allerede var, men spesielt behovet for en mobilløsning for chatassistent krevde mer arbeid som vi ikke var forberedt på Mobil versjon Ettersom vi nå hadde fått informasjon om at det var ønskelig at siden for chatassistenter også skulle fungere på mobil startet vi å planlegge hvordan vi kunne få dette til å skalere til mobil versjon. Vi tok utgangspunkt i prinsippene for material design fra Google når vi skulle tenke over plassering av de ulike elementene og hvordan de skal passe sammen. Et av disse prinsippene handler om at applikasjonen skal være enkel som vil si at hver side ikke skal inneholde for mye tekst, mange knapper eller bilder. Vi har derfor passet på at det kun er den informasjonen som er 77

78 absolutt nødvendig som vises på skjermen. Navigasjon skal også være tydelig og brukerne skal alltid vite hvor de er i applikasjonen og hva som er hoved funksjonaliteten på den siden de befinner seg på (ibid). Vi delte opp sidene etter hvordan vi hadde delt inn applikasjonen i ulike kolonner. Den første siden, som avbildet i figur 3.23 a), består av «mine samtaler» og «samtale kø». Det vil si at fokuset for denne siden er å håndtere og navigere mellom de ulike samtalene. Når man har valgt en samtale kommer man inn i chat-vinduet avbildet i figur 3.23 b). a) b) Figur 3.23 Wireframe for mobil. a) navigasjon b) chat-vindu Chat-viduet er også tilpasset mobil ved at for eksempel knappene er større som gjør det enklere å trykke på dem. Ikonene har heller ikke lengre en tekst etikett som er med på å gjøre brukergrensesnittet renere. Dette vil si at de ikke inneholder for mye tekst som kan være distraherende og gjøre det vanskeligere for brukeren å vite hva man skal fokusere på (Natoli, 2016). I følge en test utført av «UserTest», som er et selskap som arbeider med å hjelpe andre selskaper med å eliminere dårlige brukeropplevelser, så var det kun 60% av brukerne som klarte å forutse hva ikonene bruktes til uten at de hadde noe forklarende tekst. Når ikonene hadde forklarende tekst økte dette tallet til 88% av tilfellene, men de kom også frem til at dersom man har en form for opplæring så kan man holde dette tallet stabilt uavhengig av om 78

79 man har ikoner med eller uten en tekstbeskrivelse (Alvarez, 2014). Vi tar utgangspunkt i at en chatassistent som vil benytte seg av chat-løsningen først og fremst vil benytte seg av løsningen for desktop, og mobil løsningen som et alternativ for når de er i møter eller ikke tilgjengelig på desktop. En chatassistent vil da lære seg hvordan chat-løsningen tas i bruk på desktop og så vil de kjenne igjen de ulike ikonene og funksjonaliteten på mobil når de begynner å bruke det Klient siden av chatten Frem til nå hadde vi et førsteutkast av en prototype av klient siden av chatten. I og med at designet for klient chatten har vært sentral har vi frem til nå testet ut ulike muligheter. Det har blitt gjennomgått flere iterasjoner av denne prosessen hvor det via møter har blitt foreslått endringer. Vi hadde på dette tidspunktet all den informasjonen vi behøvet om funksjonalitet og brukerønsker for å kunne komme frem til et endelig design. Den første utfordringen vi møtte på var hvordan vi ønsket å fremstille de ulike funksjonalitetene. Ettersom det var ønskelig med et enkelt og rent design valgte vi å legge til en meny med flere valgmuligheter for å unngå visual noise. Som beskrevet i seksjon økes brukeropplevelsen dersom man unngår visual noise (Natoli, 2016). På wireframene i figur 3.24 er det illustrert hvordan klient chatten ser ut når menyen er lukket og åpen. Figur 3.24 Wireframe for klient chat versjon 1 79

80 Kontaktpersonen i Webnodes hadde tidligere vist iver når det gjelder muligheten til å gi tilbakemelding fra chatten, og dette var også noe selskapene vi intervjuet ønsket å implementere, så dette ble vårt neste punkt. Å få tilbakemeldinger av kunden er et viktig punkt for enhver bedrift for å se om forbedringer er nødvendige, hvilke situasjoner det er som skaper misnøye blant kundene og for å se effekten av ulike endringer som blir implementert. En negativ tilbakemelding er den eneste måten å vite at en endring er nødvendig, noe Janelle Barlow & Claus Moller uttrykker ved å si at A complaint is a gift (Barlow & Moller, 1996). De konkluderer med at businesses that don t value their customers suffer from costly, negative word-ofof-mouth advertising noe som igjen vil føre til negative assosiasjoner med hele selskapet, og ikke bare chatassistent delen. Det er ingen fastsatt løsning for å gi tilbakemelding, og det er i all hovedsak tre populære metoder. Den ene benytter seg av stjerner, ofte fem eller ti hvor et høyere antall stjerner betyr en høyere grad av tilfredshet. Løsning nummer to er smilier, hvor man har mellom to og fem ulike. Ansiktsuttrykket representerer da hvor fornøyd du er. Den siste typen som er brukt er tommel opp og tommel ned. Alternativer slik som ti stjerner vil gi deg et mer detaljert innblikk i kundenes mening om det de gir tilbakemelding på, men på bekostning av antall tilbakemeldinger. Netflix har nylig valgt å benytte seg av tommel opp og tommel ned istedenfor den tidligere brukte fem stjerner tilbakemeldingen. Under en testperiode fant de ut at antall tilbakemeldinger økte med 200 prosent når de gikk over til tomlene (Roettgers, 2017). Resultatet indikerer at færre og enklere valg, resulterer i høyere antall deltakere. Vi valgte å velge et kompromiss hvor vi gir brukeren tre valg i form av smilier som i figur Dette gir litt mer detaljert informasjon enn en enkel tommel opp eller ned, men holder det fortsatt enkelt nok til at flere vil gi tilbakemelding. Figur 3.25 Wireframe for tilbakemeldinger på klien chat Vi valgte å benytte oss av smilier basert delvis på en studie som viser at mennesker tolker smilier som ansiktsuttrykk (Churches, Nicholls, Thiessen, Kohler, & Kaege, 2014) og dermed gjør det lettere å identifisere hva den spesifikke tilbakemeldingen 80

81 representerer. I tillegg til dette var smilier også et ønske fra Webnodes, men de ønsket at vi skulle ta et informert valg istedenfor å bare lytte til dem. En annen innvending veileder fra Webnodes hadde var angående menyen. Han ønsket heller at valgene i menyen skulle være mer tilgjengelige og gjerne synlige fra selve chat-vinduet. Vi kom frem til en løsning hvor vi plasserer send epost og avslutt samtale knappen i headeren som i figur Avslutt samtale knappen ble gjort om til et x-ikon. Figur 3.26 Wireframe for header på kilent chat For å forsikre oss om at applikasjonen er brukervennlig for flere typer brukere er det anbefalt at ikoner har en tilhørende tekst etikett (Alvarez, 2014). Derfor la vi til en bekreftelsesside for om brukeren virkelig ønsker å avslutte samtalen. Som diskutert i seksjon var et av prinsippene for interaksjonsdesign å gjøre interaksjonsmuligheter synlige. For å ta hensyn til dette valgte vi en rød farge på avslutt samtale knappen som er et symbol for fare siden samtalen ikke kan gjenopptas etter dette valget er gjort som i figur 3.27 (Harley, 2014) Tilkobling av database 3.27 Wireframe for avslutt samtale på klient chat Neste steg for oss var å koble løsningen opp mot databasen vår. Hittil hadde all data kun eksistert midlertidig eller vært skrevet inn direkte, noe vi som nevnt tidligere hadde valgt å gjøre grunnet Facebook sine egne anbefalinger for å ta i bruk React (Facebook, 2013). Databasen hadde vi konstruert i sitt eget lag kalt DAL, men dette hadde ikke vært koblet opp mot noe. For å få koblet databasen opp mot 81

82 applikasjonen var det nødvendig å lage funksjoner som kunne hente og sette inn data i databasen. I motsetning til det meste annet vi har møtt på i dette prosjektet så er dette noe vi hadde erfaring med tidligere og dermed enkelt å løse. For at dataen skulle være mulige å bruke i resten av applikasjonen var det også nødvendig å lage modeller av dataen som ligger i databasen. En model er rett og slett en klasse som dataen kan konverteres til, og disse modellene ligger i sitt eget model lag. Når disse modellene var ferdig laget så var det en smal sak å bruke de samme objektene over hele løsningen vår uten å måtte konvertere disse eller møte på andre problemer. Til slutt var det et lag til som gjenstod som var nødvendig for databasen. Dette laget kalles BLL (Business Logic Layer) og er et mellomlag mellom alt applikasjonen og databasen. Alle forespørsler mot databasen skal gå gjennom BLL først, slik at BLL kan påføre det som kalles business rules på disse forespørslene. En business rule er som navnet antyder regler satt av bedriften som benytter seg av applikasjonen. Et eksempel kan være hvordan en ansatt med en lavere stilling ikke skal kunne endre på data hos en ansatt i en høyere stilling Siste wireframe iterasjon, sanntids-side Etter å ha vært gjennom fire iterasjoner for å forbedre brukergrensesnittet og gjort det mer brukervennlig har vi kommet frem til et design som nærmer seg å være komplett. I denne femte og siste iterasjonen har vi hatt møter med veileder og oppdragsgiver og kommet frem til et design vi er komfortable med å presentere som fullstendig. Slik som figur 3.28 viser har vi i løpet av denne iterasjonen også tilegnet oss mer kunnskap som har vært med på å gjøre løsningen komplett. Figur 3.28 Femte iterasjon av wireframe design prosessen i form av Build-Measure-Learn modellen 82

83 Tilbakemeldingene vi fikk på forrige versjon av high-fidelity wireframe var positive og både oppdragsgiver og veileder var fornøyde med hvordan designet så ut. På møtet med Webnodes fikk vi høre at deres kunder ikke vil sitte kontinuerlig å administrere chatten. Dette vil si at en chatassistent vil måtte endre sin påloggingsstatus og logge seg ut opptil 20 ganger daglig. Dette resulterte i at vi valgte å fjerne profil-siden og legge dette tilbake igjen på chat-siden slik som vi hadde det på et tidligere punkt i prosessen. Vi valgte å plassere denne i kolonnen ved siden av menyen slik som i figur 3.29 under. Figur 3.29 Nedtrekksliste for endring av påloggingsstatus og logg ut knapp Et av ønskene til arbeidsgiver var muligheten til å kunne lese ulike typer data fra systemet. Hvilken data vi ønsket å inkludere kom vi frem til under planleggingsprosessen som beskrevet i seksjon om utarbeidelse av funksjonalitet. Beregningene som vi da kom frem til har allerede blitt implementert på chat-siden, bortsett fra siste punkt som er antall klienter per chatassistent. Vi møtte utfordringen om hvordan vi skulle fremstille denne informasjonen på en måte som både er effektiv og informativ for chatassistentene. En chatassistent må kunne komme inn på siden og umiddelbart kunne lese den informasjonen de er ute etter. Vi utviklet et par forslag i form av wireframes som ble diskutert og vurdert under møter med oppdragsgiver og veileder. Det dukket opp forslag om å utvikle en side med grafer og diagrammer som presenterte data i sanntid. En slik side trenger mye data som kan produsere daglige, månedlige og årlige rapporter. Blant de som skal benytte seg av løsningen så var hovedfokuset vårt kunde, chatassistent og IT-ansvarlig. Slike rapporter vil ikke være til interesse for noen av disse rollene og av den grunn er dette heller noe vi kan vurdere senere som neste steg av utviklingen. Etter å ha undersøkt hvilken informasjon som vil være til nytte for en chatassistent kom vi frem til en side som skal inneholde en oversikt over de ulike ansatte, deres 83

84 påloggingsinformasjon, informasjon om hvor mange klienter de administrerer og har administrert totalt i dag. Dette er en side som inneholder sanntidsinformasjon og ble derfor kalt for sanntid i navigasjonsmenyen. Fra denne siden kan en chatassistent fortsatt endre sin påloggingsstatus slik at det ikke er nødvendig å måtte navigere mellom de ulike sidene for å gjøre dette. Wireframen som ble utviklet er designet med samme utgangspunkt som chat-siden slik at det er et konsistent design og derfor lett gjenkjennelig for brukerne. Som vist i figur 3.30 finnes det en kolonne som inneholder en oppsummert beskrivelse av statusene til de ulike ansatte samt informasjon om samtale køen. Figur 3.30 informasjon om status og samtale kø på sanntidssiden Med betraktning om at løsningen kan benyttes av større bedrifter som har mange flere ansatte enn hva de nåværende kundene til Webnodes har så la vi til en filtreringsfunksjon. Som vist i figur 3.31 vil filtreringen være til nytte dersom det er mange ansatte i bedriften og man er ute etter å se de som for eksempel er pålogget. Dersom man er usikker på om man kan ta en pause eller ikke kan man sjekke pågangen i samtale køen som vist i figur 3.30 og sjekke dette opp mot hvor mange som er i pågående samtaler i figur

85 Figur 3.31 oversikt over chatassistenter, deres påloggingsinformasjon og samtale status på sanntidssiden Nederst i figur 3.31 er det også en rad som inneholder den totale summen av antall pågående samtaler og totale samtaler for gjeldende dag. Dette gjør det enklere for en chatassistent å følge med på pågangen for den gjeldende dagen. For mobil er sanntidssiden delt inn i to ulike sider. Figur 3.32 a) fungerer som en meny for å kunne navigere til en mer detaljert oversikt i figur 3.32 b). På figur 3.32 a) er det inkludert en se mer lenke på status og samtale kø som fører deg videre til disse sidene. Siden det er ulikt for mobil versjonen at man kan trykke på lenkene for status og ssamtale kø og bli videreført til en ny side måtte vi gjøre denne muligheten tydelig. I følge prinsippene om interaksjonsdesign i seksjon skal interaksjonsmuligheter være synlige. Det er ønskelig at brukeren ikke skal være i tvil om at dette er en lenke som fører deg videre til neste side. Derfor la vi til beskrivelsen se mer i tillegg til et ikon av en pil. 85

86 a) b) Figur 3.32 oversikt siden for mobil Frem til hvor vi var nå i prosjektet hadde vi ikke brukt mye tid på å tenke over navnevalg. Vi valgte navn ut i fra hva som kom til å være mest mulig selvforklarende for brukeren. Noe vi måtte ta hensyn til var hvordan de ulike navnene passet med hverandre. Vi har både benyttet oss av benevningen chat og samtale, men ønsker at dette skal være konsistent. I seksjon om UI- og UX-design prinsippene kom vi også innom interaksjonsdesign. Interaksjonsdesign er noe som bidrar til å skape bedre brukergrensesnitt og bedre brukeropplevelser. Ett av disse prinsippene går ut på at innholdet bør være konsistent (Natoli, UX & Web Design Master Course: Strategy, Design, Development, 2016). Vi tok derfor en revurdering av navngivning for de ulike komponentene og kom frem til at vi ønsker å bruke benevningen samtale. Et annet av prinsippene om interaksjonsdesign, som er diskutert i seksjon om hva UI- og UX-design er og hvorfor trenger vi det, er tilbakemeldinger. Det skal gis tilbakemeldinger til brukeren og de skal kunne vite hva som skjer, hva som har skjedd eller kommer til å skje (ibid). Når brukeren velger logg ut kommer det opp en dialogboks som i figur

87 Figur 3.33 Dialogboks for logg ut Det mest sannsynlige valget brukeren vil velge skal være fremhevet. Dette valget vil være primær handlingen for de fleste brukerne og skal plasseres til venstre, slik som «Ja» er gjort i dette tilfellet. Den sekundære handlingen plasseres da til høyre uten å være visuelt dominerende. Brukeren vil da fiksere på det området med høyest kontrast og det som trekker mest oppmerksomhet som da vil fremstå som det naturlige valget (Natoli, UX & Web Design Master Course: Strategy, Design, Development, 2016). På dette tidspunktet var vi fornøyde med wireframene våre. Gjennom denne prosessen har vi designet et brukervennlig brukergrensesnitt og vi har tatt hensyn til at løsningen skal gi en god brukeropplevelse. Dette har vi fått til ved å gjennomføre intervjuer med kunder og hatt jevnlige møter med oppdragsgiver og veileder hvor vi har presentert ideer og løsninger. Med disse tilbakemeldingene har vi kommet frem til et design vi er fornøyde med og som vi mener er tilrettelagt UX- og UI-design prinsippene som diskutert i seksjon Webpack migrasjon fra versjon 1 til 2 Versjon 2 av Webpack ble nylig lansert, og vi ønsket å benytte oss av denne utgaven for fordelene webpack 2 kommer med, samt framtidssikring av løsningen vår. Webpack 2 er mer effektiv enn tidligere versjoner, forbedrer måten den setter all koden vår sammen til et dokument samtidig som konfigurasjonen er forbedret. Ettersom webpack skaper utviklingsmiljøet vårt var det ikke nødvendig å endre noe av koden i løsningen ettersom dette vil fungere fint i den oppgraderte versjonen. Det som måtte gjøres var kun å installere webpack 2 og bytte ut den originale konfigurasjonsfilen med en som benyttet seg av den oppdaterte versjonen Forsinkelse, bug fiksing, siste funksjonalitet Vi hadde opprinnelig satt oss en dato for når vi skulle være ferdig med utvikling, men som i mange systemutviklings prosjekter fikk vi ikke fullført alt vi ønsket å gjøre 87

88 innen denne tiden. Vi ble enige om å fortsette utviklingen i to uker til for å ferdigstille det vi kunne ferdigstille, samt implementere mindre funksjonaliteter som var ønsket av Webnodes. Mesteparten av det som ble implementert i denne perioden var rettelser av ulike feil i løsningen, men det var også en del resterende funksjonaliteter. Under følger en tabell med hvilke nye brukerkrav vi arbeidet med å implementere i disse to ukene. Brukerhistorier #24 Som en chatassistent ønsker jeg å motta en notifikasjon ved en ny melding #25 Som en chatassistent ønsker jeg å kunne se at kunden skriver en melding #26 Som en kunde ønsker jeg å kunne se at kundeservice skriver en melding #27 Som en kunde ønsker jeg å få en notifikasjon ved ny melding #36 Som en chatassistent ønsker jeg å kunne ha en videosamtale med kunde #37 Som en kunde ønsker jeg å kunne ha en videosamtale med kundeservice #38 Som en chatassistent ønsker jeg å kunne se hvilke land kundene skriver fra #39 Som en admin ønsker jeg å kunne se ulik statistikk Tabell 3.34 Brukerhistorier arbeidet med i denne delen Alt utenom videosamtale var svært enkelt å implementere ettersom dette var mindre funksjonaliteter. I tillegg til dette så har vi blitt langt mer effektive med tanke på å utvikle i prosjektet gjennom prosjektperioden, og tiden det tar å utvikle nye funksjoner har blitt redusert betraktelig. Videosamtale på sin side krevde bruken av en helt ny teknologi kalt WebRTC. Dette er en teknologi som åpner for muligheten til å la to datamaskiner kommunisere direkte med hverandre og sende medier som video og lyd. Vi bestemte oss for å bruke JavaScript rammeverket Peer.js som gjør det langt enklere å implementere WebRTC, og ved bruk av denne teknologien fikk vi gjennomført til og med dette i løpet av et par intensive arbeidsdager. Når det kom til siden for statistikk fikk vi fra oppdragsgiver vite at dette var svært ønskelig fra hans side. Vi hadde i utgangspunktet satt dette med lav prioritet ut ifra tidligere antagelser om at dette ikke skulle være en prioritering. Med tanke på hvor vi nå var kommet i prosjektet og tiden som gjenstod var vi usikre på om vi kunne få dette til. Etter litt undersøking fant vi frem til JavaScript rammeverket Chart.js som førte til at vi fikk implementert statistikk siden i løpet av relativt kort tid. 88

89 Etter å ha implementert dette sa vi oss fornøyde med funksjonaliteten til løsningen vår, og alt arbeid vi utførte videre handlet om å optimalisere løsningen og ordne opp i bugs vi fant underveis og dette ble da slutten på utviklingsprosessen Testing Vi ønsket å kunne utføre ulike tester av chat-løsningen for å forsikre oss om at den møter kravene og forventningene vi og oppdragsgiver har. Vi utførte ulike tester som blant annet brukertester, kompatibilitetstester og enhetstester. For brukertestene forberedte vi oppgaver og spørsmål. Spørsmålene tar utgangspunkt i delen om brukervennlighet fra testplanen som finnes som vedlegg 4.2. Som beskrevet i seksjon ble denne planen for front-end brukertesting satt opp under UX-design kurset. Før vi kunne starte å teste løsningen måtte den lastes opp på en server. Vi fikk tilgang til en Windows server hvor vi kunne laste opp løsningen vår. Frem til nå har vi kun kjørt løsningen på lokalt på localhost. Ved å laste denne opp på en server fikk vi muligheten til å teste løsningen som en helhet. Vi har testet: Tid Hastighet Optimalisering Webkamera, hvordan alt fungerer parallelt stress testing 4 Resultat I denne seksjonen vil vi ta for oss hva vi tenker om det endelige sluttproduktet vårt. I tillegg til dette vil vi gå gjennom hva som legges opp til videreutvikling for Webnodes. Istedenfor å gå gjennom enhver funksjon som kan legges til vil vi heller gå gjennom tre funksjoner for neste iterasjon, to funksjoner for framtidig utvikling og en funksjon som vi synes hadde vært flott å implementere en gang i fremtiden. Egenevaluering av arbeidsprosess Samarbeid Vi som gruppe har fungert svært godt. Vi har alle hatt ambisjoner om å skape et produkt som imponerer og som gruppemedlemmer har vi hverandres mangler. Gjennom prosjektet har vi alle spesialisert oss innenfor ulike felt samtidig som vi alle har vært innom og arbeidet med alle delene av prosjektet. Vi har ikke alltid vært enige om hverken prioriteringer eller hvordan ting skal løses, men med et godt arbeidsmiljø som oppfordrer til åpenhet har vi aldri hatt et problem med å bli enige om en felles løsning. 89

90 Allikevel er det ikke alt som er plettfritt i et gruppesamarbeid. Når man arbeider så tett over så lang tid med gruppemedlemmer man kjenner fra tidligere er det veldig lett å ende med pauser som varer litt lenger enn de burde eller avbrytelser i arbeidet for uformell prat. I tillegg til dette så har det vært dager hvor en av gruppemedlemmene har en dårlig arbeidsdag, og ender da med å distrahere de andre gruppemedlemmene fra deres arbeid. Allikevel så har disse problemene oppstått såpass sjeldent at vi ikke ser på det som et stort problem. Samtidig har uformelle samtaler og lignende vært en stor del av å skape et godt arbeidsmiljø hvor alle trives og holdes motiverte Arbeidsmetodikk Vi har som nevnt tidligere benyttet oss av arbeidsmetodikken kalt Crystal Clear og dette er et valg vi har vært svært fornøyde med. Det å ha en mer fleksibel arbeidsmetodikk uten for mye struktur har latt oss jobbe mer effektivt enn om vi skulle bruke tiden på møter, dokumenter og lignende som ikke har en stor effekt på en gruppe av vår størrelse. En gruppe av en større størrelse vil trenge mer struktur, men i vårt tilfelle har Crystal Clear fungert svært godt. Samtidig har de teknikkene vi har benyttet oss av fra Scrum, da spesielt Product Backlog vært svært hjelpsomme under prosjektet. Da vi startet prosjektet var vi enige om å benytte oss av Scrum Standups møter. Vi merket at etter hvert i prosjektet kunne vi vært flinkere til å holde disse møtene, men samtidig har Crystal Clear sitt krav om Osmotisk Kommunikasjon ført til at informasjonen som samles i Standup møtene har blitt delt i løpet av arbeidsdagen. Kunde- og Kundeservice-sidene Vi er svært fornøyde med begge sidene av vår løsning. Vi synes utseendet er appellerende samtidig som det er funksjonelt og kanskje viktigst av alt brukervennlig. Når det gjelder kunde siden så har det vært utfordrende å sette så mange funksjoner i noe av denne størrelsen, men brukertestene vi har utført tyder på at vi har fått til dette og møtt målet vårt om å skape noe som er brukervennlig. Chatassistent siden var enklere når det gjaldt å sette funksjonene sammen på en god måte ettersom vi hadde hele skjermen til disposisjon. Allikevel så har det vært så mange funksjoner som skulle implementeres her, så det er uten tvil denne delen av chatten som har krevd mest tid. I tillegg så var det svært utfordrende å tilpasse denne siden for mobil ettersom det er veldig mye å komprimere til en såpass liten skjerm, men til slutt så føler vi at vi har oppnådd et godt resultat som vi kan si oss svært fornøyde med. 90

91 Å bruke React har vært en god opplevelse, og vi er spesielt fornøyd med å ha utviklet alt i komponenter. Det å bytte ut en komponent er så enkelt som å legge til og fjerne en linje med kode og dette er utrolig viktig for potensiell videreutvikling. Grunnen til dette er at det ikke er noen garanti for at alle for eksempel vil ønske å ha footeren i chatten. Da er det bare å fjerne linjen med kode som setter inn footer komponentet så vil resten av chatten fylle ut den nye plassen. Utseendet har forandret seg utrolig mye fra våre første wireframes, og det er artig å se progresjonen som har vært her. Alt fra fargene som har blitt tatt i bruk til funksjonalitet og plassering har endret seg underveis. Vi er også svært fornøyde med å ha intervjuet selskapene som skulle benytte seg av applikasjonen for å finne ut av deres behov og ønsker. I de tidlige wireframene så hadde vi mye ubenyttet skjermareal, og selve chatten var det ikke like mye fokus på som det burde ha vært. Slik det er i dag så okkuperer chatten omtrent ¾ av skjermen, fargene har blitt endret til noe som ser langt mer profesjonelt ut. Oversikten over pågående samtaler og kunde køen er også flyttet fra høyre side til venstre side. Alle disse endringene har blitt gjort med hensyn på brukervennlighet og tilbakemeldinger fra intervjuer og møter. Vår struktur for å sette utseendet til chatten har også fungert svært godt. Ved at hver komponent har hatt sin egen sass fil så har det vært enkelt å justere på de ulike komponentenes utseende uten at konflikter har oppstått. Det er også langt mer ryddig og strukturert enn å for eksempel ha en enkel fil som setter utseendet for hele løsningen. Back-end Back-end delen av vårt prosjekt er strukturert og derfor enkel å videreutvikle. Vi valgte å lagdele applikasjonen noe vi føler var en god beslutning ettersom det gjør det enklere å arbeide med de riktige delene av løsningen. For eksempel så vil det med en lagdelt løsning være enkelt å vite hvor man skal arbeide med databasen, og hvor man arbeider med utseendet til applikasjonen. Vi har benyttet oss av SignalR for det meste av kommunikasjon mellom klienten og serveren og dette fungerer svært bra. Muligheten til å kalle metoder hos klienten fra serveren og omvendt har vært veldig praktisk i en rekke omstendigheter og SignalR har kjørt smertefritt. Det aller beste med SignalR er at den faller tilbake på eldre teknologier om de mest moderne kommunikasjonsprotokollene ikke støttes av nettleseren. 91

92 For pålogging har vi brukt.net sitt Identity som er et system som holder oversikt over ulike brukere. Identity har gjort det langt enklere å håndtere pålogging og ulike brukere, og i tillegg så funker Identity og SignalR sammen som har vært essensielt for å kunne håndtere de ansatte hos kundeservice. Videreutvikling Som vi nevnte tidligere i rapporten så innså vi allerede da vi fikk oppgaven at denne applikasjonen kunne implementere så mange funksjonaliteter at vi selv var nødt til å begrense oss. Nettopp på grunn av oppgavens potensielle størrelse var det en prioritet for oss å legge opp for videreutvikling. Arbeidet vi gjorde under planlegging ved å møte med ulike bedrifter og intervjue disse ga oss et innblikk i hvilke behov disse vil ha, og for Webnodes som selskap vil det være viktig å innfri disse behovene selv om vi som gruppe ikke hadde kapasitet til å innfri alle disse behovene Neste iterasjon Noen av bedriftene som benytter seg av Webnodes er internasjonale selskap. For disse selskapene ville det vært svært nyttig om chatten støttet flere språk. Å implementere dette er realistisk for neste iterasjon av løsningen. Mengden tekst som eksisterer i løsningen vår er begrenset, og å implementere en mulighet til å bytte mellom språk kan gjøres igjennom React. Vi ser for oss at dette kan gjøres ved å ha det som kalles en store med alle ordene som brukes i løsningen i en liste, for så å ha en innstilling som lar deg bytte mellom hvilken liste man benytter seg av avhengig av hvilket språk som ønskes. Et viktig punkt for bedriftene vi har intervjuet er at de ulike kundeservice departementene som da består av telefon, e-post og nå chat, skal kunne kommunisere og dele informasjon. Vi har ikke kunnet ta for oss dette problemet ettersom Webnodes har vært under rekonstruering mens vi har arbeidet med denne oppgaven. Vi har lagt opp til at vårt webapi skal være enkelt å bygge videre på slik at Webnodes møter på minimalt med utfordringer når det gjelder å hente informasjon fra chatten samt å gi informasjon til chatten. Videre så er det en viktig funksjon som vi ikke har rukket å implementere som er nødvendig å fullføre ved neste iterasjon. Denne funksjonen er tilpasning av CSS etter egne ønsker. Det som er tanken her er å implementere et CSS dokument som er lagt opp til at man selv kan endre visse deler av løsningen. Dette vil da være farger, eventuelle bilder, tekststørrelser og annet. Funksjonen er viktig ettersom det er ulike selskap som skal ta i bruk denne chatten, og disse selskapene vil mest sannsynlig ønske å sette sitt eget preg på chatten. 92

93 4.4.2 Framtidig utvikling En teamleder vil ha andre behov for sin del av chat-løsningen enn det en chatassistent vil ha. Disse behovene kan bli lagt inn i en mer avansert side med innstillinger. Det vi ville ønsket å implementere på en slik side er for eksempel statistikk over de ansattes samtaler, muligheten til å endre utseendet på chatten, både på kunde siden og chatassistent siden og muligheten til å gi direkte tilbakemeldinger til ansatte. Skalerbarhet er et annet tema som er nødvendig å videreutvikle. I starten av arbeidsprosessen diskuterte vi med Webnodes hvilken størrelse det er vi skal forberede løsningen for. Vi fikk da beskjed om at ingen av selskapene benytter seg av mer enn én server for sine nettsider, og vi kan derfor ta utgangspunkt i dette. Med dette som grunnlag valgte vi å lagre tilkoblinger til serveren in memory. Grunnen er at det er den eneste måten å holde en oversikt over pågående tilkoblinger samtidig som det er optimalisert for effektivitet. Det negative aspektet ved denne løsningen er at det kun fungerer med én server, og det er derfor nødvendig å gjøre endringer hvis et større selskap ønsker å benytte seg av løsningen. Den eneste erstatningen vil være permanent lagring av tilkoblingene i en database. Permanent lagring vil gjøre det mulig å kjøre løsningen på flere servere, men vil koste på effektiviteten Prikken over I-en Et av de mest spennende utviklingsfrontende som foregår i dag er når det gjelder kunstig intelligens. Chatbot s er et svært populært eksempel, og de selskapene vi intervjuet uttrykket interesse i en implementasjon av en slik Chatbot. En slik bot vil da kunne svare på enkle spørsmål, informere om åpningstider og mye annet. Denne vil også kunne arbeide konstant uten å være begrenset til åpningstidene for kundeservice. Microsoft har utviklet noe kalt Microsoft Cognitive Services som tilbyr mange nyttige verktøy for å skape gode bot s. Dette er definitivt noe vi ville sett mer på om tiden strakk til, men må dessverre overlates til framtidig utvikling ettersom denne funksjonen ikke er essensiell i første omgang. Konklusjon For å oppsummere vil vi si at vi føler vi har arbeidet godt gjennom prosjektet og at produktet vårt er et godt en. Ikke alt vi har gjort har vært perfekt, og det er noe forbedringspotensial, men med vårt utgangspunkt tatt i betraktning føler vi selv at vi har gjort et godt arbeid. Noen ting kunne bli gjort bedre underveis. Vi skulle gjerne sett at vi hadde testet regelmessig gjennom våre iterasjoner av produktet. Noe vi forsøkte å få til, men som 93

94 ikke ble mulig, var testing med de ansatte som skal benytte seg av løsningen vår. Dessverre ønsket ikke selskapene å delta på dette. Gruppearbeidet har fungert svært godt. Gruppemedlemmene har ikke vært redde for å ytre sine meninger og det har vært et generelt godt miljø. Allikevel så har det vært noen dager hvor gruppen har vært litt for sosiale og tid burde vært brukt på prosjektarbeidet. Vi merket også at alle har dårlige dager innimellom hvor det er vanskeligere å holde fokus. Når man jobber så tett som vi har gjort så vil ofte det at et gruppemedlem har en slik dag føre til at hele gruppen jobber mindre effektivt. Heldigvis så oppstod ikke dette problemet så ofte, men det kunne vært en idé for gruppemedlemmer å jobbe individuelt på slike dager. 94

95 Produktdokumentasjon Chatnodes Bachelorprosjekt 2017 Gruppe 32 95

96 Forord Denne rapporten tar utgangspunkt i at leseren har en generell forståelse om teknologiene som er benyttet i applikasjonen. De viktigste teknologiene brukt i denne løsningen er React.js,.Net. Vedlagt ligger også en ordliste for denne rapporten [Vedlegg 5]. Rapporten er delt inn i 3 deler. Den første av disse går gjennom forventningene Webnodes hadde til oppgaven, den andre går gjennom det meste av funksjonaliteten med bilder og forklaring av kode siden av funksjonen. Til slutt går vi dypere inn i den tekniske delen av løsningen. 96

97 Innholdsfortegnelse 1 Webnodes sine forventninger Funksjonalitet Meldinger UI perspektiv Programvare perspektiv Lagrede svar UI perspektiv Programvare perspektiv Sanntidsinformasjon UI perspektiv Programvare perspektiv Statistikk side UI perspektiv Programvare perspektiv Filoverføring UI perspektiv Programvare perspektiv Pålogging UI perspektiv Programvare perspektiv Logging UI perspektiv Programvare perspektiv Notifikasjoner UI perspektiv Programvare perspektiv Last inn siden på nytt og flere faner åpne UI perspektiv Programvare perspektiv Tilbakemelding UI perspektiv Programvare perspektiv Chat på E-post UI perspektiv Programvare perspektiv Smilier UI Perspektiv Programvare perspektiv Video samtale UI perspektiv Programvare perspektiv Tekniske siden av løsningen Produksjon og utviklingsmiljø Node.js Webpack

98 Data Dataoverføring i SignalR Web API Data i React med MobX Databaser Back-End API DAL BLL Model View Autentisering Identity Front-End Struktur React komponenter React Router Sass Mobil tilpasning Enhetstesting Moq & Nunit Jest

99 1 Webnodes sine forventninger Da vi først fikk den konkrete oppgaven av Webnodes var det ikke mye funksjonalitet som ble spesifisert. Vi ble bedt om å lage en chat som skulle tillate for kommunikasjon mellom kundeservice og kunder. Kunde siden av chatten skulle bestå av en knapp som alltid var synlig og som åpnet et chat-vindu i samme nettleservindu. Det ble også nevnt noe tilleggs funksjonalitet som blant annet smilier, fil opplastning, online status og hvis mulig enkel tekstformatering, video og skjermdeling. Når det gjelder siden for chatassistenter var det viktig at det var mulig å kommunisere med flere kunder om gangen, at noe statistikk og historie kunne vises, samt sanntidsinformasjon. Webnodes ønsket også at det skulle være mulig å initiere kontakt med en kunde, men dette er noe vi som gruppe konkluderte med var upassende for en kundeservice chat. Grunnen for dette er at det for mange brukere vil føles som påtrengende. I løpet av prosjektperioden har det dukket opp flere ønsker, spesielt gjennom intervju med noen av kundene som vurderer å benytte seg av chatten. I neste del av rapporten vil vi derfor gå gjennom hvilke funksjonaliteter som har blitt implementert. 2 Funksjonalitet En chat-løsning mellom kundeservice og kunder består av mer enn bare muligheten til å chatte med hverandre. I vårt prosjekt som er et hybrid mellom brukersentrert utvikling og programvareutvikling har det vært viktig å lage en løsning hvor all funksjonaliteten fungerer, men også hvor løsningen er visuelt appellerende og brukervennlig. Funksjonene som vi har valgt å implementere går vi gjennom her. Funksjonene vi har implementert er basert på Webnodes sine ønsker og samtaler vi har hatt med Webnodes sine kunder. Vi har valgt å implementere de funksjonene det er en enighet om er svært viktige, og heller legge opp til videreutvikling for funksjonalitetene vi ikke hadde tid til å implementere. Mer om denne prosessen står i prosessrapporten. I denne seksjonen vil vi gå gjennom de ulike implementerte funksjonene. Vi vil første forklare hvordan funksjonen fungerer i brukergrensesnittet, for så å gå gjennom de tekniske detaljene av løsningen. For å kunne forstå det som blir gått gjennom i denne delen av rapporten er det forventet at leseren har noe teknisk forståelse av teknologiene involvert i løsningen. Vi henviser også til ordliste som er lagt til som [vedlegg 5]. 99

100 Meldinger Definisjonen for en chat er ifølge oxford dictionary som følger: «Exchange messages online in real time with one or more simultaneous users of a computer network.» (Oxford Dictionaries, n.d.) Dermed kan man si at det å sende meldinger fram og tilbake er minstekravet for å kunne kalle noe en «chat» UI perspektiv Fra kunde siden kan det sendes meldinger direkte til en chatassistent fra kundens chat-vindu. For at en kunde skal kunne sende en melding så må de være i en samtale med en kundeserviceassistent, og hvis dette ikke er tilfellet vil det stå en tydelig beskjed om dette slik som vist i figur 2.2. Kundene har også muligheten til å velge om de ønsker å presse enter-tasten for å sende meldinger eller ikke. I figur 2.1 ser vi hvordan meldingene ser ut fra kundens side. Meldingene man selv sender er på høyre side mens meldingene sendt av en chatassistent er på venstre siden Figur 2.1 Viser hvordan meldinger ser ut fra kunden sin side. Venstre side viser mottatte meldinger og høyre viser sendte 100

101 Figur 2.2 Viser hva som skjer når man prøver å sende en melding før man er i kommunikasjon med en chatassistent For at en chatassistent skal kunne sende meldinger til en kunde så må han først ha lagt til en kunde i chatten fra samtale køen, se figur 2.3. Når dette er gjort vil den ansatte ha mulighet til å sende meldinger fram og tilbake med kunden. Hvis den ansatte er i samtale med mer enn én kunde vil disse kundene være listet opp på siden av chatten og den ansatte vil da kunne bytte fritt mellom disse samtalene. Når det byttes mellom samtalene vil meldingene tilhørende den chatten automatisk lastes inn igjen av React. 101

102 Figur 2.3 Viser hvordan meldinger ser ut fra chatassistent sin side. Venstre side viser mottatte meldinger mens høyre viser sendte Programvare perspektiv Måten løsningen sender meldinger på er litt forskjellig fra kunde siden og chatassistent siden. Først går vi gjennom kunde siden før vi forklarer hva som er annerledes på chatassistent siden av løsningen. Figur 2.4 viser en forenkling av denne prosessen, og denne forklares i mer detalj i de neste avsnittene. 102

103 Brukeren trykker send melding React sender melding videre til SignalR SignalR på klient side kaller SignalR metode på serveren Serveren mottar melding, identifiserer gruppen meldingen skal sendes til Klient mottar melding og skriver denne ut til skjermen. Figur 2.4 Viser en forenkling av den tekniske prosessen for å sende en melding Når man har skrevet en melding og trykket på send knappen eller enter-tasten, hvis dette er slått på, så vil en onclick metode kjøres i React. Denne vil da kalle på en funksjon i SignalR delen av applikasjonen. SignalR delen kommuniserer med huben på serveren. En hub i SignalR er et API som lar server og klient kalle på metoder hos hverandre. Applikasjonen vil da kalle på sendmelding metoden i serverens hub, og sender meldingsteksten med dette kallet. I huben vil det gjøres en sjekk på om det er en ansatt eller en kunde som sender meldingen. Når sjekken er fullført vil SignalR sende meldingen til alle tilkoblingene i SignalR gruppen med kundens ID. Dette skjer ved å kalle på en metode som eksisterer i alle klientene. En SignalR gruppe holder tilkoblingene til klientene som legges inn. I våre grupper legger vi alle kundens tilkoblinger til serveren samt den ansatte som snakker med kunden. Metoden som serveren kaller hos alle klientene tar da imot meldingen og skriver ut meldingen på skjermen. Det sendes også med en boolean variabel som indikerer om meldingen er sendt fra en kunde eller assistent. Variabelen brukes til å sette variabelen til høyre eller venstre i meldingsvinduet. Fra chattassistent siden er det noen små forskjeller. I tillegg til selve teksten meldinger består av sendes også ID en til den kunden admin sender meldingen til. Serveren bruker denne ID en til å sende meldingen til riktig kunde. 103

104 Lagrede svar Etter å ha hatt intervjuene med et par bedrifter som allerede har implementert sine egne chat-løsninger forstod vi at det var essensielt å inkludere forhåndslagrede responser. Dette vil de ansatte kunne benytte seg av for å effektivisere arbeidet sitt samt å skape en viss konsistens blant tilbakemeldinger kunder får av kundeservice UI perspektiv Funksjonen aktiveres ved å trykke på ikonet for lagrede svar og åpner da en dialogboks som viser de ulike responsene. Figur 2.5 viser hvordan lagrede svar ser ut. Helt til venstre står en formulering av spørsmålet, i midten er svaret som er den faktiske teksten som vil bli lagt til i input feltet der man skriver og til høyre er det en velg knapp som lar deg velge et av svarene. I tillegg til disse funksjonene har vi også implementert et søkefelt hvor man kan søke etter spesifikke svar. Listen av lagrede svar oppdateres mens man skriver så man raskest mulig kan finne frem til den riktige responsen. Figur 2.5 Viser hvordan de lagrede svarene listes opp i applikasjonen. Når man trykker på en av velg knappene vil vinduet svarene befinner seg i automatisk lukkes og teksten som tilhører svaret man valgte vil legges inn i input feltet. Teksten vil ikke overskrive det som allerede står i input feltet, og man kan gjøre modifikasjoner på denne teksten dersom det er ønskelig Programvare perspektiv De lagrede svarene oppbevarer vi i en database på server siden. Når chat-siden laster inn vil React kalle en funksjon som henter de lagrede svarene fra serveren vår. Serveren vil da verifisere brukeren som forsøker å hente svarene og vil så hente de lagrede svarene fra databasen og sende dem tilbake til klienten. Klienten mottar da 104

105 en liste med lagrede svar. Når denne listen er hentet så vil den lagres i variabelen filteredinput. Koden vil så gå gjennom listen og skrive de ut i lagrede svar vinduet. Løsningen vil også lytte på søkefeltet, og hver gang denne endres så vil listen i filteredinput endres, og kun det som matcher med det som står i søkefeltet vil legges inn her. Når disse endringene skjer vil også løsningen skrive ut de lagrede svarene som er i filteredinput på nytt. Sanntidsinformasjon Det er en stor mengde data som kan samles når man lager en chat-løsning. For en chatassistent vil det være sanntidsdata som er spesielt relevant og det er dette vi skal gå gjennom her UI perspektiv I figur 2.6 kan vi se hvordan oversikt siden ser ut. Informasjonen her er den vi anser som mest relevant for de ansatte som sitter på jobb. På venstre side vises det hvor mange som er satt til pålogget og borte. Pålogget indikerer at en ansatt foreløpig sitter og arbeider, mens borte indikerer at personen ikke sitter på chatten for øyeblikket. Hvis man ser på hoveddelen av oversikt siden ser man at alle de ansatte i denne figuren vises sortert etter påloggingsstatus. Hvordan man vil sortere brukerne kan man velge fra listene øverst på siden. Fra listen til høyre kan man velge å sortere etter status, antall pågående samtaler eller totale samtaler for denne dagen. Til venstre for denne listen er det enda en liste som lar deg velge å kun se ansatte som er pålogget, borte eller avlogget. For hver ansatt vises navn, påloggingsinformasjon, antallet pågående chatter de har samt hvor mange chatter de har fullført i løpet av dagen. Figur 2.6 Viser sanntid siden i applikasjonen 105

106 2.3.2 Programvare perspektiv I vår ChatStore i React har vi tilgang til alle de påloggede ansatte. En store er en komponent hvor data lagres, og vi går i mer detalj om dette i seksjon I objektene som representerer de ansatte er det lagret informasjon om hvor mange samtaler de har hatt i løpet av dagen, hvor mange pågående samtaler de har, påloggingsstatusen deres og annen relevant informasjon. I storen vår er det en liste for hver påloggingsstatus, hvor de ansatte med tilsvarende status legges inn. I React komponenten som skaper sanntidsinformasjonen har vi to dropdown lister. En som representerer sorteringsrekkefølge og en som representerer hvilke påloggingsstatuser som skal vises. Komponentet henter listene som representerer hvilke brukere som er tilkoblet med hvilken status, og sorterer deretter disse basert på hvilken sorteringsrekkefølge som er valgt i dropdown listen. Før render metoden kjøres gjøres det en sjekk for å se hvilken påloggingstatus som er valgt i den tilhørende dropdown listen, for så å hente data kun fra denne listen. I render metoden vises alle listene, men kun den som er valgt vil inneholde noe data og dermed er det kun denne brukeren ser. Statistikk side I tillegg til sanntidsinformasjonen er det mye statistikk som samles i en Chat applikasjon og denne må fremstilles. For dette har vi laget en oversikt side med sanntidsinformasjon UI perspektiv Figur 2.7 viser hvordan oversikt siden ser ut. Her vises ulike representasjoner av data som er relevant for brukeren. Foreløpig er dataen som vises på siden statistikk antall samtaler som har vært de ulike dagene. Denne er delt opp ukesvis. Under denne vises data om kundenes tilfredshet basert på tilbakemeldinger kundene kan gi når de avslutter en samtale. I baren til venstre kan vi også se gjennomsnittlig ventetid for en kunde i køen og en representasjon av brukertilfredshet i prosent. 106

107 Figur 2.7 Viser oversikt siden i applikasjonen vår Programvare perspektiv For å få fremstilt dataen på måten som er gjort har vi benyttet oss av javascript rammeverket chart.js. Dette er et rammeverk vi har implementert via en pakke i Node.js noe vi kommer tilbake til i seksjon 3.1.1, og gjør det svært enkelt å lage ulike diagrammer. Alt som er nødvendig er å sette en «div» tag med klassenavn tilsvarende typen diagram som skal brukes. Inne i disse lages diver for å justere ulike deler av diagrammet og spans med klassenavn tilsvarende hvilke felter span skal fremstille. Under i kodeeksempel 2.7 vises et eksempel for hvordan en prosentbar lages. <div classname="percent-bar-container"> <div classname="time"> <span classname="time-numbers">1.6</span> <span classname="time-measurment">min</span> </div> <div classname="bar-header"> <span>mål</span> <span>{this.props.percent} %</span> </div> <div classname="bar-bg"> <div classname="bar" style={{width: this.state.width+'%'}}></div> </div> </div> Kodeeksempel 2.7 Viser koden vi bruker for å lage et prosentdiagram. 107

108 For å hente dataen fra serveren benytter vi oss av Web APIet. Vi ber APIet hente all samtale date for en spesifikk uke for å minske dataen som må overføres. Vi utfører beregningene nødvendige for å få ut statistikken vi viser, i React koden og legger dem inn i så inn i de tilhørende diagrammene som da justerer seg for å vise riktig informasjon til brukeren. Filoverføring Filoverføring er noe som kan være nyttig i mange ulike situasjoner. For visse bedrifter er filoverføring essensielt for at de skal kunne ha en chatløsning ettersom det fortsatt er ting som må utføres for hånd slik som underskriving av kontrakter og lignende. Ikke alle bedrifter har bevegd seg mot kun digitale løsninger enda, og det er viktig å tilby dem verktøyene de trenger for å kunne fortsette sitt arbeid UI perspektiv Som vi ser i figur 2.8 så vil operativsystemets egen fil dialog åpnes når man trykker på knappen for å sende en fil, og herfra velges da filen brukeren ønsker å sende. Når denne filen velges så vil den lastes opp og et opplastningsikon vil vises inntil dette er fullført. Figur 2.8 Viser hva som skjer når man trykker på vedlegg knappen Når filen er ferdig lastet opp vil man se en melding slik som den i figur 2.9 som indikerer at det nå er mulig å laste ned filen. Ved å trykke på last ned vil nettleserens 108

109 nedlastingsdialog starte og etter at man har fullført denne vil filen bli lastet ned til den valgte destinasjonen. Figur 2.9 Viser hva som skjer etter at man har valgt filen man ønsker å sende Figur 2.10 viser hvordan meldingen mottas på kunde siden. På samme måte som på chatassistent siden vil man da trykke på last ned for så å få nettleserens nedlastingsdialog opp, og når dette er fullført lastes filen ned. 109

110 2.5.2 Programvare perspektiv Figur 2.10 Viser hvordan det ser ut fra kundens side. Filoverføring er noe av det som gjøres gjennom APIet og grunnen til dette er at SignalR er laget for å overføre mindre JSON objekter. Når man overfører filer gjennom serveren vil man etter å ha valgt hvilken fil som skal sendes, dele filen opp i mindre biter. Hver av disse bitene vil lastes opp til serveren individuelt, og serveren vil da sjekke om filen allerede eksisterer, eller lage en ny fil. Når alle bitene er samlet er filen lastet opp. Når mottaker aksepterer filen vil det samme da gjøres andre veien. Vi går gjennom hvordan dette gjøres i mer detalj i seksjon Pålogging For de som arbeider hos kundeservice blir det nødvendig å ha en måte å logge seg inn på jobb. Derfor har vi laget en påloggingsfunksjon for de ansatte. Påloggingsiden vil være det første chatassistentene møter når de starter vår løsning UI perspektiv I figur 2.11 ser vi pålogging skjermen. Her oppgir man informasjonen sin for så å trykke logg inn. En «vente» indikasjon vil vises på skjermen mens brukeren verifiseres. Når dette er fullført vil chatassistentenes brukergrensesnitt åpne seg og den ansatte kan da begynne å jobbe. 110

111 Figur 2.11 Viser hvordan påloggingssiden ser ut. Vi fant ut da vi intervjuet bedrifter som hadde en chat-løsning at det å vise påloggingsstatus for å indikere om de ansatte har pause eller er tilgjengelige er en funksjon som er nyttig for de ansatte. Med bakgrunn i dette valgte vi å implementere et status system og vi benytter oss av tre statuser, nemlig pålogget, borte og usynlig. Pålogget indikerer da at du er tilgjengelig og kommuniserer med kunder. Borte indikerer at du har pause og er derfor ikke tilgjengelig for øyeblikket men vil være det når pausen er over. Usynlig på sin side indikerer at brukeren er tilstede, men kan ikke svare på meldinger for øyeblikket grunnet ulike årsaker. Hvis man trykker på navnet sitt oppe til venstre i løsningen vår vil en dropdown meny slik som den er vist i figur 2.12 vises. Her vil du da kunne endre din status eller logge ut av systemet. Man vil øyeblikkelig kunne se endringen ettersom statusen under navnet til brukeren vil endre seg. Det er ikke mulig å endre statusen sin til borte eller usynlig hvis man er i dialog med en kunde, ettersom man må fullføre de kundene man har før man tar pause. Det ville vært svært problematisk å forlate kunden midt i en samtale. 111

112 2.6.2 Programvare perspektiv Figur 2.12 Viser hvordan status endringene gjøres. For å logge på må brukeren skrive inn brukernavn og passord. Dette sendes så til serveren for verifisering. Påloggingen håndteres av Microsoft sin Identity løsning som vi tar i bruk. Vi kaller på funksjonen for å logge inn ved å utføre et axios kall, noe vi kommer tilbake til i seksjon Med kallet sender vi et objekt med passord og brukernavn somt Et serveren så utfører en sjekk på for å se om denne informasjonen stemmer overens med en bruker i databasen. Hvis sjekken stemmer vil serveren returnere et token, og denne vil bli lagret lokalt i nettleseren. Hver gang man kommuniserer med serveren vil denne bli sendt med, og man kan dermed forsikre seg om at brukeren har tilgang til det som skal utføres. Status representeres i koden av en variabel som ligger i ChatStore. I React komponenten er det en dropdown list som viser alle statusene. Når en status endres vil variabelen i ChatStore også endres på. Når denne endres kalles det også på en metode fra SignalR huben. Denne metoden tar imot statusen, og oppdaterer serverens admin objekt til å ha riktig status. Logging De aller fleste selskap ønsker å ha muligheten til å logge chattene som tar plass gjennom kundeservice. Dette er viktig for å ha bevis for enhver bekreftelse man har eller enhver avtale som er gjort over chat. 112

113 2.7.1 UI perspektiv Dette er en av funksjonene som ikke vil være synlige fra UI siden ettersom alt dette gjøres i koden Programvare perspektiv Vi diskuterte med Webnodes hvordan vi skulle logge chattene. Opprinnelig tenkte vi å lagre meldinger i såkalte «batch», altså samle opp flere meldinger på en gang for så å lagre dem i databasen samtidig. Webnodes på sin side ønsket at vi skulle lagre hver melding i øyeblikket de ble sendt. Hvis et større selskap tar i bruk chatten vår må dette endres ettersom databasekall er ressurskrevende., altså samle opp flere meldinger på en gang for så å lagre disse Når en melding sendes vil den gå gjennom «Send» metoden for enten kunde eller ansatt i SignalR huben på serveren. Her bruker vi et objekt som representerer den ansatte i samtalen, og vi valgte derfor å lage en liste med meldinger i objektet. Hver gang en melding sendes vil den da settes inn i listen med meldinger, og når samtalen er avsluttet vil vi sammen med all annen informasjon vi lagrer om samtalen. Notifikasjoner Et viktig aspekt av en chat-løsning vil være notifikasjoner. Man vil ikke alltid være helt oppmerksom på chatten og kan da ende opp med å ikke merke at en ny melding popper inn. I et slikt tilfelle vil notifikasjoner bidra med å hente oppmerksomheten til brukeren når en melding dukker opp. I tillegg så er notifikasjoner svært viktig ettersom vi har implementert muligheten til å snakke med flere kunder på en gang. Ettersom man da ikke har alle kundene åpne samtidig så er det hjelpsomt å kunne se hvilken kunde det er som har sendt en ny melding UI perspektiv Figur 2.13 viser hvordan notifikasjoner ser ut fra chatassistenter sitt perspektiv. Her vil det altså dukke opp et rødt ikon ved siden av den respektive kunden som har sendt meldingen. Tallet inne i ikonet indikerer hvor mange uleste meldinger det er i denne chatten, og når man åpner den chatten så vil ikonet forsvinne ettersom meldingene da skal være lest. Vi gir også notifikasjoner når kunde køen går fra tom til å ha en eller flere kunder i seg. 113

114 Figur 2.13 Viser hvordan notifikasjonene ser ut for en chatassistent På kunde siden så indikeres notifikasjonene med en lyd. Denne lyden vil kun høres om chatten er minimert eller om kunden befinner seg i en annen fane enn der chatten foregår. Dette er fordi hvis kunden er i riktig fane og har chatten åpen så er kunden høys sannsynlig bevist på chatten, og en slik lyd vil da kun være irriterende. I tillegg til denne typen notifikasjoner har vi en annen type for ting som ikke har med meldinger å gjøre. Disse oppstår når køen går fra 0 til høyere, når en ansatt prøver å endre status mens hen er i en samtale og andre passende situasjoner. Disse ser ut som vist i figur Programvare perspektiv Figur 2.14 til høyre vises en notifikasjon For telleren som viser antall mottatte meldinger bruker vi ChatStore. Her lagres mesteparten av dataen som brukes i løsningen. Vi lager her en liste med et tall tilhørende hver av de pågående chattene. Hver gang det mottas en melding så økes denne counteren med en for kunden som mottar meldingen. Denne endringen vil gjennom mobx oppdatere GUI slik at riktig antall notifikasjoner vises. For å resette denne counteren blir den satt til 0 hver gang den respektive chatten åpnes. Under i figur 2.15 vises en simplifisering av denne prosessen. 114

115 Melding mottas Når kundeservice åpner chatt resettes counter Counter økes med 1 React oppdaterer komponenten i nettleser og viser endring Endring oppdaterer React komponent gjennom mobx Figur 2.15 Viser hvordan notifikasjonene på siden for chatassistenter oppdateres. For å spille av lydnotifikasjonene bruker vi JavaScript rammeverket Howler. Denne er laget slik at den støtter lydavspilling på de aller fleste nettlesere og vi slipper derfor å gjøre egne tilpasninger for dette. Når en melding mottas så gjøres en sjekk om kravene for å motta en lydnotifikasjon er tilstede. Vi har også laget en metode som sjekker om selve nettsiden er i fokus for å bekrefte at dette ikke er tilfellet når vi spiller av lyder. Videre så har vi måtte forsikre oss om vi ikke sender flere lydnotifikasjoner etter hverandre. Dette gjør vi ved å vente to sekunder med å sende en lydnotifikasjon, og hvis en melding sendes innen denne tiden så vil ikke lyd spilles av for denne. Dette forhindrer at vi får et overtall av notifikasjoner, og kun en vil spilles med mindre det er over to sekunder siden siste melding ble sendt. Typen notifikasjoner slik vist i figur 2.14 har vi laget et eget React komponent for. Når vi bruker dette React komponentet i løsningen sender vi med en tittel og teksten som skal stå i notifikasjonen. Vi sender også med hvilken type notifikasjon det er hvor den kan være enten en suksess, advarsel eller feil notifikasjon. Ikonet som vises i notifikasjonen vil tilsvare typen. 115

116 Last inn siden på nytt og flere faner åpne Det vil være svært upraktisk å ha en chat hvor all data går tapt når man laster inn siden på nytt. I tillegg til dette støtter de fleste chatter i dag at man kan holde samtalen gående i flere ulike faner. Ofte har kunden lyst til å fortsette å navigere rundt nettsiden mens man chatter, spesielt i nettbutikker, og da er chatten nødt til å «huske» meldingene for at den skal kunne brukes UI perspektiv Denne funksjonen vil nok for mange gå ubemerket fra UI perspektivet. Det som skjer her er at når man laster inn siden eller går til en annen side på samme domenet så vil meldingene som var der tidligere, fortsatt være der kort tid etter man laster inn siden. Det samme vil skje om man holder chatten åpen over flere faner. På chatassistent siden gjelder det samme, og man vil hente tilbake all data på siden hvis man laster inn siden på nytt på nytt. I tillegg til det at man henter tilbake data, så bevares også tilkoblingen mellom klient og server. Av seg selv vil SignalR avslutte en tilkobling når man laster inn siden på nytt, men vi har ordnet det slik at hvis man må laste inn siden så settes man tilbake i den samme samtalen som man var i før Programvare perspektiv Først tar vi for oss hvordan tilkoblingen mellom klient og server bevares. Figur 2.16 viser en simplifisert forklaring av dette. Når en klient kobler seg til siden så opprettes det en cookie med en unik GUID som da brukes til å identifisere klienten. Når en kunde starter sin chat så vil SignalR koble seg opp mot serveren, og da sende med denne cookien. Kunden vil da settes inn i kunde køen og det vil samtidig lages en SignalR gruppe som bruker denne IDen som navn. Ettersom cookien lagres hos nettleser så vil serveren altså kunne kjenne igjen denne kunden så lenge cookien eksisterer, som er til nettleseren lukkes. Ved å ha denne cookien kan serveren sjekke om en kunde eksisterer i køen fra før eller eventuelt er i samtale med en admin, og hvis dette er tilfellet vil den nye tilkoblingen settes inn i samme SignalR gruppe og vil da kunne sende og motta meldinger i den samme chatten. 116

117 Åpner nettsiden og lager cookie hvis denne ikke finnes fra før Kunden åpner chatten Sjekker om kunden eksisterer Kunden eksisterer Kunden eksisterer ikke Kunden legges til i den allerede eksisterende SignalR gruppen Lager en ny SignalR gruppe Kunden legges til i kunde køen Tilbakemelding Figur 2.16 Forenklet figur av oppkobling mot siden Tilbakemelding er essensielt for at en service skal kunne forbedres. Tilbakemelding blir den eneste måten en teamleder eller andre i ledelsen kan få vite hvordan kunden reagerer på deres kundeservice. Uten denne tilbakemelding så er det mulig at ting som gjøres galt ikke dukker opp på radaren til bedriften og blir dermed ikke forbedret UI perspektiv Vår tilbakemelding utføres når en kunde avslutter samtalen. Kunden vil da få opp en dialog boks hvor hen blir spurt om å gi tilbakemelding som vist i figur Under denne teksten finner man tre fargede smilier. Smiliene indikerer hvor fornøyd kunden er med opplevelsen, og ved å klikke på en av disse vil smiliene vil man bli takket for tilbakemeldingen og få muligheten til å lukke chatten. 117

118 Programvare perspektiv Figur 2.17 Viser hvordan tilbakemelding i applikasjonen Figur 2.18 viser en forenkling av hvordan tilbakemelding gis i systemet. Når samtalen avsluttes og en av smiliene velges så settes en tilsvarende tekst verdi som enten er high, medium eller low. High representerer da høy kundetilfredshet og low indikerer lav tilfredshet. Når samtalen da er avsluttet så kjøres en funksjon gjennom mobx og signalr og denne gir beskjed til serveren om at samtalen er avsluttet og sender samtidig med tilbakemelding og annen data om samtalen. På serveren vil denne dataen mottas og man vil da lagre tilbakemeldingen i databasen. 118

119 Samtale avsluttes Dialogboks med smilier åpnes Kunde trykker på en smiley Verdien til smilien sendes gjennom SignalR til server Chat på E-post Figur 2.18 Forenklet forklaring for hvordan tilbakemelding Håndteres av applikasjonen. I mange situasjoner vil det være nyttig for en bruker å kunne få en kopi av samtalen de har hatt. En samtale kan ha kommet frem til en spesiell dato, resultert i et identifikasjonsnummer eller noe lignende. I tillegg så er det greit å ha noe konkret for å være sikker på at man kan holde selskapet til det de har lovet via chatten. Dette er noen få av grunnene til at vi har inkludert muligheten til å sende chatten på E-post UI perspektiv Server lagrer tilbakemelding i database Når man forsøker å avslutte en samtale fra kunde siden vil man få opp et par valg muligheter. Et av disse er valget om å sende chatten på e-post. Når man trykker på denne får man opp en dialogboks som vist i figur Her skriver man inn e-post adressen sin, og denne valideres live. Når du har skrevet inn en godkjent e-post adresse kan du presse send knappen. E-posten vil ikke bli sendt før etter samtalen er endt, men vil bli sendt øyeblikkelig etter det. 119

120 Programvare perspektiv Figur 2.19 Viser e-post dialog boksen som dukker Opp når man trykker på E-post knappen. Når man velger å få samtalen sendt på e-post vil man bli bedt om å skrive inn sin e- post adresse. Når denne er skrevet inn så vil en variabel i React bli satt til true, og denne variabelen representerer om en e-post skal bli sendt eller ikke. E-post adressen vil også bli lagret, og når samtalen ender så vil denne dataen bli sendt til serveren. Serveren vil så utføre en sjekk på boolean variabelen, og når den ser at denne er true vil en e-post bli sendt til kunden. For å sende mailen bruker vi SmtpClient klassen i.net. For å benytte oss av denne konstruerer vi først et E-post objekt. Her legges alle meldinger som ligger inne hos assistenten og det skrives inn hvem det er som har sendt dem. Når e-posten er konstruert utføres koden i kodeeksempel 2.20 for å sende denne. SmtpClient smtp = new SmtpClient(); smtp.host = "smtp.gmail.com"; //Eller SMTP Server Adressen smtp.credentials = new System.Net.NetworkCredential ("domene@gmail.com", "COoZPRTZhPGle4bdmWBTB5vFqYVip9375h6Tkb"); smtp.enablessl = true; smtp.send(mail); Kodeeksempel 2.20 Koden som kjøres for å sende en E-post fra serveren 120

121 Smilier Det er et velkjent faktum at smilier har blitt en del av vår skriftlige kommunikasjon, og det er derfor nødvendig å gi både kunder og ansatte muligheten til å benytte dette for å lette dialogen UI Perspektiv Å sette inn smilier er noe vi ønsket skulle være mulig både fra kunde siden samt siden for de ansatte. Disse to ser litt ulike ut, men konseptet er den samme for dem begge. Under følger det bilder som viser hvordan det ser ut på begge sidene. Figur 2.21 Viser hvordan smilier ser ut fra siden til chatassistenter 121

122 Figur 2.22 Viser hvordan smilier ser ut fra kundens side Som vi ser har begge sidene et smilie ikon enten i eller over input feltet. Når man klikker dette på ikonet så åpnes en liste med mange ulike smilier. For å sette disse smiliene inn i en melding trenger man kun å klikke på dem. Man har også muligheten til å velge mellom ulike kategorier av smilier øverst i listen Programvare perspektiv Vi benytter oss av NPM modulen react-emojione for å ta i bruk smilier i løsningen vår. For å ta i bruk denne bruker vi funksjonen «emojify()» i løsningen vår. Modulen vil da oversette verdier i teksten til tilsvarende verdier for smilier. I koden så har vi en liste med smilier for hver kategori som eksisterer. Denne listen representerer da smiliene som tilhører denne kategorien. Hver av disse smiliene er en knapp med smilien den representerer som innhold. Når denne trykkes på kalles en funksjon som setter smilien inn etter teksten som allerede eksisterer i input feltet. Dette får vi gjort ettersom vi har knyttet input feltets verdi mot en string vi har i komponentens state. Dette er en to-veis binding, så hvis man endrer teksten et sted så endres det automatisk i det andre. 122

123 Video samtale For visse kunder så kan det å ha muligheten til å kjøre en video samtale være svært hjelpsomt ettersom mange ting er lettere å forklare med muntlig kommunikasjon framfor skriftlig. Vi ønsket å inkludere dette på vår løsning, og har fått til dette ved å benytte oss av teknologien WebRTC UI perspektiv På kunde siden kan vi se et lite videokamera ikon i input feltet. Det er ved å trykke på dette at man starter en videosamtale. Når man trykker på denne vil chatten byttes til å vise videokameraet til brukeren, og når chatassistenten aksepterer samtalen vil deres videokamera også vises. Det er ikke før kunden starter en videosamtale at chatassistenten vil se et videokamera ikon dukke opp over input feltet. Når hen trykker på dette ikonet vil man åpne en komponent på høyre side og kan da trykke start samtale for å starte denne. Under i figur 2.23 ser vi hvordan videosamtalen ser ut under fra chatassistentens side. Figur 2.23 Kunde siden under oppringning 123

124 Programvare perspektiv For å benytte oss av teknologien WebRTC som gjør det mulig å ha slike videosamtaler bestemte vi oss for å bruke JavaScript rammeverket Peer.js. Peer.js er laget for å gjøre det enklere for utviklere å implementere denne teknologien i sin løsning. Under utvikling har vi benyttet oss av Peer.js sin utviklingsserver som tillater oss å ha maks 50 pågående videosamtaler på en gang, men denne kan byttes ut med en egen server hos bedriftene som vil benytte seg av chatten, men for bedrifter i vårt kundesegment vil 50 pågående samtaler være langt mer enn det de behøver. Når en kunde kobler seg på løsningen lages en PeerID. Denne blir da sendt til serveren hvor den lagres hos objektet som representerer den chatassistenten som er i dialog med kunden. Når kunden så trykker på ikonet for videosamtale vil en stream lages. En stream er et objekt som representerer video og mikrofon mediene og kan kun hentes etter at brukeren godtar at nettleseren skal ha tilgang til webkameraet og mikrofonen. Under i kodeeksempel 2.24 vises koden som benyttes for å hente en stream, og brukeren blir automatisk spurt om tillatelse. Vi ser også at når tillatelsen er gitt så lagres stream i React komponentet State. getusermedia(function (err, stream) { if (err) { console.log('failed'); } else { console.log('got a stream', stream); self.setstate({ stream: stream, stream_url: URL.createObjectURL(stream) }); } }); Kode eksempel 2.24 Viser hvordan man henter en stream i Peer.js Når en stream er hentet fra nettleseren så kan denne sendes til chatassistenten. Når den ansatte da trykker på sitt videokamera ikon for å starte samtalen vil den motta denne streamen samt sende sin egen stream til kunden hvor denne da vil bli vist. Når samtalen skal avsluttes så kalles «.close» på den åpne samtalen og samtalen er da endt. Et viktig krav for å benytte seg av videosamtaler gjennom WebRTC er at det er nødvendig å ha en server med SSL sertifikat. Grunnen til dette er for å forhindre uvedkommende fra å få tilgang til disse mediene. 124

125 3 Tekniske siden av løsningen I denne delen av rapporten skal vi gå gjennom de mer tekniske delene av vår applikasjon. Blant annet vil dette dreie seg om hvordan løsningen er satt sammen og teknologiene som brukes for å få det hele til å kjøre. DAL BLL API Klient View Figur 3.1 figur som illustrerer dataflyt Figur 3.1 viser hvordan data flyter i applikasjonen vår. Videre gis en kort beskrivelse av de fem ulike delene: DAL BLL API Klient View Database laget, denne tar seg av logikken nødvendig for å hente data eller lagre data til databasen. Business Layer Logic, denne delen tar seg av logikken som er nødvendig når data skal hentes eller sendes til DAL. Dette er laget som som front-end kommuniserer med. Denne delen av løsningen inneholder SignalR sin hub og et Web API som kommuniserer med front-end. Klient siden av chatten, inneholder en kontroller som react koden kan interagere med. Chatassistent siden av chatten, inneholder en kontroller som react koden kan interagere med. Tabell 3.2 Tabell for de ulike delene av applikasjonen DAL, BLL og API er utelukkende back-end deler mens Klient og View er delt opp i to. Data kan bevege seg begge veier mellom lagene, men alltid i den oppsatte rekkefølgen. I tillegg til de fem delene nevnt her er det også et model lag. Dette er hvor klassene som representerer de ulike objektene som transporteres mellom lag ligger, og disse brukes for å forsikre seg om at alle lagene bruker de samme objektene for å unngå å måtte konvertere dem. 125

126 Klient og View lagene er som tidligere nevnt delt opp i to deler, nettopp front-end og back-end. Front-end delen er kodet i javascript-rammeverket React mens back-end er gjort i.net med kodespråket C#. Produksjon og utviklingsmiljø For å skape vår løsning og kombinere alle de ulike teknologiene har det vært gjort noen tak for å skape et utviklingsmiljø som kan kombinere alt vi ønsker å bruke. I denne seksjonen går vi gjennom noen av teknologiene som er brukt i vårt utviklingsmiljø Node.js Vi bruker Node.js i vår løsning, en server-side plattform utviklet i javascript. Node gjør det mulig å ta i bruk en rekke pakker ved bruk av deres Node Package Manager(NPM). Pakkene vi benytter oss av lagres i en package.json fil slik at man enkelt kan installere de pakkene som er nødvendige. I tabellen nedenfor går vi gjennom noen av de viktigste av pakkene vi tar i bruk og hva de gjør. Modul Beskrivelse Webpack Babel loader Jest Sass React Webpack Tar alle filene våre og samler de til en JavaScript fil. Et JavaScript bibliotek som brukes for å oversette moderne JavaScript til vanlig JavaScript Et testrammeverk for JavaScript Brukes for å oversette Sass dokumenter til CSS dokumenter som da forstås av nettlesere Nødvendig pakke for å bruke React. Tabell 3.3 Tabell som viser de viktigste NPM modulene i løsningen vår Vi kan se på webpack som et mellomlag mellom utviklingsmiljøet vårt og det som sendes til nettleseren. Webpack samler koden vi skriver eller «bundler» den til en eller færre filer som sendes til nettleseren. Ved å ta i bruk det som kalles «loaders» vil den kunne oversette filene vi har skrevet til standard javascript som da kan leses direkte av nettleseren. Loaders gjør Webpack til et mye kraftigere verktøy. Den viktigste funksjonen våre loadere utfører er øversettelsen av react og ecmascript kode til vanlig javascript som kan leses av nettlesere. I tillegg til dette bruker vi 126

127 loadere til å gjøre mindre, men tidsbesparende ting under denne oversettelsen. Et eksempel på dette er hvordan våre loadere auto-prefixer all CSS koden vår slik at den er tilpasset de ulike nettleserne. Når man konfigurerer webpack må man spesifisere hvor webpack skal starte å samle filer, et såkalt «entry point», og «output» som er hvor de kombinerte filene skal skrives ut. Nedenfor i kodeeksempel 3.4 og 3.5 ser vi hvordan dette gjøres. Vi trenger kun å referere til index filen ettersom webpack automatisk bundler alle filene som er importert til filen, som da er resten av løsningen. I kodeeksempel 3.5 ser vi at vår konfigurasjon bundler filene til en javascript fil kalt «app.js». entry: [ "webpack-dev-server/client? "webpack/hot/only-dev-server", "./src/index" ] Kodeeksempel 3.4 Entry points I webpack konfigurasjon output: { path: path.join( dirname, "dist"), publicpath: "/", filename: "app.js" } Kodeeksempel 3.5 Output i webpack konfiguarsjon Videre deler vi opp webpack i to miljøer. Vi har laget en konfigurasjonsfil for utviklingsmiljøet og et for produksjonsmiljøet. Grunnen til dette er at det er ulike plugins som er praktiske for de ulike situasjonene. For eksempel så er det greit å minifisere javascript koden når man produserer løsningen, men for utviklere vil man helst at javascript koden skal være forståelig. Kodeeksempel 3.4 og 3.5 viser konfigurasjonen for utvikling serveren. Ved å benytte oss av utviklings server har vi muligheten til å gi oss selv et par ekstra funksjonaliteter under utviklingen. Den mest hjelpsomme av disse er hvordan vi har konfigurert utviklingsserveren til å utføre det som heter «live reload» som går ut på at siden lastes inn på nytt hver gang vi endrer koden, slik at vi øyeblikkelig kan se hvilken effekt endringer har på applikasjonen. Data I denne seksjonen går vi gjennom hvordan data benyttes i applikasjonen vår. Dette inkluderer hvordan data lagres, overføres og håndteres. Vi starter med å gå gjennom den viktigste delen av en chatløsning, nettopp hvordan data overføres. Videre går vi gjennom hvordan data bevares i React for å til slutt se på databasene vi benytter oss av. 127

128 3.2.1 Dataoverføring i SignalR Den viktigste delen av vår applikasjon er overføring av data, hovedsakelig i form av meldinger, mellom kunder og ansatte. Vi har gjort dette ved å benytte oss av teknologien kalt SignalR, og det er denne vi skal forklare i denne seksjonen. SignalR er et bibliotek som gjør det mulig å skape toveiskommunikasjon mellom klient og server. For å gjøre dette benytter den seg av den relativt nye kommunikasjonsprotokollen websockets, men faller også tilbake på andre protokoller hvis nettleseren ikke støtter teknologien. Websockets har introdusert en langvarig TCP socket tilkobling som støtter toveiskommunikasjon mellom klient og server. Dataen SignalR sender, sendes i Javascript Objekt Notation(JSON) format. Når man kaller en funksjon hos enten server eller klient vil dataen som sendes med metode kallet automatisk konverteres til et JSON objekt. På server siden er man avhengig at det finnes et tilsvarende objekt som JSON objektet kan konverteres til, mens i javascript er det mulig å bruke JSON objekter direkte. SignalR benytter seg av en «hub» for å kommunisere med klienten. Hub er en klasse som består av funksjoner som både kan kalle på funksjoner hos klienten og kan selv kalles på av klienten. Før vi går inn på huben selv må vi forklare hvordan tilkoblingene mot SignalR bevares i vår løsning. Vi har laget en kø som håndterer ansatte og kunder som er koblet til løsningen. Denne køen eksisterer i sin egen klasse kalt «ClientAssistantConnectionController». I denne har vi laget to dictionaries, en for kunder og en for ansatte. Dictionaries består av nøkkel-verdi par og nedenfor ser vi hvordan assistentkøen deklareres. private readonly ConcurrentDictionary<string, Assistant> _assistantlist = new ConcurrentDictionary<string, Assistant>(); Enhver tilkobling mot SignalR får sin egen ConnectionID som kan hentes når en tilkobling kommuniserer med serveren. En bruker kan fra samme nettleser ha flere tilkoblinger mot SignalR og vi kan derfor ikke bruke denne Iden til å identifisere brukeren, men den må bevares for å kunne kommunisere gjennom tilkoblingen. Derfor lager vi en Cookie med en GUID som er unik for hver bruker. Cookien deles over hele nettleseren slik at alle tilkoblinger brukeren åpner i en og samme nettleser vil dele denne. I køen lages så en SignalR gruppe på denne måten: Groups.Add(Context.ConnectionId, clientviewsessionid); Gruppen bruker Iden i cookien som gruppeid og hvis gruppen allerede eksisterer blir tilkoblingen automatisk lagt til i denne, ellers lages en ny gruppe. Ettersom alle tilkoblingene deler Iden vil alle tilkoblingenes ConnectionsID legges i en og samme gruppe. Dermed vil man kunne sende meldingene til alle brukerens tilkoblinger. 128

129 Kunde køen holder oversikt over de ventende kundene og en rekke funksjoner er laget for å interagere med køen. Nedenfor i kodeeksempel 3.6 viser vi et eksempel på en av disse funksjonene, nemlig en funksjon for å øke antall tilkoblinger en kunde har til serveren. public void IncremenetClientConnections(string clientviewsessionid) { Client Client; if(trygetclientfromassistantlists(clientviewsessionid, out Client)) { Client.ConnectionsCounter++; return; } lock(_clientqueue) { Client = (Client)_clientQueue[clientViewSessionId]; Client.ConnectionsCounter++; } } Kodeeksempel 3.6 Viser hvordan funksjoner som interagerer med kunde køen ser ut Det er viktig å legge merke til hvordan vi låser køen når vi aksesserer denne. Dette gjøres for å unngå feil som kan oppstå om flere prøver å aksessere køen på samme tidspunkt. Låsing av køen innebærer at køen ikke kan aksesseres av andre mens den er låst. Ansatt køen holder oversikt over alle de ansatte i systemet, og hos de ansatte lagres den nødvendige dataen for å blant annet holde oversikt over hvilke kunder den ansatte er i kommunikasjon med. Når en ny samtale starter hentes en kunde ut fra kunde køen og den ansatte blir lagt til i SignalR gruppen som tilhører kunden. Hvilken gruppe dette er lagres også hos den ansatte og dermed vil den ansatte være tilkoblet alle kundens faner Web API SignalR egner seg ikke for all funksjonalitet vi har ønsket å implementere. I vår løsning er det autentisering av brukere, filoverføring og datauthenting som har krevd en annen løsning, og for disse har vi laget et Web API. For å benytte oss av APIene fra klient siden benytter vi oss av Axios, et «promise» basert API som håndterer http forespørsler. «Promises» gjør det mulig å sende med funksjoner til et metodekall og eksisterer i tre tilstander; Pending: Venter på å bli utført. Fulfilled: Metoden var vellykket og suksess funksjonen utføres. 129

130 Rejected: Metoden feilet og feil funksjonen utføres. Hvis promiset blir satt som Fulfilled vil funksjonen som sendes med utføres, hvis ikke vil promiset bli satt som rejected og du kan da fange opp feilen. I kodeeksempel 3.7 ser vi hvordan vi bruker axios kallet til å sende en post http request til APIet, og hvis kallet utføres kjøres funksjonen som står i «then», mens hvis kallet feiler så fanges feilen opp i catch funksjonen. getipgeo(ipaddress, success, fail) { axios({ method: 'get', url: ' }).then((res) => { if(res.status === 200) { success(res.data); } }).catch((err) =>{ fail(err); });; } Kodeeksempel 3.7 Et axios kall For at axios kallene skal finne fram til riktig metode i APIet bruker vi såkalt «routing». Routing innebærer at APIet kobler en URI til et av APIets funksjoner. APIet setter først en URI på seg selv ved bruk av et routeprefix attributt som dette: [RoutePrefix("api/File")]. RoutePrefix vil da sette det som skal skrives etter domenenavnet i URIet. For metodene i APIet setter man et «routing» attributt som igjen indikerer hva som skal skrives etter RoutePrefix delen av URIen. Eksempel på et route attributt er: «[Route("UploadFile")]». For å kalle på funksjonen UploadFile inne i FileController på «domene.test» vil man da benytte seg av følgende uri: «' Når det gjelder autentisering av API kall er kontrollerne i web apiet markert med et [Authorize] attributt. Dette betyr at for å få tilgang til controlleren må du være autorisert av løsningen. Dette sjekkes ved at det ses etter et token i http headeren som sendes med http forespørselen. Hvis det er noen metoder inne i kontrolleren som du vil at uautoriserte brukere skal ha tilgang til så gir man disse metodene attributtet [AllowAnonymous] som da vil godta forespørsler fra anonyme brukere. Som nevnt tidligere bruker vi API til å utføre filoverføringer. I figur 3.8 nedenfor vises en forenkling av hvordan filoverføring fungerer i vår løsning. Dette gjøres ved at vi deler en fil i mindre biter og setter disse inn i en array. Når dette er gjort itereres det så gjennom denne arrayen, og filen sendes «del for del». Løsningen vil så benytte 130

131 seg av tidligere nevnte axios kall for å laste opp hver individuelle filbit til serveren. Når serveren mottar en bit av filen vil det først gjøres en sjekk på om filen eksisterer fra før, og hvis dette er tilfellet vil den eksisterende filen slettes. Filbiten vil så lagres før det gjøres en sjekk på om filen er ferdig lastet opp, hvis hele filen er ferdig lastet opp så slås alle filbitene sammen til en hel fil. Henter filen fra klient Filen deles i biter En bit av filen sendes av gangen Sender bit Server mottar filbit og lagrer denne Server sjekker om alle biter er mottatt ved hver ny bit Filen settes sammen på server siden når testen bekrefter at alle biter er mottatt Figur 3.8 Viser en simplifisert forklaring av hvordan filoverføring fungerer i vår løsning Data i React med MobX I vår løsning bevares data i React i et av to steder. Alle komponenter i React har det som kalles State. I state kan man lagre ulike variabler og da endre disse når brukeren gjør noe eller når informasjon kommer fra server eller SignalR i vårt tilfelle. Når noe endres i state så vil React automatisk rendre komponenten, og bare den spesifikke komponenten, på nytt. Den andre måten vi lagrer data er det som kalles Store i MobX. MobX er et bibliotek som håndterer dataflyt. Her lagrer man da data i disse storene, og man kan da lytte på objekter i ulike komponenter. Når noe oppdateres i en store så vil MobX be alle komponenter som lytter på den om å oppdatere seg. Disse storene kan da deles mellom alle komponentene, i motsetning til state som kun vil eksistere i sitt eget komponent og de man selv sender den til. I figur 3.9 viser vi en forenklet versjon av 131

132 en av disse storene. Øverst ser vi det som kalles observables. En observable er objekter som kan lyttes på av komponenter som benytter seg av denne storen. import {map, observable, action, usestrict} from 'mobx'; import 'expose?jquery!jquery'; import '../js/jquery.signalr min.js'; import chathub from '../services/signalr/chathub'; usestrict(true); class ChatStore conversation = chatactive = footer = = true; sendmelding(messagetext){ var message = { MessageText: messagetext } this.chathub.invoke('send', message); } endchat(rating, , adress){ var data = { Rating: rating, Send , Address: adress } this.chathub.invoke('clientendschat', data); } } const chatstore = new ChatStore(); export default chatstore; Kodeeksempel 3.9 Viser en forenklet versjon av en React Store For å ta i bruk en store i en annen komponent må komponentet benytte seg av «@observer» dekoratøren. Denne setter render metoden i react komponenten inn i mobx sin funksjon «autorun» som da vil rendre komponenten på nytt hvis den observerte verdien endres. Et slikt komponent vises i kodeeksempel

133 import React from 'react'; import LeftChatMessage from './components/leftchatmessage/leftchatmessage'; import RightChatMessage from './components/rightchatmessage/rightchatmessage'; import EndingMessage from './components/endingmessage/endingmessage'; import {observer} from export default class ChatMessages extends React.Component{ //Krever en chatstore static contexttypes = { stores: React.PropTypes.object.isRequired }; //Henter chatstore for bruk constructor(props, context){ super(props, context); this.chatstore = this.context.stores.chat; } } render(){ return( <div> //Går gjennom denne typen kode i et senere punkt </div> ) } Kodeeksempel 3.10 Viser hvordan en klasse som skal benytte seg av en store ser ut Databaser Vår løsning benytter seg av to ulike databaser. Den første av disse er den som brukes i forbindelse med Microsoft Identity. Vi skal forklare denne teknologien i mer detalj senere, men det denne databasen oppbevarer er data for registrerte brukere samt deres rettigheter og rolle. Selve databasen lages automatisk av Visual Studio, det vi gjør er å registrere brukere opp mot denne samt hente brukere fra den for å sjekke hvilke tilganger de har. Den andre databasen vår er den vi selv har laget for å bevare relevant informasjon for vår løsning. For å lage databasen benytter vi oss av entity framework med code first. Det code first betyr er at man lager databasen ut ifra kode man skriver. Denne databasen vil da basere seg på klasser man har laget i koden. Ved å bruke dette var 133

134 det langt enklere for oss å kunne begynne å kode i starten uten å måtte strukturere databasen først, ettersom databasen ville være basert på vår kode isteden. Ved å bruke code first vil også databasen automatisk genereres om den ikke eksisterer fra før. Figur 3.11 under viser en ER-modell av vår database. Figur 3.11 ER-modell av vår database Back-End I introduksjonen av denne seksjonen gikk vi grovt over strukturen til løsningen vår. Som nevnt er løsningen delt opp i seks deler, hvorav to av disse utgjør «view» delen som er vanlig i lagdeling. Grunnen til dette er at det var nødvendig å separere delen som chatassistentene skal arbeide i, fra delen kunder skal benytte seg av. De resterende fire delene er DAL, BLL, Model og API API APIet vårt er det laget hvor mesteparten av funksjonaliteten ligger. Dette er laget som kommuniserer med klient sidene av chatten. Laget henter og sender data fra 134

135 både klientene og databasene. API laget vårt er i all hovedsak delt inn i to ulike deler, nemlig SignalR delen og Web API kontrollere. Kontrollere behandler http forespørsler mot serveren og utfører ulike funksjoner basert på disse. Vi har tre kontrollere i vår løsning som tar for seg hver sin del av funksjonaliteten. Disse tre er som følger: en for autentisering, en for chatdata og en for filoverføring. Alle kontrollerne er beskyttet av vår autentisering løsning som vi kommer tilbake til i seksjon 3.4. Dette betyr at kun brukere med den autentiseringen som er nødvendig kan kalle på funksjonene. Under i kodeeksempel 3.11 ser vi et eksempel på en gjennomsnittlig funksjon i en kontroller. [Route("getSettings")] [Authorize(Roles = "Admin, Assistant")] public IHttpActionResult getsettings(string username) { Settings settings; if (username!= "undefined") settings = _chatbll.getsettings(username); else settings = _chatbll.getsettings(); if (settings!= null) return Ok(settings); } else return NotFound(); Kodeeksempel 4.11 En metode i kontrollerne i API laget Vi ser her at øverst gis ruten til denne funksjonen, som bestemmer URIen som skal brukes for å kalle på funksjonen. Videre bruker vi identity til å autentisere brukeren, og kun brukere med roller som admin og assistent har tillatelse til å kalle funksjonen. Parameteret som skal sendes med kan være et objekt, og disse sendes da som JSON objekter fra front-end siden av løsningen. JSON objektene vil automatisk konverteres til tilsvarende objekter på serveren, og om dette ikke eksisterer vil en error oppstå. Den siste delen inne i metoden går ut på feilhåndtering. I dette eksempelet vil det om «settings» variabelen ikke står tom utføres et av.net sine API funksjoner for å returnere en http status kode av 200 som indikerer at alt gikk som det skulle. Hvis ikke bruker vi igjen.net sine egne funksjoner for å returnere en 404 status kode som indikerer at det som letes etter ikke er funnet. Kontrollerne brukes hovedsakelig til funksjoner som har med annet enn selve kommunikasjonen mellom en ansatt og en kunde å gjøre. For denne kommunikasjonen, selve kjernen i chatten vår, bruker vi SignalR. Vi har allerede gått gjennom hvordan SignalR fungerer i vår løsning i seksjon

136 3.3.2 DAL DAL som står for «Data Access Layer» er laget som kommuniserer direkte med databasen. Ved å bruke dette laget vil man slippe å spre database kall utover hele løsningen, samt at oppdateringer av databasen vil være langt enklere å gjøre når all kode som relaterer til denne finnes i et sted. Som nevnt vil DAL være det eneste laget som er i direkte kommunikasjon med databasen, og det er derfor slik at man konverterer data man får ut av databasen til objekter som kan brukes i resten av løsningen her. Slik får man langt færre konverteringer ettersom alt vil gjøres et sted. Under i kodeeksempel 3.12 ser vi hvordan et slikt databasekall er gjort. public Model.Admin getadmin(string username) { using (var db = new ChatDbContext()) { Model.Admin admin = db.admins.where(a => a.username == username).select(a => new Model.Admin { Username = a.username, OrganisationId = a.organisationid, SettingsId = a.settingsid }).Single(); } } return admin; Kode eksempel 3.12 Et databasekall i DAL. Man starter med å koble seg opp mot databasen. Videre så gjør man et direkte kall mot tabellen i databasen og samtidig konverterer dataen man får til et objekt som hentes fra «Model» laget i løsningen. Ved å bruke modeller sikrer man at hele løsningen bruker de samme type objekter. Prosessen er litt annerledes for å legge inn data i databasen. For å gjøre dette har vi laget egne databasemodeller som representerer et objekt slik det vil se ut i databasen. Grunnen til dette er at mange av variablene i Models laget benyttes kun når objektet er i bruk og er ikke nødvendige å lagre i databasen. Dermed har vi egne modeller med kun den relevante dataen. Kodeeksempel 3.13 viser ulikhetene mellom databasemodell og den generelle modellen. All informasjon som er utelatt i databasemodellen er informasjon som kun er nødvendig for den direkte bruken av objektet, men som ikke er relevant som data. 136

137 Model laget: public class SavedAnswer { public Guid SavedAnwerId { get; set; } public string Question { get; set; } public string Answer { get; set; } public DateTime DateTimeAdded { get; set; } } Database modell: public class SavedAnswer { [Key] public Guid SavedAnswerId { get; set; } public string Question { get; set; } public string Answer { get; set; } public DateTime DateTimeAdded { get; set; } } Kodeeksempel 3.13 Sammenligner modell i databaselaget og model lag metodeeksempel Under i kodeeksempel 3.14 ser vi et eksempel av hvordan vi setter inn data i databasen, og her ser vi også at objektet må konverteres til et databaseobjekt før det legges inn. Å legge inn objektet i databasen gjøres i en try-catch for å kunne bekrefte om objektet ble lagt inn eller ikke. 137

138 public bool addadmin(model.admin admin) { using (var db = new ChatDbContext()) { Admin newadmin = new Admin { Username = admin.username, OrganisationId = admin.organisationid, SettingsId = admin.settingsid }; } } try { db.admins.add(newadmin); db.savechanges(); return true; } catch(exception e) { return false; } Kodeeksempel 3.14 Viser hvordan data legges inn i databasen BLL BLL, også kjent som «Business Logic Layer», er et lag hvor all kommunikasjonen mot DAL må gå gjennom. I dette laget skrives såkalte «Business Rules», regler som for eksempel kan kreve at visse krav er oppfylt for at du skal ha tillatelse til å utføre databasekall. Et eksempel kan være at en bedrift ønsker at en bruker ikke skal kunne endre på brukere med en høyere jobb posisjon enn dem selv. Vi har implementert BLL ettersom under videreutvikling så er det stor sannsynlighet for at slike «business rules» er nødvendige å implementere, men i vårt tilfelle gjør BLL svært lite, og er kun et mellomledd mellom DAL og alle andre lag i løsningen Model Model laget inneholder modeller for alle objektene som brukes i løsningen vår. Dette for å forsikre seg om at de samme objektene blir brukt overalt, slik at man ikke ender opp med inkompatible objekter som vil tvinge unødvendige konvertering som igjen vil være med på å svekke effektiviteten til løsningen vår. Det er også langt enklere å holde oversikt over objekter som eksisterer i løsningen vår om disse er samlet på et sted i motsetning til å ha de spredt rundt om i vår løsning. I tillegg til dette er det nødvendig å ha disse objektene for at APIet og SignalR skal kunne 138

139 konvertere JSON objekter. Et JSON objekt kan kun automatisk konverteres om det finnes et tilsvarende objekt i serveren, og disse ligger da i model laget. Under i kodeeksempel 3.15 vises et eksempel på hvordan et JSON objekt må matche serverens modell. JSON objekt: [ { "SavedAnswerID": "", "Question": "", "Answer": "", "DateTimeAdded": "" } ] Klasse modell: public class SavedAnswer { public Guid SavedAnswerId { get; set; } public string Question { get; set; } public string Answer { get; set; } public DateTime DateTimeAdded { get; set; } } Kodeeksempel 3.15 Et JSON objekt med sin server motpart View Vi har to view lag, et for kunde og en for de ansatte. Disse har en tilhørende backend del i form av hver sin kontroller. Denne kontrolleren gjør ikke mye, ettersom det meste av funksjonaliteten til viewene er integrert i front-end koden, men det den gjør er å lage en cookie med en GUID som identifiserer nettleseren som bruker løsningen. Denne brukes så for å kjenne igjen den spesifikke brukeren i løsningen vår. Resten av koden kommer vi tilbake til i seksjonen om front-end. Autentisering Det er selvsagt viktig å sikre en løsning slik vi lager. Å ha uønskede brukere benytte seg av de ansattes side av chatten kunne resultert i en rekke problemer, og det er derfor viktig å ta hensyn til dette. I denne seksjonen skal vi gå gjennom hvordan autentisering fungerer i vår applikasjon Identity Identity er Microsoft sin egen løsning for å håndtere brukere. De har sett på den tidligere brukte membership løsningen og tatt med seg tilbakemeldingene for denne 139

140 da de utviklet Identity. Identity ble utviklet med mål om å støtte alle ASP.Net rammeverkene samt at den skulle fungere med både mobile og web løsninger. Identity benytter seg av roller for å skille mellom de ulike rettighetene til ulike brukere. Disse rollene lager man selv, og de vi har laget er da en rolle for admin og en for assistent. Assistent vil da være de som arbeider i kundeservice. Man kan da i applikasjonen gjøre en sjekk på rollen til klienten som prøver å kjøre en funksjon, og man kan også begrense hvem som har lov til å kjøre ulike funksjoner. For å kunne benytte oss av Identity har vi laget en kontroller som inneholder bruker relaterte funksjoner. I kodeeksempel 3.16 kan vi se hvordan en av de mindre funksjonene i kontrolleren ser ut, nemlig funksjonen for å logge ut. Den første linjen viser hvordan vi kan blokkere funksjoner for andre roller enn de vi ønsker. I dette tilfellet ønsker vi at kun brukere som er logget inn som en admin eller assistent skal kunne bruke logg ut funksjonen. [Authorize(Roles = "Admin, Assistant")] [Route("Logout")] public IHttpActionResult Logout() { Authentication.SignOut(CookieAuthenticationDefaults.AuthenticationType); return Ok(); } Kodeeksempel 3.16 En metode fra kontrolleren som brukes for brukere. \ Front-End Front-end delen av applikasjonen har vært et spennende arbeid. Vi har fått lov til å benytte oss av de nyeste teknologier som er svært relevante på arbeidsmarkedet i dag og dette har vært en spennende utfordring. I denne seksjonen vil vi gå over hvordan vårt front-end er satt opp Struktur For et prosjekt av denne størrelsen er det viktig å ha en god struktur, spesielt grunnet at det er flere mennesker som sammen skal jobbe på løsningen. Vi i gruppen satte oss sammen for å finne en struktur som ville fungere for oss. Vi bestemte oss for å dele løsningen i en mappe for felles komponenter som ville bli tatt i bruk flere steder i løsningen. Eksempler på slike komponenter er for eksempel komponentet vi bruker for knapper. Videre så ønsket vi å ha en mappe for det vi valgte å kalle «konteinere». En konteiner er da et React komponent som inneholder flere komponenter, slik som for eksempel chat siden av løsningen. Konteinere legges til i løsningen ved å importere dem med følgende setning; 140

141 import AddSavedAnswer from './containers/addsavedanswer/index'; og settes inn i render metoden i React med følgende linje: {AddSavedAnswer}. Dette gjør det hele svært utbyttbart, og med den sass koden vi har brukt vil hele siden automatisk justere seg om en komponent fjernes eller legges til. Den neste mappen vi lagde er for de vi kaller «services». Dette er mappen for kommunikasjonslagene mot serveren. Dette inkluderer to typer filer. Det ene er API filene og det er disse som kommuniserer med APIet på server siden. Disse benytter seg av http forespørsler gjennom tidligere nevnte axios for å kommunisere med Web APIet. Den neste typens service vi har er SignalR delen. Denne filen brukes til å koble løsningen opp mot SignalR. Her har vi også laget en funksjon som binder metoder som eksisterer i front-end opp mot SignalR slik at disse kan kalles fra serveren. Funksjonen kan du se i kodeeksempel VI har også en funksjon som brukes for å kalle på metoder som ligger i SignalR huben på serveren og denne funksjonen vises i kodeeksempel bindmethodtosignalr(chathubmethodname, methodname){ this.chathubproxy.on(chathubmethodname,(param) => {methodname(param)}); } Kodeeksempel 3.17 Viser funksjonen vi har laget for å binde funksjoner i front-end opp mot SignalR. invoke(method, data = false){ if(data) { this.chathubproxy.invoke(method, data); } else { this.chathubproxy.invoke(method); } } Kodeeksemmpel 3.18 Funksjonen som brukes for å kalle på metoder i huben på serveren Til slutt har vi en mappe for lagring av data i stores som gjøres av mobx. Disse storene inneholder da data som komponenter kan observere og dermed vil komponentene reagere på endringer. Vi har gått gjennom MobX i mer detalj i seksjon Vi visste allerede da vi begynte at konteiner mappen kom til å bli den mest kompliserte av disse. De andre ville fungere med kun et nivå, men det ville ikke kontaineren ettersom en konteiner vil inneholder mange underkomponenter. Det var derfor nødvendig å danne en struktur for de indre filene i denne mappen. En konteiner har sin egen jsx fil hvor react koden skrives. Med denne er det en tilhørende scss fil, hvor vi stilsetter react koden. Begge disse importerer sine 141

142 underkomponenter slik at de tilslutt havner i det øverste laget. En komponent kan også inneholde en komponent mappe hvor den oppbevarer alle sine underkomponenter, hvor da disse igjen er strukturert på samme måte React komponenter Vi har utviklet front-end delen av løsningen vår ved å ta i bruk React.js. React er facebook sitt egenutviklede javascriptrammeverk, og i motsetning til andre javascriptrammeverk bringer React kun et view lag. React benytter seg av komponenter for å forme nettsiden. Under i figur 3.19 har vi laget et eksempel komponent for å lettere forklare hvordan disse er strukturert. Øverst har vi et par import setninger som importerer «Component» klassen fra React som er nødvendig for at vi skal kunne lage vår egen komponent og «HentetKomponent» som er en komponent vi selv har laget. Komponenter vi lager i React kan da brukes overalt i løsningene vår, som gjør det enkelt å gjenbruke kode. Videre har vi en konstruktør som kjører med en gang komponentet blir tatt i bruk. Props parametere er data som sendes fra forelder til barnekomponent, og kan da inneholde enten funksjoner eller data. Videre så lager vi det som kalles state. State inneholder data som kan brukes gjennom hele komponentet, og kan i motsetning til props endres av komponentet selv. Når state endres så oppdateres også komponentet i nettleseren. Etter å ha satt variabler i staten til komponentet binder vi funksjonene som i vårt tilfelle kun er funksjonen «funksjon» til selve komponentet. Grunnen til at React gjør det slik er at det er mulig å motta funksjoner fra for eksempel forelder komponenter, og i disse tilfellene så er disse funksjonene fortsatt bundet til foreldrene. Hvis alle funksjoner automatisk ble bundet til komponentet som tok det i bruk ville ikke dette vært mulig. Etter konstruktøren så har vi en funksjon. Denne illustrerer hvordan state og props kan brukes i løsningen. Som man ser kan man både lese og endre på state, og endringer gjøres ved å bruke metoden setstate. Her skriver man inn objektet man ønsker å endre samt verdien man ønsker å gi denne. Props kan også leses i React, men kan da ikke endres på. Til slutt er selve resultatet av hele React komponentet. Render metoden setter opp hva som skal vises når komponentet blir tatt i bruk. Alt som returneres er nødt til å være inne i en hoved div, selv om man kan lage flere diver inne i denne. Man kan også her sette inn komponenter som man har laget andre steder i løsningen, slik det har blitt gjort her med «HentetKomponent». Disse komponentene blir da barnekomponentene, og man kan sende med data eller funksjoner til denne. Disse 142

143 kan da aksesseres gjennom props i barnekomponentet, og når disse endres hos forelder vil de også endres hos barnet. import React, { Component } from 'react'; import HentetKomponent from './mappe/komponent.jsx'; export default class Eksempel extends React.Component{ constructor(props){ super(props); } this.state = { verdi1: true, verdi2: '', verdi3: 1, objekt1: { Fornavn: 'Adam', Alder: 22 } } this.funksjon = this.funksjon.bind(this); funksjon(){ if(this.state.verdi1){ this.setstate({verdi2: 'verdi1 var sann'}); } else{ this.setstate({verdi3: 'verdi1 var usann'}); } } if(this.props.verdisentfraforelder) { this.setstate({verdi3: 1}); } } render(){ return( <div classname="testkomponent"> <div classname="eksempeldiv"> <h1>overskrift</h1> <HentetKomponent verditilbarn={this.state.verdi2}/> </div> </div> ); } Kodeeksempel 3.19 Viser et eksempel komponent i React 143

144 3.5.3 React Router For å kunne vise flere ulike sider i React bruker vi det som kalles React router. React routing bestemmer hva som skal vises for brukeren basert på URLen. React router ser på hva som står etter domenenavnet i URLen. Basert på denne verdien bruker den et egenkonstruert «Router» komponent. Under i kodeeksempel 3.20 ser vi hvordan vår komponent ser ut. Router komponentet vil da etter å ha sett på URLen finne det tilsvarende komponentet og vise dette. <Route path='/' component={app}> <IndexRoute onenter={authrequired} component={chat}/> <Route path="login" component={login} /> <Route path="sanntid" component={realtime} /> <Route path="ko" component={queue} /> <Route path="legg-til-svar" component={addsavedanswer} /> <Route path="registrerassistent" component={registerassistant} /> <Route path="registrerbedrift" component={registercompany} /> <Route path="innstillinger" component={settings} /> </Route> Kodeeksempel 3.20 Router komponentet I vår løsning Sass For å kunne endre utseendet til applikasjonen vår har vi brukt CSS gjennom Sass. Sass er en «CSS Preprocessor», et skript språk som benytter seg av CSS. Sass kompilerer da skript språket til vanlig CSS som da støttes av vanlige nettlesere. Sass gir oss mulighet til å separere stilsetting vår i flere mindre filer, som da settes sammen til en større fil under kjøring som gjør det mindre krevende for klienten. Den lar oss også deklarere variabler som kan brukes gjennom hele prosjektet. Under ser vi et eksempel på en Sass fil. Sass lar oss gjøre det som kalles «nesting», som betyr at man setter stilen for ulike diver inne i hverandre, på samme måtene som diver er satt opp i html dokumentet. Dette er langt mer strukturert og gir en enklere oversikt over hvilken kode som endrer hva. Ettersom dette samsvarer med html koden blir det også lettere å finne fram til den riktige koden. Man kan også importere kode fra andre Sass filer, som er nødvendig med vår komponent struktur med i React, ettersom når man importerer et React komponent blir det også nødvendig å importere stilsettingen. 144

145 @import './components/clientqueue/clientqueue';.ytterstediv{ height:100%; display:flex; background-color: #394959;.innerDiv1{ display:flex; flex-flow:column; height:100%; background-color:#495c70; } }.innermostdiv1{ font-size:1.5em; background-color:#394959; text-transform: uppercase; box-sizing: border-box; padding:1.24em; color:white; } Kodeeksempel 3.21 En Sass fil Mobil tilpasning For å få siden til å fungere på mobiltelefoner tar vi i bruk det som kalles media queries. Ved å ta i bruk disse kan vi endre på utseendet til våre komponenter basert på størrelsen på skjermen som benytter seg av siden. Dette innebærer også å kunne fjerne eller legge til ting for mobiltelefoner. Under vises et eksempel på hvordan media queries brukes i løsningen vår. Her bruker vi media queries til å fjerne noe som er laget spesifikt for mobiltelefoner hvis skjermen er større enn en only screen and (min-width: $mobile_display) { display: none; } Kodeeksempel 3.22 en media query I koden vår 145

146 Enhetstesting For å teste løsningen vår underveis i arbeidet har vi benyttet oss av enhetstesting. Enhetstesting går ut på å dele løsningen i så små deler som er mulige å teste. Som regel går dette ut på å teste individuelle funksjoner i løsningen Moq & Nunit For å kunne unit teste server koden vår har vi benyttet oss av to NuGet pakker for.net. Den første og største av disse er Nunit. Dette er et testrammeverk for.net applikasjoner og gir oss muligheten til å kjøre tester samt bekrefte om de feiler eller lykkes. Videre benytter vi oss av pakken kalt Moq. Moq gir oss muligheten til å lage Mock objekter. Vi bruker Mock objekter for å erstatte komplekse objekter under testing. Et Mock tar imot et interface og returnerer et objekt som kan bygges opp basert på det tidligere nevnte interfacet. Dette gjøres ved å definere returverdien til de funksjonene som eksisterer i interfacet. Under i kodeeksempel 3.23 ser vi et eksempel på hvordan et objekt mockes. Her ser vi at vi lager et mock objekt og sender med interfacet «HubCallerContext». Videre bygger vi opp mock objektet ved å definere hva som skal returneres av de disse. Til slutt henter man ut det ferdige objektet som da brukes til å etterligne våre komplekse objekter. var mockhubcallercontext = new Mock<HubCallerContext>(); mockhubcallercontext.setup(m => m.querystring["admin"]).returns("1"); mockhubcallercontext.setup(s => s.user.identity.name).returns("ad@ad.com"); testobject = mockhubcallercontext.object; Kodeeksempel 3.23 Hvordan et Mock object lages Vi benytter oss også av dynamiske objekter i løsningen. Disse bruker vi for å erstatte objekter som eksisterer inne i de komplekse objektene våre som Mocks skal erstatte. Vi kan selv definere hva metodene inne i disse objektene skal utføre slik at vi i test metoden kan se om disse har blitt kjørt. Øverst i klassen har vi boolean variabler som starter som false, og når metodene inne i de dynamiske objektene blir kalt endrer metodene verdien til true. Boolean verdiene gjør vi så en sjekk på ved slutten av metoden for å bekrefte at alt har kjørt som det skulle. dynamic all = new ExpandoObject(); all.assistantsdataupdated = new Action<ConcurrentDictionary<string, Assistant>>((assistants) => { assistantsdataupdatedcalled = true; }); Kodeeksempel 3.24 Viser et dynamisk objekt hvor vi representerer et metodekall ved å endre en boolean for å bekrefte at metoden kjørte. For å enhetsteste løsningen benytter vi oss også av dependency injection. Dette betyr at om en klasse er avhengig av en annen klasse for å fungere så kan man 146

147 skape avhengighetene i konstruktøren slik at man under testing kan sende med en egen konstruert versjon av denne avhengigheten. I vårt tilfelle så mocker vi klassen og sender den til klassen som skal testes. Vi benytter oss av AAA syntaks for å teste løsningen vår. Dette er en struktur for test metodene og står for «Arrange, Act, Assert». Først setter vi opp alt metoden er avhengig av, altså alle mocker og annen relevant data først. Når all testdata er konstruert kjører man metoden som skal testes, dette er «Act» delen. Til slutt har vi Assert steget hvor vi sjekker at boolean verdiene vi har nevnt tidligere har blitt endret, som bekrefter at de metodene som skal kjøres har kjørt. Dette gjøres med Nunit sine Assert funksjoner. Under viser vi et eksempel for hvordan vi bruker Nunit for å teste om variablene har blitt endret riktig Jest Assert.IsTrue(sendMessageCalled); Assert.IsNotNull(receivedMessage); For å teste front-end siden av applikasjonen vår bruker vi testrammeverket Jest. Jest er et testrammeverk laget for javascript og er enkel å ta i bruk. Nedenfor viser vi et kodeeksempel fra vår løsning hvor vi tester en funksjon. Describe forklarer hva det er som skal testes. Det som følger etter dette er «it» hvor vi kjører metoden. Først beskriver man hva det er test resultatet indikerer. Etter dette kjøres funksjonen som skal teste og til slutt kjøres «expect» funksjoner for å se om testen utførte det den skulle. describe("chatstore", () => { it("status changed online", () => { const store = new ChatStore }) }) store.statuschanged(0) expect(store.currentstatus).tobe('pålogget') expect(store.currentstatuscolor).tobe('color-green') 147

148 Testdokumentasjon Chatnodes Bachelorprosjekt 2017 Gruppe

149 Forord I denne dokumentasjonen vil vi gå gjennom de ulike testene som ble utført. For å sikre seg at programmet man utvikler møter de kravene som er forventet er det ideelt å utføre testing. Programvaretesting gjennomføres med testdata hvor resultatene sjekkes for feil og kvalitet. Vedlagt ligger også en ordliste for denne rapporten [Vedlegg 5]. 149

150 Innholdsfortegnelse Forord Gjennomførte tester Brukertesting Brukertest av chatassistent siden Brukertest av kunde siden Kompatibilitetstesting Enhetstesting

151 1 Gjennomførte tester Brukertesting Brukertesting er en prosess som inkluderer at brukere benytter seg av applikasjonen. Vi har valgt å la ulike brukere ta i bruk applikasjonen, gitt dem ulike oppgaver og observert hvordan de har utført disse. En slik testmetode er svært effektiv for å avdekke områder som bør forbedres i applikasjonen og for å sikre seg om applikasjonen møter kravene om brukervennlighet (Sauro, 2015). Spørsmålene eller oppgavene man stiller under en slik undersøkelse bør helst ta utgangspunktet i de mest sentrale brukerkravene (Natoli, UX & Web Design Master Course: Strategy, Design, Development, 2016). For denne prosessen har vi valgt å forholde oss til en studie som går ut på hvorfor det er tilstrekkelig å kun teste med fem brukere. I følge studiet er det å teste med flere enn fem brukere bortkastet tid og ressurser. I studiet kom de frem til en formel som sier hvor mange problemer om brukervennlighet som oppstår som en funksjon av antall brukere som tester løsningen. Etter mange studier kom de frem til at andelen bruksproblemer som oppdages mens man tester en enkelt bruker er 31%. Når man tar utgangspunkt i dette vil formelen gi en graf hvor resultatene fra en enkelt bruker vil gi tilnærmet en tredjedel av hva det er å lære om hvor brukervennlig løsningen er. Når man så tester person nummer to oppdager man at denne personen vil gjøre noe av det samme som person nummer en. Konklusjonen deres var at desto flere brukere man tester desto mindre ny informasjon vil man kunne innhente. Grunnen for at de endte opp med akkurat fem brukere er at grafen begynner å flate ut ved dette tallet og man vil ikke kunne gjøre mange nye oppdagelser etter å ha testet med fem brukere. De nevner også at det finnes tilfeller hvor det er nødvendig å teste med flere brukere, men dette gjelder ikke i vårt tilfelle. (Sommerville, 2010). Vi delte denne prosessen opp i to deler hvor vi testet chatassistent siden separat fra siden for kunder. Vi ønsket å observere hvordan brukere vil interagere med programmet og hvordan de vil navigere seg gjennom de ulike funksjonalitetene. For chatassistent siden utformet vi tre hovedoppgaver som vi ga hver og én av brukerne før de startet. Deretter observerte vi hvordan de gjennomførte disse oppgavene og om det gikk raskt eller tregt. For klient siden av chatten ønsket vi å observere hvordan de vil benytte seg av chatten og hvordan de vil oppfatte de ulike funksjonalitetene. I denne seksjonen vil vi derfor gå dypere inn på hvordan disse testene ble gjennomført, hva resultatene var og hvordan vi valgte å tolke disse. 151

152 1.1.1 Brukertest av chatassistent siden Vi valgte å utføre denne brukertesten ved å sette opp tre oppgaver for brukeren. Grunnen for at vi utformet oppgaver på forhånd var at vi ikke fikk muligheten til å inkludere brukere med relevant kompetanse i testingen. Vi var i kontakt med kunder av Webnodes som var interesserte i en slik chat-løsning og fikk hentet inn mye nyttig informasjon om hva det er de ønsker av en slik løsning. Når det var forespørsel om de også var interessert i å delta på å teste løsningen var dette noe de ikke ønsket. Av den grunn tok vi hensyn til at de brukerne som kom til å teste denne siden av løsningen ikke har tidligere erfaring med å administrere en chat og vi ga dem derfor veiledning i form av oppgaver om hva som skulle utføres. I de følgende tabellene har vi satt opp de ulike oppgavene som vi ga til brukerne. Under utføringen gjorde vi ulike observasjoner av brukerne i henhold til oppgavens formål. Disse formålene og resultatene av observasjonene er beskrevet i tabellene under. Etter å ha samlet inn resultatene fra alle brukerne tolket vi disse og tok en vurdering på hvordan dette kan bidra til å øke brukervennligheten for løsningen vår. Oppgave 1 Formål Legg til en klient fra køen og spør hva du kan hjelpe dem med, finn svar på det de lurer på. Hensikten med denne oppgaven er å teste om det er tydelig nok beskrevet hva som må til for å starte en samtale med en klient når det ikke finnes noen samtaler i "mine samtaler" listen. Vi ønsker også å observere om de finner frem til "lagrede svar" og forstår hvordan dette kan brukes til å svare på spørsmål de nødvendigvis ikke vet svaret på. Resultat Bruker 1 Gikk fint uten problemer, tok ikke lang tid i det hele tatt Bruker 2 Bruker 3 Bruker 4 Bruker 5 Gikk uten problemer, skjønte øyeblikkelig hvordan Gikk uten problemer, bruker fant øyeblikkelig legg til knappen og skjønte at det var denne han skulle bruke Gikk fint uten problemer, beskrivelsen på knappen var forklarlig. Fant frem med en gang og utførte oppgaven raskt. Tolkning av resultat Av resultatene fra de ulike brukerne kan vi konkludere med at prosessen med å legge til en ny klient er overkommelig, da alle brukerne klarte å utføre oppgaven raskt og problemfritt. For denne oppgaven stemmer 152

153 teorien til Nielsen som sier «As you add more and more users, you learn less and less because you will keep seeing the same things again and again.» (Nielsen, 2000) siden vi ser at det er gjort relativt like observasjoner for alle brukerne. at det Tabell 1.2 Oppgave 1 for brukertest av chatassistent siden Oppgave 2 Sett påloggingsstatusen din til "borte" slik at du kan gå å ta en lunsjpause. Formål Formålet med denne oppgaven er å observere om brukeren får med seg at de må avslutte samtalen med klienten før de kan sette statusen sin til "borte" og gå å ta en lunsjpause. Dersom dette ikke er opplyst tydelig nok kan brukeren oppfatte dette som en feil fordi de ikke vil få endret statusen sin til "borte" og dermed ikke fullført oppgaven. Resultat Bruker 1 Gikk til innstilinger side først, skjønner ikke at han må avslutte samtale først. Etter litt mer tid fant han ut av det. Bruker 2 Bruker 3 Bruker 4 Bruker 5 Fikk det til uten problemer, leste notifikasjonen og skjønte hva som måtte gjøres Trodde først at å gå til en annen side var nok, når dette ikke fungerte så avsluttet han samtalen ved å trykke på knappen. Prøvde å bytte status til borte først. Leste notifikasjon, fant ut at samtalen måtte avsluttes først. Prøvde å bytte statusen til borte først. Leste notifikasjon og fant ut at samtalen måtte avsluttes først. Tolkning av resultat Av resultatene fra denne oppgaven ser vi at den første brukeren hadde litt problemer før han kom frem hvordan oppgaven skulle løses. Bruker nummer to hadde ingen problemer, bruker nummer tre brukte litt tid til å finne frem og bruker nummer fire og fem hadde relativt samme resultater. Som også Nielsen forklarer er dette en vanlig observasjon hvor man ser at bruker nummer tre gir litt ny tilleggsinformasjon men etter dette vil observasjonene av de neste brukerne variere lite (Nielsen, 2000). Med dette kan vi konkludere med at brukerne fikk utført oppgaven ved at de ble veiledet av teksten i notifikasjonen. Tabell 1.3 Oppgave 2 for brukertest av chatassistent siden 153

154 Oppgave 3 Formål Finn ut følgende informasjon: 1. Hva er påloggingsstatusen til "Anne Hansen" og hvor mange er hun i samtale med nå? 2. Hvor mange er det totalt som er pålogget? Hensikten med disse oppgavene er å teste om brukeren klarer å navigere seg frem til hvor de skal finne denne informasjonen. For en chatassistent er det optimalt at de kan navigere seg rundt og finne den informasjonen de trenger. Resultat Bruker 1 Trodde først at kø-ikonet var hvor denne informasjonen lå, klikket så på de ulike sidene nedover i navigasjonsmenyen og finner dermed informasjonen. Bruker 2 Bruker 3 Bruker 4 Bruker 5 Fant dette øyeblikkelig, ikke noen vansker. Skjønte ikke at sanntid betød informasjon om andre brukere, gikk gjennom alle sidene i navigasjonsmenyeni navigasjonsmenyen til han fant informasjonen. Når siden var funnet fant han informasjonen raskt. Trykket først på kø-ikonet i navigasjonsmenyen siden det ser ut som en ansatt, åpnet navigasjonsmenyen og leste tekstbeskrivelsene. Tok litt tid for å skjønne hva sanntid var. Fant raskt ut hvor mange som var pålogget fra sanntidssiden. Ble forvirret over at det var en person i kø-ikonet i navigasjonsmenyen og trodde det var her informasjonen skulle finnes. Etter en del leting fant hun frem og fikk lest informasjonen. Tolkning av resultat Som resultatene i oppgave to ser vi at en likhet for denne oppgaven er at etter bruker nummer tre gjør vi relativt like observasjoner av hvordan oppgaven blir utført. Det oppstod forvirring blant brukerne rundt begrepet sanntid og resultatene tilsier at det ikke var tydelig nok hvor man kunne finne informasjonen det ble spurt om i oppgaven. Med dette kan vi konkludere med at det kan gjøres endringer for å redusere tiden man bruker på å navigere seg rundt på siden. Tabell 1.4 Oppgave 3 for brukertest av chatassistent siden 154

155 Selv om de ulike brukerne gjennomførte oppgavene i ulikt tempo fikk de til syvende og sist utført det oppgaven spurte om. Vi observerte at å ha gode tekstbeskrivelser fungerer som god veiledning for brukeren når de er usikre på hvordan noe kan gjennomføres. I tilfellet for sanntidssiden oppstod det forvirring ved at navn og ikon i navigasjonsmenyen ikke var selvforklarende nok. Av den grunn bestemte vi oss for å endre dette til å være mer brukervennlig for ulike brukere. Fra prinsippet om læring fra interaksjonsdesign vil det kreves at systemet tas i bruk et par ganger før en bruker vil kunne lære seg og huske hvordan de ulike funksjonene fungerer. Av den grunn har denne brukertesten oppfylt kravene våre om at applikasjonen skal være brukervennlig og forholde seg til UI- og UX-design prinsippene Brukertest av kunde siden For å teste klient siden av chatten ønsket vi å skape så realistiske omgivelser som mulig. Av den grunn valgte vi å la brukeren benytte seg av chatten hvor målet er å finne ut av et spørsmål de har om et produkt. Vi opplyste dem om at de kunne benytte seg av chatten for å komme i kontakt med kundeservice. Mens brukeren benyttet seg av chatten observerte vi om det oppstod noen utfordringer eller om det var noe de ikke fant ut av. Vi hadde på forhånd forberedt noen oppfølgingsspørsmål. Disse spørsmålene tar utgangspunkt i brukerkravene for klient chatten, som finnes i vedlegg 3. Etter at brukeren sa at de var ferdige eller de hadde avsluttet samtalen i chatten ba vi dem svare på spørsmålene i spørreskjemaet under. Skjemaet laget vi i Google Forms som gjør det enkelt å dele og å sende skjemaet til de ulike testbrukerne. Følgende spørreskjema inneholder både spørsmålene og resultatene etter at de fem ulike brukerne hadde testet kunde siden. 155

156 156

157 Som resultatene i spørreskjemaet tilsier møtte ingen av de fem ulike testbrukerne på noen vansker verken med navigasjon eller funksjonalitet. Alle brukerne ga samtydige svar og vi kan konkludere med at de var enige om at applikasjonen er brukervennlig og mangler ingen funksjonalitet. Kompatibilitetstesting Hva skjer når chat-løsningen brukes på ulike enheter, nettlesere og plattformer? Hensikten med å teste hvor kompatibelt programmet er med ulike nettlesere er å passe på at innholdet holder seg konsistent. Vil man fortsatt kunne aksessere de samme tingene, ser alt likt ut i de ulike tilfellene? Fungerer all funksjonalitet i de ulike tilfellene? Dette er hva vi ønsker å finne ut av ved å gjennomføre denne testen. Vi har benyttet oss av BrowserStack som tilbyr en nettbasert løsning hvor vi kan teste chat-løsningen i ulike nettlesere. BrowserStack gir umiddelbar tilgang til ulike skrivebord og mobilnettlesere som for tiden er over 300 stykker. Fordelene med å benytte BrowserStack er at det er sky-basert og krever ingen installasjoner slik at man kommer raskt i gang med testingen. Resultatet av testene er fremstilt i tabell

158 Tabell 1.5 Resultater av kompatibilitetstester utført i BrowserStack Enhetstesting For enhetstesting ble det skrevet tester for chatstore (react + mobx) og for chathub (.net). Dette resulterte i en kodedekning på 73.47% som dekker alt av kode på server. Enhetstestene for chathub ble kjørt direkte fra Visual Studio som vist i figur 1.6. Testene for chatstore ble kjørt fra kommandolinjen via jest som illustrert i figur 1.7 under. Figur 1.6 Testmetoder og coverage for chathub 158

159 Figur 1.7 Testresultater for chatstore 159

160 Brukerveiledning Chatnodes Bachelorprosjekt 2017 Gruppe

161 Forord Brukerveiledningen er ment for å gi brukeren en oversikt over de ulike funksjonalitetene og en veiledning på hvordan disse benyttes. Veiledningen er strukturert etter de relevante brukerne av programmet. Det skal av den grunn være enkelt å finne frem til ønsket handling for de ulike brukergruppene. Veiledningen inneholder skjermbilder for de ulike handlingene med forklarende tekst og figurer. Det kreves minimalt med tekniske ferdigheter for å kunne benytte seg av Chatnodes. For en person med administrator rettigheter er det anbefalt å lese både seksjonen for chatassistent og for administrator. 161

162 Innholdsfortegnelse 1 Chatassistent Logge inn Endre påloggingsstatus / logge ut Navigere mellom de ulike sidene Legge til en klient Bytte mellom ulike klienter Avslutte en samtale Velge et svar fra «Lagrede svar» Notifikasjon fra klienter Finne informasjon om chatassistenter Se informasjon om klienter fra «Samtale kø» Starte en videosamtale Administrator Oppdatere lagrede svar Slette/endre et lagret svar Registrere en ny assistent Endre innstillinger Klient Start en chat Sende en melding Avslutte en chat-samtale Sende transkript på epost Føre en videosamtale

163 1 Chatassistent Logge inn Skriv inn epost og passord og trykk deretter på «Logg inn» for å logge på. Dersom man ikke allerede er registrert som en bruker kan man registrere seg ved å trykke på «Registrer». Endre påloggingsstatus / logge ut Advarsel: Det er ikke mulig å logge av dersom påloggingsstatusen er satt til noe annet enn «Pålogget». Påloggingsstatus er tilgjengelig fra alle de ulike sidene i programmet. Trykker man på pilen åpnes en «dropdown-liste» med flere valg. Endre din påloggingsstatus ved å trykke på «Pålogget», «Borte» eller «Usynlig» avhengig av hva som allerede er valgt. Trykk på «logg ut» knappen for å logge av. 163

164 Navigere mellom de ulike sidene Naviger mellom de ulike sidene ved å bruke menyen til venstre. Trykk på hamburger ikonet for å utvide menyen og se en tekstlig beskrivelse av de ulike navigasjonsmulighetene. Legge til en klient Dersom man har logget inn og det ikke er noen klienter under «Mine samtaler» står følgende melding: 164

165 For å legge til en klient, trykk på «legg til» under samtale kø. Bytte mellom ulike klienter Bytt mellom de ulike klientene under «Mine samtaler» ved å trykke på ønsket klient. Avslutte en samtale Avslutt en pågående samtale ved å trykke på «Avslutt samtale» nederst i chatvinduet. Dersom en kunde avslutter eller kobler av samtalen før en chatassistent, kommer følgende melding opp: Man kan enten vente til tiden har kommet til null eller avslutte den med en gang ved å trykke på «Avslutt samtale». 165

166 Velge et svar fra «Lagrede svar» For å velge et lagret svar fra «Lagrede svar» boksen trykker man på «velg» knappen ved det tilhørende svaret man vil velge. Dersom man ikke finner det man leter etter kan man benytte seg av «Søk» feltet øverst til høyre. Notifikasjon fra klienter En ny melding fra en klient vil markeres med en teller. Forutsatt at du har flere enn èn samtale under «Mine samtaler» og ikke har åpen chat-vinduet til gjeldende kunde. Dersom du er i en annen fane i nettleseren enn Chatnodes vil du få en notifikasjon i form av en meldingslyd. Finne informasjon om chatassistenter Velg «Sanntid» fra menyen for å få tilgang til informasjon om andre chatassistenter. Informasjonen som vises kan filtreres fra «dropdown-listene». 166

167 Et sammendrag av antallet brukere som er pålogget finnes i kolonnen til venstre under «Status». Se informasjon om klienter fra «Samtale kø» Velg «Kø» fra menyen for å se informasjon om klienter som befinner seg i «Samtale kø». Starte en videosamtale Åpne panelet for video samtale ved å trykke på videokamera-ikonet: 167

168 Start en video samtale med kunden ved å trykke på «start video» knappen: 2 Administrator En innlogget administrator vil kunne se fire ytterligere valg i navigasjonsmenyen til venstre enn det som er listet i seksjon 2.3. Følgende valg vises i tillegg: Oppdatere lagrede svar Legg til et nytt svar til «Lagrede svar» ved å velge «Oppdater lagrede svar» fra menyen (se 1.3). For å legge til et nytt svar gjør følgende: 1. Trykk på «Opprett svar» knappen 2. Skriv inn et spørsmål 3. Skriv inn et tilhørende svar 4. Trykk på «Opprett» knappen for å lagre dette 168

169 Slette/endre et lagret svar For å slette eller endre et lagret svar gjør følgende: 1. Velg svaret du vil slette/endre fra menyen til venstre 2. Dersom du vil endre svaret se seksjon 2.1 ovenfor 3. Dersom du vil slette svaret trykk på «Slett» knappen

170 Registrere en ny assistent Velg «Registrer assistent» fra menyen for å registrere en ny assistent. Fyll ut feltene: «Epost», «Passord» og «Gjenta passord». Trykk deretter på «Registrer» knappen. Advarsel: Dersom epostadressen eller passordet ikke er gyldig eller møter kravene for epost eller passord, vil ikke en ny assistent bli registrert. Følgende meldinger vises: Endre innstillinger Velg «Innstillinger» fra menyen for å få tilgang til innstillingene. Endre innstillingene som følger: 1. Endre verdien til de ulike feltene ved å skrive inn en ny verdi eller bruk pil opp eller pil ned. 2. Trykk på «Oppdater» knappen for å lagre endringene. 170

171 Klient Start en chat Aktiver chatten ved å trykke på følgende ikon: Dersom det ikke er noen tilgjengelig som kan assistere deg umiddelbart vil følgende melding vises: Start å chatte ved å skrive inn din forespørsel i input-feltet: 171

172 Sende en melding Send en melding etter at du har skrevet din forespørsel i inputfeltet (se 3.1). For å sende meldingen har man 2 valg: 1. Trykk på «Send» knappen 2. Hak av «Trykk enter for å sende» og bruk enter-tasten Avslutte en chat-samtale For å avslutte samtalen gjør følgende: 1. Trykk på x-ikonet øverst til høyre i chat-vinduet. 2. Trykk på «Avslutt» knappen. 3. Gi en tilbakemelding av chatten ved å trykke på en av smiliene 172

173 4. Trykk på «Lukk» knappen. Sende transkript på epost For å sende transkript av samtalen på epost, gjør følgende: 1. Trykk på x-ikonet øverst til høyre i chat-vinduet. 2. Velg «Send transkript på epost» knappen. 3. Skriv inn din epostadresse i input-feltet (1) og deretter trykk på «Send» knappen (2)

174 Føre en videosamtale Start en videosamtale ved å trykke på videokamera-ikonet: Gå tilbake til samtalen ved å trykke på tilbake-pilen: Avslutt videosamtalen ved å trykke «Avslutt video»: 174