avfallshantering: mjukvara för hantering av information...

INOM EXAMENSARBETE DATATEKNIK,GRUNDNIVÅ, 15 HP

, STOCKHOLM SVERIGE 2017

Avfallshantering: Mjukvara för hantering av information och tjänster

En fallstudie i SÖRAB-regionen

ALEXANDER LINDFORS

ERIC AMUNDSSON

KTHSKOLAN FÖR INFORMATIONS- OCH KOMMUNIKATIONSTEKNIK

AbstractSÖRAB is a waste disposal firm that is operative in nine of the municipalities inStockholm County, Sweden. Each municipality has their own separate managementof information and services. SÖRAB aspires to facilitate the process of finding andplacing orders on waste disposal services for the residents in these municipalities.

This thesis examines what should be done in order to centralize the municipalities’waste disposal information into a shared portal. The main difficulties, concerningcentralization, are that the municipalities use different underlying customer systemsand have different practices in regulating waste disposal rates. After proposals forsolutions for the identified problems are presented, an investigation into the mostsuited application type for the portal is conducted. This investigation focuses on acomparison between the two application types native mobile applications and mo-bile web applications. The usability of the portal is considered important. Hencedifferent techniques, aiming to increase the usability of the graphical interface, areresearched and presented. The identified problem areas, the application study andthe usability aspects are the foundation for the development of a functional proto-type of the portal.

The result of the thesis is a prototype of a responsive web application. The pro-totype is implemented with the framework Angular. In order to facilitate potentialfuture development, an architectural document describing the prototype is written.

The thesis can be usable for future implementation projects. It presents a func-tioning methodology, gives insight in usability principles and compares pros andcons with different application types.

Keywords

Web applications, usability, application types, software development, An-gular, responsive design, wireframes, waste disposal management.

3

AbstraktSÖRAB är ett avfallsbolag som är verksamt i nio av Stockholm läns kommuner.Varje kommun har separat hantering av information och tjänster. SÖRAB vill un-derlätta för kommuninvånarna att hitta och beställa tillgängliga avfallstjänster.

Detta examensarbete undersöker vad som krävs för att centralisera kommunernasavfallsinformation i en gemensam portal. De stora svårigheterna kring centralisering-en ligger i att kommunerna använder olika bakomliggande kundsystem och tillämparolika sätt att styra sina avfallstaxor. Efter att lösningsförslag för problemområdenapresenteras, undersöks vilken typ av plattform som passar bäst för portalen. Den-na undersökning jämför de två applikationstyperna nativa mobilapplikationer ochmobila webbapplikationer. En viktig del för portalen anses vara dess användarvän-lighet. I rapporten undersöks och presenteras därför olika tekniker som kan höjaanvändarvänligheten i grafiska gränsnitt. De identifierade problemområdena, appli-kationsstudien och användarvänlighetaspekterna, blir underlag för att utveckla enfunktionell prototyp av portalen.

Examensarbetets resultat är en prototyp av en responsiv webbapplikation. Imple-menteringen sker med ramverket Angular. För att underlätta eventuellt fortsattarbete, skrivs ett dokument som beskriver prototypens arkitektur.

Rapporten kan vara till nytta för framtida implementeringsprojekt. Den uppvisaren fungerande metodik, ger insikt i användarvänlighetsprinciper och jämför för- ochnackdelar med olika applikationstyper.

Nyckelord

Webbapplikationer, användarvänlighet, applikationstyper, mjukvaruutveck-ling, Angular, responsiv design, wireframes, avfallshantering.

4

Innehåll1 Introduktion 7

1.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.4 Mål . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.5 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.6 Disposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Teoretisk bakgrund 112.1 Ansvarsområden i SÖRAB-regionen . . . . . . . . . . . . . . . . . . . 112.2 Existerande underlag . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Programmeringsspråk & ramverk . . . . . . . . . . . . . . . . . . . . 122.4 Relaterad litteratur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 Terminologi: olika typer av applikationer . . . . . . . . . . . . . . . . 142.6 Design av användarvänliga gränssnitt . . . . . . . . . . . . . . . . . . 16

3 Metodik 193.1 Forskningsmetoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Anpassad forskningsmetod . . . . . . . . . . . . . . . . . . . . . . . . 203.3 Fasernas arbetssätt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4 Mjukvaruutveckling - Metoder & verktyg . . . . . . . . . . . . . . . . 24

4 Problemområden för en gemensam portal 274.1 Att hitta information på ett användarvänligt sätt . . . . . . . . . . . 284.2 Kommunernas olika sätt att sköta kundtjänst . . . . . . . . . . . . . 294.3 Enhetlig presentation av taxor . . . . . . . . . . . . . . . . . . . . . . 304.4 Att leverera relevant miljöåterkoppling . . . . . . . . . . . . . . . . . 314.5 Övriga önskemål . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Design och implementering 335.1 Kravspecifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.2 Val av applikationstyp . . . . . . . . . . . . . . . . . . . . . . . . . . 335.3 Design av användargränssnitt . . . . . . . . . . . . . . . . . . . . . . 355.4 En responsiv webbprototyp . . . . . . . . . . . . . . . . . . . . . . . 38

6 Diskussion 436.1 Är frågeställningen besvarad? . . . . . . . . . . . . . . . . . . . . . . 436.2 Framtida arbete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.3 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Bilaga A Uppdragsbeskrivning 49

Bilaga B Kravspecifikation 53

Bilaga C Arkitekturdokument 59

5

1 IntroduktionDetta kapitel ger läsaren en överblick över projektets bakgrund och syfte. Här intro-duceras, bland annat, arbetets problemställning, mål, avgränsningar och disposition.

Avfallsplan

Enligt 15. kap. 41 § i miljöbalken (SFS 1998:808) har varje kommun i Sverige enskyldighet att ta fram en renhållningsordning. Denna skall innehålla en avfallsplan.I paragrafen står skrivet att "...avfallsplanen ska innehålla uppgifter om avfall inomkommunen och om kommunens åtgärder för att minska avfallets mängd och farlighet.Lag (2016:782)"

SÖRAB

SÖRAB är ett regionalt avfallsbolag vars delägare är kommunerna Danderyd, Jär-fälla, Lidingö, Sollentuna, Solna, Stockholm, Sundbyberg, Täby, Upplands Väsbyoch Vallentuna. SÖRAB är verksam i alla dessa kommuner, utom i Stockholm. SÖ-RAB har tillsammans med sina ägarkommuner tagit fram en gemensam avfallsplan[1], som innehåller en uppsättning miljömål. Ett samlingsnamn för SÖRAB, ägar-kommunerna och deras invånare är SÖRAB-regionen.

1.1 Bakgrund

SÖRAB, tillsammans med sina ägarkommuner, vill förenkla för sina kunder1 att hit-ta information om och utföra beställningar av de tjänster som erbjuds. Detta ska skegenom att alla kunder använder en gemensam portal oavsett kommuntillhörighet.Det är viktigt att detta kan utföras på ett användarvänligt och enkelt sätt, samt gekunden återkoppling kring miljönyttan från den valda tjänsten.

Examensarbetet ska undersöka om och hur detta kan genomföras genom en förstu-die tillsammans med SÖRAB och kommunerna. Förstudien bör följas av en kortarestudie angående vilken typ av system som är det bästa valet för att skapa den ge-mensamma portalen. Därefter bör en prototyp utvecklas för hur detta system kanse ut och användas.

1.2 Problem

I dagsläget har SÖRABs ägarkommuner separata hemsidor med olika tjänster, tax-or, öppettider för kundtjänst, bakomliggande kundsystem och så vidare. Detta göratt sammankoppling av en gemensam portal medför vissa svårigheter gällande kom-patibilitet mellan de olika kommunerna, deras bakomliggande affärssystem och derasarbetssätt.

Författarna ställer sig frågan:

Hur kan ett IT-system konstrueras som på ett likformigt sätt, för flerakommuner, informerar om och tillhandahåller avfallstjänster?

1Med kunder avses kommunernas invånare

7

1.3 Syfte

Projektet ger SÖRAB och ägarkommunernas invånare en gemensam portal och gördärmed information mer lättillgänglig. Portalens syfte är att främja kundernas mil-jömedvetenhet genom att till exempel ge återkoppling av miljönyttan som derasavfallssortering och återvinning bidrar till. Detta är ett sätt för SÖRAB och ägar-kommunerna att aktivt arbeta mot uppfyllandet av den gemensamma avfallsplanen[1].

Examensarbetets allmänna syfte är att vara till nytta för och bidra till bredareingenjörskunskap. Rapporten visar ett ingenjörsmässigt arbetssätt vid ett imple-menteringsprojekt.

1.4 Mål

Genomförande av examensarbetet resulterar i ett antal lösningsförslag för hur por-talens utveckling kan genomföras. Det resulterar slutligen i en funktionell prototypav den gemensamma portalen, med tillhörande dokumentation.

Projektet är ett moment i examinationen för högskoleingenjörer på KTH. Rapportenär ett av de dokument som är del av examensarbetets bedömning.

1.4.1 Fördelar

Portalen ger kunder i ägarkommunerna en förenklad möjlighet att hitta informationom beställningsbara tjänster. Ytterligare kan ägarkommunernas avfallshandläggaredagliga arbete förenklas, då portalen bör erbjuda kunderna ett standardiserat sättatt genomföra beställningar.

1.4.2 Hållbarhet

Eftersom en ambition är att främja kundernas miljömedvetenhet finns det tydliga,positiva hållbarhetsaspekter i projektets resultat. Detta sker indirekt genom attinformation angående avfallshantering, som kommunerna erbjuder, blir enklare attta del av jämfört med idag. Den direkta påverkan som portalen har är att kundernafår positiv återkoppling kring deras avfallshantering.

1.4.3 Etik

Projektets genomförare skall under arbetets gång hålla god kontakt med uppdrags-givaren och andra intressenter för att se till att utfört arbete sker i samförståndoch inte bryter mot några andra bestämmelser. Insamling av kundinformation skerendast enligt bestämmelser som godkänts av kunden. Informationen som tillhanda-hålls genom portalen skall i största mån vara tillgänglig för så många som möjligt,oavsett teknisk kunnighet, funktionsnedsättningar eller språkliga förutsättningar.

1.5 Avgränsningar

Uppdragsgivaren anser att det är minst lika viktigt att få ett resultat av förunder-sökningen som att prototypimplementationen blir påbörjad eller färdigställd. Upp-

8

draget bör inte medföra en förändring av hur avfallshandläggare i ägarkommunernaarbetar, utan bör förenkla för deras kunder att ta del av information och beställatjänster. Projektet innehåller en tidig prototyp av den gemensamma portalen, somkan ses som en grund för framtida arbete.

1.6 Disposition

Rapporten innehåller kapitel om projektets teoretiska bakgrund, metodik, veten-skaplighet, projektets utförande, resultat och slutsatser. Följande punkter samman-fattar innehållet i varje kapitel.

2 Teoretisk Bakgrund - Kapitlet ger läsaren en bredare bild av projektetsbakgrund. Teknisk terminologi som kan vara av nytta för läsaren presenteras.Slutligen presenteras olika användarvänlighetsprinciper för design av grafiskagränssnitt.

3 Metodik - Kapitlet beskriver teoretiska forskningsmetoder och hur de anpas-sats för användning i projektet. Projektets olika faser presenteras med tillhö-rande metodik. Slutligen ingår kapitel om hur den anpassade metoden kankopplas till generell utveckling av mjukvara.

4 Problemområden för en gemensam portal - Detta kapitel består av enanalys av projektets första fas; förundersökningen. Lösningsförslag för de iden-tifierade problemområdena presenteras, tillsammans med resonemang kringgenomförbarhet.

5 Design och implementering - Kapitlet innehåller en jämförelse mellan olikatyper av applikationer där för- och nackdelar vägs mot varandra, motsvaran-de fas 2; applikationsstudien. Dessutom ingår en presentation av förarbetetför fas 3; prototypimplementationen. Förarbetet består av resonemang kringanvändarvänlighet och designval. Slutligen presenteras resultatet av implemen-teringen.

6 Diskussion - Kapitlet består av en diskussion av projektets metodik, resultatoch framtida arbete. Slutligen presenteras examensarbetets slutsatser.

9

2 Teoretisk bakgrundDetta kapitel presenterar bakgrundsinformation som kan vara av intresse för läsareav denna rapport. Kapitlet består av underkapitel om ansvarsområden i SÖRAB-regionen, existerande underlag, programmeringsspråk & ramverk, relaterad littera-tur, principer för webben och slutligen användarvänlighetsprinciper för design avgrafiska gränssnitt. Kapitlet finns för att ge en djupare förståelse för projektets för-utsättningar och problemområden beskrivs.

2.1 Ansvarsområden i SÖRAB-regionen

Vem gör vad med avfallshanteringen i SÖRAB-regionen? Rubrikerna nedan förtyd-ligar hur ansvaret är fördelat mellan kunden, kommunen och SÖRAB vid hanteringav avfall. Informationen är hämtad från SÖRABs hemsida [2].

Kundens ansvar

Privatpersonens primära ansvar är att se till att avfallet hamnar där det hör hemma.Fastighetsägaren är skyldig att ha en insamlingsplats för avfall, nära eller i bostaden.För flerfamiljshus innebär det att det måste finnas ett soprum där avfall kan sorteras.

Varje bostad ansvarar för att betala renhållningsavgiften för att bedriva den kommu-nala avfallshanteringen. Avgiften ingår i hyran/avgiften för boende i flerfamiljshus.

Kommunens ansvar

Kommunen ansvarar för att informera sina invånare om de bestämmelser som gälleroch om relevant avfallshantering. Kommunen ansvarar även för att samla in, trans-portera bort och hantera avfall. Hämtningen utförs av en upphandlad entreprenör.De entreprenörer som används i SÖRAB-regionen är Rang-Sells, RenoNorden ochSuez (tidigare Sita). Vissa kommuner har egen kundtjänst för avfall, medan andrahar lagt över ansvaret på den upphandlade entreprenören. Kommunen ansvarar föratt hålla ett dokument med de taxor som gäller för de avfallstjänster som kunderkan nyttja.

SÖRABs ansvar

SÖRAB ansvarar för att behandla avfallet som uppstår i ägarkommunerna. SÖRABdriver de återvinningscentraler som finns i regionen.

2.2 Existerande underlag

Under projektets gång har tillgänglig information rörande kommunernas avfallshan-tering och tidigare arbeten tagits del av. De mest relevanta underlagen beskrivsnedan.

2.2.1 Ägarkommunernas hemsidor

Varje kommun i SÖRAB-regionen sköter sin egen hemsida, där all information somrör avfall och återvinning samlas. Författarna använder delvis hemsidorna som un-

11

derlag för att utföra förundersökningen, genom att sammanställa den informationoch de tjänster som tillhandahålls.

2.2.2 Sören - Sorteringsguiden i SÖRAB-regionen

Sören [3] är ett av SÖRABs tidigare projekt som syftade att tillhandahålla informa-tion rörande avfallssortering. Tjänsten skulle samla information från alla kommunerpå en hemsida, men skalades ned efter att det beslutades att den var krånglig attunderhålla2. Sidan erbjuder idag hjälp med att kategorisera avfall och sortering.Tjänsten ses som en inspirationskälla för det aktuella arbetet.

2.2.3 Suez mobilapp ’Källsortera’

Suez är en avfallsentreprenör som har skapat en mobilapplikation för sorteringshjälp,som heter Källsortera. Med denna applikation är det möjligt att söka på specifikarestprodukter, för att få upp den korrekta avfallskategoriseringen och tillhörandeinformation om hur och var man gör sig av med produkter inom kategorin. Tjänstenfinns även tillgänglig via Suez hemsida [4]. Applikation ses som en inspirationskällatill det aktuella arbetet.

2.2.4 EDP Future Avfall & BFUS

EDP Future Avfall och BFUS är kundhanteringssystem som används av ägarkom-munerna och deras entreprenörer. Samtliga kommuner i regionen, utom Sollentuna,använder EDP Future Avfall. Examensarbetet ska delvis undersöka om det går attbygga en portal som har åtkomst till kundsystemet, till exempel via ett API.

2.3 Programmeringsspråk & ramverk

Ett ramverk används för att underlätta utveckling, genom att bland annat erbju-da vanligt förekommande funktionalitet för mjukvara inom samma kategori. Ett avmånga ramverk för utveckling av webbapplikationer är Angular ; ett projekt somdrivs av Google3. Angular skrivs med programmeringsspråket TypeScript. Type-Script är ett språk utvecklat av Microsoft, som vid kompilering översätts till Java-Script, som enligt W3C (World Wide Web Consortium) är standard för programme-ring på webben. Styrkan i TypeScript ligger i att det är ett så kallat statiskt typat(eng. statically typed) språk, vilket, enkelt sammanfattat, leder till att utvecklings-miljön kan varna och visa fel innan kod körs. Detta kan i sin tur, enligt Microsoft4,leda till ökad produktivitet och underlättad testning och felsökning.

2Enligt handledare och kontaktpersoner på SÖRAB.3Läs mer på www.angular.io/features.html4Läs mer på www.typescriptlang.org/docs/home.html

12

2.4 Relaterad litteratur

I detta kapitel introduceras några rapporter och artiklar som har haft stor påver-kan på examensarbetets metodik och genomförande. Varje underkapitel förklararkort vad de olika texterna innehåller och var, i denna rapport, som de införskaffadekunskaperna används.

Niclas Andersson & Anders Ekholm - Vetenskaplighet - Utvärdering avtre implementeringsprojekt inom IT, Bygg & Fastighet [5]

Denna rapport beskriver olika metoder för att höja den vetenskapliga nivån i ettimplementeringsprojekt. Några av de termer och resonemang som används är kvali-tativa och kvantitativa forskningsmetoder, deduktiv och induktiv teoribildning samten teknologisk forskningsprocess. Beskrivning av metoderna, och hur de används iexamensarbetet, presenteras i kapitel 3.

William M.K. Trochim - Deduction & Induction [6]

Denna artikel beskriver deduktiv och induktiv teoribildning. Artikelns beskrivningarpresenteras i kapitel 3.1.1. Beskrivningarna hjälper till att definiera en metod, somsenare anpassas för användning i examensarbetet. Den anpassade metoden presen-teras i kapitel 3.2.

William Jobe - Native apps vs mobile web apps. [7]

Denna artikel beskriver en fallstudie på skillnaden mellan nativa mobilapplikationeroch mobila webbapplikationer. Fallstudien behandlade två mobila webbapplikatio-ner som användes av löpare i Kenya. Dessa jämfördes, via intervjuer med löparna,sedan med motsvarande nativa mobilapplikationer.

Det relevanta fyndet i denna undersökning, är att nativa mobilapplikationer är detbästa valet för applikationer som kräver hårdvarutillgång. Det bör dock nämnas attjämförelsen endast betraktade mobiltelefonernas GPS och ingen annan hårdvara.Artikeln används som underlag vid den jämförande diskussionen i kapitel 5.2.1.

Jim Conallen - Modeling Web Application Architectures with UML [8]

Denna publicering ger en definition av en mobil webbapplikation och hur man mo-dellerar en sådan med UML.

Det som är relevant för examensarbetet är definitionen av en webbapplikation ochdess skillnad från en webbsida. Denna definition beskrivs i kapitel 2.5, som senareingår i jämförelsen mellan applikationstyper. Denna jämförelse finns i kapitel 5.2.

Jacob Nielsen - 10 Usability Heuristics for User Interface Design [9]

Denna publicering beskriver 10 tumregler för design av användarvänliga gränssnitt.De relevanta tumreglerna beskrivs i kapitel 2.6. Dessa används som underlag i kapitel5.3, för att ta fram en grund för ett användarvänligt gränssnitt.

13

2.5 Terminologi: olika typer av applikationer

Följande kapitel presenterar terminologi för webben och applikationsutveckling. Ter-minologin kan vara av nytta för att följa resonemang under projektets applikations-studie. De termer som beskrivs är statiska webbplatser, dynamiska webbplatser,responsiv webbdesign, webbapplikationer, nativa mobilapplikationer och hybrida ap-plikationer.

2.5.1 Statisk webbplats

Innehållet på en statisk webbplats ser likadan ut för varje besökare varje gång denbesöks. Det som ändrar innehållet och informationen är, formella eller informella,uppdateringar av källkoden från utvecklaren. Att en webbplats är statisk betyderatt användaren inte direkt kan bidra till eller påverka innehållet, då den helt ochhållet består av logik på klientens sida. Det är därmed inte komplexiteten i webb-platsens innehåll eller formgivning som avgör om den bör klassas som statisk [10][11] [12] eller inte. Det lättaste sättet att beskriva en statisk webbplats är genomatt kontrastera den mot en dynamisk webbplats.

Konkreta exempel på statiska webbplatser är sådana där besökarna endast kan kon-sumera innehåll, utan fokus på att producera innehåll. De är alltså helt informa-tionsbaserade, som till exempel uppdragsgivarens webbplats5.

2.5.2 Dynamisk webbplats

En dynamisk webbplats har möjligheten att presentera personaliserat innehåll förbesökaren. Det sker genom att den dynamiska webbplatsen använder sig av datalagrat antingen i klientens webbläsare eller i en databas på en server. Innehålletoch presentationen kan variera beroende på vilket operativsystem eller webbläsaresom besökaren använder. Det är viktigt att poängtera att det inte är användar-gränssnittets komplexitet som avgör om webbplatsen är statisk eller dynamisk. Detavgörande är huruvida användare kan publicera, och därmed förändra innehållet,utan utvecklarens inverkan [11] [12] [13].

Dynamiska webbplatser låter besökaren både konsumera och producera innehåll.Exempel är forum och sociala medier.

2.5.3 Responsiv webbdesign

Ett problem som uppstår vid utvecklingen av en hemsida är anpassning till god-tycklig skärmstorlek. För att en hemsida ska ha ett anständigt utseende på bådedatorskärmar och mindre skärmar på mobila enheter, bör den ha en så kallad respon-siv design. Detta kan bland annat lösas genom att använda CSS3 Media Queries,introducerat av W3C (World Wide Web Consortium) år 2008, som låter utvecklaredefiniera olika utseenden för webbplatsen, beroende på skärmens storlek [14, s. 37].

5www.sorab.se

14

2.5.4 Webbapplikation

En webbapplikation är ett mjukvarusystem med ett logiskt tillstånd (eng. Businessstate), vars klient levereras via webben till besökarens webbläsare; en definition en-ligt Conallen [8]. Tillståndet kan antingen hållas i webbläsaren eller på en server,beroende på behov och funktionalitet. Conallen fortsätter med att konstatera attinnehållet i en webbapplikation inte nödvändigtvis behöver skilja sig från dynamiskaeller statiska webbplatser. Skillnaden ligger i hur sidan används; dess syfte, och hurden presenteras; dess användargränssnitt [8]. Det betyder att en webbapplikation tillutseendet ofta kan likna en skrivbords- eller mobilapplikation, men att den serverastill användaren via en webbläsare.

En webbapplikation kan utvecklas som en så kallad Single-Page Application. Detbetyder att hela applikationen hämtas från servern på en gång. Det kan leda till enlångsammare första hämtning av sidan, men snabbar upp påföljande operationer in-om applikationen, då man inte behöver förlita sig på konstant kontakt med servern.Det ger användaren fördelar från nativa applikationer, hög interaktivitetsgrad, ochfrån webbplatser, hög portabilitet och tillgänglighet [15].

En webbapplikation kan vara antingen statisk, dynamisk eller en blandning av ty-perna. Huvudsaken är att ge besökaren en användarvänlig upplevelse, som liknar ennativ skrivbords- eller mobilapplikation.

2.5.5 Nativ mobilapplikation

En nativ mobilapplikation är en applikation som skapats specifikt för en mobil en-hets operativsystem. En sådan applikation kan ha full tillgång till den hårdvara(kamera, accelerometer, GPS m.m) som den mobila enheten innehåller, varför ennativ applikation bör användas då enhetens hårdvara ska utnyttjas. Detta bekräftasav en fallstudie, baserad på GPS-använding på Android-telefoner, utförd av W. Jobevid Stockholms universitet 2013. [7] Nativa mobilapplikationer är färdigkompileradeoch kan laddas ned till enheten, oftast via en marknadsplats (t.ex App Store ellerGoogle Play). Det är via dessa marknadsplatser en mobilapplikation måste granskas,innan den blir tillgänglig för allmänheten. En applikation måste genomgå sammagranskningsprocess vid påföljande uppdateringar, vilket kan göra underhållsarbetetlångsammare [16].

Det programmeringsspråk som används för utveckling av nativa mobilapplikatio-ner beror på vilket operativsystem mobiltelefonen använder. De två mest användaoperativsystemen för mobiltelefoner 2016, globalt och i Sverige, var Android ochiOS, enligt data från IDC (International Data Corporation) och Statcounter [17][18]. De populära programmeringsspråken som används för utveckling för ovanstå-ende operativsystem är Java (Android) [19] och Swift6 (iOS) [20]. Detta leder till atten applikation behöver flera utvecklingsprocesser för att maximera tillgänglighetenhos användare.

6Tidigare har Objective C varit ett populärt val för utveckling av iOS-appar, men Apple re-kommenderar att använda Swift.

15

2.5.6 Hybrid applikation

Hybrida applikationer är, som namnet avslöjar, en blandning av en nativ och en web-bapplikation. De utvecklas med webbteknologier som HTML5, CSS & JavaScript.De kompileras sedan till en applikation som kan laddas ner och installeras, precissom en nativ applikation. Detta leder till att teknologin ärver både för- och nackdelarfrån nativa applikationer och webbapplikationer. Till exempel anses en av de störstanackdelarna med nativa applikationer att de kräver nedladdning från en marknads-plats. Det stämmer även för en hybrid applikation. Tidsåtgången, och därmed ävenkostnaden, för att utveckla en nativ applikation är överlag stor och beroende påkomplexiteten förs en stor del av detta över på utveckling av en hybrid applikation[21]. För att nå maximal spridning på en nativ applikation, bör den utvecklas bådetill iOS och Android. Detta kan reduceras till endast en utvecklingsprocess för enhybrid applikation, vilket generellt är dess starkaste fördel. En hybrid applikationhar närmare åtkomst till enhetens hårdvara än en webbapplikation, men inte likanära åtkomst som en nativ applikation [21] [22].

2.6 Design av användarvänliga gränssnitt

För att utforma ett grafiskt gränssnitt på ett användarvänligt sätt, finns det ettantal tumregler som kan följas. De är till stor del utformade av Jakob Nielsen, fil.dri människa-dator interaktion, som under många år har forskat kring användarvänlig-het. Han har tagit fram tio tumregler (eng. heuristics) som kan användas vid designav användargränssnitt [9]. De beskriver vad utvecklaren bör ha i åtanke för att un-derlätta interaktionen mellan användaren och gränssnittet så mycket som möjligt.Det finns en generell metod som kan användas för att tidigt i ett utvecklingsarbeteskapa en grafisk bild över hur ett gränssnitt kan komma att se ut. Detta kallas för ensidmall (eng. wireframe). Följande kapitel beskriver dessa två användarvänlighetsa-spekter.

2.6.1 Tumregler

De tumregler som Nielsen presenterar kan appliceras på i stort sett alla typer avsystem och applikationer, där det huvudsakliga syftet är att förbättra användarensupplevelse. De som anses vara relevanta och som på störst sätt kan påverka denaktuella portalens användarvänlighet lyfts fram. Nedan följer en kort beskrivning avnågra av användarvänlighetstumreglerna.

1. Minimera användarens minnesbelastning. Gör olika val ochlänkar synliga och lättillgängliga. Användaren ska inte behöva me-morera information från tidigare steg i en kedja av val.

2. Systemet ska använda språk som användaren är van vid.Termer och ord ska vara anpassade till den verklighet som använ-daren lever i.

3. Ge användaren kontroll över sina handlingar. Låt dem av-bryta pågående operationer och markera tydligt hur dem kan ta sigtillbaka för att göra om tidigare steg.

16

4. Tydliggör systemets status. Håll alltid användaren uppdateradom vad som händer genom att visa var de befinner sig och vadsystemet gör.

5. Förhindra fel. Utforma en design som gör det svårt för användarenatt göra fel.

6. Använd beskrivande felmeddelanden. Om något ändå går fel,hjälp användare att identifiera, diagnostisera och återställa frånfelet.

7. Bistå med hjälp & dokumentation. Ge användaren tillgång tillhjälp som är enkel att hitta och följa.

8. Begränsa komplexitet i designen. Använd inte information somanvänds sällan, då den konkurrerar med den mer relevanta infor-mationen.

Samtliga tumregler ovan är från Nielsens sammanfattade lista av de, enligt ho-nom, viktigaste aspekterna vid användarvänlig gränssnittsdesign [9]. De kallas förtumregler eftersom att de inte är specifika riktlinjer eller regler.

2.6.2 Sidmallar

En sidmall är en skiss av ett grafiskt gränssnitt, som kan tas fram innan kodningpåbörjas. Skissen ska inte representera den färdiga formen, som till exempel färgeroch innehåll, utan är till för att finnas som grund för vilka funktioner och elementska finnas i den färdiga produkten, helst med så få detaljer som möjligt. Teknikenkan användas till alla typer av applikationer för att tidigt i utvecklingen skapa enbild av hur gränssnittet bör se ut, men det används oftast vid utveckling för webben.De går att göra med papper och penna eller med något datorprogram; huvudsakenär att det ska gå snabbt och vara kontinuerligt förbättrande [23] [24].

Mallen kan ses som en tidig prototyp, som kan användas för att genomföra testerpå tänkta användare. Det är nyttigt att tidigt i projekt fastställa vad som fungerar,och vad som kan förbättras, då det är enklare och billigare att göra ändringar innankod har skrivits [24].

17

3 MetodikDetta kapitel börjar med att beskriva bakgrunden till olika teoretiska forskningsme-toder och hur de anpassats till examensarbetet. Sedan introduceras examensarbetetsfaser med tillhörande arbetssätt. Slutligen introduceras en övergriplig teoretisk bildav mjukvaruutvecklingsprocessen och hur den används i examensarbetet.

3.1 Forskningsmetoder

Det finns ett flertal etablerade metoder för vetenskaplig forskning. Metoderna ärmer eller mindre passande för olika typer av forskningsområden, problemställning-ar och målsättningar. En utvärdering av det aktuella projektet måste därför görasinnan en forskningsmetod väljs och appliceras. Följande kapitel innehåller teoretis-ka beskrivningar av forskningsterminologi. De termer som beskrivs är kvantitativaoch kvalitativa forskningsmetoder, deduktiv och induktiv teoribildning. Slutligenpresenteras en forskningsprocess framtagen specifikt för teknologiska projekt.

3.1.1 Allmänna forskningsmetoder

Följande kapitel beskriver teorin bakom kvantitativa och kvalitativa forskningsme-toder och induktiv och deduktiv teoribildning.

Kvantitativa och kvalitativa forskningsmetoder

Enligt Ekholm & Andersson kan forskningsmetoder delas in i kvantitativa och kva-litativa metoder [5, s. 24]. Kvalitativa metoder inkluderar arbete med fokusgrupper,djupgående intervjuer och granskning av dokument efter gemensamma teman [25].Detta ställs i kontrast till kvantitativa metoder som använder sig av undersökningar(eng. surveys), observationer, experiment och granskning av numeriska data. Kvali-tativa metoder fokuserar alltså på analys av text som resulterar i fördjupade fynd omett fåtal fall, medan kvantitativa metoder analyserar siffror som resulterar i bredarefynd om ett flertal fall. Det leder till att analys, vid användning av kvalitativa me-toder, inte går att formulera med statistiska slutsatser, vilket dock faller sig naturligvid användning av kvantitativa metoder [25], då den insamlade datan är mätbar.

Ekholm & Andersson säger att den kvalitativa metoden passar väl till implemen-teringsinriktade studier och att datainsamlingen, analysen och tolkningen är över-lappande". De menar vidare att gränsen mellan de olika momenten är tydligare vidanvändning av kvantitativa metoder [5, s. 24].

Deduktiv och induktiv teoribildning

Ekholm & Andersson menar att en teori kan utvecklas via antingen en deduktiv elleren induktiv metod [5, s. 21]. En deduktiv teoribildning går från generell information,till specifika slutsatser, enligt Trochim [6]. Han menar att, utifrån en bred teori kanmer specifika och verifieringsbara hypoteser bildas. Genom dessa observationer kanhypoteserna alltså bevisas eller motbevisas.

Induktiv teoribildning fungerar, enligt Trochim, tvärtom. Den går från specifika

19

observationer, till generella teorier. Med observationer som utgångspunkt, upptäcksmönster som kan användas för att formulera preliminära hypoteser. Utifrån de for-mulerade hypoteserna kan generella teorier skapas [6].

Vanligtvis används induktiv teoribildning vid kvalitativa forskningsmetoder för attformulera frågeställningar och hypoteser. Omvänt används vanligtvis deduktiv te-oribildning vid kvantitativa forskningsmetoder [25]. En stor skillnad mellan de tvåär hur deduktiva metoder ofta leder till resultat som är verifieringsbara.

3.1.2 En teknologisk forskningsprocess

Ekholm & Andersson presenterar en metod för teknologisk forskning [5, s. 17], somär baserad på en generell vetenskaplig arbetsmetod. De 10 stegen kan ses i figur 1.

Figur 1: Tio steg för en teknologisk forskningsprocess som de presenteras av Andersson & Ekholm

3.2 Anpassad forskningsmetod

I examensarbetet används kvalitativa forskningsmetoder för att införksaffa en för-djupad förståelse av ett fåtal problemområden. Eftersom att underlaget7 i stort settär rent textbaserat, är det rimligt att använda dessa metoder i det här fallet.

Teoribildningen sker genom en induktiv metod, alltså att ett specifikt och subjektivtproblemområde utforskas för att skapa en bredare, generaliserad teori. Valet av attkalla arbetet för en fallstudie förstärks av Ekholm & Andersson som säger att:

"Vid förändrings/implementeringsinriktade studier är det naturligt attvälja någon form av fallstudie, case studies, där flera variabler som in-verkar på förändringen kan identifieras." [5, s. 24]

De fortsätter med att poängtera att detta metodval medför att de som berörs avimplementeringen bör involveras i forskningsarbetet i en iterativ process. Det sker

7Se kapitel 2

20

genom kontinuerlig kontakt med uppdragsgivare och andra intressenter.

En översikt över den arbetsprocess som examensarbetet följer kan ses i figur 2.Det är en omarbetad version av den teknologiska forskningsprocessen presenteradav Andersson & Ekholm [5, s. 17], som introducerats i kapitel 3.1. De rödmarkeraderaderna är de som modifierats för att bättre motsvara examensarbetets metodik.

Figur 2: En omarbetad teknologisk forskningsprocess för projektarbetet, baserad på Andersson &Ekholm

Till författarnas hjälp att besvara examensarbetets frågeställning, som tidigarepresenterats i kapitel 1.2, ställer de sig följande delfrågor:

1. Kan systemet konstrueras?

2. På vilket/vilka olika sätt kan uppdragsgivarens mål uppfyllas?

3. Till vilken plattform passar systemet bäst?

4. Med vilken/vilka teknologier bör systemet utvecklas?

5. Vilken typ av arkitektur bör systemet ha?

6. Vilket arbetssätt bör systemets fortsatta utveckling följa?

För att besvara delfrågorna, delades projektet in i tre faser utifrån uppdragsbeskriv-ningen8. De identifierade faserna kallas härefter:

A. Förundersökning

B. Applikationsstudie

C. Prototypimplementation

Fas A ska besvara delfråga 1 och 2 och resulterar i en kravspecifikation och därmedäven underlag för påföljande fas. Fasen motsvarar ungefär punkt 1, 2 och delvispunkt 3 i figur 2 där en korrekt och heltäckande förståelse för problemområdet ska-pas.

Fas B ska besvara delfråga 3 och 4 och resulterar i ett val av applikationstyp för det8Se bilaga A

21

beskrivna systemet och ger därmed underlag för den sista fasen. Fasen motsvararalltså ungefär punkt 4 och delvis punkt 5 i figur 2.

Fas C ska slutligen besvara delfråga 5 och 6 och resulterar i en funktionell prototypmed tillhörande arkitekturdokumentation. Fasen fortsätter i punkt 5 och sträckersig genom resten av punkterna i figur 2.

3.3 Fasernas arbetssätt

Följande kapitel ger en fördjupad inblick i metodiken för genomförandet av fasernai examensarbetet.

3.3.1 Fas A: Förundersökning

Förundersökningen ska besvara delfrågorna:

• Kan systemet konstrueras?

• På vilket/vilka olika sätt kan uppdragsgivarens mål uppfyllas?

Första delen av förundersökningen gick ut på att identifiera problemområden. Deidentifierades genom att, med uppdragsbeskrivningen i åtanke, besöka kommunernashemsidor och leta efter information. Genom kontakt med uppdragsgivare och deolika kommunerna formades en djupare förståelse för problemområdet, av vad deförväntar sig och vill lyfta fram i systemet. Efter att problemområden identifierats,påbörjades en iterativ process för att fullständigt förstå var och en av dem och tafram lösningsförslag. Denna iterativa process visas i figur 3. Lösningsförslagen ochden djupare förståelse för problemet resulterar i underlag för nästkommande fas.

22

Figur 3: Överblick över metoden för examensarbetets fas A; förundersökningen

3.3.2 Fas B: Applikationsstudie

Applikationsstudien utförs för att besvara delfrågorna:

• Till vilken plattform passar systemet bäst?

• Med vilken/vilka teknologier bör systemet utvecklas?

Efter förundersökningen undersöktes vilken typ av applikation som bäst passar dentyp av tjänst som uppdragsgivaren önskar. Studien baseras på dialog med uppdrags-givare och litteraturstudier för att göra välgrundade beslut. Forskningslitteratur hit-tades främst via sökmotorn Google Scholar men även mindre vetenskapliga artiklaroch publikationer användes som underlag. Relevanta texter granskades för att inför-skaffa förståelse för för- och nackdelar med olika typer av applikationer. Kapitel 5.2innehåller en sammanfattning av de fynd som gjordes under studien. Inför proto-typimplementationen togs, förutom studiens fynd, befintliga kunskaper inom olikateknologier och ramverk i beaktning för att systemet ska kunna implementeras påett modernt och effektivt sätt. Figur 4 visar använd metodik för att bestämma denbäst passande applikationstypen.

23

Figur 4: Överblick över arbetsmetod för att genomföra applikationsstudien.

3.3.3 Fas C: Prototypimplementation

Fasen genomförs för att besvara delfrågorna:

• Vilken typ av arkitektur bör systemet ha?

• Vilket arbetssätt bör systemets fortsatta utveckling följa?

Genom underlag som tagits fram under tidigare faser påbörjades implementation aven funktionell prototyp. Kunskap inom den valda applikationstypen, programme-ringsspråket och ramverket erhölls genom att läsa guider, titta på utbildningsvideoroch genom praktisk övning. Efter att tillräcklig kunskap införskaffats påbörjadesarbetet enligt den inkrementella metoden som kan ses i figur 5.

3.4 Mjukvaruutveckling - Metoder & verktyg

Följande kapitel beskriver den generella processen bakom mjukvaruutveckling ochhur den motsvaras av examensarbetet, med tillhörande metod för system- och arki-tekturdokumentation.

24

Figur 5: Arbetsmetod som följs under implementeringsarbetet

3.4.1 Mjukvaruprocess

Det finns flera filosofier och teorier om vilket som är det bästa tillvägagångssättet föreffektiv mjukvaruutveckling. Enligt Sommerville finns det dock fyra grundläggandeaktiviteter som måste finnas i varje mjukvaruprojekt[26, s. 28]:

1. Specifikation - Identifiera och definiera villkor och funktionalitet förmjukvaran

2. Design & implementation - Mjukvaran tas fram enligt specifikation

3. Validering - Uppfyller implementeringen specifikationen?

4. Evolution - Kontinuerlig utveckling av mjukvaran för att möta för-ändrade krav och mål

Stegen sker i en cykel i en inkrementell metod där steg 4 leder till steg 1, för konstantförbättring av mjukvaran [26, s. 61]. Examensarbetets faser som beskrivits tidigarei kapitlet kan enkelt kopplas till stegen. Steg 1, specifikationen, samlades under ex-amensarbetets faserna A och B; förundersökningen och applikationsstudien, genomkontinuerlig kontakt och förankring med uppdragsgivare. Steg 2, steg 3 och 4 sked-de kontinuerligt under fas C, prototypimplementationen. Överlag används alltså eninkrementell modell med inslag av iterativa processer genom hela examensarbetet,som tidigare beskrivits i kapitel 3.3.

I moderna utvecklingsprojekt är det gynnsamt att kunden involveras i arbetet ti-digt och kontinuerligt, då det ger god insikt vid evaluering av iterationernas resul-tat. Inkrementellt arbete låter kunden justera och specificera önskemål och kravmed låg effekt på kostnad och tidsåtgång [26, s. 33, 60]. Sommerville säger vida-re att ett inkrementellt arbetssätt passar bra för de flesta mindre, till medelstora,affärssystem[26, s. 706], då det, genom att bryta ned ett större problem i mindredelar, liknar hur människor vanligtvis löser problem [26, s. 33]. Detta liknar detsätt som fas A och främst fas C genomför, genom förankring och återkoppling frånuppdragsgivaren.

25

3.4.2 System- & arkitekturdokumentation

Eftersom dokumentationen i ett inkrementellt mjukvaruprojekt är föränderlig i sinnatur, finns det svårigheter för framtida underhållningsarbete av mjukvaruprojekt.Svårigheten ligger i att den formella dokumentationen minimeras under utveckling-en. Detta motverkas genom att hålla god kvalitet och läsbar kod, vilket enligt agilaentusiaster leder till goda förutsättningar för framtida underhåll, menar Sommerville[26, p. 61]. Han fortsätter med att poängtera att i ett sådant fall är kravspecifika-tionen det dokument som bör användas som referensram av framtida utvecklare,eftersom att det bör innehålla tillräcklig information om vad systemet ska kunnaanvändas till [26, p. 61].

I examensarbetet sköttes en något högre grad av formell systemdokumentation föratt underlätta överlämning av projektet för framtida utvecklingsarbete. Detta an-sågs viktigt då det i första hand inte kommer att handla om ett underhållsarbete,utan om att ta den under examensarbetet framtagna prototypen till en färdig portal.Samtidigt har arbetet med att skriva välstrukturerad och läsbar kod skett kontinu-erligt. Även detta för att ge portalen en stabil grund för fortsatt arbete. Parallelltmed implementationen skrevs ett arkitekturdokument, som kan vara av nytta förframtida utvecklare. Detta dokument kan ses i bilaga C.

26

4 Problemområden för en gemensam portalDet finns ett flertal svårigheter kopplat till att skapa en portal för de nio kommu-nerna i SÖRAB-regionen. De problem som troligtvis har störst påverkan på detfärdiga systemet identifierades som problemområden. Detta kapitel innehåller enpresentation av dessa problemområden, följt av en beskrivning av varje område medtillhörande lösningsförslag.

Det system som projektet ska implementera kommer i detta och följande kapitelenbart refereras till som portal eller portalen, om inget annat anges.

Identifierade problemområden

Nedan följer en sammanfattning av varje identifierat problemområde.

1. Att hitta information på ett användarvänligt sätt

• Problemområdet anses viktigt att lösa för att uppfylla uppdragsgivarensönskan om att den gemensamma portalen ska förenkla för kunderna atthitta information om och utföra beställningar av de tjänster som erbjuds,vilket beskrivs i kapitel 1.1; examensarbetets bakgrund. En mer utförligbeskrivning av problemområdet, tillsammans med lösningsförslag, ses ikapitel 4.1.

2. Kommunernas olika sätt att sköta kundtjänst

• Anledningen till att detta problemområde identifierats som viktigt äruppdragsgivarens önskan att bakomliggande affärssystem ska vara kom-patibla med en gemensam portal. Kort om detta går att läsa i kapitel 1.1;examensarbetets bakgrund och i examensarbetets uppdragsbeskrivning,som kan ses i bilaga A. En mer utförlig beskrivning av problemområdet,tillsammans med lösningsförslag, ses i kapitel 4.2.

3. Enhetlig presentation av taxor

• Att hitta ett gemensamt sätt att presentera taxorna anses vara viktigt,eftersom priset för en beställningsbar tjänst förväntas vara tillgängligtpå ett genomtänkt sätt. En mer utförlig beskrivning av problemområdet,tillsammans med lösningsförslag, ses i kapitel 4.3.

4. Att leverera relevant miljöåterkoppling

• Att ge kund återkoppling gällande den miljöpåverkan som en beställdtjänst står för anses vara en viktig del av den gemensamma portalen.Att främja kundens miljömedvetenhet är ett av SÖRABs huvudsakligasyften med projektet. Mer om det kan läsas i kapitel 1.1 och i uppdragsbe-skrivningen i bilaga A. En mer utförlig beskrivning av problemområdet,tillsammans med lösningsförslag, ses i kapitel 4.4.

27

5. Övriga önskemål

• Under förundersökningen har andra önskemål identifierats som inte klas-sats som problemområden. De ses istället som intresseområden som, imån av tid och resurser kan ingå i portalen. En önskan om att en sorte-ringsguide kan integreras i portalen har uttryckts. Kapitel 4.5 innehålleren diskussion kring genomförbarheten av dessa önskemål.

4.1 Att hitta information på ett användarvänligt sätt

I dagsläget kan kommunernas avfallsinformation hittas genom att navigera genomett antal hyperlänkar på respektive kommuns hemsida.

Figur 6: Den väg som en kund måste ta genom en av kommunernas hemsidor för att hitta infor-mation kring hantering av farligt avfall

Figur 6 visar ett diagram över den väg som en kund måste ta genom en av kom-munhemsidorna9 för att hitta information. Varje bubbla representerar en aktiv sidasom visas för besökaren och varje pil representerar ett klick på en länk. Rutornavisar hur många olika val som besökaren kan göra på varje sida, inklusive det kor-rekta valet. Det scenario som presenteras i exemplet är att en besökare vill hittainformation angående hantering av farligt avfall.

4.1.1 Lösningsförslag - Följ etablerade riktlinjer för användarvänlig de-sign av gränssnitt

Man bör sträva efter att alltid se till att användaren vet exakt var de befinner sigi en process. Det betyder att man till exempel kan visa för användaren att den förnärvarande befinner sig på steg 1 av 3, samtidigt som man visar vad som väntar sigi nästa steg.

Tumreglerna för användarvänlig design, som presenterats i kapitel 2.6, följs vidprototypimplementationen, för att ge portalen hög användarvänlighet. Kapitel 5.3innehåller mer information om hur användarvänlighetsprinciper har använts i exa-mensarbetet.

9Diagrammet avser vägen genom Upplands-Väsby kommuns hemsida

28

4.2 Kommunernas olika sätt att sköta kundtjänst

I varje kommun kan en invånare kontakta kundtjänst rörande frågor kring eller be-ställning av avfallstjänster. Kundtjänsten är antingen i kommunens egna regi eller såsköts den av en upphandlad entreprenör. Kontakten kan för alla kommuner ske viatelefon eller mejl. Vissa kommuner har även beställningsformulär för några av av-fallstjänsterna. Efter att kundtjänst tagit emot en beställning, oavsett kontaktkanal,förs den manuellt in i det enskilda kundsystemet. De olika kundtjänsterna användertill viss del olika kundsystem, med olika nivåer av skräddarsydda lösningar. Kort omdessa kundsystem går att läsa i kapitel 2.2, Existerande underlag.

Figur 7: Förenklad översikt över vilka steg en generell beställning av avfallstjänst genomgår

Figur 7 visar vilka och hur olika aktörer är delaktiga vid en beställning av enavfallstjänst. Observera att en beställning inte nödvändigtvis sker via en kommunshemsida.

Problemet handlar om hur besökaren utför en beställning och hur den skickas frånportalen till berörd kundtjänst. Det vanligaste sättet för en användare att fylla iinformation är genom formulär. Ett ifyllt formulär bör innehålla all nödvändig in-formation för att kundtjänst ska kunna skapa en arbetsorder i kundsystemet. Dettakommer hädanefter att kallas för standardiserade formulär. Följande underkapitelberör olika lösningsförslag gällande hur ett ifyllt formulär kan hanteras.

4.2.1 Lösningsförslag - Skicka data direkt till kundsystemet

Ett förslag är att använda kundsystemen direkt. Det betyder alltså att ett ifylltformulär skickas via Internet, till exempel via ett API, för att spara dess data ikundsystemet automatiskt. Förslagets för- och nackdelar kan summeras enligt föl-jande:

+ Kan avlasta arbetet för avfallshandläggare

+ Ökad möjlighet att ge kunden skräddarsydd återkoppling baserat på beställdtjänst

– En utvecklingsprocess per kundsystem som används

4.2.2 Lösningsförlag - Skicka data via mejl till kundtjänst

Eftersom handläggare på kundtjänst manuellt för in beställningar i kundsystemet,kan standardiserade beställningsformulär användas som sedan skickas som mejl tillberörd kundtjänst. Förslagets för- och nackdelar kan summeras enligt följande:

29

+ Kan underlätta för avfallshandläggare i och med att de inkomna beställning-arna får enhetlig struktur

+ Valen av vilken entreprenör som anlitats eller vilket kundsystem som användsblir irrelevanta

– Svårt att ge kund personlig återkoppling kopplat till beställd tjänst

4.2.3 Implementerad lösning

Prototypen innehåller ett förslag på hur ett formulär kan struktureras. Inget avlösningsförslagen har implementerats. Att skicka formulärens data som ett mejl tillkundtjänst är i dagsläget kompatibelt med bakomliggande system och arbetssätt.Denna lösning är i den närmaste framtiden den som rekommenderas av författarna.

4.3 Enhetlig presentation av taxor

Varje kommun har sina egna avfallstaxor10, som styr priset för de avfallstjänster somerbjuds i respektive kommun[27]. Den problematik som uppstår är tvådelad. Delsligger den i att kommunerna uppdaterar och ändrar sina taxor ungefär vart annatår. Taxorna skrivs som ett PDF-dokument och låter sig alltså inte på ett enkeltsätt individuellt läsas in för att presenteras i en extern applikation, vilket leder tillförsvårat underhållningsarbete, alltså att hålla informationen i den gemensammaportalen aktuell. Det andra problemet handlar om att varje kommun har sina egnainterna motiveringar för hur taxorna styrs, det finns alltså inget sätt att på ett enkeltoch enhetligt sätt presentera taxorna för de olika tjänsterna i olika kommuner.

4.3.1 Lösningsförslag - Skapa en databas med taxor

Ett förslag är att samla alla kommuners taxor i en databas för att på så sätt enkeltkunna hämta dessa från portalen. Förslagets för- och nackdelar kan summeras enligtföljande:

+ Enkelt att presentera tjänstspecifika taxor i portalen

– Tidskrävande att underhålla databasen, då taxorna ändras

– Kommuner mäter avfall på olika sätt (t.ex. vikt eller volym).

– Det finns en stor skillnad i kommunernas utformning av taxorna

4.3.2 Lösningsförslag - Länka till avfallstaxor

Ett förslag är att, för varje kommun i den gemensamma portalen, införa en länk tillrespektive avfallstaxa. Förslagets för- och nackdelar kan summeras enligt följande:

+ Säkrat för framtida förändring i taxorna

– Svårigheten att presentera taxorna i portalen10En taxa är en avgift för någon tjänst

30


Den lösning som implementeras är den med att i portalen länka till respektive kom-muns avfallstaxa. Det underhållsarbete som då uppkommer består enbart i att hållalänkarna uppdaterade.

I dagsläget skulle en lösning med en databas med taxorna kräva stort underhålls-arbete då taxorna förändras. Detta beror till stor del på att taxorna styrs på olikasätt i olika kommuner. Förslaget skulle bli aktuellt i framtiden om kommunernabestämmer ett enhetligt sätt att styra taxorna.

4.4 Att leverera relevant miljöåterkoppling

Kommunerna har uttryckt ett önskemål om att användaren ska få en notifikation,innehållande en beskrivning av miljönyttan som kundens beställning har lett till,när tjänsten är utförd.

4.4.1 Lösningsförslag - Skicka notifikation efter slutförd tjänst

Ett lösningsförslag är att informera kunden om miljönyttan som beställningen bidrarmed, genom att skicka ut en notifikation. Förslagets för- och nackdelar kan summerasenligt följande:+ Kunden kan på ett effektivt sätt få uppmuntrande personlig återkoppling som

kan höja miljöengagemanget

– Återkopplingen behöver underhållas för att vara aktuell

4.4.2 Lösningsförslag - Presentera miljönytta till kunden via portalen

En lösning är att ge kunden återkoppling direkt via portalen efter genomförd be-ställning. Denna återkoppling består av förbestämd information. Denna informationkan exempelvis ha formatet:

Visste du att för varje kg Y som återvinns, kan du driva en brödrost i xtimmar?

Förslagets för- och nackdelar kan summeras enligt följande:+ Allmänbildande

– Återkopplingen blir inte personlig

– Återkopplingen behöver underhållas för att vara aktuell


Den lösning som implementeras i prototypen är den med att presentera miljönyttadirekt i portalen.

Att kunna skicka personliga notifikationer till kund efter slutförd tjänst skulle krä-va att portalen har tillgång till kunddata. Detta lösningsförslag skulle bli aktuelltom portalen vidareutvecklas med en inloggningsfunktion. Detta skulle fungera bratillsammans med lösningsförslaget att skicka data direkt till kundsystemet, om möj-ligheten även finns att skicka data från kundsystemet tillbaka till portalen.

31

4.5 Övriga önskemål

Följande områden, som anses mindre kritiska än ovanstående, utforskades av förfat-tarna efter att olika önskemål dykt upp under förundersökningen.

4.5.1 Integrerad sorteringsguide

En sorteringsguide kan användas för att hjälpa en besökare att sortera sitt avfallrätt. Det kan till exempel ske genom att presentera en lista eller tabell som inne-håller mappningar mellan avfallsprodukter och avfallsfraktioner11. Det kan även skegenom att besökaren använder en sökfunktion för att skriva in det som skall slängasoch systemet visar information om vilken fraktion som avfallet sorteras som. SÖ-RABs sorteringsguide Sören och Suez mobila version av Källsortera12 använder bådametoderna, medan webbversionen av Källsortera endast erbjuder sökfunktionen.

En nackdel med att presentera en hel lista eller tabell är att det tar upp myc-ket plats på skärmen och kan distrahera besökaren från portalens andra funktioner.En fördel är att besökaren lättare kan skaffa en överblick över tillgängliga söktermer.


En sorteringsguide har implementerats, där användaren kan söka efter en avfallspro-dukt och få fram vilken avfallskategori den tillhör.

11Till exempel farligt avfall, grovavfall, matavfall12Se kapitel 2.2 för mer information om sorteringsguiderna

32

5 Design och implementeringKapitlet beskriver designen och implementeringen av prototypen. Först görs ettval av applikationstyp, sedan visas hur användargränssnittet designas och slutligenpresenteras resultatet av implementeringen.

5.1 Kravspecifikation

Utifrån förundersökningen togs en kravspecifikation fram. Kravspecifikationen vartill för att fånga de krav på prototypen som SÖRAB har. De viktigaste delarna ikravspecifikationen är de funktionella och icke-funktionella kraven. Där specifierast.ex. kravet att prototypen ska vara mobilanpassad, vilket påverkar applikationsstu-dien. Kravspecifikationen kan läsas i sin helhet i bilaga B.

5.2 Val av applikationstyp

Kapitlet består av en jämförelse mellan applikationstyper och analys av på vilket sättden gemensamma portalen bör implementeras. Underlaget som används för analy-sen är dialog med uppdragsgivaren, forskningspublikationer och diverse artiklar frånindustrin. En sammanfattning av de fynd som gjorts har tidigare presenterats i ka-pitel 2.5.

Det finns flera olika, mer eller mindre likartade, teknologier för att konstruera entjänst som uppfyller uppdragsgivarens syfte. Uppdragsgivaren har uttryckt önskanom att tjänsten bör vara responsiv och interaktiv samt vara tillgänglig via mobilte-lefon. Denna önskan tas till hänsyn genom att eliminera irrelevanta teknologier, tillexempel renodlade skrivbordsapplikationer.

Eftersom utveckling och stöd för hybrida applikationer fortfarande är i ett tidigt sta-die, kommer följande resonemang endast att ta hänsyn till rena nativa applikationeroch responsiva webbapplikationer. Med nativ mobilapplikation menas applikatio-ner för moderna smarta enheter för de mobila operativsystemen iOS och Android.Med responsiv webbapplikation menas att den använder responsiv webbdesign ochdärmed är anpassad både för stora och små skärmar.

5.2.1 Jämförelser

Applikationsstudiens relevanta fynd kan sammanställas enligt tabell 1, där nativamobilapplikationer och responsiva webbapplikationer jämförs. För- och nackdelarnaär vägda ur examensarbetets synpunkt. Raden tillgänglighet betyder, exempelvis,inte att nativa applikationer har dålig tillgänglighet, utan att den jämfört med re-sponsiva webbapplikationer inte är tillgänglig för lika många användare. Eftersomatt varje mobilt operativsystem kräver en separat utvecklingsprocess med olika pro-grammeringsspråk, ses det som en nackdel jämfört med den enda utvecklingspro-cessen som krävs för att utveckla en responsiv webbapplikation. Det kan resonerasatt även responsiva webbapplikationer kräver flera programmeringsspråk och tekno-logier, som HTML, CSS och JavaScript, men fokus ligger här på antal utvecklings-processer. Den tidsåtgång som krävs för de olika applikationstyperna är kopplad tillantal utvecklingsprocesser. I ett större projekt med annan budget och tidsram, kan

33

Nativ mobilapplikation Responsiv webbapplikationAntal utvecklingsprocesser FördelTidsåtgång vid utveckling Fördel

Hårdvarutillgång FördelUnderhåll Fördel

Tillgänglighet Fördel

Tabell 1: En överblick över för- och nackdelar för nativa mobilapplikationer och responsiva web-bapplikationer, ur examensarbetets synpunkt.

det vara värt att utveckla nativa mobilapplikationer till samtliga operativsystem.På grund av examensarbetets begränsade tidsram, anses därför den mindre tidsåt-gången för responsiva webbapplikationer en fördel.

Den gemensamma portalen behöver inte särskilt hårdvarustöd på mobila enheter,till exempel direkt tillgång till kamera eller andra hårdvarufunktioner. Därför spelarhårdvarutillgången mindre roll, men om applikationen varit i behov av hårdvaru-funktioner skulle fördelen gå till nativa mobilapplikationer, enligt tabell 1.

Även underhållsarbetet för de olika applikationstyperna är kopplat till antal utveck-lingsprocesser. För att hålla mobilapplikationer för separata operativsystem uppda-terade, krävs separat underhållsarbete. Att underhålla en responsiv webbapplikationkräver därmed något mindre arbete, vilket ur examensarbetets synpunkt ses som enfördel. Detta för att underlätta både fortsatt utveckling och framtida underhåll vidöverlämning av projektet.

Så länge en användare har en modern webbläsare installerad på sin enhet, harde tillgång till responsiva webbapplikationer. En nativ mobilapplikation fungerarendast för användare som använder rätt mobilt operativsystem, enligt tidigare dis-kussion. Ur examensarbetets synpunkt anses det fördelaktigt att på kort tid nå uttill så många användare som möjligt. Alltså ses den responsiva webbapplikationenha fördel i denna jämförelse.

5.2.2 Användning i projektet

Tabell 1, tillsammans med tidigare redovisning av skillnaderna, visar att den respon-siva webbapplikationen troligtvis är den mest passande applikationstypen. De mestövertygande aspekterna är den högre tillgängligheten tillsammans med den singulä-ra och relativt korta utvecklingsprocessen. För att hålla högt fokus på tillgänglighetär det inte aktuellt i detta examensarbete att utveckla för endast ett av de mobilaoperativsystemet. Med god användning av responsiv design vid utveckling av enwebbapplikation, kan det grafiska gränssnittet utformas på ett sätt som direkt på-minner om en nativ mobilapplikation. Vidare bör portalen ha låga underhållskrav.Med detta menas att minimera det underhåll som krävs för portalens kontinuerligadrift, som bakomliggande datastrukturer och dess innehåll.

Innehållet som erbjuds i portalen är statiskt, som till exempel information om deolika avfallstjänsterna. Det betyder att innehållet inte påverkas av användare, utanatt endast formella uppdateringar av källkod förändrar sidans innehåll.

34

Med de teoretiska beskrivningarna av de olika applikationstyperna i kapitel 2.5,de krav och önskemål som ställts upp under förundersökningen13 och jämförelseni detta kapitel som underlag, fattas beslutet att implementera den gemensammaportalen som en responsiv webbapplikation med statiskt innehåll.

5.3 Design av användargränssnitt

Efter beslutet i det föregående kapitlet, påbörjas ett arbete med att utforma ettgränssnitt för den responsiva webbapplikationen.

Detta kapitel innehåller en beskrivning av hur sidmallar använts för att ta framen första skiss av portalen. Beskrivningar av iterationernas för- och nackdelar ochhur vanliga användarvänlighets- och designprinciper har applicerats ingår i kapitlet.Principerna är sedan tidigare beskrivna i kapitel 2.6.

I examensarbetet har inga användartester genomförts, utan sidmallar har använtsför att i ett tidigt skede kunna ställa upp en grund för hur portalen kan se utoch användas. Sidmallarna gjordes i programmet Balsamiq14, som tillåter en gratistestperiod på 30 dagar.

5.3.1 Skisser av gränssnitt

Eftersom att portalen bör vara mobilanpassad, togs både en fullskärmsversion ochen motsvarande mobilversion fram. Figur 8 presenterar samtliga iterationer av sid-mallen.

Den första iterationen visade sig komplicerad att på ett logiskt sätt översätta till enmobilversion, utan att göra en helt separat design. Sidan innehåller för stor mängdinformation, även för en fullskärmsapplikation. Den stora informationsmängden bry-ter mot principen att begränsa komplexitet i design, vilken säger att överflödig infor-mation inte får konkurrera med relevant information. På grund av problemen meddesignen, gick arbetet vidare till iteration 2, för att från början ha en design somenklare kan anpassas till mindre skärmstorlekar.

Iteration 2 skapades med en mobilanpassad version i åtanke, delvis genom att mäng-den information förminskades per visad sida. I denna iteration navigerar användarengenom ett antal separata steg för att genomföra en beställning. Aktuellt steg somanvändaren befinner sig på visas och klickbara listor förtydligas. Detta för att följaprinciperna om attminimera användarens minnesbelastning och tydliggöra systemetsstatus. Principen som säger förhindra fel följs genom att minimera antalet knappar,klick och val som kan göras per sida. Det största problemet med iterationen är attden mobilanpassade versionen fortfarande inte direkt motsvarar den för större skär-mar.

Gränssnittet i iteration 3 liknar traditionella webbplatser med en navigeringsme-13Se bilaga B14www.balsamiq.com/products/mockups/

35

ny högst upp på sidan. Menyn visar var på sidan användaren befinner sig, inklusiveen länk för att få hjälp. När en beställning påbörjas visas vilket steg använda-ren befinner sig på. I denna iteration inkluderades även kontroll över navigeringen,via knapparna som låter användaren gå tillbaka eller avbryta. Det mobilanpassa-de gränssnittet i iteration 3, återanvänder så mycket som möjligt från gränssnittetför större skärmar. Navigeringsmenyn döljs bakom "hamburger"-menyn i högra hör-net; ett vanligt designval för responsiv design. Efter att iteration 3 var färdigställdbeslutades det att implementeringen var redo att påbörjas.

36

Figur

8:Sidm

allarnas

iterationerförbättradedetgrafi

skagrän

ssnittetsdesign.

37

5.4 En responsiv webbprototyp

Kapitlet presenterar resultatet av implementeringen. Kapitlet visar prototypens ak-tuella design, för olika skärmstorlekar. Hur prototypen löser de problemområden sompresenterats i kapitel 4, redovisas tillsammans med de användarvänlighetsprincipersom presenterats i kapitel 2.6.

5.4.1 Översikt av design

Figur 9 visar en översikt av prototypens design. Menyn, överst i figuren, visar varanvändaren befinner sig. Designen utnyttjar breda skärmar genom att placera deolika komponenterna bredvid varandra. Menyvalet Hjälp, längst till höger, är tillför att följa användarvänlighetsprincipen om att bistå med hjälp och dokumentation.Figur 10a visar hur designen har anpassats till mindre skärmstorlekar. För de mind-re skärmstorlekarna placeras komponenterna ovanpå varandra. Figur 10b visar hurmenyn ser ut på mindre skärmar. Menyn öppnas, och stängs, genom att klicka påden gröna, fyrkantiga knappen i det övre högra hörnet.

Figur 9: En översikt av gränssnittet för stora skärmar

(a) (b)

Figur 10: En översikt över det grafiska gränssnittet för mindre skärmstorlekar.

38

5.4.2 Lösning: Användarvänlighet

För att lösa problemområde 4.1, har olika användarvänlighetsprinciper följts. Prin-ciperna är tidigare presenterade i kapitel 2.6. Figur 11 visar hur gränssnittet ser utnär användaren är mitt i en beställning. Överst i figuren visas vilket steg använ-daren befinner sig på, för att tydliggöra systemets status. Namnet på den kommunsom valdes i det tidigare steget, presenteras för att minimera användarens minnes-belastning. Rutnätet som visar tillgängliga tjänster är designat för att förhindra feloch minimera komplex design. Principerna uppfylls genom att det enda val som an-vändaren kan göra, för den ett steg närmare målet. Knapparna längst ner i figurenanvänds för att ge användaren kontroll över navigering. Det betyder att användarenska kunna gå ett steg tillbaka eller avbryta en operation, utan att använda webblä-sarens navigeringsverktyg.

Användarvänlighetsprinciperna har följts kontinuerligt under implementeringen. Föl-jande kapitel presenterar resterande lösningar av problemområdena, tillsammansmed hur principerna har följts.

Figur 11: Prototypen följder etablerade principer för ökad användarvänlighet.

39

5.4.3 Lösning: Beställning

För att lösa problemområde 4.2, används formulär i portalen. Efter att en tjänsthar valts, presenteras användaren med ett formulär som fylls i för att genomföraen beställning. I portalens aktuella tillstånd är formuläret inte kopplat till någonsärskild kommun eller tjänst.

Beställningssidan följer ytterligare några användarvänlighetsprinciper, som kan sesi figur 12. Principen använd språk som användaren är van vid följs genom att inteintroducera några nya termer eller sätt att presentera formulär. Användandet av enasterisk för att signifiera obligatoriska fält följer samma princip. Portalen förhindrarfel vid ifyllning av formulär genom att inaktivera skicka-knappen. Knappen aktive-ras först när samtliga fält i formuläret är korrekt ifyllda.

Figur 13 visar hur ett felmeddelande presenteras för användaren. Felmeddelandenpresenteras när ett fält är felaktigt ifyllt, för att följa användarvänlighetsprincipensom säger använd beskrivande felmeddelanden. Principen är till för att låta använ-daren själv diagnostisera och åtgärda fel som uppstår.

Figur 12: En användare fyller i formulär för att genomföra beställningar.

Figur 13: Felmeddelanden visas när ett fält är felaktigt ifyllt.

40

5.4.4 Lösning: Miljöåterkoppling

Figur 14 visar ett exempel på lösning för problemområde 4.4, som handlar om hurportalen kan presentera relevant miljöåterkoppling för användaren. Miljöåterkopp-lingen i prototypen är inte kopplad till den beställda tjänsten, utan används som ettexempel på hur lösningen kan implementeras. Användaren kan välja att direkt göraen ny beställning, för att återigen uppfylla principen om att ge användare kontroll.

Figur 14: Prototypen innehåller ett exempel på hur miljöåterkoppling kan ges vid genomförd be-ställning.

5.4.5 Lösning: Avfallstaxor

Figur 15 visar hur portalen länkar vidare till respektive kommuns avfallstaxa, enligtlösningsförslag 4.3.2. PDF-ikonen bredvid kommunnamnen används för att visa attdokumenten öppnas eller laddas ned som PDF-filer.

Figur 15: Prototypen visar en lista med länkar till varje kommuns avfallstaxa.

41

5.4.6 Arkitekturdokument

Ett arkitekturdokument skrevs parallellt med implementeringen av prototypen. Detär ett dokument som kan vara till hjälp vid framtida utveckling. Dokumentet be-skriver vilken funktionalitet som implementerats och vilka verktyg som använts.Applikationens olika lager, bakomliggande kodstruktur och kodexempel ingår i do-kumentet. Arkitekturdokumentet kan ses i sin helhet i bilaga C.

42

6 DiskussionI detta kapitel utvärderas projektarbetets metodik och resultat. Utvärderingen görsmed termerna validitet och reliabilitet i åtanke. Slutligen diskuteras framtida arbeteoch det dras generella slutsatser kring examensarbetet som helhet.

Validitet

Validiteten av en forskningsmetod handlar om huruvuda den faktiskt kan använ-das för att besvara frågeställningen, enligt en rapport av Golafshani [28]. Att mätavaliditeten av kvalitativ forskning är i sin natur problematisk. Golafshani menaratt det istället bör handla om att värdera trovärdigheten i forskningens resultat.Denna trovärdighet kan ses från olika perspektiv [29]. Den kan ses från ett interntperspektiv, vilket betyder att forskningsarbetets utövare gör en subjektiv värderingav resultatens trovärdighet. Trovärdigheten kan även ses ur ett externt perspektiv,vilket behandlar hur väl resultaten kan generaliseras och överföras till andra sam-manhang.

Reliabilitet

Generellt innebär en forskningsmetods reliabilitet ett mått på hur pass reproducer-bart dess resultat är, enligt Golafshani [28]. Likt validitet är även detta ett måttsom är problematiskt att applicera på kvalitativa arbeten. Istället kan termen till-förlitlighet användas, med ett fokus på den föränderliga naturen av det kvalitativaunderlaget [29].

6.1 Är frågeställningen besvarad?

I kapitel 1.2 formulerades projektets huvudsakliga frågeställning:

Hur kan ett IT-system konstrueras som på ett likformigt sätt, för flerakommuner, informerar om och tillhandahåller avfalltjänster?

Frågan delades upp i sex delfrågor. Detta kapitel diskuterar hur väl delfrågorna ärbesvarade.

Kan systemet konstrueras?

Under förundersökningen hittades inget som tydde på att en utveckling av systemetskulle vara omöjlig, vilket tolkades som ett bejakande svar till frågan. Den internavaliditeten i detta ligger i att författarna lyckades konstruera en systemprototyp.Den externa validiteten är emellertid svår att bedöma, då andra förutsättningareventuellt skulle kunna göra en systemkonstruktion omöjlig. Reliabiliteten bedömsvara hög, då erfarna utvecklare med stor sannolikhet hade kunnat konstruera ettsystem, givet samma förutsättningar.

Detta svar i sig är inte uppseendeväckande. Nästa delfråga går djupare och gerett mer intressant svar.

43

På vilket/vilka olika sätt kan uppdragsgivarens mål uppfyllas?

Denna fråga besvaras med lösningsförslagen som beskrivs i kapitel 4. Diskussionenkan sammanfattas med att uppdragsgivarens mål skulle kunna uppfyllas på andraoch bättre sätt, givet att kommunerna ändrar sitt nuvarande arbetssätt gällandebåde styrning av taxor och tillgång till kundsystem. En stor förbättring skulle iframtiden vara möjlig med tillgång till ett API för kundsystemen. Med detta i åtankeutvecklades systemet så att framtida utveckling skulle vara så smidig som möjligt.

Till vilken plattform passar systemet bäst?

Denna fråga besvarades genom att utesluta irrelevanta plattformar och jämföra deåterstående. Jämförelsen behandlade då nativa mobilapplikationer och mobilanpas-sade hemsidor. Den jämförande diskussionen återfinns i kapitel 5.2.1, där slutsatsenvar att mobilanpassade hemsidor var den plattform som portalen skulle implemen-teras för. En begränsande faktor i examensarbetet har varit tiden. Med mer tideller/och resurser, hade prototyper för flera applikationstyper kunna tagits fram.Dessa hade då kunnat testas för att göra en mer objektiv bedömning av vilken ap-plikationstyp som passar bäst för portalen. Det finns inget hinder för att en nativmobilapplikation, i framtiden, också utvecklas, men det faller utanför tidsramen fördetta projekt att utveckla till fler plattformar. På grund av att tidsbristen var enavgörande faktor, anses reliabiliteten vara låg.

Utvecklingen går fort framåt gällande mobila webbapplikationer och nativa mo-bilapplikationer, den applikationsstudie som i rapporten utförs kan mycket väl varaföråldrad om bara ett par år. Detta har författarna själva upplevt från den litteratursom är skriven för några år sedan. Både den interna och externa validiteten ansesdärför vara låg.

Med vilken/vilka teknologier bör systemet utvecklas?

Det finns många olika ramverk för att utveckla en hemsida och vilket som skulleanvändas var svaret som söktes för denna delfråga. Att välja ramverk visade sigvara en komplicerad uppgift. Slutligen valdes Angular, men portalen hade kunnatimplementerats lika väl med något annat ramverk, som t.ex AngularJS, Ember.js,Django, React, Spring och så vidare. Valet var högst subjektivt eftersom författarnaville lära sig JavaScript, men föredrar programmeringsspråk med statisk typning.Eftersom Angular använder sig av TypeScript, som i grunden är JavaScript fasttillåter ett statiskt typsystem, föll det sig naturligt att välja detta ramverk. Dettasubjektiva val leder till låg reliabilitet och låg validitet.

Vilken typ av arkitektur bör systemet ha?

Det övergripande svaret är att systemet bör utvecklas objektorienterat för att fåinkapsling, hög sammanhållning och låg koppling i koden. Detta underlättar förframtida utvecklare som vill ändra eller lägga till ny funktionalitet i portalen. Arki-tekturen beskrivs i sin helhet i form av ett arkitekturdokument som finns som bilagaC. Objektorienterad design har genomsyrat många programmeringskurser inom för-fattarnas utbildning och ansågs därför vara ett naturligt designval. Andra utvecklare

44

med annan bakgrund och andra kunskaper, skulle säkerligen utveckla efter en annanarkitektur. Därför anses reliabiliteten vara låg.

6.2 Framtida arbete

Den sista delfrågan var: Vilket arbetssätt bör systemets fortsatta utveckling följa?Under utvecklingen har hänsyn tagits till framtida utveckling. Programmeringenföljer moderna designmönster och är väldokumenterad. Detta borde leda till atttillägg av ny eller förändring av nuvarande funktionalitet kan ske utan stora hinder.

I kapitel 4 diskuteras hur alternativa lösningsförslag kan tillämpas i framtiden. Sam-manfattningsvis skulle de alternativa lösningsförslagen vara aktuella, om kommuner-na har tillgång till API:er för kundsystemen och om de bestämmer ett enhetligt sättatt styra avfallstaxorna. Med direkt tillgång till kundsystemen kan också miljöåter-kopplingen bli mer personlig i och med förmågan att skicka tillbaka någon form avnotifikation, anpassad efter beställd tjänst, när beställningen är slutförd.

6.3 Slutsatser

Det finns inga tydliga tecken på att metodiken som använts är optimal. Metodikenhar däremot varit lätt att följa och det iterativa arbetssättet var smidigt. Andra,liknande implementeringsprojekt kan, med stor sannolikhet, komma fram till andralösningar än i denna rapport. Med mer tid tillgodo skulle en mer komplett prototyp,med mer implementerad funktionalitet, kunna tas fram och även testas på riktigaanvändare. En stor anledning till projektets tidsbrist uppkom i samband med desig-nen av prototypen. Designen visade sig ta upp en större del av arbetet än tidigaretänkt. I metodiken tar författarna inte hänsyn till designen av gränssnittet, vilketvar ett lärorikt misstag.

Författarnas förhoppning är att denna rapport kan vara till nytta för framtida im-plementeringsprojekt, genom att ge insikt i principer för användarvänlighet samtför- och nackdelar för olika applikationstyper.

45

Referenser[1] SÖRAB, Avfallsplanen. Tillgänglig Online (2017-03-30):

http://avfallsplan.sorab.se/se/Avfallsplanen.

[2] SÖRAB, Så hanteras dina sopor. Tillgänglig Online (2017-04-19):http://www.sorab.se/hushall/sa-funkar-det/.

[3] Sören. Tillgänglig Online (2017-04-19): http://www.soren.nu/.

[4] Suez - källsortera. Tillgänglig Online (2017-04-19):http://www.suez.se/sv-SE/Guider–Hjalp/Kallsortera/.

[5] Niclas Andersson and Anders Ekholm. Vetenskaplighet - Utvärdering av treimplementeringsprojekt inom IT Bygg & Fastighet 2002. 2002.Tillgänglig Online (2017-03-30):http://www.caad.lth.se/fileadmin/projekteringsmetodik/research/Other_projects/utvarderingver1.pdf.

[6] William M.K. Trochim. Deduction & Induction. Tillgänglig online(2017-05-10): http://www.socialresearchmethods.net/kb/dedind.php.

[7] William Jobe. Native apps vs. mobile web apps. International Journal ofInteractive Mobile Technologies, 7(4):29–32, 2013.

[8] Jim Conallen. Modeling Web Application Architectures with UML. Commun.ACM, 42(10):63–70, October 1999. Tillgänglig online(2017-05-12):http://doi.acm.org/10.1145/317665.317677.

[9] Jakob Nielsen. 10 Usability Heuristics for User Interface Design, January 1,1995. Tillgänglig online (2017-05-12):https://www.nngroup.com/articles/ten-usability-heuristics/.

[10] Static Web page Definition from PC Magazine Encyclopedia. Tillgängligonline (2017-05-09):http://www.pcmag.com/encyclopedia/term/52045/static-web-page.

[11] Micah McDunnigan. The Difference Between Dynamic & Static Web Pages |Chron.com. Tillgänglig online (2017-05-09):http://smallbusiness.chron.com/difference-between-dynamic-static-pages-69951.html.

[12] Based on work by Jon Lane. How does the Internet work - W3C Wiki.Tillgänglig online (2017-05-09):https://www.w3.org/wiki/How_does_the_Internet_work#Static_vs._Dynamic_Web_Sites.

[13] Dynamic Web page Definition from PC Magazine Encyclopedia. Tillgängligonline (2017-05-09):http://www.pcmag.com/encyclopedia/term/42199/dynamic-web-page.

[14] Jay Bryant and Mike Jones. Responsive Web Design. Apress, Berkeley, CA,2012.

[15] Michael S Mikowski and Josh C Powell. Single page web applications. B andW, 2013.

47

http://www.caad.lth.se/fileadmin/projekteringsmetodik/research/Other_projects/utvarderingver1.pdf

http://www.caad.lth.se/fileadmin/projekteringsmetodik/research/Other_projects/utvarderingver1.pdf

http://www.socialresearchmethods.net/kb/dedind.php

http://doi.acm.org/10.1145/317665.317677

https://www.nngroup.com/articles/ten-usability-heuristics/

http://www.pcmag.com/encyclopedia/term/52045/static-web-page

http://smallbusiness.chron.com/difference-between-dynamic-static-pages-69951.html

http://smallbusiness.chron.com/difference-between-dynamic-static-pages-69951.html

https://www.w3.org/wiki/How_does_the_Internet_work#Static_vs._Dynamic_Web_Sites

https://www.w3.org/wiki/How_does_the_Internet_work#Static_vs._Dynamic_Web_Sites

http://www.pcmag.com/encyclopedia/term/42199/dynamic-web-page

[16] Mark Rickmeier. Mobile App vs. Responsive Design: Ask These 10 QuestionsFirst | Table XI. Tillgänglig online (2017-05-08):http://www.tablexi.com/mobile/mobile-app-vs-responsive-design-ask-these-10-questions-first/.

[17] IDC: Smartphone OS Market Share 2016, 2015. Tillgänglig online(2017-05-09): http://www.idc.com/promo/smartphone-market-share/os.

[18] Mobile operating system market share in Sweden 2016 | StatCounter GlobalStats. Tillgänglig online (2017-05-09):http://gs.statcounter.com/os-market-share/mobile/sweden/2016.

[19] Android Developers. What is android, 2011.

[20] Swift apple developer. Apples officiella hemsida, tillgänglig online(2017-05-11): https://developer.apple.com/swift/.

[21] Robbie Abed. Hybrid vs Native Mobile Apps - The Answer is Clear,September 30, 2016. Tillgänglig online (2017-05-15):https://ymedialabs.com/hybrid-vs-native-mobile-apps-the-answer-is-clear/.

[22] Krishnan R Menon. Hybrid vs Native Mobile App Development. Decide in 5minutes!, Februari 15, 2015. Tillgänglig online (2017-05-15):https://julyrapid.com/hybrid-vs-native-mobile-app-decide-5-minutes/.

[23] Wulf Andreas. Wireframes: A Great Way to Start Development Projects,Augusti 7, 2012. Tillgänglig online (2017-05-22):https://www.infoq.com/articles/wireframes-start-development-projects.

[24] Nielsen Jakob. Paper Prototyping: Getting User Data Before You Code, April14, 2003. Tillgänglig online(2017-05-22):https://www.nngroup.com/articles/paper-prototyping/.

[25] Differences Between Qualitative and Quantitative Research Methods | OakRidge Institute for Science and Education. Tillgänglig online(2017-05-10):https://www.orau.gov/cdcynergy/soc2web/Content/phase05/phase05_step03_deeper_qualitative_and_quantitative.htm.

[26] Ian Sommerville. Software engineering. Pearson, 9th edition, 2010.

[27] Taxor och avgifter | Avfall Sverige.Tillgänglig Online(2017-05-02):http://www.avfallsverige.se/avfallshantering/ekonomi-och-styrmedel/taxor-och-avgifter/.

[28] Nahid Golafshani. Understanding reliability and validity in qualitativeresearch. The qualitative report, 8(4):597–606, 2003.

[29] William M.K. Trochim. Qualitative Validity. Tillgänglig online (2017-05-15):http://www.socialresearchmethods.net/kb/qualval.php.

48

http://www.tablexi.com/mobile/mobile-app-vs-responsive-design-ask-these-10-questions-first/

http://www.tablexi.com/mobile/mobile-app-vs-responsive-design-ask-these-10-questions-first/

http://www.idc.com/promo/smartphone-market-share/os

http://gs.statcounter.com/os-market-share/mobile/sweden/2016

https://developer.apple.com/swift/

https://ymedialabs.com/hybrid-vs-native-mobile-apps-the-answer-is-clear/

https://ymedialabs.com/hybrid-vs-native-mobile-apps-the-answer-is-clear/

https://julyrapid.com/hybrid-vs-native-mobile-app-decide-5-minutes/

https://julyrapid.com/hybrid-vs-native-mobile-app-decide-5-minutes/

https://www.infoq.com/articles/wireframes-start-development-projects

https://www.infoq.com/articles/wireframes-start-development-projects

https://www.nngroup.com/articles/paper-prototyping/

https://www.orau.gov/cdcynergy/soc2web/Content/phase05/phase05_step03_deeper_qualitative_and_quantitative.htm

https://www.orau.gov/cdcynergy/soc2web/Content/phase05/phase05_step03_deeper_qualitative_and_quantitative.htm

http://www.socialresearchmethods.net/kb/qualval.php

Bilaga A Uppdragsbeskrivning

49

Ex‐jobbsförslag – Utredning och utveckling av app för beställning och

miljöåterkoppling

Bedömd omfattning: 30 högskolepoäng För ansökan se www.sorab.se.

Bakgrund

SÖRAB tillsammans med sina nio ägarkommuner vill göra det lättare för slutkund (abonnenten) att

beställa de tjänster som finns inom kommunens avfallsabonnemang. Det är viktigt att detta kan

utföras på ett användarvänligt och enkelt sätt samt också ge kunden återkoppling kring miljönytta

med den valda orden/tjänsten.

Frågeställning

Studien bör omfatta en inledande utredning vad som krävs för att bakomliggande affärssystem och

liknande system ska vara kompatibla med en gemensam webbportal/app. Det bör också ingå en

studie av vilket system/applikation som är det bästa valet för denna typ av tjänst. En del av

metodiken kommer att omfatta intervjua med avfallshandläggare inom kommunerna samt ta del av

bakgrundsfakta från samtliga kommuner. I ett första skede handlar det om att utreda ifall det är

möjligt att skapa appen/webbportalen och i ett andra skede handlar det om att ta fram en struktur

och grund för appen/webbportalen.

Bilaga B Kravspecifikation

53

Kravspecifikation för SÖRABs gemensamma portal

Innehåll Innehåll 1

1 Bakgrund 1 1.1 Projektets avgränsning 1

2 Huvudsakliga krav 2 2.1 Generella krav 2 2.2 Informationssökning 2 2.3 Beställning av avfallstjänster 2 2.4 Återkoppling 2 2.5 Sociala medier 3

3 Övriga krav 3 3.1 Navigering 3 3.2 Kompatibilitet 3

3.2.1 Nuvarande arbetssätt 3 3.2.2 Webbläsare 3

3.3 Överlämning 4

1 Bakgrund SÖRAB tillsammans med sina ägarkommuner vill förenkla för sina kunder att hitta information om och utföra beställningar av de tjänster som erbjuds. Detta ska ske genom att alla kunder använder en gemensam portal, oavsett kommuntillhörighet. Det är viktigt att detta kan utföras på ett användarvänligt och enkelt sätt, samt ge kunden återkoppling kring miljönyttan från den valda tjänsten. Kommuner har uttryckt ett intresse för att utöka sin närvaro på sociala medier.

1.1 Projektets avgränsning Undersökning av och framtagande av en prototyp av beskrivet slag sker genom ett examensarbete på grundnivå, inom högskoleingenjörsprogrammet Datateknik, vid KTH i Kista. Examensarbetet genomförs under perioden 2017-03-20 till 2017-06-08.

Eric Amundsson 2017-05-09, Stockholm Alexander Lindfors

2 Huvudsakliga krav En besökare till portalen är främst en invånare i någon av kommunerna i SÖRAB-regionen. Portalens sökfunktion är även användbar för invånare utanför regionen. Portalen är åtkomlig via webbläsare på dator eller mobil enhet. Följande rubriker beskriver de krav som rör portalens rena funktionalitet.

2.1 Generella krav ● Besökare kan välja kommuntillhörighet ● Valet bör sparas på lämpligt sätt för framtida besök ● Där möjligt bör portalen följa World Wide Web Consortiums(W3C) riktlinjer för

tillgänglighet på webben ● Innehållet i portalen bör vara tillgängligt på flera språk, främst svenska och

engelska. ● Portalens formgivning ska vara anpassad för optimal användning via både

datorer och mobila enheter

2.2 Informationssökning

● Portalen har en sökfunktion för avfallsprodukter som: ○ Presenterar vilket sorts avfall(fraktion) produkten sorteras som ○ Bör kunna hjälpa besökaren att hitta till beställning av avfallstjänst

● Portalen visar enbart information relevant för vald kommun ● Portalen ger information om återvinningscentraler inklusive:

○ Plats ○ Öppettider

2.3 Beställning av avfallstjänster ● Portalen erbjuder standardiserade beställningsformulär som är kopplat till vald

kommun ● Ifyllt formulär bör valideras lokalt innan det skickas iväg, till exempel:

○ Obligatoriska fält får inte lämnas tomma ○ Giltiga kontaktuppgifter

2.4 Återkoppling ● Portalen bör presentera relevant miljöåterkoppling rörande beställd tjänst, till

exempel: ○ Vid beställning av hämtning av farligt avfall ges besökaren statistik

angående mängd sorterad eller osorterad farligt avfall i regionen

Sida 2 av 4


● Presentation av miljöåterkoppling / aktuell statistik kan om möjligt ske utan att besökaren gjort en beställning

2.5 Sociala medier ● Om möjligt kan portalen integrera konton från de berörda kommunernas

sociala medier, till exempel: ○ Hämta inlägg från Facebook eller Instagram

● Portalen kan använda Facebooks API för att hämta information från kommunernas sidor, till exempel:

○ Öppettider ○ Kontaktinformation ○ Kommande evenemang

3 Övriga krav Följande rubriker rör de krav som inte är direkt kopplade till portalens funktionalitet.

3.1 Navigering ● Funktioner i portalen som är användbara för samtliga besökare ska vara

tydligt tillgängliga, till exempel: ○ Sökfunktionen

● I den färdiga portalen ska antal klick för att hitta information om och beställning av avfallstjänster vara lägre än i dagsläget

○ I dagsläget är antal klick ungefär mellan 5 och 7 ● Varje klick som görs i portalen ska föra besökaren närmare målet, till

exempel: ○ Portalen visar tydligt var på sidan besökaren befinner sig, hur många

och vilka steg som kvarstår för att uppfylla målet.

3.2 Kompatibilitet Se nedanstående rubriker för de aspekter rörande kompatibilitet som portalen bör uppfylla.

3.2.1 Nuvarande arbetssätt ● Portalen ska vara kompatibel med kommunernas nuvarande arbetssätt och

bakgrundssystem

3.2.2 Webbläsare ● Portalen ska vara kompatibel att användas med följande moderna

webbläsare: ○ Firefox

Sida 3 av 4


○ Google Chrome ○ Safari ○ Microsoft Edge

3.3 Överlämning ● Efter examensarbetets slut överlämnas all kod och dokumentation i sin helhet

till uppdragsgivare SÖRAB ● Portalen och tillhörande resurser bör enkelt kunna modifieras av framtida

utvecklare

Sida 4 av 4

Bilaga C Arkitekturdokument

59

ArkitekturdokumentSÖRABS gemensamma portal

Eric Amundsson & Alexander Lindfors

10 juni 2017

Innehåll1 Verktyg 2

1.1 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 HTML5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Angular 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.6 PrimeNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.7 ReactiveFormsModule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.8 Font Awesome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.9 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Funktionalitet 3

3 Arkitektur & design 43.1 View: Komponentmallar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1.1 Mobilanpassning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2 Controller: Komponent-klasser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.3 Model: Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.4 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.5 Arkitekturöversikt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Validering 10

5 Installation 115.1 Angular CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.1.1 Nyttiga kommandon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

6 Referenser 12

1

1 VerktygDetta kapitel ger en introduktion till de verktyg som använts under utvecklingen.

1.1 JavaScriptJavaScript är känt för att vara programmeringsspråket för webben. Det är av den anledningendet används för webbportalen. JavaScript används indirekt via TypeScript, som kompileras tillJavaScript. JavaScript är otypat och dynamiskt.

1.2 TypeScriptAlla TypeScript-program är också JavaScript-program, men inte tvärtom. TypeScript tillåter sta-tisk typning. Det används eftersom att Angular 2+(se nedan) använder det.

1.3 HTML5HTML5, HyperText Markup Language, användes för den huvudsakliga strukturen på webbporta-len.

1.4 CSSCSS, Cascading Style Sheets, användes för att designa webbportalens gränssnitt. CSS3 MediaQueries användes för att skapa den responsiva designen.

1.5 Angular 4Angular är ett ramverk för utveckling av single-page-webbapplikationer. Det användes i detta pro-jekt för att underlätta synkronisering mellan vyn och data (two-way-binding"). Vid utveckling avAngular-applikation strävar man efter att bygga återanvändingsbara komponenter. Projektet an-vänder den, vid skrivande stund, senaste versionen av Angular: Angular 4. Det är bakåtkompatibeltmed Angular 2+ men inte med Angular 1.x (AngularJs). Sedan Angular 2 används TypeScript iramverket. För mer information, se dokumentationen för Angular [1].

1.6 PrimeNGPrimeNG är ett bibliotek med grafiska komponenter för Angular. Det visade sig att flera av kom-ponenterna behövde justeras för att fungera och se ut på tänkt sätt. Många av de tillgängligakomponenterna användes som grund för att göra egna. Se den officiella hemsidan för mer informa-tion [2].

1.7 ReactiveFormsModuleReactiveFormsModule är en modul i Angular 4 som tillåter enkel specificering och validering avformulär. Modulen låter utvecklare definiera formulär och dess egenskaper i affärslagret istället fördirekt i HTML, som varit aktuellt i tidigare versioner av Angular. Se den officiella dokumentationenför mer information [3].

1.8 Font AwesomeFont Awesome är ett ikon-bibliotek som används i portalen för att utsmycka knappar i det grafiskagränssnittet1.

1.9 UMLUML, Unified Modeling Language, användes för att skapa det arkitekturella översiktsdiagram somvisas i kapitel 3.5. Modelleringen gjorde i UML-redigeraren Astah Community Edition.

1Se dokumentationen på http://www.fontawesome.io/get-started/

2

2 FunktionalitetPortalen ska erbjuda en användare möjligheten att hitta information gällande avfallshantering in-om någon av de nio kommunerna i SÖRAB-regionen. Det ska vara möjligt att beställa en tjänst.Detta ska möjliggöras genom att erbjuda ett standardiserat formulär som användaren kan fylla i.När formuläret är ifyllt ska datan skickas till korrekt mejl-server. Portalen erbjuder en sökfunktiondär användare kan söka på olika avfallsprodukter för att hitta rätt fraktion. För mer informationom portalens krav, se separat dokument Kravspecifikation.

I den aktuella versionen skickas inte formuläret från portalen.

3

3 Arkitektur & designPortalen utvecklas med ramverket Angular 4. Anledningen till att Angular används är för att detkörs på klient-sidan och behöver, för grundläggande funktionalitet, ingen server för att genererasidor. En server behövs endast för att hosta applikationen. Angular är ett single-page-application-ramverk. Detta betyder att all navigering sker lokalt hos klienten genom användning av Angularsrouting-modul.

Arkitekturen i en Angular-applikation kan ses som att det följer ett MVW-mönster (Model-View-Whatever). Mönstret kan anpassas till att mer följa ett traditionellt MVC-mönster (Model-View-Controller). En Angular-applikation består av komponenter (Components). Varje komponent iportalen består av en komponentmall (Component Template) och en komponentklass. Komponent-mallen strukturerar innehållet med HTML, medan komponentklassen är en TypeScript-fil som kananvändas för att programmera logiken. Anledningen till Angular kan ses som ett MVW-ramverk ärför att komponentklasserna kan användas som antingen Model eller Controller, eller båda. För attfå en tydligare separering mellan Model och Controller kan man till exempel använda så kalladeservices, som agerar som Model. Interaktion med applikationen sker då genom mönstret:

1. View - Komponentmallar. Användaren interagerar med användargränssnittet. Dessa filer har.html -filändelsen.

2. Controller - Komponentklass. Beroende på användarens val i vyn, körs metoder i klassen somi sin tur anropar en service-klass. Dessa filer har .ts-filändelsen2.

3. Model - Service-klass. Metoder blir anropade från komponentklassen för att till exempelhämta data. Dessa filer har .ts-filändelsen.

Den hämtade datan tar samma väg tillbaka för att slutligen presenteras för användaren.

Följande kapitel presenterar mer utförligt hur MVC-mönstret används i projektet. Stegvis, ge-nom applikationens hela arkitektur, presenteras hur vyn kan komma åt och presentera data föranvändaren.

3.1 View: KomponentmallarPresentationslagret består av HTML-dokument som strukturerar innehållet som visas för använ-daren. Portalen använder Angulars router för att styra vilken sida som visas för användaren. Detär den större rutan till vänster, som kan ses i figur 1a, som byts"ut när en ny sida ska visas. Denmarkerade raden i figur 1b visar hur applikationen använder Angulars router för att styra vilketinnehåll som visas.

Strukturen i portalen erhålls till stor del genom att använda Grid, definierat genom CSS-klasserav PrimeNG. HTML-taggen <div> används för att strukturera upp en tabell. Divarna tilldelasolika klasser för att bete sig annorlunda beroende på skärmstorlek, där varje div agerar som enkolumn i tabellen. Tabellen är uppdelad i 12 tillgängliga kolumner, där den tilldelade klassen angerhur många av dessa som ska användas. Ett exempel visas i figur 2, som innehåller tabell som de-finierats på detta sätt. I den första markerade raden tilldelas diven klassen ui-grid, som blir rotenför tabellen. Den andra markerade raden anger hur tabellen ska bete sig för olika skärmstorlekar.ui-g-12 betyder att diven ska sträva efter at ta upp hela den tillgängliga bredden. ui-md-6 betyderatt för mellanstora skärmar ska varje div ta upp 6 av 12 kolumner, det vill säga hälften av dentillgängliga bredden. ui-lg-4 betyder att för stora skärmar ska varje div ta upp 4 av 12 kolumner,det vill säga en tredjedel av tillgänglig bredd.

*ngFor är ett Angular-direktiv som itererar över en Array för att konstruera HTML-elementdynamiskt. Direktivet skapar i det här fallet en div för varje element i Array kommuner, somär definierad i den tillhörande komponentklassen. Inuti denna for-loop har vi tillgång till loop-variabeln som har namnet kommun. Den fjärde markerade raden använder denna variabel för atthämta namnet på kommunen. Dubbla klammerparenteser används, i Angular, för att använda datasom existerar i komponentklassen.

2.ts är filändelsen för TypeScript-filer

4

(a)

(b)

Figur 1: Router-outlet används för att styra vilken sida som ska visas.

(a)

(b)

Figur 2: Applikationen visar knappar med alla kommuner som presenteras annorlunda på olikaskärmstorlekar.

5

3.1.1 Mobilanpassning

Förutom att definiera olika kolumnbredder i tabeller används CSS media queries för att anpassaportalens utseende vid olika skärmstorlekar. Den viktigaste delen av mobilanpassningen är menyn.Figur 3a visar hur menyn ser ut på mindre skärmstorlekar. Menyn göms och en hamburger -knappvisas istället. Om knappen aktiveras visas menyn som en lista. Figur 3b visar ett exempel påhur element kan ha annorlunda stil beroende på skärmens storlek. Klasserna vars stiler anpassasunder @Media-taggen gäller endast då skärmstorleken ligger i intervallet 0 till 768 pixlar bred. ID:tnav-mobile-button tillhör hamburger-knappen, som gör att den kan döljas vid större skärmar. Påsamma sätt kan den breda menyn, för de större skärmarna, döljas när skärmstorleken underskrider768 pixlar.

(a)

(b)

Figur 3: Menyn visas annorlunda på mindre skärmar. CSS media queries används för att åstad-komma effekten.

6

3.2 Controller: Komponent-klasserMetoder som anropas från komponenter (vyn) körs i motsvarande komponentklass (controllern).Det kan även vara dynamisk data som visas i vyn som hämtas via controllern. I fallet med att visade olika kommunerna används komponentklassen för att skicka vidare ett anrop, till modellen. Sefigur 4a, där en klassvariabel, kommuner, initieras och instansieras som en tom Array. Det är dennaArray som vyn itererar över, som beskrivet i tidigare kapitel.

ngOnInit är en livscykel-metod som körs när komponenten skapas. Variabeln dataService geråtkomst till Model-klassen, som innehåller metoden getKommuner(). Nyckelordet this måste an-vändas för att komma åt de lokalt definierade variablerna. En then-konstruktion används för atthantera den asynkrona operationen som efterfrågar kommunerna. Först när det asynkrona anropetär färdigt, tilldelas kommuner. Livscykelmetoden, anropet till Model och slutligen tilldelningen avklassvariabeln kommuner kan ses i figur 4b.

(a)

(b)

Figur 4: Komponentklassen innehåller till exempel metoder för att efterfråga data till en Arraymed kommuner.

3.3 Model: ServicesModellen innehåller de metoder som anropas av controllern. I portalen representeras modellen aven service-klass. Klassen innehåller metoder som returnerar den data som ska visas för användaren.Servicen har importerat en Array, KOMMUNER, som är lagrad lokalt. Figur 5 visar en metod,getKommuner(), som returnerar ett Promise som, när det körs, innehåller den efterfrågade Arrayen.

Figur 5: En metod i service-klassen som returnerar en Array inbakat i ett Promise.

7

I modellen definieras även den struktur som representerar olika data. Figur 6 visar, en del av,hur en kommun är definierad. Anledningen till att definiera en klass på det här sättet är för att,vid användning, låta programmeringsmiljön ge förslag på tillgängliga attribut.

Figur 6: Deklareringen av datans struktur tillhör Model.

3.4 DataUnder utveckling används data som lagras lokalt i applikationen, i TypeScript-filer. Filerna in-nehåller Arrayer av JSON-objekt. Komponent-klasserna och service-klasserna är skrivna på ettsätt som för framtida arbete tillåter hämtning av data via till exempel HTTP eller databasanrop.Detta möjliggörs genom att använda Promises, en teknik för att hantera asynkrona händelser iJavaScript. Google Developers guide3 beskriver Promises och dess användningsområden.

Figur 7: En Array med kommuner där varje element representeras av ett JSON-objekt.

3https://developers.google.com/web/fundamentals/getting-started/primers/promises

8

3.5 ArkitekturöversiktI figur 8 presenteras en översikt över hela applikationens arkitektur. Varje relevant fil i applikationenmotsvaras i diagrammet av en UML-klass. I vyn finns de HTML-dokument (komponentmallarna)som strukturerar innehållet. Filen styles.css används som en global stilmal för samtliga HTML-filer. Komponentmallrna har en tillhörande komponentklass i Controllern. Dessa klasser dirigerarde metodanrop, som startas i vyn, vidare till modellen. Vissa anrop sker av användaren, andrasker automatiskt för att hämta det innehåll som ska visas. Modellen innehåller filer som definierarklasser. Modellklasserna är definierade som JSON-prototyper. GlobalDataService väntar på anropfrån Controllern, för att hämta den data som behövs.

Figur 8: En översikt över applikationens lager.

9

4 ValideringValidering av formulär görs i portalen med hjälp av Angular-modulen ReactiveFormsModule. Mo-dulen låter oss definiera formulärets innehåll och validering i komponent-klassen.

(a)

(b)

(c)

(d)

Figur 9: Formulärets komponentklass definierar fälten i formuläret. Felmeddelandet visas om vali-deringen inte är godkänd.

Figur 9 visar de viktigaste delarna av validering av fält i ett formulär. I ReactiveFormsModulebeskrivs ett formulär av klassen FormGroup. En FormGroup består av en eller flera FormControls,som motsvarar ett fält i formuläret. Attibutet namn, som kan ses i figur 9b är en FormControl sominte tilldelas något ursprungsvärde, null, och ska följa valideringsregeln required, det är ett obli-gatoriskt fält. Figur 9c visar hur misslyckad validering resulterar i att ett felmeddelande renderasför användaren, med hjälp av ett *ngIf-direktiv. Ett ytterligare villkor för att felmeddelandet skarenderas är touched. Detta villkor evalueras till sant först efter att användaren har fokuserat påfältet minst en gång, för att undvika att felmeddelanden visas direkt när sidan öppnas. Figur 9dvisar hur felmeddelandet ser ut.

10

5 InstallationNågra steg bör följas innan utveckling i ramverket påbörjas. Detta kapitel beskriver grundläggandehjälp för att fortsätta utveckling av påbörjade Angular-projekt. Samtlig information är hämtadfrån den officiella dokumentationen [1].

5.1 Angular CLIFör att underlätta utveckling finns Angular CLI (Command Line Interface). Det kan till exempelanvändas för att skapa projekt, lägga till filer och för att testköra applikationen lokalt. För attladda ner Angular CLI krävs först installation av Node.js och npm4. När de är installerade kanAngular CLI laddas ned genom att, via terminalfönstret, köra kommandot:

npm install -g @angular/cli

Efter att nedladdning och installation är slutförd kan nya Angular-projekt skapas var som helst pådatorn och existerande projekt kan startas och redigeras. CLI:t används genom att alla kommandonges prefixet ng.

5.1.1 Nyttiga kommandon

Det finns ett flertal kommandon som kan vara av nytta för att effektivisera utveckling av en applika-tion i Angular. I kapitlet visas och förklaras kort några kommandon som använts vid utveckling avdet aktuella projektet. Samtliga kommandon körs från projektets rotmapp, via ett terminalfönster.

För att starta en lokal testserver kan följande kommando användas:

ng serve -open

eller

ng serve -open -host *lokal IP-adress*

Kommandot ser till att applikationen laddas om varje gång en ändring sparas i någon av projektetsfiler. Flaggan -open gör att applikationen automatiskt öppnas i en webbläsare. Flaggan -host, följtav den lokala IP-adressen, gör att applikationen kan nås av andra enheter på samma nätverk. Dettaär nyttigt för att, till exempel, kunna besöka applikationen från en mobil enhet.

För att generera nya komponenter och services kan kommandot generate användas enligt föl-jande:

ng generate component componentName

och

ng generate service serviceName

Kommandona gör att de nyskapade filerna automatiskt läggs till i applikationen.

4Se https://nodejs.org/en/download/

11

6 Referenser[1] Angular Documentation, 2017. Tillgänglig

online(2017-05-30):https://angular.io/docs/ts/latest/.

[2] PrimeNG, 2017. Tillgänglig online(2017-05-30):https://www.primefaces.org/primeng/#/.

[3] Angular Documentation | Reactive Forms, 2017. Tillgängligonline(2017-05-30):https://angular.io/docs/ts/latest/guide/reactive-forms.html.

12

TRITA TRITA-ICT-EX-2017:60

www.kth.se

avfallshantering: mjukvara för hantering av information...

Documents