Webbaserad best ¨allningshanterare
f ¨or b ¨attre arbetsfl ¨oden hos
studentpubar
Benjamin Angeria
Albin Antti
Aliyawer Qambari
Christoffer Wall ´en
Institutionen f ¨or informationsteknologi Bes ¨oksadress: ITC, Polacksbacken L ¨agerhyddsv ¨agen 2 Postadress: Box 337 751 05 Uppsala Hemsida: https://www.it.uu.se Abstract
Webbaserad best ¨allningshanterare f ¨
or b ¨attre
arbetsfl ¨
oden hos studentpubar
Benjamin Angeria Albin Antti
Aliyawer Qambari Christoffer Wall ´en
Many student pubs handle customer orders manually by using slips of paper and handing them to the kitchen personnel. This process can lead to some orders being lost due to the occasional misplacement of the pa-per slips. Additionally, thousands of papa-per slips are used and thrown away which consumes resources. Our solution is to replace this ana-logue process with a completely digital self-hosted web based order management application. The application does not handle any payment transactions which gives users a flexible application that can be inte-grated with their payment system of choice. The application contains all necessary functionality to be used in student pubs. Usability testing showed that all users were able to use the system effectively. Finally, the application aids in reducing food waste by providing statistics on previous food consumption.
Extern handledare: Daniel Fehrm, Uppsala teknolog- och naturvetark˚ar Handledare: Mats Daniels, Bj¨orn Victor och Tina Vrieler
M˚anga studentpubar hanterar i dagsl¨aget sina kunders matbest¨allningar genom att man-uellt skriva ner dem p˚a papperslappar och d¨arefter ge dem till k¨okspersonalen. Denna process kan leda till att vissa ordrar f¨orsvinner eftersom papperslapparna ibland slarvas bort. Vidare anv¨ands tusentals papperslappar ˚arligen vilket ¨ar en on¨odig f¨orbrukning av resurser. V˚ar l¨osning var att ers¨atta den analoga processen med en helt digital webbap-plikation f¨or orderhantering som kan k¨oras p˚a valfri webbserver. Apwebbap-plikationen hanterar inte betalningar vilket ger applikationens anv¨andare flexibiliteten att integrera applika-tionen med ett betalningssystem som passar dem. Applikaapplika-tionen inneh˚aller all funktio-nalitet som kr¨avs f¨or att anv¨andas p˚a studentpubar. Resultatet av anv¨andartesterna var att alla anv¨andare klarade av att anv¨anda systemet. Slutligen underl¨attar applikationen med att minska on¨odigt matsvinn genom att sammanst¨alla statistik ¨over tidigare mat˚atg˚ang.
Inneh ˚all
1 Introduktion 1
2 Bakgrund 1
2.1 Olika s¨att att hantera matbest¨allningar . . . 2
2.1.1 Handskrivna lappar . . . 2
2.1.2 Lappar skrivna av kvittoskrivare . . . 2
2.1.3 Digitala system . . . 3
2.2 M˚algrupper . . . 3
3 Syfte, m˚al, och motivation 4 3.1 Syfte . . . 5
3.2 M˚al . . . 5
3.3 Etiska aspekter . . . 6
3.3.1 Tillg¨anglighet . . . 6
3.3.2 Anv¨andbarhet . . . 7
3.3.3 Integritet och s¨akerhet . . . 8
3.3.4 H¨ansyn till andra utvecklare . . . 8
3.4 Avgr¨ansningar . . . 9
4 Relaterat arbete 9 5 Metod, tillv¨agag˚angss¨att och tekniker 10 5.1 M˚algruppsunders¨okning . . . 10
5.2 Ramverk . . . 11
7 Krav och utv¨arderingsmetoder 14
7.1 Anv¨andarv¨anlighet . . . 15
7.1.1 Anv¨andartester . . . 15
7.1.2 Nielsens tio heuristikprinciper . . . 16
7.2 Responsivitet . . . 16
7.3 S¨akerhet . . . 17
8 Implementation 17 8.1 Kommunikationen mellan systemets delar . . . 17
8.2 Autentisering och s¨akerhet . . . 18
9 Hur anv¨ands applikationen? 19 10 Utv¨arderingsresultat 20 10.1 Hur ˚aterkopplingen implementerats . . . 20
10.1.1 Lagda best¨allningar tar f¨or mycket plats . . . 24
10.1.2 Storlek p˚a text och ikoner . . . 24
10.1.3 Ihopblandning av ordernotering och specialkost . . . 25
10.1.4 Ta bort enskilda r¨atter fr˚an en best¨allning . . . 25
10.1.5 L˚angsam ˚aterkoppling . . . 26
10.2 Antalet testdeltagare . . . 26
10.3 Tester under verkliga f¨orh˚allanden . . . 26
11 Resultat och diskussion 27
13 Framtida arbete 29 13.1 Kundvy . . . 29 13.2 Detaljerad statistik . . . 29 13.3 Realtidsuppdateringar . . . 29 13.4 F¨orb¨attrad administrat¨orvy . . . 30 A Resultat av m˚algruppsunders¨okning 35 A.1 Vilken arbetsgrupp tillh¨or du? . . . 35
A.2 Var ¨ar ditt prim¨ara arbetsomr˚ade? . . . 35
A.3 Vad skulle du vilja se f¨or funktioner i ett s˚adant h¨ar system? . . . 35
B Resultat av anv¨andartester 37 B.1 Testperson 1 . . . 37 B.2 Testperson 2 . . . 37 B.3 Testperson 3 . . . 38 B.4 Testperson 4 . . . 39 B.5 Testperson 5 . . . 40
2 Bakgrund
1
Introduktion
I restaurangbranschen anv¨ands idag olika variationer av pappersbaserade system f¨or att hantera matbest¨allningar. En mottagen best¨allning skrivs ned p˚a ett papper - en s˚a kallad bong - antingen f¨or hand eller av kvittoskrivare. Bongen ges sedan vidare till k¨oket f¨or behandling. Processen bidrar till Sveriges f¨orbrukning av kvittopapper som Svensk Handel uppskattat till att motsvara cirka 60 000 tr¨ad per ˚ar [34]. Pappersbaserade system kan ¨aven medf¨ora m˚anga problem s˚asom ol¨asliga lappar, lappar som tappas bort eller lappar som hanteras i fel ordning. Misstag som detta kan leda till ¨okade v¨antetider, missn¨ojda kunder och en stressigare arbetsmilj¨o f¨or serveringspersonalen.
M˚alet med detta arbete var att l¨osa problemen med on¨odig pappersf¨orbrukning och sv˚ar-tolkade lappar f¨or att g¨ora serveringspersonalens arbetsmilj¨o b¨attre och mindre stress-fylld, vilket i sin tur kan leda till f¨arre missn¨ojda kunder och en mer h˚allbar verksam-het. P˚a en st¨orre skala kan ett system som detta ¨aven verka f¨or att minska pappers-f¨orbrukningen inom restaurangbranschen i sin helhet, ett viktigt m˚al f¨or s˚av¨al samh¨allet som klimatet.
Uppsala teknolog- och naturvetark˚ar (UTN) ¨ar studentk˚aren f¨or alla studenter och dok-torander p˚a teknisk- naturvetenskaplig fakultet vid Uppsala universitet. Dess syfte ¨ar att ta tillvara p˚a, fr¨amja samt bevaka studenternas intressen fr¨amst vad avser utbild-ningsfr˚agor, studiesociala fr˚agor och n¨aringslivsfr˚agor [27]. D¨arut¨over har k˚aren i upp-gift att tillhandah˚alla sociala aktiviteter f¨or sina medlemmar samt att verka f¨or ett gott kamratskap dem emellan. Som en del av detta sociala arbete bedriver UTN regelbun-den pubverksamhet. Genom evenemang s˚a som Forsr¨anningen, karri¨arm¨assan Utnarm och regelbundna k˚arhuspubar serverade Uppsala teknolog- och naturvetark˚ar mat f¨or strax under en miljon kronor ˚ar 2019 [35, sid. 3]. Under dessa evenemang har alla mat-best¨allningar historiskt skrivits ned p˚a papperslappar av barpersonal och l¨amnats vidare till k¨oket. Det har inneburit att UTN har haft problem med just ¨okade v¨antetider och missn¨ojda kunder p˚a grund av d˚aligt skrivna eller borttappade lappar. Genom sin pub-verksamhet f¨orbrukar de ocks˚a tusentals papperslappar per ˚ar. I samarbete med UTN har d¨arf¨or ett digitalt best¨allningssystem utvecklats d˚a UTN skulle kunna dra nytta av ett s˚adant system.
2
Bakgrund
Inom Uppsalas studentliv finns ett flertal studentnationer och studentk˚arer. De bedri-ver n˚agon form av regelbunden pubbedri-verksamhet f¨or Uppsalas h¨ogskole- och unibedri-ver- univer-sitetsstudenter och en stor del av denna pubverksamhet involverar matservering.
Ef-tersom Uppsalas studentnationer och studentk˚arer till stor del drivs genom studenters volont¨arsarbete ¨ar personaloms¨attningen h¨og och de som jobbar p˚a dessa studentpubar har generellt inte lika mycket erfarenhet som personal p˚a allm¨anna restauranger. D¨arf¨or st¨alls h¨oga krav p˚a den infrastruktur och de system som personalen p˚a respektive stu-dentpub anv¨ander, samt att dessa system ska ha en h¨og niv˚a av anv¨andarv¨anlighet f¨or att matbest¨allningar ska kunna l¨aggas samt behandlas s˚a snabbt och felfritt som m¨ojligt.
2.1
Olika s ¨att att hantera matbest ¨allningar
Det vanligaste s¨attet att hantera matbest¨allningar ¨ar via bongar som kassapersonal l¨amn-ar ¨over till k¨okspersonal och som inneh˚aller information om vad f¨or typ av mat och dryck som best¨allts, i vilket antal samt av vem. Det finns m˚anga olika s¨att att hantera bongar p˚a och alla har sina olika f¨or- och nackdelar.
2.1.1 Handskrivna lappar
De handskrivna lapparna ¨ar den enklaste typen av bong. Metoden ¨ar l¨att att l¨ara sig, ¨ar flexibelt och framf¨or allt billigt d˚a den enda kostnaden det medf¨or ¨ar kostnaden av papperslappar och pennor. Under intensiva arbetspass finns det dock en risk att det blir r¨origt med en massa papperslappar liggandes. Kommunikationen mellan bar och k¨ok kan ocks˚a bli ett problem om barpersonalen till exempel har sv˚arl¨aslig handstil. Det kan i sin tur leda till felaktiga och f¨orsenade best¨allningar, eller i v¨arsta fall borttappade best¨allningar.
I dagsl¨aget ¨ar det detta system Uppsala teknolog- och naturvetark˚ar anv¨ander eftersom licenskostnaderna f¨or digitala system ¨ar f¨or h¨oga. Denna l¨osning fungerar men f¨or att s¨anka sina driftkostnader och minska sin klimatp˚averkan s¨oker UTN efter en anpassad digital l¨osning.
2.1.2 Lappar skrivna av kvittoskrivare
Lapparna skrivna av kvittoskrivare ¨ar den snabbaste typen av bong. N¨ar barperson-alen sl˚ar in en best¨allning p˚a verksamhetens kassasystem och tar betalt av kunden skrivs relevant information ut av en ansluten kvittoskrivare i k¨oket. Denna metod ¨ar snabb och enkel att anv¨anda och leder s¨allan till missf¨orst˚and. Metoden leder dock till h¨ogre l¨opande kostnader d˚a det kr¨aver en kassaapparat i baren och en kvittoskrivare i k¨oket som kan interagera med varandra. Det beh¨ovs ¨aven mjukvara med st¨od f¨or den-na typ av funktion. Ett exempel p˚a ett s˚adant system ¨ar applikationen iZettle [11] som
2 Bakgrund
licenseras ut och s˚aledes medf¨or licenskostnader. Denna typ av system medf¨or ¨aven f¨orbrukningskostnader i form av bland annat kvittorullar.
2.1.3 Digitala system
Ett annat alternativ ¨ar digitala system. Dessa fungerar likt kvittosystemet ovan, men ¨ar helt n¨atverksbaserade. N¨ar barpersonalen sl˚ar in en best¨allning i en kassaapparat (eller separat dator om kassaapparaten inte ¨ar ansluten till ett n¨atverk) skickas en digital bong till en sk¨arm i k¨oket via en webbserver. Denna typ av system ¨ar snabba och enkla att l¨ara sig och f¨orbrukar inget fysiskt material, till skillnad fr˚an de ¨ovriga tv˚a alternativen. Som nackdelar kan dock n¨amnas licenskostnader, att en datorsk¨arm tar mer plats ¨an en kvittoskrivare i k¨oket samt att systemet kr¨aver en stabil n¨atverksuppkoppling, antingen till ett lokalt n¨atverk eller till internet. De flesta program som i dagsl¨aget erbjuder den-na typ av bongar ¨ar dessutom desigden-nade f¨or att ¨aven ta betalt av kunden direkt genom snabbkassor som finns p˚a till exempel snabbmatsrestauranger vilket kan vara ett pro-blem om verksamheten inte kan ta emot internetbetalningar. Mer om dessa system finns i avsnitt 4.
2.2
M ˚algrupper
Arbetet hade tre t¨ankta m˚algrupper inom Uppsala teknolog- och naturvetark˚ar: Fors-r¨anningskommitt´en, UTN:s systemadministrat¨or samt UTN:s klubbverk. Dessa tre m˚al-grupper ¨ar de t¨ankta prim¨ara anv¨andarna av systemet och av detta sk¨al ¨ar det dessa m˚algrupper som anv¨andartester och unders¨okningar kommer att g¨oras mot.
Forsr¨anningskommitt´en anordnar varje ˚ar en forsr¨anning p˚a Fyris˚an i Uppsala den sista april [33] som lockar tiotusentals bes¨okare [9]. I samband med forsr¨anningen h˚alls en veckol˚ang festival utanf¨or ˚Angstr¨omslaboratoriet. Under denna festival annordnas pub-verksamhet och ˚ar 2019 s˚aldes det mat f¨or totalt 161 000 kronor [35, sid. 27]. Forsr¨ann-ingskommitt´en ans˚ags s˚aledes vara en bra m˚algrupp eftersom de kommer att anv¨anda system v¨aldigt intensivt med m˚anga matbest¨allningar under en kortare period.
UTN:s systemadministrat¨or ¨ar en f¨ortroendevald post inom UTN som innehas f¨or n¨ar-varande av Daniel Fehrm vars arbetsuppgifter prim¨art ¨ar att sk¨ota UTN:s digitala system samt se till att alla dess hemsidor underh˚alls och fungerar som de ska [28]. Som en del av detta arbete kommer systemadministrat¨oren i framtiden ¨aven ansvara f¨or att webbap-plikationen utvecklad av projektgruppen ska kunna anv¨andas fram¨over. Systemadmi-nistrat¨oren kommer ¨aven att sk¨ota alla systemets anv¨andare, deras konton, l¨osenord och s˚a vidare. Eftersom systemadministrat¨orens mandatperiod ¨ar ett ˚ar tills¨atts en ny
syste-madministrat¨or varje ˚ar. Eftersom en nyvald systesyste-madministrat¨or ofta m˚aste l¨ara sig hur UTN:s system fungerar st¨aller det h¨oga krav p˚a systemet g¨allande dokumentation av s˚av¨al funktioner som kod samt att systemet ska vara l¨att att underh˚alla. F¨or att f¨ors¨akra detta har god kontakt h˚allits med UTN:s nuvarande systemadministrat¨or, Daniel Fehrm, som var arbetets externa handledare.
Den sista m˚algruppen, UTN:s klubbverk, ansvarar f¨or UTN:s kontinuerliga pub- och festverksamheter [28]. Eftersom UTN:s klubbverk jobbar kontinuerligt under ˚aret med matservering kommer de att vara systemets prim¨ara anv¨andare. Det ¨ar d¨arf¨or av stor vikt att systemet anpassas f¨or att fungera bra med deras arbetss¨att och rutiner. UTN:s klubb-verk ans˚ags s˚aledes vara en bra m˚algrupp eftersom de kommer att anv¨anda systemet under en l¨angre period och har annorlunda krav j¨amf¨ort med till exempel forsr¨annings-kommitt´en.
3
Syfte, m ˚al, och motivation
Historiskt har alla matbest¨allningar p˚a UTN:s evenemang skrivits ned f¨or hand p˚a pap-perslappar av serveringspersonal och fysiskt l¨amnats vidare till k¨oket. Systemet kan upplevas ha brister s˚asom ol¨asliga lappar, lappar som tappas bort eller lappar som ham-nat i fel ordning i k¨oket. Misstag som dessa kan leda till ¨okade v¨antetider och missn¨ojda kunder vilket i sin tur leder till en stressigare och jobbigare arbetsmilj¨o f¨or serverings-personalen p˚a evenemangen.
Det analoga systemet resulterar ¨aven i att UTN f¨orbrukar en m¨angd papper d˚a mat-best¨allningar skrivs p˚a lappar som sedan sl¨angs i slutet av varje arbetspass. De sl¨angs d˚a de inte kan ˚ateranv¨andas vilket ¨ar ett on¨odigt slitage p˚a s˚av¨al ekonomin som milj¨on. P˚a nationell niv˚a f¨orbrukar Sverige kvittopapper motsvarande 60 000 tr¨ad, varje ˚ar [34]. En del av denna f¨orbrukning kommer fr˚an de bongar som anv¨ands inom restaurangbran-schen.
F¨orenta nationerna har sammanst¨allt 17 stycken m˚al som en agenda f¨or h˚allbar utveck-ling p˚a global niv˚a [31]. Ett av dessa ¨ar m˚al nummer tolv, H˚allbar konsumtion och produktion, och str¨avar efter att bland annat minska m¨ansklighetens ekologiska fotav-tryck genom att s¨anka konsumtionen av varor och resurser [32]. F¨or att ˚astadkomma detta har ett antal delm˚al satts upp, bland annat delm˚al 12.5, Minska m¨angden avfall markant som knyter an v¨al till projektgruppens m˚al att minska f¨orbrukning av papper inom restaurangbranchen.
3 Syfte, m˚al, och motivation
3.1
Syfte
Projektet syftade p˚a att effektivisera och underl¨atta arbetet f¨or bar- och k¨okspersonal p˚a pubar och restauranger, som i dagsl¨aget anv¨ander fysiska best¨allningshanteringssystem, som exempelvis de matserveringsevenemang som anordnas av UTN eller Uppsalas stu-dentnationer. F¨or att uppn˚a detta str¨avade projektet efter att ¨andra bar- och k¨oksperson-alens arbetss¨att till att bli mer strukturerat och enkelt vilket kan leda till f¨arre misstag och ett mer effektivt arbete f¨or personal i s˚av¨al bar som k¨ok.
Projektet syftade ¨aven p˚a att minska f¨orbrukningen av papper som denna typ av best¨all-ningshanteringssystem inom restaurangbranschen medf¨or. Som tidigare n¨amnt f¨orbru-kar Sverige en stor m¨angd kvittopapper varje ˚ar, delvis genom det papper som anv¨ands f¨or att skriva ut bongar bland de olika restauranger och pubar i s˚av¨al studenternas Upp-sala som nationellt. Digitaliseringen av dessa system som projektet str¨avar att erbjuda hade s˚aledes varit ett steg mot att hj¨alpa F¨orenta nationerna uppn˚a deras globala m˚al nummer tolv genom att minska restaurangbranschens konsumtion av fysiska resurser.
3.2
M ˚al
Projektets m˚al var att uppfylla dessa tv˚a ovann¨amsnda syften genom utvecklingen av en webbapplikation. D˚a UTN, enligt systemadministrat¨or Daniel Fehrm, inte var villiga att k¨opa in ny h˚ardvara kr¨avdes det att applikationen skulle kunna k¨oras p˚a vanliga datorer, det vill s¨aga b¨arbara eller station¨ara datorer. Valet blev d¨arf¨or att utveckla en webbappli-kation som k¨ors direkt i en webbl¨asare. I grunden var m˚alet med appliwebbappli-kationen att kopp-la samman bar och k¨ok digitalt. Med hj¨alp av systemet ska serveringspersonal kunna l¨agga matbest¨allningar som sedan visas f¨or k¨okspersonalen via en sk¨arm i k¨oket. Detta innebar ocks˚a att systemet m˚aste vara kompatibelt med m˚anga olika operativsystem, webbl¨asare och sk¨armuppl¨osningar.
Eftersom studentpubar i allm¨anhet har ganska h¨og personaloms¨attning genom volon-t¨arer - bara UTN har ¨over 1000 engagerade studenter ˚arligen [27] - m˚aste systemet ocks˚a vara l¨att att anv¨anda f¨or att oerfaren personal l¨att kan komma ig˚ang. Ju enklare systemet ¨ar att anv¨anda, desto f¨arre misstag kommer ske och viljan att anv¨anda det ¨okar. Det bidrar till att n˚a det ena syftet: att minska kundmissn¨oje och f¨orb¨attra arbetsmilj¨on genom effektivare arbete.
Ett annat problem med det tidigare arbetss¨attet som framgick av projektets m˚algrupps-unders¨okningar (se avsnitt 5.1) var att livsmedelsansvariga inom varje m˚algrupp fann det sv˚art att uppskatta m¨angden livsmedel som skulle k¨opas in inf¨or varje evenemang. Enligt de livsmedelsansvariga ledde sv˚arigheten ofta till matsvinn d˚a de best¨allde f¨or
mycket mat. F¨or att motverka detta och p˚a s˚a vis bidra till att minska evenemangens milj¨op˚averkan i enlighet med FN:s m˚al nummer tolv, H˚allbar konsumtion och produk-tion, finns ett m˚al att systemet ska kunna visa grundl¨aggande statistik fr˚an alla tidigare evenemang, fr¨amst hur mycket, och vilken mat som serverats. Statistiken kan respekti-ve livsmedelsansvariga sedan anv¨anda f¨or att l¨attare uppskatta hur m˚anga portioner mat som kommer att serveras och p˚a s˚a s¨att minska matsvinnet.
Det sista m˚alet med projektet st¨alldes av UTN:s systemadministrat¨or. Eftersom syste-madministrat¨oren ¨ar en f¨ortroendevald post som f¨ornyas varje ˚ar m˚aste applikationen vara l¨attillg¨anglig f¨or systemadministrat¨oren. Det inneb¨ar att applikationens funktioner ska vara v¨aldokumenterade, k¨allkoden ska vara kommenterad och l¨attl¨aslig och kanske viktigast av allt att administrativa uppgifter ska kunna ske direkt i webbl¨asaren utan tillg˚ang till webbserverns terminal. Med administrativa uppgifter menas saker som att skapa och radera anv¨andarkonton eller att byta deras l¨osenord. Genom att g¨ora systemet mer l¨attillg¨angligt f¨or systemadministrat¨oren kommer applikationen att faktiskt kunna anv¨andas, och f˚a ett l¨angre liv genom b¨attre underh˚all.
3.3
Etiska aspekter
Eftersom applikationen kommer att anv¨andas av m˚anga olika personer i ett offentligt sammanhang beh¨ovdes en rad etiska aspekter tas i beaktning vid utvecklandet. Det finns framf¨or allt fyra grundprinciper som applikationen utvecklades efter. Dessa fyra prin-ciper tituleras Ethical Web Development, ¨ar skapade av Adam Scott och kan ses som ett manifest ¨over hur webbutvecklare borde arbeta vid utveckling av webbapplikatio-ner [25]. Dessa fyra etikprinciper ¨ar:
1. Webbapplikationen b¨or kunna anv¨andas av alla 2. Webbapplikationen b¨or fungera ¨overallt
3. Webbapplikationen b¨or respektera anv¨andarens integritet och s¨akerhet 4. Webbapplikationen b¨or visa h¨ansyn till andra utvecklare
3.3.1 Tillg ¨anglighet
Applikationen kommer att anv¨andas av personer med olika kulturell bakgrund, spr˚ak-kunskaper samt eventuella funktionshinder, vilket st¨aller krav p˚a att ha alla t¨ankbara anv¨andare i ˚atanke n¨ar man tar design- och funktionalitetsbeslut.
3 Syfte, m˚al, och motivation
F¨or att inkludera s˚a m˚anga anv¨andare som m¨ojligt anv¨andes engelska som spr˚ak i an-v¨andargr¨anssnittet ist¨allet f¨or svenska. Eftersom Uppsala universitet ¨ar ett internationellt universitet med m˚anga utbytesstudenter, har m˚anga studenter utl¨andsk bakgrund och talar m¨ojligtvis inte svenska och skulle d¨arf¨or haft sv˚arigheter att anv¨anda applikationen ifall det var gr¨anssnittsspr˚aket.
Vidare kan vissa anv¨andare ha en annan kulturell bakgrund d¨ar f¨arger och symboler har en annan metaforisk inneb¨ord [26]. I designprocessen har f¨arger anv¨ants f¨or att indikera status p˚a best¨allningar: gr¨on f¨or Ready, gul f¨or In Progress, gr˚a f¨or Waiting samt r¨od f¨or kritiska handlingar, till exempel att ta bort en best¨allning. Dessa f¨arger kan dock ha en annorlunda inneb¨ord f¨or m¨anniskor fr˚an andra kulturer. Till exempel anv¨ands r¨od ofta f¨or att symbolisera lycka och v¨alg˚ang i Kina [17]. Vidare anv¨ands symboler utan tillh¨orande text som bland annat pilar och pappersflygplan f¨or att indikera handlingsin-viter till funktionalitet. Dessa ¨ar f¨or m˚anga m¨anniskor i Sverige vedertagna symboler med k¨and inneb¨ord, men det ¨ar v¨art att ha i ˚atanke att det kan finnas kulturer d¨ar de inte har samma betydelse. F¨or att f¨orhindra att de f¨arger och symboler som anv¨ants i appli-kationen skapar missf¨orst˚and har varje handlingsinvit f¨ortydligats genom en f¨orklarande text som visas om man flyttar muspekaren ¨over symbolen, samt att f¨arger ocks˚a kom-pletteras med text.
Slutligen ¨ar det m¨ojligt att anv¨andare kan ha olika former av funktionshinder - till ex-empel f¨argblindhet, nedsatt syn eller nedsatt finmotorik. Som n¨amndes ovan anv¨ands f¨arger f¨or att indikera orderstatus. F¨or att underl¨atta f¨or personer med nedsatt syn att kunna urskilja orderstatus anv¨ands ¨aven stora textrubriker f¨or att markera orderstatus. Ordrar ¨ar ¨aven positionerade i separata kolumner baserat p˚a status. Vidare ¨ar knappar som anv¨ands frekvent tydligt markerade och med stor tr¨affyta f¨or att underl¨atta f¨or per-soner med nedsatt syn eller finmotorik. Tyv¨arr ¨ar applikationen inte anpassad f¨or alla former av funktionshinder, till exempel blindhet. Sammanfattningsvis anv¨ands oftast flera olika attribut f¨or att indikera funktionalitet och status. F¨arg, form och text anv¨ands parallellt f¨or att underl¨atta f¨or personer med funktionshinder.
3.3.2 Anv ¨andbarhet
Enligt den andra etiska grundprincipen f¨or webbutveckling b¨or webbapplikationer fun-gera ¨overallt p˚a olika typer av enheter. De b¨or vara responsiva, snabba, och om m¨ojligt kunna anv¨andas med s¨amre eller ingen internetuppkoppling [25].
Eftersom applikationen ¨ar utvecklad f¨or att anv¨andas i en specifik milj¨o p˚a ett specifikt s¨att ¨ar det inte lika viktigt att den fungerar p˚a alla olika typer av enheter. Applikationen ¨ar t¨ankt att anv¨andas i en bar- eller restaurangmilj¨o d¨ar pekplattor, b¨arbara och station¨ara datorer anv¨ands n¨astan uteslutande. Att anpassa applikationen f¨or mobiltelefoner har
d¨arf¨or inte prioriterats.
Applikationen beh¨over ha konstant kontakt med en databas f¨or att kunna logga in samt skapa, ¨andra och ta bort ordrar. Applikationen fungerar d¨arf¨or inte offline d˚a det har f¨orutsatts att internetuppkoppling finns tillg¨angligt i de t¨ankta anv¨andningsmilj¨oerna.
3.3.3 Integritet och s ¨akerhet
Den tredje etiska grundprincipen s¨ager att anv¨andares integritet och s¨akerhet ska vara v¨al skyddade. D¨arf¨or l˚ag stor fokus i utvecklandet av applikationen att anv¨andare av systemet ska kunna k¨anna sig trygga n¨ar de anv¨ander det och att eventuella personupp-gifter hanteras ansvarsfullt.
Att uppn˚a detta har varit relativt enkelt f¨or applikationen d˚a inga personuppgifter sparas ¨overhuvudtaget. Inloggning sker via f¨ordefinierade anv¨andare som representerar olika organisationer (l¨as mer om detta i avsnitt 9). Ett anv¨andarkonto f¨or personal kan allts˚a inte kopplas till en specifik person.
Applikationen kommunicerar med hj¨alp av protokollet HTTP, Hypertext Transfer Pro-tocol. Eftersom kommunikationen sker i klartext anv¨ands till¨agget HTTPS, Hypertext Transfer Protocol Secure f¨or att s¨akerst¨alla att inloggade sessioner inte kan bli kapade. HTTPS ¨ar ett till¨agg som uppr¨attar en krypterad anslutning mellan tv˚a enheter f¨or att vanlig HTTP-kommunikation ska kunna ske p˚a ett s¨akert s¨att. Vidare anv¨ander ¨aven UTN HTTPS vilket g¨or att HTTPS forts¨attningsvis kommer att anv¨andas n¨ar applika-tionen flyttas till UTN:s servrar.
3.3.4 H ¨ansyn till andra utvecklare
Den fj¨arde etiska grundprincipen som f¨oljts har varit att visa h¨ansyn till andra utveck-lare, dels f¨or medlemmarna i projektgruppen men ¨aven f¨or andra utvecklare som i framtiden eventuellt kan komma att ut¨oka eller underh˚alla kodbasen. Generellt inneb¨ar detta v¨aldokumenterad kod, tester, k¨allkontroll samt f¨oljandet av en enhetlig kodstan-dard [25]. Applikationens kodbas f¨oljer ¨aven f¨oretaget Airbnbs kodstankodstan-dard. Denna kodstandard ¨ar en upps¨attning regler om p˚a vilket s¨att kod ska skrivas och formateras, och ¨ar ocks˚a den mest anv¨anda kodstandarden inom industrin [21, sid. 47].
4 Relaterat arbete
3.4
Avgr ¨ansningar
Projektet ¨ar prim¨art inriktat p˚a Uppsalas studentpubar. P˚a grund av detta ¨ar applika-tionen anpassat efter ett visst arbetss¨att - n¨amligen att kunden sj¨alv g˚ar fram till baren f¨or att best¨alla mat som sedan antingen b¨ars ut av k¨okspersonalen eller h¨amtas vid en utl¨amningsplats av kunden. Applikation ¨ar allts˚a inte t¨ankt att anv¨andas av serverings-personal vid restauranger d¨ar best¨allningar tas av kund direkt fr˚an borden, och ¨ar d¨arf¨or till exempel inte designad f¨or mobila enheter med sm˚a sk¨armar som kan t¨ankas anv¨andas av denna personal f¨or att ta emot best¨allningar.
En annan avgr¨ansning som h¨arstammar fr˚an denna inriktning ¨ar att applikationen fo-kuserar p˚a matbest¨allningar. Applikationen skulle kunna utvidgas f¨or att ¨aven t¨acka in andra restaurangaspekter, till exempel dryckesbest¨allning, notor eller bordsbokning, men eftersom studentpubar i Uppsala generellt sett inte anv¨ander dessa valdes den funk-tionaliteten bort. Dryck serveras vanligtvis direkt n¨ar kunden best¨aller vid baren.
4
Relaterat arbete
I och med att restaurangbongar inte ¨ar n˚agot nytt koncept fanns det redan en del l¨os-ningar inom branschen. Till att b¨orja med fanns det ett stort utbud av kommersiella system, till exempel iZettle [11] eller Trivec [30]. iZettle ¨ar en kassasystemsl¨osning anpassad f¨or sm˚af¨oretag vars mjukvara ¨ar designad f¨or mobila enheter. Systemet ¨ar hu-vudsakligen t¨ankt f¨or anv¨andning i butik, men kan anpassas f¨or restaurangbruk och med hj¨alp av kvittoskrivare skriva ut bongar. Trivec ¨ar ett kassasystem designat med restau-ranger i ˚atanke, och har d¨arf¨or st¨od f¨or bland annat digitala bongar samt automatisk statistikf¨oring. Nackdelen med denna typ av kommersiella system var dock just kom-mersialismen - systemen licenseras med m˚anadskostnader vilket kan vara en betydande kostnad f¨or k˚ardrivna restauranger som UTN.
D˚a priset spelade stor roll f¨or UTN blev gratisprogram med ¨oppen k¨allkod relevanta. Exempel p˚a s˚adana system ¨ar Floreant POS [8] och Chromis POS [4]. Dessa tv˚a sy-stem var lite bredare funktionsm¨assigt ¨an de kommersiella produkterna, och var mer anpassningsbara f¨or att passa en s˚a bred m˚algrupp som m¨ojligt. P˚a grund av detta kunde de dock vara ganska sv˚ara att installera och deras breda funktionalitet blev ett hinder d˚a UTN bara var ute efter bongsystemet. Det finns ocks˚a en risk med att anv¨anda pro-gram med ¨oppen k¨allkod, d˚a mjukvaran kan ha ¨overgivits av utvecklaren och s˚aledes ¨ar f¨or˚aldrade.
kassasystem. Det inneb¨ar att de hanterar betalningar, kvitton, lagerh˚allning, skatt och s˚a vidare. Eftersom UTN redan hade existerande arkitektur f¨or dessa finesser blev all denna funktionalitet s˚aledes on¨odig.
Vid s¨okning efter mjukvara som var enklare och bara erbj¨od bongfunktionaliteten blev urvalet markant mindre. Det enda system som hittades, och som liknade den appli-kation som detta projekt str¨avade att skapa, var Kitchen View [24]. Kitchen View ¨ar ett system med ¨oppen k¨allkod som utvecklats ˚at en kyrka i USA f¨or att hantera deras matbest¨allningar. Systemet matchade till stor del det den externa intressenten fr˚agade efter - det ¨ar helt webbaserat, kostnadsfritt och modernt. Tyv¨arr finns en kritisk nackdel, n¨amligen att Kitchen View kr¨aver att verksamheten har ett kassasystem som ¨ar anslutet till onlineplattformen Square vilket UTN inte har.
Av denna orsak valde projektgruppen heller inte att f¨orgrena och bygga p˚a Kitchen View och modifiera systemet efter projektets specifikation. Detta beslut togs eftersom Kitchen Views systemarkitektur ¨ar s˚a t¨att utvecklat runt onlineplattformen Square och dess API att v¨aldigt mycket kod hade beh¨ovts skrivas om oavsett.
Vidare fanns det en annan funktion som UTN ville se i denna typ av applikation. P˚a sina k˚arhuspubar erbjuds medlemsrabatt till UTN:s medlemmar. F¨or att till˚ata barper-sonal m¨ojligheten att snabbt kontrollera om en kund ¨ar medlem eller ej ¨onskades d¨arf¨or att applikationen skulle kopplas till deras medlemsdatabas. Av f¨orklarliga sk¨al fanns denna funktion inte i n˚agot existerande system, utan blev en del av anpassningen till intressenten som projektet hade.
5
Metod, tillv ¨agag ˚angss ¨att och tekniker
Innan utvecklingen b¨orjade lades en stor del tid ner p˚a planering av systemet och dess funktionalitet. H¨ar f¨ordes en dialog med den externa intressenten, Daniel Fehrm, dels f¨or att se till att de ramverk som valdes var kompatibla med UTN:s redan existerande webbsystem men ocks˚a f¨or att se till att det skulle vara s˚a anv¨andbart som m¨ojligt. Det gjordes ¨aven en m˚algruppsunders¨okning f¨or att unders¨oka vilka funktioner de t¨ankta m˚algrupperna skulle vilja se i systemet.
5.1
M ˚algruppsunders ¨
okning
M˚algruppsunders¨okningen bestod av ett kort fr˚ageformul¨ar som skickades ut till med-lemmarna i de tre m˚algrupperna fr˚an avsnitt 2.2 innan utvecklingen av applikationen
5 Metod, tillv¨agag˚angss¨att och tekniker
b¨orjade. Unders¨okningen var v¨aldigt enkel och bestod av tv˚a flervalsfr˚agor samt en fritextfr˚aga. De tv˚a flervalsfr˚agorna anv¨andes f¨or att f˚a en id´e om vem det var som svarat p˚a unders¨okningen och fritextfr˚agan anv¨andes f¨or att ta reda p˚a vad personen ville se f¨or funktionalitet i systemet. Fr˚agorna som skickades ut var:
• Vilken arbetsgrupp tillh¨or du?
– Svarsalternativ: Forsr¨anningskommitt´en, UTN:s klubbverk, UTN:s syste-madministrat¨or
• Vad ¨ar ditt prim¨ara arbetsomr˚ade?
– Svarsalternativ: Arbete i bar, Arbete i k¨ok, Varken eller • Vad skulle du vilja se f¨or funktioner i ett s˚adant h¨ar system?
– Svarsalternativ: Textf¨alt
Fr˚ageformul¨aret valdes att h˚allas kort och koncist f¨or att uppmuntra fler deltagare att svara och med resonemanget att det projektgruppen tyckte var viktigast att f˚a ut av unders¨okningen var vilka funktioner m˚algruppen tyckte skulle underl¨atta deras arbete f¨or att se ¨over om n˚agot gl¨omts fr˚an den initiala prototypen.
Av totalt 35 inbjudna m˚algruppsdeltagare svarade sju stycken p˚a formul¨aret, en svarsfre-kvens p˚a 20 %. Trots ett l˚agt deltagande var svaren v¨alutvecklade och m˚anga funktioner lades till i projektplanen, bland annat ett ¨oppet API, m¨ojligheten att fritt specificera matpreferenser och m¨ojligheten att markera en best¨allning som under tillagning. En sammanst¨allning av m˚algruppsunders¨okningen g˚ar att l¨asa i bilaga A.
5.2
Ramverk
N¨ar det kommer till teknik f¨or utveckling av tj¨anstens anv¨andargr¨anssnitt valdes webbib-lioteket React. Andra alternativ som ¨overv¨agdes var Vue och Angular. Alla tre ramverk har mycket funktionalitet gemensamt och alla kan anv¨andas f¨or att producera komplexa webbapplikationer.
React valdes av flera anledningar. Till att b¨orja med ¨ar React bland de mest anv¨anda webbiblioteken inom industrin [29]. React anv¨ands av m˚anga stora f¨oretag och i popu-l¨ara applikationer som till exempel Instagram, Facebook och Airbnb vilket s¨akerst¨aller framtida utveckling och underh˚all. Dessutom finns det m˚anga m¨ojligheter att enkelt
integrera React med andra ramverk och bibliotek [5]. N˚agra nackdelar ¨ar att utveck-lingstakten p˚a ramverket ¨ar h¨og, det vill s¨aga att det ofta sl¨apps nya versioner av ram-verket med ut¨okad funktionalitet, och d¨arf¨or st¨alls det stora krav p˚a utvecklare att h¨anga med i utvecklingen och l¨ara sig nya funktioner. I viss grad kan detta ¨aven f¨orsv˚ara syste-madmininstrat¨orens underh˚allsarbete. Vidare beh¨over utvecklare l¨ara sig syntaxtill¨agget JavaScript XML, JSX, f¨or att kunna anv¨anda React effektivt [1]. JSX ¨ar en ut¨okning till JavaScripts spr˚aksyntax som underl¨attar utvecklingen d˚a utvecklare kan skriva Java-Script i ett m¨arkspr˚ak v¨aldigt likt HyperText Markup Language, HTML.
En stor anledning till att Angular inte valdes ¨ar att inl¨arningskurvan p˚ast˚as vara brant och kr¨aver k¨annedom om andra programmeringsabstraktioner [3, 18]. Likt React har Angular en stor anv¨andarbas och en aktiv gemenskap av personer som utvecklar mjuk-varan [5].
Vue ¨overv¨agdes men utesl¨ots p˚a grund av ett par orsaker. F¨or det f¨orsta ¨ar det fort-farande ett relativt nytt ramverk med en mindre gemenskap som underh˚aller och ut-vecklar j¨amf¨ort med de andra alternativen. F¨or det andra anv¨ands Vue i mycket mindre utstr¨ackning inom industrin j¨amf¨ort med React och Angular [12]. Det inneb¨ar st¨orre os¨akerhet kring framtida underh˚all och utveckling d˚a f¨arre stora akt¨orer ¨ar beroende av ramverket.
F¨or serverdelen, backend, valdes pythonramverket Django d˚a det var ett krav fr˚an v˚ar externa intressent. Django ¨ar s¨akert och f¨orebygger m˚anga vanliga attacker [20]. Ett par nackdelar med ramverket ¨ar att det ibland kan g¨ora webbapplikationen l˚angsam om arkitekturen ¨ar d˚aligt designad samt att det kr¨aver mycket konfiguration f¨or att komma ig˚ang.
Ett annat alternativ hade varit ramverket Flask. Flask ¨ar likt Django l¨ampligt f¨or att snabbt utveckla webbapplikationer, men anses vara l¨attare att l¨ara sig [19]. Dessutom p˚ast˚as Flask passa b¨ast f¨or enklare webbapplikationer eller statiska webbsidor med en sida.
5.3
Databas
PostgreSQL valdes som databas eftersom det var ett explicit krav fr˚an v˚ar externa intres-sent. Databasen ¨ar dock v¨alk¨and f¨or sin h¨oga s¨akerhet [22]. I kontrast till detta har det ¨aven vissa nackdelar - PostgreSQL anses till exempel vara l˚angsamt f¨or vissa typer av f¨orfr˚agningar [6]. Detta har dock inte p˚averkat arbetet negativt d˚a antalet f¨orfr˚agningar per sekund kommer vara s˚a pass l˚aga i och med att applikationen inte kommer ha m˚anga anv¨andare.
6 Systemstruktur
En annan databas som skulle ha kunnat anv¨ants ¨ar MySQL. En f¨ordel med MySQL ¨ar att det ¨ar det vanligaste systemet f¨or databashantering och d¨armed har brett st¨od och m˚anga tredjepartstill¨agg. I vissa fall ¨ar ¨aven MySQL snabbare ¨an PostgreSQL [10].
6
Systemstruktur
Den webbaserade applikationen som har byggts i detta projekt ¨ar uppbyggd av tre olika delar. Den f¨orsta delen ¨ar databasen som ¨ar en PostgreSQL-instans. I databasen sparas all information som beh¨over vara best˚aende. Till s˚adan information r¨aknas bland annat alla ordrar som l¨aggs, alla matr¨atter som finns och alla anv¨andare som ¨ar registrerade. Den andra delen ¨ar anv¨andargr¨anssnittet skrivet med biblioteket React. Det ¨ar genom denna del alla anv¨andare, ¨aven administrat¨orer, interagerar med applikationen. Gr¨ans-snittet ¨ar i sin tur uppbyggt av flera separata vyer: en inloggningsvy, en vy f¨or att v¨alja ett evenemang, en vy f¨or bar- och serveringspersonal, en vy f¨or k¨okspersonal, en vy f¨or administrat¨orer samt en vy f¨or att h¨amta och bygga statistik fr˚an tidigare genomf¨orda evenemang. Hur de olika vyerna sitter ihop och hur man navigerar mellan dem finns grafiskt representerat i figur 1.
Figur 1 Tr¨addiagram ¨over de olika vyerna och navigation mellan dem
Den tredje och sista delen ¨ar mellanhanden mellan anv¨andargr¨anssnittet och databasen som ¨ar skriven med hj¨alp av ramverket Django. Mellanhanden styr b˚ade autentiserings-processen f¨or att s¨akerst¨alla att enbart beh¨origa anv¨andare f˚ar h¨amta eller manipulera data och sj¨alva manipulationen av data genom att kommunicera direkt med databasen.
¨
Overgripande kommunicerar delarna genom att anv¨andargr¨anssnittet skickar f¨orfr˚ag-ningar till mellanhanden genom HTTPS. Mellanhanden inspekterar vad f¨or typ av f¨or-fr˚agan det ¨ar och om anv¨andaren ¨ar beh¨orig om beh¨orighet kr¨avs. D¨arefter, om det ¨ar en korrekt f¨orfr˚agan och anv¨andaren vid behov ¨ar beh¨orig, skickar mellanhanden motsva-rande operation till databasen f¨or att exempelvis h¨amta alla existemotsva-rande ordrar. Mellan-handen skapar sedan ett svar inkapslat i ett HTTPS-meddelande inneh˚allande eventuell data samt en statuskod som beskriver hur f¨orfr˚agningen behandlades och skickar tillba-ka svaret till anv¨andargr¨anssnittet. Anv¨andargr¨anssnittet tillba-kan d¨arefter agera p˚a statuskod och eventuell data i svaret. I figur 2 finns en illustration av det just beskrivna fl¨odet. En mer detaljerad genomg˚ang hur kommunikationen sker hittas under avsnitt 8.1.
Genom denna struktur har en god abstraktionsniv˚a uppn˚atts d˚a gr¨anssnittet inte ¨ar direkt beroende av en databas, och databasen inte direkt beroende av ett anv¨andargr¨anssnitt. Django, och d¨armed mellanhanden, ¨ar i sin tur byggt f¨or att samma kodbas ska fungera p˚a alla databaser som Django har st¨od f¨or (Django ¨ar database-agnostic, det vill s¨aga fungerar med olika sorters databaser) [7]. P˚a s˚a s¨att kan PostgreSQL-databasen enkelt bytas utan att beh¨ova g¨ora f¨or¨andringar i varken mellanhand eller anv¨andargr¨anssnitt, och anv¨andargr¨anssnittet kan bytas ut utan att beh¨ova g¨ora f¨or¨andringar i varken databas eller mellanhand.
Figur 2 ¨Overgripande fl¨odesschema f¨or applikationen
7
Krav och utv ¨arderingsmetoder
F¨or att applikationen skulle anses vara f¨ardig skulle den uppfylla tre krav. Dessa tre krav g¨allde anv¨andarv¨anlighet, responsivitet samt s¨akerhet.
7 Krav och utv¨arderingsmetoder
7.1
Anv ¨andarv ¨anlighet
Det f¨orsta kravet var att anv¨andargr¨anssnittet beh¨ovde vara enkelt och effektivt att an-v¨anda. Detta innebar att anv¨andare utan tidigare erfarenhet av systemet snabbt skul-le kunna l¨ara sig hur man anv¨ander det effektivt f¨or att hantera matbest¨allningar. F¨or att uppn˚a detta m˚al utf¨ordes anv¨andartester med personer fr˚an UTN:s klubbverk, d˚a det ¨ar den m˚algrupp som l¨ar anv¨anda systemet mest. I samband med anv¨andartesterna utv¨arderades systemet ocks˚a med hj¨alp av Nielsens tio heuristikprinciper f¨or att g¨ora sy-stemet mer anv¨andarv¨anligt. Detta genom att anv¨andartesterna hittade brister i applika-tionen och heuristikprinciperna sedan anv¨andes som riktlinjer f¨or att g¨ora f¨orb¨attringar. God kontakt uppr¨atth¨olls ocks˚a kontinuerligt med den externa intressenten, UTN:s sys-temadministrat¨or Daniel Fehrm, f¨or att f¨ors¨akra sig om att systemet skulle vara kompa-tibelt med de system som de anv¨ander.
7.1.1 Anv ¨andartester
Anv¨andartesterna gick till p˚a f¨oljande s¨att: F¨orst fick testpersonen n˚agra uppgifter att utf¨ora. De uppgifter som gavs till testpersonen var:
1. Logga in som anv¨andaren Bar 1 i organisationen Klubbverket.
2. G˚a in i barvyn och l¨agg en best¨allning p˚a en hamburgare och en glutenfri b¨arpaj med kundnummer 25 och ange att kunden sitter utomhus.
3. Byt till k¨oksvyn och ¨andra status p˚a den lagda best¨allningen till In Progress och sedan Done.
4. Byt tillbaka till barvyn och markera den lagda best¨allningen som levererad. M˚alet med testet var att testpersonen skulle klara av dessa uppgifter utan att g¨ora n˚agot fel, till exempel att specialkosten inte f¨oljde med best¨allningen. I m˚anga tester ¨ar det vanligt att det ¨aven s¨atts upp en tidsgr¨ans f¨or denna typ av anv¨andartest, till exempel att uppgifterna ska l¨osas inom tre minuter [2, sid. 142]. Tidsgr¨anser var dock inte en del av testerna som utf¨ordes av projektgruppen eftersom det inte fanns n˚agon s¨arskild motivation till att g¨ora det.
Samtidigt som testpersonen utf¨orde de angivna uppgifterna observerades testpersonen av en medlem av projektgruppen, och testpersonen uppmanades att h¨ogt s¨aga vad han eller hon t¨ankte enligt t¨ank-h¨ogt-metoden [2, sid. 140]. T¨ank-h¨ogt-metoden inneb¨ar att testpersonen h¨ogt s¨ager allt som han eller hon t¨anker och tycker medan testpersonen
utf¨or de givna uppgifterna, s˚a att det blir l¨attare f¨or observat¨orerna att f¨orst˚a hur test-personen t¨anker och tycker. N¨ar testtest-personen utf¨ort de angivna uppgifterna h¨olls en kort diskussion med testpersonen av observat¨oren. D¨ar fick testpersonen m¨ojlighet att uttryc-ka sin helhetsupplevelse av systemet och sina ˚asikter samt f¨orb¨attringsf¨orslag.
7.1.2 Nielsens tio heuristikprinciper
I ett f¨ors¨oka att ¨oka anv¨andbarheten har projektgruppen anv¨ant sig av Jakob Nielsens tio designheuristiker i samband med anv¨andartesterna. Dessa tio designheuristiker ¨ar tumregler f¨or att kunna kategorisera i princip alla typer av anv¨andbarhetsfel skapat av Jakob Nielsen [15]. Denna lista ¨ar en sammanst¨allning av forskning bedriven av Jakob Nielsen och Rolf Molich som publicerades ˚ar 1990 [14]. Dessa tio principer ¨ar vanliga att anv¨anda inom gr¨anssnittsdesign f¨or att analysera tester och system [2, sid. 139]. Resultatet av anv¨andartesterna kategoriserades baserat p˚a de tio tumreglerna f¨or att b¨attre kunna kartl¨agga var systemet hade som flest problem. Ett exempel p˚a hur dessa tumregler har anv¨ants ¨ar att systemet i s˚a stor m˚an som m¨ojligt l˚ater anv¨andaren ˚angra diverse handlingar inom systemet, vilket rekommenderas av tumregel nummer tre som ber¨or anv¨andarkontroll och anv¨andarfrihet, s˚a att en anv¨andare beh˚aller kontroll ¨aven om anv¨andaren g¨or misstag.
7.2
Responsivitet
Det andra kravet var att systemet skulle vara nog responsivt. F¨or detta sattes tre stycken tidsgr¨anser upp baserat p˚a Robert B. Millers forskning om responstid inom m¨anniska-dator-interaktion [13, sid. 271-272]:
• H¨ogst 0,1 sekund f¨or att reagera p˚a att en handling skett, till exempel att en knapp har tryckts p˚a, genom exempelvis en laddningsanimation eller ett byte av f¨arg. • H¨ogst 2 sekunder f¨or att ge anv¨andaren resultat p˚a en handling, till exempel att en
best¨allning byter status eller att en best¨allning skapas.
• H¨ogst 15 sekunder f¨or att systemet ska ladda data ˚at anv¨andaren, i systemet g¨aller denna tidsgr¨ans f¨or sammanst¨allning av statistik f¨or evenemang.
Applikationen utv¨arderades mot dessa krav genom att utf¨ora interna tester. F¨or de f¨orsta tv˚a tidsgr¨anserna testades responstiden genom enkel huvudr¨akning med motiveringen att det ¨ar l¨att att m¨arka om till exempel knappar tar l¨angre tid ¨an 0,1 sekunder att reagera.
8 Implementation
F¨or 15-sekunderskravet anv¨andes profileringsverktyg inbyggda i webbl¨asarna Firefox och Chromes utvecklarverktyg f¨or att m¨ata tiden det tog f¨or till exempel statistik att sammanst¨allas.
7.3
S ¨akerhet
Det tredje kravet som skulle uppfyllas bestod av tv˚a delkrav p˚a s¨akerhet. F¨orsta del-kravet var att autentiseringsprocessen beh¨ovde skyddas fr˚an sessionskapning, session hijacking. Det andra delkravet var att en obeh¨orig person inte skulle ha ˚atkomst till da-ta som lagrades i dada-tabasen. Detda-ta delkrav tog inte h¨ansyn till entiteter som har fysisk ˚atkomst till mellanhanden eller databasen alternativt som, exempelvis genom social ma-nipulation, har lyckats att komma ¨over inloggningsuppgifter till applikationen.
Det f¨orsta delkravet, skydd mot sessionskapning, utv¨arderades genom att s¨akerst¨alla att HTTPS anv¨ands f¨or all kommunikation mellan anv¨andargr¨anssnittet och mellanhanden. Det andra delkravet uppfylls d˚a f¨orsta delkravet uppfylls och all kommunikation mellan mellanhanden och databasen sker ¨over HTTPS.
8
Implementation
I f¨oljande avsnitt beskrivs hur kommunikationen mellan applikationens delar sker samt hur autentisering och s¨akerhet har implementerats.
8.1
Kommunikationen mellan systemets delar
Kommunikation mellan anv¨andargr¨anssnitt och mellanhand med tillh¨orande databas sker ¨over HTTPS via ett REST API. API st˚ar i sin tur f¨or Application Programming Interface och kan ¨overs¨attas till gr¨anssnitt. Ett gr¨anssnitt ¨ar ett f¨ordefinierat s¨att p˚a vil-ket tv˚a parter kan kommunicera med varandra utan att veta n˚agonting mer ¨an att de f¨oljer den specifikation gr¨anssnittet specificerar. REST st˚ar f¨or Representational State Transfer och ¨ar ett s¨att eller ramverk f¨or att bygga ett gr¨anssnitt f¨or datakommunikation mellan en klient och en server.
I mellanhanden har ett antal s˚a kallade ¨andpunkter definierats i f¨orv¨ag. En ¨andpunkt ¨ar en specifik webbadress som f¨oljer grundadressen till mellanhanden d¨ar mellanhan-den har specificerat vad som ska h¨anda vid ett HTTPS-anrop med en viss typ av me-tod/operation. I denna ¨andpunkt lyssnar mellanhanden efter HTTPS-anrop. Ponera att
webbadressen till mellanhanden ¨ar “www.mellanhand.se” och mellanhanden har speci-ficerat en ¨andpunkt “/orders” d¨ar den enda till˚atna metoden ¨ar GET (h¨amta data) vil-ket h¨amtar alla lagda ordrar i databasen. Ponera ocks˚a att anv¨andaren navigerar till en vy i anv¨andargr¨anssnittet som ska visa alla ordrar. F¨or att h¨amta alla ordrar skickar anv¨andargr¨anssnittet d¨arf¨or en HTTPS-f¨orfr˚agan till “www.mellanhand.se/orders” med metoden GET. Mellanhanden kommer att uppt¨acka och inspektera denna f¨orfr˚agan. In-spektionen g˚ar till genom att analysera vilken typ av metod som f¨orfr˚agan inneh˚aller, i detta fall GET, och om det ¨ar en till˚aten metod. I exemplet ¨ar det en till˚aten metod och mellanhanden kommer d¨arf¨or skicka en SQL-f¨orfr˚agan (Structured Query Language, ett standardiserat databasspr˚ak) till databasen som beg¨ar ut alla existerande ordrar. Svaret mellanhanden f˚ar fr˚an databasen serialiseras, det vill s¨aga transformeras till ett format anpassat f¨or att lagra data, till text i JavaScript Object Notation, JSON, ett standardi-serat dataformat. Den serialiserade datan kapslas in i ett HTTPS-svar med en l¨amplig HTTPS-statuskod, oftast 200, och skickas tillbaka till anv¨andargr¨anssnittet d¨ar datan av-serialiseras och visas f¨or anv¨andaren. Om ett fel uppst˚ar n˚agonstans i kedjan, exempelvis om webbl¨asaren skulle skicka en f¨orfr˚agan med en otill˚aten metod, kommer mellanhan-den skicka ett svar d¨ar statuskomellanhan-den i HTTPS-meddelandet ber¨attar f¨or webbl¨asaren vad f¨or n˚agot som gick fel.
8.2
Autentisering och s ¨akerhet
F¨or att obeh¨origa anv¨andare inte ska f˚a tillg˚ang till data som lagras i databasen finns ett autentiseringssystem p˚a plats som ocks˚a hanteras av mellanhanden. Autentiserings-systemet bygger p˚a att en systemadministrat¨or i f¨orv¨ag har skapat anv¨andarkonton med ett anv¨andarnamn samt l¨osenord och gett ut dessa uppgifter till en beh¨orig person, till exempel den ansvariga f¨or respektive organisation eller kommitt´e. Vederb¨orande m˚aste i sin tur dela uppgifterna vidare till de personer som ska anv¨anda systemet.
I avsnitt 8.1 beskrivs kommunikationen mellan systemets delar. Avsnittet beskriver dock bara en bit av hur anv¨andargr¨anssnittet framg˚angsrikt kommunicerar med mellanhan-den. Det ¨ar inte tillr¨ackligt att k¨anna till adressen till mellanhanden, vilka ¨andpunkter som finns samt vilka till˚atna metoder varje ¨andpunkt har f¨or att f˚a tillg˚ang till, eller manipulera, data i databasen.
Om man ˚aterg˚ar till exemplet i avsnitt 8.1 g˚ar det inte att beg¨ara alla ordrar fr˚an systemet genom att skicka en GET-f¨orfr˚agan till “www.mellanhand.se/orders” om inte den som skickar f¨orfr˚agan ocks˚a kan bevisa att den ¨ar beh¨orig att h¨amta datan. Beviset ¨ar extra data som skickas med f¨orfr˚agan i form av en autentiseringsnyckel. En s˚adan nyckel ges endast ut av mellanhanden till en anv¨andare om vederb¨orande kan, med hj¨alp av anv¨andarnamn och l¨osenord, bekr¨afta sin identitet. F¨or att bekr¨afta sin identitet kr¨avs
9 Hur anv¨ands applikationen?
ingen nyckel utan bara anv¨andarnamn och l¨osenord i korrekt dataformat som skickas med korrekt metod till en specifik ¨andpunkt som lyssnar efter autentiseringsf¨ors¨ok. Att besitta en s˚adan nyckel ger dock inte n¨odv¨andigtvis en anv¨andare full tillg˚ang till all data i databasen. En systemadministrat¨or best¨ammer vilka beh¨origheter en viss anv¨andare har, och d¨armed nyckeln som bekr¨aftar vederb¨orandes identitet, har. Det kan vara att anv¨andaren har r¨att att h¨amta men inte modifiera eller radera data. Dessutom ¨ar det inbyggt i systemet att alla organisationer eller kommitt´eer ¨ar isolerade fr˚an varandra, det vill s¨aga att de endast har tillg˚ang till datan de har skapat sj¨alva.
9
Hur anv ¨ands applikationen?
Det finns olika typer av funktioner tillg¨angliga i applikationen f¨or s˚a v¨al administrat¨orer som pubpersonal. En administrat¨or ska kunna skapa, radera och redigera en organi-sation, evenemang, anv¨andare eller menyartiklar. Personalen d¨aremot har tillg˚ang till begr¨ansad funktionalitet. Till exempel kan l¨agga till en order eller ¨andra status p˚a en order.
Vid start m¨ots anv¨andaren av inloggningsvyn, d¨ar f¨ordefinierade organisationer och anv¨andare kan v¨aljas mellan fr˚an rullgardinsmenyer, se figur 3. Observera att bara sys-temadministrat¨oren kan skapa nya anv¨andarkonton.
Efter inloggning presenteras evenemangsv¨aljarvyn d¨ar det evenemang som ¨ar relevant f¨or dagens verksamhet v¨aljs, se figur 4. Varje evenemang kan representera en f¨ors¨alj-ningsdag eller ett evenemang kan l¨opa ¨over flera dagar. Det ¨ar anv¨andaren som be-st¨ammer att skapa ett nytt evenemang varje g˚ang en f¨ors¨aljningsdag startas eller att l˚ata n˚agra dagar ing˚a i samma evenemang. Anv¨andaren kan s¨oka namnet p˚a ett evenemang i s¨okf¨altet. Om det inskrivna namnet p˚a ett evenemang redan har skapats ser man det som f¨orslag som anv¨andaren kan sedan markera det och klicka p˚a CONFIRM EVENT knappen. Men om inget evenemang matchar den inskrivna namnet ser anv¨andaren inga f¨orslag vilket betyder det inte finns n˚agot evenemang befintlig. Anv¨andaren kan fort-farande klicka p˚a CONFIRM EVENT knappen f¨or att skapa ett nytt evenemang med samma namn.
D¨arefter n˚ar anv¨andaren menyvyn d¨ar den kan v¨alja att g˚a in i n˚agon av vyerna bar, k¨ok eller statistik, se figur 5. Olika vyer ¨ar anpassade f¨or olika ¨andam˚al som underl¨attar arbe-tet f¨or bar- och k¨okspersonalen. Uppdelningen g¨or att personalen i baren och k¨oket har tillg˚ang till de funktioner och data som de beh¨over f¨or sina respektive ansvarsomr˚aden. I barvyn kan best¨allningar l¨aggas till, ¨andras och tas bort fr˚an systemet, se figur 6. Vid
skapandet av ordrar kan olika matr¨atter v¨aljas och ¨onskem˚al om specialkost samt even-tuella ¨ovriga noteringar skrivas in. Ordrar ges manuellt ett ordernummer f¨or att mat-cha den numrerade bordsskylt som utl¨amnas till kunden. Kundens medlemskap i stu-dentk˚aren kan ¨aven kontrolleras. Slutligen presenteras en ¨overblick av alla nuvarande ordrar och deras status. En order kan ha tre olika statusar som presenteras med olika f¨arger. I figuren ser man n˚agra ordrar i kolumnen All Orders. Gr¨ont visar en order som har statusen Done vilket inneb¨ar att maten ¨ar klar i k¨oket. Gult visar att en order h˚aller p˚a lagas och gr˚att visar en nylagd order som v¨antar p˚a att lagas.
K¨oksvyn best˚ar av tre kolumner som inneh˚aller alla nuvarande ordrar ordnade efter status, se figur 7. Varje order inneh˚aller information om ordernummer, best¨allningstid, matr¨atter, noteringar samt eventuella ¨onskem˚al om specialkost. Knappar markerade med pilar anv¨ands f¨or att flytta ordrar till andra kolumner vilket d¨armed ¨andrar deras status. Vidare syns det totala antalet matr¨atter som v¨antar p˚a att tillagas f¨or att ge k¨oksperson-alen en ¨overblick om hur m˚anga best¨allningar som finns, f¨or att bland annat f¨orhindra att maten pl¨otsligt tar slut.
I statistikvyn kan anv¨andaren v¨alja ett evenemang och se ett cirkeldiagram ¨over antalet matr¨atter som best¨alldes och f¨ordelningen mellan dessa, se figur 8. Statistiken hj¨alper pubverksamheten att kunna planera b¨attre inf¨or kommande evenemang, exempelvis hur mycket mat som beh¨over k¨opas in. Detta hj¨alper till att f¨orebygga matsvinn genom att livsmedelsansvariga slipper k¨opa f¨or mycket livsmedel som sedan inte kommer till anv¨andning och bidrar till en mer h˚allbar verksamhet.
10
Utv ¨arderingsresultat
I detta avsnitt beskrivs utv¨arderingsresultaten av de anv¨andartester som beskrevs i av-snitt 7.1.1, och alternativa testmetoder som inte kunde utf¨oras. En komplett samman-st¨allning av samtliga anv¨andartester finns i bilaga B. Anv¨andartesterna genomf¨ordes p˚a medlemmar av UTN:s klubbverk under en veckas period. Totalt utf¨ordes fem anv¨andar-tester, det vill s¨aga en provstorlek p˚a cirka 14 % av m˚algruppernas medlemmar.
10.1
Hur ˚aterkopplingen implementerats
Av de fem anv¨andartester som genomf¨ordes st¨otte inte n˚agon testperson p˚a n˚agot st¨orre problem som orsakade hinder under testsessionen. Alla testpersoner kunde klara alla uppdrag beskrivna i avsnitt 7.1.1 snabbt. D¨aremot gavs m˚anga v¨ardefulla ˚asikter om delar som var otydliga eller kunde f¨or¨andras.
10 Utv¨arderingsresultat
Figur 3 Applikationens inloggningsvy.
Figur 5 Applikationens menyvy.
10 Utv¨arderingsresultat
Figur 7 Applikationens k¨oksvy. Observera att proportionerna ¨ar ¨andrade f¨or l¨asbarhet.
Figur 8 Applikationens statistikvy. I figuren ses f¨ors¨aljningsstatistik fr˚an ett evenemang d¨opt SEKA 2019. I diagrammet ses hur m˚anga av varje r¨att som s˚alts.
Fem st¨orre anv¨andbarhetsproblem uppdagades tack vare anv¨andartesterna. Det f¨orsta som uppt¨acktes var att lagda best¨allningar tog f¨or mycket plats i barvyn. Det andra pro-blemet var att textstorleken p˚a vissa f¨alt var f¨or liten. Det tredje var att tv˚a textf¨alt, order-notering och specialkost, blandades ihop. Det fj¨arde var att testdeltagarna k¨ande att de inte hade tillr¨acklig kontroll ¨over att kunna ta bort specifika matr¨atter fr˚an en best¨allning. Det femte och sista anv¨andbarhetsproblemet var att det tar l˚ang tid f¨or anv¨andare att f˚a ˚aterkoppling vid ¨andring av orderstatus.
10.1.1 Lagda best ¨allningar tar f ¨or mycket plats
Lagda best¨allningar tar f¨or mycket plats i barvyn. Eftersom barpersonalen inte har lika stort behov att se lagda best¨allningar som k¨oket tyckte m˚anga av testdeltagarna att de redan lagda best¨allningarna tog upp f¨or mycket plats p˚a sk¨armen. De gav dessutom ett n¨astan ¨oversv¨ammande intryck n¨ar barvyn ¨oppnades f¨or f¨orsta g˚angen i och med att olika best¨allningar dessutom har olika f¨arger.
˚
Aterkopplingen adresserades genom att minska antalet kolumner med lagda best¨allning-ar fr˚an tv˚a till en samt att kolumnbredden f¨or best¨allningbest¨allning-arna minskades lite grann. Det gav ett st¨orre utrymme och fokus p˚a menyartiklarna vilket ¨ar den prim¨ara funktiona-liteten barpersonalen kommer utnyttja, och var mer i enlighet med Nielsens ˚attonde tumregel som s¨ager att man b¨or str¨ava efter en s˚a minimalistisk design som m¨ojligt [15, #8].
10.1.2 Storlek p ˚a text och ikoner
N˚agra testdeltagare uttryckte oro ¨over storleken p˚a text i vissa f¨alt. Oron bestod av att texten eventuellt kan vara sv˚arl¨ast p˚a grund av sin lilla storlek i till exempel k¨oket d¨ar datorn st˚ar p˚a ett l¨angre avst˚and ¨an vid normalt datorarbete.
Detta problem l¨ostes genom att text- och ikonstorlek ¨okades p˚a alla relevanta platser till en storlek som var l¨asbar fr˚an minst en arml¨angds avst˚and fr˚an projektgruppens sk¨armar. Avst˚andet texten ska vara l¨aslig p˚a valdes till en arml¨angd. Det beror p˚a att k¨okspersonalen beh¨over interagera med applikationen f¨or att bland annat ¨andra status p˚a matbest¨allningar vilket g¨ors antingen med peksk¨arm eller mus och tangentbord. De beh¨over s˚aledes vara p˚a en arml¨angds avst˚and vid anv¨andningen av peksk¨armen alter-nativt tillr¨ackligt n¨ara f¨or att kunna f¨olja muspekaren.
10 Utv¨arderingsresultat
10.1.3 Ihopblandning av ordernotering och specialkost
I barvyn finns det tv˚a stycken textf¨alt d¨ar man kan ange en ordernotering samt ange specialkost f¨or en matr¨att. F¨altet f¨or ordernoteringen ¨ar t¨ankt att anv¨andas f¨or att ange en notering som g¨aller hela best¨allningen och kan vara till exempel “Kund sitter utom-hus”. F¨altet f¨or specialkost, ˚a andra sidan, anv¨ands f¨or att ange specialkost f¨or en del av best¨allningen, till exempel att en speciell r¨att ska vara glutenfri. Eftersom applikationens spr˚ak ¨ar engelska var textf¨altet f¨or ordernotering d¨opt till Note och f¨altet f¨or specialkost d¨opt till Special request. Det framgick dock tydligt av anv¨andartesterna att skillnaden p˚a dessa tv˚a f¨alt inte var uppenbara, eftersom de dels l˚ag bredvid varandra, och dels var v¨aldigt lika varandra spr˚akm¨assigt. Detta ledde till att n¨ast intill alla testpersoner blandade ihop eller missf¨orstod dessa tv˚a f¨alt, vilket inte var i led med Nielsens andra heuristik som s¨ager att man ska anv¨anda spr˚ak som ¨ar bekant f¨or anv¨andaren [15, #2]. F¨or att ˚atg¨arda detta anv¨andbarhetsproblem ¨andrades texten p˚a dessa f¨alt till Order note och Modification f¨or ordernotering respektive specialkost. Vidare s¨arades f¨alten fr˚an varandra f¨or att f¨ortydliga olikheterna mellan de tv˚a och f¨altet f¨or ordernotering flyttades till siffertangentbordet d¨ar barpersonalen anger kundnummer f¨or att st¨arka kopplingen till hela best¨allningen.
Ett annat problem med specifikt specialkosten ¨ar att man m˚aste ange specialkost f¨or en r¨att innan man trycker p˚a meny-knappen i barvyn. Det g˚ar allts˚a inte att ange spe-cialkost i efterhand. F¨or att f¨ortydliga detta arbetsfl¨ode flyttades f¨altet f¨or spespe-cialkost ovan menyartiklarna f¨or att st¨arka kopplingen till matr¨atterna, och f¨or att uppmuntra ett top-down-fl¨ode. Se figur 6.
10.1.4 Ta bort enskilda r ¨atter fr ˚an en best ¨allning
Det fj¨arde problemet som framgick av anv¨andartesterna var att barpersonalen inte kunde ta bort enskilda matr¨atter fr˚an en best¨allning. Om man till exempel av misstag r˚akade l¨agga till tv˚a hamburgare i en best¨allning var det enda s¨attet att ta bort den ena ham-burgaren att b¨orja om best¨allningen p˚a nytt. Detta fungerade f¨orvisso, men testdelta-garna tyckte att det kunde bli ett irritationsmoment, och det stred mot Nielsens tredje anv¨andbarhetstumregel som uppmanar applikationsdesign att l˚ata anv¨andare r¨atta till misstag p˚a ett enkelt s¨att [15, #3]. F¨or att f¨orhindra denna frustration lades kryss till bredvid varje r¨att i den nuvarande best¨allningen som l¨at personalen ta bort enskilda r¨atter utan att beh¨ova ˚aterst¨alla en best¨allning helt.
10.1.5 L ˚angsam ˚aterkoppling
Det sista anv¨andbarhetsproblemet som uppdagades var att det tar l˚ang tid att f˚a ˚aterkopp-ling av ¨andringar av ordrar, n˚agot som gick emot Nielsens f¨orsta designprincip som s¨ager att anv¨andare b¨or f˚a feedback p˚a systemets status inom rimlig tid [15, #1]. Anv¨and-are ¨ar inte helt s¨akra p˚a att en knapptryckning, till exempel f¨or att ¨andra en order fr˚an “v¨antande” till “under tillagning”, faktiskt registrerades. Det gjorde att deltagarna ibland klickade flera g˚anger p˚a samma knapp.
Anledningen till att ˚aterkopplingen ¨ar l˚angsam beror i huvudsak p˚a att databasen har under utvecklingen varit geografiskt placerad i USA. Vid drifts¨attning av systemet kom-mer databasen vara n¨armare placerat rent geografiskt vilket ger snabbare responstider d˚a n¨atverksanropen f¨ardas en kortare str¨acka samt mellan f¨arre datorer. F¨or att ¨and˚a ge anv¨andaren ˚aterkoppling att knapptryckningar har registrerats inaktiveras knappen och ers¨atts med en laddningsikon tills att ¨andringen ¨ar genomf¨ord.
10.2
Antalet testdeltagare
Ett problem med anv¨andartesterna var att ett f¨arre ¨an ¨onskat antal personer deltog. Pro-jektgruppen bj¨od in anv¨andare alla tre m˚algrupperna, Forsr¨anningskommitt´en, UTN:s klubbverk samt UTN:s systemadministrat¨or. Det var dock bara medlemmar fr˚an UTN:s klubbverk var villiga att delta p˚a grund av den r˚adande pandemin.
Det l˚aga testdeltagandet var dock inte ett s¨arskilt stort problem d˚a man, enligt Niel-sens tidigare n¨amnda forskning om anv¨andbarhetstestning, finner ungef¨ar 85 % av alla anv¨andbarhetsfel redan efter de fem f¨orsta testerna [16]. Nielsen n¨amner ocks˚a att ef-fektiviteten av anv¨andartesterna minskar drastiskt efter fem tester, eftersom man hittar samma fel flera g˚anger. Detta beskriver han ¨ar ett sl¨oseri med tid, och tycker att det ¨ar b¨attre att g¨ora tre tester med fem deltagare (d¨ar man ¨andrar systemet efter varje testrun-da) ¨an ett enda test med 15 deltagare.
10.3
Tester under verkliga f ¨
orh ˚allanden
Tanken var fr˚an b¨orjan att utf¨ora dessa anv¨andartester under Forsr¨anningen 2020:s fes-tivalvecka. UTN valde dock att st¨alla in festivalen p˚a grund av Covid-19-pandemin vil-ket ¨andrade planerna f¨or de planerade testerna och de gjordes ist¨allet till att g¨oras en och en med de som hade m¨ojlighet att delta. Det ledde till att testningen inte blev lika verklighetstrogen som var t¨ankt fr˚an b¨orjan. En f¨ordel med detta var dock att
testning-11 Resultat och diskussion
en blev mer strukturerade d˚a testdeltagarnas beteende kunde observeras n¨armare och noggrannare. Dessutom kunde testerna ha ett fokusomr˚ade i taget, till exempel testa en funktionalitet i taget.
11
Resultat och diskussion
Resultatet av projektet ¨ar en fungerande webbapplikation f¨or best¨allningshantering av mat f¨or studentpubar och restauranger. Applikationen g¨or det m¨ojligt att ¨overg˚a fr˚an fy-siska pappersbongar till en digital orderhantering. Best¨allningshanteraren l¨oser proble-matiken med borttappade ordrar och otydlig text samt on¨odig f¨orbrukning av material som beskrevs i projektets syfte.
Applikationen best˚ar av flera olika vyer. Dessa ¨ar en inloggnings-, evenemangsv¨aljar-, bar-evenemangsv¨aljar-, k¨oks- och statistiksvy. Anv¨andare av systemet loggar in med konton skapade i f¨orv¨ag av systemadministrat¨oren. Varje konto tillh¨or n˚agon form av organisatorisk en-het som ska anv¨anda applikationen. Inloggningen sker ¨over en s¨aker HTTPS-anslutning vilket s¨akerst¨aller att sessionen inte kan bli kapad. I evenemangsv¨aljaren v¨aljs ett evene-mang dit alla best¨allningar knyts till. Vad ett eveneevene-mang representerar ¨ar upp till orga-nisationen men det kan till exempel kan motsvara en viss f¨ors¨aljningsdag. Evenemanget m˚aste v¨aljas innan de andra vyerna, bar, k¨ok och statistik, kan anv¨andas f¨or att kunna presentera relevanta ordrar, matr¨atter och statistik.
¨
Overlag har det uppsatta m˚alen som ben¨amns i avsnitt 3.2 uppn˚atts. Applikationen fun-gerar i de st¨orsta webbl¨asarna p˚a vanliga datorer. Vidare uppfyller applikationen m˚alet att koppla samman bar och k¨ok digitalt. Ordrar som l¨aggs i baren ses p˚a sk¨armen i k¨oket och kan direkt b¨orja tillagas.
Ett annat m˚al var att utveckla ett anv¨andarv¨anligt system som ¨ar l¨att att komma ig˚ang med f¨or ny personal. I de utf¨orda anv¨andartesterna lyckades alla testpersoner anv¨anda applikationen. Testerna p˚avisade ocks˚a vissa brister i applikationen som sedan korrige-rades, se avsnitt 10.1. Efter korrigeringarna gjordes bed¨omningen att m˚alet uppfyllts. Vidare fanns ett uppsatt m˚al att ta fram en statistikvy f¨or att underl¨atta planeringen av matink¨op. I den framtagna vyn kan anv¨andare ¨overblicka antalet best¨allningar och matr¨atter som best¨allts under ett evenemang eller en f¨ors¨aljningsdag. Det g¨or det l¨attare att i framtiden uppskatta hur mycket mat som beh¨over best¨allas till liknande tillst¨all-ningar och d¨armed reducera matsvinnet.
Ett annat m˚al var att det f¨ardiga systemet skulle vara v¨aldokumenterat och l¨attillg¨angligt f¨or systemadministrat¨orer. Detta m˚al nedprioriterades till f¨orm˚an f¨or de andra m˚alen. I
den slutliga applikationen saknas komplett dokumentation till applikationens funktioner och k¨allkoden ¨ar ej kommenterad. D¨aremot uppn˚addes m˚alet att g¨ora det l¨att f¨or syste-madministrat¨orer att g¨ora ¨andringar i webbl¨asaren utan djupare kunskap om systemet. Vid drifts¨attning kommer applikationen kompletteras med dokumentation.
Systemet har vissa brister i funktionalitet. En svaghet ¨ar att det tar l˚ang tid f¨or anv¨andare att f˚a ˚aterkoppling p˚a ¨andring av orderstatus p˚a grund av l˚anga svarstider fr˚an databa-sen som under systemets utveckling varit bel¨agen p˚a en server i USA. Som l¨angst har svarstider uppemot tv˚a till tre sekunder uppm¨atts med hj¨alp av webbl¨asaren utveck-lingsverktyg, vilket ¨ar just ¨over gr¨ansen f¨or det uppsatta m˚alet p˚a max tv˚a sekunder som beskrivs i avsnitt 7.2. Den l˚angsamma ˚aterkopplingen har negativa konsekvenser p˚a anv¨andarv¨anligheten och systemets upplevda responsivitet. N¨ar applikationen kommer att anv¨andas i produktion kommer d¨aremot databasen vara placerad n¨armare geografiskt vilket ger snabbare svarstider d˚a n¨atverksanropen f¨ardas en kortare str¨acka samt mellan f¨arre datorer. Det har funnits en ambition under projektets g˚ang att implementera re-altidsuppdateringar. Med realtidsuppdateringar hade orderstatus ¨andrats lokalt i realtid ist¨allet f¨or att g¨ora det efter n˚agra sekunders f¨ordr¨ojning d˚a en bekr¨aftelse fr˚an servern kommit tillbaka. Funktionen visade sig vara komplicerad att implementera och tiden r¨ackte d¨arf¨or inte till.
12
Slutsatser
Detta projekt har skapat en best¨allningshanterare i form av en webbapplikation som m¨ojligg¨or f¨or pubar och restauranger att hantera best¨allningar digitalt. Den skiljer sig fr˚an andra liknande l¨osningar bland annat genom att inte ha ett integrerat betalsystem, inget krav p˚a permanent installerad h˚ardvara och genom koppling till intressentens med-lemsdatabas.
Applikationen har all n¨odv¨andig funktionalitet som kr¨avs f¨or att s¨attas i produktion hos intressenten. Anv¨andare kan logga in s¨akert och v¨alja ett aktuellt f¨ors¨aljningsevene-mang. Kundbest¨allningar kan skapas, redigeras och tas bort av bar- och k¨okspersonalen. K¨okspersonalen kan ¨overblicka alla lagda best¨allningar och ¨andra status p˚a dem. Slut-ligen kan f¨ors¨aljningsstatistik ¨overblickas f¨or att utv¨ardera hur matink¨opet gick. Ut¨over dessa grundl¨aggande funktioner finns specifik funktionalitet anpassad f¨or intressenten, till exempel m¨ojligheten att kontrollera om en kund ¨ar medlem i organisationen.
Det ¨ar fullt m¨ojligt att vidareutveckla applikationen till att kunna anv¨andas av fler stu-dentpubar och -restauranger som vill digitalisera sin best¨allningshantering. Som n¨amnts ovan finns all basfunktionalitet som kr¨avs.
13 Framtida arbete
I anv¨andartesterna lyckades alla testpersoner genomf¨ora de f¨ordefinierade uppgifterna utan st¨orre problem. Viss f¨orvirring och os¨akerhet kring applikationens funktioner fanns - men ¨overlag uttrycktes positiva tankar om anv¨andargr¨anssnittet och arbetsfl¨odet.
13
Framtida arbete
Det finns fyra huvudsakliga f¨orb¨attringsomr˚aden till applikationen som beskrivs i detta avsnitt. Dessa ¨ar saker som antingen valts bort p˚a grund av tidsbrist, eller funktioner vars behov uppt¨ackts under utvecklingens g˚ang och s˚aledes inte inkluderats i arbetet.
13.1
Kundvy
Det f¨orsta f¨orb¨attringsomr˚adet ¨ar att skapa en kundvy d¨ar kunder kan g˚a in f¨or att se om deras best¨allning ¨ar f¨ardig. I dagsl¨aget b¨ar bar- eller k¨okspersonal ut maten och m˚aste d¨arf¨or hitta kunden med r¨att nummer bland potentiellt hundratals kunder. Under tiden maten b¨ars ut minskas effektiviteten i baren d˚a f¨arre personal ¨ar p˚a plats. Om kunden sj¨alv kan veta n¨ar maten ¨ar f¨ardig och var maten kan h¨amtas ut blir verksamheten d¨arf¨or effektivare.
13.2
Detaljerad statistik
Den andra f¨orb¨attringen ¨ar m¨ojligheten att visa detaljerad statistik ¨over arrangemangen. Det var en av de mest ¨onskade funktionerna fr˚an den genomf¨orda m˚algruppsunder-s¨okningen. Exempel p˚a vad som menas med detaljerad statistik ¨ar trender ¨over n¨ar under serveringstillf¨allet flest best¨allningar l¨aggs och genomsnittlig tid fr˚an lagd till levererad order. Dessutom ¨onskades m¨ojligheten att exportera den genererade statistiken till ett mer vedertaget dataformat som till exempel kalkylark.
13.3
Realtidsuppdateringar
Det tredje omr˚adet ¨ar att implementera realtidsuppdateringar av databasf¨or¨andringar. I dagsl¨aget finns inte realtidsuppdateringar, utan ist¨allet beg¨ar systemet all relevant da-ta fr˚an dada-tabasen med j¨amna mellanrum och fyller gr¨anssnittet med den. Det ¨ar en l¨osning som fungerar men som inte ¨ar speciellt effektiv, eftersom trafik g˚ar mellan
