Karakter: 12

P2 PROJEKT

Midtbyens Tennisklub

Konstruktion og afprøvning af et

IT-system

Gruppe B263

Informationsteknologi & Informatik – 2. semester Aalborg Universitet

27. maj 2019

Første Studieår 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 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.

Midtbyens Tennisklub

Tema:

Konstruktion og afprøvning af et IT-system

Projektperiode: Forårssemestret 2019

Projektgruppe:

BaIT/INF B263

Deltagere:

Jakob Rønnest Sørensen

Line Buch Christensen

Mads Larsen Underbjerg

Nicolai Harbo Christensen Stefan Emil Mundt

Thomas Kristian Margon Vinther

Vejledere:

Heidi Nielsen

Anslag: 150.903

Sidetal: 129 Bilagsantal: 5 Afleveringsfrist: 27. maj 2019

Rapportens indhold er frit tilgængeligt, men offentliggørelse (med kildeangivelse) må kun ske efter aftale med

forfatterne.

Indhold

Indledning 5
Problemanalyse 6
1. Midtbyens Tennisklub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  1. Bookingprocessen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  2. Nuværende IT-system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Motivation for samarbejdet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Problemformulering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Understanding 9
1. Interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
  1. Forberedelse inden interview . . . . . . . . . . . . . . . . . . . . . . . . . . 9
  2. Interviewformer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
  3. Vores interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2. PACT Analyse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
  1. People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
  2. Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
  3. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
  4. Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
  5. PACT efter interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3. Udarbejdelse af kravspecifikationer. . . . . . . . . . . . . . . . . . . . . . . . . . 16
  1. Kravspecifikationer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  2. MoSCoW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
  3. Vores kravspecifikationer. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Envisionment 22
1. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
  1. Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
  2. Navigationsmap og sekvensmodel for systemet . . . . . . . . . . . . . . . 23

1. Designprincipper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2. Sketches og wireframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
  1. Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
  2. Sketches for Midtbyens Tennisklub . . . . . . . . . . . . . . . . . . . . . . 28
  3. Wireframes for Midtbyens Tennisklub . . . . . . . . . . . . . . . . . . . . . 31

5. Physical design 34

1. Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
  1. Ikoner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
  2. Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
  3. Gestaltlovene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
  4. Farvevalg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
  5. Closure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2. Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
  1. Menubaren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
  2. Bookingkalenderen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
  3. Knapper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6. Implementering 43

1. Sprog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2. Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
  1. Oprettelse af forbindelse til databasen. . . . . . . . . . . . . . . . . . . . 47
3. Princippet bag booking systemet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4. Bookingkalenderen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5. Log-ind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6. Ændring af tekst og billeder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
  1. Redigering af tekst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
  2. Redigering af billeder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7. Medlemshåndtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8. Fra implementering til usability. . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7. Evaluering 76

1. 1. Testplanlægning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
    1. Formålet med testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
    2. Metodeafsnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
    3. Testens forløb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
    4. Succeskriterier for systemet . . . . . . . . . . . . . . . . . . . . . . . . . . . Testpersoner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
    5. Testopgaver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
    6. Databehandling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
      1. Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
      2. Klassificering af problemer i testen for medlemmer. . . . . . . . . . . . 87
      3. Klassificering af problemer i testen for administratorer. . . . . . . . . 90

8. Konklusion 102

Bibliografi 103

Kapitel1

Indledning

Denne rapport vil gennemgå konstruktionen og evalueringen af et IT-system for Midtbyens

Tennisklub. Den grundlæggende 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.

Foreningen blev derfor kontaktet, da vi gerne ville undersøge problematikken nærmere. 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ørre de senere år. Ydermere berettede gruppemedlemmet at der, ved den årlige standerhejsning, var flere medlemmer, der udtalte sig omkring problematikken angående den nuværende bookingproces. Problemet var blandt andet, at banen ofte var optaget, hvilket resulterede i at medlemmer uden en booket tid, kom forgæves til banen. Herudover udtalte bestyrelsesformanden også, at han ønskede at banen blev benyttet mere i fremtiden, hvortil den nuværende bookingproces kan være problematisk.

Foreningen valgte derfor at indgå i et samarbejde med os, da vi havde frembragt idéen om et online bookingsystem.

Rapporten vil beskrive processen fra den initierende kontakt til det færdigt udviklede system. Først vil problematikken belyses yderligere for at få et bedre indblik i, hvordan problemet kan løses bedst muligt i forhold til foreningens interesser. Derefter gennemgås de benyttede udviklingsfaser; Understanding, Envisionment, Physical design, Implementering og Evaluering. Dette vil give et indblik i processen for systemets udvikling fra idé til færdigt produkt.

Afslutningsvis diskuterer vi processen og konkluderer på vores resultater.

Kapitel2 Problemanalyse

2.1 Midtbyens Tennisklub

Midtbyens Tennisklub er bygget på baggrund af ildsjæles irritation over, at tennisklubberne i området var fyldte, og tid på banerne var sparsom. Det blev startskuddet til en lille lokal tennisklub med én enkelt bane i Aalborg midtby. Foreningens værdier bygger på hygge, fællesskab og plads til alle, hvilket foreningens motto, “Livsnydernes Klub”, også afspejler ganske præcist [interview med bestyrelsesformanden].

Foreningen har i dag flere medlemmer, end de har haft i lang tid. Hvor det tidligere har været muligt blot at tage ned på 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ænge er blevet [interview med kasseren].

2.1.1 Bookingprocessen

Når et medlem i dag skal booke en tid på foreningens bane, foregår det fysisk i det lille tilhørende klubhus ved banen. Her er der en kalender, hvori der skrives navn og tidsrum ind, og derved gør andre opmærksomme på, at lige netop på det tidspunkt er banen optaget. Tiderne må ifølge foreningens regler kun bookes én af gangen af en times varighed, således at medlemmer ikke kan reservere banen flere dage i træk. Processen er transparent i forhold til andre medlemmers navne og lægger ikke skjul på hvem, som er der hvornår.

Tager medlemmer spontant ned i foreningen, og banen ikke er i brug, er der frit lejde til at spille, men såfremt banen er booket, og personen med reservationen dukker op senest 15 minutter efter tidens begyndelse, overlades banen til denne person [interview med bestyrelsesformanden].

2.1.2 Nuværende IT-system

Midtbyens Tennisklub nuværende website har adressen www.mtk9000.dk [Tennisklub n.d.]. Websitet er simpelt opbygget og leverer primært informationer til nuværende, samt eventuelt interesserede og kommende medlemmer. Den er oprettet og hostet gennem 123hjemmeside.dk [123hjemmeside.dk n.d.].

Figur 2.1: Billede af nuværende hjemmeside: http://www.mtk9000.dk/

På sitet findes der enkelte informationer om kommende begivenheder, indmeldelse og kontaktinformationer til foreningens bestyrelse. Opbygningen og navigationen er simpel, og alt på siden tilgås gennem menubaren i øverst på siden. Der er sparsomme interaktionsmuligheder på sitet, og disse er kun at finde som kontaktformularer under siden Indmeldelse og Kontakt. Flere af siderne er uden information, hvilket gør at siden fremstår ufærdig eller ubenyttet.

2.2 Motivation for samarbejdet

Det indledende interview med bestyrelsesformanden gav indblik i foreningens motivation for at indgå i et samarbejde. Bestyrelsesformanden nævnte bl.a. at foreningen gerne vil have flere medlemmer, så den kan vokse sig større, samt for at få fornyet energi ind. De nye kræfter til foreningen skal være med til at føre foreningen videre og bevare dens værdier. Desuden nævnte bestyrelsesformanden, at foreningen ikke har interesse i at tjene penge, men derimod kun at se banen blive brugt mere end den gør i dag.

Bestyrelsesformanden ville gerne hjælpe os og kunne samtidigt se fordelene i et online bookingsystem, da det kunne være med til at skabe mere engagement i foreningen og samtidig understøtte et øget antal medlemmer [interview med bestyrelsesformanden].

2.3 Problemformulering

Med udgangspunkt i ovenstående observationer og kontakt med foreningen, er der blevet belyst nogle problemstillinger. Først og fremmest er der den nuværende bookingproces, som er tidskrævende og besværlig for foreningens medlemmer. Dette har skabt en klubkultur, hvor bookingprocessen ofte bliver omgået, og hvor medlemmerne tager ned på banen uden at booke i forvejen, og håber på at banen er ledig. For det andet, har foreningen en vision om at erhverve flere medlemmer, så banens potentiale i højere grad kan blive udnyttet. Dette kunne skabe problemer for den nuværende bookingproces, i og med sandsynligheden for at banen tilfældigvis er ledig vil blive formindsket mere, end den er i forvejen. På baggrund af dette, er vi kommet frem til følgende problemformulering:

Hvordan kan vi designe og konstruere et IT-system, som understøtter foreningens ønske om større brug af banen?

Kapitel3

Understanding

Ved udviklingen af et IT-system er det vigtigt at forstå, hvem der udvikles til. I det følgende afsnit gennemgås teorien for interview, da vi benytter denne undersøgelsesmetode til at opnå mere viden om vores problem. Derefter vi vil udarbejde en PACT analyse med løbende beskrivelser af teorien. Denne vil hjælpe i den efterfølgende proces, hvor kravene til systemet skal udarbejdes.

3.1 Interview

Et interview er en form for samtale, som sigter på at udlede samtalepartnerens viden, opfattelse, meninger eller vurderinger om et bestemt emne. Intervieweren kan være en fremmed person, der ønsker indsigt indenfor et område, som samtalepartneren er en del af. En meningsfuld samtale mellem intervieweren og samtalepartneren opstår bedst, hvis intervieweren har forhåndsviden om det domæne samtalepartneren befinder sig i [Riis 2004, side 75-76].

Vi har valgt at benytte os af et interview, da vi har adgang til en repræsentant i den forening, som vi beskæftiger os med. Interviewformen bidrager også til vores PACT analyse, da vi via et interview både kan få data til at analysere personerne i den forening vi beskæftiger os med, samtidig med at vi kan få oplysninger omkring de aktiviteter, der foregår i foreningen. Derudover kan vi også, via interviewformen, indsamle data omkring konteksten i foreningen, samt om den teknologi foreningen gør brug af.

3.1.1 Forberedelse inden interview

Inden interviewets start er det vigtigt at vide, hvem der interviewes, hvor interviewet kommer til at foregå, samt hvad der gerne vil opnås med interviewet. I det sociologiske interview repræsenterer 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øler,

3.1. INTERVIEW

denne kan eller ikke kan sige [Riis 2004, side 76-77]. Interviewets placering kan påvirke forløbet. Hvis stedet er fremmed for samtalepartneren, vil denne være en gæst hos intervieweren, men hvis interviewet foregår på samtalepartnerens arbejdsplads eller i dennes hjem, kan det give en tryghed for samtalepartneren. Dog kan det give en begrænsning i form af de svar, som den interviewede giver, eller de forstyrrelser denne kunne opleve gennem interviewet [Riis 2004, side 77].

Intervieweren har til formål at styre samtalen, så den holder sig inden for den problemstilling, som er fundet inden interviewet. Det er samtidig vigtigt at interviewerens kropssprog og reaktioner følger samtalens udformning og tempo, så samtalepartneren forbliver afslappet under interviewet. Ydermere er det vigtigt at begge parter er på bølgelængde, og intervieweren skal desuden turde spørge ind til emner, som intervieweren kunne være i tvivl om eller misforstå [Riis 2004, side 78-80].

3.1.2 Interviewformer

Et interview kan udføres på flere forskellige måder, alt efter, hvad der ønskes at opnå med selve interviewet. Der kan gøres brug af tre forskellige former for interview; det strukturerede, det semi-strukturerede og det ustrukturerede.

Det semi-strukturerede interview bygger på en fri form for interview. Her er intervieweren forberedt med nogle spørgsmål, men der er rig mulighed for at berøre andre relevante eller pludseligt opståede emner i løbet af interviewet. På den måde er der mulighed for at opnå en masse data, som berører det emne, der er i fokus fra mange forskellige vinkler. Denne form for interview kan dog være meget krævende for den interviewede, da denne ofte vil blive spurgt om en lang række uddybende spørgsmål, som følge af, eller udover, de egentligt forberedte spørgsmål fra intervieweren [Benyon 2014, side 143].

3.1.3 Vores interview

Vi har valgt at benytte os af det semi-strukturerede interview, da vi ønsker besvarelse af en række spørgsmål, som kan bidrage til vores udarbejdelse af det pågældende IT-system. Det er også en fordel at benytte denne interviewform, da vi er uerfarne interviewere [Riis 2004, side 89].

På baggrund af vores indledende PACT-analyse har vi udledt en række spørgsmål, som vi fandt relevante for at skabe en vis form for struktur, men med mulighed for at stille uddybende spørgsmål undervejs.

3.2 PACT Analyse

Mennesker bruger teknologi til forskellige aktiviteter i forskellige kontekster. Det er derfor vigtigt at forstå og designe systemet efter den sammenhæng, det skal bruges i, og de folk det skal bruges af. Dette kan være komplekst at analysere, så derfor bruger vi PACT-modellen for at sikre os, at vi har taget højde for de elementer, som systemet skal kunne rumme. PACT står for People, Activities, Context og Technology [Benyon 2014, side 25]. Modellen tager højde for mange faktorer, som er vigtige at overveje for at designe et system. Vi vil gennemgå teorien bag de enkelte elementer i PACT-modellen, og løbende applicere dem i forhold til vores projekt. Vi tager udgangspunkt i vores umiddelbare viden om området 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ået be- eller afkræftet 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å domænet og forstå, hvad der er relevant at observere i foreningen samt spørge om i interviewet.

3.2.1 People

Teori

Det er vigtigt at forstå brugerne af systemet og deres forskelligheder samt at tage højde for dem, når der designes et interaktivt system til mennesker. Det er de fysiske, psykologiske og sociale forskelle, der skal tænkes ind i designprocessen. Fysiske forskelle kan være alt fra højde og vægt til fingerstørrelse. Der skal eksempelvis tage højde for fingerstørrelse 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ærdigheder ^{^[1]}, hukommelse, sindslidelser, koncentration samt forskellige persontyper [Benyon 2014, side 30-31].

Et andet aspekt, som er vigtigt, når 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ålgruppe, kan der være store forskelle på deres færdigheder i IT-systemer generelt. Det skal tilgodeses og designes efter, så alle i systemets målgruppen, uanset færdighedsniveau, kan benytte sig af systemet [Benyon 2014, side 33]. I forlængelse af det, skelnes der også mellem heterogene og homogene grupper. En heterogen gruppe er en gruppe af mennesker, som har forskellige forudsætninger og formål med brugen af et IT-system. En homogen gruppe består af personer, som udfører den samme handling, har samme formål, samt færdigheder for brugen af et IT-system [Benyon 2014, side 33].

Analyse

Med udgangspunkt i Midtbyens Tennisklub skal vi tage højde for, at der både er ældre og unge spillere i foreningen, og de derfor kan have forskellige fysiske forudsætninger, såsom forskellige grader af syn og fingerstørrelser. 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ævende.

Derudover skal der tages højde 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å det er så intuitivt som muligt, hvilket fjerner behovet for at det er vigtigt at huske systemet fra gang til gang. Vi har også tænkt over, om det vil være relevant at have en oversættelsesfunktion på siden, hvis der skulle være nogle ikke-dansktalende medlemmer i foreningen, men dette vil vi undersøge nærmere (se afsnit 3.2.5).

Vi antager, at foreningens medlemmer vil være en heterogen gruppe, da der typisk vil være en bred målgruppe i en tennisklub, og det vil formentlig være ækvivalent med, at brugeren vil have forskellige formål og forudsætninger for brug af systemet. Vi forventer, at der i foreningen både vil være erfarne og uerfarne brugere af internettet, og derfor skal systemet designes til de forskellige færdigheder, som brugerne måtte have.

3.2.2 Activity

Teori

Der er mange forskellige aktiviteter systemet skal understøtte og flere måder systemet kan blive brugt på. Det er vigtigt at overveje aktiviteterne et system skal understøtte for at vide hvilke aspekter af systemet, der er vigtige at fokusere på. Der er eksempelvis stor forskel på at designe et system, som bliver brugt dagligt af brugeren, i modsætning til et, som de måske kun bruger en gang om året. Er det et system, hvor brugeren kan være fuldt fokuseret på system og løse opgave for opgave, eller vil brugeren være i et miljø, hvor deres fokus vil skifte mellem systemet og noget andet? Er der nogle perioder, hvor der er høj trafik i systemet og kan dette understøtte det? Disse overvejelser er vigtige at have i designet af et system [Benyon 2014, side 33-34].

Analyse

Det primære formål med systemet er en online bookingfunktion, hvor medlemmerne skal kunne reservere en bane, når de gerne vil spille. Det skal erstatte den nuværende løsning, hvor medlemmet fysisk skal skrive sig op i en kalender nede i foreningen. Derudover er der også en række mindre aktiviteter, som vi antager systemet skal kunne understøtte. Dette indebærer blandt andet en online opslagstavle, kontaktside og vedtægter. Herudover bliver vi også nødt til at have en log-ind funktion, så det kun er foreningens medlemmer, der kan booke en bane.

Hyppigheden for brugen af booking-funktionen vil formentlig være 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æsonen ligger. Vi antager, at der vil være et lille peak omkring standerhejsningen, da det er her sæsonen starter, medlemmer vil formentlig booke banen oftere, og der vil blive foretaget flere indmeldelser.

3.2.3 Context

Teori

Konteksten for hvor og hvordan et systemet bliver brugt er altid vigtig at overveje i designprocessen, da det vil påvirke, hvordan brugeren kommer til at interagere med et system. Konteksten kan både referere til omstændighederne omkring systemet, men også hvordan der samles flere aktiviteter til en større 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å arbejde, udendørs eller noget andet, der kunne påvirke brugen af systemet. I den sociale kontekst bør designeren tænke på, om brugeren er alene eller sammen med andre under brugen af systemet. Den organisatoriske kontekst kunne f.eks. indebære overvejelser om, hvorvidt implementeringen af et system kunne resultere i nedskæringer af job [Benyon 2014, side 34-36].

Analyse

Et eksempel på overvejelser om den fysiske kontekst i vores system kunne eksempelvis være, om spillerne i foreningen primært vil booke en bane fra deres computer hjemmefra eller på 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å smartphone vil komme til at foregå nede i foreningen. Dette er praktisk, da brugeren her vil være sammen med deres medspiller, og de sammen kan planlægge næste gang de skal spille. Grundet den store variation i den fysiske kontekst kan det være svært at tage højde for, og designe til alle de forskellige kontekster. En overvejelse kunne her være størrelsen på brugerens skærm. Det er brugervenligt at have et responsivt design, der retter ind efter størrelsen på brugerens skærm, så hjemmesidens funktionalitet vil være den samme uanset om brugeren benytter systemet på deres computer eller smartphone. Dog er dette udenfor dette semesters fokus og vores evner herpå, så vi har sat responsivt design som et want to have, but won’t have this time around (se afsnit 3.3.2).

I den sociale kontekst kunne det være relevant at kigge på om brugeren benytter sig af systemet sammen med andre eller alene. I vores tilfælde kunne det være, som tidligere nævnt, at brugeren booker banen sammen med sin medspiller. Brugeren ville kunne spørge medspilleren om hjælp, hvis der skulle opstå problemer i interaktionen med systemet.

Det organisatoriske aspekt er begrænset i vores projekt grundet størrelsen på foreningen. Det kunne overvejes, hvordan den nye bookingproces gennem systemet vil ændre spillernes forhold til foreningen. For nogle vil det være en forbedring og løsningen på at skulle fysisk ned i foreningen for at booke en tid.

3.2.4 Technology

Teori

Det er vigtigt at forstå teknologien, som IT-systemet benytter, samt forstå dets begrænsninger og muligheder, når systemet skal designes. Det er vigtigt for udviklerne af det interaktive system at forstå 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ære en smartphone, hvor en input teknologi kunne være touchskærmen eller låseknappen [Benyon 2014, side 36]. Det er vigtigt at tage højde for de muligheder og designe derefter. Output teknologi er, hvor teknologien giver fysiske outputs, f.eks. det visuelle, så som en computerskærm eller lyd fra en højtaler, som er indbygget i mange teknologier [Benyon 2014, side 40].

Analyse

I vores domæne, hvor vi ønsker at designe en hjemmeside, vil der primært blive benyttet to former for fysiske teknologier i form af computeren og smartphonen. I forhold til designet af det interaktive system skal vi forstå, hvilke output og input muligheder de to teknologier har og designe derefter. Vi bruger primært input teknologien touch på mobilen og på computeren anvendes mus og tastatur. Output teknologien vil primært være den samme for begge teknologier i form af skærmen. På trods af at vi går ud fra, at den primære brug vil være på både telefonen og computeren, vil vores design udelukkende fokusere på computer versionen af systemet, da det, som nævnt tidligere, ikke er vores fokus, at optimere systemet til brug på mobilen på dette semester.

3.2.5 PACT efter interview

PACT analysen har givet os et overblik over de kontekster, som er vigtige at tage højde for i forhold til at designe IT-systemet til Midtbyens Tennisklub. PACT analysen har, som tidligere nævnt, hjulpet os med at forstå, hvad der var relevant at spørge om i første interview med bestyrelsesformanden. PACT analysen har suppleret interviewet, og omvendt har interviewet også suppleret PACT analysen. Interviewet har resulteret i at nogle af de antagelser, som vi foretog i PACT analysen, er blevet både be- og afkræftet – og i nogle tilfælde yderligere udspecificeret. Vi vil derfor nu gennemgå de punkter, hvor bestyrelsesformandens udtalelser har påvirket PACT analysen.

I forhold til afsnittet People havde vi en antagelse om, at der ville være en bred målgruppe i foreningen, altså både unge og ældre medlemmer. Dette bekræftede bestyrelsesformanden, og derudover informerede han om, at det primært 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 år. Dette bekræftede blot, at vi skal designe et system til en bred målgruppe, og derfor er de tidligere nævnte overvejelser i afsnittet People, altså reelle problemstillinger. Bestyrelsesformanden berettede også, at der er enkelte engelsktalende medlemmer i foreningen. Det kunne derfor være relevant at have en engelsk version af hjemmesiden, men dette var ifølge bestyrelsesformanden ikke relevant, grundet den lille størrelse på foreningen.

I afsnittet Activity foreslog vi en række funktioner, som kunne være 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æf-

tede bestyrelsesformanden ville være en brugbar funktion for hjemmesiden, som også ville være med til at styrke det fællesskab foreningen står for.

3.3 Udarbejdelse af kravspecifikationer

Interviewet med bestyrelsesformanden og PACT analysen har ligget til grund for udarbejdelsen af vores kravspecifikationer. De hjalp os til at forstå, hvilke krav, der var vigtige at udforme samt prioritere, således at systemet vil kunne understøtte foreningens behov og vision.

I følgende afsnit vil vi først gennemgå teorien for udformningen af kravspecifikationer og derefter gennemgå nogle af de opstillede krav, som er vigtige for foreningen og systemets funktionalitet.

3.3.1 Kravspecifikationer

Teori

Et krav kan defineres som something the product must do or a quality the product must have [Benyon 2014, side 139]. Det er altså elementer eller opgaver, som et produkt skal kunne opfylde.

I udarbejdelsen af kravene til et system undersøger 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^{^[2]}, og derfor er de første udkast sandsynligvis ikke de eneste, ej heller de sidste [Benyon 2014, side 139].

Kunden kan være interesseret i at modtage en kravspecifikation, hvori de opstillede krav til produktet står listet med tilhørende informationer. En kravspecifikation skal være let at læse og forstå, og bør som minimum indeholde:

Et unikt nummer at referere til (et ID)
Kort forklaring/opsummering af kravet
Kilde og begrundelse for kravet

Udover de tre ovenstående kriterier, bør en kravspecifikation ligeledes indeholde en måde at teste om de enkelte krav er blevet opfyldt, en ændringshistorik, 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].

Kravene til et produkt bliver opdelt i funktionelle og ikke-funktionelle krav. De funktionelle krav dækker over de ting eller funktioner, som produktet skal kunne gøre. De ikke-funktionelle krav dækker over alle de ting, som ikke er direkte funktionelle, eksempelvis usability, design, sikkerhed og opfyldelse af lovkrav.

Begrundelser kan være informationer opnået gennem interviews eller observationer, og de kan være med til at give læseren en bedre forståelse af, hvorfor kravene er som de er, samt et indblik i de bagvedliggende tanker [Benyon 2014, side 140].

3.3.2 MoSCoW

I vores kravspecifikation for IT-systemet har vi opstillet en række funktionelle og ikke-funktionelle krav. Disse krav har vi prioriteret fra 1 til 4, hvor kravene med en prioritet på 1 er vigtigst og kravene med en prioritet på 4 er mindre vigtige. Dette har vi gjort ved hjælp af MoSCoW metoden. Denne metode opdeler krav i 4 segmenter: Must have, Should have, Could have og Want to have but won’t have this time around [Benyon 2014, side 140].

Her er en prioritet på 1 en Must have, altså at dette krav er fundamentalt for at systemet skal kunne fungere og være brugbart
En prioritet på 2 er en Should have og betyder, at dette krav er relativt essentielt for systemet, men at systemet vil være nyttigt og brugbart uden
En prioritet på 3 er en Could have og betyder, at dette krav er mindre vigtigt for systemet, og det vil typisk være inkluderet, hvis der er tid og ressourcer til det [Agile Business n.d.]. Det er muligt senere hen at implementere de Could have krav, som ikke nåede at komme med i første omgang
Prioritet 4, som er Want to have but won’t have this time around, betyder at disse krav ikke bliver implementeret i denne omgang.

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ære en god ide. De kan blandt andet være med til at styre forventningerne til systemet, samtidig med at det undgås, at disse krav uformelt bliver reintroduceret på et senere tidspunkt indenfor den givne tidsramme [Agile Business n.d.]. Det kan også være med til at overskueliggøre, hvad der bliver implementeret og ikke bliver implementeret i systemet i denne omgang.

3.3.3 Vores kravspecifikationer

Kravspecifikationen for IT-systemet, som er lavet i samarbejde med foreningen, består af 21 funktionelle krav og 10 ikke funktionelle krav. Kravspecifikationen er en kombination af krav, som er udarbejdet med udgangspunkt i vores undersøgelse af foreningen og erfaringer med lignende systemer, samt en række krav som blev stillet af samarbejdspartneren.

De funktionelle krav er fordelt på seks kategorier:

Booking: Denne kategori indeholder seks krav, som omhandler bookingfunktionaliteten
Booking database: Denne kategori indeholder to krav, som omhandler databaser, der skal laves for at bookingsystemet kan fungere
Indmeldelseoglogin: Denne kategori indeholder tre krav, som omhandler indmeldelse i foreningen og oprettelse af log ind
Admin bruger: Denne kategori indeholder to krav, som omhandler administrator funktionaliten
Framtk9000.dk: Denne kategori indeholder syv krav, som omhandler videreførelsen af funktionalitet, som allerede er at finde på foreningens nuværende website, mtk9000.dk
Kosmetisk: Denne kategori indeholder et krav, som omhandler en kosmetisk funktionalitet, som ønskes på forsiden

De ikke funktionelle krav er inddelt i tre kategorier:

Usability: Denne kategori indeholder fire krav, som omhandler brugbarheden af systemet
Sikkerhed: Denne kategori indeholder to krav, der omhandler den ønskede sikkerhed på websitet
Design: Denne kategori indeholder fire krav, som omhandler designet af websitet Udvalgte kravspecifikationer

Gennem vores problem- og PACT analyse har selve bookingprocessen været i fokus. Den nuværende proces er, som tidligere nævnt, tidskrævende og besværlig for medlemmerne. Derudover kan den også skabe problemer for bestyrelsens vision om at udvide antallet af medlemmer, da det nuværende system ikke er at foretrække, hvis der kommer flere medlemmer i foreningen.

Ud fra disse observationer, samt interviewet med bestyrelsesformanden, har vi opstillet nogle krav, som systemet skal underbygge.

Kravspecifikationerne for IT-systemet har ændret sig af flere omgange. Disse ændringer skyldes vores observationer omkring foreningen og systemet, som senere hen er blevet korrigeret. Korrektionenå er lavet på baggrund af løbende afklaringer eller nye informationer, samt interviews med bestyrelsesformanden, som har haft tilføjelser eller ændringer til de krav, som blev udarbejdet på baggrund af det første møde med ham.

Kravspecifikationerne er uddybet i bilag A, hvor de ændringer, der er foretaget løbende ligeledes står beskrevet.

Funktionelle krav

Vi vil ikke gennemgå alle de funktionelle krav, men siden vores fokus primært ligger på selve bookingprocessen, vælger vi at gennemgå nogle af de krav, som vedrører denne.

Prioritering

Summary

Source

Booking af bane: Hvis brugeren er logget ind kan denne trykke på en ledig tid i bookingkalenderen og booke den. Hvis brugeren ikke er logget ind kan denne ikke se kalenderen, men blot information om login.

Dette krav er blevet konstrueret med udgangspunkt i viden, vi har tilegnet ved at læse foreningens hjemmeside. Bekræftet af formand.

Medspillere: Brugeren skal kunne skrive navnet på partneren (eventuel en liste), når banen bliver booket.

Minimum 1 maks 3 medspillere. Spilleren søger efter navn på medspillere, som automatisk bliver tilføjet på en liste.

Dette krav er blevet konstrueret med udgangspunkt i viden, vi har tilegnet ved at læse foreningens hjemmeside. Bekræftet af formanden.

Tabel 3.1: Tabel med udvalgte funktionelle kravspecifikationer.

Kravet 1a beskriver, hvordan det er muligt for et medlem at booke en bane. Kravet er tilrettet ud fra kommentarer fra bestyrelsesformanden, som ikke ønsker, at det skal være muligt for ikke-medlemmer at se kalenderen. Vi har valgt, at kravet har en prioritering 1 – altså et must have – i vores system, da dette især knytter sig til bestyrelsesformandens ønsker.

Kravet 1b beskriver processen efter et medlem har valgt en tid. Her skal medlemmet vælge sine medspillere ud fra en søgefunktion i foreningens nuværende medlemmer. Dette krav er udformet på baggrund af interviewet med bestyrelsesformanden, der vil bibeholde den del af den nuværende bookingproces, hvor medlemmet skal skrive medspilleren på. Dette gør det muligt at kontrollere, hvem banen har været benyttet af. Når medlemmet har udfyldt dette vil navnene fremgå i kalenderen på deres bookede tid. Kravet har en prioritering 1, da det netop har været et ønske fra bestyrelsesformanden at beholde denne del.

Ikke funktionelle krav

Under de ikke funktionelle krav har vi bl.a. valgt at fokusere på designet. Gennem interviewet med bestyrelsesformanden erfarede vi, at foreningen beskriver sig selv som “Livsnydernes klub”, og at de vægter fællesskabet i foreningen højt.

Kravet 9b er derfor sat som en prioritet 2, da designet skal afspejle foreningens image – og derved frembringe det foreningen står for.

Kravet 7a er medtaget i kravspecifikationen, da det har været brugt til at forventningsafstemme systemets benyttelse med bestyrelsesformanden. Selve kravet ligger uden for dette semesters fokus, og det er derfor en prioritet 4.

ID	Prioritering	Summary	Source
9b	2	Design, der matcher foreningens identitet: Designet skal stemme overens med det image foreningen gerne vil fremvise, og understøtte dette	Dette krav er opstillet af projektgruppen, med udgangspunkt i viden tilegnet på 1. semester. Bekræftet af formanden.
7a	4	Responsivt: Websitet skal være responsivt, således at indholdets fremvisning er afhængigt af skærmstørrelsen på det device, som benyttes til at besøge sitet	Dette krav er opstillet af projektgruppen, med udgangspunkt i viden tilegnet på 1. semester

Tabel 3.2: Tabel med udvalgte ikke funktionelle kravspecifikationer.

Kapitel4

Envisionment

I det følgende 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]).

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éer til sketches og wireframes for Midtbyens Tennisklub’s website. Afslutningsvis beskriver vi de sketches og wireframes, som vi har udarbejdet.

4.1 Struktur

4.1.1 Teori

Navigationsmap

Et navigationsmap hjælper med at danne et overblik over, hvordan websitet er opbygget. I navigationsmappet er hver underside på websitet repræsenteret 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ære en fordel at bruge pile, såfremt det hjælper på forståelsen af, hvordan websitet fungerer samt hvordan de enkelte sider hænger sammen [Benyon 2014, side 172]. Et eksempel på et navigationsmap kan ses på figur 4.1.

Da hele designprocessen er iterativ, er det normalt at rette designet af navigationsmappet løbende, hvis der opstår sider, hvor brugeren ikke kan komme videre. Dette kan testes ved at benytte scenarier for at gennemgå websitet, og derved opdage problemer, hvor brugeren f.eks. ikke kan komme videre eller tilbage [Benyon 2014, side 172].

4.1. STRUKTUR

Sekvensmodel

Sekvensmodellen bruges til at vise de forskellige trin, det tager at udføre en handling på f.eks. et website [Benyon 2010, side 282].

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]:

Intentionen bag udførelsen af handlingen. Denne komponent kan findes ud fra et udarbejdet flowdiagram eller et navigationsmap, som giver et større overblik over navigationen på siderne samt deres funktioner
Triggeren, der får brugeren til at udføre sekvensen
Trinene i selve sekvensen, som får brugeren fra intention til udførelse
Problemer, der kan opstå undervejs i sekvensen

Selve modellens sekvens er ikke altid lineær. Hvis der opstår problemer, eller der er flere muligheder for udførelsen, kan modellen indeholde loops eller forgreninger, som viser de forskellige retninger sekvensen kan tage [Benyon 2010, side 284-285].

4.1.2 Navigationsmap og sekvensmodel for systemet

Navigationsmappet for websitet, vi udarbejder for Midtbyens Tennisklub, kommer til at se ud som vist i figur 4.1.

Figur 4.1: Navigationsmap over systemet

4.1. STRUKTUR

Vi har her taget udgangspunkt i deres nuværende hjemmeside, http://mtk9000.dk, hvor vi har taget samme menupunkter med på det nye site (se figur 2.1). Her har vi dog tilføjet endnu et menupunkt i form af log ind. Dette har vi gjort, da brugerne er nødt til at kunne logge ind for at booke en tid på banen. Vi har valgt at omstrukturere rækkefølgen af menupunkterne, da hovedfunktionerne i systemet omhandler booking og administration af medlemmer. Herudover har bestyrelsesformanden også haft input i forhold til, hvilken rækkefølge menupunkterne skal oplistes i [interview med bestyrelsesformanden].

Figur 4.2: Navigationsmap med administratorfunktioner for systemet

Navigationsmappet på figur 4.2 er en uddybning af det, som ses på figur 4.1, da der her er inkorporeret de funktioner, som administratoren vil have på websitet. Administratorfunktionerne er illustreret med sorte bokse, som skiller sig ud fra de resterende. Disse muligheder vil kun være tilgængelige på hjemmesiden, såfremt der er logget ind som administrator. Foruden de funktioner, som er illustreret med sorte bokse, vil administratoren ligeledes være i stand til at ændre og opdatere i tekster på store dele af websitet.

4.2. DESIGNPRINCIPPER

Figur 4.3: Sekvensmodel over bookingfunktion

Det er bookingfunktionen, som er det centrale på 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å banen. Her er intent og trigger næsten det samme; nemlig, at et medlem gerne vil booke en tid på banen.

Herefter er der en række trin, som brugeren skal igennem som kan læses på figur 4.3.

4.2 Designprincipper

Vi har valgt at bruge designprincipperne oplyst i bogen Designing Interactive Systems for at sikre, at vi fra starten af designfasen udviklede nogle designidéer, som var brugervenlige og funktionelle [Benyon 2014, side 86]. Disse designprincipper fungerede som en guideline for vores tidlige designidéer. Samtidigt har vi også brugt designprincipperne til at foretage en lavpraktisk heuristic evaluering løbende i designprocessen. Herved menes at de er brugt i en mere uformel form, hvor det er diskuteret løbende, om de følger designprincipperne. Dette har gjort, at vi har kunne lave en løbende evaluering af systemet uden at skulle investere for meget tid [Benyon 2014, side 217]. En mere formel heuristic evaluering ville kræve en mere

veldokumenteret proces, hvor flere personer individuelt ville evaluere systemet og diskutere det i fællesskab [Nielsen 1993, side 156].

Grunden til at vi har valgt disse designprincipper, og ikke Jakob Nielsen Heuristic’s, er, at bogen er af nyere dato og mere fokuseret på webdesign. Der er tale om i alt 12 designprincipper, som er inddelt i tre hovedgrupper, learnabillity, effectivness og accommodating [Benyon 2014, side 86]. Et eksempel på et designprincip, er princip fire: affordance. Dette princip går ud på at designe efter, at det skal være nemt at fortolke hvad funktionen er. Det kunne eksempelvis være en knap i en menulinje. Her er det vigtigt, at tydeliggøre at det er en knap, og at der kan trykkes på knappen. Dette kan eksempelvis gøres ved, at knappen ændrer farve, når musen placeres over knappen.

De designprincipper vi bl.a. benytter er:

Visibility: Synliggør de forskellige funktioner samt hvad systemet er i gang med
Consistency: Vær konsistent i designet og måden dette fungerer på
Familiarity: Benyt sprog og symboler, som brugerne er bekendte med
Affordance: Design systemet, så det er tydeligt hvad de forskellige funktioner er til
Navigation: Guide brugerne gennem siden, så de nemt kan navigere rundt
Feedback: Informerer brugerne om, hvilken effekt deres handler har haft
Recovery: Muliggør hurtig genopretning af fejl begået på siden
Conviviality: Interaktive systemer skal være høflige og venlige. Brug derfor sprog, informationer, fokus på specifikke funktioner m.m. til at skabe et venligt system til brugeren [Benyon 2014, side 86-88].

Designprincipperne vil løbende blive inddraget i vores analyse af systemet.

4.3 Sketches og wireframes

4.3.1 Teori

Sketches

Sketches er en metode, som kan bruges i begyndelsen af designfasen, hvor idéer og tanker kan visualiseres [Benyon 2014, side 167]. Sketches er et brugbart redskab i designfasen, da idéer og tanker ofte kan fortolkes anderledes end tiltænkt. Her kan designerne af systemet hurtigt visualisere deres tanker og præsentere dem for andre, hvis det er relevant. Metoden hjælper med at visualisere ens idéer 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å en computer. På figur 4.4 ses et eksempel på en sketch, lavet i programmet Balsamiq. Som det ses på 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å en eventuel samarbejdspartner eller kunde kan få en bedre forståelse for kravene, og dermed give mere præcis feedback på om designidéerne opfylder kundens krav [Bruun 2019].

Figur 4.4: Eksempel på sketch

Wireframes

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ære det næste skridt efter at have briefet designidéerne til kunden, og det er mere sikkert, hvilken retning designet skal gå i [Bruun 2019]. Wireframes går mere i dybden med specifikke sider på en hjemmeside, hvor sketches mere danner et overblik. Wireframes fokuserer på de generelle elementer i et design uden at omhandle de endelige detaljer. Det er f.eks. placeringer af forskellige elementer såsom knapper, menulinje og hvad det tekstlige indhold skal være. De er dog ikke så detaljeorienteret i forhold til, hvordan et logo eller ikon præcist skal fremstå [Benyon 2014, side 173].

4.3.2 Sketches for Midtbyens Tennisklub

Vi har valgt at udarbejde sketches, fordi det er en hurtig og nem måde, hvorved vi kan illustrere vores tanker og idéer om systemet for hinanden samt samarbejdspartneren. På den måde kan vi, i fællesskab med vores samarbejdspartner, få designet et system, der dækker deres behov bedst muligt. Derved lægger vi ikke for meget energi i et design, som muligvis bliver forkastet. Vores samarbejdspartner gjorde det klart, inden vi påbegyndte arbejdet med sketchene, at han godt kunne lide den overordnede struktur på deres nuværende website. Strukturen skulle dermed videreføres til det nye website, dog med nogle kosmetiske ændringer. Designproces har båret præg af udsagnene fra bestyrelsesformanden, hvor vi efterfølgende har vendt og visualiseret forskellige forslag til designet. Vi har valgt overvejende at bibeholde det samme design fra deres nuværende site, i udarbejdelsen af sketches til det nye site, som følge af bestyrelsesformandens udtalelser.

Processen fra idéer til endelige sketches, startede på et lavpraktisk stadie, hvor vi i fællesskab diskuterede nogle af siderne, som systemet skulle indeholde. Det var primært de sider, som indeholdte mange detaljer og interaktionsmuligheder, vi diskuterede i fællesskab, før sketchene blev udarbejdet. En af disse sider var blandt andet bookingkalenderen. Her blev flere forskellige versioner tegnet på tavlen med inspiration fra andre bookingsystemer. Ved en gruppediskussion blev designet, som ses på figur 4.7, valgt som det design, der skulle videreføres og tegnes i sketchprogrammet Balsamiq.

Figur 4.5: Udarbejdede sketches på tavlen, af hhv. bookingkalender og indmeldelse side.

Det næste skridt i processen efter udvælgelsen af vores sketches, var at få 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ælge imellem. Sketchene blev udarbejdet med designprincipperne i baghovedet. Vi har blandt andet designet efter, at knapperne skal fremstå tydelige, således at det er åbenlyst, at der en interaktionsmulighed. Derudover har vi fokuseret på et konsistent design. Vi har kontrolleret, at knapper på sketchene har samme design og farver, og at menubaren går igen på alle sider. De udarbejdede sketches blev gennemgået og diskuteret, og vi udvalgte her de endelige sketches, som vi ønskede at præsentere for bestyrelsesformanden. Alle sketchene blev taget med til mødet i tilfældet af, at han ønskede nogle andre løsninger end dem vi foretrak. På figur 4.6 ses et eksempel på en færdig sketch.

Figur 4.6: Sketch af bookingkalender

Administratorfunktionerne er på de sider hvor det er nødvendigt for bestyrelsen at kunne redigere på siden. På disse sider vil der være en form for rediger knap eller funktion, såfremt administratoren er logget ind på sitet. Til de funktioner, som ikke intuitivt hører til på nogle af siderne på sitet, har vi lavet en medlemshåndterings-fane. Under denne er der f.eks. aktivering af brugerlogin, se figur 4.7.

Fravalg af sketches

Efter andet møde med bestyrelsesformanden, hvor vi fremlagde diverse sketches over funktioner for sitet, blev der sorteret nogle sketches fra. Det blev der på baggrund af bestyrelsesformandens ytringer, om hvorvidt han vurderede, om designet var passende eller ej. Udover dette kom vi også med forslag til hvilke sketches, som vi vurderede ville fungere bedst. På den måde fik vi indsnævret det til, at der kun var de sketches tilbage, som både vi og bestyrelsesformanden vurderede ville fungere bedst.

Vi præsenterede eksempelvis bestyrelsesformanden for to forskellige sketches, som viste hver

Figur 4.7: Sketch af administratorfunktionernen rediger (denne sketch blev ikke anvendt)

deres mulige måder at logge ind på. 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øsning ift. at simplificere log ind-funktionen.

Figur 4.8: Forskellige versioner af login-funktionen. Til venstre ses en dropdown-menu, og til højre ses et pop-op vindue

Udover dette blev der bl.a. også præsenteret fire forskellige sketches, som illustrerede forskellige måder for brugerne at afmelde en booket tid. Her havde bestyrelsesformanden en holdning til, at det skulle være sketch 3 (se figur 4.9), der skulle benyttes, da han mente, at det var den mest simple måde for brugerne at afmelde deres tider på.

Figur 4.9: Forskellige designs af afmeldfunktionen.

Afslutningsvis fravalgte vi de pågældende sketches, samtidig med at vi tilrettede kravspecifikation, således at den var ajour med de beslutninger, der blev nået frem til på mødet med bestyrelsesformanden.

4.3.3 Wireframes for Midtbyens Tennisklub

Ud fra de tilbageværende sketches valgte vi at udarbejde wireframes til de mere komplekse sider i systemet for at få et bedre overblik over, hvordan designet præcist skulle se ud.

På figur 4.10 ses et wireframe for startsiden af websitet. Udarbejdelsen af dette hjalp os med at forstå, hvordan de forskellige elementer på siderne skulle fremstå. Designet er skabt på baggrund af bestyrelsesformandens ønske om at bibeholde foreningens nuværende design og opsætning. Ligesom ved sketchene har vi også her taget højde for design principperne i udviklingen af wireframes.

Figur 4.10: Wireframe for startsiden.

På figur 4.11 og 4.12 ses de wireframes for selve kalenderen, samt hvilken besked brugeren får, når denne gerne vil booke en ledig tid.

Figur 4.11: Wireframe for bookingkalenderen.

Figur 4.12: Wireframe for pop-op vindue i bookingkalenderen.

Kapitel5

Physicaldesign

Det følgende afsnit omhandler processen med at få videreført vores mere abstrakte designs i form af sketches og wireframes fra envisionment afsnittet. I envisionment afsnittet var fokus på den overordnede struktur, og hvad de enkelte sider skulle indeholde. I dette afsnit vil vi have mere fokus på detaljerne, og vise hvordan vi kommer frem til vores endelige design. Vi vil analysere os frem til hvordan de enkelte elementer skal stå i forhold til hinanden, og hvordan de enkelte elementer skal designes i forhold til farver og layout. Vi vil først redegøre for teorien og derefter argumentere for vores valg af fysisk design.

5.1 Teori

5.1.1 Ikoner

Ikoner kan bruges til at repræsentere sider eller funktioner i et softwaresystem. Ikoner bliver generelt brugt som et redskab til at hjælpe brugeren med at forstå, hvilke sider eller funktioner, de skal tilgå for at opnå den ønskede handling. Ikoner bliver brugt i et stort omfang på hjemmesider og kan variere meget i design. Der skelnes mellem tre hovedtyper af ikoner: metaforer, direkte billeder og konventioner [Benyon 2014, side 259]. Et metafor ikon kræver at brugeren kan overføre viden fra én sammenhæng til en anden. Det kan eksempelvis være 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å et andet stykke papir [Benyon 2014, side 259].

Et direkte billed ikon betyder, at ikonet er et billede af, hvad den repræsenterer og kræver derfor ingen fortolkning [Benyon 2014, side 259]. Det kan for eksempel være 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ære indstillingsikonet,

5.1. TEORI

som i langt de fleste tilfælde ligner et tandhjul.

5.1.2 Menu

Mange systemer gør 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år menuer skal designes, er det vigtigt at funktionerne er grupperet i menuemner, som er en liste af menuelementer. Det fungerer således, at når brugeren klikker på et menuelement i menubaren, bliver en handling udført. Menuer bliver brugt i et stort omfang på hjemmesider til at strukturere informationer, samt som den centrale metode for navigation på hjemmesiden. Udover selve hovedmenuen bruges der også i mange tilfælde undermenuer. Undermenuer kaldes også for hierarkisk organiserede menuer eller cascading menuer. Dette er brugbart, hvis en hjemmeside har mange informationer, hvor en simpel menubar ikke er nok. Når en person klikker eller kører musemarkøren over et af hovedemnerne i menuen, åbnes der en ny liste af grupperede emner, som er relateret til hovedemnet i menubaren [Benyon 2014, side 261-262].

Chunking

Chunking dækker over processen, hvor der grupperes informationer ind i meningsfulde enheder. Det er en effektiv måde hvorpå brugerens hukommelsesbelastning reduceres. Det kan for eksempel være en undermenu som nævnt tidligere [Benyon 2014, side 273].

Working memory

Når et system skal designes, er det vigtigt at tage højde for brugerens arbejdshukommelse^{^[3]}. Der er uenigheder om hvor mange ting, det forventes at brugeren kan huske. Nyere forskning peger på at kapaciteten af arbejdshukommelsen er tre til fire ting. Cowan argumenterer for at arbejdshukommelsen kan rumme 4 ± 1 elementer [Benyon 2014, side 273][Cowan 2019].

5.1.3 Gestaltlovene

Der findes tre forskellige gestaltlove: perception, similiarity og continuity. Perception giver indblik i måden forskellige objekter kan opfattes. Ved eksempelvis en observation af forskellige grupperede elementer kan disse opfattes som en helhed, men hvis de deles op, så vil de opfattes som forskellige elementer [Benyon 2014, side 271-272].

5.1.4 Farvevalg

I figur 5.1 er der listet forskellige vestlige farvekonventioner, som er en fordel at benytte sig af. Det er dog vigtigt at være opmærksom på, at farverne kan opfattes anderledes i andre kulturer, og det er derfor godt at overveje farvernes betydning i designet.

Figur 5.1: Vestlige farvekonventioner [Benyon 2014, side 277]

5.1.5 Closure

Loven Closure omhandler måden, hvorved information bedst opfattes. Hvis informationerne tilføjes til et lukket objekt, der står i kontrast til baggrunden (f.eks. en aflukket kasse), vil informationerne her blive hurtigere opfattet end hvis de bliver tilføjet til et åbent objekt [Benyon 2014, side 272].

5.2 Analyse

5.2.1 Menubaren

Vores ønske for designet af hjemmesiden til Midtbyens Tennisklub var at holde det så simpelt som overhovedet muligt, og samtidig imødegå foreningens ønske om et design, som minder om det fra deres nuværende side. Derfor har vi videreført menubaren i samme farvenuance, så det er genkendeligt. Formålet med menubaren, som ses i figur 5.2, er at den skal indeholde samtlige sider på hjemmesiden, så brugeren kan tilgå alle informationer fra menubaren. På den måde kan vi sikre en simpel navigation, hvor den eneste måde brugeren kan navigere rundt mellem siderne er ved brug af menubaren, eller pilene til at gå frem og tilbage mellem siderne som ses i venstre hjørne på browseren. Vores hjemmeside har det, der kaldes for et menu-drevet interface, og det skulle gerne resultere i, at brugeren har en nem måde at navigere rundt på siden. Dette er noget vi vil teste i vores endelige usability test, når systemet er klar til dette.

Menubaren går igen på alle siderne, hvilket gør at designet fremstår mere ensartet, og derfor

også mere genkendeligt for brugeren, uanset hvilken side de befinder sig på. Det følger også designprincipperne consistency og visibility [Benyon 2014, side 86], hvilket gerne skulle hjælpe på systemets learnability [Benyon 2014, side 86]. Selvom menubaren består af syv elementer og overskrider Cowan’s argument, at den arbejdende hukommelse maksimalt kan huske 4 ± elementer, er dette ikke et problem, da menubaren går igen på alle sider, og sætter derfor ikke nogle væsentlige krav til brugerens arbejdshukommelse [Benyon 2014, side 273].

Et andet redskab til brugeren i menubaren er, når brugeren klikker ind på en side, vil baggrunden i menubaren blive mørkeorange, og brugeren er derfor ikke i tvivl om, hvor denne befinder sig på hjemmesiden. Ydermere benyttes der også en hover-effekt^{^[4]}, som gør at når brugeren kører musen over et af menuelementerne, vil baggrunden blive orange, og musemarkøren vil ændre sig til en såkaldt pointer (se figur 5.5). Dette tydeliggør interaktionsmuligheden, så det ligner at det er en knap, som brugeren kan trykke på, hvilket også følger designprincippet affordance [Benyon 2014, side 97].

Figur 5.2: Skærmbillede af menubaren fra mbtennis.dk

Som det fremgår 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å hjemmesiden, hvorimod Log ind er en funktion og ikke en navigationsmulighed. Derfor har vi inddelt det i to grupper for at tydeliggøre forskellen for brugeren. Det følger også Gestaltloven Perception, så alle menu elementerne ikke bliver opfattet som én gruppe.

I menubaren har vi brugt to ikoner, det ene er ved siden af Om os og det andet ikon ved siden af Log ind. Log ind symbolet er et konventionelt ikon, som bruges mange steder for at indikere en log ind funktion. Ikonet er samtidigt også et metafor ikon, og kan symbolisere handlingen at gå igennem en åben dør, som har en sammenhæng til det at logge ind. Når brugeren er logget ind, vil der i stedet stå Log ud, og symbolet vil være stort set det samme, på nær at pilen vender ud af og ikke indad, som ses på figur 5.3. Ikonet ved siden af Om os i menubaren er en pil som vender ned. Den er brugt til at indikere, at der er en undermenu. Dette er også 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 familiarity (se afsnit 4.2) [Benyon 2014, side 86]. Vi har valgt dette ikon, da det er let genkendeligt og hjælper brugeren til at forstå, at der er mere information under dette menuelement.

Figur 5.3: Skærmbillede af drop-down menuen fra mbtennis.dk

Måden undermenuen åbnes på er ved brug af en hoverfunktion, som åbner menuen automatisk, når musemarkøren placeres over knappen. Grunden til at vi har gjort brug af en undermenu, eller en cascading menu, er for at holde hovedmenuen så simpel som mulig, og derved undgå at brugeren har for mange elementer at forholde sig til på en gang. Undermenuen følger også princippet chunking, da den nye undermenu, som åbnes er en gruppering af relaterede emner, som alle relaterer sig til menuelementet Om os.

5.2.2 Bookingkalenderen

På undersiden Booking af bane ses bookingkalenderen, som er repræsenteret af en ugentlig kalender, hvor det er muligt at gå frem og tilbage mellem ugerne (se figur 5.4).

Vi har valgt at lave kalenderen i dette genkendelige format, således at brugeren ikke skal sætte sig for meget ind i systemet for at kunne benytte sig af det. Dette følger designprincippet familiarity (se afsnit 4.2).

Figur 5.4: Skærmbillede af bookingkalenderen fra mbtennis.dk

Figur 5.5: Musemarkører: Venstre side er en normal markør.

Højre side er en pointer, hvor det er muligt at trykke på det musemarkøren er over.

Når brugeren skal booke en tid vil denne opleve, at der er en hovereffekt på tiderne i kalenderen (se figur 5.4). Samtidig vil musemarkøren ændre udseende fra en pil til en pointer for at symbolisere, at det nu er muligt at trykke på cellen (se figur 5.5). Denne effekt har vi valgt at benytte os af, da det indikerer, at det er muligt at trykke på selve cellen og derved tydeliggør interaktionsmuligheden for brugeren. Dette følger designprincipperne affordance og visibility (se afsnit 4.2).

Vi har valgt at benytte farverne grøn, rød, grå og blå i bookingkalenderen (se figur 5.4), som følger de vestlige farvekonventitioner.

Grøn: Indikation for at banen er ledig
Rød: Indikation for at banen er optaget
Grå: Indikation for at den pågældende tid er passeret, og derfor ikke kan bookes
Blå: Den reservation, som brugeren har foretaget sig. Den blå farve er valgt, da den står i kontrast til det den røde farve, er neutral og fremstår rolig.

Når brugeren vælger en tid, vedkommende gerne vil booke i kalenderen, vil tiden åbne sig i et pop-op vindue (se figur 5.6). Vi har valgt at inddrage denne funktion, da dette vil holde brugeren fokuseret på de informationer, der bliver vist, samt sørge for de ikke bliver distraheret af andre informationer på websitet. Dette følger samtidig også loven Closure, da vi på et sted samler de informationer, som brugeren skal forholde sig til.

Figur 5.6: Skærmbillede af pop-op vindue i bookingkalender på mbtennis.dk

5.2.3 Knapper

Ved udarbejdelsen af knapperne på siden var det vigtigt at lave et kontinuerligt design, som derved sørger for de forskellige funktioner er genkendelige for brugeren. Designet af de forskellige knapper er derfor gennemgående på samtlige sider på websitet.

På figur 5.6 ses Bekræft booking- og Annuller-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å valget Bekræft booking ved at dele dem op, da de to valg ikke vil blive opfattet som en helhed, hvilket følger gestaltloven perception.

Knapperne har fået farverne grøn og rød, da det ud fra de vestlige farvekonventitioner er de farver, der oftest benyttes til at separere valgene bekræft og annuller. Samtidig er der også her pålagt en hover-effekt, for igen at tydeliggøre interaktionsmuligheden.

På næsten 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å, da det er en rolig og neutral farve, som står i kontrast til farverne grøn og rød. Den blå farve er valgt for at vise, at der ved tryk på knappen vil komme information frem, som administratoren derefter vil skulle tage stilling til. Dette understøttes af designprincippet visibility (se afsnit 4.2).

Når administratoren trykker ind, vil denne blive præsenteret for et pop-op vindue (se figur 5.8), som har et sammenligneligt design med bookingfunktionen (se figur 5.6).

Figur 5.7: Skærmbillede af redigeringsknap på mbtennis.dk

Figur 5.8: Skærmbillede af redigeringsfunktion på mbtennis.dk

Det simple design af knapperne på hele websitet mindsker udfaldet for fejl, da designet af pop-op vinduet og de få muligheder gerne skulle medføre, at brugeren nemmere kan holde fokus på den igangværende opgave. Dette følger bl.a. loven Closure og designprincippet recovery (se afsnit 4.2).

Systemet har generelt et meget gennemgående design, som sørger for at det er nemt at danne sig et overblik, samt navigere gennem siderne. På administratorsiderne har de forskellige funktioner et bestemt og ensformigt design, samt fået tydeliggjort deres funktion i form af beskrivende tekst. Dette er netop gjort for at mindske fejl og misforståelser, når administratoren skal benytte systemet.

Kapitel6

Implementering

I følgende afsnit vil vi forklare om kodeforløbet, gennemgå 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æret den største udfordring. Derudover vil vi også forklare de kodesprog, vi har brugt i udformningen af systemet.

I starten af vores kodeproces benyttede vi hosting servicen 5gbfree.com [5GBfree n.d.], men den havde nogle begrænsninger, som gjorde at vi skiftede hosting service. Derfor valgte vi i stedet at købe hosting service hos unoeuro.com [UnoEuro n.d.], som ikke havde samme begrænsninger, understøttede vores arbejde med MySQL bedre og tager samtidig dagligt backup af filerne. Vi har forsøgt at sikre versionskontrol ved løbende at uploade vores kode til GitHub [Inc. n.d.], for at sikre vi havde en version af systemet, der virkede, i tilfælde af at der skulle gå noget galt.

6.1 Sprog

Vi har brugt følgende kodesprog i vores projekt: HTML, CSS, PHP og JavaScript samt databasesystemet MySQL.

HTML

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år blandt andet af forskellige tags (også kaldet elementer) til at danne en struktur på en hjemmeside. Disse elementer kan være tags såsom <h1>, som vil medføre at den efterfølgende skrift bliver en stor overskrift indtil tagget </h1> skrives, og dermed bestemmer, hvor overskriften slutter. Foruden tekst er, der ved brugen af HTML, blandt andet mulighed for at indsætte billeder,

6.1. SPROG

lave forms^{^[5]}og indsætte knapper, samt lave referencer, der linker til andre sider på internettet.

CSS

CSS eller Cascading Style Sheets er et client-side^{^[6]}sprog, der kan ændre på det visuelle design af hjemmesider [Nixon 2014, side 423]. Med CSS kan der målrettes styles til elementer i HTML-koden gennem en selector. En selector kunne f.eks. være h1, p, body, et selvvalgt id^{^[7]}eller class^{^[8]}. Efter at have valgt en selector^{^[9]}på sin hjemmeside skal der tilføjes en attribut til ændring, eksempelvis color, size, margin, padding osv. Afslutningsvis sættes en værdi på den attribut, der skal ændres. Ved size kan der vælges px eller em og ved color kan der eksempelvis vælges green eller blue. Et eksempel på et stykke CSS kode kunne dermed være: “h1 color: red;”

PHP

PHP står for PHP Hypertext Preprocessor og er et serverside^{^[10]}scriptsprog [Nixon 2014, side

45]. PHP kan lave en statisk hjemmeside dynamisk. En dynamisk hjemmeside er en, der laver en HTML fil baseret på data fra en database og/eller PHP funktioner.

En vigtig del af PHP sproget er variabler, som er en “beholder”, der indeholder informationer, som f.eks et array^{^[11]}eller string. Et eksempel på en variabel kunne være $tennisspillere. Denne variabel kunne være en array, der indeholder alle navnene på 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å en bestemt knap på hjemmesiden, så køres scriptet i funktionen.

MySQL

MySQL (SQL er en forkortelse af Structured Query Language) [Nixon 2014, side 171] er et databasesystem, og er det databasesystem vi har benyttet på det website, vi har udviklet. En MySQL database kan bestå af adskillige tabeller, som hver især består af rækker og kolonner, som indeholder data [Nixon 2014, side 172].

6.1. SPROG

Der kan primært interageres med MySQL gennem tre veje: kommandoprompt, et interface på en hjemmeside (såsom phpMyAdmin^{^[12]}) eller gennem et sprog såsom 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.

JavaScript

JavaScript er et scripting sprog, der udelukkende kører i webbrowseren [Nixon 2014, side 324]. Sproget minder meget om PHP, men den primære forskel er at PHP kører på server-side og

JavaScript kører på client-side. JavaScript kan bruges til en række ting, men vi har primært benyttet det til at ændre HTML og CSS kode.

Vi har blandt andet benyttet JavaScript til at lave en slags pop-up vindue kaldet en modal. Denne modal har vi brugt i flere henseender, blandt andet til administratorfunktionerne, galleriet, samt bookingkalenderen. Modalen i kalenderen ser ud som vist på figur 6.1.

Figur 6.1: Modalen, som den ser ud på bookingsiden

Denne modal bliver åbnet, når der trykkes på en ledig tid i kalenderen. Her er det JavaScript der sørger for at modalen bliver vist. Hvordan dette præcist sker vil blive beskrevet yderligere i afsnit 6.4.

6.2. DATABASE

6.2 Database

Det databasesystem vi har benyttet på mbtennis.dk er MySQL og er håndteret gennem PHPMyAdmin. Databasen består af otte forskellige tabeller (se figur 6.2), som hver især indeholder data, der bliver benyttet på websitet. De to mest benyttede tabeller er medlemmer og booking. Disse databaser er essentielle for henholdsvis at kunne logge ind på siden, samt foretage reservationer af tennisbanen.

Figur 6.2: Oversigt over de tabeller databasen indeholder

Tabellen medlemmer (se figur 6.3) indeholder data for alle de indmeldte medlemmer i klubben, såsom deres kontaktoplysninger, log ind og om betalingen for medlemskab er registreret eller ej.

Figur 6.3: På figuren ses de informationer, som er lagret i tabellen medlemmer

Strukturen for tabellen medlemmer kan ses på figur 6.4 og sætter de begrænsninger, som afgør, hvad der kan indsættes af data i de forskellige kolonner i tabellen. Ikonet af den lille nøgle ved siden af navnet ID er en indikation for, at ID’et er en primary key for tabellen, hvilket vil sige, at der i den kolonne skal være forskellige værdier for hvert medlem. Datatypen for ID er sat til at være int(11), hvilket betyder at dataen udelukkende er tal og kan indeholde op til 11 cifre. Nulværdien er sat til Nej, som medfører, at kolonnen ikke kan være tom. Ydermere

6.2. DATABASE

har ID’et et ekstra element, AUTO_INCREMENT, som gør at værdien automatisk bliver udfyldt og sat til det næste endnu ikke benyttede tal i rækken.

Datatypen varchar( ) betyder, at dataen i kolonnen kan være af varierende karakterer i form af eksempelvis tal, bogstaver eller tegn såsom @. Tegnsættet latin1_danish_ci betyder, at tegnene kan være danske, og at der ikke er forskel på store og små bogstaver.

Figur 6.4: Strukturen for tabellen medlemmer i databasen

6.2.1 Oprettelse af forbindelse til databasen

For at oprette forbindelse til databasen linkes der på næsten alle sider af websitet til PHP-filen connection.php, hvori der oprettes en variabel, som efterfølgende bruges i forbindelse med at hente eller sende data til en eller flere tabeller i databasen (se figur 6.5).

Figur 6.5: Koden, som filen connection.php indeholder

I variablen $connection på linje 3 lagres funktionen mysqli_connect( ), hvor der i parentesen indsættes de informationer, som skal bruges til at oprette forbindelse til databasen. På figur 6.5 er der af sikkerhedsmæssige årsager udskiftet de korrekte informationer med placeholdere,

6.3. PRINCIPPET BAG BOOKING SYSTEMET

som informerer om, hvad der skal stå mellem de respektive apostroffer. Kan der ikke oprettes forbindelse til databasen vil fejlmeddelelsen ”cannot connect to database” blive skrevet på hjemmesiden.

6.3 Princippet bag booking systemet

Vi vil i dette afsnit gennemgå den tankegang, der ligger til grund for vores måde at konstruere bookingsystemet på. Overordnet set har tankegangen været, at bookinger skulle være relationer mellem to set (mængder^{^[13]}) bestående af mulige datoer og mulige tidspunkter [Rosen 2019, side 116]. Dette er illustreret i figur 6.6.

Figur 6.6: Set med datoer og set med tidspunkter

Til venstre på figur 6.6 ses settet med de mulige datoer brugeren kan booke, og dette set forsætter i princippet uendeligt. Til højre ses settet med de mulige tidspunkter på dagen, hvor banen kan bookes. Dette set går 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å pil viser relationen.

Figur 6.7: De to set med en relation mellem dem

6.3. PRINCIPPET BAG BOOKING SYSTEMET

Denne relation vil blive lagret i databasen og på selve bookingkalenderen, vil den nu fremstå som optaget. Alle bookinger vil således kunne blive repræsenteret som en række pile – ligesom den blå. Der vil f.eks. sagtens kunne komme flere pile ud fra datoen 2019-05-10, som derved henviser til forskellige tider på dagen.

Vi har også 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å 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

Figur 6.8: Relationernes navne

være 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’s medlemsid er 12, og Niels Nielsen’s medlemsid er 25, vil relationen derfor se ud som i højre side af figur 6.8.

For at få et unikt id på hver booking samles datoen og tidspunktet på reservationen i et enkelt felt. Herefter er reservationen klar til at blive brugt, og dataen indsættes derfor i databasen (se figur 6.9).

Figur 6.9: Bookinginformation, der indsættes i databasen

Som det fremgår af figur 6.9 samles datoen og tidspunktet og sættes herefter ind i database tabellen, som ses på nederste række. Dette ses i kolonnen date_time, som indeholder værdien “2019-05-10.8”, som er den sammensatte dato og tid. Herudover inkluderes de forskellige personer, der gerne vil spille på banen, altså spiller1 var medlem nr. 12 (Jens Jensen) og spiller2 var medlem nr. 25 (Niels Nielsen).

6.4 Bookingkalenderen

Bookingfunktionen er det centrale i vores system. Vores primære motivation for at påbegynde samarbejdet med netop Midtbyens Tennisklub var erfaringer med den ikke-optimale bookingprocess i klubben. Det er dette problem, som vi forsøger at løse i dette afsnit. Billeder af den færdige kalender kan ses på figur 6.10 og 6.11

Figur 6.10: Kalenderen, som den ser ud når brugeren er logget ind på siden

Figur 6.11: Denne modal åbnes, når der klikkes på en grøn celle i kalenderen

Håndtering af dato og tider

Det første skridt for at programmere bookingfunktionen var at oprette datovariabler, hvilket gjorde det muligt for os at lave en “uendelig”kalender. Koden henter datoerne ved hjælp af en indbygget PHP-funktion, DateTime.

Figur 6.12: Kode til oprettelse af datovariabler benyttet i kalenderen (booking-af-bane.php)

Først oprettes en variabel med den nuværende dato og tid, $dt (linje 266 på figur 6.12). Herefter kontrolleres det, om der er kørt en funktion, som gør, at der vises en anden tid end den nuværende (linje 267-268). Hvis dette ikke er tilfældet skal den blot indeholde det nuværende år og ugenummer (linje 269-270).

Herefter indsættes år, ugenummer, måned og dag ind i variabler, så de kan benyttes senere i koden (linje 272-275).

Koden i figur 6.12 benyttes til at konstruere navigationen i kalenderen, så det er muligt at ændre ugerne ved hjælp af to knapper til at gå en uge frem eller en uge tilbage. På figur

6.13 kan koden for tableheaderen^{^[14]}ses, hvori navigationsknapperne er placeret.

Figur 6.13: Kode, som opretter navigationsknapper i kalenderen. Når der eksempelvis klikkes på

Næste uge vil der blive lagt 1 til variablen $week, og variablens nye værdi gør, at den næste uge vises i kalenderen (booking-af-bane.php)

Det væsentligste i koden på figur 6.13 er knapperne Forrige uge og Næste uge. Når der klikkes på en af disse, ændres der på tidsvariablen, $dt, og der skiftes enten en uge frem eller en uge tilbage i kalenderen. I kodestykket er der en restriktion gennem et if else statement^{^[15]}(linje 371-372), som gør at knappen Forrige Uge ikke er tilgængelig, hvis kalenderen viser indeværende uge. Dette er for brugerne ikke skal kunne gå tilbage i kalenderen og booke en tid der ligger i fortiden (denne restriktion er dog ikke at finde på administrator versionen af siden).

Herefter indsættes ugedage og datoer ind i de øverste felter i kalenderen i rækken under tableheaderen, hvor forrige- og næste uge-knapperne (figur 6.15).

Figur 6.14: I koden startes et do while loop, som oversætter dagene fra engelsk til dansk, og gemmer de nye navne i variablen $ugedagdansk (booking-af-bane.php) (koden slutter på figur 6.15)

[…]

Figur 6.15: Her sluttes do while loopet (booking-af-bane.php) (koden starter på figur 6.14)

I et do while loop^{^[16]}hentes først ugedagene, hvor vi derefter oversætter dagen til dansk gennem et switch statement (se figur 6.14 og 6.15). Herefter laver vi felter med ugedagen og datoen, og derefter indsættes de felt for felt i kalenderen, indtil vi kommer ind i en ny uge, dvs. at loopet kører imens $week == $dt->format(‘W’));, og stopper derved, når variablen $week skifter værdi til en ny uge (linje 411-413).

Udfyldning af felter til booking

For at udfylde resten af bookingkalenderen benytter vi os bl.a. af følgende kode, som udfylder de resterende celler med informationer. Koden til at gøre dette er lang, så vi har inddelt den i mindre sektioner bestående af figur 6.16 til figur 6.18

Figur 6.16: Variabler til tidsintervaller, der kan bookes tider i (booking-af-bane.php)

Først og fremmest oprettes en række variabler, som skal bruges, dels til dette afsnit, og dels til de tilhørende JavaScript kodestykker (disse ses blandt andet i figur 6.21). $x og $y viser de tidspunkter på dagen, som brugeren kan booke, og den første mulige tid er fra kl. 6:00 til klokken 7:00. Variablen $antaltimer viser antallet af ledige tider, og variablen $antalbookinger viser antallet af bookinger.

Herefter startes et while loop^{^[17]}med de forskellige tidspunkter på dagen, som kan bookes. Altså fra kl. 6 til kl. 23 ($i = 6 til og med $i = 22). Dette loop angiver antallet af rækker i kalenderen, og tidsintervallet indsættes i den første kolonne.

Figur 6.17: I et do while loop er der indsat et if elseif statement, som bestemmer, hvilken class de enkelte tider i kalenderen skal tildeles (booking-af-bane.php)

I while loopet indsættes et do while loop (se figur 6.17), som udfylder de enkelte celler i kalenderen for det pågældende tidsinterval. Først tildeles hvert felt (<td>^{^[18]}) et unikt id baseret på dato og tidspunkt. Formatet for id’et lyder således: år-måned-dag.tidspunkt, eksempelvis id=2019-05-16.8 (se linje 432). Dette id er efterfølgende den data, som bl.a. indsættes i databasen, når der foretages en booking i kalenderen.

Udover et unikt id tildeles hver celle en class baseret på bookingstatusen:

Hvis tiden er ledig får cellen classen timer (linje 450-451)
Hvis tiden er booket får den classen redtimer (linje 435-441)
Hvis tiden er tidligere end det nuværende tidspunkt og dato, får den classen graytimer (linje 454-455).

Dette ses på if elseif kodestykkerne, som kontrollerer cellerne en efter en.

Der er herefter et JavaScript kodestykke, der sørger for, hvad der kan bookes, og ikke kan bookes baseret på cellens tildelte class (se figur 6.21 og 6.24).

I det første if kodestykke kontrolleres det om det unikke id for cellen findes i variablen $minekampe, som er et array med de kampe, som er reserveret for den pågældende bruger. I figur 6.18, ses det hvordan dette array oprettes.

Figur 6.18: $currentuser er det brugerid, der er logget ind nu. Date_time er i samme format, som de unikke id’er felterne har, og her vælges alle de reservationer af banen, hvor den indloggede bruger er enten spiller1, spiller2, spiller3 eller spiller4. Herefter indsætter vi de unikke celle id’er, som er reserveret til brugeren i arrayet $minekampe. (booking-af-bane.php)

Hvis cellens id findes i arrayet $minekampe, så skal den farves blå og have classen redtimer, og $antalbookinger bliver herefter adderet med 1 (se linje 435-437 på figur 6.17). $antalbookinger bruges til at lave en ny funktion for hver tid, der er reserveret.

Hvis cellens id ikke er i $minekampe kontrolleres det om id’et er i arrayet $dage, som er bygget op i samme princip som $minekampe, men arrayet indeholder derimod alle de bookinger, som er foretaget. Findes id’et i $dage tildeles cellen classen redtimer, samt farven rød, som indikerer at tiden er reserveret af andre brugere.

Findes id’et heller ikke i arrayet $dage, kontrolleres det om den pågældende tid er fremtidig eller dags/tidligere dato. Er tiden fremtidigt tildeles cellen classen timer, som gør at cellen bliver grønt og kan reserveres af brugeren.

Er tiden dags dato og det ikke er tidligere end det nuværende tidspunkt på dagen, bliver cellen også tildelt classen timer.

Hvis ingen af de ovenstående kriterier er opfyldt, tildeles classen graytimer, hvilket gør at cellen bliver grå, og det vil ikke være muligt at interagere med den pågældende celle.

Efter at have kontrolleret en celle lukkes den (se linje 459 på figur 6.17), og hele loopet går videre til samme tidsrum den efterfølgende dag indtil tidsrummet, eksempelvis 8:00-9:00, er udfyldt på alle ugens dage.

Do while loopet er nu færdigt, men der er stadig en del af det yderste while loop, som kører for alle timerne. Dette loop slutter lige efter do while loopet med kodestykket i figur 6.19.

Figur 6.19: Med dette kodestykke slutter det yderste while loop. Her adderes en værdi til variablerne $x, $y og $i, alt imens der subtraheres 7 fra variablen $dt (booking-af-bane.php)

Her lukkes rækken og variablerne $x, $y og $i bliver adderet med 1. $x og $y var tidsrummet der startede fra 06:00 til 07:00, og bliver adderet med 1, fordi næste tidsinterval er 07:00 til 08:00. $i er timetallet, der starter fra 6 og bliver adderet med 1, fordi næste timetal er 7. Herefter sættes $dt2->modify(‘-7 day’); for at der startes med den rigtige dato for det næste tidsinterval. Koden udfylder først det samme klokkeslæt for alle ugens dage og går derefter videre til det næste klokkeslæt.

Når der trykkes på en farvet celle i kalenderen, åbnes der et interaktivt vindue, og alt efter om den pågældende tid er reserveret eller ej, står der forskellige informationer i vinduet. Er tiden reserveret, oplistes navnene på 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.

Hvad der vises i dette vindue bliver styret af JavaScript og afhænger af, hvilken class cellen har. Altså om classen er redtimer eller timer.

Figur 6.20: JavaScript kode, der henter elementerne fra HTML koden (booking-af-bane.php)

JavaScript delen starter med at hente de forskellige elementer ind i scriptet gennem kodestykkerne document.getElementBy- Id/ClassName, som kan ses i figur 6.20.

Figur 6.21: Kodestykke til fremvisning af modalen til bookingkalenderen, når der klikkes på en grøn celle (booking-af-bane.php)

Herefter laves en funktion per celle med classen timer (figur 6.21). Her tilføjes en onclick function til at vise modalen og vælg medspiller-delen, når der trykkes på en grøn celle i kalenderen. Dernæst hentes id’et fra de enkelte grønne celler og indsættes i variablen text$i (hvor $i er et tal fra nul til antallet af felter med classen timer). Herefter splitters id’et op ved punktummet, således at der er en liste bestående af to elementer, en med dato og en med tidspunkt. Datoen og tidspunktet indsættes i overskriften i modalen, f.eks. 2019-05-05 kl. 8:00 (linje 493 på figur 6.21). Ovenfor denne dato og tidspunkt indsættes navnet på den pågældende bruger i teksten (linje 495 på figur 6.21) så den endelige besked bliver:

Hej [fornavn]!

Din booking af banen kommer til at hedde:

[dato] kl. [tidspunkt[.

Figur 6.22: Kodestykke i modalen til at vælge medspillere (booking-af-bane.php)

Dernæst får brugeren mulighed for at vælge medspiller(e), jf. linje 494 til 516 på figur 6.22. Inden dette er der foretaget en SQL query^{^[19]}, der henter alle medlemmer i foreningen (undtagen administrator og indloggede bruger) ind i arrayene $medlemid2, $medlemfornavn2 og $medlemefternavn2. Alle fornavne og efternavne bliver herefter vist i en drop-down menu, så brugeren kan vælge medspillere. Id’et på medspiller(e) bliver brugt i databasen, således at den pågældende tid også bliver reserveret til medspillere(n).

Figur 6.23: Skjulte inputs med datoen, tidspunktet samt id’et på den bruger, der er logget ind (booking-af-bane.php)

Til sidst i formen er der skjulte inputs med datoen og tiden (det unikke id for cellen), samt id’et på den bruger, der er logget ind (figur 6.23). Når der klikkes på knappen Bekræft booking starter en PHP-fil, som indsætter dataene fra modalen i en database, således at bookingen er reserveret (et lignende eksempel på dette kan ses i afsnit 6.7).

Figur 6.24: PHP til at generere JavaScript funktioner til reserverede tider (booking-af-bane.php)

Herefter bliver der lavet en ny JavaScript-funktion (linje 624 til 639) til de røde og blå celler i kalenderen. Dette gøres ligesom ved de grønne celler, bortset fra at der her bliver vist, hvem der har reserveret tiden.

Afmeld tid

Figur 6.25: Koden til at vise brugerens reservationer samt muligheden for at afmelde reservationer

(booking-af-bane.php)

Til højre for kalenderen ses afmeldfunktionen, hvor brugeren kan se og afmelde sine tider. $minereservationer 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ældet bliver de vist for brugeren sammen med en knap, som gør det muligt at afmelde den valgte tid (linje 686 til 702).

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øre dette hentes datoerne ned i variablen

$temptid i loopet på linje 687. Herefter opdeles de, hvor der er bindestreg (linje 688) for at få år, måned og dato fordelt. Derefter indsættes datoen i formatet dag/måned for bookingen

(linje 691).

Trykkes der på knappen Afmeld tid starter PHP-filen, som ses i figur 6.26:

Her hentes datoen og tiden, som brugeren gerne vil afmelde ind i variablen $date_time. Herefter kører SQL querien, som sletter rækken fra databasen booking, hvor datoen og tiden er magen til den, som brugeren gerne vil afmelde (linje 6). På linje 10 henviser filen brugeren tilbage til samme side som før, booking-af-bane.php.

6.5 Log-ind

Der er flere grunde til, at vi valgte at lave et log ind system. Den første og vigtigste grund er, at det kun er betalende medlemmer, der skal kunne booke en tid på banen. Dernæst skulle systemet også have nogle administratorfunktioner, så bestyrelsen kunne opdatere informationer på hjemmesiden, og her var det også oplagt at benytte sig af log ind systemet.

Måden hvorpå en bruger får et log ind er, at denne giver sine oplysninger i indmeldelsesformularen, når 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ørst aktiveret, når kassereren i foreningen har kontrolleret, at der er blevet betalt for medlemskabet, hvorefter det kan benyttes af brugeren.

Log-ind funktionen optræder to steder på websitet; under Booking af bane og i menubaren (se figur 6.27).

Grunden til at vi oprindeligt valgte at placere log ind funktionen i menubaren var, at både booking- og gallerifunktionen kun skulle kunne tilgås, hvis der var logget ind. Det gav derfor mere mening at have en universal log ind funktion på siden, der gav adgang til alle hjemmesidens log ind påkrævede sider, i stedet for at have en log ind formular til de enkelte sider. Derudover gav bestyrelsesformanden gennem interviewet også udtryk for, at han gerne ville have et drop-down log-ind, samt at den kan tilgås fra alle sider på websitet.

Figur 6.27: Placering af log ind forms

Log ind funktionen bruger dataene fra database-tabellen medlemmer, som indeholder de data brugeren indtastede i indmeldelsesformularen. Log ind scriptet starter med at indsætte de informationer brugeren har indtastet i log ind formularen i variablerne $brugernavn og $kode (se linje 7-8 på figur 6.28). Dernæst kontrolleres det om de indtastede oplysninger i log ind formularen har et resultat i databasen. Dette gøres ved at query databasen og kontrollere, at $brugernavn svarer til en e-mail i databasen, og at $kode svarer til koden i samme række, som $brugernavnet står i. Derudover skal deres betalt status også være = 1, ellers vil log ind fejle (se figur 6.28).

Figur 6.28: Kodestykke til at validere log ind (login-validation.php)

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øve at logge ind igen. Er der derimod et resultat i databasen, vil brugeren blive logget ind, og en session vil blive startet (se figur 6.29).

Figur 6.29: Kode som opretter session start (login-validation.php)

Der er to essentielle ting session gør på sitet.

Den gemmer en session^{^[20]}variabel, når der logges ind. Denne variabel gør at brugeren på hver side ikke behøver at logge ind på ny. Derudover fordi session variablen er sat til at være email’, giver denne også 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.
Den sætter en session timer, som logger brugeren ud 30 minutter efter deres sidste interaktion med siden. Brugeren er dermed ikke logget ind på ubestemt tid.

På figur 6.30 ses et eksempel på et kodestykke fra en side, hvor brugeren skal være logget ind for at loade siden.

Figur 6.30: Session på de enkelte sider

Vi har valgt at benytte en session, da den muliggør log ind funktionen på alle sider, uden hver enkelt side skal have sin egen log ind formular. I stedet kan der i koden, efter systemet har gemt session variablen og brugeren er logget ind, “bare”stå session start i toppen af de dokumenter, der ellers skulle have en separat formular. Dette var især nyttigt til administratorfunktionerne, hvor log ind er nødvendigt på alle sider.

Er der en log ind funktion, skal systemet også have en log ud funktion (se figur 6.31).

Figur 6.31: Log ud funktion (logout.php)

Når brugeren klikker på log ud knappen bliver variablen $sti (nuværende url) videreført til variablen $url. Herefter vil scriptet køre og den igangværende session vil blive afsluttet. Brugeren vil herefter blive sendt til enten den samme side, som de er på, eller hvis siden kræver log ind, vil de blive præsenteret for en log ind form.

6.6 Ændring af tekst og billeder

Når et bestyrelsesmedlem er logget ind som administrator, vil denne få adgang til flere funktioner end en almen bruger. Dette indebærer blandt andet muligheden for redigering af tekster og billeder på websitet, samt medlemshåndtering. Vi vil i dette afsnit beskrive de mest væsentligste administratorfunktioner.

6.6.1 Redigering af tekst

Administratorfunktionen til at redigere tekst ser ud som venstre del af figur 6.32.

Figur 6.32: Rediger tekst knap, samt modalen som knappen åbner

Når administrator trykker på rediger tekst knappen åbner der en modal, som vist i højre side af figur 6.32. I denne modal har administratoren mulighed for at ændre overskriften og teksten.

Koden til denne modal, der kan redigere teksten, ser ud som vist på figur 6.33.

På figur 6.33 ses det at koden starter med at åbne modalen (koden til oprettelse af modeln kan ses i figur 6.21). Det væsentlige i denne kode er, at der åbnes to felter, som administratoren kan skrive i: input med overskriften og textarea til teksten (linje 132 og 135). Her har vi inden hentet overskriften samt teksten ned fra databasen og gemt det i arrayet $row. Denne data fra $row indsættes i egenskaben value for input og textarea. Denne egenskabs funktion er at vise tekst i feltet inden administratoren skriver noget. Havde vi ikke haft dette, ville felterne på højre side af figur 6.32 være tomme. Hvis administratoren trykker Gem ændringer bliver disse values sendt til databasen og erstatter de værdier, som var der i forvejen. Dette sørger for, at det nu er de nye værdier, der bliver hentet fra databasen, når siden tilgås, som lige er blevet redigeret.

6.6.2 Redigering af billeder

Måden, som administratoren redigerer billeder på, er ved at logge ind som administrator og føre musemarkøren over det billede, som administratoren gerne vil ændre. Herefter kommer der en mulighed for at vælge fil samt uploade den valgte fil. Dette vil erstatte det billede, der var der før, som er vist i figur 6.34, hvor venstre side viser det nuværende billede, og højre side viser valgmulighederne, når musemarkøren holdes over billedet.

Figur 6.34: Redigering af billede på mbtennis.dk

Koden til at ændre billeder ses på figur 6.35.

Classen preview1 (se figur 6.36) indeholder billedet og bliver først hentet med et SQL query, for derefter at blive indsat i classen. Det er derfor denne class, der bliver ændret, når der uploades et nyt billede. Når der trykkes upload billede køres scriptet, som ses under form action= på linje 86 på figur 6.35. Dette script kontrollerer om den valgte fil overholder en række krav, som eksempelvis størrelse og filtype. Hvis den valgte fil overholder kravene, bliver den uploadet og erstatter det gamle billede.

6.7 Medlemshåndtering

På websitet er der på alle sider (med undtagelse af siderne Galleri og Kontakt) tilknyttet administratorsider, hvor det er muligt for foreningens bestyrelse at opdatere og vedligeholde hjemmesiden. Undersiden Medlemsoversigt (se figur 6.37) fra drop-down menuen Medlemshåndtering vil her blive beskrevet.

Figur 6.37: Medlemsoversigt, som kun kan tilgås af administrator

Figur 6.38: Kodestykke til at hente data fra databasen til medlemsoversigten (admin-medlemmer.php)

På tredje linje i figur 6.38, hentes filen connection.php, hvori der oprettes forbindelse til databasen.

Herefter anmodes der med PHP om at hente alle dataene i tabellen medlemmer, dog med undtagelse af rækken, hvori ID = 22 (nr. 22 er administratorkontoen) og dataen sorteres efter fornavn (se linje 7). Lykkedes anmodningen gemmes de hentede data i variablen $results, ellers skrives der en fejlmeddelelse på hjemmesiden.

Herefter kontrolleres det om siden bliver tilgået uden at være logget ind på en administratorkonto, og hvis dette er tilfældet, bliver brugeren omdirigeret til forsiden af mbtennis.dk, hvilket fremgår af PHP koden på linje 14 og 15 på figur 6.38.

Figur 6.39: Kodestykke medlemsoversigt tabellen (admin-medlemmer.php)

Der oprettes på siden en tabel med ni kolonner. Disse kolonner udfyldes efterfølgende række for række af et while loop (se linje 49 – 76 på figur 6.39), som indsætter de data, der blev hentet i figur 6.38. Her hentes der et associative array i form af rækker ved at kalde variablen $results, som gemmes i en ny variabel, $row. Variablen $row benyttes herefter til at indsætte dataene om de enkelte medlemmer, som tidligere nævnt er lagret i tabellen medlemmer i den tilknyttede database, i den oprettede tabel på siden. For at indsætte dataene skrives der eksempelvis: echo «td>”.$row[’fornavn’].«br>”.$row[’efternavn’].«/td>”; (linje 51 på figur

6.39). Det første i koden, echo, bruges for at fortælle, at der i stykket for PHP koden gerne vil benyttes HTML. <td> og </td> taggene fortæller, hvad der skal stå i den celle i tabellen, og tagget <br> starter en ny linje. For at indsætte informationen fra databasen kaldes den variabel vi oprettede arrayet i, samt navnet på den kolonne vi gerne vil hente data fra, hvilket ser ud som følger: .$row[’fornavn’].. Samme fremgangsmåde bliver gentaget for hele tabellen indtil alt det ønskede data er indsat i tabellen.

Den egentlige administratorfunktionalitet på siden kommer i form af de knapper, der er i forlængelse 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ågældende medlem har fået udleveret en nøgle til banen. Den første knap (se linje 60-63 på figur 6.39) er til udlevering af nøgle. Når der klikkes på knappen aktiveres filen noegle.php og id’et på det pågældende medlem postes, så det kan benyttes af den nu åbne fil (se figur 6.40).

Figur 6.40: Kodestykke til registrering af nøgleudlevering (noegle.php)

I et if statement benytter filen noegle.php det medlems-id, der tidligere blev postet af knappen, og id’et gemmes som variablen $ID. Derefter oprettes der endnu en variabel, $query (se linje 6 på figur 6.40), der bestemmer at tabellen medlemmer skal opdateres, og at der skal stå 1 i kolonnen noegle i den række, hvor ID’et er tilsvarende til det, som er gemt i variablen $ID. I linje 8 på figur 6.40 interageres der med databasen ved først at kalde variablen $connection

(denne variabel hentes fra filen “connection.php”), som opretter forbindelse til databasen, og derefter kaldes variablen $query, der fortæller, hvad der skal gøres i databasen. Lykkedes det at opdatere tabellen i databasen, bliver administratoren vist siden de er på, Medlemsoversigt,

6.8. FRA IMPLEMENTERING TIL USABILITY

men lykkedes det ikke, skrives der en fejlmeddelelse.

Knappen Slet medlem fungerer næsten på samme måde, som knappen til udlevering af nøgle. Der er dog den forskel, at i stedet for at opdatere informationen på et medlem bliver medlemmet slette fra databasen, og det pågældende medlem kan derfor ikke længere benytte sig af mbtennis.dk.

6.8 Fra implementering til usability

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ælp af usability tests, både for administratorsiden og for medlemssiden af sitet.

Kapitel7

Evaluering

I det følgende afsnit vil vi give en detaljeret beskrivelse vores usability test, samt hvad der danner rammerne om denne. Først vil vi beskrive, hvad vi ønsker at få ud af testen samt metoderne bag den. Dernæst vil vi beskrive hvordan testen rent praktisk forløber, samt de forskellige roller undervejs i testen. Herefter vil vi komme ind på, hvad succeskriterierne for systemet er, samt en beskrivelse af vores testopgaver. Afslutningsvis vil vi gennemgå de data, vi har indsamlet fra usability testene, samt hvordan vi har behandlet og hvad vi har udledt ud fra dataene.

7.1 Testplanlægning

7.1.1 Formålet med testen

Formålet med vores usability test er, at teste brugbarheden af sitets funktionaliteter for hhv. medlemmer af foreningen samt for administratorerne på foreningens website. Dette gøres med en række forskellige scenarier. Der er otte scenarier, som administratorerne bliver præsenteret for og seks scenarier, som medlemmerne bliver præsenteret for. Ved hjælp af databehandlingen af vores usability tests vil vi danne os et indtryk af, hvorvidt hjemmesiden stemmer overens med de kravspecifikationer, som vi i fællesskab med bestyrelsesformanden har udarbejdet i løbet af projektet.

7.1.2 Metodeafsnit

I vores usability tests vil vi hovedsageligt teste de tre usability attributter learnability, errors og satisfaction.

Den vigtigste attribut for os at teste er learnability, da den kan give en indikation om, hvorvidt det er let eller svært for en bruger at blive kompatibel med systemet. Dette kan bl.a. ses på tiden, det tager en testperson at gennemføre en stillet opgave [Nielsen 1993, side 27-37].

Vi tester også efter attributten satisfaction, da det er vigtigt, at brugeren føler sig godt tilpas, når 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øges specifikt i debriefingen [Nielsen 1993, side 27-37].

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ænke 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].

Vi benytter os, gennem alle usability testene, af think-aloud metoden, som gør det muligt at få et indblik i, hvad testpersonen tænker, imens denne udfører scenarierne. På den måde kan både testlederen og notetageren (se afsnit 7.1.3) få et indblik i, ikke blot hvad testpersonen gør, men også hvorfor de gør det. Think-aloud metoden kan også være med til at udpege specifikke interface komplikationer, således at disse kan blive rettet op på[Nielsen 1993, side 18-19].

7.1.3 Testens forløb

Vores usability test består af en testperson, en testleder og en notetager. Testpersonen udfører de udleverede scenarier på en bærbar computer, som er stillet til rådighed. 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øbende i udførelse af scenarierne, notere deres fysiske adfærd samt færden på sitet.

Testlederens rolle består i at observere testpersonen på tæt hold, samt være til hjælp, såfremt en testperson skulle være ude af stand til at komme igennem et scenarie efter gentagne forsøg. Testlederen starter indledningsvis med at udlevere introduktionen til testen (usability testene kan ses i bilag B og C), samt fortælle kort om, hvad der kommer til at foregå undervejs. Testlederen udleverer løbende scenarierne, som er udprintet og klippet til på små stykker papir. Afslutningsvis går testlederen igennem en debriefing, som har til formål at give en opsummering af testpersonens samlede indtryk af websitet. Debriefingen består af spørgsmål, som relaterer sig til systemet (se bilag B og C).

Et scenarie kan anses som fuldført, når testlederen registrerer at testpersonen har gennem-

ført scenariet, og testlederen vil derefter udlevere næste scenarie. Skulle der opstå tvivl fra testpersonens side om, hvorvidt et scenarie er fuldført eller ej, vil testlederen træde til og oplyse om status på gennemførelsen af det pågældende scenarie.

For at kvalitetssikre usability testen har vi udført 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.

7.1.4 Succeskriterier for systemet

Teori

Ved planlægningen 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].

Kriterier for succes

Ved udarbejdelsen af kravspecifikationen blev succeskriteriet præciseret for hvert krav. Derfor er det relevant for os at gennemgå de opstillede kriterier for at se, om de enkelte krav er opfyldt, samt muligt at udføre for testpersonerne. Vi har her præciseret kravene med prioritet 1 Must have og proritet 2 Should have, som værende de krav, som skal være opfyldt. Krav med en prioritet på 3 eller 4 er ikke obligatoriske krav.

Systemet er opbygget til at understøtte brugen som både medlemmer og administrator. Vi har derfor valgt at opsætte to forskellige usability tests, som har forskellige kriterier for succes.

Succes for medlemstesten

Et eksempel på et succeskriterie for et medlem er krav 1a, hvor det skal være muligt for testpersonen at logge ind og booke en ledig tid i bookingkalenderen. Hvis testpersonen ikke er logget ind, skal kalenderen dog ikke være synlig. Dette succeskriterium afhænger dog af kravet 3a og 3b, hvor testpersonen skal have oprettet en bruger på websitet for at benytte bookingkalenderen. Derfor har vi netop opstillet de to scenarier for at kunne undersøge de forskellige funktioner i relation til hinanden.

Figur 7.1: Kravspecifikation og succeskriterier for medlemssiden i systemet

Det er samtidig vigtigt at de tre usability attributter, learnability, satisfaction og errors, bliver opfyldt. Systemet skal være let at anvende, da medlemmerne ikke er eksperter i systemet og ikke nødvendigvis har prøvet det før. Samtidig skal systemet være tilfredsstillende for brugeren, så de kunne have lyst til at anvende det igen.

Ydermere ses det også som en succes, hvis der ingen seriøse, kritiske eller katastrofale fejl opstår undervejs i testen. Skulle der opstår disse fejltyper på medlemssiden vil vi stræbe efter at få disse rettet hurtigst muligt.

Succes for administratortesten

I kravspecifikationen er der også for administratorfunktionerne udarbejdet succeskriterier for de enkelte krav. Disse kan ses på figur 7.2, og skal være mulige at fuldføre i usability testen.

Figur 7.2: Succeskriterium for administrator

Denne del af websitet testes også for learnability, satisfaction og errors. Her må det gerne tage testpersonen længere tid at blive komfortabel med systemet, da denne del af systemet er mere avanceret end medlemssiden. Systemet må gerne være tilfredsstillende (høj satisfaction), men da den skal bruges til at administrere de data, der findes på websitet, vil dette kriterium ikke være vores største fokus. Ydermere er det vigtigt, at der ikke opstår nogle seriøse, kritiske eller katastrofale fejl undervejs, da dette vil forstyrre det arbejde, der er tiltænkt siden.

7.1.5 Testpersoner

Teori

Ved benyttelsen af thinking aloud er der behov for minimum tre deltagere i testen, da de få deltagere samlet giver en stor mængde af kvalitativ data[Nielsen 1993, side 195, 224]. Testpersonerne skal være repræsentative for den målgruppe, som systemet er tiltænkt, da dette vil give et mere præcist billede af systemets brug [Nielsen 1993, side 209-214].

Vores testgruppe

Gennem vores interview med bestyrelsesformanden (se afsnit 3.2.5) erfarede vi at vores målgruppe var opdelt i aldersgrupperne med ca. 50% mellem 18 – 25 år og ca. 50% på 50+.

Ud fra dette har vi valgt at teste systemet med en opdeling på fire personer i aldersgruppen 18 – 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ære appellerende for dem.

Ikke alle testpersoner har tidligere erfaring med tennis, hvilket vi har bedømt ikke vil påvirke vores test, da det at spille tennis ikke har relevans for at brugen af et bookingsystem. Samtidig ønsker foreningen flere medlemmer, som nævnt i afsnit 2.3, hvilket gør det relevant at teste personer, som ikke tidligere har spillet tennis.

Testperson Køn Alder

1	Mand	22
2	Mand	24
3	Kvinde	21
4	Kvinde	25
5	Mand	46
6	Mand	64

Tabel 7.1: Testpersoner til medlemstesten

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øre, fordi de to personer er dem, der kommer til at benytte administratordelen efter systemets færdiggørelse. Vi vurderede at det ikke ville være relevant at finde en generel målgruppe af testpersoner til denne del af hjemmesiden, da den ikke vil blive benyttet af mere end et par personer af gangen.

Testperson Køn Alder

1	Mand	46
2	Mand	64

Tabel 7.2: Testpersoner til administratortesten

7.1.6 Testopgaver

Teori

Ved udarbejdelse af testopgaverne er det vigtigt, at sørge for at testpersonen får en tidlig succesoplevelse. Samtidig skal opgaverne teste de funktioner, som systemet er beregnet til at skulle understøtte. Opgaverne skal være små nok til at kunne blive udført indenfor den afsatte tidsperiode for testen, men samtidig ikke så små, at de bliver trivielle [Nielsen 1993, side 181-186].

Ved at udlevere opgaverne en ad gangen i løbet af testen mindskes sandsynligheden for misforståelse af opgaverne. Det gør det muligt for testpersonen at forstå opgaverne i deres eget tempo og vende tilbage til dem, hvis det skulle være nødvendigt [Nielsen 1993, side 181-186].

Vores opgaver

Testopgaverne er udarbejdet på baggrund af de opstillede kravspecifikationer for at sikre, de er opfyldt. Den fulde kravspecifikation kan ses i bilag A.

Herunder vil vi gennemgå et udsnit af opgaverne for de to forskellige tests samt deres tilhørende krav. De to usability tests kan ses i henholdsvis bilag B og C.

Usability test medlemmer

Usability testen af medlemmerne har fokus på de funktioner, som de skal kunne benytte på websitet, f.eks. bookingfunktionen og indmeldelse i foreningen.

Scenarie 1

Du er interesseret i at melde dig ind i Midtbyens Tennisklub, men før du melder dig ind vil du gerne undersøge klubbens vedtægter.

(a) Find vedtægt 4, og læs den højt.

Dette scenarie er opstillet på baggrund af kravet 5c (se figur 7.3), hvor foreningen gerne vil have overført informationer fra deres nuværende website til det nye system. Samtidig er det opstillet for at teste navigationen på siden. Scenariet er valgt som det første, for netop at sørge for testpersonen har en simpel opgave til start.

Figur 7.3: Kravet 5c for almindelig bruger

Scenarie 2

Du har nu læst vedtægterne, og ønsker nu at melde dig ind i klubben.

(a) Find indmeldelse siden og udfyld indmeldelses felterne med nedenstående oplysninger:

Navn: Jens Jensen

Adresse: Min Vej 3, 9000 Aalborg

Telefon: 99999999

Email: jens@gmail.com

Kode: 1234

Betaling: MobilePay

Dette scenarie er opstillet for at teste kravet 3b (se figur 7.4), som beskriver indholdet af indmeldelsesproceduren. Dette tester vi ud fra ovenstående informationer, såsom navn, adresse m.m., som er indsat i scenariet, da der ikke skulle opstå tvivl om de informationer, der skulle udfyldes.

Figur 7.4: Kravet 3b for almindelig bruger

Scenarie 4

Du ønsker nu at booke en tid på tennisbanen.

Find bookingsiden og log ind med følgende informationer;

Email: jens@gmail.com

Kode: 1234

Book en tid d. 16/5 kl. 10:00 – 11:00 i kalenderen sammen med Jakob Rønnest.
Du ønsker at booke endnu en tid d. 17/5 kl. 17:00 – 18:00, men den er booket i forvejen.

Find ud af, hvem der har booket tiden, og sig det højt.

Du fortryder nu, at du har booket tiden d. 16/5 kl. 10:00 – 11:00. Afmeld din tid.

Dette scenarie gennemgår 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ære en af de mere krævende opgaver.

Vi har her igen valgt at oplyse informationen om log ind til testpersonen, for at der ikke skulle opstå tvivl om de informationer, der skulle benyttes til opgaven.

Figur 7.5: Kravene for bookingkalenderen

Usability test administrator

Usability testen for administratorsiden har fokus på de funktioner, som administratoren skal kunne benytte. Dette er f.eks. håndtering af medlemmer og opdatering af websitet.

Scenarie 1

Du vil gerne undersøge om der er kommet nye medlemmer i klubben.

Log ind som administrator ved at benytte følgende oplysninger:

Email: ******@mbtennis.dk

Kode: *********

Der er en medlemsanmodning, og du har kontrolleret at personen har betalt. Godkend det nye medlem Stefan Mundt.

Dette scenarie er udarbejdet fra kravet 3c, se figur 7.6. Vi har indsat dette som det første scenarie, da det ofte vil være en af grundene til administratoren tilgår websitet. Samtidig er det en af kernefunktionerne for deres arbejde i starten af sæsonen, da medlemmerne skal kunne tilgå websitet efter de er blevet godkendt af administratoren.

Testpersonerne får i testen udleveret gyldige log ind oplysninger, som er oprettet i databasen, så de kan tilgå sitets fulde administratorfunktioner.

Figur 7.6: Krav 3c for administrator

Scenarie 2

Du har udleveret en nøgle til det nye medlem Stefan Mundt, og du ønsker at registrere det på hjemmesiden.

(a) Registrer at medlemmet Stefan Mundt har fået udleveret en nøgle.

Scenarie 2 er relevant at have med, da det er en del af foreningens procedure i forbindelse med nye medlemmer. Bestyrelsesformanden bekræftede, at nøgleudleveringen skulle registreres, og derfor blev denne funktion inkorporeret i systemet.

Scenarie 7

Et bestyrelsesmedlem har fået et nyt telefonnummer, og du ønsker at opdatere telefonnummeret.

(a) Opdater bestyrelsesmedlemmet Jakob Rønnest Sørensen’s telefonnummer til 10101010.

Flere af scenarierne tester administratorens mulighed for at redigere oplysningerne på websitet. Disse scenarier er opstillet ud fra kravet 4b (se figur 7.7), og er fordelt gennem testen for at observere, hvordan navigationen på siden fungerer.

Figur 7.7: Krav 4b for administrator

7.2 Databehandling

I det følgende afsnit gennemgås og bearbejdes de data vi har indsamlet i forbindelse med vores usability test, samt hvad vi har fået ud af disse. Først vil vi se på tidsmålingerne for vores usability test af medlemmer, samt forklare hvordan vi har klassificeret de fundne problemer. Herefter vil vi gennemgå resultaterne af testen for administratorer. Afslutningsvis vil vi samle op på de fundne problemer for de to tests og sammenholde dem med debriefingerne.

For at kunne sige noget om graden af usability problemer har vi valgt at tage tid på de enkelte testpersoner samt observere deres reaktioner på de enkelte scenarier. De reaktioner, vi fokuserer på, er frustration og irritation, som kommer til udtryk ved at testpersonerne ryster på hovedet, virker opgivende, klikker forvirret rundt, sukker m.m. Dette kan vi bruge til at klassificere usability problemerne ved hjælp af severity skalaen, som bliver gennemgået i følgende afsnit.

7.2.1 Teori

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:

Kosmetisk problem: Et kosmetisk problem forsinker testpersonen med mindre end et minut. Problemet behøves kun at blive løst, såfremt der er ekstra tid til rådighed. Dette problem vil skabe en lav frustration hos testpersonen, da systemet kun reagerer en anelse anderledes end det forventes
Seriøst problem: Et seriøst problem er et problem, som vil forsinke testpersonen flere minutter. Dette problem er ikke en nødvendighed at løse, men det skal gerne løses efterfølgende. Der vil her opleves en betydelig grad af frustration hos testpersonen, da systemet pludselig agerer en del anderledes end det forventes at gøre
Kritisk problem: Et kritisk problem vil forhindre testpersonen i at fuldføre scenariet, og testpersonen er nødsaget til at skulle have hjælp 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ølgende
Katastrofalt problem: Et problem kan defineres som værende 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].

Udover severity skalaen benyttes der også en debriefing efter usability testene, som kan være med til at give en mere subjektiv forståelse af testpersonernes oplevelser med sitet [Nielsen 1993, side 103].

7.2.2 Klassificering af problemer i testen for medlemmer

I tabel 7.3 ses en oversigt over tidsmålingerne for de forskellige testpersoners udførelse af de enkelte scenarier (se afsnit 7.1.6 og bilag D). Dette har været med til at give os et samlet overblik over tidsforbruget pr. scenarie, som har hjulpet os med at klassificere de fundne usability fejl.

Testperson/ Scenarie	1	2	3	4	5	6
1.a	0:18	0:18	0:22	0:27	1:00	1:12
2.a	1:07	1:30	1:11	1:02	1:31	4:31
3.a	0:19	0:17	1:22	0:37	0:15	0:22
4.a	0:20	0:28	0:15	0:12	0:24	1:20
4.b	0:32	0:20	0:23	0:20	0:38	0:59
4.c	0:07	0:15	0:30	0:14	0:50	0:50
4.d	0:36	0:02	0:02	0:02	0:30	2:15
5.a	0:22	0:09	0:12	0:12	0:09	0:27
5.b	0:25	0:20	0:20	0:13	0:35	3:05
6.a	0:03	0:02	0:02	0:02	0:03	0:05
Samlet	4:00	3:42	4:39	3:21	5:55	15:06

Tabel 7.3: Tidsforbrug pr. scenarie for medlemmer opgjort i minutter:sekunder

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ået tildelt graden kosmetisk, og et er blevet tildelt graden seriøst.

Oplevet af

Sce.	Brugbarhedsproblem		Kategori	1	2	3	4	5	6
1.a	P1	Vedtægt placering	Kosmetisk	x				x	x
3.b	P2	Besværlighed ved at finde dato for standerhejsning	Kosmetisk			x	x
4.b	P3	Afmelding af den bookede tid	Seriøst	x				x	x

Tabel 7.4: Kategorisering af problemer ud fra vores usability test af medlemmer

Kosmetiske problemer

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ærende kosmetiske skyldes den minimale tidsforsinkelse på under et minut, samt det at der ikke var nogle frustrationer at identificere ud fra testpersonernes kropssprog.

Et eksempel på 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å at finde siden, der indeholdte vedtægterne, som kan findes i undermenuen Om os i menubaren. Der var her tale om en tidsforsinkelse på under et minut, og der var ingen frustrationer at identificere hos testpersonerne.

Seriøse problemer

Vi har identificeret et seriøst problem, P3 (se tabel 7.4). Problemet udmundede sig i, at når en booket tid skulle afmeldes, var der tre ud af seks brugere, som klikkede på det blå felt i selve kalenderen, som er den bookede tid (se figur 7.8). Ved at klikke på dette felt, åbnes der blot information om, hvem der har booket banen og hvornår. For at afmelde den bookede tid, skal testpersonen klikke på knappen Afmeld tid, som er til højre for selve bookingkalenderen. Dette skabte for to af testpersonerne en minimal tidsforsinkelse. En af testpersonerne var nødsaget til at få hjælp af testlederen for at identificere knappen. Hertil skal det dog nævnes, 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øre opgaven uden hjælp fra testlederen.

Figur 7.8: Skærmbillede af bookingfunktionen på mbtennis.dk. Knappen Afmeld tid ses til højre på billedet.

Debriefing

Generelt mente testpersonerne, at det var nemt og ukompliceret at finde rundt på hjemmesiden. To testpersoner udtalte, at den var ensartet hele vejen rundt, hvilket gjorde det let at få et overblik og nemmere at benytte systemet.

Tre testpersoner mødte dog en udfordring i forhold til at finde vedtægterne på siden. De var her i tvivl om, hvor de skulle finde denne information henne.

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.

Dog havde tre testpersoner svært ved at afmelde tiden, da de gerne ville trykke på den valgte tid og afmelde den ved hjælp af pop-op vinduet, som tidligere nævnt. Dette skabte en smule undren hos disse, og de udtalte at det kunne være rart, hvis det var muligt at afmelde tiden ved at kunne trykke ind på den. Dog udtalte en af testpersonerne, at det kun var et problem første gang, da denne ville kende placeringen af funktionen næste gang en tid skulle afmeldes.

En testperson udtalte, at det havde været rart, hvis det var muligt at finde nyeste informationer i menubaren, og derved ikke skulle lede efter informationerne om standerhejsning på forsiden. Samtidig mente testpersonen også, at inddelingen af indmeldelsesformularen var anderledes end hvad denne var vant til, men det var dog ikke et problem at udfylde informationerne – kun en undren til inddelingen.

Alle testpersonerne udtalte, at de gerne ville benytte systemet igen, da det var nemt at benytte og danne sig et overblik over ledige tider.

7.2.3 Klassificering af problemer i testen for administratorer

Tabel 7.5 viser tidsmålingerne for testpersonernes udførelse 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ævnt, netop er de to personer, der kommer til at benytte systemet. Det faktum at vi kun tester to personer kan dog medføre at resultaterne ikke er lige så konkluderende, som hvis vi havde testet flere, men kan stadig være med til at udpege nogle usability fejl.

Testperson/ Scenarie	1	2
1.a	0:57	2:04
1.b	0:36	0:43
2.a	0:32	0:29
3.a	0:39	1:01
4.a	1:31	5:44
5.a	0:52	1:19
6.a	0:14	1:42
6.b	0:13	0:16
7.a	0:23	0:43
8.a	0:14	0:12
Samlet	6:11	14:30

Tabel 7.5: Tidsforbrug pr. scenarie for administratorer opgjort i minutter:sekunder

Tabel 7.6 viser klassificeringen af fundne usability fejl i testen af administratorerne. Her har vi identificeret et kosmetisk og et seriøst problem, som vi uddyber herunder.

Oplevet af

Sce.	Brugbarhedsproblem		Kategori	1	2
4.a	P4	Upload af billede	Seriøst	x	x
5.a	P5	Afmelding af tid	Kosmetisk	x

Tabel 7.6: Kategorisering af problemer ud fra usability testen af administratorer

Kosmetiske problemer

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å 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ør afmeldingsfunktionen i højre side af figur 7.8 blev fundet.

Figur 7.9: Skærmbillede af bookingfunktionens pop-op vindue på administratorsiden

Problemet P5 blev også observeret ved P3 i medlemstesten. Det er derfor et gennemgående problem på siden, som har skabt en smule forvirring og undren hos flere testpersoner.

Seriøse problemer

Der blev fundet et seriøst problem på 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å knappen Upload billede, se figur 7.10.

Dette er et seriøst problem, da begge testpersoner blev flere minutter forsinkede og gentagne gange prøvede 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.

Figur 7.10: Skærmbillede af administratorfunktionen til upload af billede

Debriefing

Begge testpersoner udtalte, at de fandt siden nem at benytte – især grundet det genkendelige layout fra medlemssiden. De nævnte dog begge, at de lige skulle lære systemet at kende, da de startede på opgaverne og ikke helt vidste, hvordan systemet fungerede.

Testpersonerne havde begge problemer med at uploade et billede til websitet, hvilket er klassificeret som et seriøst problem. En af testpersonerne udtalte dog, at han ikke normalt benyttede computere, så derfor havde han lidt problemer med at finde ud af, hvordan funktionen fungerede. De mente begge, at hvis de havde fået en introduktion til funktionen forinden, så ville de ikke have haft problemer med at uploade.

Generelt var begge testpersoner ikke i tvivl om funktionerne på sitet. En testperson nævnte, at systemet var logisk og intuitivt, og det derfor ikke ville være et problem, hvis systemet skulle benyttes igen uden hjælp.

Samtidig nævnte en testperson ligeledes, at det var et væsentligt lettere system at finde rundt i, i forhold til deres nuværende hjemmeside.

7.3. FEJLKILDER

7.3 Fejlkilder

Gennem usability testene observerede vi steder, hvor vi skulle have været mere opmærksomme, eller hvor testen kunne forbedres.

7.3.1 Fejl i kode

Den første testperson, efter pilottesten var udført, oplevede en fejl, hvor denne ikke kunne afmelde sin tid i kalenderen. Denne fejl opstod, da vi havde ændret opstilling af koden for at gøre 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.

7.3.2 Netværksforbindelse

I usability testen for administratorsiden oplevede vi problemer med netværksforbindelsen, 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.

7.4 Evaluering af usability test

For at sikre vores system levede op til vores egne, samt samarbejdspartnerens forventninger, var det essentielt at gennemføre en usability test. Vi opstillede derfor en række succeskriterier for usability testen, for at sikre vores ønskede formål 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ældet. Vi kan konstatere, at langt de fleste af kravene er opfyldt i systemet. Det mest fundamentale var, at alle vores krav med prioritet 1 (Must have) eller 2 (Should have) var opfyldt, hvilket blev opfyldt for alle, på nær ét krav. Succeskriteriet for krav 7b er, at ingen seriøse, kritiske eller katastrofale fejl er at finde i systemet for medlemmer. Da vi har identificeret en seriøs fejl i testen, er dette ikke opfyldt. I forhold til prioritet 3 (Could have) og prioritet 4 (Want to have but want have this time around), 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 diskussion).

7.4. EVALUERING AF USABILITY TEST

Udover at kontrollere om kravene var opfyldt for hhv. bruger og administrator var et af vores fokusområder 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åtte indeholde nogle seriøse, kritiske eller katastrofale fejl. Dette kriterie er identisk med krav 7b i kravsspecikfikationen og ikke opfyldt, som nævnt i foregående afsnit.

I administratortesten var succeskriteriet ligeledes at systemet ikke måtte indeholde seriøse, kritiske eller katastrofale fejl. Da et af problemerne var seriøst, er dette kriterium ikke opfyldt, men vi stræber efter at løse problemet og vil komme med løsningsforslag i afsnit 7.5.

Ud fra usability attributten satisfaction var succeskriteriet for medlems- samt administrator testen, at systemet skulle være 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.

Den sidste usability attribut vi havde fokuseret på var learnability. Succeskriteriet var her for medlemstesten, at systemet skal være let anvendeligt for en ny bruger, og at brugeren skal bruge mindst muligt tid på at sætte sig ind i systemet. Kigges der på tabel 7.3, var hovedparten af opgaverne udført på under et minut og langt de fleste på under to minutter. Testperson 6 var den eneste testperson, som brugte over 2 minutter på at løse en opgave. Denne testperson havde ikke særlig meget erfaring med brug af computere, hvilket resulterede i at opgaver, hvor blandt andet tastaturet skulle bruges tog længere tid. Udover at opgaverne blev gennemført relativ hurtigt, havde testpersonerne generelt set heller ingen problemer med at løse opgaverne. Kun testperson 6 havde problemer med en opgave, hvor testpersonen måtte få hjælp af testlederen, ellers blev alle opgaverne gennemført uden hjælp.

I den efterfølgende debriefing gav testpersonerne også udtryk for, at det var nemt og ukompliceret at finde rundt på hjemmesiden. Som nævnt tidligere udtalte to af testpersonerne, at siderne var ensartet, hvilket gjorde det let at få et overblik og nemmere at benytte systemet. I envisionment-fasen (se afsnit 4) designede vi efter nogle designprincipper, som blandt andet fokuserede på learnabillityen af systemet, heriblandt designprincippet consistency. Ud fra deltagernes udtalelser og ageren i prøven kan vi konstatere, at vores mål for designet er opfyldt i forhold til systemets learnability.

7.5. FORBEDRINGER TIL SYSTEM UD FRA USABILITY TEST

I forhold til administratortesten måtte systemet gerne tage lidt længere tid at lære og blive komfortabel med, idet der er flere og mere komplekse funktioner. Herudover er det også de samme få personer, der kommer til at bruge disse funktioner gang på 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øre opgaven. En af testpersonerne nævnte at systemet var logisk og intuitivt, og at det derfor ikke ville være et problem, hvis systemet skulle benyttes uden hjælp. Administratorfunktionernes learnability lever ligeledes op til vores forventninger og succeskriterie.

7.5 Forbedringer til system ud fra usability test

Gennem usability testen og databehandlingen har vi fået belyst nogle problemområder i vores system. Vi har taget disse problemer til overvejelse og vil herunder gennemgå forbedringer, som kan laves til systemet.

7.5.1 Afmeld funktion

Usability testen viste, at både medlemmer og administratorer havde problemer med at afmelde en tid med afmeldningsfunktionen. Dette problem kunne løses, hvis det var muligt at afmelde en reserveret tid ved en funktion i pop-op vinduet. Systemet ville således både understøtte afmeldingsfunktionen i pop-op vinduet og den nuværende løsning (se figur 7.8). Løsningen med at kunne afmelde en tid i pop-up vinduet var allerede fra starten den løsning, vi helst så udført, men grundet tidspres og problemer med JavaScript i den åbne modal (se afsnit 6.6), valgte vi den løsning, som er at finde i det udarbejdede system. Dette er noget vi vil bestræbe på at løse, hvis systemet bliver taget i brug. Anvendes løsningen med afmeldingsknappen i pop-up vinduet vil det betyde, at den seriøse fejl vil blive løst, og dermed overholdes samtlige prioritet 1 og 2 krav i kravsspecifikationen.

7.5.2 Upload af billeder

Begge testpersoner i testen for administratorer havde problemer med at uploade et billede til hjemmesiden. Dels grundet netværksforbindelsen, men primært grundet misforståelse af selve funktionen. På nuværende tidspunkt skal administratoren placere musemarkøren over det billede, som denne gerne vil have ændret. Derefter skal billedet vælges og til slut skal der trykkes på Upload billede. Funktionen forsvinder dog, når administratoren fjerner musemarkøren fra det billede, der skal skiftes. En løsning kunne være at lade funktionen

7.5. FORBEDRINGER TIL SYSTEM UD FRA USABILITY TEST

blive vist i længere tid efter musemarkøren er fjernet. En anden løsning kunne være at ændre koden, således at kunne uploades billeder i modalen, hvor det er nødvendigt at trykke upload for at lukke modalen. På denne måde vil det blive åbenlyst at trykke upload før billedet er uploadet. Dette problem er ligeledes noget vi vil bestræbe at løse i tilfældet af at systemet anvendes. Det vil eliminere den seriøse fejl identificeret i adminstratortesten.

7.5.3 Indmeldelsesformular

En af testpersonerne udtalte, at rækkefølgen på de informationer, som et medlem skal udfylde, stod anderledes end hvad denne havde mødt før (se figur 7.11). Forbedringen i dette tilfælde kunne være at omrokere de forskellige felter, så de står over hinanden i stedet, så brugeren nemmere bliver guidet gennem de oplysninger, som skal gives.

Figur 7.11: Skærmbillede af indmeldelsesformularen på mbtennis.dk

7.5.4 Nyeste informationer

Flere testpersoner ledte efter information om standerhejsningen. En af testpersoner udtalte, at det kunne være rart, hvis der havde været en mulighed i menubaren, hvori der stod de nyeste informationer. Dette har vi taget til overvejelse og mener, at dette kunne være med til at forbedre hjemmesiden, idet ældre nyheder dermed også vil blive lagret.

Kapitel8

Diskussion

8.1 Optimering af koden

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ørste kode vi skrev ikke var optimal. Vi har ikke haft tid til at lave radikale ændringer, så i dette afsnit vil vi beskrive den mest nævneværdige ændring, som vi kunne have lavet i forhold til at optimere koden.

I bookingfunktionen oprettes en ny funktion for hver ledig og reserveret tid (se figur 8.1).

8.1. OPTIMERING AF KODEN

Figur 8.1: Kodestykke til fremvisning af modalen over bookingkalenderen, når der klikkes på en grøn celle

Hvis der eksempelvis er 60 ledige tider i kalenderen, vil dette kodestykke lave 60 forskellige funktioner, som i bund og grund gør det samme, blot med forskellige værdier. De værdier, der er forskellige, er det unikke id for cellerne.

Her ville det være 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’et for de enkelte celler, og dette kunne gøres ved at have en onclick funktion på de enkelte celler, der kalder cellens id ind i funktionen. Dette kunne for eksempel se således ud: onClick=”function(this.id)”.

8.2. NEDPRIORITERINGER

8.2 Nedprioriteringer

Nogle krav i kravspecifikationen blev nedprioriteret i implementerings-fasen og er derfor ikke med i det færdige system.

Det første krav vi ikke implementerede, var en administratorfunktion til galleriet på siden

(krav 4b). Vi fik lavet en dynamisk gallerifunktion, men grundet tidspres valgte vi ikke at lave administratorfunktionen, og valgte i stedet at fokusere på andre dele af systemet, som havde en højere prioritet.

Det andet krav vi ikke fik med var opfyldelse af lovkrav i relation til datasikkerhed (krav 8b). Dette krav havde en prioritering på 2, men fordi vores samarbejdspartner ikke var sikre på, at de ville benytte systemet, vurderede vi, at kravet var mindre vigtigt at implementere, idet systemet måske ikke skulle ud i den virkelige verden. Gennem forløbet med samarbejdspartneren er de dog blevet mere tilfredse med systemet og vil gerne benytte det. Efter vi har kigget på reglerne for GDPR^{^[21]}, har vi dog indset, at de er langt mere komplekse end først antaget. Vores første tanker var, at kravet kunne løses med en samtykkeerklæring fra brugeren, når de afgav deres oplysninger, men vi har sidenhen erfaret, at dette blot er et af mange facetter i GDPR. Herudover begyndte vi først at se på det så sent i vores projektforløb, at vi ikke kunne nå at implementere sikkerhedsforanstaltningerne i systemet.

Kravet om responsivt design, som vi valgte at give en prioritet 4 (Want to have but not this time around), ville vi kigge på, hvis vi skulle arbejde videre med systemet. Kravet har været et element, som har optrådt i PACT analysen, men som vi valgte ikke at tage med, da det ikke var i dette projektforløbs fokus.

8.2.1 Datasikkerhed

I forhold til sikkerhed er der to ting, som vi hverken har med på hjemmesiden eller i kravspecifikationen, men som ville være en god ide at implementeret på et tidspunkt. Det ene er et SSL-certifikat på hjemmesiden og det andet er kryptering af adgangskoder i databasen.

SSL-certifikat

SSL er en krypteringsprotokol, der sørger for at det kun er afsender og modtager, der kan læse informationen, der sendes mellem disse parter [FairSSL n.d.]. Når der er sat SSL kryptering op

8.3. PROTOTYPER

på en hjemmeside, vil der i starten af url’en stå https fremfor blot httpGoogle n.d. Idet Midtbyens Tennisklub modtager personlige oplysninger fra deres medlemmer, når de tilmelder sig, bør de derfor på et tidspunkt få SSL-certifikatet sat op for medlemmernes sikkerhed.

Kryptering

Kryptering af koder i databasen vil ligeledes være en god ide, da det nuværende 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øge at få 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år i databasen, ikke har noget med de egentlige adgangskoder at gøre, men derimod består af en lang række “tilfældige” tegn. PHP har indbyggede funktioner til at gøre dette, men det er, som beskrevet, ikke noget vi har haft fokus på at implementere på hjemmesiden [php.net n.d.].

8.3 Prototyper

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å siderne. Vi kunne have opstillet opgaver ud fra de udarbejdede sketches og bede testpersonerne om at pege på sketchen, når der skulle foretages en interaktion. Dette kunne give os et indtryk af om vores tidlige design idéer var på vej i den rigtige retning, samt teste den overordnede navigation på sitet. Udover at følge designprincipperne beskrevet i afsnit 4.2 til at understøtte designet, kunne en prototype have givet yderligere indsigt i dette.

Da navigationen i systemet er simpel og indeholder få navigationsmuligheder, vurderede vi derfor, at det ikke var nødvendigt at benytte os af en Lo-Fi prototype, da denne prototype primært fokuserer på den overordnede struktur.

8.4 Spørgeskema

Vi kunne have valgt at benytte os af spørgeskemaer som supplement til problemanalysen. Udover beretninger fra flere bestyrelsesmedlemmer og gruppemedlemmet om den utilstrækkelige bookingproces kunne et spørgeskema, udsendt i foreningen, have givet os yderligere indsigt i bookingprocessen. På den måde ville vi have haft udsagn fra flere medlemmer i

8.4. SPØRGESKEMA

foreningen, som kunne have været med til at give os yderligere viden omkring, hvorvidt der var et problem.

Set i bakspejlet ville det derfor have været fordelagtigt at have benyttet spørgeskemaer. Dette ville have givet os et stærkere grundlag i forhold til det problem, som vi skulle løse. Vores fokus lå på kontakten med bestyrelsesformanden for tidligt at kunne få udviklet nogle designidéer, 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å at indhente den tabte tid i designprocessen, og ikke på at udsende spørgeskemaer til medlemmerne i foreningen.

Kapitel9

Konklusion

Det initierende problem vi gerne ville løse var en ineffektiv bookingprocess. Efter interview med bestyrelsesformanden blev det klart at udover problemet med bookingprocessen, var det også vigtigt for foreningen at erhverve nye medlemmer. Dette udmundede i vores problemformulereing:

Hvordan kan vi designe og konstruere et IT-system, som understøtter foreningens ønske om større brug af banen?

På 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øse fejl på sitet: en ved afmeldingsfunktionen og en ved upload af billeder for administrator. På 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øvningen i usability testen for bestyrelsesmedlemmerne, udtalte de, at de gerne ville anvende det.

Vi kan konkludere, at IT-systemet understøtter foreningens ønske om større brug af banen på følgende måder:

For det første medfører anvendelsen af dette IT-system, at det ikke længere kræver en fysisk tilstedeværelse i klubhuset for at booke en tid. Dette vil gøre det mere appellerende for medlemmerne at booke banen på forhånd og derfor, højst sandsynligt, løse den problematiske bookingproces, hvor klubkulturen er, at medlemmerne omgås bookingkalenderen. For det andet gør digitaliseringen af bookingprocessen det mere attraktivt for foreningens primære målgruppe, unge, at melde sig ind i foreningen. Det online bookingsystem er attraktivt for især unge, idet unge i højere grad vil have en forventning til, at bookingprocessen foregår online.

Bibliografi

123hjemmeside.dk (n.d.). 123hjemmeside – nem hjemmesideservice. URL: https://www.

123hjemmeside.dk/. (Tilgået d. 25.02.2019).

5GBfree (n.d.). 5GB free Hosting | Free Webhost |The Best Free Hosting, Period. URL: https:

//www.5gbfree.com/. (Tilgået d. 29.03.2019).

Agile Business, Consortium (n.d.). The DSDM Agile Project Framework (2014 Onwards) –

MoSCoW Prioritisation. URL: https://www.agilebusiness.org/content/moscowprioritisation. (Tilgået d. 15.03.2019).

Benyon, David (2010). Designing Interactive Systems. Second edition. PEARSON.

— (2014). Designing Interactive Systems. Third edition. PEARSON.

Bruun, Anders Rysholt (2019). DEB 3: Envisionment (videomateriale). URL: https://www. moodle.aau.dk/course/view.php?id=28472. (Tilgået d. 20.03.2019).

Cowan, Dr. Nelson (2019). Working Memory Laboratory. URL: https://memory.psych. missouri.edu/cowan.html. (Tilgået d. 24.05.2019).

FairSSL (n.d.). Hvad er et SSL-certifikat? | FairSSL. URL: https://www.fairssl.dk/da/sslinformation/what-is-an-ssl-certificate. (Tilgået d. 13.05.2019).

Felke-Morris, Terry Ann (2011). Basics of Web Design: HTML5 & CSS3. PEARSON.

Google (n.d.). Beskyt dit website med HTTPS. URL: https://support.google.com/ webmasters/answer/6073543?hl=da. (Tilgået d. 24.05.2019).

Hosting, NTC (n.d.). phpMyAdmin – a MySQL Databse Administration Tool. URL: https:

//www.ntchosting.com/encyclopedia/databases/mysql/phpmyadmin/. (Tilgået d.

18.05.2019).

Inc., Github (n.d.). The world’s leading software development platform – GitHub. URL: https:

//github.com/. (Tilgået d. 29.03.2019).

Nielsen, Jacob (1993). Usability Engineering. Morgan Kaufmann.

Nixon, Robin (2014). Learning PHP, MySQL, JavaScript, CSS & HTML5 (3rd Edition). O’Reily Media.

php.net (n.d.). PHP: password_h^ash− Manual. URL: https://www.php.net/manual/en/ function.password-hash.php. (Tilgået d. 13.05.2019).

BIBLIOGRAFI BIBLIOGRAFI

Raptis, Dimitri (2018). Lecture 3: Identifying and categorizing usability problems. URL: https:

//www.moodle.aau.dk/pluginfile.php/1348651/mod_resource/content/10/ ITSY-Usab%5C%20Lecture%5C%203.pdf. (Tilgået d. 18.05.2019).

Riis, Ole (2004). Sociologiske metoder i praksis. Aalborg Universitetsforlag.

Rosen, Kenneth H. (2019). Discrete Mathematics and Its Applications (Eighth Edition). McGrawHill Edication.

Tennisklub, Midtbyens (n.d.). Midtbyens Tennisklubs hjemmeside. URL: http://www.mtk9000. dk/. (Tilgået d. 25.02.2019).

UnoEuro (n.d.). UnoEuro – Webhoteller og domæner. URL: https://www.unoeuro.com/.

(Tilgået d. 10.04.2019). w3schools.com (n.d.). w3schools – The world’s largest developer site. URL: https://www.

w3schools.com/php/php_arrays.asp. (Tilgået d. 15.05.2019

Spatiale færdigheder afgør individets evne til at finde rundt på og huske en hjemmeside ↑
En iterativ proces, er en proces, som bliver gennemgået og revurderet gentagene gange ↑
Arbejdshukommelse er et andet term for korttidshukommelse ↑
Når musemarkøreren holdes over et element vil det skifte farve/nuance. ↑
Forms (på dansk: formular) indsamler bruger input, blandt andet via checkboxes eller tekstfelter ↑
Client-side betyder at handlingen køres lokalt i brugerens browser ↑
Et id er unik attribut for et HTML-element ↑
En class er ligesom et id en attribut, men bruges til at påvirke flere elementer ↑
En selector er det element, som skal ændres ↑
Når der omtales serverside, betyder det at handlingen eksekveres af en server, og ikke af brugerens browser ↑
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ørste element tilgås ved at skrive $array[0]. Andet element vil kunne tilgås ved $array[1] osv. ↑
phpMyAdmin er gratis open source software, der bruges til at håndtere MySQL databaser gennem et grafisk bruger interface [Hosting n.d.] ↑
En mængde er en ikke-ordnet samling af objekter. Mængden siges at indeholde sine elementer. Dvs. at elementet “8:00″er i mængden “tidspunkter”[Rosen 2019, side 116] ↑
En tableheader er den øverste række i en tabel og indeholder ofte navne på diverse kolonner ↑
Et if else statement kontrollerer først om udsagnet (if ) er sandt, og hvis det ikke er tilfældet, aktiveres der en alternativ kode (else) ↑
Et do while loop betyder, at der gøres noget, (do), imens et andet udsagn er sandt, (while) ↑
Et while loop udfører en handling, så længe et parameter er opfyldt. I eksemplet på linje 425 i figur 6.16 kører loopet så længe $i er mindre end 23. ↑
<td> eller tabledata er det tag, som benyttes for at lave en celle i en række i en tabel. For at lukke cellen igen, skrives tagget </td> ↑
En query er forespørgsel til databasen. Når vi tilgår databasen ved hjælp af PHP kommandoer, benytter vi os af SQL queries for at vælge præcis den data, vi ønsker at bruge ↑
En session variabel gemmer bruger information i en variabel, som kan bruges på samtlige side, og fungerer som en global variabel ↑
General Data Protection Regulation ↑