Vad kan ifan Monitor göra? 1.2 Vad systemet består

Transkript

1 INNEHÅLL 1.0 BAKGRUND Vad är ifan Monitor? 2.0 SYSTEMÖVERSIKT Här beskrivs systemet och dess olika delar 2.1 REGISTRERING Hur information om användarna lagras 2.2 KIOSKEN Användarnas gränssnitt mot ifan Monitor 2.3 PHIDGETS & JAVA Val av implementationssätt 3.0 DESIGNPROCESSEN Hur och varför systemet ser ut som det gör 4.0 VISUALISERING Förklaring om hur besökrna på hultsfredsfestivalen visualiseras på kiosken 5.0 FRIEND-O-FINDER Funktion för att hjälpa besökarna att hitta sina vänner 6.0 BAND-O-METER Funktion för att avgöra likhet mellan besökare och artisters musiksmak Vad är ifan Monitor? 1.0 Bakgrund Tanken med informationspresentationen är att på ett så enkelt sätt som möjligt ge besökaren en ögonblicksbild av festivalområdet och låta användaren själv på ett intuitivt sätt ta till sig informationen, och själv avgöra vad den kan betyda. Ingen vill ha ett system som i sig blir ett problem, är svårt att interagera med och säger åt en vad man ska göra. Varför? 1.1 Scenario Tänk dig att du står i folkvimlet på en festival. Du är lerig och uttråkad, och vet inte var du ska ta vägen. Du har kommit bort från dina kompisar, och trots att ni bestämt mötesplats, finns de inte att finna någonstans. 'Okay, jag kan ha kul själv' tänker du, och börjar fundera på vad du ska hitta på, vilket band du kan titta på. Men vad spelas just nu? Och är det den typ av musik du gillar? Du vet att Metallica ska spela senare under kvällen, men tills dess är det ett par timmar. Du bestämmer dig för att gå och äta och ta en öl istället, så du börjar plöja dig igenom folkmassorna för att hitta någon utav gatuköken. Scenariot belyser en av de absolut viktigaste frågorna man kan ställa på en festival: Var är det roligast just nu? Var ska jag gå nu? Tanken med ifan Monitor är att skapa ett slags informationssystem med översikt över festivalområdet, för att på så sätt kunna förhöja upplevelsen av festivalbesöket. Vad kan ifan Monitor göra? 1.2 Vad systemet består av Tanken med informationspresentationen är att på ett så enkelt sätt som möjligt ge besökaren en ögonblicksbild av festivalområdet och låta användaren själv på ett intuitivt sätt ta till sig informationen, och själv avgöra vad den kan betyda. Ingen vill ha ett system som i sig blir Figur 1. ifan Monitor är ett anagram av information för att spegla informationsflödet. ett p roblem, är svårt att interagera med och säger åt en vad man ska göra. Informationen presenteras på en kiosk - en bankomat-liknande maskin. Enkelt sett består kiosken av en skärm med 6 knappar. När besökaren kommer fram till kiosken, loggas denne automatiskt in med hjälp av RFID-taggen i festivalarmbandet. Användaren kan sedan välja att titta på det som kan intressera denne genom att visa den information som de sex knapparna representerar: Densitet - visar folktätheten. Folk - var alla besökare är. Vännner - de specifika personer besökaren lagt till. Band-O-Meter - vilka band som spelar och hur lik deras musik är användarens musiksmak. Mat/öl - visar aktuella köer för de olika mat och ölställena. WC - visar toalettköer för områdets toaletter.

2 JFrame FullFrame Portal RFIDEventListener ActionListener TCPClient RFID _IPhidgetRFIDEventsAdapter Figur 2. Klassdiagram över ifan-portalen där användarna matar in namn och favoritartister Hur allt hänger ihop 2.0 Systemöversikt ifan Monitor består ett fysiskt gränssnitt och två applikationer; en registreringsstation som kan användas för att fylla i personuppgifter när man löst sin biljett och en kiosk som finns utplacerad i flera exemplar på festivalområdet. Big Brother - vad lagras? 2.1 Registrering Registreringen är en enkel applikation där besökaren identifieras med hjälp av RFID-taggen som finns inuti festivalarmbandet. När besökaren loggats in kan den fylla i uppgifterna eller avbryta registreringen. När alla uppgifter fyllts i skickas informationen över en TCP-anslutning till databasen där den lagras. I Figur 2 visas ett förenklat klassdiagram över registreringsapplikationen. Kiosken, såväl som registreringen, visas i fullskärmsläge. Fördelen med detta är att uppritningen av komponenter kan hanteras effektivare samt att upplösningen kan kontrolleras. All uppritning styrs av klassen Map som kontrollerar vilka knappar som är aktiva, och använder en instans av MapCalculations och BandOMeter för att rita ut de olika objekten på kartan. Systemets hård- och mjukvara 2.3 Phidgets & Java Phidgets är fysiska sensorer och effektorer som kan styras enkelt ifrån datorn. Exempel på phidgets är servomotorer, sliders, ljussensorer och dioder. Ursprungligen designades de för att programmeras i Visual Basic men sedan 2004 finns det en betaversion för Java. Figur 3. Skiss över portalens gränssnitt Figur 4. Switchar och dioder för phidgets. Användarnas gränssnitt mot systemet 2.2 Kiosken Kiosken identifierar användare på samma sätt som registreringen, det vill säga med RFID-taggen i armbandet. När besökaren loggat in öppnas en UDP-anslutning till databasen som börjar strömma koordinater för alla deltagare på festivalen. Beroende på vilka fysiska knappar som är aktiva ritas olika objekt ut på kartan. Alla uppgifter utöver besökarnas positioner hämtas över TCP när de efterfrågas. I figur 5 visas ett förenklat klassdiagram över relationerna mellan klasserna som ingår i kiosken. Vår prototyp är skriven i Java och de phidgets vi använt är digitala störmbrytare, dioder och RFID-läsare. För att förenkla phidgetshanteringen skrev vi två enkla wrapper-klasser som hanterar koppling till phidgets. Vi skrev även förenklade interface för händelsehanteringen när phidgets reagerar på indata. Ett stort problem med phidgets är hur RFID-läsaren hanterar taggar. Detta problem är inte unikt för Java, utan samma problematik uppstår i Visual Basic. Problemet är att läsaren endast känner av när en tagg är inom läsavståndet. Så fort en tagg känns av börjar en händelse kastas och detta fortsätter enda tills taggen avlägsnas. Det som saknas är alltså metoder för att känna av när en tagg försvinner från läsaren. Enda sättet att göra detta är helt enkelt att notera avsaknaden av läsningshändelsen. Lösningen till problemet är att använda en timer som med jämna mellanrum kontrollerar om taggen slutat läsas av. I vårt fall låter vi timern kontrollera läsaren med 300 millisekunders mellan-

3 JFrame Kiosk RFIDEventListener FullFrame IFKEventListener JComponent RFID _IPhidgetRFIDEventsAdapter PhysicalIO _IPhidgetInterfaceKitEventsAdapter MateMeasure MatingTimer UDPPositions Map BandOMeter Thread UDPClient BandFinder TCPClient MapCalculations Container Figur 5. Klassdiagram över ifan Monitors uppbyggnad och delkomponenter rum och när en tagg inte påträffats på tio iterationer (det vill säga tre sekunder) kastas en händelse som indikerar detta. Denna lösning ingår i vår wrapper-klass RFID och händelserna som kastas definieras i interfacet RFIDEventsListener. Hur lägger vi till personer i systemet? 2.4 Registrering av användare När besökarna betalar in sig till festivalen erbjuds de att registrera sig i systemet. Att registrera sig är helt frivilligt och inget krav för att få använda systemet. När man betalar in sig måste man dock acceptera att man mäter position och puls och gör detta tillgängligt för andra besökare på festivalen. Man kan alltså välja att vara aktivt eller passivt delaktig i systemet. Alla användare tilldelas en unik identitet i form av en RFIDtagg. Vår nuvarande lösning bygger på att denna tagg integreras i festivalarmbandet som alla besökare redan har. När man får sitt armband kan man stanna upp vid en dator och lägga in sina uppgifter i systemet. Figur 6. Armband för besökarna, med inbyggd RFID-tag. grund för en musikprofil som används när systemet bedömer band utifrån användarens musiksmak. Alla artister som spelar på Hultsfredsfestivalen eller går att välja vid registreringen har tilldelats en musikprofil. Musikprofilen består av en mängd genres där en artist antingen ingår eller inte i varje genre. Genom att summera de genres en användare väljer skapas en musikprofil som sedan kan jämföras med de band som spelar på festivalen. Vem är vem? 2.5 Hantering av RFID-nummer När systemet simulerades användes inte RFID-nummer som unik identifierare i databasen. Detta berodde på att det är svårt att generera många unika och giltiga RFID-nummer. Den lösning som valdes var istället att identifiera besökare med heltal som kunde sammankopplas med ett RFID-nummer. Denna koppling utfördes inte i databasen utan fick hanteras på applikationsnivå. När en användare loggar in på systemet kontrolleras om det finns någon person med detta RFID-nummer i databasen. Om numret finns hämtas detta och personen har blivit identifierad. Om numret saknas innebär det att taggen är ny och därmed måste en ny person skapas. En ny person skapas genom att slumpvis välja en person utan ett RFID-nummer ur databasen. På så sätt klarar systemet av att hantera lika många RFID-taggar som det finns simulerade besökare. De uppgifter som registreras är ett namn och en musikprofil. Namnet behöver inte vara ett fullständigt namn, ett smeknamn eller ett blankt namn (det vill säga att utelämna namnet) går lika bra att använda. Musikprofilen skapas genom att användaren får välja tio artister bland 36 alternativ. Dessa band ligger sedan till Från ax till limpa. Från idé till papier-maché 3.0 Designprocessen Brainstorming För att kunna förverkliga en prototyp till något upplevelseförhöjande informationssystem, delades vi upp i fem grupper.

4 1. Databas 2. Simulering 3. Applikationsgrupp 1 4. Applikationsgrupp 2 5. Applikationsgrupp 3 Genom brainstormingsessioner i de olika grupperna kom vi fram till ett antal olika idéer och förslag. Ur dessa sållades de bästa förslagen ut och likartade idéer slogs samman. Efter detta återstod tre kategorier av system/applikationer: Visualisering - att tillhandahålla besökarna med någon slags översiktsinformation angående andra besökare, artister och annat som finns på hultsfredsområdet. Publikåterkoppling - återkoppla publik/artisters reaktioner matas tillbaka på något sätt. Spel/lekar - olika former av spel som engagerar besökarna till interaktion. Val av implementationssätt För att klara av de krav vi hade på idéerna valde vi att rikta in oss på java som programmeringsspråk då TCP och UDPkopplingar är relativt enkla att hantera, samt att det numera finns möjlighet att styra phidgets-kit med java. Själva hanteringen av phidgets och klasserna i java-applikationen finns beskrivet mer detaljerat i del 2.3 av rapporten. Fysisk och grafisk formgivning För att göra systemet lättanvändt och simpelt, då omgivningen på en festival kan vara väldigt smutsig, vilket kräver ett robust system. Vår lösning blev ett system bestående av en skärm, sex fysiska knappar och RFID-läsare för att detektera, identifiera och logga in besökarna. En RFID-tag placerat i festivalarmbandet skulle vara ett enkelt sätt att lösa identifikationen och inloggningen utan att behöva tillföra något mer som besökarna måste hålla reda på. Figur 8. Bygge av det fysiska gränssnittet. Utvecklande av idéer via diskussion och skisser Idéerna vidareutvecklades med scenarios och skisser för att kunna ge oss en inblick i vad de olika idéerna innebar för en faktisk implementation av dem samt hur idéerna kan förfinas. Figur 7. Sprängskiss över kiosken och phidgethårdvara Scenarios Två längre scenarios finns att läsa i bilaga 1(länka till en pdf med de två längre scenariona som finns på bloggen) Fastställande av funktionalitet När vi gått igenom scenariona började vi slå fast till vad som skulle vara genomförbart och även det som vi skulle vilja göra om vi fick tid över. Vi ville kunna presentera information om festivalområdet just nu, och samtidigt med någon koppling till deltagarna själva för att göra informationen mer intressant. Hela l ösningen skulle bilda en kiosk - en bankomat-liknande maskin. Kiosker skulle finnas utplacerad på olika ställen på festivalområdet och inbjuda till enkel och trevlig interaktion, via ett tilltalande och lättanvändt grafiskt gränssnitt tillsammans med de fysiska knapparna. För det fysiska gränssnittet användes, utöver phidgetinterfacet och RFID-läsare, digitala switchar, dioder, kartong och grönskum. Själva skalet byggdes omkring en 19 tums CRT-skärm. Allting spraylackades för att ge en simpel och ren finnish. Switcharna monterades på en bit kartong och gavs etiketter med text och ikoner. Dioderna användes för att ge användarna feedback om knappen var intryckt eller ej, eftersom switcharnas fysiska utformning inte berättar något om dess läge. Den grafiska layouten producerades uteslutande i Adobe Illustrator. Målet var ett ge ett mycket rent utseende utan onödiga detaljer då en kiosk på festivalområdet troligtvis inte skulle kunna återge en större mängd detaljrikedom, samt att denna ändå skulle gå förlorad under den interaktionstiden. Animationerna och den dynamiska grafiken på kiosken och portalen skapades med hjälp av Java. Figur 9. Kioskprototypen nästan färdig.

5 Hur informationen läggs samman 4.0 Visualisering Grafiken ritas dubbelbuffrad allting ritas ut på en bildbuffert som i sin tur ritas ut på bildskärmen när grafikoperationerna är klara. En fördel mot att direkt rita på bildskärmen är att flimrande grafik undviks. En annan fördel är snabbare och mer responsiv utritningshastighet, eftersom grafiken i ifan Monitor är tung att beräkna. Utifrån vilka lager användaren valt att se ritas de ut i tur och ordning innan den färdiga buffertbilden ritas ut. Se figur 10. När nya användarpositioner erhållits från databasen startar en ny utritningsprocess: 1. Töm buffertbilden. 2. Kartan ritas ut. 3. Arrayen med alla besökares positioner gås igenom och om användaren valt det ritas varje person ut på kartan som en svart prick. Om användaren valt det beräknas folktätheten genom att omvandla positionen till en position i en mindre array med lägre upplösning. För att spara på datorresurser sker dessa båda närliggande uträkningar i samma iteration. 4. Om användaren valt att se folktätheten ritas den ut. Tätheten ritas ut i rött vilket ger en tydlig visuell feedback. Täthetsrutorna är 10x10 pixlar och ju tätare med folk desto rödare. Den röda färgens genomskinlighet avgörs av antalet människor i området multiplicerat med faktor 16, exempelvis ger 4 personer värdet 64 av 255 i genomskinlighet. Maxvärde är satt till 192 så att kartan alltid syns under tätheten. 5. Kartelement såsom scener, toaletter och öltält ritas ut. Dessa ritas alltid ut, men över folkmassan och tätheten så att de inte döljs. 6. Om användaren valt att se Band-o-Metern ritas den ut. Ett pajdiagram bredvid varje scen visar hur bra bandet stämmer överens med användarens musiksmak. Under pajdiagrammet visas bandets namn. 7. Om användaren valt att visa ölköer ritas dessa ut. De ritas ut som en stapel med absoluta värden, eftersom relativa värden som "75 %" inte säger så mycket om hur mycket folk det är i en kö. Problem med att definiera 100 % undviks. 8. Om användaren valt att se toalettköer ritas dessa ut. Samma tankegång som ölköer. 9. Om användaren valt att se vänner ritas dessa ut. Vännens position markeras med en tjock gul ring med svarta kanter. Bredvid ringen skrivs vännens namn ut. Figur 10. Bildritningssekvensen som anropas när skärmen uppdateras Var är mina vänner? 5.0 Friend-O-Finder Ett problem som belyst i inledningen av denna rapport är att man lätt tappar bort sina vänner på festivalområdet. Med ifan Monitor vill vi ta bort oron över att förlora sina kompisar och göra det enkelt att hitta nya såväl som gamla kompisar på området. När besökare loggar in på en kiosk kan de se sina vänner genom att aktivera det informationslagret. För att vänner ska visas måste de först registeras. Denna procedur är mycket enkel och vi återkommer till den strax. Det främsta skälet till att denna funktion finns är framförallt att, som tidigare nämts, ta bort oron över att tappa bort kompisarna. Avlastningen som funktionen ger är både kognitiv och emotionell. Kognitiv ur aspekten att man inte behöver an-

6 stränga sig för att leta reda på kompisarna och emotionell ur aspekten att man slipper oroa sig och kan njuta mer av festivalupplevelsen. Figur 11. Skärmdump med Friend- O-Finder påslaget Figur 12. När användaren kan lägga till en kompis visas denna bild. När kompisen lägger handen på plattan visas en ny skärm som bekräftar att en kompis-koppling skapats emellan användarna. Förutom att skapa en koppling mellan personerna jämför systemet deras musikprofil och visar resultatet genom att fylla en not med lika många procentenheter som personerna är lika. Fördelen med denna typ av lokalisering av kompisarna är att man inte är beroende av att kompisarna ska höra en mobiltelefon eller att det ska finnas täckning på området. Systemet hjälper helt enkelt besökarna hitta en utgångspunkt för sitt sökande istället för att de ska irra omkring och söka i blindo. Kan jag skaffa fler vänner? 5.1 Stöd för att skapa nya kontakter En förutsättning för att visa var vännerna befinner sig på festivalområdet är att man kan registrera sina vänner. En ursprunglig idé var att låta användarna göra detta via ett webbaserat gränssnitt innan de kommit till festivalen. Denna idé förkastade vi ganska snabbt eftersom vi ville göra det möjligt att lägga till vänner på plats. Funktionen tappar snabbt sin attraktionskraft om den inte ger stöd för spontant kontaktskapade. Om man träffar några trevliga personer på festivalen ska det vara möjligt att registrera dem som vänner för att kunna hitta tillbaka till dem senare. Vi vill alltså främja skapandet av nya kontakter. Man träffar ofta personer som man normalt inte umgås med på en festival och detta skulle innebära en möjlighet att förlänga den kontakten. Till en början tänkte vi oss fristående lådor som man tillsammans skulle kunna sticka ned sina händer i för att registreras som vänner. I slutänden bakades funktionaliteten ihop med det övriga systemet, men denna variant vore fullt möjlig att genomföra. Lösningen som valdes innebär att man kan lägga till en ny kontakt när man loggar ut från kioskerna på området. När man lyfter bort sin hand från inloggningsplattan visas en instruktion i åtta sekunder under vilken kompisen kan placera sin hand på plattan. Bilden som förklarar proceduren för användaren visas i Figur 12. Gillar jag det här bandet? 6.0 Band-O-Meter Band-O-Metern är en funktion som räknar ut hur troligt det är att en besökare gillar ett band. Beräkningen utgår från den genrevektor som skapades när besökaren valde tio band vid registreringen. Vektorn som skapas är en summering av de valda artisternas genres. Alla artister som spelar har en genrevektor som motsvarar besökarens genrevektor. Genom att jämföra likheten (rent matematiskt blir det avståndet) erhålls en procentsats som säger hur sannolikt det är att vektorerna är samma vektor. När användaren vill se vilka band som spelar på de olika scenerna hämtas deras genrevektorer ur databasen och jämförs i tur och ordning med besökarens genrevektor. Resultatet presenteras som en pajgraf som fylls mer om likheten är stor. Likheten mellan vektorerna beräknas genom att räkna ut cosinus-vinkeln mellan dem. Cosinus-vinkeln räknas ut genom att dividera skalärprodukterna av de båda vektorerna med varandra. Därefter divideras denna kvot med normen av vektorerna. Figur 13. Skärmdump med Band- O-Meter påslaget