i

Digital Konferenslösning

Ett mediadistribueringsverktyg och presentationssystem för digital skyltning.

Digital Conference Solution

A media distribution system and presentation system for digital signage.

Anton Odén

Olle Pejstrup

Fakulteten för hälsa, natur- och teknikvetenskap

Datavetenskap

C-uppsats 15hp

Handledarens namn: Katarina Asplund

Examinator: Donald F. Ross

Oppositionsdatum: 2016-01-21

ii

Sammanfattning

Gustaf Fröding hotell behöver en smidigare lösning för att uppdatera och visa information om

konferensbokning. De använder sig idag papperskyltar för att informera och vägleda kunder

till konferensrummen. Pappersskyltarna ska ersättas med surfplattor för att bland annat ge

bättre intryck på deras kunder. Surfplattorna behöver en applikation för att ta emot och visa

materialet. Vi utvecklade en prototyp för detta ändamål som sedan ska användas för

vidareutveckling av systemet. Denna uppsats beskriver vår utveckling av denna applikation.

Resultatet blev en webbapplikation skriven i ASP.NET MVC som är baserad på Gustaf

Fröding hotells behov. Webbapplikationen har administrativa funktioner för sammansättning

av media, vilket skapar presentationer. Surfplattor kopplar upp sig till webbapplikationen via

en unik URL som visar tilldelad presentation. Applikationen levererades och beslutet om

vidareutveckling är ännu inte bestämt.

iii

Abstract

Gustaf Fröding hotel needs a smother agile solution for updating and displaying the

information on conference booking. They currently use paper signs to inform and guide

customers to the conference rooms. These paper signs are going to be replaced by tablets to

create a better impression for their customers. The tablets need an application for receiving

and displaying material and we developed a prototype for this purpose. This prototype will be

used for further development of the system. This dissertation describes our development of

this application.

The result of the project is a web application written in ASP.NET MVC based on Gustaf

Fröding hotels requirements. The web application has administrative functions for the

composition of media, creating presentations. Tablets connect to the web application via a

unique URL that displays the assigned presentation. The application was delivered but the

decision of further development has not yet been made.

iv

Innehållsförteckning

Sammanfattning ......................................................................................................................... ii

Abstract ..................................................................................................................................... iii

Figurer ..................................................................................................................................... viii

Tabeller ...................................................................................................................................... ix

1 Introduktion ......................................................................................................................... 1

1.1 Syfte & mål .................................................................................................................. 2

1.2 Resultat ........................................................................................................................ 2

1.3 Disposition ................................................................................................................... 3

2 Bakgrund ............................................................................................................................. 4

2.1 Digital Skyltning .......................................................................................................... 4

2.2 Kravhantering .............................................................................................................. 5

2.3 Verktyg ........................................................................................................................ 8

MVC ..................................................................................................................... 8

ASP.NET .............................................................................................................. 8

Visual Studio ........................................................................................................ 9

Team Foundation Server ...................................................................................... 9

Entity Framework ................................................................................................. 9

Draw.io ................................................................................................................. 9

Jquery ................................................................................................................. 10

Bootstrap ............................................................................................................ 10

2.4 Sammanfattning ......................................................................................................... 10

3 Förundersökning ............................................................................................................... 11

3.1 Typ av applikation ..................................................................................................... 11

Ren applikation .................................................................................................. 11

Webbapplikation ................................................................................................ 12

Hybridapplikation ............................................................................................... 14

v

Val ...................................................................................................................... 14

3.2 Redigeringsverktyg .................................................................................................... 15

Skrivbordsredigering .......................................................................................... 15

Webbredigering .................................................................................................. 17

Val ...................................................................................................................... 21

3.3 Kioskläge ................................................................................................................... 21

Test av kiosklägeapplikationerna ....................................................................... 21

3.4 Förundersökningens slutsats ...................................................................................... 24

4 Projektdesign ..................................................................................................................... 25

4.1 Enheter ....................................................................................................................... 25

Administrations-klient (aklient) ......................................................................... 25

Visnings-klient (vklient) .................................................................................... 25

Webbserver ......................................................................................................... 26

Systemdesign ...................................................................................................... 26

4.2 Terminologi ............................................................................................................... 27

Slide .................................................................................................................... 27

Spellista .............................................................................................................. 27

Story ................................................................................................................... 27

4.3 Databasdesign ............................................................................................................ 28

Tabellbeskrivning ............................................................................................... 28

4.4 Kodstruktur ................................................................................................................ 30

Service ................................................................................................................ 30

Domain ............................................................................................................... 31

Web .................................................................................................................... 32

Data .................................................................................................................... 32

5 Implementation ................................................................................................................. 33

5.1 Grafiskt användargränssnitt ....................................................................................... 33

vi

Simpel Vy ........................................................................................................... 33

Avancerad Vy ..................................................................................................... 37

5.2 Uppladdning av material ........................................................................................... 38

5.3 Visning av media ....................................................................................................... 39

Backend .............................................................................................................. 40

Visningspresentation Frontend ........................................................................... 41

5.4 Code First .................................................................................................................. 42

5.5 Problem ...................................................................................................................... 43

Testning .............................................................................................................. 44

Nuget Error ......................................................................................................... 44

6 Resultat ............................................................................................................................. 45

6.1 Översikt ..................................................................................................................... 45

6.2 Kravuppfyllelse ......................................................................................................... 47

Krav som uppfylldes .......................................................................................... 47

Krav med lägre prioritet som påbörjades ........................................................... 48

6.3 Kundnöjdhet .............................................................................................................. 48

6.4 Tekniker och verktyg ................................................................................................. 48

7 Utvärdering ....................................................................................................................... 50

7.1 Tidsåtgång ................................................................................................................. 50

7.2 Arbetsmiljö ................................................................................................................ 50

7.3 Lärdomar ................................................................................................................... 51

Kravspecifikation ............................................................................................... 51

Verktyg ............................................................................................................... 51

Förundersökning ................................................................................................. 52

Kundkontakt ....................................................................................................... 52

7.4 Vidareutveckling ....................................................................................................... 52

Inloggning och konton ....................................................................................... 52

vii

Grafiskt användargränssnitt ................................................................................ 53

8 Avslutning ......................................................................................................................... 54

9 Referenser ......................................................................................................................... 55

viii

Figurer

Figur 2-1. Symbolisk bild för funktioners prioritet i systemet. ................................................................................. 5

Figur 3-1. Spara presentationer i Strut som JSON-objekt. ..................................................................................... 19

Figur 3-2. Strut översikt. ........................................................................................................................................ 19

Figur 3-3. Exempelkod på SMIL-strukturen. .......................................................................................................... 20

Figur 3-4, Kiosk Browser Lockdowns gratisversion................................................................................................ 23

Figur 3-5, Kiosk Browser Lockdown med premium. .............................................................................................. 23

Figur 4-1. Bildrepresentation av administrationsklienten. .................................................................................... 25

Figur 4-2. Bildrepresentation av visningsklienten. ................................................................................................ 26

Figur 4-3. Bildrepresentation av webbservern. ..................................................................................................... 26

Figur 4-4. Exempelbild över systemdesign. ........................................................................................................... 27

Figur 4-5. Ett enkelt ER-diagram över databasens struktur. ................................................................................. 28

Figur 4-6. Kodstruktur överblick ............................................................................................................................ 30

Figur 4-7, Kodstruktur Servicemodul ..................................................................................................................... 31

Figur 4-8, Kodstruktur Domainmodul .................................................................................................................... 31

Figur 4-9, Kodstruktur Webmodul ......................................................................................................................... 32

Figur 4-10, Kodstruktur Datamodul och kodexempel ........................................................................................... 32

Figur 5-1. Simpel Vy-sidan på webbplatsen. ......................................................................................................... 33

Figur 5-2. Allt som visas på Simpel Vy. .................................................................................................................. 34

Figur 5-3. I Simpel Vy med val av vyklient. ............................................................................................................ 34

Figur 5-4. Redigering av vklient. ............................................................................................................................ 35

Figur 5-5. Lägga till spellista till vklient. ................................................................................................................ 35

Figur 5-6. I Simpel Vy vid val av spellista. .............................................................................................................. 36

Figur 5-7. Redigering av spellista. ......................................................................................................................... 36

Figur 5-8. Lägga till slide till spellista. ................................................................................................................... 37

Figur 5-9. Lisa över Vklienter i Avcancerad Vy. ..................................................................................................... 37

Figur 5-10. Länkning Mallar och filer efter uppladdning. ...................................................................................... 38

Figur 5-11. Representation av spellista. ................................................................................................................ 39

Figur 5-12, Spelordningen för en spellista som innehåller en annan spellista. ..................................................... 39

Figur 5-13. Controller. ........................................................................................................................................... 40

Figur 5-14. Slideview-objekt. ................................................................................................................................. 40

Figur 5-15. View. ................................................................................................................................................... 41

Figur 5-16. Presentation javascript. ...................................................................................................................... 42

Figur 5-17. De entitetsklasser som Entity Framework använder sig av för att generera databasen. ................... 43

Figur 5-18. Exempel på hur en av en entitetklasserna är uppbyggda. .................................................................. 43

Figur 5-19. Figuren visar hur konfiguration mellan två tabeller sker i Entity Framework Fluent API. .................. 43

Figur 6-1. Konvertering av en PowerPoint-presentation till bilder. ....................................................................... 45

Figur 6-2. Flödesschema över användarens interaktion med systemet. ............................................................... 46

ix

Tabeller

Tabell 1. Lista av funktioner från Kravspecifikation _________________________________________________ 8

Tabell 2. Webbläsarandelar för stationära enheter. _______________________________________________ 13

Tabell 3. Webbläsarandelar för mobila enheter. __________________________________________________ 13

Tabell 4. Lista över vilka krav som uppfylldes. ____________________________________________________ 47

Tabell 5. Tidfördelning mellan uppsatsskrivning, programmering och förundersökningen._________________ 50

1

1 Introduktion

Projektet beskrivet i denna rapport togs fram i samarbete med Gustaf Fröding hotell i Karlstad

vilka efterfrågade en lösning för informationsvisning utanför deras konferensrum. Hotellet har

strax över hundra gästrum och nio stycken konferensrum. Temat på hotellet är delvis från den

svenska författaren Gustaf Fröding och diverse rum och salar är namngivna efter platser

relaterade till Gustaf Fröding.

Hotellets konferensrum har alla pappersskyltar som vid bokning uppdateras med den

bokandes företagsnamn. Projektet är ämnat att testa en digital lösning för att förenkla och

förbättra uppdatering av information framför konferensrummen. Gustaf Fröding hotell har

tidigare undersökt flera lösningsalternativ för detta ändamål, men dessa har ansetts vara för

dyra för att köpas in till ett medelstort hotell som Gustaf Fröding. De flesta lösningar

innehåller också mycket komplexitet i sina distribueringssystem av media; animationer,

transaktioner, positionering av visningsobjekt med mera, vilket kan vara en orsak till de höga

kostnaderna.

Genom att ersätta dessa pappersskyltar med digitala skärmar kan information som t.ex.

företagsnamnen uppdateras enklare och snyggare, eftersom uppdateringen kan ske på distans

och man kan använda sig av animationer och bilder. När konferensrummen är lediga kan

information om hur man bokar konferensrummen och även övrig information riktat till

hotellets gäster visas. Detta ger en mer levande upplevelse och lockar gästerna till att se och ta

till sig hotellets utbud av tjänster och produkter.

Informationen ska kunna uppdateras på distans utan att personal behöver förflytta sig till varje

konferensrum, genom att uppdateringen sker via nätverket. En annan fördel med en digital

lösning är att hotellet slipper utskrivning av pappersskyltar med skrivaren.

I denna uppsats kommer vi att beskriva det system som vi utvecklade med den funktionalitet

som efterfrågades.

2

1.1 Syfte & mål

Lösningen som Gustaf Fröding hotell sökte var ett distribueringssystem som främst fokuserar

på visning av enklare media. Exempelvis att enbart en statisk informationsbild visas på

skärmen som kan bytas till en annan statisk informationsbild med en transaktionsanimation

emellan.

Gustaf Fröding hotell önskade också förslag på väggmontering och surfplattor för inköp. För

att ingen stöld av surfplattor på väggen skulle ske önskades också ett stöldskydd. Hur vi

utarbetat dessa förslag har exkluderats från rapporten då det inte ansågs relevant för

uppsatsen.

Vi estimerade att utvecklingstiden av systemet uppskattades att överskrida den tillgängliga

tiden för examensarbetet. Eftersom kunden ville ha kvar mycket av funktionalitet i systemet

gjordes därför en förundersökning av liknande lösningar där målet med förundersökningen

var att hitta ett befintligt system som sedan skulle vidareutvecklas för att kunna appliceras på

vårt system.

Slutmålet med projektet var att skapa en prototyp för Android surfplattor som kunde köras på

deras befintliga server.

1.2 Resultat

Resultatet blev en webbapplikation där bilder och Youtubeklipp kan kombineras för att skapa

presentationer som kan presenteras i webbläsaren. Ett redigeringsverktyg för

presentationsmedia utvecklades dock inte och Gustaf Fröding hotell hänvisades till

användning av Microsofts presentationsprogram PowerPoint för att skapa presentationsbilder.

3

1.3 Disposition

I kapitel 1 ges en kort introduktion till projektet.

I kapitel 2 ges en detaljerad bakgrund och översikt av projektets delar. Kapitlet beskriver

också olika verktyg som användes.

I kapitel 3 beskriver förundersökningen som gjordes i början av projektet och de beslut som

togs efter informationsinsamlingen. Här undersökte vi vilken typ av applikation som skulle

utvecklas och testade relaterande applikationer.

I kapitel 4 beskrivs de olika designdelarna av projektet, som infrastrukturdesign,

databasdesign, och kodstruktur.

I kapitel 5 går vi igenom några intressanta lösningar som vi utvecklade vid implementation av

systemet.

I kapitel 6 presenteras resultatet från projektet.

I kapitel 7 utvärderas resultatet från projektet.

Kapitel 8 innehåller vår avslutning av denna uppsats.

4

2 Bakgrund

Detta kapitel innehåller diverse bakgrundsinformation till projektet. I avsnitt 2.1 beskrivs

digital skyltning och dess historia. I avsnitt 2.2 sammanfattas kravhanteringen och i avsnitt

2.3 ges en sammanfattning av diverse verktyg som använts i projektet.

2.1 Digital Skyltning

Digital skyltning [1] består av en enhet som presenterar media dynamiskt. Enheten kan bestå

av en eller flera olika typer av digitala skärmar, vilka är placerade så att

presentationsmaterialet når sin målgrupp på offentliga platser. Tekniken uppstod tillsammans

med när TV-apparater blev vanliga i hushåll. Vid distribution av media behövs först en

mjukvara för redigering av visningsmaterial och sedan en mjukvara för hur materialet ska

visas. Mjukvarorna kopplas samman av ett nätverk. Skärmarnas visningsinformation baseras

på den plats som TV-apparaten är placerad på, där målgruppen befinner sig. T.ex. en TV-

skärm i ett shoppingcenter som riktar sig till shoppingintresserade och visar extraerbjudande

för shoppingcentret.

Enligt Mike Strand [2] är distribueringssystemet den största kostnaden i ett digitalt

skyltningsnätverk och hårdvarukostnaden till digital skyltning är oftast bara en liten del av

totalkostnaden för lösningen. Med internet var det möjligt att spara en stor kostnad för

kunderna, eftersom kunderna nu själva enklare kunde uppdatera innehållet för sina enheter via

inskickning av mediamaterial via email och efter ett par års tid även genom webbplattformar.

Vid användning av webbplattformar blev det enklare att uppdatera media på skärmarna. Innan

var man tvungen att vänta på distribueringsansvarigas godkännande och uppdatering.

Idag finns en del implementation av digital media till surfplattor men det är inte särskilt

vanligt då surfplattornas skärmstorlek är relativt liten (7″-13″). Eftersom skärmarna är mindre

ser färre antal personer den media som visas. Exempelvis texter blir svårt att läsa på långt

avstånd på grund av surfplattors skärmstorlek. Det hittas dock fler och fler

användningsområden för surfplattor, t.ex. tavlor.

5

2.2 Kravhantering

Vid starten av projektet diskuterade vi med representanter från Gustaf Fröding om olika

funktionaliteter som systemet behövde och därefter delades funktionaliteterna upp i tre

stycken prioriteter (se Figur 2-1). Detta gjordes främst för att funktioner som var viktigast för

Gustaf Fröding hotell skulle bli klara först och för att lämna tid åt viktigare korrigeringar av

huvudfunktionerna innan utveckling av mindre viktig funktionalitet började. Dessa samlades i

en kravspecifikation.

Kravspecifikationen innehåller en lista över funktionalitet som önskades i systemet samt en

kort förklaring av varje funktionalitet. Listan på funktionalitet går att finna i Tabell 1.

Figur 2-1. Symbolisk bild för funktioners prioritet i systemet.

Utvecklingen bedrevs inifrån och utåt: funktionerna i det gula området (Prioritet 1) är

funktioner som måste implementeras och därefter följer de röda funktionerna (Prioritet 2) som

bör implementeras. Blåa funktioner är extrafunktioner (Prioritet 3) som är potentiella

uppgifter för framtida utveckling. Nedan följer en tabell på de funktioner som Gustaf Fröding

fick prioritera (se Tabell 1). Tabellen innehåller kolumnerna funktion, storypoints, prioritet

(se Figur 2-1) samt beskrivning av funktion.

Storypoints1 (se Tabell 1) är tänkt att eventuellt ändra projektbeställarens val av prioriteringar

och själva uttrycket Storypoints härstammar från hjälpmedlet Scrum [3]. Siffran representerar

ett fiktivt tidsmått och används vid diskussion av prioritetsättning med kund. Ett fiktivt

tidsmått gör det enklare för kunden att fokusera på prioritering och inte bli distraherad av

exakta tider men ändå få en uppfattning om varje storys omfattning. Storypoints representerar

tidsrelationer mellan funktioner. T.ex. funktionen Uppdatera presentation uppskattades till 25

1 Storypoints är en siffra som representerar hur lång tid (fiktivt) vi trodde att funktionen skulle ta att utveckla.

6

Storypoints att utveckla och Lista med anslutna uppskattades till 15 Storypoints. Uppdatera

presentation uppskattades därmed till att ta cirka 1.67 gånger längre tid att utveckla.

Funktion Storypoints Prioritet Beskrivning

Helt Kioskläge 10 1 Surfplattan ska vara låst och ge begränsade

interaktionsmöjligheter. Ingen interaktion

med surfplattan i form av touch eller

knappar ska kunna ske om man inte vet om

pinkoden som låser upp kioskläget.

Uppdatera

presentation

25 1 Surfplattan ska kunna uppdatera den

information som visas utan att t.ex. en

laddningsikon syns på visningsklienten.

Lista med

anslutna

15 1 Administrationen får reda på att en ny

visningsklient har anslutits och listar de

visningsklienter som är anslutna.

Nytt

visningsmaterial

35 1 Tillagt material på administrationen

distribueras automatiskt till de

visningsklienter som administratören valt

att det ska visas på.

Schemaläggning

av

presentationer

30 1 Möjlighet att schemalägga när

presentationer visas. (t.ex., klockan 11.30

vardagar visas luncherbjudande.)

Installation av

webbserver

40 1 Installera mjukvaran på server. Sker i slutet

av projektet.

Stöd för ställ 15 1 Undersök olika typer av väggmonteringar

för surfplatta.

Mallar 25 2 När en befintlig mall ändras så ska

visningsklienterna uppdateras efter den nya

mallen.

Mörklägga

enheter

5 2 Via administrationsklienten ska val för att

specifika visningsklienter inte ska visa

någonting finnas. T.ex. Gustaf Frödings

logotyp visas eller att skärmarna är helt

svarta.

7

Säker omstart 10 2 När surfplattan oväntat stänger av sig (t.ex.

får slut på ström) ska presentationen

återuppta visningen när surfplattan startas

igen.

Videovisning 20 2 Uppspelning av video ska fungera och de

ska automatiskt spelas. En video kan laddas

upp eller vara Youtubeklipp.

Installations

media

40 2 Visningsklienter installeras automatiskt

genom en länk från servern.

Autentisering 25 2 Inloggning för att kunna administrera

visningsklienternas material. Flera olika

konton och personer ska ha tillgång till

samma visningsklienter med

redigeringsbehörighet.

Multiförhandsgr

anskning

av

presentationer

8 2 En liveöverblick som till sitt utseende ser ut

som ett kameraövervakningssystem.

Överblickar allt visningsmaterial från en

vy.

Konfiguration 15 3 När en visningsklient ska konfigureras så

går man in på en länk med visningsklienten

och där ges en säkerhetsfråga för att ingen

annan ska kunna ansluta.

Prestationstest 40 3 Visningsklienterna skickar information till

administrationen om deras status,

temperatur, CPU, etc. Administrationen ger

en överblick över alla visningsklienter och

deras status.

Fjärrstyrning 30 3 Vid drift ska eventuella fel kunna sökas och

fixas på distans.

Interaktion 30 3 Surfplattan går att interagera med på några

förvalda sätt. T.ex. byte av slide.

Animationer 50 3 Det finns stöd för att presentationsbilderna

innehåller animationer.

8

Koppling med

bokning

n/a 3 Gustaf Frödings bokningssystem kan

kommunicera med projektet. T.ex. när en

bokning sker i Gustaf Frödings Hotells

bokningssystem så uppdateras

presentationerna som visar bokningar.

Tabell 1. Lista av funktioner från Kravspecifikation

2.3 Verktyg

I detta avsnitt ges en genomgång av de verktyg som använts i projektet. I avsnitt 2.3.1

beskrivs designmönstret MVC och ramverket ASP.NET presenteras i avsnitt 2.3.2. Om

utvecklingsmiljön Visual studio kan vi läsa i avsnitt 2.3.3 och i avsnitt 2.3.4 ges en

beskrivning av Team Foundation Server. I avsnitt 2.3.5 beskrivs Entity Framework och i

avsnitt 2.3.6 beskrivs Draw.io. I avsnitt 2.3.7 ges information om Jquery och i sista avsnittet

2.3.8, beskrivs Bootstrap.

MVC

MVC [4] är ett designmönster där ett program separeras i tre sammanhängande komponenter

Model, View och Controller. View-komponenten hanterar användargränssnittet och

Controller-komponenten agerar på användarens interaktion. Controllern hanterar också den

mottagna informationen och delegerar vidare till View eller Model. Model-komponenten

hanterar all logik och data.

Uppdelningen av ett program i flera separata komponenter gör det enklare att underhålla

större program samt gör så att personer i större utvecklingsteam kan fokusera på olika

komponenter utan att veta om hur andra komponenter fungerar. Detta kallas för ”Separation

of concerns” [5].

ASP.NET

ASP.NET [6] är ett ramverk utvecklat av Microsoft för utveckling av dynamiska

webbapplikationer. .NET bygger på Common Language Runtime vilket möjliggör för

utvecklaren att programmera i valfritt språk som stöds av .NET, till exempel c#, VB.NET och

Lisp [7].

9

Visual Studio

Microsoft Visual Studio 2015 [8] Enterprise är utvecklingsverktyget som använts för

framställning av webbsidor, webbapplikationer, webbtjänster och program för Microsofts

olika Windows-operativsystem. De olika programspråk som stöds är C, C++, C#, F#, Python,

och Ruby med flera.

Med Visual Studio 2015 lades in stöd för utveckling i andra operativsystem utöver Microsofts

olika versioner av operativsystemet Windows. [9]

Team Foundation Server

Team Foundation Server [10] är en Microsoftprodukt som finns till för att underlätta för

utveckling. Produkten innehåller flera verktyg, till exempel för planering, rapportering,

testning och versionshantering.

I det här projektet så har Team Foundation Server används tillsammans med Visual Studio (se

avsnitt 2.3.3) för att sköta versionshanteringen av källkoden.

Entity Framework

Entity Framework [11] är en uppsättning av verktyg för objekt/relationsmappning skapat av

Microsoft. Objekt/relationsmappning kopplar ihop bakomliggande databastabeller med

klasser. Detta sparar tid för utvecklaren som kan koncentrera sig på att skriva domänspecifika

klasser och sedan låta Entity Framework koppla samman dessa domänklasser med en

underliggande databas. Code First [12] introducerades i Entity Framework 4.1 och gör att

utvecklaren inte behöver designa den bakomliggande databasen. Entity Framework skapar

databasen och använder domänklasserna och utvecklarens konfigurationsklasser för att skapa

databasens tabeller.

Draw.io

Draw.io [13] är en webbapplikation för framställning av bilder och modeller. Draw.io har

många fördefinierade bilder, tabeller och modeller som gör skapandet enklare och snabbare.

Detta verktyg har använts för framställning av diverse bilder och modeller.

10

Jquery

Jquery [14] är ett javascriptbibliotek som bygger DOM2-objekt som är ett sätt att formulera

alla element på en webbsida i en trädstruktur. Jquery förenklar mycket av javascripten som att

skala ner på den mängd kod man behöver skriva för att åstadkomma samma sak i JavaScript.

Jquery använts i drygt 65% av alla webbsidor idag [15] och är gratis att använda.

Bootstrap

Bootstrap [16] är ett ramverk för utveckling av responsiva webbtjänster. Bootstrap innehåller

HTML- och CSS-baserade mallar för knappar, typografi, navigering, m.m. Ramverket är till

för framställning av gränssnittet på klientsidan.

2.4 Sammanfattning

Detta kapitel har gått igenom diverse bakgrundsinformation till projektet. Digital skyltning

har beskrivits samt hur vi samlat och behandlat kravhanteringen har diskuterats. Några av de

verktyg som använts i projektet har också beskrivits.

2 DOM är ett språkgränsnitt som används för att skapa och kommunicera med objekt i ett dokument. Används

främst inom HTML och XHTML och XML.

11

3 Förundersökning

I förundersökningen undersöktes i huvudsak två delar; vilken typ av applikation samt vilket

redigeringsalternativ för presentationer som lämpar sig bäst för projektet. I avsnitt 3.1

beskrivs undersökningen av applikation och i avsnitt 3.2 redigeringsalternativen. En tredje

förundersökningen som gjorts på kioskläge finns i avsnitt 3.3.

3.1 Typ av applikation

Vid utveckling av en applikation för en surfplatta finns det olika tillvägagångssätt. Ett sätt är

att använda en ren applikation3 som installeras direkt på enheten baserad på enhetens

operativsystem via en applikationsmarknad4. Ett annat sätt är att utveckla en webbapplikation

som nås genom en domän. Surfplattan behöver då nå domänen via en webbläsare.

Alternativt kan en hybrid mellan de två föregående alternativen användas, där applikationen

distribueras som en ren applikation men är programmerad som en webbapplikation [17].

Ren applikation

En ren applikation är installerad direkt i operativsystemet, där av behöver den också vara

utvecklad i ett språk som operativsystemet stödjer. När det kommer till mobila plattformar är

det surfplattor med iOS, Android eller Windows som har undersökts. De språk som stöds på

de olika operativsystemen är:

Android: Java [18].

iOS: ObjectiveC och Swift

Windows: C# och C/C++

Att distribuera en ren applikation kan göras på flera sätt och olika plattformar har stöd för

olika många metoder. De metoder som stödjs är följande:

Appbutik: Den applikationsbutik som är kopplat till operativsystemet som är

installerat. Exempel på appbutiker är Google Play och App Store.

3 En ren applikation är en applikation som är utvecklad för ett specifikt operativsystem. (Engelska: Native

application.) 4 Applikationsmarknadsplats – En tjänst för sökning och hämtning av applikationer till mobila enheter. (T.ex.

Play Butik och App Store.)

12

Appbutik från tredje part: Fungerar som en vanlig applikationsbutik men har inte

direkt stöd från operativsystemsföretaget. Ett exempel på appbutik från tredje part är

Galaxy Apps.

Email: En installationsredo fil skickas med ett email. Den mottagande enheten känner

av att detta är en installationsfil för systemet om detta är inställt i enhetens

inställningar.

Webblänk: Genom att besöka en webblänk får enheten en förfrågan om att installera

en applikation i systemet om detta är tillåtet enligt enhetens inställningar.

Alla operativsystem stödjer inte alla distribueringsalternativ, utan operativsystemen har stöd

för följande typ av applikationsdistribuering:

Android stödjer distribuering via appbutik, appbutik från tredje part, email och

webblänk. [19]

iOS stödjer distribuering via appbutik.

Windows stödjer distribuering via appbutik. [20]

Fördelar

- Programmet skrivs närmare enhetens operativsystem och kan använda sig av enhetens

hård- och mjukvara.

Nackdelar

- Applikationerna är beroende av plattformen, vilket innebär att applikationen är låst till

plattformens operativsystem.

- Uppsättning av en företagsbutik är ytterligare en process och för ett lågt användarantal

kan denna process inte ge tillräckligt värde för att iscensättas.

Webbapplikation

En webbapplikation nås via en adress och är beroende av en webbläsare. Webbapplikationen

blir då beroende av webbläsarens representation av de webbsidor vi får från adressen. Olika

operativsystem använder sig av olika webbläsare. De fem vanligaste webbläsarna är de med

13

utgiven procentandel i tabellerna nedan. Tabell 2 visar ett pajdiagram över de vanligaste

webbläsarna som används på stationära och bärbara datorer. [21]

Tabell 2. Webbläsarandelar för stationära enheter.

Tabell 3 visar ett pajdiagram över de vanligaste webbläsarna som användas på mobila enheter

(Smartphones, surfplattor m.m.). [22]

Tabell 3. Webbläsarandelar för mobila enheter.

När det kommer till operativsystemen i de tre stora mobila plattformarna stöds de följande

större webbläsarna.

Android: Google Chrome, Mozilla Firefox och Opera. [23]

iOS: Google Chrome, Opera, Safari [24]. Och Firefox [25].

Windows: Microsoft Internet Explorer och Opera. [26]

14

Fördelar

- Plattformsoberoende: det är skillnad mellan webbläsare men de vanligaste förstår

samma språk, med några skillnader.

- Trots att det finns många webbläsare så är det endast några få som är allmänt

utbredda.

Nackdelar

- Kräver konstant uppkoppling mot server eftersom de måste köras genom en

webbläsare.

- Applikationerna blir begränsade av webbläsarnas möjligheter.

Hybridapplikation

En hybridapplikation är programmerad som en webbapplikation men distribueras som en ren

applikation. Hybridapplikationen använder sig av en webbvisualisering [27] för att visa

applikationen, därför är den beroende av webbläsaren på enheten snarlikt en webbapplikation.

Fördelar

- Trots att applikationen är programmerad som en webbapplikation så kan vi komma åt

mer hårdvarunära information än om applikationen vore en ren webbapplikation.

- Koden för webbdelen går att återanvända för alla operativsystem.

Nackdelar

- Det finns kända kompabilitetssvårigheter mellan olika Android versioner. [28]

- Applikationer blir begränsade av webbvisualiseringens möjligheter.

Val

Gustaf Fröding hotell önskade en lösning där presentationsmaterialet skulle redigeras på

enheter med olika operativsystem. För att uppfylla de funktioner och hinna med som

efterfrågades valde vi att göra en webbapplikation med all funktionalitet, alternativet var

annars att att göra en webbapplikation för redigering och en ren applikation för representation

av media. Dessutom blir distribueringen av applikationen enklare och den extra funktionalitet

som fås från en ren applikation behövdes inte.

15

3.2 Redigeringsverktyg

Våra förhoppningar med denna undersökning var att hitta ett redigeringsverktyg av

presentationer som vi kunde applicera på vår applikation. Syftet var att hitta ett grundsystem

att utgå ifrån och sedan vidareutveckla och skräddarsy det systemet till Gustaf Fröding. Två

olika kategorier för redigering undersöktes. Det första var skrivbordsredigering som innebär

att presentationer redigeras i ett program installerat lokalt på administrationsenheten. Avsnitt

3.2.1 beskriver skrivbordsredigering mer ingående. Det andra alternativet som undersöktes

var webbredigering som skulle betyda att redigeringsverktyget finns att tillgå genom

webbläsaren. Mer om detta beskrivs i avsnitt 3.2.2.

Skrivbordsredigering

Skrivbordsredigeringsverktyg är de som installeras på användarens PC och som används för

att framställa presentationer som ska visas på visningsklienterna.

Vi sökte efter ett redigeringsverktyg som gav ett filformat som hade stöd för visning av

innehållet på webben. För skrivbordsredigering finns det flera miljöer såsom Microsoft

PowerPoint [29], LibreOffice Impress [30] och OpenOffice Impress [31]. Från dessa miljöer

kan användaren välja att spara presentationerna i olika filtyper som ger olika funktionalitet.

De nämnda tre redigeringsverktygen har den minsta gemensamma nämnaren att de kan spara

filer i följande typer som beskrivs nedan: Portable Document Format (PDF), Open Document

Presenter(ODP) och Bilder.

Open Document Presenter

Open Document Presenter är en filtyp som förkortas ODP och som ingår i filfamiljen ODF,

Open Document Format. webODF [32] är ett JavaScript-bibliotek som har utvecklats för

direktläsning av alla Open Document Format-filer. webODF konverterar ODP filer till HTML

och CSS. Sedan, med hjälp av ett API, låter verktyget användaren påverka det som visas.

Efter testning fick vi fram några fördelar och nackdelar.

Fördelar

- Det går att få ut hur många sidor presentationen innehåller samt påverka vilken sida

som ska visas.

- Det är lätt att ändra presentationens storlek för anpassning till skärmen.

16

- Den stora fördelen vid användning av webODF är att användaren kan redigera

presentationen i en nativ redigeringsmiljö och användaren behöver bara arbeta med en

fil.

Nackdelar

- Animationer mellan byten av sidor stöds inte, vilket har konfirmerats av utvecklarna.

- Videovisning stöds inte, vilket också har konfirmerats av utvecklarna.

- De animationer som redigeraren har lagt till i redigeringsverktyget finns det inte

längre stöd för när det presenteras vilket kan vara förvirrande.

Portable Document Format - PDF

PDF.js är öppen kod för att översätta en PDF till html. PDF.js [33] är ett javascriptbibliotek

som tillhandahåller ett API som utvecklaren kan använda för att presentera filen. Vid

skapande av PDF så följer inte de animationer som gjort med. Redigeringen av PDFfiler är

inte optimalt och kan vara processtungt.

Fördelar

- PDF är en lättigenkännlig filtyp för användaren.

Nackdelar

- Redigering är begränsad och osmidig.

- Trots att filtypen är lättigenkännlig för allmänheten så är det inget som direkt

förknippas med presentationer.

Bilder

Det tredje alternativet vi sett är att spara alla sidor som vi får från en presentation som bilder.

Detta alternativ gör att vi inte kan redigera sidorna efteråt men det gör det väldigt mycket

enklare att presentera. Vi behöver inte använda oss av något speciellt verktyg för att

presentera en bild.

Fördelar

- Enkelt att utveckla presentationsapplikationen.

- Om en sida i presentationen ska redigeras så är redan varje sida en egen fil i form av

bild så den berörda bilden behöver bara bytas ut.

17

Nackdelar

- Gör uppladdningen av filer och uppsättningen av presentationen mer tidskrävande

- Redigering av bilder kräver avancerade kunskaper.

Webbredigering

Ett webbredigeringsverktyg är en tjänst som användaren kommer åt genom webbläsaren. Här

letade vi efter en tjänst som vi kunde implementera direkt i vårt system.

Om inte tjänsten kräver något speciellt tillägg så ska användaren inte behöva installera

någonting på sin dator för att webbredigering ska fungera. I detta avsnitt beskrivs tre tjänster:

Prezi [34], SlideDog [35] och Strut [36] som alla är verktyg för att skapa presentationer samt

SMIL, vilket är ett standardiserat format för digital skyltning på webben.

Prezi

Prezi är ett presentationsverktyg som använder sig av webben för skapande, redigering och

presentation av presentationer. Presentationerna kan också laddas ner för visning på

Windows- och Mac-enheter. Verktyget skiljer sig från andra presentationsverktyg genom att

inte presentera i form av sekvens. Istället används mycket in- och ut-zoomning för att förflytta

sig på sin presentations canvas.

Fördelar:

- Har avancerade funktioner som passar för digital skyltning.

- Från redigeringsverktyget kan vi få en länk som vilken klient som helst kan öppna och

spela upp den skapade presentationen under loop.

Nackdelar:

- Månadskostnaden för att bli av med en vattenstämpel är hög. En vattenstämpel är en

text som alltid visas på skärmen.

- Använder avancerande transaktioner och animationer och upplärningskurvan är stor.

18

SlideDog

SlideDog är en tjänst för att göra flera olika typer av filer till en sammanhängande

presentation. Programmet har inte stöd för redigering av visningsmaterial utan binder enbart

samman olika filer till en visningsshow. Man kan exempelvis binda ihop filer som

Powerpoint-filer, filmer, bilder och mycket mer. En presentation presenteras sedan i

SlideDogs klientprogram som körs offline på användarens PC.

Fördelar:

- Stöd för många olika typer av filer som användaren laddar upp på tjänsten.

- En presentation som visas på en klient kan styras från en annan klient.

- Direktsändning av presentationer. Klienter kopplar upp sig mot skaparen och tar emot

de uppdateringar som görs i realtid.

Nackdelar:

- Stor fördröjning på direktsändningen.

- Inget utvecklings-API kan fås av utvecklarna.

Strut

Strut är en webbapplikation designad för att skapa presentationer och presentera dessa med

hjälp av javascriptbibliotek Impress.js [37] eller Bespoke.js [38]. Det är möjligt i

applikationen att spara undan strukturen på den tillverkade presentationen i form av en JSON-

fil5 (se Figur 3-1) som är lätt att läsa av för en webbapplikation. Detta är något som

webbapplikationen skulle kunna utnyttja för att spara de tillverkade presentationerna direkt i

administrationen.

5 Standardiserat textformat för kommunikation mellan applikationer över internet.

19

Figur 3-1. Spara presentationer i Strut som JSON-objekt.

Strut är under licensen GNU Affero General Public License [39] och finns på Github6.

Licensen gör att det inte finns några hinder för att använda applikationen och förändra den i

eget syfte. I Figur 3-2 ges en överblick över applikationen idag och visar områden inramade i

rött vilket är funktioner som eventuellt skulle skalas bort vid användning av applikationen i

projektet. Funktionerna inom de röda områdena är följande; Visa spellista, Ändra editerings

vy och två menyer för diverse funktioner.

Figur 3-2. Strut översikt.

6 Samarbetssystem för programmering.

20

Fördelar:

- En webbapplikation som går att integrera med projektets administrationsverktyg kan

göra det lätt för användaren av systemet.

- Öppen kod gör det möjligt att skala bort funktioner som inte är önskvärda och lägga

till funktioner som är nödvändiga.

Nackdelar:

- Strut är för närvarande i betastadie och för ostadigt att vidareutveckla.

- Många funktioner stödjs inte i de vanligaste webbläsarna.Tabell 2. (se Tabell 2)

SMIL

Standardformatering av digital skyltningsmedia kallas för Synchronized Multimedia

Integration Language (SMIL) och är grundat på filformatet XML7. Den första versionen av

SMIL lanserades 1999 och den senaste uppdateringen kom 2008. SMIL 3.0 är den version

som används idag (se Figur 3-3). SMIL är specifikt konstruerat för kommunikation med

synkroniserad multimedia och har specifika fält lämpade för digital skyltning [40], som

animationsfält, transaktionsfält och sammanfogning av bilder och text. Kontorsmjukvaran

Microsoft PowerPoint och LibreOffice Impress använder sig av standarden ODF som i sin tur

använder en del av smilstrukturen.

Figur 3-3. Exempelkod på SMIL-strukturen.

7 Standardiserat textformat för kommunikation mellan applikationer över internet.

<smil>

<head />

<body>

<seq repeatCount="indefinite">

<video src="ad1_15s.mpg" />

<video src="ad2_30s.mpg" />

</seq>

</body>

</smil>

21

Val

Vid testning av dessa applikationer fann vi att vidareutveckling eller implementation av någon

inte var passande eftersom de inte uppfyllde de krav vi letade efter. Tills vidare

rekommenderar vi att användaren använder valfritt redigeringsverktyg för presentationer

externt från vår applikation.

3.3 Kioskläge

Att sätta en surfplatta i kioskläge innebär att det bara går att kommunicera med en förvald

applikation eller webbsida. Den som vill interagera med surfplattan kan inte göra mer än vad

som har definierades av användaren som aktiverade kioskläget. Vid egen utveckling av

kioskläge finns det många guider online som till exempel Andreas Schrades ”How to create a

working kiosk mode in Android” [41].

Det finns olika applikationer som erbjuder tjänsten att försätta surfplattan i kioskläge. Test

gjordes för att se om det gick att använda en färdig applikation för kioskläge istället för egen

utveckling av denna funktion. Testet gjordes på en Nexus surfplatta med Android 5.0 system

och listan nedan är de applikationer som hittades och testades.

clyd Kiosk Standalone Lockdown (gratis)

Surefox (gratis alt premium)

KioWare Lite (gratis)

Mobilock Kiosk Lockdown (gratis)

Kiosk Browser Lockdown (gratis alt premium)

Inbyggt i iPad finns funktionaliteten ”Guided Access” som ger en möjlighet att låsa

surfplattan till en applikation och vid inaktivering kräva en pinkod för upplåsning. Även

Android 5.0 har en funktion för skärmlåsning till en specifik applikation.

Test av kiosklägeapplikationerna

Alla kiosklägeapplikationer ersätter Androids egna startapplikation som körs vid uppstart av

enheten. Då startas den valda kiosklägetapplikationen i stället för enhetens startapplikation.

Även hemknappen är bunden till startapplikationen.

22

Det vi letade efter var en applikation som kunde låsa enheten så pass bra att det inte går att ta

sig ur hemsidan som visas på surfplattan och som startade automatisk vid uppstart av enheten.

För att åter aktivera integrationsmöjlighet med surfplattan ska man behöva ge en

identifikationsnyckel av något slag.

Ett grundkrav för kiosklägeapplikationen var alltså att man inte kunde ta sig ur kioskläget.

Vid testning så avslutades testet direkt när vi hittade ett sätt att kringgå låsningen. Eftersom vi

från kapitel 3.1 valde att utveckla en webbapplikation letade vi efter en kiosklägeapplikation

som kan låsas till en specifik hemsida. Om inget stöd för detta hade hittats hade vi behövt

ändra vårt val av applikationstyp.

Clyd Kiosk Standalone Lockdown

Clyd låser surfplattan till flera rena applikationer (se 3.2.1). Hemknappen tar användaren till

en ny applikationssida med genvägar till en mängd egenvalda applikationer.

Beslut: Inte lämplig för vårt ändamål.

Surefox

Genom aktivitetsknappen går det att gå runt kioskläget i Surefox. Applikationen låser

surfplattan till en vald applikation.

Beslut: Uppfyllde inte grundkravet.

Mobilock Kiosk Lockdown

Mobilock låser surfplattan till flera applikationer. Hemknappen tar användaren till en ny

applikationssida med genvägar till en mängd egenvalda applikationer.

Beslut: Inte lämplig för vårt ändamål.

Pronestor Kiosk Browser

Pronestor låser surfplattan till en valbar URL. Avstängningsknappen fungerar och

applikationen har ett vattenmärke nere i höger hörn.

Beslut: Uppfyllde inte grundkravet och hade ett vattenmärke.

23

Kiosk Browser Lockdown

Kiosk Browser Lockdown låser surfplattan till en valbar URL och inga sätt att kringgå

låsningen hittades. Utan premium går det inte att ha helskärmsläge på och en banner i toppen

av skärmen är alltid synlig(se Figur 3-4). Premium behövs för att applikationens banner (se

Figur 3-5) inte ska vara synlig. Det går också att importera inställningar och schemalägga

ström av och på.

Figur 3-4, Kiosk Browser Lockdowns gratisversion.

Figur 3-5, Kiosk Browser Lockdown med premium.

Beslut: Passar för vårt ändamål.

24

3.4 Förundersökningens slutsats

Efter testning har slutsatsen dragits att skapa ett system liknande SlideDog som körs i

webbläsaren. Fokus ligger på hur det uppladdade materialet ska presenteras och inte hur det

skapas. Strut (se 3.2.2 Webbredigering) verkade lovande för projektet men eftersom det inte

fanns stöd för alla webbläsare hade det tagit för långt tid att förbättra programmet.

Istället för utveckling av en kiosklägeapplikation valde vi att rekommendera en redan färdig

kiosklägeapplikation. Applikationen som lämpade sig bäst var Kiosk Browser Lockdown och

denna rekommenderas slutligen.

Tiden som gick åt för redigeringsverktygsdelen i förundersökningen var omfattande sett till

projektets tid och resulterade inte i att någon implementation av ett befintligt system för

bildredigering och bildpresentation gjordes.

25

4 Projektdesign

I kapitlet projektdesign presenteras de enheter som finns i systemet, designen på databasen

samt kodstrukturen på systemet. I avsnitt 4.1 beskrivs enheterna i systemet och en enkel

översikt ges i Figur 4-4. Designen på databasen beskrivs närmare i avsnitt 4.3 och i avsnitt 4.4

går vi närmare inpå kodstrukturen.

4.1 Enheter

I detta avsnitt beskrivs olika typer av enheter som ingår i strukturen av systemet. Avsnittet

innehåller även en kort information om de olika klienternas användning.

Administrations-klient (aklient)

Aklienten representeras enligt Figur 4-1 och är en dator som kan administrera det innehåll som

ska representeras på visnings-klienterna. Uppkoppling till aklient sker genom webbanslutning

till webbapplikationens adress. Aklient används av ett par personer som ansvarar för

uppdatering av media till visnings-klienterna.

Figur 4-1. Bildrepresentation av administrationsklienten.

Visnings-klient (vklient)

Vklient representeras enligt Figur 4-2 och är en surfplatta som spelar upp media från

aklienten, vilket sker via surfplattans webbläsare. Surfplattan har en applikation för Kioskläge

(se kap 3.3) som låser alla knappar och funktioner på enheten för att hindra åskådare att

använda surfplattan för annat.

26

Figur 4-2. Bildrepresentation av visningsklienten.

Visningsklienten är tänkt att huvudsakligen vara en surfplatta men då anslutning sker via en

webbadress kan vklienten i princip vara vilken enhet som helst med internetuppkoppling och

stöd för en webbläsare.

Webbserver

Webbservern representeras enligt Figur 4-3 och är en webbserver som har en filstruktur för

uppladdning av presentationsmaterial. Det är tänkt att kräva inloggning för att få tillgång till

webbapplikationen. Det finns två olika gränssnitt, en för aklienter och en för vklienter. På

webbservern finns en databas för lagring av presentationsmaterial.

Figur 4-3. Bildrepresentation av webbservern.

Systemdesign

I systemet (se Figur 4-4) sker all kommunikation genom en central server (B1).

Visningsklienterna (C1-C4) kopplar upp sig emot servern. Administrationsklienterna (A1,

A2) bestämmer vad som ska visas på den koppling som visningsklienterna har.

27

Figur 4-4. Exempelbild över systemdesign.

4.2 Terminologi

I detta avsnitt så förklaras vissa uttryck som används hädanefter.

Slide

En slide är ett visningsobjekt. Detta visningsobjekt kan vara en bild eller ett videoklipp.

Spellista

En spellista består av flera slides med ett värde som representerar ordningen som de ska visas

i. En spellista kan också innehålla andra spellistor, se Figur 5-11. Representation av spellista.

Figur 5-11.

Story

En story är funktionalitet som har diskuterats fram tillsammans med kund. Komplexiteten på

varje story varierar och kan innehålla flera olika funktioner samlade under en gemensam

målriktning.

28

T.ex. Uppdatera visningsmaterial på en visningsklient innefattar först att man måste kunna

visa material på visningsklienten och sedan hämtning av nytt material och övergångar mellan

det gamla materialet och det nya.

4.3 Databasdesign

Med användning av Entity Framework (se avsnitt 2.3.5) skapades databasen från koden i

projektet där en mängd objekt tillsammans med konfigurationsrader omvandlas till en

relationsdatabas. Varje tabell (se Figur 4-5) motsvarar ett objekt och attributen för varje tabell

motsvarar de variabler som varje objekt har. Nedan beskrivs de olika tabellerna i databasen.

Figur 4-5. Ett enkelt ER-diagram över databasens struktur.

Tabellbeskrivning

I detta avsnitt beskrivs samtliga tabeller i databasen (se Figur 4-5) lite mer ingående.

Viewclient (Skärmklient)

Tabellen Viewclient innehåller information om de skärmklienter som spelar upp

presentationerna. Tabellen innehåller information som placering, typ av enhet och namn på

enheten. All denna information är sådant som användaren av systemet ställt in. Tabellen har

29

en en-till-många relation till ViewclientPlaylist, vilket är en tabell som kopplar samman

skärmklienterna med spellistor.

ViewclientPlaylist(SkärmklientSpellista)

Tabellen ViewclientPlaylist sammanfogar tabellerna Playlist och Viewclient. Tabellen

innehåller information om schemaläggning och den ordningen som spellistorna ska spelas i.

Tabellen har en en-till-många relation med både Viewclient och Playlist.

Playlist (Spellista)

Tabellen Playlist innehåller spellistor som användaren skapat. Playlist har en en-till-många

relation med PlaylistSlide och ViewclientPlaylist, vilka båda är tabeller som kopplar samman

spellistor med slides respektive skärmklienter.

PlaylistSlide(SpellistaSlide)

Tabellen PlaylistSlide sammankopplar tabellerna Playlist och Slide. Tabellen innehåller

information om hur lång tid sliden ska visas, vilken animation som ska spelas samt

spelordningen på sliden. Om sliden är en video så finns också information om vid vilken

tidpunkt i videon som sliden ska börja spela upp. PlaylistSlide har en en-till-många relation

med både Playlist och Slide.

Slide (Slide)

Tabellen Slide innehåller information om filerna/länkarna; vilken typ av slide det är,

filsökvägen på servern samt en referens till en Template. Slide har en en-till-många relation

till både PlaylistSlide och Template.

Template

Tabellen Template innehåller mallarna, d.v.s. de filer som vi inte kan spela upp men som är

lättare för användaren att redigera. Information finns om sökvägen på servern till mallen och

tabellen har en en-till-många relation till Slide. En mall kan ha referenser till många slides

men en slide kan bara ha referens till en mall.

30

4.4 Kodstruktur

Kodstrukturen i projektet som kan ses i Figur 4-6, är uppdelad i fyra olika moduler. Figur 4-6

visar den relation som de fyra modulerna har till varandra.

I början av projektet så jobbade vi bara med modulerna Web, Domain och Data. Vi upptäckte

dock att vi var i behov av ett API (Service) för att kommunicera med Data. Service behövdes

för att slippa skriva duplicerande kod och för att vi ansåg det positivt att webbapplikationen

inte har tillgång till mer än som bestäms i Servicemodulen, till skillnad mot Datamodulen som

ger tillgång till allt.

Nedan följer en beskrivning av de nämnda modulerna:

Figur 4-6. Kodstruktur överblick

Service

Modulen Service är ett API mot Datamodulen och innehåller funktionalitet som återanvänds

ofta. Servicemodulen består utav ett antal klasser (se Figur 4-7) som primärt jobbar mot varsin

tabell i databasen. Vilken tabell som klassen jobbar mot avslöjas i klassens namn (jämför

Figur 4-5 i Databasdesign med Figur 4-7), t.ex. PlaylistRepository jobbar primärt mot

databastabellen Playlist (Spellista). Eftersom Spellistor är kopplade till vklienter och har

slides kopplade till sig så jobbar också klassen mot dessa kopplingar.

31

Figur 4-7, Kodstruktur Servicemodul

PlaylistRepository (se Figur 4-7) i Servicemodulen innehåller funktioner som t.ex.

GetPlaylistById, vilken gör mycket precis det som funktionsnamnet säger. Ett annat

funktionsexempel är ConnectSlide som skapar en koppling mellan en argumenterad slide och

en spellista.

Domain

Resterande moduler i systemet använder sig av modellerna i modulen Domain. Modellerna

skrivna i denna modul är också de som Entity Framework (se avsnitt 2.3.5) använder för att

skapa databasen (se avsnitt 5.4 Code First). De namn som sätts på klasserna (se Figur 4-8) blir

automatiskt tabellnamnen om inget annat konfigureras.

Figur 4-8, Kodstruktur Domainmodul

Modulen Service måste använda Domainmodellerna för att kunna hämta data och det är

praktiskt att ha tillgång till Domainmodellerna för modulen Web eftersom t.ex. modellen som

representerar en spellista är också ofta samma modell vi använder i webbapplikationen.

32

Web

Modulen Web innehåller projektets webbapplikation. Skripts, bilder, fonts och resterande som

hör en webbapplikation till har sin bas i denna modul. Modulen använder den MVC-struktur

som beskrivs i avsnitt 2.3.1. Modellerna som finns i modulen Domain används av

webbapplikationen men i huvudsak används modellerna som redan finns i Webmodulen i

mappen Models (se Figur 4-9).

Figur 4-9, Kodstruktur Webmodul

Data

Modulen Data innehåller DbSets (se Figur 4-10) som Entity Framework uppdaterar parallellt

med databasen. Förutom detta så innehåller modulen också konfigurationsfiler som

tillsammans med modellerna i modulen Domain används när Entity Framework skapar

databasen (se avsnitt 5.4 Code First). Klassen ApplicationDbInitializer (se Figur 4-10) kör

extra konfiguration när databasen rensas och startas om vilken är vanligt vid utvecklande.

Figur 4-10, Kodstruktur Datamodul och kodexempel

public DbSet<Playlist> Playlists { get; set; } public DbSet<Slide> Slides { get; set; } public DbSet<Template> Templates { get; set; } public DbSet<Viewclient> Viewclients { get; set; } public DbSet<ViewclientPlaylist> Viewclient_Playlist { get; set; } public DbSet<PlaylistSlide> Playlist_Slide { get;

set; }

33

5 Implementation

Detta kapitel tar upp detaljer runt implementationen av webbplatsen. Kapitlet börjar med att

beskriva det grafiska gränssnitt som användaren interagerar med i avsnitt 5.1. I avsnitt 5.2

beskriver vi hur systemet beter sig när användaren laddar upp material. I avsnitt 5.3 beskrivs i

form av bilder och text vår implementation av visningen av objekt. Därefter i avsnitt 5.4 ges

läsaren en beskrivning av vårt tillvägagångssätt i kodningen av databasen genom att beskriva

Code First (se 2.3.5 Entity Framework).

5.1 Grafiskt användargränssnitt

Vid design av det grafiska användargränssnittet valde vi att använda Bootstrap för att ge en

responsiv design. Det fanns inga krav på responsivitet i kravspecifikationen men vi valde att

lägga tid på detta för att skapa en snygg och modern design. Det grafiska användargränssnittet

är uppdelat i två olika gränssnitt som beskrivs nedan. Uppdelningen gjordes för att minimera

att användare av misstag gör allvarliga fel i systemet, SimpelVy är kraftigt begränsad, t.ex. att

ta bort visningsklienter eller filer är inte möjligt från det gränssnittet vilket ger användaren en

viss säkerhet vid användning.

Simpel Vy

Simpel Vy är det gränssnitt som kommer att användas mest och har därför en enklare och

snyggare design. Det är också lättare att få en helhetsbild av systemets innehåll med Simpel

Vy. Detta gränssnitt går att nå via indexsidan på webbapplikationen och genom att klicka på

tabben DigiconSolution (se Figur 5-1).

Figur 5-1. Simpel Vy-sidan på webbplatsen.

Sidans innehåll uppdateras vid interaktion med användaren men laddar inte om sidan. De

blåmarkerade listobjekten har användaren markerat med ett vänster musklick enligt Figur 5-2.

34

Figur 5-2. Allt som visas på Simpel Vy.

Listans utseende ser från start ut enligt Figur 5-1 och vid markering av ett objekt i listan

uppdateras sidan stegvis hela vägen till Figur 5-2. Vid val av vklient visas en tabell med de

spellistor som är tilldelade den valda visningsklienten.

Figur 5-3. I Simpel Vy med val av vyklient.

Listan över spellistor innehåller också en knapp för att redigera vklientens spellistor (Figur

5-4) som är kopplade till vklienten. Vid val att redigera vklienten kan vi ändra namn på

vklient, visningordning av spellistor och att koppla bort spellistor från vklienten.

35

Figur 5-4. Redigering av vklient.

En annan knapp för tilläggning av spellista visas i Figur 5-5. Här listas alla spellistor som

finns i systemet. Dessa kan kopplas till den vklient som vi valt innan vi valde att lägga till en

spellista. Dessutom kan vi skapa en ny spellista som också kommer att läggas till i den valda

vklienten.

Figur 5-5. Lägga till spellista till vklient.

Vid val av en av spellistorna visas de visningsobjekt tilldelade till denna spellista enligt Figur

5-6 och här finns också en knapp för att editera (se Figur 5-7) och lägga till (se Figur 5-8).

Vid val av ett visningsobjekt visas information om visningsobjektet enligt Figur 5-2.

36

Figur 5-6. I Simpel Vy vid val av spellista.

Nedan i Figur 5-7 kan vi se vyn för redigering av en spellista. Vi kan byta namn på spellistan,

ändra visningstid och spelordning på slides samt koppla bort en slide från spellistan.

Figur 5-7. Redigering av spellista.

Vid koppling av en slide till en spellista är det vyn nedanför oss i Figur 5-8 som presenteras.

Här kan vi välja att lägga till en existerande slide från systemet genom att markera en eller

flera slides. Alternativt kan vi välja någon av de andra tabbarna, Youtube och Ladda Upp. I

Youtube-tabben får vi välja en länk och i Ladda upp-tabben får vi välja en fil på vår dator att

ladda upp och lägga till i spellistan.

37

Figur 5-8. Lägga till slide till spellista.

Avancerad Vy

Avancerad Vy är en benämning på sidor som kan nås via tabbarna Skärmar, Spellistor och

Filer. Här finns samma funktionalitet som i Simpel Vy men också funktioner för att ta bort

data permanent från systemet. Alltså borttagning av uppladdat material och vklienter måste

göras via denna vy. I Figur 5-9 visas den vy man får när man klickar på tabben Skärmar där

man har valet att koppla bort en vklient från systemet genom Ta bort-knappen. Detta kan man

inte göra från g gör allvarliga fel i systemet, SimpelVy är kraftigt begränsad, t.ex. att ta bort

visningsklienter eller filer är inte möjligt från det gränssnittet vilket ger användaren en viss

säkerhet vid användning.

Simpel Vy. De andra sidorna i Avancerad Vy liknar den som presenteras i Figur 5-9.

Figur 5-9. Lisa över Vklienter i Avcancerad Vy.

38

5.2 Uppladdning av material

I det här avsnittet tas upp viss grundfunktionalitet som används vid administration och är

tänkt att ge en bättre förståelse över hur systemet fungerar.

När en användare lägger upp nytt visningsmaterial som han/hon har gjort i sitt

favoritbildverktyg loggar användaren in på administrationsklienten och väljer att ladda upp

flera filer till servern (se Figur 5-10). Typer av filer som kan laddas upp är bilder och mallar,

där varje bild är materialet som kommer att visas på en vklients skärm under en viss tidpunkt.

Alla filer laddas upp som separata http-postförfrågningar. Detta görs för att kunna se vilka

filer som inte laddas upp vid fel av uppladdning och ge den informationen till användaren.

Figur 5-10. Länkning Mallar och filer efter uppladdning.

Mallarna är originalpresentationen som används för generering av bildfilerna. Tillsammans

med bilderna rekommenderar vi att användaren alltid laddar upp den mallfil som användes för

framställning av bilderna. Servern skapar automatiskt en länkning till de bilder som har

laddats upp med en mall. Detta gör det enklare för användaren att redigera sina bilder vid en

senare tidpunkt eftersom han/hon har tillgång till den presentationsfil som bilderna

framställdes ifrån. Denna fil är möjlig att redigera till skillnad från bilderna.

En spellista kan innehålla bilder, Youtubelänkar och andra spellistor (se Figur 5-11). För att

en vklient ska spela upp media behövs först en eller flera slides tillagda i en spellista.

39

Figur 5-11. Representation av spellista.

Vid tilläggningen av en slide till spellistan fyller användaren in medians spelordning i

spellistan och hur länge median ska visas. På en bild kan vi sätta antal sekunder median ska

visas och på en Youtubelänk kan vi välja start- och slutposition. Vid inlägg av en spellista i en

annan spellista skapas en länkning till den andra spellistan (se Figur 5-11) och

visningsordningen blir enligt Figur 5-12.

Figur 5-12, Spelordningen för en spellista som innehåller en annan spellista.

5.3 Visning av media

I detta avsnitt så beskrivs koden som gör att vi presenterar materialet som användaren av

systemet lagt till. De funktioner som vi går igenom i detta avsnitt finns i modulen Web (se

avsnitt 4.4.4) och avsnittet är uppdelat i två avsnitt, backend och frontend.

40

Backend

Metoden DisplayView (se Figur 5-13) skapar en lista av alla filer som länkats till vklienten.

En specifik vklient väljs genom det ID-nummer som skickas som argument. En lista med

objektet SlideView skapas och tillsammans med filerna paketeras visningstid, animation och

spelordningen i SlideView. Sedan returneras DisplayView tillsammans med listan.

Figur 5-13. Controller.

Funktionerna och klasserna Figur 5-13, Figur 5-14, Figur 5-15, Figur 5-16, Figur 5-18 och

Figur 5-19 finns i modulen Web (se avsnitt 4.4.3).

Figur 5-14. Slideview-objekt.

[HttpGet] public ActionResult DisplayView(int id) { List<SlideView> Slides = new List<SlideView>();

foreach (ViewclientPlaylist vp in viewclientService.GetPlaylistConnections(id))

{ // if we got more than one playlist this is a handy variable

int numberOfSlidesBefore = Slides.Count(); foreach (var playlistslide in playlistService.GetSlideConnections(vp.PlaylistID))

{ Slides.Add(new SlideView { Slide = playlistslide.Slide, Duration = playlistslide.Duration, Transition = playlistslide.Animation.Name, Playorder = playlistslide.Playorder

+ numberOfSlidesBefore }); } } return View(Slides); }

public class SlideView { public Slide Slide { get; set; } public int Playorder { get; set; } public int Duration { get; set; } public string Transition { get; set; } }

41

Visningspresentation Frontend

Koden enligt Figur 5-15 loopar igenom alla SlideViews (se 5.3.1) som skickats med html-

dokumentet. Därefter skapas ett <iframe> objekt om sliden är en youtubelänk eller ett <img>

objekt för bild. Varje objekt prepareras med värden som fås från modellen.

När sidan har laddat klart så anropas javascriptfunktionen slideviewer som sätter igång

uppspelningen av elementen som från början är satta till att inte visas.

Figur 5-15. View.

Figur 5-16 visar den funktion som startas vid laddning av sidan (Se Figur 5-5). Funktionen

använder sig av funktionen setTimeout för att anropa sig själv efter att visningselementet har

visats under den tid som var satt från användaren. Vilken ordning som elementen ska visas i

bestäms av elementattributet ”data-playorder” som är satt vid tillägg av en Slide i en playlist.

<body onload="slideviewer()"> <div id ="myMedia"class="mediaarea"> @foreach (var slide in Model.Slides) { if (slide.Slide.ContentType == "youtube") { <iframe id="Slide @slide.Playorder" data-transition="@slide.Transition" data-duration="@slide.Duration" data-playorder="@slide.Playorder" class="testvideo" style="display:none" src="@slide.Slide.Path" data-linksrc="@slide.Slide.Path?autoplay=1&cc_load_policy=1" frameborder="0" allowfullscreen> </iframe> } else if (slide.Slide.ContentType == "image/jpeg"

|| slide.Slide.ContentType == "image/jpg" || slide.Slide.ContentType == "image/png")

{ <img id="Slide @slide.Playorder" data-transition="@slide.Transition" data-duration="@slide.Duration" data-playorder="@slide.Playorder" class="testbild" src="@slide.Slide.Path" style="display:none" /> } } </div>

42

Figur 5-16. Presentation javascript.

5.4 Code First

Code-First [42] är en metod i Entity Framework där utvecklaren skriver entiteter (se Figur

5-17 och Figur 5-18) som kan likställas med tabellerna i databasen. Sedan med lite extra

konfiguration (se Figur 5-19) kan Entity Framework generera databasen.

function slideviewer() { numberofelement = $('[id^="Slide "]').length; //If the element is the last in the list if (numberofelement == 1) { lastElement = $("html").find("[data-playorder='" + (i) + "']"); } else if (i > numberofelement) { lastElement = $("html").find("[data-playorder='" + (i) + "']"); i = 1; } else {lastElement = $("html").find("[data-playorder='" + (i - 1) + "']");} //Disabels the prev element if (lastElement.length !== 0) { if (lastElement.prop('tagName') == "IMG") { } else if (lastElement.prop('tagName') == "IFRAME") { if (typeof lastlinksrc !== typeof undefined && attr !== false) { $(lastElement).attr("src", ""); $(lastElement).attr("src", video); } } } $(lastElement).hide(); currElement = $("html").find("[data-playorder='" + i + "']"); currsrc = $(currElement).attr('src') currlinksrc = $(lastElement).attr('data-linksrc'); if (typeof currlinksrc !== typeof undefined && attr !== false) { //The element had no extra src } else {currsrc = currlinksrc;} //Counter never steps over 1 when only one element in playlist $(currElement).show(); if(numberofelement!=i){ i++; } else {i = 1;} setTimeout(slideviewer, currElement.attr("data-duration")); }

43

Figur 5-17. De entitetsklasser som Entity Framework använder sig av för att generera databasen.

Figur 5-18. Exempel på hur en av en entitetklasserna är uppbyggda.

Figur 5-19. Figuren visar hur konfiguration mellan två tabeller sker i Entity Framework Fluent API.

5.5 Problem

Detta avsnitt innehåller den problematik som uppstod under utvecklingsprocessen och hur vi

hanterade denna problematik.

namespace DigiCon.Domain.Entities { public class Template { [Key] public int TemplateID { get; set; } public string Name { get; set; } public string ContentType { get; set; } public string Path { get; set; } public virtual ICollection<Slide> Slides { get; set;} } }

// one-to-many (viewclient-to-viewclientplaylist) modelBuilder.Entity<ViewclientPlaylist>() .HasRequired(vp => vp.Viewclient) .WithMany(v => v.ViewclientPlaylists) .HasForeignKey(vp => vp.ViewclientID);

44

Testning

Vi satte inte tillräckligt värde på testning och enhetstester, vilket gjorde att vi upptäckte

buggar i systemet som relaterande till funktioner som vi tidigare trott varit färdiga. Detta

resulterade i att vi hade många funktioner som var halvt implementerade som vi fick gå

tillbaka och fortsätta med. Hoppandet mellan funktioner som vi hade schemalagda för stunden

och de halvimplemterande funktionerna gjorde att det blev rörigt att arbeta.

Vi ansåg att vid tillfället som dessa problem identifierades var resterande tid såpass kort att

det inte fanns tid för att införa testning och enhetstester och att vi behövde lägga den tiden på

att stabilisera systemet.

Nuget Error

Nuget är ett biblioteksdistribueringssystem inbyggt i Visual Studio och vid en

sammanfogning av kod till Team Foundation Server fick en av oss Nuget Error på majoriteten

av de referenser som användes, d.v.s. projektet gick inte att starta. Efter en halvdag med

felsökning och olika typer av lösningsförslag skickade vi all kod från utvecklaren som det

fungerade hos och ersatte alla filer. Detta är bara ett exempel på när mycket tid gick åt för att

vi inte riktigt förstod oss på verktygen och då speciellt Nuget i Visual Studio.

45

6 Resultat

I kapitel resultat ges först en sammanställning av projektets resultat i avsnitt 6.1. Sedan

presenteras det som fullgjordes från projektuppdraget i avsnitt 6.2. I avsnitt 6.3 beskriver vi

kundens nöjdhet och i avsnitt 6.4 går vi igenom vilka tekniker och verktyg som

implementerades.

6.1 Översikt

Förundersökningen gav inte lika bra resultat som vi hade hoppats på. Vi hade förhoppningar

att hitta ett redigeringsprogram för presentationer i webbläsaren som hade ett tillägg för

konvertering till HTML och CSS. Eftersom att vi inte hittade något så valde vi att exkludera

slideredigeringsdelen från systemet och rekommenderar kund att använda PowerPoints egen

funktion för export till bilder (se Figur 6-1).

Figur 6-1. Konvertering av en PowerPoint-presentation till bilder.

Lösningen blev att Gustaf Fröding hotell laddar upp nytt visningsmaterial som sedan visas på

tilldelad vklients skärm i helskärmsläge. Det finns ingen redigering av uppladdat material men

PowerPoint-filerna kan laddas upp. Vid ändring av en bild kan användaren då ladda ner den

PowerPoint-fil som användes för generering av bilden. Och ändring av bilden görs i

PowerPoint-programet för att sedan exportera sliden till en bild och ladda upp den nya bilden

med Powerpoint-filen. Förklarande bild på flödet enligt Figur 6-2 nedan.

46

Figur 6-2. Flödesschema över användarens interaktion med systemet.

47

6.2 Kravuppfyllelse

I detta avsnitt ges en beskrivning av hur många stories som uppfylldes, de uppgifter som blev

delvis uppfyllda och de som inte påbörjades, se Tabell 4. Vi beskriver också hur bra vi anser

att vi har uppfyllt de krav som vi sammanställde tillsammans med kund i början av projektet.

För en tydlig beskrivning av varje uppgift så finns detta under avsnitt 2.2 i Tabell 1.

Stories Story points Prioritet

Helt Kioskläge (v) 10 1Uppdatera presentation (v) 25 1

Lista med anslutna (a) 15 1

Nytt visningsmaterial (a) 35 1

Schemaläggning av slide (a) 30 1Installation av webbserver (s) 40 1

Sök om stöd för ställ 15 1

Säker omstart (v) 10 2Mallar (a) 25 2

Mörklägga enheter (a) 5 2Videovisning 20 2

Installations media 40 2

Autentisering för (a) 25 2

Multiförhandsgranska slide (a) 8 2Konfiguration (v+a) 15 3

Prestationstest (v) 40 3

Fjärrstyrning (v) 30 3Integration (v) 30 3

Animationer (v) 50 3

Koppling med bokning n/a 3

Förkortningars=server

a=administrationklient

v=visningsklient

Prioritet går från 1 till 3, dvs 1 är viktigast.Helt uppfyllt

Delvis uppfyllt

Ej uppfyllt

Tabell 4. Lista över vilka krav som uppfylldes.

Krav som uppfylldes

De funktioner som uppfylldes kan vi utläsa från tabellen (se Tabell 4), d.v.s. Helt Kioskläge,

Uppdatera presentation, Lista med anslutna, Nytt visningsmaterial, Sök om stöd för ställ och

Säker omstart. Helt kioskläge och Säker omstart ansågs klara efter att vi funnit ett kioskläge i

förundersökningen (se avsnitt 3.3) som täckte de kraven. Uppdatera presentation, Lista med

anslutna och Nytt visningsmaterial ansågs klara efter att de funktionerna blivit

48

implementerade i webbapplikationen. Sök om stöd för ställ ansågs klart när Gustaf Fröding

fått tre olika alternativ för uppsättning av ställ.

Främsta målet för projektet var att slutföra de uppgifter med prioritet 1. Som vi kan utläsa från

Tabell 4 så är det två uppgifter som inte är uppfyllda inom denna prioritet, schemaläggning

och installation av webbserver. Schemaläggning implementerades inte på grund av tidsbrist

och installation av webbserver gjordes inte eftersom vår prototyp inte uppfyllde alla

funktioner med prioritet 1. Resterande funktionalitet uppfylldes inte på grund av tidsbrist.

Krav med lägre prioritet som påbörjades

Vid val av Kiosk Browser Lockdown fanns säker omstart funktionen redan och där av blev

den uppfylld.

De uppgifter som påbörjades men inte blev helt klara är två stycken. Båda dessa funktioner är

av prioritet två och borde egentligen inte ha påbörjats innan alla funktioner av prioritet 1 var

klara. Storyn mallar påbörjades för att funktionaliteten gick snabbt att lägga till. Storyn

Videovisning implementerades av misstag före schemaläggning.

I storyn Mallar går det att ladda upp ODP-filer (se avsnitt 3.2.1) och spara men det finns ingen

koppling mellan slides och uppladdade ODP-filer. Koppling är nödvändig för att användaren

ska veta vilken mallfil som han/hon ska ladda ner vid redigering av materialet på en slide.

Storyn Videovisning är delvis klar eftersom visning av ett youtubeklipp är fullt möjlig men

inte uppladdning eller presentation av en videofil.

6.3 Kundnöjdhet

På grund av utebliven kontakt med kunden efter färdigställandet av webbapplikationen har vi

inte hunnit få någon återkoppling, men med tanke på att nästan alla grundfunktioner är

implementerade så anser vi att deras nöjdhet är god.

6.4 Tekniker och verktyg

De tekniker och verktyg som vi valde att använda har fungerat ungefär som förväntat.

Microsofts Visual Studio upplevdes väldigt omfattande och komplext men fungerade bra

under projektets gång. En testperiod med användning av programmet skulle ha underlättat

49

debugging, testning och navigering. Resultatet kan utläsas från Tabell 4, d.v.s. att 70 % av

prioritet 1 är avklarat, 14 % av prioritet 2 samt 0 % av prioritet 3.

Versionshanteringen med TFS fungerade relativt bra men ett par problem uppstod vid upp-

och nerladdning av kod, vilket kunde ha undvikits med en genomgång. Från Sogeti blev vi

tilldelade en TFS-server som vi använde oss av under hela projektet. Denna server hade vi

bara tillgång till när vi var på plats på Sogetis kontor, vilket kunde skapa problem om mycket

programmering skett på annan plats och vi inte tänkte oss för innan vi laddade upp den nya

koden på servern.

50

7 Utvärdering

I detta kapitel utvärderar vi projektet; hur vi planlade vår arbetstid finns i avsnitt 7.1 och hur

vi anser att arbetsmiljön var beskrivs i avsnitt 7.2 och i avsnitt 7.3 beskriver vi några av våra

lärdomar från projektet. Framtida planer för projektet och vidareutveckling beskrivs i avsnitt

7.4.

7.1 Tidsåtgång

Den tid som vi har jobbat med examensarbetet har varit under 24 augusti till 14 januari, och vi

har under denna period arbetat 2.5 dagar per vecka. Se Tabell 5 för en överblick.

Uppdelningen mellan uppsatsskrivning och utveckling har varierat. I början blev det mer

uppsatsskrivning då vi gjorde mycket teoriforskning och skrev då också mera uppsats. Sedan

utvecklade vi nästan heltid den mittersta perioden för att sedan mot slutet fasa ut till allt mera

uppsatsskrivning.

Tabell 5. Tidfördelning mellan uppsatsskrivning, programmering och förundersökningen.

7.2 Arbetsmiljö

Majoriteten av tiden satt vi på Sogetis kontor i Karlstad och utvecklade och merparten av

uppsatsen skrevs hemifrån eller på universitetet. Vi uppskattade möjligheten att få låna varsin

arbetsbänk, laptop och möjligheten för programmeringsstöd under utvecklingen. Under

utvecklingen hade vi kontinuerligt presentationer varannan vecka för en ansvarig på Sogeti

51

där vi presenterade arbetet och fick återkoppling på vad som var bra och vad som borde

struktureras om.

Vi avslutade vår vistelse på Sogetis kontor med en slutdemo för hela kontoret strax innan jul.

7.3 Lärdomar

I detta avsnitt tar vi upp olika lärdomar som vi har tagit med oss efter projektet.

Kravspecifikation

De flesta funktionerna som implementerades var relativt självklara för systemets

funktionalitet och vi ansåg inte att kravspecifikation var såpass betydelsefull i vår

utvecklingsprocess.

De extra kraven som vi fångade in hade lägre prioritet och (se Figur 2-1) och

kravspecifikationen skulle ha varit mera till nytta om vi hade kunnat utveckla annat än

grundfunktionalitet. I vårt fall kom detta extra arbete på kravspecifikationen inte till

användning.

Vid sammansättning av vår kravspecifikation glömde vi att räkna med hela

förforskningsdelen som en del av kraven. Förundersökningen tog mycket tid av projektet och

den enda förforskningsdel som fanns i kravhanteringen i Tabell 1 (sida 8) var Sök om stöd

som var en relativt liten del av hela förundersökningen.

Verktyg

Det var en del tekniker som var nya för oss och som vi har lärt oss hyfsat bra; ASP.NET

MVC, Entity Framework, Youtube API och Bootstrap.

Vi borde själva ha åsidosatt tid i början av projektet för inlärning av de tekniker som vi

använde. Hade vi gjort det hade vi kunnat fokusera bättre på programmeringen och inte

behövt känna att vi fick stanna upp ibland för att leta information för användning av Visual

Studio.

Vid presentation av slides använde vi Jquery och vi var inte bekanta med biblioteket sedan

innan, utan vi sökte information konstant på Google. Istället skulle vi ha sparat mycket tid om

vi hade lärt oss att använda Jquery innan.

52

Förundersökning

Trots att vi inte såg den direkta nyttan med förundersökningen i början av projektet så gav den

oss ganska mycket insikt i digital skyltning och verktyg för detta. Genom att sätta sig in i

digitalskyltning fick vi en annan synvinkel på vad som var viktigt i systemet som skulle

utvecklas, framförallt hur viktigt det var med designen.

Samtidigt använde vi oss inte av all information som samlades in och det kändes som slöseri

med utvecklingstid i vissa fall.

Kundkontakt

Att hålla kundkontakt är något väldigt viktigt och svårt att bemästra och vi fick uppleva hur

lätt det är att tappa kontakt med kund. När utvecklingen gick långsamt i början av olika skäl

så ville vi inte ta upp tid för kunden i onödan. I efterhand förstår vi att vi borde kontaktat kund

oftare och varit mera transparanta i vår utveckling än vad vi var.

7.4 Vidareutveckling

I detta avsnitt kommer vi att gå igenom saker som vi rekommenderar att vidareutveckla i

framtiden. Vi ser gärna sett att framtida examensjobbare fortsätter på vårt projekt.

Inloggning och konton

Inloggning och konton bör implementeras för säkerheten så att inte alla kan ändra och ladda

upp, utan vi rekommenderar att ett visst antal konton kan skapas. Förslagsvis rekommenderar

vi tre stycken typer av konton:

Koordinerare: Denna grupp kan använda det material som är uppladdat och ändra vad som

vissas i spellistor och på vklienter men också lägga upp nytt material.

Regissör: Denna grupp har samma behörigheter som Koordinerare. Dessutom kan Regissören

ta bort spellistor och uppladdat material som Koordinerare har gjort.

Adminkonto: Denna grupp kan skapa fler användare, ta bort användare samt har förövrigt

samma funktionalitet som de andra grupperna har.

53

Fördelen med att koordinerare inte kan ta bort material är att de inte kan råka ta bort något

som fortfarande används. Nackdelen är då man laddar upp fel material av misstag och inte

kan ta bort detta och måste vända sig till regissören för borttagning.

En alternativ lösning är att adminkonto och regissör behåller sina behörigheter men att

koordinerare får funktionaliteten att ta bort det material som de själva har laddat upp. Detta

för att undvika att koordinerare inte kontaktar regissören för borttagning och att det samlas

filer som är onödiga på servern.

Grafiskt användargränssnitt

Visning av AvanceradVy (se 5.1 Grafiskt användargränssnitt) skulle kunna gömmas för

behörighetsgruppen Koordinerare som vi nämnde ovan. Inga användartester har genomförts

och sådana rekommenderas för att fånga in vidareutvecklingsmöjligheter på det grafiska

användargränssnittet.

54

8 Avslutning

Vi är nöjda med resultatet av examensarbetet, då vi har utvecklat en fungerande prototyp.

Prototypen innehåller simpel visning av media utan komplicerade animationer och

transaktioner och har grunden för att visa presentationsmaterial på surfplattor. Vi har

genomfört en omfattande förundersökning som väglett oss i våra val och vi anser att det

grafiska användargränssnittet är snyggt, innovativt och behagligt att arbeta med. I och med

systemets enkla funktionalitet är det lättare för användaren att lära sig systemet.

Det var svårt att avsluta utvecklingen när vi var medvetna om hur många stories (se avsnitt

2.2) som fortfarande fanns kvar. Efter detta examensarbete har vi fått en djupare förståelse för

Team Foundation Server, Visual Studio och de andra verktyg vi använt i projektet (se avsnitt

2.3).

Utöver utvecklingsdelen har vi också fått en insyn inom digital skyltning som har fångat

bådas intresse. Det finns många utmaningar och utvecklingsområden inom digital skyltning

och det skulle vara roligt att fortsätta inom det området.

55

9 Referenser

[1] ”ltlmagazine,” [Online]. Available: http://www.ltlmagazine.com/article/using-digital-

signage-build-community. [Använd 21 Oktober 2015].

[2] M. Strand, ”Using digital signage to build community,” Using digital signage to build

community, vol. 58, nr 8, pp. 40-46, 2009.

[3] ”Wikipedia,” [Online]. Available:

https://en.wikipedia.org/wiki/Scrum_(software_development). [Använd 21 December

2015].

[4] G. E. K. a. S. T. Pope, ”A Description of the Model-View-Controller User,” ParcPlace

Systems, pp. 1-5, 1988.

[5] ”wikipedia,” wikipedia, [Online]. Available:

https://en.wikipedia.org/wiki/Separation_of_concerns. [Använd 21 Oktober 2015].

[6] ”wikipedia,” wikipedia, [Online]. Available: https://en.wikipedia.org/wiki/ASP.NET/.

[Använd 21 Oktober 2015].

[7] ”wikipedia,” wikipedia, [Online]. Available:

https://en.wikipedia.org/wiki/List_of_CLI_languages/. [Använd 21 Oktober 2015].

[8] [Online]. Available: https://en.wikipedia.org/wiki/Microsoft_Visual_Studio. [Använd

2 December 2015].

[9] ”geekwire,” [Online]. Available: http://www.geekwire.com/2014/net-visual-studio-

microsoft-open-source-cross-platform/. [Använd 2 December 2015].

[10] ”Team_Foundation_Server,” [Online]. Available:

https://en.wikipedia.org/wiki/Team_Foundation_Server. [Använd 11 November 2015].

[11] ”wikipedia,” [Online]. Available: https://en.wikipedia.org/wiki/Entity_Framework.

[Använd 13 01 2016].

56

[12] ”entityframeworktutorial,” [Online]. Available:

http://www.entityframeworktutorial.net/code-first/what-is-code-first.aspx/. [Använd 25

November 2015].

[13] ”draw,” [Online]. Available: https://www.draw.io/. [Använd 25 Oktober 2015].

[14] [Online]. Available: https://en.wikipedia.org/wiki/JQuery. [Använd 22 December

2015].

[15] ”w3techs,” [Online]. Available: [http://w3techs.com/technologies/details/js-

jquery/all/all] . [Använd 4 Januari 2016].

[16] ”Wikipedia,” [Online]. Available: https://en.wikipedia.org/wiki/Bootstrap_(front-

end_framework). [Använd 22 12 2015].

[17] ”nngroup,” nngroup, [Online]. Available: http://www.nngroup.com/articles/mobile-

native-apps/. [Använd 21 Oktober 2015].

[18] ”ddeveloper.android,” 04 Januari 2016. [Online]. Available:

https://developer.android.com/sdk/index.html.

[19] ”developer.android.com,” [Online]. Available:

http://developer.android.com/distribute/tools/open-distribution.html/. [Använd 2 10

2015].

[20] ”msdn.microsoft.com,” [Online]. Available: https://msdn.microsoft.com/en-

us/library/windows/apps/jj206943(v=vs.105).aspx/. [Använd 12 02 2015].

[21] ”netmarketshare,” netmarketshare, [Online]. Available:

https://www.netmarketshare.com/browser-market-share.aspx?qprid=0&qpcustomd=0 .

[Använd 14 Oktober 2015].

[22] ”netmarketshare,” netmarketshare, [Online]. Available:

https://www.netmarketshare.com/browser-market-share.aspx?qprid=0&qpcustomd=1/.

[Använd 14 Oktober 2015].

[23] ”play.google.com,” [Online]. Available: https://play.google.com/store/apps?hl=en/ .

[Använd 14 10 2015].

57

[24] ”intego.com,” [Online]. Available: http://www.intego.com/mac-security-blog/ios-web-

browser-comparison/. [Använd 13 10 2015].

[25] ”mozilla,” [Online]. Available: https://www.mozilla.org/en-US/firefox/ios/. [Använd

13 Januari 2016].

[26] ”windowsphone,” [Online]. Available: http://www.windowsphone.com/en-

gb/search?q=Firefox/. [Använd 13 10 2015].

[27] ”telerik,” [Online]. Available: http://developer.telerik.com/featured/what-is-a-hybrid-

mobile-app/. [Använd 2 December 2015].

[28] ”W3,” [Online]. Available:

https://www.w3.org/community/webed/wiki/Optimizing_content_for_different_brows

ers:_the_RIGHT_way. [Använd 04 Januari 2016].

[29] ”microsoft office,” [Online]. Available: https://support.office.com/en-sg/article/File-

formats-that-are-supported-in-PowerPoint-2010-252c6fa0-a4bc-41be-ac82-

b77c9773f9dc/ . [Använd 25 9 2015].

[30] ”Wiipedia,” [Online]. Available:

https://en.wikipedia.org/wiki/LibreOffice#Supported_file_formats/. [Använd 25 9

2015].

[31] ”OpenOffice,” [Online]. Available: https://wiki.openoffice.org/wiki/Main_Page.

[Använd 26 September 2015].

[32] ”webodf,” [Online]. Available: http://webodf.org/

https://github.com/kogmbh/WebODF/. [Använd 21 Oktober 2015].

[33] ”github,” [Online]. Available: https://github.com/mozilla/pdf.js/. [Använd 21 Oktober

2015].

[34] ”prezi,” [Online]. Available: https://prezi.com/. [Använd 2 December 2015].

[35] ”slidedog,” [Online]. Available: http://slidedog.com/. [Använd 2 December 2015].

[36] ”strut,” [Online]. Available: http://strut.io/. [Använd 2 December 2015].

58

[37] ”Github,” [Online]. Available: https://github.com/impress/impress.js. [Använd 27

januari 2016].

[38] ”Github,” [Online]. Available: http://markdalgleish.com/projects/bespoke.js/. [Använd

27 Januari 2016].

[39] ”gnu,” [Online]. Available: http://www.gnu.org/licenses/agpl-3.0.en.html. [Använd 04

Januari 2016].

[40] ”w3,” [Online]. Available: http://www.w3.org/AudioVideo/. [Använd 2 December

2015].

[41] [Online]. Available: http://www.andreas-schrade.de/2015/02/16/android-tutorial-how-

to-create-a-kiosk-mode-in-android/. [Använd 2 December 2015].

[42] ”MSDN Microsoft,” [Online]. Available: https://msdn.microsoft.com/en-

us/data/jj193542.aspx. [Använd 21 December 2015].

[43] wikipedia, [Online]. Available: https://en.wikipedia.org/wiki/Entity_Framework/.

[Använd 25 November 2015].

[44] T. Sneed, ”develop.com,” [Online]. Available:

https://www.develop.com/onionarchitecture. [Använd 02 12 2015].