Mater Thesis

Universitt Duisburg - Essen Paluno - The Ruhr Institute for Software Technology Pervasive Computing and User Interface
Engineering
Entwicklung einer Privatsphre erhaltenden Architektur fr Mobile Interaktion mit zuknftigen Pervasive Public Display Netzwerken
Masterarbeit im Studiengang Angewandte Informatik Systems Engineering am Institut fr Informatik und Wirtschaftsinformatik der Universitt Duisburg-Essen
Thomas Robert Kubitza 2235232

Essen, 18.06.2012
Betreuer: Prof. Dr. Nigel Davies, Dipl. Medien-Inf. Florian Alt Erstgutachter: Prof. Dr. Albrecht Schmidt Zweitgutachter: Prof. Dr. Enrico Rukzio
Eidesstattliche Erklrung
Hiermit versichere ich, dass ich die vorliegende Arbeit ohne Hilfe Dritter und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt habe. Ich habe alle Stellen, die ich aus den Quellen wrtlich oder inhaltlich entnommen habe, als solche kenntlich gemacht. Diese Arbeit hat in gleicher oder hnlicher Form noch keiner Prfungsbehrde vorgelegen.
Essen, am 18.06.2012
Entwicklung einer Privatsphre erhaltenden Architektur fr Mobile Interaktion mit Pervasive Public Display Netzwerken
II
Danksagung
Diese Arbeit ist speziell meinen Eltern Ursula und Leonhard gewidmet. Vielen Dank fr eure bedingungslose Untersttzung.
Mein Dank gilt auch Nigel Davies und Adrian Friday fr die herzliche Gastfreundschaft, Untersttzung und Zusammenarbeit an der Lancaster University sowie Albrecht Schmidt fr die Ermglichung dieser Erfahrung und das entgegengebrachte Vertrauen.
III
Zusammenfassung
Digitale ffentliche Displays sind bereits allgegenwrtig und ihre Verbreitung in ffentlichen Rumen des Alltags nimmt stndig zu. Aufgrund ihrer hufigen Nutzung zur einseitigen Informationsverbreitung und ihren oft kontextlosen Inhalten, werden viele digitale Anzeigeflchen eher ignoriert, anstatt wahrgenommen oder aktiv genutzt zu werden. Dabei knnten Pervasive Public Display Netzwerke in der Zukunft als offenes, allgegenwrtiges, interaktives Kommunikation-Medium des 21. Jahrhunderts dienen. Als Beitrag zu dieser Vision, stellt diese Arbeit eine Architektur vor, die es Nutzern mit Mobiltelefon erlaubt, implizit oder explizit so genannte Display Apps auf nahen Public Displays auszufhren, diese zu personalisieren und mit ihnen in Echtzeit per Mobiltelefon interagieren zu knnen, potentiell ohne dabei durch die DisplayInfrastruktur identifiziert oder verfolgt werden zu knnen. Gleichzeitig ist die Architektur leicht integrierbar, skalierbar, ermglicht praktikable Inhalts-Kontrolle durch Display-Verwalter und ermglicht Drittanbietern die einfache Entwicklung und Publikation von interaktiven Anwendungen fr Public Displays a la App-Store Konzept.
Abstract
Digital public displays are already ubiquitously present in our daily life and their spread still continuous. Due to their common use as unidirectional information broadcast medium and their mostly non-contextualised content, many public displays are just ignored instead of being recognized or even actively used. At the same time, pervasive public display networks have the potential to be an open, ubiquitous, interactive communication medium for the 21st century. As a contribution to that vision, this work presents an architecture that allows mobile users to implicitly or explicitly trigger and personalise display apps on near public displays and start a real time connection between the display app and the mobile phone, without being identifiable or track-able by the display infrastructure. At the same time the architecture provides easy integration, scalability and feasible contentcontrol for display owners as well as easy development and publication of interactive display apps based on the app store model.
IV
Abbildungsverzeichnis
Abbildung 1: Taxonomie von Public Displays (aus [29]) und Eingliederung der fokussierten Interaktionsarten in dieser Arbeit (blau) _______________________________________ 16 Abbildung 2: Interaktions-Phasen mit Public Displays nach Mller et al. [35,29] _________ 21 Abbildung 3: Broadcast von Display-Eigenschaften und Anwendungs-Aufruf __________ 33 Abbildung 4: Vertrauensbeziehungen zwischen Stakeholdern und Anwendungen _______ 34 Abbildung 5: Basis-Architektur ___________________________________________________ 35 Abbildung 6: Display-App Nutzungsflle __________________________________________ 37 Abbildung 7: Aggregationsstufen von Personalisierungs-Anfragen ____________________ 42 Abbildung 8: Mgliche Partitionierung von Display-Flchen bis zu 4 Anzeigebereichen __ 43 Abbildung 9: Kreissektoren zur Modellierung von Sichtfeldern bzw. Trigger-Zonen _____ 50 Abbildung 10: Flussdiagramm der Prozesse auf der mobilen App _____________________ 53 Abbildung 11: Verbindungsstationen einer persistenten Verbindung zwischen mobiler und Display-App _______________________________________________________________ 54 Abbildung 12: Beispiel-Oberflchen zur mobilen Interaktion mit Public Displays Universeller Ansatz (links), Individuelles Kontroll-UI (rechts) ____________________ 55 Abbildung 13: Basis-Architektur erweitert um Display App Stores_____________________ 57 Abbildung 14: Entfaltungssraum fr Geschftsflle im Kontext der Tacita Architektur ___ 60 Abbildung 15: Aufruf und Anzeige einer Display App ohne Backend (l.) und mit Backend (r.) ________________________________________________________________________ 66 Abbildung 16: Innere Architektur einer Display App mit Backend und Verbindungen zu Clients ____________________________________________________________________ 67 Abbildung 17: Sequenzdiagramm zur Anfrage einer Display App auf einem Display Node __________________________________________________________________________ 68 Abbildung 18: Display App Backend als zentraler Verbindungspunkt __________________ 69 Abbildung 19: Display App Developer Kit _________________________________________ 71 Abbildung 20: Web-basierter App-Player ruft eingebettet andere Display Apps auf ______ 73 Abbildung 21: App-Player im Gesamtkontext der Tacita Architektur___________________ 74 Abbildung 22: App Player in Passive Mode (not running any App) ____________________ 75 Abbildung 23: App Player Frontend Konfiguration Menus Basiseinstellungen (links), AppPolicy (rechts) ______________________________________________________________ 76 Abbildung 24: App Player Aufteilen der Anzeigeflche zwischen Apps (Tiling) ________ 77 Abbildung 25: Android App Startbildschirm (l.), App-bersicht (m.), App-Detailansicht (r.) __________________________________________________________________________ 82 Abbildung 26: Android App Kartenansicht (l.), Karte mit sichtbaren Trigger-Zonen (m.), Public Display Infos(r.) ______________________________________________________ 84 Abbildung 27: Android App Aufruf der Ansicht zur direkten Steuerung einer Display App __________________________________________________________________________ 86 Abbildung 28: Display Standorte Standort A (l.), Standort B (r.) ______________________ 92 Abbildung 29: e-Channel Player App im Einsatz, geffnetes App-Player Konfig-Men (r.) 95 Abbildung 30: News App auf Public Display (l.) personalisiert ber mobile App (r.) _____ 96
Abbildung 31: Weather App auf Public Display in InfoLab21-Foyer (l.) personalisiert ber mobile App (r.) _____________________________________________________________ 97 Abbildung 32: ubiVM Display App im Einsatz ______________________________________ 98 Abbildung 33: ubiVM Start von 9 VNC-Verbindungen gleichzeitig (l.), Dauer des Aufbaus und Anzeige von n VNC-Verbindungen (r.) ____________________________________ 99 Abbildung 34: Direkte Steuerung von Digifieds [49] ber die mobile App _____________ 100
VI
Tabellenverzeichnis
Tabelle 1: Abstrakte API Display App ____________________________________________ 38 Tabelle 2: Abstrakte Metadaten Display App ______________________________________ 39 Tabelle 3: Abstrakte API Media Player ___________________________________________ 45 Tabelle 4: Abstrakte Metadaten Public Display ____________________________________ 46 Tabelle 5: Abstrakte API Service Directory ________________________________________ 48 Tabelle 6: Roundtrip-Zeiten von Mobilfunk-Technologien ____________________________ 54 Tabelle 7: Abstrakte API Display App Store _______________________________________ 59 Tabelle 8: Beispielhafte App Metadaten im XML-Format _____________________________ 70 Tabelle 9: Display App Frontend Javascript API _____________________________________ 71 Tabelle 10: App Anfrage-bermittlungsdauern ermittelt aus 20 Messungen_____________ 91 Tabelle 11: Ermittelte Exposure- und Accuracy-Raten jeweils pro Standort, TriggerzonenGre und verwendete Technologie ___________________________________________ 94
VII
Inhaltsverzeichnis
Eidesstattliche Erklrung __________________________________________________ II Danksagung_____________________________________________________________ III Zusammenfassung ________________________________________________________ IV Abstract _________________________________________________________________ IV Abbildungsverzeichnis_____________________________________________________ V Tabellenverzeichnis ______________________________________________________ VII Inhaltsverzeichnis ______________________________________________________ VIII 1 Einleitung ___________________________________________________________ 10
1.1 Motivation ______________________________________________________________ 10 1.2 Beitrag __________________________________________________________________ 11 1.3 berblick _______________________________________________________________ 12
2 3
Verwandte Arbeiten ___________________________________________________ 13 Hintergrund __________________________________________________________ 19

3.1 Public Displays __________________________________________________________ 19 3.2 Identifikation von Stakeholdern___________________________________________ 20 3.3 Interaktionsphasen mit Public Displays ____________________________________ 21
Anforderungen________________________________________________________ 24
4.1 Nutzungs-Szenarien _____________________________________________________ 24
4.1.1 4.1.2 4.1.3 4.2.1 4.2.2 Szenario 1: Informationen in fremder Umgebung __________________________________ 24 Szenario 2: Einkaufs-Assistent _________________________________________________ 25 Szenario 3: Zeitvertreib und soziale Interaktion __________________________________ 27 Funktionale Anforderungen ____________________________________________________ 30 Qualitative Anforderungen ____________________________________________________ 31
4.2 Anforderungen __________________________________________________________ 29
Architektur __________________________________________________________ 32
5.1 Grundkonzept ___________________________________________________________ 32 5.2 Basis Architektur ________________________________________________________ 35
5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 5.2.6 5.3.1 bersicht ____________________________________________________________________ 35 Display Node ________________________________________________________________ 36 Display App _________________________________________________________________ 36 Media Player _________________________________________________________________ 39 Service Directory _____________________________________________________________ 46 Mobile App __________________________________________________________________ 49 Display App Stores ___________________________________________________________ 56
5.3 Erweiterte Architektur ____________________________________________________ 56 5.4 Privacy _________________________________________________________________ 60
Implementierung ______________________________________________________ 63
6.1 Verwendete Technologien ________________________________________________ 63 6.2 Display Apps____________________________________________________________ 65
6.2.1 6.2.2 6.2.3 Aufbau Web-basierter Display Apps ____________________________________________ 65 App Metadaten _______________________________________________________________ 70 Display App Developer Kit ____________________________________________________ 70
VIII
6.3 Media Player ____________________________________________________________ 72

6.3.1 6.3.2 6.3.3 Web-basierter App-Player als Referenz-Implementierung _________________________ 72 Display Metadaten ___________________________________________________________ 77 Integration mit e-Campus Media Player _________________________________________ 78
6.4 Service Directory ________________________________________________________ 78 6.5 Mobile Android App _____________________________________________________ 80 6.6 Minimaler Display App Store _____________________________________________ 87
Evaluation ___________________________________________________________ 89
7.1 e-Campus Deployment ___________________________________________________ 89 7.2 Sensing und Aufruf von Display Apps _____________________________________ 90
7.2.1 7.2.2 7.2.3 7.3.1 7.3.2 7.3.3 7.3.4 7.3.5 Verzgerungsfaktoren _________________________________________________________ 90 Netzwerk-Verzgerung ________________________________________________________ 91 Effektivitt unter realen Bedingungen ___________________________________________ 92 e-Channel Player App Dauerhafter Betrieb _____________________________________ 95 News App Multi-Viewer Personalisierung _____________________________________ 96 Weather App Anonymisierungs-Anstze _______________________________________ 97 Ubi-VM App Mein Desktop verfolgt mich! _____________________________________ 98 Digifieds Direkte Interaktion ________________________________________________ 100
7.3 Display App Anwendungsflle ____________________________________________ 94
Zusammenfassung und Ausblick _______________________________________ 101

8.1 Zusammenfassung ______________________________________________________ 101 8.2 Ausblick _______________________________________________________________ 102
Literaturverzeichnis ______________________________________________________ 103 Anhang _________________________________________________________________ 109
IX
Kapitel 1 - Einleitung
1 Einleitung
1.1 Motivation
Groe digitale Anzeigeflchen sind heutzutage bereits in bestimmten Umgebungen, wie z.B. Flughfen, fester Bestandteil der dortigen Infrastruktur. Viele Flughfen sind sogar schon so flchendeckend ausgestattet, dass Bildschirme praktische aus jeder Position des ffentlichen Flughafengebudes in Sichtweite sind und auch von Reisenden intuitiv genutzt werden. Sinkende Kosten fr groformatige digitale Bildschirm-Hardware begnstigen nun bereits seit mehreren Jahren deren sichtbare Ausbreitung auf weitere Bereiche des ffentlichen Lebens, wie z.B. Einkaufstrassen, Geschfte, Bars, Haltestellen, Bahnhfe, mter, Universitten, Firmenflure und viele mehr. Dabei bernehmen diese ffentlichen Anzeigeflchen (Public Displays) oft die Aufgaben ihrer statischen Vorgnger, wie z.B. von Beschilderung oder Papierbasierten Werbepostern und Bannern. Auch in Zukunft ist dabei absehbar, dass dieser Trend anhlt und ffentliche Rume noch viel strker als bisher mit digitalen Anzeigeflchen ausgestattet werden. Trifft die Vision aus Mark Weisers The Computer for the 21st Century [1] zu, so werden vielen dieser digitalen Anzeigeflchen jedoch viel besser und beinahe unsichtbar in ihre Umgebung integriert sein, um bei Bedarf unaufdringlich in den Vordergrund zu treten und Personen in ihrer Umgebung proaktiv und intelligent zu untersttzen. Heutige Netzwerke von Public Displays sind zwar oft technisch bereits vollkommen ausreichend ausgestattet, um diese Vision anzugehen, jedoch basieren die Nutzungskonzept der Betreiber der meisten Public Displays lediglich auf unidirektionaler Verbreitung oft Kontext-loser Inhalte, auf die das Publikum dieser Anzeigeflche keinerlei Einfluss hat. Entgegen der Annahme, dass z.B. digitale Werbeanzeigeflchen in Einkaufsstraen (z.B. aufgrund ihrer dynamischen Anzeigefhigkeiten) deutlich mehr Aufmerksamkeit erhalten mssten als ihre Papier-basierten Vorgnger, trifft dies in der Tat gar nicht zu [2]. Mit dem kurzfristigen und flchendecken Austausch von Papierwerbepostern im ffentlichen Raum durch digitale Anzeigeflchen im Posterformat, wurde zwar die Technologie gendert, jedoch blieben die Inhalten weitgehen gleich, was in den Kpfen des potentiellen Publikums die Erwartungshaltung lediglich statische, uninteressante und nicht auf dessen Kontext angepasste Inhalte vorzufinden, auf die digitalen Anzeigeflchen bertragen hat, was zur Folge hat, dass diese oft weitestgehend ignoriert werden (Display Blindness). Gleichzeitig wurde jedoch gezeigt [3], dass Inhalte von digitalen Werbeanzeigen, viel fter von Personen wahrgenommen werden, wenn die Anzeigen deren selektive Wahrnehmung erregen knnen, z.B. wenn die Inhalte an Produkte angepasst sind, nach denen Personen in der Nhe gerade suchen.
10
1.2 Beitrag
Die Vision, zu der diese Arbeit ein Stck beitragen will, ist die ffnung der weltweit verteilten Public Display Netzwerke fr die Nutzung und Personalisierung durch die Menschen ihrer Umgebung und somit der Schaffung eines neuen allgegenwrtigen, interaktiven Kommunikationsmediums. Zu diesem Zweck stellt diese Arbeit eine leicht einsetzbare, verteilte und dadurch skalierbare Architektur vor, die es Personen erlaubt mit Hilfe ihres Mobiltelefons, Inhalte auf nahen Public Displays implizit und explizit zu beeinflussen und mit diesen ber ihr Mobiltelefon in Echtzeit interagieren zu knnen, ohne durch die unbekannte, spontan genutzte, Display-Infrastruktur verfolgbar oder identifizierbar zu sein. Die Integration und Kombination dieser Funktionalitt mit existierenden Public Display Infrastrukturen erfordert dabei keinerlei neue Hardware, wie spter gezeigt wird nicht einmal die Installation spezieller Software, sondern im einfachsten Fall, nur den Aufruf einer Webseite ber einen Browser im Vollbildmodus. Dadurch werden Public Displays, die bis dahin aufgrund fehlender Hardware wie Touch-Panel nur zur unidirektionalen Informationsverbreitung verwendet werden konnten, pltzlich interaktiv nutzbar. Inspiriert durch das erfolgreiche Konzept von Apps fr Mobiltelefone, wird desweiteren dieser Ansatz auf Public Displays bertragen und als vielversprechendes Mittel zur Bereitstellung individueller, interaktiver und kontextualisierter Inhalte fr Public Displays prsentiert, die durch Personen in der Nhe ber ihr Mobiltelefon aufgerufen werden knnen. Dabei bildet so eine Display App als definierte funktionale Einheit einen Schnittpunkt zwischen den Interessen der Display Nutzer, der DisplayVerwalter und der Display App Anbieter und ermglicht daher den anonymen Display Nutzern individuelle Inhalte, den Display-Verwaltern mehr Aufmerksamkeit auf Anzeigeflchen unter Beibehaltung der Kontrolle durch Vorauswahl von Display Apps und den Display App Anbietern ein neues innovatives Geschftsfeld. Schon einmal haben u.a. Apps die bis dahin fr Drittanbieter weitestgehend unzugnglichen Mobiltelefon-Plattformen geffnet, dabei die Nutzung von Mobiltelefonen revolutioniert und einen wachsenden, Milliarden schweren Markt geschaffen. Konkret besteht der Beitrag dieser Arbeit zum einen aus der konzeptionellen Ausarbeitung dieser Architektur und der Beschreibung seiner Komponenten und abstrakten Definition von Schnittstellen und Datenaustauschformaten. Zuknftige Arbeiten knnen darauf aufsetzten und unterschiedliche Implementierungen realisieren. Zum anderen beschreibt diese Arbeit bereits eine vollstndige prototypische Implementierung der konzipierten Architektur sowie die Installation und Evaluation im Public Display Netzwerk der Lancaster University, England. Mehrere unterschiedliche Display Apps konnten in diesem Zusammenhang mit Hilfe eines eigens entwickelten Display App Developer Kits realisiert werden. Somit wird mit dieser Arbeit bereits eine umfangreiche, funktionale Plattform geliefert, die zur weiteren Erforschung der Praktikabilitt und des Designraums dieses Ansatzes dienen kann.
11
1.3 berblick
Diese Arbeit beginnt in Kapitel 2 mit einem berblick verwandter Arbeiten. Kapitel 3 liefert Hintergrund-Informationen zu Public Displays im Allgemeinen sowie deren besonderem Interaktionsmodell. Mit Hilfe mehrerer Szenarien werden in Kapitel 4 verschiedene Nutzungsflle prsentiert, um den darauf formulierten funktionalen und qualitativen Anforderung mehr Hintergrund zu gegeben. Kapitel 5 beschreibt die entworfene Architektur konzeptionell, indem zunchst die Grundideen vermittelt werden und anschlieend jede Komponente der Architektur genauer betrachtet wird. Aufbauend auf dieser Vorarbeit beschreibt Kapitel 6 die konkrete Implementierung der Komponenten dieser Architektur. Dazu werden zunchst die verwendeten Technologien vorgestellt und ihr Einsatz begrndet, um im Anschluss die Implementierungs-Lsungen fr die einzelnen Komponenten und deren Kommunikation zu prsentieren. Kapitel 7 beschreibt die Integration und Evaluation auf der eCampus Public Display Infrastruktur der Lancaster University. Abschlieend liefert Kapitel 8 eine Zusammenfassung sowie die Aussicht auf zuknftige Arbeiten.
12
Kapitel 2 - Verwandte Arbeiten
2 Verwandte Arbeiten
Der Ursprung der Forschung um Public Displays entspringt eher den semiffentlichen Bereichen, wie z.B. Firmen und Forschungseinrichtungen. Viele frhe Arbeiten untersuchen deshalb den Einsatz von groen Displays in Broumgebungen als Kommunikationsmedium und zur Untersttzung der Kollaboration ihrer Mitarbeiter oder der Anreicherung der Umgebungen mit kontextualisierten Daten, die ohne Display nicht sichtbar wren. Durch die wachsende Verbreitung von digitalen Anzeigeflchen in der ffentlichkeit, sowie der steigenden Zahl von InteraktionsArten, erffnen sich zudem ganz neue, interaktive Anwendung-Mglichkeiten, Herausforderungen und somit auch Forschungsfelder. Verwandte Arbeiten aus einigen Bereichen, die fr diese Arbeit hohe Relevanz haben, werden im Folgenden vorgestellt. Eine besondere Betrachtung des speziellen Interaktionsmodells von Public Displays und dessen verwandten Arbeiten wird dagegen im darauffolgenden Kapitel durchgefhrt. Implizite I nteraktion Implizite Interaktion zwischen Personen und Public Displays findet statt, wenn Displays, meistens mit Hilfe von Sensoren, die Prsenz von Personen wahrnehmen knnen und darauf basierend ihre Anzeige anpassen, ohne dass das der Personen bewusst ist. Dabei kann man Anstze unterscheiden, die lediglich anonym feststellen, ob Personen prsent sind oder nicht, sowie Anstze, die Personen in der Nhe eindeutig identifizieren knnen. So nutzt Pantic [4] Bildschirme mit Gesichtserkennung um nicht nur die Prsenz von Personen festzustellen, sondern ebenso, um deren Gesichtsausdruck und damit ggf. emotionale Reaktionen auf die angezeigten Inhalte festzustellen, und diese dadurch implizit zu markieren (implizit human centered tagging). Mit Reflective Signs nutzen Mller et al. [5] einen hnlichen Ansatz. Mit Hilfe von Gesichtserkennungs-Software stellen sie fest, ob und wie lange vorbeigehende Personen auf angezeigte Inhalte schauen, um auf Basis dieser Daten die Zusammenstellung und Anzeigedauer der Inhalte zu beeinflussen. Die Hello.Wall [6] nutzt dagegen Short-Range-Transponder Technologie um Personen in dessen Umgebung, aufgeteilt in drei Zonen wahrnehmen zu knnen und seine Anzeige auf unaufdringliche Art (Ambient) anzupassen. FunSquare [7], eine Applikation fr Public Displays, nutzt verschiedene Sensor-Quellen der Umgebung, z.B. Bluetooth-Scans oder Temperaturdaten um periodisch neu generierten Inhalte zu erzeugen. So hat die reine Zahl der in der Umgebung gescannten Bluetooth Gerte bereits Einfluss auf den angezeigten Inhalt. Ein frhes System, dass Nutzer auf Basis von Infrarot-Badges in der Nhe von Public Displays in verschiedenen Broumgebungen identifiziert und deren Inhalte adaptiert, prsentieren McCarthy et al. [8] mit Uni/Out/GroupCast. Bluetooth ist jedoch die populrste Technologie zur Identifikation von Personen (bzw. derer Telefone) in der direkten Umgebung eines Public Displays. Zwei unterschiedliche Anstze lassen feststellen. Cardoso und Jos [9] prsentieren ein System,
13
bei dem Nutzer zunchst zentral gespeicherte Profile anlegen und Interessen uern mssen, die dann mit ihrer Bluetooth-MAC-Adresse verknpft werden, um die Inhalte auf Public Displays dementsprechend anzupassen, sobald die Mobiletelefone der Nutzer per Bluetooth gescannt werden. Alt et al. [10] nutzen ebenso BluetoothMAC-Adressen fr die automatische adaptive Generierung anonymer Benutzerprofile zur Ermglichung von gezielterer Werbung auf digitalen Werbeanzeigen. Der andere hufig verwendete Ansatz nutzt dagegen Bluetooth Gerte Namen um darin Informationen, wie z.B. Benutzer Prferenzen an die Umgebung mitzuteilen. Ribeiro et al. [11,12] nutzen diese Methode, um Inhalte auf Public Displays mit Hilfe von Schlsselwrtern fortlaufend automatisch an die Prferenzen der Nutzer in der Umgebung anzupassen. Der Gleiche Ansatz wird von Villar et al. [13] verwendet (jedoch per RF-Technologie) um mit Hilfe eines kleinen tragbaren Gertes (Pendle) vorher definierte Interessen auf Basis von Keywords an die Umgebung zu senden und Inhalte auf Bildschirmen implizit anzupassen. Davies et al. [14] nutzen BluetoothGertenamen um diverse Dienste auf Public Displays gezielt aufzurufen. Einen Kombinierte Nutzung von Bluetooth-MAC-Adressen zur Identifizierung und Gertenamen zum bermitteln von Anweisungen verwenden Jos et al. in ihrem Instant Places System [15]. Alle vorgestellten Bluetooth-basierten Anstze bringen jedoch gewisse Privacy-Probleme mit sich. Zum einen muss ein Nutzer sein Gert stndig im Discoverable Modus betreiben und ist somit nicht nur von den gezielt genutzten Systemen, sondern praktisch jedem in der Nhe detektierbar. Zum anderen muss er, falls er seine Prferenzen uern mchte, diese an die gesamte Umgebung preisgeben (z.B. per Gertename) oder diese zuvor auf Basis eines Profils an mindestens eine dritte Partei bermitteln. Explizite I nteraktion Direkte, bewusste Interaktion von Personen mit Public Displays kann auf unterschiedlichste Weise und mit Hilfe verschiedenster Technologien realisiert werden. Mit Hilfe einer am Public Display angebrachten Kamera zum Beispiel wird das Display eines Mobiltelefons in der Hand der davorstehenden Person verfolgt und zur Bewegung einer Cursors auf der groen Anzeigeflche verwendet [16]. Auf gleiche Weise nutzen Vogel et al. [17] Marker angebracht an eine Hand, um diese zu verfolgen und Gesten zu interpretieren. Nawaz. et al. [18] schlagen vor, groe Bildschirme mit einer Kombination aus Blick-Verfolgung und Gesten-Erkennung zu steuern. Mller et al.[19] verwenden Microsofts Kinect-Sensor um Personen mit einem Public Display in einem Schaufenster interagieren zu lassen. Auch Laserpointer in Verbindung mit Kamera-Bildverarbeitung werden zur Steuerung verwendet [20]. Mit Point & Shoot [21] wird die Kamera eines Mobiltelefons genutzt um zunchst ein gewnschtes Objekt auf einem groen Bildschirm zu fokussieren und abzudrcken. Daraufhin wird ein Gitter von 2D-Codes kurzzeitig auf dem Public Display eingeblendet, das die Feststellung der absoluten Position erlaubt. Mit Sweep ermglichen die gleichen Autoren eine Steuerung des Cursors auf Public Displays mit Hilfe eines Mobiltelefons, das seine Kamera als optischen Maussensor nutzt, welches nicht einEntwicklung einer Privatsphre erhaltenden Architektur fr Mobile Interaktion mit Pervasive Public Display Netzwerken 14
mal in die Richtung des Bildschirms zeigen muss. Auf Basis einer RFID-Tag-Matrix, die hinter den Bildschirm geklebt wird, kann ein NFC-fhiges Mobiltelefon zur direkten Interaktion verwendet werden [22]. Das Pendle-Device [13], welches als Badge um den Hals getragen wird, kann in die Hand genommen und auf Basis von Gesten die Inhalte auf nahen Display explizit beeinflussen (z.B. URLs anzeigen, die auf dem Pendle gespeichert sind). Andere [23] nutzen Mobiltelefone mit Beschleunigungssensoren und Bluetooth um sich mit eine groen Public Display zu verbinden und darauf ein Multiplayer Rennspiel zu steuern (analog zur Nintendo Wii Controllern). Bei einem hnlichen Ansatz zu Untersttzung der gleichzeitigen Interaktion mehrerer Mobilegerte-Nutzer mit Public Displays, nutzen Leikas et al. [24] drahtlose Datenverbindungen zur Kommunikation. Ist einem Nutzer bewusst, dass er alleine durch seine Prsenz in der Nhe von Public Displays bestimmte Aktionen auslst, dann ist dies ebenso explizite Interaktion. McDonald et al. nutzen in diesem Zusammenhang RFID-Tags um die gegenseitige Wahrnehmung von Teilnehmern auf Konferenzen mit Hilfe von personalisierten Inhalten auf groen Displays zu untersttzen. Dazu zeigt ihr proaktives System z.B. das Profil eines Teilnehmers fr alle sichtbar an, sobald dieser zum Mikrofon kommt (AutoSpeakerID), sowie die (gemeinsamen) Interessen von Personen, die sich in Wartebereichen aufhalten (Ticket2Talk und Neighborhood Window). hnliches leistet auch IntelliBadge [25] auf Basis von RFID. Durch gezieltes An- oder Ausschalten des sichtbaren Modus von Bluetooth-Devices, bzw. gezieltes ndern von Gertenamen, knnen diese auch zur expliziten Interaktion eingesetzt werden [14,15]. Ebenso knnen solche Befehle oder Inhalte auch per SMS und MMS an Public Displays versendet werden. Eine der verbreitetesten Methoden zur direkten Interaktion mit Public Display ist die direkte Berhrung, ermglicht entweder durch eine kapazitative Schicht ber der Anzeigeflche oder durch einen Infrarot-Rahmen. Abhngig von Technologie, Treiber und Betriebssystem des Public Display Rechners, knnen solche Touch-Panel entweder nur per Single-Touch von einem Nutzer oder per Multi-Touch von einem oder mehreren Nutzern gleichzeitig bedient werden. Peltonen et al. [26] nutzen z.B zum Betrieb ihrer CityWall, ein groes interaktiven Multi-Touch Display, dass in seiner stdtischen Umgebung von einer Vielzahl von Personen gleichzeitig bedient werden kann. Schlielich kommen auch noch physikalische Knpfe zum Einsatz [27] (z.B in Museen) oder speziell in semi-ffentlichen Umgebungen auch manchmal Tastatur und Maus, wie z.B. beim Plasma Poster Network [28]. Abbildung 1 zeigt eine Taxonomie (entnommen aus [29]) von Public Displays, basierend auf der Interaktionsart und dem verwendeten mentalen Model der Display Anwendung, sowie die Eingliederung einiger verwandter Arbeiten. Die blau markierten Bereiche stellen dabei die Eingliederung dieser Arbeit dar, welche sowohl implizite Interaktion ber Prsenzerkennung, also auch ferngesteuerte Interaktion ber Mobilgerte (ggf. auch per Gesten) erlaubt. Mit Hilfe der abstrakten Idee von Display Apps knnen dabei praktisch alle mentalen Modelle realisiert werden.
15
Abbildung 1: Taxonomie von Public Displays (aus [29]) und Eingliederung der fokussierten Interaktionsarten in dieser Arbeit (blau)
Architekturen und Middleware Unterschiedliche Architekturen und Middleware existieren fr Public Display Netzwerke, welche z.B. die Inhaltsverbreitung steuern, Ereignisse und Nachrichten bermitteln, Interaktion steuern oder externe (mobile) Gerte zur Steuerung oder als privates Display einbinden. Mit MAGIC Broker [30] schlagen Erbad et al. ein Middleware Toolkit fr interaktive Public Displays vor, dass auf einem zentralisierten HTTP-basierten Publish/Subscribe Message-Server basiert. Display Clients in Form von einfachen Webseiten abonnieren dabei einen s.g. Channel, welcher vorher von ihnen innerhalb von einer hierarchischen Struktur von Channels angelegt werden kann. Mobiletelefone mit Browser knnen nun ber Client-Webseiten Befehle und Inhalte an denjenigen Channel schicken, der von dem Public Display abonniert wird, mit dem ein Nutzer interagieren will. Ein Display-Client nutzt dabei Polling um den Server regelmig auf neue Nachrichten zu prfen. Das MAGIC Broker System ist durch die Verwendung von HTTP als Transportprotokoll und der Implementierung einer RESTful API zusammen mit seinem hierarchischen Channel System ein sehr allgemeines, einfach nutzbares System zur asynchronen Nachrichtenbermittlung, insbesondere nicht nur in Zusammenhang mit Public Displays. Sein zentralisierter Ansatz skaliert jedoch nicht, insbesondere bei greren Mengen Clients die Polling verwenden. Mit Distributed User Interfaces (DUIs) stellen Hosio et al. [31] ein System zur Erweiterung von Web-basierten Public Display Anwendungen um mobile, auf J2ME basierende, private Benutzerschnittstellen vor. Mit Hilfe einer J2ME-Service Discovery Anwendung fr mobile Gerte kann ein Nutzer Anwendungen auf Public Displays starten und falls diese ein mobiles UI anbieten, diese Anwendung auf dem Public
Entwicklung einer Privatsphre erhaltenden Architektur fr Mobile Interaktion mit Pervasive Public Display Netzwerken 16
Display ber die mobile UI steuern und ggf. private Informationen der Anwendungen auf dem mobilen Gert anzeigen. Eine Display Anwendung muss schon zur Designzeit fr diese verteilte Form von UIs vorbereitet werden und kann dann entweder maximal einem Nutzer gleichzeitig Zugang geben (privater Modus), oder mehreren mobilen Usern gleichzeitig (Community Modus). Zudem sind mehrere Kombinationen der Steuerung ber die interaktive Public Display Oberflche und die mobile UI gleichzeitig oder jeweils getrennt mglich. Public Display Anwendungen verwenden dabei Metadaten, um zu kommunizieren, ob und welcher Art der mobile Benutzerschnittstelle sie untersttzen. Zur Identifikation vor welchem Public Display sich ein mobiler Nutzer befindet, muss das Mobiltelefon vor den RFID-Leser der Public Displays gehalten werden. Anschlieend kann ein Nutzer auf dem mobilen Gert ber eine Art mobile Service-Layer App (UBI-mobile) verfgbare Anwendungen aufrufen, und ein s.g. Lease anfordern. Hat ein Public Display gerade bereits ein Lease eines anderen mobilen Nutzers und untersttzt die ausgefhrte Anwendung nicht den Community-Modus, so tritt der Nutzer in eine Wartschlange ein und wird per Signal benachrichtigt, sobald das Public Display UI wieder frei ist. Die vorgestellte Implementierung basiert bereits auf Web-basierten Public Display Apps, die mit Hilfe von Metadaten beschrieben und mit mobilen UIs ergnzt werden knnen. Ein groer Nachteil liegt jedoch in der Verwendung von mobilen J2ME Anwendungen, die speziell fr jede Public Display Applikation entwickelt werden mssen. Da zur Wahrnehmung der Prsenz eines Public Displays (bzw. in diesem Fall der Wahrnehmung von Nutzern durch Public Displays) ein Nutzer erst das Telefon in die Nhe des RFID-Readers halten muss, ist lediglich explizite Interaktion auf Basis dieser Plattform realisierbar. Insgesamt bietet diese Plattform zwar die sehr interessante Funktionalitt Public Display Anwendungen um private mobile UI zu erweitern, allerdings scheitert die praktisch Implementierung an fehlender Flexibilitt und einfacher Nutzbarkeit durch gewhnliche Endnutzer. Storz et al. [32] prsentieren mit e-Campus ein System zur Steuerung und Inhaltverbreitung einer verteilten Public Display Infrastruktur auf dem Campus der Lancaster Universitt in England. Die dortige Infrastruktur besteht dabei aus etwa 25 LCD Bildschirmen die an populren Pltzen des Campus angebracht sind. Da die Public Displays keine direkte Eingabe untersttzen, werden sie berwiegend zur Verbreitung von multimedialen Campus-Informationen verwendet. Das System zur InhaltsVerbreitung teilt sich dabei in zwei Schichten. ber eine API kann eine Low-LevelSchicht die Basis-Steuerung von einzelnen oder ganzen Gruppen von Displays transaktionsorientiert bernehmen. Als Basis-Befehle kann eine abstrakte Anwendung (welche fr die Darstellung ihrer Inhalte zustndig ist) gestartet, gestoppt, parametrisiert und ein- oder ausgeblendet werden. Die Kommunikation dieser Low-Level Schicht erfolgt dabei auf Basis asynchroner Ereignis-basierter 1-zu-n Kommunikation mit Hilfe eines zentralen Messaging-Servers (Elvin) der unterschiedliche Publikationsmodelle wie z.B. Publish/Subscribe untersttzt. Auf dieser Low-Level-Schicht knnen nun komplexere, Domnen-abhngige Scheduler aufsetzten und dadurch sowohl Zeitplan-basierte, als auch spontan angefragte Inhalte anzeigen. Eines dieser
High-Level-Interfaces ist das Web-basierte e-Channel-System, welches von verschiedenen administrativen Nutzergruppen des Display Netzwerks genutzt werden kann und Inhalt-Ersteller und Display-Besitzer mit Hilfe von Channels entkoppelt, die von ersteren erstellt und gepflegt und von letzteren abonniert werden knnen. Somit knnen Display Verwalter bequem gewnschte Inhalte durch die Verschachtelung von abonnierten Inhalten auf ihren Displays anzeigen lassen. Die e-Campus Plattform ist durch ihre 2-Schichten Struktur flexibel einsetzbar. Verschiedene Inhalte bentigen jedoch auf der Low-Level-Schicht unterschiedliche Anwendungen bzw. Renderer um diese anzeigen zu knnen. Ein System zur zeitlich und rumlich verteilten Verwaltung von interaktiven Webbasierten Public Display Applikationen stellen Linden et al. [33] vor. Diese Middleware wird auf der Public Display Infrastruktur der Stadt Oulu in Finnland betrieben, welche aus 6 doppelseitigen Outdoor Displays und 11 einseitigen Indoor Displays besteht, die quer durch die Stadt verteilt sind. Alle Displays sind mit Touch-Paneln, Kamera, Bluetooth- und WLAN-Hotspots sowie NFC-Readern ausgestattet. Zur Untersttzung interaktiver Inhalte wird auf Web-basierte Anwendungen gesetzt. Ein s.g. Layout-Manager, welcher selbst als Web-basierte Anwendung, die im VollbildModus eines Firefox-Browsers luft, implementiert wurde, teilt dabei die verfgbare Anzeige-Oberflche in bis zu 4 verschiedene Layouts. Jedes Layout hat 2-4 Bereiche, in denen individuelle Web-Anwendungen oder sogar unterschiedliche Views einer Web-Anwendung angezeigt werden knnen. ber ein dauerhaft erreichbares Men im unteren Bereich, knnen Nutzer von Public Displays gezielt verfgbare Anwendungen aufrufen, sowie u.a. die Anzeigesprache ndern. Die verwendeten WebAnwendungen werden dabei auf Basis von IFrames eingebunden, und ber einfache bergabe von HTTP-GET Parametern mit notwendigen Angaben wie z.B. der ID des aufrufenden Displays, der gewhlten Anzeigesprache usw. versorgt. Der LayoutManager speichert dabei persistent den Zustand der Oberflche und kommuniziert fortlaufend ber ein Web-Interface mit einem Ressourcen-Manager, der fr die Verteilung von Inhalten, die z.B. im Idle-Mode des Displays wiedergegeben werden sollen, zustndig ist. Das von Linden et al. nun bereits seit mehr als 3 Jahre auf einer ffentlichen Infrastruktur von interaktiven Public Displays eingesetzte System, demonstriert die Mchtigkeit und Flexibilitt von reinen Web-Anwendungen auch fr den Langzeitbetrieb. Dieser Ansatz zusammen mit dem Nachweis seiner Praktikabilitt stellt u.a. eine wesentliche Inspiration fr die Implementierung der Architektur dieser Arbeit dar.
18
Kapitel 4 - Anforderungen
3 Hintergrund
Dieses Kapitel untersucht zunchst Merkmale von Public Displays, identifiziert und benennt Interessengruppen fr die sptere Verwendung und stellt das besondere Interaktionsmodell von Public Displays vor.
3.1 Public Displays

Digitale Bildschirme sind immer in einen Kontext eingebettet. Dieser kann zunchst grob als ffentlich (public), semi-ffentlich (semi-public) oder privat (private) kategorisiert werden. Bildschirme in ffentlichen Umgebungen sind prinzipiell durch jeden zugnglich. Oft bedrfen sie dazu jedoch auch einer speziellen Robustheit gegen Wettereinflsse und Demolierung. Semi-Public Displays befinden sich dagegen in Bereichen die nicht jedem zugnglich sind und werden dadurch meistens nur durch bestimmte Gruppen wahrgenommen (z.B. Mitarbeiter in Firmenfluren). Private Displays wie. z.B. Computer- und Handy-Displays werden dagegen meistens von genau einer Person genutzt. Im Gegenteil zu privaten Displays, sind die Hauptnutzer von (Semi-)Public Display praktisch nie gleichzeitig seine Besitzer. Zumeist haben die Personen, die sich typischer Weise in der Nhe dieser Displays befinden, gar keine Einfluss auf deren Aufstellungsort, Zweck oder Inhalt, obwohl sie als potentielle Informationskonsumenten die primre Zielgruppen sind. Interaktive Anwendungen und implizite und explizite Interaktionstechnologien fr Public Displays beginnen jedoch dieses Prinzip aufzuweichen. Im weiteren Verlauf dieser Arbeit sollen die Begriffe Public Display und Semi-Public Display, falls nicht explizit anders angegeben, mit dem Begriff Public Displays zusammengefasst werden. Der Kontext eines Public Displays kann jedoch genauer beschrieben. So haben die meisten Public Displays eine feste Geo-Position. Einige andere sind dagegen mobil, z.B. in U-Bahnen, Taxis, Zgen oder auch auf Menschen [34]. Desweiteren knnen Bildschirm auf verschiedenen Technologien bestehen (z.B. LCD/PlasmaFlachbildschirme, Projektoren, LED-Anzeigen) sowie verschiedene Gren, Geometrien (eben rechteckige und zylindrische Anzeigen, Bnder, freifrmige Projektionen) und Formate haben (Portrait, Landscape, Poster, Kiosk). Zudem sind sie in einer festen Lage angebracht. Diese kann z.B. sehr hoch sein, um eine bessere Sichtbarkeit zu ermglichen, jedoch gleichzeitig z.B. Interaktionsmglichkeiten einschrnken (z.B. nicht mehr berhrbar). Poster-formatige, Touch-basierte Displays, die z.B. bis zum Boden reichen, wrde dagegen potentiell nur in Sichthhe und Berhrungs-Reichweite genutzt. Format, Geometrie, Gre, Lage, Umgebung und ggf. auch Wetter bestimmen schlielich das Sichtfeld von Bildschirmen. Bei ebenen Anzeigen lsst sich dieses aus Vogelperspektive z.B. oft grob als Kreissektor (mit Winkeln < 180) annhern, bei zylindrische Displays als Ringflche. Die Sichtweite und Interpretierbarkeit ist dagegen u.a. von Displaygre, Helligkeit, Kontrast und Inhaltsgre abhngig. Schlielich sind Public Displays jedes Mal in einem vllig indi-
19
viduellen Kontext eingebettet, der potentiell einen enormen Einfluss auf die Wahrnehmung ihrer Inhalte hat.
3.2 Identifikation von Stakeholdern

Mehrere Interessengruppen (Stakeholder) knnen im Kontext von Public Display Netzwerken identifiziert werden. Diese werden im Folgenden beschrieben und benannt, um im weiteren Verlauf dieser Arbeit eindeutig referenziert werden zu knnen. Display Owner Die Interessengruppe der Display Owner fasst Besitzer von Bildschirmflchen sowie deren Verwalter zusammen. Dazu zhlen z.B. Ladenbesitzer mit einem einzigen ffentlichen Display in ihrer Vitrine bis hin zu Verwaltern von Netzwerken mit mglicherweise hunderten von Displays an verschiedenen Standorten wie z.B. in Shopping-Malls. Display Owner sind fr den Betrieb und die Wartung ihrer Infrastruktur zustndig. Sie sind daran interessiert, ihre Display-Flchen mit Inhalten zu fllen, die von Personen in ihrer Umgebung (Viewer) wahrgenommen werden sollen. Diese Inhalte knnen dazu dienen eigene Zwecke zu verfolgen (z.B. Eigenwerbung, Reiseinformationen auf Flughafen-Bildschirmen, usw.) oder auch von Dritten stammen, die z.B. Anzeigezeit auf der Bildschirm-Infrastruktur von Display Ownern kaufen. Content Provider Die Anbieter dieser Fremdinhalte werden im weiteren Verlauf Content Provider genannt. Heutige kommerzielle Content Provider sind zumeist Werbeagenturen (Advertiser), die im Namen ihrer Auftraggeber Produktanzeigen mit Hilfe der Infrastruktur von Display Ownern schalten. Weiterhin sind bereits oft ffentliche Displayflchen zu beobachten, die eine Mixtur aus allgemeinen Informationen (wie Schlagzeilen, Wetter, usw.) und Werbung anbieten. Dies deutet an, dass reine Werbeanzeigen im ffentlichen Raum (insbesondere in Wartebereichen) weniger Aufmerksamkeit erhalten, als in einer Kombination mit Infotainment, und dies obwohl sie effektiv weniger Anzeigezeit erhalten. Die Anbieter dieser fr Public Displays optimierten Kombination aus Information/Entertainment und Werbung kommen bereits jener Interessengruppe sehr nahe, die in dieser Arbeit als Application Provider bezeichnet wird. Application Provider bieten Inhalte speziell fr Public Displays an, die von vllig statischen Inhalten bis hin zu komplexen interaktiven Anwendungen reichen knnen. Diese Anwendungen (Display Apps) knnen auch Inhalte von Advertisern (ggf. Kontext-basiert) einbetten und werden gewhnlich ber die Display Infrastruktur von Display Ownern aufgerufen.
20
Viewer Als Viewer sollen schlielich diejenigen Personen bezeichnet werden, die sich entweder einfach nur unbewusst im Sichtfeld von Public Displays befinden, die Inhalte von Public Displays auf irgendeine Weise wahrnehmen oder sogar mit Public Displays interagieren. Viewer sind die primren Nutzer von Public Displays und Konsumenten ihrer Inhalte. Sie stehen dabei in keinerlei Besitz oder Nutzungsrecht zu diesen Anzeigeflchen und sind sich oft gar nicht der Nutzung, also des (unterbewussten) Informationskonsums, bewusst. Dieses komplexere Interaktionsmodell von Viewern mit Public Displays im ffentlichen Raum wird daher im nchsten Abschnitt genauer betrachtet.
3.3 Interaktionsphasen mit Public Displays

Die Interaktion von Personen mit ffentlichen Displays kann in Phasen eingeteilt werden. Abbildung 2 veranschaulicht ein Model mit 6 Phasen nach Michelis und Mller [35,29]. Um von einer Phase zur nchsten zu gelangen, muss immer erst eine gewisse Schwelle berschritten werden. Mit Hilfe von Transitionsquoten knnen diese messbar, berechenbar und vergleichbar gemacht werden. In Phase 1 passiert eine Person ein Public Display ohne es zunchst wahrzunehmen. Bereits hier kann eine Interaktion unbeabsichtigt (implizit) geschehen. Ein Public Display, das mit Sensoren wie z.B. einer Kamera und Gesichtserkennungs-Software1 ausgestattet ist, knnte Bildschirminhalte beim vorbeigehen einer Person z.B. an dessen Geschlecht, geschtztes Alter und Gesichtsausdruck anpassen. Diese Interaktion ist ggf. von der Person ungewollt und der Effekt wird mglicherweise von dieser gar nicht wahrgenommen. Trotzdem hat die Person den Inhalt in diesem Fall bereits beeinflusst.
Abbildung 2: Interaktions-Phasen mit Public Displays nach Mller et al. [35,29]
Um die Schwelle in die zweite Phase zu berqueren, in der die Person auf das Display sieht und ggf. reagiert, muss zunchst die Aufmerksamkeit der Person gewon1
z.B. Fraunhofer SHORE: http://www.iis.fraunhofer.de/bf/bsy/produkte/shore/ 21
nen werden. Dabei wirken bestimmte Inhalte wie z.B. bewegte und bunte Inhalte [2] allgemein anziehender. An dieser Stelle ist es mglich, dass eine Person z.B. Inhalte nur kurz ansieht und ohne sichtbare Reaktion weitergeht. Im Allgemeinen kann bereits an der Dauer des Blickes die Strke des Interesses erkannt werden. Mit ReflectiveSigns stellen Mller et al.[5] z.B. ein System vor, dass Dauer und Reihenfolge von Inhalten auf Public Displays fortlaufend auf Basis von Blickdauern vorbeilaufender Personen anpasst. Die dritte Phase umfasst subtile Interaktion insbesondere durch Gesten und wird nur untersttzt, falls das Public Displays diese interpretieren kann. Zunchst muss jedoch die Neugier einer Person geweckt werden. Beim Looking Glass [19], einer interaktiven Public Display Anwendung die das Bild bzw. die Silhouette von Passanten wiedergibt, um deren Aufmerksamkeit zu erlangen und virtuelle Overlays zu bewegen, wurde beobachtet wie Personen im Vorbeilaufen auf die Interaktivitt (und ihr Spiegelbild) aufmerksam werden, stehen bleiben und noch einmal zurckkommen (landing effect) um den Effekt verschiedener Gesten auszuprobieren. Gestenbasierte Interaktion weckt hufig auch die Aufmerksamkeit anderer Passanten auf sich und fhrt regelmig zur Anhufung von Menschengruppen (honeypot effect). Direkte Interaktion mit dem Display durch Berhrung wird durch die 4. Phase reprsentiert. Auch hier muss eine Person neugierig werden und sich dem Display nhern um mit der Interaktion beginnen zu knnen. Ein hufiges Problem ist, dass Personen Touch-basierte Public Displays meistens nicht fr interaktiv halten. Dies liegt zumeist an der (berechtigten) Erwartungshaltung, dass Public Displays ein reiner Ersatz fr traditionelle Papier-basierte Poster sind. Dabei spielt der Kontext in der sich eine Person befindet, ein groe Rolle - von einem groen Display in einer Bibliothek oder einem Museum wird eher Interaktivitt erwartet, als von einer digitalen Werbetafel in einer Einkaufsstrae. Somit muss oft erst auf diese Funktionalitt hingewiesen werden (z.B. durch Touch the Screen Aufforderungen). Bei manchen Displays scheidet direkte Interaktion jedoch schon dadurch aus, dass sie einfach nicht per Berhrung zugnglich sind, wie z.B. auf grerer Hhe oder auf der anderen Seite der Gleise in U-Bahnstationen. Mehrfache Interaktion kann schlielich stattfinden wenn, z.B. mehrere Bildschirme vorhanden sind oder Nutzer nach einer Pause wiederkehren um die Interaktion fortzufhren. Schlielich umfasst die letzte Phase mgliche Folgeaktivitten die klar auf die Interaktion mit Public Displays zurckzufhren sind. Die knnte z.B. das einlsen eines per QR-Code eingescannten Coupons sein [36] oder auch das Fotografiert werden vor den Displays. Wichtige fr eine lngere Interaktion mit einem Public Display ist die fortlaufende Motivation des Nutzers mit Hilfe intuitiver, fordernder, jedoch nicht zu komplizierter Benutzungskonzepte und interessanter, grafischer User Interfaces [29]. Gleichzeitig muss beim Design einer interaktiven Public Display Anwendung immer beachtet werden, dass die Interaktion in der ffentlichkeit stattfindet und Personen sich oft anders benehmen oder sich nicht trauen, z.B. aus Angst sich zu blamieren.
22
Einflsse vorausgehender Situationen Bevor eine eigentliche Interaktion mit Public Display erfolgen kann, befindet sich eine Person jedoch immer schon in einer individuellen Situation, die groen Einfluss auf die eigentliche (bevorstehende) Interaktion mit Public Display haben kann. Einige davon knnen wie folgt beschrieben werden: Wartesituationen: Bereiche in denen regelmig Wartesituationen stattfinden sind aus Sicht von Display Ownern besonders interessante Orte fr Public Displays. Displays in solchen Situationen erhalten daher eine vergleichsweise sehr lange und hufige Aufmerksamkeit ihrer Betrachter. Gleichzeitig laufen diese Bildschirme auch Gefahr die Aufmerksamkeit ihres Publikums dauerhaft zu verlieren [2], falls sie nicht fortlaufend deren Aufmerksamkeit binden knnen. Pass-By Situationen: Typische Pass-By Situationen finden z.B. in Einkaufstrassen mit digitalen Werbeanzeigen statt. Personen, die an diesen Public Displays vorgehen, haben zumeist einen inneren Zustand, der zwischen Freizeitauslebung und zielgetriebener Verfolgung von Aufgaben liegt. Letzterer hat die Konsequenz, dass diese Personen mit einer besonders starken selektiven Wahrnehmung durch die Straen laufen, und daher meistens nur auf bestimmte Reize reagieren. Gezielte Nutzung: Bei der gezielten Nutzung sind sich Personen bereits ber die Fhigkeiten und den potentiellen Mehrwert der Public Displays bewusst, auf die sie zusteuern um explizit mit ihnen zu interagieren.
Diese drei Situationen sind auch das Thema der Szenarien im nchsten Kapitel und werden dort deshalb grndlicher diskutiert.
23
4 Anforderungen
In diesem Kapitel werden funktionale und qualitative Anforderungen fr eine Architektur formuliert, die die anonyme implizite und explizite Ad-hoc Interaktion mit unbekannten Public Displays ber das Mobilgert von Viewern ermglichen soll. Um diesen Anforderungen mehr Hintergrund zu geben, werden im Folgenden drei Szenarien verwendet.
4.1 Nutzungs-Szenarien
Im Folgenden werden verschiedene Nutzungsflle in Form von Szenarien vorgestellt, die die Vision von offenen, globalen Pervasive Public Display Netzwerken motivieren sollen, die auf Basis von individuellen Anwendungen fr Public Displays (Display Apps) durch Viewer in der Nhe implizit oder explizit genutzt und personalisiert werden knnen. 4.1.1 Szenario 1: Informationen in fremder Umgebung Achim ist Rentner und reist gerne. Er ist besonderes an Architektur und Geschichte interessiert und freut sich deshalb umso mehr an diesem Wochenende zum ersten Mal Barcelona zu besichtigen. Er mag es, einfach durch Stdte zu spazieren und diese selbstndig zu entdecken. Auf einer seiner Reisen hatte er entdeckt, dass er ffentliche Bildschirme nutzen kann, um Informationen ber seine Umgebung zu erhalten. Im Bus auf dem Weg in die Innenstadt aktiviert der dazu einfach eine App auf seinem Smartphone, whlt aus, dass er an Informationen ber Geschichte und Architektur interessiert ist und steckt das Telefon wieder in seine Tasche. Whrend er durch die Stadt spaziert und interessiert die Architektur betrachtet, luft er gleichzeitig auch regelmig an Public Displays im Kioskformat vorbei, die verschiedene Inhalte, jedoch zumeist Werbung anzeigen. Sobald sich Achim jedoch in die Nhe eines dieser Anzeigen begibt, wird der Displayinhalt aufgeteilt. In der unteren Hlfte wird weiterhin Werbung angezeigt, in der oberen Hlfte jedoch Informationen in deutscher Sprache zur Geschichte und Architektur der direkt umliegenden Gebude sowie eine kleine Karte mit dem aktuellen Standort. Achim gefllt es diese Informationen in seiner Landesprache und direkt im Kontext der Gebude zu erfahren. Auch wenn an vielen Gebuden Informationstafeln angebracht sind, so ist sein Spanisch nicht gut genug um diese zu verstehen. Er wei, dass er hnliche Informationen auch direkt auf seinem Smartphone finden knnte, jedoch mag er es nicht besonders mit dem Handy in der Hand und der Lesebrille auf dem Kopf durch die Straen zu laufen und sich auf die Bedienung fokussieren zu mssen, anstatt die Umgebung entspannt auf sich wirken zu lassen. Achim mchte noch so einige Ecken sehen, bekommt jedoch langsam Hunger. Er ist nun schon an einigen Restaurants vorbeigegangen. Um mehr Informationen zu Restaurants zu erhalten, aktiviert er in der Public Display App auf seinem Smartphone einfach Restaurants, versenkt das Telefon wieder in der Tasche und schlendert weiter die Strasse herunter. Auf den nchsten Public Displays werden Ihm nun zustzlich Informationen zur Restaurants in der direkten Umgebung angezeigt. Whrend er gerade auf ein weiteres Public Display an einer Bushaltestelle zuluft, bemerkt Achim ein kleines sympaEntwicklung einer Privatsphre erhaltenden Architektur fr Mobile Interaktion mit Pervasive Public Display Netzwerken 24
thisch wirkendes Lokal auf der anderen Straenseite. Auf dem Public Display findet er es ebenfalls wieder und erfhrt, dass es anscheinend erstklassige einheimische Kche zu guten Preisen bietet und von einer Vielzahl von Personen positiv bewertet wurde. Genau das, worauf Achim gerade Lust hat. Szenario 1 ist insbesondere ein Beispiel fr die Ntzlichkeit gezielter (Mit-)Nutzung ffentlicher Display Infrastrukturen fr individuelle Zwecke. Achim ist diese Mglichkeit bewusst, weshalb er sich digitalen Public Displays jedes Mal gezielt nhert wenn er Informationen ber Architektur und Geschichte seiner direkten Umgebung erfahren mchte. Den Wunsch genau diese Informationen zu erhalten hat Achim im Voraus mit Hilfe seines Smartphones geuert. Dieses behlt er fast die ganze Zeit in seiner Tasche und nutzt es nur um ggf. Prferenzen zu ndern. Er empfindet es als strend und umstndlich die gewnschten Informationen stndig von seinem kleinen Display abzulesen. Stattdessen erhlt er automatisch gewnschte Informationen auf Public Displays ber den Kontext, in dem er sich gerade befindet sobald er sich diesen Displays nhert. Dabei deutet das Szenario bereits eine mgliche gemischte Nutzung der Public Display Flchen an, bei dem entweder die gesamte Flche z.B. fr Werbung o.. genutzt wird oder ein Teil der Bildschirmflche fr personalisierte Inhalte genutzt werden kann, welche wieder ausgeblendet werden sobald der Nutzer nicht mehr in der Nhe ist. Insbesondere fr Stdte mit viel Tourismus knnte solch eine Mischnutzung ffentlicher Display-Strukturen zur Untersttzung verschiedenster lokalisierter Informationen sehr attraktiv sein. Eigene Informationsdisplays oder mehrsprachige statische Beschilderungen knnten so eingespart werden. Die Idee von offenen, globalen Public Display Netzwerken erlauben es Achim in diesem Szenario spontan Public Display Anwendungen zu nutzen, die er zuvor in einer ganz anderen Umgebung genutzt hatte und mit denen er bereits gute Erfahrungen gemacht hat. Diese werden in Regel von Drittanbietern bereitgestellt und sind zunchst vom Ort ihrer Anzeige und Nutzung unabhngig. So nutzt Achim spter zustzlich zu der Tourismus-Anwendung auch eine weitere Public Display Anwendung zum Anzeigen von Restaurantinformationen in Verbindung mit Kundenbewertungen und Kommentaren. Smtlich fr Public Displays angebotenen Anwendungen knnen und sollten sich dabei an den Kontext des Public Displays sowie an die vom Nutzer zur Verfgung gestellten Angaben anpassen (z.B. an die Sprache). 4.1.2 Szenario 2: Einkaufs -Assistent Anja ist auf dem Weg in eine groe Shopping-Mall um ein neues Sommerkleid fr eine Feier zu kaufen, die bereits heute Abend stattfindet. Sie hat schon recht konkrete Vorstellung von Schnitt und Farbe, jedoch nicht wirklich genug Zeit um alle in Frage kommenden Geschfte abzusuchen. Auf dem Weg vom Parkplatz tippt sie deshalb Sommerkleid rot wei in ihr Smartphone, aktiviert die Public Shopping Assistent App und versteckt das Telefon wieder in ihrer Tasche. Anja hat mit der Anwendung bereits gute Erfahrungen in den langen Einkaufsstraen der Innenstadt gemacht. In der Shopping-Mall hat sie bereits einige Geschfte im Sinn, die sie auf jeden Fall besuchen mchte. Auf dem Weg zum ersten Laden ihrer geistiEntwicklung einer Privatsphre erhaltenden Architektur fr Mobile Interaktion mit Pervasive Public Display Netzwerken 25
gen Liste achtet sie bereits auf die doppelseitigen Public Displays im Kioskformat, die auf jeder Etage etwa alle 10 Meter zu finden sind und auf einigen sieht sie bereits rote und weie Sommerkleider whrend sie auf die Displays zugeht. Vor dem Display, welches fast vor dem Geschft steht, das sie gesucht hat, bleibt sie schlielich stehen und schaut sich eine Auswahl von Sommerkleidern dieses Geschftes an. Per Berhrung klickt sie sich durch die Bilderliste bis sie schlielich ein Kleid entdeckt, dass ihr gefllt und welches sie zunchst in Vollbilddarstellung betrachtet. Anja mchte sich das Kleid genauer ansehen und betritt den Laden um es zu suchen und ggf. anzuprobieren. Enttuscht verlsst sie wenige Minuten spter das Geschft, da das Kleid ihr nach der Anprobe leider doch nicht zugesagt hat. Dann mal weiter denkt sie sich auf dem Weg in den zweiten Laden ihrer mentalen Liste. Unterwegs entdeckt sie schon von weitem ein Kleid auf einem Public Display, welches fast genau ihren Vorstellungen entspricht. Sie nhert sich dem Display und entdeckt, dass es in dem Laden zu finden ist, vor dem sie gerade steht, an dem sie bisher jedoch immer vorbeigelaufen ist. Motiviert besucht sie das Geschft zum ersten Mal und kommt nach einigen Minuten zufrieden mit einer Einkaufstasche wieder heraus. Das ging ja schneller als erwartet denkt sich Anja auf dem Weg Richtung Parkdeck. Da fllt ihr auf einem Public Display schon wieder ein RotWeies Sommerkleid ins Auge, welches von verschiedenen passenden Schuhen und Accessoires umgeben ist. Anja bleibt vor dem Display stehen, denkt sich Hmm, die Schuhe sehen wirklich gut aus und Zeit habe ich ja jetzt noch genug und spaziert in das gegenber liegende Geschft. Dieses Szenario behandelt die typische Pass-By Situation an Public Displays, wie z.B. in Einkaufsstraen. Passanten in Einkaufstrassen haben meistens eine konkrete Aufgabe im Kopf, der sie fokussiert nachgehen (z.B. rot-weies Sommerkleid suchen) oder sie sind weniger Ziel getrieben und vertreiben sich z.B. mit Shopping die Freizeit. Die zielgetriebene Gruppe verwendet dazu insbesondere die kognitive Fhigkeit der selektiven Wahrnehmung eine Methode des menschlichen Hirns, um aus der Masse von sensorischen Informationen, die darauf einprasseln, nur die gewnschten herauszufiltern. Nach dem Modell von Weiser und Brown [37] knnen mehrere sensorische Informationen gleichzeitig durch die periphere Wahrnehmung berwacht werden, um beim berwinden einer gewissen Schwelle schlielich einzeln in die primre Wahrnehmung berzugehen um genauer untersucht zu werden (z.B. optisches Fokussieren eines gesuchten Objekts, Hren des eigenen Namens). Erfahrung zeigen [2], dass digitale Bildschirme in Einkaufsstraen oft einfach ignoriert werden, auer sie treffen die optische selektive Wahrnehmung von Passanten, also Dinge nach denen diese gerade Ausschau halten (Shoppers were most responsive to messages that relate to the task at hand[3]). Der Public Shopping Assistent im Szenario nutzt Anjas Angaben um auf Public Displays in ihrer Nhe passende Suchergebnisse darzustellen. Diese werden zum einen mglichst angezeigt, sobald sich Anja in Sichtweite befindet und zum anderen an den Kontext des jeweiligen Displays angepasst. Letzteres bedeutet, dass passende Produkte, die in Geschften in unmittelbarer Nhe verfgbar sind, auch zuerst angezeigt werden. Die Displays im Szenario sind per Berhrung bedienbar und ermglichen dadurch einen erweiterten Funktionsumfang (z.B. browsen durch die Ergebnisse, Vergrerung, Wegbeschreibung zum Geschft des
Artikels, usw.). Jedoch auch ohne Touch-Screen knnten einige dieser Funktionen realisiert werden, z.B. durch eine Karussell-Funktion durch die besten Suchergebnisse. Im Szenario wird Anja schlielich durch ein Public Display auf ein Kleid aufmerksam, welches sie normalerweise nicht gefunden htte, da sie das jeweilige Geschft bisher nicht interessant fand. Die hhere Aufmerksam Anjas auf die Public Displays ist zum einen durch die vernderte Erwartungshaltung geprgt, nmlich dort interessante (personalisierte) Inhalte zu finden und zum anderen durch die selektive Wahrnehmung, welche automatisch auf die mglicherweise passenden Suchergebnisse aufmerksam wird. Eine weitere Funktion des Public Shopping Assistent ist es mglichst passende Produkte um die eigentlichen Suchergebnisse herum zu positionieren und somit zustzliche Kufe zu stimulieren. Dieses Szenario zeigt insbesondere wie Public Displays verwendet werden knnen, um reale Umgebungen mit lokalisieren und auf Personen in der Nhe abgestimmten Informationen anzureichern, die sonst nicht zu sehen wren. Diese Informationen knnen wahrgenommen werden, mssen es aber nicht zwingend. Insgesamt hat Anja in diesem Szenario zum einen ein Produkt gefunden, dass sie sonst mglicherweise nicht gefunden htte und zum anderen hat sie durch das System Zeit gespart. Zur Aktivierung des Shopping Assistenten waren dabei nur einmalig wenige Sekunden zur Eingabe des Suchwortes auf ihrem Smartphone ntig, danach war keine direkte Interaktion mehr mit dem Telefon notwendig. 4.1.3 Szenario 3: Zeitvertreib und soziale Interaktion Max fhrt tglich mit der S-Bahn und U-Bahn zur Universitt. Es steigt im Hauptbahnhof um und muss meistens ein paar Minuten auf dem Bahnsteig auf die U-Bahn warten. Die Wartezeit berbrckt er oft mit Musikhren und dem Surfen im Internet ber sein Smartphone. Regelmig betrachtet er auch die Inhalte auf den groen Public Displays gegenber seinem Bahnsteig sie sind so angebracht, dass man sie praktisch nicht bersehen kann. Sie bieten eine Mischung aus Werbung, Schlagzeilen und Wettervorhersage, wiederholen sich jedoch nach wenigen Minuten. Vor kurzem hatte Max eine App heruntergeladen, mit der er Inhalte auf den Werbedisplays in der Innenstadt beeinflussen konnte. Er muss noch mindestens 5 Minuten auf seine Bahn warten, weshalb Max sein Smartphone herausholt und nachschaut welche Public Display-Anwendungen wohl hier verfgbar sind. Er whlt eine Anwendung namens Public Opel Pong aus und wird aufgefordert einen Spielernamen einzugeben. Nach der Eingabe von MegaMax aktiviert er die Anwendung auf seinem Telefon. Innerhalb weniger Sekunden wird auf dem groen Public Display gegenber ein Pong Spiel angezeigt, dessen Paddel auf der linken und rechten Seite aus kleinen Opel Automodellen besteht. Durch das Hoch- und Runterneigen seines Telefons kann Max das kleine Auto auf der linken Seite (mit seinem Namen in der oberen Ecke) in Echtzeit hoch und runterfahren. Auf der rechten Seite wird jedoch ein groer QR-Code angezeigt ber dem steht Jetzt einscannen und Spiel starten. Max begreift, dass er fr dieses Spiel einen Mitspieler braucht. Er schaut sich links und rechts um und entdeckt schon bald mehrere Leute, die ihr Telefon bereits auf das Display ausrichten um offenbar den QR-Code zu scannen. Da verschwindet
27
auch schon der QR-Code, ein Count-Down zhlt von 5 herunter und der Ball fngt an sich zu bewegen. Max bewegt sein Paddel, verfehlt den Ball jedoch knapp und ermglicht so den ersten Punkt fr den anderen Spieler. Neugierig schaut sich Max um und entdeckt eine junge Frau ein paar Meter entfernt mit einem grinsen im Gesicht. Auch sie schaut sich um und entdeckt Max, der sie ebenfalls anlchelt. Gleichzeitig bemerkt Max, dass auch die vielen anderen Personen auf dem Bahnsteig dem Geschehen folgen oder sich offenbar mit Freunden ber das Spiel unterhalten. Die nchste Runde geht los und Max packt nun der Ehrgeiz. Schlielich kommt er nach kurzer Zeit doch als erster auf 5 Punkte und das Spiel wird mit einer Bestenliste abgeschlossen, die kurz angezeigt wird. Max taucht dort sogar relativ weit vorne auf. Er sieht zu seiner Mitspielerin rber, die mit den Schultern zuckt und lacht. Gleichzeitig sieht er seine Bahn einfahren und wundert sich, dass die Zeit so schnell vergangen ist. Mal sehen wer morgen mitspielt denkt sich Max fast schon mit ein wenig Vorfreude. Public Displays knnen im Gegensatz zu Laptop- oder Handy-Displays von vielen Personen gleichzeitig gesehen werden. Desto grer und ggf. exponierter diese sind, desto mehr Leute erreichen sie in der Regel. Dies trifft ganz besonders fr Umgebung zu, in denen regelmig Wartesituationen entstehen und Menschen einen lngeren Zeitraum in Sichtweite von Public Displays verbringen. Soziale Normen, die dazu fhren, dass Fremde in engen Situationen Augenkontakt vermeiden, verstrken die Aufmerksamkeit auf Public Displays zustzlich. Wie das Szenario zeigt, bieten solche Umgebungen jedoch auch Chancen zur spielerischen sozialen Interaktion mit Hilfe von Public Displays [24]. Wie Max zunchst nicht wei, ist das Spiel, das er auf dem Bahnsteig gegenberliegenden Display aufruft, fr zwei Spieler gedacht. Seine anfngliche Motivation zur Interaktion mit dem Public Display ist durch Langweile und Neugier geprgt (die sich wiederholenden Inhalte des Displays hat er nun schon mehrfach gesehen). Gleichzeitig versprt er keinerlei soziale ngste, da ihm bewusst ist, dass die Personen in seiner Umgebung nicht wissen, dass Max mit dem Display interagiert. Als das Spiel nun zum Mitspielen auffordert, wird auch die Aufmerksamkeit und Neugier der anderen Personen in Sichtweite des Bildschirms gewonnen und schon bald ein Mitspieler gefunden. Obwohl beide Spieler anonym sind, schafft das gemeinsame Spielen eine gewisse Bindung, so dass die Kontrahenten schlielich auch neugierig nach Augenkontakt suchen. Diese Mglichkeit zum Aufbrechen sozialer normen mit Hilfe von Public Displays ist auch Thema anderer Arbeiten [38]. Weiterhin bewirkt das interaktive Spiel auch eine verstrkte Aufmerksamkeit des umstehenden Publikums, da diesem klar ist, dass sich die Spieler unter ihnen befinden mssen. Von dieser Aufmerksamkeit profitiert in diesem Fall der Sponsor dieses interaktiven Spiels (hier z.B. Opel). Sieger solcher interaktiven Spiele knnen z.B. wie beschrieben mit Bestenlisten motivierten oder z.B. mit Hilfe von Coupons belohnt und somit zu Folgeaktionen animiert werden. Die Interaktion mit dem Public Display erfolgt in diesem Szenario ferngesteuert ber die Smartphones der Personen in Reichweite des Bildschirms. Wie im Beispiel, knnen viele ffentliche digitale Anzeigeflchen nicht per Berhrung oder Gestenerkennung gesteuert werden, weil sie auerhalb der Reichweite von Personen
sind (z.B. hier auf der anderen Seite der Gleise) oder die Personen auerhalb der Reichweite von Sensoren des Displays. Die Steuerung ber Mobiltelefone, die ohnehin stndig gegenwrtig sind, bietet deshalb einen einfachen und generell anwendbare Kanal zur impliziten und expliziten (Echtzeit-)Interaktion mit Public Displays. Anzeigeflchen, die bereits direkte Interaktion untersttzen (z.B. per Berhrung), knnen dabei insbesondere von der impliziten Interaktion (Prsenz) profitieren, wogegen bisher nicht-interaktive Public Displays zustzlich noch einen Kanal zur direkten Interaktion erhalten. Zudem bietet diese Art der Interaktion den Steuernden, falls diese sich in Menschenmengen aufhalten, eine gewisse Anonymitt, obwohl sie sich in Sichtweite des Bildschirms befinden. Somit knnen Personen mit Anzeigeflchen interagieren ohne identifizierbar zu sein und daher auch ggf. peinliche Situationen vermeiden. Zusammenfassung Mit Hilfe von Szenarien wurden drei Nutzungsflle in unterschiedlichen Situationen skizziert (1. explizite Nutzung, 2. Pass-By Situation, 3. Wartesituation), in denen eine implizite und explizite Interaktion mit Public Displays von Vorteil fr die Nutzer war. So hat Achim ffentliche Anzeigeflchen genutzt um sich im Ausland gezielt und in seiner Sprache ber seine direkte Umgebung zu informieren. Anja hat die Displays in einer Shopping-Mall beim Vorbeilaufen dazu genutzt, um sie beim gezielten Einkauf zu untersttzen und Produkte in ihrem Kontext sichtbar zu machen, die sie sonst nicht bemerkt htte. Max konnte schlielich mit Hilfe eines interaktiven Spiels seine Wartezeit berbrcken und gleichzeitig unverhofft in soziale Interaktion mit bisher Unbekannten treten. Diese und viele weitere ntzliche und unterhaltsame Public Display Anwendungen werden durch die neugewonnene Interaktivitt und Personalisierbarkeit von Public Displays mglich. Fr Display Owner ist in diesem Zusammenhang die gesteigerte Wahrnehmung und messbare Nutzung ihrer Display Flchen interessant. Fr Application Provider wird dagegen praktisch ein neuer Markt geschaffen. Szenario 3 zeigt dabei beispielhaft, wie interaktive Public Display Anwendungen und kommerzielle Werbung (Opel) attraktiv kombiniert werden knnen.
4.2 Anforderungen
Eine Architektur fr potentiell globale Pervasive Public Display Netzwerke, die mindestens die in den Szenarien beschriebene Funktionalitt ermglichen soll, muss eine Vielzahl funktionaler und qualitativer Anforderungen erfllen. Diese werden im Folgenden genannt und kurz beschrieben.
29
4.2.1 Funktionale Anforderungen Unterst tzung impliziter I nteraktion Wie in allen drei Szenarien deutlich wurde, ist die Wahrnehmung der Prsenz von potentiellen Nutzern in der Nhe von Public Displays eine wesentliche Anforderung zur Ermglichung impliziter und expliziter Interaktion mit Public Displays. Durch die Wahrnehmung von Prsenz knnen digitale Bildschirme in der Umgebung einer Person vielfltigste Aufgaben auf unterschiedliche Arten bernehmen (z.B. Ambient Information Systems [17,39]) und dadurch einen erheblichen Mehrwert bieten. Die Prsenz kann dabei als Kombination aus reiner rumlicher Nhe einer Person und einer Menge von dessen Prferenzen betrachtet werden (z.B. das Interesse an Architektur). Wie die Szenarien zeigen, kann das Smartphone ein Weg sein, um diese Prferenzen implizit zu ueren und so Public Displays in direkter Umgebung zu beeinflussen. Personalisierung von Public Display Inhalten Viewer sollten die Mglichkeit haben Inhalte auf Public Displays implizit und explizit beeinflussen zu knnen, solange sie sich in ihrer Nhe befinden. Die Inhalte auf digitalen Anzeigen knnen dabei von statischen Inhalten wie Bildern ber dynamische Inhalte wie Videos bis hin zu komplexen interaktiven Anwendungen reichen. Aktuelle Public Displays zeigen bereits statische und dynamische Inhalte an, manchmal sogar interaktive Anwendungen. Jedoch sind diese Inhalte bisher gar nicht oder schwach an ihren Kontext sowie ihr direktes Publikum angepasst. Desweiteren hat das Publikum von Public Displays heutzutage bisher keine Mglichkeit Public Display Infrastrukturen temporr fr sich zu nutzen, z.B. durch gewnschte Anwendungen. Zuknftige Public Display Netzwerke sollten sich somit fr verschiedenste Anwendungen ffnen, die spontan durch das Publikum angefragt werden knnten. Display Anwendungen sollten sich dabei automatisch an den Kontext des aufrufenden Displays sowie die Prsenz und Prferenzen des Publikums anpassen. Der Kontext eines Public Displays kann dabei aus vielen Information bestehen, u.a. Position, Lage, Ausrichtung, Bildschirmgre, Format, Form, Umgebungsinformationen, Sensorinformationen u.v.m. Gleichzeitig ist es jedoch wichtig, dass Display Owner weiterhin Einfluss auf die Inhalte und die Nutzung ihrer Infrastruktur haben. Unterst tzung direkter I nteraktion In vielen Situationen ist die implizite Interaktion mit Public Display Inhalten nicht ausreichend, z.B. falls die Bildschirme keine direkte Bedienung durch Touch oder Gesten untersttzen oder falls diese nicht zugnglich sind, jedoch trotzdem interaktive Inhalte aufgerufen werden, welche Bedienung verlangen. Zu diesem Zweck soll deshalb direkte Interaktion in Echtzeit zwischen den Mobilgerten des Publikums und der auf einem Public Display gerade ausgefhrten Anwendung ermglicht wer-
30
den. Eine Anwendung selbst soll dabei entscheiden wie viel Personen gleichzeitig mit Ihr interagieren knnen (z.B. zwei Spieler beim Pong Spiel in Szenario 3). 4.2.2 Qualitative Anforderungen Privacy Wie bereits beschrieben basiert die geforderte Mglichkeit der impliziten Interaktion auf der Wahrnehmung der Prsenz von Personen in der Nhe von Public Displays. Typische Anstze zur Bestimmung der relativen oder absoluten Position von Personen beruhen zumeist auf dem Tracking von Mobilgerten (Smartphone, Badge, etc.) die diese Personen mit sich fhren und diese eindeutig identifizieren. Diese Anstze ermglichen jedoch gleichzeitig leicht das Anlegen von Bewegungsprofilen und implizieren ein vorhandenes Vertrauensverhltnis zur berwachenden Infrastruktur. In der Realitt heterogener Public Display Netzwerke sind solche Vertrauensverhltnisse jedoch weder vom Viewer gewollt noch realistisch. Gleichzeitig basiert die Personalisierung von Public Displays in rumlicher Nhe auf der Notwendigkeit Prferenzen zu bermitteln und die Prsenz des Nutzers wahrzunehmen. Eine mgliche Lsung soll dem Viewer daher die volle Kontrolle darber geben wann, mit wem und welche Daten er teilen will, jedoch gleichzeitig praktikabel bleiben. Interoperabilitt Die beschriebene Funktionalitt soll ohne spezielle Anforderungen und Aufwand in mglichst gleichzeitig viele verschiedene kommerzielle Public Display Media-Player und Middleware-Systeme integrierbar sein oder optional unabhngig von diesen betrieben werden knnen. Skalierbarkeit Eine Architektur zur Untersttzung der genannten Funktionalitt soll auch noch bei einer groen Zahl von Displays, Nutzern und Anfragen nutzbar und performant bleiben und optimaler Weise in die Vision von offenen globalen Pervasive Public Display Netzwerken hineinpassen. Performanz Zur Untersttzung impliziter Interaktion ist es notwendig, dass die Personalisierung von Public Display Inhalten optimaler Weise in einem Zeitfenster stattfindet, indem das Display gerade in Sichtweite des Viewers kommt oder aber sptestens bevor der Viewer das Display bereits passiert hat (Pass-By Situation als Referenz-Fall). Desweiteren erfordert die Bedienung per direkte Interaktion mglichst schnelle Reaktionszeiten. Abhngig von der interaktiven Anwendung, sind mglicherweise jedoch auch leichte Verzgerungen akzeptabel.
31
Kapitel 5 - Architektur
5 Architektur
Die im Folgenden beschriebene, Tacita getaufte Architektur, wurde im Rahmen des PD-Net Projekts [40] in Zusammenarbeit mit Prof. Nigel Davies und Prof. Marc Langheinrich erarbeitet und im Rahmen eines sechs monatigen Aufenthalts an der Lancaster University (UK) durch den Autor dieser Arbeit weiterentwickelt, implementiert und auf der dortigen Public Display Infrastruktur [41] evaluiert. Aufbauend auf den funktionalen und qualitativen Anforderung, wird in diesem Kapitel eine leicht einsetzbare, verteilte Architektur vorgestellt, die es Personen erlaubt mit Hilfe ihres Mobiltelefons, Inhalte auf nahen Public Displays implizit und explizit zu beeinflussen und mit diesen Inhalten ber ihr Mobiltelefon in Echtzeit interagieren zu knnen, ohne durch die unbekannte, spontan genutzte, Display-Infrastruktur verfolgbar oder identifizierbar zu sein. Die Beschreibung der Architektur lsst dabei, soweit mglich, technische Details auer Acht und bleibt auf einem eher abstrakten Niveau. Wo es fr das Verstndnis notwendig ist, werden jedoch ggf. konkretere Implementierungswege oder Technologien vorgeschlagen. Die Beschreibung einer konkreten prototypischen Implementierung der Komponenten dieser Architektur erfolgt dagegen im nchsten Kapitel. Diese Kapitel beginnt mit einer Einfhrung in das Schlsselkonzept der Tacita Architektur, gibt einen berblick ber dessen Komponenten und deren Zusammengang, um schlielich die einzelnen Komponenten genauer zu diskutieren.
5.1 Grundkonzept
Das Konzept von Tacita wird insbesondere durch zwei grundlegende Designentscheidungen geprgt - dem Broadcast von Display-Eigenschaften sowie indirekter Kommunikation mit Hilfe von Display Anwendungen (Display Apps). 1. Broadcast von Display Eigenschaften: Bisherige Anstze zur Wahrnehmung von Prsenz in der Nhe von Public Display wie z.B. dem Tracking mit Hilfe von IDs[42] oder dem Broadcast von Prferenzen durch Viewer [14], bringen offensichtliche Nachteile mit sich, wie z.B. die Notwendigkeit zustzlicher Infrastruktur sowie Privacy Probleme. Der Ansatz in dieser Arbeit kehrt deshalb die bliche Praxis um, so dass nun Public Displays ihre Fhigkeiten publizieren und diese von Viewer-Mobilgerten in der Nhe wahrgenommen werden knnen (Abbildung 3). Auf Basis der empfangenen Informationen knnen die Prferenzen von Viewern auf deren Mobilgerten nun mit den verfgbaren Fhigkeiten verglichen und ggf. automatisch Anfragen zur Personalisierung versendet werden. Wie spter gezeigt wird, ist fr die reine bermittlung von Display-Fhigkeiten zum Mobiltelefon keine besondere bertragungstechnologie notwendig, ja nicht einmal rumliche Nhe, sondern lediglich ein Weg zur bermittlung von Display-Fhigkeiten an Mobilgerte.
32
Abbildung 3: Broadcast von Display-Eigenschaften und Anwendungs-Aufruf
2. Indirekte Kommunikation: Die zweite wesentliche Designentscheidung besteht darin, smtliche Interaktions-Anfragen des Viewer-Mobilegertes direkt an die gewnschte Applikation, welche zur Personalisierung genutzt werden soll, zu richten, anstatt direkt mit dem Public Display zu kommunizieren. Die Display Anwendung, welche z.B. in der Cloud liegt, erhlt ggf. notwendige Parameter vom Viewer2, um dann eine Aufruf-Anfrage an das gewnschte Public Display zu senden. Dieses kann dann, abhngig von seinem Zustand sowie Policies, die anfragende Display-Anwendung direkt abrufen und anzeigen, sie fr einen spteren Zeitpunkt parken oder ggf. ganz ablehnen. Die Kombination dieser beiden Anstze ermglicht es Viewern, gnzlich unsichtbar fr die typischerweise unbekannte und daher nicht vertrauenswrdige Public Display Infrastruktur zu bleiben, jedoch indirekt trotzdem implizit und explizit mit dieser interagieren zu knnen. Vertrauens-Modell und Display Apps Die Kontrolle darber welche personalisierten Inhalte wann fr welches ffentliche Display angefordert werden, liegt dabei beim Viewer. Dieser kann ber sein Mobilgert seine Prferenzen dadurch uern, dass er aus einer Menge verfgbarer Public Display Anwendungen, diejenigen aktiviert und mit Parametern versieht, die er auf nahen Public Displays nutzen mchte. Gleichzeitig haben Display Owner die endgltige Kontrolle darber, welche Display Anwendungen, wann, wie oft und ggf. wie lange auf ihren Displays ausgefhrt werden knnen.
Abhngig vom Kontext wird Viewer ggf. auch als Abkrzung fr Viewer-Mobilgert verwendet. 33
Abbildung 4: Vertrauensbeziehungen zwischen Stakeholdern und Anwendungen
Sowohl Viewer als auch Display Owner bauen somit eine Vertrauensbeziehung zu Display Applikationen auf sobald sie sich entschlieen diese zu nutzen bzw. diese zur Nutzung freizugeben (Abbildung 4). Display Owner knnen dabei ein breites Band von Policys untersttzen, von der Erlaubnis jeglicher Anwendungen, ber das Zulassen ausgewhlter Anwendungen zu bestimmten Zeiten oder in Kontingenten, bis hin zur dauerhaften Ausfhrung einer einzigen oder gar keiner Anwendung. Anwendungen, die durch den Display Owner zur dauerhaften Ausfhrung ausgewhlt wurden, knnen dabei auch komplett auf mglicher Personalisierung durch das Publikum verzichten und stattdessen vorgegebene Aufgaben erfllen. Die Verwendung von Anwendungen oder Apps, die von dritten Parteien angeboten werden und zur flexiblen Ergnzung spezifischer Funktionalitt dienen, ist nicht neu und mittlerweile ein sehr populres Konzept (z.B. Facebook-Apps, Google+ und Google Chrome-Apps, iPhone- und Android-Apps). Ein Vertrauensverhltnis mit einer Display App wird dabei in zwei Schritten aufgebaut. Zunchst kann ein potentieller Nutzer sich mit Hilfe von App-Metadaten ber Zweck, Funktionsumfang, Anforderungen, Anbieter, Nutzungs- und Datenschutzbedingungen, usw. einer App informieren und sich dann ggf. im zweiten Schritt dazu entschlieen diese zu aktivierten bzw. zu installieren und bei Bedarf zu nutzen oder auch jederzeit wieder zu deaktivieren. Mit Hilfe von Display Apps wird nun dasselbe, bereits allgemein akzeptierte Konzept auf Anwendungen fr Public Display Netzwerke bertragen. Im Gegensatz zu z.B. Apps fr Smartphones sollen in Public Display Netzwerken die gleichen Display Apps durch Viewer und Display Owner genutzt werden, wobei Display Owner als Besitzer der Infrastruktur andere Interessen verfolgen als Viewer. Dies fhrt generell zu komplexeren konomischen Geschftsmodellen. Diese werden an anderer Stelle dieser Arbeit skizziert. Unter Bercksichtigung der geforderten funktionalen und qualitativen Anforderungen wird dieses Konzept nun im folgenden Abschnitt konkretisiert und eine BasisArchitektur prsentiert.
34
5.2 Basis Architektur

5.2.1 bersicht Wie Abbildung 5 verdeutlicht, besteht die Basisarchitektur aus fnf notwendigen Komponenten: Den Display Nodes, welche die physikalischen Rechner darstellen und die einen Media Player ausfhren, welcher fr die Anzeige von Inhalten auf einem oder mehreren angeschlossenen Public Displays verantwortlich ist, Einer Menge von Display Apps, die potentiell von Drittanbietern angeboten und auf deren Infrastruktur oder in der Cloud betrieben werden, Einer mobilen App fr Viewer, die fr die Verwaltung von NutzerPrferenzen, die Wahrnehmung naher Displays und ihrer Fhigkeiten sowie die Kommunikation mit Display App genutzt wird, Sowie einem Service Directory, dass die bertragung von Display Fhigkeiten zur mobilen App von der Notwendigkeit entkoppelt, tatschlich in Rumlicher Nhe eines Public Displays sein zu mssen.
Display Owner
Display Node Display Display Node MediaNode Player
Publish Capabilities
Service Service Directory Directory
Request Display Foreground
Get Content
Near Display
Download Database Viewer
Display Display Display Application Application Application

Application Provider
Request Personalisation Mobile App
Abbildung 5: Basis-Architektur
Display Apps knnen entweder direkt durch Media Player aufgerufen und angezeigt werden (z.B. bei dauerhafter Nutzung) oder sie werden durch die Mobile App eines Viewers aufgefordert, bei einem bestimmten Display die Anzeige dieser App anzufragen. Erhlt ein Media Player auf einem Display Node diese Anfrage, so wird diese basierend auf den Policies des Display Owners berprft, ggf. erlaubt und die gewnschte Anwendung aufgerufen und angezeigt. Die Art des Abrufs, der Ausfhrung und der Anzeige einer Display App wird auf dieser architektuellen Ebene nicht weiter konkretisiert, ist aber vom verwendeten bertragungsprotokoll und der ver-
35
wendeten Media-Player Software abhngig. Mit Hilfe den von jeder Display App zur Verfgung gestellten App-Metadaten, knnen Display Owner fr jedes Ihrer Displays festlegen, ob und welche Display Apps sie zum Aufruf durch Viewer erlauben mchten (Policies). Die Fhigkeiten eines Public Displays (bestehend aus Display-ID, Name, Geo-Position, erlaubten Display Apps, etc.) werden in Form von Public Display Metadaten in einem oder mehreren Service Directories publiziert. Service Directories werden von der mobilen App verwendet, um Display Metadaten fr ganze Regionen abzurufen und lokal zu cachen. Mit Hilfe dieser lokalen Datenbanken und mit dem Wissen der eigenen Position und der Prferenzen des Viewers, knnen nun Display Apps auf nahen Public Displays durch die mobile App implizit oder explizit angefordert werden. Im Weiteren werden nun die einzelnen Komponenten, ihre Funktionen sowie Schnittstell und Metadaten genauer beschrieben und diskutiert. 5.2.2 Display Node Ein Display Node ist als physikalische Komponente genaugenommen nicht Teil der beschriebenen Architektur von Software-Komponenten, sondern fhrt als HostRechner lediglich die Media Player Komponente aus. Trotzdem werden Display Nodes in Abbildung 5 beibehalten, um die rumliche Assoziation zwischen Mobilgerten von Viewern (und der darauf ausgefhrten mobilen App) zu illustrieren. Display Nodes sind somit fr den Langzeitbetrieb und ggf. Outdoor-Betrieb ausgelegte Rechner [41,43], die ein oder mehrere Displays ansteuern, vernetzt sind und eine Software zur Verwaltung und Wiedergabe von Inhalten ausfhren (Media Player). Desweiteren sind an diese Rechner ggf. Sensoren angeschlossen, die zur Interaktion mit dem Display dienen (z.B. Kameras, Kinect, NFC-Reader, Bluetooth, etc.) oder erweitere Kontextinformationen anbieten (z.B. Temperatur, Umgebungslicht, Anzahl Personen vor dem Bildschirm, usw.). Display Nodes haben in der Regel Zugriff zum Internet um beliebige Inhalte abzurufen und ggf. cachen zu knnen. 5.2.3 Display App Eine Display App3 ist eine Anwendung speziell fr Public Displays, die potentiell von Drittanbietern (Application Provider) entwickelt und betrieben wird. Sie kann prinzipiell jede Ausfhrungs-Form haben, die vom Media-Player auf dem aufgerufenen Display untersttzt wird. Denkbare Mglichkeiten wren u.a. kompilierte ausfhrbare Programme, virtuelle Maschinen, oder Webseiten. Letzterer Ansatz wird z.B. im Kapitel Implementierung verwendet um komplexere interaktive webbasierte Display-Apps zu realisieren. Eine Anwendung kann von der Anzeige eines simplen Bildes bis hin zu einem interaktiven 3D-Spiel verschiedenste Zwecke und unterschiedlichste Komplexitt besitzen.
3
Oder hier auch App. Applikationen fr Mobilgerte werden zur Abgrenzung immer als mobile App bezeichnet 36
Media Player auf aktuellen Public Displays spielen meistens nur vorgegebene Inhalte ab und sind somit selbst eine Art Display App die jedoch dauerhaft als einzige App ausgefhrt wird und keinerlei Kanle zur Personalisierung und Interaktion bietet. Die Tacita Architektur fokussiert jedoch eine Vision, in der die Funktionalitt von traditionelle Media Playern auf Displaysystemen mit Hilfe eines lebendigen kosystems von Apps realisiert wird, aus dem sowohl Display Owner als auch Viewer greifen knnen um gewnschte Inhalte gezielt auf Public Displays zu bekommen. Nutzungsflle Es lassen sich drei Nutzungsflle einer Display App zusammenfassen, die durch Display Owner bzw. Viewer beeinflusst werden (Abbildung 6): 1. Keine Personalisierung: In diesem Nutzungsfall hat der Display Owner eine oder mehrere Display Apps ausgewhlt, die dauerhaft ausgefhrt werden (hier z.B. eine Ads App die zur Wiedergabe von Werbeinhalten), die jedoch keine Schnittstelle fr mobile Viewer-Personalisierung bieten. 2. Einzel-App Personalisierung: Der Display Owner fhrt dauerhaft eine einzige App aus, die auch von mobilen Viewern beeinflusst werden kann (hier z.B. eine News App, die zustzlich zu anderen Themen auch Sportnachrichten anzeigt). 3. Multi-App Personalisierung: Mehrere personalisierbare Apps sind gleichzeitig verfgbar. Im Beispiel wird z.B. eine Ads App zur Anzeige von Werbeanzeigen dauerhaft angezeigt und bei Bedarf von einer News-App berlagert. Unterschiedliche Strategien zur Darstellung mehrerer Display Apps gleichzeitig auf einem Display werden im Abschnitt Media Player vorgestellt.
1. No Personalisation 2. Single-App Personalisation Display Node Media Player News App
Topic: Sport,...
3. Multi-App Personalisation Display Node Media Player Ads News App App
Display Request
Display Node Media Player Ads App
Display Request
News App
Viewer Request : Topic: Sport
Viewer
X
Display Request
News App
News App
Viewer
Viewer
Abbildung 6: Display-App Nutzungsflle

37
Personalisierung Sowohl bei der Anfrage einer Display-App durch einen Viewer, als auch beim Aufruf durch das gewnschte Display knnen Prferenzen in Form von Parametern an eine Display App bergeben werden. Diese knnen dann dazu genutzt werden, um die Wiedergabe der Inhalte von Display Apps entsprechend zu personalisieren. Im ersten Szenario aus dem letzten Kapitel verwendet Achim z.B. eine TourismusDisplay-App, um die ffentlichen Anzeigeflchen um sich herum mit seinen Prferenzen Geschichte und Architektur zu personalisieren. Die Displays auf denen diese Display-App schlielich aufgerufen wird, ergnzen die App um weitere Parameter (z.B. Display-Geoposition) und ermglichen schlielich den Abruf von Tourismusinformationen fr die direkte Umgebung. Somit hat eine Display-App beim Aufruf durch ein Display immer auch Zugriff auf dessen Metadaten und erhlt dadurch Zugriff auf wertvolle Kontext-Informationen zur Anpassung seines Inhalts. Wurde eine Display App schlielich im Media Player eines Display Nodes geladen und ausgefhrt, so kann der Media Player der App mglicherweise ber zustzliche Schnittstellen Zugriff auf weitere Sensoren bieten. Weiterhin kann eine Display App z.B. Verbindungen zu anderen entfernten Rechnern aufbauen um z.B. zustzliche Daten abzurufen (News, Wetterdaten, Aktien, usw.) oder sogar persistente Kommunikation (ggf. in Echtzeit) zu ermglichen. Schnitts tellen Eine Display App sollte mindestens folgende Schnittstellenaufrufe4 bieten:
API: Display App Public: getApp(display_preferences): app getMetadata(): app_metadata requestDisplay(display_id,display_url,viewer_preferences): result sendDisplayRequest(app_id,callback_parameters[,metadata_url]): result
Tabelle 1: Abstrakte API Display App
Private:
ber getApp wird die Display App selbst vom Display abgerufen und ihr dabei Prferenzen des Displays und sonstige Parameter bergeben. getMetadata ruft die Metadaten einer Display App ab. ber den Aufruf von requestDisplay kann die mobile App unter der Spezifikation des Displays (z.B. per ID und URL) und Viewer Prferenzen den Aufruf dieser Anwendung auf dem angegebenen Display anfordern. Die private Funktion sendDisplayRequest dient intern dem Absenden einer Anfrage an die zuvor vom Viewer ber die Funktion requestDisplay erhalte display_url des ge4
Beschrieben mit der Syntax: functionsname(parameter): rckgabe 38
wnschten Public Displays. Dabei werden zustzlich mglicherweise bestimmte callback_parameter bergeben, die zur Identifikation der ursprnglichen Anfrage (Request-Session) dienen, sobald die App-Anfrage vom Media-Player des Public Displays akzeptiert und die App ber getApp aufgerufen wird. Metadaten Die Metadaten einer Display App sollten mindestens folgenden Informationen enthalten:
Metadaten: Display App App-ID Typ:[Executable,VM,Website,] Name Beschreibung Nutzungsbedingungen Anbieter (Name, Email, Website) Screenshots (Image1:URL, Image2:URL,) Metadata-URL App-URL Display-Parameter (Parameter1:[Value5,Value6],) Viewer-Aufruf-URL Viewer-Parameter (Parameter1:[Value1,Value2,Value3],)
Tabelle 2: Abstrakte Metadaten Display App
Mit Hilfe einer App-ID wird eine Display App eindeutig identifiziert. Der Typ bestimmt die Art des Aufrufs und der Ausfhrung dieser Anwendung. Die nchsten fnf Angaben dienen der reinen Information fr Viewer und Display-Owner. Die Metadata-URL referenziert den Ursprung der Metadaten (Selbstreferenz) und ermglicht so die jederzeitige Aktualisierung von der Quelle. Die App-URL ermglicht einem Media Player den Abruf der Display App (Referenz auf getApp der API in Tabelle 1) und Display-Parameter definiert die dabei zur Verfgung stehenden Parameter. Die Viewer-Aufruf-URL dient dagegen dem Viewer zur Anfrage von Personalisierungsanfragen ber die mobile App. Viewer-Parameter definieren dazu verfgbare Parameter und ggf. vorgegebene Werte. 5.2.4 Media Player Die Media Player aktueller Public Display Systeme untersttzen zumeist nur statische und dynamische Inhalte (Bilder, Video, Webseiten), die basierend auf Zeitplnen wiedergegeben werden. Dazu laden sie regelmig Playlisten herunter, die durch separate Software ihrer Verwalter erstellt werden, cachen die Inhalte der Playliste lokal und geben diese nach Zeitplan wieder. Seltener untersttzen Public Displays und dessen Media-Player bisher direkte Interaktion (z.B. per Berhrung) und damit die Bedienung interaktiver Display Anwendungen, wie dies z.B. der Fall in
39
[43] ist. Praktisch kein (kommerzielles) ffentliches System dagegen ermglicht bisher die Ad-hoc Interaktion mit und Personalisierung durch mobile Viewer. Integration mit klassischen I nhalten Eine mgliche zuknftige ffnung von Pervasive Display Netzwerken fr DisplayApps und mobile Viewer Personalisierung verlangt ggf. zunchst nach einer schrittweisen Integration vorhandener Systeme und Anzeigestrategien mit neuen Funktionen. Dabei unterscheidet sich die bisherige planbare, zeitlich lineare Wiedergabe von Inhalten auf Public Displays vollstndige von der spontanen, durch Viewer beeinflussten, App-basierten Generierung. Zweifellos lassen sich komplizierteste Regeln definieren, um geplante Inhalte und spontan angefragte Display-Apps zu kombinieren. Zur Erhaltung der Einfachheit wird an dieser Stelle jedoch ein simples Model vorgeschlagen. Media Player werden dazu um eine Schnittstelle ergnzt, um externe Anfragen zum Aufruf von noch nicht ausgefhrten Display Apps annehmen zu knnen. Wenn keine Personalisierungsanfragen vorliegen, wird die geplante Playlist wiedergegeben. Sobald eine Anfrage einer durch die lokale Policy erlaubten App eingeht, wird die Playlist angehalten, die Display App gestartet und mit dessen Inhalten berlagert (hhere Prioritt). Ist der Viewer auerhalb der Reichweite des Displays, so wird die Display App wieder ausgeblendet und die Playlist fortgesetzt. Auf diese Weise lassen sich Wiedergabezeiten geplanter traditioneller Inhalte nachvollziehen (z.B. zur Abrechnung mit Advertisern) und gleichzeitig Personalisierung untersttzen. Durch das Konzept zeitlicher und oder Aufrufzahl-basierter Kontingente liee sich zudem das Nutzungsvolumen von Display-Apps eingrenzen. Diese Strategie zielt offensichtlich auf aktuelle kommerzielle digitale Anzeigeflche fr traditionelle Werbung ab. Betrachte man jedoch Szenario zwei aus dem vorhergehenden Kapitel, so wird durch die Public Shopping Assistant Display App deutlich, dass Display Apps auch dauerhaft auf Public Displays ausgefhrt werden knnen und sogar leicht die Aufgabe von klassischen Media Playern bernehmen knnen. Daher wrden bei einem Grne Wiese-Szenario (d.h. ohne die Notwendigkeit der Untersttzung vorhandener Media Player Software) einfach eine Media Player Display App zur Wiedergabe geplanter Inhalte dauerhaft ausgefhrt und ggf. mit anderen Display Apps berlagert, die durch Viewer angefordert wurden (Analog zur weiter oben genannten Strategie). Um eine konsistente Nutzung von Display Apps zu forcieren, wird deshalb im weiteren Verlauf dieses Kapitel davon ausgegangen, dass die klassische lineare Wiedergabe von Inhalten ebenso durch eine entsprechende Display App bereitgestellt wird (die jedoch dauerhaft aktiviert ist). Display Owner Policies Zur Erhaltung der Kontrolle von Bildschirminhalten durch den Display Owner, kann dieser eine Menge von Regeln definieren, die den Aufruf von Display Apps durch mobile Viewer reglementieren. Diese Policies knnen prinzipiell bestimmen welche
Apps gestartet werden knnen, zu welchen Zeiten, wie lange, wie oft und natrlich auf welchen Displays. Diese Regeln knnen natrlich beliebig komplex gestaltet werden und hngen von der Implementierung des Media Players ab. Zur Erhaltung der Einfachheit wird in dieser Arbeit ein simplerer Regelsatz vorgeschlagen. Dieser basiert auf dem beidseitige Vertrauensverhltnis mit Display Apps (Abbildung 4) um deren Aufruf zu kontrollieren. So kann ein Display Owner ber die Einstellungen des Media Players entweder keine Apps, alle (unbekannten) Apps, oder eine oder mehrere bestimmte Apps zur Nutzung durch mobile Viewer auswhlen. Erweiterte Einstellung zur Darstellung von Display App regeln schlielich auf welche Art (einzelnd oder parallel) und wie lange angefragte Apps angezeigt werden. Diese Policies erlaubter Anwendungen werden ber die Display-Metadaten publiziert und erlauben es Viewern durch die mobile App gezielt implizit und explizit (erlaubte) Display Apps auf Public Displays anzufordern. Die Existenz von Display Apps, die durch Applikation Provider angeboten werden, muss natrlich auch noch von Display Ownern und Viewern auf praktikable Weise wahrgenommen werden knnen. Zu diesem Zweck wird das mit dem AppKonzept in enger Verbindung stehende App-Store Konzept im erweiterten Teil dieser Architektur zur Publikation von Display Apps integriert. Im Rahmen der Basis-Architektur soll dieser Teil jedoch zunchst auen vor gelassen werden. Multi-App und Multi-Viewer Unterst tzung Mehrere unterschiedliche Display Apps knnen potentiell zur gleichen Zeit ausgefhrt werden. Diese werden entweder zur dauerhaften parallelen Ausfhrung durch den Display Owner gestartet, oder von Viewern spontan angefragt. Viewer Anfragen durchlaufen dabei potentiell zwei Ebenen (Abbildung 7): Zunchst die angeforderte Display-App, und im Anschluss den Media Player des Display Nodes, falls dieser die Anfrage akzeptiert.
41
Display Node Media Player
Display-Level Aggregation
App Requests
Display Application 1
Viewer Requests
Display Application 2
App-Level Aggregation
Mobile App User 1
Mobile App User 2
Mobile App User 3
Mobile App User 4
Abbildung 7: Aggregationsstufen von Personalisierungs-Anfragen
So knnen bereits auf der Display-App Ebene, Anfragen von unterschiedlichen mobilen Viewern, die sich in der Nhe des gleichen Public Displays befinden, potentiell aggregiert oder einzeln weitergeleitet werden. Insgesamt hat eine Display-App in dieser Situation mehrere Mglichkeiten: 1. Aggregation: Falls die Display-App noch nicht auf dem Public Display ausgefhrt wird, so wird diese dort gestartet und gibt dort Inhalte wieder die an beide Viewer-Prferenzen angepasst sind. Whrend die Display App ausgefhrt wird, knnen dessen Inhalte kontinuierlich, z.B. ber eine Eventbasierte persistente Verbindung5 an inzwischen neue Personalisierungsanfragen angepasst werden. 2. Einzelne Anfragen: Abhngig von dem Zweck einer Display-App ist es mglich, dass diese fr die Personalisierung durch mehrere mobile Viewer auf dem gleichen Display nicht geeignet sind (z.B. Eine Single-Player Game). Hier kann die App zustzliche Anfragen fr das gleiche Public Display ggf. parken oder ganz ignorieren. 3. Parallele Anfragen: Weiterhin kein eine Display App auf die Steuerung von Anfragen fr das gleiche Display auch ganz verzichten, und diese einfach an den Media Player des Display Nodes weiterleiten. Ein Media Player eines Diplay Nodes kann, abhngig von dessen Fhigkeit, seine Bildschirmflche ggf. dynamisch aufteilen und mehrere (gleiche oder unterschiedliche) Apps gleichzeitig anzeigen oder jeweils nur eine App zur gleichen Zeit. Auch hier existieren mehrere Mglichkeiten zur Behandlung multipler Anfragen:
5
Vorausgesetz, dass Display Apps Remote Hosts haben knnen, mit denen sie und mobile Viewer kommunizieren. 42
1. Anzeige einer App gleichzeitig: Hier whlt der Media Player nach der FirstCome-First-Serve Strategie die erste App-Anfrage aus und weit dieser einen einstellbaren Zeitraum (time-slot) zu. Entweder werden nun Anfragen, die whrend der Ausfhrung der aktiven App eingehen, ignoriert oder in einer Warteschlange geparkt um nach Beendigung der ersten App sequentiell abgearbeitet zu werden (zur Erhaltung der Praktikabilitt solle die maximale Lnge der Queue nicht zu gro sein). Dabei bleibt zu beachten, dass Anfragen an Display Apps, welche gerade ausgefhrt werden, und die Aggregation untersttzen, ggf. gar nicht warten mssen und direkten Einfluss auf Inhalte haben knnten (abhngig von der Steuerung durch die Display App). 2. Anzeige mehrerer Apps gleichzeitig: Das Anzeigen mehrerer Apps gleichzeitig erfordert die dynamische Aufteilung der Bildschirmflche. Ein mglicher Ansatz ist es diese in gleich groe Rechtecke aufzuteilen. Dabei mssen Display Apps in diesem Fall auf die dynamische Anpassung der ihnen zur Verfgung stehenden Displayflche vorbereitet sein. Dieser Ansatz ist u.a. von der Gre und Auflsung des Public Displays und der typischen Sichtweite zu seinem Publikum abhngig und natrlich auf eine maximale Zahl von Anzeigebereichen beschrnkt. Abbildung 8 demonstriert eine mgliche Aufteilung eines Displays im Landscape- und Portrait-Modus in bis zu vier Bereiche.
Abbildung 8: Mgliche Partitionierung von Display-Flchen bis zu 4 Anzeigebereichen
Unter Zuhilfenahme zustzlicher, von Display Apps zur Verfgung gestellter Informationen ber speziell untersttze Anzeigebereiche (z.B. Fuzeilen fr Ticker-Apps), knnte ein Media Player eine deutlich intelligentere Strategie zur Aufteilung der verfgbaren Anzeigeflche zur Darstellung multipler Anwendungen implementieren. Diese Informationen knnten dabei leicht als Teil der Display-App Metadaten publiziert werden. Sicherstellung von Prsenz Die Tacita Architektur macht durch die ffentliche Publikation von Display- und App-Metadaten auch den einfachen Zugriff auf die Schnittstellen von Display Apps und Media Player mglich. Diese sind in erster Linie fr die Kommunikation der architekturellen Komponenten unter sich notwendig, knnen jedoch aufgrund der offenen, verteilten Art dieser Architektur potentiell auch von anderen Host aufgerufen werden. Somit knnen diese Schnittstellen auch Opfer von Missbrauch werden.
Dieses Problem haben sie jedoch mit jedem ber das Internet aufrufbaren Rechner, der Dienste zur Verfgung stellt, gemeinsam. Daher knnen z.B. auch die blichen Methoden zur Einschrnkung von Missbrauch genutzt werden. (z.B. durch den Einsatz von IP-Level Mechanismen wie simplen Flood-Blockern auf Basis von iptables, die nur eine bestimmte Menge von Anfragen pro Zeitraum von der gleichen Quelle durchlassen). Weiterhin knnen Media Player anhand von App-Metadaten der vom Display Owner erlaubten Apps leicht berprfen, ob anfragende Apps tatschlich von der gleichen Quelle stammen, wie in den Metadaten angegeben (analog zur Same-Origin Policy in Browsern). Zustzlich knnen Media Player ihre eigenen Kontingent basierten Regeln zur Eingrenzung von App-Aufrufen enthalten. Gleiches gilt auch fr Anfragen die bei Display-Apps eingehen. Weiter Missbraucheinschrnkend knnen z.B. beschrnkte Zugnge wirken, die nur mit Hilfe entsprechender Zugangsdaten Zugriff auf Funktionalitt erlauben. So knnte das Recht bestimmte Display-Apps und/oder Public Display aufrufen bzw. nutzen zu knnen zunchst auf dem Erwerb der Nutzungsrechte basieren. Wie dem auch sei, der Zweck der Tacita Architektur ist es mobilen Viewern implizite und explizite Interaktion mit den gewnschten Display Apps auf rumlich naher Display Infrastruktur zu ermglichen. Die Sicherstellung, dass ein Nutzer tatschlich in der Nhe ist, kann fr die Nutzung mancher Display-Apps bzw. der DisplayInfrastruktur Voraussetzung sein. Zu diesem Zweck wird im Folgenden das PresenceToken Konzept vorgestellt. Presence Token sind regelmig durch Media-Player auf Public Displays generierte Codes, die mit Hilfe von bertragungstechniken mit kurzer rumlicher Reichweite als Broadcasts publiziert werden. Mgliche Technologien sind z.B. QR-Codes, Infrarot, NFC, Bluetooth und andere Funkbertragungstechnologien. Presence Token knnen dann durch die Mobilgerte von Viewern empfangen und zusammen mit der Anfrage zur Personalisierung an die gewnschte Display App gesendet werden. Diese werden dann durch die Display App zur Autorisierung einer Anfrage beim Public Display verwendet, dass dieses Presence Token generiert hat. Im Implementierungsteil dieser Arbeit wird demonstriert wie Presence Tokens ber Bluetooth Device Names oder sogar Hardware-unabhngig mit Hilfe von QR-Codes an Viewer bertragen werden knnen. Feedback Das bereitstellen von (informativen) Benutzer-Feedback ist eine der acht goldenen Regeln [44] der Prinzipien guten User Interface Designs. Insbesondere in Zusammenhang mit expliziten Personalisierungs-Anfragen an Public Display bedeutet dies, dass Grnde fr eine nicht erfolgreiche oder Verzgerte Interaktion mit einem Public Display dem Nutzer mitgeteilt werden sollten (erfolgreiche Anfrage haben trivialer Weise sichtbare Auswirkungen). Dies knnte sowohl auf dem Mobilgert des Viewers, als auch auf den Displays selbst mitgeteilt oder angedeutet werden (z.B. durch die kurze Einblendung, kleiner, unaufdringlicher Symbole).
Unabhngig von der Anzeige dieser Informationen, sollten die beteiligten Schnittstellen der kommunizierenden Komponenten dieser Architektur auf einfache und transparente Weise Status- und Fehlernachrichten austauschen knnen. Konkret heit dies, dass das Ergebnis eines Personalisierungs-Aufrufs eines Viewers erst ber die aufgerufene Display App wieder zurck zum Mobilgerte des Viewers gelangen muss. Eine konkrete Implementierung kann dazu auf der gesamten Strecke entweder synchrone Kommunikation nutzen, oder asynchrone Kommunikation in Verbindung mit Message-Polling zur Abfrage einer Display-App, ob die Antwort des Public Displays bereits eingetroffen ist. Schnitts tellen Eine Media Player sollte zur Untersttzung von mobiler, Viewer-basierter Personalisierung mindestens folgende Schnittstellenaufrufe anbieten:
API: Media Player Public: handleAppRequest(app_id,callback_parameters[,metadata_url]): result getMetadata(): display_metadata requestApp(display_preferences,callback_parameters): app
Tabelle 3: Abstrakte API Media Player
Private:
ber die ffentliche Schnittstelle handleAppRequest fragt eine Display App ihre Ausfhrung an. Mit Hilfe des app_id Parameters wird verglichen, ob diese vom Display Owner erlaubt ist. Falls das Display den Aufruf beliebiger Apps erlaubt, und die gewnschte App ihm noch nicht bekannt ist, kann es ber den optionalen Parameter metadata_url zunchst die Metadaten anfordern, welche u.a. die App-URL enthalten, die zum Abruf der App bentigt wird. ber den callback_paramter knnen zustzliche Parameter fr den eigentlichen Aufruf der App durch den Media Player bergeben werden (z.B. zur Erhaltung von Sessions). Weiterhin sollte eine Media Player Komponente eine ffentliche Schnittstelle zum Abruf der Display-Metadaten anbieten. ber die interne Funktion requestApp kann nun die Display App durch den Media Player angefordert und ausgefhrt werden. ber den display_preferences Parameter werden die Display-App Prferenzen des Display Owners bermittelt (z.B. Topic: Dsseldorf, falls er auf seinem Public Display eine News-App verwendet und er primr Nachrichten ber Dsseldorf anzeigen lassen will). Metadaten Die Metadaten eines Public Displays sollten mindestens folgenden Informationen enthalten:
45
Metadaten: Public Display Display-ID Typ-Untersttzung:[Executable,VM,Web,] Anbieter (Name, Adresse, Telefon, Email) Eigenschaften Geoposition (Lat,Lng,Alt) Sichtbereiche (Radius, Von-Winkel, Bis-Winkel[,]) Bildschirm-Auflsung Orientierung Direkte-Interaktion([J|N]) Bluetooth-MAC-Adresse Metadata-URL Anfrage-URL Erlaubte-Apps: [None|All|List] App-1 (App1-Metadaten, Display-Owner-Prferenzen) App-2 (App2-Metadaten, Display-Owner-Prferenzen)
Tabelle 4: Abstrakte Metadaten Public Display
Eine Display-ID dient der eindeutigen Identifizierung eines Displays. Als Eigenschaften knnen eine Vielzahl ntzlicher Informationen bertragen werden, die zur Kontextualisierung der aufgerufenen Display-App sowie zum detektieren der rumlichen Nhe eines Viewers zum Public Display verwendet werden knnen. Eine zwingende Angabe im Rahmen der Tacita Architektur ist die Angabe der Geoposition des Public Displays. Mit zustzlichen Angaben wie Sichtbereichen und der BluetoothMAC-Adresse kann das im Abschnitt Mobile App erluterte Verfahren zur Bestimmung der Prsenz von Public Displays in der Nhe von Viewern noch weiter verfeinert werden. ber Metadata-Url wird auf die Quelle dieser Metadaten verwiesen und die Anfrage-URL referenziert die Schnittstelle zur Anfrage durch Display-Apps. Schlielich definiert Erlaubte-Apps die Display Owner Policy und gibt ggf. eine Liste von erlaubten Display Apps an, welche primr durch die mobile App genutzt wird (jedoch indirekt ber die Publikation durch das Service Directory, da keinerlei direkte Kommunikation zwischen der nicht vertrauenswrdigen Public Display Infrastruktur und der mobilen App erfolgen soll). 5.2.5 Service Directory Die Service Directory Komponente dient fr Public Displays als Verzeichnis zur Publikation dessen Fhigkeiten (auf Basis von Display-Metadaten) und fr die mobile App zum Abruf dieser Daten fr ganze Regionen. Regelmige automatische Anfragen an ein Service Directory ermglichen inkrementelle Updates einer bereits gecachten Region oder, falls der Nutzer eine neue Region betritt, den Download der Daten fr diese.
46
Auf Basis dieser Daten und insbesondere der Geoposition von Displays und deren verfgbaren Display Apps, kann die mobile App, ausgehende von der eigenen Position, nahe Displays detektieren und gezielte Anfragen an verfgbare Display Apps senden, die gleichzeitig auch mit den Prferenzen des Viewers bereinstimmen. Service Directories sind eine notwendige strukturelle Komponente. Ihr zentralisierter Ansatz macht die Publikation der Display-Metadaten sehr einfach. Die Tacita Architektur untersttzt dabei problemlos mehrere Service Directories und skaliert dadurch auch bei einer groen Zahl von Nutzern. Die Referenz zu mindestens einem Service Directory muss dabei Display Ownern sowie Viewern bekannt sein. Falls ein Display Owner seine Displays in genau einem Verzeichnis registriert, so muss auch genau dieses der mobilen App des Viewers bekannt sein. Eine mobile App kann eine beliebige Zahl von Service Directories untersttzen. Ein Verzeichnis kann dabei einfach durch eine URL referenziert werden. Nach dem der Installation der mobile Public Display App auf dem Mobilgert des Viewers kann diese z.B. bereits eine oder mehrere URLs zu Service Directories voreingestellt enthalten, oder diese aus einer Quelle herunterladen die z.B. Links zu diversen Service Directories anbietet. Unabhngig davon kann ein User jederzeit manuell Service Directory Link hinzufgen. Auch der Display Owner, muss sich entscheiden seine Displays in einem oder mehreren Service Directories zu publizieren. Nach dem Setup eines Media Players und dem hinzufgen der URL eines Service Directories, kann das Registrieren, Aktualisieren und Abmelden von Public Displays vllig automatisiert ber die ffentlichen Schnittstellen des Service Directories ablaufen. Die erwartete nderungshufigkeit ist dabei nicht besonders hoch. Ein Display-Owener wird die Metadaten seiner Displays eher wchentlich oder noch seltener als z.B. jede Minute ndern. Der Abruf von Display-Metadaten durch die mobile App erzeugt dagegen einen greren Datenverkehr, welche jedoch durch Komprimierung und inkrementelle Updates stark minimiert werden kann. Automatische Bekanntmachung verwendeter Service Directories Ein Public Display ermglicht zudem noch eine automatisierte Art, um dessen verwendetes Service Directory an die mobile App von Viewern zu bertragen. Mit Hilfe von kurzweitigen bertragungs-Technologien wie Bluetooth, kann die im Media Player verwendete Service Directory URL als Broadcast per Bluetooth Device Name problemlos allen Viewern in der Nhe eines Displays bekannt gemacht werden. Auf Basis dieses Verfahrens ist ein vllig konfigurationsfreier Betrieb der mobilen App mglich, welcher immer automatisch die bentigten Display-Metadaten von den richtigen Service Directories herunterldt. Service Directory Privacy Um eine potentielle Mglichkeit zur Erstellung von anonymen Viewer Bewegungsprofile durch die Betreiber von Service Directories zu vermeiden (z.B. bei mehreren Anfragen durch dieselbe IP-Adresse), knnen verschiedene Methoden zur ErzeuEntwicklung einer Privatsphre erhaltenden Architektur fr Mobile Interaktion mit Pervasive Public Display Netzwerken 47
gung von Unschrfe genutzt werden. So kann die mobile App z.B. alle Daten eines Service Directories herunterladen und damit absolute Positions-Unschrfe erreichen (nicht realistisch fr groen Mengen von Public Displays) bis hin zum Runterladen lediglich aller Displays in direkter Umgebung (geringe Datengre) jedoch dem absoluten Verlust der Unschrfe. Ein mglicher Ansatz ist es dem mobilen Nutzer selbst die Wahl zu geben, welches Level an Privacy er fr akzeptabel hlt. So knnen ber die Schnittstelle von Service Directories z.B. Daten fr eine Stadt, ein Bundesland oder gar ein Land heruntergeladen werden, ohne eine genaue Position zu spezifizieren. Oft kann dieser grad an Lokalisierung alleine schon durch die aufrufende IP-Adresse ermittelt werden. Desweiteren ist die Nutzung von Service Directories anonym so, dass keine6 Rckschlsse auf die wahre Identitt eines einzelnen Viewers geschlossen werden kann. Auerdem lassen sich zwei unterschiedliche Anfragen desselben Mobilgertes zu zwei unterschiedlichen Zeitpunkten (und daher ggf. mit unterschiedlichen IP-Adressen) kaum in Verbindung bringen, solange die mobile App keine weiteren eindeutigen Identifikatoren sendet. Potentiell ist es jedoch generell mglich auch aus groben Trajektorien, auf Personengruppen sowie durch Kombination mit anderen Daten ggf. auch auf konkrete Person zu schlieen. Dies beinhaltet jedoch bereits enormen Aufwand. Wie auch immer, eine weitere Art Unschrfe herzustellen, ohne groe Datenmengen herunterzuladen, ist die Kombination einer gezielten Anfrage mit mehreren zuflligen Anfragen. Dieser Ansatz hat jedoch bei Anwendungen ber einen lngeren Zeitraum schwchen, da die Verteilung der aufgerufenen Geopositionen oft die intuitive Unterscheidung von Echten und zuflligen Bewegungen erlaubt. Schnitts tellen Folgende Schnittstellen solle ein Service Directory mindestens anbieten:
API: Service Directory Public: registerDisplay(display_metadata, password): result unregisterDisplay(display_id, password): result updateDisplay(display_metadata, password): result query(region_name[,last_timestamp]): [display_metadata] query(lat,lon,radius[,last_timestamp]) : [display_metadata]
Tabelle 5: Abstrakte API Service Directory
Die ersten drei Aufrufe dienen dem Media Player von Public Displays zum Registrieren, Abmelden und Aktualisieren von Display-Metadaten. Dabei wird beim registrieren ein im Media Player gesetztes bzw. automatisch generiertes Passwort bergeben, dass bei Abmelden und Aktualisieren diese Eintrags abgefragt wird. Un6
Keine auer den blichen, die bei jeder Art Kommunikation ber das Internet entstehen 48
terschiedliche query Aufrufe, die fr die Verwendung durch die mobile App gedacht sind, ermglichen den Download von Display-Metadaten fr angegebene Bereiche. Dies kann entweder ber die Angabe der Region (z.B. Dsseldorf) erfolgen oder spezifischer ber eine kreisrunden Bereich mit angegebenem Zentrum und Radius. Mit Hilfe eines last_timestamp knnen zudem optional inkrementelle Updates angefordert werden. Die unterschiedlichen Anfragemglichkeiten ermglichen dabei, wie zuvor erwhnt, unterschiedliche Stufen von Location-Privacy. 5.2.6 Mobile App Die mobile App fr den Einsatz auf dem Mobilgerte des Viewers ist eine der Schlsselkomponenten der Tacita-Architektur. Durch das Definieren von Prferenzen, dem Wissen ber die eigene Position und dem Zugriff auf Display-Metadaten mit Hilfe von Service Directories, kann die mobile App fortlaufend und vllig automatisch Display Apps auf rumlich nahen Display Apps detektieren und anfordern. Dies ermglicht sowohl implizite Interaktion mit Public Display, bei dem das Mobilgert des Viewers die meiste Zeit in seiner Tasche liegt, als auch explizite Interaktion zum bewussten und gezielten Aufruf von Display Apps und ggf. der Echtzeit Interaktion mit diesen. Display Sensing Viewer sollen mit Hilfe der mobilen App in der Lage sein, nahe Displays zu detektieren, um daraufhin mit ihnen interagieren zu knnen. Die Wahrnehmung naher Displays kann dabei entweder auf Basis absoluter Position oder der Detektierung von Identifiern in direkter Nhe erfolgen. Absolute Position: Die meisten modernen Mobiltelefone knnen ihre eigene Position bis auf wenige Meter genau bestimmen. Die Genauigkeit und Aktualisierungsrate hngt dabei von der zu Grunde liegenden Technologie ab. GPS (Global Positioning System) bietet z.B. einer Genauigkeit von wenigen Metern und eine maximalen Updaterate von einer Sekunde. Innerhalb von Gebuden ist GPS allerdings nicht einsetzbar. Auf WiFi- bzw. Bluetooth-Fingerprinting basierende Lokalisierung kann potentiell eine fast genau so hohe Genauigkeit erreichen, ist jedoch abhngig von einer hohen Abdeckung durch Hotspots und daher nicht Flchendecken verfgbar bzw. in Regionen mit schwacher Abdeckung sehr lckenhaft und unzuverlssig. Lokalisierung auf Basis von Mobilfunk Cell-IDs dagegen, steht Flchendecken zur Verfgung, eignet sich jedoch aufgrund seiner geringen Przision nicht direkt zur Detektierung naher Objekte. Mit Hilfe einer bzw. der Kombination dieser Technologien, kann somit fortlaufend eine (relativ) genaue Position des Mobiltelefons des Viewer bestimmt werden. Da die Display-Metadaten eines Public Displays dessen Position enthalten, kann eine mobile App fortlaufend ihre lokale Datenbank von Display-Metadaten auf nahe Dis-
49
plays abfragen und diese somit detektieren. Dieser Ansatz ist dabei im Prinzip unabhngig von der tatschlichen Prsenz, da die lokale Datenbank beliebige Positionsangaben annimmt und als Ergebnis nahe Public Displays zurckliefert. Diese Art der Detektierung basiert jedoch auf der Berechnung, ob ein Viewer sich innerhalb eines Radius um das Display herum befindet. Dies entspricht jedoch nicht der Realitt von Public Displays und dessen Betrachtung durch Viewer. Ein typischer digitaler Bildschirm hat nmlich immer eine Ausrichtung und eine potentielle Reichweite (u.a. beschrnkt durch Anbringung, Schirmgre und Umgebung) und daher ein bestimmtes Sichtfeld (Abbildung 9). Verwendet man nun eine Detektierung, die rein auf der Distanz zum Public Display besteht, so werden in mindestens 50 Prozent aller Flle (Sichtfeld von <180) Anfragen an Displays geschickt, obwohl sich der Viewer gar nicht in dessen Sichtfeld befindet (z.B. weil er sich hinter dem Display, einer Wand, oder wie in Abbildung 9 auf dem Gehweg aufhlt). Ein Verbessertes Model muss deshalb auf der Abbildung tatschlicher Sichtfelder von Public Displays basieren. Im Rahmen dieser Arbeit wird dazu ein vereinfachter Ansatz vorgeschlagen, der auf multiplen Kreissektoren zur Abbildung von Sichtfeldern basiert, die durch die mobile App als Trigger-Zonen zur Auslsung von Display-App Anfragen genutzt werden knnen. Diese Sichtfelder knnen dabei ebenso ber die Metadaten einer Public Displays publiziert werden, und bieten Display Ownern einen hheren Grad an Kontrolle zur Auslsung von ViewerInteraktionen mit ihrer Display Infrastruktur. Ein komplexerer Ansatz knnte sogar auf Basis beliebiger Polygonflchen, ein noch detaillierteres Ma an Kontrolle bieten.
Abbildung 9: Kreissektoren zur Modellierung von Sichtfeldern bzw. Trigger-Zonen
Detektierung von Identifiern: Zur Identifikation eines oder mehrerer Displays in der Nhe eines Viewers knnen auch Identifier dienen. Diese knnen u.a. mit Hilfe von Bluetooth, WiFi, NFC und QR-Codes detektiert werden. So haben typische Bluetooth und WiFi-Hotspots eine relativ begrenzte Reichweite von wenigen Metern, in
welcher sie u.a. ber ihre eindeutige MAC-Adresse wahrgenommen und identifiziert werden knnen. Durch die radiale Ausbreitung elektromagnetische Signale, kann dabei nicht die gleiche Przision bzw. Kontrolle zur Auslsung von Personalisierungs-Anfragen durch Viewer erreicht werden, wie dies mit dem Trigger-Zonen Ansatz mglich ist. QR-Codes (Quick Response Codes), knnen dagegen auf Public Displays direkt angezeigt werden und haben eine auf Sichtweite beschrnkte Reichweite. Beim einscannen ber die Kamera des Viewers knnen sie beliebige Informationen enthalten und somit auch Identifier. NFC (Near Field Communication) kann ebenso beliebige Daten transportieren, ist jedoch meistens auf Reichweiten von unter einem Meter beschrnkt (oft nur wenige Zentimeter). Diese Identifier knnen nun als Teil der Display-Metadaten durch Display Owner publiziert, durch die mobile App heruntergeladen und durch die Sensoren des Mobiltelefons detektiert und mit den Display-Metadaten verglichen werden. Dieser Ansatz ist im Gegensatz zum vorhergehenden tatschlich von der realen Prsenz eines Viewers abhngig, um ein nahes Public Display identifizieren zu knnen und kann daher auch im Zusammenhang mit der Sicherstellung von Prsenz (Abschnitt 5.2.4) auf Basis von Presence Token verwendet werden. Definition von Prferenzen Im Rahmen der Tacita Architektur wird Personalisierung von Public Display Inhalten durch die Anfrage gewnschter Display Apps erreicht. Display Apps bieten wiederum verschiedene Parameter an, mit dessen Hilfe Viewer die Inhalte von Display Apps anpassen knnen. Somit werden die Prferenzen einen Viewers durch die Menge ausgewhlter Display Apps und dessen individuelle Konfiguration mit Hilfe von Parametern definiert. Zunchst muss ein Viewer jedoch erst von der Existenz potentiell verfgbarer Apps wissen. Eine Liste aller auf Public Displays der Region verfgbaren Apps kann dabei leicht aus der lokalen Display-Metdaten Datenbank extrahiert und dem Viewer bersichtlich prsentiert werden (z.B. sortiert nach Distanz). Mit Hilfe der zu jeder Display App verfgbaren Meta-Daten, kann sich ein Nutzer ber Zweck, Beschreibung, Aussehen und Nutzungsbedingungen einer App informieren, bevor er beschliet diese zu nutzen. Weiterhin erhlt ein Viewer eine bersicht ber ggf. verfgbare Personalisierungs-Parameter der App und kann diese setzen und dauerhaft lokal abspeichern. Parameter knnen dabei von allgemeinen Angaben wie gewnschte Sprache bis hin zu potentiell kritischen Angaben wie Benutzername und Password reichen. Mchte ein Viewer auf seiner mobilen App Zugriff auf Display Apps erhalten, die von Application Providern angeboten werden, jedoch in seiner Region auf keinem Display verfgbar und deshalb in der Liste nicht sichtbar sind, dann muss ein anderer Weg gefunden werden, um die Metadaten der gewnschten App zu erhalten. Eine solche Situation tritt z.B. immer dann auf wenn ein Viewer eine Reise in ein anderes Land plant und im Voraus bestimmte Apps aktivieren mchte, die ggf. in jener
Region verfgbar sind jedoch nicht in der Region in der er sich gerade befindet. Dazu kann ein Viewer z.B. mit der mobilen App gezielt Metadaten fr die gewnschte Region herunterladen. Dies ist jedoch mit Aufwand verbunden und setzt voraus, dass man seine zuknftigen Aufenthaltsorte bereits vorausplanen kann. Eine andere Mglichkeit ist es, global verfgbare Display-Apps unabhngig von ihrer lokalen Verfgbarkeit auf Displays suchen und zur Verwendung auswhlen zu knnen. Diese werden dann (bei impliziter Nutzung) automatisch dort aufgerufen, wo sie verfgbar sind. Als Mittel zur Bereitstellung dieser Display-App Metadaten werden im Abschnitt 5.3.1 Display App Stores vorgestellt. Implizite und Explizite I nteraktion Mit Hilfe der zuvor erklrten Methoden zur Display-Detektierung sowie mit Hilfe der lokalen Display-App Metadaten kann nun mit nahen Displays explizit und implizit interagiert werden. Explizite Interaktion: Hier mchte ein Viewer bewusst und mglichst sofort mit Hilfe einer Display App die Anzeige eines nahen Public Displays beeinflussen. Dazu erhlt er ber die mobile App eine Liste aller in seiner direkten Umgebung erlaubten Display Apps, whlt eine dieser Apps aus, gibt ggf. bentige Parameter an und fordert schlielich dessen sofortigen Aufruf an. Abhngig von den aktivierten Technologien auf seinem Mobiltelefon (GPS, WiFi, Bluetooth, etc.) werden Displays in der Nhe unterschiedlich genau detektiert. Befindet sich ein Nutzer z.B. gerade in den Trigger-Zonen mehrerer Displays (bzw. scannt mehrere Identifier), so wird der Viewer vorher gefragt, an welches der Displays in der Nhe seine Anfrage gehen soll. Zur Untersttzung bei der Auswahl, knnen die verfgbaren Displays dem Nutzer ggf. in einer Kartenansicht prsentiert werden, auf welcher er sich besser orientieren kann. Falls jedoch genau ein Display detektiert wird, kann die Anfrage ber das Mobiltelefon des Nutzers sofort abgeschickt werden. Implizite Interaktion: Bei der impliziten Interaktion mit Public Displays whlt ein Nutzer bereits im Voraus eine oder mehrere Display Apps aus, die er verwenden mchte, setzt ggf. bentigte Parameter und aktiviert diese. Whrend sich der Viewer nun mit dem Mobiltelefon in der Tasche durch seine Umgebung bewegt, werden automatisch Public Displays in der Nhe detektiert, auf die Verfgbarkeit der gewnschten Apps berprft und ggf. Anfragen zur Personalisierung versendet. Abbildung 10 bildet dabei in einem Flussdiagramm die Prozesse ab, die bei diesem Vorgang in der mobilen App stattfinden. Da Personen sich typischerweise regelmig in verschiedenen Situationen befinden, in denen sie ggf. unterschiedliche Bedrfnisse bezglich der gewnschten Inhalte auf Public Displays haben (z.B. Arbeitsumfeld vs. Shopping-Mall), knnte die mobile App mit Hilfe von Profilen unterschiedliche Gruppen von Display Apps untersttzen, die dann einfach bei Bedarf oder auf Basis von Regeln aktiviert werden knnten. Mgliche Regeln knnten z.B. aus KomEntwicklung einer Privatsphre erhaltenden Architektur fr Mobile Interaktion mit Pervasive Public Display Netzwerken 52
binationen aus Zeit und Raum bestehen (z.B. Shopping-Profil nur Fr-Sa 8-17 Uhr im Bereich der Innenstadt aktivieren).
Absolute Position (GPS, WLAN, Cell-ID)
Identifiers (Bluetooth, NFC, QR-Code)
Proximity and Identifier Sensing [Display Detected] DisplayMetadata
DisplayMetadata DB
Set Preferences
Display App Store
Display App Matching [Display App Available] Display App Parameters
Viewer Preferences
Send Display App Request
Abbildung 10: Flussdiagramm der Prozesse auf der mobilen App
Direkte I nteraktion mit Display Apps Wird eine Display App auf einem Public Display gestartet, die direkte mobile Interaktion untersttzt, so kann die mobile App des Viewers genutzt werden, um ggf. interaktive Inhalte auf dem Display potentiell in Echtzeit zu steuern. Direkte Interaktion per mobile App kann insbesondere ntzlich zur Nutzung interaktiver fr Touch-Screens konzipierter Public Display Anwendungen sein, die jedoch auf Public Displays aufgerufen werden, die gar keine Steuerung per Berhrung untersttzen oder auerhalb der Bedienreichweite liegen (z.B. wie im dritten Pong-Szenario aus dem letzten Kapitel). Zur Realisierung dieser Fernsteuerung wird eine persistente Verbindung zwischen der mobilen App und dem Host-Rechner der Display App, sowie der Display App im Media Player und dem gleichen Host-Rechner aufgebaut. Die tatschlichen Reaktionszeiten zwischen einer Aktion auf der mobilen App und den visuellen Auswirkungen auf dem Public Display hngen dabei mageblich von der Latenz sowie der Auslastung der beiden Netzwerkverbindungen ab. Die magebende Latenz wird jedoch typischerweise durch die Mobilfunkstrecke der Gesamtverbindung geprgt. Tabelle 6 gibt dazu einen berblick typischer Datenpaket Roundtrip-Zeiten heutiger Mobilfunk-Technologien.
LTE UMTS mit HSDPA UMTS 30 100ms 100 200 ms 200 300 ms
53
EDGE (EGPRS) GPRS
400 500 ms 600 ms und mehr
Tabelle 6: Roundtrip-Zeiten von Mobilfunk-Technologien7
Die Angaben in Tabelle 6 sind dabei ggf. zu halbieren, da abhngig vom bertragungsprotokoll nur die Latenz in eine Richtung in die Gesamtreaktionszeit einfliet. Zustzlich zur Latenz der Mobilfunkverbindung zwischen der Mobilen App und einem Mobilfunk Gateway kommt noch die Dauer zum Erreichen des Display App Hosts, dessen bentigte Processing-Zeit, die Latenz zwischen Display App Host und Diplay Node sowie schlielich die bentigte Dauer zur Anzeige der Reaktion dazu (Abbildung 11). Mglichweise ist auch ein Display Node per Mobilfunkanbindung an das Internet angeschlossen, was die Gesamtreaktionszeit zustzlich erheblich verschlechtert.
Mobilfunk
Internet
Internet / Mobilfunk
Mobile App
Mobilfunk Gateway
Display App Host
Display Node mit laufender App
Abbildung 11: Verbindungsstationen einer persistenten Verbindung zwischen mobiler und DisplayApp
Abhngig vom der Art eine interaktiven Public Display App, ist mglicherweise eine schnelle Reaktionszeit von weniger als 200ms erforderlich um eine positive Benutzererfahrung herzustellen. Fr andere Display Apps ist mglicherweise sogar eine Reaktionszeit von 200 2000ms noch akzeptabel. Da durch diese persistente Verbindung nun beliebige Daten zwischen Mobiltelefon und Display App bermittelt werden knnen, ist es auch mglich verschiedenste Interaktionsarten zu untersttzen. So knnten z.B. Gesten mit dem Mobiltelefon oder Wischbewegungen auf dessen Touchscreen in Daten bzw. Befehle umgewandelt und fortlaufend an die Display App bertragen werden. Im Folgenden werden zwei Mglichkeiten vorgeschlagen, um einfache Benutzerschnittstellen zur Interaktion mit Display Apps anzubieten. Universelle Benutzerschnittstelle: Um eine einheitliche, Display App bergreifende Benutzerschnittstelle ber die mobile App zu ermglichen, wrden alle Display Apps ber eine gleich aussehende Oberflche aus der mobilen App bedient. Diese
Quelle: http://www.elektronik-kompendium.de/sites/kom/0910251.htm 54
knnte in einer einfachen Version z.B. Hoch, Runter, Rechts, Links Onscreen-Tasten als Basis-Steuerung sowie eine virtuelle Eingabetastatur zur Texteingabe verwenden. Diese simplen Steuerbefehle knnten z.B. schon zum Browsen durch Informationen auf Public Displays dienen, die aufgrund Ihrer Menge nicht gleichzeitig dargestellt werden knnen. Zustzlich knnten Gesten und Wischbewegungen interpretiert und als alternative Basissteuerung verwendet werden (z.B. Links, Rechts, Hoch, Runter). Ein visuelles Feedback auf der mobilen App wrde dabei nicht erfolgen, stattdessen wre die Wirkung auf dem Public Display zu sehen. Individuelle Benutzerschnittstelle: Alternativ knnten Display Apps selbst eine optionale separate Oberflche zum Aufruf auf dem Mobiltelefon des Viewers bereitstellen. Diese knnte nicht nur als persnliches Display zur Anzeige ggf. privater Daten genutzt werden, sondern insbesondere zur Bereitstellung individueller Bedienoberflchen zur Interaktion mit der dazugehrigen Display App. Die Verfgbarkeit einer solchen Oberflche knnte wie blich ber die Display-App Metadaten bekannt gemacht werden. Abbildung 12 zeigt eine mgliche Universal-Kontroll-Oberflche (links) sowie eine mgliche individuelle gestaltete mobile Bedienoberflche (rechts), die in diesem Fall zur Steuerung einer Public Display Tetris App gedacht ist.
Abbildung 12: Beispiel-Oberflchen zur mobilen Interaktion mit Public Displays Universeller Ansatz (links), Individuelles Kontroll-UI (rechts)
Eine Kombination beider Anstze knnte Public Displays Apps ohne individuelle mobile Kontroll-UI immer noch ber den Universal-Controller bedienbar machen und gleichzeitig die Freiheit lassen, diesen bei Bedarf zur Verfgung zu stellen. Wie dem auch sein, Display Apps knnen auch ganz auf diese Art der ferngesteuerten Bedienung verzichten und z.B. nur auf Basis von Display-App Parametern personalisiert werden. Dies hngt ganz vom interaktiven Charakter der Display App ab.
55
Feedback ber die mobile App ausgelste Anfragen zum Aufruf von Display Apps knnen potentiell jederzeit ohne sichtbaren Effekt auf einem nahen Public Display bleiben. Grnde dafr knnen Verbindungsprobleme, fehlende oder fehlerhafte Display App Parameter oder auch Ablehnung durch Display App oder Public Display sein. Ein Viewer sollte in diesen Fllen informatives Feedback erhalten. Dies sollte in allen Fllen in der mobilen App ersichtlich sein, kann jedoch auch auf einem Public Display angedeutet werden. Zudem sollte ein Viewer speziell bei Nutzung der impliziten Interaktion bei Bedarf mit Hilfe einer Anfrage-History die zuletzt angefragten Apps und Public Displays einsehen knnen. Zudem knnte ein Nutzer der impliziten Interaktion wollen, dass er dezent ber das automatische Versenden von Display App Anfragen an nahe Public Displays informiert wird (z.B. ber kurzes Vibrieren).
5.3 Erweiterte Architektur

Display Apps werden in der Tacita Architektur sowohl durch Dislplay Owner als auch durch Viewer verwendet, um individuelle Funktionalitt auf die Anzeigeflchen zu bringen. Dazu whlen Display Owner Apps aus, die sie dauerhaft auf ihren Displays ausfhren wollen, sowie Apps, die optional durch Viewer aufgerufen und angezeigt werden knnen. Diese Policies werden zusammen mit den Metadaten eines Displays publiziert und gelangt ber Service Directories auf die Mobilgerte von Viewern. Viewer erhalten dadurch einen berblick ber die in ihrer Umgebung verfgbaren Display Apps. Ein bisher wenig behandelter Aspekt dieser Architektur ist jedoch das Finden und Integrieren von Display Apps, die durch eine Vielzahl verschiedener, potentiell unbekannter Application Provider angeboten werden knnen. Technisch gesehen, muss ein Display Owner lediglich die Metadaten einer Display-App ber seinen Media Player importieren und Regeln zu dessen Nutzung aufstellen. Zuvor muss er jedoch erst von der Existenz dieser Display App wissen sowie die Quelle kennen, an welcher die App bzw. dessen Metadaten verfgbar sind. Als eine Erweiterung der bisherigen Architektur werden deshalb Display App Stores als zustzliche (optionale) Komponenten eingefhrt, die einen zentralisierten Ansatz zur Publikation von Display-Apps fr Applikation Provider und zum Konsum durch Display Owner und Viewer darstellen. 5.3.1 Display App Stores Wie Apple mit iTunes und Google mit Google Play zeigen, sind App Stores ein erfolgreiches Mittel zur Publikation und Distribution von Apps fr mobile Gerte. Ihr zentralisierter Ansatz erlaubt es Anwendungs-Anbietern ihre Apps schnell und einfach publik zu machen. Durch die Standard-mige Integration von Apple bzw.
Android Gerten mit ihren App Stores, haben Nutzer von Smartphones von Beginn an Zugriff auf ein riesiges Angebot von Apps. Gleichzeitig erhalten AnwendungsAnbieter den potentiellen Zugriffs auf eine riesige Nutzerschaft. Dasselbe Prinzip soll nun zur Publikation von Display Apps verwendet werden. Wie die Bezeichnung App Store schon ausdrckt, beinhalten App Stores nicht nur den funktionalen Aspekt der Publikation und Distribution von Apps, sondern dienen gleichzeitig als kommerzielle Plattform zum Erwerb von kostenpflichtigen Anwendungen. Dieser und viele weitere Aspekte, die von App Stores bernommen werden knnen, gehen jedoch ber den Umfang dieser Arbeit hinaus, und knnen u.a. in [45] und [46] vertieft werden. Im Fokus dieser Arbeit steht die Publikations-Funktion von App Stores sowie deren Integrationskonzept in die Tacita Architektur. Abbildung 13 gibt dazu einen berblick.
Assign Apps Display Owner Browse/Use/Buy Applications Get Application Meta-Data Get Analytics Data Link App Store
Display Node Media Player
Publish Capabilities
Service Directory
Display App Store
Request Display Foreground / Get Content
Near Display
Download Display Database Viewer
Register Application Build/Provide Application Provider
Display Application
Request Personalisation Mobile App Set Preferences
Browse/Use/Buy Applications
Abbildung 13: Basis-Architektur erweitert um Display App Stores
Application Provider Um eine Display App im App Store publizieren zu mssen, muss der Application Provider zunchst einmalig ein Benutzerkonto anlegen und sich dann per Benutzername und Password einloggen. Um nun Display Apps seinem Account hinzufgen zu knnen, kann dieser entweder auf bereits vorhandene Display-App Metadaten verweisen und diese importieren, oder er kann diese nun mit Hilfe von Formularen eingeben und erzeugen. Ein App Store kann zudem die Angabe weiterer Informationen verlangen, die typischerweise nicht ber die App-Metadaten publiziert werden. Sobald dieser Vorgang abgeschlossen ist, wird die neue App in der zentralen App Store Datenbank abgespeichert und kann potentiell bereits durch Display Owner und Viewer gefunden werden. Aktuelle App-Stores fr mobile Apps (iTunes, Google Play) bernehmen zudem das Hosting und die Distribution von mobilen Apps. Da die Tacita Architektur jedoch offen lsst, wie Display Apps tatschlich implementiert sind und diese ggf. gar nicht zu einem ausfhrbaren Paket kompiliert werden knnen (z.B. Web-Anwendungen),
soll diese Funktion zunchst auch nicht durch einen Display App Store bernommen werden. Stattdessen kann mit Hilfe der App-Metadaten die Art und Quelle bestimmt werden, von der die App ggf. heruntergeladen und/oder gestartet werden soll. Applikation Provider betreiben in diesem Modell daher eher ihre eigene Infrastruktur zum Herunterladen bzw. Aufrufen ihrer Display Apps. Display Owner Display Owner knnen nun den Display App Store nutzen um nach gewnschten Apps zu suchen und eigene Kollektionen anzulegen. Die ffentlich zugngliche Suche nach Display Apps kann dabei ber die blichen Methoden wie Stichworte, Kategorien, Ranking-Listen usw. geschehen. Zu jeder App knnen ihrer Meta-Daten, wie Name, Beschreibung, Screenshots bersichtlich betrachtet werden. Zustzlich knnte dieApp-Ansicht durch zustzliche Community-Funktionen, wie Bewertungen und Erfahrungsberichte ergnzt werden. Ein Display Owner hat nun entweder die Mglichkeit gewnschte Apps einzeln mit Hilfe von Hyper-Links zu deren Metadaten in die Media Player auf seinen Display Nodes zu importieren oder er erstellt einen eigenen Display-Owner Benutzer-Account fr den App-Store und legt dort Kollektionen von Apps an. Kollektionen knnen benannt und ggf. innerhalb des App Stores fr andere sichtbar gemacht werden. Sie knnen ebenfalls mit Hilfe eines (ffentlichen oder privaten) Links referenziert und somit leicht in Media Player importiert werden. Auf diese Weise kann ein Display Owner die Media Player auf seinen Public Displays leicht und dauerhaft mit seinem Benutzer-Account bzw. Kollektion von Apps im Display App Store verbinden. ffentliche Kollektionen im App Store knnten zudem ein Mittel sein, um langfristig Zusammenstellungen von Apps anzubieten, die fr spezifische Bedrfnisse bzw. Umgebungen mit Public Display gedacht sind und ggf. bestimmte Qualittsanforderungen erfllen (z.B. Qualitt und Aktualitt der App-Inhalte). Optional knnen App Stores Display Ownern dazu dienen, Nutzungsstatistiken von Display Apps auf ihren Display Nodes zentralisiert abzurufen und darzustellen. Diese Funktion knnte jedoch ebenso innerhalb der eigenen Infrastruktur der Display Owner erfolgen. Viewer Wie bereits erwhnt, erhalten Viewer mit Hilfe der mobilen App eine bersicht der verfgbaren Display Apps in ihrer Region. Die mobile App ldt bzw. aktualisiert dazu regelmig Display-Metadaten fr die Region, in der sich ein Nutzer befindet. Diese enthalten ebenso die Display-App Metadaten der Apps, die die Public Displays untersttzen. Mchte ein Viewer jedoch eine bersicht ber alle ffentlich verfgbaren Apps erhalten (die ggf. in anderen Regionen verfgbar sind), so kann er seine mobile App mit einem Display App-Store integrieren. ber einen Link kann er einen oder mehrere App-Stores dauerhaft mit der mobile App verbinden und daraufhin ber sein Mobilgert auf Basis unterschiedlicher Kriterien nach Apps suchen,
bzw. einfach durch das Angebot browsen. Die mgliche implizite und explizite Nutzung entspricht dem gleichen Vorgehen wie bisher (siehe Abschnitt Mobile App). Fr erweiterte Funktionen wie dem Schreiben von Bewertungen im App Store oder dem Erwerb nicht-kostenfreier Display Apps (bzw. dessen Nutzungsrecht) mssen ggf. auch Viewer einen Benutzeraccount im jeweils verwendeten App Store anlegen. Schnitts tellen Folgende Schnittstellen sollte ein Display App Store zur Erbringung der beschriebenen Minimalfunktionalitt anbieten:
API: Display App Store Users registerUser(credentials,profile_data): result login(credentials): token modifyUser(credentials,profile_data,token): result unregisterUser(token) : result addApp(app_metadata,token): app_uri modifyApp(app_metadata,token): app_uri removeApp(app_uri,token) getApp(app_uri): app_metadata queryApp([filter]): app_metadata_list addCollection(name,settings,token): collection_uri modifyCollection(collection_uri,name,settings,token): on_uri removeCollection (collection_uri,token): result add/removeAppToCollection(app_uri,collection_uri,token): result queryCollection([filter]): collection_list getCollectionApps(collection_uri[,token]): app_metadata_list
Tabelle 7: Abstrakte API Display App Store
Apps
Collections collecti-
Die ersten vier Aufrufe dienen dem Registrieren, Einloggen, Modifizieren und Lschen eine Benutzer-Accounts. Diese knnen von allen Stakeholdern genutzt werden, d.h. ein Nutzer wird erst zum Application Provider, wenn er eine App registriert, kann jedoch u.a. auch gleichzeitig auch Kollektionen anlegen. Die folgenden vier Aufrufe dienen der Verwaltung von Apps. Der Aufruf queryApp ist ffentlich verfgbar, nimmt als Parameter diverse Filter an (Keywords, Kategorien, usw.) und gibt eine Liste von Display-App Metadaten zurck. Die restlichen Aufrufe dienen schlielich der Verwaltung von App-Kollektionen und dessen Zugriff.
59
Entfaltungsraum fr Geschftsflle Die konkreten Geschftsflle, die auf Basis der in dieser Arbeit beschriebenen Architektur prinzipiell ermglicht werden, sind sehr vielfltig. Eine Andeutung dieser Mglichkeiten soll Abbildung 14 anhand mglicher Geschftsbeziehungen zwischen beteiligten Stakeholdern geben.
Content Provider
Pay for Providing Apps/ Embedding Ads
Advertiser
Pay for Embedding
Pay for Delivery Buy Apps / Pay for Use Pay for Using Apps ( with Ads ) Offer Rewards For Use Offer Rewards For Use
Buy Apps / Pay for Use
Pay for Displaying Apps with Ads
Viewer
Buy Right to Use Displays
Display Owner
Abbildung 14: Entfaltungssraum fr Geschftsflle im Kontext der Tacita Architektur
Eine konkrete Ausarbeitung dieser Mglichkeit geht dabei ber den Rahmen dieser Arbeit hinaus. Grundstzlich, und insbesondere im Kontext des App Stores, lassen sich jedoch zahlreiche dieser Mglichkeiten unter Vorbild bereits erfolgreicher Geschftsmodelle durch die Erweiterung der Basisfunktionalitt der Tacita-Architektur hinzufgen.
5.4 Privacy
Die Tacita-Architektur ist kein Ansatz, der es ermglicht ohne jegliche Preisgabe von persnlichen Informationen beliebige personalisierte Inhalte auf Pubic Displays zu zeigen. Stattdessen gibt Tacita Viewern, durch den App-zentrierten Ansatz und die Mglichkeit der Wahrnehmung von nahen Displays, die Kontrolle darber, mit wem sie interagieren und welche Daten die teilen mchten. Diese Kontrolle beginnt bereits bei der Art die Prsenz eines Viewers in der Nhe von Public Displays festzustellen. bliche Anstze zur Wahrnehmung von Prsenz basieren typischerweise entweder auf dem fortlaufenden Tracking des Viewers durch die Infrastruktur oder auf Broadcast der eigenen Prsenz des Viewers sowie seiner Prferenzen an die gesamte Umgebung. Beim Ansatz des Trackings durch die Infrastruktur, muss ein Nutzer meis-
60
tens vorher auch noch an mehreren Stellen Profile anlegen (potentiell eins fr jede Public Display Infrastruktur unterschiedlicher Display Owner) und dort ggf. seine Prferenzen und Identifier hinterlegen. Bei Bluetooth basierten Verfahren muss ein Nutzer sich im Discoverable-Modus befinden, um von der Infrastruktur gefunden zu werden, kann dabei jedoch auch von jeder anderen dritten Partei verfolgt werden. Bei Positions-basierten Anstzen, sendet dagegen oft das Mobiltelefon des Viewers fortlaufend seine eigene Position mit potentiell sehr genauer Auflsung an eine zentrale Stelle, die dann ggf. Aktionen auf Public Display auslsen kann. Ist ein Viewer jedoch in der gesamten Zeit gar nicht in der Nhe eines Public Display gewesen, so hat die Infrastruktur trotzdem sein przises Bewegungsprofil erhalten. Der andere hufig vorzufindende Ansatz zur Personalisierung von Public Displays durch das fortlaufende Publizieren seiner Prferenzen an die direkte Umgebung z.B. mit Bluetooth-Gerte-Name, hat den offensichtlichen Nachteil, dass neben der Verfolgung der Prsenz einen Nutzers, auch noch jeder in der Umgebung die Prferenzen eines Viewers mithren kann. Mchte ein Nutzer nun ggf. Inhalte auf Public Display in seiner Nhe sehen wie z.B. die Anzahl neuer Emails in seinem Postfach, so muss er zwanglufig seine EmailZugangsdaten mit allen unbekannten Betreibern von Display Infrastrukturen (oder auch mit allen in seiner Umgebung, falls Bluetooth-Gerte Namen verwendet werden) teilen, da diese bentigt werden um die Anzahl neuer Emails auf dem jeweiligen Display anzuzeigen. Betrachtet man nun im Vergleich dazu den Tacita-Ansatz, so findet smtliche Interaktion direkt mit Display Apps statt, zu denen ein ggf. temporres Vertrauensverhltnis aufgebaut wurde, anstatt mit der unbekannten Display Infrastruktur. Zweifellos ermglicht dies den Applikation Providern dieser Apps das zentralisierte Sammeln von viel mehr Daten, als wenn all diese Daten auf verschiedene unbekannte Display-Infrastrukturen verteilt wrden. Warum ist also der App-zentrierte Ansatz besser? Betrachtet man den heutigen Umgang von Personen mit Anbietern von Internet-Services wie Facebook, Google und Amazon, so wird deutlich, dass diesen bereits jeder Art privater Daten anvertraut wird und daher ein sehr hohes Vertrauensverhltnis besteht. So werden z.B. die Kreditkartendaten lieber ein Mal an Amazon anvertraut, als diese jedem unbekannten kleinen Web-Shop mitzuteilen. Fhrt man sich nun wieder das Beispiel vor Augen, bei dem ein Viewer auf einem Public Display gerne die Anzahl seiner neuen Emails sehen wrde, so ist es verstndlich, dass ein Nutzer dies Daten eher mit einer einzigen Public Display App teilen wrde (welche z.B. bereits durch eine Vielzahl von Nutzern positive Bewertungen erhalten hat), als mit vielen unbekannten Quellen. Dabei ist es absolut vorstellbar, dass groe Dienste wie Facebook und Google, mit denen bereits Vertrauensverhltnisse bestehen, selbst eigene Public Display Apps anbieten. Die Daten, die diese Anbieter dann durch die Nutzung von Public Displays ihrer User sammeln, sind in vielen Fllen sicher nur eine kleine Ergnzung zu den Daten die ber viele
61
Jahre durch Check-ins, Foto-Tagging, Nachrichten-Korrespondenz usw. bereits gesammelt wurden. Unabhngig von dem App-zentrierten Konzept der Tacita Architektur, bietet dessen Ansatz zur Wahrnehmung von nahen Public Displays erhebliche Privacy-Vorteile im Vergleich zu den hufig verwendeten Anstzen. Da die mobile App mit Hilfe von lokalen Display-Metadaten bereits alle bentigen Informationen ber Public Displays in der Umgebung verfgt, bewegt sich ein Viewer durch seine Umgebung solange vllig unsichtbar, bis eine der verwendeten Sensing-Technologien ein nahes Display detektiert, dass eine gewnschte App anbietet. Da nun die mobile App die Anfrage zur Personalisierung des Displays gezielt direkt an das Display-App Backend sendet, bleibt der Nutzer fr die Public Display Infrastruktur weiterhin nicht identifizierbar, Das angefragte Public Display wei lediglich, dass irgendwer mglicherweise in der Nhe ist und eine bestimmte App aufgerufen hat. Ein wichtiger Privacy Aspekt ist sicherlich der Inhalt, den eine Public Display App anzeigt und somit fr die gesamte Umgebung sichtbar macht. Falls diese bereits sensible Informationen ber Viewer anzeigt, knnen diese durch alle Personen in der Umgebung, jedoch auch durch den potentiell nicht-vertrauenswrdigen Display Owner wahrgenommen und durch letzteren ggf. auch technisch mitgeschnitten werden. Somit liegt die Verantwortung einerseits bei dem Viewer, sich vor der Nutzung einer Display App zu informieren, welche Daten diese auf einem Public Display anzeigt bzw. an dieses bermittelt (z.B. mit Hilfe der App-Beschreibung sowie ggf. Nutzerkommentaren und Bewertungen im Display App Store), und andererseits bei dem Applikation Providern, nmlich Display Apps zu entwickeln, die die Privacy von Nutzern sehr ernst nehmen. So sollte z.B. eine Display App, die die Anzahl der Emails eines Nutzers anzeigt, auf keinen Fall von sich aus gleichzeitig auch die Email-Adresse des Nutzers anzeigen, sondern wirklich lediglich die reine Zahl neuer Emails und ggf. einen anonymen Indikator. Display Apps, die leichtsinnig mit Nutzerdaten umgehen, sollten dementsprechend ber Mittel wie Bewertungen und Meldesystemen von Nutzern identifizierbar gemacht werden knnen.
62
Kapitel 6 - Implementierung
6 Implementierung
Dieses Kapitel beschreibt die prototypische Implementierung der zuvor beschriebenen Tacita Architektur sowie dessen Integration mit Komponenten der e-Campus Public Display Infrastruktur auf dem Gelnde der Lancaster Universitt8 in England.
6.1 Verwendete Technologien

Eine wesentliche Designentscheidung bei der konkreten Implementierung der Tacita Architektur ist die breite Nutzung von Web-Technologie zur Realisierung der meisten Komponenten, jedoch insbesondere als Basis zur Entwicklung von Display Apps. Die verwendeten Technologien sowie Begrndungen fr deren Einsatz werden nun im Folgenden gegeben. HTTP (HyperText Transfer Protocol) soll als das primre bertragungsprotokoll zwischen allen beteiligten Komponenten verwendet werden. Durch seine hohe Verbreitung wird es praktisch durch alle aktuellen Programmiersprachen und Systeme umfangreich untersttzt. Desweiteren wird HTTP als das bertragungsprotokoll fr Webinhalte schlechthin von allen aktuellen Netzwerkinfrastrukturen problemlos weitergeleitet (Proxy-Server, Firewalls, etc.) und von Administratoren zugelassen. In Kombination mit RESTful (Representational State Transfer) APIs [47] kann es zudem dazu verwendet werden sauber strukturierte, leicht nutzbare, ffentliche Programmierschnittstellen zu realisieren. Es lsst dabei offen welche Inhalte darber transportiert werden knnen und ermglicht dadurch eine Hohe Flexibilitt bei der Nutzung. Durch den einfachen Upgrade auf HTTPS (HyperText Transfer Protocol Secure) lassen sich zudem Inhalte vor dem Abhren durch Unberechtigte schtzen. HTTP(S) ist ein zustandsloses Protokoll zur asynchronen Kommunikation und untersttzt keine persistenten Verbindungen. HTML5, CSS3 und Javascript sollen zur Entwicklung von Display-App Frontends verwendet werden. Eines der wichtigsten Argumente fr diese Designentscheidung ist die breite Untersttzung existierender Media Player zur Darstellung von Webinhalten. Die Mglichkeiten zur Realisierung attraktiver, interaktiver Public Display Apps auf Basis dieser Webtechnologien (und insbesondere seit HTML Version 5) sind beinahe unbegrenzt 9. So lassen sich z.B. mit Hilfe von WebGL (Web Graphics Library) und Javascript beliebige 2D und 3D Objekte innerhalb einer Website erzeugen und mit Hilfe von hardwarebeschleunigten 3D-Grafikkarten animieren. Die Ausfhrung von Javascript wurde zudem mittlerweile so stark optimiert (z.B. durch die V8 Engine im Webkit), dass sie mit manchen klassischen Programmiersprachen konkurrieren kann. Deswei8 9
http://www.lancs.ac.uk bersicht von HTML5 Features: http://slides.html5rocks.com/ 63
teren ermglicht die Nutzung nativer Web-Technologien einem enorm groen Entwicklerkreis den direkten Einstieg in die Entwicklung von Display-Apps. Im Gegensatz zu vorkompilierten Anwendungen knnen Aktualisierungen von Display App schlielich einfach an zentraler Stelle durchgefhrt werden und stehen bereits beim nchten Aufruf auf Public Displays zur Verfgung. XML (Extensible Markup Language) und JSON (JavaScript Object Notation) sollen zum Datenaustausch zwischen Komponenten und speziell zur Definition und Publikation von Display- und App-Metadaten verwendet werden. XML ermglicht aufgrund seiner hohen Flexibilitt die Abbildung beinahe beliebiger Datenstrukturen. In Verbindung mit XSD (XML Schema Definition) lassen sich diese Datenformate przise spezifizieren und automatisiert validieren, was die Grundlage fr die Interkation heterogener verteilter Systeme darstellt. Fr eine effizientere bertragung lassen sich XML-Daten jederzeit in das kompaktere JSON-Format umwandeln, welches zudem nativ in Javascript interpretiert werden kann. PHP5, Zend Framework und SQLite sollen schlielich zur Entwicklung von Display-App Backends dienen, welche serverseitig den Zustand von Display-Apps verwalten und als Verbindungspunkt fr Viewer-Personalisierung und Interaktion dienen. PHP5 wird als populre, flexible und performante Scriptsprache zur Entwicklung serverseitiger Funktionalitt gewhlt. In Kombination mit dem Zend Framework, einer umfangreichen freien Bibliothek von schwach gekoppelten PHP-basierten Komponenten, knnen schnell sauber strukturierte, auf dem Model-View-Controller Entwurfsmuster basierende Anwendungen entwickelt werden. Durch die Nutzung von SQLite wird auerdem die persistente, strukturierte, serverseitige Ad-hoc Speicherung von Daten ermglicht. Aufgrund der somit einzigen Umgebungsanforderung eines PHP-Interpreters, knnen auf diese Art entwickelten Anwendungen einfach per Copy, Paste & Run verteilt und genutzt werden. An dieser Stelle sei angemerkt, dass der hier verwendete Grundansatz zur Entwicklung von Webanwendungen nicht mehr auf der traditionellen Methode basiert, nmlich der serverseitigen Generierung und dem Reload von Web-Inhalten bei jeder Interaktion durch den User, sondern eine klare Unterscheidung zwischen Front- und Backend-Komponenten verwendet, die lediglich reine Daten ber klar definierte APIs austauschen. Somit wird jegliche Darstellungs- und Interaktions-Logik in das Frontend verlagert, welches auf HTML5, CSS3 und Javascript basiert. Websockets, Node.js und Socket.IO sollen verwendet werden, um direkte Interaktion in Echtzeit zwischen der mobilen App von Viewern und webbasierten Display-Apps zu ermglichen.
64
Mit Hilfe der in HTML5 eingefhrten Websockets, lsst sich zum ersten Mal eine bidirektionale persistente Verbindung zwischen Webseiten und Server-Anwendungen erstellen, die insbesondere das Auslsen von Ereignissen auf dem Server sofort an Webseiten weiterleiten kann und somit Webanwendungen mit hohen Reaktionszeiten ermglicht. Node.js10, einem Konsolen-Interpreter fr Javascript sowie Socket.IO11 werden dabei verwendet um einen Websocket-Server zu entwickeln, der die Echtzeit-Kommunikation zwischen beliebigen verteilten Komponenten ermglicht. Android und Java sollen schlielich zur Entwicklung einer mobilen App fr Android-Smartphones verwendet werden, die als eine der wichtigsten Komponenten die implizite und explizite Interaktion von Viewern mit Public Display Apps ermglicht.
6.2 Display Apps

Display Apps dienen in der Tacita Architektur als Mittel zur Gestaltung von Inhalten und Anwendungen fr Public Displays sowie als gemeinsame InteressenSchnittstelle zwischen den Stakeholdern. Dabei sollen Display Apps verschiedene Arten der Personalisierung und Interaktion untersttzen - von der Personalisierung mit Hilfe von Parametern durch Display Owner und Viewer bis hin zur direkten Interaktion per Berhrung oder der Multi-Viewer Echtzeit-Steuerung per Smartphone. Im Folgenden wird zunchst der Aufbau von webbasierten Display Apps beschrieben, die all diese Funktionalitt untersttzen. Anschlieend wird das AppMetadaten Format auf Basis von XML vorgestellt sowie ein Developer Kit zur Entwicklung von webbasierten Display Apps prsentiert. Im Rahmen dieses Kapitels soll im Folgenden mit dem Begriff Display App immer webbasierte Display App assoziiert werden. 6.2.1 Aufbau Web-basierter Display Apps Web-basierte Display Apps knnen in zwei Versionen, einer Minimal-Version sowie einer Version mit vollem Funktionsumfang realisiert werden. Minimal Display App Die Minimal-Version besteht dabei aus einem reinen App-Frontend welches vom Media Player eines Public Displays aufgerufen und angezeigt werden kann. Ein App-Frontend ist im Grunde genommen eine normale Website, die jedoch fr die (Vollbild-)Anzeige auf groen digitalen Bildschirmen ausgelegt ist. Die Gestaltung von Anwendungen und Inhalten speziell fr die Anzeige auf Public Displays ist dabei ein umfangreiches Thema fr sich, welches in dieser Arbeit nicht genauer betrachtet werden kann, das jedoch immer noch einen groen Forschungsspielraum
10 11
http://nodejs.org/ Eine Abstraktionsschicht fr Echtzeit-Browser Kommunikation: http://socket.io/ 65
bietet. Wie dem auch sein, HTML5, CSS3 und Javascript lassen einen gewaltigen Spielraum zur Entwicklung entsprechender User Interfaces. Ein Media-Player, der Webinhalte aufrufen und anzeigen kann, nutzt dazu meisten selbst eine der populren Browser-Engines, wie z.B. Webkit12. Das App-Frontend einer Display App wird wie bliche Webseiten auf Servern seines Application Providers gehostet (Abbildung 15, links) und nach dem Herunterladen lokal in seinem Web-Renderer ausgefhrt (analog zum Browser).
Abbildung 15: Aufruf und Anzeige einer Display App ohne Backend (l.) und mit Backend (r.)
Der lokale Javascript-Code kann nun abhngig von dem Zweck der Display App ggf. Inhalte aus anderen Quellen nachladen (z.B. News-Feeds). Im Prinzip knnen diese Inhalte nun von beliebigen Quellen geladen werden. Falls jedoch eine Same-OriginPolicy der Render-Komponente in Kraft ist, muss der Abruf von externen Informationen ggf. doch ber den Host-Rechner geladen werden, von dem die App aufgerufen wurde. Zur Realisierung dieses Mini-Proxies reicht oft bereits ein simples Script oder alternativ die Abschaltung dieser Policy. Eine Minimal Display App kann nur von Display Owner zur dauerhaften (ggf. zeitlich geplanten) Ausfhrung genutzt werden. ber ggf. angebotene Parameter kann auch dieser Typ von App zudem durch Display Owner konfiguriert werden (z.B. Auswahl der gewnschten Themen zur Anzeige durch eine News App). Viewer knnen diese Art von App nicht beeinflussen, da sie dafr keine Schnittstellen bietet. Voll wertige Display App Eine vollwertige Display App besitzt nun auf Serverseite ein App Backend, welches Schnittstellen zum Aufruf durch Viewer bietet. Nach dem Aufruf eines AppFrontends durch den Media Player (Abbildung 15, rechts), baut dieses entweder eine persistente Verbindung auf Basis von Websockets mit dem Backend auf oder falls Websockets nicht untersttzt werden, einen periodischen Abruf von Datenupdates per HTTP (Polling). Das App Backend bietet eine ffentliche Schnittstelle (RESTful API), die ber die App-Metadaten referenziert ist, und somit durch die mobile App von Viewern aufgerufen werden kann. Eine bersicht dieser API ist in Angang A1 zu finden. Ist eine Display App (oder genauer ihr Frontend) bereits auf einem Public Display ausgefhrt, so besteht eine persistente Websocket-Verbindung (oder eine leicht versetzter indirekter Weg ber HTTP-Polling), so dass Viewer HTTP-Anfragen
12
http://www.webkit.org/ 66
einschlielich ihrer Personalisierungs-Parameter fr dasselbe Public Display sofort an das Frontend weitergeleitet werden knnen. Zustzlich kann die mobile App zur Ermglichung direkter Interaktion in Echtzeit ebenso eine Websocket-Verbindung zum App-Backend aufbauen, wodurch eine virtuelle Verbindung zwischen AppFrontend und mobiler App aufgebaut wird, die zur bidirektionalen Full-Duplex Kommunikation genutzt werden kann. Ein Display Node erfhrt dabei nie von welchem Verbindungsendpunkt Viewer Anfragen stammen eines der wesentlichen Ziele der Tacita Architektur. Abbildung 16 veranschaulicht den inneren Aufbau eines App Backends sowie mgliche Verbindungen zum Frontend und Viewer-Mobilgerten.
App Host Display Node Media Player App Frontend App Frontend
Realtime Data (Websocket) RequestData (HTTP) Direct Interaktion (Websocket) Mobile Requests (HTTP)
App Backend Node.js Websocket Server HTTP API SQLite-DB
Near
RESTful API
PHP-Application
Viewer
Abbildung 16: Innere Architektur einer Display App mit Backend und Verbindungen zu Clients
Die Komponenten eines App-Backend bestehen aus einer PHP-Applikation, einer Datei-basierten SQLite-Datenbank sowie einem simplen Websocket-Server. Die PHPApplikation, basierend auf dem Zend Framework13, dient zur Implementierung bentigter Business-Logik und ist in ihrer Minimalausfhrung fr die Verwaltung von Viewer-Anfragen und dessen Zustand an Frontends auf verschiedenen Public Displays zustndig. Die SQLite Datenbank wird genutzt um diesen Zustand persistent zu speichern. ber eine RESTful API wird genau eine Schnittstelle zur Anfrage von Display Apps fr Viewer angeboten, sowie eine oder mehrere zum HTTP-basierten Abruf von Daten durch das Frontend. Der Websocket-Server dient als Verbindungspunkt fr Websocket-Verbindungen von Viewern und App-Frontends. Dieser hat zudem eine interne Schnittstelle (per Loopback Device) ber die er Nachrichten von der PHP-Applikation empfngt. Auf diese Weise knnen, ber HTTP eingehende Anfragen von Viewern die fr bereits per Websockets verbundene Frondends gedacht sind, sofort ber die bestehende Verbindung weitergeleitet werden. Der Websocket-Server fhrt dabei eine Liste von offenen Verbindungen, die ber die DisplayID referenziert werden. Anfragen vom Frontend an das Backend werden dabei in der Regel direkt an die RESTful Schnittstelle der PHP-Anwendung geleitet, jedoch ist die Nutzung einer bereits vorhandenen Websocket Verbindung dazu alternativ auch mglich. Zur Ermglichung von Echtzeit-Kommunikation zwischen Viewer und
13
http://framework.zend.com/ 67
Display App Frontend muss der Websocket-Server zustzlich Buch darber fhren, welcher mobile Client mit welchem Frontend verbunden ist. Zudem muss dieser, ggf. vor Weiterleitung von Nachrichten beim Applikations-Server anfragen, wie viele gleichzeitige Benutzer die Display App untersttzt, und ggf. Verbindungsanfragen ablehnen. Das gesamte Backend bietet im vorgestellten Aufbau lediglich die Basis fr eine Display-App im Rahmen der Tacita-Architektur. Die Voraussetzungen fr die Realisierung komplexerer Business-Logik werden durch die leicht erweiterbare PHPApplikation sowie eine bereits vorhandene und leicht ersetzbare SQL-Datenbank gegeben. Bisher wurde jedoch noch die der Nutzungsfall erlutert, bei dem eine Display App noch gar nicht auf dem Public Display luft, sondern erst durch einen Viewer zum Aufruf angefordert wird. Abbildung 17 erklrt diesen Nutzungsfall mit Hilfe eines Sequenz-Diagramms:
mobile App
Display App Backend
Display App Frontend
Media Player
1 .RequestApp(Display-URI, Display-URL, Params) 2. RequestApp(App-URI, Callback_URL) 3. App Allowed? [yes] 4. Load & Run Display App Frontend 5. RequestData(Display-URI) Data ... ... 6. Kill Display App Frontend Timeout, Other App Requested
Abbildung 17: Sequenzdiagramm zur Anfrage einer Display App auf einem Display Node
1. Die mobile App eines Viewers fordert ber die RESTful-API des Backends der gewnschten Display App dessen Aufruf auf einem nahen Public Display an. ber die Display-URI (analog zu Display-ID) wird das Display eindeutig identifiziert und ber die Display-URL die Schnittstelle seines Media Players zum Empfang von Personalisierungs-Anfragen bestimmt. ber Params werden die Personalisierungs-Parameter des Viewers an die Display App bermittelt. Smtliche Parameter knnen in Form von HTTP-POST-Body Parametern oder HTTP-GET URL-Parameter bertragen werden (z.B. /index.php?param1=value1&param2=value2). 2. Das App-Backend sendet nun eine Anfrage an die angegebene Display-URL, welche die eigene App-URI (analog zu App-ID) sowie eine Callback-URL enthlt. Die Callback-URL enthlt dabei einen Session-ID Parameter, der eine anonyme Referenz auf den aufrufenden Viewer darstellt und bentigt wird, um zu identifizieren, welcher Viewer eine Anwendung angefordert hat, sobald diese das Frontend zur Ausfhrung zurckruft.
3. Der Media Player berprft nun die Anfrage anhand seiner Policy und beendet diese mit einer positiven oder negativen Antwort (Basierend auf HTTPResponse Codes sowie ggf. zustzlichen Fehlernachrichten). 4. Falls die gewnschte App erlaubt ist, wird diese sofort (App-Tiling) oder zum nchsten mglichen Zeitpunkt (App-Queuing) vom Host des Application Providers geladen, gerendert und angezeigt (ggf. als eine unter mehreren anderen Apps). 5. Das App Frontend kann nun, wie bereit beschrieben, eine Websocket und/oder HTTP Verbindungen zum Backend aufbauen und so fortlaufend auf Anfragen von Viewern reagieren, Nutzdaten aktualisieren oder direkte Interaktion in Echtzeit ermglichen. 6. Die angeforderte Display App wird nun solange ausgefhrt, bis der Media Player diese z.B. aufgrund eines Timeout oder der Anfrage durch andere Apps ausblendet und beendet. Die Rolle des Display-App Backends soll zum Abschluss noch einmal mit Hilfe von Abbildung 18 deutlich gemacht werden. Ein App-Backend kann potentiell gleichzeitig sowohl von einer Vielzahl von Instanzen seines Frontends, die auf verschiedenen Public Displays verteilt sind, genutzt werden, als auch gleichzeitig durch eine Vielzahl von mobilen Viewern. Zudem knnen App-Frontends, ausgefhrt auf den Media Playern der Public Displays, Inhalte direkt oder ggf. indirekt ber ihr Backend von Content Provider abrufen.
Display Node 1 Media Player App Frontend Display Node 2 Media Player App Frontend Display Node n Media Player App Frontend
HTTP/ Websockets
HTTP/ Websockets
HTTP/ Websockets
App Host App Frontend App Backend

Request for Display 1 Request for Display 1 HTTP
Content Provider
Request for Display 2
Viewer 1
Viewer 2
Viewer n
Abbildung 18: Display App Backend als zentraler Verbindungspunkt
69
6.2.2 App Metadaten Die im vorherigen Kapitel abstrakte definierten App-Metadaten (Tabelle 2) werden nun konkretisiert und im XML-Format beschrieben. Tabelle 8 zeigt dazu beispielhaft die App Metadaten einer Public Display News App Beispielanwendung.
App Metadaten im XML-Format
<?xml version="1.0" encoding="UTF-8"?> <app> <uri>pdnews.lancs.ac.uk</uri> <type>website</type> <name>PD News</name> <description>Personalisable News for Public Displays</description> <terms><url>http://pdnet1.lancs.ac.uk/pdnews/public/terms.html</url></terms> <provider> <name>PD-NET</name> <email>info@pd-net.org</email> <url>http://pd-net.org</url> </provider> <images> <image> <url>http://pdnet1.lancs.ac.uk/pdnews/public/images/screenshot1.png</url> <title>News on Public Display</title> </image> </images> <metadata-origin-url>http://pdnet1.lancs.ac.uk/pdnews/public/metadata.xml</metadata-origin-url> <api> <display-api> <url>http://pdnet1.lancs.ac.uk/pdnews/public/display</url> <parameters> <parameter name="topics" type="text" required="true" desc="Select preferred news topics"/> </parameters> </display-api> <viewer-api> <url>http://pdnet1.lancs.ac.uk/pdnews/public/mobile</url> <parameters> <parameter name="topics" type="text" required="false" desc="Select preferred news topics"/> </parameters> </viewer-api> <persistent> <url>ws://pdnet1.lancs.ac.uk:1234/pdnews/mobile</url> </persistent> </api> <changed>2012-06-12T07:25Z</changed> </app> Tabelle 8: Beispielhafte App Metadaten im XML-Format
Das App-Backend bietet zur Generierung dieser Metadaten eine Webseite, auf der die Daten ber ein Formular eingegeben und abgespeichert werden knnen. 6.2.3 Display App Developer Kit Um zuknftigen Entwicklern die Erstellung von Tacita-kompatiblen Display Apps zu erleichtern, die Viewer Personalisierung untersttzen, wird ihnen eine Developer Kit zur Verfgung gestellt. Dieses besteht aus dem zuvor vorgestellten Front- und
70
Backend einer generischen Display App (Abbildung 19). Das Front-End besteht dabei aus einer Blanko Webseite (index.html) die bereits die zur Kommunikation mit dem Backend ntige Javascript Library einbindet (PDApp.js) und eine einfache Javascript API zum behandeln von Viewer Anfragen und direkter Interaktion bietet. Bentig ein Entwickler keinerlei zustzliche serverseitige Logik, so braucht er nur das Frontend nach seinen Wnschen anzupassen.
Display App Developer Kit to be run on Provider Host App Frontend PDApp.js App Backend Node.js Websocket Server HTTP API SQLite-DB
Index.html
RESTful API
PHP-Application
Abbildung 19: Display App Developer Kit
Die Javascript-API des Frontends zum Empfangen von Personalisierungsanfragen whrend der Laufzeit besteht dabei lediglich aus zwei Aufrufen, die berladen werden mssen, um sie zu implementieren (Tabelle 9: Display App Frontend Javascript API).
Display App Frontend Javascript API
function MyPublicDisplayApp() { this.onViewerAppears = function (id,params) { // ADD YOUR CODE HERE }; this.onViewerDisappears = function (id,params) { // ADD YOUR CODE HERE }; Tabelle 9: Display App Frontend Javascript API
Die direkte Interaktion per Websockets wird dagegen, transparent fr den Entwickler, als eine Art virtuelles Keyboard integriert. D.h. Tastencodes, die auf dem Smartphone bettigt werden, werden als Nachrichten ber die persistente Verbindung bertragen und ber die DOM(Document Object Model)-Event-API der HTMLSeite als Tastendruck-Events eingefgt. Mit Hilfe des Developer Kits wird es somit Entwicklern, die lediglich ber HTML, CSS und Javascript Kenntnisse verfgen, ermglicht innerhalb krzester Zeit eigene Display Apps anzubieten, die bereits durch Viewer-Smartphones personalisierbar ist und direkte Interaktion untersttzt.
71
6.3 Media Player

In aktuellen Display Netzwerken werden Media Player verwendet um geplante Inhalten mit Hilfe von Playlisten abzuspielen. Diese Inhalte bestehen zumeist aus Bildern, Videos und ggf. simplen Webseiten und werden zu bestimmten Zeiten, in einer bestimmten Dauer sowie zu in einer definierten Frequenz wiedergegeben. In der Tacita Architektur kann jegliche Funktionalitt mit Hilfe von Display Apps realisiert werden. Die Hauptaufgabe eines Media Players in Tacita ist somit die Ausfhrung und Steuerung von Display Apps. Welche Apps dabei dauerhaft aufgerufen oder spontan durch Viewer angefragt werden knnen, muss der Display Owner ber diesen Media Player Konfigurieren knnen. Zudem muss der Media-Player in der Lage sein seine Fhigkeiten in Service Directories zu publizieren sowie App-Stores als Quelle fr App-Metadaten einbinden zu knnen. Fhr man sich nun das im vorherigen Abschnitt vorgestellte Konzept von Webbasierten Apps vor Augen, so fllt auf, dass die Funktionalitt von klassischen Playlisten basierten Media Playern, selbst als einfache Web-basierte Minimal Display App realisiert werden kann. Diese Display App muss lediglich als Parameter vom Display Owner eine Playliste14 (z.B. im XML-Format) erhalten, kann diese dann interpretieren und die Inhalte (Bilder, Videos, andere Webinhalte) nach dem Zeitplan sequenziell laden und entsprecht skaliert anzeigen. Diese Art von App bentigt dabei offenbar nur eine Frontend, da Viewer Personalisierung nicht gewnscht ist. Eine Display App namens eChannel Player App, die exakt auf diesem Prinzip gebaut wurde, wird im nchsten Kapitel als Beispiel-App prsentiert und im Public Display Netzwerk der Lancaster University erprobt. Da nun gezeigt wurde, dass die Funktionalitt klassischer Media Player bereits auf Basis einer simplen Web-basierten Display App realisiert werden kann, liegt es nahe sogar einen Schritt weiter zu gehen und zu versuchen, den zur Ausfhrung von Display Apps bentigten, Tacita kompatiblen Media Player selbst als spezielle Web-App zu implementieren. Die dazu bentigten Funktionalen Voraussetzung, wie z.B. das eingebettete Aufrufen anderer Web-Inhalte (und somit anderer Display Apps), das dynamische Skalieren von Anzeigebereichen oder auch die persistente Speicherung von Display Owner Einstellungen, knnen dabei problemlos mit Hilfe von WebTechnologie realisiert werden. 6.3.1 Web-basierter App-Player als Referenz-Implementierung Tatschlicher befreit der eben beschriebene Ansatz den Rechner eines Public Displays (Display Node) vollstndig von der Notwendigkeit einen speziellen MediaPlayer installieren zu mssen. Stattdessen, wird lediglich ein aktueller Browser ben-
14
Die Erstellung solcher Playlisten wird blicherweise mit separater, spezieller Scheduling-Software durchgefhrt. 72
tigt, der den Web-basierten App-Player im Vollbild-Modus (Kiosk-Mode) ausfhrt. Abbildung 20 illustriert diese verschachtelte Verwendung von Web-basierten Display Apps. Auf diese Weise lsst sich prinzipiell jeder Rechner mit Bildschirm innerhalb Sekunden in ein personalisierbares (Public) Display verwandeln.
Display Node Browser in Kiosk-Mode App-Player eChannel Player App eChannel eChannel News App Player App Player App
Abbildung 20: Web-basierter App-Player ruft eingebettet andere Display Apps auf
Im Folgenden wird dieser Web-basierte App-Player als Referenz-Implementierung fr die innerhalb der Tacita Architektur bentigte Media-Player Komponente vorgestellt. App Player Aufbau Die Implementierung des App-Players baut dabei auf dem bereits vorgestellten Display App Developer Kit auf (Abbildung 19). Dementsprechend besteht der Aufbau aus einem Frontend, dass primr fr den Aufruf und die eingebettete Darstellung von Display Apps zustndig ist, sowie dem Backend, welches die Erreichbarkeit durch Viewer ermglicht. Der wesentliche Unterschied zur einer normalen Display App, welche eine Viewer Personalisierungs-Anfrage erhlt, ist, dass das App Player Backend diese Anfrage nun zur Anzeige an seine Frontend sendet, anstatt die Anfrage zur Anzeige seines eigenen Frontends an den Media-Player eines Display Nodes zu schicken. Aufgrund des verschachtelten Ansatzes der Nutzung von Display Web Apps sind die Zusammenhnge nicht ganz einfachen zu begreifen, weshalb diese im Folgenden Schrittweise erklrt werden. Abbildung 21 zeigt dazu den App Player (Front- und Backend) im Gesamtkontext der Tacita Architektur sowie seiner Nutzer.
73
Display Node Browser in Kiosk-Mode Service Directory

4. Publish Display Metadata Download/ Update Database
Available Apps From Display App Store
App-Player Frontend eChannel Player App eChannel eChannel News App Player App Player App
1 .Configure
Display Owner
8. Website 7. Request
3. Events (Websocket)
2. (Un-)Register Frontend
Display Owner Host App-Player Backend

Viewer
6. Request to be shown
News App Host App Frontend App Backend

Provides
App-Player Frontend
5. Request News App on near Display
Abbildung 21: App-Player im Gesamtkontext der Tacita Architektur
Der Folgende Ablauf bezieht sich auch Abbildung 21 und beschreibt das Konfigurieren und Aktivieren des App-Players auf einem Display-Node sowie die anschlieende Anfrage zum Starten einer News App durch die mobile App eines Viewers. 1. Der Display Owner ruft das Frontend des App-Players, welcher ggf. auf seiner eigenen Infrastruktur gehostet wird, auf und setzt einmalig die zum Betrieb des App-Player ntigen Einstellungen. Unter anderem verlinkt der Display Owner einen Display App Store und kann nun aus dessen Datenbank Display Apps selektieren, die er dauerhaft auf seinem Public Display ausfhren will oder zum Aufruf durch Viewer erlaubt. Diese Einstellungen werden persistent gespeichert und zur Generierung des Display Metadaten verwendet. 2. Sobald der Display Owner das App-Player Frontend ber einen Knopfdruck aktiviert hat, wird dieses mit seinen Einstellungen im Backend registriert und steht fr Viewer Anfragen zur Verfgung. 3. Gleichzeitig baut das App Player Frontend zum Backend eine persistente Websocket-Verbindung auf, die dazu genutzt wird Viewer-Anfragen ohne Verzgerung zu bermitteln. 4. Weiterhin werden im Backend die Display-Metadaten des gerade registrierten Frontends generiert und in einem durch den Display Owner spezifizierten Service Directory publiziert bzw. aktualisiert. 5. Ist nun ein Display Owner in der Nhe diese Public Displays und mchte implizit oder explizit die News App auf diesem Bildschirm aufrufen, dann muss seine mobile App dies beim Backend der News App anfragen.
74
6. Dieses fragt nun selbst das Backend des App-Player an, um von diesem aufgerufen zu werden. 7. Das App-Player Backend berprft die Anfrage anhand seiner Policy und sendet ber seine persistente Verbindung ggf. sofort eine Nachricht an sein Frontend, damit dieses die News App aufruft. 8. Der App-Player ruft nun die News App ab und stellt diese als Vollbild oder ggf. in aufgeteilten Bereichen zusammen mit anderen laufenden Apps dar. Oberflche Die Oberflche des App Players ist dazu gedacht im Vollbildmodus ausgefhrt zu werden. Abbildung 22 zeigt diese im passiven Modus an (keine ausgefhrten Apps). Die gesamte Anzeigeflche des App Players steht fr die Darstellung von Apps zur Verfgung. Lediglich ein QR-Code auf der Linken sowie ein kleiner Knopf auf der rechten Seite, der zum Aufruf des Mens genutzt wird, sind dauerhaft zusehen.
Abbildung 22: App Player in Passive Mode (not running any App)
Der QR-Code kann mit der Kamera des Viewer-Smartphones eingescannt und zum expliziten Aufruf von Display Apps dienen. Gleichzeitig wird der Presence Token Ansatz zur Validierung der Prsenz eines Nutzers vor genau diesem Public Display mit Hilfe des sich periodisch ndernden QR-Codes realisiert. ber das Konfigurations-Menu des App-Players mssen zunchst Grundangaben wie Display-URI (analog zu Display-ID), Name, Geoposition, Sichtfeld sowie Anbieter Angaben eingetragen werden (Abbildung 23, links). ber den Reiter Apps lsst sich ein Display App Store durch Angabe seiner URL einfinden. Anschlieend knnen aus der Liste verfgbarer Apps, einschlielich deren Beschreibung, diejenigen ausgewhlt werden, die zur dauerhaften Ausfhrung genutzt werden sollen und/oder jene die zum Aufruf durch Viewer erlaubt werden (Abbildung 23, rechts). Ebenso knnen ber die Viewer-Policy grundstzlich alle Apps erlaubt bzw. verboEntwicklung einer Privatsphre erhaltenden Architektur fr Mobile Interaktion mit Pervasive Public Display Netzwerken 75
ten werden. Fr jede ausgewhlte App knnen nun ggf. verfgbare Personalisierungs-Parameter fr Display Owner gesetzt werden. Hat eine Display-Owner alle ntigen Angaben gesetzt (u.a. auch die URL eines Service Directories), dann kann er den Active Knopf bettigen und den App Player und somit sein Public Display am Backend und im Service Directory registrieren. Display Apps, die zur dauerhaften Ausfhrung ausgewhlt wurden, werden sofort nach der Aktivierung ausgefhrt und angezeigt. Wurden mehrere ausgewhlt, so wird die Anzeigeflche entsprechend aufgeteilt (siehe nchster Abschnitt).
Abbildung 23: App Player Frontend Konfiguration Menus Basiseinstellungen (links), App-Policy (rechts)
App Til ing ber die weiteren Reiter kann im Konfigurations-Men unter anderem auch das Verhalten zur Ausfhrung von multiplen Apps eingestellt werden. Wie bereits im vorherigen Kapitel erlutert, knnen gleichzeitige Anfragen fr unterschiedlich Display Apps entweder auf Basis von Warteschlangen und der sequenziellen Anzeige dieser Apps als Vollbild oder durch das Aufteilen des Bildschirms und die gleichzeitige Anzeige der Apps, gelst werden. Der App Player implementiert dazu nur die letzte Strategie. Dazu wird der Bildschirm dynamisch bis zu einer einstellbaren Maximal-Anzahl von Apps in gleich groe Bereiche geteilt (Abbildung 24). Konkret werden zum eingebetteten Ausfhren der Apps HTML-IFrame-Elemente verwendet. Zustzlich lsst sich einstellen wie lange eine durch Viewer aufgerufene App maximal angezeigt wird, wenn der gleiche Viewer in der Zwischenzeit keine neue Anforderung geschickt hat.
76
Abbildung 24: App Player Aufteilen der Anzeigeflche zwischen Apps (Tiling)
Eine Reihe von Bildern, die den App-Player und dessen Tiling-Konzept im Einsatz mit echten Display-Apps zeigt, werden im nchsten Kapitel vorgefhrt. Vorteile des App Players Die Verwendung des App Players, und damit eines vollstndig Web-basierten Ansatzes bietet viele Vorteile: Plattformunabhngigkeit: Durch den rein Web-basierten Ansatz, lsst sich der App Player auf jeder Plattform die Webseiten aufrufen kann, ausfhren. Zentralisiert: Dadurch, dass das App Player Backend auf einem Webserver ausgefhrt wird, kann ein Display Owner eine Vielzahl von App Player Frontends auf den Public Displays seiner Infrastruktur betreiben, die alle das gleiche Backend nutzen. Dies ermglicht eine zentralisierte Verwaltung und Wartung dieser Komponente. Erreichbar: Der zentralisierte Ansatz des App Player Backends ermglicht es, lediglich diesen Rechner dem freien Internet exponieren zu mssen, jedoch seine Frontends hinter beliebigen Firewalls und NAT(Network Address Translation)-Netzwerken betreiben zu knnen. Dies ermglicht z.B. den Betrieb des App Players an einem Rechner an einem ggf. ffentlichen WLAN, jedoch weiterhin die Fhigkeit von beliebigen Viewer in der Nhe personalisiert zu werden ohne die Notwendigkeit von Portweiterleitungen an den Rechner des App Players (d.h. ohne Konfigurationsaufwand der Infrastruktur). Leicht Integrierbar: Der Web-basierte Ansatz des App Players ermglicht dessen Aufruf durch traditionelle Media Player (falls diese Webinhalte untersttzen) und somit eine schneller und einfache Integration in existierende Public Display Infrastrukturen.
6.3.2 Display Metadaten Die im vorherigen Kapitel abstrakt definierten Display-Metadaten (Tabelle 4: Abstrakte Metadaten Public Display) wurden ebenso wie die App-Metadaten konkretisiert und ins XML-Format bertragen. Ein Beispiel der Metadaten eines Public DisEntwicklung einer Privatsphre erhaltenden Architektur fr Mobile Interaktion mit Pervasive Public Display Netzwerken 77
plays knnen in Anhang A3: Display Meta-Daten im XML Format gefunden werden. Wie beschrieben werden die Display-App Metadaten automatisch Anhand seiner Einstellungen durch den App Player generiert und bei einem Service Directory registriert. Mchte ein Display Owner keinerlei Personalisierungs-Mglichkeiten fr Viewer anbieten, so kann er den App Player trotzdem nutzen, braucht diesen jedoch in keinem Service Directory zu registrieren. 6.3.3 Integration mit e-Campus Media Pl ayer Anstatt des im Rahmen dieser Arbeit entwickelten App-Players, kann auch jeder andere Media Player in die Tacita Architektur integriert werden, solange dieser die bentigten Schnittstellen implementiert (siehe. Kapitel 5, Tabelle 3). Genau dies wurde mit dem an der Lancaster University entwickelten und auf dem dortigen Public Display Netzwerk betriebenen Yarely Media Player durchgefhrt. Dem in Python implementierten Player, der hauptschlich zur Wiedergabe von geplanten Inhalten auf Basis von Playlisten aus dem dortigen e-Channel-System genutzt wird, wurde eine Schnittstelle hinzugefgt, die die Anfragen von Display Apps entgegennehmen kann, welche von mobilen Viewer angefragt wurden. Diese Schnittstelle wurde dabei einfach als TCP/IP Socket implementiert, der auf einem beliebigen Port auf Anfragen im spezifizierten Format wartet. Angefragte Apps wurden dabei mit hherer Prioritt behandelt und haben dadurch die Playlisten Anzeige einfach berlagert. Die Web-Renderer Komponente dieses Python Players hat dabei die ber die Schnittstelle angeforderten Display Apps Anhand ihrer CallbackURL aufgerufen und angezeigt. Eine Policy Implementierung sowie eine automatische Generierung von Metadaten und dessen Registrierung in einem Service Directory, wie beim App Player, wurden jedoch nicht implementiert. Um die Existenz dieser Player jedoch trotzdem fr mobile Viewer sichtbar zu machen, wurden die DisplayMetadaten Formular-basiert direkt beim Service Directory erstellt und registriert.
6.4 Service Directory

Das Service Directory wird vom App Player bzw. allgemein von Public Display Media Playern genutzt um deren Existenz und Fhigkeiten zu publizieren. Auf der anderen Seite dienen Service Directories dem Abruf von Metadaten durch die mobile App von Viewern. Dabei knnen Viewer Meta-Daten fr ganze Regionen auf einmal abrufen. Die Implementierung des Service Directories wird ebenso auf Basis von PHP, SQLite und dem Zend Framework realisiert. Dazu wurden die in Tabelle 5 definierten Schnittstellen-Aufrufe auf Basis einer RESTful API implementiert (siehe Anhang A1: RESTful APIs von Komponenten). Die Anwendung basiert, wie alle anderen serverseitigen Anwendungen dieser Arbeit, auf dem Model-View-Controller Architekturmuster und verwendet zudem mehrere Abstraktionsschichten zur Realisierung von
ORM (Object Relational Mapping). Weitere Implementierungsdetails sollen an dieser Stelle jedoch ausgelassen werden. Die API ermglicht das Registrieren von Metadaten geschtzt durch ein Passwort, sowie das Aktualisieren und lschen dieser Metadaten unter Angabe dieses Passworts. Der Aufruf dieser API wird direkt und automatisiert durch den App Player bernommen, was lediglich eine spezifische Funktion des App Players ist, die zur bequemeren Bedienung dienen soll. Der Abruf der Metadaten wird dagegen durch die mobile Android App gettigt, welche im nchsten Abschnitt vorgestellt wird. Abruf fr ganze Regionen Eine Besonderheit der Service Directory Implementierung liegt dabei in der Bereitstellung der Schnittstelle fr die mobile App der Viewer zum Abruf von Metadaten fr ganze Regionen, die lediglich ber ihre Art (Land, Bundesland, Region, Stadt, Strasse, usw.) und ein Schlsselwort (Dsseldorf) spezifiziert werden. Da diese Daten nicht mit den Display-Metadaten geliefert werden, mssen diese beim registrieren jedes neuen Displays neu herausgefunden werden. Dazu wird einfach die Geoposition des Public Display (aus den Metadaten) verwendet, um ber den Google-Reverse-Geocoding Dienst eine hierarchische Adresse zu erhalten. Diese Angabe werden dann zusammen mit den Metadaten in der SQLite Datenbank gespeichert und separat indiziert. Der Abruf von Metadaten durch Viewer auf diese Art ermglicht diesen selbst zu entscheiden, wie genau sie die Position, an der sie sich befinden und fr die sie Display-Metadaten bentigen, angeben mchten. Alternativ kann der Abruf auch fr kreisfrmige Bereiche erfolgen (durch Angabe des Zentrums und eines Radius). Inkrementelle Aktualisierungen und Datenreduktion Eine weitere Besonderheit der Schnittstelle zum Abruf von Metadaten, ist ihre Fhigkeit inkrementelle Aktualisierungen auf Basis des Zeitpunktes des letzten Abrufs zu ermglichen. Dadurch kann die zu bertragende Datenmenge ggf. drastisch reduziert werden. Bei Nutzung dieser Mglichkeit werden so lediglich alle Metadatenstze die sich gendert haben, oder die neu sind vollstndig bertragen. Fr alle andere wird lediglich ihre ID bermittelt, damit die mobile App lokal feststellen kann, welche Displays gelscht wurden. Ein weiteres Mittel zur Reduktion von redundanten Daten liegt in dem Ansatz, alle von Displays verwendeten App-Metadaten in einem separaten Bereich der Rckgabedaten zu sammeln und diese lediglich aus den Display-Metadaten heraus zu referenzieren. Auf diese Weise beinhaltet z.B. ein Suchergebnis mit 1000 DisplayMetadaten die alle die gleiche App untersttzen lediglich eine Instanz dieser AppMetadaten. Schlielich wird zur bertragung an mobile Gerte das schlanke JSON-Datenformat (anstatt XML) verwendet sowie Gzip bertragungskompression eingesetzt.
6.5 Mobile Android App

Aufbauend auf dem Konzept der mobilen App Komponente in der Tacita Architektur (Mobile App), wurde diese auf Basis des Android Plattform15 fr Smartphones prototypisch implementiert. Die Wahl fr Android wurde zum einen durch seine umfangreichen Mglichkeiten zum Zugriff auf Sensoren, wie GPS, Bluetooth, Kamera, usw., sowie seine Multi-Threading Fhigkeiten motiviert und zum anderen durch dessen hohe Verbreitung und einfaches und flexibles Publikationskonzept (im Gegenteil zu z.B. Apple iOS). Haupt-Funktionen Die Aufgabe der mobilen App ist es seinem Nutzer (Viewer) die implizite und explizite Interaktion mit nahen Public Displays zu ermglichen. Die Tacita-Architektur ermglicht dabei, dass eine Viewer zu dieser meistens unbekannten Public Display Infrastruktur keinerlei Vertrauensverhltnis aufbauen muss, um diese nutzen zu knnen. In der Tat bleibt ein Viewer, falls er es mchte, fr Public Displays und dessen Betreiber vllig unsichtbar. Stattdessen whlt ein Viewer Display Apps (hnlich zu Apps fr Smartphones) aus, personalisiert diese und fordert deren Anzeige auf nahen Public Displays aus, die diese Apps erlauben. Zur Realisierung dieser Funktionalitt muss ein Viewer ber seine mobile App Zugriff auf verfgbare Display Apps haben knnen, gewnschte Apps auswhlen und personalisieren knnen, sowie den Aufruf dieser Apps explizit oder implizit auf nahen Displays anfordern knnen. Weiterhin soll ein Viewer nach dem Start seiner angeforderten Display App ber sein Smartphone in Echtzeit mit dieser interagieren knnen. Die Realisierung dieser Funktionen auf Basis der Interaktion mit den Schnittstellen der anderen bereits implementierten Komponenten wird im Folgenden genauer beschrieben. Bedienungskonzept Das Bedienungskonzept dieser mobilen App besteht aus mehreren Ansichten (Activities) von denen jeweils immer nur eine sichtbare bzw. aktiv sein kann. Zwischen den Ansichten wird ber die angeboten Schaltflchen navigiert. Zustzlich sieht das Android-Bedienkonzept eine jederzeit mgliche Rckwrtsnavigation durch die zuletzt aufgerufenen Ansichten vor, sowie das wechseln zu anderen Anwendungen oder zur Wallpaper-Ansicht. Activities, die nicht mehr sichtbar sind werden angehalten und knnen daher nicht mehr weiterhin Code ausfhren. Das Konzept dieser mobilen App erfordert jedoch fr viele Funktionen (wie periodische Aktualisierungen, Positionsbestimmung, Scans und persistente Verbindungen) eine dauerhafte Ausfhrung unabhngig vom Zustand der Benutzeroberflche. Dies
15
http://developer.android.com 80
wird durch die Nutzung eines Android Service realisiert. Die Steuerung des Service und somit der darin ausgefhrten Prozesse wird ber einen Knopf im Benutzerinterface ermglicht, welcher leicht ber jede Activity zugnglich ist. Is der Service aktiv, so laufen alle wichtigen Prozesse weiter auch wenn eine andere Anwendung in den Vordergrund Gert. Der aktive Service wird zudem ber die Statusleiste signalisiert. ber den Service Steuerungs-Knopf hat ein Nutzer volle Kontrolle ber die App und kann diese jederzeit deaktivieren, falls er z.B. die Batterie schonen mchte. Display- und App-Metadaten Da die Tacita-Architektur auf dem Modell basiert, bei dem die mobilen Nutzer Public Displays in der Nhe detektieren und nicht umgekehrt, muss die mobile App ber Informationen zu deren Position oder mgliche Identifier (z.B. Bluetooth MAC-ID) verfgen. Diese Display-Meta Daten werden von der Android-App regelmig fr die Region des Viewers heruntergeladen und aktualisiert. Der Nutzer konfiguriert dabei ber die Einstellungen eine von drei Regionsgren (City, State, Country). Mit Hilfe der Bestimmung der eigenen Position, wird per Google Reverse Geocoding API entsprechend die Stadt, das Bundesland, oder das Land bestimmt, in dem sich der Nutzer gerade befindet. Das Tupel aus Regionsgre und Regionsname wird anschlieend zum Abruf der Display-Metadaten aller Displays in dieser Region ber die API des Service Directories verwendet. Die App wird dabei bereits mit der URL zu einem existieren Service Directory in ihren Einstellungen ausgeliefert. Jedoch lsst sich diese URL jederzeit ndern sowie zustzliche Service Directories hinzufgen. Falls Public Displays in der Nhe dies anbieten, kann die Android App sogar die URLs von verwendeten Service Directories automatisch aus den Bluetooth Gerte Namen dieser Public Display extrahieren (Service Directory Discovery). Die vom Service Directory heruntergeladenen Display-Metadaten im JSON-Format erhalten alle Informationen zu den Displays der Region, sowie die App-Metadaten der DisplayApps, die sie untersttzen. Zur Ermglichung von effizienten, lokalen Daten-Abfragen, wird die auf Android nativ untersttzte SQLite16 Datenbank zum abspeichern der Metadaten verwendet. Dabei werden diese in eine Tabelle fr Displays und eine fr Display-Apps aufgeteilt, sowie eine weitere, die deren n:n Relation abbildet. Fr SQL-Abfragen relevante Felder (ID, Lat, Lng, BT-Identifier, App-Policy, letzte Aktualisierung) werden zustzlich zu einem Feld mit dem gesamten Eintrag im JSON-Format in separaten Tabellenfeldern abgespeichert. Nach dem Herunterladen der Display-Metadaten vom Service Directory werde diese mit einem JSON-Parser gelesen und in die Datenbank berfhrt, bzw. dessen Eintrge aktualisiert. Dieser gesamte Vorgang passiert im Hintergrund, wird lediglich durch eine unaufdringliche Progress-Bar signalisiert und strt den Nutzer nicht bei der Interaktion.
16
http://developer.android.com/reference/android/database/sqlite/package-summary.html 81
ber den Download der Display-Metadaten erhlt ein Viewer auch die Metadaten der Displays Apps, die durch diese Displays untersttzt werden. Mchte ein Viewer jedoch noch andere ffentlich verfgbare Apps nutzten (z.B. auf Displays die grundstzlich die Ausfhrung aller Apps erlauben), so muss er zustzlich einen Display App Store einbinden. Die mobile App ermglicht dazu einfach das Eintragen einer App Store URL (oder potentiell mehrerer) ber die Einstellungen. Anschlieend verbindet sich die mobile App periodisch mit der API dieses App Stores, ruft die verfgbaren App-Metadaten ab, und aktualisiert seine App-Datenbank-Tabelle. Der simple Abruf aller Daten dient dabei nur der Einfachheit. Eine fortgeschrittene Version der mobilen App sollte dagegen die gezielte Suche von Apps erlauben (Die App Store API bietet diese Funktion auch bereits an). Auswahl und Personalisierung von Display -Apps Die mobile App erfordert von ihrem Nutzer im Prinzip nur das Auswhlen von Display Apps zur Nutzung sowie ggf. deren Personalisierung durch Parameter. Die Oberflche startet deshalb direkt nach der Anzeige des Splash-Screens direkt mit der Listen-Ansicht aller verfgbaren Display Apps. In dieser Ansicht werden die Namen der Apps sowie ggf. deren individuelle Symbole angezeigt. Der Haupt-Bildschirm wird mit Hilfe von Reitern in eine Ansicht aller Apps, aktivierter Apps und der Anzeige von Ereignissen strukturiert (Abbildung 25).
Abbildung 25: Android App Startbildschirm (l.), App-bersicht (m.), App-Detailansicht (r.)
Aus der bersicht aller Apps lassen sich dieser entweder direkt aktivieren, oder erst deren Detailansicht aufrufen. In der Detailansicht (Abbildung 25, rechts). werden die zur Personalisierung der App verfgbaren Parameter als Eingabefelder dargestellt,
die entweder optional oder oligatorisch sind. Der aktuelle Prototyp bietet bisher nur Textfelder zur Eingabe an, jedoch sollte eine fortgeschrittene Version ebenso Checkboxen, Auswahlfelder, etc. untersttzen. Aus der Detailansicht lsst sich ber Schaltflchen die App aktivieren, die direkte Interaktion starten (falls verfgbar) oder eine Kartenansicht anzeigen, die Public Displays im Umkreis anzeigt (und ob die aktuelle App durch diese untersttzt wird). Die alle Einstellungen aktivierter Apps und dessen Parameter werden lokal persistent gespeichert. Public Display Sensing Nach dem Abruf der regionalen Display-Metadaten und der Auswahl und Personalisierung gewnschter Apps muss die mobile App wahrnehmen knnen, wann sie in der Nhe von Public Displays ist, die die gewnschten Apps zur Ausfhrung erlauben. Die App verfgt dabei bereits ber alle Informationen um, Anwendungen auch aus der Ferne auf Public Displays anfordern zu knnen. Eine klare Designentscheidung ist es jedoch, Anwendungen nur anzufordern, wenn der Viewer mit seinem Mobilgert tatschlich in der Nhe ist. Auerdem knnen Public Displays auf Basis von Presence Token die Validierung der Viewer-Prsenz erzwingen sowie andere Mechanismen zur Vermeidung von Missbrauch einsetzten (z.B. Request Quotas). Zur Detektierung von nahen Displays wurden sowohl der Ansatz basierende auf absoluter Position als auch jener auf Basis von Identifiern implementiert (siehe Mobile App). Die Detektierung, basierend auf absoluter Position, nutzt GPS und WiFiFingerprinting17 des Smartphones zur Bestimmung der eigenen Position. Dazu biete Android eine einheitliche Schnittstelle, die u.a. die Angabe der gewnschten Positions-Genauigkeit bentigt und im Anschluss Positionsnderungen in Form von Ereignissen zu melden. Die mobile App verwendet dazu zwei unabhngige LocationListener, die Positionsnderungen sowohl ber GPS stammend als ber WiFi separat verfolgen. Die Positionsbestimmung basierend auf Mobilfunkmasten wird aufgrund deren Ungenauigkeit nicht verwendet. Desweiteren implementiert die mobile bereits das auf Kreissektoren basierende Trigger-Zonen Konzept. Die dazu ntigen Informationen werden durch Display Owner ber ihre Media Player modelliert und mit Hilfe der Display-Metadaten publiziert. Der fortlaufende Sensing-Algorithmus basiert nun auf mehreren Schritten: 1. Aus der Datenbank werden alle Displays selektiert, die sich in einem quadratischen18 Bereich von 200 Metern um die eigene Position befinden. Dies reduziert alle folgenden Abfragen auf eine relativ begrenzte Menge. 2. Aus dieser Menge werden diejenigen selektiert, die mindestens eine gewnschte App oder grundstzliche alle Apps untersttzen. 3. Zuletzt wird diese Menge auf alle Displays reduziert, in dessen Trigger-Zone sich der Viewer mit seinem Mobilgert gerade befindet (Abbildung 26, mitte).
17 18
Die Positionsbestimmung ber WiFi wird bereits transparent fr den Entwickler ber Google-Dienste realisiert Punkt in Quadrat SQL Abfragen sind gnstiger als Punkt in Kreis Abfragen 83
Die Bestimmung ob die eigene Position innerhalb eines Kreissektors liegt, basiert lediglich auf der Berechnung der Distanz sowie dem Winkel19 zwischen dem Display und dem Viewer. 4. An alle Displays, die sich nun noch in der letzten Menge befinden, werden ber die Backends der Display Apps selbst Anfragen zum Aufruf gesendet.
Abbildung 26: Android App Kartenansicht (l.), Karte mit sichtbaren Trigger-Zonen (m.), Public Display Infos(r.)
Zustzlich zur der gerade erluterten Detektierungs-Methode wird die Wahrnehmung von Public Display Identifieren auf Basis von Bluetooth untersttzt. In einem separaten Prozess des App-Services werden dazu fortlaufend Bluetooth Inquiry Scans durchgefhrt. Diese periodischen Scans liefern alle Bluetooth-MAC-Adressen und Gertename von Bluetooth Gerten in der Nhe. Abhngig von deren Gerteklasse kann die Reichweite eines Senders (hier Public Display) dabei zwischen 10 und 100 Metern liegen. Mit Hilfe der in den Display-Metadaten hinterlegten MAC-Adresse knnen nun mit einer einfachen Abfrage alle Displays in der Nhe identifiziert werden. Sendet ein Public Display zudem ein Presence Token in seinem Gerte-Name, so wird dieses als zustzlicher Parameter in den folgenden Anfragen verschickt. Wie zuvor werden die detektierten Displays auf App-Untersttzung berprft und ggf. Anfragen zum Aufruf von Apps gestartet (jedoch indirekt ber deren App Hosts). Die Hufigkeit von Anfragen an die gleiche App wird durch eine maximale Rate begrenzt (z.B. 1 Anfrage / 10s). Auerdem nutzt die App lediglich die ihm gerade zur Verfgung stehenden Technologien, d.h. ein Nutzer kann GPS, Bluetooth und WiFi jederzeit aus oder dazu schalten. Desto mehr Sensoren zur Verfgung stehen, desto
19
Ausgehend vom geographischen Nordpol 84
genauer und zuverlssiger lassen sich nahe Displays potentiell wahrnehmen. Eine absolute Anforderung zur Ermglichung dieser Anfragen ist jedoch die Verfgbarkeit einer Internetverbindung. Implizite und Explizite I nteraktion Der Nutzer kann die Anfragen zur Anzeige von Apps nun implizit oder explizit nutzen. Bei der impliziten Nutzung whlt der Viewer im Voraus Anwendungen aus, die er sehen mchte, sobald er an Public Displays vorbeikommt, die diese Apps untersttzen. Ebenso muss es bereits vorher seine Personalisierungs-Parameter setzten. Nun muss er lediglich die Haupt-Kontroll-Schaltflche bettigen, um den Hintergrunddienst und somit die Detektierungs-Prozesse zu starten und kann sein Smartphone in seiner Hosentasche versenken. Sobald ein Viewer nun in die Trigger-Zone oder Bluetooth-Reichweite eines Public Displays gelangt, welches die gewnschten Apps untersttzt, werden automatisch Anfragen an diese Apps (unter Angabe der Display-ID und Display-Request-URL) versendet und optimaler Weise innerhalb kurzer Zeit angezeigt (ein Evaluierung der Performanz dieses Ansatzes erfolgt im nchsten Kapitel). Es ist dabei offensichtlich, dass der Nutzer nicht immer das von ihm implizit personalisiere Public Display wahrnimmt, allerdings machen die ersten beiden Szenarien aus In diesem Kapitel werden funktionale und qualitative Anforderungen fr eine Architektur formuliert, die die anonyme implizite und explizite Ad-hoc Interaktion mit unbekannten Public Displays ber das Mobilgert von Viewern ermglichen soll. Um diesen Anforderungen mehr Hintergrund zu geben, werden im Folgenden drei Szenarien verwendet. Nutzungs-Szenarien die Ntzlichkeit dieses Modus deutlich. Mchte ein Nutzer explizit mit einem Public Display in der Nhe interagieren, so geht er auf gleiche vor. Er whlt die gewnschte(n) App(s) aus, setzt die Parameter und aktiviert die App. Die Personalisierung des Displays wird nun so lange fortgesetzt, bis der Viewer die App wieder deaktiviert oder er aus der Reichweite Gert. Der Fall, dass mehrere Displays gleichzeitig in Reichweite und potentiell personalisierbar sind, und deshalb ggf. nur eins ausgewhlt werden muss, wird durch den aktuellen Prototyp vernachlssigt. Eine weitere Methode zur direkten Interaktion wird durch das scannen der vom Public Display generierten QR-Codes ermglicht, das die ID des Displays sowie ggf. ein Presence Token beinhaltet (siehe Abbildung 22). Der auf den Scanvorhang ber die Smartphone-Kamera folgende Vorgang ist dabei anlog zu den vorhergehenden Ablufen. Fernsteuerung Hat ein Viewer bereits eine Display App aufgerufen, die direkte Steuerung per Mobilgert untersttzt, dann lsst sich, wie in Abbildung 27 gezeigt, die Ansicht zur
direkten Steuerung aufrufen. Im Hintergrund wird dabei eine WebsocketVerbindung zum Backend der aufgerufenen App hergestellt, die alle Befehle potentiell in Echtzeit an das auf dem Public Display ausgefhrte Frontend sendet. Die Reaktionszeit des Displays ist dabei insbesondere von der Qualitt, Auslastung und Latenz der auf dem bertragungsweg liegenden Mobilfunk-Verbindungen abhngig.
Abbildung 27: Android App Aufruf der Ansicht zur direkten Steuerung einer Display App
Wie in Abbildung 27 zu sehen, implementiert der Prototyp lediglich eine einfaches, jedoch sehr universal nutzbares User Interface zur Navigation und Texteingabe. Die gedrckten Tasten werden dabei an das ausgefhrte Frontend der Display App gesendet und in das DOM-Event-Model der Webseite eingeschleust. Auf diese Weise erscheinen diese Tastendruck-Ereignisse der Frontend-Webseite als kmen sie von einer lokalen Tastatur. Diese einfache Methode ermglicht bereits das Navigieren durch Webseiten (mit Hilfe der Cursor-Tasten oder der Shift-Taste, die den Fokus von Elementen verschiebt) sowie die Texteingabe in Felder mit Fokus. Insbesondere bei Public Displays, die durch fehlende Hardware keinerlei direkte Interaktion untersttzen, erweitert dieser Ansatz deren Fhigkeiten zur direkten Interaktion ohne jeglichen Konfigurationsaufwand. Eine fortgeschrittene Version knnte an dieser Stelle zustzlich leicht die Steuerung durch Gesten oder Wisch-Bewegungen implementieren. Feedback Um Nutzer darin zu untersttzen das Verhalten der App nachvollziehen zu knnen, wird einerseits ein ber den Reiter jederzeit erreichbares Event-Log angezeigt, sowie andererseits die Kartenansicht. Das Event-Log zeigt z.B. an welche Apps, wann und an welche Displays versendet wurden sowie die Ergebnisse dieser Anfragen. Weiterhin ist die Sensor-Quelle ersichtlich, ber die die Anfrage ausgelst wurde. Die
Kartenansicht bieten dagegen eine bersicht aller Displays in der Umgebung (sowie der gesamten Region) und zeigt dabei an, ob die gerade ausgewhlte Display App von den Displays untersttzt wird (Abbildung 26, links). Zudem wird die eigene Position angezeigt, was dem Viewer die Mglichkeit gibt, optisch zu verfolgen, wann er sich in einer Trigger-Zone befindet und wann nicht (Abbildung 26, mittig). Energieverbrauch Der Sensor-Intensive Ansatz dieser App erforder von einem Smartphone entsprechend viel Energie und fhrt daher ggf. zu einer stark verkrzen Laufzeit. Der Prototyp verwendet dabei zur Erhaltung der Einfachheit die bestmgliche Przision der gerade verfgbaren Sensor-Quellen. Ebenso wird, sobald der Nutzer den Detektierungs-Prozess aktiviert, der periodische Bluetooth Scan dauerhaft gestartet. Eine fortgeschrittene Version dieser App wrde diese Scan-Prozesse auf Basis vorhandener Informationen intelligent steuern und somit den Energieverbrauch ggf. drastisch senken ohne die Detektierungs-Genauigkeit zu verschlechtern. Diese intelligente Steuerung knne z.B. auf Basis der jederzeit verfgbaren groben Position auf Basis von Mobilfunkmasten smtliche Scan-Prozesse anhalten, da sich weit und breit keine Public Display befindet. Analog knnte dieser Ansatz auf die prziseren Ebenen bertragen werden, so dass der Bluetooth-Scan tatschlich erst gestartet wird, wenn der Viewer sich in der Nhe von Displays mit Bluetooth-Support befindet.
6.6 Minimaler Display App Store

Der Display App Store ist eine architektuelle Komponente zur zentralisierten Publikation von Display-App Metadaten durch Application Provider und zur Nutzung durch Display Owner und Viewer. Es ist auf die gleiche Weise wie das Service Directory implementiert (PHP, SQLite, Zend Framework, RESTful API) weshalb nicht weiter auf Implementierungsdetails eingegangen wird. Insgesamt wurde nur der Teil der im Architektur-Kapitel vorgeschlagenen Schnittstelle (Tabelle 7: Abstrakte API Display App Store) implementiert, der das Registrieren, Aktualisieren, Lschen und Anrufen von App-MetadatenEintrgen erlaubt. Eine bersicht ber die Aufrufe dieser RESTful API findet sich in [Anhang A1: RESTful APIs von Komponenten]. Da weder User-Accounts, noch AppKollektionen implementiert wurden, wird ein Password zum Schutz von Eintrgen verwendet. Desweiteren ist entweder der Abruf aller App-Metadaten mglich, oder nur derjenigen, die zu einem Suchwort passen. Die Minimal-Implementierung des App-Stores ermglicht jedoch bereits die Integration mit dem App Player sowie der mobilen App und damit deren bequemen Zugriff auf existierende Display Apps. Eine Webseite ermglicht zudem die einfache Formular-basierte Registrierung, Aktualisierung und Entfernung von Apps, ohne die RESTful API direkt ansprechen zu mssen. Dies dient genau genommen lediglich als GUI fr die API. Die Webseite, bentigt zur Registrierung und Aktualisierung eines
87
Eintrages lediglich ein Password, sowie eine URL, von der die App-Metadaten heruntergeladen werden knnen (Eine Schnittstelle zur Erzeugung und Bereitstellung von App-Metadaten wird bereits durch das Display App Developer Kit bereitgestellt). Die Minimal-Implementierung dieser Komponente stellt eine solid Grundlage fr eine Weiterentwicklung und Ergnzung des Display App Stores mit zustzlicher Funktionalitt dar.
88
Kapitel 7 - Evaluation
7 Evaluation
Whrend seines sechs monatigen Aufenthalts an der Lancaster University, hatte der Autor dieser Arbeit die Gelegenheit, die zur Realisierung der Tacita-Architektur entwickelten Komponenten innerhalb der dortigen, ber den gesamten Campus verteilten Public Display Infrastruktur, zu evaluieren. Die Evaluation wurde dabei in drei Schritten durchgefhrt. Im ersten Schritt wurden die zuvor implementierten Komponenten mit Hilfe eines mehrwchigen Deployments auf Funktionalitt und Integrierbarkeit mit der dortigen Infrastruktur berprft. In einem zweiten Schritt wurden zunchst experimentell mittlere Netzwerkverzgerungen gemessen und dann auf Basis eines Pass-By-Szenarios in insgesamt 84 Testlufen die Effektivitt mit der Display Apps auf Public Displays durch vorbeigehende Viewer aufrufen werden knnen, an zwei unterschiedlichen Standorten quantitativ festgestellt. Zuletzt wurde mit Hilfe mehrerer auf Basis des Display App Developer Kits erstellten Display Apps, der Designraum fr Display Anwendungen, die auf der Tacita-Architektur aufsetzen, erforscht und die Nutzbarkeit dieses Kits durch verschiedene Anwendungen praktisch berprft.
7.1 e-Campus Deployment

Um die Funktionalitt und die Integrierbarkeit mit einer realen genutzten Public Display Infrastruktur zu testen, wurden die im letzten Kapitel prsentierten Komponenten fr mehrere Wochen auf der Infrastruktur des Lancaster University eCampus Systems installiert. Dazu wurde die bis dahin genutzte Media Player Software auf drei Display Nodes auf dem Campus sowie drei Display Nodes im InfoLab21-Gebude deaktiviert und stattdessen der Web-basierte App-Player im Kiosk-Modus des Chrome-Browsers ausgefhrt. Da diese Public Displays, wenn sie gerade nicht personalisiert wurden, weiterhin die ber das e-Channel-System publizieren Inhalte als traditionelle Playlist wiedergeben sollten, wurde eine e-Channel Player App entwickelt, die diese Aufgabe erfllt und einfach dauerhaft vom App Player ausgefhrt wird (Das e-Channel-System und die e-Channel Player App werden im bernchten Abschnitt genauer vorgestellt). Auf diese Weise konnte optisch kein Unterschied zum bis dahin verwendeten Player festgestellt werden (auer den QR-Code in der linken unteren Ecke). ber den App-Player wurden fr jedes der sechs Public Displays der Lage entsprechende Trigger-Zonen gewhlt sowie bis dato verfgbare Display Apps zur Personalisierung ausgewhlt (News und Wetter-App). Diese Daten wurden automatisch im Service Directory gespeichert und konnten daher von den mobilen Apps im Einsatz abgerufen werden. Mehrere Mitarbeiter aus dem InfoLab21, die sich auch regelmig auf dem Campus aufhalten, wurden schlielich geben die mobile auf ihren Android-Smartphones zu installieren und ber die nchsten Wochen zu Testen. Um eine Konfiguration herzustellen, die eher denen von Display Ownern und Application Providern entspricht, wurden der AppPlayer und die verfgbaren Display-Apps auf separaten ffentlicher erreichbaren
89
Servern installiert (anstatt alle auf einem). Dies sollte bei Messungen zur realistischeren Reaktionszeiten fhren. Zu Beginn der Testphase konnten insbesondere einige Probleme mit der AndroidApp und unterschiedlichen Smartphones behoben, sowie Verbesserungsvorschlge integriert werden. Unter anderem wnschten sich Nutzer mehr Kontrolle, z.B. um jederzeit selbst die Aktualisierung von Display-Metadaten manuell auslsen zu knnen. Bei der Anzeige von Display Apps wurde zudem eine lngere MindestAnzeigezeit von >20 Sekunden erwnscht. In den meisten Fllen wurde durch die Nutzer berichtet, dass sie Inhalte auf den nahen Displays auslsen konnten. Desfteren mussten die dazu jedoch ggf. bis dahin nicht aktivierte Sensor-Quellen aktivieren (z.B. Dazu schalten von Bluetooth speziell in Gebuden). Mit Hilfe der bereits vorhandenen Display Apps konnte zudem das Konzept leicht demonstriert und Personen dazu aufgefordert werden, Ideen fr weitere Apps zu entwickeln. Als eine der dauerhaft aktiven Komponenten, konnte sich die e-Channel Player App, trotz Ausfhrung unterschiedlichster Inhalte (Bilder, Videos, Webseiten) ber den gesamten Testzeitraum stabil behaupten. Als besonderer Test wurde ein Display Node fr mehrere Minuten vom Netzwerk getrennt und dadurch eine nicht selten vorkommende Alltagssituation herbeigefhrt. Obwohl die prototypisch implementierten Komponenten nicht bewusst fr diese Situation vorbereitet wurden, wurde die Wiedergabe von Inhalten ber den eChannel Player (danke des transparenten BrowserCachings) problemlos weitergefhrt.
7.2 Sensing und Aufruf von Display Apps

In diesem Kapitel sollen zunchst die Verursacher der Verzgerung erlutert werden, die zwischen dem Eintreten eines Nutzers in eine Trigger-Zone (bzw. in Bluetooth-Reichweite) und dem Einblenden der gewnschten Display-App auf den Public Display auftritt. Anschlieend werden die reinen mittleren Netzwerkbertragungszeiten fr die notwendige Kommunikation der ArchitekturKomponenten experimentell unter Laborbedingungen gemessen. Schlielich wird der in den architektuellen Anforderungen dieser Arbeit genannte Referenzfall der Pass-By Situation, in dem die Personalisierung auf dem Public Display in einem bestimmten Zeitfenster geschehen muss, bevor der Viewer am Display vorgeht, mit Hilfe einer Reihe von Feldtests an zwei realen Public Standorten des Lancaster University Campus praktisch evaluiert. 7.2.1 Verzgerungsfaktoren Die fr die Verzgerung verantwortlichen Vorgnge zwischen dem Eintritt einer Person in die Trigger-Zone eines Displays und dem Erscheinen der gewnschten App(s) auf dem Public Display knnen in drei Abschnitte eingeteilt werden:
90
1. Die Detektierungs-Zeit, die die mobile App bentigt um feststellen zu knnen, ob sich der Viewer bereits in der Trigger-Zone eines Display befindet, das gewnschte Apps erlaubt. 2. Die Dauer zum Senden einer Anfrage per Mobilfunkverbindung (3G/GPRS) oder WiFi an das Backend der gewnschten Display App. 3. Die Anfrage des Display App Backends an den Media Player des Public Displays und dessen Aufruf und Darstellung der gewnschten App. Der erste Anschnitt hngt zunchst von den aktivierten Technologien ab. Falls WiFi, GPS und Bluetooth aktiviert sind haben jede von ihnen andere mittlere Ereignisraten. GPS liefert bei bester Auflsung 1 Location-Fix Ereignis pro Sekunden. Bluetooth basiert auf ca. 11 Sekunden dauernden Bluetooth-Inquiry Scans, welche das gesamte Frequenzband von Bluetooth durchsuchen und bereits whrend des Scans (oft mehrfach da Bluetooth-Gerte Frequenz-Hopping betreiben) gefundene Bluetooth-MACAdressen melden. Daher bentigen Bluetooth-Scans im Durchschnitt ca. 5,5s um ein Gert in Reichweite zu finden. Positionsermittlung basierend auf WiFi sind (zumindest auf Android Gerten) stark abhngig von der WiFi Abdeckung und liefern daher sehr unterschiedliche Positionsermittlungs-Raten. 7.2.2 Netzwerk-Verzgerung Da der erste Abschnitt extrem abhngig von dem Standort ist und bei Messung an nur einem Standort praktisch nichts aussagt, wurden zunchst die letzten Abschnitte, welche die Verzgerung durch das Netzwerk darstellen, experimentell unter Laborverhltnissen gemessen. Dabei wurden alle beteiligten Stationen (mobile App, App-Backend, App-Player-Backend und Display Node) per Zeitserver (Network Time Protokol) synchronisiert und jeder Station mit Logging-Funktionalitt erweitert. Die mobile App (verbunden ber 3G) hat dazu bei jeder Anfrage eine eindeutige Log-ID generiert, die von jeder Station an die nchste weitergegeben wurde und so am Ende durch Differenzbildung aller gemessenen Zeitstempel genaue Verzgerungsdauern fr Abschitt 2 und 3 ermittelt werden konnten (Tabelle 10).
Mean [s] 2) Mobile to App server 3) App server to Display Sum 1.96 2.35 4.31 Median [s] 1.70 2.22 4.13 Stnd. Abw. [s] 0.99 0.19 1.18
Tabelle 10: App Anfrage-bermittlungsdauern ermittelt aus 20 Messungen
Dabei wurde im Abschnitt 3 der (schlimmere) Fall gewhlt, bei dem keine Websocket-Verbindung zwischen App-Player-Front und Backend untersttzt wird, wodurch auf HTTP-Polling ausgewichen wurde. Somit wurde eine mittlere AnfrageNetzwerk-Verzgerung bis zum Anzeigen der gewnschten App von 4,31+-1.18s
gemessen (durch Einsatz von Websockets wre Abschnitt 3 um weitere ca. 1,5s reduziert worden). Ausgehend von dieser Verzgerungszeit, kann unter Annahme einer Gehgeschwindigkeit von 1.39m/s und einer GPS-Rate von 1 Fix/s eine Trigger-Zone mit einem Mindestradius von (4,31+1,18+1)s*1,39m/s = 9,02 Metern berechnet werden. 7.2.3 Effektivitt unter realen Bedingungen Zur Ermittlung der Leistungsfhigkeit der implementierten Komponenten in echten Situationen wurden zwei Public Display Standorte auf dem Campus der Lancaster University ausgewhlt, um dort mehrere Test-Reihen durchzufhren. Das Ziel war es dabei herauszufinden, wie gut der Tacita-Ansatz zur Personalisierung von Public Displays in der Vorbeigeh-Situationen funktioniert. In einem optimalen Fall sollte der gewnschte Inhalt gerade eingeblendet werden, wenn ein Viewer in Sichtweite eines Public Displays gert und wieder ausgeblendet werden, sobald dieser das Sichtfeld verlsst. Folgende Standorte wurden ausgewhlt um diese Situation zu testen. Display-Standort A befindet sich auf der Ecke eines Universittsgebudes, welches direkt an einem vielgenutzten Weg liegt, von dem aus das Display durch eine Glassfront von auen einsehbar ist (Abbildung 28, links). Standort B befindet sich in einem Erdgescho-Durchgangsbereich innerhalb eines Gebudes, welches dort mit zwei Public Displays ausgestattet ist (Abbildung 28, rechts). Fr beide Standorte wurden Sichtfelder geschtzt und entsprechende Trigger-Zonen erstellt. Der Radius wurde dabei an beiden Standorten auf 15m gesetzt, was in etwa der Sichtweit in Standort A entsprach, jedoch wesentlich grer war als die tatschliche Sichtweite in Standort B. Dies wurde bewusst auch dort gewhlt, um den auf absolute Position basierenden Positions-Quellen (GPS und WiFi) in dieser Indoor-Situation auch eine Chance zu geben an den jeweiligen Eingangsbereichen auszulsen. Die gewhlten Trigger-Zonen sowie die Laufwege werden in Abbildung 28 dargestellt.
Abbildung 28: Display Standorte Standort A (l.), Standort B (r.)
Methodik Es wurde eine Reihe von Tests durchgefhrt, bei denen einen Person die Rolle des Viewers bernommen hat und mit einem Mobiltelefon und der mobilen App ausge-
92
stattet wurde. Eine zweite Person bernahm die Rolle des Beobachters, um mit Hilfe einer speziell fr diese Aufgabe entwickelten Zeitmessungs-App die entsprechenden Ereignisse festzuhalten. Die mobile App des Viewers wurde eingestellt, um eine bestimmte Display App aufzurufen, sobald sich der Viewer in der Trigger-Zone befindet. Diese Display-App wurde dann fr 10s auf dem Public Display angezeigt, falls in der Zwischenzeit keine neue Anfrage empfangen wurde. Der Viewer hat sich nun zunchst weit auerhalb der Trigger-Zone begeben, um anschlieen mglichst immer im gleichen Geh-Tempo die angedeuteten Laufwege abzugehen und weit auerhalb der Trigger-Zone wieder Halt zu machen. Der Beobachter hat dabei jedes Mal mehrere Ereignisse mit Hilfe der Mess-App zeitlich festgehalten: 1) Den Zeitpunkt an dem der Viewer in Sicht des bzw. der Displays gekommen ist, 2) an dem die gewnschte App auf dem Public Display erschienen ist, 3) an dem der Viewer das Sichtfeld verlassen hat und 4) an dem die Display-App wieder vom Public Display ausgeblendet wurde. Die Ereignisse sind jedoch nicht zwingend in dieser Reihenfolge passiert, was ber die Mess-App festgehalten werden konnte. Es wurden auf diese Weise pro Standort jeweils 3 Lufe in jede Richtung durchgefhrt, bei denen jeweils immer nur eine Technologie alleine aktiviert war (GPS, WiFi, Bluetooth), sowie 3 Lufe in jede Richtung bei denen alle Sensor-Quellen aktiviert waren. Anschlieend wurden die Radien der Trigger-Zonen auf 24m (entsprechend des berechneten Mindest-Trigger-Zone-Radius) vergrert sowie die Winkel der TriggerZonen um 30 auf jeder Seite verbreitert und alle Tests wie zuvor noch einmal durchgefhrt. Insgesamt wurden 84 Testlufe durchgefhrt, wobei die von der Gre der Trigger-Zone unabhngige Bluetooth-Sensorquelle die Zahl der Experimente minimiert hat. Ergebnisse Um die Effektivitt des Systems zu ermitteln, wurden basierend auf den ZeitMessungen jeweils zwei Werte berechnet: Content-Exposure spiegelt den prozentuellen Anteil der Zeit wieder, in dem der gewnschte Inhalt auf dem Display angezeigt wurde, whrend der Viewer in Sichtweite war. Dadurch wird die Effektivitt des Systems ausgedrckt, den Viewer gezielt Inhalten aussetzen zu knnen. Content-Accuracy ist der prozentuelle Anteil der Zeit, in der der Inhalt vom Viewer htte gesehen werden knnen, relativ zu der Gesamtdauer die der Inhalt angezeigt wurde. Dieser Wert spiegelt die Fhigkeit des Systems wieder, Inhalte mglichst genauso lange anzuzeigen, wie der Viewer sich in Sichtweite befindet (Przision).
Ein System dass nun z.B. einen speziellen Inhalt dauerhaft einem Viewer anzeigt, egal ob dieser sich vor dem Display aufhlt oder nicht, hat eine hohe Exposure, jedoch eine sehr geringe Accuracy. Tabelle 11 zeigt die ermittelten Exposure/Accuracy Werte fr alle Kombinationen aus verwendeter Technologie, Standort und TriggerZonen-Gre.
GPS Loc. A 15m Loc. A 24m Loc. B 15m Loc. B 24m 0.2/0.26 0.25/0.16 0.01/0.01 0.64/0.65
WiFi 0.0/0.0 0.83/0.44 0.35/0.5 0.53/0.54
Bluetooth 0.21/0.34 0.58/0.51
All 0.38/0.35 0.89/0.64 0.74/0.63 0.98/0.26
Tabelle 11: Ermittelte Exposure- und Accuracy-Raten jeweils pro Standort, Triggerzonen-Gre und verwendete Technologie
Es lsst sich feststellen, dass in allen auer einem Fall die Anzeige der gewnschten Display App ausgelst wurde (Loc A, 15m, WiFi). Fr den gleichen Fall jedoch mit einer greren Trigger-Zone lassen sich erstaunlicherweise sehr gute Werte fr Exposure und Accuray feststellen. Dies lsst sich damit erklren, dass auf WiFiFingerprinting basierende Positionierung nicht fortlaufend eine neue Position liefert, sondern eher sprungartig zur nchsten, immer fr einen Aufenthaltsort selben, Position springt, sobald neue WiFi Netzwerke gescannt werden. Da die Trigger-Zone nun grer ist, deckt diese nun auch den auf Basis von WiFi bestimmten Punkt ab, und lst deshalb die Anzeige von Inhalten aus. Ebenso kann festgestellt werden, dass in vielen Fllen eine akzeptable Przision erreicht werden konnte. Im besten Fall war dabei der Viewer zu 65% der Zeit, die die Display App angezeigt wurde, auch im Sichtfeld. Weiterhin ist klar feststellbar, dass die Kombination aus allen verfgbaren Technologien in allen Fllen bessere Ergebnisse erzielt hat, als jede Technologie fr sich alleine. Durch die Vergrerung der Trigger-Zonen, konnte wie erwartet meistens ebenso die Exposure erhht werden. Gleichzeitig wre jedoch zu erwarten gewesen, dass sich dadurch die Przision verschlechtert, was jedoch nicht immer der Fall war. Dies lsst sich damit erklren, dass kleinere Trigger-Zonen fters erst die Anzeige des Inhalts auslsen, wenn dieser die Zone schon fast verlassen hat, wodurch Exposure und Accuracy schlecht ausfallen. Bei einer vergrerten Zone ist die Wahrscheinlichkeit grer, dass die Anzeige frher ausgelst wird und dann (durch die Mindestanzeigezeit von 10s) genauso lange dauert, bis der Viewer die Zone wieder verlassen hat. Insgesamt konnte an zwei verschiedenen Standorten einer echten Public Display Infrastruktur gezeigt werden, dass Inhalte basierend auf der Prsenz des Viewers mit groer Zuversicht aufgerufen werden knnen, sowie dass die Przision dabei gleichzeitig bei etwa 50% liegt.
7.3 Display App Anwendungsflle

Im Folgenden werden mehrere unterschiedlich Display Apps vorgestellt, die bisher zur dauerhaften oder spontanen Nutzung auf Public Displays entwickelt wurden. Jede von ihnen hat dabei entweder einen speziellen Fokus oder dient zur Demonstration der Mglichkeit, die durch die Tacita-Architektur gestattet werden. Gleichzeitig wurden die Apps auf Basis des Display App Developer Kits entwickelt, weshalb dieses,
leider zwar nur durch den Autor selbst, jedoch durch die praktische Nutzung in verschieden Anwendungsfllen getestet und verbessert werden konnte. 7.3.1 e-Channel Player App Dauerhafter Betrieb Das im e-Campus System der Lancaster University verwendete Channel System bietet fr verschiedenen administrative Nutzergruppen eine Web-Oberflche zur Komposition und Publikation von Inhalten auf der Public Display Infrastruktur des Campus und entkoppelt Inhalt-Ersteller und Display-Verwalter mit Hilfe von Channels. Inhaltersteller haben eigene Channels zur Publikation und Modifikation ihrer Inhalte. Display Verwalter knnen die Inhalte der Displays bestimmten, die sich in ihren Gebuden oder Bereichen befinden und abonnieren dazu einfach einen oder mehrere Channels fr jedes ihrer Displays. Auf diesen Displays befindet sich ein Media-Player, der fr ihn bestimmte Subscriptions regelmig aus dem ChannelSystem aktualisiert und abspielt. Diese traditionelle Media Player Funktionalitt wurde mit Hilfe der e-Channel Player App als separate Display App implementiert. Die App sollte dabei die dauerhafte Ausfhrung ermglichen und dem Display Owner die Mglichkeit zur Parametrisierung geben. Eine Personalisierung durch Viewer wurde in dieser Version nicht bentigt, weshalb die gesamte App als reines Display-App Frontend realisiert werden konnte (keine Verbindung zu einem Backend ntig).
Abbildung 29: e-Channel Player App im Einsatz, geffnetes App-Player Konfig-Men (r.)
Zur Implementierung der Channel Player App musste lediglich die vom Display Owner angegebenen e-Channel-Subscription-URL regelmig auf Aktualisierungen geprft, heruntergeladen, geparst und deren Inhalte abgerufen und angezeigt werden. Der Inhalt einer Subscription besteht dabei auf beliebig tief verschachtelten Channel-Playlisten im XML-Format (Content Descriptor Set), dessen Inhalte mit bestimmten Metadaten annotiert sind, wie z.B. Prioritt, Abspieldauer, AbspielWochentage und Uhrzeiten, Aktualisierungsrate, Datentyp, Gre und URL der jeweiligen Inhalte. Auf Basis dieser Metadaten wird nach jeder Aktualisierung eine interne sequenzielle Playlist erstellt und wiedergegeben. Abbildung 29 zeigt die e-
95
Channel Player App im Einsatz, sowie das (sonst ausgeblendete) KonfigurationsMen des App Players, in dem die e-Channel Player App zur dauerhaften Ausfhrung ausgewhlt und mit einer Subscription-URL parametrisiert wurde. Eine erweitere Version der e-Channel Player App knnte zustzlich die Steuerung von Viewern in der Nhe einbinden, damit diese interessante Inhalte z.B. Anhalten knnen um sie vollstndig zu lesen, oder ggf. auch um durch die Playlist zu navigieren. 7.3.2 News App Multi-Viewer Personalisierung Mit der PD News App wurde eine App zur Public Display optimierten Darstellung individueller Nachrichtenmeldungen entwickelt, die dauerhaft durch Display Owner oder spontan durch Viewer in der Nhe aufgerufen werden kann. Die App kann sowohl durch Display Owner als auch Viewer personalisiert werden, indem diese einfach Schlsselwrter angeben, ber die sie Nachrichten sehen mchten. Die durch den Display Owner bestimmten Themen werden standardmig angezeigt. Falls ein oder mehrere Nutzer sich in der Nhe befinden, werden aus freien News-APIs (z.B. Google News20) automatisch Inhalte zu deren Keywords abgerufen und im vorderen Teil aller Nachrichten angezeigt (hhere Prioritt als die Display Owner bestimmten Themen). Dabei zeigt die News App exemplarisch, wie die Personalisierungsanfragen mehrerer Viewer, die sich vor dem gleichen Display befinden und die gleiche App personalisieren mchten, bereits im News App-Backend verwoben und somit in der gleichen Frontend-Oberflche angezeigt werden. Alternativ htte das Backend der News App auch mehrere separate Anfragen an das Public Display senden knnen, so dass der ausfhrende Media Player (App Player) z.B. beide News Anfragen gleichzeitig in getrennten Bereichen angezeigt htte (Tiling).
Abbildung 30: News App auf Public Display (l.) personalisiert ber mobile App (r.)
20
https://developers.google.com/news-search/v1/jsondevguide 96
Abbildung 30 zeigt das News App Frontend (links) sowie die Personalisierung ber News-Tags (mehrere mglich, ber Komma getrennt) aus der mobile App heraus (rechts). Da die News-App hufig mehr Inhalte hat, als sie gleichzeitig anzeigen kann, rotiert diese die einzelnen Eintrge fortlaufend weiter. Dabei wird ein Eintrag fr mehrere Sekunden angezeigt (einstellbar durch Display Owner), dann langsam ausgeblendet und der nchste Artikel an dessen Stelle verschoben. Dieser Vorgang geschieht fr Nutzer optisch nachvollziehbar, so dass diese intuitiv das Rotationsprinzip verstehen. Ebenso werden Inhalte gleicher Kategorie ber eine gemeinsame Kategorie-Farbe verdeutlicht, sowie gezielt Bilder in Verbindung mit Nachrichtentexten verwendet um die Aufmerksamkeit von Passanten zu fangen. Eine erweitere Version dieser App knnte zudem fr jedes Display auf dem es aufgerufen wurde eine History von Viewer-Themen sammeln und sich somit, bei entsprechende aktiver Nutzung, automatisch an die Prferenzen der Viewer seiner Umgebung anpassen. Desweiteren, knnte ebenso die bereits bei der letzten App erwhnte Funktion zur direkten Navigation durch vorhandene News-Eintrge auch hier ergnzt werden. Schlielich sollte fr jeden News-Artikel eine Mglichkeit geschaffen werden, diesen auf das Mobiletelefon mitzunehmen und vollstndig lesen zu knnen. Eine einfache Lsung wre jeden Artikel mit einem kleinen QR-Code mit einer URL zur Artikelquelle zu versehen. 7.3.3 Weather App Anonymisierungs-Anstze PD Weather ist eine weitere Display App, die diesmal Wetterinformationen fr beliebige Orte anzeigen kann. Der Display Owner gibt in diesem Fall beim setzten der Personalisierungseinstellungen einen Ort an, fr den dauerhaft Wetterdaten angezeigt werden sollen (potentiell den Standort des Displays). Daneben werden fortlaufend Wetterdaten fr zwei weitere zufllig ausgewhlte Orte des Wetter-App Backends angezeigt.
Abbildung 31: Weather App auf Public Display in InfoLab21-Foyer (l.) personalisiert ber mobile App (r.)
97
Da die Anzeige von personalisierten Wetterdaten auf Public Displays auch fr fremde Personen in der Umgebung sichtbar ist (z.B. wenn diese angezeigt wird, solange der Viewer in der Nhe ist), knnte ein Nutzer es als unangenehm empfinden weil dies z.B. auf seinen Wohnort schlieen lsst. Befinden sich z.B. mehrere Personen in der Nhe des Public Displays und wird die mobile App im impliziten Modus genutzt (Smartphone in der Hosentasche), dann lsst sich nicht klar identifizieren, wer welche Personalisierung auslst. Stehen jedoch nur zwei Personen vor einem Bildschirm, so kann die zweite Person klar auf die Personalisierung durch die erste Person schlieen. Ein Ansatz zur Anonymisierung ist die Personalisierungs-Anfragen mit mindestens einem anderen zufllig ausgewhlten Ort anzuzeigen (oder mehreren) sowie in gleicher Dauer wie die zufllig eingeblendeten Orte. Dieser Ansatz ist natrlich etwas naiv, da ein dauerhafter Beobachter ggf. schnell die Liste aller zuflligen Orte herausfinden knnte und somit die angefragten Orte unterscheiden kann. Deshalb dient dieser Ansatz mehr zur Demonstration potentieller Strategien zur Anonymisierung von mglichen sensiblen Inhalten. 7.3.4 Ubi-VM App Mein Desktop verfolgt mich ! Die ubiVM (Ubiquitous Virtual Maschine) App basiert auf der Idee, dass zuknftig viele Personen eine eigene VM in der Cloud betreiben knnten, die als spezielle Inhaltscontainer dienen knnten um auf Public Displays angezeigt zu werden, wenn ihre Nutzer in der Nhe sind. Auf Basis von Display Apps und der Tacita Architektur Implementierung, konnte diese Idee in krzester Zeit realisiert werden. Dazu wurde ein App-Frontend entwickelt, dass ein VNC-Java-Applet enthlt, welches sich zu VNC-Servern verbinden kann. Ein Viewer muss auf seinem Mobilgert lediglich die ubiVM App zur Nutzung auswhlen und dort als Parameter den Hostnamen/Port und das Passwort seiner ber das Internet erreichbaren VM eingeben. Sobald sich dieser dann Public Display nhert, die diese App erlauben, wird die Oberflche der VM sofort dort angezeigt.
Abbildung 32: ubiVM Display App im Einsatz
98
Um die Performanz dieser Lsung auch noch bei potentiell mehr als einem ubiVM App Nutzer in der Nhe eines Displays zu testen, wurden mehrere gleichzeitige Aufrufe auf dem gleichen Public Display erzeugt. Abbildung 32 (l.o.) zeigt vier parallele VNC-Verbindungen zu unterschiedlichen Rechnern, die mit Hilfe der App-Player Tiling-Funktion in vier gleichgroen Bereichen dargestellt werden. Einer der VM-Dektops zeigt dabei ntzliche Widgets wie Kalender, Uhr und Wettervorhersage an. Ein anderer spielt gerade ein Video ab, das flssig angezeigt wird. Um diesen Test zu verschrfen wurden noch weitere parallele Verbindungen aufgebaut. Abbildung 33 (links) demonstriert dabei die Aufteilung in 9 Anzeigeflchen die jeweils eine Verbindung zur gleichen VM aufgebaut haben (aufgrund nicht genug vorhandener unterschiedlicher Testrechner). Der Graph dokumentiert dabei die Zeitdauern aus 10 Experimenten, welche bentigt wurde um gleichzeitig n VNC-Verbindungen zu externen Rechnern aus einem Kaltstart aufzubauen und seine Inhalte anzuzeigen (mit n = 1 bis 10). Kaltstart heit dabei, dass die n Apps erst frisch vom App-Player aufgerufen werden mussten, dies jedoch praktisch gleichzeitig.
Abbildung 33: ubiVM Start von 9 VNC-Verbindungen gleichzeitig (l.), Dauer des Aufbaus und Anzeige von n VNC-Verbindungen (r.)
Die Aufrufverzgerung bei mehreren Nutzern gleichzeitig ist deshalb interessant, da ab einer bestimmten Zahl gleichzeitig Nutzer, die VM eines neuen Viewers der gerade an einem Display vorbeigeht, ggf. nicht mehr rechtzeitig aufgerufen werden kann, um noch wahrgenommen zu werden. Abgesehen davon ist eine Aufteilung einer Public Display Anzeigeflche in mehr als vier Bereiche eher ungnstig um noch erkennbaren Inhalt zu liefern, auer die Personen befinden sich direkt vor dem Bildschirm, oder dieser ist einfach sehr gro. Mit Hilfe der ubiVM Display App konnte einigen Fokus-Gruppen, die von Kollegen zur weiteren Erforschung der VM-Idee durchgefhrt wurden, eine funktionierende Demonstration dieser Idee vorgefhrt werden, um dadurch ggf. weitere Ideen und Reaktionen bei den Teilnehmern zu stimulieren.
99
7.3.5 Digifieds Direkte Interaktion Im Rahmen eines internationalen Forschungswettbewerbs (Ubi-Challenge 2011 [48]) wurde u.a. durch den Autor dieser Arbeit eine interaktive Web-basierte Applikation fr Public Display entwickelt, die traditionelle Kleinanzeigen auf digitale Public Displays bringen mchten. Die Oberflche dieser Anwendungen ist jedoch stark auf Touch-basierte Bedienung ausgelegt, wie z.B. die Public Displays der Stadt Oulu [43]. D.h. Public Displays ohne diese Mglichkeit der Interaktion, wie z.B. die Displays der e-Campus Infrastruktur, knnen kaum von dieser Anwendung profitieren. Da Digifieds jedoch vollstndig Web-basiert ist, lie sich die Anwendung problemlos zur Display App erweitern. Mit Hilfe der direkten Interaktion ber die mobile App, kann durch Digifieds-Oberflche nun auch per mobile App navigiert werden. Dazu werden, wie in Abbildung 34 gezeigt, die Cursortasten der mobilen App dazu verwendet um durch die Kategorie-Bereiche der Digifieds App horizontal und vertikal scrollen zu knnen. Desweiteren kann die Tab-Schaltflche verwendet werden, um den Fokus auf Elementen der Oberflche zu verschieben und gezielt Elemente oder Eingabe-Felder zu selektieren. Die Tastatur der mobile App kann zudem zur Eingabe genutzt werden.
Abbildung 34: Direkte Steuerung von Digifieds [49] ber die mobile App
Somit zeigt dieser Anwendungsfall, wie leicht bereits vorhandene WebApplikationen fr Public Displays mit der Tacita-Architektur integriert werden knnen und zudem von dessen Funktionalitt profitieren. In dieser Kombination kann Digifieds nun durch Viewer auf Public Displays aufgerufen und bedient werden, auch wenn das Display gar kein Touch-Panel besitzt oder es ggf. sogar hinter einem Schaufenster steht wo es fr direkte Interaktion nicht erreichbar ist.
100
Kapitel 8 - Zusammenfassung und Ausblick
8 Zusammenfassung und Ausblick

8.1 Zusammenfassung
Groe digitale Displays sind bereits heute in vielen ffentlichen Umgebungen unseres Alltags zu finden. Die meisten dieser Displays dienen jedoch lediglich der sich stndig wiederholenden Anzeige Kontext-loser Inhalte, weshalb sie mittlerweile von einem groen Teil ihrer Zielgruppe einfach ignoriert werden. Dabei bieten Public Displays ein riesiges Potential ntzliche, interessante und unterhaltsame Inhalte anzubieten, die durch die Personen ihrer Umgebung beeinflusst und auf den Kontext eines Displays abgestimmt sind. Dazu werden jedoch Mglichkeiten bentigt explizit und auch implizit mit Public Display interagieren zu knnen. Eines der Gerte die problemlos zur Interaktion mit der Umgebung und somit auch Public Displays eingesetzt werden knnen, trgt beinahe jeder von uns stndig mit sich in der Hosentasche - das Mobiltelefon. Diese Arbeit zeigt, wie das Mobiltelefon als Interaktionsschnittstelle mit Public Displays eingesetzt werden kann, um potentiell beliebige Inhalte in Form von Display Apps aufzurufen, diese zu personalisieren und sogar in Echtzeit mit diesen interagieren zu knnen. Display Apps als Mittel zur Erbringung von individueller Funktionalitt auf Public Displays stellen zudem eine zentrale Schnittstelle zwischen den Interessen der beteiligten Stakeholdern dar. Application Provider knnen kreative Display Apps entwickeln und diese leicht mit Hilfe von Display App Stores publizieren. Viewer und Display Owner knnen, aus dieser potentiell groen Menge zuknftig verfgbarer Apps whlen und so bequem beliebige Funktionalitt auf Public Display bringen. Dabei behalten Display Owner weiterhin die Kontrolle darber, ob und welche Display Apps sie zulassen mchten. Viewer knnen dabei bewusst und gezielt Display Apps aufrufen und diese nutzen oder sie setzen Prferenzen in Form von Display Apps und Personalisierungseinstellungen, welche dann dazu verwendet werden Displays in der Umgebung eines Viewers automatisch anzupassen und seine Umgebung dadurch mit Informationen anzureichern, die fr ihn von Interesse sind. Die Architektur zur Erbringung dieser Funktionalitt ist dabei stark verteilt und skaliert daher auch (bzw. insbesondere) bei groen Display-, App- und Viewer-Zahlen. Wie auf Basis der prototypischen Implementierung gezeigt werden konnte, ist die Architektur leicht in eine existierende Public Display Infrastruktur integrierbar und in der Lage Viewer-initiierte Inhalte mit hoher Effektivitt und akzeptabler Przision auf nahen Public Displays aufzurufen und anzuzeigen. Schlielich wurde gezeigt, dass diverse Public Display Apps einfach und schnell auf Basis des Display App Developer Kits realisiert werden konnten, sowie dass sogar bereits vorhandene Public Display Anwendungen leicht zur Display Apps erweitert werden knnen.
101
Kapitel 8 - Zusammenfassung und Ausblick
8.2 Ausblick
Ein System dieser Art und dieses Umfangs bietet natrlich eine Vielzahl von Erweiterungs- und Optimierungsmglichkeiten jeder einzelnen Komponente. So knnten Display Apps (wie bereits im Architekturteil vorgeschlagen) um optionale private UIs extra zur Anzeige auf der mobilen App erweitert werden. Diese knnten dann zur bidirektionalen Interaktion mit der laufenden Display App auf einem Public Display eingesetzt werden und auf diese Weise individuell Steuerungsoberflchen anbieten (wie z.B. der virtuelle Nintendo Controller fr eine Public Display Tetris App) oder ggf. als privates oder sekundres Display dienen. Die jetzige Universal Remote Controller Funktion knnte leicht durch die Nutzung des Beschleunigungssensors um Gestensteuerung und Touch-Gesten (Verschiebung, Rotation etc.) erweiter werden, was die Qualitt der direkten Interaktion mit Public Displays ber die mobile App stark verbessern knnte. Eine weitere Methode zur direkten Steuerung einer Display App ber einen simulierten und animierten Cursor knnte mit Hilfe der in [21] vorgestellten Methode erfolgen, die die Kamera eines Mobiltelefons als visuellen Maussensor nutzt. Die mobile App knnte zudem intelligentere Strategien zur sparsameren Nutzung seiner Sensor-Quellen implementieren und somit deutlich weniger Energie verbrauchen. Um in Multi-User Szenarien bessere Erkennbarkeit zu gewhrleisten, wer welchen Inhalte aufgerufen hat (z.B. beim Aufruf gleicher Apps auf einem Display), knnte ein Konzept fr visuelle Identifikatoren entwickelt werden, das jedoch weiterhin (technisch) Anonymitt fr Viewer gewhrleisten muss. Um neu erstellte Apps auch entsprechend prsentieren zu knnen, sollte desweiteren der Display App Store, welcher bisher nur aus einem Minimal-UI besteht, um eine visuell ansprechende und funktionale Oberflche ergnzt werden, welche das Browsen durch Display Apps, dessen Screenshots, Bewertungen, Kommentare, AppKollektionen usw. erlaubt. Eine der wichtigsten Aufgabe ist jedoch die Realisierung weiterer kreativer Public Display Apps. Der Designraum und die durch die HTML5-Webtechnologie in Kombination mit der Tacita Architektur bereitgestellten Mglichkeiten zur Implementierung von Display-Apps sind riesig. Das ntige Web-Wissen ist bei potentielle Entwicklern meistens schon vorhanden und Einschrnkungen durch Vorgaben der Architektur praktisch nicht existent. Vielleicht kann diese Architektur, mit Untersttzung kreativer Display App Entwickler, tatschlich einen Schritt zur Realisierung Weisers Zukunftsvision [1] beitragen.
102
Literaturverzeichnis
[1] Marc Weiser, "The Computer for the 21st Century," Scientific American, no. 265, pp. 94-104, 1991. [2] Jrg Mller et al., "Display Blindness: The Effect of Expectations on Attention towards Digital Signage," Pervasive Computing, no. 5538, 2009. [3] Raymond R. Burke, "Behavioral Effects of Digital Signage," Jornal of Advertising Research, pp. 180-185, June 2009. [4] M. Pantic, "Implicit human-centered tagging," Signal Processing Magazine, IEEE, pp. 173 - 180 , 2009. [5] Jrg Mller, Juliane Exeler, Markus Buzeck, and Antonio Krger, "ReflectiveSigns: Digital Signs That Adapt to Audience Attention," Pervasive Computing, no. 5538, pp. 17-24, 2009. [6] Thorsten Prante et al., "Hello.Wall Beyond Ambient Displays," in Adjunct Proceedings of the 5th Intern Conference on Ubiquitous Computing UBICOMP03 (2003), 2003. [7] Nemanja Memarovic, Ivan Elhart, and Marc Langheinrich, "FunSquare: first experiences with autopoiesic content," in Proceedings of the 10th International Conference on Mobile and Ubiquitous Multimedia (MUM '11), 2011, pp. 175-184. [8] Joseph F. McCarthy, Tony J. Costa, and Edy S. Liongosari, "UniCast, OutCast & GroupCast: Three Steps Toward Ubiquitous, Peripheral Displays," in Ubicomp 2001, pp. 332-345. [9] Jorge C. Cardoso and Rui Jos, "A Framework for Context-Aware Adaptation in Public Displays," in Proceedings of the Confederated International Workshops and Posters on On the Move to Meaningful Internet Systems: ADI, CAMS, EI2N, ISDE, IWSSA, MONET, OnToContent, ODIS, ORM, OTM Academy, SWWS, SEMELS, Beyond SAWSDL, and COMBEK 2009 (OTM '09), 2009, pp. 118 - 127. [10] Florian Alt et al., "Adaptive User Profiles in Pervasive Advertising Environments," Ambient Intelligence, vol. 5859, pp. 276-286, 2009. [11] Fernando Reinaldo Silva Garcia Ribeiro, Rui Jos, and Peixoto Jos, "Timely and Keyword-Based Dynamic Content Selection for Public Displays," in Proceedings of the 2010 International Conference on Complex, Intelligent and Software Intensive Systems (CISIS '10), 2010, pp. 655-660. [12] Fernando Reinaldo Ribeiro and Rui Jos, "Autonomous and Context-Aware Scheduling for Public Displays Using Place-Based Tag Clouds," Ambient Intelligence and Future Trends-International Symposium on Ambient Intelligence (ISAmI 2010), no. 72, pp. 131-138, 2010. [13] Nicolas Villar, Albrecht Schmidt, Gerd Kortuem, and Hans-Werner Gellersen, "Interacting with Proactive Community Displays," Computers and Graphics, no.
27, pp. 849-857, 2003. [14] Nigel Davies, Adrian Friday, Peter Newman, Sarah Rutlidge, and Oliver Storz, "Using bluetooth device names to support interaction in smart environments," in In Proceedings of the 7th international conference on Mobile systems, applications, and services (MobiSys '09), 2009. [15] Rui Jos, Nuno Otero, Shahram Izadi, and Richard Harper, "Instant Places: Using Bluetooth for Situated Interaction in Public Displays," IEEE Pervasive Computing, no. 7, pp. 52-57, 2008. [16] Kento Miyaoku, Suguru Higashino, and Yoshinobu Tonomura, "C-blink: a huedifference-based light signal marker for large screen interaction via any mobile terminal," in Proceedings of the 17th annual ACM symposium on User interface software and technology (UIST '04), 2004, pp. 147-156. [17] Daniel Vogel and Ravin Balakrishnan, "Interactive public ambient displays: transitioning from implicit to explicit, public to personal, interaction with multiple users," in In Proceedings of the 17th annual ACM symposium on User interface software and technology (UIST '04), 2004. [18] T Nawaz, M Mian, and H Habib, "Infotainment devices control by eye gaze and gesture recognition fusion ," IEEE Transactions on Consumer Electronics, no. 54, 2008. [19] Jrg Mller, Robert Walter, Gilles Bailly, Michael Nischt, and Florian Alt, "Looking glass: a field study on noticing interactivity of a shop window," in Proceedings of the 2012 ACM annual conference extended abstracts on Human Factors in Computing Systems Extended Abstracts (CHI EA '12), 2012, pp. 1465-1466. [20] R. Ballagas, M. Rohs, J. Borchers, and J. Sheridan, "The Smart Phone: A Ubiquitous Input Device," IEEE Pervasive Computing, no. 5, pp. 70-77, 2006. [21] Rafael Ballagas, Michael Rohs, and Jennifer G. Sheridan, "Sweep and point and shoot: phonecam-based interactions for large public displays.," in CHI '05 extended abstracts on Human factors in computing systems (CHI EA '05), 2005, pp. 1200-1203. [22] Robert Hardy, Enrico Rukzio, Matthias Wagner, and Massimo Paolucci, "Exploring Expressive NFC-Based Mobile Phone Interaction with Large Dynamic Displays," in Proceedings of the 2009 First International Workshop on Near Field Communication (NFC '09), 2009, pp. 36-41. [23] "Using a mobile phone as a "Wii-like" controller for playing games on a large public display," Int. J. Comput. Games Technology, 2008. [24] Jaana Leikas, Hanna Stromberg, Veikko Ikonen, Riku Suomela, and Juhani Heinila, "Multi-User Mobile Applications and a Public Display: Novel Ways for Social Interaction," in Proceedings of the Fourth Annual IEEE International Conference on Pervasive Computing and Communications (PERCOM '06), 2006, pp.
66-70. [25] Donna Cox, Volodymyr Kindratenko, and David Pointer, "IntelliBadgeTM: Towards Providing Location-Aware Value-Added Services at Academic Conferences," UbiComp 2003, no. 2864, pp. 264-280, 2003. [26] Esko Kurvinen, Antti Salovaara, Giulio Jacucci Peter Peltonen, Tommi Ilmonen, John Evans, Antti Oulasvirta, and Petri Saarikko, "It's Mine, Don't Touch!: interactions at a large multi-touch display in a city centre," in Proceedings of the twenty-sixth annual SIGCHI conference on Human factors in computing systems (CHI '08), 2008, pp. 1285-1294. [27] Eva Hornecker, "Interactions around a contextually embedded system," in Proceedings of the fourth international conference on Tangible, embedded, and embodied interaction (TEI '10), 2010, pp. 169-176. [28] Elizabeth F. Churchill, Les Nelson, Laurent Denoue, and Andreas Girgensohn, "The Plasma Poster Network: Posting Multimedia Content in Public Places," in Ninth IFIP TC13 International Conference on Human-Computer Interaction (INTERACT 2003), Zrich, Switzerland, 2003. [29] Jrg Mller, Florian Alt, Daniel Michelis, and Albrecht Schmidt, "Requirements and design space for interactive public displays," in In Proceedings of the international conference on Multimedia (MM '10), New York, 2010. [30] Aiman Erbad, Michael Blackstock, Adrian Friday, Rodger Lea, and Jalal AlMuhtadi, "MAGIC Broker: A Middleware Toolkit for Interactive Public Displays," in 6th IEEE International Conference on Pervasive Computing and Communications PerCom, 2008, pp. 509-514. [31] Simo Hosio, Marko Jurmu, Hannu Kukka, Jukka Riekki, and Timo Ojala, "Supporting distributed private and public user interfaces in urban environments," in In Proceedings of the Eleventh Workshop on Mobile Computing Systems & Applications (HotMobile '10), 2010. [32] Oliver Storz, Adrian Friday, and Nigel Davies, "Supporting content scheduling on situated public displays," Computers & Graphics, pp. 681-691, 2006. [33] Tomas Linden, Tommi Heikkinen, Timo Ojala, Hannu Kukka, and Marko Jurmu, "Web-based framework for spatiotemporal screen real estate management of interactive public displays," in In Proceedings of the 19th international conference on World wide web (WWW '10), New York, 2010. [34] Jennica Falk and Staffan Bjrk, "The BubbleBadge: a wearable public display," in CHI '99 extended abstracts on Human factors in computing systems (CHI EA '99), 1999, pp. 318-319. [35] Daniel Michelis and Jrg Mller, "The audience funnel: Observations of gesture based interaction with multiple large displays in a city," International Journal of Human-Computer Interaction, vol. Vol 27, 2011.
[36] Jrg Mller and Antonio Krger, "MobiDiC: Context Adaptive Digital Signage with Coupons," Ambient Intelligence, no. 5859, pp. 24-33, 2009. [37] Mark Weiser and John Seely Brown, "Designing calm technology," Powergrid Journal, 1996. [38] Simo Hosio, Hannu Kukka, and Jukka Riekki, "Social Surroundings: Bridging the Virtual and Physical Divide," IEEE MultiMedia Magazine, no. 17, Apr. 2010. [39] Norbert Streitz et al., "Ambient Displays and mobile devices for the creation of social architectural spaces," in Puplic and Situated Displays: Social and Interactional Aspects of Shared Display Technologies.: Kluwer Academic Publisher, 2003, ch. 16, pp. 387-409. [40] PD-NET - Towards Future Pervasive Display Networks. European Union Seventh Framework Programme (FP7/2007-2013) under grant agreement no. 244011. [Online]. http://www.pd-net.org [41] Sarah Clinch, Nigel Davies, Adrian Friday, and Christos Efstratiou, "Reflections on the long-term use of an experimental digital signage system," in In Proceedings of the 13th international conference on Ubiquitous computing (UbiComp '11), 2011. [42] Matthew Sharifi, Terry Payne, and Esther David, "Public Display Advertising Based on Bluetooth Device Presence," in Proceedings of the Workshop "Mobile Interaction with the Real World" in conjunction with MobileHCI, 2006. [43] Timo Ojala et al., "UBI-Hotspot 1.0: Large-Scale Long-Term Deployment of Interactive Public Displays in a City Center," in Proceedings of the 2010 Fifth International Conference on Internet and Web Applications and Services (ICIW '10), Washington. [44] Ben Schneiderman, Designing the User Interface., 1996. [45] Nigel Davies, Adrian Friday, Sarah Clinch, and Albrecht Schmidt, "Challenges in Developing an App Store for Public Displays - A Position Paper," in Proc. of Research in the Large" Workshop at UbiComp, Copenhagen, 2010. [46] Sarah Clinch, Nigel Davies, Thomas Kubitza, and Albrecht Schmidt, "Designing Application Stores for Public Display Networks," in Proceedings of The International Symposium on Pervasive Displays (to appear), Porto, 2012. [47] Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software Architectures, Dissertation, 2000. [48] Timo Ojala and Vassilis Kostakos, "UBI challenge: research coopetition on realworld urban computing," in In Proceedings of the 10th International Conference on Mobile and Ubiquitous Multimedia (MUM '11), 2011. [49] F. Alt et al., "Digifieds: Evaluating Suitable Interaction Techniques for Shared Public Notice Areas," in Adjunct Proceedings of the 9th International Conference on Pervasive Computing, 2011.
[50] Saul Greenberg and Michael Rounding, "The notification collage: posting information to public and personal displays," in In Proceedings of the SIGCHI conference on Human factors in computing systems (CHI '01), New York, 2001. [51] Elaine M. Huang and Elizabeth D. Mynatt, "Semi-public displays for small, colocated groups," in In Proceedings of the SIGCHI conference on Human factors in computing systems (CHI '03), 2003. [52] O. Storz et al., "Public Ubiquitous Computing Systems: Lessons from the eCampus Display Deployments," IEEE Pervasive Computing, vol. Vol 5, 2006. [53] David W. McDonald, Joseph F. McCarthy, Suzanne Soroczak, David H. Nguyen, and Al M. Rashid, "Proactive displays: Supporting awareness in fluid social environments," ACM Trans. Comput.-Hum. Interact, vol. 14, 2008. [54] Saul Greenberg, Michael Boyle, and Jason Laberge, "PDAs and shared public displays: Making personal information public, and public information personal," in Personal Technologies, London, 1999. [55] Elaine M. Huang, Anna Koster, and Jan Borchers, "Overcoming Assumptions and Uncovering Practices: When Does the Public Really Look at Public Displays?," Pervasive Computing, vol. 5013, pp. 228-243, 2008. [56] Timo Ojala et al., "Multipurpose Interactive Public Displays in the Wild: Three Years Later," Computer, no. vol. 45, 2012. [57] Elizabeth F. Churchill, Les Nelson, and Laurent Denoue, "Multimedia Fliers: Information Sharing With Digital Community Bulletin Boards," in Communities and Technologies, Amsterdam, 2003. [58] Adam Fass, Jodi Forlizzi, and Randy Pausch, "MessyDesk and MessyBoard: two designs inspired by the goal of improving human memory," in In Proceedings of the 4th conference on Designing interactive systems: processes, practices, methods, and techniques (DIS '02), New York, USA, 2002. [59] T. Heikkinen et al., "Lessons Learned from the Deployment and Maintenance of UBI-Hotspots," in Multimedia and Ubiquitous Engineering (MUE), 2010 4th International Conference, 2010. [60] H. Brignull and Y. Rogers, "Enticing people to interact with large public displays in public spaces," in Proceedings of INTERACT'03, 2003, pp. 17 - 24. [61] Florian Alt, Thomas Kubitza, Dominik Bial, Firas Zaidan, Markus Ortel, Bjrn Zurmaar, Tim Lewen, Alireza Sahami Shirazi, and Albrecht Schmidt, "Digifieds: insights into deploying digital public notice areas in the wild.," in Proceedings of the 10th International Conference on Mobile and Ubiquitous Multimedia (MUM), 2011. [62] Dave Snowdon and Antonietta Grasso, "Diffusing information in organizational settings: learning from experience," in In Proceedings of the SIGCHI conference on Human factors in computing systems: Changing our world, changing ourselves (CHI
107
'02), 2002. [63] Florian Alt, Nemanja Memarovic, Ivan Elhart, Dominik Bial, Albrecht Schmidt, Marc Langheinrich, Gunnar Harboe, Elaine Huang, Marcello P. Scipioni, "Designing Shared Public Display Networks - Implications from Todays PaperBased Notice Areas," in Ninth International Conference on Pervasive Computing Pervasive 2011, 2011. [64] Hannu Kukka, Fabio Kruger, and Timo Ojala, "BlueInfo: Open Architecture for Deploying Web Services in WPAN Hotspots," in Proceedings of the 2009 IEEE International Conference on Web Services (ICWS '09), 2009, pp. 984-991. [65] Gilbert Beyer et al., "Audience behavior around large interactive cylindrical screens," in In Proceedings of the 2011 annual conference on Human factors in computing systems (CHI '11), 2011. [66] Lauri Aalto, Nicklas Gthlin, Jani Korhonen, and Timo Ojala, "Bluetooth and WAP push based location-aware mobile advertising system," in Proceedings of the 2nd international conference on Mobile systems, applications, and services (MobiSys '04), 2004, pp. 49-58. [67] Keith Cheverst et al., "Exploring bluetooth based mobile phone interaction with the hermes photo display," in Proceedings of the 7th international conference on Human computer interaction with mobile devices & services (MobileHCI '05), 2005.
108
Anhang
Anhang
A1: RESTful API s von Komponenten Info: Die Body-Parameter und Datenformate sind zur Erhaltung der bersichtlichkeit hier nicht angegeben.
App Player API:

Resource Action Method URI
api/display/{display_uri}
Display
App
Register a new display with its unique display_uri and settings Unregister the display Get current active apps Request the start of a display app with parameters
PUT
DELETE GET POST
api/display/{display_uri} api/display/{display_uri}/app api/display/{display_uri}/app
Generische Display App aus Developer Kit:

Resource App Action Method URI
api/app/{display_uri} api/app/{display_uri}
Mobile
Register a new app frontend on a display Unregister the app frontend from a display Get current active personalisation requests for a display Request the start of this app on a given display
PUT DELETE
GET
api/app/{display_uri}/viewer
POST
api/app
109
Anhang
Service Directory:
Resource Display Action Method URI
api/display/{display_uri} api/display/{display_uri}
Register display and save display metadata Change display metadata unsing password Delete display metadata unsing password Get displays by positions and radius Get displays by region type and name
PUT POST
DELETE
api/display/{display_uri}
GET GET
api/display/{lat}/{lon}/{radius} ?since={ISO8602-format} api/display/{regiontype}/{regionname} ?since={ISO8602-format}
Display App Store:

Resource App Action Method URI
api/app/{app_uri} api/app/{app_uri} api/app/{app_uri} api/app/{app_uri}
Add new app and set password Modify app-metadata using password Delete app using password Retrieve appmetadate for given app_uri Get all apps or filter by keyword
PUT POST DELETE GET
GET
api/app/[{keyword}]
110
Anhang
A2: Display-App Meta-Daten im XML Format

Display App Metadaten im XML-Format (News App)
<?xml version="1.0" encoding="UTF-8"?> <app> <uri>pdnews.lancs.ac.uk</uri> <type>website</type> <name>PD News</name> <description>Personalisable News for Public Displays</description> <terms><url>http://pdnet1.lancs.ac.uk/pdnews/public/terms.html</url></terms> <provider> <name>PD-NET</name> <email>info@pd-net.org</email> <url>http://pd-net.org</url> </provider> <images> <image> <url>http://pdnet1.lancs.ac.uk/pdnews/public/images/screenshot1.png</url> <title>News on Public Display</title> </image> </images> <metadata-origin-url>http://pdnet1.lancs.ac.uk/pdnews/public/metadata.xml</metadata-origin-url> <api> <display-api> <url>http://pdnet1.lancs.ac.uk/pdnews/public/display</url> <parameters> <parameter name="topics" type="text" required="true" desc="Select preferred news topics"/> </parameters> </display-api> <viewer-api> <url>http://pdnet1.lancs.ac.uk/pdnews/public/mobile</url> <parameters> <parameter name="topics" type="text" required="false" desc="Select preferred news topics"/> </parameters> </viewer-api> <persistent> <url>ws://pdnet1.lancs.ac.uk:1234/pdnews/mobile</url> </persistent> </api> <changed>2012-06-12T07:25Z</changed> </app>
111
Anhang
A3: Display M eta-Daten im XML Format

Display Metadaten im XML-Format
<display> <uri>ecampus-50.lancs.ac.uk</uri> <name>SCC C Floor</name> <owner> <name>Lancaster University</name> <website/> <email>admin@infolab21.lancs.ac.uk</email> </owner> <location> <lat>54.00557848</lat> <lon>-2.78455742</lon> <alt>0</alt> <triggerzone> <radius>15</radius> <view-angle-left>235</view-angle-left> <view-angle-right>359</view-angle-right> </triggerzone> </location> <metadata-origin-url>http://pdnet1.lancs.ac.uk/appplayer/public/display/1/metadata</metadataorigin-url> <viewer-api-url>http://pdnet1.lancs.ac.uk/appplayer/public/mobile/</viewer-api-url> <capabilities> <app-type-support> <type>web</type> <app-type-support> <app-policy>selected</app-policy> <apps> <app> ...APP-Metadata... </app> ... </apps> <presence-token-broadcast enabled="true"/> <direct-interaction enabled="true"/> <bluetooth-identifier-support> <mac-id>00:17:F2:A5:21:F7</mac-id> </bluetooth-identifier-support> </capabilities> </display>
112

Mater Thesis

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Mater Thesis

Hochgeladen von

Copyright:

Verfügbare Formate

Universitt Duisburg - Essen Paluno - The Ruhr Institute for Software Technology Pervasive Computing and User Interface

Thomas Robert Kubitza 2235232

Verwandte Arbeiten ___________________________________________________ 13 Hintergrund __________________________________________________________ 19

4.2 Anforderungen __________________________________________________________ 29

5.3 Erweiterte Architektur ____________________________________________________ 56 5.4 Privacy _________________________________________________________________ 60

6.3 Media Player ____________________________________________________________ 72

7.3 Display App Anwendungsflle ____________________________________________ 94

Zusammenfassung und Ausblick _______________________________________ 101

Literaturverzeichnis ______________________________________________________ 103 Anhang _________________________________________________________________ 109

Kapitel 2 - Verwandte Arbeiten

Kapitel 2 - Verwandte Arbeiten

Kapitel 2 - Verwandte Arbeiten

Kapitel 2 - Verwandte Arbeiten

Kapitel 2 - Verwandte Arbeiten

Kapitel 2 - Verwandte Arbeiten

3.1 Public Displays

3.2 Identifikation von Stakeholdern

3.3 Interaktionsphasen mit Public Displays

Abbildung 2: Interaktions-Phasen mit Public Displays nach Mller et al. [35,29]

z.B. Fraunhofer SHORE: http://www.iis.fraunhofer.de/bf/bsy/produkte/shore/ 21

Abbildung 3: Broadcast von Display-Eigenschaften und Anwendungs-Aufruf

Abbildung 4: Vertrauensbeziehungen zwischen Stakeholdern und Anwendungen

5.2 Basis Architektur

Display Node Display Display Node MediaNode Player

Service Service Directory Directory

Request Display Foreground

Download Database Viewer

Display Display Display Application Application Application

Request Personalisation Mobile App

Display Node Media Player Ads App

Viewer Request : Topic: Sport

Viewer Request : Topic: Sport

Viewer Request : Topic: Sport

Abbildung 6: Display-App Nutzungsflle

Beschrieben mit der Syntax: functionsname(parameter): rckgabe 38

Display Node Media Player

Mobile App User 1

Mobile App User 2

Mobile App User 3

Mobile App User 4

Abbildung 7: Aggregationsstufen von Personalisierungs-Anfragen

Abbildung 8: Mgliche Partitionierung von Display-Flchen bis zu 4 Anzeigebereichen

Abbildung 9: Kreissektoren zur Modellierung von Sichtfeldern bzw. Trigger-Zonen

Identifiers (Bluetooth, NFC, QR-Code)

Proximity and Identifier Sensing [Display Detected] DisplayMetadata

Display App Store

Display App Matching [Display App Available] Display App Parameters

Send Display App Request

Abbildung 10: Flussdiagramm der Prozesse auf der mobilen App

EDGE (EGPRS) GPRS

400 500 ms 600 ms und mehr

Tabelle 6: Roundtrip-Zeiten von Mobilfunk-Technologien7

Display App Host

Display Node mit laufender App

5.3 Erweiterte Architektur

Display Node Media Player

Display App Store

Request Display Foreground / Get Content

Download Display Database Viewer

Register Application Build/Provide Application Provider

Request Personalisation Mobile App Set Preferences

Abbildung 13: Basis-Architektur erweitert um Display App Stores

Pay for Embedding

Buy Apps / Pay for Use

Verwandte Arbeiten _ 13 Hintergrund ________ 19

5.3 Erweiterte Architektur 56 5.4 Privacy _____________ 60

Literaturverzeichnis 103 Anhang ___________ 109