Implementation av en interaktiv användarguide.
Implementing an interactive user guide.
Fredrik Sjökvist Johan Stenström
Fakulteten för matematik och datavetenskap Dataingenjör
15 hp
Lothar Fritsch Karl-Johan Grinnemo 070617
2
Sammanfattning
Digital skyltning är någonting som blir allt mer populärt över världen. DISE International AB har kunder från hela världen och levererar tjänster för att kunna skylta digitalt.
Kunderna styr sina digitala skyltar genom ett webbgränssnitt, många nya kunder tycker detta är svårt då webbgränssnittet inte är helt självförklarande.
Vårt projekt har gått ut på att implementera en interaktiv användarguide i ett redan existerande webbgränssnitt.
3
Abstract
The use of digital signage is becoming more and more popular all over the world. DISE International AB delivers digital signage services to customers all over the world. The customer can control their signs by using a web page. Many customers think this is a bit difficult because the website is not very self-explanatory.
The purpose of this project was to implement an interactive user guide on an already existing web page.
4
Innehållsförteckning
1 Introduktion ... 10
1.1 Projektmål och motivationer ... 10
1.2 Förväntade Resultat ... 10
1.3 Projektresultat ... 11
1.4 Rapportupplägg ... 11
1.5 Projektets upplägg ... 12
1.6 Avgränsningar ... 13
1.7 Kaptitelsummering ... 13
2 Bakgrund ... 14
2.1 Introduktion till undersökning ... 14
2.2 Detaljerat om undersökningen ... 14
2.3 Tidigare arbeten ... 15
2.1 Kaptitelsummering ... 16
3 Utmaningar ... 16
3.1 Utmaningar med att jobba med etablerad kodbas ... 16
3.2 Lära sig nya programspråk ... 17
3.3 Kaptitelsummering ... 17
4 Design ... 18
4.1 Introduktion ... 18
4.2 Översikt ... 19
4.3 Studie av användarguider ... 21
4.4 Hur det ser ut nu ... 21
4.5 Första skisser ... 22
4.6 Prototyp med intro.js ... 23
4.6.1 Om intro.js ... 24
4.6.2 Prototypen ... 24
4.7 Slutdesign ... 26
4.8 Kaptitelsummering ... 27
5 Implementation ... 28
5.1 Introduktion till utvecklingsmiljön... 28
5.1.1 Vilka programspråk har vi använt oss av? ... 29
5.1.2 HTML ... 29
5.1.3 CSS ... 29
5.1.4 JavaScript ... 29
5.2 Introduktion till implementation ... 30
5
5.2.1 React ... 30
5.2.2 Backbone ... 30
5.3 Implementering av triggerknapp ... 31
5.4 Implementationsstart samt beskrivning av uppbyggnad ... 32
5.5 Ändringar i planen ... 34
5.6 Ge kunden ett val samt ett trevligt välkomnande ... 34
5.7 Cookies ... 36
5.7.1 Vad är en cookie? ... 36
5.7.2 Implementation av cookies ... 36
5.7.3 Tolkning av lagrade cookies ... 37
5.8 Implementation av innehållet i guiden ... 38
5.9 Testning ... 40
5.10 Kaptitelsummering ... 40
6 Resultat... 41
6.1 Introduktion ... 41
6.2 Den färdiga guiden ... 41
6.2.1 Guidestart ... 41
6.2.2 Slutresultat guide ... 43
6.2.3 Cookielagring ... 45
6.3 Kaptitelsummering ... 46
7 Utvärdering av arbetet... 47
7.1 Summering av arbetet ... 47
7.2 Problem som uppstått i arbetet ... 47
7.2.1 Installation av server ... 47
7.2.2 Installation av frameworks ... 47
7.2.3 Designmässiga problem ... 48
7.3 Vad kommer vi göra annorlunda i framtiden? ... 48
7.4 Vad kan vi ta med oss från detta projekt? ... 48
7.5 Kaptitelsummering ... 48
8 Källförteckning ... 49
9 Bilagor ... 50
9.1 Bilaga A: Projektspecifikation ... 50
6
Figurlista
Kapitel 1
1.1... Diagram över hur de olika delarna av projektet kommer tillsammans för att nå vårt mål
Kapitel 4
4.1... Pajdiagram över vad de tillfrågade tycker är viktigast för en användarguide 4.2... Pajdiagram över om de tillfrågade föredrar textrutor eller en längre guide 4.3... Pajdiagram över om de tillfrågade tycker att det är viktigt att guiden ser bra ut.
4.4... Exempel på hur guide byggd på små textrutor kan se ut.
4.5... huvudsidan på webbgränssnittet original utan guide
4.6... Vår vision över hur guiden ska se ut innan man startar den 4.7... Skiss på hur de olika stegen ska kunna se ut.
4.8... Prototyp av meny
4.9... Prototyp över de olika stegen.
4.10... Prototyp på hur nästa steg av guiden skulle kunna se ut 4.11... Stukturdiagram över guiden.
Kapitel 5
5.1... Atom, editorn som har använts till projektet 5.2... Exempel på hur Reactkod kan se ut [React]
5.3... Hur Backbone är uppbyggt [Backbone].
5.4... Knappen men ett utropstecken är vår triggerknapp.
5.5... Hur webbgränssnittet ser ut original.
5.6... När användaren har tryckt på saker så att fyra stackpanes finns i stacken.
5.7... Illustration av konceptet att vi kan återanvända samma stegsnummer för varje undermeny
5.8... Modalen som hälsar kunden välkommen
5.9... Kod för Modal. Bilden visar konceptet med att ha en webbsida inuti Modal 5.10... Kod för att lagra cookies
5.11... Om användaren tackar nej kommer denna ruta upp
7 5.12... Visar kontrollen för cookies
5.13... Argument till intro, pga. sekretess visar vi inte hela HTML-taggen 5.14... Inladdning av HTML-klasser från en annan fil
5.15... HTML-koden till guidesteget som förklarar players Kapitel 6
6.1... Den färdiga Modalen för att starta guiden
6.2... Sista steget i guiden. Visar vart man startar guiden igen 6.3... Närmare titt på introrutan i bild 6.2
6.4... Första rutan i den färdiga guiden
6.5... När användaren har tryckt på sliderknappen 6.6... När användaren gått vidare till nästa steg
6.7... Modal med cookies när användaren loggar in första gången 6.8... Cookies när användaren valt att gå igenom guiden
6.9... Cookies när användaren har varit inloggar förut
8
Begreppslista
Overlay = En slags bild som hamnar ovanpå en hemsida.
Digital signage = Digital skyltning.
Google-formulär = Formulär skapat med hjälp av Googles tjänster.
Framework = Externt bibliotek.
Modal = Framework för att skapa overlays som innehåller webbsidor.
Intro.js = Framework utvecklat speciellt för användarguider.
9
Sidan avsiktligen lämnad blank
10
1 Introduktion
1.1 Projektmål och motivationer
Målet med vårt projekt är dels att vi ska lära oss mer om hur man jobbar direkt med ett företag men även att vi ska lära oss hur vi kan samarbeta tillsammans för att uppnå högsta möjliga resultat. Vi har även som mål att kunna leverera en produkt som sedan kan användas av företaget. Detta är våra två största mål, sedan så kommer saker som att lära oss ett nytt programspråk och liknande som en bonus. Men att förstå hur man jobbar inom ett företag och att leverera en produkt som går att använda är våra två största mål.
Motivationerna för dessa mål är bland annat att vi tycker att det är väldigt viktigt att vi vet hur ett arbete går till inom ett företag och hur man kan samarbeta för att uppnå ett resultat, detta kommer vi ha nytta av när vi själva tar examen och ska sedan ut och leta jobb. Motivationen för målet att leverera en färdig produkt är för att vi vill göra klart det vi påbörjat och även att vi vill att företaget som vi arbetar med på detta projekt har uttryckt ett intresse att använda vårt projekt som en del av deras produkt.
1.2 Förväntade Resultat
Det förväntade resultatet är en färdig produkt som är byggd på analyserade data som vi samlat in. Vi hoppas även att resultatet blir att det blir lättare för kunderna att förstå med hjälp av vårt projekt hur de navigerar och använder de tjänster som DISE levererar. Vi båda känner att så länge som det blir lättare för användarna och vi kan leverera någonting som går att använda så har vi nått ett lyckat resultat. Vi förväntar oss att efter projektet ska vi ha fått känna på hur det är att programmera en applikation åt ett företag och känna oss mer redo att komma ut i arbetslivet.
11
1.3 Projektresultat
Vi är nöjda med resultatet, vi känner att vi har lyckats skapa en guide som fyller sin funktion.
Guiden blev att praktiska anledningar inte som vi hade tänkt oss ifrån början men trots det är vi nöjda. Anledningen till att den inte blev som vi hade tänkt kommer förklaras i kapitel 5. För detaljerad beskrivning av resultatet se kapitel 6.
1.4 Rapportupplägg
Rapporten ska börja med en introduktion där vi går igenom vad det är vi försöker åstadkomma med projektet och hur vi ska åstadkomma det, men även vilka mål vi vill uppnå. Vi kommer även skriva om de förväntade resultaten.
Under bakgrundsdelen av rapporten så kommer vi att gå igenom mer om varför vi valde att arbeta med detta projekt och vilka förutsättningar vi hade. Här kommer vi även ge projektet ett bredare koncept och jämföra vårt projekt med andra liknande projekt. Vi kommer även diskutera utmaningar med projektet.
I vår designdel kommer vi diskutera resultatet från en undersökning som vi kommer göra. Vi kommer även visa upp våra första skisser och vår prototyp som vi byggt innan vi började med implementeringen. Vi kommer även visa upp slutdesignen.
I implementationsdelen kommer vi skriva om utvecklingsmiljön och de olika programspråk som vi använt oss av. Här kommer vi även förklara hur vi löst de olika delarna av implementeringen. Efter vi visat implementationen kommer vi ha en resultatdel. Här kommer vi visa upp slutprodukten.
I slutet av rapporten har vi en slutsats där vi diskuterar hur vi tycker att det gick och även om vi känner att våra mål uppfylls. Utöver detta så diskuterar vi de problem vi haft under projektets gång och de potentiella lösningar vi hade på dessa problem. För att avsluta rapporten skriver vi om framtida arbeten, vilka begränsningar vi hade under projektets gång och hur vi i framtiden ska försöka undvika dessa problem och begränsningar.
Varje kapitel avslutas med en summering av kapitlet.
12
1.5
Projektets uppläggVi har skapat ett diagram (se Bild 1.1) som visar hur vi har planerat att de olika delarna av projektet ska arbeta tillsammans för att skapa en färdig rapport och en färdig produkt. Vi har tre stycken grundsektioner av rapporten, dessa är analys, rapport och kodning. Analys består av en undersökning där vi tar reda på vad det är vi vill analysera, vilka frågor vi vill ställa osv. I implementeringsdelen tar vi det vi har undersökt och implementerar enligt det vi kom fram till i analysfasen. Vi använder även denna information för att hjälpa oss implementera koden. Med detta menar vi eftersom analysen främst går ut på att ta reda på vad olika personer tycker är viktigt i en användarguide så använder vi även denna information när vi implementerar och designar guiden.
Under rapportdelen har vi inte så många individuella delar eftersom det mesta som ska vara med i rapporten kommer från kodning och analys. Bakgrund är allt som inte har direkt med projektet att göra utan mer om rapporten, t.ex. introduktion, bakgrund osv.
Kodningen är upplagd på så sätt att vi började med design. Designen är den del där vi planerar hur vårt färdiga projekt ska se ut. Design hjälpte oss även med att välja rätt framework vilket är anledningen till varför vi planerade att göra det före undersökningen. I undersökningen så börjar vi leta efter ett framework men även verktyg för att hjälpa oss att uppnå designmålet.
Implementering är där vi implementerar vår design med hjälp av de frameworks som vi kom fram till att använda i undersökningsfasen vilket ger oss ett färdigt resultat.
13
Bild 1.1. Diagram över hur de olika delarna av projektet kommer tillsammans för att nå vårt mål
1.6 Avgränsningar
Uppdragsgivaren har bett att vi inte publicerar kod som vi själva inte har skrivit, detta för att detta dokument är en offentlig handling och uppdragsgivaren inte vill att deras kod ska vara publik.
1.7 Kaptitelsummering
Vi förklarar våra mål och ambitioner, vad vi hoppas kunna åstadkomma med detta projekt. Vi diskuterar även vilka resultat vi förväntar oss samt hur resultatet blev. Vi förklarar ingående hur vi byggt upp rapporten. Vi har även en ingående förklaring med både text och bild på hur vi lagt upp de olika delarna av projektet.
14
2 Bakgrund
DISE International AB är ett internationellt bolag med huvudkontor i Karlstad. Bolaget levererar tjänster inom digital signage. Företagets kunder kan styra sina digitala skyltar med hjälp av ett webbgränssnitt. Företaget har kunder från hela världen inom många olika branscher vilket innebär att deras kunder har väldigt varierande datorvana. För kunder som är vana att använda olika gränssnitt är det inget större problem att använda sig av DISE men däremot finns ett problem att de kunder som har mindre datorvana blir förvirrade och har svårt att komma igång med gränssnittet. Gränssnittet har en hjälpknapp där man kan trycka för att få lite information om vad den sektionen som man är i just nu handlar om. DISE har även introduktion videos på Youtube där de förklarar hur de olika delarna fungerar. Vi misstänker att kunderna inte kollar på dessa videos eller åtminstone inte kollar på alla. Därför ska vi göra en interaktiv användarguide så att kunderna kan få instruktioner direkt i webbgränssnittet och slipper använda sig av externa verktyg för att få instruktioner. Vi vill dels att kunderna ska kunna komma in i hur webbgränssnittet funkar snabbt men även att DISE ska få färre supportsamtal där kunderna undrar hur enkla saker funkar i webbgränssnittet. Vi tror att detta kommer leda till att kunderna blir nöjdare men även att DISE kan fokusera på andra uppgifter än att svara på supportsamtal angående väldigt enkla saker.
2.1 Introduktion till undersökning
Då vi som utför detta uppdrag jobbar på DISE med testning så är vi vana att använda webbgränssnittet och kommer behöva göra en undersökning. Detta för att vi ska kunna få ett underlag för hur guiden ska designas och vad som är viktigt när man skapar en interaktiv användarguide.
2.2 Detaljerat om undersökningen
Efter undersökning om olika sätt att undersöka och analysera hur användare använder en produkt så kom vi fram till tre stycken olika alternativ. Vårt första alternativ var att vi tänkte implementera en logg i webbgränssnittet där allt som kunderna gör loggas. Det andra alternativet är att vi låter personer som aldrig använt mjukvaran förut göra olika uppgifter där vi sitter bredvid och observerar deras beteende. Det tredje och sista alternativet var att vi istället
15
för att fokusera för mycket på hur användare använder webbgränssnittet så fokuserar vi mer på vad användare vill se i en guide genom att skapa en undersökning online.
Alla tre alternativen har både för och nackdelar, om vi loggar hur kunderna beter sig får vi skarpa data, alltså data på hur kunder som använder systemet på riktigt gör. Däremot är en av nackdelarna att vi inte vet hur mycket datorvana de olika kunderna har eller hur mycket de har arbetat i DISE webbgränssnitt förut.
Fördelarna med alternativ två är just att vi kan välja ut personer som har olika mycket datorvana.
Vilket ger oss en mycket bättre bild hur svårt det är att förstå hur man använder olika delar av gränssnittet. Detta alternativ är också väldigt attraktivt för att guiden är i stort sett bara menat för personer som aldrig använt DISE mjukvara innan. Nackdelen med detta alternativ är att det är väldigt svårt för oss att utföra dessa tester. Det är för DISE produkter är mer än bara ett webbgränssnitt och testpersonerna skulle behöva komma till oss på DISE kontor för att kunna göra testerna.
Det tredje alternativet vilket var att vi skapar ett formulär online där personer svarar på frågor angående guider och vad de vill se i en guide. Det är även det alternativ som vi i slutändan bestämde oss för att använda. Anledningen till att vi valde att använda alternativ tre fast de andra alternativen hade större fördelar var för att detta alternativ inte var lika tidskrävande.
Fördelarna med att använda alternativ tre och göra en bred undersökning var att vi fick väldigt mycket information om vad användare vill se i en guide. En annan fördel var att vi kunde nå ut till många fler personer än vad vi hade hunnit med de andra alternativen.
2.3 Tidigare arbeten
Efter att vi gjort undersökningar och gått igenom gamla rapporter hittade vi inget liknande examensarbete. Däremot finns det många frameworks utvecklade för just detta ändamål, därför har vi anledning att tro att användarvänlighet är ett ganska vanligt problem för företag som har någon form av gränssnitt som kunderna jobbar i.
16
2.1 Kaptitelsummering
Kapitlet introducerar vad uppdragsgivaren gör och varför vi fått detta uppdrag. I kapitlet förklarar vi även att vi kommer göra en undersökning och hur vi kommer göra den.
3 Utmaningar
I den här delen av rapporten beskriver vi de delar av projektet som för oss var mest utmanande.
Vi ger även en inblick i hur vi tänkte och planerade för att kunna lösa utmaningarna på ett bra sätt. För att komma fram till lösningar så gjorde vi informationssökning på hur andra personer har löst liknande problem. Sen även hur man kunde förbereda sig inför kommande problem och helt undvika dem.
3.1 Utmaningar med att jobba med etablerad kodbas
Eftersom vårt projekt innebär att vi ska implementera ny kod in i en redan existerande kodbas var en av de största utmaningarna att lära sig koden som redan fanns. Till att börja med så gjorde vi misstaget att vi började implementera utan att gå igenom koden. Detta gick självklart inte bra då vi väldigt snabbt fastnade och visste inte vad vi skulle göra för att komma vidare.
För att på ett smartare sätt kunna implementera vår kod så bestämde vi oss för att följa ett par steg. Till att börja med så tog vi reda på hur koden var uppbyggd, detta innebar att vi tog reda på saker som:
Vilka bibliotek används?
Vilka programspråk används?
Vilken del av kodbasen ska vi fokusera på?
Vilken del av koden gör vad?
Genom att försöka hitta svar på dessa frågor vart det väldigt mycket lättare för oss att förstå hur vi skulle implementera vår kod. Det gav oss även en bra förståelse över vad vi behövde göra innan vi ens försökte implementera någonting i kodbasen. Vilket var att vi gick igenom och lärde oss om dem olika biblioteken som användes, vi lärde oss även grunderna av de språk som är relevanta för detta projekt.
17
Det var i början svårt för oss att hitta vart i koden vi skulle börja implementera, som en lösning på detta problem gick vi metodiskt igenom koden och försökte hitta vilka delar som gjorde vad för att på så sätt hitta de filer som var relevanta för oss i vårt arbete.
När vi hade gått igenom koden och lärt oss mer om hur strukturen och hur kodbasen var uppbyggd så började vi med en ny taktik. Denna taktik är egentligen bara ”trial and error” vilket innebär att vi gör små ändringar i koden och ser vad som händer och vart det händer[t&e]. Detta är ett väldigt snabbt och effektivt sätt att hitta de delar av koden som är relevanta. Detta fungerade väldigt bra för oss eftersom vårt projekt är en användarguide som visas grafiskt så det var lätt att se vart vi skulle införa vår kod.
3.2 Lära sig nya programspråk
Ingen av oss hade tidigare jobbat med programspråket som skulle användas i vårt projekt.
Programspråket som vi huvudsakligen skulle lära oss var JavaScript. Vi båda har däremot jobbat mycket med andra programspråk innan som t.ex. C och HTML. Kunskapen i HTML hjälpte oss mycket på vägen eftersom ofta när man jobbar i JavaScript så jobbar man även i HTML. Detta är för att båda två används för att bygga hemsidor. Vår kunskap i C hjälpte mycket då syntaxen i JavaScript liknar den i C.
För att lära oss JavaScript så började vi med att läsa om det. Vi gick igenom guider och försökte lära oss grunderna. Vi fick även mycket hjälp av att kolla och läsa om det framework vi skulle använda. Detta var det vi fokuserade mest på, vi kände att vi inte hade tid att lära oss allt om JavaScript. Så därför fokuserade vi väldigt mycket på just de delar vi behövde för att kunna implementera vårt framework in i den redan existerande kodbasen. Genom att göra på detta sätt byggde vi snabbt upp tillräckligt med kunskap för att jobba effektivt med projektet.
Webbgränssnittet bygger främst på två olika framework som heter React och Backbone, för att lära oss om dessa använde vi oss av deras officiella hemsidor där vi läste igenom exempelkod.
3.3 Kaptitelsummering
Vi pratar om vilka utmaningar vi har stött på, kort sammanfattat var utmaningarna att lära sig att jobba med en redan etablerad kodbas men även att lära sig nya programspråk.
18
4 Design
Designen var alltid en väldigt viktig del av vårt projekt. Det är för att en användarguide är väldigt grafisk. Det var därför vi bestämde oss för att göra undersökningar i just detta område.
Vi kände att det var viktigt att få feedback från vanliga användare vad de tycker är viktigt i en användarguide. Vi använde även denna undersökning som hjälp att förstå vilka delar som vi skulle lägga mest fokus på. Ett exempel på detta är att vi märkte att väldigt många tyckte att det var viktigt att man inte fick för mycket information på en gång utan att man bara fick tillräckligt med information för att kunna förstå det viktigaste och komma igång. Detta gjorde att vi tänkte om hur vi skulle designa användarguiden och tog bort vissa steg som vi tidigare hade tänkt använda. Det är till exempel inte nödvändigt att ha med förklaringar på saker som de flesta användare aldrig kommer använda sig av, exempelvis administratörsinställningar.
4.1 Introduktion
Den interaktiva användarguiden består av ett antal overlays som hamnar över webbgränssnittet.
Gränssnittet har en kort förklarande text för den delen som guiden för tillfället förklarar. Det finns även en liten styrpanel på overlayen där användaren kan välja att avbryta guiden eller bläddra till nästa eller föregående steg, detta görs antingen genom att klicka på knappar med muspekaren eller använda sig av piltangenterna. Webbgränssnittet i sig har en meny på vänstersidan där användaren kan välja att redigera spelare, ladda upp material till webbservern, schemalägga spelare osv.
Tanken är att när användaren loggar in på webbgränssnittet första gången ska guiden komma upp automatiskt, det ska även vara möjligt att trigga guiden i efterhand via en knapp. Det var tänkt att när användaren går in på en av menyerna för första gången ska guiden triggas igen med relevant information. Tanken med detta var att användaren inte ska få för mycket information på en gång utan istället ska det portioneras ut tills det att användaren faktiskt behöver informationen. Om all information kommer på samma gång finns det risk för att användaren har hunnit glömma bort vad som stod i guiden alternativt att de bara trycker ner guiden när de tycker att den blir för lång och tråkig, vi tror att detta kan leda till att användaren missar viktig information.
19
4.2 Översikt
Som hjälp att bestämma vad vi skulle fokusera på när vi designade guiden använde vi resultatet från enkätundersökningen och kunde konstatera att några viktiga aspekter för en användarguide är att den ska vara förklarande utan att användaren behöver läsa mycket text men man ska även kunna avbryta guiden när man känner för det. 22.2% av de tillfrågade svarade att den viktigaste aspekten är att guiden inte ska ta lång tid att ta sig igenom.
Bild 4.1. pajdiagram över vad de tillfrågade tycker är viktigast för en användarguide
Vi gjorde även en undersökning över om allmänheten föredrar att det poppar upp små textrutor med en förklarande text eller om de föredrar en lite längre guide där hemsidan förklaras steg för steg. 79.8% svarade att de föredrar små textrutor medan 14.1% inte tyckte att det spelar någon roll.
Vi tyckte att en lite längre guide där hemsidan förklaras steg för steg var mer applicerbart på den hemsida som vi skulle implementera guiden i. DISE tyckte också att det vore bättre med en lite längre guide istället för textrutor.
20
Bild 4.2. pajdiagram över om de tillfrågade föredrar textrutor eller en längre guide
En majoritet av de tillfrågade svarade även att det är viktigt att guiden ser bra ut för att man ska vilja följa den. Olika användare tycker givetvis att olika saker ser bra ut så här fick vi en tankeställare om hur vi själva faktiskt vill att den ska se ut. Tanken var i början efter undersökningen att vi skulle skapa en minimalistisk guide vilket betyder att vi gör designen väldigt simpel och förenklad.
Bild 4.3. pajdiagram över om de tillfrågade tycker att det är viktigt att guiden ser bra ut.
21
Med hjälp av denna undersökning fick vi en bättre idé över vad vi skulle sikta in oss på och hur vi vill att vår guide ska se ut. Den ska vara minimalistisk och försöka ge användaren så mycket information som möjligt utan att använda för mycket text. Tanken var att vi skulle försöka skapa en guide som bara ger små anvisningar genom att ringa in och peka ut vad användaren ska göra.
4.3 Studie av användarguider
För att hämta inspiration till vår design undersökte vi hur guiderna på andra hemsidor och applikationer ser ut. Vi fick tips från vår enkätundersökning att de flesta moderna dataspel brukar ha någon form av guide när man spelar första gången. Att undersöka hur guiderna ser ut för spel är relevant på grund av att slutmålet är detsamma som för webbsidor, att användaren snabbt ska förstå hur saker funkar.
Vi har hämtat exempel från det populära dataspelet World of warcraft. Spelet har många menyer där användaren kan göra olika saker. Exemplet nedan visar när användaren har klickat upp spelets karta och en textruta visas som förklarar att indikatorn i nedre vänstra hörnet visar hur många uppdrag man måste göra på ett visst ställe i spelet för att kunna hämta ut en belöning.
Bild 4.4. exempel på hur guide byggd på små textrutor kan se ut.
4.4 Hur det ser ut nu
Bild 4.5 nedan demonstrerar hur webbgränssnittet såg ut utan någon användarguide överhuvudtaget. Det här var alltså grunden som vi hade och som vi byggde vårt projekt på. Det
22
här är även det första man såg när man besökte webbsidan. För en användare som besöker sidan för första gången tror vi att det här bemötandet kan vara väldigt avskräckande. Istället för att användare nu blint ska börja klicka sig runt på sidan har vi alltså skapat en guide för att assistera med hur man kommer igång.
Bild 4.5. huvudsidan på webbgränssnittet original utan guide
4.5 Första skisser
För att ge uppdragsgivaren en idé om hur vi tänkte att guiden skulle se ut ritade vi ett antal skisser. Det gav även oss en bra uppfattning över vad vi ville åstadkomma. Som man kan se på bild 4.6 så kommer det upp en ruta som välkomnar användaren till sidan och erbjuder en guide för att visa hur användaren kommer igång. På bild 4.7 kan vi också se vår vision över hur vi ville att guiden skulle se ut.
Det var alltid viktigt för oss att guiden skulle vara valfri. Vi tycker själva att det är irriterande om en hemsida tvingar användaren att följa en guide, bild 4.1 från vår undersökning visar att 33.3% av de tillfrågade tycker att det viktigaste för att göra en bra guide är att den ska gå att avbryta när man känner för det. Detta är anledningen till varför vi bestämde oss för att ha en välkomstruta där alternativet att skippa guiden helt och hållet finns. Det här binder även in i andra val som vi gjorde vid senare steg av utvecklingen där vi kom på att man även ska kunna avbryta guiden efter att man startat den. Detta är om användaren känner att man fått tillräckligt med information eller att guiden inte levde upp till förväntningarna och man då inte vill följa den längre.
23
Bild 4.6. Vår vision över hur guiden ska se ut innan man startar den
Bild 4.7. Skiss på hur de olika stegen ska kunna se ut.
4.6 Prototyp med intro.js
Webbgränssnittet består av ett antal menyer på vänstra sidan. För att skapa vår design samt lära oss lite om hur olika framework fungerar gjorde vi en egen hemsida med liknande menyer för att kunna simulera hur det skulle vara med en användarguide på DISE webbserver. Nedan följer
24
ett par bilder på vår första prototyp som vi gjorde med hjälp av ett framework som heter intro.js.
Frameworket är utvecklat i JavaScript.
4.6.1 Om intro.js
Under projektets gång så bytte vi fram och tillbaka mellan flera olika frameworks. Detta var för att det var svårt att hitta ett framework som fungerade ordentligt med den redan etablerade kodbasen. Det första alternativ som vi testade är även det alternativ som vi senare bestämde oss för att använda. Men detta var inte förens vi hade försökt använda andra frameworks och märkt att vårt första alternativ var det som fungerade bäst. Det framework som vi bestämde oss för att använda var alltså intro.js. Vi bestämde oss för att använda detta för att det var lätt att använda och hade en väldigt bra demonstration med mycket exempelkod och ett väldokumenterat API.
Vi tyckte även att de funktioner som fanns tillgängliga passade vår vision bra. intro.js är open- source vilket innebär det är gratis att använda, dock finns möjligheten att köpa till kommersiella licenser för extra teman och uppdateringar[intro].
4.6.2 Prototypen
Det här är alltså den allra första prototypen vi gjorde för att testa idén bakom vårt projekt.
Prototypen är en enkel hemsida som vi själva skapat, hemsidan använder sig av intro.js.
Bild 4.8. Prototyp av meny
Här kan vi se hur guiden ser ut när den precis har startat. Guiden har en förklarande text och tre knappar. Knapparna används för att skippa guiden, gå till nästa steg eller gå tillbaka till föregående steg. På bild 4.8 är guiden i sitt första steg därför är tillbakaknappen nedtonad.
25
Bild 4.9. Prototyp över de olika stegen.
Delen som demonstreras på bild 4.9 är den del som vi senare fokuserade mest på när vi bytte fokus i projektet. Det som demonstreras är alltså det som händer när man klickar sig vidare i guiden och hur textrutan följer med.
Bild 4.10. Prototyp på hur nästa steg av guiden skulle kunna se ut
På bild 4.10 har användaren tryckt på menyn players för att komma in i spelarmenyn. Här kan vi se att relevant del av guiden kan triggas igång så att användaren inte behöver se hela guiden.
26
Det framgår inte av bilden men i prototypen har guiden triggats igång automatiskt när användaren tryckt sig in i spelarmenyn.
4.7 Slutdesign
Efter ett möte med DISE bestämde vi att guiden inte skulle vara som vi först hade tänkt. Guiden ska inte öppna några undermenyer, istället ska vi satsa på att få de rutorna som förklarar huvudmenyn att samtidigt förklara hur relevanta saker fungerar i undermenyn.
Vi bestämde oss för att det bästa alternativet till detta förmodligen är att använda en slider där vi kan använda oss av flera olika bilder som användaren kan bläddra mellan. Denna slider kommer vi lägga in i intros rutor. Vi började även kolla på olika alternativ för att hälsa kunden välkommen och ge kunden ett val att starta eller skippa guiden. Till detta bestämde vi oss för att använda oss av ett bibliotek som heter React-modal. Alla ändringar som vi bestämde under mötet kommer vi prata mer ingående om i kapitel 5.
Bild 4.11. Stukturdiagram över guiden.
På bild 4.11 visas ett strukturdiagram som vi ritat över vårt projekt. När användaren ansluter till webbsidan kommer en kontroll göras angående huruvida användaren har fått se guiden eller inte. Om användaren inte har sett guiden kommer en Modal triggas, här kommer användaren få
27
välja mellan att se eller skippa guiden. Om användaren väljer att skippa guiden kommer han eller hon komma till sista steget. Detta för att sista steget visar vart man kan trigga guiden i efterhand. Om användaren väljer att se guiden kommer den starta på steget players som vi definierat till att vara steg 1, här kommer en förklaring om hur man sätter upp och redigerar sina spelare. Om användaren väljer att gå till nästa steg kommer steget playlists läsas in, detta för att vi valt att definiera det som steg nummer 2. Detta kommer fortsätta ända tills nästa steg i listan är det sista steget, då kommer användaren bli informerad om vart man kan trigga guiden igen. Sista steget är ett specialsteg, det är här användaren blir informerad om vart man kan trigga igång guiden senare, därför har vi valt att låta det steget vara skiljt från de andra stegen i diagrammet. Användaren kan när som helst välja att avsluta guiden med hjälp av en knapp.
4.8 Kaptitelsummering
Vi pratar om hur vi har tänkte att guiden ska se ut. Vi pratar även om hur vi använde studier av andra användarguider samt vår undersökning för att komma fram till en design. Vi visar upp våra skisser över hur vi har tänkt att guiden ska se ut, vi visar även upp vår prototyp som vi gjorde innan vi började med själva implementeringen. Kapitlet slutar med en förklaring och en diskussion över slutdesignen, varför den blev som den blev.
28
5 Implementation
5.1 Introduktion till utvecklingsmiljön
Under projektets gång har vi både utvecklat en prototypsida och implementerat guiden i en färdig kodbas. När vi utvecklade prototypen använde vi oss av Notepad++. Vi skrev guiden i två HTML-filer vilka var kopplade till intro.js. Anledningen till att vi använde oss av Notepad++ är för att vi redan hade det installerat på en av våra datorer då vi använt programmet i en tidigare kurs och prototypbyggandet var en såpass enkel del att vi inte kände något behov av att byta texteditor.
Vi stötte på problem när vi skulle börja skriva i den riktiga koden. Problem som att det var väldigt besvärligt att jobba i flera filer samtidigt då editorn inte har något bra sätt att organisera filer. Vi hade även problem med att editorn inte kunde färgkoda koden vilket gjorde att den blev väldigt svår att läsa.
Vi kände att vi var tvungna att byta editor och blev tipsade om Atom. Atom är en gratis open- source editor med stöd för färgkodning och ett användarvänligt GUI för att snabbt och enkelt kunna byta mellan olika filer [Atom; Atom2]. Bild 5.1 är ett exempel på hur det kan se ut.
Bild 5.1. Atom, editorn som har använts till projektet
29
5.1.1 Vilka programspråk har vi använt oss av?
Webbgränssnittet är uppbyggt av HTML, JavaScript och CSS. Senare i kapitlet kommer vi prata om att vi använt oss av React samt Backbone. Dessa två är frameworks utvecklade i JavaScript för att underlätta uppbyggnaden av dynamiska webbsidor. Större delen av sidans JavaScript är JavaScript es6, es6 står för ECMA-Script 6[es6].
5.1.2 HTML
HTML står för Hypertext Mark-Up Language och är ett programspråk som används för att göra hemsidor. Det är med hjälp av HTML som man definierar vad en hemsida ska visa. När en webbläsare ansluter till en hemsida görs ett HTTP-anrop till en webbserver som i sin tur returnerar en HTML-sida. Webbgränssnittet som vi jobbat med genererar HTML dynamiskt beroende på vad användaren gör, vilka rättigheter användaren har osv. [html].
5.1.3 CSS
CSS står för Cascading Style Sheets och är ett språk som används för att beskriva hur ett dokument skrivet i HTML ska visas. CSS kan antingen skrivas direkt i en HTML-fil eller i en egen CSS-fil. Fördelen med att skriva CSS i en separat fil är att den kan återanvändas i flera olika HTML-filer. I CSS kan man definiera saker som textstorlek, textfärg, bakgrundsfärg och typsnitt. CSS gör även att man kan anpassa sin webbsida efter olika enheter och skärmstorlekar [css].
5.1.4 JavaScript
JavaScript är ett språk som används för att bygga dynamiska hemsidor, språket har stöd för objektorienterad programmering, imperativ programmering samt funktionell programmering.
Det innebär alltså att JavaScript är ett multiparadigmspråk. JavaScript används av nästan alla hemsidor, alla moderna webbläsare stödjer språket [js]. JavaScript sköter all logik på hemsidan, hanterar input från användaren samt läser och skriver till databaser. Det är även JavaScript som hanterar cookies som vi kommer förklara i kapitel 5.7
30
5.2 Introduktion till implementation
Implementationsfasen har utan tvekan varit den svåraste delen av projektet. Dels för att vi som tidigare nämnt måste jobba i en redan etablerad kodbas men även för att olika delar av webbgränssnittet använder olika tekniker. Vissa delar är byggda i React medan vissa är byggda i Backbone.
5.2.1 React
React är ett JavaScriptbibliotek som är uppbyggd av komponenter där varje komponent har en renderfunktion. Denna renderfunktion returnerar dynamiskt genererad HTML-kod. Det vill säga funktionen kan returnera olika HTML-koder beroende på till exempel input från användaren[React]. De allra största delarna av webbservern som vi arbetat i är byggda med hjälp av React.
Bild 5.2. Exempel på hur Reactkod kan se ut [React].
5.2.2 Backbone
Backbone är ett JavaScriptbibliotek som används för att ge struktur till en hemsida[Backbone].
Alla grundfunktioner ligger i Backbone, det är så att säga lägsta nivån av uppbyggnaden av webbservern.
Backbone använder sig av en modell och en view. I stora drag kan man säga att view är en sida med HTML-kod som är kopplad till modellen. View hanterar interaktionen med användaren och skickar mottaget data från användaren till modellen. View är även ansvarig för att rendera ut hemsidan till webbläsaren. I modellen sköts all logik, saker som att bestämma vad view ska rendera ut. Läsa och spara data till databaser osv.[Backbone].
31
Bild 5.3. Hur Backbone är uppbyggt [Backbone].
5.3 Implementering av triggerknapp
Den första delen av hemsidan, d.v.s. dit man kommer när man loggar in består av två olika menyer. En meny där användaren kan gå in för att redigera spelare, spellistor osv. En annan meny där användaren kan logga ut, trycka på en hjälpknapp eller ändra systeminställningar. Vi behövde något sätt att trigga igång guiden manuellt för att kunna testa den och bestämde oss för att koppla den till den redan existerande hjälpknappen. I React finns även en funktion som heter onComponentDidMount(); som körs varje gång ett Reactobjekt har skapats [React], vi testade att använde oss av detta för att kunna trigga guiden genom att ladda om hemsidan. Detta var väldigt opraktiskt då guiden triggades igång varje gång man tryckte på någon av webbgränssnittets menyer, oavsett vilken meny man tryckte på.
Då webbgränssnittet redan hade knappar implementerade behövde vi bara kopiera redan befintlig kod och göra lite ändringar. Vi behövde ändra knappens ikon så den inte skulle se lika ut som den kopierade knappen men även vilket funktionsanrop som ska göras när användaren trycker på knappen.
Bild 5.4. Knappen men ett utropstecken är vår triggerknapp.
32
5.4 Implementationsstart samt beskrivning av uppbyggnad
Då vi bara har tillstånd att publicera den koden vi har skrivit själva men inte den koden som vi fick att jobba med kommer vi göra en beskrivning av hur webbgränssnittet fungerar utan att faktiskt visa någon kod.
Allt det som syns på bild 5.5 nedanför renderas ut från samma fil, menyn till vänster kommer alltid finnas där. För olika användare finns det olika många alternativ i menyn, detta på grund av att inte alla användare ska ha rättigheter att göra allt. Hemsidan använder sig av en stack som består av ett antal stackpanes. Menyn som ni ser kan beskrivas som en stackpane.
Bild 5.5. Hur webbgränssnittet ser ut original
När en användare trycker på något av menyvalen kommer en ny stackpane att läggas till i stacken för att renderas ut. Om användaren trycker på någonting i den nya stackpanen kommer eventuellt en till stackpane läggas på stacken. När man trycker på något av menyvalen i den vänstra menyn kommer dock hela stacken att rensas innan någonting nytt läggs på. Om användaren trycker på krysset i övre högra hörnet kommer den sista panelen som lades till på stacken tas bort.
33
Bild 5.6. När användaren har tryckt på saker så att fyra stackpanes finns i stacken.
Att webbsidan är uppbyggd på detta sätt gör att vi ganska enkelt kunde implementera en separat guide för varje undermeny. När användaren loggar in kommer den vänstra menyns guide att triggas. Stegen i guiden kommer vara numrerade så att de tvingas att visas i en viss ordning.
Om vi exempelvis väljer att ha fyra saker från menyn med i guiden kan vi numrera stegen 1 till 4. Då stacken kommer tömmas när man går in i en ny undermeny kommer alltså aldrig två undermenyer kunna visas samtidigt. Detta gör att oavsett vilken undermeny vi ska implementera guiden i kan vi numrera första steget i den undermenyn till 5 och numrera därifrån. Frameworket Intro.js stödjer att man startar guiden på specifika steg vilket innebär att vi inte har behövt ändra någonting i frameworket.
Bild 5.7. Illustration av konceptet att vi kan återanvända samma stegsnummer för varje undermeny
34
5.5 Ändringar i planen
Efter vi hade kommit igång med implementationen av vårt projekt hade vi ett möte med DISE.
De tyckte att vår idé om hur guiden ska se ut och det frameworket vi hade valt var bra. När vi visade upp vår guide kom de anställda på att vissa saker lätt kan bli fel i guiden för att vissa saker kan ändra sig beroende på vilken användare det är som använder tjänsten. Ett exempel på detta är att olika kunder kommer ha tillgång till olika spelare. Ett annat exempel är att olika användare för samma kund kommer ha tillgång till olika menyer beroende på vilka rättigheter användaren har. DISE ville även ha möjlighet att kunna använda sig av bilder i de olika textrutorna till guiden.
Vi gjorde en bedömning att det inte är realistiskt att vi skulle hinna testa och ta till hänsyn till alla saker som kan gå fel om vi fortsätter implementera guiden enligt vår nuvarande design.
Detta skulle leda till en lång men halvfärdig guide, vi ville hellre leverera någonting som är färdigt. Vårt mål blev nu istället att fixa så att guiden förklarar huvudmenyn, bara startar första gången en användare loggar in, se till att guiden blir snygg och smälter in i resten av webbgränssnittet samt se till att det kommer vara enkelt att fortsätta bygga på guiden.
5.6 Ge kunden ett val samt ett trevligt välkomnande
För att implementera så att användaren får ett val att starta guiden eller skippa den använde vi oss av någonting som heter Modal. En Modal är ett slags popup-fönster som man kan bygga en webbsida inuti [modal]. När Modalen visas kommer resten av sidan också visas men vara lite utsuddad så Modalen blir tydligare. I vår Modal bestämde vi oss för att ha två knappar, en knapp kommer trigga guiden och den andra kommer skippa guiden. Om man väljer att skippa guiden kommer den faktiskt inte skippas helt utan kommer starta på sista steget. Detta för att sista steget berättar vart man kan trigga igång guiden senare.
35
Bild 5.8. Modalen som hälsar kunden välkommen
Koden på bild 5.9 är koden till Modalen, mellan taggarna <ReactModal> och </ReactModal>
kan man skriva HTML-kod. Denna kod kommer visas inuti modalen precis som det har gjort på bild 5.8 det är alltså här vi bestämmer hur Modalen ska se ut. Lägg märke till att två olika funktionsanrop görs beroende på vilken av knapparna användaren trycker på.
Bild 5.9. Kod för Modal. Bilden visar konceptet med att ha en webbsida inuti Modal
36
5.7 Cookies
För att lösa problemet med att guiden bara ska kunna komma upp när användaren loggar in för första gången bestämde vi i samråd med vår handledare att använda oss av Cookies.
5.7.1 Vad är en cookie?
En cookie är en slags fil som sparas på användarens dator när användaren ansluter till en webbsida som använder cookies. I en cookie kan olika sorters information lagras, syftet kan vara att komma ihåg ett språkval eller se till att användaren hålls inloggad. När användaren ansluter till webbplatsen igen skickas cookien till webbservern. Detta gör att webbservern får tillgång till den informationen som sparats ner på användarens dator[cookies].
”Cookies kan ha olika lång lagringstid, i vissa fall försvinner en cookie direkt efter webbläsaren stängts av men i vissa fall försvinner den inte försens användaren rensar ut alla cookies. En cookie som försvinner när användaren stänger av webbläsaren kallas oftast för session cookie”
[cookies].
5.7.2 Implementation av cookies
I vårt fall har vi valt att låta Cookien bestå av en textsträng som berättar om användaren har fått se guiden eller inte. Med denna lösning kommer dock användaren bli frågad om han eller hon vill se på guiden igen vid inloggning från en ny dator eller om användaren rensar sina cookies.
Vi hade kunnat lösa det genom att lägga till en variabel i databasen där användarna lagras och låta den variabeln berätta om användaren har fått se guiden eller inte och kontrollera det värdet när användaren loggar in. Men vi ansåg att det blir för mycket jobb för att slippa ett trivialt problem, då DISE kunder för det mesta är andra företag är risken stor att en företagsdator där Cookies sällan rensas används för att jobba i webbgränssnittet. Vi förklarade detta för vår uppdragsgivare och fick medgivande att använda cookies istället för att ändra i deras databas.
DISE ville även att guiden ska triggas varje gång en ny version av deras mjukvara släpps. Därför lade vi till en rad i vår cookie som lagrar vilket versionsnummer det var på mjukvaran förra gången användaren loggade in. När användaren loggar in igen kommer det lagrade numret jämföras med det versionsnummer som är aktuellt just nu och om de inte stämmer överens kommer Modal att triggas.
37
Bild 5.10. Kod för att lagra cookies
Bild 5.10 visar koden som vi har skrivit för att lagra och läsa av värdet på cookies, om ingen cookie finns lagras kommer cookiens värde bli 0. DISE använde sig redan av cookies för andra saker vilket innebär att vi egentligen inte har behövt implementera något annat än set och get- funktioner samt en kontroll på vilket värde cookien har.
5.7.3 Tolkning av lagrade cookies
Som variabelnamnen anger används modalShown för att hålla koll på om modalen har blivit visad eller inte, oavsett vilket val användaren gör kommer denna cookiens värde bli 1 när Modal stängs ner. takeTour är cookien som håller koll på vilket val användaren har gjort, när modalen stängs ner kommer en kontroll att göras. Om värdet på takeTour är 0 kommer guiden starta på sista steget. Alltså har användaren tackat nej till att gå igenom guiden men blir ändå informerad om vart man kan starta den senare.
Bild 5.11. Om användaren tackar nej kommer denna ruta upp
38
buildNum är den aktuella versionen av mjukvaran, att vi lagrar denna är på grund av att vi vill att guiden ska triggas vid varje ny uppdatering. Detta kommer kunna användas i framtiden för att göra en specialbyggd guide som bara visar vad som är nytt i den senaste uppdateringen.
Bild 5.12. Visar kontrollen för cookies
Som bild 5.12 visar kommer alla rader i cookien återställas om det gamla buildnummret inte överensstämmer med det nya. På bilden återställs alla cookies oavsett men detta är bara i rent utvecklingssyfte så att vi slipper rensa våra cookies varje gång vi vill se Modal.
5.8 Implementation av innehållet i guiden
Både vi och de anställda på DISE tyckte att rutorna för intro såg lite tråkiga ut när vi bara hade skrivit en kort förklarande text på dom. Därför implementerade vi så att vi kan rendera HTML- kod i varje introruta precis som i Modalen som vi använder i början av guiden. Efter att vi provat oss fram fann vi att om man skriver HTML-taggar i guidetexten till intro så kommer intro att tolka det som en HTML-tagg.
Om vi sätter guidetexten data-intro=”<img src=”Exempel.jpg”> Exempelbild </img>” kommer en bild med bildtexten ”Exempelbild” visas i introrutan. Detta kunde vi använda till vår fördel då vi bara behövde definiera en HTML-klass för det vi vill att introrutan ska innehålla. När vi sen skickar en pekare till denna klass som argument till intro kommer klassen renderas ut i guiderutan. Nu kan vi fylla rutan med precis vad vi vill.
39
Bild 5.13. Argument till intro, pga. sekretess visar vi inte hela HTML-taggen
HTML-filen som visas på bild 5.13 är kopplad till en JavaScript-fil som i sin tur kan ladda in HTML-klasser från andra filer. I bild 5.14 visas hur två olika HTML-klasser kopplas till en variabel.
Bild 5.14. Inladdning av HTML-klasser från en annan fil
Slutligen kan vi skapa vår HTML-kod som kommer renderas ut i introrutorna. Bilden nedan visar en HTML-klass.
Bild 5.15. HTML-koden till guidesteget som förklarar players
Denna lösning ger oss möjlighet att lätt kunna byta ut innehållet i guiden men ger oss även möjlighet att använda oss av bilder i guiden. Vi kan även koppla en CSS-fil till varje enskilt guidesteg.
40
5.9 Testning
En del av projektet som var viktigt för oss att få tid med var att testa allt det vi har gjort innan projektarbetet var klart. Detta är för att vi båda har jobbat som testare och vet hur viktigt det är att testa all kod ordentligt innan man släpper den vidare. I vår testprocess så börjar vi med att bara använda guiden vanligt och se om det finns några uppenbarliga fel. Under denna del av testprocessen så använder vi även flera olika webbläsare. Detta är för att alla webbläsare inte visar hemsidor på samma sätt.
Efter att vi arbetat bort de allra mest uppenbara buggarna så började vi testa med att slå ihop guiden med andra funktioner som finns på webbservern. Detta var saker som att köra guiden som en vanlig användare istället för administratör, ta bort permissions så att man inte har tillgång till alla delar av guiden osv. När man hittat en bugg i koden och fixat till den är det viktigt att göra om hela testprocessen igen, detta för att kontrollera att man inte påverkat någon annan del av guiden. Det var de här två stegen som vi jobbade med tills vi inte längre kunde hitta några buggar.
5.10 Kaptitelsummering
Kapitlet presenterar utvecklingsmiljön samt de olika programspråk som vi använt oss av när vi har implementerat projektet. Kapitlet presenterar även hur hemsidan är uppbyggd, hur vår första guide blev och diskuterar varför vi bytte fokus till en mindre men mer förklarande guide. Vi presenterar även hur och varför vi har använt oss av cookies för att starta guiden. Kapitlet förklarar hur vi kan rendera HTML-kod i guidens rutor samt förklarar hur vi har använt oss av en Modal för att starta guiden. Kapitlet avslutas med en förklaring över hur vi har testat vår kod.
41
6 Resultat
6.1 Introduktion
Vi skulle vilja summera resultatet med att projektet har gått bra, DISE har fått en interaktiv guide som de kommer kunna använda. Trots att guiden inte alls blev som vi hade tänkt från början är vi nöjda. Faktum är att guiden blev både enklare och bättre än vad vi hade tänkt från början.
6.2 Den färdiga guiden
Nedan följer en uppvisning av den färdiga guiden. Uppvisningen är uppdelad i tre delar där vi börjar med att visa upp hur det ser ut när kunden välkomnas, del två visar upp själva guiden och avslutande del tre visar att de cookies som vi implementerat fungerar som de ska.
6.2.1 Guidestart
Här kan vi se hur guiden ser ut när användaren loggar in för första gången, som 6.1 visar kommer användaren få ett val att antingen starta guiden eller skippa den. Om användaren redan har sett guiden och inte rensat cookies eller om det inte har kommit någon uppdatering sen användaren senast loggade in kommer denna ruta inte att visas.
Bild 6.1. Den färdiga Modalen för att starta guiden
42
Om användaren väljer att inte starta guiden så hoppar den direkt till sista steget där en informationsruta kommer upp och informerar om att guiden kan startas igen. Den visar även vart användaren i detta fall skulle behöva klicka.
Bild 6.2. Sista steget visar vart man kan starta guiden igen
På bild 6.3 tittar vi lite närmare på hur sista steget ser ut. Lägg märke till att det inte går att trycka sig vidare i guiden, dock kan man gå igenom guiden baklänges. Vi kan välja att inte låta användarna gå igenom guiden baklänges men av praktiska skäl har vi valt att låta dem göra det.
Detta för att sista steget kommer användas oavsett om användaren vill se guiden eller inte. Det innebär att om vi väljer att inte låta användarna göra detta kommer den funktionen att behöva stängas av för båda alternativen. Vi tyckte det var dumt ifall användaren råkar klicka förbi något och vill klicka tillbaka.
Bild 6.3. Närmare titt på introrutan i bild 6.2
43
6.2.2 Slutresultat guide
Såhär ser själva guiden ut när man startat den. Som bilderna visar kommer de olika stegen ha en text som förklarar vad som händer om man trycker på just den menyn som guiden förklarar, guiden har även en slider där bilder visas.
Bild 6.4. Första rutan i den färdiga guiden
På bild 6.4 visas den första rutan som användaren kommer se när guiden startat. Textrutan har en bildslider och två paragrafer förklarande text. Den nedre paragrafen är kopplad till bildslidern. Under bildslidern finns två knappar, dessa används för att byta bild. Rutan har tre knappar där två används för att bläddra mellan guidens olika steg och en används för att avbryta guiden. Här är tillbakaknappen nedtonad på grund av att det inte finns något tidigare steg.
Bild 6.5. När användaren har tryckt på sliderknappen
44
Bild 6.5 visar hur guiden ser ut efter användaren tryckt på ena sliderknappen. Bilden i slidern har bytts ut till en annan bild och texten i den nedre paragrafen har bytts ut mot en text relevant till bilden. Detta tillåter DISE att göra en förklarande guide utan att någon undermeny behöver öppnas. Då de objekt i menyn som förklaras alltid kommer vara på samma ställe och se lika ut för alla användare är risken att någonting går fel väldigt liten jämfört med om vi hade öppnat en undermeny där saker kan se olika ut för olika användare.
Bild 6.6. När användaren gått vidare till nästa steg.
Bild 6.6 visar när användaren gått vidare till nästa steg, Nästa objekt i menyn har markerats och allt innehåll i guiderutan har bytts ut mot nytt innehåll. Lägg märke till att tillbakaknappen inte längre är nedtonad, detta på grund av att vi nu har ett steg att gå tillbaka till. På de tre bilderna som visar resultatet av guiden ligger det bara två bilder i slidern, det finns ingen begränsning på hur många bilder som går att läggas till om vi eller DISE skulle vilja bygga ut guiden i ett senare skede. Värt att notera dock att eftersom nedersta textparagrafen är kopplad till bildslidern kommer man behöva definiera en ny text för varje bild.
Guiden förklarar givetvis fler saker än de som vi tar upp här men då resten av guiden principiellt sett gör samma sak som det vi hittills visat fast med annat innehåll känns det överflödigt att visa upp resten av guiden.
45
6.2.3 Cookielagring
Här visar vi upp resultatet av cookies, för att visa vilka cookies som finns lagrade just nu kan vi skriva localStorage i Google Chromes konsol. I detta fall har användaren loggat in för första gången och inga cookies finns lagrade, det innebär att Modal kommer triggas.
Bild 6.7. Modal med cookies när användaren loggar in första gången.
Bild 6.8 visar hur cookies ser ut om användaren valt att gå igenom guiden, som vi kan se är både modalShown och takeTour satt till 1. Vi vet nu alltså att våra cookies lagras som de ska.
Bild 6.8. cookies när användaren valt att gå igenom guiden
46
När användaren loggar in eller uppdaterar sidan igen kommer inte Modal att visas, detta beror på att modalShown har blivit satt till 1. Som vi visar i kapitel 5.6 kommer en kontroll göras innan React returnerar Modal från klassen Welcome, denna kontroll kommer nu bli falsk och istället returneras bara en tom div-tag[div]. Som vi kan se funkar alltså våra cookies som planerat.
Bild 6.9. Cookies när användaren har varit inloggad förut
6.3 Kaptitelsummering
Vi börjar kapitlet med en kort diskussion om vad vi tycker om resultatet, vi visar upp guidens Modal, själva guideinnehållet samt att cookielagringen fungerar som den ska.
47
7 Utvärdering av arbetet
7.1 Summering av arbetet
Arbetet har i helhet gått bra, det var väldigt svårt för oss att förstå koden i början. Detta dels på grund av att det inte är vi som skrivit koden från början så vi visste inte vad de olika delarna var. Det var även väldigt mycket kod och nya tekniker som vi aldrig arbetat med förut. Under arbetets gång har vi för enkelhetens skull alltid suttit på DISE kontor när vi programmerat, detta för att vi ansåg att det skulle vara lättare att få hjälp och kunna ställa frågor till uppdragsgivaren.
Vi har även haft möjlighet att hålla kontakten med alla de anställda på DISE genom en plattform som heter slack. I början satt vi väldigt mycket var för sig för att kunna fördjupa oss i de olika teknikerna som vi visste att vi skulle behöva jobba med, detta kändes nödvändigt då vi ville vara så förberedda som möjligt innan vi började med själva implementeringen.
7.2 Problem som uppstått i arbetet
Vi har inte haft jättemycket problem men det har ändå uppstått några. Som vi nämnde i rapporten blev hela vår idé ändrad på grund av att det inte var realistiskt att hinna implementera så mycket som vi ville av guiden. Önskemålen från uppdragsgivaren ändrades också något under arbetes gång vilket gjorde att vi fick tänka om lite.
7.2.1 Installation av server
Ett problem som vi hade från början var att komma igång, detta var på grund av att DISE har sin egen serverklient som vi var tvungen att lära oss att använda innan vi kunde komma igång med projektarbetet. Detta innebar att vi var tvungna att installera en lokal version på våra datorer som vi kunde arbeta i. Då servern var svår att installera och det inte fanns någon bra dokumentation på hur man installerar den frågade vi de anställda på DISE om hjälp.
7.2.2 Installation av frameworks
Vi stötte även på mycket problem när vi skulle installera de frameworks som vi tänkte använda oss av, det som vi hade mest problem med att installera var förmodligen React-joyride. Vi valde tillslut att inte använda React-joyride på grund av att det var för krångligt att installera i DISE kodbas, vi valde ett annat liknande bibliotek istället som inte krånglade alls under installationen.
48
7.2.3 Designmässiga problem
När vi implementerat guiden har vi ofta haft problem med att få guiden att visas som vi vill.
Detta har inneburit till exempel att guiderutorna hamnar på fel ställe, innehållet i guiden har visats utanför guiderutan och vi har inte fått knapparna till bildslidern att sammarbeta med textslidern.
7.3 Vad kommer vi göra annorlunda i framtiden?
I framtiden kommer vi förmodligen inte fokusera så mycket på vad tidigare kod använder sig av för tekniker. I detta projekt används mycket React så vi tänkte att då kommer det naturligtvis bli mycket smidigare om vi använder oss av ett framework som också är skrivet i React. Vi märkte ganska fort att det inte nödvändigtvis behöver vara så. Vi kommer förmodligen också börja koda tidigare istället för att fokusera så mycket på att läsa exempelkod. Detta för att vi märkte att man lär sig mycket snabbare genom att skriva kod än att läsa kod även om man skriver fel många gånger innan man förstått hur det fungerar.
Vi kommer även vara bättre med att fråga om hjälp när det kommer till enkla saker som har arbetat med detta förmodligen kan svara på istället för att själva försöka hitta en lösning. Ett bra exempel på detta är problemet som vi tidigare nämnde med serverinstallationen, hade vi frågat om hjälp tidigare hade vi haft mer tid för kodning.
7.4
Vad kan vi ta med oss från detta projekt?Den mest praktiska saken som vi kan ta med oss är att vi har fått mer erfarenhet av att använda olika programspråk som bland annat JavaScript. Vi har även lärt oss hur man arbetar inom ett projekt på ett företag, hur det är viktigt att ha möten och få alla avdelningars input över vad slutresultatet av projektet ska vara. Vi har även lärt oss att det är viktigt att planera hela eller delar av projektet innan man börjar implementera.
7.5 Kaptitelsummering
Kapitlet summerar våra tankar och reflektioner kring hur vi tycker arbetet har gått, vilka problem vi stött på och vad vi kommer göra annorlunda i framtiden. Vi pratar även om vad vi tycker att vi kan ta med oss från detta projekt
49
8 Källförteckning
[Atom] https://atom.io/
[Atom2] https://en.wikipedia.org/wiki/Atom_(text_editor) [React] https://facebook.github.io/React/
[Backbone] http://Backbonejs.org/
[Modal] https://github.com/Reactjs/React-modal [Es6] http://exploringjs.com/es6/
[Cookies] https://sv.wikipedia.org/wiki/Webbkaka [Wow] https://worldofwarcraft.com/en-gb/
[Html] https://en.wikipedia.org/wiki/HTML
[html2] http://groups.engin.umd.umich.edu/CIS/course.des/cis400/html/html.html [Css] https://sv.wikipedia.org/wiki/Cascading_Style_Sheets
[intro] http://intro.js.com/#commercial [js] https://en.wikipedia.org/wiki/JavaScript [div] https://www.w3schools.com/tags/tag_div.asp [t&e] https://en.wikipedia.org/wiki/Trial_and_error
50
9 Bilagor
9.1
Bilaga A: ProjektspecifikationImplementering av en interaktiv användarguide för ett webbgränssnitt
Fredrik Sjökvist Johan Stenström
DISE international AB är ett företag som sysslar med digital signage dvs digital skyltning. Vi har fått i uppdrag att implementera en interaktiv användarguide till deras webbgränssnitt. Vi kommer behöva göra en undersökning där vi kommer föra en logg över i vilken del av användargränssnittet som DISE kunder jobbar mest men vi kommer även göra en undersökning där vi låter studenter som aldrig använt DISE försöka lösa vissa problem på egen hand. Detta för att samla in data om kundernas beteende när de inte fått nog tydliga instruktioner. Den interaktiva guiden kommer visas första gången en användare loggar in i webbgränssnittet men det kommer även finnas en knapp för att se guiden igen. Beroende på resultatet från våra undersökningar kommer vi antingen implementera en stor guide där hela guiden visas så fort den blivit triggad eller så kommer vi implementera flera små guider där relevant del kommer triggas första gången man går in på en ny del av webbgränssnittet.
Vi kommer påbörja projektet med att göra vår undersökning samt skissa hur guiden kommer se ut, under denna period kommer vi även undersöka vilka färdiga frameworks vi har möjlighet att arbeta med samt undersöka hur andra har implementerat liknande guider. Efter godkännande av DISE kommer vi börja implementera guiden
När vi implementerar guiden kommer vi använda oss av JavaScript. Guiden kommer först att skrivas som ett separat projekt och sedan integreras i DISE kod. Detta för att vår handledare
51
tycker att det vore mer effektivt då vi inte behöver sätta oss i deras kodbas utan kan börja implementera direkt
