Middag med sociale medier

Transkript

1 Middag med sociale medier Del I: Udviklingsrapport d301e11, Efteråret 2011, Aalborg Universitet 20. december 2011

2

3 0 Titelblad III Aalborg Universitet Institut for Datalogi Datalogi: 3. Semester Emne: Systemudvikling af socialt medie Adresse: Selma Lagerlöfs Vej 300, 9220 Aalborg Ø Telefon nr.: Fax nr.: Hjemmeside: Synopsis: Projekttitel: Middag med sociale medier Projektperiode: Efteråret 2011 Projektgruppe: d301e11 Vejleder: Peter Axel Nielsen Projektmedlemmer: Christoffer S. Nielsen Martin Christensen Sine L. Viesmose Søren Kejser Jensen Kopiantal: 2 Sideantal: 130 Appendiks: 64 Færdiggjort Denne rapport tager udgangspunkt i problemstillingerne omkring unges madvaner, og hvad dette på længere sigt kan medføre af problemer, og indeholder et softwareorienteret løsningsforslag. Dette projekt tager udgangspunkt deri og indeholder en analyse af problemet, hvor vi finder frem til et løsningforslag med et socialt medie, der har madlavning som omdrejningspunkt. I gennem hele projektet har informanter forsøgt inddraget gennem interviews og prototypeafprøvninger. På baggrund af disse har vi udarbejdet en objektorienteret analyse og design. Analysen gennemgår problem- og anvendelsesområdet for systemet, hvor madlaveren er hovedfokuset. Designet gennemgår arkitekturen, der følger et klient-server mønster, og herefter model- og funktionskomponenten. Dernæst gennemgås implementeringen med mulige forbedringsforslag, og resultaterne fra en usabilitytest, lavet på baggrund af implementeringen. Til slut gennemgås unittestning. Den akademiske rapport tager udgangspunkt i vores arbejdsproces, i det vi har forsøgt at arbejde evolutionært. Den gennemgår konstruktions- og evolutionsparadigmerne og forklarer og evaluerer herefter vores projekt, set ud fra processen. Dernæst gennemgås rapportopbygningen, der også forklares og evalueres. Rapportens indhold er offentlig tilgængelig, gengivelse skal ske med kildeanførelse.

4

5 0 Forord V Forord Disse raporter er resultatet af et semesterprojekt for 3. semester på datalogi, Aalborg Universitet. Rapporten er udarbejdet af fire personer, med hjælp fra Bolette Tove Gregersen, der startede med at være i vores projektgruppe. Under projektet har vi haft Peter Axel Nielsen som vejleder, og han har hjulpet os med vejledning og korrektur igennem forløbet. Projektet blev opstartet 5. september 2011 efter oplæg om forskellige projektforslag og en efterfølgende gruppedannelse. Sideløbende har vi fulgt kurset, Systemudvikling, om objektorienteret analyse og design ved Peter Axel Nielsen, som har dannet grundlag for vores analyse og design i dette projekt. Vi har også fulgt kurset, Design, implementation and evaluation of user interfaces ved Mikael B. Skov og Jeni Paay, som har lagt grundlag for brugergrænsefladen af vores program. Christoffer Samuel Nielsen Martin Dybdal Christensen Søren Kejser Jensen Sine Lyhne Viesmose

6

7 Indhold Indhold VII 1 Problemanalyse Initierende problem Madvaner Livsstilssygdomme Sociale relationers indflydelse Valg af målgruppe Spørgeskema analyse Endelig problemformulering Processen Systemvalg Studerende som informanter Interviews med studerende Papirprototype Interview med klinisk diætist Systemdefinition Analyse af problemområdet Klasser Hændelsestabel Klassediagram Adfærdsdiagram Digital prototype Designprincipper i vores prototyper Grundlag Beskrivelse Afprøvning Analysen af anvendelsesområdet Aktørbeskrivelse Brugsmønstre Funktioner Sammenhæng til problemområdet Arkitektur Kriterier Overordnet arkitektur Teknisk platform Justering af komponentarkitektur Prioritering af elementer i implementationen Modelkomponenten VII

8 VIII INDHOLD 6.7 Controllerkomponenten Viewkomponent Implementering Systemet Interaktiv madplan Signalering og opdatering ved opgaver Intelligent foreslagsfunktion Integration i loginsystemet Oplagte muligheder for forbedringer Unittest Generelt om unittest Visual Studio Test Framework Unittest i vores system Usabilitytest Formål Evalueringsmetode Opgaver Problemer Problemliste Løsningsmuligheder Konklusion 61 Litteratur 63 A Spørgeskema sendt rundt til studerende på Aalborg Universitet 65 B Svar fra interview til digital prototype 69 C Informationstekst til testpersonerne 71 D Noter taget under usabilitytest Testperson et Testperson to Testperson tre E Kildekode Models Controllers Views F Kildekode unittest 127

9 Kapitel 1 Problemanalyse I dette kapitel vil vi beskrive og analysere den undren, der ledte til vores initierende problem, samt undersøge udvalgte områder omkring problemer med danskernes madvaner. Gennem denne analyse vil vi dokumentere, om der reelt eksisterer en problemstilling og i så fald i hvilket omfang den har betydning. På baggrund af dette vil vi opstille en problemformulering som grundlag for det videre forløb. 1.1 Initierende problem Vores mad er for fed, indeholder for meget sukker, består næsten udelukkende af færdigretter og McDonalds har kronede dage. Sådan er det i hvert fald, hvis man skal tro de gængse medier, hvor den ene fødevareskandale ruller efter den anden; Danskernes madvaner bliver værre og værre. Om situationen virkelig er så problematisk, eller der blot er tale om at vi overreagerer, vil vi undersøge gennem denne problemanalyse. Et svar vil med stor sandsynlighed befinde sig i mellem de to yderligheder, for ifølge DTUs undersøgelser vil danskerne også godt spise sundere [1]. Deres undersøgelser viser, at otte ud af ti danskere, ønsker at spise sundere. Når der er et ønske i befolkningen om at ændre sine madvaner, uden at det bliver gjort, må der være nogle barrierer, der forhindrer folk i at spise sundere. Vi kan også se en stigende tendens til, at der gås på kompromis med den mad, vi spiser. Siden 1995 er der sket en stigning i mængden af fastfood, der bliver spist [2]. Det er problematisk, da denne type mad sjældent opfylder de ernæringsmæssige krav. Samtidig er mængden af færdigretter også i fremgang, og selvom det er muligt at spise nogenlunde korrekt med færdigretter, skal man være varsom, da produkterne har en ernæringsmæssige højre energitæthed [3]. Så på trods af et ønske om at spise sundere, laver vi mindre mad selv og spiser i stedet færdigretter eller bestiller fastfood. Dette gøres selvom der er en tendens til, at disse ikke overholder fødevarestyrelsens anbefalinger [2]. En mulig forklaring på overstående kan være manglende motivering til selv at lave mad. Det er et problem, man tidligere har set andre steder, f.eks. omkring motion. Mange er bevidst om behovet for at motionere, men har ofte svært ved at komme igang. En løsning, der har vist gode resultater, er konceptet social running, hvor brugerne i fælleskab forsøger at motivere hinanden til at motionere mere. Dette er f.eks. gjort ved brug af it-baserede sociale medier, der kombinerer det sociale med brugernes fælles interresse i at løbe. Samtidig indeholder mediet oftest værktøjer specifikt målrettet løb, som f.eks. ruteplanlægning og kalorietællere, så at man er i stand til at planlægge sine løbeture nemt og enkelt. Endvidere har man ofte adgang til ekstra information om, de ture man har været på. Ved at samle denne denne information i et sociale medie, er det enkelt at gøre informationen offentlig tilgængelig, så ens sociale kontakter kan hjælpe med at motivere en ved f.eks. at sende opfordringer, ideer eller ved at planlægge løbeture sammen [4]. Et lignende socialt koncept kan muligvis overføres til madlavning. Disse spørgsmål ligger til grund for vores initierende problemer. Kan danskerne motiveres til at lave mere hjemmelavet mad, der ikke stiller dem dårligere ernæringsmæssigt? Kan egenskaberne fra social running overføres til madlavning? 1

10 2 Problemanalyse 1 For at besvare spørgsmålene kigger vi på, hvor stort problemet med danskernes madvaner er, samt negative og positive konsekvenser ved at ændre på sine madvaner. Hvis det viser sig, at problemet ikke er af betydelig størrelse, er motivationen for at løse det med stor sandsynelighed ligeså, og det kan derfor være en grund til, at det ikke er blevet løst. Endvidere er det interessant at kigge på, hvilken befolkningsgruppe problemet er mest udbredt i for at finde en eventuel målgruppe at fokusere på en løsning til. Da effekten af sociale medier, og hvordan de påvirke personer, tidligere har været undersøgt i andre sammenhæng, vil vi kigge nærmere på, om disse rent faktisk har en betydelig effekt, og i såfald hvordan denne opnås. Dette munder ud i følgen spørgsmål, der skal danne grund for ideer til et løsningsforslag: I hvor stort omfang tager danskerne sig ikke tid til at lave mad selv? Hvad er konsekvenserne ved ikke at lave mad selv? Har sociale medier nogen betydelig effekt? 1.2 Madvaner Det er vigtigt af afklare danskernes madvaner for at afgrænse, hvor det reelle behov befinder sig. DTU Fødevareinstituttet har udarbejdet en rapport omkring danskernes madvaner [5], og det er denne, som det følgende afsnit vil tage udgangspunkt i. Vi vil hovedsageligt koncentrere os om de nyere data, da formålet ikke er, at undersøge ændringerne i forhold til for 10 år siden. Som det ses ud fra tabel T1-1, er det tydeligt at se en sammenhæng mellem alderen og tiden brugt på at lave mad til hverdag. For unge i alderen år er det 41-43%, der bruger mindre end en halv time på at lave aftensmad. Det ses desuden, at der ikke er nogen stor forskel fra 1995 til Det betyder, at forskellen i tiden brugt på madlavning ikke kan skyldes et generationsskifte år år år Bruger under 30 minutter 41% 41% 24% 36% 22% 21% Tabel T1-1: Tidsforbrug på madlavning en hverdag Når man ser på husstandens størrelse, viser det sig også, at 61% af singlerne bruger under 30 min. til at lave mad i hverdagen. Vi bruger begrebet single til at beskrive en person, som bor for sig selv og til hverdag spiser alenet. Begrebet skal ikke forveksles med civilstatusen. Børnefamilierne er den hustandsgruppe, hvor færrest bruger under 30 min. på madlavningen. I rapporten bliver der også set på forbruget af færdigretter såsom pizza, pastaretter og suppe. Her ser man, at unge mellem år er de største forbrugere, hvor 30% spiser færdigretter mindst én gang om ugen. Når man ser på dette i forhold til hustandens størrelse er det igen klart singlerne, der er dem som spiser flest færdigretter. Omkring 39% spiser færdigretter mindst én gang om ugen. En grund til dette forbrug af færdigretter blandt singlerne kan skyldes manglende motivation til selv at lave mad. De skal kun lave mad til sig selv, og det er en mulig grund til at de måske ikke finder det særligt interessant. I en familie er der flere mennesker at lave mad til, og dette kan være en god motivationsfaktor. Manglende motivation kan også forklare, hvorfor singlerne oftest er dem, der bruger under 30 min. på tilberedelsen af mad. De største forbugere af halvtilberedte retter såsom ovnkartofler, frosne grøntsager osv. der bruges i det danske køkken, viser sig også at være de unge. Over halvdelen bruger dem mindst en gang om ugen, og af dem er der 30%, der bruger dem flere gange om ugen. Ved disse varegrupper er der desværre ingen information om fordelingen mellem aldersgrupper eller husstandsstørrelsen. DTU Fødevareinstistuttet har også udarbejdet en anden rapport, som omhandler danskernes gennemsnitlige kostsammensætning fra 2003 til 2008 [6]. Rapporten skelner her mellem tre forskellige aldersgrupper; 4-9 årige, årige og årige. I vores sammenhæng er de to første grupper ikke interessante, da det ikke typisk er dem, der står for madlavningen i hjemmet, og vi desuden ikke kan sammenligne resultaterne med den første rapport. Dataene for rapporten, og anbefalingerne i forhold til energifordeling kan ses på tabel T1-2. Energi fra alkohol er i denne forbindelse udeladt. Ud fra dette ses det, at danskerne i gennemsnit får for meget fedt. Rapporten viser også at ud af de 35% fra fedt, kommer 15% fra mættet fedt, som er det usunde fedt. Dette kunne tyde på, at

11 1.3 Livsstilssygdomme 3 Gennemsnitligt energifordeling Anbefalet energifordeling Fedt 35% max. 30% Kulhydrat 50% 50-60% Protein 15% 10-15% Tabel T1-2: Energifordeling i voksnes gennemsnitskost danskerne i gennemsnit får for meget af de usunde madvarer, hvor mættet fedt ofte udgør stor rolle af energiregnskabet. Kombineret med det faktum at det er singlerne mellem 19 og 24 år, der oftest spiser færdigretter, kan det tyde på, at man kan ændre på deres energiregnskab i en positiv retning ved at ændre deres madvaner i forhold til færdigretterne[6]. Ved at spise mange færdigretter er der desuden en risiko for, at man ikke får en kost, der er varieret nok i forhold til ens vitamin- og mineralbehov, og dette har negative konsekvenser i forhold til helbredet. Det viser sig, at det er normalt med færdigretter en gang i mellem, og det er unge og i særdeleshed unge singler der står for det største forbrug. Dette hænger godt sammen med tiden, der bliver brugt på madlavning, hvor det igen er den samme del af befolkningen, der bruger mindst tid. Danskere spiser generelt også for meget af det usunde fedt, så der er altså mulighed for at forbedre vores spisevaner i forhold til sundhed. Eftersom der er en sammenhæng mellem færdigretter og det usunde, vil der være grundlag for, at fokusere en indsats på at ændre dette ved unge singler. 1.3 Livsstilssygdomme Livsstilssygdomme har i dag store konsekvenser for mange mennesker i Danmark. Blandt årsagerne til disse er fysisk inaktivitet, overvægt og usund mad. Overvægt og usund mad kan begge forbindes med forkerte madvaner og er begge et meget udbredt fænomen. I år 2000 var ca. 10% af alle danskere svært overvægtige, og indtaget af usunde madvarer var alt for højt [7]. Konsekvenserne af dette er alvorlige, både fysisk, socialt og samfundsmæssigt. En af konsekvenserne for usund mad er at middellevetiden forkortes med henholdsvis fem og fire måneder for mænd og kvinder, fordi det øger risikoen for forskellige sygdomme, som karsygdomme. Overvægtighed reducerer danskernes levetid og for svært overvægtige med op til 2-3 år[7]. En af de samfundsmæssige konsekvenser er omkostningen ved behandling af symptomer, der skyldes overvægt. Svært overvægtige kan forvente 5-10 år mere med langvarige belastende sygdomme i forhold til normalvægtige. Hvis de ikke skulle behandle for det, ville der hvert år kunne spares hundrede af millioner i sundhedsvæsnet [7]. Der ses et markant dyk i livskvaliteten hos folk, der spiser usundt. En rapport fra Statens institut for folkesundhed konkluderer, at overvægtige føler sig mere stressede, sover dårligere og procentvis flere er deprimerede, nedtrykte eller ulykkelige. Dette skyldes blandt andet, at der er en tendens til, at samfundet har et kritisk syn på overvægtige, og dette kan føre til dårlig trivsel. Samfundet ser kritisk på dem, fordi de mener, at det er den overvægtiges egen skyld. Der er tilbud og muligheder nok for selv at gøre en indsats i at tabe sig [8]. Blandt overvægtige kvinder føler 60% sig ensomme, selvom de gerne vil være sammen med andre, til sammenligning er talet 36% for normalvægtige [9]. Disse oplysninger viser at der er forskellige problematikker ved usunde madvaner. Konsekvenserne er søvnløshed, sygdomme, stress og depression, som de moderat overvægtige og svært overvægtige lider mere af, end normalvægtige. Dette underbygger dette vigtigheden af at motiverer alle til at spise sundere mad. Da usunde madvaner kke kun påvirker den enkelte person psykisk, men et emne der påvirker samfundet negativt. 1.4 Sociale relationers indflydelse Det ser ud til, at der er en tendens mellem danskernes madvaner, hvor gamle de er og husstandens størrelse. Disse faktorer er oftest sværere at ændre, og det er derfor interessant at undersøge, hvordan man ellers kan påvirke folks madvaner. En undersøgelse fra 2009 [10] har påvist, at ens sociale omgangskreds har en indflydelse på ens egne vaner, hvis man kan identificere sig med personen. Undersøgelsen påviste, at hvis en person, man identificerede sig med tog på i vægt, er der en større sandsynlighed for, at man også selv gør det. Selvom denne undersøgelse handler om en persons vægt, mener vi, at konklusionen derfra kan overføres til andre vaner. En løsning på problemet kan derfor være at sammensætte grupper, hvor

12 4 Problemanalyse 1 gruppen sammen kan ændre deres madvaner. Dette vil muligvis være en løsning, da undersøgelsen viser at mennesker bliver påvirket af hinanden. Derfor, ved at få folk til at intragrere med andre vil det være muligt, at de kan motivere hinanden til at lave mad. Forskere fra Carnegie Mellon University [11] har studeret sammenhængen mellem sociale medier og den enkelte brugers sandsynlighed for at omstille sig. Denne undersøgelse kommer frem til det samme resultat som undersøgelsen omkring ens sociale omgangskreds. Et online socialt medie kan med andre ord også bruges til at ændre folks madvaner. En mulig løsning er derfor at lave et socialt medie, hvor brugerne kan interagere med hinanden. Dette hænger i god tråd med udviklingen, da flere og flere elementer fra vores dagligdag i dag er flyttet ud på internettet. Denne løsningsform er afprøvet før med succes i forbindelse med social running. Effekten af sociale medier er undersøgt i en rapport fra University of Massachusetts [12]. I dette studie kom det frem, at et socialt medie er med til at styrke brugernes egne intentioner i gennem motivation og hjælp fra de andre brugere af mediet. Undersøgelsen fra Carnegie Mellon University konkluderer også, at ved brug af sociale medier er det vigtigt at tilpasse indholdet meget præcist til målgruppen. Det er altså muligt at påvirke folks vaner, og der i gennem også deres madvaner, i gennem et socialt medie. Et socialt medie har de fordele, ens sociale omgangskreds også giver og giver derved mulighed for at påvirke brugerne af det. 1.5 Valg af målgruppe Fra afsnit 1.4 ved vi, at et socialt medie er en mulig platform til at lave en løsning. Ved sociale medier er det vigtigt, at indholdet passer meget præcist til den valgte målgruppe, hvis de skal blive påvirket af det [11]. Det vil derfor være en fordel at have en meget afgrænset og præcis målgruppe at arbejde videre med. Fra afsnit 1.2 ved vi, at den aldersgruppe, der spiser flest færdigretter og delvist tilberedte retter er unge mellem år. Det er også denne aldersgruppe, der bruger mindst tid på at lave mad i hverdagene. Når man ser på hustandens størrelse gælder det, at det er singler, der spiser flest færdig- og delvist færdigretter, og som bruger mindst tid på at lave mad selv. Ud fra dette vælger vi, at vores primære målgruppe skal være singler mellem år. 1.6 Spørgeskema analyse For at få en forståelse for vores målgruppe, og for at finde ud af hvordan vi skal forholde os til dem, har vi udarbejdet et spørgeskema, som vi har sendt ud til en række studerende på 3. og 5. semester på samfundsfagligt og humanistisk fakultet. Spørgeskemaet består af 15 spørgsmål hovedsageligt omkring deres madvaner samt nogle demografiske spørgsmål. Vi fik 67 besvarelser tilbage, ud af disse 67 bor 27 af dem alene, og det er dem, der passer ind i vores målgruppe. Derfor vil den følgende analyse fokuserer mest på disse, og sammenligne med de andre på nogle punkter for at bekræfte vores formodning om målgruppen. Som forventet spiser størstedelen af singlerne alene de fleste dage om ugen. 51% spiser deres måltider alene 4-5 dage om ugen, og 40% spiser deres mad alene 6-7 dage om ugen. Til sammenligning er der under 10%, der spiser deres mad alene mere end 4 gange om ugen, blandt de personer, der ikke bor alene. Undersøgelsen viser også at motivationen til at lave mad alene ligger under middel. Dette man kan ses ud fra figur F1-1.

13 1.6 Spørgeskema analyse 5 Figur F1-1: Motivation til at lave mad alene. Når man ser på de samme studerendes svar når det gælder motivativation til at lave mad sammen med andre, så får man helt andet billede. Dette kan ses på figur F1-2. Her ses det, at når de skal lave mad sammen med andre så stiger deres motivation meget. Figur F1-2: Motivation til at lave mad med andre. En anden ting vi ser er de studerendes forbrug af færdigretter og delvist tilberedte retter. De færreste benytter sig af færdigrettet i et større omfang. Kun 30% køber færdigretter 1 ud af 10 gange. Tilgengæld er det kun 25% af de adspurgte der næsten aldrig spiser delvist tilberedte retter, mens 25% spiser delvist tilberedte retter mere end 5 ud af 10 gange. Tendensen er i mod vores forventninger den samme hos dem der ikke bor alene. Udsagnene passer godt med det, vi allerede antog om denne målgruppe. Der er en klar tildens til, at folk hellere vil lave mad sammen med andre, hvilket tyder på at et socialt medie vil kunne motivere dem. Dog svarer de fleste, at det ikke vil være interessant med et socialt medie, se fig. F1-3. Dette kan skyldes, at de ikke kan forestille sig et sådant system eller ikke ved nok om det. Interessen for systemet er ca. det samme hos dem, der ikke bor alene, dog er der lidt færre, der har meget høj interesse for idéen, se fig. F1-4. Figur F1-3: Hvor meget interesse der er for et socialt mad medie blandt unge, der bor alene.

14 6 Problemanalyse 1 Figur F1-4: Hvor meget interesse, der er for et socialt mad medie blandt unge, der ikke bor alene. Vi spurgte i spørgeskemaet også om deres brug af sociale medier for at underbygge vores hypotese om, at vores system skal være et socialt medie. Ud fra spørgeskemaet ser det ud til, at de studerende er flittige brugere af sociale medier, hvor 47% af 67 studerende bruger sociale medier 1 til 3 timer om dagen eller mere. Der er også kun 11%, der bruger mindre end 1 time om ugen. Ser vi alene på singlerne, kan man se på figur F1-5, at tidsforbruget på sociale medier er højere, og at hele 53% bruger 1-3 timer om dagen eller mere på sociale medier. Figur F1-5: Hvor hvor meget de studerende bruger sociale medier. Dette tyder godt for vores valg at lave et socialt medie, da de fleste ser ud til at bruge disse på regulær basis. Spørgeskemaet bekræfter altså til en vis grad vores forventninger til målgruppen, dog er mængden af adspurgte forholdsvis lille og repræseneterer ikke den generelle unge særlig godt, da de alle går på universitetet og endda på de samme studier. Det kan derfor være svært at sige noget generelt. 1.7 Endelig problemformulering Danskernes gennemsnitlige energifordeling afviger lidt i forhold til anbefalingerne, og dette kan øge risikoen for at få livsstilssygdomme. Danskernes madvaner for de forskellige aldersgrupper har ikke ændret sig de seneste år, og det ser ud til, at det er singlerne mellem 19-24, der spiser flest færdigretter, og bruger mindst tid på at lave mad. Da færdigretter oftest har en højere energitæthed og ikke følger anbefalingerne for energifordelingen, vil det være fordelagtigt, hvis man kan ændre singlernes madvaner til at lave mere mad selv. Problemet ser ikke ud til at have noget at gøre med generationer, da fordelingen var den samme for både 5 og 16 år siden. Forskellen på madvanerne ses især i husstandsstørrelsen. Dette tyder på en sammenhæng mellem lysten til at lave mad og antallet af personer det er til, da motivationen også mangler hos singlerne. En velkendt måde at ændre vaner på er ved at bruge de personer i ens sociale omgangskreds, som man kan relatere sig til. Hvis de ændrer deres vaner, har man større sandsynlighed for at ændre sine egne. Undersøgelser har vist, at det er muligt, og at effekten også kan opnås gennem et digitalt socialt medie. Denne form for adfærdsændrende metode, har tidligere været anvendt med succes i forbindelse med at få folk til at dyrke mere motion.

15 1.8 Processen 7 På den baggrund har vi opstillet følgende problemformulering: Hvordan kan vi konstruere et socialt medie, der motiverer til at lave mad selv, samt gør det muligt at tilskynde til at spise sundere. 1.8 Processen I dette projekt har vi arbejdet evolutionært. Det betyder at vores arbejdsproces har været iterativt og præget af mange genovervejelser. Vores arbejdsproces kan ses på figur F1-6. I løbet af dette projektforløb nåede vi igennem fire iterationer. De fire iterationer har haft hvert sit fokuspunkt. I første iteration havde vi fokus på den indledende analyse og på en produktafklaring. I anden iteration på analysen af problemområdet. I trejde iteration havde vi fokus på analysen af anvendelsesområdet. I fjerde og sidste iteration havde vi fokus på designet af systemet. Dette er en naturlig konsekvens af, at begge prototyper lavet i tidligere iterationer er horisontale prototyper, som ikke krævede så meget design. Testen af det endelige system vil hovedsageligt fokusere på at finpudse detaljer og rette fejl i systemet, da den grundlæggende funktionalitet på forhånd er afprøvet i gennem prototyperne i tidligere iterationer. En konsekvens af denne arbejdsmetode er, at vi har måtte genoverveje flere elementer, som analysen skred frem. Vi har i rapporten valgt at dokumentere disse ændringer og skrive en procesorienteret rapport. Figur F1-6: En visualising af den iterativ metode[13]. Sideløbende med prototyper og vurdering af disse har vi arbejdet med at udarbejde et objektorienteret design som grundlag for det endelige system. Denne proces tager udgangspunkt i den viden, vi har fået gennem arbejdet med prototyperne. Dette er gjort for at fastlægge en grundstruktur og undersøge, hvordan den nye viden, vi har opnået, afspejler sig i ændringer af systemstrukturen og omvendt. Derved gennemarbejdes den tekniske side af systemet på lige fod med brugergrænsefladen og dennes funktionalitet.

16

17 Kapitel 2 Systemvalg Dette afsnit omhandler interviews med informanter, der passer ind i vores primære målgruppe, vores første prototype, afprøvningen af denne og et interview med en klinisk diætist, der kan give os viden til, hvordan vi formidler og motivere folk til at spise sundere. Denne viden bruger vi til at udarbejde vores systemdefiniton i både tekst og gennem BATOFF-kriterier [14], der skal være med til at sikre, at vi undgår større misforståelser gennem udviklingen. 2.1 Studerende som informanter Mulige informanter, vi kan bruge i vores projekt, er andre studerende på Aalborg Universitet. En grund til at vælge denne gruppe er, at en stor del af de studerende her på universitetet er i alderen år, hvor mange bor alene, da de som oftest er flyttet hjemmefra og endnu ikke har stiftet familie. En stor del vil derfor være i vores primære målgruppe. En fordel ved at vælge denne gruppe som informanter vil være, at vi let vil kunne komme i kontakt med dem, da de geografisk set befinder sig tæt på os. En anden fordel ved at bruge andre studerende er, at vi allerede har en forståelse for dem, i det vi selv er studerende. Dette betyder, at vi vil have lettere ved at finde ud af hvilke informationer, vi kan få ud af vores informanter, samt at vi kan bruge vores egne erfaringer til at udforme et system til dem. Valget af studerende fra samme studieretning har ulemper, da vi for hurtigt kan gå fra vores problem og direkte over til løsningen. Studerende med IT-baggrund ved også, hvad der er teknisk muligt, og er derfor ikke gode informanter. Ideerne og kritikken man får af disse studerende vil af samme grund minde meget om de tanker vi selv har, og vi vil derfor få færre nye ideer og mindre hjælp til et nyt design. For at forhindre dette vil vi bruge studerende fra studieretninger, hvor de generelt tænker radikalt anderledes i forhold til os. Dette kunne f.eks. være de humanistiske fag. Ved at gøre dette bevarer vi fordelene, og ulemperne er mindre. 2.2 Interviews med studerende For at undersøge hvad det er behov for og hvilke ønsker, målgruppen har, har vi lavet interviews med to studerende. I dette afsnit vil vi afdække deres ønsker og behov. De studerende blev først udspurgt om deres nuværende madvaner, og hvilken motivation de følte for selv at lave mad. Derefter forklarerede vi dem om vores idé til et system, og de blev bedt om at fortælle, hvad de kunne tænke sig, at et sådan system havde af funktionalitet og hvad de synes om vores ideer til funktionalitet. Til slut spurgte vi ind til, hvor sandsynligt det ville være, at de selv ville bruge et sådant system. Nedenfor ses en liste med den funktionalitet, som vi udspurgte dem om. Venner: For at skabe fælleskab mellem brugerne af systemet er det muligt at anmode andre brugere om at blive venner. Så man nemt kan se, hvad de har lavet, og sammenligne deres resultater med en selv. Grupper: Grupper er en samling af brugere, som deler en interesse. Man kan f.eks. have en gruppe for folk, der er glad for rejer el.lign. Det er tænkt som en måde at gøre det nemmere at finde venner, man deler en interesse med. 9

18 10 Systemvalg 2 Kontakt baseret på geografi: En funktion, hvor man kan lave mad med andre, der bor i nærheden af en selv. Grundlæggende undervisning: Grundlæggende informantion omkring forskellige madlavningsmetoder. Tiltænkt brugere uden tidligere erfaring. Opskrifter: Muligheden for at dele madopskrifter med andre brugere. Opskrifterne beskrives gennem tekst og billeder. Systemet kan også skalere opskrifter ud fra hvor mange personer, man vil lave den til. Videoer: Videoerne er en anden måde at fremvise opskrifter på. Fremfor at man skal læse den, kan man se en video af, hvordan retten skal tilberedes. Fravælg ingrediens: En funktion til at fravælge bestemte ingredienser. Hvis en bruger f.eks. ikke bryder sig om rejer, kan man fravælge dem, og disse opskrifter vil så ikke fremkomme i søgeresultatet. Rating: Mugligheden for at give en opskrift en karakter for at hjælpe andre med at skelne mellem gode og dårlige opskrifter. Kommentarer: Der kan skrives kommentarer til opskrifter, hvis man f.eks. har et forslag til en forbedring af opskriften, nemmere tilbedredning eller blot vil fremhæve nogle gode sider ved den. Madplan: Madplanen kan tilføjes opskrifter, hvorefter den holder styr på hvilke ingredienser, der indgår. Herefter kommer den med forslag, som bruger disse ingredienser, så man kan bruge det, der er tilovers fra de retter, man allerede har lavet. Madtemaer: Opskrifter kan tilføjes til forskellige temaer, så brugere der f.eks. skal holde fødselsdag, nemt kan finde forskellige fødselsdagsretter. Guides: Guides hjælper brugere med forskellige dele af madlavningen og ting forbundet hertil. F.eks. hvordan man laver en imponerende menu eller hvordan man anretter tunmousse. Opgaver: Opgaver som brugere kan løse. F.eks. at lave en flot rejemad eller tilføje ti opskrifter. For hver opgave, de løser, får de point og et lille ikon. Baseret på antallet af point opnår brugerne forskellige rang i systemet, der dog kun er af symbolsk værdi. Konkurrencer: Konkurrencer er udfordringer, der styres af systemet, og som alle brugere kan deltage i. Derved kan brugerne også konkurrere mod hinanden. Ved konkurrencer udpeges til slut en vinder Informant A A er en pige, 22 år gammel, der læser Arkitektur og Design, og bor alene på kollegium med eget køkken. Til dagligt laver hun mad selv, men hun synes ikke, at det bliver varieret nok, da hun ikke har tiden til at lave ordentlig mad. Ordentlig mad betydet for hende dansk mad og mad fundet i kogebøger. I forbindelse med et nyt socialt medie omkring madlavning er informanten interesseret i det omfang, at det ikke tager ekstra tid at bruge det. Det vigtige for hende er, at hun kan søge og finde interessante opskrifter nemt og hurtigt, og at det skal være muligt at frasortere ingredienser. For en oversigt over, hvilke funktioner hun kan lide, se tabel T2-1. Ud over at bruge det som inspirationsguide kan informanten se sig selv bruge det som en metode til at finde andre at lave mad sammen med i hendes lokalområde. Det skal være muligt at søge efter andre, der også vil være med til at lave mad sammen. Det er for hende ikke vigtigt, hvilken alder eller baggrund de har. Hun vil ikke sidde og se en video med en hel opskrift, da det vil tage for meget af hendes tid. Hun vil langt hellere have, at svære trin i opskriften blev forklaret med en film, hvis det af tekst ikke fremgik helt, hvordan det skulle gøres. Hun var ikke så meget til opgaver og konkurrencer. Mest af alt fordi hun ikke har tiden til at gøre noget ved det. En madplan, der kan hjælpe hende med at planlægge mad for en uge, så hun dermed kan spare tid, er derfor også højt prioteret. Når hun får gæster og søger efter opskrifter, vil hun også gerne have muligheden for guides til anretning af den mad, som hun laver. Hun synes, at det lyder spændende, og tror at hun vil kunne finde på at bruge det omkring en gang om ugen.

19 2.2 Interviews med studerende 11 - Opgaver + Opskrifter (+) Videoer + Madplan - Grundlæggende undervisning + Madtemaer + Kontakt baseret på geografi + Rating + Guides (+) Konkurrencer Tabel T2-1: A s ønsker til funktioner og indhold. + står for funktioner, hun kunne lide. - står for funktioner, hun ikke kunne lide Informant B B er en fyr, 22 år gammel, læser byggeri og anlæg og bor sammen med en anden fyr i en lejlighed. De laver sjældent mad sammen, og B orker ikke at lave mad til sig selv. Indtil for nyligt levede han derfor af færdigretter, men det har nu vist sig at være for dyrt, så han er begyndt at lave nemme retter selv. Han vil egentligt gerne lave mere mad selv og han har også tiden til det, men han mangler oftest motivationen til at lave mad, når det kun er til ham selv. I forbindelse med et nyt socialt medie omkring madlavning er det vigtigste for ham, at han i gennem det bliver motiveret til selv at lave mad. Det, at det kommer til at tage lidt længere tid gør ham ikke noget. Han skal nok finde tiden til det. For en oversigt over, hvilke funktioner han kan lide, se tabel T2-2. For informanten er det interessant at have en intern konkurrence med hans venner. Dette kan gøres gennem opgaver og et pointsystem, hvor man kan få rang alt efter, hvor meget mad man laver, og hvor mange opgaver man gennemfører. For ham er konkurrenceelementet overfor hans venner en meget central del af motivationsfaktoren. Det er derfor også vigtigt for ham at kunne invitere hans venner til også at være med. Han er negativ overfor at skulle lave mad sammen med fremmede mennesker, og han har heller ikke lyst til at møde andre gennem dette medie. Grupper er en ting, han synes kunne være godt, hvis det er grupper for ens vennekreds. Ud over dette er han dog ikke helt med på ideen. Han er meget interesseret i en madplan, så han også bliver motiveret til at lave mad dagen efter, og samtidig kan lave en indkøbsseddel for flere dage af gangen. Han synes, at et sådan madforum lyder spændende, og hvis han kan blive fanget af konkurrenceelementet, tror han, at han vil bruge det. + Opgaver + Opskrifter + Videoer + Madplan - Grundlæggende undervisning + Madtemaer - Kontakt baseret på geografi + Rating - Guides (+) Grupper + Kommentarer + Konkurrencer + Venner Tabel T2-2: B s ønsker til funktioner og indhold. + står for funktioner, han kunne lide. - står for funktioner, han ikke kunne lide Sammenfatning på interviews De to informanter er umiddelbart meget forskellige. A virker til at være et meget travlt menneske, der gerne vil have hjælp til bedre tidsudnyttelse. B virker til at være et konkurrencemenneske, der

20 12 Systemvalg 2 sagtens kan finde tiden til det, hvis han bliver motiveret til selv at lave mad. Deres synspunkter angående vores ideer, se side 2.2, afspejler også dette. De er dog begge ret enige om, at opskrifter er en vigtig del af et socialt medie omkring madlavning, og at en madplan med forslag vil være oplagt at have med. De er også ret enige om de mere almindelige tiltag, såsom rating og kommentarer. Herefter bevæger de sig lidt i hver sin retning. Hvor A virker mere eksperimentiel og gerne vil lave mad sammen med fremmede og have muligheden for at finde dem gennem sitet, vil B meget hellere bruge det til at konkurrere med hans venner om hvem, der kan få den højeste rang. A vil gerne have muligheden for at lære mere om anretning af de retter, hun laver, når hun får gæster, og han vil gerne have muligheden for at kunne se hele videoer af opskrifter for at lade sig friste til selv at lave det. De er begge enige om, at undervisning i grundlæggende madlavning ikke er interessant. De virker heller ikke særligt interesseret i at have grupper dannet på baggrund af, hvad man godt kan lide eller hvor man bor. 2.3 Papirprototype Baseret på de to interviews har vi fremstillet en prototype, hvor designet indeholder de funktioner, vores informanter finder interessante. Prototypen er en visualisering af den respons vi fik fra de to informanter. Dette gør det muligt for os at diskutere mere specifikke ideer til designet af systemet. Samtidig er det nemmere for informanterne at danne sig et overblik over vores ideer og kommentere på, hvad de mener fungerer godt i forhold til deres brug. Vi får derved mere konkret information, som vi direkte kan bruge til at forbedre systemets design og funktionalitet. Prototypen er lavet på papir, da dette gør det meget enkelt at arbejde med. Det er hurtigt at skitsere ideer og lave ændringer. Den korte produktionstid gør også, at ændringer ikke er særligt krævende. Vi kan derfor afprøve mange forskellige designs på meget kort tid, hvilket er en fordel, da det lader os eksperimentere mere med nye ideer. Ydermere gør det, det nemmere for os at efterlade det gamle, da der ikke er brugt ret megen tid på det. Vi mener at papirprototypen er god, da den giver informanterne et bedre indtryk af vores system end hvis vi blot forklarede ideen til dem. En anden fordel ved papirprototypen er, at informanterne kan se, at der ikke er brugt tid på den, og derfor ikke holder så meget igen på deres holdninger. Figur F2-1: Billede af prototypen.

21 2.3 Papirprototype 13 Figur F2-2: Billede af prototypen. Billeder af prototypen kan ses ovenover i figur F2-1 og F2-2. Designet er lavet, som det skal præsenteres i en browser. Navigation til sidens hovedelementer sker ved brug af faneblade langs toppen af siden, som er gennemgående på alle sider. Strukturen for siderne er tredelt med et hovedvindue i midten og to små i siderne. På denne måde kan vi have al hovedinformationen i midten og komplementerende funktioner og information i siderne. I de tilfælde hvor siden skal indeholde meget information, er der ingen sidebar i højre side, og pladsen bruges til hovedindholdet, for at dette ikke bliver for komprimeret. Funktionalitet der ikke kan udfylde denne tredelte-struktur, fremvises via små popup-vinduer. Oprettelse af en opskrift sker også via et pop-op vindue. Oprettelsen kræver meget brugerinput, og vi har derfor opdelt funktionen i flere trin, så brugeren ikke overvældes. Funktioner Her er de funktioner, vi har visualiseret i vores prototype: Opskrifter Søgning, fremvisning og mulighed for at tilføje opskrifter til en madplan. Det er desuden muligt at tilføje en opskrift til systemet. Opgaver Fremvisning af de opgaver, der er i systemet og muligheden for at gennemføre dem. En opgave kan f.eks. være at lave mad ti gange eller tilføje en opskrift til systemet. Highscore Fremvisning af highscoren, hvor de brugere med flest point i systemet vil være vist. Temaer Fremvisning af temaer, hvor man under de forskellige temaer, f.eks. årstider og helligdage, kan finde opskrifter, anretning og oppyntning, der passer til andledningen. Venner Fremvisning af ens venner, og muligheden for at tilføje flere venner til systemet Afprøvning For at undersøge de tanker og ideer vi havde til designet og funktionerne i vores prototype, afprøvede fire studerende fra Aalborg Universitet den med det formål at forbedre prototypen på baggrund af deres mening. De fire studerende går på det humanistiske fakultet, hvor alle fire læser dansk på første semester. Aldersmæssigt ligger alle i alderen 19-23; tre af dem bor ude med deres kæreste, og den

22 14 Systemvalg 2 sidste er hjemmeboende. De tre udeboende står selv for madlavningen, hvortil den fjerde kun laver mad, når han er alene hjemme. Deres madvaner består af hjemmelavet mad og aldrig færdigretter. Fremvisningen af prototypen til disse fire foregik som en fokusgruppe. Dette blev valgt over interviews med hvert enkelt på grund af mangel på tid i forhold til deres tidsplan, og da vi mente, at det ikke ville påvirke vores resultater på nogen negativ måde. Det giver også mulighed for, at deltagerne kan diskutere på de ting, som de andre kommer frem med. Fremgangsmåden ved fremvisningen forgik ved, at startsiden blev vist, og deltagerne fik et førstehåndsindtryk af den. Efterfølgende bad vi dem om at udføre forskellige handlinger, der skulle vise, hvor godt de kunne finde rundt i systemet. Disse handlinger inkluderede at logge ind, søge og finde en opskrift, tilføje den til en madplan, gå til Min side, finde temaer, uploade en opskrift, finde opgaver og at finde highscore. For hver handling blev de spurgt hvor let de følte, de kunne finde rundt og omkring de enkelte sider de kom ind på. Tilsidst blev de spurgt om deres mening omkring prototypen som en helhed, og hvad der skal til for, at de ville anvende systemet. Dette resulterede i: Brugbarheden af systemet - Overskueligt med fanebladsbaren i toppen af siderne. - Gode beskrivelser på funktioner; man ved, hvad man skal trykke på. - Der skal være en bedre oversigt over, hvor man befinder sig i systemet. - Synes ikke Tema skal ligge under opskrifter i fanebladsbaren. - Highscore skal flyttes op over venner i Min side. Funktionaliteten af systemet - Positiv over tilføjelser af billeder ud fra trin, når man uploader opskrift. - Man skal kunne søge på temaer fra startsiden, ikke kun opskrifter. - God idé at madplan og indkøbsliste hænger sammen. - Tilføje madvarer på indkøbsliste og derefter kommer forslag til madplanen frem. - Man skal trykke på Opgave i stedet for se flere-knappen på Min side for at komme ind på opgavesiden. - God idé med temaer, eftersom vores informanter er unge, uerfarne og mangler inspiration til madlavning og temabaseret madlavning. - Egne uploadede opskrifter, samt funktionen upload ny opskrift skulle ligge under Min side. - Man skal kunne skifte mellem global og lokal highscore, under Highscore. Generel feedback Overordnet syntes de godt om systemet, og der var nogle spændende funktioner, såsom temaer, som de ville anvende. Deres førstehåndsindtryk af layoutet var også ret positivt. De fandt den enkel i sin opbygning, og de var glade for, at den i layoutet minder om andre websites. Desuden kunne de godt lide, at der kun var få funktioner at vælge imellem, og de fandt det inspirerende med facts i højre side af vinduet. De kunne også godt lide ideen om at få opskriftsforslag for de næste dage ud fra en indkøbsliste eller andre opskrifter. Sammensætningen af opskrifter til tre dage ud fra indkøbsliste eller én valgt opskrift, er noget de ikke selv kan gennemskue, og da de ikke er interesseret i at smide mad ud, ville de bruge systemets forslag. I fanebladene skal MAD-logoet fremhæves, så man bedre kan forstå, at man kan bruge den som en knap til at komme tilbage til startsiden. Fanen Opskrifter skal omdøbes, da ingen syntes, at navnet var dækkende for, hvad den indeholdte. De ville desuden gerne have flere funktioner i fanebladsbaren. Opgaver, Konkurrencer og Inviter venner er ikke noget, de ville bruge. De forstod ikke ideen med det og syntes ikke, at den var en motivationsfaktor for at lave mad. Når man tilføjer en ny opskrift, forstod de heller ikke, hvad knappen tilføj/fjern medie gjorde. Efter at blive forklaret dens funktion, syntes de bedre om, at vi i stedet for medie brugte billede/video. Tre ud af de fire ville bruge systemet, men kun til at se opskrifter, blive inspireret under Tema, og muligvis selv tilføje opskrifter. Den sidste ud af de fire, fandt ikke systemet interessant. For at tiltrække hendes opmærksomhed skulle det være opskrifter fra kendte eller klip af, at kendte, der ikke kan lave mad, laver mad.

23 2.4 Interview med klinisk diætist Sammenfatning af prototypeafprøvningen Ud fra denne fokusgruppe kan vi se, at de ikke er interesseret i at bruge andet end opskriftsdelen, og at de ikke ser opgaver og konkurrencer som en motivationsfaktor. Dette kan hænge sammen med, at de i forvejen selv laver mad og har en anden motivationsfaktor i og med, at de laver mad til andre. Vi kan se, at vores målgruppe er meget fast, da det kun henvender sig til dem, der bor alene og som har brug for en motivationsfaktor for at komme i gang med selv at lave mad. Til næste prototypeafprøvning vil vi derfor vælge vores informanter med større omhu, end det er gjort denne gang. Da brugervenligheden er nogenlunde den samme, kan vi stadig bruge fokusgruppens kommentarer på denne front, og så se bort fra deres kommentarer omkring funktionaliteten, da denne ikke skal optimeres efter dem, men efter vores primære målgruppe. 2.4 Interview med klinisk diætist Da vi ikke selv har viden om, hvordan man formidler og motiverer mennesker til at spise mere ernæringsmæssigt korrekt, har vi brug for en informant der kan hjælpe os til at finde ud af dette. Diæstister arbejder hver dag med at rådgive og motivere mennesker til at leve sundere. Vi formoder at erfaringen og rådene er nogle, vi kan overføre til kommunikation og motivation over internettet, og en diætist er derfor et udemærket valg til en informant. Vi har interviewet Janne Danielsen, der er klinisk diætist på Aalborg Sygehus og sidder i Sund Info, som er et forbyggelsesambulatorie. Hun arbejder med patienter, der alle vejledes og behandles forskelligt indenfor kost, rygning, alkohol og motion. Behandlingen kan være i form af rygestop inden en operation, da patienten så heler hurtigere. En stor del af behandlingerne har fokus på patientens vægt. Det er vigtigt inden en knæoperation, at patienten ikke er overvægtig, da de kommer hurtigere på benene igen og formindsker risikoen for blodpropper. I dette tilfælde er det Janne Danielsens opgave at skabe tillid mellem hende og patienten, hvorefter de sammen udarbejder en kostplan. Når de udarbejder en kostplan, er det ud fra patientens ressourcer, overskud til at ændre deres vaner, og hvor patienten generelt befinder sig psykisk og fysisk. Der er forskellige faktorer, der spiller en stor rolle, når patienten skal ændre sine vaner, såsom sorg, familiekrise, inkontinent og andre sygdomme. Ved at de udarbejder kostplanen sammen, bliver der ikke stillet urealistiske krav eller for stor ændring, som patienten ikke kan overholde. I andre tilfælde kan det være en mindre ændring i patientens kostvaner, der er nok til vægttab. Når patienter ikke lader sig motivere, prøver Janne at afklare, hvad de ikke går med til og finde ud af, hvad de så gerne vil. På den måde opnår Janne og patienten et tillidsbånd, og når det er lykkedes, kan patienten nemmere påvirkes og motiveres, da patienten så er ærlig om hendes vaner. Konsekvensen af, at patienten ikke er ærlig overfor Janne og sig selv, er, at der ikke sker forbedringer, eftersom man får den forkerte behandling og ikke overholder de mål, de har sat sammen. En behandling ved Janne afsluttes ikke, når en patient har opnået målene, men derimod når rådighedsbeløbet er brugt. Derefter skal patienten fortsætte behandling er de steder, kommunen kan tilbyde. Stod det til Janne, stoppede behandlingen hos hende, når patienten har opnået det, patienten ville. Janne giver sine patienter følgende grundlæggende råd i forbindelse med kostplanlægning. - Spis varieret. - Følg de otte kostråd. - Ingen grund til at frygte kalorier. - Det er nødvendigt med nogle sunde fedtstoffer. - Køb produkter med nøglehullet og fuldkornsmærket. - Spis mange grønsager, på trods af højt kalorieindehold. - Vitaminer er vigtige, men bør fås gennem en varieret kost. Overordnet er det ifølge Janne vigtigt at spise en varieret kost, så kroppens behov bliver dækket gennem kosten, frem for med vitaminpiller og kosttilskud. Det handler om at være opmærksom på sin krops behov, så den for det, den har brug for, hvilket også indbefatter fedtstoffer og kalorier. De otte kostråd er gode da de informerer omkring, hvad korrekt kost er uden at forbyde bestemte madvarer, men derimod ved at hjælpe med at dosere dem korrekt. Markeringen af varer gør det nemmere at spise efter kostrådene, da man hurtigt kan forhold sig til de mange forskellige fødevarer.

24 16 Systemvalg Sammenfatning på interview Det vigtigste er at sørge for at brugeren har tillid til websitet. Når tilliden først er skabt, er det et website man vil vende tilbage til og anbefale til andre. De unge socialiserer sig med vennerne, og derfor kan man overbevise sine venner til at spise sundere. I forhold til madvaner er det vigtigt at spise varieret for at sikre, at ens krop for det den har behov for. Det er derfor bedre at vurdere de mængder, man spise af de forskellige fødevarer, fremfor helt at udelukke nogen. Samtidig er det vigtigt med gode informative markeringer og symboler, da det er en god hjælp til at vurdere indholdet af en madvare. 2.5 Systemdefinition Baseret på den viden, vi har opnået gennem problemanalysen, prototypeafprøvningen og de interviews, vi har lavet med vores informanter, har vi lavet en systemdefinition [14], der præcist beskriver hvilket system, vi har planlagt at udarbejde, for at der ikke opstår større misforståelser under udviklingen. Systemdefinitionen er skrevet først som tekst, og derefter vha. BATOFF-kriterier. Dette er gjort for at specificere systemet nøjagtigt. Et IT-system, der kan bruges til at motivere brugere til at lave mad gennem et online socialt medie. Systemet skal bruges i forbindelse med madlavningen, og det skal primært være en motivationsfaktor til brugeren gennem sociale aktiviteter, såsom opgaver, og kontakt med andre brugere. Systemet skal også bruges, når maden er lavet for at give brugeren mulighed for feedback på sin madlavning. Gennem kontakten med andre brugere og gennem opgaverne, som systemet har, skal systemet tilskynde til at spise sundere. Sekundært skal det gøre det nemmere at planlægge madlavningen gennem en madplan og en autogenereret indkøbsliste. Systemet skal være et klient-serversystem, hvor klientdelen skal kunne afvikles i en tidsvarende internetbrowser, uafhængigt af den underliggende platform. Serverdelen afvikles på en opdateret version af Windows Server med tidsvarende værktøjer. Betingelser: Unge singler, der er vant til at bruge IT, og hvor sociale medier er en naturlig del af deres hverdag. Anvendelsesområde: Anvendes i forbindelse med planlægning, inspiration, udførsel og opfølgning af madlavningen. Teknologi: Klient-serversystem. Klientdelen skal kunne afvikles i en nyere browser. Objekter: brugere/madlavere, opgaver, derunder konkurrencer og udfordringer, opskrifter, temaer og en madplan. Funktionalitet: Registrering af brugernes madlavning, og udførte opgaver. Madplan med mulighed for forslag. Filosofi: Systemet skal motivere til at lave mere mad selv, og gennem interaktion med systemet og andre brugere, skal der opfordres til at lave sundere mad.

25 Kapitel 3 Analyse af problemområdet For at danne overblik over, hvilke elementer vores system skal indeholde for at udføre de planlagte funktioner, vil vi i dette kapitel analysere problemområdet. Denne analyse tager udgangspunkt i vores systemdefinition, de erfaringer vi har fået fra prototyperne og feedback fra informanterne. Ud fra dette vil vi modellere en grundstuktur til vores system, der viser sammenspillet mellem de forskellige elementer og hændelser. Analysemetoden tager udgangspunkt i bogen Objektorienteret Analyse & Design [14]. Problemområdeanalysen har flere gange undervejs været ændret, den fremgår i dette kapitel som seneste version af vores analyse. 3.1 Klasser I det følgende afsnit vil vi gennemgå kandidater til klasser systematisk for derefter at udvælge hvilke, vi ønsker at inddrage i vores system. De foreslåede klasser er blevet til ved en brainstorm, og vi har derfor ikke på forhånd valgt nogen fra. Madlaver: Repræsenterer en Madlaver, der laver mad i problemområdet. Den indeholder unik information, såsom navn, titel og lignende. Klassen er nødvendig for at identificere forskellige Madlavere og det data, der er associeret med dem. Kalender: Tiltænkt som overordnet struktur omkring madplanen, men da denne ikke er baseret på dage, men måltider, er denne klasse ikke nødvendig. Opskrift: Modellering af Opskrifter indeholdende Ingredienser. Bevares af samme grund som Madlaver, da den repræsenterer et separat element i systemet, der indeholder unik information. Ingrediens: Beskrivelse af de Ingredienser, en Opskrift består af. Kan muligvis indkapsles i Opskriften, men er bibeholdt for at gøre det nemmere at arbejde med forholdet mellem Ingrediens og Opskrift. Samtidig gør det, det nemmere at udvide med mere information om Ingrediensen. Opgave: Opgaver kan Madlavere løse for at stige i rang. De fungerer uafhængigt af Madlaverne og repræsenterer unik information i systemet. Klassen er derfor beholdt. Konkurrencer: Konkurrencer afviger fra Opgaver ved, at en Konkurrence ikke kan startes af Madlavere. Samtidig har alle Madlavere mulighed for tilmelde sig og Konkurrere indbyrdes mod hinanden. Bibeholdes derfor. Udfordring: Udfordringer er, ligesom Konkurrencer, Opgaver mellem Madlaverne, men de bliver, i modsætning til Konkurrencer, startet af Madlavere, som derved også selv bestemmer, hvem der kan deltage. Bibeholdes også, da den afviger fra en Konkurrence. Billede: Repræsenterer et billede, der kan tilføjes i en Opskrift. Da disse ikke indeholder anden information, har vi valgt at indkapsle dette i Opskriftsklassen. Video: Beskriver en video, der kan tilføjes i en Opskrift. Da disse, ligesom billedet, ikke indeholder anden information, har vi igen valgt at indkapsle dette i Opskriftsklassen. Tema: Indkapsler Opskrifter efter kategorier, som f.eks. jul. Indeholder også anden information vedrørende det specifikke tema. Vi har derfor valgt at beholde klassen. 17

26 18 Analyse af problemområdet 3 Kommentar: En Kommentar givet til en Opskrift af en Madlaver. Denne er fravalgt, da vi mener, det er bedre at indkapsle informationen i en Opskrift, eftersom den ikke indeholder anden unik information. Ven: Er de Venner, som en Madlaver har. Denne er fravalgt, da en Ven også er en Madlaver. Madlaverklassen får derfor en relation til sig selv. Venskab: En relation, der beskriver forholdet mellem to Madlavere. Denne klasse er nødvendig for at beskrive hvilket Venskab, der er mellem to Madlavere. Administrator: Repræsenterer en, der sikrer, at problemområdet er opdateret. Vi har valgt at afgrænse os fra Administratoren. 3.2 Hændelsestabel For at få en bedre forståelse for sammenhængen mellem klasser og hændelser har vi opstillet en hændelsestabel. Tabellen viser en repræsentation af de forskellige hændelser og viser, hvilke klasser der er påvirket af denne hændelse. Dette giver os et overblik over sammenspillet mellem vores klasser og gør det nemmere at overskue og designe den samlede struktur af vores system. Opgaver, udfordringer og konkurrencer bliver oprettet af programmøren og er derfor ikke hændelser. Mad- Opskrift Ingre- Opgave Konkur- Udford- Tema Madlaver diens rence ring plan Madlaver tilmeldt x Opskrift tilføjet x x x Opskrift tilføjet til tema x x Opskrift fjernet fra tema x x Ven inviteret x Ven tilføjet x Opgave udført x x x Rating givet x x Kommentar tilføjet x x Opskrift tilføjet til madplan x x Ingrediens tilføjet til madplan x x Ingrediens fjernet fra madplan x x Opskrift fjernet fra madplan x x x Profil redigeret x Deltaget i konkurrence x x x Udfordring sendt x x Udfordring accepteret x x Deltaget i udfordring x x Deltaget i opgave x x Tabel T3-1: Hændelsestabel 3.3 Klassediagram Ud fra ovenstående hændelsestabel har vi opbygget en systemstruktur, der beskriver forholdet mellem de forskellige klasser i problemområdet. Vi starter ved Madlaveren og udvider strukturen derfra, da Madlaveren er en meget essentiel klasse. Da vi begyndte at lave klassediagrammet, gik det op for os, at Opgaver og Konkurrencer mindende meget om hinanden, og at Mængder er nødt til at være i en særskilt klasse. På figur F3-1 ses Madlaveren øverst til venstre. For at beskrive forholdet til Madlaverens venner, har denne klasse en relation til sig selv gennem Venskabsklassen, der holder styr på hvilken relation, der er mellem de to Madlavere. Der er også en forbindelse til Opgave, da Madlaveren har mulighed for gennemføre Opgaverne, og derved skal den være bekendt med den information, Opgaven indeholder.

27 3.3 Klassediagram 19 Figur F3-1: Opgaveklassen. Konkurrencer er blevet lavet til en generaliseringsstruktur. Strukturen har Opgaveklassen som superklasse, da den indkapsler den mest generelle information. Konkurrence nedarves herfra, da Konkurrence ikke styres af Madlaverne, og flere Madlavere kan være med i samme Konkurrence. Udfordring er en Opgave, hvor det er muligt for flere personer at Konkurrere mod hinanden. Dette adskiller den fra Konkurrencer, som styres af systemet, mens Udfordringer startes af Madlavere. Vi lader derfor også Udfordringer nedarve fra Opgave. Figur F3-2: Opskriftklassen. Opskriftsklassen på figur F3-2 associeres med Madlaveren, da den kan tilføje Opskrifter. Selve Opskriften er opbygget af en aggregeringstruktur, da den består af både Trin og Ingredienser. Vi har valgt at opdele Opskriften i disse for at gøre indkapslingen af informationen lettere at forstå. Til brug ved Ingrediens har vi valgt Genstand-Beskrivelsesmønstreret for at holde styr på Mængderne i forhold til Opskriften. Dette betyder, at der i forhold til afsnit 3.1 er kommet en klasse ekstra. Opskrifter er også en abstrakt superklasse for to subklasser, Madopskrifter og Oppyntningopskrifter. Denne struktur er valgt, da en vejledning til Oppyntning og anretning minder meget om en Madopskrift, som vi allerede har modelleret. Den afviger ved ikke at bestå af Trin, men blot forskellige forslag, som vi på klasseniveau kan betragter som Trin, da de indkapsler den samme information. Vi beslutter derfor at lade grundstrukturen være indkapslet i Opskrift og så lade to typer af Opskrifter nedarve herfra. Dette er også med til at gøre forbindelsen til Temaer simplere. Vi har valgt at lade Temaklassen indkapsle Opskriftsklassen gennem aggregering, da Madopskrift og Oppyntningsopskrift er specialiseringer heraf.

28 20 Analyse af problemområdet 3 Figur F3-3: Det samlede diagram. På figur F3-3 ses det samlede diagram. Den sidste forbindelse til Madlaverklassen er Madplan. Madplan indkapsler de Opskrifter, Madlaveren har tilføjet til sin Madplan og en indkøbsliste, der indeholder de Ingredienser, som skal bruges til at lave Opskrifterne. Klassen er associeret med Madopskrift. Den færdige struktur består af tre store elementer. Madlaveren og dennes Madplan, Opgave og Opskrift med Temaer, samt deres bestanddele og underklasser. 3.4 Adfærdsdiagram For at danne et overblik over, hvordan de forskellige klasser fungerer, og hvad de mere præcist indeholder, har vi lavet adfærdsdiagrammer for udvalgte klasser. Diagrammerne beskriver, hvilken adfærd de forskellige klasser skal udvise, og hvilke attributter de skal indeholde. Figur F3-4: Madlaverens adfærd Madlaverklassen indeholder al information om Madlaveren. Navn, alder og adresse beskriver hvem Madlaveren er. Når Madlavere klarer Opgaver, opnår de point og får nye titler. Klassen er også bekendt, med hvilke Opskrifter Madlaveren har tilføjet. Alle Madlavere har en Madplan, som de kan tilføje Opskrifter til. Klassen oprettes med navn, alder og adresse, hvorefter den er aktiv. Madlaveren kan også tilføje nye Opskrifter til systemet, tilføje Opskrifter til sin Madplan, udfordre andre Madlavere, udføre Opgaver/konkurrencer og invitere andre til at blive brugere af systemet.

29 3.4 Adfærdsdiagram 21 Figur F3-5: Madplans adfærd. Madplan indkapsler de Opskrifter, Madlavere har tilføjet til planen, og de Ingredienser, der bruges hertil. Denne oprettes uden information, da det er op til Madlavere selv at vælge, hvad de vil have på planen. Tilføj Opskrift gør det derfor muligt at tilføje en Opskrift, mens Tilføj Ingrediens gør det muligt at tilføje ekstra Ingredienser til indkøbslisten. Disse kan ligeledes fjernes igen med de respektive fjern muligheder. Figur F3-6: Opskrifts adfærd. Klassen Opskrift indeholder Opskriftens navn; de Ingredienser, den kræver; hvilke trin, der skal til for tilberede den, og Madlaveres kommentarer til Opskriften. Hvis det er nødvendigt at redigere i Opskriften, går den tilbage til tilføjelsesfasen, mens den bliver redigeret. Ved oprettelse gives Opskriften et navn, hvorefter den er i tilføjelsesfasen, mens der tilføjes trin og Ingredienser til den. Ligeledes giver fasen mulighed for at tilføje Opskriften til et Tema. Når alt dette er gjort, bliver klassen aktiv, og der kan ikke længere tilføjes trin og Ingredienser, men Madlavere kan kommentere på Opskriften. Figur F3-7: Opgave s adfærd. Opgaveklassen indeholder navnet på Opgaven; en beskrivelse af den Opgave, den repræsenterer; gevinsten ved at gennemføre den, i form af point og emblem, og hvem der deltager i Opgaven. Opgaven oprettes med navn og kan i tilføjelsestilstand tilføjes point, en beskrivelse af Opgaven og et gevinstemblem. Herefter bliver den aktiv og Madlavere kan nu tilføjes med Tilføj Deltager.

30 22 Analyse af problemområdet 3 Figur F3-8: Tema adfærd. Tema har et navn og en række forskellige Opskrifter, der har en form for sammenhæng f.eks. jul eller fastelavn. Den skabes med navn, hvorefter den i aktiv tilstand kan tilføjes Opskrifter og fjernes Opskrifter, hvis nogen er tilføjet.

31 Kapitel 4 Digital prototype I dette kapitel vil vi dokumentere vores digitale prototype. Vi vil gennemgå de tanker og ideer, der ligger til grund for udviklingen af prototypen, og de ændringer, der er foretaget i forhold til papirprototypen. Vi vil dokumentere resultatet af voeres afprøvning med informanter, så vi kan få feedback der kan hjælpe os med udviklingen af det endelige system. 4.1 Designprincipper i vores prototyper I forbindelse med udarbejdelsen af vores prototyper har vi overvejet vores valgte design ud fra forskellige designprincipper [15]. Det er forsøgt at skabe konsistens i vores prototype i forhold til de systemer, som målgruppen i forvejen er vant til. Det har betydet, at vi har valgt at placere en række elementer på samme måde som mange andre hjemmesider. F.eks. er vores logo placeret øverst længst til venstre og linker tilbage til forsiden, og øverst længst til højre er log ud/log ind placeret, præcis som det kendes fra f. eks. Facebook. Se figur F4-1. For at undgå at forvirre brugeren, er det vigtigt at sørge for, at designet er konsistent. Dette fører også til, at designet bliver meget nemmere at lære og huske. Derfor har vi altid en menubar øverst, der er ens på alle sider. Indholdet under menubaren er også konsistent. Alle sider består af tre dele, hvor den midterste del viser hovedinholdet, og de to dele i siderne giver ekstra informationer. De ekstra informationer der er i samme kategori ligger altid i samme side. På både siden der viser highscoren og profilsiden, kan man se information om sin egen bruger og dette ligger på begge sider i højre del af siden. På samme måde ligger søgefelterne på highscoresiden, profilsiden og opskrift siden altid i venstre del af siden og er ens. De samme elementer bliver også altid præsenteret ens, bl.a. vises venner altid ved en lille kokkehue og et navn på brugeren. Et vigtigt designprincip, når der designes brugergrænseflader er gestaltlovene. Gestaltlovene forsøger at illustrere, den måde mennesker kobler ting sammen på, og siger at mennesket har en tendens til at se sammenhængende mønstre i stedet for individuelle dele, og at mennesket automatisk putter elementer i samme kategori. Gestaltlovene fortæller, hvordan vi afgør om elementer befinder sig et sammenhængende mønster. Lighedsloven fortæller at symboler der ligner hinanden, opfattes som hørende sammen, nærhedsloven fortæller at symboler, der beginder sig tæt på hinanden opfattes som hørende sammen, lukkethedsloven fortæller at symboler, der er afgrænset fra andre symboler f.eks. ved linjer, opfattes som hørende sammen og forbundethedsloven fortæller at symboler der er forbundet, opfattes som hørende sammen. Det har vi forsøgt at udnytte igennem sidens design. I vores menubar udnytter vi lukkethedsloven og lighedsloven, ved at knapperne har samme størrelse og teksttype og ligger på en linje, der er afgrænset fra resten af siden, ved at have en anden farve. På samme måde udnyttes lukkethedsloven i tre delingen af siden, ved at hver af de to dele i siderne er afgrænset fra resten ved at have en anden farve. Vi har gjort vores logo til et landmærke [15], som man altid kan se, og som altid fører en tilbage til vores forside, uanset hvor på websitet man befinder sig. Dette betyder at hvis der skulle opstå en situation hvor brugeren bliver forvirret, kan denne altid gå tilbage til forsiden og starte forfra. Den menneskelige hukommmelse er delt op i korttids- og langtidshukommelsen. I kortidshukommelsen bliver information ikke gemt særlig lang tid, helt ned til få sekunder og op til et par minutter. Derfor bliver man nød til at hjælpe brugeren ved at vise information igen, hvis det er relevant, og ikke bare antage at brugeren kan huske det. I forbindelse med oprettelsen af en opskrift, bliver de 23

32 24 Digital prototype 4 ingredienser, man tilføjer, gemt i korttidshukommelsen. Ved næste trin skal man tilføje trin til opskriften, og korttidshukommelsen overskrives. For at undgå at brugeren går tilbage for at sikre sig, at han har indtastet ingredienser korrekt, eller om der er en ingrediens der ikke bliver brugt, bliver de igen vist på samme skærmbillede, som trinene bliver oprettet. En anden vigtig ting at tage hensyn til, er at mennesker meget hurtigere genkender symboler end tekst og derfor bruger symboler til at navigere efter. For at imødekomme dette har tilføjet billeder og symboler for at illusterer mange af funktionerne. Hvor langt man er kommet i en quest illusteres ved en progress bar frem for bare et tal, og ved alle quests og opskrifter er der et billede, der illustrerer denne. 4.2 Grundlag Denne prototype er lavet ud fra den viden, vi har opnået gennem vores analyse af problemområdet, designprincipper og ud fra de erfaringer, vi opnåede under arbejdet med papirprototypen, og indeholder, de ændringer vi fandt nødvendige ud fra informanternes feedback. Med papirprototypen fokuserede vi på det generelle layout og den overordnede struktur af funktionerne. Med den digitale prototype har vi forsøgt at lave en mere detaljeret prototype, for at kunne diskutere mere konkrete dele af vores system med informanterne. Vi vil bruge prototypen til at få fjernet konkrete elementer i layoutet, som ikke fungerer efter hensigten, ikke er intuitive, eller på anden vis er problematiske for brugerne. Vi vil ligeledes diskutere de tiltænkte funktioner, og hvordan de er tiltænkt i forhold til brugerfladen. Den digitale prototype er ligesom papirprototypen horisontal, og uden egentlig funktionalitet. Til forskel fra papirprototypen er denne prototype skrevet i HTML, og den kører derfor på en computer. Dette er gjort for at gøre prototypen mere detaljeret, og for at få den til at minde mere om det vi har tiltænkt som det endelige produkt. Dette vil forhåbentligt gøre det lettere for informanterne at forestille sig systemet og give os en mere præcis feedback. Der er dog stadigvæk kun tale om en facade, og alt funktionalitet er derfor skrevet direkte ind i prototypen. Dette er gjort så vi bedre kan fremvise funktionerne, uden at det er nødvendigt at lave det endelige system. 4.3 Beskrivelse Designet af prototypen har vi holdt grundlæggende ens i forhold til papirprototypen. Vi har valgt at opdele prototypens sider i fire dele. Dette kan ses på figur F4-1, der viser prototypens forside. Sidens hovedfunktion er placeret midt på siden. I højre og venstre del af siden, har vi placeret en farvet bar, der afgrænser dele af siden i forhold til midterfeltet. Disse indeholder funktioner og information, der er med til understøtte brugen af hovedfunktionen. I toppen af siden har vi placeret en fanebladsbar, som gør det muligt at skifte mellem prototypens forskellige sider. Der er dog nogle få undtagelser til dette, på nogle sider har vi valgt at fjerne de to farvede barer i siderne. Dette er gjort på sider, hvor hovedfunktionen ikke havde behov for ekstra information.

33 4.3 Beskrivelse 25 Figur F4-1: Billede af prototype. Vi lærte fra papirprototyper, at folk ikke helt forstod at navigere rundt i systemet, da nogle ting, som f.eks. highscore, var gemt for langt væk. Dette har vi forsøgt at udbedre, ved at tage de elementer de ikke kunne finde og flytte dem op i fanebladsbaren. Forsiden, er opbygget sådan, at midtersektionen har en søgefunktion, hvor det er muligt at søge på opskrifter. I den venstre sidebar kan man se information relateret til ens bruger, såsom opgaver og venner. I den højre sidebar er det muligt at se highlights af opskrifter, som man kan klikke sig ind på. Foruden at søge efter opskrifter, kan man også finde alle opskrifter under fanebladet Opskrifter. Hvilket fører en til den side, hvorfra man kan vælge de forskellige opskrifter, som er opstillet i listeform i midtersektionen. Den venstre sidebar indeholder her et søgefelt, mens den højre ikke bliver anvendt, men er bibeholdt for at gøre designet konsistent. Det er også muligt at tilføje en opskrift på siden.en opskrift bliver tilføjet til siden gennem et proceduremønster, for at sikre, at opskriften overholder den struktur, der er fastlagt. Denne funktion er dog ikke implementeret i prototypen. Når man er inde på en opskrift, kan man se at opskriftens side bryder med den grundlæggende design, da den kun har den venstre sidebar. Der er her brug for ekstra plads i midtersektionen, så alting kan stå overskueligt. Den venstre sidebar bruges her til et søgefelt, samt information om hvad man kan lave dagen efter med resterne fra den pågældende ret. På opskriftsiden er det muligt at tilføje en kommentar, at give opskriften karakter, tilføje den til sin madplan og fortælle, at man har lavet retten. Den sidstnævnte funktionalitet hører sammen med opgavedelen. Under fanebladet Opgaver kan man få information om ens opgaver, i midtersektionen kan man se informationer om de opgaver, man er tæt på at færdiggøre og hvilke man fornyeligt har gennemført. Man kan desuden i bunden af midtersektionen søge i opgaver. I den venstre sidebar kan man se hvilke opgaver ens venner har klaret. Den højre sidebar indeholder statistik over ens progression i opgaverne. Ved at trykke på en opgave, vil der komme en pop-up med information omkring opgaven. Herfra kan man også tilføje en besvarelse til de opgaver, der kræver det. Andre opgaver opnås mere flydende, ved f.eks. at lave mad. Når en opgave er gennemført, kan man se den i ens gennemførte opgaver, og der kommer en ramme omkring opgavens logo. Rammens farve er baseret på, hvor svær opgaven var. Underfanebladet Temaer finder man opskrifter baseret på et tema såsom årstider eller højtider. Siden er opbygget så man i midtersektionen finder en liste med alle de forskellige temaer, opdelt efter forskellige kategorier såsom årstider. I den venstre sidebar er der et søgefelt over temaer. Der er også en liste af de mest populære temaer, samt hvad månedens tema er. I den højre sidebar kan man se de kommende højtider og klikke sig ind på dem. Foruden madopskrifter, indeholder temaer også information om hvordan man anretter maden og pynter op.

34 26 Digital prototype 4 Under Highscore kan man se sin placering på en highscorelisten, som udgør midtersektionen af siden. I den venstre sidebar er der to funktioner, den første er et søgefelt gør det at søge efter andre brugere af systemet på highscorelisten. Den anden funktion er et filter, der gør det muligt at skifte mellem en highscoreliste der er lokalt blandt ens venner eller globalt for alle. Min side giver et overblik over, hvad man har foretaget i systemet. I midtersektionen kan man finde de opskrifter man har tilføjet på sin madplan. Man kan også følge med i, hvor langt man er nået med forskellige opgaver, og se hvilke man allerede har gennemført. Ud fra ens madplan, kan man generere en indkøbsseddel, som man kan printe ud. I venstre sidebar har man sin venneliste, hvor man kan se lidt information om dem. Der er her også en funktion til at tilføje nye venner. Man tilføjer en ven ud fra indtastning af vennens . Hvis adressen findes i forvejen, sendes en venneanmodning, og ellers bliver brugeren spurgt, om der skal sendes en til vedkommende. I den højre sidebar finder man information om en selv, samt en funktion til at redigere sin profil. 4.4 Afprøvning For at afprøve vores prototype vil vi lave en portotypeafprøvning med informanter, der passer ind i vores målgruppe. Formålet med afprøvningen er at få feedback på funktionaliteten og designet, så vi kan forbedre det til vores endelige system. For at teste funktionaliteten vil vi under interviewet stille nogle opgaver, som den interviewede skal klare. En opgave er f.eks. at finde sin egen placering på highscoren. Vi vil observere, hvad den interviewede gør og stille uddybende spørgsmål til de elementer og funktioner, opgaverne omhandler. Til sidst vil vi bede om en prioritering af, hvor nyttige funktionerne er, så vi kan få en idé om, hvad der er vigtigt for målgruppen Afprøvninger Vi har afprøvet prototypen med tre forskellige informanter. Informanterne består af en studerende på 5. semester, psykologi; en medialogistuderende, på 3. semester og en studerende fra globale forretningssystemer på 5. semester. Vi har nedenfor sammenfattet de vigtigste kommentare fra de tre afprøvninger. For en uddybende gennemgang af de tre afprøvninger, se appendiks B. Brugbarheden af systemet - Overskueligt og rart med fanebladene i toppen. - Nemt at finde rundt i prototypen. - Det er ikke tydeligt for informanterne, hvad opgaver er. - God idé med en søgefunktion på alle sider, men det skal tydeliggøres, hvad man kan søge på. - Mere konsistens i forhold til billedernes størrelser på de forskellige sider. - Svært at overskue, hvad de forskellige billeder hører til. - Ikke tydeligt, at opgaverne på Min side er gennemførte opgaver. Funktionaliteten af systemet - Madplanen bør være bekendt med udløbsdatoerne på ens madvarer. - Indkøbslisten bør kunne eksporteres til telefonen eller printes. - Der bør være en kalender til ens madplan, og til højtiderne under temaer. - For let at snyde med opgaverne. - Lav madplanen intelligent, så den lærer, hvad man ofte spiser. - Lav søgefunktionen brugerspecifik, så man kan tage højde for f.eks. allergi. - Det skal være muligt også at rate billeder og kommentarer. Vurdering af systemet Til sidst spurgte vi dem om, hvad deres vurdering af de forskellige dele af systemet er. Deres vurderinger kan ses i tabel T4-1. Denne fortæller os, hvilke dele af systemet vi burde kigge nærmere på, så vi muligvis kan få det til at passe bedre i forhold til vores målgruppe. Testperson 2 afgav ikke karakterer direkte, og vi har derfor foretaget en vurdering, ud fra hvad der blev sagt.

35 4.4 Afprøvning 27 Opgaver Venner Opskrifter Kommentarer Madplan Temaer Highscore Testperson Nr.1 5 4, ,5 3,5 3,5 Testperson Nr Testperson Nr Gennemsnit 3 3,8 4 4,5 4,2 4,2 2,2 Tabel T4-1: Vurdering af system på en scala fra 1 til Sammenfatning af afprøvningerne Overordnet synes de tre testpersoner, at madplanen med en tilhørende indkøbsliste er en god idé. De vil dog gerne have, at madplanen er intelligent, så den kan lære ud fra ens tidligere valg, og at der er mulighed for at fravælge ingredienser, som man ikke kan tåle eller lide, så de ikke dukker op mellem forslagene til ens madplan. De ønskede også, at der var en måde at eksportere deres madplan/indkøbsliste til deres mobiltelefon, f.eks. via en app. De var også enige om, at temaer er en rigtig god idé. Når det kommer til opgaver, var de alle skeptiske over for konceptet, desuden var navnet ikke forklarende nok i selv, og det skabte derfor forvirring. Under afprøvningen af prototypen brugte vi ordet quests til at beskrive opgaverne, da dette skabte forvirring, valgte vi efterfølgende af ændre dette til opgaver. Efter at informanterne blev forklaret konceptet med opgaverne var to af dem interesseret i at bruge denne funktionalitet. Den sidste mente, at det er for nemt at snyde med systemet, og han ville derfor kun være interesseret i at bruge udfordringer, hvor det var nogle han kendte, som han dystede imod. Generelt synes de det var meget nemt at navigere rundt og finde funktionerne i systemet. Det skyldes i høj grad fanebladene i toppen. De forskellige punkter i menuen skal være mere forklarende, da de blev misforstået af flere informanter. Det skal også gøres tydeligere, hvad der menes med opgaver. Generelt vil det hjælpe med mere forklaring og en hjælpefunktion. De var alle meget enige om, at systemets layout bør minde om Facebook, da de er vant til at navigere rundt her, og er vant til den måde, tingene fungerer på, på Facebook. De synes også, at det kunne være godt med en form for integration med Facebook, så det er muligt automatisk at have sine venner fra Facebook i systemet, hvis de også tilmeldte sig vores system.

36

37 Kapitel 5 Analysen af anvendelsesområdet Følgende kapitel præsenterer vores analyse af anvendelsesområdet [14]. Vi vil primært tage udgangspunkt i de to prototypeafprøvninger vi har lavet og vores analyse af problemområdet. Gennem analysen vil vi kortlægge, hvad der definerer aktørene i vores system, foruden deres sammenhæng med de tiltænkte funktioner. Dernæst vil vi undersøge funktionernes type og kompleksitet. De komplekse funktioner vil blive beskrevet detaljeret for at skabe en bedre forståelse for, hvordan de fungerer. 5.1 Aktørbeskrivelse Aktøreren, madlaveren, er vores primære og eneste aktør i systemet, denne skal bruge alle systemets funktioner. En aktørbeskrivelse af madlaveren kan ses i tabel T5-1. Madlaver Formål: En person, der er interesseret i inspiration til at lave mad, og som godt kan lide at lave at mad med andre. Madlaverens basale behov er at lave mad. Karakteritik: Primært singler i alderen med meget forskellige madlavningsevner, som har erfaring med brugen af internettet. De følger sig ikke motiveret til at lave mad alene. De vil gerne interargere med andre for at få motivation til at lave mad alene. Eksempler: Madlaver A har tiden, men mangler lysten til at lave mad til sig selv, og spiser oftest færdigretter. A synes det er for dyrt med færdigretter og vil derfor gerne i gang med selv at lave mad, men mangler lidt motivation. A er meget konkurrencepræget. B har ikke tiden til at bruge ekstra tid på at lave mad, men vil gerne hurtigt inspireres til at lave mere varieret mad, så B ikke får det samme at spise hver dag. C synes, det er spændende at få lov til at konkurrence med C s venner. C kan godt lide selv at lave mad, man mangler ofte inspiration. Tabel T5-1: Aktørbeskrivelse af madlaveren 5.2 Brugsmønstre Da vores system ikke er en model af en eksisterende problemløsning, besluttede vi at medtage informanter tidligt i forløbet for at få feedback på vores grundlæggende ideer. Til at arbejde videre med disse ideer valgte vi at fremstille prototyper, så vores informanter bedre kunne vurdere, hvordan funktionaliteten i systemet bedst kunne fungere i praksis. Ud fra vores prototyper afprøvninger med vores informanterne, er vi kommet frem til de følgende brugsmønstre. Nogle af disse brugsmønstrene er opstået på baggrund af det, informanterne savnede i prototyperne, dette er derfor blevet implementeret i brugsmønstrene her. Brugsmønstrene Brug en opskrift, Tilføj til madplan, Send udfordring, Tilføj besvarelse, Rediger brugerprofil og Udskriv indkøbsliste er alle beskrevet ved hjælp af billeder 29

38 30 Analysen af anvendelsesområdet 5 fra prototypen, og de kan ses beskrevet i figur F5-1, F5-2 og F5-3. Resten er beskrevet vha. tekst og kan ses herunder. Log ind Man logger ind ved at klikke på Log på, og indtaste de oplysninger, man valgte, da man tilmeldte sig. Tilmelde sig som bruger Under fanebladet Log på, klikker man på linket Registrer og indtaster de nødvendige oplysninger, og klikker herefter på Opret. Log ud Det faneblad, der før hed Log på, hedder nu Log ud. Her klikker man, og så er man logget af systemet. Tilføj og redigere en opskrift Man tilføjer en opskrift ved at klikke på tilføj opskrift, og følger derefter trinene i sekvens for at tilføje en opskrift. Hvis man senere vil redigere en opskrift, gøres dette fra opskriften, hvor der skal være en knap, rediger. Samme sekvens, som da man tilføjede opskriften, vil nu dukke op, og man kan i sekvens redigere de felter, der skal ændres. Find og se opgave Under fanebladet Opgaver kan man søge efter opgaver og udfordring er ved at skrive et eller flere søgeord i søgefeltet. Man kan herefter klikke på en opgave for at få flere oplysninger om den. Accepter udfordring Hvis en af ens venner har sendt en en udfordring, skal man acceptere den, før den er aktiv. Under Opgaver, kan man i højre side se sine udfordringer. Der kan man også acceptere dem, ved at klikke på knappen Godkend. Tilføj ven Under Min side er der en knap, Tilføj ven, som gjorte det muligt at tilføje en anden person til ens venneliste. Når man trykker på knappen, kommer et lille vindue op, hvor man kan søge på en vens brugernavn. Hvis vennen ikke findes i systemet, kan man sende en invitation via mail til vedkommende. Knappen kan ses med en grøn markering, på figur F5-3. Se og sorter highscore Ved at klikke på Highscore kan man se den nuværende highscore. Man har herunder også muligheden for at filtrere i den, ved at klikke på knapperne i venstre side af vinduet. Brug tema Under Temaer kan man klikke sig ind på hvert enkelt tema og se de opskrifter og tips, der er derinde. Oprettelsen af opgaver er ikke et brugsmønster, da vi har afgrænset os til, at det er programmørerne, der opretter opgaverne, og ikke brugerne.

39 5.2 Brugsmønstre 31 Figur F5-1: Brugsmønstre på opskriftssiden. Rød er Bruge en opskrift, grøn er Madplan

40 32 Analysen af anvendelsesområdet 5 Figur F5-2: Brugsmønstre på Opgavesiden. Den hedder her Quest da navnet blev ændret efter prototypen var lavet. Rød er Tilføj besvarelse, grøn er Send udfordring

41 5.2 Brugsmønstre 33 Figur F5-3: Brugsmønstre på opskriftssiden. Rød er Rediger brugerprofil, blå er Udskriv indkøbsliste, grøn er Tilføj ven

42 34 Analysen af anvendelsesområdet Funktioner Følgende afsnit er en komplet funktionsliste for systemet, og beskriver derved den fulde funktionalitet som grundlag for designet. Funktionerne beskrives ved kompleksitet, type og hvilket brugsmønster, de hænger sammen med. De mest komplekse funktioner vil efterfølgende blive beskrevet yderligere. Funktion Kompleksitet Type Anvendes i brugsmønster Opret bruger Medium Opdater Tilmeld bruger Log ind Simpel Opdater Log ind Log ud Simpel Opdater Log ud Opret en opskrift Medium Opdater Tilføj og redigere en opskrift Søg efter en opskrift Simpel Aflæsning Brug opskrift Rating af en opskrift Simpel Opdater Brug opskrift Lavet denne opskrift Simpel Opdater Brug opskrift Tilføj opskrift til madplan Kompleks Opdater/Beregn Tilføj til madplan Søg efter opgave Simpel Aflæsning Find og se opgave Tilføj opgavebesvarelse Medium Opdatering Tilføj besvarelse Send udfordring Medium Opdater/Signal Send udfordring Accepter udfordring Medium Opdater/Signal Accepter udfordring Afgør udfordring Simpel Opdater Tilføj opgavebesvarelse Udfør opgave Kompleks Opdatering Brug opskrift, tilføj opgavebesvarelse Tilføj ven Medium Opdatering Tilføj ven Søg efter tema Simpel Aflæsning Brug tema Fremvis highscore Medium Aflæsning Se og sorter highscore Tabel T5-2: Funktionsliste med kompleksitet og type Hver af de komplekse funktioner er opstillet i separate funktionlister og opdelt i et passende antal underfunktioner. Funktionens formål og forskellige trin er efterfølgende beskrevet. Tilføj opskrift til madplan Kompleks Opdater/Beregn Tilføj opskrift til brugerens plan Simpel Tilføj ingredienser til liste Simpel Sammenlign ingredienser med opskrifter Medium Udvælg mest passende opskrifter Medium Præsenter resultat for bruger Simpel Tabel T5-3: Funktionsliste for tilføj opskrift til madplan Funktionen tilføjer en valgt opskrift til brugerens madplan, hvorefter den tilføjer ingredienserne, der skal bruges til indkøblisten. Ud fra de ingredienser som listen indeholder, udvælger systemet andre opskrifter, som indeholder nogle af de samme ingredienser. Disse præsenteres dernæst for brugeren, som derfor nemt kan tilføje dem til madplanen. Udfør opgave Kompleks Opdatering Registrer opgave udført Simpel Opdatering Automatisk opgave fuldført Medium Signal Opdater point Simpel Opdater titel Simpel Tabel T5-4: Funktionsliste for udfør opgave Funktionen overvåger det relevante område af modellen, og vurderer ændringer i forhold til den aktive brugers ikke klarede opgaver. Hvis der findes opgaver, der bliver påvirket af ændringen, opdaterer funktionen disse opgaver i forhold til de ændringer, der er sket i modellen. Brugeren bliver dernæst tildelt point, hvorefter det nye antal point sammenlignes med titlerne, og den korrekte titel tilføjes til brugeren.

43 5.4 Sammenhæng til problemområdet Sammenhæng til problemområdet I analysen af problemområdet nåede vi frem til et klassediagram, der beskriver strukturen af problemområdet. For at vise at der er konsistens mellem klasserne i problemområdet, og de brugsmønstre, der findes i anvendelsesområdet, har vi opstillet en tabel, der viser, hvilke klasser, de forskellige brugsmønstre arbejder på. Se tabel T5-5. Som det kan ses udfra tabellen, er der ingen klasser fra problemområdet, som ikke hører til et brugsmønster, og ingen brugsmønstre, der ikke hører til mindst en klasse. Som det ses ud fra tabellen er madlaverklassen klart den største i vores system, og det hænger godt sammen med vores tanker omkring problemområdet, da et socialt medie bygger på brugernes interaktioner. Hjælpeklasser, som ingrediens, og ikke har nogle selvstændige brugsmønstre, dette hænger i god tråd med, at de er en del af en større sammenhæng. Klasse Madlaver Relation Madplan Opgave Udfordring Madopskrift Ingrediens Mængde Trin Tema Brugsmønster Tilmelde sig som bruger Log ind Log ud Tilføj og redigere en opskrift Brug en opskrift Send udfordring Accepter udfordring Tilføj besvarelse Rediger profil Se og sorter highscore Tilføj ven Tilføj til madplan Udskriv indkøbsliste Find og se opgave Tilføj besvarelse Find og se opgave Send udfordring Accepter udfordring Tilføj besvarelse Tilføj og redigere en opskrift Brug en opskrift Tilføj og rediger opskrift Udskriv indkøbsliste Tilføj og rediger opskrift Udskriv indkøbsliste Tilføj og rediger opskrift Brug tema Tabel T5-5: Sammenholdning mellem klasser og brugsmønstre

44

45 Kapitel 6 Arkitektur I dette kapitel vil vi starte med at gennemgå kriterierne for vores system. Dernæst vil vi gennemgå den ideelle arkitektur for vores design, vores valgte tekniske platform og herefter den arkitektur, som vi har i vores implementering. Dernæst vil vi lave en prioritering af funktionaliteten i systemet på baggrund af kriterierne og hvor meget tid, der er til rådighed til implementeringen. Til slut vil vi gennemgå og forklare vores modelkomponent, og hvorfor den ser anderledes ud end vores model fra problemområdet, og funktionskomponenten, hvor vi vil uddybe de funktioner, der ikke uden forklaring kan laves. Komponenterne er kun lavet for de dele af systemet, vi har prioteret at implementere. Designet tager udgangspunkt i både problem- og anvendelsesområdeanalyserne. Designet, der er vist i dette kapitel, er det design vi har implementeret i systemet. 6.1 Kriterier Som grundlag for systemarkitekturen har vi vurderet, hvordan vi vil prioritere forskellige egenskaber ved arkitekturen. Ved at definere hvilke områder vi vil fokusere på, har vi mulighed for at tage valg i forbindelse med udarbejdelsen af systemet, som gør det svære at opfylde visse krav. Vi har således mulighed for at lave et system uden væsentlige svagheder i de betydningsfulde områder, som dog måske ikke lever op til de mindre vigtige kriterier. Det er nødvendigt at foretage en prioritering, da flere af kriterierne modvirker hinanden. F.eks. vil det være svært at lave et system, der både er effektivt og flytbart, da effektiv brug af platformen ofte kræver brug af platformspecifikke funktioner. Derudover vil et system, der prioriterer mange kriterier højt, ofte også kræver flere resurser at udvikle, da flere overvejelser indgår i designet. Vores vurdering af designkriterier, i forhold til vores system, kan ses i tabel T6-1. Brugbart Sikkert Effektivt Korrekt Pålideligt Vedligeholdsbart Testbart Fleksibelt Forståeligt Genbrugbart Flytbart Integrerbart Meget vigtigt Vigtigt Neutralt Mindre Vigtigt Irrelevant x x x x x x x x x x x x Tabel T6-1: Vores priotering af kriterierne Vurderingen er lavet ud fra hvilke kriterier, vi fandt relevante fra vores tidligere analyse. Samt hvad vi forventer er muligt at implementere i den planlagte projektperiode. Følgende argumentation er grundlaget for vores prioritering af de forskellige kriterier. 37

46 38 Arkitektur 6 Brugbart: Brugbart er vurderet meget højt, da vi vurderer at brugbarheden af systemet, er vigtigt for at vi kan motivere brugerne til at anvende systemet. Hvis systemet ikke er tilpasset brugernes ønsker, kan det tænkes at de vil forlade det eller ikke invitere andre til at blive brugere. Sikkert: Da vi er i besiddelse af private informationer om brugerne, er det vigtigt at disse informationer opbevares sikkert. Samtidig er konkurrence imellem brugerne en vigtig del af system, og vi skal derfor sikre at det ikke er muligt at snyde ved f.eks. at ændre ens point eller titel. Effektivt: Denne er vurderet lavt, da vi ikke har erfaring med udvikling af webapplikationer, og ikke har tid nok i projektforløbet til opnå den nødvendige viden for at anvende den tekniske platform optimalt. Korrekt: De formulerede krav er udarbejdet på baggrund af den viden, vi har fået fra vores informanter. Vi mener dog ikke denne er særlig vigtig, da det ikke er nødvendigt, at vi overholder alle vores specifikationer, for at have et system der fungerer efter hensigten. Pålideligt: Vi har sat pålideligheden til vigtig, fordi vi mener, det er vigtigt, at systemet altid opfører sig på samme måde, for at fastholde brugerne, og minimere risikoen for, at de tror, at der sker snyd i systemet. Det er f.eks. vigtigt, at alle brugere opnår det samme antal point for gennemførslen af den samme opgave. Vedligeholdsbart Da systemet ikke skal anvendes efter projekt forløbet, har vi vurderet at systemet ikke behøver at være vedligeholdsbart på længere sigt. Testbart: Vi vurderer testbart som vigtigm da vi gerne vil have et pålideligt system, som opfører sig efter hensigten. Derfor vil vi gerne være i stand til, at kunne gennemteste vores system ordentligt. Fleksibelt: Da systemet som udgangspunkt ikke skal anvendes efter projektforløbet, har vi valgt at sætte fleksibelt til neutral, fordi selvom systemet ikke skal anvendes bagefter, så må systemet gerne have lidt fleksibilitet, da man ikke kan forudse om der sker nogle forandringer i fremtiden, hvor det kunne være godt at have denne fleksibilitet. Forståeligt: Denne er vurderet højt, da det i vores projektforløb er nødvendigt at skifte mellem forskellige udviklere. Genbrugbart: Vi har ingen planer om at udvikle lignende systemer i dette projektforløb, og vurderer derfor ikke det er nødvendigt at gøre dele af systemet genbrugbart. Flytbart: De platformafhængige dele af systemet er centraliseret på en server, det er derfor ikke nødvendigt at tage hensyn til dette kriterium. Integrerbart: Da nogle af vores informanter har ønsket at systemet kunne integreres med andre sociale medier, har vi vurderet integrerbart neutralt Sammenfatning af kriterier Vi vil forsøge at gøre systemet brugbart ved at inddrage de erfaringer vi har fra vores prototyper sat sammen med vores viden omkring designprincipper [15]. Måden vi vil afprøve, om vi har formået at gøre dette, er gennem en usabilitytest, som vil afdække mange af de brugervenlighedsproblemer, der findes i systemet. Vores tekniske platform giver os muligheden for at integrere unittestning i vores system, så unittestning kan blive foretaget samtidig med, at vi programmerer vores system. Ved at gennemteste vores system, vil vi også sikre en høj pålidelighed, da systemet vil reagere på den måde, vi ønsker det. I gennem projektforløbet har vi arbejdet evolutionært, men også logisk, og vi har derfor forsøgt at gøre vores design enkelt gennem brug af metoderne fra Objektorienteret Analyse og Design [14].

47 6.2 Overordnet arkitektur Overordnet arkitektur For at realisere systemet ønsker vi at gøre brug af en overordnet arkitektur, der tager udgangspunkt i arkitekturmønstret grundarkitektur kombineret med mønstret klient-server arkitektur, der er opbygget efter distribueret præsentation [14]. Denne struktur er valgt, da vi har et ukendt antal brugere, som alle skal bruge den samme funktionalitet. Alt data skal også være konstant tilgængeligt for alle brugere, så selvom en bruger logger af, skal dennes profil stadig kunne ses af andre brugere. Vi vælger derfor at samle dette centralt på en server. Funktionaliteten bliver også holdt på serveren, da den derved er nemmere at opdatere og vedligeholde. Dette hænger også sammen med at et af vores krav til systemet, var at det skulle kunne afvikles gennem en webbrowser. For at sikre kompatibilitet med så mange forskellige webbrowser og styresystemer som muligt er det også nemmere at afvikle funktionerne på serveren, og så kun levere en brugerflade gennem webbrowseren. Dette er der standardiserede metoder til. Arkitekturen kan ses på figur F6-1. Figur F6-1: Den overordnede komponentarkitektur

48 40 Arkitektur Teknisk platform Valget af teknisk platform til at realisere arkitekturen er faldet på ASP.NET MVC Framework 3 hvor vi skriver i C#. Platformen er et webapplikations framework der bygger på ASP.NET og implementerer Model-View-Controller mønsteret. Model-View-Controller mønsteret som det bruges i ASP.NET MVC er illustreret på figur F6-2. Figur F6-2: MVC i ASP.NET Der interaggeres med systemet gennem en browser, der får tilsendt HTML kode fra viewkomponenten. Input fra browseren sendes gennem URL s til controlleren, der udfører funktionskaldene for at ændre på modellen og præsentationsmodellen. ASP.NET MVC 3 giver mulighed for at vælge i mellem flere forskellige View engines. En view engine genererer HTML-kode så brugergrænsefladen kan fremvises for klienten. Vi har valgt viewenginen Razor, der er den nyeste og syntaksen er enkel og hurtig at lære. View-enginen abonnere på præsentationsmodellen(via observermønsteret) som er bestemt af controlleren ud fra modellen, og får derfra alt relevant data der er gemt i modellen. Denne tilgang betyder, at viewkomponenten aldrig tilgår modellen direkte, og er derfor ikke direkte afhængig af hvordan modellen ser ud. I modelkomponenten bruges Entity-frameworket, der er et object-relational mapping (ORM) framework. Det understøtter en Code-First tilgang, hvilket betyder at hele databasen kan genereres og tilgåes ud fra klasserne i modellen, uden at programmøren arbejder direkte med databasen [16]. Derfor kan vi under udviklingen af systemet abstrahere fra databasen og tilgå data, som var det gemt i klasser i stedet for tabeller i en database. Det kræver dog at, alle klasser i modellen har en id-attribut der bruges som primær nøgle i databasen. 6.4 Justering af komponentarkitektur Ud fra platformens opbygning er der foretaget justeringer til komponentarkitekturen. Denne arkitektur kan ses på F6-5.

49 6.5 Prioritering af elementer i implementationen 41 Figur F6-3: Den endelige overordnede komponentarkitektur 6.5 Prioritering af elementer i implementationen Da vi i dette projekt ikke har resurser til at implementere det fulde system, har vi valg at prioritere nogle funktioner højere end andre og implementere disse for at vise de vigtigste elementer i vores system. Vi har vurderet, at de vigtigste funktioner er vores opgavesystem, samt indkøbsog madplanlægningsfunktionerne. Derfor vil vi prioritere disse dele af systemet højt. For at disse kan implementeres, skal opskrifterne og brugerne i systemet også laves, da de er en væsentlig del af opgaverne og planlægningen af mad. Den tredje store funktion, temaer, har vi valgt at afgrænse os frafgrænse os fra. Selvom vores interviews har vist funktionen er interessant for vores system, vurderer vi, at temaer er forholdsvis triviel at implementere og bare tager tid, som kunne være bedre brugt på at få lavet de andre funktioner. Vi har desuden valgt at afgrænse of fra nogle af de mindre og mere trivielle funktioner, som rank af brugere, kommentarer til opskrifter, redigering af opskrifter og oppyntningsopskrifter.

50 42 Arkitektur Modelkomponenten På bagground af vores priotering og den tekniske platform, har vi med udgangspunkt i problemområdet, udarbejdet en modelkomponent for systemet F6-4. Denne indeholder de forskellige klasser og deres attributter. Modelkomponenten er specificeret for den del af systemet, som vi har prioteret af implementere, se afsnit 6.5. Figur F6-4: Modelkomponenten for systemet Vores modelkomponent består af 13 forskellige klasser. Hver af disse klasser har et id, genereret af den underliggende database, som bruges til associeringer mellem de forskellige klasser der har en associering. Da alle klasserne har id, har vi valgt ikke at tage dem med som attribut, da deres brug som sagt kan ses som associeringer mellem klaserne. Foruden associeringer, gøres der brug af aggregeringer i modelkomponenten. Disse opstår i det at mange af klasserne har referencer til andre klasser. Dette kan både være enkelte referencer, som mellem definition og opgave. Her er opgave en aggregering af definition, da den har en reference til et enkelt objekt af klassen opgave. Omvendt er definition også en aggregering af opgave, da opgave indeholder en liste med objekter af klassen definition. Dette kan lade sig gøre, da de for hinanden i implementeringen kun er en reference af et objekt af den anden klasse. Sammenlignet med vores model af problemområdet, har vi lavet en række ændringer i modelkomponenten. Disse ændringer er sket på grund af den tekniske platform, samt vore prioritering. I forhold til prioritering har vi valgt blot at fjerne de klasser, som ikke længere er behøvet, f.eks. er Tema ikke realiseret i Modelkomponenten. Vi har valgt at implementere opgaver, ved at dele opgave klassen op i tre klasser, for bedre at indkapsle data, samt lave klassen MEvent, der gemmer information om hvilke funktioner brugeren har anvendt på siden. Madlaverens opgaver kan derefter opdateres, ud fra de MEvents der er gemt på madlaveren. For at gøre det nemmere at finde opskrifter ud fra en ingrediens, har vi oprettet klassen Forbindelser, denne har id erne for en ingrediens samt den opskrift den hører til. Ved at se på de forbindelser en Ingrediens indeholder, kan vi derved hurtigt, finde frem til de opskrifter den indgår i.

51 6.7 Controllerkomponenten Controllerkomponenten Controllerkomponenten er specificeret for den del af systemet, som vi har prioriteret af implementere, se afsnit 6.5. Den overordnede struktur af controllerkomponenten, bestemmes af den tekniske platform, der adskiller logik fra data ved udelukkende at bruge placering på funktionsklasse mønstret [14]. Controllerkomponenten er derfor opbygget af en samling af, for det meste, usammenhængende klasser, der har hver deres ansvars område. Metoderne på klasserne bliver kaldt fra det overliggende view lag, og sikrer at tilgangen til modellen sker korrekt. Der er derfor ikke sammenhæng mellem de forskellige klasser i controllerkomponenten, da hver klasse udfører en afgrænset opgave, og alt data i modellen er tilgængelig for alle controllers. Der er dog en undtagelse i form af klassen Hjaelpecontrolleren, der indeholder metoder, der bruges flere steder i systemet og derfor gemmes på en controller, som så aggregeres i de klasser, der har behov for at anvende de pågældende metoder. Figur F6-5: Den overordnede komponentarkitektur Controllerne indeholder ved oprettelse en række standard funktioner som vi har valgt at gøre brug af, og udvide efter vores behov. Disse er metoderne Index, Create og Details. Index er klassens hoved metode og den der kaldes hvis ikke andre specificeres. Create returnerer et view beregnet på at oprette en ny instans af objektet, og Details returnerer et view med en opstilling af en instanr af den underliggende modelklasse der er gemt i databasen. Da dette er funktioner vi anvender forskellige steder i systemet, valgte vi at anvende de eksisterende fremfor at oprette nye. Ligeledes har vi valgt at bibeholde den automatisk generede Account controller, som indeholder metoder der gør det enkelt at opstille et login system med forskellige brugere Accountcontroller Accountcontrolleren udfører identifikation af brugeren, og sikrer at systemet ved hvilken bruger der er logget ind. Foruden dette tillader den brugerne at ændre deres kodeord. Vi valgte at bruge Account controlleren, da det var hurtigere end at lave et login system selv, som vi desuden ikke havde tid til at gøre lige så sikkert. Dette har dog gjort, at man må oprettes en madlaver i systemet som korrespondere med brugeren, for at opbevare den information vi har behov for Hjaelpecotronller Hjaelpecontrolleren indeholder metoder, der deles af flere controllere i systemet, for ikke at implementere dem mere end et sted, valgte vi derfor at lave en ekstra controller som andre kan instantiere. Vi har derfor kun én implementering af metoderne og de andre controllers kan stadig anvende dem frit.

52 44 Arkitektur 6 Navn: FindMestBrugte Kategori: Beregning Formål: Find de id er der optræder flest gange i en liste. Inddata: Liste af tal, antal. Betingelser: Effekt: En liste med de mest brugte retuneres, Involverede objekter: Hjaelpecontroller Udløsende hændelser: FindForslag Madlavercontroller Madlavercontrolleren bearbejder alt information omkring og mellem Madlaver klasserne i modellen. I denne controller anvendes Details til at fremvise madlaverens profilside. Navn: EkstraIngredienser Kategori: Opdatering Formål: Tilføje ekstra ingredienser til en madlavers indkøbsliste. Inddata: Maengder og ingredienser. Betingelser: Maengderne og ingredienserne indeholder ikke ugyldig data, og der er logget en madlaver ind i systemet med et gyldigt brugernavn. Effekt: De ekstra ingredienser ligges til madplanden uden at blive gemt i databasen, hvis de findes på indkøbslisten opdateres de eksisterende mængder. Involverede objekter: Madlaver, Maengder og Ingredienser. Udløsende hændelser: View Navn: FindIngredienser Kategori: Aflæsning / Beregning Formål: Finde og sammenlægge de indgredienser som opskrifterne på madplanen indeholder, samt dem brugeren selv har tilføjet. Inddata: Opskrifter, Maengder og Ingredienser Betingelse: Brugeren er logget ind og åbner sin profilside. Effekt: Der udregnes en liste af ingredienser, som returneres til details metoden. Involverede objekter: Madlaver, Opskrift, Maengder og Ingredienser Udløsende Hændelser: Details Navn: AddFriendRelation

53 6.7 Controllerkomponenten 45 Kategori: Opdatering Formål: Tilføje en relation på en madlaver, til en anden madlaver. Inddata: Madlaver, brugernavn. Betingelser: Der eksisterere to madlavere, med de angivede informationer. Effekt: Der oprettes et nyt objekt af klassen Relation, der tilføjes begge madlavere. Involverede objekter: Madlaver, Relation. Udløsende hændelser: AddFriend Homecontroller Homecontrolleren indeholder logik for de views, der ikke er knyttet til en funktion, i vores tilfælde er dette dog kun forsiden. Vi har derfor blot bibeholdt Index metoden, og implementerer forsidens minimale logik der Opskriftcontroller Opskriftcontrolleren kan oprette opskrifter ved brug af metoderne Create, TilfoejIngredienser og TilfoejTrin. Herefter kan opskriften vises med Details, hvis brugeren har indtastet en ny mængde i viewet kaldes OmregnMaengde, der så skalerer opskriften. OpskriftLavet tilføjer et opskriftlavet event til madlaveren, og index fremviser den samlede liste af opskrifter. Navn: OmregnMaengde Kategori: Beregning Formål: At omregne mængderne i en opskrift efter et bestemt antal personer. Inddata: Opskrift, nytantal. Betingelser: At antal personer er ændret i viewet. Effekt: At maengderne på viewet ændre sig i forhold til de nye værdier. Involverede objekter: maengde, opskrift. Udløsende hændelser: View Opgavecontroller Opgavecontrolleren bruger systemets events til at beregne hvilke opgaver, madlaveren har udført, samt opdatere deres status løbende. Index returnerer et view med de opgaver systemet indeholder, samt information om hvilke opgaver madlaveren har klaret. Details returnerer viewet for en enkel opgaver, med dens information og status hos den madlaver der er logget ind i systemet. Navn: RegistrerOpgave Kategori: Opdater Formål: Tilføje en igangværende opgave til den korrekte madlaver. Inddata: OpgaveId, Madlaver

54 46 Arkitektur 6 Betingelse: Der fremvises en opgave i viewet der ikke er tilføjet madlavarens aktive opgaver. Effekt: Der tilføjes et Opgavestatus objekt til madlaveren. Involverede objekter: Madlaver, Opgave, OpgaveStatus Udløsende Hændelser: UpdateProgress Navn: UpdateProgress Kategori: Opdatere / Beregning Formål: At udregne hvor langt en madlaver er kommet med en opgave, og opdatere modellen efter behov. Inddata: OpgaveId, Brugernavn Betingelse: Effekt: Madlaverens opgave med OpgaveId bliver opdateret i forhold til de events madlaveren har udført. Involverede objekter: Madlaver, Opgave, Event Udløsende Hændelser: Details Navn: OpgaveKlaret Kategori: Opdatering Formål: Opretter et event for en klaret opgave, på den tilhørende madlaver. Inddata: OpgaveId, Brugernavn Betingelse: Madlaveren har et Opgave objekt med attributten progress på 100, og åbnet den i viewet. Effekt: Der tilskrives et nyt opgaveudført event til madlaveren. Involverede objekter: Madlaver, Opgave, MEvents. Udløsende Hændelser: Details. 6.8 Viewkomponent Strukturen af viewkomponenten er givet af den tekniske platform. Delene i viewkomponenten genrerer HTML kode der kan vises af en browser ved hjælp af standard HTML og CSS, standard C# kode og indbyggede C# hjælpefunktioner, der er indbygget i ASP.net MVC 3.0. For at skabe dynamik på brugerens side bruges JavaScript og jquery, som er et stort bibliotek til JavaScript. Komponenten består overordnet af tre dele; et layout, en række indholdsfiler og nogle tilknyttede hjælpefiler. Layoutet definerer, hvordan siden generelt ser ud, dvs. det er her, de ting, der går igen på alle sider, bliver defineret, såsom menuen, baggrunden og siden logo. De tilknyttede hjælpefiler er javascript, og CSS-filer. Her laves de styles der går igen på sider og de JavaScript scripts, der bruges. Indholdsfilerne er de filer, der genererer det primære indhold på hver side. I systemet bruger vi primært fem forskellige af disse indholdsfiler, se tabel T6-2. I kode 6.1 ses et eksempel på koden fra en indholdsfil. Syntaksen er simpel og bestemt af Razor View Engine. indikerer, at der skrives C# kode, resten er normal HTML kode. For at fremvise et view kaldes en funktion i controllerenm der returner viewet. Når dette gøres, kan der samtidig sendes data med til viewet, enten gennem en ViewBag der indeholder data der bliver genereret på

55 6.8 Viewkomponent 47 Fil HomeIndex MadlaverDetails OpskriftIndex OpskriftDetails OpgaveIndex Indhold Viser velkomstsiden Viser en madlavers profil Viser en liste over systemets opskrifter samt en opskriftssøgefunktion Viser detaljerne for en opskrift Viser en liste over systemts opgaver og giver mulighed for at se detaljer om dem på samme side Tabel T6-2: Liste over de forskellige indholdsfiler i viewkomponenten runtime eller i gennem en model. I kodeeksemplet er Model en opgave fra modellen. I linje 1 køres en foreach løkke på modellen. Da modellen her er opgaver itereres der gennem alle opgaver i systemet, og opgavens billede, navn, beskrivelse og pointværdi vises i hver sin række i en tabel. Viewet, der bliver genereret udfra kode 6.1 og fremvist i en browser kan ses på figur F6-6. foreach ( var item in Model ) 2 { 3 <tr > 4 <td > 5 <img src Billede alt Navn width =40 px /> 6 </td > 7 <td > ActionLink ( item.navn, " Index ", new { id = item. OpgaveId }) 9 </td > 10 <td > DisplayFor ( modelitem => item. Beskrivelse ) 12 </td > 13 <td > DisplayFor ( modelitem => item.ævrdi ) 15 </td > 16 </tr > 17 } Listing 6.1: Opgave:Details.cshtml, linje Figur F6-6: Del af et view fremvist i Internet Explorer

56

57 Kapitel 7 Implementering I dette kapitel vil vi fremvise implementeringen af systemet, og kort beskrive dens opbygning i forhold til den digitale prototype. Dernæst vil vi beskrive og diskutere implementeringen af de mest spændende funktioner i vores system, samt de valg, der er taget under implementeringen. Desuden vil vi diskutere muligheder for forbedring og udvidelse af funktionerne. For at den fulde kildekode, se appendiks E. 7.1 Systemet Det udviklede system følger de samme overordnede designprincipper, som vi anvendte i udviklingen af den digitale prototype. Den overordnede struktur er derfor lavet på samme måde med en tredeling af siderne, og den vigtigste information i midten af siden. Vi har dog fokuseret på at udvikle systemets funktioner, fremfor at sikre, at der er taget hånd om detaljerne. Et eksempel på det implementerede system kan se på figur F7-1. Figur F7-1: Opgavesiden fra systemet I forhold til prototypen har vi her ikke implementeret sorterings- og søgefunktionen, der ses i bunden af opgavesiden, i den digitale prototype. Indholdet af venstre del af siden er blevet skiftet ud med en forklaring af opgaver, da vi tidligere har set, at vores informanter har svært ved at forstå 49