Bilag 1, Desk research/moodboard

Bilag 1, Desk research/moodboard

Bilag 2, Chris-Ann/Noter

Bilag 3, SWOT Strengths Internal Weaknesses Høj værdi institution Velorganiseret Frivillige Miljø Gratis Læring Dårlig hjemmeside Umoderne Nørdet Afhængig af offentlig støtte Forældet teknologi Dårlig markedsføring Uden fokus på turister Opportunities External Threats Tiltrække bredere kundekreds ved fornyelse Udvikkle app Bedre markedsføring Nye kunder turister Økonomi Konkurrence Teknologien udvikler sig hurtigt: IN i dag er YT i morgen.

Bilag 4, TOWS

Bilag 5, Stakeholders

Bilag 6, Projektbeskrivelse

Bilag 7, Oplevelsesmatricerne

Bilag 8, Brainstorm

Bilag 9, Bartle player types

Bilag 10, Ideproces

Bilag 11, Kampagnesite

Bilag 12, Logo størrelser

Bilag 13, Promotionvideo/Inspiration Big Kahuna Mobile Game Promotion Video https://www.youtube.com/watch?v=wbuzf0obr98 Colchester Castle Augmented Reality App Promo https://www.youtube.com/watch?v=sfx6l1vc4ci

Bilag 14, Storyboard

Bilag 15, Systemudviklingsmetoder Systemudviklingen (Busch et al, 2011, s.131) er sket på baggrund af kravene (Bilag 7, Projektbeskrivelse) til de enkelte systemer, Appen er udviklet ved brug af den Agile Udviklingsmetode (Busch et al, 2011, s.141). Kampagnesiden/hjemmesiden er lavet ved at bruge, Smid væk-prototyper metoden. (Busch et al, 2011, s.136). App: Vi startede med research på andre app s som henvender sig til samme målgruppe som vores, ud fra den research og de krav vi havde til appen, lavede vi brainstorm over hvad vi skulle have med i vores app. Som det fremgår af den Agile metode, så er kunden en vigtig del af processen, og derfor er udviklingen sket ved ofte at have kontakt med kunden/målgruppen. På den måde har vi løbende kunne tilpasse appen efter deres feedback. Flere dele af systemet til appen blev leveret af vores undervisere, så som Vuforie pakken, SDK pakken, Enkelte scripts, og den user interface vi skulle bruge. Samt at vi selv købte en færdiglavet 3D model på Unity store. Og på den måde har det været muligt at få lavet noget brugbar software hurtigt og få det testet hos kunden, som den agile metode går efter. Dette har i vores tilfælde givet en udfordring, den består af, at hvis der har været problemer med systemet, så som at vores app ikke kan håndterer at vise vores AR video 2 gange, så har vi ikke haft nok kendskab til den underlæggende teknologi/software til at kunne rette det. Så selv om det er hurtigt og nogle gange effektivt at bruge færdiglavet dele som kommer ude fra, så kan det også give problemer, og i værste fald forsinke systemudviklingen. Website: (Bilag 19, Brugertests) Som ved appen lavede vi research på hjemmesider som henvender sig til samme målgruppe som vores, og ud fra den og kravene til hjemmesiden (Bilag 7, Projektbeskrivelse), kom vi frem til hvilke funktioner hjemmesiden skulle have. Derefter lavede vi en del prototyper af designet af hjemmesiden i Adobe Potoshop og Adobe Illustrator, hvor flere af dem blev kasseret/smidt væk. Da det endelig design var fundet, blev hjemmesiden kodet ved hjælp af HTML5, Css og php, og der efter testet hos målgruppen.

Grunden til at vi har valgt den agile metode til appen, er fordi vi som nævnt fik leveret flere dele af systemet, som færdige løsninger. Og det er nemmere at integrere disse pakker via den agile metode, da der ikke er en for stor skemalagt proces, som implementeringen af en af disse pakker kan komme i vejen for. Men også fordi den er så tilpasningsvenlig og det er vigtigt da kravende til systemet kan skifte fra det ene øjeblik til det andet, alt efter hvordan målgruppen reagerer på systemet når de tester det. Smid væk metoden blev valgt til udviklingen af kampagnesiden, da den er meget fleksibel agil (Busch et al. 2011, s.141), det er nogle af de andre metoder også, men med denne metode har vi kunne lave flere prototyper, hvilket vi har gjorte i forhold til designet/udseendet, hvor vi hver især lavede vores forslag, og til sidst kunne sammenlægge de dele vi mente passede bedst til målgruppen og kravene.

Bilag 16, Use Case og Scenarier Use Cases og Scenarier er udviklet via den metode som er beskrevet i bogen: Kommunikation i Multimediedesign. (Busch et al. 2011, s.174) Brugerscenario af App. Brugerprofil: Jessica Rabbit Mål: At, komme ind i quizzen, og tage den. Hændelse som starter scenariet: Jessica får leveret en tablet, hvor Junior Ranger Explorer appen er åbnet, hun bliver bedt om at finde ud af hvordan hun kommer ind og tager quizzen. Scenario Jessica har ikke haft denne app i hånden før, og ser på skærmen lidt forundret. Men hurtigt finder hun start knappen og trykker på den, derfra kommer hun ind i en menu hvor hun ser 2 punkter, explorermap og Info. Hun trykker på info, og kommer ind og får nu vist på skærmen hvordan appen fungerer. Hun ser at hun derfra kan gå ind på explorermap, og dette gør hun. En 3D verden kommer frem på skærmen, hun ser to objekter der glimter. Hun går hen til det ene objekt, trykker på det, og en AR oplevelse dukker op. Da AR oplevelsen er slut kommer hun tilbage til explorermap, og hun kan nu se at der er dukket en quiz knap op. Hun trykker på den, bruger den viden hun fik via AR oplevelsen til at besvare spørgsmålene i quizzen, hun får en scorer, og har nu løst opgaven.

Brugerscenario af Kampagnesite. Brugerprofil: Jessica Rabbit Mål: At få skrevet sig op til et nyhedsbrev. Hændelse som starter scenariet: Jessica har fra en af sine klasse kammerater hørt om en ny oplevelse på The Bay Model Visitor Center, og hun vil derfor gerne se hvad det er. Hun går derfor først ind på BMVC hjemmeside, hvor hun finder et link til kampagnesiden. Da hun kommer ind på siden starter promotion videoen, og hun ser den. Scenario Da videoen slutter, er hun helt opslugt om ideen om at besøge stedet, og hun vil derfor gerne finde ud af hvor hun kan skrive sig op til et nyhedsbrev. Hun kan se at det ikke er muligt på forsiden, og hun går derfor ind på info siden. Fordi hun mener at der må hun kunne finde noget information om hvordan man får sig skrevet op. Hun ser hurtigt teksten nyhedsbrev, samt en formular hun kan udfylde, dette gør hun, og hun er nu skrevet op til nyhedsbrevet. Use Case: At få sig skrevet op til nyhedsbrevet. Præ-betingelser: En person er inde på kampagnesiden Post-betingelser: Finde hvor man skriver sig op til nyhedsbrevet samt at få sig skrevet op. 1. Person trykker på info knappen 2. Denne fører personen til info forsiden 3. Personen ser feltet hvor man kan indtaste sin email adresse 4. Personen indtaster sin email adresse 5. Personen trykker send 6. Personens email er nu skrevet op i en database

Bilag 17, Brugertests AppBrugertest WebBrugertest

Bilag 18, Ganntkort

Bilag 19, Kontrakt Gruppekontrakt Navn på medlemmer: Kim Morten Nissen og Camilla Moberg Jørgensen Arbejdsform På skolen, privat. Individuelt, gruppe. Fravær Ikke eksisterende, accepteres ved sygdom. Man har pligt til at melde afbud, hvis man ikke kan komme Kommunikation E-mail, sms, mundtlig Deadlines SKAL overholdes! Der bliver løbende uddelegeret arbejdsopgaver. Mødestruktur Dagsorden Hjemmeopgaver Refleksion Evaluering