FrameworkFinder - Implementation av användbarhet hos webbapplikationer

Teknik och samh¨alle Datavetenskap

Examensarbete 15 h¨ogskolepo¨ang, grundniv˚a

FrameworkFinder - Implementation av anv¨andbarhet hos

webbapplikationer

FrameworkFinder - Implementing usability in web applications

Robin S¨

oderholm

Examen: kandidatexamen 180 hp Huvudomr˚ade: datavetenskap

Program: Datavetenskap och applikations-utveckling

Datum f¨or slutseminarium: 2019-02-07

Sammanfattning

Webbutveckling och dess ekosystem kan vara frustrerande ¨aven f¨or den initierade. Det finns en otalig m¨angd ramverk och bibliotek som ofta erbjuder samma eller snarlik funktion. Samtidigt f¨or¨andras detta ekosystem n¨astan dagligen med nya till¨agg som ytterligare h¨ojer inl¨arningskurvan f¨or en utvecklare. Av denna anledning ¨ar det viktigt att g¨ora processen av att v¨alja dessa ramverk enklare f¨or att minska frustrationen kring det och f¨ormedla en f¨orklaring kring varf¨or de finns.

I denna studie unders¨oks det huruvida det ¨ar m¨ojligt att utveckla en webbapplika-tion som v¨aljer ut en l¨amplig samling ramverk och verktyg och presenterar detta f¨or anv¨andaren. Det unders¨oks ¨aven huruvida ett s˚adant verktyg kan g¨oras anv¨andarv¨anligt.

Abstract

The ecosystem of web development can be frustrating even for the initiated. Nowadays there is a countless number of frameworks that supply functionality to web applications. Moreover, several of these frameworks offer the same or similar functionality which only serves to increase the difficulty of choosing the right one for a given project. At the same time, new frameworks are released almost daily, leaving predecessors obsolete. Therefore, it is increasingly important for the web developer to stay up to date with the world of frameworks.

This study aims to investigate whether it is possible to develop a user-friendly tool that educates and aids the developer in choosing a proper collection of frameworks and libraries for a project.

Inneh˚

all

1 Inledning 1

1.1 Bakgrund och tidigare forskning . . . 1

1.2 Avgr¨ansning . . . 1

1.3 Fr˚agest¨allning . . . 1

1.4 Tidigare forskning . . . 2

1.5 Anv¨andbarhet . . . 2

1.5.1 Anv¨andarbas . . . 2

1.5.2 Varf¨or ¨ar anv¨andbarhet viktigt? . . . 3

1.5.3 Anv¨andartestning . . . 3 1.5.4 Enk¨at . . . 3 1.6 Ramverk . . . 4 2 Metod 4 2.1 Metodbeskrivning . . . 4 2.2 RQ1 . . . 5 2.3 Steg i forskningsmetoden . . . 5

2.3.1 Konstruera ett konceptuellt ramverk . . . 5

2.3.2 Utveckla en systemarkitektur . . . 6

2.3.3 Analys och design av system . . . 6

2.3.4 Bygg systemet/prototypen . . . 6

2.3.5 Observation och utv¨ardering av prototyp . . . 6

2.4 RQ2 . . . 6 2.5 Metoddiskussion . . . 6 3 Design 7 3.1 Konceptuellt ramverk . . . 7 3.1.1 Anv¨andningsfall . . . 7 3.1.2 Krav . . . 7 3.2 Systemarkitektur . . . 7 3.3 Systemdesign . . . 8 3.4 Fl¨ode . . . 8 4 Implementation 9 4.1 Applikationen . . . 9 4.2 Klientsidan . . . 9 4.2.1 EJS . . . 10 4.3 Serversidan . . . 10 4.4 NodeJS . . . 10 4.5 Express . . . 11 4.6 Bootstrap . . . 11 4.7 MongoDB . . . 11

5 Resultat 12

5.1 Implementerad webbapplikation . . . 12

5.2 Server Side rendering . . . 14

5.3 Implementation av anv¨andbarhet . . . 14

5.4 Anv¨andartestning . . . 16

5.4.1 Enk¨atplattform . . . 17

5.5 Presentation av insamlad data . . . 17

6 Analys och Diskussion 22 6.1 RQ1 - Hur kan man utveckla en applikation som f¨oresl˚ar en samling ramverk och verktyg vid webbutveckling? . . . 22

6.2 RQ2 - Hur kan en s˚adan applikation utvecklas p˚a ett s¨att som p˚avisar h¨og anv¨andbarhet? . . . 22

6.2.1 Navigation och Gr¨anssnitt . . . 23

6.2.2 Felf¨ormedling . . . 23

6.2.3 Hastighet . . . 23

6.2.4 Relevans . . . 24

6.2.5 Flexibilitet . . . 24

7 Slutsatser och vidare forskning 25

1

Inledning

Detta kapitlet introducerar bakgrunden till studien. D¨arefter f¨oljer studiens m˚al, dess forskningsfr˚agor samt de avgr¨ansningar som finns.

1.1 Bakgrund och tidigare forskning

Webbutveckling ¨ar ett omr˚ade som idag f¨or¨andras v¨aldigt fort. De trender som anses vara nya och banbrytande idag ¨ar gamla och utdaterade imorgon och det ¨ar av denna anledning sv˚art f¨or utvecklaren att h˚alla sig ordentligt uppdaterad med ny teknologi. F¨or nyb¨orjaren som nyligen l¨art sig Javascript inneb¨ar detta att inl¨arningskurvan ¨ar brantare ¨an n˚agonsin. I takt med att hemsidor blivit st¨orre och att de g˚att fr˚an att presentera statisk informa-tion till att vara dynamiska, har s¨attet utvecklare bygger hemsidor p˚a f¨or¨andrats. Det ¨ar idag v¨aldigt vanligt att webbapplikationer anv¨ander n˚agon form av ramverk som st¨od vid utvecklingsprocessen. Jag vill d¨arf¨or skapa ett verktyg, i form av en webbapplikation som f¨orutom att delge information kring ramverk, ¨aven ska hj¨alpa webbutvecklaren att v¨alja en l¨amplig samling verktyg och ramverk f¨or sitt projekt. Detta g¨ors i syfte att utbilda om de f¨or och nackdelar som finns med att anv¨anda ramverk vid utveckling och f¨or att underl¨atta valet av dem.

F¨orutom ovan n¨amnda funktionalitet s˚a g¨aller det generellt att en webbapplikation ska vara anv¨andarv¨anlig (se t ex [10]). Jakob Nielsen definierar anv¨andbarhet som ett kvali-tetsattribut som bed¨omer hur enkla anv¨andarinterface ¨ar att anv¨anda [10].

1.2 Avgr¨ansning

Vi kan se v˚ar studie som best˚aende av f¨oljande tv˚a delar:

1. Utveckla en prototyp som informerar om och hj¨alper anv¨andare att v¨alja en samling ramverk och verktyg i en utvecklingsprocess.

2. Unders¨oka hur en s˚adan webbapplikation kan g¨oras anv¨andbar genom att inf¨orliva 10 riktlinjer som definierats av Jakob Nielsen [9]

1.3 Fr˚agest¨allning

Denna studie ska unders¨oka huruvida det ¨ar m¨ojligt att bygga ett verktyg som efter in-put fr˚an anv¨andaren kan f¨oresl˚a en samling verktyg som den kan anv¨anda i sin utveck-lingsprocess. Studien ska ¨aven unders¨oka i vilken utstr¨ackning denna prototyp kan g¨oras anv¨andarv¨anlig enligt den standard som finns idag och som definierats av Jakob Nielsen [10].

RQ1: Hur kan man utveckla en applikation som f¨oresl˚ar en samling ramverk och verktyg vid webbutveckling?

RQ2 Hur kan man utveckla denna applikation p˚a ett s¨att som p˚avisar h¨oga niv˚aer av anv¨andbarhet?

1.4 Tidigare forskning

N¨ar Web 2.0 kom f¨or¨andrades s¨attet folk nyttjade internet p˚a [18]. Hemsidor p˚a Internet gick fr˚an att inneh˚alla statisk information till en plats d¨ar anv¨andarna sj¨alva stod f¨or skapandet av ny information p˚a sidor som Facebook och Instagram [2]. Idag, n¨ar fler och fler f¨oretag flyttar sina tj¨anster online s˚asom bank och nyhetstj¨anster ¨ar anv¨andbarhet viktigare ¨an n˚agonsin. Det ¨ar viktigt att anv¨andare p˚a ett enkelt s¨att f¨orst˚ar hur man anv¨ander sig av tj¨ansterna. Vi lever nu i informations˚aldern och f¨or att anv¨andare ska kunna ta del av denna information har tanken kring hur man bygger webbapplikationer f¨or¨andrats radikalt.

1.5 Anv¨andbarhet

ISO definierar anv¨andbarhet som den grad av f¨orst˚aelse en anv¨andare har f¨or hur man brukar en produkt p˚a ett effektivt samt tillfredsst¨allande s¨att[4]. Effektivitet syftar i detta fallet p˚a hur mycket resurser en anv¨andare beh¨over spendera f¨or att utf¨ora en viss uppgift. Tillfredsst¨allelsen syftar till hur positiv anv¨andarens inst¨allning till produkten ¨ar efter anv¨andandet. Jakob Nielsen menar p˚a att ordet anv¨andbarhet fr¨amst utg¨ors av fem delar [12]. Dessa delar ¨ar f¨oljande:

Learnability - Learnability s¨oker finna svar p˚a hur enkelt det ¨ar f¨or en anv¨andare att l¨osa grundl¨aggande uppgifter vid deras f¨orsta m¨ote med webbapplikationen

Efficiency - N¨ar anv¨andaren v¨al har l¨art sig hur designen fungerar, hur enkelt ¨ar det f¨or den att utf¨ora vissa uppgifter?

Memorability - Vid ett ˚aterbes¨ok av designen efter en tids fr˚anvaro, hur enkelt ¨ar det f¨or anv¨andaren att minnas hur designen fungerar?

Errors - Hur m˚anga fel g¨or anv¨andaren vid anv¨andning av webbapplikationen och hur allvarliga ¨ar dessa? Hur enkelt ¨ar det f¨or anv¨andaren att ˚aterh¨amta sig fr˚an dessa fel?

Satisfaction - Hur behagligt ¨ar det f¨or anv¨andaren att anv¨anda den f¨oreslagna designen? Det finns emellertid fler kvalitetsattribut som r¨or omr˚adet anv¨andbarhet men de fem ovan n¨amnda delarna anses utg¨ora grundpelarna.

1.5.1 Anv¨andarbas

Traditionellt sett har anv¨andbarhet varit fokuserat p˚a att g¨ora en produkt s˚a l¨attanv¨and som m¨ojligt f¨or nyb¨orjaren. Ofta ¨ar detta r¨att tillv¨agag˚angss¨att d˚a det st¨orsta behovet f¨or l¨attf¨orst˚aelighet finns inom denna grupp. Det ¨ar emellertid viktigt f¨or f¨oretag att f¨orst˚a att de krav och behov som finns p˚a en produkt skiljer sig drastiskt beroende p˚a vem som f¨or tillf¨allet anv¨ander den. Till f¨oljd av oh˚allbarheten i att ha tv˚a olika utformningar p˚a samma produkt ¨ar det imperativt att f¨oretaget bakom en webbapplikation g¨or denna tillg¨anglig f¨or nyb¨orjare s˚av¨al som expertanv¨andare. Expertanv¨andaren definieras som de som p˚a sikt blir de anv¨andare som ˚aterv¨ander till webbapplikationen p˚a en eventuellt daglig basis[11]. Inom ramen f¨or denna studie ¨ar den tillt¨anka anv¨andaren fr¨amst utvecklare, oavsett om

detta ¨ar p˚a hobbyniv˚a eller inte. Dessa har ofta stor internetvana och f¨oruts¨atts kunna mer ¨an normalanv¨andaren. D¨arf¨or riktar sig designen fr¨amst till expertanv¨andare och dess f¨orv¨antningar p˚a en webbapplikation.

1.5.2 Varf¨or ¨ar anv¨andbarhet viktigt?

Internet ˚ar 2019 skiljer sig drastiskt fr˚an visionen som fanns vid dess skapande. ˚Ar 2019 ¨

ar Internet ¨oversv¨ammat med information och m˚anga f¨oretag och dess hemsidor erbjuder samma eller snarlika tj¨anster. Det spelar emellertid ingen roll hur bra en erbjuden tj¨anst bakom en webbapplikation egentligen ¨ar om det inte finns n˚agon som f¨orst˚ar hur denna anv¨ands. H¨ar kommer anv¨andbarhet in. F¨or att ett f¨oretag ska lyckas med sin hemsida erfordras en del kriterier som s¨akerst¨aller att informationen som erbjuds kan konsumeras av anv¨andaren p˚a ett fullgott s¨att. Det ¨ar viktigt att f¨orst˚a att detta inte enbart ¨ar viktigt f¨or anv¨andarens upplevelse utan ¨aven f¨or f¨oretag som ¨ar m˚ana om sin image d˚a ett f¨oretags existens ¨ar beroende av att det finns en kundbas. Tiden ¨ar ¨over n¨ar f¨oretag fr¨amst annonserade i gula sidorna och p˚a TV. Idag ¨ar Internet den huvudsakliga plattformen p˚a vilken f¨oretag kommunicerar sina tj¨anster med sin m˚algrupp och d¨ar de l¨agger majoriteten av sina annonspengar[5].

Tydlighet F¨or att en webbapplikation ska kunna anses vara anv¨andbar erfordrar det att webbapplikationen p˚a ett klart och tydligt s¨att f¨ormedlar vad m˚alet med den ¨ar samt vad den kan erbjuda anv¨andaren. Detta skapar i sin tur f¨orst˚aelse kring tj¨ansten vilket i l¨angden inger ett f¨ortroende f¨or f¨oretaget och dess erbjudna tj¨anster. L¨attnavigerad F¨or att kunna ta del av all information applikationen har att erbjuda

m˚aste anv¨andaren kunna hitta fram till den eller produkten p˚a ett l¨attnavigerat och tillfredsst¨allande s¨att, annars kan anv¨andaren om¨ojligt k¨opa eller tillgodog¨ora sig den i avsedd form. D˚alig navigation frustrerar anv¨andare och g¨or att de l¨amnar tj¨ansten f¨or en annan motsvarande tj¨anst.

1.5.3 Anv¨andartestning

Det finns flera olika s¨att att anv¨andartesta en applikation. Det enklaste och kanske mest anv¨andbara s¨attet att testa en design p˚a ¨ar anv¨andartestning[14]. Detta test utf¨ors genom att testledaren sitter och passivt observerar anv¨andaren under dess anv¨andande av tj¨ansten f¨or att se var anv¨andaren g¨or r¨att eller fel samt vilka tester som tar l¨angre tid ¨an andra. Det kan ¨aven utf¨oras genom att testdeltagarna f˚ar fylla i en enk¨at vid avklarat prov. Det finns f¨or och nackdelar med b˚ada och i detta projektet har enk¨at valts ut som metod.

Ett test som inkluderar fem testpersoner ¨ar enligt Jakob Nielsen tillr¨ackligt f¨or att identifiera de st¨orsta designproblem som finns n¨arvarande hos en produkt[14]. I valet av testpersoner ¨ar det viktigt att g¨ora ett urval av m¨anniskor som anses vara potentiella anv¨andare av tj¨ansten d˚a det ¨ar dessa som st¨alls inf¨or designen. I detta fall ¨ar dessa potentiella anv¨andare personer som ut¨ovar webbutveckling i n˚agon form [11].

1.5.4 Enk¨at

En enk¨at anv¨ands ofta som ett komplement till anv¨andartestet vid m¨atning av anv¨andbarhet. Enk¨aten syftar till att samla in data om hur testdeltagarna upplever applikationens anv¨andbarhet.

Detta inneb¨ar i praktiken att man l˚ater testdeltagarna fylla i en enk¨at efter avklarat anv¨andartest. Notera att testdeltagarna l¨ampligen ¨ar t¨ankta anv¨andare av applikationen. Innan enk¨aten utformas ¨ar det viktigt att man f¨orst˚ar vad m˚alet med enk¨aten ¨ar, vilka svar som s¨oks samt hur resultaten som insamlas fr˚an enk¨aten ska tolkas[10]. Innan enk¨aten utformas ¨ar det viktigt att man f¨orst˚ar vad m˚alet med enk¨aten ¨ar, vilka svar som s¨oks samt hur resultaten som insamlas fr˚an enk¨aten ska tolkas.

Med detta i ˚atanke bed¨oms Likertskalan vara ett l¨ampligt verktyg som kan anv¨andas f¨or att bed¨oma anv¨andarna av tj¨anstens attityd gentemot de p˚ast˚aenden som st¨alls i enk¨atunders¨okningen. Detta d˚a Likertskalan ger en ¨onskv¨ard granularitet som m¨ojligg¨or en djup analys av de svar som samlats in. Likertskalan utg¨ors av en fem eller sjugradig skala som i detta fall ¨amnar ge forskaren en bild kring hur pass v¨al en anv¨andares attityd st¨ammer in p˚a de f¨orv¨antningar som finns p˚a tj¨ansten[7].

Figur 1: exempel p˚a en enk¨at som anv¨ander sig av Likertskalan

1.6 Ramverk

Begreppet ramverk (framework) definieras som n˚agot som utg¨or en n¨odv¨andig struktur vid konstruktionen av ett objekt, ett s˚a kallat skelett[8]. I kontexten av utveckling inneb¨ar detta att ramverket ska ge st¨od i utvecklingsprocessen av en produkt. I kontexten av webbutveckling hj¨alper ramverk till med automatiseringen av saker som riskerar ta on¨odigt l˚ang tid i ett nytt projekt s˚asom uppl¨agg av struktur och installation av n¨odv¨andiga bibliotek f¨or en viss uppgift. D˚a m˚anga ramverk f¨oljer designm¨onstret MVC s˚a till˚ater det utvecklaren att uppr¨atth˚alla en struktur p˚a sin kod som uppmuntrar ˚ateranv¨andningen av kod vilket i sin tur g¨or vidareutvecklingen av produkten enklare[6].

2

Metod

2.1 Metodbeskrivning

Denna studie ¨ar uppdelad i tv˚a delar. En studie som syftar till att s¨atta sig in i tidigare forskning som anv¨ands f¨or att samla ihop relevant information och data om den forskning som idag finns inom omr˚adet. Denna data kommer sedan ligga till grund f¨or det arbete som utf¨ors under del tv˚a. Andra delen ¨ar utvecklingen av en prototyp, i detta fall en webbapplikation som ¨ar t¨ankt att anv¨andas i informativt syfte om de f¨or och nackdelar som finns med att anv¨anda olika ramverk i en utvecklingsprocess. Ett andra syfte f¨or hemsidan ¨

bibliotek till sitt projekt baserat p˚a dennes svar p˚a ett formul¨ar g¨allande dennes behov. Anv¨andargruppen ¨ar s˚aledes fr¨amst utvecklare men m˚alet ¨ar att g¨ora denna anv¨andbar f¨or ¨

aven normalanv¨andare. Applikationen ska i sig sj¨alv utg¨ora ett exempel p˚a en applikation med h¨oga niv˚aer av anv¨andbarhet. D˚a m˚alet med den andra delen av projektet ¨ar att utveckla en prototyp ¨ar det av denna anledning l¨ampligt att anv¨anda en forskningsmetod som tillhandah˚aller ett ramverk f¨or att ˚astadkomma detta p˚a ett modernt och agilt s¨att.

2.2 RQ1

I utvecklingen av en prototyp till denna studie har systemutveckling som en forsknings-metod anv¨ants som f¨oreslaget av Nunamaker[16]. Denna metod l¨ampar sig v¨aldigt v¨al f¨or denna uppgift d˚a metoden i sig tillhandah˚aller ett systematiskt s¨att att bygga ett system p˚a. Ett resultat av forskningsmetodens agila natur blir att utvecklaren st¨andigt ˚aterkommer till tidigare steg i utvecklingsprocessen f¨or att utv¨ardera och eventuellt utf¨ora

n¨odv¨andiga f¨or¨andringar.

2.3 Steg i forskningsmetoden

Nunamakers forskningsmetod best˚ar av fem steg som illustreras nedan.

Figur 2: Ovanst˚aende diagram illustrerar de olika stegen i Nunamakers forskningsmetod[16]

2.3.1 Konstruera ett konceptuellt ramverk

Det allra f¨orsta steget i denna utvecklingsprocess ¨ar att formulera en meningsfull forsk-ningsfr˚aga och motivera varf¨or denna fr˚aga ¨ar viktig att besvara. H¨ar unders¨oker forskaren

¨

aven vilken funktionalitet systemet beh¨over vara i besittning av genom att formulera en tydlig kravspecifikation. I denna del ska forskaren ta reda p˚a vad som ska byggas och hur detta ska g˚a till. Denna del ¨ar vital f¨or processen d˚a utvecklaren beh¨over f¨orst˚a dom¨anen f¨or att kunna l¨osa problemet ifr˚aga.

2.3.2 Utveckla en systemarkitektur

Efter att ha identifierat de krav som st¨alls p˚a systemet kan systemarkitekturen designas. I detta stadiet ¨ar m˚alet att utveckla en systemarkitektur som till˚ater framtida utbyggnad. D˚a forskningsmetoden ¨ar iterativ och utvecklaren kan beh¨ova ˚aterbes¨oka tidigare steg i processen ¨ar det viktigt att komponenterna som utg¨or systemet byggs modul¨art. Under detta steg definierar utvecklaren ¨aven vilken funktionalitet de de olika komponenterna b¨or ha, dess f¨orh˚allande tiall varandra samt hur dessa kommunicerar med varandra.

2.3.3 Analys och design av system

I detta steget designas de processer som beh¨ovs f¨or att systemet ska kunna utf¨ora de funktioner som beh¨ovs f¨or anv¨andningsfallet. Optimalt tas fler l¨osningar ¨an en fram h¨ar och en v¨aljs ut f¨or vidare utveckling.

2.3.4 Bygg systemet/prototypen

Kan problemet l¨osas med den prototyp som skapats? Om svaret p˚a denna fr˚aga ¨ar jakande ska forskaren visa p˚a hur, samt varf¨or det l¨oser det aktuella problemet.

2.3.5 Observation och utv¨ardering av prototyp

I detta steget utv¨arderar forskaren om prototypen kan anses ha uppn˚att de krav som st¨allts p˚a den. F¨or att kunna utv¨ardera om m˚alen uppfyllts kommer testdeltagarna att fylla i en enk¨at r¨orande applikationens funktionalitet.

2.4 RQ2

RQ2 syftar till att samla in ˚asikter fr˚an anv¨andare g¨allande webbapplikations grad av anv¨andbarhet. Svaren fr˚an anv¨andarna kommer att j¨amf¨oras med redan existerande kri-terier som definierar vad som utg¨or en anv¨andbar applikation. F¨or att ˚astadkomma detta kommer en enk¨at skickas ut som testdeltagarna kommer att fylla i.

2.5 Metoddiskussion

Nunamakers forskningsmetod systemutveckling[16] valdes som prim¨ar forskningsmetod d˚a den l¨ampar sig v¨aldigt v¨al f¨or agil utveckling.. Dess agila natur ger utvecklaren ett robust ramverk att f¨orh˚alla sig till vad g¨aller utvecklingen av applikationen som utvecklas men ¨

aven ˚at forskningen i sig. En alternativ metod till denna hade kunnat vara Design and Creation d˚a ¨aven den ¨ar iterativ i sitt f¨orh˚allningss¨att till forskning [17]. Denna forsknings-metod valdes emellertid bort d˚a Nunamakers forskningsmetod[16] k¨anns mer intuitiv att anv¨anda sig av d˚a dess fl¨ode g¨or att den upplevs som b¨attre l¨ampad vid utvecklingen av ett system. Ett alternativ till en enk¨at hade kunnat vara intervjuer. Intervjuer hade

gjort att ett mer djupg˚aende resonemang kring applikationen hade kunnat samlas in och presenterats. Detta hade emellertid ¨aven lett till att f¨arre svar kunnat samlas in. Detta valdes d¨arf¨or bort.

F¨or att kunna svara p˚a om applikationen uppvisar en h¨og niv˚a av anv¨andbarhet har en femgradig likertskala anv¨ants f¨or att utforma en enk¨at best˚aende av fr˚agor r¨orande webbapplikationens grad av anv¨andbarhet En ut¨okning av denna forskningsmetod vore att testdeltagarna hade svarat p˚a samma enk¨at under olika delar av utvecklingsproces-sen f¨or att se hur deras attityd g¨allande hemsidans anv¨andbarhet f¨or¨andrats i takt med att graden av anv¨andbarhet ¨okat. Detta visade sig emellertid vara sv˚art att koordinera tillsammans med testdeltagarna och till f¨oljd av den begr¨ansade tidsramen f¨or projektet valdes detta alternativ bort.

3

Design

3.1 Konceptuellt ramverk

I denna tidiga utvecklingsfas ¨ar det viktigt att skapa en tydlig bild av problemet man f¨ors¨oker l¨osa. Ett steg p˚a v¨agen f¨or att ˚astadkomma detta ¨ar genom att skapa anv¨andningsfall f¨or vad en anv¨andare beh¨over kunna g¨ora med prototypen. Fr˚an dessa anv¨andningsfall kan man sedan skapa en kravspecifikation d¨ar det klart och tydligt framg˚ar vad systemet beh¨over kunna g¨ora.

3.1.1 Anv¨andningsfall

D˚a systemet ska ge f¨orslag p˚a vilka verktyg och ramverk som kan anv¨andas av utvecklaren vid en utvecklingsprocess beh¨over ett formul¨ar skapas som samlar in information fr˚an anv¨andaren. Detta formul¨ar beh¨over vara kort och koncist f¨or att vara l¨attf¨orst˚aeligt men beh¨over samtidigt vara tillr¨ackligt detaljerat f¨or att kunna f¨oresl˚a en samling l¨ampliga verktyg utan att vara f¨or generiskt.

3.1.2 Krav

1. Anv¨andaren ska kunna fylla i ett fullst¨andigt formul¨ar som samlar in n¨odv¨andig information f¨or att kunna ge f¨orslag.

2. Systemet m˚aste f¨oresl˚a en lista med namn p˚a ramverk eller bibliotek samt en moti-vering f¨or dessa f¨or anv¨andaren.

3. Systemet m˚aste till˚ata anv¨andaren att spara sitt resultat i n˚agon form. 4. Systemet m˚aste p˚avisa h¨og anv¨andbarhet enligt g¨allande principer. 3.2 Systemarkitektur

Systemarkitekturen ¨ar sammans¨attningen av systemet. Ut¨over att denna m˚aste inneh˚alla sammans¨attningen av de komponenter som utg¨or systemet, m˚aste den ¨aven beskriva hur dessa fungerar och varf¨or de fungerar som de g¨or.

3.3 Systemdesign

Systemdesignen best˚ar i sin helhet av tv˚a delar. Systemets tekniska design ska finnas med. Ut¨over detta ska ¨aven ett fl¨odesdiagram finnas med som beskriver ett anv¨andarscenario fr˚an b¨orjan till slut, till exempel hur anv¨andaren interagerar med formul¨aret.

3.4 Fl¨ode

Figur 3: Hemsidans fl¨ode

Figur 3 visar hur fl¨odet p˚a hemsidan ser ut fr˚an dess att ett bes¨ok har inletts till att det avslutats. Fl¨odet b¨orjar med att anv¨andaren startar webbapplikationen. Anv¨andaren m¨ots d˚a av en text som f¨orklarar applikationens syfte. D¨arefter erbjuds anv¨andaren att starta fl¨odet genom att trycka p˚a en knapp som i sin tur ¨oppnar en dialogruta som kort f¨orklarar hur formul¨aret fungerar. Anv¨andaren trycker p˚a ¨annu en knapp och tas till for-mul¨aret som inneh˚aller flertalet inmatningsf¨alt som st¨aller fr˚agor kring anv¨andarens behov

i kontexten av nyutveckling. Efter att ha fyllt i detta formul¨ar skickas denna information till servern som i sin tur renderar ¨annu en sida inneh˚allandes f¨orslag som matchar den input anv¨andaren gett.

4

Implementation

Syftet med detta kapitel ¨ar att f¨orklara de teknologier som anv¨ants f¨or att bygga prototy-pen och motivera varf¨or dessa val gjorts.

4.1 Applikationen

Arkitekturen f¨or applikationen baseras p˚a klient-serverarkitekturen, ¨aven kallad ’Two tier architecture’[21]. Detta inneb¨ar att applikationen prim¨art ¨ar uppdelad i tv˚a lager. Klient-sidan ¨ar den del av applikationen som anv¨andare interagerar med genom webbl¨asaren och serversidan som inneh˚aller all data tolkar dennes input och returnerar ny data.

Serversidan utvecklas i Node med hj¨alp av ramverket Express. Arkitekturen f¨or en applikation som anv¨ander sig av detta ser ut p˚a f¨oljande s¨att:

Figur 4: Expressapplikation

4.2 Klientsidan

Klientsidan i ett projekt utg¨or det som inte s¨allan kallas f¨or frontend. Klientsidan ¨ar enkelt f¨orklarat det gr¨anssnitt som exponeras f¨or anv¨andaren n¨ar denne anv¨ander web-bapplikationen med hj¨alp av en webbl¨asare. D˚a ett grundl¨aggande m˚al f¨or projektet ¨ar att applikationen ska visa p˚a s˚a h¨og anv¨andbarhet som m¨ojligt och att s˚a m˚anga po-tentiella anv¨andare som m¨ojligt ska kunna ta del av den, kommer webbapplikationen att utvecklas till att ha responsiv design i syfte att g¨ora anv¨andarupplevelsen s˚a bra som m¨ojligt p˚a s˚a m˚anga olika typer av enheter som m¨ojligt. Detta d˚a de ofta kommer med olika sk¨armstorlekar. Dessa enheter kan variera fr˚an datorer till bland annat surfplattor

och smartphones. I ¨ovrigt kommer gr¨anssnittet att h˚allas s˚a minimalt som m¨ojligt f¨or att undvika att skapa delar som konkurrerar mot varandra om anv¨andarens uppm¨arksamhet. 4.2.1 EJS

EJS st˚ar f¨or ’Embedded Javascript’ och ¨ar ett templatingspr˚ak som till˚ater utvecklaren att generera HTML-kod med hj¨alp av vanlig JavaScript[1]. Templating g¨or att utvecklaren kan skapa dynamiska vyer med hj¨alp av den data som h¨amtas fr˚an servern. EJS-filerna ser ut som vanlig HTML med undantaget att JavaScriptkod kan k¨oras i dem. I dessa filer placeras platsh˚allare som vid k¨orning ers¨atts med den data som h¨amtas fr˚an servern. Fler f¨ordelar med att anv¨anda EJS f¨or att generera dynamisk information i webbapplikationer ¨

ar:

• EJS anv¨ander vanlig JavaScript. Detta leder till att man kan kapa mellanh¨ander och ytterligare bibliotek f¨or att ˚astadkomma samma resultat.

• EJS snabbar upp utvecklingsprocessen f¨or den som redan kan JavaScript d˚a ingen ny syntax beh¨over l¨aras in.

• EJS ¨ar enkel att debugga.

• EJS utvecklas aktivt och har en stor community som kan hj¨alpa till med att svara p˚a fr˚agor vid behov.

EJS inkluderar st¨od f¨or s˚a kallade ’Includes’ vilket inneb¨ar att man kan importera kod fr˚an en annan fil, till exempel ett sidhuvud eller navigation som anv¨ands av alla sidor i webbapplikationen. Detta leder till att koden till komponenter kan skrivas en g˚ang och ˚ateranv¨andas hur m˚anga g˚anger som helst.

4.3 Serversidan

Serversidan i projektet ¨ar det som ofta ben¨amns som backenden. Servern ¨ar den del av implementationen som bland annat hanterar in och utf¨orsel av data fr˚an databaser samt att den ansvarar f¨or att g¨ora denna presentabel f¨or klienten i form av l¨asbar text. Servern b¨ar ¨aven ansvaret f¨or att validera och sanitera den data som kommer fr˚an anv¨andarinput. Servern i denna implementation best˚ar av fr¨amst tv˚a delar. Del ett ¨ar ett REST-API som genom HTML-metoder s˚asom GET, POST, UPDATE samt DELETE exponeras f¨or klientsidan s˚a att denne kan kommunicera med servern i form av inh¨amtning av in och utf¨orsel av data. Bakom detta API ligger resten av servermjukvaran med tillh¨orande klasser som st˚ar f¨or applikationens funktionalitet.

4.4 NodeJS

Efter noggrant ¨overv¨agande togs beslutet att serversidan skulle utvecklas i JavaScript med hj¨alp av NodeJS. Node ¨ar en milj¨o f¨or JavaScript som till˚ater webbutvecklare att bygga sin server i JavaScript.

Node ger utvecklare st¨od f¨or att bygga skalbara n¨atverksapplikationer med h¨og prestanda. En f¨ordel med Node som ofta n¨amns ¨ar att det g¨or det m¨ojligt f¨or en utvecklare att anv¨anda

ett enda programmeringsspr˚ak f¨or att bygga hela sin applikation med d˚a ¨aven klientsidan anv¨ander sig av det. Node kommer med en pakethanterare som heter NPM som g¨or det m¨ojligt f¨or utvecklaren att enkelt ut¨oka sin applikations funktionalitet med s˚a kallade moduler[19]. Dessa moduler kan i sig tillhandah˚alla funktioner s˚asom l¨asning av filer och metodkroppar. Beslutet att anv¨anda Node togs med den relativt korta utvecklingstiden i ˚atanke d˚a Node g¨or det m¨ojligt att utveckla b˚ada klient och server med hj¨alp av JavaScript. Detta beslut kan vid r¨att omst¨andigheter leda till att utvecklingstiden av applikationen kortas ner d˚a det f¨orutom att vara ett l¨ampligt verktyg f¨or ¨andam˚alet ¨aven inneb¨ar att ytterligare programmeringsspr˚ak och bibliotek inte beh¨over l¨aras in d˚a milj¨on redan ¨ar bekant.

4.5 Express

APIet skapas med hj¨alp av ramverket Express. API st˚ar f¨or ’Application Programming In-terface’ och ¨ar den del av servern som m¨ojligg¨or kommunikation mellan klienten och servern i applikationen[20]. Express ¨ar ett f¨orh˚allandevis l¨attviktigt ramverk som kanske viktigast tillhandah˚aller ett enkelt s¨att f¨or klienten att tala med servern med hj¨alp av HTML-metoder. Med klient ˚asyftas webbl¨asaren som anv¨andaren nyttjar f¨or att anv¨anda web-bapplikationen. Det g˚ar alldeles utm¨arkt att ˚astadkomma ovanst˚aende utan att anv¨anda sig av ett ramverk men f¨ordelarna i form av bland annat tidsvinst bed¨omdes i detta fall vara st¨orre ¨an nackdelarna. D˚a Express ¨ar modul¨art och i sitt grundutf¨orande v¨aldigt minimalt kan och m˚aste utvecklaren vid behov importera ytterligare bibliotek som ut¨okar dess funktionalitet i den utstr¨ackning som kr¨avs. Detta kan b˚ade ses som en f¨ordel och nackdel d˚a det med sin minimalism ¨aven medf¨or att utvecklaren i h¨ogre utstr¨ackning sj¨alv beh¨over importera externa bibliotek f¨or att ut¨oka funktionaliteten i den m˚an det beh¨ovs. F¨or den som ¨ar van vid att en stor portion av vad som kan anses vara standardfunktiona-litet inte finns inkluderat fr˚an start kan detta ses som obekv¨amt. I optimalfallet resulterar ¨

aven detta i att l¨osningen blir v¨aldigt flexibel och s˚a liten i storlek som m¨ojligt. 4.6 Bootstrap

Ramverket Bootstrap har i detta projekt anv¨ants f¨or att utveckla det grafiska gr¨anssnittet i applikationen. Bootstrap snabbar upp utvecklingsprocessen av det grafiska gr¨anssnittet d˚a Bootstrap f¨orser utvecklaren med f¨ardig CSS-kod som g¨or det enkelt att g¨ora appli-kationens gr¨anssnitt responsivt och anpassat f¨or flera typer av enheter. Risken med att anv¨anda ett popul¨art ramverk som Bootstrap ¨ar att applikationen l¨oper risk att se ut som m˚anga andra hemsidor grafiskt. Detta kan dock b˚ade vara en f¨or och nackdel beroende p˚a hur man ser p˚a saken. ˚A ena sidan riskerar hemsidan att se likadan ut som m˚angra andra sidor, ˚a andra sidan inneb¨ar detta att igenk¨anningsfaktorn f¨or de komponenter som ryms inom ramverket ¨okar f¨or anv¨andaren d˚a den f˚ar en k¨ansla f¨or hur komponenterna brukar fungera. Bootstrapkomponenter g˚ar dock att skr¨addarsy med olika f¨arg och form s˚a att de b¨attre passar det egna varum¨arket.

4.7 MongoDB

MongoDB anv¨ands som den prim¨ara databasen f¨or applikationen. N¨ar det g¨aller databa-ser, finns det flertalet alternativ att v¨alja mellan som alla skulle kunna erbjuda godtagbar

prestanda och funktionalitet. F¨or detta projektet gjordes emellertid en avv¨agning mellan MongoDB och MySQL d˚a dessa tv˚a bed¨omdes vara mest l¨ampliga f¨or uppgiften. D˚a appli-kationen inte best˚ar av en n¨amnv¨ard m¨angd relationell data togs beslutet att MongoDB var mer l¨ampad f¨or uppgiften. MongoDB ¨ar en dokumentdatabas som lagrar databasob-jekt i vad som kallas ett dokument. Ett dokument ¨ar att n¨armast liknas med en rad i en relationell databas. Det ¨ar vanligt att dokumentdatabaser antingen lagrar sin data med formatet XML eller JSON. MongoDB anv¨ander sig av BSON som st˚ar f¨or ’Binary JSON’. Det finns klara f¨ordelar med detta som format d˚a det f¨orutom att vara l¨attl¨ast ¨aven har ett v¨aldigt intuitivt format f¨or utvecklaren att arbeta med [3]. Till f¨oljd av anv¨andandet av detta format, samt det faktum att MongoDB ¨ar schemal¨ost, kan en utvecklares produkti-vitet ¨oka d˚a tid inte beh¨over l¨aggas p˚a att designa tabeller i f¨orv¨ag[3]. MongoDBs flexibla natur l¨ampar sig ¨aven v¨al till det faktum att utvecklingsprocessen ¨ar och beh¨over vara iterativ d˚a ¨andringar kan beh¨ova g¨oras i varje steg av utvecklingsprocessen. MongoDB kommer fr¨amst att anv¨andas till att lagra artiklar som kommer presenteras p˚a applikatio-nens f¨orstasida samt blogginl¨agg.

5

Resultat

I detta kapitel kommer resultaten av den webbapplikation som utvecklats inom ramen f¨or denna studie presenteras. ¨Aven resultaten fr˚an anv¨andartestet och enk¨aten presenteras h¨ar.

5.1 Implementerad webbapplikation

Webbapplikationen som utvecklats som en del av denna studie har konstruerats med hj¨alp av verktyg och ramverk som ¨ar v¨alanv¨anda inom omr˚adet webbutveckling. Applikationen best˚ar av flertalet sidor. Dessa sidor ¨ar f¨oljande:

• Start • Resultat • Blogg • Hj¨alp • Kontakt

N¨ar applikationen startas m¨ots anv¨andaren av startsidan.

Denna sida erbjuder information om applikationen samt en knapp med texten ’Get Started’ som direkt tar en till formul¨aret som beg¨ar information om vad anv¨andaren s¨oker f¨or funktionalitet. Formul¨aret tar emot denna information, skickar den till servern som matchar den med objekt fr˚an databasen som motsvarar de svar anv¨andaren gett. Servern returnerar d¨arefter dessa objekt genom att rendera en resultatsida inneh˚allandes datan som h¨amtades fr˚an databasen. Applikationen har ¨aven en bloggsida som inneh˚aller kortare artiklar som f¨orklarar olika begrepp som anv¨ands inom applikationen, h¨ar kan ¨aven anv¨andarna kommentera och st¨alla fr˚agor vid oklarheter. Till sist s˚a finns det en hj¨alpsida som vid eventuella missf¨orst˚and visar exakt vad anv¨andaren kan g¨ora inom applikationen.

Figur 5: Webbapplikationens startsida.

Figur 6: Formul¨aret

Resultatet av detta formul¨ar ¨ar ytterligare en sida som f¨oresl˚ar en samling ramverk och andra verktyg. Anv¨andaren kan klicka p˚a detta f¨orslag vilket ¨oppnar upp en vy som inneh˚aller mer information, samt l¨ankar till skaparnas dokumentation av verktyget. Fr˚an denna vy kan anv¨andaren v¨alja att f˚a f¨orslaget skickat till deras e-post.

Figur 7: Applikationens resultatsida. 5.2 Server Side rendering

F¨or att s¨akerst¨alla att anv¨andarupplevelsen ¨ar h¨og, inte bara sett till hur komponenter och annat ¨ar placerat p˚a sidorna i webbapplikationen har ¨aven h¨oga krav st¨allts p˚a web-bapplikationens prestanda. F¨or att ˚astadkomma en s˚a snabb och effektiv webbapplikation som m¨ojligt har tekniken Server Side Rendering anv¨ants. Detta inneb¨ar att en full statisk sida renderas fr˚an servern s˚a fort anv¨andaren matat in adressen f¨or att bes¨oka webbappli-kationen. Alternativet vore att anv¨andaren ist¨allet m¨ots av en vit sida som bitvis laddar in alla sidans komponenter vilket ¨ar fallet n¨ar sidan renderas fr˚an klienten. I praktiken ¨ar det inte avsev¨art mycket snabbare sett till ren tid. Anv¨andarupplevelsen blir dock b¨attre d˚a applikationen upplevs som snabbare ¨an den faktiskt ¨ar i praktiken.

5.3 Implementation av anv¨andbarhet

Det finns m˚anga, inte s¨allan varierande ˚asikter kring vad som utg¨or en modern, anv¨andbar applikation och det ena perspektivet ¨ar inte n¨odv¨andigtvis mer sant ¨an det andra. Av denna anledning ¨ar det av st¨orsta vikt att po¨angtera att denna studie enbart agerar utifr˚an ett perspektiv. I Jakob Nielsen och Marie Tahirs bok ’HomePage Usability: 50 websites deconstructed’ definieras 113 riktlinjer som bed¨omer hur anv¨andbar en hemsida ¨

ar [15]. Dessa riktlinjer str¨acker sig fr˚an hur en s¨okfunktion fungerar till hur utvecklaren b¨ast samlar in anv¨andardata samt hur l¨ankar ¨ar utformade f¨or att n¨amna n˚agra f˚a. Inom avgr¨ansningen f¨or detta projekt har emellertid tio riktlinjer som bed¨oms vara de viktigaste i aktuell kontext valts ut. Dessa ¨ar f¨oljande:

1. Synlighet av systemstatus inneb¨ar att systemet b¨or informera anv¨andaren om aktuell systemstatus inom en rimlig tid. Kommunikation skapar tillit och anv¨andaren beh¨over lita p˚a applikationen f¨or att vilja anv¨anda den. I en perfekt v¨arld hade

ladd-ningsikoner inte beh¨ovts men v¨arlden vi lever i best˚ar en divers skara av anv¨andare med varierande f¨oruts¨attningar s˚asom h˚ardvara och uppkopplingshastigheter. Det kan inte f¨oruts¨attas att applikationen kommer att vara lika snabb f¨or samtliga. D¨arf¨or har applikationen en laddningsikon som kommunicerar att n˚agot h¨ander ¨aven n¨ar det ser ut att ta tid.

2. Tydligt spr˚ak. Systemet b¨or anv¨anda sig av ett tydligt spr˚ak och kommunicera med ett spr˚akbruk som matchar anv¨andarens f¨orv¨antningar. Undvik systemorienterade termer som ¨ar mer av nytta f¨or en utvecklare men ofta betydelsel¨os f¨or en anv¨andare. 3. Anv¨andarkontroll och frihet. I det fall en anv¨andare v¨aljer fel ska denne erbjudas ett enkelt och tydligt s¨att att l¨amna det felaktiga stadiet utan att beh¨ova g¨ora om hela processen. Formul¨aret har d¨arf¨or tilldelats en knapp som till˚ater anv¨andaren att g˚a tillbaks vid varje stadie utan att f¨or den skull beh¨ova b¨orja om helt.

4. Konventioner. Ett tydligt spr˚ak sett till b˚ade spr˚akbruk och designspr˚ak ska anv¨andas s˚a en anv¨andare slipper undra om ett ord eller term betyder samma sak som denne f¨orv¨antar sig. Knappar och andra komponenter ska se likadana ut i ap-plikationen oavsett vilken sida anv¨andaren befinner sig p˚a.

5. Felprevention. Utvecklaren b¨or alltid str¨ava efter en design d¨ar ett fel kan f¨orhindras, snarare ¨an ˚atg¨ardas. I applikationen har detta ˚atg¨ardats genom att anv¨andaren i for-mul¨aret enbart kan v¨alja mellan f¨orbest¨amda val. Detta g¨or att systemet vet precis vilken input det har att f¨orv¨anta sig fr˚an ett visst val. Det kan inte bli n˚agra fel. 6. Igenk¨anning. Str¨ava efter att g¨ora viktiga delar av webbapplikationen l¨attigenk¨annliga

ist¨allet f¨or att f¨orlita p˚a anv¨andarens minne av hur saker ¨ar upplagda. Instruktioner f¨or hur man anv¨ander systemet ska vara synliga eller i minsta laget, l¨atta att h¨amta. I applikationen har detta l¨osts genom att placera viktiga komponenter direkt synli-ga f¨or anv¨andaren. Anv¨andaren beh¨over inte g˚a via n˚agra andra sidor f¨or att hitta huvudm˚alet.

7. Flexibilitet och effektivt anv¨andande Denna punkt inneb¨ar att gr¨anssnittet m˚aste vara flexibelt nog att anpassa sig till b˚ade nyb¨orjare s˚av¨al som expertanv¨andare. I denna applikation inneb¨ar detta att vid bes¨ok erbjuds anv¨andaren att genomg˚a en kort guidad tur genom hemsidan som f¨orklarar vad dess syfte ¨ar samt vad anv¨andaren kan g¨ora. Anv¨andaren ges en m¨ojlighet att skippa detta i det fall den k¨anner sig tillr¨ackligt bekv¨am med att g¨ora det sj¨alv.

8. Estetik och minimalistisk design Dialoger b¨or aldrig inneh˚alla irrelevant infor-mation f¨or anv¨andningsfallet. All extra information t¨avlar om anv¨andarens uppm¨arksamhet och g¨or detta p˚a bekostnad av relevant information. Detta g¨or att anv¨andaren gl¨ommer bort applikationens syfte. Av denna anledning har informationen h˚allits minimal f¨orutom i de fall en anv¨andare klickar p˚a en tooltip f¨or att f˚a n˚agot s¨arskilt f¨orklarat. Det g˚ar d¨arf¨or att argumentera f¨or att funktionen i applikationen som h¨amtar nyheter b¨or tas bort. Detta bed¨omdes dock ge merv¨arde till tj¨ansten av anv¨andarna och valdes d¨arf¨or att beh˚allas.

9. Fel˚aterh¨amtning Felmeddelanden ska klart indikera vad som orsakat ett problem och erbjuda en l¨osning. I applikationen har detta l¨osts genom att rendera s˚a kallade flash messages fr˚an servern. Om till exempel en resurs inte kan n˚as f¨or tillf¨allet, pre-senteras detta via ett felmeddelande som visas p˚a anv¨andarens sk¨arm. Samma sak g¨aller om en anv¨andare fyllt i en felaktig mailadress. Dessa meddelanden varierar i f¨arg beroende p˚a meddelandets natur. R¨ott ¨ar den f¨arg som anv¨ants f¨or att f¨ormedla fel och ¨ar n˚agot som anv¨andare normalt associerar med det. F¨or att inte avskr¨acka anv¨andaren ska felmeddelande f¨ormedlas p˚a ett artigt och icke-anklagande s¨att. Det-ta g¨ors genom ett spr˚akbruk som motiverar anv¨andaren till att forts¨atta anv¨anda applikationen.

10. Hj¨alp och dokumentation Applikationen b¨or vara skapad p˚a ett s˚adant s¨att att en anv¨andare inte beh¨over dokumentation f¨or att kunna anv¨anda den men i det fall det beh¨ovs, ska detta erbjudas. Denna dokumentation ska vara enkel att ge-noms¨oka. Denna dokumentation b¨or h˚allas minimal och relevant till anv¨andarfallen. F¨or att l¨osa detta har en hj¨alpsida skapats. D˚a applikationen ¨ar relativt liten ¨ar denna hj¨alpsida f¨or n¨arvarande minimal. Den ¨ar dock redan kopplad till s¨okf¨altet som finns tillg¨anglig p˚a alla sidor i applikationen. Detta s¨okf¨alt s¨oker ¨aven igenom blogginl¨agg efter information som ¨ar relevant till s¨okfr˚agan.

5.4 Anv¨andartestning

F¨or att testa huruvida applikationen uppfyller de utvalda krav som st¨allts p˚a den uti-fr˚an de kriterier Nielsen definierat har anv¨andartestning anv¨ants i kombination med en enk¨at som testdeltagarna f˚att svara p˚a[9][14]. Fem testdeltagare valdes ut f¨or att testa applikationen samt svara p˚a ett antal fr˚agor g¨allande applikationens funktion och hur pass tillfredsst¨allande denna ¨ar utifr˚an anv¨andarens perspektiv. Dessa anv¨andare har sedan tidigare en grundl¨aggande f¨orst˚aelse f¨or webbutveckling men ingen formell erfarenhet av anv¨andbarhet. Testgruppen best˚ar av tre m¨an och tv˚a kvinnor mellan ˚aldrarna 17-44. D˚a det bed¨omts att den st¨orsta anv¨andarbasen finns inom omr˚adet expertanv¨andare och utvecklare har anv¨andbarheten fr¨amst anpassats efter denna grupp men applikationen in-neh˚aller ¨aven funktionalitet som hj¨alper nyb¨orjaren. Formul¨aret best˚ar av ett antal fr˚agor som r¨or olika delar av webbapplikationen samt en ¨oppen fr˚aga som efterfr˚agar konstruktiv feedback.

Efter avklarat test st¨alldes anv¨andarna inf¨or en enk¨at som st¨allde p˚ast˚aenden kring deras upplevelse av applikationen.

1. Sidan upplevs som l¨attnavigerad.

2. Systemet anv¨ander sig av ett tydligt spr˚ak som matchar dina f¨orv¨antningar. 3. Viktiga delar av webbapplikationen ¨ar l¨attigenk¨annliga.

4. Inneh˚allet i webbapplikationenen ¨ar relevant till dina f¨orv¨antningar. 5. Applikationen f¨orklarar sin funktion v¨al.

7. Sidan upplevs som responsiv och snabb.

Anv¨andartestningen utf¨ordes ¨over ett videosamtal. Under samtalets g˚ang str¨ommades testdeltagarens sk¨arm samtidigt som denne anv¨ande webbapplikationen. Detta f¨or att anv¨andarens sk¨arm passivt skulle kunna ¨overvakas utan n˚agon form av v¨agledning fr˚an testledaren. Denna bit av testet ¨ar viktig f¨or att kunna se om nyckelmoment utf¨ordes med ¨onskv¨ard hastighet. I det fall dessa moment utf¨ors l˚angsamt kan testledaren f˚a en indikation p˚a huruvida detta moment lider av designproblem.

Enk¨aten som testdeltagarna har f˚att fylla i har syftet att ge svar p˚a huruvida de krav p˚a anv¨andbarhet som st¨allts p˚a den ¨ar uppfyllda. N˚agra kriterier ¨ar sv˚arare att definiera som fr˚agor d˚a det ¨ar saker som en anv¨andare eventuellt aldrig uppfattar men som ¨and˚a ligger till grund f¨or en bra upplevelse.

5.4.1 Enk¨atplattform

Datan och formul¨aret genererades genom Google Forms. Denna plattform anv¨andes f¨or att den f¨or m˚anga anv¨andare ¨ar en v¨alk¨and plattform, samt f¨or att plattformen p˚a ett enkelt s¨att m¨ojligg¨or insamling av testdata samt att den tillhandah˚aller diagram som p˚a ett klart och tydligt s¨att ger en ¨overblick av denna data. Kommande stycke kommer kort att presentera vad dessa kriterier inneb¨ar mer detaljerat samt hur dessa matchar formul¨arfr˚agorna.

5.5 Presentation av insamlad data

Som tidigare n¨amnts i metodavsnittet best˚ar enk¨aten av ˚atta fr˚agor. Svarsalternativen i formul¨aret ¨ar baserat p˚a en femgradig likertskala[7]. I praktiken inneb¨ar detta att svarsper-sonen st¨alls inf¨or ett antal p˚ast˚aenden d¨ar svarsdeltagaren f˚ar v¨alja vilket p˚ast˚aende som b¨ast passar den personliga upplevelsen kring ¨amnet i fr˚aga. Fr˚agorna ¨ar deriverade fr˚an tio kriterier som definierats av Jakob Nielsen[9]. Ju l¨angre ut till h¨oger p˚a skalan anv¨andaren hamnar i sina svar, ju mer h˚aller denne med om p˚ast˚aendet som st¨allts. Nedan presenteras samtliga svar fr˚an testdeltagarna.

Figur 10: Del 1 fr˚agor

Figur 12: Del 1 fr˚agor

Figur 13:

Figur 15:

6

Analys och Diskussion

Syftet med detta kapitel ¨ar att analysera och diskutera kring den insamlade data som presenterats i resultatdelen.

6.1 RQ1 - Hur kan man utveckla en applikation som f¨oresl˚ar en samling ramverk och verktyg vid webbutveckling?

Svaret f¨or denna forskningsfr˚aga ligger i utvecklingsprocessen av applikationen som pre-senterats i tidigare kapitel. Genom att granska testsvaren kan det konstateras att samtliga anv¨andare lyckades genomg˚a hela det fl¨ode som presenterades i det fl¨odesdiagrammet som skapades under designfasen. Anv¨andarna har d¨arf¨or tagit del av all funktionalitet som applikationen utlovat. Dessa testdeltagare fick vid avslutat fl¨ode ett f¨orslag p˚a en sam-ling verktyg att anv¨anda samt information kring hur dessa fungerar. Med dessa punkter i ˚atanke ser vi att denna applikation, som implementerades med hj¨alp av de steg som presenterats i denna uppsats, ¨ar ett exempel p˚a ett s¨att p˚a vilket man kan designa och implementera en webbapplikation som har f¨orm˚agan att f¨oresl˚a en samling verktyg till en utvecklingsprocess.

6.2 RQ2 - Hur kan en s˚adan applikation utvecklas p˚a ett s¨att som p˚avisar h¨og anv¨andbarhet?

Svaret p˚a RQ2 f˚as genom att inf¨orliva tidigare n¨amnda riktlinjer avseende anv¨andbarhet samt genom analys av de enk¨atsvaren som mottagits fr˚an testdeltagarna. Datan som sam-lats in tyder p˚a att dessa riktlinjer implementerats p˚a ett korrekt s¨att. Det visar att det ¨ar m¨ojligt att utveckla en s˚adan applikation som utvecklats inom ramen f¨or denna studie som p˚avisar h¨oga niv˚aer av anv¨andbarhet. Det ¨ar ¨aven viktigt att po¨angtera att detta perspek-tiv p˚a anv¨andbarhet inte n¨odv¨andigtvis ¨ar sant under alla t¨ankbara omst¨andigheter utan enbart g¨aller inom denna specifika grupp av testdeltagare och denna typ av applikation.

Syftet med f¨oljande stycken ¨amnar analysera de svar som samlats in i ett f¨ors¨ok att se huruvida n˚agon niv˚a av anv¨andbarhet uppn˚atts eller inte. Kriterierna h¨arstammar fr˚an Nielsens 10 riktlinjer f¨or vad som g¨or en applikation anv¨andbar[9].

6.2.1 Navigation och Gr¨anssnitt

Testsvaren tyder p˚a att alla deltagare ans˚ag att applikationens s¨att att navigera p˚a an-tingen var bra eller v¨aldigt bra. Serverloggar visar att samtliga delar av hemsidan bes¨okts. Med detta sagt anser jag att kravet av tydlig och effektiv navigation uppfyllts. Svaret p˚a fr˚aga tv˚a och fyra tyder ¨aven p˚a att hemsidan f¨ormedlar sitt syfte p˚a ett korrekt s¨att. Detta ¨ar inte f¨orv˚anande eftersom det f¨orsta anv¨andaren st¨alls inf¨or vid start av webbap-plikation ¨ar en f¨orklaring av dess syfte.

Samtliga deltagare tyckte att viktiga delar av hemsidan var l¨attigenk¨annliga. De viktigaste delarna av hemsidan ¨ar knappen som tar anv¨andaren vidare i huvudfl¨odet till formul¨aret som tar emot input och f¨oresl˚ar verktyg. F¨orutom val av f¨arg, pulserar denna knapp tillr¨ackligt f¨or att visa att den ¨ar viktig, men inte tillr¨ackligt f¨or att sticka i ¨ogonen p˚a anv¨andaren. I andra hand ¨ar de viktigaste delarna av applikationen de blogginl¨agg som syftar till att informera kring de saker applikationen vill informera om

Samtliga deltagare gav maxpo¨ang vad g¨aller applikationens f¨orklaring av sin egen funk-tion. Detta var f¨orv¨antat d˚a denna information inte g˚ar att missa d˚a den ¨ar bel¨agen h¨ogst upp p˚a f¨orstasidan.

6.2.2 Felf¨ormedling

Svaren var blandade g¨allande hur applikationen f¨ormedlar fel som kan uppst˚a. Enligt en kommentar som l¨amnats st¨otte en enda anv¨andare p˚a ett fel men det ¨ar oklart vad detta varit. Mest troligt har en f¨orfr˚agan gjorts till servern som sedan inte svarat. Denna fr˚aga hade eventuellt kunnat bytas ut till n˚agot som ¨ar l¨attare att testa. Alternativt hade ett fel kunnat planteras f¨or att tvinga fram ett fel. Det bed¨omdes dock att ett medvetet fel skulle p˚averka bilden av applikationen negativt och detta valdes d¨arf¨or bort.

6.2.3 Hastighet

Samtliga testdeltagare f¨orutom en ans˚ag att hemsidan var snabb och responsiv. F¨or att kvantifiera detta beh¨ovs en definition f¨or vad som kan anses vara snabbt. F¨or att se hur pass dessa svar st¨ammer ¨overens med definitionen gjordes ett test med hj¨alp av Google Chromes utvecklarverktyg d¨ar samtliga delar av applikationen laddades. Resultaten var f¨oljande:

• Startsidan var l˚angsammast med en responstid p˚a 480 ms. Denna sida ¨ar ¨aven den tyngsta i webbapplikationen. Detta ¨ar till f¨oljd av API-anropen till ett externt API f¨or att h¨amta nyheter samt att den renderar dessa till separata nyhetsposter. • Resultatsidan hade en genomsnittlig responstid p˚a 86 ms. Denna sida h¨amtar data

fr˚an en databas och renderar denna med hj¨alp av EJS.

• Bloggsidan hade en genomsnittlig responstid p˚a 160 ms. Denna sida h¨amtar data fr˚an en databas och renderar denna med hj¨alp av EJS.

Detta ger sidorna i applikationen en total genomsnittlig responstid p˚a 242 ms. Enligt Jakob Nielsen finns det tre prim¨ara tidsgr¨anser f¨or hur l˚angsamt en hemsida f˚ar svara[13].

Hemsidor som laddar klart p˚a under 100 ms upplevs vara momentana av anv¨andaren och ger k¨anslan av att det ¨ar anv¨andaren sj¨alv som f˚ar n˚agot att h¨anda. Mellan 100 ms och 1 sekund f˚ar anv¨andaren k¨anslan av att det ¨ar datorn som f˚ar n˚agot att h¨anda. Detta ¨ar dock inte tillr¨ackligt l˚angsamt f¨or att anv¨andaren ska f¨orlora k¨anslan av att ha kontroll ¨over interaktionen men det f¨ors¨amrar ¨and˚a anv¨andarupplevelsen n˚agot. I det fall hemsidan ¨ar l˚angsammare ¨an detta erfordras n˚agon form av feedback fr˚an systemet s˚asom en laddningsindikator f¨or att anv¨andaren inte ska k¨anna att den f¨orlorar greppet om interaktionen vid l˚anga laddningstider. F¨or att ˚atg¨arda detta har applikationen ett laddningshjul som dyker upp n¨ar sidan laddar s˚a anv¨andaren inte ska f˚a k¨anslan av att saker st˚ar still.

6.2.4 Relevans

Svarsdeltagarna hade innan testet f˚att kort information av vad syftet med hemsidan var. Efter avklarat test visar resultatet att anv¨andarna tyckte hemsidan inneh¨oll relevant in-formation och att det de fick det som utlovades.

6.2.5 Flexibilitet

Enk¨atsvaren avseende detta kriterie visar att anv¨andarna ans˚ag att applikationen m¨otte dem p˚a deras respektive expertisniv˚a. Anv¨andarna fick m¨ojligheten att f˚a en guidad rund-tur av applikationen av systemet sj¨alv men hade ¨aven m¨ojlighet att skippa detta i det fall de ans˚ag att uppgiften var f¨or l¨att.

Sammanfattningsvis, v˚ara resultat visar att man kan uppn˚a en betydande grad av anv¨andbarhet genom att kombinera denna typ av applikation med design patterns som implementerar Nielsens kriterier[10] f¨or att uppn˚a anv¨andbarhet. D¨armed har jag besvarat b˚ade RQ1 och RQ2. Det ¨ar dock viktigt att notera att jag i denna studie var tvungna att f¨orh˚alla sig till endast ett f˚atal kriterier inom omr˚adet anv¨andbarhet. Med mer tid hade denna studie kunnat ut¨okas p˚a s˚a s¨att att ytterligare kriterier hade kunnat beaktats, och p˚a s˚a vis uppn˚att h¨ogre anv¨andbarhet hos min prototyp.

7

Slutsatser och vidare forskning

Webbutveckling i dagens l¨age ¨ar stundtals ett komplicerat omr˚ade och p˚a vissa s¨att till och med mer komplicerat ¨an andra omr˚aden av applikationsutveckling. Webbutveckling ¨

ar ett omr˚ade i st¨andig f¨or¨andring och verktyg som idag ¨ar nya kan imorgon anses vara f¨or˚aldrade. Detta g¨or det s˚aledes sv˚art inte bara f¨or nyb¨orjare inom webbutveckling utan ¨

aven f¨or den vana utvecklaren eftersom denna m˚aste h˚alla sig uppdaterad g¨allande nya trender. Ovanst˚aende argument motiverade mig till att unders¨oka om det var m¨ojligt att skapa ett anv¨andarv¨anligt verktyg som hj¨alper ovann¨amnda grupper att g¨ora denna del av webbutvecklingsprocess enklare genom att f¨oresl˚a en samling verktyg samt informera kring dess vara eller inte vara. De slutsatser som kan dras fr˚an denna uppsats ¨ar att det ¨

ar m¨ojligt att utveckla ett anv¨andarv¨anligt verktyg som hj¨alper en utvecklare att v¨alja en samling av ramverk och bibliotek f¨or ett projekt inom webbutveckling. Det ¨ar dock viktigt att framh˚alla att det endast ¨ar en prototyp som utvecklats i denna studie; en fullskalig implementation ¨ar ett intressant ¨oppet problem. Ett annat intressant ¨oppet problem ¨ar att ytterligare validera v˚ara initiala resultat om anv¨andbarheten hos v˚ar prototyp med en st¨orre antal testpersoner.

Referenser

[1] Embedded javascript templating. https://ejs.co//, Last accessed on 2019-02-10. [2] Grant Blank and Bianca C Reisdorf. The participatory web: A user perspective on

web 2.0. Information, Communication & Society, 15(4):537–554, 2012. [3] Guy Harrison. Next Generation Databases. Apress, 2015.

[4] ISO. Ergonomics of human-system interaction — part 11: Usability: Definitions and concepts. 2018.

[5] Rani Kafka, Peter. Molla. 2017 was the year digital ad spending finally beat tv. https://www.recode.net/2017/12/4/16733460/2017-digital-ad-spend-advertising-beat-tv/, Last accessed on 2019-01-15.

[6] A. Leff and J. T. Rayfield. Web-application development using the mo-del/view/controller design pattern. In Proceedings Fifth IEEE International Enter-prise Distributed Object Computing Conference, pages 118–127, Sep. 2001.

[7] Rensis Likert. A technique for the measurement of attitudes. New York: The Science Press, 1932.

[8] Merriam-Webster. Search word: framework. https://https://www.merriam-webster.com/dictionary/framework/, Last accessed on 2019-01-14.

[9] Jakob Nielsen. 10 usability heuristics for user interface design, 1994.

[10] Jakob Nielsen. Designing Web Usability: The Practice of Simplicity. New Riders Publishing, Thousand Oaks, CA, USA, 1999.

[11] Jakob Nielsen. Novice vs. expert users, 2000.

[12] Jakob Nielsen. Usability 101: Introduction to usability, 2003.

[13] Jakob Nielsen. Powers of 10: Time scales in user experience, 2010. https://www.nngroup.com/articles/website-response-times/, Last accessed on 2019-01-14.

[14] Jakob Nielsen and Thomas K. Landauer. A mathematical model of the finding of usability problems. In Proceedings of the INTERACT ’93 and CHI ’93 Conference on Human Factors in Computing Systems, CHI ’93, pages 206–213, New York, NY, USA, 1993. ACM.

[15] Jakob Nielsen and Marie Tahir. Homepage Usability : 50 websites deconstructed. New Riders Publishing, 2001.

[16] Jay F. Nunamaker, Jr., Minder Chen, and Titus D. M. Purdin. Systems development in information systems research. J. Manage. Inf. Syst., 7(3):89–106, October 1990. [17] B.J Oates. Researching information systems and computing. Sage Publications LTD,

[18] Chris J. Pilgrim. Improving the usability of web 2.0 applications. In Proceedings of the Nineteenth ACM Conference on Hypertext and Hypermedia, HT ’08, pages 239–240, New York, NY, USA, 2008. ACM.

[19] Shelley Powers. Learning Node, 2nd Edition. O’Reilly Media, Inc, 2016.

[20] Leonard Richardson, Mike Amundsen, and Sam Ruby. RESTful Web APIs. O’Reilly Media, Inc., 2013.

[21] Wikipedia contributors. Client–server model — Wikipedia, the free encyclope-dia. https://en.wikipedia.org/w/index.php?title=Client2019. [Online; accessed 3-February-2019].