Linköpings universitet SE–581 83 Linköping 013-28 10 00 , www.liu.se
Linköpings universitet | Institutionen för datavetenskap
Examensarbete på grundnivå, 16hp | Datateknik
2021 | LIU-IDA/LITH-EX-G--2021/043--SE
Utvecklingseffektivitet för
Pyra-mid E-Line
Efficient development of Pyramid E-Line based webshops
Andrei Moga
Handledare : Anders Fröberg Examinator : Erik Berglund
Upphovsrätt
Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publice-ringsdatum under förutsättning att inga extraordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopi-or för enskilt bruk och att använda det oförändrat för ickekommersiell fkopi-orskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan använd-ning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens litterära eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.
The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.
According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.
For additional information about the Linköping University Electronic Press and its procedu-res for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
Utvecklingseffektivitet för Pyramid E-line
Andrei Moga
Linköpings Universitet
Norrköping, Sweden
andmo435@student.liu.se
SAMMANFATTNING
Detta arbete har haft som syfte att utforska bästa utgångspunkten för utveckling av webbsidor i E-line. Problemet har undersökts genom att implementera tre responsiva kunddesigner enligt två metoder och analysera den resulterande koden utifrån antal rader som en utvecklare behöver skriva. Den första metoden, närmaste mall, utgår från grundmallen som är närmast den önskade designen. Den andra, samma mall, utgår från samma mall oavsett design. Samma mall resulterade i mer kod totalt men gav betydligt mer kod som skulle kunna återanvändas vid nästa projekt. Närmaste mall resulterade i mindre kod totalt men också mindre kod som kan återanvändas.
INTRODUKTION
Svenskar spenderade cirka 300 miljarder kronor på e-handel under 2019. Hela Norden stod för drygt 800 miljarder kronor. [1] De flesta företag som säljer sina produkter online använder olika e-handelsplattformar för att förenkla processen och ha full kontroll över sin webbplats. E-handelsplattformar erbjuder oftast affärssystem som genererar, eller är nära kopplade till webbplatserna där produkterna säljs. En av e-handelsplattformarna som används av många företag i Norden är E-line. Denna plattform utvecklas av Unikum datasystem AB och är nära kopplad till affärssystemet Pyramid som är utvecklat av samma företag.
Fördelen med Pyramid E-line är att all administration görs från affärssystemet som sedan genererar en färdig webbshop. Nackdelen är att det enbart finns tre grundmallar som affärssystemets användare kan välja mellan och dessa är väldigt enkla. För att nå den nivån som användare förväntar sig från en modern e-handelslösning, krävs oftast vidareutveckling. Webbyråer som Webblandskapet arbetar med att förändra grundmallen och skapa kundunika webbplatser utifrån en av de tre mallarna.
Webbsidan som genereras av affärssystemet kommer oavsett grundmall att innehålla en basuppsättning av CSS-filer. Utvecklare behöver sedan överskriva CSS och Javascript för att få ut önskad design och funktionalitet. Det finns misstankar hos Webblandskapet om att processen kan effektiviseras.
Det finns tre potentiella tillvägagångssätt när utvecklingen av en webbsida ska påbörjas. Det allra vanligaste är att välja den design som är närmast kundens önskemål och sedan ändra precis så mycket som det behövs. Det andra
alternativet är att alltid utgå från samma mall men skapa olika moduler för de vanligaste designkraven. Tredje alternativet är att helt utesluta all medföljande kod och skapa egna designer som man utgår från. Det tredje alternativet rekommenderas inte eftersom man bortser från allt som gör webbsidan en e-line och därav går miste mycket viktig funktionalitet som måste skrivas om från grunden.
Alla dessa metoder har fördelar och nackdelar och kommer utforskas vidare i denna studie för att komma fram till vilken som är bäst när det gäller antal rader skrivna och användbarhet.
FRÅGESTÄLLNING
Vilken metod ger den bästa utgångspunkten för utveckling i E-Line med hänsyn till antal rader kod skrivna?
AVGRÄNSNING
Den här studien kommer inte att undersöka andra typer av e-handelsplattformar eller utvecklingsprocessen hos ytterligare företag. Utvecklingen av webbplats kommer begränsas till en enda sida eftersom tiden inte skulle räcka till flera fullständiga webbshoppar för varje metod. Responsivitet och prestanda kommer inte att analyseras och jämföras i denna studie utan kommer enbart bestå av en grundläggande nivå som man bör förväntas sig av en fungerande webbsida. Den tredje metoden för att utveckla dessa sidor, ingen mall, undersöktes inte praktiskt då denna skulle ta för mycket tid.
BAKGRUND
Det här kapitlet innehåller bakgrundsinformation om teknikerna och metoderna som kommer användas i utvecklingen.
SASS
Syntactically Awesome Style Sheets (SASS/SCSS) är en förprocessor som agerar som en utökning till klassisk CSS. Det vanligaste syntaxen för SASS är SCSS som är en css-kompatibel syntax. SCSS tillåter utvecklare att använda funktionalitet som inte återfinns i CSS från början som variabler, nästlade selektorer, ärvda egenskaper. Denna teknik är mycket användbar i större projekt då det också möjliggör uppdelning av CSS-kod i mindre moduler som sedan importeras med @import. SCSS minskar inte nödvändigtvis antalet rader kod men det tillåter mer modularitet och ger ökad läsbarhet. I figur 1 så kan man se
$text-grey : #444; $font-small : 16px; $font-med : 20px; $font-big : 28px; #MainFooter_FooterCompanyInfo { width : 100%; .contact-title { font-size : $font-big ; } .footerInfo { font-size : $font-small ; .companyName { font-size : $font-med ; margin-bottom : 10px; a { color : $text-grey ; font-weight : 600; } } div { .label { font-weight : 700; margin-right : 3em; width : 65px; } .value { color : $text-grey ; } } } } .page-Prodlist #Page .footer-wrapper .footer-inner #MainFooter_FooterCompanyInfo { width : 100%; } .page-Prodlist #Page .footer-wrapper .footer-inner #MainFooter_FooterCompanyInfo .contact-title { font-size : 28px; } .page-Prodlist #Page .footer-wrapper .footer-inner #MainFooter_FooterCompanyInfo .footerInfo { font-size : 16px; } .page-Prodlist #Page .footer-wrapper .footer-inner #MainFooter_FooterCompanyInfo .footerInfo .companyName { font-size : 20px; margin-bottom : 10px; } .page-Prodlist #Page .footer-wrapper .footer-inner #MainFooter_FooterCompanyInfo .footerInfo .companyName a { color : #444; font-weight : 600; } .page-Prodlist #Page .footer-wrapper .footer-inner #MainFooter_FooterCompanyInfo .footerInfo div .label { font-weight : 700; margin-right : 3em; width : 65px; } .page-Prodlist #Page .footer-wrapper .footer-inner #MainFooter_FooterCompanyInfo .footerInfo div .value { color : #444; }
Figur 1: SCSS-kod (vänster) och motsvarande
ett kodstycke SCSS till vänster och ett av CSS till höger. SCSS ger mycket mindre kodupprepning och tillåter användningen av variable
JQUERY
Jquery är ett JavaScript bibliotek som har som syfte att förenkla manipulering av dokumentstrukturen för webbsidor. Jquery förenklar också hantering av händelser och anrop till olika element.1Det är för närvarande det mest
använda Javascript-biblioteket och kommer användas även i det här projektet för att effektivisera utvecklingsprocessen2.
I figur 2 finns exempel på hur detta kan se ut. Det lägre exemplet tar bort alla barnnoder för elementet “#wrap”, och det högre sätter en eventlistener vid klick på alla anchor tags.
PYRAMID
Pyramid business studio är ett affärssystem som hanterar hela processen för att sälja produkter. Systemet hanterar handel, redovisning och även kundtjänst beroende på behov genom att tillhandahålla olika moduler som kan användas tillsammans. Den senaste versionen i skrivande tid är Pyramid 4.3
// jQuery
$('a').click(function() {
// code...
})
// Vanilla
[].forEach.call(document.querySelectorAll('a'),
function(el) {
el.addEventListener('click', function() {
// code... }) }) // jQuery $('#wrap').empty() // Vanilla
var wrap = document.getElementById('wrap')
while(wrap.firstChild)
wrap.removeChild(wrap.firstChild)
Figur 2: Två exempel på vanliga
javascript-operationer skrivna i jquery samt vanilla
3http://kund.unikum.se/dok/anvandarguide_339_v3.pdf. 2https://w3techs.com/technologies/overview/javascript_libra ry 1"jQuery,"[Online].Available: https://learn.jquery.com/about-jquery/. [Accessed 10 Februari 2021]. E-LINE
E-line är en e-handelsmodul som kan användas i samband med Pyramid. Denna modul genererar en webbplats där data hämtas från Pyramid i realtid. Modulen möjliggör kunder att kunna se de olika produkterna, deras saldo, kampanjer och mycket mer. E-line genererar en fullskalig webbshop där användare kan logga in, lägga beställningar, kontakta kundtjänst och se information. För att göra förändringar i sidan som har genererats av E-line så kan ett företag skapa en katalog manuellt där egna filer kan sättas in. Katalogen och dess filer skickas upp till webbservern och läggs in på rätt ställen men måste då respektera en specifik mappstruktur. Några av de underkatalogerna som är värda att nämnas är: site: innehåller bilder som kommer att användas på sidan, likaså logotyper och ikoner,
css: innehåller egen css in i en fil som kallas user.css, scripts: innehåller egen javascript in i en fil som kallas
user.js,
nav: innehåller stilmallar för navigeringsträdet.
Som standard så medföljer tre CSS-paket då det finns tre standardutseenden. Vilket paket som skickas till webbservern beror på designen som har valts. Standardutseendet går att överskrivas med hjälp av koden från user.css. När det kommer till JavaScript så kommer koden i user.js att inkluderas i trädstrukturen via en script tagg i HTML-dokumentet. Koden i denna fil kan påverkas av och påverkar andra JS-filer i E-line.4
MOBILE FIRST
År 2021 uppskattas det att ungefär 54.8% av all webbtrafik kommer från smartphones.5 Med detta i åtanke, blir sidor
som är mobilanpassade viktigare än någonsin. En metod för att designa och utveckla responsiva webbsidor på kallas för mobile first. Mobile first syftar till att börja utvecklingen i mobilversionen av webbsidan, och sedan utveckla från mindre skärmstorlekar till större. I detta arbete innebär det att SCSS och Javascript kommer skrivas för mobila enheter (320 – 412 px bredd), därefter kommer ytterligare SCSS läggas till för enheter av större storlekar med hjälp av @media regeln som finns tillgänglig i CSS såväl som SCSS tillsammans “min-width” argumentet som man kan se i figur 3. På detta sättet är den mobila SCSS standard och
5https://www.statista.com/statistics/277125/share-of-website
-traffic-coming-from-mobile-devices/
4 Unikum Datasystem AB, "Pyramid e-handel," Augusti
2015. [Online]. Available:
http://kund.unikum.se/installationsmeny/PyDocs/ehandel_h andbok341a.pdf.
övrig SCSS kommer in om skärmstorleken når en viss storlek. @media(min-width: 768px){ .header { display: flex; } }
Figur 3: Media-regel som lägger till CSS/SCSS-koden innanför klammerpareteserna om argumentet stämmer.
GRUNDMALL A
Grundmall A har ett klassiskt utseende med en meny längst upp i headern, tillsammans med en logotyp samt sökruta. Under headern följer en horisontell produktmeny som öppnar underkategorier vid hover. Andra element som är värda att nämnas är en filtrerings- samt sorteringsmeny som sprider ut sig horisontellt och tillhandahåller olika alternativ. Under denna följer produktlistan. För tablet och mobil så ersätts menyn i headern med en dropdown lista, och produktmenyn med en hamburger-knapp som öppnar en vertikal meny men samtliga kategorier och underkategorier.6
GRUNDMALL B
Grundmall B har två horisontella menyer i headern samt en vertikal vänstermeny som är alltid synlig i desktopläge. Även denna har en horisontell filtrering- och sorteringsmeny följt av produktlistan. För tablet och mobil så ersätts menyerna i headern med en hamburgerknapp som öppnar en vertikal meny från högersidan. Menyn som innehåller produktkategorierna samt varukorg är flyttade till en bottenmeny som är fixerad längst ner på skärmen. Dessa knappar öppnar respektive vertikal meny från högersidan av skärmen.7
GRUNDMALL C
Grundmall C saknar synliga menyer i headern helt och har istället enbart en hamburgerknapp till vänster, logotyp i mitten samt knapp för kundkorg till höger. Knappen till vänster öppnar upp en vertikal produktmeny från vänster. Kundkorgsknappen öppnar kundvagnen som en vertikal meny från höger. Sortering och filtrering har varsin knapp som är fixerad vid botten av skärmen och öppnar upp menyer med ytterligare funktionalitet ovanpå en mörk overlay. Denna design behåller samma utseende för alla enheter men trycker ihop allting en aning.8
KUNDDESIGN A
Kunddesign A är mycket lik grundmall A. Denna har en meny längst upp i headern, följd av en logga, sökruta och
8https://github.com/Andrei-Moga/examensarbete 7https://github.com/Andrei-Moga/examensarbete 6https://github.com/Andrei-Moga/examensarbete
kundkorg. Under headern finns en horisontell meny som öppnar dropdown-listor för menyposterna som har underkategorier. En stor skillnad är att denna design har enbart tre knappar för sortering av produktlistan. Knapparna avser sortering per artikelkod, benämning samt pris. För mobil och tablet så liknar denna design grundmall C bättre då den saknar menyposter i headern helt och förlitar sig på en hamburgerknapp för att visa en vertikal meny. Sorteringsknapparna är likadan för alla enheter.9
KUNDDESIGN B
Kunddesign B är mycket lik grundmall B. Designen har en meny i headern med en logga. Produktmenyn är högerställd och alltid synlig i desktopläge. Sortering- och filtreringsmenyn är även här horisontell och har samma knappar som grundmall B. I detta fall så fanns inte skisser för mobil och tablet vilket gjorde att dessa inspirerades av desktopskissen.10
KUNDDESIGN C
Kunddesign C är mycket lik grundmall C. Den har en hamburgerknapp till vänster i headern, en logotyp i mitten och en kundkorg till höger. Hamburgermenyn öppnar en vertikal meny från vänster sidan som innehåller produktkategorier med dropdowns såväl som allmäna menyposter som “Mitt konto”, “Kontakt” och så vidare. För mobil och tablet så har webbsidan samma utseende men mer anpassad för de mindre storlekarna med större element i allmänhet.11
RELATERADE ARBETEN
E-handel är ett ämne som har studerats väldigt noggrant, både ur en ekonomisk synpunkt och en teknologisk sådan. Den senare är den mest relevanta för detta arbete.
Själva utvecklingen av e-handelsprogram har studerats tidigare av Johansson et.al. Här studerades uppbyggnadsprocessen från grunden och vad som krävs från en e-handelssida, författarna går också djupare på hur ASP.NET och AJAX fungerar något som inte i sig är så relevant för detta arbete. Om man går djupare in på ämnet så kan man se studier som analyserar skapandet av e-handelssidor med hjälp av befintliga e-handelsplattformar. [3] Ekdahl et.al undersöker vilka kriterier som är viktigast i denna typ av tillämpning och hur detta jämför sig med tidigare empiriskt framtagna kriterier. [4] Wesström och Gustafsson studerar också befintliga plattformar men fokuserar mer på svårighetsgraden mellan två kända plattformar. [5]
På en mer generell front så har även frågor om uppbyggnaden av e-handelsidor studerats. Berntsson och Rigsjö studerar användbarheten hos webbsidor som används inom e-handel. Deras resultat tyder på att många företag är medvetna om vikten av att skapa en
11https://github.com/Andrei-Moga/examensarbete 10https://github.com/Andrei-Moga/examensarbete 9https://github.com/Andrei-Moga/examensarbete
användarvänlig sida även om många företag lämnar denna process till slutet eller bortser från den helt. Något som studeras av andra i detta ämne är också hur en e-handelssida påverkar kundens tillit och förtroende för e-handel. [6] [7] Vad gäller själva programvaran så finns en del studier om Pyramid. De flesta studier utforskar ärendehantering i Pyramid eller andra programmeringsverktyg. [8] [9] [10] Något som det här arbetet tangerar vid men inte riktigt går in på. Några studier tar även upp Pyramid i kontexten av affärssystem i en större mening och syftar till att undersöka processen för införande och konsekvenser för dessa system. [11] [12] Nyblom et.al. undersöker också en större mängd affärssystem och poängsätter dessa enligt kriterier som användarvänlighet, effektivitet, pris, flexibilitet och mer. [13]
De tidigare studierna undersöker en stor mängd kringliggande ämnen men ingen går in på pyramidmodulen E-line, och därav inte heller undersöker sådant som har med dess utvecklingsmetodik.
METOD
Effektiviteten hos de olika metoderna testades genom att tre designer utvecklades för de två tillvägagångssätten, och antalet rader kod mättes. Utvecklingen skedde från de minsta skärmarna till de större, alltså mobilt först, och sedan för tablet och desktop. Där det inte fanns en mobil design så utvecklades sidan för att passa ihop med desktopskissen.
TRE DESIGNER
Valet av design som implementerades grundades på typiska designer från tidigare kunder och valdes av företaget. För att få ut mer bredd i studien valdes designer som var så olika som möjligt. Olikheten mellan de befintliga designerna baserades på hur sidorna var strukturerade. För att göra en rättvis jämförelse så var varje vald design mer lik en av de tre grundmallarna som Unikum tillhandahåller.12 Den största skillnaden mellan dessa var
placering av headermeny. Enbart en sida utvecklades för varje design och denna var densamma för alla, samt utvecklad responsivt så att den funkar på enheter av alla storlekar. Sidan som utvecklades var produktlistningen, då denna var mest annorlunda mellan de olika designen och innehöll de mest intressanta designelementen enligt företaget. Intressanta designelement som avses här är header, footer, sorteringsfilter och de listade produkterna.
UTVECKLINGSMILJÖN
Sidorna utvecklades mot en demoshop som Unikum har online där de tre grundmallarna A,B och C finns för
12https://github.com/Andrei-Moga/examensarbete
uppvisning13. Demosajten har knappar där man kan byta
mellan dessa designer, och är fylld med fiktiva produkter. Koden som skrevs testades mot denna sida genom att injektera javascript-filen user.js, samt den kompilerade user.css filen i demoshoppen. Denna metod stämmer väl överens med vad som händer när kod faktiskt laddas upp till en Pyramidserver utan att det är nödvändigt att faktiskt ha ett Pyramidsystem igång. För att göra detta möjligt så gjordes filerna tillgängliga lokalt, i webbläsaren med hjälp av en webbserver inuti en virtuell maskin. Nackdelen med detta var att Pyramid har en mängd inställningar för vilka element som ska synas på en sida och vad menyerna ska innehålla. I detta fall var utvecklingen begränsad till elementen och menyerna som fanns i demoshoppen. Element som saknades utöver det lades till via javascript för att inte påverka antalet rader SCSS som behöver skrivas.
RESPONSIVITET
Utvecklingen av nya tekniker har gett upphov till fler typer av enheter än någonsin förr. Glassman och Shen [2] beskriver detta fenomen som att en utvecklare aldrig kan veta vad det är för storlek på enheten som deras webbsida kommer visas upp på. Även i denna studie så var det omöjligt att veta vilka enheter som en sida kan visas på. Därav gjordes ett försök att täcka så många typer av enheter som möjligt genom att använda storlekarna på de enheter som finns i Google Chromes inspekterare. Storlekarna varierade mellan smartphones (320 – 412 px bredd), tablets (768 – 1024px) och desktop ( > 1025 px). Responsiviteten mättes inte i denna studie utan var enbart ett grundläggande krav för att designen skulle anses vara färdigt. Responsivitet ansågs vara uppnått när alla element visades och var användbara i alla tidigare nämnda pixelintervall.
NÄRMASTE MALL
Denna utvecklingsmetod använde samtliga mallar som utgångspunkt. Grundmallen som utvecklingen utgick från för varje kunddesign berodde på vilken som var närmast utseendemässigt. Design A motsvarade grundmallen A med en horisontell header-meny med dropdowns och fönstervy för de visade produkterna. Design B motsvarade grundmall B med vänsterställd meny i desktopläge och fönstervisning för produkterna. Slutligen motsvarade design C grundmallen C med vänsterställd meny som måste öppnas upp med hjälp av en hamburgerknapp och med listvisning för produkterna.
SAMMA MALL
Utvecklingsmetodiken för samma mall utgick enbart från en grundmall för samtliga designer. Företaget använder grundmallen C i betydligt större utsträckning än de övriga och därav så valdes den som utgångspunkt. Denna mall hade en vänsterställd meny, som visades med hjälp av en hamburgarknapp. Detta innebar att kunddesignerna B och C var relativt enkla att utveckla medan design A krävde betydligt mer arbete. Design A var svårare att utveckla på
grund av att menyn i grundmall C behövde flyttas och omstruktureras för att motsvara den synliga headern som grundmall A och kunddesign A har. Denna metod förväntades kräva mer kod än närmaste mall men behöver i teorin lika mycket arbete när sidan är strukturerad efter design 1. Därav så delades koden som skrevs under denna del av utvecklingen. Koden delades upp i kod som krävdes för att få samma sidostruktur som design A, alltså en horisontell header-meny som alltid syns, och kod för att implementera den önskade designen. Anledningen till detta var att strukturkoden skulle kunna återanvändas i andra projekt och därav dra ner den totala mängden kod som behöver skrivas när projekt utvecklas efter denna metod.
INGEN MALL
Denna metod innebar att utesluta all kod som kommer med från Pyramid. Metoden var viktig att nämna, då det är en möjlig utvecklingsmetod av E-line projekt. Metoden uteslöts däremot ur detta arbete. Mängden funktionalitet som hade krävts för att få den att fungera hade gjort den onödig ur en effektivitetssynpunkt. Metoden hade också krävt betydligt mer arbete vid varje framtida uppdatering för att se till att nya funktioner hanteras på rätt sätt. Att kartlägga denna metod på ett rättvist sätt hade krävt ett eget arbete för sig.
MÄTNING AV KODRADER
Den utvecklade koden mättes i antal rader skrivna. För att få konsekventa mätningar så användes samma kodstandard för CSS/SCSS och JavaScript i samtliga designer. För SCSS så räknades rader både totalt sett, och som funktionella rader eftersom det är möjligt att skriva samma kod med ett varierande antal rader. Funktionella rader avser rader som tillför funktionalitet dvs. utan selectors och klammerparenteser. I figur 4 kan man se ett exempel på olika sätt att skriva samma funktionella kod. För att anpassa divven med klassen “level4” så skulle man kunna skriva SCSS som varianten i mitten på figur 4, som varianten till höger och flera sätt där emellan. Därav skulle en sån mätning inte vara konsekvent. Ytterligare, innebar det att antalet rader inte påverkades av om det är CSS eller SCSS som användes då båda använder samma innerkod även om sättet man skriver selectors på skiljer sig, något som också syns väl i figur 1.
<divclass="outer"> <divclass="level1">
<divclass="level2"> <divclass="level3">
<div class="level4"> Hej! </div> </div> </div> </div> </div> .outer{ .level1{ .level2{ .level3{ .level4{ margin: 0; } } } } } .outer{ .level4{ margin: 0; } }
Figur 4: HTML-struktur samt två sätt att peka ut den innersta divven.
För JavaScript/Jquery mättes koden som rader med skriven kod där alla tomma rader uteslöts. Alla enkla statements avslutas med semikolon och tar varsin rad, dock inte i de fall där flera funktioner kedjas efter varandra. Kodblock med klammerparenteser börjas på samma rad som funktionen eller variabeln deklareras, och avslutas på en egen rad. Varje värde i ett objekt får en egen rad och avslutas med ett kommatecken. För funktioner som används som argument för andra funktioner eller callback-funktioner så används anonyma funktioner som påbörjas på samma rad som de övriga argumenten. Funktionerna följer samma regler som vanliga kodblock. För enkelhetens skull så delas inte rader med mer än 80 tecken upp även om det är den rekommenderade standarden utan får brytas ner till nästa rad av soft-wrap. Ytterligare kodstandarder gör skillnad i läsbarhet, men tas inte upp här då de inte påverkar antalet rader som skrivs.
ÅTERANVÄNDBARHET
Ett viktigt begrepp för att effektivisera utvecklingen av E-line webbsidor är återanvändbarhet. Anledningen till detta är att effektiviseringen är nära kopplat till antalet rader kod som behöver skrivas. Detta innebär att alla rader kod som kan återanvändas från ett tidigare projekt är rader som inte behöver skrivas om. Av denna anledning så kommer antalet återanvändbara rader att räknas, likaså kundunika rader. Återanvändbara rader kommer att räknas på samma sätt som funktionella rader, men enbart om de ligger till grunden för design som skulle kunna användas i andra projekt. Något som kan vara lite svårt avgöra men som i detta fall kommer avsåg större ombyggnader av sidostruktur och features som skilde sig från den övriga designen. Element som fanns på rätt ställe i DOM-strukturen och enbart behövde designas om räknades som kundunik design.
RESULTAT
Resultaten från kodmätningarna är redovisade i tabellerna nedan. De resulterande implementationerna finns tillgängliga för visning på GitHub. Likaså kan den skrivna koden ses i samma repository.14
DESIGN A
Design A utgick från grundmall A i omgången närmaste mall. Den totala mängden kod som skrevs var 710 rader SCSS samt 50 rader Javascript. Den funktionella SCSS koden som skrevs hamnade på 309 rader. För närmaste mall så fanns många designelement på rätt plats layoutmässigt, men behövde designas om. All denna design kan ses i tabell 1 på raden “Kundunikt”. Designelementen som gjordes om helt åt hållet men som också kan återanvändas vid ett liknande projekt bestod av:
- Sorteringsknapparna innan produktlistan (desktop). - Flytt av toppmeny (mobil- och tablet-läge).
Återanvändbar kod resulterade i 82 rader SCSS kod och 11 rader Javascript.
Samma mall kom väldigt nära i totalt antal rader kod med 697 och också antal rader funktionell kod. Grunddesign C skiljer sig betydligt mer från Design A. Mängden kod som var kundunikt var strax över hälften av den totala mängden funktionell kod. Antalet rader återanvändbar kod är betydligt högre än närmaste mall. Även för Javascript så kan man se denna jämnare fördelningen. Anledningen till detta är att grunddesign C behöver väldigt många större justeringar och förflyttningar för att likna design A. Det som ingår i den återanvändbara koden är:
- Förflyttning av produktmeny, från sidomeny till header.
- Förflyttning och ombyggnad av kundkorg. - Sorteringsknappar ovanför produktlistan.
Design A
SCSS Närmaste mall Samma mall
Totalt 710 697 Funktionell 309 290 Återanvändbart 82 142 Kundunikt 227 148 JS Totalt 50 48 Återanvändbart 11 28 Kundunikt 39 20
Tabell 1: Resultaten för design A.
DESIGN B
Den totala mängden kod för närmaste mall blev 695 rader varav 238 funktionella. Antalet rader återanvändbar kod var låg med enbart 59 rader medan den kundunika resulterade i 179 rader. För närmaste mall så är grunddesign B och design B väldigt lika. Även här så fanns det inte stora skillnader och den största delen av arbetet var design av element som var på rätt plats. Den återanvändbara koden för denna omgång var:
- Filtrering och sorteringsrutan innan produktlistan. För samma mall var resultaten väldigt annorlunda. Den totala mängden kod som skrevs hamnade något högre än närmaste mall med 826 rader varav 346 funktionella. I det här fallet så kan man se att mängden återanvändbar kod var faktiskt högre än den kundunika. Förändringarna som gav upphov till det här var:
- Ombyggnad av headermeny (mobil /tablet). - Filtrering och sorteringsruta innan produktlistan.
- Bottenmeny med produkter, sök och varukorg (mobil/tablet).
- Ombyggnad av togglad headermeny (mobil/tablet). - Flyttning/ombyggnad av header samt under-header
(desktop).
- Ombyggnad av sidomeny (desktop).
Även för Javascript så var mängden återanvändbar kod högre än den kundunika för samma mall.
Design B
SCSS Närmaste mall Samma mall
Totalt 695 826 Funktionell 238 346 Återanvändbart 59 189 Kundunikt 179 157 JS Totalt 26 65 Återanvändbart 5 37 Kundunikt 21 28
Tabell 2: Resultaten för design B.
DESIGN C
Då samma mall använde grundmall c och närmaste mall för kunddesign C också var grundmall C så blev resultaten för denna exakt samma. Här var mängden återanvändbar kod 0 för båda metoderna då designen var väldigt lik grundmallen och ingenting behövde flyttas.
Design C
SCSS Närmaste mall Samma mall
Totalt 178 178 Funktionell 48 48 Återanvändbart 0 0 Kundunikt 48 48 JS Totalt 15 15 Återanvändbart 0 0 Kundunikt 15 15
EFFEKTIVITET
Figur 5 och 6 visar hur mängderna kod jämför sig. Den funktionella mängden kod är högre för samma mall, både för SCSS och Javascript. Det innebär att denna metod kräver mer kod än närmaste mall. Det man kan se i figurerna är också att samma mall ger mer återanvändbar kod, vilket medför att färre rader kundunik kod behöver skrivas. Resultaten tyder på att det är mer effektivt att utveckla efter samma mall så länge som kod faktiskt återanvänds. I annat fall så kan man se att mängden kod som behöver skrivas är högre.
Figur 5: Diagram som visar hur många rader SCSS-kod som skrevs för varje metod och kategori.
Figur 6: Diagram som visar hur många rader Javascript-kod som skrevs för varje metod och kategori.
DISKUSSION
I det här kapitlet diskuteras metoderna bakom resultaten och själva resultaterna.
Det har funnits en mängd faktorer som har påverkat utvecklingen av de olika webbsidorna. En av dom har varit demoshoppens utformning. E-line har ett system där man inte kommer åt html-strukturen som skapas och inte heller åt servern som hostar själva webbshoppen. För att göra detta arbete så replikerbart som möjligt och för att uppsättningen av ett sånt system måste gå genom Unikum så togs beslutet att utveckla webbsidorna på ett sätt som
vem som helst har tillgång till. Med detta menas att injektera den skrivna koden i själva sidan inne i webbshoppen. Nackdelen med denna metod är att det inte går att ändra innehåll som produkter, menyer och kategorier som finns tillgängliga. I de resulterande designerna kan man se detta genom att menyposterna och produkterna är annorlunda jämfört med de i kundskisserna. Det påverkar inte mängden skriven kod men det påverkar designen. Vad gäller mängden skriven kod så har den påverkats av att vissa designelement har fått läggas till med Javascript för att inte påverka den totala mängden SCSS som skrivs. Exempel på dessa är artikelnummer, som vanligtvis kan slås på inne i systemet men som i detta arbete har lagts dit med Javascript. Ett liknande problem är att alla grundmallar inte har samma funktionalitet, knapparna för sortering som man kan se i design A är enbart två i grundmall A medan alla tre är med i grundmall C. Lyckligtvis har dessa fungerat väl att läggas till med Javascript men det påverkar antalet rader skrivna.
En annan begränsning i arbetet har varit att alla designer inte hade mobila sidor. Design B hade enbart en skiss för desktop och därför utvecklades det enligt närmaste mall med desktopskissen som inspiration. När den sedan utvecklades efter samma mall användes designen från den tidigare metoden som skiss. Trots att den slutgiltiga designen blev nästan identisk för både närmaste mall och samma mall så kan designvalen som gjordes i närmaste mall ha påverkat utgången för utvecklingen enligt samma mall.
För att få en mer rättvis bild av hur metoden samma mall påverkar mängden skriven kod, hade det behövts att man utgår från samtliga mallar för alla designer. Med detta menas att man för samma mall utgår från grundmall A, B och C, inte enbart från C som gjordes i detta arbete. För att genomföra detta så hade det behövts betydligt mer tid som dessvärre inte fanns tillgängligt. Det är dock ett utmärkt ämne som framtida forskning inom området skulle kunna ta upp.
För att räkna antal rader som är återanvändbara har raderna av SCSS och Javascript som ligger bakom designen av vissa element som har beskrivits tidigare, markerats med en kommentar. Kommentarerna har sedan räknats ihop för att ge siffrorna som redovisades i tabellerna. I stora drag så är all kod som påverkar dessa element räknat som återanvändbar kod. Det är ett koncept som funkar eftersom vid framtida utveckling så skulle hela det stycket av kod behövas. Däremot kan det finnas några enstaka rader, exempelvis som beskriver färg eller font, som skulle behöva ändras för en annan kund och därav så skulle mängden rader som faktiskt återanvänds vara marginellt mindre än redovisat.
Tidigare studier har inte utforskat utvecklingen av webbsidor i E-line och kan därav varken stödja resultaten eller motsäga dessa, något som är en nackdel.
Förhoppningsvis så kommer framtid forskning att ta upp ämnet och utveckla det vidare.
REFERENSER
[1] Nets, ”Nordic e-commerce,” 2019. [Online]. Available:
https://info.nets.dk/hubfs/Nordic%20e-commerce% 202019%20-%20Nets%20report.pdf?hsLang=se. [2] N. R. Glassman och P. Shen, ”One Site Fits All:
Responsive Web Design,” Journal of Electronic
Resources in Medical Libraries, pp. 78-90, 2014.
[3] H. Johansson, T. Skålberg och J. Grunditz, ”Utveckling av e-handel med ASP.NET AJAX,” Kalmar, 2008.
[4] A. Ekfahl och F. Olsson, ”Accelerator inom e-handel: En fallstudie inom paketerade lösningar,” 2016.
[5] A. Wessström och G. P, ”Gör det själv! : En flerfallsstudie över skapandet av e-handelssidor med hjälp av e-handelsplattformar,” Dissertation, 2018.
[6] J. Karlsson, ”Användarnas förtroende till gränssnitt vid e-handel,” 2017.
[7] E. Johansson och S. Efraimsson, ”Att våga skicka in pengarna : en studie om tillit och trygghet inom e-handel,” Dissertation, University of Borås/School of Business and IT, 2012.
[8] J. Nilsson Hansen, ”Ärendehanteringssystem på web,” Chalmers tekniska högskola / Institutionen för data- och informationsteknik (Chalmers), 2014. [9] F. Holm, ”Ärendehantering för webbaserade
affärssystem,” Dissertation, 2018.
[10] T. D. Vo, ”Utvärdering av
programmeringsverktygen i affärssystemet Pyramid,” 2013.
[11] M. Persson, C.-J. Lindegren och N. Staffan, ”Affärssystem i svenska småföretag,” 2004. [12] A. Wickman och S. Chiok Marrou, ”Affärssystem i
små och medelstora företag: Konsekvenser av införande och användande av ett affärssystem,” Lund, 2009.
[13] M. Nyblom, J. Behrami, T. Nikkilä och K. Solberg Søilen, ”An evaluation of business intelligence software systems in SMEs - a case study,” Journal of Intelligence Studies in Business 2.2, 2012.
