En jämförelse av front-end ramverk för utveckling av responsiva webbsidor

Transkript

1 Vedran Lipovac En jämförelse av front-end ramverk för utveckling av responsiva webbsidor A comparison of front-end frameworks for developing responsive websites Informatik C-uppsats Termin: Handledare: VT-17 Peter Bellström

2 Abstract Antalet personer som besöker hemsidor med sina smartphones har ökat under de senaste åren. Enligt statistik från StatCounter(StatCounter 2016a) så gick 2016 antalet användare som besöker hemsidor med sina smartphones om användarna för stationära datorer. Det är därför idag viktigt att som webbutvecklare utveckla responsiva webbsidor. Man kan använda ramverk för responsiv webbutveckling men det finns så många att det kan vara svårt att veta vilket man bör välja. För att utvärdera ramverken används metoden experiment eftersom det passar undersökningens mål bra. Syftet med uppsatsen är att rekommendera utvecklare ett ramverk utifrån kriterier så som popularitet, stöd, prestanda i form av renderingstid och antal http-begäran samt hur bra dokumentationen för ramverken är. Resultatet visar att både Foundation samt Bootstrap fick samma poäng för renderingstid, antal http-begärande samt dokumentationen. Rekommendationen blev trots detta Bootstrap då detta ramverket var populärare samt hade ett större stöd.

3 Innehållsförteckning 1.Introduktion Syfte Undersökningsfråga Målgrupp Avgränsningar Begreppsbeskrivning Bakgrund Responsiv webbdesign Flexibel Grid-layout Flexibla bilder Media Queries Ramverk Front-end ramverk Front-end & Back-end Front-end Back-end Tidigare uppsatser & forskning Tidigare forskning Tidigare uppsatser Metod Metoddiskussion Första urvalet Datainsamling första urvalet Andra urvalet Datainsamling andra urvalet Bedömningskriterier Datainsamling Teknisk beskrivning Mjukvara Hårdvara Verktyg Installation av ramverk Webbapplikationerna Resultat -- urvalsprocessen Resultat första urvalet Resultat andra urvalet Resultat -- implementation och dokumentation Renderingstid HTTP-Begäran Dokumentation Sammanställning av resultat Analys Bootstrap Foundation SemanticUI Slutsatser Metodologiska reflektioner Framtida arbeten Referenslista Bilagor...34

4 1. Introduktion Antalet personer som besöker hemsidor med sina smartphones har ökat under de senaste åren. Enligt en rapport från StatCounter (StatCounter 2016a) så gick 2016 antalet mobila-enheter om de stationära datorerna i antal besökare av webbsidor i världen. I rapporten visas att stationära datorer erhöll 48,7% av besökarna medans de mobila enheterna var 51.3%. Även Google's sökmotor har optimerats att ge fördel till de webbsidor som förutom stationära datorer är anpassade till mobila-enheter(google 2015). Responsiva webbdesign är därför en viktig faktor när man idag utvecklar en webbsida då en stor andel användare idag använder sina telefoner eller surfplattor för att surfa på webben. Att som webbutvecklare utveckla sidor responsiva är därför viktigt. Det finns ett flertal sätt att utveckla responsiva webbsidor på. Det går bland annat att direkt koda i HTML, CSS och JavaScript. Ett annat alternativ för att utveckla responsiva webbsidor är att använda ramverk. Ramverk är ett bibliotek med funktioner som gör det lättare för dig som utvecklare att skapa en responsiv webbsida snabbare. En nackdel med ramverk är att du inte har kontroll över all kod och kan därför vara svårare att felsöka än om man kodar direkt med HTML, CSS och JavaScript. Det är därför extra viktigt att välja rätt ramverk som är beprövat och har bra support. Anledningen till att jag valt att göra en jämförelse av ramverk för responsiv webbdesign är för att de finns många ramverk att välja bland idag och det kan därför vara svårt att veta vilket som passar webbutvecklare best. Har personer inte tidigare använt sig av de olika ramverken kan det vara svårt att välja det bästa för den typen av arbete du gör. Syftet med uppsatsen är att försöka hjälpa vid val mellan olika responsiva ramverk genom att jämföra några olika ramverken samt ge rekommendationer för vilket av ramverken som är att rekommendera Syfte Syftet med arbetet är att jämföra olika ramverk för front-end utveckling av responsiva webbsidor samt rekommendera de ramverket som ger bäst resultat utifrån bedömningskriterierna. Undersökningfrågan är viktiga då de flesta utvecklare idag använder sig av ett eller annat typ av ramverk för att utveckla responsiva webbsidor. Detta är bra och även ett enklare sätt att skapa responsiva webbsidor jämfört med att koda direkt i CSS och HTML. Men det finns ett flertal ramverk att välja mellan och att välja ett som passar utvecklaren bäst är inte alltid det enklaste Undersökningsfråga Vilket av ramverken rekommenderas för att utveckla responsiva webbsidor? 1.3. Målgrupp Den målgruppen som valts är framförallt webbutvecklare som redan använder sig utav ett responsivt front-end ramverk men också de webbutvecklare som aldrig tidigare använt sig av dessa ramverk tidigare och därför kan behöva hjälp att välja Avgränsningar En avgränsning som bland annat kommer att göras är att det inte kommer att finnas några ramverk för hybridapplikationer som jämförs i detta arbete. Det kommer enbart att studeras rena så kallade responsiva front-end ramverk. 1

5 En annan avgränsning som kommer göras är att ändringar i de filer som ramverket är uppbyggt av inte kommer att ske. Manipulation av dessa filer är inte det som ramverken i första han är skapade för utan ramverken kommer endast att användas i sitt standardutförande. Utseendet på ramverken är olika. Detta kan ha en stor betydelse när man väljer ramverk men kommer dock inte testas i denna uppsats. Detta då resurser för att testa alla delar av ramverken inte finns tillgängliga men kan vara bra att ha i åtanke när man väljer ramverk för att utveckla responsiva ramverk. Att inte utföra experiment på både stationär dator med Apples OS samt Windows operativsystem. Samt de mobila-enheterna med både IOS samt Android som operativsystem då de skulle täcka den största majoriteten av användare(statcounter 2017b). Men av anledningen att resurser som tid samt hårdvara/mjukvara inte finns tillgänglig så har jag begränsat mig och kommer inte att använda Apples OS för stationära datorer eller IOS för mobila enheter Begreppsbeskrivning HTML Html står för HyperText Markup Language och är en standard enligt World Wide Web Consortium som är till för att beskriva strukturen på en webbsida(mozilla Developer Network 2017a). CSS Css står för Cascading Style Sheets och är en standard enligt World Wide Web Consortium och är till för att beskriva presentationen på en webbsida(mozilla Developer Network 2017b). JavaScript JavaScript är ett programmeringsspråk på klientsidan som används för att i interaktion med användaren skapa dynamiska sidor(mozilla Developer Network 2017c). Viewport Är den delen som användaren ser av webbsidan på sin skärm. Viewporten är exempelvis mindre på en enhet med mindre skärm(mozilla Developer Network 2017d). Media Types Är en äldre CSS egenskap som frågar webbläsaren vilken media typ den är. Detta kan exempelvis vara en skärm eller en skrivare(w3.org 2017). Media Queries Är en CSS egenskap som hjälper till att skapa responsiva webbsidor genom att låta utvecklaren ändra presentationen på webbsidan, exempelvis beroende vilken skärmbredd användaren har. (Mozilla Developer Network 2017e) Grid-layout En grid-layout är ett verktyg i CSS för att dela upp delar av en webbsida i rader samt kolumner. Den kan exempelvis användas för att dela upp layouten av webbsidan i sektioner eller definiera delar av sidans innehåll i form av storlek eller position(mozilla Developer Network 2017i). Ramverk Ramverk är ett bibliotek av funktioner som kan hjälpa utvecklaren att spara tid och ibland även hjälpa till att göra koden stabilare. Detta genom att ha färdiga, oftast väl beprövade kod-delar som utvecklaren då genom metodanrop kan instansiera(mozilla Developer Network 2017f). 2

6 Front-end ramverk Är ramverk som då oftast består av CSS och/eller JavaScript kod. Det som kännetecknar ett front-end ramverk från alla andra ramverk är just de att de använder sig av språk som exekveras på klientsidan(2.2 front-end & back-end). Responsiv webbdesign Kan beskrivas som att designen ska vara uppbyggd så att den anpassar utseendet beroende på vilken enhet du använder. Dessa enheter kan då exempelvis vara en mobil, surfplatta eller en stationär dator(marcotte 2011). Exempel på hur detta kan se ut visas i figur 1. Figur 1. Exempelbild på hur responsiv webbdesign kan se ut på olika enheter Källa: Författare 3

7 2. Bakgrund I detta kapitel beskrivs den tekniska bakgrunden samt teorin för uppsatsen Responsiv webbdesign Att kalla en design responsiv kan beskrivas på ett flertal olika sätt. Mozille Developer Network (MDN) beskriver en responsiv design såhär: Responsive web apps use technologies like media queries and viewport to make sure that their UIs will fit any form factor: desktop, mobile, tablet, or whatever comes next. (Mozilla Developer Network 2017g). Andra specificerar mer exakt vad de tycker att en responsiv design innebär. Ethan Marcotte (2011) och Kim Bohyun (2013) nämner framförallt tre saker som de menar är till grund för att skapa en responsiv design. Dessa tre är: Flexibel grid-layout Flexibla bilder och annan media Media Queries från standarden CSS Flexibel Grid-layout Ethan Marcotte (Marcotte 2011) beskriver i sin bok att man på webben inte har ett papper där man kan rita upp sina element i olika kolumner och rader som man kan för exempelvis grafisk design för tidningar. Han beskriver istället att en webbutvecklares canvas är webbläsaren vilket inte är en fast storlek utan ändras beroende på skärmupplösning och om användaren har en mobil, surfplatta eller exempelvis en stationär dator. För att skapa en flexibel grid-layout så behöver utvecklaren istället för som tidigare i webbdesign använda sig av pixlar som är en absolut enhet för att sätta storleken nu använda sig av en relativ enhet som procent. Detta gör att det som tidigare var en fixerad layout nu ändras beroende på din skärmstorlek(kim, 2013) Flexibla bilder Att skapa bilder som är flexibla är inte svårare än att skapa en flexibel grid-layout. Det man i detta fall behöver göra är att lägga bilden i en flexibel container samt använda sig av CSSegenskapen max-width. Denna egenskapen kommer att göra så att bilden inte flyter över containern den är i och kommer på så sätt att skalas i storlek beroende på containerns storlek(marcotte 2011). CSS egenskapen stöds dock inte av vissa äldre webbläsare som exempelvis Internet Explorer 6 och lägre. Detta kan vara en bra sak att ha i åtanke när man försöker att skapa responsiva bilder Media Queries Är en CSS egenskap som är utvecklad från CSS2 egenskapen media types. Denna egenskap hjälpte webbläsaren att skapa olika typer av utformningar beroende på vilken enhet du satt på genom att fråga vilken media typ den är. Detta kan exempelvis vara en skrivare eller en skärm. (W3.org 2017). När CSS3 standarden kom ut 2014 skapades media queries baserat på idén av media types. Denna CSS-egenskapen kan användas för att hämta information om enheten som använder den. Exempel på de saker som en media query kan hämta information om är: Bredd & Höjd av viewport:en Bredd & Höjd av enheten 4

8 Orientering (Om mobilen eller surfplattan är orienterad vertikalt eller horisontellt) Upplösning Med hjälp av dessa kan man ha olika CSS egenskaper för olika media queries. Alltså kan man utifrån olika typer av enheter ändra storleken på element, färg, test-storlek, mm(mozilla Developer Network 2017e). Ethan Marcotte beskriver att varje gång du startar upp en webbsida så frågar media query'n webbläsaren två saker. Det ena är vilken media typ (härstammar från CSS2 media types) samt direkt efter kommer själva frågan som kan delas upp i två delar. Den ena är namnet av egenskapen exempelvis min-width. Den andra är värdet exempelvis 1024px. Frågan blir då i detta fallet i parentes: (min-width: 1024px). Om denna fråga besvaras som sann så kommer webbläsaren att applicera de CSS-egenskaper som den media query'n innehåller(marcotte 2011). Exempel på hur detta kan se ut visas i figur 2. Figur 2. Exempelbild på hur en media query kan se ut Källa: Författare 2.2. Ramverk Ramverk kan beskrivas som ett bibliotek av funktioner som kan hjälpa utvecklare genom att man med hjälp av metodanrop kan anropa kod i biblioteket och på så vis få tillgång till olika funktioner som ramverket har. Fördelarna med detta är att eftersom koden oftast använts av flertal användare tidigare och körts flertal gånger tidigare så är oftast koden stabil samt väl beprövad. Detta leder då till att de delar som du använder av ramverket redan är stabilt och testat av tidigare användare av ramverket(mozilla Developer Network 2017f ) Front-end ramverk Ett ramverk som då klassas som front-end brukar beskrivas med ett flertal olika namn för samma sak. De kan bland annat kallas för CSS-ramverk, HTML-ramverk, Front-end ramverk eller responsiva ramverk. Syftet med dessa ramverk är framförallt att underlätta för utvecklare vid skapande av responsiva webbsidor. De är oftast uppbyggda av olika metoder av CSS och/eller JavaScript-kod. Exempel på hur denna kod kan se ut i CSS visas i figur 3. Figur 3. Exempel på CSS metod i front-end ramverk Källa: Författare 5

9 Dessa metoder anropas oftast genom metodanrop i HTML-koden i form av specifika namn i taggar. På grund av detta har ramverken ibland kallats för HTML-ramverk. Exempel på hur dessa anrop kan se ut i HTML-koden visas i figur 4. Figur 4. Exempel på HTML-tag som anropar färdig metod i front-end ramverk Källa: Författare Anropen i HTML-koden aktiverar då metoden i CSS / JavaScript-koden som sedan bygger den funktionaliteten eller utseendet som metoden innehåller. Att istället skapa all denna funktionaliteten själv blir därför mer för utvecklaren. Det som är nackdelen med att använda sig av ramverk istället för att skapa funktionaliteten samt utseendet själv är då att man är till viss del är begränsad i anpassningen då funktionaliteten och utseendet redan är förutbestämt. Där emot är då den stora fördelen att man sparar tid men fortfarande får en responsiv webbsida som fungerar på mobila enheter(hernández-nieto et al 2015) Front-end & Back-end När man skapar en webbapplikation finns det två sidor där kod renderas. Dessa är antingen på klient-sidan(front-end) eller på server-sidan(back-end). De flesta av webbsidorna idag använder sig av båda delarna(codeconquest 2017). För exempelbild se figur Front-end Det som kännetecknar front-end är att koden som exekveras gör detta på klient-sidan. Detta betyder att koden skickas till användaren och körs på användarens egen dator, oftast i webbläsaren. Exempelvis är JavaScript ett front-end script språk eftersom de körs i användarens webbläsare efter att webbsidan laddats in. I front-end räknas även HTML och CSS trots att de inte är programmeringsspråk i sig så körs de på klient-sidan(codeconquest 2017) Back-end Kännetecknas genom att koden till skillnad från front-end exekveras på server-sidan. Vad detta betyder är att innan front-end kod exekveras så körs all back-end kod på server-sidan först. Det finns ett flertal programmeringsspråk som är så kallade server-side programmeringsspråk. Det vanligaste idag är PHP och Ruby on Rails(CodeConquest 2017). Figur 5. Front-end & Back-end Källa: Författare 6

10 2.4. Tidigare uppsatser & forskning Det var svårt att hitta forskning om just jämförandet och utvärdering av front-end ramverk. Anledningen kan vara den att de helt enkelt inte finns så mycket forskning kring området eller att front-end ramverk brukar benämnas med ett flertal olika namn. CSS-ramverk, html-ramverk, front-end ramverk, är bara några av de namn som används för att beskriva responsiva ramverk. Det finns däremot en del forskning om bland annat back-end ramverk samt en del information om jämförelser av andra ramverk så som utvärdering av ramverk för hybridapplikationer. Denna tidigare forskning beskrivs nedan samt jämförs med denna uppsatsens syfte för att förklara vart i ämnet som uppsatsen passar in. Det finns även beskrivningar av liknande uppsatser och en beskrivning av hur dessa skiljer sig samt i vilka aspekter den liknar denna Tidigare forskning Dirk Riehle (2000) har skrivit en doktorsavhandling med titeln Framework Design: A Role Modeling Approach. Avhandlingen är framförallt fokuserad på the role model approach vilket han menar hjälper utvecklaren att lära sig, designa samt använda ramverket. Han förklarar också fördelarna och nackdelarna med användandet av ramverk. Han menar på att ramverk hjälper till att öka produktiviteten och kortar ner tiden från utveckling till färdig produkt. Detta framförallt genom att ha en bra design av koden samt att återanvända kod. Han beskriver dock att ramverk kan vara svåra att lära sig. De kan även vara svåra att skapa och kan kräva flera iterationer innan ramverket blir bra. Han menar att ramverk kan kosta på ett eller annat sätt. Antingen genom att man betalar för de eller genom den tid de tar för utvecklare att lära sig ramverket. Han påpekar dock att kostnaderna oftast är värd de resurser som man initialt lagt på ramverken då produktiviteten ökar samt tiden för utveckling minskar(riehle 2000). Zervas et al (2014) har skrivit en artikel där de försöker lösa problemet med att kunna använda ett flertal olika plattformar i virtuella laboratorier. De diskuterar bland annat för- och nackdelar med nativ-applikationer, hybrid-applikationer samt webbapplikationer. De beskriver i mer detalj fördelarna med en webbapplikation och går därefter in och gör en jämförelse av några responsiva ramverk. I likhet med detta arbete så jämförs responsiva ramverk men ändamålet är annorlunda då de har ett annat syfte och en annan användning för ramverken. De använder bland annat i likhet med detta arbete bedömningskriterier så som dokumentation samt stöd(community support) för de olika ramverken. Lei et al (2014) har gjort en jämförelse samt utvärdering mellan olika webbutvecklingsspråk för back-end. Mer specifikt har de gjort en jämförelse där de mätte prestanda mellan språken PHP, Python och Node.JS. I likhet med detta arbetet har de utvärderat och gjort en jämförelse av teknologier för webbutveckling. Det som dock skiljer detta arbete åt är för det första att de jämfört just programmeringsspråk för back-end. Till skillnad från detta arbetet där ramverken har samma front-end programmeringsspråk i grunden och studien istället fokuserar på jämförandet av just ramverken. Den andra skillnaden är att eftersom deras utvärdering är fokuserat på back-end programmeringsspråk blir därför också deras bedömningskriterier mer inställda på prestanda för back-end så som svarstider. Heitkötter et al (2012) har skrivit en artikel där de tog fram ett antal kriterier för att jämföra och utvärdera ramverk för hybridapplikationer. I sin artikel tar de också upp fördelarna och nackdelarna med att använda en ren webbapplikation istället för en hybridapplikation. I utvärderingen beskrives några positiva aspekter med en webbapplikation är att ramverken ofta är gratis med undantag för några Javascript ramverk. Andra kriterier som de skriver om i sin artikel skiljer sig dock mot mitt arbete då de fokuserar på funktionalitet som en hybridapplikation har. Exempelvis användande av kamera och gyroskop vilket inte finns för rena webbapplikationer och 7

11 därför inte heller finns med i de ramverken som kommer jämföras. De tar även upp vikten av applikationens hastighet och beskriver även hastigheten för rena webbapplikationer där webbläsarna numera är prestandaoptimerade Tidigare uppsatser Tidigare uppsatser inom mitt område är gjort av bland annat två personer som hittades och skulle vara bra att ta upp för att förklara skillnaden i detta arbete jämfört med deras. Den ena är från Alexander Hansson(Hansson 2015). Hans uppsats är lik min i den mån att han jämför olika ramverk. Hans arbete handlar dock mer om hybridapplikationer där min handlar mer om rena webbsidor som även ska fungera på mobila enheter. Hans målgrupp är även den annorlunda än min i den meningen att han endast fokuserar på webbutvecklare som saknar tidigare kompetens inom ramverken. Detta görs dock inte i denna uppsats utan den fokuserar om tidigare nämnt framförallt på webbutvecklare som redan använt eller använder ett responsivt front-end ramverk men även då på webbutvecklare som inte har någon erfarenhet och som då kan få hjälp vid valet. Ett annat arbete som gjorts på området är Emma Johanssons utvärdering av responsiva front-end ramverk och renderingstekniker(johansson 2016). Där i likhet med mitt arbete handlar om fontend ramverk. Men den forskningen Emma gjort handlar mer om renderingstekniker och svarstider så frågeställningen är om val av front-end ramverk har någon betydelse eller ej. Den handlar om svarstiderna har en större inverkan. Alltså om ramverket hämtar data från en databas eller ej och hur detta påverkar applikationens svarstider. Där denna uppsats skiljer sig från hennes är i de att den istället jämför ramverken mot varandra. 8

12 3. Metod 3.1. Metoddiskussion För att mäta några av bedömningskriterierna så som renderingstid samt HTTP-begäran kommer en webbapplikation behöva skapas för de ramverk som kommer jämföras. Detta för att efterlikna använde av ramverken på ett så verklighetsbaserad sätt som möjligt. En närmare beskrivning av hur webbapplikationerna kommer att vara utformade beskrivs i kapitel 4.5 Webbapplikationerna. Den metoden som valts att användas är experiment. Anledningen till detta är då att metoden passar undersökning av ramverken bra för att på ett så säkert sätt utan påverkan av andra faktorer så som andra personers åsikter kan ge en bra uppfattning av vilket av ramverken som är best baserat på de kriterier som finns. Enligt Patel & Davidson (2011 s ) så måste de faktorer som kan ha en inverkan på resultatet, alltså en situationsfaktor samt individfaktor att försöka förhindras så gott det går för att uppnå ett vetenskapligt resultat. För att uppnå detta kommer det i experimenten inte användas flera användare då detta endast kan leda till ett varierat resultat. Webbläsarens lagrande av cacheminne kommer då också att stängas av för att undvika att filer samt information som är nödvändiga vid anrop av webbsidan redans finns sparade och som därmed kan påverka resultatet av experimentet. En annan metod som skulle kunna användas är att man gör en fallstudie. Patel & Davidson (2011 s. 56) förklarar att den fallstudie passar sig bra vid studier om en process eller en förändring. Denna förändringen kan då exempelvis vara vid byte av ramverk. Dock beskrivs också en fallstudie som bra vid studie om ett företag eller liknande. Då detta arbete inte är på uppdrag av en specifik organisation eller ett företag så är en fallstudie inte det bästa alternativet. En annan anledning till att en fallstudie inte valdes var på grund utav att några av de bedömningskriterierna som valts inte går att bedöma genom intervjuer eller enkäter för datainsamling Första urvalet De ramverk som ska vara med i urvalsprocessen är baserade på ett antal kriterier. Dessa kriterier är baserade på att försöka få ut de ramverken som bäst lämpas att jämföras med varandra. Detta för att försöka undvika att något av ramverken som slutligen kommer att jämföras får någon fördel eller har någon nackdel. De kriterier som tagits fram är följande: Kriterier urval ett(u1) a) Ramverket ska vara gratis b) Ramverket ska vara öppen källkod c) Ramverket ska vara responsivt d) Storlek på ramverket(css samt JavaScript-filer) Om ramverket är gratis kommer att kontrolleras genom att besöka de respektive ramverkens webbsida och där hitta information om ramverket har en licens och i så fall vilken. Anledningen till att ramverken ska vara gratis är för att de finns populära responsiva front-end ramverken som är gratis och därmed är de flesta som används idag gratis. Vad som menas med att de är gratis är att de ska uppfylla kraven för MIT licensen eller liknande för att man fritt ska få använda och publicera ramverket. MIT Licensen som flertal av de ramverken som kommer att testas har beskriver att alla personer ska kunna få tillgång till mjukvaran samt dess tillhörande dokumentation gratis. Den ska även få kopieras, modifieras, publiceras samt distribueras fritt(opensource.org 2007). 9

13 Om ramverken uppfyller kravet för öppen källkod kommer att kontrolleras vid nedladdning av ramverken samt via de respektive ramverkens hemsida. Öppen källkod är enligt opensource.org inte endast att man får tillgång till källkoden utan måste följa 10 kriterier för att få definitionen opensource. Några av dessa kriterier för öppen källkod är: Gratis distribution Licensen ska inte hindra någon part från att sälja eller ge ut mjukvaran som komponent av en annan mjukvara. Källkoden Koden som distribueras måste finnas tillgänglig i såväl kompileras samt icke-kompilerad form. Källkoden måste finnas tillgänglig gärna genom en gratis nedladdning via internet. Nödvändiga mellanhänder som preprocessor eller översättare är inte tillåtet. Alla de punkterna som är nödvändiga för att definieras som öppen källkod finns på opensource.org(opensouce.org 2007). Öppen källkod kan då ha ett flertal fördelar då ett stort antal personer använt koden och på så sätt kan ge förändringsförslag och påpeka brister i koden. Katherine Noyes gjorde 2010 en artikel där hon beskrev 10 anledningar till varför open source är bra. Hon beskriver bland annat att att säkerheten i programvaran kan bli bättre när man har öppen källkod. Detta för att fler personer som testar och använder programvaran kommer då göra programvaran säkrare. Hon nämner också att programvara inte alltid passar alla utan att man med öppen källkod kan ladda ner programvaran samt modifiera den för att passa sitt eget ändamål bättre(noynes, K. 2010). Flertalet av de responsiva ramverken som finns idag har därför öppen källkod och passar då bra att ha som ett krav i denna uppsatsen. Detta går också hand i hand med att ramverken ska vara gratis enligt krav A. Responsiviteten på ramverken kommer att testas genom att kolla igenom CSS-koden samt dokumentationen för respektive ramverk och där med se om varje ramverk har de tre huvuddelarna som beskrivs som nödvändiga för att skapa en responsiv design enligt Marcotte (2011) och Kim (2013). Dessa är då en flexibel grid-layout, flexibla bilder & media samt användandet av media-queries. Dessa kommer att kontrolleras för varje ramverk genom att granska dokumentationen och se om ramverken har de kriterier som efterfrågas enligt Marcotte och Kim. Att kontrollera att dessa ramverk verkligen är responsiva är viktigt då fördelen med dessa ramverk är att man snabbt kan skapa responsiva webbsidor(hernández-nieto et al 2015). Huvudsyftet med ett responsivt ramverk är då just att vara responsivt och därmed viktigt att se om ramverken verkligen uppfyller detta kriteriet. Storleken på ramverkens CSS samt JavaScript-filer kommer att kontrolleras efter de att en standard version av de utvalda ramverken har laddats ned. Ramverkets storlek kan ha en inverkan på webbsidan beroende på hur stort och komplext ramverket är. Storleken på dessa filer behöver alltid laddas in oavsett om du använder alla funktioner i filerna eller ej. Därför kan ramverkens storlek påverka valet av ramverk då du eventuellt inte behöver alla den funktionaliteten som vissa ramverk erbjuder och istället för att användaren får ladda ner större filen än nödvändigt vid besök av webbplatsen. För att undvika att ramverk med lite funktionalitet får negativa eller positiva värden vid utvärderingen. Exempelvis en orättvis bedömning på antalet HTTP begärande så kommer storleken på ramverken vid X urvalet ha ett minimum samt maximum krav. Detta kommer att kontrolleras efter att de ramverken som ska bedömas laddats ned och där efter kontrollera storleken på de nedladdade CSS samt JavaScrips filerna. Detta för att utesluta att bilder, ikoner eller fonter räknas in i storleken på ramverken utan endast storleken på funktionaliteten. JavaScript samt CSS-filerna kommer att konverteras till minifierade versioner av de vanliga CSS och JavaScript-filerna. En.min fil är precis som den vanliga versionen av CSS filen bara minifierad. Alltså är denna filen mer komprimeras och inte anpassad för 10

14 redigering som de vanliga CSS filerna är. Konverteringen av CSS-filerna kommer ske genom webbverktyget CSS minifier(cssminifier.com 2017). Konverteringen av JavaScript-filerna kommer ske genom webbverktyget Javascript-minifier(javascript-minifier.com 2017). Gränsen som kommer att sättas är 30Kb för JavaScript samt 30Kb för CSS-filerna. Detta då de flesta ramverken som kallar sig för så kallade lättvikts-ramverk ligger under dessa gränser och som tidigare beskrivits hade skapat en orättvis bedömning vid den slutliga utvärderingen Datainsamling första urvalet Insamling av data för första urvalet kommer framförallt att ske genom att information hämtas från de olika ramverkens webbsidor. Information som om ramverket är gratis, open source samt om de verkligen är responsiva enligt de krav som Marcotte (2011) och Kim (2013) säger är nödvändiga för att kunna beskrivas som responsiva. kommer att hämtas från de respektive ramverkens webbsidor. Storleken på ramverkens CSS samt JS-filer kommer att kontrolleras efter nedladdning av ramverken. Efter datainsamlingen kommer data som samlats in att läggas upp i tabeller för att på så sätt få en lätt överskådlig bild av skillnaderna samt likheterna mellan den data som samlats in. Utifrån denna data kommer då ett antal av ramverken som uppfyller dessa krav bäst att gå vidare till andra urvalet Andra urvalet Det ramverken som går vidare efter urval ett kommer att gå vidare till urval två. I urval två kommer endast tre stycken ramverk att gå vidare och genomgå en jämförelse och utvärdering. Anledningen till att ett detta görs är att det inte finns möjlighet i form av tid att göra en webbapplikation för varje ramverk och därefter jämföra dessa. Ramverken kommer därför att väljas ut efter följande kriterier: Kriterier urval två(u2) a) Popularitet (Antal stjärnor på GitHub) b) Stöd (Antal resultat som uppkommer vid sökning av ramverket på Stackoverflow(Stackoverflow 2017) Populariteten av ramverken ska bedömas genom att se hur många stjärnor de respektive ramverken har på Github. Detta är en webbsida där webbutvecklare kan ladda upp sina projekt och hantera versioner och för att samarbeta med andra. Men de kan också användas till att publicera sina projekt. Projekten som exempelvis ramverken i mitt fall kan då få stjärnor från användare för att visa på att de gillade just de ramverket(github 2017). Genom detta kan man då skapa sig en uppfattning om vilka av ramverken som är populärast. Detta ger då en inblick i hur stor dess community är. Detta kan vara bra att ha i åtanke då ett populärt ramverk kommer vara väl beprövat av ett större antal personer och därmed kan vara stabilare men de kan också vara färre buggar då ett större antal personer har använt de. Stödet till ramverket kan vara en faktor i hur bra ramverket är. Detta kan vara till stor hjälp då du som användare av ramverken kan behöva leta upp problem du stöter på eller har egna frågor att ställa i exempelvis forum-trådar. För att mäta detta kommer jag att söka på antal lösta trådar vid sökning av respektive ramverk på webbsidan Stackoverflow (2017). En sökning där kommer visa antalet lösta trådar på Stackoverflow och på de sättet ge en förståelse över hur aktivt ramverkens community är. 11

15 Datainsamling andra urvalet Datainsamlingen kommer att ske genom att jag granskar informationen från sökningar av webbsidorna GitHub (2017) & Stackoverflow (2017) som är kriterier för ramverken. Jag kommer sedan att ta denna data och lägga upp i tabeller för att göra en bedömning av vilka ramverk som jag ska gå vidare med och göra en webbapplikation samt utvärdering på. De tre ramverken som uppfyller kriterierna bäst kommer sedan att gå vidare och jämföras mot varandra Bedömningskriterier Efter det andra urvalet kommer tre ramverk gå vidare för en jämförelse. En webbapplikation kommer skapas för varje ramverk som ska jämföras för att kunna bedöma krav A samt B. Dessa bedömningskriterier är till för att tillsammans skapa en helhet där man utifrån de enskilda kriterierna tillsammans ska kunna skapa sig en uppfattning av vilket av ramverken som är att rekommendera. Bedömningskriterierna är följande: Bedömningskriterier a) Renderingstid b) Antal HTTP-begäran c) Dokumentation, hur bra uppfyller dokumentationen IEEE's standard av vad en dokumentation bör innehålla(ieee Computer Society 2001). Renderingstider är den tid de tar för webbläsaren att bygga upp applikationen du ser. Renderingstider sker därför på klient-sidan och är skild från svarstider vilket är den tid de tar för servern att behandla en respons. För mer om klient-sida vs server-sidan se kapitel 2.3. Front-end & Back-end. Renderingstiden är högst beroende på av vilken webbläsare användaren använder då olika webbläsare har olika renderingsmotorer. Webbläsaren som kommer användas för varje enhet i testerna är Google Chrome som använder sig av renderingsmotorn Blink(Chromium.org 2013). Diskussionen om val av webbläsare för dessa tester finns i kapitel 4.1 Mjukvara där de diskuteras för varför just denna webbläsare valdes för jämförelsen av ramverken. Google gjorde ett experiment för att se hur användare reagerade vid långsammare laddande av sökresultaten. De visade sig att om sidan bara svarade mellan 100 och 400ms längre så minskade sökandet på Google med 0,2% - 0,6%. Google förklarar att även fast dessa nummer inte låter mycket så är de mycket för ett så stor och välkänd sökmotor som Google(Google.com 2009). Även Heitkötter et al (2012) som nämns i litteratur-kapitlet beskriver vikten av hastigheten på webbapplikationer. Av dessa anledningar kommer renderingstider att vara ett av bedömningskriterierna vid jämförelsen av ramverken. Detta kommer att mätas genom att för de mobila-enheterna använda mig av Google Chrome's Remote Debugging. Samt för testerna av de stationära enheterna Google Chrome's DevTools. Dessa verktyg beskrivs i detalj i kapitel 4.3 Verktyg. Antal HTTP-begäran som en webbläsare gör är beroende på hur många filer den använder sig av för att bygga upp webbsidan. Dessa filer är exempelvis alla de CSS, Javascript, HTML samt alla de bilder som sidan behöver för att byggas upp. HTTP-begäran är alltså den fråga som webbläsaren ställer till servern och ett respons är de svaret som webbläsaren får från serven. Webbsidans responsivitet kan försämras om i detta fallet ramverken hämtar många filer (Mozilla Developer Network 2017j). Av denna anledning kommer antalet HTTP-begäran vara en faktor vid jämförelsen av ramverken. Antalet HTTP-begäran som görs av webbläsaren för de filer som ramverket behöver kommer att ge en bild av hur många filer de respektive ramverken behöver för att bygga upp de funktioner som kommer att ingå för att skapa exempelsidan. Hur många HTTPbegäran exempelsidan gör för respektive ramverk kommer att kontrolleras för bedömningskriteriet A genom Google Chrome's DevTools för stationära-enhetern och Google Chrome's Remote Debugger för de mobila-enheterna. Dessa verktyg beskrivs i detalj i kapitel 4.3 Verktyg. 12

16 Om ramverken uppfyller standarden för mjukvarudokumentation kommer att kontrolleras genom att jämföra IEEEs minimum krav mot den dokumentation som respektive ramverk erbjuder. IEEE's standard för mjukvarudokumentation för användare kollar på strukturen samt informations-innehållet i den dokumentation som ramverken i detta fall erbjuder användaren. Standarden är till för såväl dokumentation för installation av mjukvaror men även dokumentation för användande av mjukvaror som i mitt fall ramverk. Dokumentationen ska enligt IEEE ses som ett minimum krav för användardokumentationen(ieee Computer Society 2001). Ett ramverks dokumentation kan vara viktig då den ska förklara och visa på hur man använder ramverket samt dess funktionalitet. Som tidigare nämnt i kapitel 2.4. Teori beskriver Dirk Riehle (2000) att ramverk initialt medför en kostnad som bland annat kan vara i form av resurser för att lära sig ramverket. Om då dokumentationen är väl beskriven och då uppfyller IEEEs minimum krav så kan detta reducera tiden som utvecklare behöver för att lära sig ramverket. Att istället ha ett ramverk utan någon dokumentation kan därför blir svårt att använda och lära sig. Av denna anledning så kommer dokumentationen vara ett av kriterierna vid jämförandet av ramverken Datainsamling Datainsamlingen för bedömningskriterierna A samt B kommer att ske genom att skriva en webbapplikation för de utvalda ramverken som sedan kommer att testas genom Google Chrome's DevTools för de stationära enheterna samt Google Chrome's Remote Debugging Android för de mobila-enheterna. För mer information se kapitel 4.3 Verktyg. Data kommer sedan att analyseras och läggas upp i tabellform för att på ett enkelt sätt få en överskådlig bild av resultaten från testerna. Datainsamling för bedömningskriterier C om dokumentationen kommer att läsas samt analyseras och genom detta jämföras mot hur väl dokumenterade ramverken är enligt IEEE Computer Society (2001)'s minimum krav för användardokumentation. 13

17 4. Teknisk beskrivning Webbapplikationerna för utvärderingen kommer att prövas på samma enheter samt samma mjukvara för varje ramverk. Mjukvara samt hårdvara kan ha en inverkan på resultatet av vissa tester som kommer genomföras och kommer därför att beskrivas noga. Testerna kommer också att utföras på samma enheter samt samma versioner av mjukvaran. Detta för att förhindra att något av ramverken får en fördel över något annat ramverk. Nedan kommer en beskrivning av både valet av mjukvara samt hårdvara och specifikation med exakta namn och versioner på de mjukvaror samt hårdvaror som kommer att användas i testerna. Anledningen till att det endast är Android samt Windows operativsystem som ingår är att Google chrome's Remote debugging som är de verktyget som kommer användas vid mätning av bedömningskriterierna A samt B endast för tillfället fungerar på Android. Det hade gått att utöka testerna genom att använda Apples egna webbläsare Safari som ytterligare en webbläsare för enheterna. Men detta valdes bort för att remote debugging med Safari kräver att version 6.0 eller nyare används. Dock är den senaste uppdaterade versionen för Windows 5.0 vilket betyder att utförandet av mätningarna för Safari hade krävt tillgång till en dator med Apples operativsystem vilket inte fanns tillgängligt i detta fall Mjukvara Den mjukvara som kommer att användas för testerna kommer att vara samma och ha samma version för varje ramverk som testas. Detta för att som tidigare nämnts inte någon av ramverken ska kunna få en fördel när testerna utförs. För att testerna ska kunna återupprepas och på så sätt kunna säkerställas kommer alla mjukvara samt dess versioner vid testtillfället att specificeras nedan. Hur webbläsaren tolkar koden den får kan vara olika. Exempelvis kan de vara olika renderingsmotorer i olika webbläsare. Det är därför viktigt att alla testerna utförs på samma versioner av webbläsare. Vissa äldre versioner av webbläsare saknar stöd för viss funktionalitet som dessa ramverk använder och ibland även saknar viktiga egenskaper för att skapa en responsiv webbsida. Internet explorer version 6 och under har till exempel inte stöd för CSS3 egenskapen media-queries vilket enligt Marcotte (2011) och Kim (2013) är en central del i skapandet av en responsiv design. Den webbläsare som då kommer att användas är Google Chrome. Anledningen till detta är att den är mest använda webbläsaren för mobilaenheter(statcounter 2016c). Eftersom de responsiva ramverkens huvudfunktion är att kunna skapa webbsidor som ser bra ut på flertal mobila-enheter så är de därför valet av webbläsare hamnade på den mest använda för mobila enheter, Google Chrome(StatCounter 2016c). Stationär dator Operativsystem: 64-bitars Windows 10 Home OS-Version: Google Chrome, Version (64-bit) Surfplatta Operativsystem: Android OS-Version: ("Lollipop") Webbläsare: Google Chrome, Version Mobil Operativsystem: Android OS-Version: ( KitKat ) 14

18 Webbläsare: Google Chrome, Version Hårdvara Testerna kommer att utföras på tre olika enheter. En stationär dator, en surfplatta samt en mobil. Det går att utföra testerna på antingen fysiska enheter så som en fysisk mobil eller surfplatta. Eller så går det att använda simulerade enheter. Bland annat har webbläsaren Google Chrome som testerna kommer utföras på en simulator där den simulerar storleken på skärmen för att få applikationen att visa sig som om den var på en faktiskt mobil-enhet. Detta är ett bra verktyg då du ska testa exempelvis funktionalitet. Problemet med en simulering är att den inte kan simulera prestandan på en fysisk-enhet. Av denna anledning så kommer mätning av kraven A samt B mätas på fysiska enheter. Hårdvaran för varje enheter beskrivs i detalj nedan. Stationär dator Skärmupplösning: 1920 x 1080px Processor: Intel(R) Core 3.4GHz (Överklockad till 4.2 GHz) Internminne(RAM): 8 GB Grafik-processor: AMD Radeon R9 200 Series 6 GB Surfplatta Google Nexus 10 (Wi-Fi only) Skärmupplösning: 2560 x 1600px Processor: 1.7GHz Cortex-A15 Internminne(RAM): 2 GB Grafik-processor: Mali-T604 Mobil Modellbeteckning: Samsung Galaxy Ace 4 G357FZ Skärmupplösning: 480 x 800px Processor: 1.2 Ghz Cortex-A53 Internminne(RAM): 1 GB Grafik-processor: Adreno Verktyg De verktyg som kommer att användas för mätningar av renderingstid samt antal http-begärande är Google Chrome's DevTools(Chrome.com 2017) för mätningar på den stationära datorn samt Google Chrome's remote debug(google.com 2017) för mobila enheter. Google Chromes remote debug är en funktion i Devtools som med hjälp av att ansluta en USB sladd mellan datorn och den mobila-enheten då kan mäta och felsöka genom den mobila-enhetens hårdvara. En representation av hur detta kan se ut på den stationära datorn visas i bilaga 2 genom en skärmdump. Det är genom detta verktyg som mätningar av renderingstid samt http-begärande kommer att utföras för att då använda de mobila-enheternas hårdvara i mätningarna Installation av ramverk Installation av ramverken kommer att ske genom att en standard-version av ramverken laddas ner från de respektive ramverkens webbsidor. Vad som menas med en standard-version är den version som ramverken själv rekommenderar utan tillägg. Detta av just den anledningen att testen går ut på att testa ramverken själv och inte deras tillägg som går att installera. Detta också för att ramverken ska få en så rättvis bedömning som möjligt utifrån deras egenskaper och inte med hjälp av tillägg eller tredjepart tillbehör. 15

19 En mapp kommer sedan att skapas för varje ramverk där själva applikationen kommer att ligga men också där ramverken tillhandahålls. Detta görs för att ramverken ska få en så rättvis bedömning som möjligt och att ingen av ramverken ska få någon sorts fördel Webbapplikationerna De webbapplikationerna som kommer skapas med hjälp av respektive ramverk är tänkt att efterlikna en informations-sida för exempelvis ett företag. Detta för att försöka simulera ramverkens användning i verkligheten. För exempelbild på strukturen se figur 6. De texter och den exempelinformation som kommer finnas på webbapplikationerna för ramverken kommer ha samma innehåll oavsett vilket ramverk som testas. Detta för att utesluta så många variabler som möjligt vid utförande av testerna. Strukturen på webbsidan kommer att skapas genom att efterlikna Mozilla Developer's beskrivning av hur de anser en typisk webbsida kan se ut. De beskriver att webbsidor kan och brukar se annorlunda ut men att de oftast innehåller till största del samma komponenter(mozilla Developer Network 2017h). Dessa komponenter är följande: Figur 6. Upplägg av struktur på webbapplikationerna. Källa: Författare Header Denna komponenten innehåller oftast en stor horisontell rubrik eller logotyp och brukar se likadan ut för varje sida av webbsidan som besöks. I de webbapplikationerna som kommer skapas kommer denna komponent att innehålla texten Exempel Företag som ska representera ett ett företags namn eller logotyp. Navigation bar Precis som i Header-komponenten ska navigations bar:en inte ändras beroende på vilken sida på webbplatsen man besöker. Detta för att inte skapa förvirring för användaren. Många webbdesigners lägger komponenten navigations bar i headern men Mozilla Developer(Mozilla Developer Network 2017h) anser inte detta vara ett krav utan beskriver istället att de kan vara en 16

20 fördel att separera de två komponenterna. I webbapplikationen som kommer skapas för att utföra testerna kommer denna komponent innehålla fyra meny-knappar. Page1, Page2, Page3 samt Page4. Detta för att försöka efterlikna en så verklig webbsida som möjligt. Main content Beskrivs som en stor yta i mitten av webbplatsen med den huvudsakliga informationen för webbsidan. Detta kan exempelvis vara bilder, video eller nyhetsartiklar. Denna delen av webbsidan är en av de komponenter som vanligen ändras beroende på vilken sida på webbplatsen man besöker(mozilla Developer Network 2017h). Denna komponent kommer i skapandet av webbapplikationen innehålla en några bilder som är gjorda responsiva med hjälp av ramverkens funktionalitet. Den kommer även innehålla exempeltext som kommer att vara likadan för varje ramverk som testas. Detta för att försöka använda ett flertal av de egenskaper som ramverken har att erbjuda och samtidigt försöka efterlikna hur en webbsida kan se ut för ett företag. Sidebar Denna komponenten beskrivs som en ett komplement till Main content-komponenten. Den kan exempelvis innehålla information som länkar och reklam(mozilla Developer Network 2017h). I denna komponenten kommer det att finnas en responsiv tabell med exempelinformation samt fyra stycken länkar. Informationen kommer att vara samma för varje ramverk som testas. Komponenterna Main content samt Sidebar kommer att läggas i en flexibel grid-layout. Detta för att de två sektionerna av webbapplikationen och ska bli responsiva. En flexibel grid-layout är ett krav för att skapa en responsiv design enligt Ethan Marcotte (2011) och Kim Bohyun (2013). För mer information se kapitel Flexibel Grid-layout. Footer Är oftast den nedersta delen på en webbapplikation. Denna komponent kan användas för bland annat information om hur man kan kontakta företaget, upphovsrätts information samt också ibland för genvägar till information som är populärt på webbapplikationen(mozilla Developer Network 2017h). För webbapplikationen som kommer skapas kommer dock denna komponenten endast innehålla upphovsrätts information. Källkoden för HTML strukturen som kommer användas kan hittas i bilaga 1. 17

21 5. Resultat -- urvalsprocessen Urvalsprocessen kommer att ske i två steg. Första urvalsprocessen är till för att fastställa att alla ramverken uppfyller de kriterierna som finns för första urvalet (U1). Dessa är att ramverken ska vara gratis, ha en öppen källkod, vara responsiva samt att storleken på ramverken inte är för litet då detta kan ge en fördel eller nackdel för några av ramverken i utvärderingen. Dessa kriterier är till för att tillsammans ge alla ramverken en så rättvis bedömning som möjligt. En mer detaljerad beskrivning av de olika kriterierna finns i kapitel 3.2 Första urvalet. Den andra urvalsprocessen (U2) är mer utformad för att skala ned antalet ramverk till ett fåtal som ska gå vidare till den slutliga utvärderingen. Detta för att möjligheten att utvärdera alla ramverk inte är möjligt med den tid som finns tillgänglig för denna uppsats. Den andra urvalsprocessen kommer därför att bedömas genom två kriterier vilka är ramverkens popularitet samt ramverkens stöd. De ramverk som då går vidare i utvärdering ett (U1) som då genom dessa kriterier ska bli endast 3. Detta för att som tidigare nämnt tiden att utvärdera för många ramverk inte finns Resultat första urvalet De ramverk som är utvalda att genomgå den första urvalsprocessen är hittade genom sökande på sökmotorn Google efter responsiva ramverk. Responsiva ramverk har som tidigare nämnts ett flertal olika benämningar. De som användes vid sökande av ramverken var HTML frameworks, CSS frameworks, responsiva frameworks samt front-end frameworks. Inspiration togs också av sidorna Designinstruct(Designinstruct.com 2013) samt Colorlib(Colorlib.com 2016). De som finns med på vissa sidor men inte tagit med har bland annat varit då de exempelvis är hybridapplikationer eller beta-versioner och där med inte passar in i en utvärdering av responsiva ramverk. Tabell 1. En tabellsammanställning av de ramverk som valdes ut för urval ett samt dess resultat Tabell 1 visar alla de ramverken som valdes för att genomgå första urvalet. De flesta ramverken har ligger under licensen MIT(Opensource.org 2017) vilket också betyder att de är både gratis samt open-source. Ramverkens storlek skiljer sig dock från varandra. Vissa har mindre CSS-filer och större JavaScript-filer. Medans andra har större CSS-filer men mindre JavaScript-filer. Vissa av 18

22 ramverken kallar sig själva för Light weight frameworks alltså lättvikts-ramverk. Detta för att de endast skapar en grund med hjälp av CSS ramverken som webbutvecklaren själv sedan får bygga vidare på. Detta betyder att de har små CSS/JavaScript filer eller ibland inte har med JavaScript filer alls. Några av dessa lättvikts-ramverk är Material, Baseguide, Siimple, Schema, Concise, Skeleton samt HTML5 Boilerplate vilket också är markerat med röd text där de inte uppfyller kriterierna för U1d och där med utesluts för andra urvalet(u2). Några av dessa ramverk är inte komprimerade vid nedladdning. Detta görs då som tidigare är beskrivet i kapitel 3.2 Första urvalet genom att skriva in den ominifierade koden på sidorna Cssminifier.com(Cssminifier.com 2017) för CSS och Javascript-minifier.com(javascriptminifier.com 2017) för JavaScript och sedan ladda ned de minifierade filerna och läsa av storleken. De ramverken som inte uppfyllde kriteriet för responsivitet (U1c) var Siimple, Schema, Skeleton samt HTML5 Boilderplate. De ramverken som då gick vidare till andra urvalet var: Bootstrap (Bootstrap 2017) Bulma (Bulma 2017) HTML KickStart (HTML KickStart 2017) UIkit (UIkit 2017) MetroUI (MetroUI 2017) Foundation (Foundation 2017) Kube (Kube 2017) SemanticUI (SemanticUI 2017) Cascade (Cascade 2017) 5.2. Resultat andra urvalet Antalet stjärnor för respektive ramverk hittades genom en sökning av ramverkens namn Github.com(Github 2017). Resultatet av sökningen visas i Tabell 2. Tabell 2. Ramverkens popularitet baserat på antal stjärnor på GiHub Sökningen visade att de ramverket som hade störst antal stjärnor var Bootstrap med 110,701 stjärnor. Detta med 75,839 mer stjärnor än SemanticUI som kom på andra plats. Skillnaden mellan SemanticUI på andra plats och Foundation på tredjeplats var betydligt mindre där de 19

23 endast skiljer ca 10,000 stjärnor. En representation av den totala summan i procent visas i form av ett cirkeldiagram i figur 7. Figur 7. Cirkeldiagram som representerar antal stjärnor i procent Sökningen på Stackoverflow(Stackoverflow 2017) för krav U2b gick till på de sätt att ramverkens namn användes vid sökningen. Resultatet av sökningen visas i Tabell 3. Tabell 3. Ramverkens stöd baserat på sökning av ramverkens namn på Stackoverflow. Sökningen på Stackoverflow(Stackoverflow, 2017). Visade att de ramverken som hade störst stöd var Bootstrap med 80,403 sökresultat. Följt av Foundation med 11,013 samt SemanticUI med 3,604 sökresultat. En representation av den totala summan i procent visas i form av ett cirkeldiagram i figur 8. 20

24 Figur 8. Cirkeldiagram som representerar resultat vid sökning av ramverken på Stackoverflow i procent Poängen som delas ut är den procent de respektive ramverken har av den totala summan. Detta gäller både antalet stjärnor på Github(Github 2017) men också resultatet från sökningen av stackoverflow(stackoverflow 2017). Anledningen till detta är att de ramverken som har ett större stöd samt är populärare ska få så poäng baserat på jämförelsen av de andra ramverken. Resultatet av den totala poängsumman för varje ramverk visas i Tabell 4. Tabell 4. Resultatet av poängsumman för andra urvalet Resultatet visar att de tre ramverken som fick flest poäng var Bootstrap, Foundation samt SemanticUI. Det är då dessa ramverk som går vidare till en utvärdering där de jämförs mot varandra genom att en webbapplikation skapas samt att de utvärderas enligt bedömningskriterierna renderingstid, antal HTTP begäran samt hur bra dokumentationen för ramverken är. 21

25 6. Resultat -- implementation och dokumentation Nedan kommer resultaten från experimentet presenteras. Poäng kommer att ges till de olika ramverken från 1-3 där 3 ges till de bäst presterande ramverket och 1 till de sämst presterade ramverket. Detta för att lättare kunna sammanställa poängen från de olika bedömningskriterierna och få ett sammanställt resultat av utvärderingen. För bedömningskriterierna A samt B skapades en webbapplikation för respektive ramverk. För Bootstrap kan källkoden hittas i bilaga 3, För Foundation hittas källkoden i bilaga 4 samt för SemanticUI hittas källkoden i bilaga Renderingstid Bedömningskriteriet för renderingstiden genomfördes på den skapade webbapplikation för varje ramverk. Renderingstiden mättes i 5 iterationer för att få ett medelvärde av renderingstiden för ramverken. Mätningar gjorde då på stationär dator, surfplatta samt mobil-enhet. Resultatet från dessa mätningar presenteras nedan. Tabell 5. Iterationer av renderingstid i millisekunder(ms) för stationär dator Tabell 5 visar att de ramverket med kortast renderingstid på stationär dator var Bootstrap med ett medelvärde av 22.5ms. På andra plats med endast 0.4ms skillnad kom Foundation med 22.9ms. På sista plats kom SemanticUI med 26.5ms. Tabell 6. Iterationer av renderingstid i millisekunder(ms) för surfplatta Tabell 6 visar att de ramverket som hade kortast renderingstid på surfplatta även här var Bootstrap med ett medelvärde av 88.9ms följt av Foundation med 100.5ms. Sist kom SemanticUI med 233.6ms. Tabell 7. Iterationer av renderingstid i millisekunder(ms) för mobil 22

26 Tabell 7 visar att de ramverken med kortast renderingstid på en mobil-enhet var Bootstrap med ett medelvärde av 50.9ms följt av Foundation med 55.2ms. Sist kom även här SemanticUI med 111.5ms. Tabell 8. Resultatsammanställning av renderingstid Tabell 8 visar att de ramverket som hade kortast renderingstid på alla de tre enheterna stationär dator, surfplatta samt mobil var Bootstrap som då också tilldelas 3 poäng. Detta följt av Foundation som kom på andra plats på alla enheterna och därmed tilldelades 2 poäng samt SemanticUI som kom sist på alla enheterna och därmed tilldelades 1 poäng HTTP-Begäran Bedömningskriteriet för antal HTTP-begäran genomfördes på den skapade webbapplikation för varje ramverk. Resultatet av testet presenteras nedan. Tabell 9. Antal HTTP-begäran Tabell 9 visar antalet HTTP-begäran som varje ramverk gjorde för webbapplikationen. De ramverket som gjorde minst HTTP-begäran var Bootstrap med 5st och därför fick maxpoängen 3. Detta följt av Foundation med 6st HTTP-begäran som då fick 2 poäng samt SemanticUI med 9st HTTP-begäran och 1 poäng. Antalet HTTP-begäran som ramverken gjorde mättes på alla de tre enheterna som renderingstiden mättes på för att säkerställa att inget av ramverken gjorde fler eller mindre HTTP-begärande när dessa enheter användes. Testet visade dock att detta inte var fallet Dokumentation Dokumentationen enligt IEEE' standard för mjukvarudokumentation(ieee Computer Society 2001) har totalt 14 punkter som de tar upp. De 14 punkterna som IEEE tar upp är följande: 23

27 Identifieringsinformation Sidan ska innehålla Dokumentets namn, version, datum, vilken mjukvara den behandlar samt vilken organisation den tillhör Innehållsförteckning Dokumentationen ska innehålla en innehållsförteckning med alla delar av dokumentationen Lista av illustrationer Om dokumentationen innehåller fler än 5st illustrationer eller figurer ska en lista för dessa finnas i dokumentationen Introduktion Introduktionen i dokumentet ska beskriva meningen med dokumentet samt ge läsaren en kort överblick av meningen med mjukvaran Information om användning av dokumentet Dokumentationen ska innehålla information om hur man använder dokumentet samt en förklaring av notationen. Operationella koncept Dokumentation ska beskriva de operationella koncept som används i mjukvaran Procedurer Dokumentationen ska beskriva procedurer för exempelvis installation av mjukvaran eller data-operationer som spara, radera samt skriva. Information om kommandon Ska beskriva de kommandon som finns för mjukvaran. Detta kan exempelvis vara information för parametrar samt syntax kommandon Felmeddelanden samt problemlösning Dokumentationen ska se till så att användaren på ett enkelt sätt antingen kan ta sig ur problem som uppstår med mjukvaran eller enkelt kunna felrapportera eventuella fel Ordlista Dokumentationen ska innehålla en ordlista om dokumentationen kan innehålla ord som den tilltänkta målgruppen kan ha svårt för Relaterade informationskällor Information om relaterade källor så som webbsidor, lista av referenser ska vara inkluderade Navigations struktur Information för att strukturera dokumentationen med exempelvis titlar för rubriker ska finnas med Index Dokumentationen ska innehålla indexering så som exempelvis sidnummer, numrerade rubriker i texten. Men endast om dokumentationen är över 40 sidor Möjlighet till sökning Elektroniska dokument ska ha en metod för sökning av ord i dokumentet Av dessa beskriver de 11 av de totalt 14 som nödvändiga. De som inte är nödvändiga är då: Relaterade informationskällor, Lista av illustrationer samt Index. Utvärderingen för dokumentationen kommer då endast göras på de 11 som anses nödvändiga enligt IEEE (IEEE Computer Society 2001). Poäng kommer att ges för varje punkt av de totalt 11 nödvändiga punkterna som ramverken har i sin användardokumentation. 24

28 Tabell 10. Resultat av dokumentation enligt IEEEs standard Tabell 10 visar resultatet av hur bra användardokumentation för ramverken är enligt IEEE's standard för mjukvarudokumentation. Resultatet visar att de ramverket med bäst dokumentation är Foundation som innehöll 8 av de 11 punkterna som IEEE anser vara nödvändiga och ges därför 3 poäng. Detta följt av SemanticUI med 6 punkter samt 2 poäng och sist Bootstrap med 5 punkter och 1 poäng Sammanställning av resultat Tabell 11 visar en sammanställning av resultatet från utvärderingen. Den visar att både Bootstrap samt Foundation fick 7 poäng var medans SemanticUI hamnade på 4 poäng. Tabell 11. Sammanställning av resultatet 25

29 7. Analys I denna uppsatsen var syftet att jämföra olika ramverk för front-end utveckling och utifrån den informationen ge en rekommendation för vilket av ramverken var att rekommendera. Den undersökningsfråga som då skapades var Vilket av ramverken rekommenderas för att utveckla responsiva webbsidor?. För att svara på denna fråga togs ett antal kriterier fram som ska hjälpa till att besvara frågan. I första urvalet kontrollerades ramverkens licenser för att se om ramverken var gratis samt hade öppen källkod. Om ramverken verkligen var responsiva enligt Ethan Marcotte (2011) och Kim Bohyun (2013). Storleken på ramverken kontrollerades också i första urvalsprocessen för att säkerställa att inget av ramverken var för litet och därför skulle få en nackdel i den senare utvärderingen vid skapande av webbapplikationer för ramverken. Vid andra urvalet behövdes antalet ramverk kortas ner då resurser i form av tid inte fanns för att testa alla ramverken. Kriterierna för detta var då popularitet av ramverken genom att se antal stjärnor på GitHub(Github 2017) samt stöd av ramverket genom att se antal sökningar på Stackoverflow(Stackoverflow 2017). Med hjälp av dessa kriterier var meningen att korta ner antalet ramverk inför utvärderingen men också att säkerställa all de ramverk som testades var de som troligen flest utvecklare var intresserade av. Av de tre ramverken som gick vidare från andra urvalet gjordes en webbapplikation på. Syftet med denna var att kunna utvärdera bedömningskriterierna för renderingstid samt antal httpbegäran. Detta för att få ett en jämförelse av ramverkens prestanda vilket är viktigt i en webbapplikation som också Heitkötter et al (2012) beskriver i sin artikel. Dokumentationen kontrollerades eftersom ramverk kan vara svåra att lära sig som också beskrivs som en nackdel med ramverk av Dirk Riehle (2000) i sin doktorsavhandling. Om dokumentationen är bra kan också kostnaderna för att lära sig ramverket minskas då mindre resurser i form av tid behövs Bootstrap Skapades av Mark Otto samt Jacob Thornton De jobbade då på Twitter därav namnet Twitter-bootstrap som det ibland kallas. Första versionen av Bootstrap släpptes 2011 och har sedan dess haft flera uppdateringar med bland annat två stycken stora uppdateringar med version v2 samt v3 där version 3 byggdes om för att vara responsivt från start(bootstrap 2017). Senaste versionen av Bootstrap är idag Storleken på Bootstrap var 37kB Javascriptkod samt 142kB CSS kod. Om man jämför detta med Foundation samt SemanticUI kan vi se att Foundation hade 121kB Javascriptkod samt 78kB CSS kod. Detta visar på att Bootstrap lagt mer fokus på en större CSS kod medans Foundation skapat mer Javascriptkod. SemanticUI har där precis som Bootstrap mer fokus på CSS då denna fil är hela 576kB samt en Javascript-fil med 272kB. Detta visar tydligt att SemanticUI har en större funktionalitet då både CSS samt Javascript-filerna är betydligt större än Bootstrap samt Foundation. Bootstrap fick högst poäng i antal stjärnor på Github med hela 75,839 mer stjärnor än Foundation som kom på andra plats. Antalet sökningar på Stackoverflow visade också där att Bootstrap har ett stort försprång från de andra ramverken där Bootstrap fick 80,403 sökresultat följt av Foundation med 11,013. Detta beror troligen på att ramverket fick en stor spridning då utvecklarna för ramverket var från Twitter. Ramverket har även uppdaterats och förändrats mycket sen första versionen för allmänheten Bootstrap är nu uppe i version och som 26

30 också Dirk Riehle (2000) beskriver i sin doktorsavhandling så tar det vanligtvis ett flertal iterationer för ett ramverk att bli bra. Bootstrap fick också högsta poäng vid mätningarna av renderingstid samt antal http-begäran. Här var dock skillnaderna inte lika stora då Foundation oftast låg nära Bootstrap. Detta kan också troligen spåras till en väl optimerad kod och flertal uppdateringar. Dokumentationen för ramverket är dock ganska avskalat i jämförelse med vad IEEE's standard är satt till samt vid jämförelse med vad de andra ramverkens dokumentation innehåller Foundation Skapade 2008 som en stilmall av designföretaget ZURB. De använde framförallt denna för sina kunder men 2011 bestämde de sig för att de behövde skapa ett ramverk för att snabbt kunna skapa prototyper. De kombinerade de CSS samt Javascript filerna och skapade ramverket Foundation (Foundation 2017). Ramverket är idag på version Storleken på ramverket är likt Bootstrap dock med skillnaden att Foundation fokuserat mer på Javascripten än CSS-filen. Foundations Javascript-fil är 121kB och CSS-filen är 78kB. Som tidigare nämnt är den jämfört med Bootstrap mer fokuserad på Javascript men ändå är de två ganska lika i storlek. Detta om man jämför med SemanticUI som är betydligt större än både Bootstrap och Foundation. Foundation hamnade på tredjeplats i mätningen om GitHub-stjärnor där de fick 25,459. Detta ganska långt under Bootstrap som fick 110,701 men dock inte lika långt under SemanticUI som fick 34,862. Även i antalet sökresultat visas att Bootstrap är överlägset i stöd med 80,403 sökresultat följt av Foundation med 11,013. Dock visar resultatet att SemanticUI endast hade 3604 resultat vid sökningen vilket tyder på att Foundation har ett större stöd och mer aktiva användare än SemanticUI. Den stora skillnaden är troligen den som tidigare nämnts att Bootstrap fick ett stort lyft av att utvecklarna av ramverket kom från Twitter. Foundation har dock ett större stöd på grund utav att den utvecklades tidigare än SemanticUI som kom ut 2013 med sin första version. Foundation är också på version jämfört med Bootstraps version samt SemanticUI som är på version Detta kan antyda att Foundation är väl underhållet och som Dirk Riehle (2000) beskriver så kan de ta flera iterationer för att skapa ett bra ramverk. För renderingstid samt antal http-begäran var även här Foundation samt Bootstrap inte långt ifrån varandra. På testerna för renderingstid låg Foundation inom några millisekunder av Bootstrap för både stationär dator samt mobil-enhet. På testerna för antal http-begäran låg där också Foundation endast 1 http-begäran ifrån Bootstrap. SemanticUI låg dock längre bak med 4 mer http-begäran än Foundation och 5 mer än Bootstrap. Detta kan vara på grund utav som tidigare nämnt att ramverket har genomgått ett flertal uppdateringar och är på version vilket åter igen styrks av Dirk Riehle's (2000) teori av att flera iterationer behövs för att skapa ett bra ramverk. Dokumentationen för Foundation var den bästa med hela 8 av 11 punkter. Där också Dirk Riehle (2000) förklarar att ramverk kan vara svåra att lära sig till en början. Här kan då en bra och väldokumenterad dokumentation hjälpa till att spara pengar genom att göra de lättare för utvecklaren att lära sig ramverk fortare SemanticUI Det finns lite information om bakgrunden till SemanticUI. Anledningen till detta kan vara att ramverket är ganska nytt. Men ramverket skapades 2013 med version som var den första versionen släppt till allmänheten(semanticui 2017). Idag är den senaste versionen

31 Storleken på SemanticUI jämfört med de andra ramverket i experimentet är ganska stort. SemanticUI verkar ha ganska mycket funktionalitet både i form av Javascript där filstorleken är 272kB men också i form av CSS där filstorleken är 576kB. Detta är en ganska stor skillnad från både Foundation samt Bootstrap. Det är tydligt att SemanticUI satsar på ett större ramverk med mycket funktionalitet. SemanticUI har trots att de är ganska nytt fått fler anhängare på GitHub än Foundation. De kan dock inte riktigt mäta sig med Bootstrap. Sökningen på Stackoverflow visar dock att stödet för SemanticUI är lägre än för både Bootstrap som fick överlägset flest sökresultat men också för Foundation. Detta kan tyda på att användarna för SemanticUI inte är lika aktiva som för Foundation. SemanticUI är på version vilket tyder på att ramverket inte riktigt är lika uppdaterad som Bootstrap på version samt Foundation på version Som Dirk Riehle's (2000) nämner så kan detta tyda på att SemanticUI inte är riktigt lika färdigutvecklat som Foundation och Bootstrap. Renderingstiden på SemanticUI var betydligt långsammare än både Foundation och Bootstrap som låg ganska nära varandra i förhållande. SemanticUI fick lägst betyg i både Renderingstid men också antal http-begäran. På antalet http-begäran så gör SemanticUI ganska många fler än vad både Foundation och Bootstrap gör. Detta kan förklaras genom att SemanticUI satsat mer på funktionalitet och därför behöver större samt fler filer men kan också kopplas till att SemanticUI endast är på version och därav inte är lika väl optimerat som Foundation och Bootstrap. Detta kan återigen kopplas till Dirk Riehle's (2000) beskrivning av att ramverk behöver genomgå flera iterationer innan de blir bra vilket också visas i resultatet av mätningarna. Dokumentationen för ramverket visade dock att SemanticUI hade en bättre dokumentation än Bootstrap då SemanticUI innehöll 6 av de 11 punkterna som IEEE anser vara nödvändiga för en användardokumentation Slutsatser För att då svara på undersökningsfrågan av vilket av ramverken som är att rekommendera för att utveckla responsiva ramverk så får vi kolla på de resultatet som helhet. Både Foundation samt Bootstrap fick 7 poäng som visas i tabell 11. SemanticUI fick dock endast 4 poäng. Trots att Foundation och Bootstrap fick samma antal poäng skulle jag rekommendera Bootstrap då de är mer populärt samt har ett större stöd vilket kan hjälpa speciellt nya utvecklare att ha ett stort stöd bakom ramverket där de kan få hjälp samt svar på frågor. Bootstrap är dock endast på version medans Foundation är på version Detta trots att resultatet av mätningarna för renderingstid samt antal http-begäran visar att Bootstrap var bättre. Detta kan tyda på att de uppdateringar som Bootstrap gjort är bättre utförda men sammanlagt färre i antal. 28

32 7.5. Metodologiska reflektioner De etiska överväganden som gjorts med tanke på experimentet är skapade för att man vid utförande av ett experiment ska försöka kontrollera alla de variabler som kan påverka resultatet av experimentet (Patel & Davidson 2011). De variabler som i detta fallet kan påverkan resultatet är bland annat utformningen av webbapplikationerna samt dess innehåll exempelvis i form av information samt antal egenskaper som används. Därför innehåller webbapplikationerna för varje ramverk samma information och samma typ av egenskaper. Lagrande av cacheminnet rensades också före samt efter varje utfört test av webbapplikationerna för att förebygga att någon information sparas i webbläsaren som på så sätt eventuellt kan ge en fördel för något ramverk. För att öka uppsatsen trovärdighet har all information i form av mjuk och hårdvaruspecifikation presenterats. Även den källkod som användes vid experimentet. Detta för att öka uppsatsens trovärdigheten och för att göra att experimentet går att upprepa. Uppsatsen behandlar endast en liten del av användarna med tanke på både hårdvara och mjukvara. Det är ett problem med att experimentet endast utförs på Android samt Windows och endast på tre enheter. För att öka uppsatsens trovärdighet ytterligare skulle eventuellt flera enheter samt mjukvaror testas. Detta skulle då kunna vara som tidigare nämnt i kap 1.4 Avgränsningar att använda ett flertal mjukvaror som Mac OS för stationära dator och IOS för mobila-enheter och surfplattor för att testa en större andel an användarna. Att utföra experimentet på flera hårdvaror så som nyare mobila-enheter än Samsung Galaxy Ace 4 och Google Nexus 10 vilket idag är äldre versioner av hårdvaror från de två tillverkarna. Det hade varit intressant att se hur renderingstiderna eventuellt hade varit annorlunda om experimentet utfördes på äldre men också nyare versioner av hårdvara. Att experimentet endast utförs på Google Chrome är också en aspekt som borde diskuteras. Hur hade renderingstiderna blivit om man använt en annan webbläsare med en annan renderingsmotor? Valet att endast använda Google Chrome kom sig från att det var den webbläsaren som användes av flest mobila-enheter med 49.23% av användarna där de andra 50.77% är uppdelade mellan ett flertal mindre populära webbläsare (StatCounter 2016c) Framtida arbeten Med tanke på att denna uppsatsen endast behandlar en liten procent med avseende av mjukvaror som operativsystem samt hårdvaror så skulle en fördjupning i hur ramverken presterar på ett flertal olika plattformar samt ett flertal olika hårdvaror vara en intressant vidareutveckling på. Även att utföra experiment på flera olika webbläsare för att se hur renderingstiden blir på ett större urval renderingsmotorer. Framtida arbeten skulle också kunna behandla och utföra experiment på ett större urval av ramverk. Då resurser i form av tid inte fanns för detta arbete för mer än tre ramverk skulle ytterligare experiment på fler ramverk vara något bra. 29

33 8. Referenslista Bootstrap (2017). Bootstrap is the most popular HTML, CSS, and JS framework for developing responsive, mobile first projects on the web. [Elektronisk] Tillgänglig: [ ]. Bulma (2017). A modern CSS framework based on Flexbox [Elektronisk] Tillgänglig: [ ]. Cascade (2017). Cascade Framework. Putting back the C in CSS [Elektronisk] Tillgänglig: Chromium.org (2013). Blink: A rendering engine for the Chromium project. [Elektronisk] Tillgänglig: [ ]. Chrome.com (2017). Chrome DevTools Overview. [Elektronisk] Tillgänglig: [ ]. CodeConquest (2017). Client Side vs. Server Side. [Elektronisk] Tillgänglig: [ ]. Colorlib.com (2016). Top 21 Best Free CSS3 Frameworks for Web Development [Elektronisk] Tillgänglig: [ ]. Cssminifier.com (2017). Minify your CSS. [Elektronisk] Tillgänglig: [ ]. Designinstruct.com (2013). 10 Best Reponsive HTML5 Frameworks. [Elektronisk] Tillgänglig: [ ]. Dirk, R. (2000). Framework Design: A Role Modeling Approach. Swiss Fedral Institute of Technology. Foundation (2017). The most advanced responsive front-end framework in the world. [Elektronisk] Tillgänglig: [ ]. Github (2017). Github. [Elektronisk] Tillgänglig: [ ]. Goldkuhl, G. (2011, ursprungligen från 1998) Kunskapande. Linköpings universitet. Google (2015). Google Webmaster Central Blog: Official news on crowling and indexing sites for Google index. [Elektronisk] Tillgänglig: [ ]. Google.com (2009). Speed Matters. [Elektronisk] Tillgänglig: [ ]. Google.com (2017). Get started with Remote Debugging Android Devices. [Elektronisk] Tillgänglig: [ ]. 30

34 Hansson, A. (2015) En jämförelse mellan ramverk för att utveckla hybridapplikationer. [Elektronisk] Tillgänglig: [ ]. Heitkötter, H., Hanschke, S., Majchrzak, T. (2012). Comparing Cross-platform Development Approaches for Mobile Applications. In Proceedings of the 8th International Conference on Web Information Systems and Technologies. Hernández-Nieto, C., Sánchez, X. & Salinas, P. (2015). A Mobile First Approach for the Development of a Sustainability Game. Procedia Computer Science. HTML KickStart (2017). Ultra-lean HTML5, CSS, & JS Building Blocks for Rapid Website Production [Elektronisk] Tillgänglig: [ ]. IEEE Coputer Society (2001). IEEE Standard for Softwere User Documentation. IEEE Press, New York. Javascript-minifier.com (2017). Minify your javascript. [Elektronisk] Tillgänglig: [ ]. Johansson, E. (2016) Utvärdering av responsiva front-end ramverk och renderingstekniker: En studie med mätningar av svarstider på olika plattformar. [Elektronisk] Tillgänglig: [ ]. Kim, B. (2013). Responsive Web Design, Discoverability, and Mobile Challenge. Library technology reports. 49(6), s Kube (2017). Kube. CSS & JS Framework for professional developers and designers alike. [Elektronisk] Tillgänglig: [ ]. Lei, K., Ma, Y., Tan, Z. (2016). Performance Comparison and Evaluation of Web Development Technologies in PHP, Python and Node.js. Institute of Big Data Technologies, Peking University. Marcotte, E. (2011). Responsive Web Design. New York: A Book Apart. MetroUI (2017). The front-end framework for developing projects on the web in Windows Metro Style [Elektronisk] Tillgänglig: [ ]. Mozilla Developer Network (2017a). HTML(HyperText Markup Language. [Elektronisk] Tillgänglig: [ ]. Mozilla Developer Network (2017b). Cascading Style Sheets (CSS). [Elektronisk] Tillgänglig: [ ]. Mozilla Developer Network (2017c). About JavaScript. [Elektronisk] Tillgänglig: [ ]. Mozilla Developer Network (2017d). Using the viewport meta tag to control layout on mobile browsers. [Elektronisk] Tillgänglig: [ ]. 31

35 Mozilla Developer Network (2017e). Media queries. [Elektronisk] Tillgänglig: [ ]. Mozilla Developer Network (2017f) Server-side web frameworks. [Elektronisk] Tillgänglig: [ ]. Mozilla Developer Network (2017g). Responsive design. [Elektronisk] Tillgänglig: [ ]. Mozilla Developer Network (2017h). Document and website structure. [Elektronisk] Tillgänglig: US/docs/Learn/HTML/Introduction_to_HTML/Document_and_website_structure [ ]. Mozilla Developer Network (2017i) CSS Grid Layout [Elektronisk] Tillgänglig: [ ]. Mozilla Developer Network (2017j) HTTP. [Elektronisk] Tillgänglig: [ ]. Noyes, K. (2010). 10 Resons Open Source Is Good for Business. [Elektronisk]. Tillgänglig: [ ]. Opensource.org (2017). The MIT Licence. [Elektronisk] Tillgänglig: [ ]. Opensoruce.org (2007). The Open Source Definition. [Elektronisk] Tillgänglig: [ ]. Patel, R & Davidson, B. (2011). Forskningsmetodikens grunder: Att planera, genomföra och rapportera en undersökning. 4. uppl. Studentlitteratur. SemanticUI (2017). User interface is the language of the web. [Elektronisk] Tillgänglig: [ ]. Stackoverflow (2017). Stack Overflow is the largest online community for programmers to learn, share their knowledge, and advance their careers [Elektronisk] Tillgänglig: [ ]. StatCounter (2016a). Mobile and tablet internet usage exceeds desktop for first time worldwide. [Elektronisk] Tillgänglig: [ ]. StatCounter (2017b). Operating System Market Share Worldwide. [Elektronisk] Tillgänglig: [ ] StatCounter (2016c). Top 9 Mobile browsers from Jan 2016 to Jan [Elektronisk] Tillgänglig: [ ]. 32

36 UIkit (2017). A lightweight and modular front-end framework for developing fast and powerful web interfaces. [Elektronisk] Tillgänglig: [ ]. W3.org (2017). Media types. [Elektronisk] Tillgänglig: CSS2/media.html [ ]. Zervas, P., Trichos, A., Sampson, D,. Li, N. (2014). A Responsive Design Approach for Supporting Mobile Access to Virtual and Remote Labratrories IEEE 14th International Conference on Advanced Learning Technologies. 33

37 9. Bilagor 1. HTML strukturen som användes för webbapplikationerna <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>titel på ramverket</title> <link href="länk till ramverket's CSS" rel="stylesheet"> </head> <body> <header> <h1>exempel Företag</h1> </header> Navigation här. <div class="row"> <main> <article> <h2>article heading</h2> <img src="exempelbild1.jpg"> <p>lorem ipsum dolor sit amet, consectetur adipisicing elit. Donec a diam lectus. Set sit amet ipsum mauris. Maecenas congue ligula as quam viverra nec consectetur ant hendrerit. Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur.</p> <h3>subsection</h3> <p>donec ut librero sed accu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipisicing elit. Aenean ut gravida lorem. Ut turpis felis, pulvinar a semper sed, adipiscing id dolor.</p> <p>pelientesque auctor nisi id magna consequat sagittis. Curabitur dapibus, enim sit amet elit pharetra tincidunt feugiat nist imperdiet. Ut convallis libero in urna ultrices accumsan. Donec sed odio eros.</p> <h3>another subsection</h3> <p>donec viverra mi quis quam pulvinar at malesuada arcu rhoncus. Cum soclis natoque penatibus et manis dis parturient montes, nascetur ridiculus mus. In rutrum accumsan ultricies. Mauris vitae nisi at sem facilisis semper ac in est.</p> 34

38 <p>vivamus fermentum semper porta. Nunc diam velit, adipscing ut tristique vitae sagittis vel odio. Maecenas convallis ullamcorper ultricied. Curabitur ornare, ligula semper consectetur sagittis, nisi diam iaculis velit, is fringille sem nunc vet mi.</p> </article> <article> <h2>article heading</h2> <img src="exempelbild2.jpg> <p>lorem ipsum dolor sit amet, consectetur adipisicing elit. Donec a diam lectus. Set sit amet ipsum mauris. Maecenas congue ligula as quam viverra nec consectetur ant hendrerit. Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur.</p> <h3>subsection</h3> <p>donec ut librero sed accu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipisicing elit. Aenean ut gravida lorem. Ut turpis felis, pulvinar a semper sed, adipiscing id dolor.</p> <p>pelientesque auctor nisi id magna consequat sagittis. Curabitur dapibus, enim sit amet elit pharetra tincidunt feugiat nist imperdiet. Ut convallis libero in urna ultrices accumsan. Donec sed odio eros.</p> <h3>another subsection</h3> <p>donec viverra mi quis quam pulvinar at malesuada arcu rhoncus. Cum soclis natoque penatibus et manis dis parturient montes, nascetur ridiculus mus. In rutrum accumsan ultricies. Mauris vitae nisi at sem facilisis semper ac in est.</p> <p>vivamus fermentum semper porta. Nunc diam velit, adipscing ut tristique vitae sagittis vel odio. Maecenas convallis ullamcorper ultricied. Curabitur ornare, ligula semper consectetur sagittis, nisi diam iaculis velit, is fringille sem nunc vet mi.</p> </article> </div> <aside> <h2>related</h2> <ul> <li><a href="#">link1</a></li> <li><a href="#">link2</a></li> <li><a href="#">link3</a></li> 35

39 <li><a href="#">link4</a></li> <li><a href="#">link5</a></li> </ul> Tabell med information här. </aside> </div> </main> </div> <footer> <p> Copyright 2050 by Vedran. All rights reversed.</p> </footer> <script src="ramverkets JS"></script> </body> </html> 2. Skärmdump på hur det kan se ut vid Chrome remote debugging via USB. 3. Källkod HTML Bootstrap <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>bootstrap 101 Template</title> <link href="bootstrap dist/css/bootstrap.min.css" rel="stylesheet"> 36