{"id":1531,"date":"2019-10-16T18:39:51","date_gmt":"2019-10-16T18:39:51","guid":{"rendered":"https:\/\/rentabilitet.dk\/opgaver\/?page_id=1531"},"modified":"2019-10-16T20:03:11","modified_gmt":"2019-10-16T20:03:11","slug":"p2-konstruktion-og-afprovning-af-et-it-system","status":"publish","type":"page","link":"https:\/\/rentabilitet.dk\/opgaver\/semesterprojekter\/p2-konstruktion-og-afprovning-af-et-it-system\/","title":{"rendered":"P2 &#8211; Konstruktion og afpr\u00f8vning af et IT-system"},"content":{"rendered":"\n<h2>Karakter: 12<\/h2>\n\n\n\n<p><\/p>\n\n\n\n<p><\/p>\n\n\n<p>P2 PROJEKT<\/p>\n<p><strong>Midtbyens Tennisklub<\/strong><\/p>\n<h1>Konstruktion og afpr\u00f8vning af et<\/h1>\n<p><strong>IT-system<\/strong><\/p>\n<p><img loading=\"lazy\" width=\"3648\" height=\"1744\" class=\"wp-image-1534\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image.jpeg 3648w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-300x143.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-768x367.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-1024x490.jpeg 1024w\" sizes=\"(max-width: 3648px) 100vw, 3648px\" \/><\/p>\n<p>Gruppe B263<\/p>\n<p>Informationsteknologi &amp; Informatik &#8211; 2. semester Aalborg Universitet<\/p>\n<p>27. maj 2019<\/p>\n<p><img loading=\"lazy\" width=\"2500\" height=\"1592\" class=\"wp-image-1535\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-1.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-1.jpeg 2500w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-1-300x191.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-1-768x489.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-1-1024x652.jpeg 1024w\" sizes=\"(max-width: 2500px) 100vw, 2500px\" \/> F\u00f8rste Studie\u00e5r Informatik og<\/p>\n<p>Informationsteknologi<\/p>\n<p>Strandvejen 12-14<\/p>\n<p>9000 Aalborg http:\/\/tnb.aau.dk<\/p>\n<p><strong>Titel: Abstract:<\/strong><\/p>\n<table>\n<tbody>\n<tr>\n<td>\n<p>This report sets out to implement and evaluate an it-system for the tennis association Midtbyens Tennisklub. The problem that the system tries to solve is an inconvenient booking process where members have to book a time in a physical calendar in the clubhouse. The main part of the developed system is an online booking system for the tennis court, but the system also incorporates a message board, sign up, about us, contact, gallery and admin functionality. Other than the creation of the system this report also sets out to evaluate the system. This was done with two individual usability tests; one where six users tested the user side and one where two admins tested the admin side of the system. The report concludes that the system succeeded in solving the problem it aimed to by making the bookingprocess easier. The implementation of the system went well and only a few usability errors were found.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Midtbyens Tennisklub<\/p>\n<p><strong>Tema:<\/strong><\/p>\n<p>Konstruktion og afpr\u00f8vning af et IT-system<\/p>\n<p><strong>Projektperiode: <\/strong>For\u00e5rssemestret 2019<\/p>\n<p><strong>Projektgruppe:<\/strong><\/p>\n<p>BaIT\/INF B263<\/p>\n<p><strong>Deltagere:<\/strong><\/p>\n<p>Jakob R\u00f8nnest S\u00f8rensen<\/p>\n<p>Line Buch Christensen<\/p>\n<p>Mads Larsen Underbjerg<\/p>\n<p>Nicolai Harbo Christensen Stefan Emil Mundt<\/p>\n<p>Thomas Kristian Margon Vinther<\/p>\n<p><strong>Vejledere:<\/strong><\/p>\n<p>Heidi Nielsen<\/p>\n<p><strong>Anslag: <\/strong>150.903<\/p>\n<h2>Sidetal: 129 Bilagsantal: 5 Afleveringsfrist: 27. maj 2019<\/h2>\n<p><em>Rapportens indhold er frit tilg\u00e6ngeligt, men offentligg\u00f8relse (med kildeangivelse) m\u00e5 kun ske efter aftale med<\/em><\/p>\n<p><em>forfatterne.<\/em><\/p>\n<h1>Indhold<\/h1>\n<ol>\n<li><strong>Indledning 5<\/strong><\/li>\n<li><strong>Problemanalyse 6<\/strong>\n<ol>\n<li>Midtbyens Tennisklub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6\n<ol>\n<li>Bookingprocessen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6<\/li>\n<li>Nuv\u00e6rende IT-system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<\/li>\n<\/ol>\n<\/li>\n<li>Motivation for samarbejdet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<\/li>\n<li>Problemformulering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8<\/li>\n<\/ol>\n<\/li>\n<li><strong>Understanding 9<\/strong>\n<ol>\n<li>Interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9\n<ol>\n<li>Forberedelse inden interview . . . . . . . . . . . . . . . . . . . . . . . . . . 9<\/li>\n<li>Interviewformer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10<\/li>\n<li>Vores interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10<\/li>\n<\/ol>\n<\/li>\n<li>PACT Analyse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11\n<ol>\n<li>People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11<\/li>\n<li>Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12<\/li>\n<li>Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13<\/li>\n<li>Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14<\/li>\n<li>PACT efter interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<\/li>\n<\/ol>\n<\/li>\n<li>Udarbejdelse af kravspecifikationer. . . . . . . . . . . . . . . . . . . . . . . . . . 16\n<ol>\n<li>Kravspecifikationer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16<\/li>\n<li>MoSCoW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17<\/li>\n<li>Vores kravspecifikationer. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/li>\n<li><strong>Envisionment 22<\/strong>\n<ol>\n<li>Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22\n<ol>\n<li>Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22<\/li>\n<li>Navigationsmap og sekvensmodel for systemet . . . . . . . . . . . . . . . 23<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<ol>\n<li style=\"list-style-type: none;\">\n<ol>\n<li>Designprincipper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25<\/li>\n<li>Sketches og wireframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26\n<ol>\n<li>Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26<\/li>\n<li>Sketches for Midtbyens Tennisklub . . . . . . . . . . . . . . . . . . . . . . 28<\/li>\n<li>Wireframes for Midtbyens Tennisklub . . . . . . . . . . . . . . . . . . . . . 31<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<p><strong style=\"font-size: inherit;\">5. Physical design 34<\/strong><\/p>\n<ol>\n<li style=\"list-style-type: none;\">\n<ol>\n<li>Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34\n<ol>\n<li>Ikoner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34<\/li>\n<li>Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35<\/li>\n<li>Gestaltlovene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35<\/li>\n<li>Farvevalg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36<\/li>\n<li>Closure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36<\/li>\n<\/ol>\n<\/li>\n<li>Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36\n<ol>\n<li>Menubaren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36<\/li>\n<li>Bookingkalenderen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38<\/li>\n<li>Knapper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<p><strong>6. Implementering 43<\/strong><\/p>\n<ol>\n<li style=\"list-style-type: none;\">\n<ol>\n<li>Sprog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43<\/li>\n<li>Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46\n<ol>\n<li>Oprettelse af forbindelse til databasen. . . . . . . . . . . . . . . . . . . . 47<\/li>\n<\/ol>\n<\/li>\n<li>Princippet bag booking systemet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48<\/li>\n<li>Bookingkalenderen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50<\/li>\n<li>Log-ind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64<\/li>\n<li>\u00c6ndring af tekst og billeder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68\n<ol>\n<li>Redigering af tekst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69<\/li>\n<li>Redigering af billeder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70<\/li>\n<\/ol>\n<\/li>\n<li>Medlemsh\u00e5ndtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71<\/li>\n<li>Fra implementering til usability. . . . . . . . . . . . . . . . . . . . . . . . . . . . 75<\/li>\n<li>&nbsp;<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<p><strong>7. Evaluering 76<\/strong><\/p>\n<ol>\n<li style=\"list-style-type: none;\">\n<ol>\n<li style=\"list-style-type: none;\">\n<ol>\n<li>Testplanl\u00e6gning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76\n<ol>\n<li>Form\u00e5let med testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76<\/li>\n<li>Metodeafsnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76<\/li>\n<li>Testens forl\u00f8b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77<\/li>\n<li>Succeskriterier for systemet . . . . . . . . . . . . . . . . . . . . . . . . . . . Testpersoner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80<\/li>\n<li>Testopgaver&nbsp;. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81<\/li>\n<li>Databehandling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86\n<ol>\n<li>Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86<\/li>\n<li>Klassificering af problemer i testen for medlemmer. . . . . . . . . . . . 87<\/li>\n<li>Klassificering af problemer i testen for administratorer. . . . . . . . . 90<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<ul>\n<li style=\"list-style-type: none;\">\n<ul>\n<li>&nbsp;<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><strong>8. Konklusion 102<\/strong><\/p>\n<p><strong>Bibliografi 103<\/strong><\/p>\n<p><\/p>\n<p><\/p>\n<p><strong>Kapitel1<\/strong><\/p>\n<h1>Indledning<\/h1>\n<p>Denne rapport vil gennemg\u00e5 konstruktionen og evalueringen af et IT-system for Midtbyens<\/p>\n<p>Tennisklub. Den grundl\u00e6ggende interesse for foreningen startede ved at et medlem i gruppen berettede om en problematisk bookingproces. Bookingprocessen foregik ved at medlemmerne fysisk skulle skrive sig i kalenderen i klubhuset.<\/p>\n<p>Foreningen blev derfor kontaktet, da vi gerne ville unders\u00f8ge problematikken n\u00e6rmere. Bestyrelsesformanden, samt kasseren, udtalte, at en stor andel af medlemmerne i foreningen omgik bookingprocessen, hvilket begyndte at blive problematisk, da medlemsantallet i foreningen er blevet st\u00f8rre de senere \u00e5r. Ydermere berettede gruppemedlemmet at der, ved den \u00e5rlige standerhejsning, var flere medlemmer, der udtalte sig omkring problematikken ang\u00e5ende den nuv\u00e6rende bookingproces. Problemet var blandt andet, at banen ofte var optaget, hvilket resulterede i at medlemmer uden en booket tid, kom forg\u00e6ves til banen. Herudover udtalte bestyrelsesformanden ogs\u00e5, at han \u00f8nskede at banen blev benyttet mere i fremtiden, hvortil den nuv\u00e6rende bookingproces kan v\u00e6re problematisk.<\/p>\n<p>Foreningen valgte derfor at indg\u00e5 i et samarbejde med os, da vi havde frembragt id\u00e9en om et online bookingsystem.<\/p>\n<p>Rapporten vil beskrive processen fra den initierende kontakt til det f\u00e6rdigt udviklede system. F\u00f8rst vil problematikken belyses yderligere for at f\u00e5 et bedre indblik i, hvordan problemet kan l\u00f8ses bedst muligt i forhold til foreningens interesser. Derefter gennemg\u00e5s de benyttede udviklingsfaser; Understanding, Envisionment, Physical design, Implementering og Evaluering. Dette vil give et indblik i processen for systemets udvikling fra id\u00e9 til f\u00e6rdigt produkt.<\/p>\n<p>Afslutningsvis diskuterer vi processen og konkluderer p\u00e5 vores resultater.<\/p>\n<h1>Kapitel2 Problemanalyse<\/h1>\n<h2>2.1 Midtbyens Tennisklub<\/h2>\n<p>Midtbyens Tennisklub er bygget p\u00e5 baggrund af ildsj\u00e6les irritation over, at tennisklubberne i omr\u00e5det var fyldte, og tid p\u00e5 banerne var sparsom. Det blev startskuddet til en lille lokal tennisklub med \u00e9n enkelt bane i Aalborg midtby. Foreningens v\u00e6rdier bygger p\u00e5 hygge, f\u00e6llesskab og plads til alle, hvilket foreningens motto, \u201cLivsnydernes Klub\u201d, ogs\u00e5 afspejler ganske pr\u00e6cist [interview med bestyrelsesformanden].<\/p>\n<p>Foreningen har i dag flere medlemmer, end de har haft i lang tid. Hvor det tidligere har v\u00e6ret muligt blot at tage ned p\u00e5 banen og spille uden at reservere en tid, er der i dag langt mindre chance for at det er muligt, da banen i dag bliver benyttet mere end den l\u00e6nge er blevet [interview med kasseren].<\/p>\n<h3>2.1.1 Bookingprocessen<\/h3>\n<p>N\u00e5r et medlem i dag skal booke en tid p\u00e5 foreningens bane, foreg\u00e5r det fysisk i det lille tilh\u00f8rende klubhus ved banen. Her er der en kalender, hvori der skrives navn og tidsrum ind, og derved g\u00f8r andre opm\u00e6rksomme p\u00e5, at lige netop p\u00e5 det tidspunkt er banen optaget. Tiderne m\u00e5 if\u00f8lge foreningens regler kun bookes \u00e9n af gangen af en times varighed, s\u00e5ledes at medlemmer ikke kan reservere banen flere dage i tr\u00e6k. Processen er transparent i forhold til andre medlemmers navne og l\u00e6gger ikke skjul p\u00e5 hvem, som er der hvorn\u00e5r.<\/p>\n<p>Tager medlemmer spontant ned i foreningen, og banen ikke er i brug, er der frit lejde til at spille, men s\u00e5fremt banen er booket, og personen med reservationen dukker op senest 15 minutter efter tidens begyndelse, overlades banen til denne person [interview med bestyrelsesformanden].<\/p>\n<h3>2.1.2 Nuv\u00e6rende IT-system<\/h3>\n<p>Midtbyens Tennisklub nuv\u00e6rende website har adressen www.mtk9000.dk [Tennisklub n.d.]. Websitet er simpelt opbygget og leverer prim\u00e6rt informationer til nuv\u00e6rende, samt eventuelt interesserede og kommende medlemmer. Den er oprettet og hostet gennem 123hjemmeside.dk [123hjemmeside.dk n.d.].<\/p>\n<p><img loading=\"lazy\" width=\"1972\" height=\"824\" class=\"wp-image-1536\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-2.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-2.jpeg 1972w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-2-300x125.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-2-768x321.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-2-1024x428.jpeg 1024w\" sizes=\"(max-width: 1972px) 100vw, 1972px\" \/><\/p>\n<p><strong>Figur 2.1: <\/strong>Billede af nuv\u00e6rende hjemmeside: http:\/\/www.mtk9000.dk\/<\/p>\n<p>P\u00e5 sitet findes der enkelte informationer om kommende begivenheder, indmeldelse og kontaktinformationer til foreningens bestyrelse. Opbygningen og navigationen er simpel, og alt p\u00e5 siden tilg\u00e5s gennem menubaren i \u00f8verst p\u00e5 siden. Der er sparsomme interaktionsmuligheder p\u00e5 sitet, og disse er kun at finde som kontaktformularer under siden <em>Indmeldelse <\/em>og <em>Kontakt<\/em>. Flere af siderne er uden information, hvilket g\u00f8r at siden fremst\u00e5r uf\u00e6rdig eller ubenyttet.<\/p>\n<h2>2.2 Motivation for samarbejdet<\/h2>\n<p>Det indledende interview med bestyrelsesformanden gav indblik i foreningens motivation for at indg\u00e5 i et samarbejde. Bestyrelsesformanden n\u00e6vnte bl.a. at foreningen gerne vil have flere medlemmer, s\u00e5 den kan vokse sig st\u00f8rre, samt for at f\u00e5 fornyet energi ind. De nye kr\u00e6fter til foreningen skal v\u00e6re med til at f\u00f8re foreningen videre og bevare dens v\u00e6rdier. Desuden n\u00e6vnte bestyrelsesformanden, at foreningen ikke har interesse i at tjene penge, men derimod kun at se banen blive brugt mere end den g\u00f8r i dag.<\/p>\n<p>Bestyrelsesformanden ville gerne hj\u00e6lpe os og kunne samtidigt se fordelene i et online bookingsystem, da det kunne v\u00e6re med til at skabe mere engagement i foreningen og samtidig underst\u00f8tte et \u00f8get antal medlemmer [interview med bestyrelsesformanden].<\/p>\n<h2>2.3 Problemformulering<\/h2>\n<p>Med udgangspunkt i ovenst\u00e5ende observationer og kontakt med foreningen, er der blevet belyst nogle problemstillinger. F\u00f8rst og fremmest er der den nuv\u00e6rende bookingproces, som er tidskr\u00e6vende og besv\u00e6rlig for foreningens medlemmer. Dette har skabt en klubkultur, hvor bookingprocessen ofte bliver omg\u00e5et, og hvor medlemmerne tager ned p\u00e5 banen uden at booke i forvejen, og h\u00e5ber p\u00e5 at banen er ledig. For det andet, har foreningen en vision om at erhverve flere medlemmer, s\u00e5 banens potentiale i h\u00f8jere grad kan blive udnyttet. Dette kunne skabe problemer for den nuv\u00e6rende bookingproces, i og med sandsynligheden for at banen tilf\u00e6ldigvis er ledig vil blive formindsket mere, end den er i forvejen. P\u00e5 baggrund af dette, er vi kommet frem til f\u00f8lgende problemformulering:<\/p>\n<p><em>Hvordan kan vi designe og konstruere et IT-system, som underst\u00f8tter foreningens \u00f8nske om st\u00f8rre brug af banen?<\/em><\/p>\n<p><strong>Kapitel3<\/strong><\/p>\n<h1>Understanding<\/h1>\n<p>Ved udviklingen af et IT-system er det vigtigt at forst\u00e5, hvem der udvikles til. I det f\u00f8lgende afsnit gennemg\u00e5s teorien for interview, da vi benytter denne unders\u00f8gelsesmetode til at opn\u00e5 mere viden om vores problem. Derefter vi vil udarbejde en PACT analyse med l\u00f8bende beskrivelser af teorien. Denne vil hj\u00e6lpe i den efterf\u00f8lgende proces, hvor kravene til systemet skal udarbejdes.<\/p>\n<h2>3.1 Interview<\/h2>\n<p>Et interview er en form for samtale, som sigter p\u00e5 at udlede samtalepartnerens viden, opfattelse, meninger eller vurderinger om et bestemt emne. Intervieweren kan v\u00e6re en fremmed person, der \u00f8nsker indsigt indenfor et omr\u00e5de, som samtalepartneren er en del af. En meningsfuld samtale mellem intervieweren og samtalepartneren opst\u00e5r bedst, hvis intervieweren har forh\u00e5ndsviden om det dom\u00e6ne samtalepartneren befinder sig i [Riis 2004, side 75-76].<\/p>\n<p>Vi har valgt at benytte os af et interview, da vi har adgang til en repr\u00e6sentant i den forening, som vi besk\u00e6ftiger os med. Interviewformen bidrager ogs\u00e5 til vores PACT analyse, da vi via et interview b\u00e5de kan f\u00e5 data til at analysere personerne i den forening vi besk\u00e6ftiger os med, samtidig med at vi kan f\u00e5 oplysninger omkring de aktiviteter, der foreg\u00e5r i foreningen. Derudover kan vi ogs\u00e5, via interviewformen, indsamle data omkring konteksten i foreningen, samt om den teknologi foreningen g\u00f8r brug af.<\/p>\n<h3>3.1.1 Forberedelse inden interview<\/h3>\n<p>Inden interviewets start er det vigtigt at vide, hvem der interviewes, hvor interviewet kommer til at foreg\u00e5, samt hvad der gerne vil opn\u00e5s med interviewet. I det sociologiske interview repr\u00e6senterer samtalepartneren en social type, en gruppe eller en organisation. Dette er den interviewede bevidst om, hvilket kan skabe restriktioner i forhold til, hvad personen f\u00f8ler,<\/p>\n<p><em>3.1. INTERVIEW<\/em><\/p>\n<p>denne kan eller ikke kan sige [Riis 2004, side 76-77]. Interviewets placering kan p\u00e5virke forl\u00f8bet. Hvis stedet er fremmed for samtalepartneren, vil denne v\u00e6re en g\u00e6st hos intervieweren, men hvis interviewet foreg\u00e5r p\u00e5 samtalepartnerens arbejdsplads eller i dennes hjem, kan det give en tryghed for samtalepartneren. Dog kan det give en begr\u00e6nsning i form af de svar, som den interviewede giver, eller de forstyrrelser denne kunne opleve gennem interviewet [Riis 2004, side 77].<\/p>\n<p>Intervieweren har til form\u00e5l at styre samtalen, s\u00e5 den holder sig inden for den problemstilling, som er fundet inden interviewet. Det er samtidig vigtigt at interviewerens kropssprog og reaktioner f\u00f8lger samtalens udformning og tempo, s\u00e5 samtalepartneren forbliver afslappet under interviewet. Ydermere er det vigtigt at begge parter er p\u00e5 b\u00f8lgel\u00e6ngde, og intervieweren skal desuden turde sp\u00f8rge ind til emner, som intervieweren kunne v\u00e6re i tvivl om eller misforst\u00e5 [Riis 2004, side 78-80].<\/p>\n<h3>3.1.2 Interviewformer<\/h3>\n<p>Et interview kan udf\u00f8res p\u00e5 flere forskellige m\u00e5der, alt efter, hvad der \u00f8nskes at opn\u00e5 med selve interviewet. Der kan g\u00f8res brug af tre forskellige former for interview; det strukturerede, det semi-strukturerede og det ustrukturerede.<\/p>\n<p>Det semi-strukturerede interview bygger p\u00e5 en fri form for interview. Her er intervieweren forberedt med nogle sp\u00f8rgsm\u00e5l, men der er rig mulighed for at ber\u00f8re andre relevante eller pludseligt opst\u00e5ede emner i l\u00f8bet af interviewet. P\u00e5 den m\u00e5de er der mulighed for at opn\u00e5 en masse data, som ber\u00f8rer det emne, der er i fokus fra mange forskellige vinkler. Denne form for interview kan dog v\u00e6re meget kr\u00e6vende for den interviewede, da denne ofte vil blive spurgt om en lang r\u00e6kke uddybende sp\u00f8rgsm\u00e5l, som f\u00f8lge af, eller udover, de egentligt forberedte sp\u00f8rgsm\u00e5l fra intervieweren [Benyon 2014, side 143].<\/p>\n<h3>3.1.3 Vores interview<\/h3>\n<p>Vi har valgt at benytte os af det semi-strukturerede interview, da vi \u00f8nsker besvarelse af en r\u00e6kke sp\u00f8rgsm\u00e5l, som kan bidrage til vores udarbejdelse af det p\u00e5g\u00e6ldende IT-system. Det er ogs\u00e5 en fordel at benytte denne interviewform, da vi er uerfarne interviewere [Riis 2004, side 89].<\/p>\n<p>P\u00e5 baggrund af vores indledende PACT-analyse har vi udledt en r\u00e6kke sp\u00f8rgsm\u00e5l, som vi fandt relevante for at skabe en vis form for struktur, men med mulighed for at stille uddybende sp\u00f8rgsm\u00e5l undervejs.<\/p>\n<h2>3.2 PACT Analyse<\/h2>\n<p>Mennesker bruger teknologi til forskellige aktiviteter i forskellige kontekster. Det er derfor vigtigt at forst\u00e5 og designe systemet efter den sammenh\u00e6ng, det skal bruges i, og de folk det skal bruges af. Dette kan v\u00e6re komplekst at analysere, s\u00e5 derfor bruger vi PACT-modellen for at sikre os, at vi har taget h\u00f8jde for de elementer, som systemet skal kunne rumme. PACT st\u00e5r for People, Activities, Context og Technology [Benyon 2014, side 25]. Modellen tager h\u00f8jde for mange faktorer, som er vigtige at overveje for at designe et system. Vi vil gennemg\u00e5 teorien bag de enkelte elementer i PACT-modellen, og l\u00f8bende applicere dem i forhold til vores projekt. Vi tager udgangspunkt i vores umiddelbare viden om omr\u00e5det i denne analyse, og vi vil derfor foretage nogle antagelser. Senere hen vil vi supplere antagelserne med viden fra interviewet med bestyrelsesformanden for foreningen, hvor vi vil have f\u00e5et be- eller afkr\u00e6ftet mange af antagelserne (se afsnit 3.2.5). Uanset om vores antagelser er korrekte eller ukorrekte, har PACT analysen hjulpet med processen i at forst\u00e5 dom\u00e6net og forst\u00e5, hvad der er relevant at observere i foreningen samt sp\u00f8rge om i interviewet.<\/p>\n<h3>3.2.1 People<\/h3>\n<h4>Teori<\/h4>\n<p>Det er vigtigt at forst\u00e5 brugerne af systemet og deres forskelligheder samt at tage h\u00f8jde for dem, n\u00e5r der designes et interaktivt system til mennesker. Det er de fysiske, psykologiske og sociale forskelle, der skal t\u00e6nkes ind i designprocessen. Fysiske forskelle kan v\u00e6re alt fra h\u00f8jde og v\u00e6gt til fingerst\u00f8rrelse. Der skal eksempelvis tage h\u00f8jde for fingerst\u00f8rrelse og synet, i designet af ikoner og knapper til et system [Benyon 2014, side 27]. I forhold til psykologiske forskelle er det eksempelvis spatiale f\u00e6rdigheder <sup><sup><a id=\"post-1531-footnote-ref-1\" href=\"#post-1531-footnote-1\">[1]<\/a><\/sup><\/sup>, hukommelse, sindslidelser, koncentration samt forskellige persontyper [Benyon 2014, side 30-31].<\/p>\n<p>Et andet aspekt, som er vigtigt, n\u00e5r der designes et IT-system, er de sociale forskelle mennesker imellem. Brugere kan have forskellige motivationer for anvendelsen af et IT-system, og deres erfaringer med IT-systemer kan variere meget [Benyon 2014, side 33]. Hvis opgaven er at designe et IT-system til en bredere m\u00e5lgruppe, kan der v\u00e6re store forskelle p\u00e5 deres f\u00e6rdigheder i IT-systemer generelt. Det skal tilgodeses og designes efter, s\u00e5 alle i systemets m\u00e5lgruppen, uanset f\u00e6rdighedsniveau, kan benytte sig af systemet [Benyon 2014, side 33]. I forl\u00e6ngelse af det, skelnes der ogs\u00e5 mellem heterogene og homogene grupper. En heterogen gruppe er en gruppe af mennesker, som har forskellige foruds\u00e6tninger og form\u00e5l med brugen af et IT-system. En homogen gruppe best\u00e5r af personer, som udf\u00f8rer den samme handling, har samme form\u00e5l, samt f\u00e6rdigheder for brugen af et IT-system [Benyon 2014, side 33].<\/p>\n<h4>Analyse<\/h4>\n<p>Med udgangspunkt i Midtbyens Tennisklub skal vi tage h\u00f8jde for, at der b\u00e5de er \u00e6ldre og unge spillere i foreningen, og de derfor kan have forskellige fysiske foruds\u00e6tninger, s\u00e5som forskellige grader af syn og fingerst\u00f8rrelser. I forhold til fysiske handicap regner vi ikke med, at vi skal tage store forbehold i designet af systemet, da vi arbejder med en tennisklub, hvor selve aktiviteten er relativt fysisk kr\u00e6vende.<\/p>\n<p>Derudover skal der tages h\u00f8jde for psykologiske forskelle, da vi regner med, at det er en bred aldersgruppe der designes til, og deres hukommelse vil variere fra person til person. Vi vil derfor designe systemet, s\u00e5 det er s\u00e5 intuitivt som muligt, hvilket fjerner behovet for at det er vigtigt at huske systemet fra gang til gang. Vi har ogs\u00e5 t\u00e6nkt over, om det vil v\u00e6re relevant at have en overs\u00e6ttelsesfunktion p\u00e5 siden, hvis der skulle v\u00e6re nogle ikke-dansktalende medlemmer i foreningen, men dette vil vi unders\u00f8ge n\u00e6rmere (se afsnit 3.2.5).<\/p>\n<p>Vi antager, at foreningens medlemmer vil v\u00e6re en heterogen gruppe, da der typisk vil v\u00e6re en bred m\u00e5lgruppe i en tennisklub, og det vil formentlig v\u00e6re \u00e6kvivalent med, at brugeren vil have forskellige form\u00e5l og foruds\u00e6tninger for brug af systemet. Vi forventer, at der i foreningen b\u00e5de vil v\u00e6re erfarne og uerfarne brugere af internettet, og derfor skal systemet designes til de forskellige f\u00e6rdigheder, som brugerne m\u00e5tte have.<\/p>\n<h3>3.2.2 Activity<\/h3>\n<h4>Teori<\/h4>\n<p>Der er mange forskellige aktiviteter systemet skal underst\u00f8tte og flere m\u00e5der systemet kan blive brugt p\u00e5. Det er vigtigt at overveje aktiviteterne et system skal underst\u00f8tte for at vide hvilke aspekter af systemet, der er vigtige at fokusere p\u00e5. Der er eksempelvis stor forskel p\u00e5 at designe et system, som bliver brugt dagligt af brugeren, i mods\u00e6tning til et, som de m\u00e5ske kun bruger en gang om \u00e5ret. Er det et system, hvor brugeren kan v\u00e6re fuldt fokuseret p\u00e5 system og l\u00f8se opgave for opgave, eller vil brugeren v\u00e6re i et milj\u00f8, hvor deres fokus vil skifte mellem systemet og noget andet? Er der nogle perioder, hvor der er h\u00f8j trafik i systemet og kan dette underst\u00f8tte det? Disse overvejelser er vigtige at have i designet af et system [Benyon 2014, side 33-34].<\/p>\n<h4>Analyse<\/h4>\n<p>Det prim\u00e6re form\u00e5l med systemet er en online bookingfunktion, hvor medlemmerne skal kunne reservere en bane, n\u00e5r de gerne vil spille. Det skal erstatte den nuv\u00e6rende l\u00f8sning, hvor medlemmet fysisk skal skrive sig op i en kalender nede i foreningen. Derudover er der ogs\u00e5 en r\u00e6kke mindre aktiviteter, som vi antager systemet skal kunne underst\u00f8tte. Dette indeb\u00e6rer blandt andet en online opslagstavle, kontaktside og vedt\u00e6gter. Herudover bliver vi ogs\u00e5 n\u00f8dt til at have en log-ind funktion, s\u00e5 det kun er foreningens medlemmer, der kan booke en bane.<\/p>\n<p>Hyppigheden for brugen af booking-funktionen vil formentlig v\u00e6re 1-2 gange om ugen for medlemmerne, hvor de andre funktioner vil blive brugt med mindre hyppighed. Vi regner generelt med, at der er mere aktivitet i systemet om sommeren, idet det er her s\u00e6sonen ligger. Vi antager, at der vil v\u00e6re et lille peak omkring standerhejsningen, da det er her s\u00e6sonen starter, medlemmer vil formentlig booke banen oftere, og der vil blive foretaget flere indmeldelser.<\/p>\n<h3>3.2.3 Context<\/h3>\n<h4>Teori<\/h4>\n<p>Konteksten for hvor og hvordan et systemet bliver brugt er altid vigtig at overveje i designprocessen, da det vil p\u00e5virke, hvordan brugeren kommer til at interagere med et system. Konteksten kan b\u00e5de referere til omst\u00e6ndighederne omkring systemet, men ogs\u00e5 hvordan der samles flere aktiviteter til en st\u00f8rre helhed [Benyon 2014, side 35]. Der er som udgangspunkt tre forskellige typer af kontekster, som skal overvejes i designet af IT-systemer: det fysiske, det sociale og det organisatoriske. I den fysiske kontekst skal der overvejes, om brugeren er derhjemme, p\u00e5 arbejde, udend\u00f8rs eller noget andet, der kunne p\u00e5virke brugen af systemet. I den sociale kontekst b\u00f8r designeren t\u00e6nke p\u00e5, om brugeren er alene eller sammen med andre under brugen af systemet. Den organisatoriske kontekst kunne f.eks. indeb\u00e6re overvejelser om, hvorvidt implementeringen af et system kunne resultere i nedsk\u00e6ringer af job [Benyon 2014, side 34-36].<\/p>\n<h4>Analyse<\/h4>\n<p>Et eksempel p\u00e5 overvejelser om den fysiske kontekst i vores system kunne eksempelvis v\u00e6re, om spillerne i foreningen prim\u00e6rt vil booke en bane fra deres computer hjemmefra eller p\u00e5 deres smartphone. Hvis brugeren har en smartphone med internetforbindelse er der uendelige muligheder for, hvilken fysisk kontekst systemet kan blive brugt i. Dog er der nogle scenarier, som er mere sandsynlige end andre. Det antages, at de fleste bookinger p\u00e5 smartphone vil komme til at foreg\u00e5 nede i foreningen. Dette er praktisk, da brugeren her vil v\u00e6re sammen med deres medspiller, og de sammen kan planl\u00e6gge n\u00e6ste gang de skal spille. Grundet den store variation i den fysiske kontekst kan det v\u00e6re sv\u00e6rt at tage h\u00f8jde for, og designe til alle de forskellige kontekster. En overvejelse kunne her v\u00e6re st\u00f8rrelsen p\u00e5 brugerens sk\u00e6rm. Det er brugervenligt at have et responsivt design, der retter ind efter st\u00f8rrelsen p\u00e5 brugerens sk\u00e6rm, s\u00e5 hjemmesidens funktionalitet vil v\u00e6re den samme uanset om brugeren benytter systemet p\u00e5 deres computer eller smartphone. Dog er dette udenfor dette semesters fokus og vores evner herp\u00e5, s\u00e5 vi har sat responsivt design som et <em>want to have, but won\u2019t have this time around <\/em>(se afsnit 3.3.2).<\/p>\n<p>I den sociale kontekst kunne det v\u00e6re relevant at kigge p\u00e5 om brugeren benytter sig af systemet sammen med andre eller alene. I vores tilf\u00e6lde kunne det v\u00e6re, som tidligere n\u00e6vnt, at brugeren booker banen sammen med sin medspiller. Brugeren ville kunne sp\u00f8rge medspilleren om hj\u00e6lp, hvis der skulle opst\u00e5 problemer i interaktionen med systemet.<\/p>\n<p>Det organisatoriske aspekt er begr\u00e6nset i vores projekt grundet st\u00f8rrelsen p\u00e5 foreningen. Det kunne overvejes, hvordan den nye bookingproces gennem systemet vil \u00e6ndre spillernes forhold til foreningen. For nogle vil det v\u00e6re en forbedring og l\u00f8sningen p\u00e5 at skulle fysisk ned i foreningen for at booke en tid.<\/p>\n<h3>3.2.4 Technology<\/h3>\n<h4>Teori<\/h4>\n<p>Det er vigtigt at forst\u00e5 teknologien, som IT-systemet benytter, samt forst\u00e5 dets begr\u00e6nsninger og muligheder, n\u00e5r systemet skal designes. Det er vigtigt for udviklerne af det interaktive system at forst\u00e5 den fysiske platform, som brugeren interagerer med gennem systemet. Der skelnes mellem to former for teknologier: input og output. Input teknologier er, hvor brugeren laver nogle fysiske input, som teknologien kan opfange og lave en handling ud fra. Det kunne for eksempel v\u00e6re en smartphone, hvor en input teknologi kunne v\u00e6re touchsk\u00e6rmen eller l\u00e5seknappen [Benyon 2014, side 36]. Det er vigtigt at tage h\u00f8jde for de muligheder og designe derefter. Output teknologi er, hvor teknologien giver fysiske outputs, f.eks. det visuelle, s\u00e5 som en computersk\u00e6rm eller lyd fra en h\u00f8jtaler, som er indbygget i mange teknologier [Benyon 2014, side 40].<\/p>\n<h4>Analyse<\/h4>\n<p>I vores dom\u00e6ne, hvor vi \u00f8nsker at designe en hjemmeside, vil der prim\u00e6rt blive benyttet to former for fysiske teknologier i form af computeren og smartphonen. I forhold til designet af det interaktive system skal vi forst\u00e5, hvilke output og input muligheder de to teknologier har og designe derefter. Vi bruger prim\u00e6rt input teknologien touch p\u00e5 mobilen og p\u00e5 computeren anvendes mus og tastatur. Output teknologien vil prim\u00e6rt v\u00e6re den samme for begge teknologier i form af sk\u00e6rmen. P\u00e5 trods af at vi g\u00e5r ud fra, at den prim\u00e6re brug vil v\u00e6re p\u00e5 b\u00e5de telefonen og computeren, vil vores design udelukkende fokusere p\u00e5 computer versionen af systemet, da det, som n\u00e6vnt tidligere, ikke er vores fokus, at optimere systemet til brug p\u00e5 mobilen p\u00e5 dette semester.<\/p>\n<h3>3.2.5 PACT efter interview<\/h3>\n<p>PACT analysen har givet os et overblik over de kontekster, som er vigtige at tage h\u00f8jde for i forhold til at designe IT-systemet til Midtbyens Tennisklub. PACT analysen har, som tidligere n\u00e6vnt, hjulpet os med at forst\u00e5, hvad der var relevant at sp\u00f8rge om i f\u00f8rste interview med bestyrelsesformanden. PACT analysen har suppleret interviewet, og omvendt har interviewet ogs\u00e5 suppleret PACT analysen. Interviewet har resulteret i at nogle af de antagelser, som vi foretog i PACT analysen, er blevet b\u00e5de be- og afkr\u00e6ftet &#8211; og i nogle tilf\u00e6lde yderligere udspecificeret. Vi vil derfor nu gennemg\u00e5 de punkter, hvor bestyrelsesformandens udtalelser har p\u00e5virket PACT analysen.<\/p>\n<p>I forhold til afsnittet People havde vi en antagelse om, at der ville v\u00e6re en bred m\u00e5lgruppe i foreningen, alts\u00e5 b\u00e5de unge og \u00e6ldre medlemmer. Dette bekr\u00e6ftede bestyrelsesformanden, og derudover informerede han om, at det prim\u00e6rt er en todelt aldersgruppe. Bestyrelsesformandens vurdering var, at det ca. er 50% af medlemmerne, som er 50+, og at ca. 50% er i aldersgruppen 18-25 \u00e5r. Dette bekr\u00e6ftede blot, at vi skal designe et system til en bred m\u00e5lgruppe, og derfor er de tidligere n\u00e6vnte overvejelser i afsnittet People, alts\u00e5 reelle problemstillinger. Bestyrelsesformanden berettede ogs\u00e5, at der er enkelte engelsktalende medlemmer i foreningen. Det kunne derfor v\u00e6re relevant at have en engelsk version af hjemmesiden, men dette var if\u00f8lge bestyrelsesformanden ikke relevant, grundet den lille st\u00f8rrelse p\u00e5 foreningen.<\/p>\n<p>I afsnittet Activity foreslog vi en r\u00e6kke funktioner, som kunne v\u00e6re relevante udover selve booking funktionen. Disse funktioner blev briefet til bestyrelsesformanden i interviewet. En af disse funktioner var blandt andet en opslagstavle, hvor bestyrelsen kan uploade tekst og billeder om relevante aktiviteter og informationer til foreningens medlemmer. Dette bekr\u00e6f-<\/p>\n<p>tede bestyrelsesformanden ville v\u00e6re en brugbar funktion for hjemmesiden, som ogs\u00e5 ville v\u00e6re med til at styrke det f\u00e6llesskab foreningen st\u00e5r for.<\/p>\n<h2>3.3 Udarbejdelse af kravspecifikationer<\/h2>\n<p>Interviewet med bestyrelsesformanden og PACT analysen har ligget til grund for udarbejdelsen af vores kravspecifikationer. De hjalp os til at forst\u00e5, hvilke krav, der var vigtige at udforme samt prioritere, s\u00e5ledes at systemet vil kunne underst\u00f8tte foreningens behov og vision.<\/p>\n<p>I f\u00f8lgende afsnit vil vi f\u00f8rst gennemg\u00e5 teorien for udformningen af kravspecifikationer og derefter gennemg\u00e5 nogle af de opstillede krav, som er vigtige for foreningen og systemets funktionalitet.<\/p>\n<h3>3.3.1 Kravspecifikationer<\/h3>\n<h4>Teori<\/h4>\n<p>Et krav kan defineres som <em>something the product must do or a quality the product must have <\/em>[Benyon 2014, side 139]. Det er alts\u00e5 elementer eller opgaver, som et produkt skal kunne opfylde.<\/p>\n<p>I udarbejdelsen af kravene til et system unders\u00f8ger udviklere eller designere blandt andet konteksten, hvori systemet skal benyttes. Kunden, som systemet laves for, kan ligeledes have krav, som denne finder essentielle. Herefter bringes alle observationer og informationer sammen, hvorefter kravene til det nye produkt begynder at udforme sig. Processen herom er meget iterativ<sup><sup><a id=\"post-1531-footnote-ref-2\" href=\"#post-1531-footnote-2\">[2]<\/a><\/sup><\/sup>, og derfor er de f\u00f8rste udkast sandsynligvis ikke de eneste, ej heller de sidste [Benyon 2014, side 139].<\/p>\n<p>Kunden kan v\u00e6re interesseret i at modtage en kravspecifikation, hvori de opstillede krav til produktet st\u00e5r listet med tilh\u00f8rende informationer. En kravspecifikation skal v\u00e6re let at l\u00e6se og forst\u00e5, og b\u00f8r som minimum indeholde:<\/p>\n<ul>\n<li>Et unikt nummer at referere til (et ID)<\/li>\n<li>Kort forklaring\/opsummering af kravet<\/li>\n<li>Kilde og begrundelse for kravet<\/li>\n<\/ul>\n<p>Udover de tre ovenst\u00e5ende kriterier, b\u00f8r en kravspecifikation ligeledes indeholde en m\u00e5de at teste om de enkelte krav er blevet opfyldt, en \u00e6ndringshistorik, en rangering af hvad der er vigtigst (eksempelvis en skala fra 1-4, se Afsnit 3.3.2) samt eventuelle problematikker eller konflikter med andre krav [Benyon 2014, side 139].<\/p>\n<p>Kravene til et produkt bliver opdelt i funktionelle og ikke-funktionelle krav. De funktionelle krav d\u00e6kker over de ting eller funktioner, som produktet skal kunne g\u00f8re. De ikke-funktionelle krav d\u00e6kker over alle de ting, som ikke er direkte funktionelle, eksempelvis usability, design, sikkerhed og opfyldelse af lovkrav.<\/p>\n<p>Begrundelser kan v\u00e6re informationer opn\u00e5et gennem interviews eller observationer, og de kan v\u00e6re med til at give l\u00e6seren en bedre forst\u00e5else af, hvorfor kravene er som de er, samt et indblik i de bagvedliggende tanker [Benyon 2014, side 140].<\/p>\n<h3>3.3.2 MoSCoW<\/h3>\n<p>I vores kravspecifikation for IT-systemet har vi opstillet en r\u00e6kke funktionelle og ikke-funktionelle krav. Disse krav har vi prioriteret fra 1 til 4, hvor kravene med en prioritet p\u00e5 1 er vigtigst og kravene med en prioritet p\u00e5 4 er mindre vigtige. Dette har vi gjort ved hj\u00e6lp af MoSCoW metoden. Denne metode opdeler krav i 4 segmenter: <em>Must have<\/em>, <em>Should have<\/em>, <em>Could have <\/em>og <em>Want to have but won\u2019t have this time around <\/em>[Benyon 2014, side 140].<\/p>\n<ul>\n<li>Her er en prioritet p\u00e5 1 en <em>Must have<\/em>, alts\u00e5 at dette krav er fundamentalt for at systemet skal kunne fungere og v\u00e6re brugbart<\/li>\n<li>En prioritet p\u00e5 2 er en <em>Should have <\/em>og betyder, at dette krav er relativt essentielt for systemet, men at systemet vil v\u00e6re nyttigt og brugbart uden<\/li>\n<li>En prioritet p\u00e5 3 er en <em>Could have <\/em>og betyder, at dette krav er mindre vigtigt for systemet, og det vil typisk v\u00e6re inkluderet, hvis der er tid og ressourcer til det [Agile Business n.d.]. Det er muligt senere hen at implementere de <em>Could have <\/em>krav, som ikke n\u00e5ede at komme med i f\u00f8rste omgang<\/li>\n<li>Prioritet 4, som er <em>Want to have but won\u2019t have this time around<\/em>, betyder at disse krav ikke bliver implementeret i denne omgang.<\/li>\n<\/ul>\n<p>Det kan virke ulogisk at opstille krav i kravspecifikationen, som egentligt ikke bliver implementeret i systemet, men der er flere gode grunde til, hvorfor dette kan v\u00e6re en god ide. De kan blandt andet v\u00e6re med til at styre forventningerne til systemet, samtidig med at det undg\u00e5s, at disse krav uformelt bliver reintroduceret p\u00e5 et senere tidspunkt indenfor den givne tidsramme [Agile Business n.d.]. Det kan ogs\u00e5 v\u00e6re med til at overskueligg\u00f8re, hvad der bliver implementeret og ikke bliver implementeret i systemet i denne omgang.<\/p>\n<h3>3.3.3 Vores kravspecifikationer<\/h3>\n<p>Kravspecifikationen for IT-systemet, som er lavet i samarbejde med foreningen, best\u00e5r af 21 funktionelle krav og 10 ikke funktionelle krav. Kravspecifikationen er en kombination af krav, som er udarbejdet med udgangspunkt i vores unders\u00f8gelse af foreningen og erfaringer med lignende systemer, samt en r\u00e6kke krav som blev stillet af samarbejdspartneren.<\/p>\n<p>De funktionelle krav er fordelt p\u00e5 seks kategorier:<\/p>\n<ul>\n<li><strong>Booking: <\/strong>Denne kategori indeholder seks krav, som omhandler bookingfunktionaliteten<\/li>\n<li><strong>Booking database: <\/strong>Denne kategori indeholder to krav, som omhandler databaser, der skal laves for at bookingsystemet kan fungere<\/li>\n<li><strong>Indmeldelseoglogin: <\/strong>Denne kategori indeholder tre krav, som omhandler indmeldelse i foreningen og oprettelse af log ind<\/li>\n<li><strong>Admin bruger: <\/strong>Denne kategori indeholder to krav, som omhandler administrator funktionaliten<\/li>\n<li><strong>Framtk9000.dk: <\/strong>Denne kategori indeholder syv krav, som omhandler videref\u00f8relsen af funktionalitet, som allerede er at finde p\u00e5 foreningens nuv\u00e6rende website, mtk9000.dk<\/li>\n<li><strong>Kosmetisk: <\/strong>Denne kategori indeholder et krav, som omhandler en kosmetisk funktionalitet, som \u00f8nskes p\u00e5 forsiden<\/li>\n<\/ul>\n<p>De ikke funktionelle krav er inddelt i tre kategorier:<\/p>\n<ul>\n<li><strong>Usability: <\/strong>Denne kategori indeholder fire krav, som omhandler brugbarheden af systemet<\/li>\n<li><strong>Sikkerhed: <\/strong>Denne kategori indeholder to krav, der omhandler den \u00f8nskede sikkerhed p\u00e5 websitet<\/li>\n<li><strong>Design: <\/strong>Denne kategori indeholder fire krav, som omhandler designet af websitet <strong>Udvalgte kravspecifikationer<\/strong><\/li>\n<\/ul>\n<p>Gennem vores problem- og PACT analyse har selve bookingprocessen v\u00e6ret i fokus. Den nuv\u00e6rende proces er, som tidligere n\u00e6vnt, tidskr\u00e6vende og besv\u00e6rlig for medlemmerne. Derudover kan den ogs\u00e5 skabe problemer for bestyrelsens vision om at udvide antallet af medlemmer, da det nuv\u00e6rende system ikke er at foretr\u00e6kke, hvis der kommer flere medlemmer i foreningen.<\/p>\n<p>Ud fra disse observationer, samt interviewet med bestyrelsesformanden, har vi opstillet nogle krav, som systemet skal underbygge.<\/p>\n<p>Kravspecifikationerne for IT-systemet har \u00e6ndret sig af flere omgange. Disse \u00e6ndringer skyldes vores observationer omkring foreningen og systemet, som senere hen er blevet korrigeret. Korrektionen\u00e5 er lavet p\u00e5 baggrund af l\u00f8bende afklaringer eller nye informationer, samt interviews med bestyrelsesformanden, som har haft tilf\u00f8jelser eller \u00e6ndringer til de krav, som blev udarbejdet p\u00e5 baggrund af det f\u00f8rste m\u00f8de med ham.<\/p>\n<p>Kravspecifikationerne er uddybet i bilag A, hvor de \u00e6ndringer, der er foretaget l\u00f8bende ligeledes st\u00e5r beskrevet.<\/p>\n<h4>Funktionelle krav<\/h4>\n<p>Vi vil ikke gennemg\u00e5 alle de funktionelle krav, men siden vores fokus prim\u00e6rt ligger p\u00e5 selve bookingprocessen, v\u00e6lger vi at gennemg\u00e5 nogle af de krav, som vedr\u00f8rer denne.<\/p>\n<table>\n<tbody>\n<tr>\n<td>\n<p>ID<\/p>\n<\/td>\n<td>\n<p>Prioritering<\/p>\n<\/td>\n<td>\n<p>Summary<\/p>\n<\/td>\n<td>\n<p>Source<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p>1a<\/p>\n<\/td>\n<td>\n<p>1<\/p>\n<\/td>\n<td>\n<p><strong>Booking af bane: <\/strong>Hvis brugeren er logget ind kan denne trykke p\u00e5 en ledig tid i bookingkalenderen og booke den. Hvis brugeren ikke er logget ind kan denne ikke se kalenderen, men blot information om login.<\/p>\n<\/td>\n<td>\n<p>Dette krav er blevet konstrueret med udgangspunkt i viden, vi har tilegnet ved at l\u00e6se foreningens hjemmeside. Bekr\u00e6ftet af formand.<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p>1b<\/p>\n<\/td>\n<td>\n<p>1<\/p>\n<\/td>\n<td>\n<p><strong>Medspillere: <\/strong>Brugeren skal kunne skrive navnet p\u00e5 partneren (eventuel en liste), n\u00e5r banen bliver booket.<\/p>\n<p>Minimum 1 maks 3 medspillere. Spilleren s\u00f8ger efter navn p\u00e5 medspillere, som automatisk bliver tilf\u00f8jet p\u00e5 en liste.<\/p>\n<\/td>\n<td>\n<p>Dette krav er blevet konstrueret med udgangspunkt i viden, vi har tilegnet ved at l\u00e6se foreningens hjemmeside. Bekr\u00e6ftet af formanden.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Tabel 3.1: <\/strong>Tabel med udvalgte funktionelle kravspecifikationer.<\/p>\n<p>Kravet 1a beskriver, hvordan det er muligt for et medlem at booke en bane. Kravet er tilrettet ud fra kommentarer fra bestyrelsesformanden, som ikke \u00f8nsker, at det skal v\u00e6re muligt for ikke-medlemmer at se kalenderen. Vi har valgt, at kravet har en prioritering 1 &#8211; alts\u00e5 et <em>must have <\/em>&#8211; i vores system, da dette is\u00e6r knytter sig til bestyrelsesformandens \u00f8nsker.<\/p>\n<p>Kravet 1b beskriver processen efter et medlem har valgt en tid. Her skal medlemmet v\u00e6lge sine medspillere ud fra en s\u00f8gefunktion i foreningens nuv\u00e6rende medlemmer. Dette krav er udformet p\u00e5 baggrund af interviewet med bestyrelsesformanden, der vil bibeholde den del af den nuv\u00e6rende bookingproces, hvor medlemmet skal skrive medspilleren p\u00e5. Dette g\u00f8r det muligt at kontrollere, hvem banen har v\u00e6ret benyttet af. N\u00e5r medlemmet har udfyldt dette vil navnene fremg\u00e5 i kalenderen p\u00e5 deres bookede tid. Kravet har en prioritering 1, da det netop har v\u00e6ret et \u00f8nske fra bestyrelsesformanden at beholde denne del.<\/p>\n<h4>Ikke funktionelle krav<\/h4>\n<p>Under de ikke funktionelle krav har vi bl.a. valgt at fokusere p\u00e5 designet. Gennem interviewet med bestyrelsesformanden erfarede vi, at foreningen beskriver sig selv som &#8220;Livsnydernes klub&#8221;, og at de v\u00e6gter f\u00e6llesskabet i foreningen h\u00f8jt.<\/p>\n<p>Kravet 9b er derfor sat som en prioritet 2, da designet skal afspejle foreningens image &#8211; og derved frembringe det foreningen st\u00e5r for.<\/p>\n<p>Kravet 7a er medtaget i kravspecifikationen, da det har v\u00e6ret brugt til at forventningsafstemme systemets benyttelse med bestyrelsesformanden. Selve kravet ligger uden for dette semesters fokus, og det er derfor en prioritet 4.<\/p>\n<table>\n<tbody>\n<tr>\n<td>\n<p>ID<\/p>\n<\/td>\n<td>\n<p>Prioritering<\/p>\n<\/td>\n<td>\n<p>Summary<\/p>\n<\/td>\n<td>\n<p>Source<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p>9b<\/p>\n<\/td>\n<td>\n<p>2<\/p>\n<\/td>\n<td>\n<p><strong>Design, der matcher foreningens identitet: <\/strong>Designet skal stemme overens med det image foreningen gerne vil fremvise, og underst\u00f8tte dette<\/p>\n<\/td>\n<td>\n<p>Dette krav er opstillet af projektgruppen, med udgangspunkt i viden tilegnet p\u00e5 1. semester. Bekr\u00e6ftet af formanden.<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p>7a<\/p>\n<\/td>\n<td>\n<p>4<\/p>\n<\/td>\n<td>\n<p><strong>Responsivt: <\/strong>Websitet skal v\u00e6re responsivt, s\u00e5ledes at indholdets fremvisning er afh\u00e6ngigt af sk\u00e6rmst\u00f8rrelsen p\u00e5 det device, som benyttes til at bes\u00f8ge sitet<\/p>\n<\/td>\n<td>\n<p>Dette krav er opstillet af projektgruppen, med udgangspunkt i viden tilegnet p\u00e5 1. semester<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Tabel 3.2: <\/strong>Tabel med udvalgte ikke funktionelle kravspecifikationer.<\/p>\n<p><strong>Kapitel4<\/strong><\/p>\n<h1>Envisionment<\/h1>\n<p>I det f\u00f8lgende afsnit vil vi beskrive de forskellige metoder, som vi har benyttet til at visualisere kravene til systemet i vores projekt, samt hvordan vi rent praktisk har anvendt disse. Envisionment betyder forestilling, og i designfasen af vores projekt handler det om, hvordan ideerne til systemet visualiseres [Benyon 2014, side 166]).<\/p>\n<p>Indledningsvis forklarer vi teorien bag navigationsmaps og sekvensmodeller, samt hvordan vi har brugt disse til at skabe et overblik over, hvad systemet skal indeholde. Herefter forklarer vi om de designprincipper, som vi har brugt i forbindelse med udarbejdelsen af vores designid\u00e9er til sketches og wireframes for Midtbyens Tennisklub\u2019s website. Afslutningsvis beskriver vi de sketches og wireframes, som vi har udarbejdet.<\/p>\n<h2>4.1 Struktur<\/h2>\n<h3>4.1.1 Teori<\/h3>\n<h4>Navigationsmap<\/h4>\n<p>Et navigationsmap hj\u00e6lper med at danne et overblik over, hvordan websitet er opbygget. I navigationsmappet er hver underside p\u00e5 websitet repr\u00e6senteret af en boks eller overskrift, hvor alle sider, der udspringer af denne er markeret med et flow i form af en streg eller en pil. Det kan v\u00e6re en fordel at bruge pile, s\u00e5fremt det hj\u00e6lper p\u00e5 forst\u00e5elsen af, hvordan websitet fungerer samt hvordan de enkelte sider h\u00e6nger sammen [Benyon 2014, side 172]. Et eksempel p\u00e5 et navigationsmap kan ses p\u00e5 figur 4.1.<\/p>\n<p>Da hele designprocessen er iterativ, er det normalt at rette designet af navigationsmappet l\u00f8bende, hvis der opst\u00e5r sider, hvor brugeren ikke kan komme videre. Dette kan testes ved at benytte scenarier for at gennemg\u00e5 websitet, og derved opdage problemer, hvor brugeren f.eks. ikke kan komme videre eller tilbage [Benyon 2014, side 172].<\/p>\n<p><em>4.1. STRUKTUR<\/em><\/p>\n<h4>Sekvensmodel<\/h4>\n<p>Sekvensmodellen bruges til at vise de forskellige trin, det tager at udf\u00f8re en handling p\u00e5 f.eks. et website [Benyon 2010, side 282].<\/p>\n<p>Modellen udarbejdes med forskellige komponenter, som alle er med til at danne et overblik over, hvordan den enkelte sekvens ser ud [Benyon 2010, side 283]:<\/p>\n<ul>\n<li>Intentionen bag udf\u00f8relsen af handlingen. Denne komponent kan findes ud fra et udarbejdet flowdiagram eller et navigationsmap, som giver et st\u00f8rre overblik over navigationen p\u00e5 siderne samt deres funktioner<\/li>\n<li>Triggeren, der f\u00e5r brugeren til at udf\u00f8re sekvensen<\/li>\n<li>Trinene i selve sekvensen, som f\u00e5r brugeren fra intention til udf\u00f8relse<\/li>\n<li>Problemer, der kan opst\u00e5 undervejs i sekvensen<\/li>\n<\/ul>\n<p>Selve modellens sekvens er ikke altid line\u00e6r. Hvis der opst\u00e5r problemer, eller der er flere muligheder for udf\u00f8relsen, kan modellen indeholde loops eller forgreninger, som viser de forskellige retninger sekvensen kan tage [Benyon 2010, side 284-285].<\/p>\n<h3>4.1.2 Navigationsmap og sekvensmodel for systemet<\/h3>\n<p>Navigationsmappet for websitet, vi udarbejder for Midtbyens Tennisklub, kommer til at se ud som vist i figur 4.1.<\/p>\n<p><img loading=\"lazy\" width=\"1452\" height=\"618\" class=\"wp-image-1537\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-3.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-3.jpeg 1452w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-3-300x128.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-3-768x327.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-3-1024x436.jpeg 1024w\" sizes=\"(max-width: 1452px) 100vw, 1452px\" \/><\/p>\n<p><strong>Figur 4.1: <\/strong>Navigationsmap over systemet<\/p>\n<p><em>4.1. STRUKTUR<\/em><\/p>\n<p>Vi har her taget udgangspunkt i deres nuv\u00e6rende hjemmeside, http:\/\/mtk9000.dk, hvor vi har taget samme menupunkter med p\u00e5 det nye site (se figur 2.1). Her har vi dog tilf\u00f8jet endnu et menupunkt i form af <em>log ind<\/em>. Dette har vi gjort, da brugerne er n\u00f8dt til at kunne logge ind for at booke en tid p\u00e5 banen. Vi har valgt at omstrukturere r\u00e6kkef\u00f8lgen af menupunkterne, da hovedfunktionerne i systemet omhandler booking og administration af medlemmer. Herudover har bestyrelsesformanden ogs\u00e5 haft input i forhold til, hvilken r\u00e6kkef\u00f8lge menupunkterne skal oplistes i [interview med bestyrelsesformanden].<\/p>\n<p><img loading=\"lazy\" width=\"1453\" height=\"715\" class=\"wp-image-1538\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-4.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-4.jpeg 1453w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-4-300x148.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-4-768x378.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-4-1024x504.jpeg 1024w\" sizes=\"(max-width: 1453px) 100vw, 1453px\" \/><\/p>\n<p><strong>Figur 4.2: <\/strong>Navigationsmap med administratorfunktioner for systemet<\/p>\n<p>Navigationsmappet p\u00e5 figur 4.2 er en uddybning af det, som ses p\u00e5 figur 4.1, da der her er inkorporeret de funktioner, som administratoren vil have p\u00e5 websitet. Administratorfunktionerne er illustreret med sorte bokse, som skiller sig ud fra de resterende. Disse muligheder vil kun v\u00e6re tilg\u00e6ngelige p\u00e5 hjemmesiden, s\u00e5fremt der er logget ind som administrator. Foruden de funktioner, som er illustreret med sorte bokse, vil administratoren ligeledes v\u00e6re i stand til at \u00e6ndre og opdatere i tekster p\u00e5 store dele af websitet.<\/p>\n<p><em>4.2. DESIGNPRINCIPPER<\/em><\/p>\n<p><img loading=\"lazy\" width=\"657\" height=\"623\" class=\"wp-image-1539\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-5.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-5.jpeg 657w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-5-300x284.jpeg 300w\" sizes=\"(max-width: 657px) 100vw, 657px\" \/><\/p>\n<p><strong>Figur 4.3: <\/strong>Sekvensmodel over bookingfunktion<\/p>\n<p>Det er bookingfunktionen, som er det centrale p\u00e5 websitet. Derfor har vi i figur 4.3 lavet en sekvensmodel, der viser de forskellige trin, der skal til for at booke en tid p\u00e5 banen. Her er <em>intent <\/em>og <em>trigger <\/em>n\u00e6sten det samme; nemlig, at et medlem gerne vil booke en tid p\u00e5 banen.<\/p>\n<p>Herefter er der en r\u00e6kke trin, som brugeren skal igennem som kan l\u00e6ses p\u00e5 figur 4.3.<\/p>\n<h2>4.2 Designprincipper<\/h2>\n<p>Vi har valgt at bruge designprincipperne oplyst i bogen <em>Designing Interactive Systems <\/em>for at sikre, at vi fra starten af designfasen udviklede nogle designid\u00e9er, som var brugervenlige og funktionelle [Benyon 2014, side 86]. Disse designprincipper fungerede som en guideline for vores tidlige designid\u00e9er. Samtidigt har vi ogs\u00e5 brugt designprincipperne til at foretage en lavpraktisk heuristic evaluering l\u00f8bende i designprocessen. Herved menes at de er brugt i en mere uformel form, hvor det er diskuteret l\u00f8bende, om de f\u00f8lger designprincipperne. Dette har gjort, at vi har kunne lave en l\u00f8bende evaluering af systemet uden at skulle investere for meget tid [Benyon 2014, side 217]. En mere formel heuristic evaluering ville kr\u00e6ve en mere<\/p>\n<p>veldokumenteret proces, hvor flere personer individuelt ville evaluere systemet og diskutere det i f\u00e6llesskab [Nielsen 1993, side 156].<\/p>\n<p>Grunden til at vi har valgt disse designprincipper, og ikke Jakob Nielsen Heuristic\u2019s, er, at bogen er af nyere dato og mere fokuseret p\u00e5 webdesign. Der er tale om i alt 12 designprincipper, som er inddelt i tre hovedgrupper, <em>learnabillity, effectivness <\/em>og <em>accommodating <\/em>[Benyon 2014, side 86]. Et eksempel p\u00e5 et designprincip, er princip fire: <em>affordance<\/em>. Dette princip g\u00e5r ud p\u00e5 at designe efter, at det skal v\u00e6re nemt at fortolke hvad funktionen er. Det kunne eksempelvis v\u00e6re en knap i en menulinje. Her er det vigtigt, at tydeligg\u00f8re at det er en knap, og at der kan trykkes p\u00e5 knappen. Dette kan eksempelvis g\u00f8res ved, at knappen \u00e6ndrer farve, n\u00e5r musen placeres over knappen.<\/p>\n<p>De designprincipper vi bl.a. benytter er:<\/p>\n<ul>\n<li><strong>Visibility: <\/strong>Synligg\u00f8r de forskellige funktioner samt hvad systemet er i gang med<\/li>\n<li><strong>Consistency: <\/strong>V\u00e6r konsistent i designet og m\u00e5den dette fungerer p\u00e5<\/li>\n<li><strong>Familiarity: <\/strong>Benyt sprog og symboler, som brugerne er bekendte med<\/li>\n<li><strong>Affordance: <\/strong>Design systemet, s\u00e5 det er tydeligt hvad de forskellige funktioner er til<\/li>\n<li><strong>Navigation: <\/strong>Guide brugerne gennem siden, s\u00e5 de nemt kan navigere rundt<\/li>\n<li><strong>Feedback: <\/strong>Informerer brugerne om, hvilken effekt deres handler har haft<\/li>\n<li><strong>Recovery: <\/strong>Muligg\u00f8r hurtig genopretning af fejl beg\u00e5et p\u00e5 siden<\/li>\n<li><strong>Conviviality: <\/strong>Interaktive systemer skal v\u00e6re h\u00f8flige og venlige. Brug derfor sprog, informationer, fokus p\u00e5 specifikke funktioner m.m. til at skabe et venligt system til brugeren [Benyon 2014, side 86-88].<\/li>\n<\/ul>\n<p>Designprincipperne vil l\u00f8bende blive inddraget i vores analyse af systemet.<\/p>\n<h2>4.3 Sketches og wireframes<\/h2>\n<h3>4.3.1 Teori<\/h3>\n<h4>Sketches<\/h4>\n<p>Sketches er en metode, som kan bruges i begyndelsen af designfasen, hvor id\u00e9er og tanker kan visualiseres [Benyon 2014, side 167]. Sketches er et brugbart redskab i designfasen, da id\u00e9er og tanker ofte kan fortolkes anderledes end tilt\u00e6nkt. Her kan designerne af systemet hurtigt visualisere deres tanker og pr\u00e6sentere dem for andre, hvis det er relevant. Metoden hj\u00e6lper med at visualisere ens id\u00e9er samt opdage eventuelle mangler og problemer. Sketches er ikke detaljeorienteret og indeholder ikke konkret tekst og farver, men er blot en hurtigt visualisering af vigtige funktioner og deres placeringer [Benyon 2014, side 168]. Sketches kan forekomme i form af fysiske tegninger eller ved brug af tegneprogrammer p\u00e5 en computer. P\u00e5 figur 4.4 ses et eksempel p\u00e5 en sketch, lavet i programmet Balsamiq. Som det ses p\u00e5 eksemplet er det en hurtigt metode til visualisering. Metoden er derfor god i en indledende fase af designprocessen, hvor koncepterne skal besluttes og konkretiseres. Eksempelvis kan sketches bruges som et supplement til en kravspecifikation, s\u00e5 en eventuel samarbejdspartner eller kunde kan f\u00e5 en bedre forst\u00e5else for kravene, og dermed give mere pr\u00e6cis feedback p\u00e5 om designid\u00e9erne opfylder kundens krav [Bruun 2019].<\/p>\n<p><img loading=\"lazy\" width=\"1453\" height=\"905\" class=\"wp-image-1540\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-6.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-6.jpeg 1453w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-6-300x187.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-6-768x478.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-6-1024x638.jpeg 1024w\" sizes=\"(max-width: 1453px) 100vw, 1453px\" \/><\/p>\n<p><strong>Figur 4.4: <\/strong>Eksempel p\u00e5 sketch<\/p>\n<h4>Wireframes<\/h4>\n<p>Wireframes er ligesom sketches en visualiseringsmetode. Dog er den mere detaljeorienteret end sketches og kan benyttes imellem sketches og prototyper i designfasen [Benyon 2014, side 167]. Det kan for eksempel v\u00e6re det n\u00e6ste skridt efter at have briefet designid\u00e9erne til kunden, og det er mere sikkert, hvilken retning designet skal g\u00e5 i [Bruun 2019]. Wireframes g\u00e5r mere i dybden med specifikke sider p\u00e5 en hjemmeside, hvor sketches mere danner et overblik. Wireframes fokuserer p\u00e5 de generelle elementer i et design uden at omhandle de endelige detaljer. Det er f.eks. placeringer af forskellige elementer s\u00e5som knapper, menulinje og hvad det tekstlige indhold skal v\u00e6re. De er dog ikke s\u00e5 detaljeorienteret i forhold til, hvordan et logo eller ikon pr\u00e6cist skal fremst\u00e5 [Benyon 2014, side 173].<\/p>\n<h3>4.3.2 Sketches for Midtbyens Tennisklub<\/h3>\n<p>Vi har valgt at udarbejde sketches, fordi det er en hurtig og nem m\u00e5de, hvorved vi kan illustrere vores tanker og id\u00e9er om systemet for hinanden samt samarbejdspartneren. P\u00e5 den m\u00e5de kan vi, i f\u00e6llesskab med vores samarbejdspartner, f\u00e5 designet et system, der d\u00e6kker deres behov bedst muligt. Derved l\u00e6gger vi ikke for meget energi i et design, som muligvis bliver forkastet. Vores samarbejdspartner gjorde det klart, inden vi p\u00e5begyndte arbejdet med sketchene, at han godt kunne lide den overordnede struktur p\u00e5 deres nuv\u00e6rende website. Strukturen skulle dermed videref\u00f8res til det nye website, dog med nogle kosmetiske \u00e6ndringer. Designproces har b\u00e5ret pr\u00e6g af udsagnene fra bestyrelsesformanden, hvor vi efterf\u00f8lgende har vendt og visualiseret forskellige forslag til designet. Vi har valgt overvejende at bibeholde det samme design fra deres nuv\u00e6rende site, i udarbejdelsen af sketches til det nye site, som f\u00f8lge af bestyrelsesformandens udtalelser.<\/p>\n<p>Processen fra id\u00e9er til endelige sketches, startede p\u00e5 et lavpraktisk stadie, hvor vi i f\u00e6llesskab diskuterede nogle af siderne, som systemet skulle indeholde. Det var prim\u00e6rt de sider, som indeholdte mange detaljer og interaktionsmuligheder, vi diskuterede i f\u00e6llesskab, f\u00f8r sketchene blev udarbejdet. En af disse sider var blandt andet bookingkalenderen. Her blev flere forskellige versioner tegnet p\u00e5 tavlen med inspiration fra andre bookingsystemer. Ved en gruppediskussion blev designet, som ses p\u00e5 figur 4.7, valgt som det design, der skulle videref\u00f8res og tegnes i sketchprogrammet Balsamiq.<\/p>\n<p><img loading=\"lazy\" width=\"1427\" height=\"556\" class=\"wp-image-1541\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-7.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-7.jpeg 1427w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-7-300x117.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-7-768x299.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-7-1024x399.jpeg 1024w\" sizes=\"(max-width: 1427px) 100vw, 1427px\" \/><\/p>\n<p><strong>Figur 4.5: <\/strong>Udarbejdede sketches p\u00e5 tavlen, af hhv. bookingkalender og indmeldelse side.<\/p>\n<p>Det n\u00e6ste skridt i processen efter udv\u00e6lgelsen af vores sketches, var at f\u00e5 disse visualiseret med flere detaljer. I mindre grupper udarbejdede vi samtlige sider, som systemet skulle indeholde. Stort set alle siderne havde flere versioner, som vi kunne v\u00e6lge imellem. Sketchene blev udarbejdet med designprincipperne i baghovedet. Vi har blandt andet designet efter, at knapperne skal fremst\u00e5 tydelige, s\u00e5ledes at det er \u00e5benlyst, at der en interaktionsmulighed. Derudover har vi fokuseret p\u00e5 et konsistent design. Vi har kontrolleret, at knapper p\u00e5 sketchene har samme design og farver, og at menubaren g\u00e5r igen p\u00e5 alle sider. De udarbejdede sketches blev gennemg\u00e5et og diskuteret, og vi udvalgte her de endelige sketches, som vi \u00f8nskede at pr\u00e6sentere for bestyrelsesformanden. Alle sketchene blev taget med til m\u00f8det i tilf\u00e6ldet af, at han \u00f8nskede nogle andre l\u00f8sninger end dem vi foretrak. P\u00e5 figur 4.6 ses et eksempel p\u00e5 en f\u00e6rdig sketch.<\/p>\n<p><img loading=\"lazy\" width=\"1815\" height=\"978\" class=\"wp-image-1542\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-8.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-8.jpeg 1815w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-8-300x162.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-8-768x414.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-8-1024x552.jpeg 1024w\" sizes=\"(max-width: 1815px) 100vw, 1815px\" \/><\/p>\n<p><strong>Figur 4.6: <\/strong>Sketch af bookingkalender<\/p>\n<p>Administratorfunktionerne er p\u00e5 de sider hvor det er n\u00f8dvendigt for bestyrelsen at kunne redigere p\u00e5 siden. P\u00e5 disse sider vil der v\u00e6re en form for rediger knap eller funktion, s\u00e5fremt administratoren er logget ind p\u00e5 sitet. Til de funktioner, som ikke intuitivt h\u00f8rer til p\u00e5 nogle af siderne p\u00e5 sitet, har vi lavet en medlemsh\u00e5ndterings-fane. Under denne er der f.eks. aktivering af brugerlogin, se figur 4.7.<\/p>\n<h4>Fravalg af sketches<\/h4>\n<p>Efter andet m\u00f8de med bestyrelsesformanden, hvor vi fremlagde diverse sketches over funktioner for sitet, blev der sorteret nogle sketches fra. Det blev der p\u00e5 baggrund af bestyrelsesformandens ytringer, om hvorvidt han vurderede, om designet var passende eller ej. Udover dette kom vi ogs\u00e5 med forslag til hvilke sketches, som vi vurderede ville fungere bedst. P\u00e5 den m\u00e5de fik vi indsn\u00e6vret det til, at der kun var de sketches tilbage, som b\u00e5de vi og bestyrelsesformanden vurderede ville fungere bedst.<\/p>\n<p>Vi pr\u00e6senterede eksempelvis bestyrelsesformanden for to forskellige sketches, som viste hver<\/p>\n<p><img loading=\"lazy\" width=\"954\" height=\"680\" class=\"wp-image-1543\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-9.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-9.jpeg 954w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-9-300x214.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-9-768x547.jpeg 768w\" sizes=\"(max-width: 954px) 100vw, 954px\" \/><\/p>\n<p><strong>Figur 4.7: <\/strong>Sketch af administratorfunktionernen rediger (denne sketch blev ikke anvendt)<\/p>\n<p>deres mulige m\u00e5der at logge ind p\u00e5. Her gav bestyrelsesformanden udtryk for at sketch 1, som fungerede som en dropdown-menu til log ind funktionen (se figur 4.8), var den bedste l\u00f8sning ift. at simplificere log ind-funktionen.<\/p>\n<p><img loading=\"lazy\" width=\"781\" height=\"361\" class=\"wp-image-1544\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-10.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-10.jpeg 781w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-10-300x139.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-10-768x355.jpeg 768w\" sizes=\"(max-width: 781px) 100vw, 781px\" \/><\/p>\n<p><strong>Figur 4.8: <\/strong>Forskellige versioner af login-funktionen. Til venstre ses en dropdown-menu, og til h\u00f8jre ses et pop-op vindue<\/p>\n<p>Udover dette blev der bl.a. ogs\u00e5 pr\u00e6senteret fire forskellige sketches, som illustrerede forskellige m\u00e5der for brugerne at afmelde en booket tid. Her havde bestyrelsesformanden en holdning til, at det skulle v\u00e6re sketch 3 (se figur 4.9), der skulle benyttes, da han mente, at det var den mest simple m\u00e5de for brugerne at afmelde deres tider p\u00e5.<\/p>\n<p><img loading=\"lazy\" width=\"852\" height=\"429\" class=\"wp-image-1545\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-11.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-11.jpeg 852w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-11-300x151.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-11-768x387.jpeg 768w\" sizes=\"(max-width: 852px) 100vw, 852px\" \/><\/p>\n<p><strong>Figur 4.9: <\/strong>Forskellige designs af afmeldfunktionen.<\/p>\n<p>Afslutningsvis fravalgte vi de p\u00e5g\u00e6ldende sketches, samtidig med at vi tilrettede kravspecifikation, s\u00e5ledes at den var ajour med de beslutninger, der blev n\u00e5et frem til p\u00e5 m\u00f8det med bestyrelsesformanden.<\/p>\n<h3>4.3.3 Wireframes for Midtbyens Tennisklub<\/h3>\n<p>Ud fra de tilbagev\u00e6rende sketches valgte vi at udarbejde wireframes til de mere komplekse sider i systemet for at f\u00e5 et bedre overblik over, hvordan designet pr\u00e6cist skulle se ud.<\/p>\n<p>P\u00e5 figur 4.10 ses et wireframe for startsiden af websitet. Udarbejdelsen af dette hjalp os med at forst\u00e5, hvordan de forskellige elementer p\u00e5 siderne skulle fremst\u00e5. Designet er skabt p\u00e5 baggrund af bestyrelsesformandens \u00f8nske om at bibeholde foreningens nuv\u00e6rende design og ops\u00e6tning. Ligesom ved sketchene har vi ogs\u00e5 her taget h\u00f8jde for design principperne i udviklingen af wireframes.<\/p>\n<p><img loading=\"lazy\" width=\"792\" height=\"742\" class=\"wp-image-1546\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-12.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-12.jpeg 792w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-12-300x281.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-12-768x720.jpeg 768w\" sizes=\"(max-width: 792px) 100vw, 792px\" \/><\/p>\n<p><strong>Figur 4.10: <\/strong>Wireframe for startsiden.<\/p>\n<p>P\u00e5 figur 4.11 og 4.12 ses de wireframes for selve kalenderen, samt hvilken besked brugeren f\u00e5r, n\u00e5r denne gerne vil booke en ledig tid.<\/p>\n<p><img loading=\"lazy\" width=\"798\" height=\"767\" class=\"wp-image-1547\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-13.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-13.jpeg 798w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-13-300x288.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-13-768x738.jpeg 768w\" sizes=\"(max-width: 798px) 100vw, 798px\" \/><\/p>\n<p><strong>Figur 4.11: <\/strong>Wireframe for bookingkalenderen.<\/p>\n<p><img loading=\"lazy\" width=\"502\" height=\"509\" class=\"wp-image-1548\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-14.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-14.jpeg 502w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-14-296x300.jpeg 296w\" sizes=\"(max-width: 502px) 100vw, 502px\" \/><\/p>\n<p><strong>Figur 4.12: <\/strong>Wireframe for pop-op vindue i bookingkalenderen.<\/p>\n<p><strong>Kapitel5<\/strong><\/p>\n<h1>Physicaldesign<\/h1>\n<p>Det f\u00f8lgende afsnit omhandler processen med at f\u00e5 videref\u00f8rt vores mere abstrakte designs i form af sketches og wireframes fra envisionment afsnittet. I envisionment afsnittet var fokus p\u00e5 den overordnede struktur, og hvad de enkelte sider skulle indeholde. I dette afsnit vil vi have mere fokus p\u00e5 detaljerne, og vise hvordan vi kommer frem til vores endelige design. Vi vil analysere os frem til hvordan de enkelte elementer skal st\u00e5 i forhold til hinanden, og hvordan de enkelte elementer skal designes i forhold til farver og layout. Vi vil f\u00f8rst redeg\u00f8re for teorien og derefter argumentere for vores valg af fysisk design.<\/p>\n<h2>5.1 Teori<\/h2>\n<h3>5.1.1 Ikoner<\/h3>\n<p>Ikoner kan bruges til at repr\u00e6sentere sider eller funktioner i et softwaresystem. Ikoner bliver generelt brugt som et redskab til at hj\u00e6lpe brugeren med at forst\u00e5, hvilke sider eller funktioner, de skal tilg\u00e5 for at opn\u00e5 den \u00f8nskede handling. Ikoner bliver brugt i et stort omfang p\u00e5 hjemmesider og kan variere meget i design. Der skelnes mellem tre hovedtyper af ikoner: <em>metaforer, direkte billeder <\/em>og <em>konventioner <\/em>[Benyon 2014, side 259]. Et metafor ikon kr\u00e6ver at brugeren kan overf\u00f8re viden fra \u00e9n sammenh\u00e6ng til en anden. Det kan eksempelvis v\u00e6re ikonet, som ligner en saks, som blandt andet bruges i mange skriveprogrammer og indikerer funktionen at klippe noget. Dette ikon kan relatere til det at klippe i et fysisk papir for at rykke et tekststykke, og lime det fast p\u00e5 et andet stykke papir [Benyon 2014, side 259].<\/p>\n<p>Et direkte billed ikon betyder, at ikonet er et billede af, hvad den repr\u00e6senterer og kr\u00e6ver derfor ingen fortolkning [Benyon 2014, side 259]. Det kan for eksempel v\u00e6re printer ikonet, som ligner en printer, og er derfor et direkte billede af den egentlige handling. Et konvention ikon omhandler et ikon, der altid forestiller den samme handling uden nogle store design forskelle [Benyon 2014, side 259]. Det kan for eksempel v\u00e6re indstillingsikonet,<\/p>\n<p><em>5.1. TEORI<\/em><\/p>\n<p>som i langt de fleste tilf\u00e6lde ligner et tandhjul.<\/p>\n<h3>5.1.2 Menu<\/h3>\n<p>Mange systemer g\u00f8r i dag brug af menuer til at organisere og huse et systems funktioner og kaldes et menu-drevet interface [Benyon 2014, side 261-262]. N\u00e5r menuer skal designes, er det vigtigt at funktionerne er grupperet i menuemner, som er en liste af menuelementer. Det fungerer s\u00e5ledes, at n\u00e5r brugeren klikker p\u00e5 et menuelement i menubaren, bliver en handling udf\u00f8rt. Menuer bliver brugt i et stort omfang p\u00e5 hjemmesider til at strukturere informationer, samt som den centrale metode for navigation p\u00e5 hjemmesiden. Udover selve hovedmenuen bruges der ogs\u00e5 i mange tilf\u00e6lde undermenuer. Undermenuer kaldes ogs\u00e5 for hierarkisk organiserede menuer eller cascading menuer. Dette er brugbart, hvis en hjemmeside har mange informationer, hvor en simpel menubar ikke er nok. N\u00e5r en person klikker eller k\u00f8rer musemark\u00f8ren over et af hovedemnerne i menuen, \u00e5bnes der en ny liste af grupperede emner, som er relateret til hovedemnet i menubaren [Benyon 2014, side 261-262].<\/p>\n<h4>Chunking<\/h4>\n<p>Chunking d\u00e6kker over processen, hvor der grupperes informationer ind i meningsfulde enheder. Det er en effektiv m\u00e5de hvorp\u00e5 brugerens hukommelsesbelastning reduceres. Det kan for eksempel v\u00e6re en undermenu som n\u00e6vnt tidligere [Benyon 2014, side 273].<\/p>\n<h4>Working memory<\/h4>\n<p>N\u00e5r et system skal designes, er det vigtigt at tage h\u00f8jde for brugerens arbejdshukommelse<sup><sup><a id=\"post-1531-footnote-ref-3\" href=\"#post-1531-footnote-3\">[3]<\/a><\/sup><\/sup>. Der er uenigheder om hvor mange ting, det forventes at brugeren kan huske. Nyere forskning peger p\u00e5 at kapaciteten af arbejdshukommelsen er tre til fire ting. Cowan argumenterer for at arbejdshukommelsen kan rumme 4 <em>\u00b1 <\/em>1 elementer [Benyon 2014, side 273][Cowan 2019].<\/p>\n<h3>5.1.3 Gestaltlovene<\/h3>\n<p>Der findes tre forskellige gestaltlove: <em>perception, similiarity og continuity<\/em>. <em>Perception <\/em>giver indblik i m\u00e5den forskellige objekter kan opfattes. Ved eksempelvis en observation af forskellige grupperede elementer kan disse opfattes som en helhed, men hvis de deles op, s\u00e5 vil de opfattes som forskellige elementer [Benyon 2014, side 271-272].<\/p>\n<h3>5.1.4 Farvevalg<\/h3>\n<p>I figur 5.1 er der listet forskellige vestlige farvekonventioner, som er en fordel at benytte sig af. Det er dog vigtigt at v\u00e6re opm\u00e6rksom p\u00e5, at farverne kan opfattes anderledes i andre kulturer, og det er derfor godt at overveje farvernes betydning i designet.<\/p>\n<p><img loading=\"lazy\" width=\"702\" height=\"214\" class=\"wp-image-1549\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-15.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-15.jpeg 702w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-15-300x91.jpeg 300w\" sizes=\"(max-width: 702px) 100vw, 702px\" \/><\/p>\n<p><strong>Figur 5.1: <\/strong>Vestlige farvekonventioner [Benyon 2014, side 277]<\/p>\n<h3>5.1.5 Closure<\/h3>\n<p>Loven <em>Closure <\/em>omhandler m\u00e5den, hvorved information bedst opfattes. Hvis informationerne tilf\u00f8jes til et lukket objekt, der st\u00e5r i kontrast til baggrunden (f.eks. en aflukket kasse), vil informationerne her blive hurtigere opfattet end hvis de bliver tilf\u00f8jet til et \u00e5bent objekt [Benyon 2014, side 272].<\/p>\n<h2>5.2 Analyse<\/h2>\n<h3>5.2.1 Menubaren<\/h3>\n<p>Vores \u00f8nske for designet af hjemmesiden til Midtbyens Tennisklub var at holde det s\u00e5 simpelt som overhovedet muligt, og samtidig im\u00f8deg\u00e5 foreningens \u00f8nske om et design, som minder om det fra deres nuv\u00e6rende side. Derfor har vi videref\u00f8rt menubaren i samme farvenuance, s\u00e5 det er genkendeligt. Form\u00e5let med menubaren, som ses i figur 5.2, er at den skal indeholde samtlige sider p\u00e5 hjemmesiden, s\u00e5 brugeren kan tilg\u00e5 alle informationer fra menubaren. P\u00e5 den m\u00e5de kan vi sikre en simpel navigation, hvor den eneste m\u00e5de brugeren kan navigere rundt mellem siderne er ved brug af menubaren, eller pilene til at g\u00e5 frem og tilbage mellem siderne som ses i venstre hj\u00f8rne p\u00e5 browseren. Vores hjemmeside har det, der kaldes for et menu-drevet interface, og det skulle gerne resultere i, at brugeren har en nem m\u00e5de at navigere rundt p\u00e5 siden. Dette er noget vi vil teste i vores endelige usability test, n\u00e5r systemet er klar til dette.<\/p>\n<p>Menubaren g\u00e5r igen p\u00e5 alle siderne, hvilket g\u00f8r at designet fremst\u00e5r mere ensartet, og derfor<\/p>\n<p>ogs\u00e5 mere genkendeligt for brugeren, uanset hvilken side de befinder sig p\u00e5. Det f\u00f8lger ogs\u00e5 designprincipperne <em>consistency <\/em>og <em>visibility <\/em>[Benyon 2014, side 86], hvilket gerne skulle hj\u00e6lpe p\u00e5 systemets learnability [Benyon 2014, side 86]. Selvom menubaren best\u00e5r af syv elementer og overskrider Cowan\u2019s argument, at den arbejdende hukommelse maksimalt kan huske 4 <em>\u00b1 <\/em>elementer, er dette ikke et problem, da menubaren g\u00e5r igen p\u00e5 alle sider, og s\u00e6tter derfor ikke nogle v\u00e6sentlige krav til brugerens arbejdshukommelse [Benyon 2014, side 273].<\/p>\n<p>Et andet redskab til brugeren i menubaren er, n\u00e5r brugeren klikker ind p\u00e5 en side, vil baggrunden i menubaren blive m\u00f8rkeorange, og brugeren er derfor ikke i tvivl om, hvor denne befinder sig p\u00e5 hjemmesiden. Ydermere benyttes der ogs\u00e5 en hover-effekt<sup><sup><a id=\"post-1531-footnote-ref-4\" href=\"#post-1531-footnote-4\">[4]<\/a><\/sup><\/sup>, som g\u00f8r at n\u00e5r brugeren k\u00f8rer musen over et af menuelementerne, vil baggrunden blive orange, og musemark\u00f8ren vil \u00e6ndre sig til en s\u00e5kaldt pointer (se figur 5.5). Dette tydeligg\u00f8r interaktionsmuligheden, s\u00e5 det ligner at det er en knap, som brugeren kan trykke p\u00e5, hvilket ogs\u00e5 f\u00f8lger designprincippet <em>affordance <\/em>[Benyon 2014, side 97].<\/p>\n<p><img loading=\"lazy\" width=\"1600\" height=\"268\" class=\"wp-image-1550\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-16.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-16.jpeg 1600w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-16-300x50.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-16-768x129.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-16-1024x172.jpeg 1024w\" sizes=\"(max-width: 1600px) 100vw, 1600px\" \/><\/p>\n<p><strong>Figur 5.2: <\/strong>Sk\u00e6rmbillede af menubaren fra mbtennis.dk<\/p>\n<p>Som det fremg\u00e5r af figur 5.2, er log ind funktionen adskilt fra de andre interaktionsmuligheder, hvilket separerer log ind funktionen fra de andre sider. Gruppen af menuemner til venstre indeholder alle sammen et link til en ny side p\u00e5 hjemmesiden, hvorimod <em>Log ind <\/em>er en funktion og ikke en navigationsmulighed. Derfor har vi inddelt det i to grupper for at tydeligg\u00f8re forskellen for brugeren. Det f\u00f8lger ogs\u00e5 Gestaltloven <em>Perception<\/em>, s\u00e5 alle menu elementerne ikke bliver opfattet som \u00e9n gruppe.<\/p>\n<p>I menubaren har vi brugt to ikoner, det ene er ved siden af <em>Om os <\/em>og det andet ikon ved siden af <em>Log ind<\/em>. Log ind symbolet er et konventionelt ikon, som bruges mange steder for at indikere en log ind funktion. Ikonet er samtidigt ogs\u00e5 et metafor ikon, og kan symbolisere handlingen at g\u00e5 igennem en \u00e5ben d\u00f8r, som har en sammenh\u00e6ng til det at logge ind. N\u00e5r brugeren er logget ind, vil der i stedet st\u00e5 <em>Log ud<\/em>, og symbolet vil v\u00e6re stort set det samme, p\u00e5 n\u00e6r at pilen vender ud af og ikke indad, som ses p\u00e5 figur 5.3. Ikonet ved siden af <em>Om os <\/em>i menubaren er en pil som vender ned. Den er brugt til at indikere, at der er en undermenu. Dette er ogs\u00e5 et konventionelt brugt ikon, som bruges i et stort omfang til at indikere, at der er mere information til stede. Det bliver blandt andet brugt i Word, Google docs samt menulinjen i Windows. Brugen af konventionelle ikoner tilgodeser designprincippet <em>familiarity <\/em>(se afsnit 4.2) [Benyon 2014, side 86]. Vi har valgt dette ikon, da det er let genkendeligt og hj\u00e6lper brugeren til at forst\u00e5, at der er mere information under dette menuelement.<\/p>\n<p><img loading=\"lazy\" width=\"1203\" height=\"326\" class=\"wp-image-1551\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-17.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-17.jpeg 1203w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-17-300x81.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-17-768x208.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-17-1024x277.jpeg 1024w\" sizes=\"(max-width: 1203px) 100vw, 1203px\" \/><\/p>\n<p><strong>Figur 5.3: <\/strong>Sk\u00e6rmbillede af drop-down menuen fra mbtennis.dk<\/p>\n<p>M\u00e5den undermenuen \u00e5bnes p\u00e5 er ved brug af en hoverfunktion, som \u00e5bner menuen automatisk, n\u00e5r musemark\u00f8ren placeres over knappen. Grunden til at vi har gjort brug af en undermenu, eller en cascading menu, er for at holde hovedmenuen s\u00e5 simpel som mulig, og derved undg\u00e5 at brugeren har for mange elementer at forholde sig til p\u00e5 en gang. Undermenuen f\u00f8lger ogs\u00e5 princippet <em>chunking<\/em>, da den nye undermenu, som \u00e5bnes er en gruppering af relaterede emner, som alle relaterer sig til menuelementet <em>Om os<\/em>.<\/p>\n<h3>5.2.2 Bookingkalenderen<\/h3>\n<p>P\u00e5 undersiden <em>Booking af bane <\/em>ses bookingkalenderen, som er repr\u00e6senteret af en ugentlig kalender, hvor det er muligt at g\u00e5 frem og tilbage mellem ugerne (se figur 5.4).<\/p>\n<p>Vi har valgt at lave kalenderen i dette genkendelige format, s\u00e5ledes at brugeren ikke skal s\u00e6tte sig for meget ind i systemet for at kunne benytte sig af det. Dette f\u00f8lger designprincippet <em>familiarity <\/em>(se afsnit 4.2).<\/p>\n<p><img loading=\"lazy\" width=\"1170\" height=\"617\" class=\"wp-image-1552\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-18.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-18.jpeg 1170w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-18-300x158.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-18-768x405.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-18-1024x540.jpeg 1024w\" sizes=\"(max-width: 1170px) 100vw, 1170px\" \/><\/p>\n<p><strong>Figur 5.4: <\/strong>Sk\u00e6rmbillede af bookingkalenderen fra mbtennis.dk<\/p>\n<p><img loading=\"lazy\" width=\"243\" height=\"175\" class=\"wp-image-1553\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-19.jpeg\"><\/p>\n<p><strong>Figur 5.5: <\/strong>Musemark\u00f8rer: Venstre side er en normal mark\u00f8r.<\/p>\n<p>H\u00f8jre side er en pointer, hvor det er muligt at trykke p\u00e5 det musemark\u00f8ren er over.<\/p>\n<p>N\u00e5r brugeren skal booke en tid vil denne opleve, at der er en hovereffekt p\u00e5 tiderne i kalenderen (se figur 5.4). Samtidig vil musemark\u00f8ren \u00e6ndre udseende fra en pil til en pointer for at symbolisere, at det nu er muligt at trykke p\u00e5 cellen (se figur 5.5). Denne effekt har vi valgt at benytte os af, da det indikerer, at det er muligt at trykke p\u00e5 selve cellen og derved tydeligg\u00f8r interaktionsmuligheden for brugeren. Dette f\u00f8lger designprincipperne <em>affordance <\/em>og <em>visibility <\/em>(se afsnit 4.2).<\/p>\n<p>Vi har valgt at benytte farverne gr\u00f8n, r\u00f8d, gr\u00e5 og bl\u00e5 i bookingkalenderen (se figur 5.4), som f\u00f8lger de vestlige farvekonventitioner.<\/p>\n<ul>\n<li><strong>Gr\u00f8n: <\/strong>Indikation for at banen er ledig<\/li>\n<li><strong>R\u00f8d: <\/strong>Indikation for at banen er optaget<\/li>\n<li><strong>Gr\u00e5: <\/strong>Indikation for at den p\u00e5g\u00e6ldende tid er passeret, og derfor ikke kan bookes<\/li>\n<li><strong>Bl\u00e5: <\/strong>Den reservation, som brugeren har foretaget sig. Den bl\u00e5 farve er valgt, da den st\u00e5r i kontrast til det den r\u00f8de farve, er neutral og fremst\u00e5r rolig.<\/li>\n<\/ul>\n<p>N\u00e5r brugeren v\u00e6lger en tid, vedkommende gerne vil booke i kalenderen, vil tiden \u00e5bne sig i et pop-op vindue (se figur 5.6). Vi har valgt at inddrage denne funktion, da dette vil holde brugeren fokuseret p\u00e5 de informationer, der bliver vist, samt s\u00f8rge for de ikke bliver distraheret af andre informationer p\u00e5 websitet. Dette f\u00f8lger samtidig ogs\u00e5 loven <em>Closure<\/em>, da vi p\u00e5 et sted samler de informationer, som brugeren skal forholde sig til.<\/p>\n<p><img loading=\"lazy\" width=\"1255\" height=\"716\" class=\"wp-image-1554\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-20.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-20.jpeg 1255w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-20-300x171.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-20-768x438.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-20-1024x584.jpeg 1024w\" sizes=\"(max-width: 1255px) 100vw, 1255px\" \/><\/p>\n<p><strong>Figur 5.6: <\/strong>Sk\u00e6rmbillede af pop-op vindue i bookingkalender p\u00e5 mbtennis.dk<\/p>\n<h3>5.2.3 Knapper<\/h3>\n<p>Ved udarbejdelsen af knapperne p\u00e5 siden var det vigtigt at lave et kontinuerligt design, som derved s\u00f8rger for de forskellige funktioner er genkendelige for brugeren. Designet af de forskellige knapper er derfor gennemg\u00e5ende p\u00e5 samtlige sider p\u00e5 websitet.<\/p>\n<p>P\u00e5 figur 5.6 ses <em>Bekr\u00e6ft booking- <\/em>og <em>Annuller<\/em>-knapperne. Vi har valgt at placere disse knapper i hver sin side i pop-op vinduet, da de to funktioner adskiller sig fra hinanden. Samtidig bliver der mere fokus p\u00e5 valget <em>Bekr\u00e6ft booking <\/em>ved at dele dem op, da de to valg ikke vil blive opfattet som en helhed, hvilket f\u00f8lger gestaltloven <em>perception<\/em>.<\/p>\n<p>Knapperne har f\u00e5et farverne gr\u00f8n og r\u00f8d, da det ud fra de vestlige farvekonventitioner er de farver, der oftest benyttes til at separere valgene bekr\u00e6ft og annuller. Samtidig er der ogs\u00e5 her p\u00e5lagt en hover-effekt, for igen at tydeligg\u00f8re interaktionsmuligheden.<\/p>\n<p>P\u00e5 n\u00e6sten alle administratorsiderne er der i bunden af hvert tekststykke opsat en redigeringsfunktion (se figur 5.7). Vi har valgt at give denne knap farven bl\u00e5, da det er en rolig og neutral farve, som st\u00e5r i kontrast til farverne gr\u00f8n og r\u00f8d. Den bl\u00e5 farve er valgt for at vise, at der ved tryk p\u00e5 knappen vil komme information frem, som administratoren derefter vil skulle tage stilling til. Dette underst\u00f8ttes af designprincippet <em>visibility <\/em>(se afsnit 4.2).<\/p>\n<p>N\u00e5r administratoren trykker ind, vil denne blive pr\u00e6senteret for et pop-op vindue (se figur 5.8), som har et sammenligneligt design med bookingfunktionen (se figur 5.6).<\/p>\n<p><img loading=\"lazy\" width=\"1012\" height=\"442\" class=\"wp-image-1555\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-21.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-21.jpeg 1012w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-21-300x131.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-21-768x335.jpeg 768w\" sizes=\"(max-width: 1012px) 100vw, 1012px\" \/><\/p>\n<p><strong>Figur 5.7: <\/strong>Sk\u00e6rmbillede af redigeringsknap p\u00e5 mbtennis.dk<\/p>\n<p><img loading=\"lazy\" width=\"1217\" height=\"749\" class=\"wp-image-1556\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-22.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-22.jpeg 1217w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-22-300x185.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-22-768x473.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-22-1024x630.jpeg 1024w\" sizes=\"(max-width: 1217px) 100vw, 1217px\" \/><\/p>\n<p><strong>Figur 5.8: <\/strong>Sk\u00e6rmbillede af redigeringsfunktion p\u00e5 mbtennis.dk<\/p>\n<p>Det simple design af knapperne p\u00e5 hele websitet mindsker udfaldet for fejl, da designet af pop-op vinduet og de f\u00e5 muligheder gerne skulle medf\u00f8re, at brugeren nemmere kan holde fokus p\u00e5 den igangv\u00e6rende opgave. Dette f\u00f8lger bl.a. loven <em>Closure <\/em>og designprincippet <em>recovery <\/em>(se afsnit 4.2).<\/p>\n<p>Systemet har generelt et meget gennemg\u00e5ende design, som s\u00f8rger for at det er nemt at danne sig et overblik, samt navigere gennem siderne. P\u00e5 administratorsiderne har de forskellige funktioner et bestemt og ensformigt design, samt f\u00e5et tydeliggjort deres funktion i form af beskrivende tekst. Dette er netop gjort for at mindske fejl og misforst\u00e5elser, n\u00e5r administratoren skal benytte systemet.<\/p>\n<p><strong>Kapitel6<\/strong><\/p>\n<h1>Implementering<\/h1>\n<p>I f\u00f8lgende afsnit vil vi forklare om kodeforl\u00f8bet, gennemg\u00e5 de centrale funktioner i vores system samt forklare, hvordan koden fungerer i disse. Vi har udvalgt bookingkalenderen, log ind systemet og nogle administratorfunktioner. Disse er nogle af de vigtigste funktioner i systemet, samt dem, der har v\u00e6ret den st\u00f8rste udfordring. Derudover vil vi ogs\u00e5 forklare de kodesprog, vi har brugt i udformningen af systemet.<\/p>\n<p>I starten af vores kodeproces benyttede vi hosting servicen 5gbfree.com [5GBfree n.d.], men den havde nogle begr\u00e6nsninger, som gjorde at vi skiftede hosting service. Derfor valgte vi i stedet at k\u00f8be hosting service hos unoeuro.com [UnoEuro n.d.], som ikke havde samme begr\u00e6nsninger, underst\u00f8ttede vores arbejde med MySQL bedre og tager samtidig dagligt backup af filerne. Vi har fors\u00f8gt at sikre versionskontrol ved l\u00f8bende at uploade vores kode til GitHub [Inc. n.d.], for at sikre vi havde en version af systemet, der virkede, i tilf\u00e6lde af at der skulle g\u00e5 noget galt.<\/p>\n<h2>6.1 Sprog<\/h2>\n<p>Vi har brugt f\u00f8lgende kodesprog i vores projekt: HTML, CSS, PHP og JavaScript samt databasesystemet MySQL.<\/p>\n<h3>HTML<\/h3>\n<p>HTML er en forkortelse af HyperText Markup Language, som er et programmeringssprog, der bruges til at opstille hjemmesider [Felke-Morris 2011, side 14]. Selve sproget best\u00e5r blandt andet af forskellige tags (ogs\u00e5 kaldet elementer) til at danne en struktur p\u00e5 en hjemmeside. Disse elementer kan v\u00e6re tags s\u00e5som <em>&lt;h1&gt;<\/em>, som vil medf\u00f8re at den efterf\u00f8lgende skrift bliver en stor overskrift indtil tagget <em>&lt;\/h1&gt; <\/em>skrives, og dermed bestemmer, hvor overskriften slutter. Foruden tekst er, der ved brugen af HTML, blandt andet mulighed for at inds\u00e6tte billeder,<\/p>\n<p><em>6.1. SPROG<\/em><\/p>\n<p>lave forms<sup><sup><a id=\"post-1531-footnote-ref-5\" href=\"#post-1531-footnote-5\">[5]<\/a><\/sup> <\/sup>og inds\u00e6tte knapper, samt lave referencer, der linker til andre sider p\u00e5 internettet.<\/p>\n<h3>CSS<\/h3>\n<p>CSS eller Cascading Style Sheets er et client-side<sup><sup><a id=\"post-1531-footnote-ref-6\" href=\"#post-1531-footnote-6\">[6]<\/a><\/sup> <\/sup>sprog, der kan \u00e6ndre p\u00e5 det visuelle design af hjemmesider [Nixon 2014, side 423]. Med CSS kan der m\u00e5lrettes <em>styles <\/em>til elementer i HTML-koden gennem en selector. En selector kunne f.eks. v\u00e6re <em>h1, p, body, <\/em>et selvvalgt <em>id<\/em><sup><sup><a id=\"post-1531-footnote-ref-7\" href=\"#post-1531-footnote-7\">[7]<\/a><\/sup><\/sup>eller <em>class<\/em><sup><sup><a id=\"post-1531-footnote-ref-8\" href=\"#post-1531-footnote-8\">[8]<\/a><\/sup><\/sup>. Efter at have valgt en selector<sup><sup><a id=\"post-1531-footnote-ref-9\" href=\"#post-1531-footnote-9\">[9]<\/a><\/sup> <\/sup>p\u00e5 sin hjemmeside skal der tilf\u00f8jes en attribut til \u00e6ndring, eksempelvis <em>color<\/em>, <em>size<\/em>, <em>margin<\/em>, <em>padding <\/em>osv. Afslutningsvis s\u00e6ttes en v\u00e6rdi p\u00e5 den attribut, der skal \u00e6ndres. Ved <em>size <\/em>kan der v\u00e6lges <em>px <\/em>eller <em>em <\/em>og ved <em>color <\/em>kan der eksempelvis v\u00e6lges <em>green <\/em>eller <em>blue<\/em>. Et eksempel p\u00e5 et stykke CSS kode kunne dermed v\u00e6re: <em>\u201ch1 color: red;\u201d<\/em><\/p>\n<h3>PHP<\/h3>\n<p>PHP st\u00e5r for PHP Hypertext Preprocessor og er et serverside<sup><sup><a id=\"post-1531-footnote-ref-10\" href=\"#post-1531-footnote-10\">[10]<\/a><\/sup> <\/sup>scriptsprog [Nixon 2014, side<\/p>\n<p>45]. PHP kan lave en statisk hjemmeside dynamisk. En dynamisk hjemmeside er en, der laver en HTML fil baseret p\u00e5 data fra en database og\/eller PHP funktioner.<\/p>\n<p>En vigtig del af PHP sproget er variabler, som er en &#8220;beholder&#8221;, der indeholder informationer, som f.eks et array<sup><sup><a id=\"post-1531-footnote-ref-11\" href=\"#post-1531-footnote-11\">[11]<\/a><\/sup> <\/sup>eller string. Et eksempel p\u00e5 en variabel kunne v\u00e6re <em>$tennisspillere<\/em>. Denne variabel kunne v\u00e6re en array, der indeholder alle navnene p\u00e5 tennisspillere i foreningen. En anden vigtig ting i PHP er funktioner. En funktion er et stykke kode, som bliver aktiveret af en trigger. Eksempelvis hvis en bruger klikker p\u00e5 en bestemt knap p\u00e5 hjemmesiden, s\u00e5 k\u00f8res scriptet i funktionen.<\/p>\n<h3>MySQL<\/h3>\n<p>MySQL (SQL er en forkortelse af Structured Query Language) [Nixon 2014, side 171] er et databasesystem, og er det databasesystem vi har benyttet p\u00e5 det website, vi har udviklet. En MySQL database kan best\u00e5 af adskillige tabeller, som hver is\u00e6r best\u00e5r af r\u00e6kker og kolonner, som indeholder data [Nixon 2014, side 172].<\/p>\n<p><em>6.1. SPROG<\/em><\/p>\n<p>Der kan prim\u00e6rt interageres med MySQL gennem tre veje: kommandoprompt, et interface p\u00e5 en hjemmeside (s\u00e5som phpMyAdmin<sup><sup><a id=\"post-1531-footnote-ref-12\" href=\"#post-1531-footnote-12\">[12]<\/a><\/sup><\/sup>) eller gennem et sprog s\u00e5som PHP [Nixon 2014, side 171-172]. Vi har i dette projekt udelukkende benyttet os af phpMyAdmin til at oprette tabeller, og derefter indskrevet eller hentet data via PHP.<\/p>\n<h3>JavaScript<\/h3>\n<p>JavaScript er et scripting sprog, der udelukkende k\u00f8rer i webbrowseren [Nixon 2014, side 324]. Sproget minder meget om PHP, men den prim\u00e6re forskel er at PHP k\u00f8rer p\u00e5 server-side og<\/p>\n<p>JavaScript k\u00f8rer p\u00e5 client-side. JavaScript kan bruges til en r\u00e6kke ting, men vi har prim\u00e6rt benyttet det til at \u00e6ndre HTML og CSS kode.<\/p>\n<p>Vi har blandt andet benyttet JavaScript til at lave en slags pop-up vindue kaldet en <em>modal<\/em>. Denne modal har vi brugt i flere henseender, blandt andet til administratorfunktionerne, galleriet, samt bookingkalenderen. Modalen i kalenderen ser ud som vist p\u00e5 figur 6.1.<\/p>\n<p><img loading=\"lazy\" width=\"894\" height=\"541\" class=\"wp-image-1557\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-23.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-23.jpeg 894w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-23-300x182.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-23-768x465.jpeg 768w\" sizes=\"(max-width: 894px) 100vw, 894px\" \/><\/p>\n<p><strong>Figur 6.1: <\/strong>Modalen, som den ser ud p\u00e5 bookingsiden<\/p>\n<p>Denne modal bliver \u00e5bnet, n\u00e5r der trykkes p\u00e5 en ledig tid i kalenderen. Her er det JavaScript der s\u00f8rger for at modalen bliver vist. Hvordan dette pr\u00e6cist sker vil blive beskrevet yderligere i afsnit 6.4.<\/p>\n<p><em>6.2. DATABASE<\/em><\/p>\n<h2>6.2 Database<\/h2>\n<p>Det databasesystem vi har benyttet p\u00e5 mbtennis.dk er MySQL og er h\u00e5ndteret gennem PHPMyAdmin. Databasen best\u00e5r af otte forskellige tabeller (se figur 6.2), som hver is\u00e6r indeholder data, der bliver benyttet p\u00e5 websitet. De to mest benyttede tabeller er <em>medlemmer <\/em>og <em>booking<\/em>. Disse databaser er essentielle for henholdsvis at kunne logge ind p\u00e5 siden, samt foretage reservationer af tennisbanen.<\/p>\n<p><img loading=\"lazy\" width=\"155\" height=\"241\" class=\"wp-image-1558\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-24.jpeg\"><\/p>\n<p><strong>Figur 6.2: <\/strong>Oversigt over de tabeller databasen indeholder<\/p>\n<p>Tabellen <em>medlemmer <\/em>(se figur 6.3) indeholder data for alle de indmeldte medlemmer i klubben, s\u00e5som deres kontaktoplysninger, log ind og om betalingen for medlemskab er registreret eller ej.<\/p>\n<p><img loading=\"lazy\" width=\"1081\" height=\"209\" class=\"wp-image-1559\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-25.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-25.jpeg 1081w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-25-300x58.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-25-768x148.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-25-1024x198.jpeg 1024w\" sizes=\"(max-width: 1081px) 100vw, 1081px\" \/><\/p>\n<p><strong>Figur 6.3: <\/strong>P\u00e5 figuren ses de informationer, som er lagret i tabellen <em>medlemmer<\/em><\/p>\n<p>Strukturen for tabellen <em>medlemmer <\/em>kan ses p\u00e5 figur 6.4 og s\u00e6tter de begr\u00e6nsninger, som afg\u00f8r, hvad der kan inds\u00e6ttes af data i de forskellige kolonner i tabellen. Ikonet af den lille n\u00f8gle ved siden af navnet <em>ID <\/em>er en indikation for, at <em>ID\u2019et <\/em>er en <em>primary key <\/em>for tabellen, hvilket vil sige, at der i den kolonne skal v\u00e6re forskellige v\u00e6rdier for hvert medlem. Datatypen for <em>ID <\/em>er sat til at v\u00e6re <em>int(11)<\/em>, hvilket betyder at dataen udelukkende er tal og kan indeholde op til 11 cifre. Nulv\u00e6rdien er sat til <em>Nej<\/em>, som medf\u00f8rer, at kolonnen ikke kan v\u00e6re tom. Ydermere<\/p>\n<p><em>6.2. DATABASE<\/em><\/p>\n<p>har <em>ID\u2019et <\/em>et ekstra element, <em>AUTO_INCREMENT<\/em>, som g\u00f8r at v\u00e6rdien automatisk bliver udfyldt og sat til det n\u00e6ste endnu ikke benyttede tal i r\u00e6kken.<\/p>\n<p>Datatypen <em>varchar( ) <\/em>betyder, at dataen i kolonnen kan v\u00e6re af varierende karakterer i form af eksempelvis tal, bogstaver eller tegn s\u00e5som @. Tegns\u00e6ttet <em>latin1_danish_ci <\/em>betyder, at tegnene kan v\u00e6re danske, og at der ikke er forskel p\u00e5 store og sm\u00e5 bogstaver.<\/p>\n<p><img loading=\"lazy\" width=\"797\" height=\"367\" class=\"wp-image-1560\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-26.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-26.jpeg 797w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-26-300x138.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-26-768x354.jpeg 768w\" sizes=\"(max-width: 797px) 100vw, 797px\" \/><\/p>\n<p><strong>Figur 6.4: <\/strong>Strukturen for tabellen <em>medlemmer <\/em>i databasen<\/p>\n<h3>6.2.1 Oprettelse af forbindelse til databasen<\/h3>\n<p>For at oprette forbindelse til databasen linkes der p\u00e5 n\u00e6sten alle sider af websitet til PHP-filen <em>connection.php<\/em>, hvori der oprettes en variabel, som efterf\u00f8lgende bruges i forbindelse med at hente eller sende data til en eller flere tabeller i databasen (se figur 6.5).<\/p>\n<p><img loading=\"lazy\" width=\"601\" height=\"101\" class=\"wp-image-1561\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-27.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-27.jpeg 601w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-27-300x50.jpeg 300w\" sizes=\"(max-width: 601px) 100vw, 601px\" \/><\/p>\n<p><strong>Figur 6.5: <\/strong>Koden, som filen <em>connection.php <\/em>indeholder<\/p>\n<p>I variablen <em>$connection <\/em>p\u00e5 linje 3 lagres funktionen <em>mysqli_connect( )<\/em>, hvor der i parentesen inds\u00e6ttes de informationer, som skal bruges til at oprette forbindelse til databasen. P\u00e5 figur 6.5 er der af sikkerhedsm\u00e6ssige \u00e5rsager udskiftet de korrekte informationer med placeholdere,<\/p>\n<p><em>6.3. PRINCIPPET BAG BOOKING SYSTEMET<\/em><\/p>\n<p>som informerer om, hvad der skal st\u00e5 mellem de respektive apostroffer. Kan der ikke oprettes forbindelse til databasen vil fejlmeddelelsen \u201d<em>cannot connect to database<\/em>\u201d blive skrevet p\u00e5 hjemmesiden.<\/p>\n<h2>6.3 Princippet bag booking systemet<\/h2>\n<p>Vi vil i dette afsnit gennemg\u00e5 den tankegang, der ligger til grund for vores m\u00e5de at konstruere bookingsystemet p\u00e5. Overordnet set har tankegangen v\u00e6ret, at bookinger skulle v\u00e6re relationer mellem to set (m\u00e6ngder<sup><sup><a id=\"post-1531-footnote-ref-13\" href=\"#post-1531-footnote-13\">[13]<\/a><\/sup><\/sup>) best\u00e5ende af mulige datoer og mulige tidspunkter [Rosen 2019, side 116]. Dette er illustreret i figur 6.6.<\/p>\n<p><img loading=\"lazy\" width=\"552\" height=\"310\" class=\"wp-image-1562\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-28.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-28.jpeg 552w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-28-300x168.jpeg 300w\" sizes=\"(max-width: 552px) 100vw, 552px\" \/><\/p>\n<p><strong>Figur 6.6: <\/strong>Set med datoer og set med tidspunkter<\/p>\n<p>Til venstre p\u00e5 figur 6.6 ses settet med de mulige datoer brugeren kan booke, og dette set fors\u00e6tter i princippet uendeligt. Til h\u00f8jre ses settet med de mulige tidspunkter p\u00e5 dagen, hvor banen kan bookes. Dette set g\u00e5r fra kl. 6:00 til kl. 22:00. Hvis der bookes en tid d. 2019-05-10 kl. 8:00, vil der derfor komme en relation, som illustreret i figur 6.7. Den bl\u00e5 pil viser relationen.<\/p>\n<p><img loading=\"lazy\" width=\"548\" height=\"316\" class=\"wp-image-1563\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-29.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-29.jpeg 548w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-29-300x173.jpeg 300w\" sizes=\"(max-width: 548px) 100vw, 548px\" \/><\/p>\n<p><strong>Figur 6.7: <\/strong>De to set med en relation mellem dem<\/p>\n<p><em>6.3. PRINCIPPET BAG BOOKING SYSTEMET<\/em><\/p>\n<p>Denne relation vil blive lagret i databasen og p\u00e5 selve bookingkalenderen, vil den nu fremst\u00e5 som optaget. Alle bookinger vil s\u00e5ledes kunne blive repr\u00e6senteret som en r\u00e6kke pile &#8211; ligesom den bl\u00e5. Der vil f.eks. sagtens kunne komme flere pile ud fra datoen 2019-05-10, som derved henviser til forskellige tider p\u00e5 dagen.<\/p>\n<p>Vi har ogs\u00e5 brug for at vide, hvem der har reserveret de enkelte tider. Derfor vil hver relation have information om, hvem der har reserveret tiden i databasen. Hvis nu Jens Jensen gerne vil booke en tid p\u00e5 banen med Niels Nielsen d. 2019-05-10 kl. 8:00 vil relationen derfor komme til at hedde deres navne, som illustreret i venstre side af figur 6.8. Da der godt kan<\/p>\n<p><img loading=\"lazy\" width=\"1090\" height=\"263\" class=\"wp-image-1564\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-30.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-30.jpeg 1090w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-30-300x72.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-30-768x185.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-30-1024x247.jpeg 1024w\" sizes=\"(max-width: 1090px) 100vw, 1090px\" \/><\/p>\n<p><strong>Figur 6.8: <\/strong>Relationernes navne<\/p>\n<p>v\u00e6re flere personer, der har de samme navne, giver vi hvert medlem i klubben et unikt id, som vi kan bruge til at referere til dem. Hvis eksempelvis, at Jens Jensen\u2019s medlemsid er 12, og Niels Nielsen\u2019s medlemsid er 25, vil relationen derfor se ud som i h\u00f8jre side af figur 6.8.<\/p>\n<p>For at f\u00e5 et unikt id p\u00e5 hver booking samles datoen og tidspunktet p\u00e5 reservationen i et enkelt felt. Herefter er reservationen klar til at blive brugt, og dataen inds\u00e6ttes derfor i databasen (se figur 6.9).<\/p>\n<p><img loading=\"lazy\" width=\"594\" height=\"624\" class=\"wp-image-1565\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-31.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-31.jpeg 594w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-31-286x300.jpeg 286w\" sizes=\"(max-width: 594px) 100vw, 594px\" \/><\/p>\n<p><strong>Figur 6.9: <\/strong>Bookinginformation, der inds\u00e6ttes i databasen<\/p>\n<p>Som det fremg\u00e5r af figur 6.9 samles datoen og tidspunktet og s\u00e6ttes herefter ind i database tabellen, som ses p\u00e5 nederste r\u00e6kke. Dette ses i kolonnen <em>date_time<\/em>, som indeholder v\u00e6rdien \u201c2019-05-10.8\u201d, som er den sammensatte dato og tid. Herudover inkluderes de forskellige personer, der gerne vil spille p\u00e5 banen, alts\u00e5 <em>spiller1 <\/em>var medlem nr. 12 (Jens Jensen) og <em>spiller2 <\/em>var medlem nr. 25 (Niels Nielsen).<\/p>\n<h2>6.4 Bookingkalenderen<\/h2>\n<p>Bookingfunktionen er det centrale i vores system. Vores prim\u00e6re motivation for at p\u00e5begynde samarbejdet med netop Midtbyens Tennisklub var erfaringer med den ikke-optimale bookingprocess i klubben. Det er dette problem, som vi fors\u00f8ger at l\u00f8se i dette afsnit. Billeder af den f\u00e6rdige kalender kan ses p\u00e5 figur 6.10 og 6.11<\/p>\n<p><img loading=\"lazy\" width=\"923\" height=\"501\" class=\"wp-image-1566\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-32.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-32.jpeg 923w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-32-300x163.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-32-768x417.jpeg 768w\" sizes=\"(max-width: 923px) 100vw, 923px\" \/><\/p>\n<p><strong>Figur 6.10: <\/strong>Kalenderen, som den ser ud n\u00e5r brugeren er logget ind p\u00e5 siden<\/p>\n<p><img loading=\"lazy\" width=\"887\" height=\"488\" class=\"wp-image-1567\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-33.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-33.jpeg 887w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-33-300x165.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-33-768x423.jpeg 768w\" sizes=\"(max-width: 887px) 100vw, 887px\" \/><\/p>\n<p><strong>Figur 6.11: <\/strong>Denne modal \u00e5bnes, n\u00e5r der klikkes p\u00e5 en gr\u00f8n celle i kalenderen<\/p>\n<h3>H\u00e5ndtering af dato og tider<\/h3>\n<p>Det f\u00f8rste skridt for at programmere bookingfunktionen var at oprette datovariabler, hvilket gjorde det muligt for os at lave en &#8220;uendelig&#8221;kalender. Koden henter datoerne ved hj\u00e6lp af en indbygget PHP-funktion, <em>DateTime<\/em>.<\/p>\n<p><img loading=\"lazy\" width=\"708\" height=\"243\" class=\"wp-image-1568\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-34.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-34.jpeg 708w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-34-300x103.jpeg 300w\" sizes=\"(max-width: 708px) 100vw, 708px\" \/><\/p>\n<p><strong>Figur 6.12: <\/strong>Kode til oprettelse af datovariabler benyttet i kalenderen (<em>booking-af-bane.php<\/em>)<\/p>\n<p>F\u00f8rst oprettes en variabel med den nuv\u00e6rende dato og tid, <em>$dt <\/em>(linje 266 p\u00e5 figur 6.12). Herefter kontrolleres det, om der er k\u00f8rt en funktion, som g\u00f8r, at der vises en anden tid end den nuv\u00e6rende (linje 267-268). Hvis dette ikke er tilf\u00e6ldet skal den blot indeholde det nuv\u00e6rende \u00e5r og ugenummer (linje 269-270).<\/p>\n<p>Herefter inds\u00e6ttes \u00e5r, ugenummer, m\u00e5ned og dag ind i variabler, s\u00e5 de kan benyttes senere i koden (linje 272-275).<\/p>\n<p>Koden i figur 6.12 benyttes til at konstruere navigationen i kalenderen, s\u00e5 det er muligt at \u00e6ndre ugerne ved hj\u00e6lp af to knapper til at g\u00e5 en uge frem eller en uge tilbage. P\u00e5 figur<\/p>\n<p>6.13 kan koden for tableheaderen<sup><sup><a id=\"post-1531-footnote-ref-14\" href=\"#post-1531-footnote-14\">[14]<\/a><\/sup> <\/sup>ses, hvori navigationsknapperne er placeret.<\/p>\n<p><img loading=\"lazy\" width=\"512\" height=\"232\" class=\"wp-image-1569\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-35.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-35.jpeg 512w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-35-300x136.jpeg 300w\" sizes=\"(max-width: 512px) 100vw, 512px\" \/><\/p>\n<p><strong>Figur 6.13: <\/strong>Kode, som opretter navigationsknapper i kalenderen. N\u00e5r der eksempelvis klikkes p\u00e5<\/p>\n<p><em>N\u00e6ste uge <\/em>vil der blive lagt 1 til variablen <em>$week<\/em>, og variablens nye v\u00e6rdi g\u00f8r, at den n\u00e6ste uge vises i kalenderen (<em>booking-af-bane.php<\/em>)<\/p>\n<p>Det v\u00e6sentligste i koden p\u00e5 figur 6.13 er knapperne <em>Forrige uge <\/em>og <em>N\u00e6ste uge<\/em>. N\u00e5r der klikkes p\u00e5 en af disse, \u00e6ndres der p\u00e5 tidsvariablen, <em>$dt<\/em>, og der skiftes enten en uge frem eller en uge tilbage i kalenderen. I kodestykket er der en restriktion gennem et <em>if else statement<\/em><sup><sup><a id=\"post-1531-footnote-ref-15\" href=\"#post-1531-footnote-15\">[15]<\/a><\/sup><\/sup>(linje 371-372), som g\u00f8r at knappen <em>Forrige Uge <\/em>ikke er tilg\u00e6ngelig, hvis kalenderen viser indev\u00e6rende uge. Dette er for brugerne ikke skal kunne g\u00e5 tilbage i kalenderen og booke en tid der ligger i fortiden (denne restriktion er dog ikke at finde p\u00e5 administrator versionen af siden).<\/p>\n<p>Herefter inds\u00e6ttes ugedage og datoer ind i de \u00f8verste felter i kalenderen i r\u00e6kken under tableheaderen, hvor forrige- og n\u00e6ste uge-knapperne (figur 6.15).<\/p>\n<p><img loading=\"lazy\" width=\"851\" height=\"218\" class=\"wp-image-1570\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-36.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-36.jpeg 851w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-36-300x77.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-36-768x197.jpeg 768w\" sizes=\"(max-width: 851px) 100vw, 851px\" \/><\/p>\n<p><strong>Figur 6.14: <\/strong>I koden startes et <em>do while loop<\/em>, som overs\u00e6tter dagene fra engelsk til dansk, og gemmer de nye navne i variablen <em>$ugedagdansk <\/em>(<em>booking-af-bane.php<\/em>) (koden slutter p\u00e5 figur 6.15)<\/p>\n<p>[&#8230;]<\/p>\n<p><img loading=\"lazy\" width=\"860\" height=\"262\" class=\"wp-image-1571\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-37.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-37.jpeg 860w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-37-300x91.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-37-768x234.jpeg 768w\" sizes=\"(max-width: 860px) 100vw, 860px\" \/><\/p>\n<p><strong>Figur 6.15: <\/strong>Her sluttes <em>do while loopet <\/em>(<em>booking-af-bane.php<\/em>) (koden starter p\u00e5 figur 6.14)<\/p>\n<p>I et <em>do while loop<\/em><sup><sup><a id=\"post-1531-footnote-ref-16\" href=\"#post-1531-footnote-16\">[16]<\/a><\/sup> <\/sup>hentes f\u00f8rst ugedagene, hvor vi derefter overs\u00e6tter dagen til dansk gennem et <em>switch statement <\/em>(se figur 6.14 og 6.15). Herefter laver vi felter med ugedagen og datoen, og derefter inds\u00e6ttes de felt for felt i kalenderen, indtil vi kommer ind i en ny uge, dvs. at loopet k\u00f8rer imens <em>$week == $dt-&gt;format(\u2018W\u2019));<\/em>, og stopper derved, n\u00e5r variablen <em>$week <\/em>skifter v\u00e6rdi til en ny uge (linje 411-413).<\/p>\n<h3>Udfyldning af felter til booking<\/h3>\n<p>For at udfylde resten af bookingkalenderen benytter vi os bl.a. af f\u00f8lgende kode, som udfylder de resterende celler med informationer. Koden til at g\u00f8re dette er lang, s\u00e5 vi har inddelt den i mindre sektioner best\u00e5ende af figur 6.16 til figur 6.18<\/p>\n<p><img loading=\"lazy\" width=\"861\" height=\"292\" class=\"wp-image-1572\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-38.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-38.jpeg 861w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-38-300x102.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-38-768x260.jpeg 768w\" sizes=\"(max-width: 861px) 100vw, 861px\" \/><\/p>\n<p><strong>Figur 6.16: <\/strong>Variabler til tidsintervaller, der kan bookes tider i (<em>booking-af-bane.php<\/em>)<\/p>\n<p>F\u00f8rst og fremmest oprettes en r\u00e6kke variabler, som skal bruges, dels til dette afsnit, og dels til de tilh\u00f8rende JavaScript kodestykker (disse ses blandt andet i figur 6.21). <em>$x <\/em>og <em>$y <\/em>viser de tidspunkter p\u00e5 dagen, som brugeren kan booke, og den f\u00f8rste mulige tid er fra kl. 6:00 til klokken 7:00. Variablen <em>$antaltimer <\/em>viser antallet af ledige tider, og variablen <em>$antalbookinger <\/em>viser antallet af bookinger.<\/p>\n<p>Herefter startes et <em>while loop<\/em><sup><sup><a id=\"post-1531-footnote-ref-17\" href=\"#post-1531-footnote-17\">[17]<\/a><\/sup> <\/sup>med de forskellige tidspunkter p\u00e5 dagen, som kan bookes. Alts\u00e5 fra kl. 6 til kl. 23 (<em>$i <\/em>= 6 til og med <em>$i <\/em>= 22). Dette loop angiver antallet af r\u00e6kker i kalenderen, og tidsintervallet inds\u00e6ttes i den f\u00f8rste kolonne.<\/p>\n<p><img loading=\"lazy\" width=\"849\" height=\"864\" class=\"wp-image-1573\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-39.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-39.jpeg 849w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-39-295x300.jpeg 295w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-39-768x782.jpeg 768w\" sizes=\"(max-width: 849px) 100vw, 849px\" \/><\/p>\n<p><strong>Figur 6.17: <\/strong>I et <em>do while loop <\/em>er der indsat et <em>if elseif statement<\/em>, som bestemmer, hvilken class de enkelte tider i kalenderen skal tildeles (<em>booking-af-bane.php<\/em>)<\/p>\n<p>I <em>while loopet <\/em>inds\u00e6ttes et <em>do while loop <\/em>(se figur 6.17), som udfylder de enkelte celler i kalenderen for det p\u00e5g\u00e6ldende tidsinterval. F\u00f8rst tildeles hvert felt (<em>&lt;td&gt;<\/em><sup><sup><a id=\"post-1531-footnote-ref-18\" href=\"#post-1531-footnote-18\">[18]<\/a><\/sup><\/sup>) et unikt id baseret p\u00e5 dato og tidspunkt. Formatet for id\u2019et lyder s\u00e5ledes: <em>\u00e5r-m\u00e5ned-dag.tidspunkt<\/em>, eksempelvis id=2019-05-16.8 (se linje 432). Dette id er efterf\u00f8lgende den data, som bl.a. inds\u00e6ttes i databasen, n\u00e5r der foretages en booking i kalenderen.<\/p>\n<p>Udover et unikt id tildeles hver celle en <em>class <\/em>baseret p\u00e5 bookingstatusen:<\/p>\n<ul>\n<li>Hvis tiden er ledig f\u00e5r cellen classen <em>timer <\/em>(linje 450-451)<\/li>\n<li>Hvis tiden er booket f\u00e5r den classen <em>redtimer <\/em>(linje 435-441)<\/li>\n<li>Hvis tiden er tidligere end det nuv\u00e6rende tidspunkt og dato, f\u00e5r den classen <em>graytimer <\/em>(linje 454-455).<\/li>\n<\/ul>\n<p>Dette ses p\u00e5 <em>if elseif <\/em>kodestykkerne, som kontrollerer cellerne en efter en.<\/p>\n<p>Der er herefter et JavaScript kodestykke, der s\u00f8rger for, hvad der kan bookes, og ikke kan bookes baseret p\u00e5 cellens tildelte class (se figur 6.21 og 6.24).<\/p>\n<p>I det f\u00f8rste <em>if <\/em>kodestykke kontrolleres det om det unikke id for cellen findes i variablen <em>$minekampe<\/em>, som er et <em>array <\/em>med de kampe, som er reserveret for den p\u00e5g\u00e6ldende bruger. I figur 6.18, ses det hvordan dette <em>array <\/em>oprettes.<\/p>\n<p><img loading=\"lazy\" width=\"857\" height=\"384\" class=\"wp-image-1574\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-40.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-40.jpeg 857w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-40-300x134.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-40-768x344.jpeg 768w\" sizes=\"(max-width: 857px) 100vw, 857px\" \/><\/p>\n<p><strong>Figur 6.18: <\/strong><em>$currentuser <\/em>er det brugerid, der er logget ind nu. <em>Date_time <\/em>er i samme format, som de unikke id\u2019er felterne har, og her v\u00e6lges alle de reservationer af banen, hvor den indloggede bruger er enten <em>spiller1<\/em>, <em>spiller2<\/em>, <em>spiller3 <\/em>eller <em>spiller4<\/em>. Herefter inds\u00e6tter vi de unikke celle id\u2019er, som er reserveret til brugeren i arrayet <em>$minekampe<\/em>. (<em>booking-af-bane.php<\/em>)<\/p>\n<p>Hvis cellens id findes i <em>arrayet $minekampe<\/em>, s\u00e5 skal den farves bl\u00e5 og have classen <em>redtimer<\/em>, og <em>$antalbookinger <\/em>bliver herefter adderet med 1 (se linje 435-437 p\u00e5 figur 6.17). <em>$antalbookinger <\/em>bruges til at lave en ny funktion for hver tid, der er reserveret.<\/p>\n<p>Hvis cellens id ikke er i <em>$minekampe <\/em>kontrolleres det om id\u2019et er i arrayet <em>$dage<\/em>, som er bygget op i samme princip som <em>$minekampe<\/em>, men arrayet indeholder derimod alle de bookinger, som er foretaget. Findes id\u2019et i <em>$dage <\/em>tildeles cellen classen <em>redtimer<\/em>, samt farven r\u00f8d, som indikerer at tiden er reserveret af andre brugere.<\/p>\n<p>Findes id\u2019et heller ikke i <em>arrayet $dage<\/em>, kontrolleres det om den p\u00e5g\u00e6ldende tid er fremtidig eller dags\/tidligere dato. Er tiden fremtidigt tildeles cellen classen <em>timer<\/em>, som g\u00f8r at cellen bliver gr\u00f8nt og kan reserveres af brugeren.<\/p>\n<p>Er tiden dags dato og det ikke er tidligere end det nuv\u00e6rende tidspunkt p\u00e5 dagen, bliver cellen ogs\u00e5 tildelt classen <em>timer<\/em>.<\/p>\n<p>Hvis ingen af de ovenst\u00e5ende kriterier er opfyldt, tildeles classen <em>graytimer<\/em>, hvilket g\u00f8r at cellen bliver gr\u00e5, og det vil ikke v\u00e6re muligt at interagere med den p\u00e5g\u00e6ldende celle.<\/p>\n<p>Efter at have kontrolleret en celle lukkes den (se linje 459 p\u00e5 figur 6.17), og hele loopet g\u00e5r videre til samme tidsrum den efterf\u00f8lgende dag indtil tidsrummet, eksempelvis 8:00-9:00, er udfyldt p\u00e5 alle ugens dage.<\/p>\n<p><em>Do while loopet <\/em>er nu f\u00e6rdigt, men der er stadig en del af det yderste <em>while loop<\/em>, som k\u00f8rer for alle timerne. Dette loop slutter lige efter <em>do while loopet <\/em>med kodestykket i figur 6.19.<\/p>\n<p><img loading=\"lazy\" width=\"823\" height=\"191\" class=\"wp-image-1575\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-41.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-41.jpeg 823w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-41-300x70.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-41-768x178.jpeg 768w\" sizes=\"(max-width: 823px) 100vw, 823px\" \/><\/p>\n<p><strong>Figur 6.19: <\/strong>Med dette kodestykke slutter det yderste <em>while loop<\/em>. Her adderes en v\u00e6rdi til variablerne <em>$x<\/em>, <em>$y <\/em>og <em>$i<\/em>, alt imens der subtraheres 7 fra variablen <em>$dt <\/em>(<em>booking-af-bane.php<\/em>)<\/p>\n<p>Her lukkes r\u00e6kken og variablerne <em>$x<\/em>, <em>$y <\/em>og <em>$i <\/em>bliver adderet med 1. <em>$x <\/em>og <em>$y <\/em>var tidsrummet der startede fra 06:00 til 07:00, og bliver adderet med 1, fordi n\u00e6ste tidsinterval er 07:00 til 08:00. <em>$i <\/em>er timetallet, der starter fra 6 og bliver adderet med 1, fordi n\u00e6ste timetal er 7. Herefter s\u00e6ttes <em>$dt2-&gt;modify(\u2018-7 day\u2019); <\/em>for at der startes med den rigtige dato for det n\u00e6ste tidsinterval. Koden udfylder f\u00f8rst det samme klokkesl\u00e6t for alle ugens dage og g\u00e5r derefter videre til det n\u00e6ste klokkesl\u00e6t.<\/p>\n<p>N\u00e5r der trykkes p\u00e5 en farvet celle i kalenderen, \u00e5bnes der et interaktivt vindue, og alt efter om den p\u00e5g\u00e6ldende tid er reserveret eller ej, st\u00e5r der forskellige informationer i vinduet. Er tiden reserveret, oplistes navnene p\u00e5 de personer, som har reserveret tiden. Er tiden derimod ikke reserveret, er der en bookingformular i vinduet, som skal udfyldes af brugeren for at kunne reservere tiden.<\/p>\n<p>Hvad der vises i dette vindue bliver styret af JavaScript og afh\u00e6nger af, hvilken <em>class <\/em>cellen har. Alts\u00e5 om classen er <em>redtimer <\/em>eller <em>timer<\/em>.<\/p>\n<p><img loading=\"lazy\" width=\"848\" height=\"426\" class=\"wp-image-1576\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-42.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-42.jpeg 848w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-42-300x151.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-42-768x386.jpeg 768w\" sizes=\"(max-width: 848px) 100vw, 848px\" \/><\/p>\n<p><strong>Figur 6.20: <\/strong>JavaScript kode, der henter elementerne fra HTML koden (<em>booking-af-bane.php<\/em>)<\/p>\n<p>JavaScript delen starter med at hente de forskellige elementer ind i scriptet gennem kodestykkerne <em>document.getElementBy- Id\/ClassName<\/em>, som kan ses i figur 6.20.<\/p>\n<p><img loading=\"lazy\" width=\"512\" height=\"434\" class=\"wp-image-1577\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-43.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-43.jpeg 512w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-43-300x254.jpeg 300w\" sizes=\"(max-width: 512px) 100vw, 512px\" \/><\/p>\n<p><strong>Figur 6.21: <\/strong>Kodestykke til fremvisning af modalen til bookingkalenderen, n\u00e5r der klikkes p\u00e5 en gr\u00f8n celle (<em>booking-af-bane.php<\/em>)<\/p>\n<p>Herefter laves en funktion per celle med <em>classen timer <\/em>(figur 6.21). Her tilf\u00f8jes en <em>onclick function <\/em>til at vise modalen og <em>v\u00e6lg medspiller<\/em>-delen, n\u00e5r der trykkes p\u00e5 en gr\u00f8n celle i kalenderen. Dern\u00e6st hentes id\u2019et fra de enkelte gr\u00f8nne celler og inds\u00e6ttes i variablen <em>text$i <\/em>(hvor <em>$i <\/em>er et tal fra nul til antallet af felter med <em>classen timer<\/em>). Herefter splitters id\u2019et op ved punktummet, s\u00e5ledes at der er en liste best\u00e5ende af to elementer, en med dato og en med tidspunkt. Datoen og tidspunktet inds\u00e6ttes i overskriften i modalen, f.eks. 2019-05-05 kl. 8:00 (linje 493 p\u00e5 figur 6.21). Ovenfor denne dato og tidspunkt inds\u00e6ttes navnet p\u00e5 den p\u00e5g\u00e6ldende bruger i teksten (linje 495 p\u00e5 figur 6.21) s\u00e5 den endelige besked bliver:<\/p>\n<p>Hej [fornavn]!<\/p>\n<p>Din booking af banen kommer til at hedde:<\/p>\n<p>[dato] kl. [tidspunkt[.<\/p>\n<p><img loading=\"lazy\" width=\"844\" height=\"873\" class=\"wp-image-1578\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-44.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-44.jpeg 844w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-44-290x300.jpeg 290w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-44-768x794.jpeg 768w\" sizes=\"(max-width: 844px) 100vw, 844px\" \/><\/p>\n<p><strong>Figur 6.22: <\/strong>Kodestykke i modalen til at v\u00e6lge medspillere (<em>booking-af-bane.php<\/em>)<\/p>\n<p>Dern\u00e6st f\u00e5r brugeren mulighed for at v\u00e6lge medspiller(e), jf. linje 494 til 516 p\u00e5 figur 6.22. Inden dette er der foretaget en SQL <em>query<\/em><sup><sup><a id=\"post-1531-footnote-ref-19\" href=\"#post-1531-footnote-19\">[19]<\/a><\/sup><\/sup>, der henter alle medlemmer i foreningen (undtagen administrator og indloggede bruger) ind i arrayene <em>$medlemid2<\/em>, <em>$medlemfornavn2 <\/em>og <em>$medlemefternavn2<\/em>. Alle fornavne og efternavne bliver herefter vist i en drop-down menu, s\u00e5 brugeren kan v\u00e6lge medspillere. Id\u2019et p\u00e5 medspiller(e) bliver brugt i databasen, s\u00e5ledes at den p\u00e5g\u00e6ldende tid ogs\u00e5 bliver reserveret til medspillere(n).<\/p>\n<p><img loading=\"lazy\" width=\"848\" height=\"428\" class=\"wp-image-1579\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-45.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-45.jpeg 848w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-45-300x151.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-45-768x388.jpeg 768w\" sizes=\"(max-width: 848px) 100vw, 848px\" \/><\/p>\n<p><strong>Figur 6.23: <\/strong>Skjulte <em>inputs <\/em>med datoen, tidspunktet samt id\u2019et p\u00e5 den bruger, der er logget ind (<em>booking-af-bane.php<\/em>)<\/p>\n<p>Til sidst i formen er der skjulte <em>inputs <\/em>med datoen og tiden (det unikke id for cellen), samt id\u2019et p\u00e5 den bruger, der er logget ind (figur 6.23). N\u00e5r der klikkes p\u00e5 knappen <em>Bekr\u00e6ft booking <\/em>starter en PHP-fil, som inds\u00e6tter dataene fra modalen i en database, s\u00e5ledes at bookingen er reserveret (et lignende eksempel p\u00e5 dette kan ses i afsnit 6.7).<\/p>\n<p><img loading=\"lazy\" width=\"512\" height=\"408\" class=\"wp-image-1580\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-46.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-46.jpeg 512w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-46-300x239.jpeg 300w\" sizes=\"(max-width: 512px) 100vw, 512px\" \/><\/p>\n<p><strong>Figur 6.24: <\/strong>PHP til at generere JavaScript funktioner til reserverede tider (<em>booking-af-bane.php<\/em>)<\/p>\n<p>Herefter bliver der lavet en ny JavaScript-funktion (linje 624 til 639) til de r\u00f8de og bl\u00e5 celler i kalenderen. Dette g\u00f8res ligesom ved de gr\u00f8nne celler, bortset fra at der her bliver vist, hvem der har reserveret tiden.<\/p>\n<h3>Afmeld tid<\/h3>\n<p><img loading=\"lazy\" width=\"512\" height=\"493\" class=\"wp-image-1581\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-47.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-47.jpeg 512w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-47-300x289.jpeg 300w\" sizes=\"(max-width: 512px) 100vw, 512px\" \/><\/p>\n<p><strong>Figur 6.25: <\/strong>Koden til at vise brugerens reservationer samt muligheden for at afmelde reservationer<\/p>\n<p>(<em>booking-af-bane.php<\/em>)<\/p>\n<p>Til h\u00f8jre for kalenderen ses afmeldfunktionen, hvor brugeren kan se og afmelde sine tider. <em>$minereservationer <\/em>henter alle reservationer brugeren har foretaget (se figur 6.25). Herefter kontrolleres det om de enkelte reservationer er fra dagsdato eller fremtidige (linje 686), og hvis dette er tilf\u00e6ldet bliver de vist for brugeren sammen med en knap, som g\u00f8r det muligt at afmelde den valgte tid (linje 686 til 702).<\/p>\n<p>Datoen i databasen er i formatet yyyy-mm-dd, men for at vise det nemmere for brugeren vises det i formatet dd\/mm (linje 691). For at g\u00f8re dette hentes datoerne ned i variablen<\/p>\n<p><em>$temptid <\/em>i loopet p\u00e5 linje 687. Herefter opdeles de, hvor der er bindestreg (linje 688) for at f\u00e5 \u00e5r, m\u00e5ned og dato fordelt. Derefter inds\u00e6ttes datoen i formatet dag\/m\u00e5ned for bookingen<\/p>\n<p>(linje 691).<\/p>\n<p>Trykkes der p\u00e5 knappen <em>Afmeld tid <\/em>starter PHP-filen, som ses i figur 6.26:<\/p>\n<p><img loading=\"lazy\" width=\"847\" height=\"478\" class=\"wp-image-1582\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-48.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-48.jpeg 847w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-48-300x169.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-48-768x433.jpeg 768w\" sizes=\"(max-width: 847px) 100vw, 847px\" \/><\/p>\n<p>Her hentes datoen og tiden, som brugeren gerne vil afmelde ind i variablen <em>$date_time<\/em>. Herefter k\u00f8rer SQL <em>querien<\/em>, som sletter r\u00e6kken fra databasen <em>booking<\/em>, hvor datoen og tiden er magen til den, som brugeren gerne vil afmelde (linje 6). P\u00e5 linje 10 henviser filen brugeren tilbage til samme side som f\u00f8r, <em>booking-af-bane.php<\/em>.<\/p>\n<h2>6.5 Log-ind<\/h2>\n<p>Der er flere grunde til, at vi valgte at lave et log ind system. Den f\u00f8rste og vigtigste grund er, at det kun er betalende medlemmer, der skal kunne booke en tid p\u00e5 banen. Dern\u00e6st skulle systemet ogs\u00e5 have nogle administratorfunktioner, s\u00e5 bestyrelsen kunne opdatere informationer p\u00e5 hjemmesiden, og her var det ogs\u00e5 oplagt at benytte sig af log ind systemet.<\/p>\n<p>M\u00e5den hvorp\u00e5 en bruger f\u00e5r et log ind er, at denne giver sine oplysninger i indmeldelsesformularen, n\u00e5r vedkommende gerne vil melde sig ind i klubben. Herefter er det personlige log ind lagret i databasen, men ikke aktiveret. Brugerens log-ind bliver f\u00f8rst aktiveret, n\u00e5r kassereren i foreningen har kontrolleret, at der er blevet betalt for medlemskabet, hvorefter det kan benyttes af brugeren.<\/p>\n<p>Log-ind funktionen optr\u00e6der to steder p\u00e5 websitet; under <em>Booking af bane <\/em>og i menubaren (se figur 6.27).<\/p>\n<p>Grunden til at vi oprindeligt valgte at placere log ind funktionen i menubaren var, at b\u00e5de booking- og gallerifunktionen kun skulle kunne tilg\u00e5s, hvis der var logget ind. Det gav derfor mere mening at have en universal log ind funktion p\u00e5 siden, der gav adgang til alle hjemmesidens log ind p\u00e5kr\u00e6vede sider, i stedet for at have en log ind formular til de enkelte sider. Derudover gav bestyrelsesformanden gennem interviewet ogs\u00e5 udtryk for, at han gerne ville have et drop-down log-ind, samt at den kan tilg\u00e5s fra alle sider p\u00e5 websitet.<\/p>\n<p><img loading=\"lazy\" width=\"2006\" height=\"810\" class=\"wp-image-1583\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-49.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-49.jpeg 2006w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-49-300x121.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-49-768x310.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-49-1024x413.jpeg 1024w\" sizes=\"(max-width: 2006px) 100vw, 2006px\" \/><\/p>\n<p><strong>Figur 6.27: <\/strong>Placering af log ind forms<\/p>\n<p>Log ind funktionen bruger dataene fra database-tabellen <em>medlemmer<\/em>, som indeholder de data brugeren indtastede i indmeldelsesformularen. Log ind scriptet starter med at inds\u00e6tte de informationer brugeren har indtastet i log ind formularen i variablerne <em>$brugernavn <\/em>og <em>$kode <\/em>(se linje 7-8 p\u00e5 figur 6.28). Dern\u00e6st kontrolleres det om de indtastede oplysninger i log ind formularen har et resultat i databasen. Dette g\u00f8res ved at <em>query <\/em>databasen og kontrollere, at <em>$brugernavn <\/em>svarer til en e-mail i databasen, og at <em>$kode <\/em>svarer til koden i samme r\u00e6kke, som <em>$brugernavnet <\/em>st\u00e5r i. Derudover skal deres <em>betalt <\/em>status ogs\u00e5 v\u00e6re = 1, ellers vil log ind fejle (se figur 6.28).<\/p>\n<p><img loading=\"lazy\" width=\"1368\" height=\"1022\" class=\"wp-image-1584\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-50.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-50.jpeg 1368w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-50-300x224.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-50-768x574.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-50-1024x765.jpeg 1024w\" sizes=\"(max-width: 1368px) 100vw, 1368px\" \/><\/p>\n<p><strong>Figur 6.28: <\/strong>Kodestykke til at validere log ind (<em>login-validation.php<\/em>)<\/p>\n<p>Hvis der ikke er et resultat i databasen, som svarer til det brugeren har indtastet, vil de blive sendt til en side, hvor de bliver informeret om, at der er sket en fejl, og at de skal pr\u00f8ve at logge ind igen. Er der derimod et resultat i databasen, vil brugeren blive logget ind, og en <em>session <\/em>vil blive startet (se figur 6.29).<\/p>\n<p><img loading=\"lazy\" width=\"1280\" height=\"1086\" class=\"wp-image-1585\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-51.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-51.jpeg 1280w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-51-300x255.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-51-768x652.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-51-1024x869.jpeg 1024w\" sizes=\"(max-width: 1280px) 100vw, 1280px\" \/><\/p>\n<p><strong>Figur 6.29: <\/strong>Kode som opretter <em>session <\/em>start (<em>login-validation.php<\/em>)<\/p>\n<p>Der er to essentielle ting <em>session <\/em>g\u00f8r p\u00e5 sitet.<\/p>\n<ol>\n<li>Den gemmer en <em>session<\/em><sup><sup><a id=\"post-1531-footnote-ref-20\" href=\"#post-1531-footnote-20\">[20]<\/a><\/sup> <\/sup>variabel, n\u00e5r der logges ind. Denne variabel g\u00f8r at brugeren p\u00e5 hver side ikke beh\u00f8ver at logge ind p\u00e5 ny. Derudover fordi <em>session <\/em>variablen er sat til at v\u00e6re <em>email\u2019<\/em>, giver denne ogs\u00e5 informationer til f.eks. bookingkalenderen om, hvem der foretager en reservation af banen, samt er med til at vise, hvilke tider brugeren har af fremtidige reservationer.<\/li>\n<li>Den s\u00e6tter en <em>session timer<\/em>, som logger brugeren ud 30 minutter efter deres sidste interaktion med siden. Brugeren er dermed ikke logget ind p\u00e5 ubestemt tid.<\/li>\n<\/ol>\n<p>P\u00e5 figur 6.30 ses et eksempel p\u00e5 et kodestykke fra en side, hvor brugeren skal v\u00e6re logget ind for at loade siden.<\/p>\n<p><img loading=\"lazy\" width=\"494\" height=\"120\" class=\"wp-image-1586\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-52.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-52.jpeg 494w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-52-300x73.jpeg 300w\" sizes=\"(max-width: 494px) 100vw, 494px\" \/><\/p>\n<p><strong>Figur 6.30: <\/strong><em>Session <\/em>p\u00e5 de enkelte sider<\/p>\n<p>Vi har valgt at benytte en <em>session<\/em>, da den muligg\u00f8r log ind funktionen p\u00e5 alle sider, uden hver enkelt side skal have sin egen log ind formular. I stedet kan der i koden, efter systemet har gemt <em>session <\/em>variablen og brugeren er logget ind, &#8220;bare&#8221;st\u00e5 <em>session start <\/em>i toppen af de dokumenter, der ellers skulle have en separat formular. Dette var is\u00e6r nyttigt til administratorfunktionerne, hvor log ind er n\u00f8dvendigt p\u00e5 alle sider.<\/p>\n<p>Er der en log ind funktion, skal systemet ogs\u00e5 have en log ud funktion (se figur 6.31).<\/p>\n<p><img loading=\"lazy\" width=\"1346\" height=\"354\" class=\"wp-image-1587\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-53.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-53.jpeg 1346w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-53-300x79.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-53-768x202.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-53-1024x269.jpeg 1024w\" sizes=\"(max-width: 1346px) 100vw, 1346px\" \/><\/p>\n<p><strong>Figur 6.31: <\/strong>Log ud funktion (<em>logout.php<\/em>)<\/p>\n<p>N\u00e5r brugeren klikker p\u00e5 log ud knappen bliver variablen <em>$sti <\/em>(nuv\u00e6rende url) videref\u00f8rt til variablen <em>$url<\/em>. Herefter vil scriptet k\u00f8re og den igangv\u00e6rende session vil blive afsluttet. Brugeren vil herefter blive sendt til enten den samme side, som de er p\u00e5, eller hvis siden kr\u00e6ver log ind, vil de blive pr\u00e6senteret for en log ind form.<\/p>\n<h2>6.6 \u00c6ndring af tekst og billeder<\/h2>\n<p>N\u00e5r et bestyrelsesmedlem er logget ind som administrator, vil denne f\u00e5 adgang til flere funktioner end en almen bruger. Dette indeb\u00e6rer blandt andet muligheden for redigering af tekster og billeder p\u00e5 websitet, samt medlemsh\u00e5ndtering. Vi vil i dette afsnit beskrive de mest v\u00e6sentligste administratorfunktioner.<\/p>\n<h3>6.6.1 Redigering af tekst<\/h3>\n<p>Administratorfunktionen til at redigere tekst ser ud som venstre del af figur 6.32.<\/p>\n<p><img loading=\"lazy\" width=\"1535\" height=\"462\" class=\"wp-image-1588\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-54.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-54.jpeg 1535w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-54-300x90.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-54-768x231.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-54-1024x308.jpeg 1024w\" sizes=\"(max-width: 1535px) 100vw, 1535px\" \/><\/p>\n<p><strong>Figur 6.32: <\/strong><em>Rediger tekst <\/em>knap, samt modalen som knappen \u00e5bner<\/p>\n<p>N\u00e5r administrator trykker p\u00e5 <em>rediger tekst <\/em>knappen \u00e5bner der en modal, som vist i h\u00f8jre side af figur 6.32. I denne modal har administratoren mulighed for at \u00e6ndre overskriften og teksten.<\/p>\n<p>Koden til denne modal, der kan redigere teksten, ser ud som vist p\u00e5 figur 6.33.<\/p>\n<p><img loading=\"lazy\" width=\"1249\" height=\"720\" class=\"wp-image-1589\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-55.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-55.jpeg 1249w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-55-300x173.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-55-768x443.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-55-1024x590.jpeg 1024w\" sizes=\"(max-width: 1249px) 100vw, 1249px\" \/><\/p>\n<p>P\u00e5 figur 6.33 ses det at koden starter med at \u00e5bne modalen (koden til oprettelse af modeln kan ses i figur 6.21). Det v\u00e6sentlige i denne kode er, at der \u00e5bnes to felter, som administratoren kan skrive i: <em>input <\/em>med overskriften og <em>textarea <\/em>til teksten (linje 132 og 135). Her har vi inden hentet overskriften samt teksten ned fra databasen og gemt det i arrayet <em>$row<\/em>. Denne data fra <em>$row <\/em>inds\u00e6ttes i egenskaben <em>value <\/em>for <em>input <\/em>og <em>textarea<\/em>. Denne egenskabs funktion er at vise tekst i feltet inden administratoren skriver noget. Havde vi ikke haft dette, ville felterne p\u00e5 h\u00f8jre side af figur 6.32 v\u00e6re tomme. Hvis administratoren trykker <em>Gem \u00e6ndringer <\/em>bliver disse <em>values <\/em>sendt til databasen og erstatter de v\u00e6rdier, som var der i forvejen. Dette s\u00f8rger for, at det nu er de nye v\u00e6rdier, der bliver hentet fra databasen, n\u00e5r siden tilg\u00e5s, som lige er blevet redigeret.<\/p>\n<h3>6.6.2 Redigering af billeder<\/h3>\n<p>M\u00e5den, som administratoren redigerer billeder p\u00e5, er ved at logge ind som administrator og f\u00f8re musemark\u00f8ren over det billede, som administratoren gerne vil \u00e6ndre. Herefter kommer der en mulighed for at v\u00e6lge fil samt uploade den valgte fil. Dette vil erstatte det billede, der var der f\u00f8r, som er vist i figur 6.34, hvor venstre side viser det nuv\u00e6rende billede, og h\u00f8jre side viser valgmulighederne, n\u00e5r musemark\u00f8ren holdes over billedet.<\/p>\n<p><img loading=\"lazy\" width=\"947\" height=\"302\" class=\"wp-image-1590\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-56.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-56.jpeg 947w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-56-300x96.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-56-768x245.jpeg 768w\" sizes=\"(max-width: 947px) 100vw, 947px\" \/><\/p>\n<p><strong>Figur 6.34: <\/strong>Redigering af billede p\u00e5 mbtennis.dk<\/p>\n<p>Koden til at \u00e6ndre billeder ses p\u00e5 figur 6.35.<\/p>\n<p><img loading=\"lazy\" width=\"759\" height=\"201\" class=\"wp-image-1591\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-57.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-57.jpeg 759w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-57-300x79.jpeg 300w\" sizes=\"(max-width: 759px) 100vw, 759px\" \/><\/p>\n<p><em>Classen preview1 <\/em>(se figur 6.36) indeholder billedet og bliver f\u00f8rst hentet med et SQL query, for derefter at blive indsat i <em>classen<\/em>. Det er derfor denne <em>class<\/em>, der bliver \u00e6ndret, n\u00e5r der uploades et nyt billede. N\u00e5r der trykkes <em>upload billede <\/em>k\u00f8res scriptet, som ses under <em>form action= <\/em>p\u00e5 linje 86 p\u00e5 figur 6.35. Dette script kontrollerer om den valgte fil overholder en r\u00e6kke krav, som eksempelvis st\u00f8rrelse og filtype. Hvis den valgte fil overholder kravene, bliver den uploadet og erstatter det gamle billede.<\/p>\n<p><img loading=\"lazy\" width=\"623\" height=\"187\" class=\"wp-image-1592\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-58.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-58.jpeg 623w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-58-300x90.jpeg 300w\" sizes=\"(max-width: 623px) 100vw, 623px\" \/><\/p>\n<h2>6.7 Medlemsh\u00e5ndtering<\/h2>\n<p>P\u00e5 websitet er der p\u00e5 alle sider (med undtagelse af siderne <em>Galleri <\/em>og <em>Kontakt<\/em>) tilknyttet administratorsider, hvor det er muligt for foreningens bestyrelse at opdatere og vedligeholde hjemmesiden. Undersiden <em>Medlemsoversigt <\/em>(se figur 6.37) fra drop-down menuen <em>Medlemsh\u00e5ndtering <\/em>vil her blive beskrevet.<\/p>\n<p><img loading=\"lazy\" width=\"2010\" height=\"846\" class=\"wp-image-1593\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-59.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-59.jpeg 2010w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-59-300x126.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-59-768x323.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-59-1024x431.jpeg 1024w\" sizes=\"(max-width: 2010px) 100vw, 2010px\" \/><\/p>\n<p><strong>Figur 6.37: <\/strong>Medlemsoversigt, som kun kan tilg\u00e5s af administrator<\/p>\n<p><img loading=\"lazy\" width=\"1216\" height=\"570\" class=\"wp-image-1594\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-60.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-60.jpeg 1216w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-60-300x141.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-60-768x360.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-60-1024x480.jpeg 1024w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-60-500x233.jpeg 500w\" sizes=\"(max-width: 1216px) 100vw, 1216px\" \/><\/p>\n<p><strong>Figur 6.38: <\/strong>Kodestykke til at hente data fra databasen til medlemsoversigten (<em>admin-medlemmer.php<\/em>)<\/p>\n<p>P\u00e5 tredje linje i figur 6.38, hentes filen <em>connection.php<\/em>, hvori der oprettes forbindelse til databasen.<\/p>\n<p>Herefter anmodes der med PHP om at hente alle dataene i tabellen <em>medlemmer<\/em>, dog med undtagelse af r\u00e6kken, hvori <em>ID = 22 <\/em>(nr. 22 er administratorkontoen) og dataen sorteres efter fornavn (se linje 7). Lykkedes anmodningen gemmes de hentede data i variablen <em>$results<\/em>, ellers skrives der en fejlmeddelelse p\u00e5 hjemmesiden.<\/p>\n<p>Herefter kontrolleres det om siden bliver tilg\u00e5et uden at v\u00e6re logget ind p\u00e5 en administratorkonto, og hvis dette er tilf\u00e6ldet, bliver brugeren omdirigeret til forsiden af mbtennis.dk, hvilket fremg\u00e5r af PHP koden p\u00e5 linje 14 og 15 p\u00e5 figur 6.38.<\/p>\n<p><img loading=\"lazy\" width=\"1358\" height=\"1384\" class=\"wp-image-1595\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-61.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-61.jpeg 1358w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-61-294x300.jpeg 294w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-61-768x783.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-61-1005x1024.jpeg 1005w\" sizes=\"(max-width: 1358px) 100vw, 1358px\" \/><\/p>\n<p><strong>Figur 6.39: <\/strong>Kodestykke medlemsoversigt tabellen (<em>admin-medlemmer.php<\/em>)<\/p>\n<p>Der oprettes p\u00e5 siden en tabel med ni kolonner. Disse kolonner udfyldes efterf\u00f8lgende r\u00e6kke for r\u00e6kke af et <em>while loop <\/em>(se linje 49 &#8211; 76 p\u00e5 figur 6.39), som inds\u00e6tter de data, der blev hentet i figur 6.38. Her hentes der et <em>associative array <\/em>i form af r\u00e6kker ved at kalde variablen <em>$results<\/em>, som gemmes i en ny variabel, <em>$row<\/em>. Variablen <em>$row <\/em>benyttes herefter til at inds\u00e6tte dataene om de enkelte medlemmer, som tidligere n\u00e6vnt er lagret i tabellen <em>medlemmer <\/em>i den tilknyttede database, i den oprettede tabel p\u00e5 siden. For at inds\u00e6tte dataene skrives der eksempelvis: <em>echo \u00abtd&gt;&#8221;.$row[\u2019fornavn\u2019].\u00abbr&gt;&#8221;.$row[\u2019efternavn\u2019].\u00ab\/td&gt;&#8221;; <\/em>(linje 51 p\u00e5 figur<\/p>\n<p>6.39). Det f\u00f8rste i koden, <em>echo<\/em>, bruges for at fort\u00e6lle, at der i stykket for PHP koden gerne vil benyttes HTML. <em>&lt;td&gt; <\/em>og <em>&lt;\/td&gt; <\/em>taggene fort\u00e6ller, hvad der skal st\u00e5 i den celle i tabellen, og tagget <em>&lt;br&gt; <\/em>starter en ny linje. For at inds\u00e6tte informationen fra databasen kaldes den variabel vi oprettede arrayet i, samt navnet p\u00e5 den kolonne vi gerne vil hente data fra, hvilket ser ud som f\u00f8lger: <em>.$row[\u2019fornavn\u2019].<\/em>. Samme fremgangsm\u00e5de bliver gentaget for hele tabellen indtil alt det \u00f8nskede data er indsat i tabellen.<\/p>\n<p>Den egentlige administratorfunktionalitet p\u00e5 siden kommer i form af de knapper, der er i forl\u00e6ngelse af informationen om det enkelte medlem. Her er der lavet to knapper, som henholdsvis kan slette et medlem eller bruges til at registrere om det p\u00e5g\u00e6ldende medlem har f\u00e5et udleveret en n\u00f8gle til banen. Den f\u00f8rste knap (se linje 60-63 p\u00e5 figur 6.39) er til udlevering af n\u00f8gle. N\u00e5r der klikkes p\u00e5 knappen aktiveres filen <em>noegle.php <\/em>og <em>id<\/em>\u2019et p\u00e5 det p\u00e5g\u00e6ldende medlem <em>postes<\/em>, s\u00e5 det kan benyttes af den nu \u00e5bne fil (se figur 6.40).<\/p>\n<p><img loading=\"lazy\" width=\"1150\" height=\"568\" class=\"wp-image-1596\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-62.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-62.jpeg 1150w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-62-300x148.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-62-768x379.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-62-1024x506.jpeg 1024w\" sizes=\"(max-width: 1150px) 100vw, 1150px\" \/><\/p>\n<p><strong>Figur 6.40: <\/strong>Kodestykke til registrering af n\u00f8gleudlevering (<em>noegle.php<\/em>)<\/p>\n<p>I et <em>if statement <\/em>benytter filen <em>noegle.php <\/em>det medlems-id, der tidligere blev <em>postet <\/em>af knappen, og id\u2019et gemmes som variablen <em>$ID<\/em>. Derefter oprettes der endnu en variabel, <em>$query <\/em>(se linje 6 p\u00e5 figur 6.40), der bestemmer at tabellen <em>medlemmer <\/em>skal opdateres, og at der skal st\u00e5 <em>1 <\/em>i kolonnen <em>noegle <\/em>i den r\u00e6kke, hvor ID\u2019et er tilsvarende til det, som er gemt i variablen <em>$ID<\/em>. I linje 8 p\u00e5 figur 6.40 interageres der med databasen ved f\u00f8rst at kalde variablen <em>$connection<\/em><\/p>\n<p>(denne variabel hentes fra filen \u201cconnection.php\u201d), som opretter forbindelse til databasen, og derefter kaldes variablen <em>$query<\/em>, der fort\u00e6ller, hvad der skal g\u00f8res i databasen. Lykkedes det at opdatere tabellen i databasen, bliver administratoren vist siden de er p\u00e5, <em>Medlemsoversigt<\/em>,<\/p>\n<p><em>6.8. FRA IMPLEMENTERING TIL USABILITY<\/em><\/p>\n<p>men lykkedes det ikke, skrives der en fejlmeddelelse.<\/p>\n<p>Knappen <em>Slet medlem <\/em>fungerer n\u00e6sten p\u00e5 samme m\u00e5de, som knappen til udlevering af n\u00f8gle. Der er dog den forskel, at i stedet for at opdatere informationen p\u00e5 et medlem bliver medlemmet slette fra databasen, og det p\u00e5g\u00e6ldende medlem kan derfor ikke l\u00e6ngere benytte sig af mbtennis.dk.<\/p>\n<h2>6.8 Fra implementering til usability<\/h2>\n<p>Vi har i dette afsnit forklaret de kodesprog og principper, der ligger til grund for de mest centrale funktioner i systemet, samt hvordan disse fungerer. Efter implementeringsfasen af systemet vil vi nu teste vores system ved hj\u00e6lp af usability tests, b\u00e5de for administratorsiden og for medlemssiden af sitet.<\/p>\n<p><strong>Kapitel7<\/strong><\/p>\n<h1>Evaluering<\/h1>\n<p>I det f\u00f8lgende afsnit vil vi give en detaljeret beskrivelse vores usability test, samt hvad der danner rammerne om denne. F\u00f8rst vil vi beskrive, hvad vi \u00f8nsker at f\u00e5 ud af testen samt metoderne bag den. Dern\u00e6st vil vi beskrive hvordan testen rent praktisk forl\u00f8ber, samt de forskellige roller undervejs i testen. Herefter vil vi komme ind p\u00e5, hvad succeskriterierne for systemet er, samt en beskrivelse af vores testopgaver. Afslutningsvis vil vi gennemg\u00e5 de data, vi har indsamlet fra usability testene, samt hvordan vi har behandlet og hvad vi har udledt ud fra dataene.<\/p>\n<h2>7.1 Testplanl\u00e6gning<\/h2>\n<h3>7.1.1 Form\u00e5let med testen<\/h3>\n<p>Form\u00e5let med vores usability test er, at teste brugbarheden af sitets funktionaliteter for hhv. medlemmer af foreningen samt for administratorerne p\u00e5 foreningens website. Dette g\u00f8res med en r\u00e6kke forskellige scenarier. Der er otte scenarier, som administratorerne bliver pr\u00e6senteret for og seks scenarier, som medlemmerne bliver pr\u00e6senteret for. Ved hj\u00e6lp af databehandlingen af vores usability tests vil vi danne os et indtryk af, hvorvidt hjemmesiden stemmer overens med de kravspecifikationer, som vi i f\u00e6llesskab med bestyrelsesformanden har udarbejdet i l\u00f8bet af projektet.<\/p>\n<h3>7.1.2 Metodeafsnit<\/h3>\n<p>I vores usability tests vil vi hovedsageligt teste de tre usability attributter learnability, errors og satisfaction.<\/p>\n<p>Den vigtigste attribut for os at teste er learnability, da den kan give en indikation om, hvorvidt det er let eller sv\u00e6rt for en bruger at blive kompatibel med systemet. Dette kan bl.a. ses p\u00e5 tiden, det tager en testperson at gennemf\u00f8re en stillet opgave [Nielsen 1993, side 27-37].<\/p>\n<p>Vi tester ogs\u00e5 efter attributten satisfaction, da det er vigtigt, at brugeren f\u00f8ler sig godt tilpas, n\u00e5r de benytter systemet. Dette kan have betydning for brugerens fremtidige brug af sitet, da en behagelig oplevelse med sitet kan give dem interesse i at vende tilbage til hjemmesiden. Dette unders\u00f8ges specifikt i debriefingen [Nielsen 1993, side 27-37].<\/p>\n<p>Den sidste attribut, som vi tester efter, er errors. Det er vigtigt, at sitet ikke er fyldt med fejl, som er med til at s\u00e6nke systemts learnability og satisfaction. Da vi foretager vores usability test kort efter vores endelige programmering af sitet, tester denne attribut ligeledes, om vi har overset nogle fejl, som kan identificeres i gennemgangen af scenarierne [Nielsen 1993, side 27-37].<\/p>\n<p>Vi benytter os, gennem alle usability testene, af think-aloud metoden, som g\u00f8r det muligt at f\u00e5 et indblik i, hvad testpersonen t\u00e6nker, imens denne udf\u00f8rer scenarierne. P\u00e5 den m\u00e5de kan b\u00e5de testlederen og notetageren (se afsnit 7.1.3) f\u00e5 et indblik i, ikke blot hvad testpersonen g\u00f8r, men ogs\u00e5 hvorfor de g\u00f8r det. Think-aloud metoden kan ogs\u00e5 v\u00e6re med til at udpege specifikke interface komplikationer, s\u00e5ledes at disse kan blive rettet op p\u00e5[Nielsen 1993, side 18-19].<\/p>\n<h3>7.1.3 Testens forl\u00f8b<\/h3>\n<p>Vores usability test best\u00e5r af en testperson, en testleder og en notetager. Testpersonen udf\u00f8rer de udleverede scenarier p\u00e5 en b\u00e6rbar computer, som er stillet til r\u00e5dighed. Undervejs bliver testpersonerne filmet via et webcam, og deres interageren med systemet bliver optaget. Notetageren er placeret i baggrunden, og dennes rolle er at observere testpersonen l\u00f8bende i udf\u00f8relse af scenarierne, notere deres fysiske adf\u00e6rd samt f\u00e6rden p\u00e5 sitet.<\/p>\n<p>Testlederens rolle best\u00e5r i at observere testpersonen p\u00e5 t\u00e6t hold, samt v\u00e6re til hj\u00e6lp, s\u00e5fremt en testperson skulle v\u00e6re ude af stand til at komme igennem et scenarie efter gentagne fors\u00f8g. Testlederen starter indledningsvis med at udlevere introduktionen til testen (usability testene kan ses i bilag B og C), samt fort\u00e6lle kort om, hvad der kommer til at foreg\u00e5 undervejs. Testlederen udleverer l\u00f8bende scenarierne, som er udprintet og klippet til p\u00e5 sm\u00e5 stykker papir. Afslutningsvis g\u00e5r testlederen igennem en debriefing, som har til form\u00e5l at give en opsummering af testpersonens samlede indtryk af websitet. Debriefingen best\u00e5r af sp\u00f8rgsm\u00e5l, som relaterer sig til systemet (se bilag B og C).<\/p>\n<p>Et scenarie kan anses som fuldf\u00f8rt, n\u00e5r testlederen registrerer at testpersonen har gennem-<\/p>\n<p>f\u00f8rt scenariet, og testlederen vil derefter udlevere n\u00e6ste scenarie. Skulle der opst\u00e5 tvivl fra testpersonens side om, hvorvidt et scenarie er fuldf\u00f8rt eller ej, vil testlederen tr\u00e6de til og oplyse om status p\u00e5 gennemf\u00f8relsen af det p\u00e5g\u00e6ldende scenarie.<\/p>\n<p>For at kvalitetssikre usability testen har vi udf\u00f8rt en pilottest. Det har vi gjort for at identificere fejl i formuleringen af vores scenarier, samt for at sikre os at de scenarier, vi har opstillet, tester kravene fra kravspecifikationen.<\/p>\n<h3>7.1.4 Succeskriterier for systemet<\/h3>\n<h4>Teori<\/h4>\n<p>Ved planl\u00e6gningen af en usability test er det vigtigt at have afklaret, hvordan testens resultater skal behandles samt hvad succeskriteriet er for de enkelte opgaver [Nielsen 1993, side 170171].<\/p>\n<h4>Kriterier for succes<\/h4>\n<p>Ved udarbejdelsen af kravspecifikationen blev succeskriteriet pr\u00e6ciseret for hvert krav. Derfor er det relevant for os at gennemg\u00e5 de opstillede kriterier for at se, om de enkelte krav er opfyldt, samt muligt at udf\u00f8re for testpersonerne. Vi har her pr\u00e6ciseret kravene med prioritet 1 <em>Must have <\/em>og proritet 2 <em>Should have<\/em>, som v\u00e6rende de krav, som skal v\u00e6re opfyldt. Krav med en prioritet p\u00e5 3 eller 4 er ikke obligatoriske krav.<\/p>\n<p>Systemet er opbygget til at underst\u00f8tte brugen som b\u00e5de medlemmer og administrator. Vi har derfor valgt at ops\u00e6tte to forskellige usability tests, som har forskellige kriterier for succes.<\/p>\n<h5>Succes for medlemstesten<\/h5>\n<p>Et eksempel p\u00e5 et succeskriterie for et medlem er krav 1a, hvor det skal v\u00e6re muligt for testpersonen at logge ind og booke en ledig tid i bookingkalenderen. Hvis testpersonen ikke er logget ind, skal kalenderen dog ikke v\u00e6re synlig. Dette succeskriterium afh\u00e6nger dog af kravet 3a og 3b, hvor testpersonen skal have oprettet en bruger p\u00e5 websitet for at benytte bookingkalenderen. Derfor har vi netop opstillet de to scenarier for at kunne unders\u00f8ge de forskellige funktioner i relation til hinanden.<\/p>\n<p><img loading=\"lazy\" width=\"1243\" height=\"354\" class=\"wp-image-1597\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-63.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-63.jpeg 1243w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-63-300x85.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-63-768x219.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-63-1024x292.jpeg 1024w\" sizes=\"(max-width: 1243px) 100vw, 1243px\" \/><\/p>\n<p><strong>Figur 7.1: <\/strong>Kravspecifikation og succeskriterier for medlemssiden i systemet<\/p>\n<p>Det er samtidig vigtigt at de tre usability attributter, learnability, satisfaction og errors, bliver opfyldt. Systemet skal v\u00e6re let at anvende, da medlemmerne ikke er eksperter i systemet og ikke n\u00f8dvendigvis har pr\u00f8vet det f\u00f8r. Samtidig skal systemet v\u00e6re tilfredsstillende for brugeren, s\u00e5 de kunne have lyst til at anvende det igen.<\/p>\n<p>Ydermere ses det ogs\u00e5 som en succes, hvis der ingen seri\u00f8se, kritiske eller katastrofale fejl opst\u00e5r undervejs i testen. Skulle der opst\u00e5r disse fejltyper p\u00e5 medlemssiden vil vi str\u00e6be efter at f\u00e5 disse rettet hurtigst muligt.<\/p>\n<h5>Succes for administratortesten<\/h5>\n<p>I kravspecifikationen er der ogs\u00e5 for administratorfunktionerne udarbejdet succeskriterier for de enkelte krav. Disse kan ses p\u00e5 figur 7.2, og skal v\u00e6re mulige at fuldf\u00f8re i usability testen.<\/p>\n<p><img loading=\"lazy\" width=\"1293\" height=\"232\" class=\"wp-image-1598\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-64.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-64.jpeg 1293w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-64-300x54.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-64-768x138.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-64-1024x184.jpeg 1024w\" sizes=\"(max-width: 1293px) 100vw, 1293px\" \/><\/p>\n<p><strong>Figur 7.2: <\/strong>Succeskriterium for administrator<\/p>\n<p>Denne del af websitet testes ogs\u00e5 for learnability, satisfaction og errors. Her m\u00e5 det gerne tage testpersonen l\u00e6ngere tid at blive komfortabel med systemet, da denne del af systemet er mere avanceret end medlemssiden. Systemet m\u00e5 gerne v\u00e6re tilfredsstillende (h\u00f8j satisfaction), men da den skal bruges til at administrere de data, der findes p\u00e5 websitet, vil dette kriterium ikke v\u00e6re vores st\u00f8rste fokus. Ydermere er det vigtigt, at der ikke opst\u00e5r nogle seri\u00f8se, kritiske eller katastrofale fejl undervejs, da dette vil forstyrre det arbejde, der er tilt\u00e6nkt siden.<\/p>\n<h3>7.1.5 Testpersoner<\/h3>\n<h4>Teori<\/h4>\n<p>Ved benyttelsen af thinking aloud er der behov for minimum tre deltagere i testen, da de f\u00e5 deltagere samlet giver en stor m\u00e6ngde af kvalitativ data[Nielsen 1993, side 195, 224]. Testpersonerne skal v\u00e6re repr\u00e6sentative for den m\u00e5lgruppe, som systemet er tilt\u00e6nkt, da dette vil give et mere pr\u00e6cist billede af systemets brug [Nielsen 1993, side 209-214].<\/p>\n<h4>Vores testgruppe<\/h4>\n<p>Gennem vores interview med bestyrelsesformanden (se afsnit 3.2.5) erfarede vi at vores m\u00e5lgruppe var opdelt i aldersgrupperne med ca. 50% mellem 18 &#8211; 25 \u00e5r og ca. 50% p\u00e5 50+.<\/p>\n<p>Ud fra dette har vi valgt at teste systemet med en opdeling p\u00e5 fire personer i aldersgruppen 18 &#8211; 25 og to personer i aldersgruppen 50+ (se tabel 7.1). Vi har valgt fire personer fra den yngre aldersgruppe, da foreningen gerne vil have flere unge med i klubben, og vi fandt det derfor relevant at finde ud af, om systemet kunne v\u00e6re appellerende for dem.<\/p>\n<p>Ikke alle testpersoner har tidligere erfaring med tennis, hvilket vi har bed\u00f8mt ikke vil p\u00e5virke vores test, da det at spille tennis ikke har relevans for at brugen af et bookingsystem. Samtidig \u00f8nsker foreningen flere medlemmer, som n\u00e6vnt i afsnit 2.3, hvilket g\u00f8r det relevant at teste personer, som ikke tidligere har spillet tennis.<\/p>\n<p><strong>Testperson K\u00f8n Alder<\/strong><\/p>\n<table>\n<tbody>\n<tr>\n<td>\n<p>1<\/p>\n<\/td>\n<td>\n<p>Mand<\/p>\n<\/td>\n<td>\n<p>22<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p>2<\/p>\n<\/td>\n<td>\n<p>Mand<\/p>\n<\/td>\n<td>\n<p>24<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p>3<\/p>\n<\/td>\n<td>\n<p>Kvinde<\/p>\n<\/td>\n<td>\n<p>21<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p>4<\/p>\n<\/td>\n<td>\n<p>Kvinde<\/p>\n<\/td>\n<td>\n<p>25<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p>5<\/p>\n<\/td>\n<td>\n<p>Mand<\/p>\n<\/td>\n<td>\n<p>46<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p>6<\/p>\n<\/td>\n<td>\n<p>Mand<\/p>\n<\/td>\n<td>\n<p>64<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Tabel 7.1: <\/strong>Testpersoner til medlemstesten<\/p>\n<p>Vi har valgt kun at teste to personer i usability testen af administratordelen af websitet (se tabel 7.2). Dette har vi valgt at g\u00f8re, fordi de to personer er dem, der kommer til at benytte administratordelen efter systemets f\u00e6rdigg\u00f8relse. Vi vurderede at det ikke ville v\u00e6re relevant at finde en generel m\u00e5lgruppe af testpersoner til denne del af hjemmesiden, da den ikke vil blive benyttet af mere end et par personer af gangen.<\/p>\n<p><strong>Testperson K\u00f8n Alder<\/strong><\/p>\n<table>\n<tbody>\n<tr>\n<td>\n<p>1<\/p>\n<\/td>\n<td>\n<p>Mand<\/p>\n<\/td>\n<td>\n<p>46<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p>2<\/p>\n<\/td>\n<td>\n<p>Mand<\/p>\n<\/td>\n<td>\n<p>64<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Tabel 7.2: <\/strong>Testpersoner til administratortesten<\/p>\n<h3>7.1.6 Testopgaver<\/h3>\n<h4>Teori<\/h4>\n<p>Ved udarbejdelse af testopgaverne er det vigtigt, at s\u00f8rge for at testpersonen f\u00e5r en tidlig succesoplevelse. Samtidig skal opgaverne teste de funktioner, som systemet er beregnet til at skulle underst\u00f8tte. Opgaverne skal v\u00e6re sm\u00e5 nok til at kunne blive udf\u00f8rt indenfor den afsatte tidsperiode for testen, men samtidig ikke s\u00e5 sm\u00e5, at de bliver trivielle [Nielsen 1993, side 181-186].<\/p>\n<p>Ved at udlevere opgaverne en ad gangen i l\u00f8bet af testen mindskes sandsynligheden for misforst\u00e5else af opgaverne. Det g\u00f8r det muligt for testpersonen at forst\u00e5 opgaverne i deres eget tempo og vende tilbage til dem, hvis det skulle v\u00e6re n\u00f8dvendigt [Nielsen 1993, side 181-186].<\/p>\n<h4>Vores opgaver<\/h4>\n<p>Testopgaverne er udarbejdet p\u00e5 baggrund af de opstillede kravspecifikationer for at sikre, de er opfyldt. Den fulde kravspecifikation kan ses i bilag A.<\/p>\n<p>Herunder vil vi gennemg\u00e5 et udsnit af opgaverne for de to forskellige tests samt deres tilh\u00f8rende krav. De to usability tests kan ses i henholdsvis bilag B og C.<\/p>\n<p>Usability test medlemmer<\/p>\n<p>Usability testen af medlemmerne har fokus p\u00e5 de funktioner, som de skal kunne benytte p\u00e5 websitet, f.eks. bookingfunktionen og indmeldelse i foreningen.<\/p>\n<p><em>Scenarie 1<\/em><\/p>\n<p>Du er interesseret i at melde dig ind i Midtbyens Tennisklub, men f\u00f8r du melder dig ind vil du gerne unders\u00f8ge klubbens vedt\u00e6gter.<\/p>\n<p>(a) Find vedt\u00e6gt 4, og l\u00e6s den h\u00f8jt.<\/p>\n<p>Dette scenarie er opstillet p\u00e5 baggrund af kravet 5c (se figur 7.3), hvor foreningen gerne vil have overf\u00f8rt informationer fra deres nuv\u00e6rende website til det nye system. Samtidig er det opstillet for at teste navigationen p\u00e5 siden. Scenariet er valgt som det f\u00f8rste, for netop at s\u00f8rge for testpersonen har en simpel opgave til start.<\/p>\n<p><img loading=\"lazy\" width=\"587\" height=\"76\" class=\"wp-image-1599\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-65.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-65.jpeg 587w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-65-300x39.jpeg 300w\" sizes=\"(max-width: 587px) 100vw, 587px\" \/><\/p>\n<p><strong>Figur 7.3: <\/strong>Kravet 5c for almindelig bruger<\/p>\n<p><em>Scenarie 2<\/em><\/p>\n<p>Du har nu l\u00e6st vedt\u00e6gterne, og \u00f8nsker nu at melde dig ind i klubben.<\/p>\n<p>(a) Find indmeldelse siden og udfyld indmeldelses felterne med nedenst\u00e5ende oplysninger:<\/p>\n<p><em>Navn: Jens Jensen<\/em><\/p>\n<p><em>Adresse: Min Vej 3, 9000 Aalborg<\/em><\/p>\n<p><em>Telefon: 99999999<\/em><\/p>\n<p><em>Email: jens@gmail.com<\/em><\/p>\n<p><em>Kode: 1234<\/em><\/p>\n<p><em>Betaling: MobilePay<\/em><\/p>\n<p>Dette scenarie er opstillet for at teste kravet 3b (se figur 7.4), som beskriver indholdet af indmeldelsesproceduren. Dette tester vi ud fra ovenst\u00e5ende informationer, s\u00e5som navn, adresse m.m., som er indsat i scenariet, da der ikke skulle opst\u00e5 tvivl om de informationer, der skulle udfyldes.<\/p>\n<p><img loading=\"lazy\" width=\"421\" height=\"101\" class=\"wp-image-1600\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-66.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-66.jpeg 421w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-66-300x72.jpeg 300w\" sizes=\"(max-width: 421px) 100vw, 421px\" \/><\/p>\n<p><strong>Figur 7.4: <\/strong>Kravet 3b for almindelig bruger<\/p>\n<p><em>Scenarie 4<\/em><\/p>\n<p>Du \u00f8nsker nu at booke en tid p\u00e5 tennisbanen.<\/p>\n<ol>\n<li>Find bookingsiden og log ind med f\u00f8lgende informationer;<\/li>\n<\/ol>\n<p><em>Email: jens@gmail.com<\/em><\/p>\n<p><em>Kode: 1234<\/em><\/p>\n<ol>\n<li>Book en tid d. 16\/5 kl. 10:00 &#8211; 11:00 i kalenderen sammen med Jakob R\u00f8nnest.<\/li>\n<li>Du \u00f8nsker at booke endnu en tid d. 17\/5 kl. 17:00 &#8211; 18:00, men den er booket i forvejen.<\/li>\n<\/ol>\n<p>Find ud af, hvem der har booket tiden, og sig det h\u00f8jt.<\/p>\n<ol>\n<li>Du fortryder nu, at du har booket tiden d. 16\/5 kl. 10:00 &#8211; 11:00. Afmeld din tid.<\/li>\n<\/ol>\n<p>Dette scenarie gennemg\u00e5r alle kravene i kategorien booking, som alle har en prioritet 1 (se figur 7.5). Det er derfor krav, som systemet skal underbygge og var dermed en del af vores hovedfokus i udviklingen af systemet. Vi har valgt at placere scenariet i midten af testen, da det kan v\u00e6re en af de mere kr\u00e6vende opgaver.<\/p>\n<p>Vi har her igen valgt at oplyse informationen om log ind til testpersonen, for at der ikke skulle opst\u00e5 tvivl om de informationer, der skulle benyttes til opgaven.<\/p>\n<p><img loading=\"lazy\" width=\"422\" height=\"623\" class=\"wp-image-1601\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-67.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-67.jpeg 422w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-67-203x300.jpeg 203w\" sizes=\"(max-width: 422px) 100vw, 422px\" \/><\/p>\n<p><strong>Figur 7.5: <\/strong>Kravene for bookingkalenderen<\/p>\n<p>Usability test administrator<\/p>\n<p>Usability testen for administratorsiden har fokus p\u00e5 de funktioner, som administratoren skal kunne benytte. Dette er f.eks. h\u00e5ndtering af medlemmer og opdatering af websitet.<\/p>\n<p><em>Scenarie 1<\/em><\/p>\n<p>Du vil gerne unders\u00f8ge om der er kommet nye medlemmer i klubben.<\/p>\n<ol>\n<li>Log ind som administrator ved at benytte f\u00f8lgende oplysninger:<\/li>\n<\/ol>\n<p><em>Email: ******@mbtennis.dk<\/em><\/p>\n<p><em>Kode: *********<\/em><\/p>\n<ol>\n<li>Der er en medlemsanmodning, og du har kontrolleret at personen har betalt. Godkend det nye medlem Stefan Mundt.<\/li>\n<\/ol>\n<p>Dette scenarie er udarbejdet fra kravet 3c, se figur 7.6. Vi har indsat dette som det f\u00f8rste scenarie, da det ofte vil v\u00e6re en af grundene til administratoren tilg\u00e5r websitet. Samtidig er det en af kernefunktionerne for deres arbejde i starten af s\u00e6sonen, da medlemmerne skal kunne tilg\u00e5 websitet efter de er blevet godkendt af administratoren.<\/p>\n<p>Testpersonerne f\u00e5r i testen udleveret gyldige log ind oplysninger, som er oprettet i databasen, s\u00e5 de kan tilg\u00e5 sitets fulde administratorfunktioner.<\/p>\n<p><img loading=\"lazy\" width=\"561\" height=\"137\" class=\"wp-image-1602\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-68.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-68.jpeg 561w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-68-300x73.jpeg 300w\" sizes=\"(max-width: 561px) 100vw, 561px\" \/><\/p>\n<p><strong>Figur 7.6: <\/strong>Krav 3c for administrator<\/p>\n<p><em>Scenarie 2<\/em><\/p>\n<p>Du har udleveret en n\u00f8gle til det nye medlem Stefan Mundt, og du \u00f8nsker at registrere det p\u00e5 hjemmesiden.<\/p>\n<p>(a) Registrer at medlemmet Stefan Mundt har f\u00e5et udleveret en n\u00f8gle.<\/p>\n<p>Scenarie 2 er relevant at have med, da det er en del af foreningens procedure i forbindelse med nye medlemmer. Bestyrelsesformanden bekr\u00e6ftede, at n\u00f8gleudleveringen skulle registreres, og derfor blev denne funktion inkorporeret i systemet.<\/p>\n<p><em>Scenarie 7<\/em><\/p>\n<p>Et bestyrelsesmedlem har f\u00e5et et nyt telefonnummer, og du \u00f8nsker at opdatere telefonnummeret.<\/p>\n<p>(a) Opdater bestyrelsesmedlemmet Jakob R\u00f8nnest S\u00f8rensen\u2019s telefonnummer til 10101010.<\/p>\n<p>Flere af scenarierne tester administratorens mulighed for at redigere oplysningerne p\u00e5 websitet. Disse scenarier er opstillet ud fra kravet 4b (se figur 7.7), og er fordelt gennem testen for at observere, hvordan navigationen p\u00e5 siden fungerer.<\/p>\n<p><img loading=\"lazy\" width=\"562\" height=\"154\" class=\"wp-image-1603\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-69.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-69.jpeg 562w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-69-300x82.jpeg 300w\" sizes=\"(max-width: 562px) 100vw, 562px\" \/><\/p>\n<p><strong>Figur 7.7: <\/strong>Krav 4b for administrator<\/p>\n<h2>7.2 Databehandling<\/h2>\n<p>I det f\u00f8lgende afsnit gennemg\u00e5s og bearbejdes de data vi har indsamlet i forbindelse med vores usability test, samt hvad vi har f\u00e5et ud af disse. F\u00f8rst vil vi se p\u00e5 tidsm\u00e5lingerne for vores usability test af medlemmer, samt forklare hvordan vi har klassificeret de fundne problemer. Herefter vil vi gennemg\u00e5 resultaterne af testen for administratorer. Afslutningsvis vil vi samle op p\u00e5 de fundne problemer for de to tests og sammenholde dem med debriefingerne.<\/p>\n<p>For at kunne sige noget om graden af usability problemer har vi valgt at tage tid p\u00e5 de enkelte testpersoner samt observere deres reaktioner p\u00e5 de enkelte scenarier. De reaktioner, vi fokuserer p\u00e5, er frustration og irritation, som kommer til udtryk ved at testpersonerne ryster p\u00e5 hovedet, virker opgivende, klikker forvirret rundt, sukker m.m. Dette kan vi bruge til at klassificere usability problemerne ved hj\u00e6lp af severity skalaen, som bliver gennemg\u00e5et i f\u00f8lgende afsnit.<\/p>\n<h3>7.2.1 Teori<\/h3>\n<p>Til behandlingen af dataene fra usability testene har vi valgt at benytte os af en severity skala. En severity skala kan kategorisere fundne usability problemer [Nielsen 1993, side 102]. Via severity skalaen kan vi inddele de fundne usability problemer i fire kategorier:<\/p>\n<ul>\n<li><strong>Kosmetisk problem: <\/strong>Et kosmetisk problem forsinker testpersonen med mindre end et minut. Problemet beh\u00f8ves kun at blive l\u00f8st, s\u00e5fremt der er ekstra tid til r\u00e5dighed. Dette problem vil skabe en lav frustration hos testpersonen, da systemet kun reagerer en anelse anderledes end det forventes<\/li>\n<li><strong>Seri\u00f8st problem: <\/strong>Et seri\u00f8st problem er et problem, som vil forsinke testpersonen flere minutter. Dette problem er ikke en n\u00f8dvendighed at l\u00f8se, men det skal gerne l\u00f8ses efterf\u00f8lgende. Der vil her opleves en betydelig grad af frustration hos testpersonen, da systemet pludselig agerer en del anderledes end det forventes at g\u00f8re<\/li>\n<li><strong>Kritisk problem: <\/strong>Et kritisk problem vil forhindre testpersonen i at fuldf\u00f8re scenariet, og testpersonen er n\u00f8dsaget til at skulle have hj\u00e6lp fra testlederen for at kunne komme videre med opgaven. Dette vil skabe stor frustration hos testpersonen, idet systemet reagerer markant anderledes end det der forventes. Problemet er vigtigt at rette efterf\u00f8lgende<\/li>\n<li><strong>Katastrofalt problem: <\/strong>Et problem kan defineres som v\u00e6rende katastrofalt, hvis flere testpersoner oplever det samme kritiske problem i den samme opgave fordelt over flere individuelle tests [Nielsen 1993, side 103][Raptis 2018, slide 17].<\/li>\n<\/ul>\n<p>Udover severity skalaen benyttes der ogs\u00e5 en debriefing efter usability testene, som kan v\u00e6re med til at give en mere subjektiv forst\u00e5else af testpersonernes oplevelser med sitet [Nielsen 1993, side 103].<\/p>\n<h3>7.2.2 Klassificering af problemer i testen for medlemmer<\/h3>\n<p>I tabel 7.3 ses en oversigt over tidsm\u00e5lingerne for de forskellige testpersoners udf\u00f8relse af de enkelte scenarier (se afsnit 7.1.6 og bilag D). Dette har v\u00e6ret med til at give os et samlet overblik over tidsforbruget pr. scenarie, som har hjulpet os med at klassificere de fundne usability fejl.<\/p>\n<table>\n<tbody>\n<tr>\n<td>\n<p><strong>Testperson<\/strong>\/<\/p>\n<p><em>Scenarie<\/em><\/p>\n<\/td>\n<td>\n<p><strong>1<\/strong><\/p>\n<\/td>\n<td>\n<p><strong>2<\/strong><\/p>\n<\/td>\n<td>\n<p><strong>3<\/strong><\/p>\n<\/td>\n<td>\n<p><strong>4<\/strong><\/p>\n<\/td>\n<td>\n<p><strong>5<\/strong><\/p>\n<\/td>\n<td>\n<p><strong>6<\/strong><\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>1.a<\/em><\/p>\n<\/td>\n<td>\n<p>0:18<\/p>\n<\/td>\n<td>\n<p>0:18<\/p>\n<\/td>\n<td>\n<p>0:22<\/p>\n<\/td>\n<td>\n<p>0:27<\/p>\n<\/td>\n<td>\n<p>1:00<\/p>\n<\/td>\n<td>\n<p>1:12<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>2.a<\/em><\/p>\n<\/td>\n<td>\n<p>1:07<\/p>\n<\/td>\n<td>\n<p>1:30<\/p>\n<\/td>\n<td>\n<p>1:11<\/p>\n<\/td>\n<td>\n<p>1:02<\/p>\n<\/td>\n<td>\n<p>1:31<\/p>\n<\/td>\n<td>\n<p>4:31<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>3.a<\/em><\/p>\n<\/td>\n<td>\n<p>0:19<\/p>\n<\/td>\n<td>\n<p>0:17<\/p>\n<\/td>\n<td>\n<p>1:22<\/p>\n<\/td>\n<td>\n<p>0:37<\/p>\n<\/td>\n<td>\n<p>0:15<\/p>\n<\/td>\n<td>\n<p>0:22<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>4.a<\/em><\/p>\n<\/td>\n<td>\n<p>0:20<\/p>\n<\/td>\n<td>\n<p>0:28<\/p>\n<\/td>\n<td>\n<p>0:15<\/p>\n<\/td>\n<td>\n<p>0:12<\/p>\n<\/td>\n<td>\n<p>0:24<\/p>\n<\/td>\n<td>\n<p>1:20<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>4.b<\/em><\/p>\n<\/td>\n<td>\n<p>0:32<\/p>\n<\/td>\n<td>\n<p>0:20<\/p>\n<\/td>\n<td>\n<p>0:23<\/p>\n<\/td>\n<td>\n<p>0:20<\/p>\n<\/td>\n<td>\n<p>0:38<\/p>\n<\/td>\n<td>\n<p>0:59<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>4.c<\/em><\/p>\n<\/td>\n<td>\n<p>0:07<\/p>\n<\/td>\n<td>\n<p>0:15<\/p>\n<\/td>\n<td>\n<p>0:30<\/p>\n<\/td>\n<td>\n<p>0:14<\/p>\n<\/td>\n<td>\n<p>0:50<\/p>\n<\/td>\n<td>\n<p>0:50<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>4.d<\/em><\/p>\n<\/td>\n<td>\n<p>0:36<\/p>\n<\/td>\n<td>\n<p>0:02<\/p>\n<\/td>\n<td>\n<p>0:02<\/p>\n<\/td>\n<td>\n<p>0:02<\/p>\n<\/td>\n<td>\n<p>0:30<\/p>\n<\/td>\n<td>\n<p>2:15<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>5.a<\/em><\/p>\n<\/td>\n<td>\n<p>0:22<\/p>\n<\/td>\n<td>\n<p>0:09<\/p>\n<\/td>\n<td>\n<p>0:12<\/p>\n<\/td>\n<td>\n<p>0:12<\/p>\n<\/td>\n<td>\n<p>0:09<\/p>\n<\/td>\n<td>\n<p>0:27<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>5.b<\/em><\/p>\n<\/td>\n<td>\n<p>0:25<\/p>\n<\/td>\n<td>\n<p>0:20<\/p>\n<\/td>\n<td>\n<p>0:20<\/p>\n<\/td>\n<td>\n<p>0:13<\/p>\n<\/td>\n<td>\n<p>0:35<\/p>\n<\/td>\n<td>\n<p>3:05<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>6.a<\/em><\/p>\n<\/td>\n<td>\n<p>0:03<\/p>\n<\/td>\n<td>\n<p>0:02<\/p>\n<\/td>\n<td>\n<p>0:02<\/p>\n<\/td>\n<td>\n<p>0:02<\/p>\n<\/td>\n<td>\n<p>0:03<\/p>\n<\/td>\n<td>\n<p>0:05<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>Samlet<\/em><\/p>\n<\/td>\n<td>\n<p>4:00<\/p>\n<\/td>\n<td>\n<p>3:42<\/p>\n<\/td>\n<td>\n<p>4:39<\/p>\n<\/td>\n<td>\n<p>3:21<\/p>\n<\/td>\n<td>\n<p>5:55<\/p>\n<\/td>\n<td>\n<p>15:06<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Tabel 7.3: <\/strong>Tidsforbrug pr. scenarie for medlemmer opgjort i minutter:sekunder<\/p>\n<p>Tabel 7.4 viser vores klassificering af fundne usability fejl i testen af medlemmer. Problemerne er listet efter scenarier, hvor to af problemer har f\u00e5et tildelt graden kosmetisk, og et er blevet tildelt graden seri\u00f8st.<\/p>\n<p>Oplevet af<\/p>\n<table>\n<tbody>\n<tr>\n<td>\n<p>Sce.<\/p>\n<\/td>\n<td colspan=\"2\">\n<p>Brugbarhedsproblem<\/p>\n<\/td>\n<td>\n<p>Kategori<\/p>\n<\/td>\n<td>\n<p>1<\/p>\n<\/td>\n<td>\n<p>2<\/p>\n<\/td>\n<td>\n<p>3<\/p>\n<\/td>\n<td>\n<p>4<\/p>\n<\/td>\n<td>\n<p>5<\/p>\n<\/td>\n<td>\n<p>6<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p>1.a<\/p>\n<\/td>\n<td>\n<p>P1<\/p>\n<\/td>\n<td>\n<p>Vedt\u00e6gt placering<\/p>\n<\/td>\n<td>\n<p>Kosmetisk<\/p>\n<\/td>\n<td>\n<p>x<\/p>\n<\/td>\n<td>&nbsp;<\/td>\n<td>&nbsp;<\/td>\n<td>&nbsp;<\/td>\n<td>\n<p>x<\/p>\n<\/td>\n<td>\n<p>x<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p>3.b<\/p>\n<\/td>\n<td>\n<p>P2<\/p>\n<\/td>\n<td>\n<p>Besv\u00e6rlighed ved at finde dato for standerhejsning<\/p>\n<\/td>\n<td>\n<p>Kosmetisk<\/p>\n<\/td>\n<td>&nbsp;<\/td>\n<td>&nbsp;<\/td>\n<td>\n<p>x<\/p>\n<\/td>\n<td>\n<p>x<\/p>\n<\/td>\n<td>&nbsp;<\/td>\n<td>&nbsp;<\/td>\n<\/tr>\n<tr>\n<td>\n<p>4.b<\/p>\n<\/td>\n<td>\n<p>P3<\/p>\n<\/td>\n<td>\n<p>Afmelding af den bookede tid<\/p>\n<\/td>\n<td>\n<p>Seri\u00f8st<\/p>\n<\/td>\n<td>\n<p>x<\/p>\n<\/td>\n<td>&nbsp;<\/td>\n<td>&nbsp;<\/td>\n<td>&nbsp;<\/td>\n<td>\n<p>x<\/p>\n<\/td>\n<td>\n<p>x<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Tabel 7.4: <\/strong>Kategorisering af problemer ud fra vores usability test af medlemmer<\/p>\n<h4>Kosmetiske problemer<\/h4>\n<p>Der er identificeret to kosmetiske problemer i usability testen for medlemmerne. Fejlene er kategoriseret ud fra severity skalaens kriterier for kosmetiske problemer. Grunden til at problemerne kategoriseres som v\u00e6rende kosmetiske skyldes den minimale tidsforsinkelse p\u00e5 under et minut, samt det at der ikke var nogle frustrationer at identificere ud fra testpersonernes kropssprog.<\/p>\n<p>Et eksempel p\u00e5 et kosmetisk problem er P1, som ses i tabel 7.4. Dette problem oplevede tre ud af i alt seks testpersoner. De tre testpersoner brugte kort tid p\u00e5 at finde siden, der indeholdte vedt\u00e6gterne, som kan findes i undermenuen <em>Om os <\/em>i menubaren. Der var her tale om en tidsforsinkelse p\u00e5 under et minut, og der var ingen frustrationer at identificere hos testpersonerne.<\/p>\n<h4>Seri\u00f8se problemer<\/h4>\n<p>Vi har identificeret et seri\u00f8st problem, P3 (se tabel 7.4). Problemet udmundede sig i, at n\u00e5r en booket tid skulle afmeldes, var der tre ud af seks brugere, som klikkede p\u00e5 det bl\u00e5 felt i selve kalenderen, som er den bookede tid (se figur 7.8). Ved at klikke p\u00e5 dette felt, \u00e5bnes der blot information om, hvem der har booket banen og hvorn\u00e5r. For at afmelde den bookede tid, skal testpersonen klikke p\u00e5 knappen <em>Afmeld tid<\/em>, som er til h\u00f8jre for selve bookingkalenderen. Dette skabte for to af testpersonerne en minimal tidsforsinkelse. En af testpersonerne var n\u00f8dsaget til at f\u00e5 hj\u00e6lp af testlederen for at identificere knappen. Hertil skal det dog n\u00e6vnes, at testlederen allerede hjalp efter mindre end et minut, hvilket var en fejl fra testlederens side af. Testpersonen havde ikke givet op eller udvist store frustrationer, og det kan derfor ikke udelukkes, at testpersonen kunne gennemf\u00f8re opgaven uden hj\u00e6lp fra testlederen.<\/p>\n<p><img loading=\"lazy\" width=\"1180\" height=\"636\" class=\"wp-image-1604\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-70.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-70.jpeg 1180w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-70-300x162.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-70-768x414.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-70-1024x552.jpeg 1024w\" sizes=\"(max-width: 1180px) 100vw, 1180px\" \/><\/p>\n<p><strong>Figur 7.8: <\/strong>Sk\u00e6rmbillede af bookingfunktionen p\u00e5 mbtennis.dk. Knappen <em>Afmeld tid <\/em>ses til h\u00f8jre p\u00e5 billedet.<\/p>\n<h4>Debriefing<\/h4>\n<p>Generelt mente testpersonerne, at det var nemt og ukompliceret at finde rundt p\u00e5 hjemmesiden. To testpersoner udtalte, at den var ensartet hele vejen rundt, hvilket gjorde det let at f\u00e5 et overblik og nemmere at benytte systemet.<\/p>\n<p>Tre testpersoner m\u00f8dte dog en udfordring i forhold til at finde vedt\u00e6gterne p\u00e5 siden. De var her i tvivl om, hvor de skulle finde denne information henne.<\/p>\n<p>Alle testpersonerne mente, at bookingfunktionen var nem at benytte, da den mindede meget om lignende systemer, og de fandt den derfor let genkendelig. En testperson udtalte, at det var meget logisk opsat og skabte derfor ikke tvivl, da en tid skulle bookes.<\/p>\n<p>Dog havde tre testpersoner sv\u00e6rt ved at afmelde tiden, da de gerne ville trykke p\u00e5 den valgte tid og afmelde den ved hj\u00e6lp af pop-op vinduet, som tidligere n\u00e6vnt. Dette skabte en smule undren hos disse, og de udtalte at det kunne v\u00e6re rart, hvis det var muligt at afmelde tiden ved at kunne trykke ind p\u00e5 den. Dog udtalte en af testpersonerne, at det kun var et problem f\u00f8rste gang, da denne ville kende placeringen af funktionen n\u00e6ste gang en tid skulle afmeldes.<\/p>\n<p>En testperson udtalte, at det havde v\u00e6ret rart, hvis det var muligt at finde nyeste informationer i menubaren, og derved ikke skulle lede efter informationerne om standerhejsning p\u00e5 forsiden. Samtidig mente testpersonen ogs\u00e5, at inddelingen af indmeldelsesformularen var anderledes end hvad denne var vant til, men det var dog ikke et problem at udfylde informationerne &#8211; kun en undren til inddelingen.<\/p>\n<p>Alle testpersonerne udtalte, at de gerne ville benytte systemet igen, da det var nemt at benytte og danne sig et overblik over ledige tider.<\/p>\n<h3>7.2.3 Klassificering af problemer i testen for administratorer<\/h3>\n<p>Tabel 7.5 viser tidsm\u00e5lingerne for testpersonernes udf\u00f8relse af de stillede scenarier, blot for administratorer. Her har vi ligeledes analyseret videomaterialet, som vi har optaget undervejs i testene. Vi har valgt kun at teste to personer, da det, som tidligere n\u00e6vnt, netop er de to personer, der kommer til at benytte systemet. Det faktum at vi kun tester to personer kan dog medf\u00f8re at resultaterne ikke er lige s\u00e5 konkluderende, som hvis vi havde testet flere, men kan stadig v\u00e6re med til at udpege nogle usability fejl.<\/p>\n<table>\n<tbody>\n<tr>\n<td>\n<p><strong>Testperson<\/strong>\/<\/p>\n<p><em>Scenarie<\/em><\/p>\n<\/td>\n<td>\n<p><strong>1<\/strong><\/p>\n<\/td>\n<td>\n<p><strong>2<\/strong><\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>1.a<\/em><\/p>\n<\/td>\n<td>\n<p>0:57<\/p>\n<\/td>\n<td>\n<p>2:04<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>1.b<\/em><\/p>\n<\/td>\n<td>\n<p>0:36<\/p>\n<\/td>\n<td>\n<p>0:43<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>2.a<\/em><\/p>\n<\/td>\n<td>\n<p>0:32<\/p>\n<\/td>\n<td>\n<p>0:29<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>3.a<\/em><\/p>\n<\/td>\n<td>\n<p>0:39<\/p>\n<\/td>\n<td>\n<p>1:01<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>4.a<\/em><\/p>\n<\/td>\n<td>\n<p>1:31<\/p>\n<\/td>\n<td>\n<p>5:44<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>5.a<\/em><\/p>\n<\/td>\n<td>\n<p>0:52<\/p>\n<\/td>\n<td>\n<p>1:19<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>6.a<\/em><\/p>\n<\/td>\n<td>\n<p>0:14<\/p>\n<\/td>\n<td>\n<p>1:42<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>6.b<\/em><\/p>\n<\/td>\n<td>\n<p>0:13<\/p>\n<\/td>\n<td>\n<p>0:16<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>7.a<\/em><\/p>\n<\/td>\n<td>\n<p>0:23<\/p>\n<\/td>\n<td>\n<p>0:43<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>8.a<\/em><\/p>\n<\/td>\n<td>\n<p>0:14<\/p>\n<\/td>\n<td>\n<p>0:12<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p><em>Samlet<\/em><\/p>\n<\/td>\n<td>\n<p>6:11<\/p>\n<\/td>\n<td>\n<p>14:30<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Tabel 7.5: <\/strong>Tidsforbrug pr. scenarie for administratorer opgjort i minutter:sekunder<\/p>\n<p>Tabel 7.6 viser klassificeringen af fundne usability fejl i testen af administratorerne. Her har vi identificeret et kosmetisk og et seri\u00f8st problem, som vi uddyber herunder.<\/p>\n<p>Oplevet af<\/p>\n<table>\n<tbody>\n<tr>\n<td>\n<p>Sce.<\/p>\n<\/td>\n<td colspan=\"2\">\n<p>Brugbarhedsproblem<\/p>\n<\/td>\n<td>\n<p>Kategori<\/p>\n<\/td>\n<td>\n<p>1<\/p>\n<\/td>\n<td>\n<p>2<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p>4.a<\/p>\n<\/td>\n<td>\n<p>P4<\/p>\n<\/td>\n<td>\n<p>Upload af billede<\/p>\n<\/td>\n<td>\n<p>Seri\u00f8st<\/p>\n<\/td>\n<td>\n<p>x<\/p>\n<\/td>\n<td>\n<p>x<\/p>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<p>5.a<\/p>\n<\/td>\n<td>\n<p>P5<\/p>\n<\/td>\n<td>\n<p>Afmelding af tid<\/p>\n<\/td>\n<td>\n<p>Kosmetisk<\/p>\n<\/td>\n<td>\n<p>x<\/p>\n<\/td>\n<td>&nbsp;<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Tabel 7.6: <\/strong>Kategorisering af problemer ud fra usability testen af administratorer<\/p>\n<h4>Kosmetiske problemer<\/h4>\n<p>Der blev fundet et kosmetisk problem (se P5 i tabel 7.6) i usability testen for administratorerne. Her havde den ene testperson problemer med at finde afmeldingsfunktionen for en booket tid. Testpersonen trykkede gentagne gange p\u00e5 den bookede tid for at se, om der kom en afmeldingsfunktion frem i pop-op vinduet, se figur 7.9. Dette skabte ikke frustration, men en smule undren hos testpersonen. Denne blev dog forsinket med et minuts tid, f\u00f8r afmeldingsfunktionen i h\u00f8jre side af figur 7.8 blev fundet.<\/p>\n<p><img loading=\"lazy\" width=\"1100\" height=\"603\" class=\"wp-image-1605\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-71.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-71.jpeg 1100w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-71-300x164.jpeg 300w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-71-768x421.jpeg 768w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-71-1024x561.jpeg 1024w\" sizes=\"(max-width: 1100px) 100vw, 1100px\" \/><\/p>\n<p><strong>Figur 7.9: <\/strong>Sk\u00e6rmbillede af bookingfunktionens pop-op vindue p\u00e5 administratorsiden<\/p>\n<p>Problemet P5 blev ogs\u00e5 observeret ved P3 i medlemstesten. Det er derfor et gennemg\u00e5ende problem p\u00e5 siden, som har skabt en smule forvirring og undren hos flere testpersoner.<\/p>\n<h4>Seri\u00f8se problemer<\/h4>\n<p>Der blev fundet et seri\u00f8st problem p\u00e5 administratorsiden, se P4 i tabel 7.6. Her havde begge testpersoner problemer med at uploade et billede til hjemmesiden. Problemet fandt sted, da testpersonerne havde valgt den fil, som de gerne ville uploade. De troede begge, at billedet automatisk ville blive uploadet og trykkede derfor ikke p\u00e5 knappen <em>Upload billede<\/em>, se figur 7.10.<\/p>\n<p>Dette er et seri\u00f8st problem, da begge testpersoner blev flere minutter forsinkede og gentagne gange pr\u00f8vede at uploade billedet uden held. De fandt dog begge ud af funktionen til sidst, men de udviste forvirring og undren over, hvorfor funktionen ikke reagerede, som de havde regnet med.<\/p>\n<p><img loading=\"lazy\" width=\"425\" height=\"281\" class=\"wp-image-1606\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-72.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-72.jpeg 425w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-72-300x198.jpeg 300w\" sizes=\"(max-width: 425px) 100vw, 425px\" \/><\/p>\n<p><strong>Figur 7.10: <\/strong>Sk\u00e6rmbillede af administratorfunktionen til upload af billede<\/p>\n<h4>Debriefing<\/h4>\n<p>Begge testpersoner udtalte, at de fandt siden nem at benytte &#8211; is\u00e6r grundet det genkendelige layout fra medlemssiden. De n\u00e6vnte dog begge, at de lige skulle l\u00e6re systemet at kende, da de startede p\u00e5 opgaverne og ikke helt vidste, hvordan systemet fungerede.<\/p>\n<p>Testpersonerne havde begge problemer med at uploade et billede til websitet, hvilket er klassificeret som et seri\u00f8st problem. En af testpersonerne udtalte dog, at han ikke normalt benyttede computere, s\u00e5 derfor havde han lidt problemer med at finde ud af, hvordan funktionen fungerede. De mente begge, at hvis de havde f\u00e5et en introduktion til funktionen forinden, s\u00e5 ville de ikke have haft problemer med at uploade.<\/p>\n<p>Generelt var begge testpersoner ikke i tvivl om funktionerne p\u00e5 sitet. En testperson n\u00e6vnte, at systemet var logisk og intuitivt, og det derfor ikke ville v\u00e6re et problem, hvis systemet skulle benyttes igen uden hj\u00e6lp.<\/p>\n<p>Samtidig n\u00e6vnte en testperson ligeledes, at det var et v\u00e6sentligt lettere system at finde rundt i, i forhold til deres nuv\u00e6rende hjemmeside.<\/p>\n<p><em>7.3. FEJLKILDER<\/em><\/p>\n<h2>7.3 Fejlkilder<\/h2>\n<p>Gennem usability testene observerede vi steder, hvor vi skulle have v\u00e6ret mere opm\u00e6rksomme, eller hvor testen kunne forbedres.<\/p>\n<h3>7.3.1 Fejl i kode<\/h3>\n<p>Den f\u00f8rste testperson, efter pilottesten var udf\u00f8rt, oplevede en fejl, hvor denne ikke kunne afmelde sin tid i kalenderen. Denne fejl opstod, da vi havde \u00e6ndret opstilling af koden for at g\u00f8re den mere ensformig. Dette resulterede i at noget af koden ikke fungerede, og funktionen derfor ikke virkede. Vi burde derfor have testet systemet igennem igen efter koden var lavet om.<\/p>\n<h3>7.3.2 Netv\u00e6rksforbindelse<\/h3>\n<p>I usability testen for administratorsiden oplevede vi problemer med netv\u00e6rksforbindelsen, som gjorde at de billeder, der skulle uploades, blev uploadet rigtig langsomt. Testpersonerne blev i tvivl, om de havde gjort det rigtigt og blev ved med at gentage processen, hvilket fik systemet til at fungere endnu langsommere. Her burde vi have sikret at netforbindelsen var hurtigt nok til at uploade billederne eller at billedfilerne var mindre.<\/p>\n<h2>7.4 Evaluering af usability test<\/h2>\n<p>For at sikre vores system levede op til vores egne, samt samarbejdspartnerens forventninger, var det essentielt at gennemf\u00f8re en usability test. Vi opstillede derfor en r\u00e6kke succeskriterier for usability testen, for at sikre vores \u00f8nskede form\u00e5l med testen ville blive opfyldt. Et af succeskriterierne var at systemet levede op til kravspecifikationen, som blev udarbejdedet sammen med bestyrelsesformanden. Vi opstillede derfor testen ud fra de testbare krav, for at se om dette var tilf\u00e6ldet. Vi kan konstatere, at langt de fleste af kravene er opfyldt i systemet. Det mest fundamentale var, at alle vores krav med prioritet 1 <em>(Must have) <\/em>eller 2 <em>(Should have) <\/em>var opfyldt, hvilket blev opfyldt for alle, p\u00e5 n\u00e6r \u00e9t krav. Succeskriteriet for krav 7b er, at ingen seri\u00f8se, kritiske eller katastrofale fejl er at finde i systemet for medlemmer. Da vi har identificeret en seri\u00f8s fejl i testen, er dette ikke opfyldt. I forhold til prioritet 3 <em>(Could have) <\/em>og prioritet 4 <em>(Want to have but want have this time around)<\/em>, var disse krav ikke fundamentale i forhold til succeskriteriet af testen. Her har vi opfyldt syv af i alt ni prioritet 3 krav (de to ikke-opfyldte krav ses i afsnittet <em>diskussion<\/em>).<\/p>\n<p><em>7.4. EVALUERING AF USABILITY TEST<\/em><\/p>\n<p>Udover at kontrollere om kravene var opfyldt for hhv. bruger og administrator var et af vores fokusomr\u00e5der at teste systemet for de tre usability attributter: Satisfaction, error og learnability. I forhold til error atributten havde vi et konkret succeskriterie for medlemstesten, som hed at systemet ikke m\u00e5tte indeholde nogle seri\u00f8se, kritiske eller katastrofale fejl. Dette kriterie er identisk med krav 7b i kravsspecikfikationen og ikke opfyldt, som n\u00e6vnt i foreg\u00e5ende afsnit.<\/p>\n<p>I administratortesten var succeskriteriet ligeledes at systemet ikke m\u00e5tte indeholde seri\u00f8se, kritiske eller katastrofale fejl. Da et af problemerne var seri\u00f8st, er dette kriterium ikke opfyldt, men vi str\u00e6ber efter at l\u00f8se problemet og vil komme med l\u00f8sningsforslag i afsnit 7.5.<\/p>\n<p>Ud fra usability attributten satisfaction var succeskriteriet for medlems- samt administrator testen, at systemet skulle v\u00e6re tilfredsstillende at bruge. Samtlige testpersoner i medlemstesten udtalte af systemet var nemt at bruge, samt at de vil benytte systemet igen, hvilket kan klassificeres som tilfredsstillende. Ydermere udviste ingen personer frustrationer eller klare utilfredsheder undervejs i testen. I administratortesten udtalte testpersonerne blandt andet, at systemet var enkelt og intuitivt at bruge, og udover opgave 4a i administratortesten, var der ingen utilfredsheder at spore hos testpersonerne.<\/p>\n<p>Den sidste usability attribut vi havde fokuseret p\u00e5 var learnability. Succeskriteriet var her for medlemstesten, at systemet skal v\u00e6re let anvendeligt for en ny bruger, og at brugeren skal bruge mindst muligt tid p\u00e5 at s\u00e6tte sig ind i systemet. Kigges der p\u00e5 tabel 7.3, var hovedparten af opgaverne udf\u00f8rt p\u00e5 under et minut og langt de fleste p\u00e5 under to minutter. Testperson 6 var den eneste testperson, som brugte over 2 minutter p\u00e5 at l\u00f8se en opgave. Denne testperson havde ikke s\u00e6rlig meget erfaring med brug af computere, hvilket resulterede i at opgaver, hvor blandt andet tastaturet skulle bruges tog l\u00e6ngere tid. Udover at opgaverne blev gennemf\u00f8rt relativ hurtigt, havde testpersonerne generelt set heller ingen problemer med at l\u00f8se opgaverne. Kun testperson 6 havde problemer med en opgave, hvor testpersonen m\u00e5tte f\u00e5 hj\u00e6lp af testlederen, ellers blev alle opgaverne gennemf\u00f8rt uden hj\u00e6lp.<\/p>\n<p>I den efterf\u00f8lgende debriefing gav testpersonerne ogs\u00e5 udtryk for, at det var nemt og ukompliceret at finde rundt p\u00e5 hjemmesiden. Som n\u00e6vnt tidligere udtalte to af testpersonerne, at siderne var ensartet, hvilket gjorde det let at f\u00e5 et overblik og nemmere at benytte systemet. I envisionment-fasen (se afsnit 4) designede vi efter nogle designprincipper, som blandt andet fokuserede p\u00e5 learnabillityen af systemet, heriblandt designprincippet consistency. Ud fra deltagernes udtalelser og ageren i pr\u00f8ven kan vi konstatere, at vores m\u00e5l for designet er opfyldt i forhold til systemets learnability.<\/p>\n<p><em>7.5. FORBEDRINGER TIL SYSTEM UD FRA USABILITY TEST<\/em><\/p>\n<p>I forhold til administratortesten m\u00e5tte systemet gerne tage lidt l\u00e6ngere tid at l\u00e6re og blive komfortabel med, idet der er flere og mere komplekse funktioner. Herudover er det ogs\u00e5 de samme f\u00e5 personer, der kommer til at bruge disse funktioner gang p\u00e5 gang. Her var tendensen den samme, nemlig at systemet var nemt og hurtigt at bruge. Der var dog opgave 4a, hvor testpersonerne havde komplikationer med at gennemf\u00f8re opgaven. En af testpersonerne n\u00e6vnte at systemet var logisk og intuitivt, og at det derfor ikke ville v\u00e6re et problem, hvis systemet skulle benyttes uden hj\u00e6lp. Administratorfunktionernes learnability lever ligeledes op til vores forventninger og succeskriterie.<\/p>\n<h2>7.5 Forbedringer til system ud fra usability test<\/h2>\n<p>Gennem usability testen og databehandlingen har vi f\u00e5et belyst nogle problemomr\u00e5der i vores system. Vi har taget disse problemer til overvejelse og vil herunder gennemg\u00e5 forbedringer, som kan laves til systemet.<\/p>\n<h3>7.5.1 Afmeld funktion<\/h3>\n<p>Usability testen viste, at b\u00e5de medlemmer og administratorer havde problemer med at afmelde en tid med afmeldningsfunktionen. Dette problem kunne l\u00f8ses, hvis det var muligt at afmelde en reserveret tid ved en funktion i pop-op vinduet. Systemet ville s\u00e5ledes b\u00e5de underst\u00f8tte afmeldingsfunktionen i pop-op vinduet og den nuv\u00e6rende l\u00f8sning (se figur 7.8). L\u00f8sningen med at kunne afmelde en tid i pop-up vinduet var allerede fra starten den l\u00f8sning, vi helst s\u00e5 udf\u00f8rt, men grundet tidspres og problemer med JavaScript i den \u00e5bne modal (se afsnit 6.6), valgte vi den l\u00f8sning, som er at finde i det udarbejdede system. Dette er noget vi vil bestr\u00e6be p\u00e5 at l\u00f8se, hvis systemet bliver taget i brug. Anvendes l\u00f8sningen med afmeldingsknappen i pop-up vinduet vil det betyde, at den seri\u00f8se fejl vil blive l\u00f8st, og dermed overholdes samtlige prioritet 1 og 2 krav i kravsspecifikationen.<\/p>\n<h3>7.5.2 Upload af billeder<\/h3>\n<p>Begge testpersoner i testen for administratorer havde problemer med at uploade et billede til hjemmesiden. Dels grundet netv\u00e6rksforbindelsen, men prim\u00e6rt grundet misforst\u00e5else af selve funktionen. P\u00e5 nuv\u00e6rende tidspunkt skal administratoren placere musemark\u00f8ren over det billede, som denne gerne vil have \u00e6ndret. Derefter skal billedet v\u00e6lges og til slut skal der trykkes p\u00e5 <em>Upload billede<\/em>. Funktionen forsvinder dog, n\u00e5r administratoren fjerner musemark\u00f8ren fra det billede, der skal skiftes. En l\u00f8sning kunne v\u00e6re at lade funktionen<\/p>\n<p><em>7.5. FORBEDRINGER TIL SYSTEM UD FRA USABILITY TEST<\/em><\/p>\n<p>blive vist i l\u00e6ngere tid efter musemark\u00f8ren er fjernet. En anden l\u00f8sning kunne v\u00e6re at \u00e6ndre koden, s\u00e5ledes at kunne uploades billeder i modalen, hvor det er n\u00f8dvendigt at trykke <em>upload <\/em>for at lukke modalen. P\u00e5 denne m\u00e5de vil det blive \u00e5benlyst at trykke <em>upload <\/em>f\u00f8r billedet er uploadet. Dette problem er ligeledes noget vi vil bestr\u00e6be at l\u00f8se i tilf\u00e6ldet af at systemet anvendes. Det vil eliminere den seri\u00f8se fejl identificeret i adminstratortesten.<\/p>\n<h3>7.5.3 Indmeldelsesformular<\/h3>\n<p>En af testpersonerne udtalte, at r\u00e6kkef\u00f8lgen p\u00e5 de informationer, som et medlem skal udfylde, stod anderledes end hvad denne havde m\u00f8dt f\u00f8r (se figur 7.11). Forbedringen i dette tilf\u00e6lde kunne v\u00e6re at omrokere de forskellige felter, s\u00e5 de st\u00e5r over hinanden i stedet, s\u00e5 brugeren nemmere bliver guidet gennem de oplysninger, som skal gives.<\/p>\n<p><img loading=\"lazy\" width=\"653\" height=\"274\" class=\"wp-image-1607\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-73.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-73.jpeg 653w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-73-300x126.jpeg 300w\" sizes=\"(max-width: 653px) 100vw, 653px\" \/><\/p>\n<p><strong>Figur 7.11: <\/strong>Sk\u00e6rmbillede af indmeldelsesformularen p\u00e5 mbtennis.dk<\/p>\n<h3>7.5.4 Nyeste informationer<\/h3>\n<p>Flere testpersoner ledte efter information om standerhejsningen. En af testpersoner udtalte, at det kunne v\u00e6re rart, hvis der havde v\u00e6ret en mulighed i menubaren, hvori der stod de nyeste informationer. Dette har vi taget til overvejelse og mener, at dette kunne v\u00e6re med til at forbedre hjemmesiden, idet \u00e6ldre nyheder dermed ogs\u00e5 vil blive lagret.<\/p>\n<p><strong>Kapitel8<\/strong><\/p>\n<h1>Diskussion<\/h1>\n<h2>8.1 Optimering af koden<\/h2>\n<p>I dette projekt har vi tilegnet os en masse viden omkring programmering i blandt andet PHP og JavaScript. Med den ekstra viden vi har tilegnet os, har vi konkluderet, at noget af det f\u00f8rste kode vi skrev ikke var optimal. Vi har ikke haft tid til at lave radikale \u00e6ndringer, s\u00e5 i dette afsnit vil vi beskrive den mest n\u00e6vnev\u00e6rdige \u00e6ndring, som vi kunne have lavet i forhold til at optimere koden.<\/p>\n<p>I bookingfunktionen oprettes en ny funktion for hver ledig og reserveret tid (se figur 8.1).<\/p>\n<p><em>8.1. OPTIMERING AF KODEN<\/em><\/p>\n<p><img loading=\"lazy\" width=\"512\" height=\"434\" class=\"wp-image-1608\" src=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-74.jpeg\" srcset=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-74.jpeg 512w, https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image-74-300x254.jpeg 300w\" sizes=\"(max-width: 512px) 100vw, 512px\" \/><\/p>\n<p><strong>Figur 8.1: <\/strong>Kodestykke til fremvisning af modalen over bookingkalenderen, n\u00e5r der klikkes p\u00e5 en gr\u00f8n celle<\/p>\n<p>Hvis der eksempelvis er 60 ledige tider i kalenderen, vil dette kodestykke lave 60 forskellige funktioner, som i bund og grund g\u00f8r det samme, blot med forskellige v\u00e6rdier. De v\u00e6rdier, der er forskellige, er det unikke id for cellerne.<\/p>\n<p>Her ville det v\u00e6re smartere at have en enkelt funktion til de ledige tider, der i stedet tog parametre. Det parameter, som vi gerne vil have i koden, er id\u2019et for de enkelte celler, og dette kunne g\u00f8res ved at have en <em>onclick <\/em>funktion p\u00e5 de enkelte celler, der kalder cellens id ind i funktionen. Dette kunne for eksempel se s\u00e5ledes ud: <em>onClick=&#8221;function(this.id)&#8221;<\/em>.<\/p>\n<p><em>8.2. NEDPRIORITERINGER<\/em><\/p>\n<h2>8.2 Nedprioriteringer<\/h2>\n<p>Nogle krav i kravspecifikationen blev nedprioriteret i implementerings-fasen og er derfor ikke med i det f\u00e6rdige system.<\/p>\n<p>Det f\u00f8rste krav vi ikke implementerede, var en administratorfunktion til galleriet p\u00e5 siden<\/p>\n<p><em>(krav 4b)<\/em>. Vi fik lavet en dynamisk gallerifunktion, men grundet tidspres valgte vi ikke at lave administratorfunktionen, og valgte i stedet at fokusere p\u00e5 andre dele af systemet, som havde en h\u00f8jere prioritet.<\/p>\n<p>Det andet krav vi ikke fik med var opfyldelse af lovkrav i relation til datasikkerhed <em>(krav 8b)<\/em>. Dette krav havde en prioritering p\u00e5 2, men fordi vores samarbejdspartner ikke var sikre p\u00e5, at de ville benytte systemet, vurderede vi, at kravet var mindre vigtigt at implementere, idet systemet m\u00e5ske ikke skulle ud i den virkelige verden. Gennem forl\u00f8bet med samarbejdspartneren er de dog blevet mere tilfredse med systemet og vil gerne benytte det. Efter vi har kigget p\u00e5 reglerne for GDPR<sup><sup><a id=\"post-1531-footnote-ref-21\" href=\"#post-1531-footnote-21\">[21]<\/a><\/sup><\/sup>, har vi dog indset, at de er langt mere komplekse end f\u00f8rst antaget. Vores f\u00f8rste tanker var, at kravet kunne l\u00f8ses med en samtykkeerkl\u00e6ring fra brugeren, n\u00e5r de afgav deres oplysninger, men vi har sidenhen erfaret, at dette blot er et af mange facetter i GDPR. Herudover begyndte vi f\u00f8rst at se p\u00e5 det s\u00e5 sent i vores projektforl\u00f8b, at vi ikke kunne n\u00e5 at implementere sikkerhedsforanstaltningerne i systemet.<\/p>\n<p>Kravet om responsivt design, som vi valgte at give en prioritet 4 <em>(Want to have but not this time around)<\/em>, ville vi kigge p\u00e5, hvis vi skulle arbejde videre med systemet. Kravet har v\u00e6ret et element, som har optr\u00e5dt i PACT analysen, men som vi valgte ikke at tage med, da det ikke var i dette projektforl\u00f8bs fokus.<\/p>\n<h3>8.2.1 Datasikkerhed<\/h3>\n<p>I forhold til sikkerhed er der to ting, som vi hverken har med p\u00e5 hjemmesiden eller i kravspecifikationen, men som ville v\u00e6re en god ide at implementeret p\u00e5 et tidspunkt. Det ene er et SSL-certifikat p\u00e5 hjemmesiden og det andet er kryptering af adgangskoder i databasen.<\/p>\n<h4>SSL-certifikat<\/h4>\n<p>SSL er en krypteringsprotokol, der s\u00f8rger for at det kun er afsender og modtager, der kan l\u00e6se informationen, der sendes mellem disse parter [FairSSL n.d.]. N\u00e5r der er sat SSL kryptering op<\/p>\n<p><em>8.3. PROTOTYPER<\/em><\/p>\n<p>p\u00e5 en hjemmeside, vil der i starten af url\u2019en st\u00e5 <em>https <\/em>fremfor blot <em>http<\/em>Google n.d. Idet Midtbyens Tennisklub modtager personlige oplysninger fra deres medlemmer, n\u00e5r de tilmelder sig, b\u00f8r de derfor p\u00e5 et tidspunkt f\u00e5 SSL-certifikatet sat op for medlemmernes sikkerhed.<\/p>\n<h4>Kryptering<\/h4>\n<p>Kryptering af koder i databasen vil ligeledes v\u00e6re en god ide, da det nuv\u00e6rende system tillader, at folk med login til databasen kan se alle brugernes adgangskoder. Dette kan potentielt blive misbrugt, idet folk med adgang til databasen kan fors\u00f8ge at f\u00e5 adgang til andre ting, som for eksempel e-mail, ved at benytte den kode, medlemmerne har angivet i systemet. Ved at kryptere adgangskoderne sikres det at den information, der st\u00e5r i databasen, ikke har noget med de egentlige adgangskoder at g\u00f8re, men derimod best\u00e5r af en lang r\u00e6kke \u201ctilf\u00e6ldige\u201d tegn. PHP har indbyggede funktioner til at g\u00f8re dette, men det er, som beskrevet, ikke noget vi har haft fokus p\u00e5 at implementere p\u00e5 hjemmesiden [php.net n.d.].<\/p>\n<h2>8.3 Prototyper<\/h2>\n<p>Vi kunne have valgt at benytte os af en Lo-Fi prototype i Envisionment-fasen. Dette kunne vi have gjort ved at bruge de udarbejdede sketches til at teste interaktionsmulighederne. Hertil kunne vi have fundet testpersoner, som vi kunne give til opgave at navigere rundt p\u00e5 siderne. Vi kunne have opstillet opgaver ud fra de udarbejdede sketches og bede testpersonerne om at pege p\u00e5 sketchen, n\u00e5r der skulle foretages en interaktion. Dette kunne give os et indtryk af om vores tidlige design id\u00e9er var p\u00e5 vej i den rigtige retning, samt teste den overordnede navigation p\u00e5 sitet. Udover at f\u00f8lge designprincipperne beskrevet i afsnit 4.2 til at underst\u00f8tte designet, kunne en prototype have givet yderligere indsigt i dette.<\/p>\n<p>Da navigationen i systemet er simpel og indeholder f\u00e5 navigationsmuligheder, vurderede vi derfor, at det ikke var n\u00f8dvendigt at benytte os af en Lo-Fi prototype, da denne prototype prim\u00e6rt fokuserer p\u00e5 den overordnede struktur.<\/p>\n<h2>8.4 Sp\u00f8rgeskema<\/h2>\n<p>Vi kunne have valgt at benytte os af sp\u00f8rgeskemaer som supplement til problemanalysen. Udover beretninger fra flere bestyrelsesmedlemmer og gruppemedlemmet om den utilstr\u00e6kkelige bookingproces kunne et sp\u00f8rgeskema, udsendt i foreningen, have givet os yderligere indsigt i bookingprocessen. P\u00e5 den m\u00e5de ville vi have haft udsagn fra flere medlemmer i<\/p>\n<p><em>8.4. SP\u00d8RGESKEMA<\/em><\/p>\n<p>foreningen, som kunne have v\u00e6ret med til at give os yderligere viden omkring, hvorvidt der var et problem.<\/p>\n<p>Set i bakspejlet ville det derfor have v\u00e6ret fordelagtigt at have benyttet sp\u00f8rgeskemaer. Dette ville have givet os et st\u00e6rkere grundlag i forhold til det problem, som vi skulle l\u00f8se. Vores fokus l\u00e5 p\u00e5 kontakten med bestyrelsesformanden for tidligt at kunne f\u00e5 udviklet nogle designid\u00e9er, der kunne benyttes til udarbejdelsen af systemet. Vi havde nogle mindre komplikationer i forbindelse med kontakten med bestyrelsesformanden, hvilket gjorde at vores designproces blev forsinket i forhold til vores oprindelige tidsplan. Derfor fokuserede vi p\u00e5 at indhente den tabte tid i designprocessen, og ikke p\u00e5 at udsende sp\u00f8rgeskemaer til medlemmerne i foreningen.<\/p>\n<p><strong>Kapitel9<\/strong><\/p>\n<h1>Konklusion<\/h1>\n<p>Det initierende problem vi gerne ville l\u00f8se var en ineffektiv bookingprocess. Efter interview med bestyrelsesformanden blev det klart at udover problemet med bookingprocessen, var det ogs\u00e5 vigtigt for foreningen at erhverve nye medlemmer. Dette udmundede i vores problemformulereing:<\/p>\n<p>Hvordan kan vi designe og konstruere et IT-system, som underst\u00f8tter foreningens \u00f8nske om st\u00f8rre brug af banen?<\/p>\n<p>P\u00e5 baggrund af rapporten kan det konkluderes, at konstruktionen af systemet var vellykket, idet det er funktionsdygtigt efter forventning. I usability testene var der en lav fejlrate og ingen kritiske eller katastrofale fejl. Der var dog to seri\u00f8se fejl p\u00e5 sitet: en ved afmeldingsfunktionen og en ved upload af billeder for administrator. P\u00e5 trods af dette, var der generel konsensus om, at systemet var yderst tilfredsstillende at bruge og simpelt at navigere i. I starten af projektet var bestyrelsen kritisk overfor fremtidig anvendelse af IT-systemet, men efter afpr\u00f8vningen i usability testen for bestyrelsesmedlemmerne, udtalte de, at de gerne ville anvende det.<\/p>\n<p>Vi kan konkludere, at IT-systemet underst\u00f8tter foreningens \u00f8nske om st\u00f8rre brug af banen p\u00e5 f\u00f8lgende m\u00e5der:<\/p>\n<p>For det f\u00f8rste medf\u00f8rer anvendelsen af dette IT-system, at det ikke l\u00e6ngere kr\u00e6ver en fysisk tilstedev\u00e6relse i klubhuset for at booke en tid. Dette vil g\u00f8re det mere appellerende for medlemmerne at booke banen p\u00e5 forh\u00e5nd og derfor, h\u00f8jst sandsynligt, l\u00f8se den problematiske bookingproces, hvor klubkulturen er, at medlemmerne omg\u00e5s bookingkalenderen. For det andet g\u00f8r digitaliseringen af bookingprocessen det mere attraktivt for foreningens prim\u00e6re m\u00e5lgruppe, unge, at melde sig ind i foreningen. Det online bookingsystem er attraktivt for is\u00e6r unge, idet unge i h\u00f8jere grad vil have en forventning til, at bookingprocessen foreg\u00e5r online.<\/p>\n<h1>Bibliografi<\/h1>\n<p>123hjemmeside.dk (n.d.). <em>123hjemmeside &#8211; nem hjemmesideservice<\/em>. URL: https:\/\/www.<\/p>\n<p>123hjemmeside.dk\/. (Tilg\u00e5et d. 25.02.2019).<\/p>\n<p>5GBfree (n.d.). <em>5GB free Hosting | Free Webhost |The Best Free Hosting, Period. <\/em>URL: https:<\/p>\n<p>\/\/www.5gbfree.com\/. (Tilg\u00e5et d. 29.03.2019).<\/p>\n<p>Agile Business, Consortium (n.d.). <em>The DSDM Agile Project Framework (2014 Onwards) &#8211;<\/em><\/p>\n<p><em>MoSCoW Prioritisation<\/em>. URL: https:\/\/www.agilebusiness.org\/content\/moscowprioritisation. (Tilg\u00e5et d. 15.03.2019).<\/p>\n<p>Benyon, David (2010). <em>Designing Interactive Systems<\/em>. Second edition. PEARSON.<\/p>\n<p>\u2014 (2014). <em>Designing Interactive Systems<\/em>. Third edition. PEARSON.<\/p>\n<p>Bruun, Anders Rysholt (2019). <em>DEB 3: Envisionment (videomateriale)<\/em>. URL: https:\/\/www. moodle.aau.dk\/course\/view.php?id=28472. (Tilg\u00e5et d. 20.03.2019).<\/p>\n<p>Cowan, Dr. Nelson (2019). <em>Working Memory Laboratory<\/em>. URL: https:\/\/memory.psych. missouri.edu\/cowan.html. (Tilg\u00e5et d. 24.05.2019).<\/p>\n<p>FairSSL (n.d.). <em>Hvad er et SSL-certifikat? | FairSSL<\/em>. URL: https:\/\/www.fairssl.dk\/da\/sslinformation\/what-is-an-ssl-certificate. (Tilg\u00e5et d. 13.05.2019).<\/p>\n<p>Felke-Morris, Terry Ann (2011). <em>Basics of Web Design: HTML5 &amp; CSS3<\/em>. PEARSON.<\/p>\n<p>Google (n.d.). <em>Beskyt dit website med HTTPS<\/em>. URL: https:\/\/support.google.com\/ webmasters\/answer\/6073543?hl=da. (Tilg\u00e5et d. 24.05.2019).<\/p>\n<p>Hosting, NTC (n.d.). <em>phpMyAdmin &#8211; a MySQL Databse Administration Tool<\/em>. URL: https:<\/p>\n<p>\/\/www.ntchosting.com\/encyclopedia\/databases\/mysql\/phpmyadmin\/. (Tilg\u00e5et d.<\/p>\n<p>18.05.2019).<\/p>\n<p>Inc., Github (n.d.). <em>The world\u2019s leading software development platform &#8211; GitHub<\/em>. URL: https:<\/p>\n<p>\/\/github.com\/. (Tilg\u00e5et d. 29.03.2019).<\/p>\n<p>Nielsen, Jacob (1993). <em>Usability Engineering<\/em>. Morgan Kaufmann.<\/p>\n<p>Nixon, Robin (2014). <em>Learning PHP, MySQL, JavaScript, CSS &amp; HTML5 (3rd Edition)<\/em>. O\u2019Reily Media.<\/p>\n<p>php.net (n.d.). <em>PHP: password<sub>h<\/sub><sup>ash <\/sup>\u2212 Manual<\/em>. URL: https:\/\/www.php.net\/manual\/en\/ function.password-hash.php. (Tilg\u00e5et d. 13.05.2019).<\/p>\n<p><em>BIBLIOGRAFI BIBLIOGRAFI<\/em><\/p>\n<p>Raptis, Dimitri (2018). <em>Lecture 3: Identifying and categorizing usability problems<\/em>. URL: https:<\/p>\n<p>\/\/www.moodle.aau.dk\/pluginfile.php\/1348651\/mod_resource\/content\/10\/ ITSY-Usab%5C%20Lecture%5C%203.pdf. (Tilg\u00e5et d. 18.05.2019).<\/p>\n<p>Riis, Ole (2004). <em>Sociologiske metoder i praksis<\/em>. Aalborg Universitetsforlag.<\/p>\n<p>Rosen, Kenneth H. (2019). <em>Discrete Mathematics and Its Applications (Eighth Edition)<\/em>. McGrawHill Edication.<\/p>\n<p>Tennisklub, Midtbyens (n.d.). <em>Midtbyens Tennisklubs hjemmeside<\/em>. URL: http:\/\/www.mtk9000. dk\/. (Tilg\u00e5et d. 25.02.2019).<\/p>\n<p>UnoEuro (n.d.). <em>UnoEuro &#8211; Webhoteller og dom\u00e6ner<\/em>. URL: https:\/\/www.unoeuro.com\/.<\/p>\n<p>(Tilg\u00e5et d. 10.04.2019). w3schools.com (n.d.). <em>w3schools &#8211; The world\u2019s largest developer site<\/em>. URL: https:\/\/www.<\/p>\n<p>w3schools.com\/php\/php_arrays.asp. (Tilg\u00e5et d. 15.05.2019<\/p>\n<ol>\n<li id=\"post-1531-footnote-1\">\n<p>Spatiale f\u00e6rdigheder afg\u00f8r individets evne til at finde rundt p\u00e5 og huske en hjemmeside <a href=\"#post-1531-footnote-ref-1\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-2\">\n<p>En iterativ proces, er en proces, som bliver gennemg\u00e5et og revurderet gentagene gange <a href=\"#post-1531-footnote-ref-2\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-3\">\n<p>Arbejdshukommelse er et andet term for korttidshukommelse <a href=\"#post-1531-footnote-ref-3\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-4\">\n<p>N\u00e5r musemark\u00f8reren holdes over et element vil det skifte farve\/nuance. <a href=\"#post-1531-footnote-ref-4\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-5\">\n<p>Forms (p\u00e5 dansk: formular) indsamler bruger input, blandt andet via checkboxes eller tekstfelter <a href=\"#post-1531-footnote-ref-5\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-6\">\n<p>Client-side betyder at handlingen k\u00f8res lokalt i brugerens browser <a href=\"#post-1531-footnote-ref-6\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-7\">\n<p>Et id er unik attribut for et HTML-element <a href=\"#post-1531-footnote-ref-7\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-8\">\n<p>En <em>class <\/em>er ligesom et <em>id <\/em>en attribut, men bruges til at p\u00e5virke flere elementer <a href=\"#post-1531-footnote-ref-8\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-9\">\n<p>En selector er det element, som skal \u00e6ndres <a href=\"#post-1531-footnote-ref-9\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-10\">\n<p>N\u00e5r der omtales serverside, betyder det at handlingen eksekveres af en server, og ikke af brugerens browser <a href=\"#post-1531-footnote-ref-10\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-11\">\n<p>Et array er en slags liste, der indeholder elementer [w3schools.com n.d.]. Har man eksempelvis et array, der hedder $array, som indeholder fem elementer, kan det f\u00f8rste element tilg\u00e5s ved at skrive $array[0]. Andet element vil kunne tilg\u00e5s ved $array[1] osv. <a href=\"#post-1531-footnote-ref-11\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-12\">\n<p>phpMyAdmin er gratis open source software, der bruges til at h\u00e5ndtere MySQL databaser gennem et grafisk bruger interface [Hosting n.d.] <a href=\"#post-1531-footnote-ref-12\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-13\">\n<p>En m\u00e6ngde er en ikke-ordnet samling af objekter. M\u00e6ngden siges at indeholde sine elementer. Dvs. at elementet &#8220;8:00&#8243;er i m\u00e6ngden &#8220;tidspunkter&#8221;[Rosen 2019, side 116] <a href=\"#post-1531-footnote-ref-13\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-14\">\n<p>En tableheader er den \u00f8verste r\u00e6kke i en tabel og indeholder ofte navne p\u00e5 diverse kolonner <a href=\"#post-1531-footnote-ref-14\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-15\">\n<p>Et <em>if else statement <\/em>kontrollerer f\u00f8rst om udsagnet (<em>if <\/em>) er sandt, og hvis det ikke er tilf\u00e6ldet, aktiveres der en alternativ kode (<em>else<\/em>) <a href=\"#post-1531-footnote-ref-15\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-16\">\n<p>Et <em>do while loop <\/em>betyder, at der g\u00f8res noget, (<em>do<\/em>), imens et andet udsagn er sandt, (<em>while<\/em>) <a href=\"#post-1531-footnote-ref-16\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-17\">\n<p>Et <em>while loop <\/em>udf\u00f8rer en handling, s\u00e5 l\u00e6nge et parameter er opfyldt. I eksemplet p\u00e5 linje 425 i figur 6.16 k\u00f8rer loopet s\u00e5 l\u00e6nge <em>$i <\/em>er mindre end 23. <a href=\"#post-1531-footnote-ref-17\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-18\">\n<p><em>&lt;td&gt; <\/em>eller <em>tabledata <\/em>er det tag, som benyttes for at lave en celle i en r\u00e6kke i en tabel. For at lukke cellen igen, skrives tagget <em>&lt;\/td&gt;<\/em> <a href=\"#post-1531-footnote-ref-18\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-19\">\n<p>En query er foresp\u00f8rgsel til databasen. N\u00e5r vi tilg\u00e5r databasen ved hj\u00e6lp af PHP kommandoer, benytter vi os af SQL queries for at v\u00e6lge pr\u00e6cis den data, vi \u00f8nsker at bruge <a href=\"#post-1531-footnote-ref-19\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-20\">\n<p>En session variabel gemmer bruger information i en variabel, som kan bruges p\u00e5 samtlige side, og fungerer som en global variabel <a href=\"#post-1531-footnote-ref-20\">\u2191<\/a><\/p>\n<\/li>\n<li id=\"post-1531-footnote-21\">\n<p>General Data Protection Regulation <a href=\"#post-1531-footnote-ref-21\">\u2191<\/a><\/p>\n<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"<p>Karakter: 12 P2 PROJEKT Midtbyens Tennisklub Konstruktion og afpr\u00f8vning af et IT-system Gruppe B263 Informationsteknologi &amp; Informatik &#8211; 2. semester Aalborg Universitet 27. maj 2019 F\u00f8rste Studie\u00e5r Informatik og Informationsteknologi Strandvejen 12-14 9000 Aalborg http:\/\/tnb.aau.dk Titel: Abstract: This report sets out to implement and evaluate an it-system for the tennis association Midtbyens Tennisklub. The problem<a class=\"moretag\" href=\"https:\/\/rentabilitet.dk\/opgaver\/semesterprojekter\/p2-konstruktion-og-afprovning-af-et-it-system\/\"><span class=\"screen-reader-text\">L\u00e6s mere omP2 &#8211; Konstruktion og afpr\u00f8vning af et IT-system<\/span>[&#8230;]<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":1830,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v16.5 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>P2 - Konstruktion og afpr\u00f8vning af et IT-system<\/title>\n<meta name=\"description\" content=\"Denne rapport vil gennemg\u00e5 konstruktionen og evalueringen af et IT-system for MidtbyensTennisklub. Den grundl\u00e6ggende interesse for foreningen startede ved at et medlem i gruppen berettede om en problematisk bookingproces. Bookingprocessen foregik ved at medlemmerne fysisk skulle skrive sig i kalenderen i klubhuset.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/rentabilitet.dk\/opgaver\/semesterprojekter\/p2-konstruktion-og-afprovning-af-et-it-system\/\" \/>\n<meta property=\"og:locale\" content=\"da_DK\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"P2 - Konstruktion og afpr\u00f8vning af et IT-system\" \/>\n<meta property=\"og:description\" content=\"Denne rapport vil gennemg\u00e5 konstruktionen og evalueringen af et IT-system for MidtbyensTennisklub. Den grundl\u00e6ggende interesse for foreningen startede ved at et medlem i gruppen berettede om en problematisk bookingproces. Bookingprocessen foregik ved at medlemmerne fysisk skulle skrive sig i kalenderen i klubhuset.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/rentabilitet.dk\/opgaver\/semesterprojekter\/p2-konstruktion-og-afprovning-af-et-it-system\/\" \/>\n<meta property=\"og:site_name\" content=\"HHX opgaver og notater\" \/>\n<meta property=\"article:modified_time\" content=\"2019-10-16T20:03:11+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image.jpeg\" \/>\n<meta name=\"twitter:card\" content=\"summary\" \/>\n<meta name=\"twitter:label1\" content=\"Estimeret l\u00e6setid\" \/>\n\t<meta name=\"twitter:data1\" content=\"118 minutter\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebSite\",\"@id\":\"https:\/\/rentabilitet.dk\/opgaver\/#website\",\"url\":\"https:\/\/rentabilitet.dk\/opgaver\/\",\"name\":\"HHX opgaver og notater\",\"description\":\"F\\u00e5 adgang til 12-tals opgaver samt notater fra forhenv\\u00e6rende hhx elever. Helt gratis.\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":\"https:\/\/rentabilitet.dk\/opgaver\/?s={search_term_string}\",\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"da-DK\"},{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/rentabilitet.dk\/opgaver\/semesterprojekter\/p2-konstruktion-og-afprovning-af-et-it-system\/#primaryimage\",\"inLanguage\":\"da-DK\",\"url\":\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image.jpeg\",\"contentUrl\":\"https:\/\/rentabilitet.dk\/opgaver\/wp-content\/uploads\/2019\/10\/word-image.jpeg\",\"width\":3648,\"height\":1744},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/rentabilitet.dk\/opgaver\/semesterprojekter\/p2-konstruktion-og-afprovning-af-et-it-system\/#webpage\",\"url\":\"https:\/\/rentabilitet.dk\/opgaver\/semesterprojekter\/p2-konstruktion-og-afprovning-af-et-it-system\/\",\"name\":\"P2 - Konstruktion og afpr\\u00f8vning af et IT-system\",\"isPartOf\":{\"@id\":\"https:\/\/rentabilitet.dk\/opgaver\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/rentabilitet.dk\/opgaver\/semesterprojekter\/p2-konstruktion-og-afprovning-af-et-it-system\/#primaryimage\"},\"datePublished\":\"2019-10-16T18:39:51+00:00\",\"dateModified\":\"2019-10-16T20:03:11+00:00\",\"description\":\"Denne rapport vil gennemg\\u00e5 konstruktionen og evalueringen af et IT-system for MidtbyensTennisklub. Den grundl\\u00e6ggende interesse for foreningen startede ved at et medlem i gruppen berettede om en problematisk bookingproces. Bookingprocessen foregik ved at medlemmerne fysisk skulle skrive sig i kalenderen i klubhuset.\",\"breadcrumb\":{\"@id\":\"https:\/\/rentabilitet.dk\/opgaver\/semesterprojekter\/p2-konstruktion-og-afprovning-af-et-it-system\/#breadcrumb\"},\"inLanguage\":\"da-DK\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/rentabilitet.dk\/opgaver\/semesterprojekter\/p2-konstruktion-og-afprovning-af-et-it-system\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/rentabilitet.dk\/opgaver\/semesterprojekter\/p2-konstruktion-og-afprovning-af-et-it-system\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Hjem\",\"item\":\"https:\/\/rentabilitet.dk\/opgaver\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Semesterprojekter\",\"item\":\"https:\/\/rentabilitet.dk\/opgaver\/semesterprojekter\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"P2 &#8211; Konstruktion og afpr\\u00f8vning af et IT-system\"}]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","_links":{"self":[{"href":"https:\/\/rentabilitet.dk\/opgaver\/wp-json\/wp\/v2\/pages\/1531"}],"collection":[{"href":"https:\/\/rentabilitet.dk\/opgaver\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/rentabilitet.dk\/opgaver\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/rentabilitet.dk\/opgaver\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rentabilitet.dk\/opgaver\/wp-json\/wp\/v2\/comments?post=1531"}],"version-history":[{"count":7,"href":"https:\/\/rentabilitet.dk\/opgaver\/wp-json\/wp\/v2\/pages\/1531\/revisions"}],"predecessor-version":[{"id":1834,"href":"https:\/\/rentabilitet.dk\/opgaver\/wp-json\/wp\/v2\/pages\/1531\/revisions\/1834"}],"up":[{"embeddable":true,"href":"https:\/\/rentabilitet.dk\/opgaver\/wp-json\/wp\/v2\/pages\/1830"}],"wp:attachment":[{"href":"https:\/\/rentabilitet.dk\/opgaver\/wp-json\/wp\/v2\/media?parent=1531"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}