mater thesis

Universität Duisburg - Essen

Paluno - The Ruhr Institute for Software Technology

Pervasive Computing and User Interface Engineering

Entwicklung einer Privatsphäre erhalten-den Architektur für Mobile Interaktion

mit zukünftigen Pervasive Public Display Netzwerken

Masterarbeit

im

Studiengang Angewandte Informatik – Systems Engineering

am Institut für Informatik und Wirtschaftsinformatik

der Universität 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

Entwicklung einer Privatsphäre erhaltenden Architektur für Mobile Interaktion mit Pervasive Public Display Netzwerken II

Eidesstattliche Erklärung

Hiermit versichere ich, dass ich die vorliegende Arbeit ohne Hilfe Dritter und nur

mit den angegebenen Quellen und Hilfsmitteln angefertigt habe. Ich habe alle Stel-

len, die ich aus den Quellen wörtlich oder inhaltlich entnommen habe, als solche

kenntlich gemacht. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prü-

fungsbehörde vorgelegen.

Essen, am 18.06.2012

Entwicklung einer Privatsphäre erhaltenden Architektur für Mobile Interaktion mit Pervasive Public Display Netzwerken III

Danksagung

Diese Arbeit ist speziell meinen Eltern Ursula und Leonhard gewidmet.

Vielen Dank für eure bedingungslose Unterstützung.

Mein Dank gilt auch Nigel Davies und Adrian Friday für die herzliche Gastfreund-

schaft, Unterstützung und Zusammenarbeit an der Lancaster University sowie Alb-

recht Schmidt für die Ermöglichung dieser Erfahrung und das entgegengebrachte

Vertrauen.

Entwicklung einer Privatsphäre erhaltenden Architektur für Mobile Interaktion mit Pervasive Public Display Netzwerken IV

Zusammenfassung

Digitale öffentliche Displays sind bereits allgegenwärtig und ihre Verbreitung in öf-

fentlichen Räumen des Alltags nimmt ständig zu. Aufgrund ihrer häufigen Nutzung

zur einseitigen Informationsverbreitung und ihren oft kontextlosen Inhalten, werden

viele digitale Anzeigeflächen eher ignoriert, anstatt wahrgenommen oder aktiv ge-

nutzt zu werden. Dabei könnten Pervasive Public Display Netzwerke in der Zukunft

als offenes, allgegenwärtiges, interaktives Kommunikation-Medium des 21. Jahr-

hunderts 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 auszuführen, diese zu personalisieren und mit ihnen in Echtzeit per

Mobiltelefon interagieren zu können, potentiell ohne dabei durch die Display-

Infrastruktur identifiziert oder verfolgt werden zu können. Gleichzeitig ist die Archi-

tektur leicht integrierbar, skalierbar, ermöglicht praktikable Inhalts-Kontrolle durch

Display-Verwalter und ermöglicht Drittanbietern die einfache Entwicklung und Pub-

likation von interaktiven Anwendungen für 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 dis-

plays 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 content-

control for display owners as well as easy development and publication of interactive

display apps based on the app store model.

Entwicklung einer Privatsphäre erhaltenden Architektur für Mobile Interaktion mit Pervasive Public Display Netzwerken V

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 Müller 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 Nutzungsfälle __________________________________________ 37

Abbildung 7: Aggregationsstufen von Personalisierungs-Anfragen ____________________ 42

Abbildung 8: Mögliche Partitionierung von Display-Flächen 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-Oberflächen 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 für Geschäftsfälle 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), App-

Policy (rechts) ______________________________________________________________ 76

Abbildung 24: App Player – Aufteilen der Anzeigefläche 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, geöffnetes App-Player Konfig-Menü (r.) 95

Abbildung 30: News App auf Public Display (l.) personalisiert über mobile App (r.) _____ 96

Entwicklung einer Privatsphäre erhaltenden Architektur für Mobile Interaktion mit Pervasive Public Display Netzwerken VI

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

Entwicklung einer Privatsphäre erhaltenden Architektur für Mobile Interaktion mit Pervasive Public Display Netzwerken VII

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, Triggerzonen-

Größe und verwendete Technologie ___________________________________________ 94

Entwicklung einer Privatsphäre erhaltenden Architektur für Mobile Interaktion mit Pervasive Public Display Netzwerken VIII

Inhaltsverzeichnis

Eidesstattliche Erklärung __________________________________________________ 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 Verwandte Arbeiten ___________________________________________________ 13

3 Hintergrund __________________________________________________________ 19

3.1 Public Displays __________________________________________________________ 19

3.2 Identifikation von Stakeholdern ___________________________________________ 20

3.3 Interaktionsphasen mit Public Displays ____________________________________ 21

4 Anforderungen ________________________________________________________ 24

4.1 Nutzungs-Szenarien _____________________________________________________ 24

4.1.1 Szenario 1: Informationen in fremder Umgebung __________________________________ 24 4.1.2 Szenario 2: Einkaufs-Assistent _________________________________________________ 25 4.1.3 Szenario 3: Zeitvertreib und soziale Interaktion __________________________________ 27

4.2 Anforderungen __________________________________________________________ 29

4.2.1 Funktionale Anforderungen ____________________________________________________ 30 4.2.2 Qualitative Anforderungen ____________________________________________________ 31

5 Architektur __________________________________________________________ 32

5.1 Grundkonzept ___________________________________________________________ 32

5.2 Basis Architektur ________________________________________________________ 35

5.2.1 Übersicht ____________________________________________________________________ 35 5.2.2 Display Node ________________________________________________________________ 36 5.2.3 Display App _________________________________________________________________ 36 5.2.4 Media Player _________________________________________________________________ 39 5.2.5 Service Directory _____________________________________________________________ 46 5.2.6 Mobile App __________________________________________________________________ 49

5.3 Erweiterte Architektur ____________________________________________________ 56

5.3.1 Display App Stores ___________________________________________________________ 56

5.4 Privacy _________________________________________________________________ 60

6 Implementierung ______________________________________________________ 63

6.1 Verwendete Technologien ________________________________________________ 63

6.2 Display Apps ____________________________________________________________ 65

6.2.1 Aufbau Web-basierter Display Apps ____________________________________________ 65 6.2.2 App Metadaten _______________________________________________________________ 70 6.2.3 Display App Developer Kit ____________________________________________________ 70

Entwicklung einer Privatsphäre erhaltenden Architektur für Mobile Interaktion mit Pervasive Public Display Netzwerken IX

6.3 Media Player ____________________________________________________________ 72

6.3.1 Web-basierter App-Player als Referenz-Implementierung _________________________ 72 6.3.2 Display Metadaten ___________________________________________________________ 77 6.3.3 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

7 Evaluation ___________________________________________________________ 89

7.1 e-Campus Deployment ___________________________________________________ 89

7.2 Sensing und Aufruf von Display Apps _____________________________________ 90

7.2.1 Verzögerungsfaktoren _________________________________________________________ 90 7.2.2 Netzwerk-Verzögerung ________________________________________________________ 91 7.2.3 Effektivität unter realen Bedingungen ___________________________________________ 92

7.3 Display App Anwendungsfälle ____________________________________________ 94

7.3.1 e-Channel Player App – Dauerhafter Betrieb _____________________________________ 95 7.3.2 News App – Multi-Viewer Personalisierung _____________________________________ 96 7.3.3 Weather App – Anonymisierungs-Ansätze _______________________________________ 97 7.3.4 Ubi-VM App – Mein Desktop verfolgt mich! _____________________________________ 98 7.3.5 Digifieds – Direkte Interaktion ________________________________________________ 100

8 Zusammenfassung und Ausblick _______________________________________ 101

8.1 Zusammenfassung ______________________________________________________ 101

8.2 Ausblick _______________________________________________________________ 102

Literaturverzeichnis ______________________________________________________ 103

Anhang _________________________________________________________________ 109

Kapitel 1 - Einleitung

Entwicklung einer Privatsphäre erhaltenden Architektur für Mobile Interaktion mit Pervasive Public Display Netzwerken 10

1 Einleitung

1.1 Motivation

Große digitale Anzeigeflächen sind heutzutage bereits in bestimmten Umgebungen,

wie z.B. Flughäfen, fester Bestandteil der dortigen Infrastruktur. Viele Flughäfen sind

sogar schon so flächendeckend ausgestattet, dass Bildschirme praktische aus jeder

Position des öffentlichen Flughafengebäudes in Sichtweite sind und auch von Rei-

senden intuitiv genutzt werden. Sinkende Kosten für großformatige digitale Bild-

schirm-Hardware begünstigen nun bereits seit mehreren Jahren deren sichtbare

Ausbreitung auf weitere Bereiche des öffentlichen Lebens, wie z.B. Einkaufstrassen,

Geschäfte, Bars, Haltestellen, Bahnhöfe, Ämter, Universitäten, Firmenflure und viele

mehr. Dabei übernehmen diese öffentlichen Anzeigeflächen (Public Displays) oft die

Aufgaben ihrer statischen Vorgänger, wie z.B. von Beschilderung oder Papier-

basierten Werbepostern und Bannern. Auch in Zukunft ist dabei absehbar, dass die-

ser Trend anhält und öffentliche Räume noch viel stärker als bisher mit digitalen An-

zeigeflächen ausgestattet werden. Trifft die Vision aus Mark Weisers „The Computer

for the 21st Century“ [1] zu, so werden vielen dieser digitalen Anzeigeflächen 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 unterstützen.

Heutige Netzwerke von Public Displays sind zwar oft technisch bereits vollkommen

ausreichend ausgestattet, um diese Vision anzugehen, jedoch basieren die Nut-

zungskonzept der Betreiber der meisten Public Displays lediglich auf unidirektiona-

ler Verbreitung oft Kontext-loser Inhalte, auf die das Publikum dieser Anzeigefläche

keinerlei Einfluss hat. Entgegen der Annahme, dass z.B. digitale Werbeanzeigeflä-

chen in Einkaufsstraßen (z.B. aufgrund ihrer dynamischen Anzeigefähigkeiten) deut-

lich mehr Aufmerksamkeit erhalten müssten als ihre Papier-basierten Vorgänger,

trifft dies in der Tat gar nicht zu [2]. Mit dem kurzfristigen und flächendecken Aus-

tausch von Papierwerbepostern im öffentlichen Raum durch digitale Anzeigeflächen

im Posterformat, wurde zwar die Technologie geändert, jedoch blieben die Inhalten

weitgehen gleich, was in den Köpfen des potentiellen Publikums die Erwartungshal-

tung lediglich statische, uninteressante und nicht auf dessen Kontext angepasste In-

halte vorzufinden, auf die digitalen Anzeigeflächen ü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 Wahrneh-

mung erregen können, z.B. wenn die Inhalte an Produkte angepasst sind, nach denen

Personen in der Nähe gerade suchen.



1.2 Beitrag

Die Vision, zu der diese Arbeit ein Stück beitragen will, ist die Öffnung der weltweit

verteilten Public Display Netzwerke für die Nutzung und Personalisierung durch die

Menschen ihrer Umgebung und somit der Schaffung eines neuen allgegenwärtigen,

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 können, ohne durch die unbekannte, spontan genutzte, Display-Infrastruktur

verfolgbar oder identifizierbar zu sein. Die Integration und Kombination dieser

Funktionalität mit existierenden Public Display Infrastrukturen erfordert dabei kei-

nerlei neue Hardware, wie später 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 auf-

grund fehlender Hardware wie Touch-Panel nur zur unidirektionalen Informations-

verbreitung verwendet werden konnten, plötzlich interaktiv nutzbar.

Inspiriert durch das erfolgreiche Konzept von Apps für Mobiltelefone, wird deswei-

teren dieser Ansatz auf Public Displays übertragen und als vielversprechendes Mittel

zur Bereitstellung individueller, interaktiver und kontextualisierter Inhalte für Public

Displays präsentiert, die durch Personen in der Nähe über ihr Mobiltelefon aufgeru-

fen werden können. Dabei bildet so eine Display App als definierte funktionale Ein-

heit einen Schnittpunkt zwischen den Interessen der Display Nutzer, der Display-

Verwalter und der Display App Anbieter und ermöglicht daher den anonymen Dis-

play Nutzern individuelle Inhalte, den Display-Verwaltern mehr Aufmerksamkeit

auf Anzeigeflächen unter Beibehaltung der Kontrolle durch Vorauswahl von Dis-

play Apps und den Display App Anbietern ein neues innovatives Geschäftsfeld.

Schon einmal haben u.a. Apps die bis dahin für Drittanbieter weitestgehend unzu-

gänglichen Mobiltelefon-Plattformen geöffnet, dabei die Nutzung von Mobiltelefo-

nen revolutioniert und einen wachsenden, Milliarden schweren Markt geschaffen.

Konkret besteht der Beitrag dieser Arbeit zum einen aus der konzeptionellen Ausar-

beitung dieser Architektur und der Beschreibung seiner Komponenten und abstrak-

ten Definition von Schnittstellen und Datenaustauschformaten. Zukünftige Arbeiten

können darauf aufsetzten und unterschiedliche Implementierungen realisieren.

Zum anderen beschreibt diese Arbeit bereits eine vollständige prototypische Imple-

mentierung der konzipierten Architektur sowie die Installation und Evaluation im

Public Display Netzwerk der Lancaster University, England. Mehrere unterschiedli-

che Display Apps konnten in diesem Zusammenhang mit Hilfe eines eigens entwi-

ckelten Display App Developer Kits realisiert werden. Somit wird mit dieser Arbeit be-

reits eine umfangreiche, funktionale Plattform geliefert, die zur weiteren Erforschung

der Praktikabilität und des Designraums dieses Ansatzes dienen kann.



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 Nutzungsfälle präsentiert, um den darauf formulierten funktionalen

und qualitativen Anforderung mehr Hintergrund zu gegeben. Kapitel 5 beschreibt

die entworfene Architektur konzeptionell, indem zunächst die Grundideen vermit-

telt werden und anschließend jede Komponente der Architektur genauer betrachtet

wird. Aufbauend auf dieser Vorarbeit beschreibt Kapitel 6 die konkrete Implemen-

tierung der Komponenten dieser Architektur. Dazu werden zunächst die verwende-

ten Technologien vorgestellt und ihr Einsatz begründet, um im Anschluss die Im-

plementierungs-Lösungen für die einzelnen Komponenten und deren Kommunika-

tion zu präsentieren. Kapitel 7 beschreibt die Integration und Evaluation auf der e-

Campus Public Display Infrastruktur der Lancaster University. Abschließend liefert

Kapitel 8 eine Zusammenfassung sowie die Aussicht auf zukünftige Arbeiten.

Kapitel 2 - Verwandte Arbeiten


2 Verwandte Arbeiten

Der Ursprung der Forschung um Public Displays entspringt eher den semi-

öffentlichen Bereichen, wie z.B. Firmen und Forschungseinrichtungen. Viele frühe

Arbeiten untersuchen deshalb den Einsatz von großen Displays in Büroumgebungen

als Kommunikationsmedium und zur Unterstützung der Kollaboration ihrer Mitar-

beiter oder der Anreicherung der Umgebungen mit kontextualisierten Daten, die

ohne Display nicht sichtbar wären. Durch die wachsende Verbreitung von digitalen

Anzeigeflächen in der Öffentlichkeit, sowie der steigenden Zahl von Interaktions-

Arten, eröffnen sich zudem ganz neue, interaktive Anwendung-Möglichkeiten, Her-

ausforderungen und somit auch Forschungsfelder.

Verwandte Arbeiten aus einigen Bereichen, die für diese Arbeit hohe Relevanz ha-

ben, werden im Folgenden vorgestellt. Eine besondere Betrachtung des speziellen

Interaktionsmodells von Public Displays und dessen verwandten Arbeiten wird da-

gegen im darauffolgenden Kapitel durchgeführt.

Implizite Interaktion

Implizite Interaktion zwischen Personen und Public Displays findet statt, wenn Dis-

plays, meistens mit Hilfe von Sensoren, die Präsenz von Personen wahrnehmen kön-

nen und darauf basierend ihre Anzeige anpassen, ohne dass das der Personen be-

wusst ist. Dabei kann man Ansätze unterscheiden, die lediglich anonym feststellen,

ob Personen präsent sind oder nicht, sowie Ansätze, die Personen in der Nähe ein-

deutig identifizieren können. So nutzt Pantic [4] Bildschirme mit Gesichtserkennung

um nicht nur die Präsenz von Personen festzustellen, sondern ebenso, um deren Ge-

sichtsausdruck und damit ggf. emotionale Reaktionen auf die angezeigten Inhalte

festzustellen, und diese dadurch implizit zu markieren (implizit human centered

tagging). Mit Reflective Signs nutzen Müller et al. [5] einen ähnlichen Ansatz. Mit Hil-

fe von Gesichtserkennungs-Software stellen sie fest, ob und wie lange vorbeigehende

Personen auf angezeigte Inhalte schauen, um auf Basis dieser Daten die Zusammen-

stellung und Anzeigedauer der Inhalte zu beeinflussen. Die Hello.Wall [6] nutzt da-

gegen Short-Range-Transponder Technologie um Personen in dessen Umgebung,

aufgeteilt in drei Zonen wahrnehmen zu können und seine Anzeige auf unaufdring-

liche Art (Ambient) anzupassen. FunSquare [7], eine Applikation für Public Dis-

plays, nutzt verschiedene Sensor-Quellen der Umgebung, z.B. Bluetooth-Scans oder

Temperaturdaten um periodisch neu generierten Inhalte zu erzeugen. So hat die rei-

ne Zahl der in der Umgebung gescannten Bluetooth Geräte bereits Einfluss auf den

angezeigten Inhalt. Ein frühes System, dass Nutzer auf Basis von Infrarot-Badges in

der Nähe von Public Displays in verschiedenen Büroumgebungen identifiziert und

deren Inhalte adaptiert, präsentieren McCarthy et al. [8] mit Uni/Out/GroupCast.

Bluetooth ist jedoch die populärste Technologie zur Identifikation von Personen

(bzw. derer Telefone) in der direkten Umgebung eines Public Displays. Zwei unter-

schiedliche Ansätze lassen feststellen. Cardoso und José [9] präsentieren ein System,



bei dem Nutzer zunächst zentral gespeicherte Profile anlegen und Interessen äußern

müssen, die dann mit ihrer Bluetooth-MAC-Adresse verknüpft werden, um die In-

halte auf Public Displays dementsprechend anzupassen, sobald die Mobiletelefone

der Nutzer per Bluetooth gescannt werden. Alt et al. [10] nutzen ebenso Bluetooth-

MAC-Adressen für die automatische adaptive Generierung anonymer Benutzerprofi-

le zur Ermöglichung von gezielterer Werbung auf digitalen Werbeanzeigen. Der an-

dere häufig verwendete Ansatz nutzt dagegen Bluetooth Geräte Namen um darin

Informationen, wie z.B. Benutzer Präferenzen an die Umgebung mitzuteilen. Ribeiro

et al. [11,12] nutzen diese Methode, um Inhalte auf Public Displays mit Hilfe von

Schlüsselwörtern fortlaufend automatisch an die Präferenzen der Nutzer in der Um-

gebung anzupassen. Der Gleiche Ansatz wird von Villar et al. [13] verwendet (jedoch

per RF-Technologie) um mit Hilfe eines kleinen tragbaren Gerätes (Pendle) vorher

definierte Interessen auf Basis von Keywords an die Umgebung zu senden und In-

halte auf Bildschirmen implizit anzupassen. Davies et al. [14] nutzen Bluetooth-

Gerätenamen um diverse Dienste auf Public Displays gezielt aufzurufen. Einen

Kombinierte Nutzung von Bluetooth-MAC-Adressen zur Identifizierung und Gerä-

tenamen zum übermitteln von Anweisungen verwenden José et al. in ihrem Instant

Places System [15]. Alle vorgestellten Bluetooth-basierten Ansätze bringen jedoch

gewisse Privacy-Probleme mit sich. Zum einen muss ein Nutzer sein Gerät ständig

im „Discoverable“ Modus betreiben und ist somit nicht nur von den gezielt genutz-

ten Systemen, sondern praktisch jedem in der Nähe detektierbar. Zum anderen muss

er, falls er seine Präferenzen äußern möchte, diese an die gesamte Umgebung preis-

geben (z.B. per Gerätename) oder diese zuvor auf Basis eines Profils an mindestens

eine dritte Partei übermitteln.

Expl izite Interaktion

Direkte, bewusste Interaktion von Personen mit Public Displays kann auf unter-

schiedlichste Weise und mit Hilfe verschiedenster Technologien realisiert werden.

Mit Hilfe einer am Public Display angebrachten Kamera zum Beispiel wird das Dis-

play eines Mobiltelefons in der Hand der davorstehenden Person verfolgt und zur

Bewegung einer Cursors auf der großen Anzeigefläche verwendet [16]. Auf gleiche

Weise nutzen Vogel et al. [17] Marker angebracht an eine Hand, um diese zu verfol-

gen und Gesten zu interpretieren. Nawaz. et al. [18] schlagen vor, große Bildschirme

mit einer Kombination aus Blick-Verfolgung und Gesten-Erkennung zu steuern.

Müller et al.[19] verwenden Microsofts Kinect-Sensor um Personen mit einem Public

Display in einem Schaufenster interagieren zu lassen. Auch Laserpointer in Verbin-

dung mit Kamera-Bildverarbeitung werden zur Steuerung verwendet [20]. Mit Point

& Shoot [21] wird die Kamera eines Mobiltelefons genutzt um zunächst ein ge-

wünschtes Objekt auf einem großen Bildschirm zu fokussieren und abzudrücken.

Daraufhin wird ein Gitter von 2D-Codes kurzzeitig auf dem Public Display einge-

blendet, das die Feststellung der absoluten Position erlaubt. Mit Sweep ermöglichen

die gleichen Autoren eine Steuerung des Cursors auf Public Displays mit Hilfe eines

Mobiltelefons, das seine Kamera als optischen Maussensor nutzt, welches nicht ein-



mal in die Richtung des Bildschirms zeigen muss. Auf Basis einer RFID-Tag-Matrix,

die hinter den Bildschirm geklebt wird, kann ein NFC-fähiges Mobiltelefon zur di-

rekten 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 Beschleu-

nigungssensoren und Bluetooth um sich mit eine großen Public Display zu verbin-

den und darauf ein Multiplayer Rennspiel zu steuern (analog zur Nintendo Wii Con-

trollern). Bei einem ähnlichen Ansatz zu Unterstützung der gleichzeitigen Interakti-

on mehrerer Mobilegeräte-Nutzer mit Public Displays, nutzen Leikas et al. [24]

drahtlose Datenverbindungen zur Kommunikation. Ist einem Nutzer bewusst, dass

er alleine durch seine Präsenz in der Nähe von Public Displays bestimmte Aktionen

auslöst, 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 großen Displays zu un-

terstützen. Dazu zeigt ihr proaktives System z.B. das Profil eines Teilnehmers für alle

sichtbar an, sobald dieser zum Mikrofon kommt (AutoSpeakerID), sowie die (ge-

meinsamen) Interessen von Personen, die sich in Wartebereichen aufhalten (Ti-

cket2Talk 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 Gerätenamen, können diese auch zur

expliziten Interaktion eingesetzt werden [14,15]. Ebenso können 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

Berührung, ermöglicht entweder durch eine kapazitative Schicht über der Anzeige-

fläche oder durch einen Infrarot-Rahmen. Abhängig von Technologie, Treiber und

Betriebssystem des Public Display Rechners, können solche Touch-Panel entweder

nur per Single-Touch von einem Nutzer oder per Multi-Touch von einem oder meh-

reren Nutzern gleichzeitig bedient werden. Peltonen et al. [26] nutzen z.B zum Be-

trieb ihrer CityWall, ein großes interaktiven Multi-Touch Display, dass in seiner städ-

tischen Umgebung von einer Vielzahl von Personen gleichzeitig bedient werden

kann. Schließlich kommen auch noch physikalische Knöpfe 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, basie-

rend auf der Interaktionsart und dem verwendeten mentalen Model der Display

Anwendung, sowie die Eingliederung einiger verwandter Arbeiten. Die blau mar-

kierten Bereiche stellen dabei die Eingliederung dieser Arbeit dar, welche sowohl

implizite Interaktion über Präsenzerkennung, also auch ferngesteuerte Interaktion

über Mobilgeräte (ggf. auch per Gesten) erlaubt. Mit Hilfe der abstrakten Idee von

Display Apps können dabei praktisch alle mentalen Modelle realisiert werden.



Abbildung 1: Taxonomie von Public Displays (aus [29]) und Eingliederung der fokussierten Interakti-

onsarten in dieser Arbeit (blau)

Architekturen und Middleware

Unterschiedliche Architekturen und Middleware existieren für Public Display Netz-

werke, welche z.B. die Inhaltsverbreitung steuern, Ereignisse und Nachrichten

übermitteln, Interaktion steuern oder externe (mobile) Geräte zur Steuerung oder als

privates Display einbinden.

Mit MAGIC Broker [30] schlagen Erbad et al. ein Middleware Toolkit für 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. Mobiletele-

fone mit Browser können nun über Client-Webseiten Befehle und Inhalte an denjeni-

gen Channel schicken, der von dem Public Display abonniert wird, mit dem ein Nut-

zer interagieren will. Ein Display-Client nutzt dabei Polling um den Server regelmä-

ßig auf neue Nachrichten zu prüfen. Das MAGIC Broker System ist durch die Ver-

wendung von HTTP als Transportprotokoll und der Implementierung einer RESTful

API zusammen mit seinem hierarchischen Channel System ein sehr allgemeines, ein-

fach nutzbares System zur asynchronen Nachrichtenübermittlung, insbesondere

nicht nur in Zusammenhang mit Public Displays. Sein zentralisierter Ansatz skaliert

jedoch nicht, insbesondere bei größeren Mengen Clients die Polling verwenden.

Mit Distributed User Interfaces (DUIs) stellen Hosio et al. [31] ein System zur Erwei-

terung von Web-basierten Public Display Anwendungen um mobile, auf J2ME basie-

rende, private Benutzerschnittstellen vor. Mit Hilfe einer J2ME-Service Discovery

Anwendung für mobile Geräte kann ein Nutzer Anwendungen auf Public Displays

starten und falls diese ein mobiles UI anbieten, diese Anwendung auf dem Public



Display über die mobile UI steuern und ggf. private Informationen der Anwendun-

gen auf dem mobilen Gerät anzeigen. Eine Display Anwendung muss schon zur De-

signzeit für diese verteilte Form von UIs vorbereitet werden und kann dann entwe-

der maximal einem Nutzer gleichzeitig Zugang geben (privater Modus), oder mehre-

ren mobilen Usern gleichzeitig (Community Modus). Zudem sind mehrere Kombina-

tionen der Steuerung über die interaktive Public Display Oberfläche und die mobile

UI gleichzeitig oder jeweils getrennt möglich. Public Display Anwendungen ver-

wenden dabei Metadaten, um zu kommunizieren, ob und welcher Art der mobile

Benutzerschnittstelle sie unterstützen. Zur Identifikation vor welchem Public Display

sich ein mobiler Nutzer befindet, muss das Mobiltelefon vor den RFID-Leser der

Public Displays gehalten werden. Anschließend kann ein Nutzer auf dem mobilen

Gerät über eine Art mobile Service-Layer App (UBI-mobile) verfügbare Anwendun-

gen aufrufen, und ein s.g. Lease anfordern. Hat ein Public Display gerade bereits ein

Lease eines anderen mobilen Nutzers und unterstützt die ausgeführte 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 vorgestell-

te Implementierung basiert bereits auf Web-basierten Public Display Apps, die mit

Hilfe von Metadaten beschrieben und mit mobilen UIs ergänzt werden können. Ein

großer Nachteil liegt jedoch in der Verwendung von mobilen J2ME Anwendungen,

die speziell für jede Public Display Applikation entwickelt werden müssen. Da zur

Wahrnehmung der Präsenz eines Public Displays (bzw. in diesem Fall der Wahr-

nehmung von Nutzern durch Public Displays) ein Nutzer erst das Telefon in die Nä-

he des RFID-Readers halten muss, ist lediglich explizite Interaktion auf Basis dieser

Plattform realisierbar. Insgesamt bietet diese Plattform zwar die sehr interessante

Funktionalität Public Display Anwendungen um private mobile UI zu erweitern,

allerdings scheitert die praktisch Implementierung an fehlender Flexibilität und ein-

facher Nutzbarkeit durch gewöhnliche Endnutzer.

Storz et al. [32] präsentieren mit e-Campus ein System zur Steuerung und Inhaltver-

breitung einer verteilten Public Display Infrastruktur auf dem Campus der Lancaster

Universität in England. Die dortige Infrastruktur besteht dabei aus etwa 25 LCD

Bildschirmen die an populären Plätzen des Campus angebracht sind. Da die Public

Displays keine direkte Eingabe unterstützen, werden sie überwiegend zur Verbrei-

tung von multimedialen Campus-Informationen verwendet. Das System zur Inhalts-

Verbreitung teilt sich dabei in zwei Schichten. Über eine API kann eine Low-Level-

Schicht die Basis-Steuerung von einzelnen oder ganzen Gruppen von Displays trans-

aktionsorientiert übernehmen. Als Basis-Befehle kann eine abstrakte Anwendung

(welche für die Darstellung ihrer Inhalte zuständig ist) gestartet, gestoppt, paramet-

risiert 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 Publikati-

onsmodelle wie z.B. Publish/Subscribe unterstützt. Auf dieser Low-Level-Schicht

können nun komplexere, Domänen-abhängige 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 verschie-

denen 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 können. Somit

können Display Verwalter bequem gewünschte Inhalte durch die Verschachtelung

von abonnierten Inhalten auf ihren Displays anzeigen lassen. Die e-Campus Platt-

form ist durch ihre 2-Schichten Struktur flexibel einsetzbar. Verschiedene Inhalte be-

nötigen jedoch auf der Low-Level-Schicht unterschiedliche Anwendungen bzw.

Renderer um diese anzeigen zu können.

Ein System zur zeitlich und räumlich verteilten Verwaltung von interaktiven Web-

basierten Public Display Applikationen stellen Linden et al. [33] vor. Diese Middle-

ware 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 Un-

terstützung interaktiver Inhalte wird auf Web-basierte Anwendungen gesetzt. Ein

s.g. Layout-Manager, welcher selbst als Web-basierte Anwendung, die im Vollbild-

Modus eines Firefox-Browsers läuft, implementiert wurde, teilt dabei die verfügbare

Anzeige-Oberfläche 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 können. Über ein dauerhaft erreichbares Menü

im unteren Bereich, können Nutzer von Public Displays gezielt verfügbare Anwen-

dungen aufrufen, sowie u.a. die Anzeigesprache ändern. Die verwendeten Web-

Anwendungen 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 gewählten Anzeigesprache usw. versorgt. Der Layout-

Manager speichert dabei persistent den Zustand der Oberfläche und kommuniziert

fortlaufend über ein Web-Interface mit einem Ressourcen-Manager, der für die Ver-

teilung von Inhalten, die z.B. im Idle-Mode des Displays wiedergegeben werden sol-

len, zuständig ist. Das von Linden et al. nun bereits seit mehr als 3 Jahre auf einer

öffentlichen Infrastruktur von interaktiven Public Displays eingesetzte System, de-

monstriert die Mächtigkeit und Flexibilität von reinen Web-Anwendungen auch für

den Langzeitbetrieb.

Dieser Ansatz zusammen mit dem Nachweis seiner Praktikabilität stellt u.a. eine we-

sentliche Inspiration für die Implementierung der Architektur dieser Arbeit dar.

Kapitel 4 - Anforderungen


3 Hintergrund

Dieses Kapitel untersucht zunächst Merkmale von Public Displays, identifiziert und

benennt Interessengruppen für die spätere Verwendung und stellt das besondere

Interaktionsmodell von Public Displays vor.

3.1 Public Displays

Digitale Bildschirme sind immer in einen Kontext eingebettet. Dieser kann zunächst

grob als öffentlich (public), semi-öffentlich (semi-public) oder privat (private) kategori-

siert werden. Bildschirme in öffentlichen Umgebungen sind prinzipiell durch jeden

zugänglich. Oft bedürfen sie dazu jedoch auch einer speziellen Robustheit gegen

Wettereinflüsse und Demolierung. Semi-Public Displays befinden sich dagegen in

Bereichen die nicht jedem zugänglich sind und werden dadurch meistens nur durch

bestimmte Gruppen wahrgenommen (z.B. Mitarbeiter in Firmenfluren). Private Dis-

plays 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 Nähe dieser Displays befinden, gar keine

Einfluss auf deren Aufstellungsort, Zweck oder Inhalt, obwohl sie als potentielle In-

formationskonsumenten die primäre Zielgruppen sind. Interaktive Anwendungen

und implizite und explizite Interaktionstechnologien für Public Displays beginnen

jedoch dieses Prinzip aufzuweichen. Im weiteren Verlauf dieser Arbeit sollen die Be-

griffe 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, Zügen oder auch auf Menschen [34]. Desweiteren können

Bildschirm auf verschiedenen Technologien bestehen (z.B. LCD/Plasma-

Flachbildschirme, Projektoren, LED-Anzeigen) sowie verschiedene Größen,

Geometrien (eben rechteckige und zylindrische Anzeigen, Bänder, freiförmige Pro-

jektionen) 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 Sicht-

barkeit zu ermöglichen, jedoch gleichzeitig z.B. Interaktionsmöglichkeiten ein-

schränken (z.B. nicht mehr berührbar). Poster-formatige, Touch-basierte Displays,

die z.B. bis zum Boden reichen, würde dagegen potentiell nur in Sichthöhe und Be-

rührungs-Reichweite genutzt. Format, Geometrie, Größe, Lage, Umgebung und ggf.

auch Wetter bestimmen schließlich das Sichtfeld von Bildschirmen. Bei ebenen An-

zeigen lässt sich dieses aus Vogelperspektive z.B. oft grob als Kreissektor (mit Win-

keln < 180°) annähern, bei zylindrische Displays als Ringfläche. Die Sichtweite und

Interpretierbarkeit ist dagegen u.a. von Displaygröße, Helligkeit, Kontrast und In-

haltsgröße abhängig. Schließlich sind Public Displays jedes Mal in einem völlig indi-



viduellen Kontext eingebettet, der potentiell einen enormen Einfluss auf die Wahr-

nehmung ihrer Inhalte hat.

3.2 Identifikation von Stakeholdern

Mehrere Interessengruppen (Stakeholder) können im Kontext von Public Display

Netzwerken identifiziert werden. Diese werden im Folgenden beschrieben und be-

nannt, um im weiteren Verlauf dieser Arbeit eindeutig referenziert werden zu kön-

nen.

Display Owner

Die Interessengruppe der Display Owner fasst Besitzer von Bildschirmflächen sowie

deren Verwalter zusammen. Dazu zählen z.B. Ladenbesitzer mit einem einzigen öf-

fentlichen Display in ihrer Vitrine bis hin zu Verwaltern von Netzwerken mit mögli-

cherweise hunderten von Displays an verschiedenen Standorten wie z.B. in Shop-

ping-Malls. Display Owner sind für den Betrieb und die Wartung ihrer Infrastruktur

zuständig. Sie sind daran interessiert, ihre Display-Flächen mit Inhalten zu füllen, die

von Personen in ihrer Umgebung (Viewer) wahrgenommen werden sollen. Diese In-

halte können dazu dienen eigene Zwecke zu verfolgen (z.B. Eigenwerbung, Reisein-

formationen 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 ge-

nannt. Heutige kommerzielle Content Provider sind zumeist Werbeagenturen

(Advertiser), die im Namen ihrer Auftraggeber Produktanzeigen mit Hilfe der Infra-

struktur von Display Ownern schalten. Weiterhin sind bereits oft öffentliche Display-

flächen zu beobachten, die eine Mixtur aus allgemeinen Informationen (wie Schlag-

zeilen, Wetter, usw.) und Werbung anbieten. Dies deutet an, dass reine Werbeanzei-

gen im öffentlichen Raum (insbesondere in Wartebereichen) weniger Aufmerksam-

keit erhalten, als in einer Kombination mit „Infotainment“, und dies obwohl sie ef-

fektiv weniger Anzeigezeit erhalten. Die Anbieter dieser für Public Displays opti-

mierten Kombination aus Information/Entertainment und Werbung kommen bereits

jener Interessengruppe sehr nahe, die in dieser Arbeit als Application Provider be-

zeichnet wird. Application Provider bieten Inhalte speziell für Public Displays an,

die von völlig statischen Inhalten bis hin zu komplexen interaktiven Anwendungen

reichen können. Diese Anwendungen (Display Apps) können auch Inhalte von

Advertisern (ggf. Kontext-basiert) einbetten und werden gewöhnlich über die Dis-

play Infrastruktur von Display Ownern aufgerufen.



Viewer

Als Viewer sollen schließlich diejenigen Personen bezeichnet werden, die sich entwe-

der einfach nur unbewusst im Sichtfeld von Public Displays befinden, die Inhalte

von Public Displays auf irgendeine Weise wahrnehmen oder sogar mit Public Dis-

plays interagieren. Viewer sind die primären Nutzer von Public Displays und Kon-

sumenten ihrer Inhalte. Sie stehen dabei in keinerlei Besitz oder Nutzungsrecht zu

diesen Anzeigeflächen und sind sich oft gar nicht der „Nutzung“, also des (unterbe-

wussten) Informationskonsums, bewusst. Dieses komplexere Interaktionsmodell von

Viewern mit Public Displays im öffentlichen Raum wird daher im nächsten Ab-

schnitt 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

Müller [35,29]. Um von einer Phase zur nächsten zu gelangen, muss immer erst eine

gewisse Schwelle überschritten werden. Mit Hilfe von Transitionsquoten können

diese messbar, berechenbar und vergleichbar gemacht werden.

In Phase 1 passiert eine Person ein Public Display ohne es zunächst 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, könnte Bildschirminhalte beim vorbeigehen einer Person z.B. an des-

sen Geschlecht, geschätztes Alter und Gesichtsausdruck anpassen. Diese Interaktion

ist ggf. von der Person ungewollt und der Effekt wird möglicherweise von dieser gar

nicht wahrgenommen. Trotzdem hat die Person den Inhalt in diesem Fall bereits be-

einflusst.

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

Um die Schwelle in die zweite Phase zu überqueren, in der die Person auf das Dis-

play sieht und ggf. reagiert, muss zunächst die Aufmerksamkeit der Person gewon-

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



nen werden. Dabei wirken bestimmte Inhalte wie z.B. bewegte und bunte Inhalte [2]

allgemein anziehender. An dieser Stelle ist es möglich, dass eine Person z.B. Inhalte

nur kurz ansieht und ohne sichtbare Reaktion weitergeht. Im Allgemeinen kann be-

reits an der Dauer des Blickes die Stärke des Interesses erkannt werden. Mit

ReflectiveSigns stellen Müller et al.[5] z.B. ein System vor, dass Dauer und Reihenfolge

von Inhalten auf Public Displays fortlaufend auf Basis von Blickdauern vorbeilau-

fender Personen anpasst.

Die dritte Phase umfasst subtile Interaktion insbesondere durch Gesten und wird

nur unterstützt, falls das Public Displays diese interpretieren kann. Zunächst muss

jedoch die Neugier einer Person geweckt werden. Beim Looking Glass [19], einer in-

teraktiven Public Display Anwendung die das Bild bzw. die Silhouette von Passan-

ten wiedergibt, um deren Aufmerksamkeit zu erlangen und virtuelle Overlays zu

bewegen, wurde beobachtet wie Personen im Vorbeilaufen auf die Interaktivität

(und ihr Spiegelbild) aufmerksam werden, stehen bleiben und noch einmal zurück-

kommen (landing effect) um den Effekt verschiedener Gesten auszuprobieren. Gesten-

basierte Interaktion weckt häufig auch die Aufmerksamkeit anderer Passanten auf

sich und führt regelmäßig zur Anhäufung von Menschengruppen (honeypot effect).

Direkte Interaktion mit dem Display durch Berührung wird durch die 4. Phase re-

präsentiert. Auch hier muss eine Person neugierig werden und sich dem Display nä-

hern um mit der Interaktion beginnen zu können. Ein häufiges Problem ist, dass Per-

sonen Touch-basierte Public Displays meistens nicht für interaktiv halten. Dies liegt

zumeist an der (berechtigten) Erwartungshaltung, dass Public Displays ein reiner

Ersatz für traditionelle Papier-basierte Poster sind. Dabei spielt der Kontext in der

sich eine Person befindet, ein große Rolle - von einem großen Display in einer Biblio-

thek oder einem Museum wird eher Interaktivität erwartet, als von einer digitalen

Werbetafel in einer Einkaufsstraße. Somit muss oft erst auf diese Funktionalität hin-

gewiesen werden (z.B. durch „Touch the Screen“ Aufforderungen). Bei manchen

Displays scheidet direkte Interaktion jedoch schon dadurch aus, dass sie einfach

nicht per Berührung zugänglich sind, wie z.B. auf größerer Höhe oder auf der ande-

ren Seite der Gleise in U-Bahnstationen.

Mehrfache Interaktion kann schließlich stattfinden wenn, z.B. mehrere Bildschirme

vorhanden sind oder Nutzer nach einer Pause wiederkehren um die Interaktion fort-

zuführen. Schließlich umfasst die letzte Phase mögliche Folgeaktivitäten die klar auf

die Interaktion mit Public Displays zurückzuführen sind. Die könnte z.B. das einlö-

sen eines per QR-Code eingescannten Coupons sein [36] oder auch das Fotografiert

werden vor den Displays. Wichtige für eine längere 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 statt-

findet und Personen sich oft anders benehmen oder sich nicht trauen, z.B. aus Angst

sich zu blamieren.



Einflüsse vorausgehender Situationen

Bevor eine eigentliche Interaktion mit Public Display erfolgen kann, befindet sich

eine Person jedoch immer schon in einer individuellen Situation, die großen Einfluss

auf die eigentliche (bevorstehende) Interaktion mit Public Display haben kann. Eini-

ge davon können wie folgt beschrieben werden:

Wartesituationen: Bereiche in denen regelmäßig Wartesituationen stattfinden

sind aus Sicht von Display Ownern besonders interessante Orte für Public

Displays. Displays in solchen Situationen erhalten daher eine vergleichsweise

sehr lange und häufige Aufmerksamkeit ihrer Betrachter. Gleichzeitig laufen

diese Bildschirme auch Gefahr die Aufmerksamkeit ihres Publikums dauer-

haft zu verlieren [2], falls sie nicht fortlaufend deren Aufmerksamkeit binden

können.

Pass-By Situationen: Typische Pass-By Situationen finden z.B. in Einkaufs-

trassen mit digitalen Werbeanzeigen statt. Personen, die an diesen Public Dis-

plays vorgehen, haben zumeist einen inneren Zustand, der zwischen Freizeit-

auslebung und zielgetriebener Verfolgung von Aufgaben liegt. Letzterer hat

die Konsequenz, dass diese Personen mit einer besonders starken selektiven

Wahrnehmung durch die Straßen laufen, und daher meistens nur auf be-

stimmte Reize reagieren.

Gezielte Nutzung: Bei der gezielten Nutzung sind sich Personen bereits über

die Fähigkeiten 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 nächsten Kapitel und

werden dort deshalb gründlicher diskutiert.



4 Anforderungen

In diesem Kapitel werden funktionale und qualitative Anforderungen für eine Archi-

tektur formuliert, die die anonyme implizite und explizite Ad-hoc Interaktion mit

unbekannten Public Displays über das Mobilgerät von Viewern ermöglichen soll.

Um diesen Anforderungen mehr Hintergrund zu geben, werden im Folgenden drei

Szenarien verwendet.

4.1 Nutzungs-Szenarien

Im Folgenden werden verschiedene Nutzungsfälle in Form von Szenarien vorge-

stellt, die die Vision von offenen, globalen Pervasive Public Display Netzwerken mo-

tivieren sollen, die auf Basis von individuellen Anwendungen für Public Displays

(Display Apps) durch Viewer in der Nähe implizit oder explizit genutzt und persona-

lisiert werden können.

4.1.1 Szenario 1: Informationen in fremder Umgebung

Achim ist Rentner und reist gerne. Er ist besonderes an Architektur und Geschichte interes-

siert und freut sich deshalb umso mehr an diesem Wochenende zum ersten Mal Barcelona zu

besichtigen. Er mag es, einfach durch Städte zu spazieren und diese selbständig 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 ak-

tiviert der dazu einfach eine App auf seinem Smartphone, wählt aus, dass er an Informatio-

nen über Geschichte und Architektur interessiert ist und steckt das Telefon wieder in seine

Tasche. Während er durch die Stadt spaziert und interessiert die Architektur betrachtet, läuft

er gleichzeitig auch regelmäßig an Public Displays im Kioskformat vorbei, die verschiedene

Inhalte, jedoch zumeist Werbung anzeigen. Sobald sich Achim jedoch in die Nähe eines dieser

Anzeigen begibt, wird der Displayinhalt aufgeteilt. In der unteren Hälfte wird weiterhin

Werbung angezeigt, in der oberen Hälfte jedoch Informationen in deutscher Sprache zur Ge-

schichte und Architektur der direkt umliegenden Gebäude sowie eine kleine Karte mit dem

aktuellen Standort. Achim gefällt es diese Informationen in seiner Landesprache und direkt

im Kontext der Gebäude zu erfahren. Auch wenn an vielen Gebäuden Informationstafeln an-

gebracht sind, so ist sein Spanisch nicht gut genug um diese zu verstehen. Er weiß, dass er

ähnliche Informationen auch direkt auf seinem Smartphone finden könnte, jedoch mag er es

nicht besonders mit dem Handy in der Hand und der Lesebrille auf dem Kopf durch die Stra-

ßen zu laufen und sich auf die Bedienung fokussieren zu müssen, anstatt die Umgebung ent-

spannt auf sich wirken zu lassen. Achim möchte noch so einige Ecken sehen, bekommt jedoch

langsam Hunger. Er ist nun schon an einigen Restaurants vorbeigegangen. Um mehr Infor-

mationen 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 nächsten Public Displays werden Ihm nun zusätzlich

Informationen zur Restaurants in der direkten Umgebung angezeigt. Während er gerade auf

ein weiteres Public Display an einer Bushaltestelle zuläuft, bemerkt Achim ein kleines sympa-



thisch wirkendes Lokal auf der anderen Straßenseite. Auf dem Public Display findet er es

ebenfalls wieder und erfährt, dass es anscheinend erstklassige einheimische Küche zu guten

Preisen bietet und von einer Vielzahl von Personen positiv bewertet wurde. Genau das, wo-

rauf Achim gerade Lust hat.

Szenario 1 ist insbesondere ein Beispiel für die Nützlichkeit gezielter (Mit-)Nutzung

öffentlicher Display Infrastrukturen für individuelle Zwecke. Achim ist diese Mög-

lichkeit bewusst, weshalb er sich digitalen Public Displays jedes Mal gezielt nähert

wenn er Informationen über Architektur und Geschichte seiner direkten Umgebung

erfahren möchte. Den Wunsch genau diese Informationen zu erhalten hat Achim im

Voraus mit Hilfe seines Smartphones geäußert. Dieses behält er fast die ganze Zeit in

seiner Tasche und nutzt es nur um ggf. Präferenzen zu ändern. Er empfindet es als

störend und umständlich die gewünschten Informationen ständig von seinem klei-

nen Display abzulesen. Stattdessen erhält er automatisch gewünschte Informationen

auf Public Displays über den Kontext, in dem er sich gerade befindet sobald er sich

diesen Displays nähert. Dabei deutet das Szenario bereits eine mögliche gemischte

Nutzung der Public Display Flächen an, bei dem entweder die gesamte Fläche z.B.

für Werbung o.ä. genutzt wird oder ein Teil der Bildschirmfläche für personalisierte

Inhalte genutzt werden kann, welche wieder ausgeblendet werden sobald der Nut-

zer nicht mehr in der Nähe ist. Insbesondere für Städte mit viel Tourismus könnte

solch eine Mischnutzung öffentlicher Display-Strukturen zur Unterstützung ver-

schiedenster lokalisierter Informationen sehr attraktiv sein. Eigene Informationsdis-

plays oder mehrsprachige statische Beschilderungen könnten so eingespart werden.

Die Idee von offenen, globalen Public Display Netzwerken erlauben es Achim in die-

sem 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 zu-

nächst vom Ort ihrer Anzeige und Nutzung unabhängig. So nutzt Achim später zu-

sätzlich zu der Tourismus-Anwendung auch eine weitere Public Display Anwen-

dung zum Anzeigen von Restaurantinformationen in Verbindung mit Kundenbe-

wertungen und Kommentaren. Sämtlich für Public Displays angebotenen Anwen-

dungen können und sollten sich dabei an den Kontext des Public Displays sowie an

die vom Nutzer zur Verfügung gestellten Angaben anpassen (z.B. an die Sprache).

4.1.2 Szenario 2: Einkaufs-Assistent

Anja ist auf dem Weg in eine große Shopping-Mall um ein neues Sommerkleid für 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 Geschäfte

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 Ein-

kaufsstraßen der Innenstadt gemacht. In der Shopping-Mall hat sie bereits einige Geschäfte

im Sinn, die sie auf jeden Fall besuchen möchte. Auf dem Weg zum ersten Laden ihrer geisti-



gen Liste achtet sie bereits auf die doppelseitigen Public Displays im Kioskformat, die auf je-

der Etage etwa alle 10 Meter zu finden sind und auf einigen sieht sie bereits rote und weiße

Sommerkleider während sie auf die Displays zugeht. Vor dem Display, welches fast vor dem

Geschäft steht, das sie gesucht hat, bleibt sie schließlich stehen und schaut sich eine Auswahl

von Sommerkleidern dieses Geschäftes an. Per Berührung klickt sie sich durch die Bilderliste

bis sie schließlich ein Kleid entdeckt, dass ihr gefällt und welches sie zunächst in Vollbilddar-

stellung betrachtet. Anja möchte sich das Kleid genauer ansehen und betritt den Laden um es

zu suchen und ggf. anzuprobieren. Enttäuscht verlässt sie wenige Minuten später das Ge-

schäft, 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 Vorstel-

lungen entspricht. Sie nähert 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 Geschäft 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 fällt ihr auf einem Public Display schon wieder ein Rot-

Weißes Sommerkleid ins Auge, welches von verschiedenen passenden Schuhen und Acces-

soires 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 gegenüber lie-

gende Geschäft.

Dieses Szenario behandelt die typische „Pass-By“ Situation an Public Displays, wie

z.B. in Einkaufsstraßen. Passanten in Einkaufstrassen haben meistens eine konkrete

Aufgabe im Kopf, der sie fokussiert nachgehen (z.B. rot-weißes Sommerkleid suchen)

oder sie sind weniger Ziel getrieben und vertreiben sich z.B. mit Shopping die Frei-

zeit. Die zielgetriebene Gruppe verwendet dazu insbesondere die kognitive Fähigkeit

der selektiven Wahrnehmung – eine Methode des menschlichen Hirns, um aus der

Masse von sensorischen Informationen, die darauf einprasseln, nur die gewünschten

herauszufiltern. Nach dem Modell von Weiser und Brown [37] können mehrere sen-

sorische Informationen gleichzeitig durch die periphere Wahrnehmung überwacht

werden, um beim überwinden einer gewissen Schwelle schließlich einzeln in die pri-

märe Wahrnehmung überzugehen um genauer untersucht zu werden (z.B. optisches

Fokussieren eines gesuchten Objekts, Hören des eigenen Namens). Erfahrung zeigen

[2], dass digitale Bildschirme in Einkaufsstraßen oft einfach ignoriert werden, außer

sie treffen die optische selektive Wahrnehmung von Passanten, also Dinge nach de-

nen 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 Nähe passende Suchergebnisse darzustel-

len. Diese werden zum einen möglichst angezeigt, sobald sich Anja in Sichtweite be-

findet und zum anderen an den Kontext des jeweiligen Displays angepasst. Letzteres

bedeutet, dass passende Produkte, die in Geschäften in unmittelbarer Nähe verfüg-

bar sind, auch zuerst angezeigt werden. Die Displays im Szenario sind per Berüh-

rung bedienbar und ermöglichen dadurch einen erweiterten Funktionsumfang (z.B.

browsen durch die Ergebnisse, Vergrößerung, Wegbeschreibung zum Geschäft des



Artikels, usw.). Jedoch auch ohne Touch-Screen könnten einige dieser Funktionen

realisiert werden, z.B. durch eine Karussell-Funktion durch die besten Suchergebnis-

se. Im Szenario wird Anja schließlich durch ein Public Display auf ein Kleid auf-

merksam, welches sie normalerweise nicht gefunden hätte, da sie das jeweilige Ge-

schäft bisher nicht interessant fand. Die höhere Aufmerksam Anjas auf die Public

Displays ist zum einen durch die veränderte Erwartungshaltung geprägt, nämlich

dort interessante (personalisierte) Inhalte zu finden und zum anderen durch die se-

lektive Wahrnehmung, welche automatisch auf die möglicherweise passenden Such-

ergebnisse aufmerksam wird. Eine weitere Funktion des Public Shopping Assistent

ist es möglichst passende Produkte um die eigentlichen Suchergebnisse herum zu

positionieren und somit zusätzliche Käufe zu stimulieren.

Dieses Szenario zeigt insbesondere wie Public Displays verwendet werden können,

um reale Umgebungen mit lokalisieren und auf Personen in der Nähe abgestimmten

Informationen anzureichern, die sonst nicht zu sehen wären. Diese Informationen

können wahrgenommen werden, müssen es aber nicht zwingend. Insgesamt hat An-

ja in diesem Szenario zum einen ein Produkt gefunden, dass sie sonst möglicherwei-

se nicht gefunden hätte 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 nötig, danach war keine direkte

Interaktion mehr mit dem Telefon notwendig.

4.1.3 Szenario 3: Zeitvertreib und soziale Interaktion

Max fährt täglich mit der S-Bahn und U-Bahn zur Universität. Es steigt im Hauptbahnhof

um und muss meistens ein paar Minuten auf dem Bahnsteig auf die U-Bahn warten. Die

Wartezeit überbrückt er oft mit Musikhören und dem Surfen im Internet über sein

Smartphone. Regelmäßig betrachtet er auch die Inhalte auf den großen Public Displays ge-

genüber seinem Bahnsteig – sie sind so angebracht, dass man sie praktisch nicht übersehen

kann. Sie bieten eine Mischung aus Werbung, Schlagzeilen und Wettervorhersage, wiederho-

len 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 verfügbar sind. Er wählt eine

Anwendung namens „Public Opel Pong“ aus und wird aufgefordert einen Spielernamen ein-

zugeben. Nach der Eingabe von „MegaMax“ aktiviert er die Anwendung auf seinem Telefon.

Innerhalb weniger Sekunden wird auf dem großen Public Display gegenüber 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 großer QR-Code angezeigt über dem steht „Jetzt eins-

cannen und Spiel starten“. Max begreift, dass er für dieses Spiel einen Mitspieler braucht. Er

schaut sich links und rechts um und entdeckt schon bald mehrere Leute, die ihr Telefon be-

reits auf das Display ausrichten um offenbar den QR-Code zu scannen. Da verschwindet



auch schon der QR-Code, ein Count-Down zählt von 5 herunter und der Ball fängt an sich

zu bewegen. Max bewegt sein Paddel, verfehlt den Ball jedoch knapp und ermöglicht so den

ersten Punkt für 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 anlächelt. Gleichzeitig bemerkt Max, dass auch die vielen an-

deren Personen auf dem Bahnsteig dem Geschehen folgen oder sich offenbar mit Freunden

über das Spiel unterhalten. Die nächste Runde geht los und Max packt nun der Ehrgeiz.

Schließlich 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 rüber, die mit den Schultern zuckt und lacht.

Gleichzeitig sieht er seine Bahn einfahren und wundert sich, dass die Zeit so schnell vergan-

gen ist. „Mal sehen wer morgen mitspielt“ denkt sich Max fast schon mit ein wenig Vorfreu-

de.

Public Displays können im Gegensatz zu Laptop- oder Handy-Displays von vielen

Personen gleichzeitig gesehen werden. Desto größer und ggf. exponierter diese sind,

desto mehr Leute erreichen sie in der Regel. Dies trifft ganz besonders für Umge-

bung zu, in denen regelmäßig Wartesituationen entstehen und Menschen einen län-

geren Zeitraum in Sichtweite von Public Displays verbringen. Soziale Normen, die

dazu führen, dass Fremde in engen Situationen Augenkontakt vermeiden, verstärken

die Aufmerksamkeit auf Public Displays zusätzlich. Wie das Szenario zeigt, bieten

solche Umgebungen jedoch auch Chancen zur spielerischen sozialen Interaktion mit

Hilfe von Public Displays [24]. Wie Max zunächst nicht weiß, ist das Spiel, das er auf

dem Bahnsteig gegenüberliegenden Display aufruft, für zwei Spieler gedacht. Seine

anfängliche Motivation zur Interaktion mit dem Public Display ist durch Langweile

und Neugier geprägt (die sich wiederholenden Inhalte des Displays hat er nun schon

mehrfach gesehen). Gleichzeitig verspürt 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 Aufmerk-

samkeit 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 schließlich

auch neugierig nach Augenkontakt suchen. Diese Möglichkeit zum Aufbrechen sozi-

aler normen mit Hilfe von Public Displays ist auch Thema anderer Arbeiten [38].

Weiterhin bewirkt das interaktive Spiel auch eine verstärkte Aufmerksamkeit des

umstehenden Publikums, da diesem klar ist, dass sich die Spieler unter ihnen befin-

den müssen. Von dieser Aufmerksamkeit profitiert in diesem Fall der Sponsor dieses

interaktiven Spiels (hier z.B. Opel). Sieger solcher interaktiven Spiele können 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, kön-

nen viele öffentliche digitale Anzeigeflächen nicht per Berührung oder

Gestenerkennung gesteuert werden, weil sie außerhalb der Reichweite von Personen



sind (z.B. hier auf der anderen Seite der Gleise) oder die Personen außerhalb der

Reichweite von Sensoren des Displays. Die Steuerung über Mobiltelefone, die ohne-

hin ständig gegenwärtig sind, bietet deshalb einen einfachen und generell anwend-

bare Kanal zur impliziten und expliziten (Echtzeit-)Interaktion mit Public Displays.

Anzeigeflächen, die bereits direkte Interaktion unterstützen (z.B. per Berührung),

können dabei insbesondere von der impliziten Interaktion (Präsenz) profitieren, wo-

gegen bisher nicht-interaktive Public Displays zusätzlich noch einen Kanal zur direk-

ten Interaktion erhalten. Zudem bietet diese Art der Interaktion den Steuernden, falls

diese sich in Menschenmengen aufhalten, eine gewisse Anonymität, obwohl sie sich

in Sichtweite des Bildschirms befinden. Somit können Personen mit Anzeigeflächen

interagieren ohne identifizierbar zu sein und daher auch ggf. „peinliche“ Situationen

vermeiden.

Zusammenfassung

Mit Hilfe von Szenarien wurden drei Nutzungsfälle 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 für die Nutzer

war. So hat Achim öffentliche Anzeigeflächen 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 ge-

zielten Einkauf zu unterstützen und Produkte in ihrem Kontext sichtbar zu machen,

die sie sonst nicht bemerkt hätte. Max konnte schließlich mit Hilfe eines interaktiven

Spiels seine Wartezeit überbrücken und gleichzeitig unverhofft in soziale Interaktion

mit bisher Unbekannten treten. Diese und viele weitere nützliche und unterhaltsame

Public Display Anwendungen werden durch die neugewonnene Interaktivität und

Personalisierbarkeit von Public Displays möglich.

Für Display Owner ist in diesem Zusammenhang die gesteigerte Wahrnehmung und

messbare Nutzung ihrer Display Flächen interessant. Für 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 können.

4.2 Anforderungen

Eine Architektur für potentiell globale Pervasive Public Display Netzwerke, die

mindestens die in den Szenarien beschriebene Funktionalität ermöglichen soll, muss

eine Vielzahl funktionaler und qualitativer Anforderungen erfüllen. Diese werden im

Folgenden genannt und kurz beschrieben.



4.2.1 Funktionale Anforderungen

Unterstützung impl iziter Interaktion

Wie in allen drei Szenarien deutlich wurde, ist die Wahrnehmung der Präsenz von

potentiellen Nutzern in der Nähe von Public Displays eine wesentliche Anforderung

zur Ermöglichung impliziter und expliziter Interaktion mit Public Displays. Durch

die Wahrnehmung von Präsenz können digitale Bildschirme in der Umgebung einer

Person vielfältigste Aufgaben auf unterschiedliche Arten übernehmen (z.B. Ambient

Information Systems [17,39]) und dadurch einen erheblichen Mehrwert bieten. Die

Präsenz kann dabei als Kombination aus reiner räumlicher Nähe einer Person und

einer Menge von dessen Präferenzen betrachtet werden (z.B. das Interesse an Archi-

tektur). Wie die Szenarien zeigen, kann das Smartphone ein Weg sein, um diese Prä-

ferenzen implizit zu äußeren und so Public Displays in direkter Umgebung zu beein-

flussen.

Personal isierung von Publ ic Display Inhalten

Viewer sollten die Möglichkeit haben Inhalte auf Public Displays implizit und expli-

zit beeinflussen zu können, solange sie sich in ihrer Nähe befinden. Die Inhalte auf

digitalen Anzeigen können dabei von statischen Inhalten wie Bildern über dynami-

sche 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. Deswei-

teren hat das Publikum von Public Displays heutzutage bisher keine Möglichkeit

Public Display Infrastrukturen temporär für sich zu nutzen, z.B. durch gewünschte

Anwendungen. Zukünftige Public Display Netzwerke sollten sich somit für ver-

schiedenste Anwendungen öffnen, die spontan durch das Publikum angefragt wer-

den könnten. Display Anwendungen sollten sich dabei automatisch an den Kontext

des aufrufenden Displays sowie die Präsenz und Präferenzen des Publikums anpas-

sen. Der Kontext eines Public Displays kann dabei aus vielen Information bestehen,

u.a. Position, Lage, Ausrichtung, Bildschirmgröße, Format, Form, Umgebungsinfor-

mationen, Sensorinformationen u.v.m. Gleichzeitig ist es jedoch wichtig, dass Dis-

play Owner weiterhin Einfluss auf die Inhalte und die Nutzung ihrer Infrastruktur

haben.

Unterstützung direkter Interaktion

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 unterstützen oder falls diese nicht zugänglich sind, jedoch trotzdem interak-

tive Inhalte aufgerufen werden, welche Bedienung verlangen. Zu diesem Zweck soll

deshalb direkte Interaktion in Echtzeit zwischen den Mobilgeräten des Publikums

und der auf einem Public Display gerade ausgeführten Anwendung ermöglicht wer-



den. Eine Anwendung selbst soll dabei entscheiden wie viel Personen gleichzeitig

mit Ihr interagieren können (z.B. zwei Spieler beim Pong Spiel in Szenario 3).

4.2.2 Qualitative Anforderungen

Privacy

Wie bereits beschrieben basiert die geforderte Möglichkeit der impliziten Interaktion

auf der Wahrnehmung der Präsenz von Personen in der Nähe von Public Displays.

Typische Ansätze zur Bestimmung der relativen oder absoluten Position von Perso-

nen beruhen zumeist auf dem Tracking von Mobilgeräten (Smartphone, Badge, etc.)

die diese Personen mit sich führen und diese eindeutig identifizieren. Diese Ansätze

ermöglichen jedoch gleichzeitig leicht das Anlegen von Bewegungsprofilen und im-

plizieren ein vorhandenes Vertrauensverhältnis zur überwachenden Infrastruktur. In

der Realität heterogener Public Display Netzwerke sind solche Vertrauensverhältnis-

se jedoch weder vom Viewer gewollt noch realistisch. Gleichzeitig basiert die Perso-

nalisierung von Public Displays in räumlicher Nähe auf der Notwendigkeit Präfe-

renzen zu übermitteln und die Präsenz des Nutzers wahrzunehmen. Eine mögliche

Lösung soll dem Viewer daher die volle Kontrolle darüber geben wann, mit wem und

welche Daten er teilen will, jedoch gleichzeitig praktikabel bleiben.

Interoperabil i tät

Die beschriebene Funktionalität soll ohne spezielle Anforderungen und Aufwand in

möglichst gleichzeitig viele verschiedene kommerzielle Public Display Media-Player

und Middleware-Systeme integrierbar sein oder optional unabhängig von diesen

betrieben werden können.

Skal ierbarkeit

Eine Architektur zur Unterstützung der genannten Funktionalität soll auch noch bei

einer großen 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 Unterstützung 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 spätestens bevor der

Viewer das Display bereits passiert hat (Pass-By Situation als Referenz-Fall). Deswei-

teren erfordert die Bedienung per direkte Interaktion möglichst schnelle Reaktions-

zeiten. Abhängig von der interaktiven Anwendung, sind möglicherweise jedoch

auch leichte Verzögerungen akzeptabel.

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, imple-

mentiert und auf der dortigen Public Display Infrastruktur [41] evaluiert.

Aufbauend auf den funktionalen und qualitativen Anforderung, wird in diesem Ka-

pitel 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 interagie-

ren zu können, ohne durch die unbekannte, spontan genutzte, Display-Infrastruktur

verfolgbar oder identifizierbar zu sein.

Die Beschreibung der Architektur lässt dabei, soweit möglich, technische Details au-

ßer Acht und bleibt auf einem eher abstrakten Niveau. Wo es für das Verständnis

notwendig ist, werden jedoch ggf. konkretere Implementierungswege oder Techno-

logien vorgeschlagen. Die Beschreibung einer konkreten prototypischen Implemen-

tierung der Komponenten dieser Architektur erfolgt dagegen im nächsten Kapitel.

Diese Kapitel beginnt mit einer Einführung in das Schlüsselkonzept der Tacita Archi-

tektur, gibt einen Überblick über dessen Komponenten und deren Zusammengang,

um schließlich die einzelnen Komponenten genauer zu diskutieren.

5.1 Grundkonzept

Das Konzept von Tacita wird insbesondere durch zwei grundlegende Designent-

scheidungen geprägt - dem Broadcast von Display-Eigenschaften sowie indirekter

Kommunikation mit Hilfe von Display Anwendungen (Display Apps).

1. Broadcast von Display Eigenschaften: Bisherige Ansätze zur Wahrnehmung

von Präsenz in der Nähe von Public Display wie z.B. dem Tracking mit Hilfe

von IDs[42] oder dem Broadcast von Präferenzen durch Viewer [14], bringen

offensichtliche Nachteile mit sich, wie z.B. die Notwendigkeit zusätzlicher Inf-

rastruktur sowie Privacy Probleme. Der Ansatz in dieser Arbeit kehrt deshalb

die übliche Praxis um, so dass nun Public Displays ihre Fähigkeiten publizie-

ren und diese von Viewer-Mobilgeräten in der Nähe wahrgenommen werden

können (Abbildung 3). Auf Basis der empfangenen Informationen können die

Präferenzen von Viewern auf deren Mobilgeräten nun mit den verfügbaren

Fähigkeiten verglichen und ggf. automatisch Anfragen zur Personalisierung

versendet werden. Wie später gezeigt wird, ist für die reine Übermittlung von

Display-Fähigkeiten zum Mobiltelefon keine besondere Übertragungstechno-

logie notwendig, ja nicht einmal räumliche Nähe, sondern lediglich ein Weg

zur Übermittlung von Display-Fähigkeiten an Mobilgeräte.



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

2. Indirekte Kommunikation: Die zweite wesentliche Designentscheidung be-

steht darin, sämtliche Interaktions-Anfragen des Viewer-Mobilegerätes direkt

an die gewünschte 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, erhält ggf. notwendige

Parameter vom Viewer2, um dann eine Aufruf-Anfrage an das gewünschte

Public Display zu senden. Dieses kann dann, abhängig von seinem Zustand

sowie Policies, die anfragende Display-Anwendung direkt abrufen und anzei-

gen, sie für einen späteren Zeitpunkt parken oder ggf. ganz ablehnen.

Die Kombination dieser beiden Ansätze ermöglicht es Viewern, gänzlich unsichtbar

für die typischerweise unbekannte und daher nicht vertrauenswürdige Public Dis-

play Infrastruktur zu bleiben, jedoch indirekt trotzdem implizit und explizit mit die-

ser interagieren zu können.

Vertrauens-Model l und Display Apps

Die Kontrolle darüber welche personalisierten Inhalte wann für welches öffentliche

Display angefordert werden, liegt dabei beim Viewer. Dieser kann über sein Mobil-

gerät seine Präferenzen dadurch äußern, dass er aus einer Menge verfügbarer Public

Display Anwendungen, diejenigen aktiviert und mit Parametern versieht, die er auf

nahen Public Displays nutzen möchte. Gleichzeitig haben Display Owner die end-

gültige Kontrolle darüber, welche Display Anwendungen, wann, wie oft und ggf.

wie lange auf ihren Displays ausgeführt werden können.

2 Abhängig vom Kontext wird „Viewer“ ggf. auch als Abkürzung für „Viewer-Mobilgerät“ verwendet.



Abbildung 4: Vertrauensbeziehungen zwischen Stakeholdern und Anwendungen

Sowohl Viewer als auch Display Owner bauen somit eine Vertrauensbeziehung zu

Display Applikationen auf sobald sie sich entschließen diese zu nutzen bzw. diese

zur Nutzung freizugeben (Abbildung 4). Display Owner können dabei ein breites

Band von Policys unterstützen, von der Erlaubnis jeglicher Anwendungen, über das

Zulassen ausgewählter Anwendungen zu bestimmten Zeiten oder in Kontingenten,

bis hin zur dauerhaften Ausführung einer einzigen oder gar keiner Anwendung.

Anwendungen, die durch den Display Owner zur dauerhaften Ausführung ausge-

wählt wurden, können dabei auch komplett auf möglicher Personalisierung durch

das Publikum verzichten und stattdessen vorgegebene Aufgaben erfüllen.

Die Verwendung von Anwendungen oder „Apps“, die von dritten Parteien angebo-

ten werden und zur flexiblen Ergänzung spezifischer Funktionalität dienen, ist nicht

neu und mittlerweile ein sehr populäres Konzept (z.B. Facebook-Apps, Google+ und

Google Chrome-Apps, iPhone- und Android-Apps). Ein Vertrauensverhältnis mit

einer Display App wird dabei in zwei Schritten aufgebaut. Zunächst kann ein poten-

tieller Nutzer sich mit Hilfe von App-Metadaten über Zweck, Funktionsumfang, An-

forderungen, Anbieter, Nutzungs- und Datenschutzbedingungen, usw. einer App

informieren und sich dann ggf. im zweiten Schritt dazu entschließen diese zu akti-

vierten bzw. zu installieren und bei Bedarf zu nutzen oder auch jederzeit wieder zu

deaktivieren. Mit Hilfe von Display Apps wird nun dasselbe, bereits allgemein akzep-

tierte Konzept auf Anwendungen für Public Display Netzwerke übertragen. Im Ge-

gensatz zu z.B. Apps für Smartphones sollen in Public Display Netzwerken die glei-

chen Display Apps durch Viewer und Display Owner genutzt werden, wobei Dis-

play Owner als Besitzer der Infrastruktur andere Interessen verfolgen als Viewer.

Dies führt generell zu komplexeren ökonomischen Geschäftsmodellen. Diese werden

an anderer Stelle dieser Arbeit skizziert.

Unter Berücksichtigung der geforderten funktionalen und qualitativen Anforderun-

gen wird dieses Konzept nun im folgenden Abschnitt konkretisiert und eine Basis-

Architektur präsentiert.



5.2 Basis Architektur

5.2.1 Übersicht

Wie Abbildung 5 verdeutlicht, besteht die Basisarchitektur aus fünf notwendigen

Komponenten:

Den Display Nodes, welche die physikalischen Rechner darstellen und die ei-

nen Media Player ausführen, welcher für 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 für Viewer, die für die Verwaltung von Nutzer-

Präferenzen, die Wahrnehmung naher Displays und ihrer Fähigkeiten sowie

die Kommunikation mit Display App genutzt wird,

Sowie einem Service Directory, dass die Übertragung von Display Fähigkeiten

zur mobilen App von der Notwendigkeit entkoppelt, tatsächlich in Räumli-

cher Nähe eines Public Displays sein zu müssen.

DisplayApplication

DisplayNode

Service Directory

DownloadDatabase

Request Display

Foreground

RequestPersonalisation

PublishCapabilities

Mobile App

DisplayNode

Display NodeService

Directory

DisplayApplication

DisplayApplication

GetContent Near

Display

Media Player

Viewer

Display Owner

Application Provider

Abbildung 5: Basis-Architektur

Display Apps können 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 anzu-

fragen. Erhält ein Media Player auf einem Display Node diese Anfrage, so wird diese

basierend auf den Policies des Display Owners überprüft, ggf. erlaubt und die ge-

wünschte Anwendung aufgerufen und angezeigt. Die Art des Abrufs, der Ausfüh-

rung und der Anzeige einer Display App wird auf dieser architektuellen Ebene nicht

weiter konkretisiert, ist aber vom verwendeten Übertragungsprotokoll und der ver-



wendeten Media-Player Software abhängig. Mit Hilfe den von jeder Display App zur

Verfügung gestellten App-Metadaten, können Display Owner für jedes Ihrer Dis-

plays festlegen, ob und welche Display Apps sie zum Aufruf durch Viewer erlauben

möchten (Policies). Die Fähigkeiten eines Public Displays (bestehend aus Display-ID,

Name, Geo-Position, erlaubten Display Apps, etc.) werden in Form von Public Dis-

play Metadaten in einem oder mehreren Service Directories publiziert. Service

Directories werden von der mobilen App verwendet, um Display Metadaten für

ganze Regionen abzurufen und lokal zu cachen. Mit Hilfe dieser lokalen Datenban-

ken und mit dem Wissen der eigenen Position und der Präferenzen des Viewers,

können 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 führt als Host-

Rechner lediglich die Media Player Komponente aus. Trotzdem werden Display No-

des in Abbildung 5 beibehalten, um die räumliche Assoziation zwischen Mobilgerä-

ten von Viewern (und der darauf ausgeführten mobilen App) zu illustrieren.

Display Nodes sind somit für den Langzeitbetrieb und ggf. Outdoor-Betrieb ausge-

legte Rechner [41,43], die ein oder mehrere Displays ansteuern, vernetzt sind und

eine Software zur Verwaltung und Wiedergabe von Inhalten ausführen (Media

Player). Desweiteren sind an diese Rechner ggf. Sensoren angeschlossen, die zur In-

teraktion 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

können.

5.2.3 Display App

Eine Display App3 ist eine Anwendung speziell für Public Displays, die potentiell von

Drittanbietern (Application Provider) entwickelt und betrieben wird. Sie kann prinzi-

piell jede Ausführungs-Form haben, die vom Media-Player auf dem aufgerufenen

Display unterstützt wird. Denkbare Möglichkeiten wären u.a. kompilierte ausführ-

bare Programme, virtuelle Maschinen, oder Webseiten. Letzterer Ansatz wird z.B. im

Kapitel „Implementierung“ verwendet um komplexere interaktive webbasierte Dis-

play-Apps zu realisieren. Eine Anwendung kann von der Anzeige eines simplen Bil-

des bis hin zu einem interaktiven 3D-Spiel verschiedenste Zwecke und unterschied-

lichste Komplexität besitzen.

3 Oder hier auch „App“. Applikationen für Mobilgeräte werden zur Abgrenzung immer als „mobile App“ bezeichnet



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 ausgeführt wird und keinerlei Kanäle zur Personalisierung und Interaktion bie-

tet. Die Tacita Architektur fokussiert jedoch eine Vision, in der die Funktionalität von

traditionelle Media Playern auf Displaysystemen mit Hilfe eines lebendigen Ökosys-

tems von Apps realisiert wird, aus dem sowohl Display Owner als auch Viewer grei-

fen können um gewünschte Inhalte gezielt auf Public Displays zu bekommen.

Nutzungsfäl le

Es lassen sich drei Nutzungsfälle 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 ausgewählt, die dauerhaft ausgeführt werden

(hier z.B. eine „Ads App“ die zur Wiedergabe von Werbeinhalten), die jedoch

keine Schnittstelle für mobile Viewer-Personalisierung bieten.

2. Einzel-App Personalisierung: Der Display Owner führt dauerhaft eine einzi-

ge App aus, die auch von mobilen Viewern beeinflusst werden kann (hier z.B.

eine „News App“, die zusätzlich zu anderen Themen auch Sportnachrichten

anzeigt).

3. Multi-App Personalisierung: Mehrere personalisierbare Apps sind gleichzei-

tig verfügbar. Im Beispiel wird z.B. eine „Ads App“ zur Anzeige von Werbe-

anzeigen dauerhaft angezeigt und bei Bedarf von einer „News-App“ überla-

gert. Unterschiedliche Strategien zur Darstellung mehrerer Display Apps

gleichzeitig auf einem Display werden im Abschnitt „Media Player“ vorge-

stellt.

Display Request

Viewer

Display Node

News App

1. No Personalisation

Media Player

XAds App

ViewerRequest : „Topic: Sport“

Display Request

Viewer

Display Node

News App

Media Player

News App


2. Single-AppPersonalisation

Topic: Sport,...

Display Request

Viewer

Display Node

News App

Media Player

News App


3. Multi-AppPersonalisation

Ads App

Abbildung 6: Display-App Nutzungsfälle



Personal isierung

Sowohl bei der Anfrage einer Display-App durch einen Viewer, als auch beim Auf-

ruf durch das gewünschte Display können Präferenzen in Form von Parametern an

eine Display App übergeben werden. Diese können 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 Tourismus-

Display-App, um die öffentlichen Anzeigeflächen um sich herum mit seinen Präfe-

renzen „Geschichte und Architektur“ zu personalisieren. Die Displays auf denen

diese Display-App schließlich aufgerufen wird, ergänzen die App um weitere Para-

meter (z.B. Display-Geoposition) und ermöglichen schließlich den Abruf von Tou-

rismusinformationen für die direkte Umgebung. Somit hat eine Display-App beim

Aufruf durch ein Display immer auch Zugriff auf dessen Metadaten und erhält da-

durch Zugriff auf wertvolle Kontext-Informationen zur Anpassung seines Inhalts.

Wurde eine Display App schließlich im Media Player eines Display Nodes geladen

und ausgeführt, so kann der Media Player der App möglicherweise über zusätzliche

Schnittstellen Zugriff auf weitere Sensoren bieten. Weiterhin kann eine Display App

z.B. Verbindungen zu anderen entfernten Rechnern aufbauen um z.B. zusätzliche

Daten abzurufen (News, Wetterdaten, Aktien, usw.) oder sogar persistente Kommu-

nikation (ggf. in Echtzeit) zu ermöglichen.

Schnittstel len

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

Private:

sendDisplayRequest(app_id,callback_parameters[,metadata_url]):

result

Tabelle 1: Abstrakte API – Display App

Über getApp wird die Display App selbst vom Display abgerufen und ihr dabei Prä-

ferenzen des Displays und sonstige Parameter übergeben. getMetadata ruft die Meta-

daten 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 Präfe-

renzen 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 ge-

4 Beschrieben mit der Syntax: functionsname(parameter): rückgabe



wünschten Public Displays. Dabei werden zusätzlich möglicherweise bestimmte call-

back_parameter übergeben, die zur Identifikation der ursprünglichen Anfrage (Re-

quest-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 ent-

halten:

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 be-

stimmt die Art des Aufrufs und der Ausführung dieser Anwendung. Die nächsten

fünf Angaben dienen der reinen Information für Viewer und Display-Owner. Die

Metadata-URL referenziert den Ursprung der Metadaten (Selbstreferenz) und ermög-

licht so die jederzeitige Aktualisierung von der Quelle. Die App-URL ermöglicht ei-

nem Media Player den Abruf der Display App (Referenz auf getApp der API in Ta-

belle 1) und Display-Parameter definiert die dabei zur Verfügung stehenden Parame-

ter. Die Viewer-Aufruf-URL dient dagegen dem Viewer zur Anfrage von Personalisie-

rungsanfragen über die mobile App. Viewer-Parameter definieren dazu verfügbare

Parameter und ggf. vorgegebene Werte.

5.2.4 Media Player

Die Media Player aktueller Public Display Systeme unterstützen zumeist nur stati-

sche und dynamische Inhalte (Bilder, Video, Webseiten), die basierend auf Zeitplä-

nen wiedergegeben werden. Dazu laden sie regelmäßig Playlisten herunter, die

durch separate Software ihrer Verwalter erstellt werden, cachen die Inhalte der Play-

liste lokal und geben diese nach Zeitplan wieder. Seltener unterstützen Public Dis-

plays und dessen Media-Player bisher direkte Interaktion (z.B. per Berührung) und

damit die Bedienung interaktiver Display Anwendungen, wie dies z.B. der Fall in



[43] ist. Praktisch kein (kommerzielles) öffentliches System dagegen ermöglicht bis-

her die Ad-hoc Interaktion mit und Personalisierung durch mobile Viewer.

Integration mit klassischen Inhalten

Eine mögliche zukünftige Öffnung von Pervasive Display Netzwerken für Display-

Apps und mobile Viewer Personalisierung verlangt ggf. zunächst nach einer schritt-

weisen Integration vorhandener Systeme und Anzeigestrategien mit neuen Funktio-

nen. Dabei unterscheidet sich die bisherige planbare, zeitlich lineare Wiedergabe von

Inhalten auf Public Displays vollständige von der spontanen, durch Viewer beein-

flussten, App-basierten Generierung. Zweifellos lassen sich komplizierteste Regeln

definieren, um geplante Inhalte und spontan angefragte Display-Apps zu kombinie-

ren. Zur Erhaltung der Einfachheit wird an dieser Stelle jedoch ein simples Model

vorgeschlagen.

Media Player werden dazu um eine Schnittstelle ergänzt, um externe Anfragen zum

Aufruf von noch nicht ausgeführten Display Apps annehmen zu können. Wenn kei-

ne 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

(höhere Priorität). Ist der Viewer außerhalb der Reichweite des Displays, so wird die

Display App wieder ausgeblendet und die Playlist fortgesetzt. Auf diese Weise las-

sen sich Wiedergabezeiten geplanter traditioneller Inhalte nachvollziehen (z.B. zur

Abrechnung mit Advertisern) und gleichzeitig Personalisierung unterstützen. Durch

das Konzept zeitlicher und oder Aufrufzahl-basierter Kontingente ließe sich zudem

das Nutzungsvolumen von Display-Apps eingrenzen. Diese Strategie zielt offen-

sichtlich auf aktuelle kommerzielle digitale Anzeigefläche für 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 ausgeführt werden können und sogar leicht die

Aufgabe von klassischen Media Playern übernehmen können. Daher würden bei ei-

nem „Grüne Wiese“-Szenario (d.h. ohne die Notwendigkeit der Unterstützung vor-

handener Media Player Software) einfach eine Media Player Display App zur Wie-

dergabe geplanter Inhalte dauerhaft ausgeführt und ggf. mit anderen Display Apps

überlagert, die durch Viewer angefordert wurden (Analog zur weiter oben genann-

ten 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 be-

reitgestellt wird (die jedoch dauerhaft aktiviert ist).

Display Owner Pol icies

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 können prinzipiell bestimmen welche



Apps gestartet werden können, zu welchen Zeiten, wie lange, wie oft und natürlich

auf welchen Displays. Diese Regeln können natürlich beliebig komplex gestaltet

werden und hängen von der Implementierung des Media Players ab.

Zur Erhaltung der Einfachheit wird in dieser Arbeit ein simplerer Regelsatz vorge-

schlagen. Dieser basiert auf dem beidseitige Vertrauensverhältnis 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

auswählen. Erweiterte Einstellung zur Darstellung von Display App regeln schließ-

lich 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 expli-

zit (erlaubte) Display Apps auf Public Displays anzufordern.

Die Existenz von Display Apps, die durch Applikation Provider angeboten werden,

muss natürlich auch noch von Display Ownern und Viewern auf praktikable Weise

wahrgenommen werden können. Zu diesem Zweck wird das mit dem „App“-

Konzept in enger Verbindung stehende „App-Store“ Konzept im erweiterten Teil

dieser Architektur zur Publikation von Display Apps integriert. Im Rahmen der Ba-

sis-Architektur soll dieser Teil jedoch zunächst außen vor gelassen werden.

Multi-App und Multi-Viewer Unterstützung

Mehrere unterschiedliche Display Apps können potentiell zur gleichen Zeit ausge-

führt werden. Diese werden entweder zur dauerhaften parallelen Ausführung durch

den Display Owner gestartet, oder von Viewern spontan angefragt.

Viewer Anfragen durchlaufen dabei potentiell zwei Ebenen (Abbildung 7): Zunächst

die angeforderte Display-App, und im Anschluss den Media Player des Display No-

des, falls dieser die Anfrage akzeptiert.



App-Level Aggregation

Mobile App

User 1

DisplayNode

DisplayApplication

2

DisplayApplication

1

ViewerRequests

AppRequests

Display-Level Aggregation

Mobile App

User 2

Mobile App

User 3

Mobile App

User 4

Media Player

Abbildung 7: Aggregationsstufen von Personalisierungs-Anfragen

So können bereits auf der Display-App Ebene, Anfragen von unterschiedlichen mo-

bilen Viewern, die sich in der Nähe des gleichen Public Displays befinden, potentiell

aggregiert oder einzeln weitergeleitet werden. Insgesamt hat eine Display-App in

dieser Situation mehrere Möglichkeiten:

1. Aggregation: Falls die Display-App noch nicht auf dem Public Display aus-

geführt wird, so wird diese dort gestartet und gibt dort Inhalte wieder die an

beide Viewer-Präferenzen angepasst sind. Während die Display App ausge-

führt wird, können dessen Inhalte kontinuierlich, z.B. über eine Event-

basierte persistente Verbindung5 an inzwischen neue Personalisierungsanfra-

gen angepasst werden.

2. Einzelne Anfragen: Abhängig von dem Zweck einer Display-App ist es mög-

lich, dass diese für die Personalisierung durch mehrere mobile Viewer auf

dem gleichen Display nicht geeignet sind (z.B. Eine Single-Player Game). Hier

kann die App zusätzliche Anfragen für das gleiche Public Display ggf. parken

oder ganz ignorieren.

3. Parallele Anfragen: Weiterhin kein eine Display App auf die Steuerung von

Anfragen für das gleiche Display auch ganz verzichten, und diese einfach an

den Media Player des Display Nodes weiterleiten.

Ein Media Player eines Diplay Nodes kann, abhängig von dessen Fähigkeit, seine

Bildschirmfläche ggf. dynamisch aufteilen und mehrere (gleiche oder unterschiedli-

che) Apps gleichzeitig anzeigen oder jeweils nur eine App zur gleichen Zeit. Auch

hier existieren mehrere Möglichkeiten zur Behandlung multipler Anfragen:

5 Vorausgesetz, dass Display Apps Remote Hosts haben können, mit denen sie und mobile Viewer kommunizieren.



1. Anzeige einer App gleichzeitig: Hier wählt der Media Player nach der First-

Come-First-Serve Strategie die erste App-Anfrage aus und weißt dieser einen

einstellbaren Zeitraum (time-slot) zu. Entweder werden nun Anfragen, die

während der Ausführung der aktiven App eingehen, ignoriert oder in einer

Warteschlange geparkt um nach Beendigung der ersten App sequentiell abge-

arbeitet zu werden (zur Erhaltung der Praktikabilität solle die maximale Län-

ge der Queue nicht zu groß sein). Dabei bleibt zu beachten, dass Anfragen an

Display Apps, welche gerade ausgeführt werden, und die Aggregation unter-

stützen, ggf. gar nicht warten müssen und direkten Einfluss auf Inhalte haben

könnten (abhängig von der Steuerung durch die Display App).

2. Anzeige mehrerer Apps gleichzeitig: Das Anzeigen mehrerer Apps gleichzei-

tig erfordert die dynamische Aufteilung der Bildschirmfläche. Ein möglicher

Ansatz ist es diese in gleich große Rechtecke aufzuteilen. Dabei müssen Dis-

play Apps in diesem Fall auf die dynamische Anpassung der ihnen zur Ver-

fügung stehenden Displayfläche vorbereitet sein. Dieser Ansatz ist u.a. von

der Größe und Auflösung des Public Displays und der typischen Sichtweite

zu seinem Publikum abhängig und natürlich auf eine maximale Zahl von An-

zeigebereichen beschränkt. Abbildung 8 demonstriert eine mögliche Auftei-

lung eines Displays im Landscape- und Portrait-Modus in bis zu vier Bereiche.

Abbildung 8: Mögliche Partitionierung von Display-Flächen bis zu 4 Anzeigebereichen

Unter Zuhilfenahme zusätzlicher, von Display Apps zur Verfügung gestellter Infor-

mationen über speziell unterstütze Anzeigebereiche (z.B. Fußzeilen für Ticker-Apps),

könnte ein Media Player eine deutlich intelligentere Strategie zur Aufteilung der ver-

fügbaren Anzeigefläche zur Darstellung multipler Anwendungen implementieren.

Diese Informationen könnten dabei leicht als Teil der Display-App Metadaten publi-

ziert werden.

Sicherstel lung von Präsenz

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 möglich. Diese sind in erster Linie für die Kommunikation der

architekturellen Komponenten unter sich notwendig, können jedoch aufgrund der

offenen, verteilten Art dieser Architektur potentiell auch von anderen Host aufgeru-

fen werden. Somit können diese Schnittstellen auch Opfer von Missbrauch werden.



Dieses Problem haben sie jedoch mit jedem über das Internet aufrufbaren Rechner,

der Dienste zur Verfügung stellt, gemeinsam. Daher können z.B. auch die üblichen

Methoden zur Einschränkung von Missbrauch genutzt werden. (z.B. durch den Ein-

satz 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 können Media Player anhand von App-Metadaten der vom

Display Owner erlaubten Apps leicht überprüfen, ob anfragende Apps tatsächlich

von der gleichen Quelle stammen, wie in den Metadaten angegeben (analog zur Sa-

me-Origin Policy in Browsern). Zusätzlich können Media Player ihre eigenen Kon-

tingent basierten Regeln zur Eingrenzung von App-Aufrufen enthalten. Gleiches gilt

auch für Anfragen die bei Display-Apps eingehen. Weiter Missbrauch-

einschränkend können z.B. beschränkte Zugänge wirken, die nur mit Hilfe entspre-

chender Zugangsdaten Zugriff auf Funktionalität erlauben. So könnte das Recht be-

stimmte Display-Apps und/oder Public Display aufrufen bzw. nutzen zu können

zunächst 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 gewünschten Display Apps auf räumlich naher

Display Infrastruktur zu ermöglichen. Die Sicherstellung, dass ein Nutzer tatsächlich

in der Nähe ist, kann für die Nutzung mancher Display-Apps bzw. der Display-

Infrastruktur Voraussetzung sein. Zu diesem Zweck wird im Folgenden das Presence-

Token Konzept vorgestellt.

Presence Token sind regelmäßig durch Media-Player auf Public Displays generierte

Codes, die mit Hilfe von Übertragungstechniken mit kurzer räumlicher Reichweite

als Broadcasts publiziert werden. Mögliche Technologien sind z.B. QR-Codes, Infra-

rot, NFC, Bluetooth und andere Funkübertragungstechnologien. Presence Token

können dann durch die Mobilgeräte von Viewern empfangen und zusammen mit

der Anfrage zur Personalisierung an die gewünschte 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 Implemen-

tierungsteil dieser Arbeit wird demonstriert wie Presence Tokens über Bluetooth De-

vice Names oder sogar Hardware-unabhängig mit Hilfe von QR-Codes an Viewer

übertragen werden können.

Feedback

Das bereitstellen von (informativen) Benutzer-Feedback ist eine der „acht goldenen

Regeln“ [44] der Prinzipien guten User Interface Designs. Insbesondere in Zusam-

menhang mit expliziten Personalisierungs-Anfragen an Public Display bedeutet dies,

dass Gründe für eine nicht erfolgreiche oder Verzögerte Interaktion mit einem Public

Display dem Nutzer mitgeteilt werden sollten (erfolgreiche Anfrage haben trivialer

Weise sichtbare Auswirkungen). Dies könnte sowohl auf dem Mobilgerät des Vie-

wers, als auch auf den Displays selbst mitgeteilt oder angedeutet werden (z.B. durch

die kurze Einblendung, kleiner, unaufdringlicher Symbole).



Unabhängig von der Anzeige dieser Informationen, sollten die beteiligten Schnittstel-

len der kommunizierenden Komponenten dieser Architektur auf einfache und trans-

parente Weise Status- und Fehlernachrichten austauschen können. Konkret heißt

dies, dass das Ergebnis eines Personalisierungs-Aufrufs eines Viewers erst über die

aufgerufene Display App wieder zurück zum Mobilgeräte 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 Dis-

plays bereits eingetroffen ist.

Schnittstel len

Eine Media Player sollte zur Unterstützung von mobiler, Viewer-basierter Personali-

sierung mindestens folgende Schnittstellenaufrufe anbieten:

API: Media Player

Public:

handleAppRequest(app_id,callback_parameters[,metadata_url]):

result

getMetadata(): display_metadata

Private:

requestApp(display_preferences,callback_parameters): app

Tabelle 3: Abstrakte API – Media Player

Über die öffentliche Schnittstelle handleAppRequest fragt eine Display App ihre Aus-

führung 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 ge-

wünschte App ihm noch nicht bekannt ist, kann es über den optionalen Parameter

metadata_url zunächst die Metadaten anfordern, welche u.a. die App-URL enthalten,

die zum Abruf der App benötigt wird. Über den callback_paramter können zusätzliche

Parameter für den eigentlichen Aufruf der App durch den Media Player übergeben

werden (z.B. zur Erhaltung von Sessions). Weiterhin sollte eine Media Player Kom-

ponente 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 ausgeführt werden. Über den display_preferences Parameter

werden die Display-App Präferenzen des Display Owners übermittelt (z.B. „Topic:

Düsseldorf“, falls er auf seinem Public Display eine News-App verwendet und er

primär Nachrichten über Düsseldorf anzeigen lassen will).

Metadaten

Die Metadaten eines Public Displays sollten mindestens folgenden Informationen

enthalten:



Metadaten: Public Display

Display-ID

Typ-Unterstützung:[Executable,VM,Web,…]

Anbieter (Name, Adresse, Telefon, Email)

Eigenschaften

Geoposition (Lat,Lng,Alt)

Sichtbereiche (Radius, Von-Winkel, Bis-Winkel[,…])

Bildschirm-Auflösung

Orientierung

Direkte-Interaktion([J|N])

Bluetooth-MAC-Adresse

Metadata-URL

Anfrage-URL

Erlaubte-Apps: [None|All|List]

App-1 (App1-Metadaten, Display-Owner-Präferenzen)

App-2 (App2-Metadaten, Display-Owner-Präferenzen)

…

Tabelle 4: Abstrakte Metadaten – Public Display

Eine Display-ID dient der eindeutigen Identifizierung eines Displays. Als Eigenschaf-

ten können eine Vielzahl nützlicher Informationen übertragen werden, die zur Kon-

textualisierung der aufgerufenen Display-App sowie zum detektieren der räumli-

chen Nähe eines Viewers zum Public Display verwendet werden können. Eine zwin-

gende Angabe im Rahmen der Tacita Architektur ist die Angabe der Geoposition des

Public Displays. Mit zusätzlichen Angaben wie Sichtbereichen und der Bluetooth-

MAC-Adresse kann das im Abschnitt „Mobile App“ erläuterte Verfahren zur Bestim-

mung der Präsenz von Public Displays in der Nähe von Viewern noch weiter verfei-

nert werden. Über Metadata-Url wird auf die Quelle dieser Metadaten verwiesen und

die Anfrage-URL referenziert die Schnittstelle zur Anfrage durch Display-Apps.

Schließlich definiert Erlaubte-Apps die Display Owner Policy und gibt ggf. eine Liste

von erlaubten Display Apps an, welche primär durch die mobile App genutzt wird

(jedoch indirekt über die Publikation durch das Service Directory, da keinerlei direk-

te Kommunikation zwischen der nicht vertrauenswürdigen Public Display Infra-

struktur und der mobilen App erfolgen soll).

5.2.5 Service Directory

Die Service Directory Komponente dient für Public Displays als Verzeichnis zur Pub-

likation dessen Fähigkeiten (auf Basis von Display-Metadaten) und für die mobile

App zum Abruf dieser Daten für ganze Regionen. Regelmäßige automatische Anfra-

gen an ein Service Directory ermöglichen inkrementelle Updates einer bereits

gecachten Region oder, falls der Nutzer eine neue Region betritt, den Download der

Daten für diese.



Auf Basis dieser Daten und insbesondere der Geoposition von Displays und deren

verfügbaren Display Apps, kann die mobile App, ausgehende von der eigenen Posi-

tion, nahe Displays detektieren und gezielte Anfragen an verfügbare Display Apps

senden, die gleichzeitig auch mit den Präferenzen des Viewers übereinstimmen.

Service Directories sind eine notwendige strukturelle Komponente. Ihr zentralisierter

Ansatz macht die Publikation der Display-Metadaten sehr einfach. Die Tacita Archi-

tektur unterstützt dabei problemlos mehrere Service Directories und skaliert dadurch

auch bei einer großen 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 belie-

bige Zahl von Service Directories unterstützen. Ein Verzeichnis kann dabei einfach

durch eine URL referenziert werden. Nach dem der Installation der mobile Public

Display App auf dem Mobilgerät des Viewers kann diese z.B. bereits eine oder meh-

rere URLs zu Service Directories voreingestellt enthalten, oder diese aus einer Quelle

herunterladen die z.B. Links zu diversen Service Directories anbietet. Unabhängig

davon kann ein User jederzeit manuell Service Directory Link hinzufügen.

Auch der Display Owner, muss sich entscheiden seine Displays in einem oder meh-

reren Service Directories zu publizieren. Nach dem Setup eines Media Players und

dem hinzufügen der URL eines Service Directories, kann das Registrieren, Aktuali-

sieren und Abmelden von Public Displays völlig automatisiert über die öffentlichen

Schnittstellen des Service Directories ablaufen. Die erwartete Änderungshäufigkeit

ist dabei nicht besonders hoch. Ein Display-Owener wird die Metadaten seiner Dis-

plays eher wöchentlich oder noch seltener als z.B. jede Minute ändern. Der Abruf

von Display-Metadaten durch die mobile App erzeugt dagegen einen größeren Da-

tenverkehr, welche jedoch durch Komprimierung und inkrementelle Updates stark

minimiert werden kann.

Automatische Bekanntmachung verwendeter Service Directories

Ein Public Display ermöglicht zudem noch eine automatisierte Art, um dessen ver-

wendetes 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 Nähe eines Displays bekannt gemacht werden. Auf

Basis dieses Verfahrens ist ein völlig konfigurationsfreier Betrieb der mobilen App

möglich, welcher immer automatisch die benötigten Display-Metadaten von den

richtigen Service Directories herunterlädt.

Service Directory Privacy

Um eine potentielle Möglichkeit zur Erstellung von anonymen Viewer Bewegungs-

profile durch die Betreiber von Service Directories zu vermeiden (z.B. bei mehreren

Anfragen durch dieselbe IP-Adresse), können verschiedene Methoden zur Erzeu-



gung von Unschärfe genutzt werden. So kann die mobile App z.B. alle Daten eines

Service Directories herunterladen und damit absolute Positions-Unschärfe erreichen

(nicht realistisch für großen Mengen von Public Displays) bis hin zum Runterladen

lediglich aller Displays in direkter Umgebung (geringe Datengröße) jedoch dem ab-

soluten Verlust der Unschärfe. Ein möglicher Ansatz ist es dem mobilen Nutzer

selbst die Wahl zu geben, welches Level an Privacy er für akzeptabel hält. So können

über die Schnittstelle von Service Directories z.B. Daten für eine Stadt, ein Bundes-

land oder gar ein Land heruntergeladen werden, ohne eine genaue Position zu spezi-

fizieren. 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 Rückschlüsse auf die wahre Identität eines einzelnen Viewers

geschlossen werden kann. Außerdem lassen sich zwei unterschiedliche Anfragen

desselben Mobilgerätes 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 gene-

rell möglich auch aus groben Trajektorien, auf Personengruppen sowie durch Kom-

bination mit anderen Daten ggf. auch auf konkrete Person zu schließen. Dies beinhal-

tet jedoch bereits enormen Aufwand. Wie auch immer, eine weitere Art Unschärfe

herzustellen, ohne große Datenmengen herunterzuladen, ist die Kombination einer

gezielten Anfrage mit mehreren zufälligen Anfragen. Dieser Ansatz hat jedoch bei

Anwendungen über einen längeren Zeitraum schwächen, da die Verteilung der auf-

gerufenen Geopositionen oft die intuitive Unterscheidung von Echten und zufälligen

Bewegungen erlaubt.

Schnittstel len

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 Regist-

rieren, Abmelden und Aktualisieren von Display-Metadaten. Dabei wird beim re-

gistrieren ein im Media Player gesetztes bzw. automatisch generiertes Passwort

übergeben, dass bei Abmelden und Aktualisieren diese Eintrags abgefragt wird. Un-

6 Keine außer den üblichen, die bei jeder Art Kommunikation über das Internet entstehen



terschiedliche query Aufrufe, die für die Verwendung durch die mobile App gedacht

sind, ermöglichen den Download von Display-Metadaten für angegebene Bereiche.

Dies kann entweder über die Angabe der Region (z.B. „Düsseldorf“) erfolgen oder

spezifischer über eine kreisrunden Bereich mit angegebenem Zentrum und Radius.

Mit Hilfe eines last_timestamp können zudem optional inkrementelle Updates ange-

fordert werden. Die unterschiedlichen Anfragemöglichkeiten ermöglichen dabei, wie

zuvor erwähnt, unterschiedliche Stufen von Location-Privacy.

5.2.6 Mobile App

Die mobile App für den Einsatz auf dem Mobilgeräte des Viewers ist eine der Schlüs-

selkomponenten der Tacita-Architektur. Durch das Definieren von Präferenzen, dem

Wissen über die eigene Position und dem Zugriff auf Display-Metadaten mit Hilfe

von Service Directories, kann die mobile App fortlaufend und völlig automatisch

Display Apps auf räumlich nahen Display Apps detektieren und anfordern. Dies

ermöglicht sowohl implizite Interaktion mit Public Display, bei dem das Mobilgerät

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 detektie-

ren, um daraufhin mit ihnen interagieren zu können. Die Wahrnehmung naher Dis-

plays kann dabei entweder auf Basis absoluter Position oder der Detektierung von

Identifiern in direkter Nähe erfolgen.

Absolute Position: Die meisten modernen Mobiltelefone können ihre eigene Position

bis auf wenige Meter genau bestimmen. Die Genauigkeit und Aktualisierungsrate

hängt dabei von der zu Grunde liegenden Technologie ab. GPS (Global Positioning

System) bietet z.B. einer Genauigkeit von wenigen Metern und eine maximalen Up-

daterate von einer Sekunde. Innerhalb von Gebäuden ist GPS allerdings nicht ein-

setzbar. Auf WiFi- bzw. Bluetooth-Fingerprinting basierende Lokalisierung kann po-

tentiell eine fast genau so hohe Genauigkeit erreichen, ist jedoch abhängig von einer

hohen Abdeckung durch Hotspots und daher nicht Flächendecken verfügbar bzw. in

Regionen mit schwacher Abdeckung sehr lückenhaft und unzuverlässig. Lokalisie-

rung auf Basis von Mobilfunk Cell-IDs dagegen, steht Flächendecken zur Verfügung,

eignet sich jedoch aufgrund seiner geringen Präzision nicht direkt zur Detektierung

naher Objekte. Mit Hilfe einer bzw. der Kombination dieser Technologien, kann so-

mit 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-



plays abfragen und diese somit detektieren. Dieser Ansatz ist dabei im Prinzip unab-

hängig von der tatsächlichen Präsenz, da die lokale Datenbank beliebige Positions-

angaben annimmt und als Ergebnis nahe Public Displays zurückliefert.

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 Realität von Public Displays und dessen Betrachtung durch Viewer. Ein typi-

scher digitaler Bildschirm hat nämlich immer eine Ausrichtung und eine potentielle

Reichweite (u.a. beschränkt durch Anbringung, Schirmgröße 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 Fälle (Sichtfeld von <180°) Anfragen an Displays ge-

schickt, 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 auf-

hält). Ein Verbessertes Model muss deshalb auf der Abbildung tatsächlicher Sichtfel-

der von Public Displays basieren. Im Rahmen dieser Arbeit wird dazu ein verein-

fachter Ansatz vorgeschlagen, der auf multiplen Kreissektoren zur Abbildung von

Sichtfeldern basiert, die durch die mobile App als Trigger-Zonen zur Auslösung von

Display-App Anfragen genutzt werden können. Diese Sichtfelder können dabei

ebenso über die Metadaten einer Public Displays publiziert werden, und bieten Dis-

play Ownern einen höheren Grad an Kontrolle zur Auslösung von Viewer-

Interaktionen mit ihrer Display Infrastruktur. Ein komplexerer Ansatz könnte sogar

auf Basis beliebiger Polygonflächen, 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 Nähe eines Viewers können auch Identifier dienen. Diese können u.a. mit Hilfe

von Bluetooth, WiFi, NFC und QR-Codes detektiert werden. So haben typische Blue-

tooth und WiFi-Hotspots eine relativ begrenzte Reichweite von wenigen Metern, in



welcher sie u.a. über ihre eindeutige MAC-Adresse wahrgenommen und identifiziert

werden können. Durch die radiale Ausbreitung elektromagnetische Signale, kann

dabei nicht die gleiche Präzision bzw. Kontrolle zur Auslösung von Personalisie-

rungs-Anfragen durch Viewer erreicht werden, wie dies mit dem Trigger-Zonen An-

satz möglich ist. QR-Codes (Quick Response Codes), können dagegen auf Public Dis-

plays direkt angezeigt werden und haben eine auf Sichtweite beschränkte Reichwei-

te. Beim einscannen über die Kamera des Viewers können sie beliebige Informatio-

nen enthalten und somit auch Identifier. NFC (Near Field Communication) kann ebenso

beliebige Daten transportieren, ist jedoch meistens auf Reichweiten von unter einem

Meter beschränkt (oft nur wenige Zentimeter).

Diese Identifier können nun als Teil der Display-Metadaten durch Display Owner

publiziert, durch die mobile App heruntergeladen und durch die Sensoren des Mo-

biltelefons detektiert und mit den Display-Metadaten verglichen werden. Dieser An-

satz ist im Gegensatz zum vorhergehenden tatsächlich von der realen Präsenz eines

Viewers abhängig, um ein nahes Public Display identifizieren zu können und kann

daher auch im Zusammenhang mit der Sicherstellung von Präsenz (Abschnitt 5.2.4) auf

Basis von Presence Token verwendet werden.

Definition von Präferenzen

Im Rahmen der Tacita Architektur wird „Personalisierung“ von Public Display In-

halten durch die Anfrage gewünschter Display Apps erreicht. Display Apps bieten

wiederum verschiedene Parameter an, mit dessen Hilfe Viewer die Inhalte von Dis-

play Apps anpassen können. Somit werden die Präferenzen einen Viewers durch die

Menge ausgewählter Display Apps und dessen individuelle Konfiguration mit Hilfe

von Parametern definiert.

Zunächst muss ein Viewer jedoch erst von der Existenz potentiell verfügbarer Apps

wissen. Eine Liste aller auf Public Displays der Region verfügbaren Apps kann dabei

leicht aus der lokalen Display-Metdaten Datenbank extrahiert und dem Viewer über-

sichtlich präsentiert werden (z.B. sortiert nach Distanz). Mit Hilfe der zu jeder Dis-

play App verfügbaren Meta-Daten, kann sich ein Nutzer über Zweck, Beschreibung,

Aussehen und Nutzungsbedingungen einer App informieren, bevor er beschließt

diese zu nutzen. Weiterhin erhält ein Viewer eine Übersicht über ggf. verfügbare

Personalisierungs-Parameter der App und kann diese setzen und dauerhaft lokal

abspeichern. Parameter können dabei von allgemeinen Angaben wie „gewünschte

Sprache“ bis hin zu potentiell kritischen Angaben wie „Benutzername und Pass-

word“ reichen.

Möchte ein Viewer auf seiner mobilen App Zugriff auf Display Apps erhalten, die

von Application Providern angeboten werden, jedoch in seiner Region auf keinem

Display verfügbar und deshalb in der Liste nicht sichtbar sind, dann muss ein ande-

rer Weg gefunden werden, um die Metadaten der gewünschten App zu erhalten.

Eine solche Situation tritt z.B. immer dann auf wenn ein Viewer eine Reise in ein an-

deres Land plant und im Voraus bestimmte Apps aktivieren möchte, die ggf. in jener



Region verfügbar sind jedoch nicht in der Region in der er sich gerade befindet. Dazu

kann ein Viewer z.B. mit der mobilen App gezielt Metadaten für die gewünschte Re-

gion herunterladen. Dies ist jedoch mit Aufwand verbunden und setzt voraus, dass

man seine zukünftigen Aufenthaltsorte bereits vorausplanen kann. Eine andere Mög-

lichkeit ist es, global verfügbare Display-Apps unabhängig von ihrer lokalen Verfüg-

barkeit auf Displays suchen und zur Verwendung auswählen zu können. Diese wer-

den dann (bei impliziter Nutzung) automatisch dort aufgerufen, wo sie verfügbar

sind. Als Mittel zur Bereitstellung dieser Display-App Metadaten werden im Ab-

schnitt 5.3.1 Display App Stores vorgestellt.

Implizite und Expl izite Interaktion

Mit Hilfe der zuvor erklärten Methoden zur Display-Detektierung sowie mit Hilfe

der lokalen Display-App Metadaten kann nun mit nahen Displays explizit und im-

plizit interagiert werden.

Explizite Interaktion: Hier möchte ein Viewer bewusst und möglichst sofort mit Hil-

fe einer Display App die Anzeige eines nahen Public Displays beeinflussen. Dazu

erhält er über die mobile App eine Liste aller in seiner direkten Umgebung erlaubten

Display Apps, wählt eine dieser Apps aus, gibt ggf. benötige Parameter an und for-

dert schließlich dessen sofortigen Aufruf an. Abhängig von den aktivierten Techno-

logien auf seinem Mobiltelefon (GPS, WiFi, Bluetooth, etc.) werden Displays in der

Nähe unterschiedlich genau detektiert. Befindet sich ein Nutzer z.B. gerade in den

Trigger-Zonen mehrerer Displays (bzw. scannt mehrere Identifier), so wird der Vie-

wer vorher gefragt, an welches der Displays in der Nähe seine Anfrage gehen soll.

Zur Unterstützung bei der Auswahl, können die verfügbaren Displays dem Nutzer

ggf. in einer Kartenansicht präsentiert werden, auf welcher er sich besser orientieren

kann. Falls jedoch genau ein Display detektiert wird, kann die Anfrage über das Mo-

biltelefon des Nutzers sofort abgeschickt werden.

Implizite Interaktion: Bei der impliziten Interaktion mit Public Displays wählt ein

Nutzer bereits im Voraus eine oder mehrere Display Apps aus, die er verwenden

möchte, setzt ggf. benötigte Parameter und aktiviert diese. Während sich der Viewer

nun mit dem Mobiltelefon in der Tasche durch seine Umgebung bewegt, werden

automatisch Public Displays in der Nähe detektiert, auf die Verfügbarkeit der ge-

wünschten Apps überprüft und ggf. Anfragen zur Personalisierung versendet. Ab-

bildung 10 bildet dabei in einem Flussdiagramm die Prozesse ab, die bei diesem

Vorgang in der mobilen App stattfinden. Da Personen sich typischerweise regelmä-

ßig in verschiedenen Situationen befinden, in denen sie ggf. unterschiedliche Bedürf-

nisse bezüglich der gewünschten Inhalte auf Public Displays haben (z.B. Arbeitsum-

feld vs. Shopping-Mall), könnte die mobile App mit Hilfe von Profilen unterschiedli-

che Gruppen von Display Apps unterstützen, die dann einfach bei Bedarf oder auf

Basis von Regeln aktiviert werden könnten. Mögliche Regeln könnten z.B. aus Kom-



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)

[Display Detected]

Display-Metadata

DB

ViewerPreferences

Display-Metadata

[Display App Available]

Display AppMatching

Send Display App Request

Display App Parameters

Proximity and IdentifierSensing

Set Preferences Display AppStore

Abbildung 10: Flussdiagramm der Prozesse auf der mobilen App

Direkte Interaktion mit Display Apps

Wird eine Display App auf einem Public Display gestartet, die direkte mobile Inter-

aktion unterstützt, so kann die mobile App des Viewers genutzt werden, um ggf.

interaktive Inhalte auf dem Display potentiell in „Echtzeit“ zu steuern. Direkte Inter-

aktion per mobile App kann insbesondere nützlich zur Nutzung interaktiver für

Touch-Screens konzipierter Public Display Anwendungen sein, die jedoch auf Public

Displays aufgerufen werden, die gar keine Steuerung per Berührung unterstützen

oder außerhalb 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 tatsächlichen Reak-

tionszeiten zwischen einer Aktion auf der mobilen App und den visuellen Auswir-

kungen auf dem Public Display hängen dabei maßgeblich von der Latenz sowie der

Auslastung der beiden Netzwerkverbindungen ab. Die maßgebende Latenz wird

jedoch typischerweise durch die Mobilfunkstrecke der Gesamtverbindung geprägt.

Tabelle 6 gibt dazu einen Überblick typischer Datenpaket Roundtrip-Zeiten heutiger

Mobilfunk-Technologien.

LTE 30 – 100ms

UMTS mit HSDPA 100 – 200 ms

UMTS 200 – 300 ms



EDGE (EGPRS) 400 – 500 ms

GPRS 600 ms und mehr

Tabelle 6: Roundtrip-Zeiten von Mobilfunk-Technologien7

Die Angaben in Tabelle 6 sind dabei ggf. zu halbieren, da abhängig vom Übertra-

gungsprotokoll nur die Latenz in eine Richtung in die Gesamtreaktionszeit einfließt.

Zusätzlich zur Latenz der Mobilfunkverbindung zwischen der Mobilen App und

einem Mobilfunk Gateway kommt noch die Dauer zum Erreichen des Display App

Hosts, dessen benötigte Processing-Zeit, die Latenz zwischen Display App Host und

Diplay Node sowie schließlich die benötigte Dauer zur Anzeige der Reaktion dazu

(Abbildung 11). Möglichweise ist auch ein Display Node per Mobilfunkanbindung

an das Internet angeschlossen, was die Gesamtreaktionszeit zusätzlich erheblich ver-

schlechtert.

Mobilfunk

Mobile App

Internet Internet /Mobilfunk

Display AppHost

Display Nodemit laufender App

MobilfunkGateway

Abbildung 11: Verbindungsstationen einer persistenten Verbindung zwischen mobiler und Display-

App

Abhängig vom der Art eine interaktiven Public Display App, ist möglicherweise eine

„schnelle“ Reaktionszeit von weniger als 200ms erforderlich um eine positive Benut-

zererfahrung herzustellen. Für andere Display Apps ist möglicherweise sogar eine

Reaktionszeit von 200 – 2000ms noch akzeptabel.

Da durch diese persistente Verbindung nun beliebige Daten zwischen Mobiltelefon

und Display App übermittelt werden können, ist es auch möglich verschiedenste

Interaktionsarten zu unterstützen. So könnten 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

Möglichkeiten vorgeschlagen, um einfache Benutzerschnittstellen zur Interaktion mit

Display Apps anzubieten.

Universelle Benutzerschnittstelle: Um eine einheitliche, Display App übergreifende

Benutzerschnittstelle über die mobile App zu ermöglichen, würden alle Display

Apps über eine gleich aussehende Oberfläche aus der mobilen App bedient. Diese

7 Quelle: http://www.elektronik-kompendium.de/sites/kom/0910251.htm



könnte 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 könnten z.B. schon zum Browsen durch Informationen

auf Public Displays dienen, die aufgrund Ihrer Menge nicht gleichzeitig dargestellt

werden können. Zusätzlich könnten Gesten und Wischbewegungen interpretiert und

als alternative Basissteuerung verwendet werden (z.B. Links, Rechts, Hoch, Runter).

Ein visuelles Feedback auf der mobilen App würde dabei nicht erfolgen, stattdessen

wäre die Wirkung auf dem Public Display zu sehen.

Individuelle Benutzerschnittstelle: Alternativ könnten Display Apps selbst eine op-

tionale separate Oberfläche zum Aufruf auf dem Mobiltelefon des Viewers bereitstel-

len. Diese könnte nicht nur als persönliches Display zur Anzeige ggf. privater Daten

genutzt werden, sondern insbesondere zur Bereitstellung individueller Bedienober-

flächen zur Interaktion mit der dazugehörigen Display App. Die Verfügbarkeit einer

solchen Oberfläche könnte wie üblich über die Display-App Metadaten bekannt ge-

macht werden. Abbildung 12 zeigt eine mögliche Universal-Kontroll-Oberfläche

(links) sowie eine mögliche individuelle gestaltete mobile Bedienoberfläche (rechts),

die in diesem Fall zur Steuerung einer Public Display Tetris App gedacht ist.

Abbildung 12: Beispiel-Oberflächen zur mobilen Interaktion mit Public Displays – Universeller Ansatz (links), Individuelles Kontroll-UI (rechts)

Eine Kombination beider Ansätze könnte 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 Verfügung zu stellen. Wie

dem auch sein, Display Apps können auch ganz auf diese Art der ferngesteuerten

Bedienung verzichten und z.B. nur auf Basis von Display-App Parametern personali-

siert werden. Dies hängt ganz vom interaktiven Charakter der Display App ab.



Feedback

Über die mobile App ausgelöste Anfragen zum Aufruf von Display Apps können

potentiell jederzeit ohne sichtbaren Effekt auf einem nahen Public Display bleiben.

Gründe dafür können Verbindungsprobleme, fehlende oder fehlerhafte Display App

Parameter oder auch Ablehnung durch Display App oder Public Display sein. Ein

Viewer sollte in diesen Fällen informatives Feedback erhalten. Dies sollte in allen Fäl-

len 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 können. Zudem könnte ein Nutzer der implizi-

ten 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 Funktionalität auf die Anzeigeflä-

chen zu bringen. Dazu wählen Display Owner Apps aus, die sie dauerhaft auf ihren

Displays ausführen wollen, sowie Apps, die optional durch Viewer aufgerufen und

angezeigt werden können. Diese Policies werden zusammen mit den Metadaten ei-

nes Displays publiziert und gelangt über Service Directories auf die Mobilgeräte von

Viewern. Viewer erhalten dadurch einen Überblick über die in ihrer Umgebung ver-

fügbaren Display Apps.

Ein bisher wenig behandelter Aspekt dieser Architektur ist jedoch das Finden und

Integrieren von Display Apps, die durch eine Vielzahl verschiedener, potentiell un-

bekannter Application Provider angeboten werden können. 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 wel-

cher die App bzw. dessen Metadaten verfügbar sind.

Als eine Erweiterung der bisherigen Architektur werden deshalb Display App Stores

als zusätzliche (optionale) Komponenten eingeführt, die einen zentralisierten Ansatz

zur Publikation von Display-Apps für 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 er-

folgreiches Mittel zur Publikation und Distribution von Apps für mobile Geräte. Ihr

zentralisierter Ansatz erlaubt es Anwendungs-Anbietern ihre Apps schnell und ein-

fach publik zu machen. Durch die Standard-mäßige Integration von Apple bzw.



Android Geräten mit ihren App Stores, haben Nutzer von Smartphones von Beginn

an Zugriff auf ein riesiges Angebot von Apps. Gleichzeitig erhalten Anwendungs-

Anbieter den potentiellen Zugriffs auf eine riesige Nutzerschaft. Dasselbe Prinzip

soll nun zur Publikation von Display Apps verwendet werden. Wie die Bezeichnung

„App Store“ schon ausdrückt, beinhalten App Stores nicht nur den funktionalen As-

pekt 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 können, gehen

jedoch über den Umfang dieser Arbeit hinaus, und können u.a. in [45] und [46] ver-

tieft 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.

Display App Store

Viewer

DisplayApplication

Display Node Service Directory

RegisterApplication

Browse/Use/BuyApplications

NearDisplay

DownloadDisplay Database

Request Display Foreground /Get Content

Link App StoreDisplay Owner

Build/ProvideRequest

Personalisation

PublishCapabilitiesGet

ApplicationMeta-Data


Assign Apps

Set Preferences

Mobile App

Browse/Use/Buy Applications

Get Analytics

Data

Media Player

Abbildung 13: Basis-Architektur erweitert um Display App Stores

Appl ication Provider

Um eine Display App im App Store publizieren zu müssen, muss der Application

Provider zunächst einmalig ein Benutzerkonto anlegen und sich dann per Benutzer-

name und Password einloggen. Um nun Display Apps seinem Account hinzufügen

zu können, 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 Informatio-

nen 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 für mobile Apps (iTunes, Google Play) übernehmen zudem das

Hosting und die Distribution von mobilen Apps. Da die Tacita Architektur jedoch

offen lässt, wie Display Apps tatsächlich implementiert sind und diese ggf. gar nicht

zu einem ausführbaren Paket kompiliert werden können (z.B. Web-Anwendungen),



soll diese Funktion zunächst 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. Ap-

plikation Provider betreiben in diesem Modell daher eher ihre eigene Infrastruktur

zum Herunterladen bzw. Aufrufen ihrer Display Apps.

Display Owner

Display Owner können nun den Display App Store nutzen um nach gewünschten

Apps zu suchen und eigene Kollektionen anzulegen. Die öffentlich zugängliche Suche

nach Display Apps kann dabei über die üblichen Methoden wie Stichworte, Katego-

rien, Ranking-Listen usw. geschehen. Zu jeder App können ihrer Meta-Daten, wie

Name, Beschreibung, Screenshots übersichtlich betrachtet werden. Zusätzlich könnte

dieApp-Ansicht durch zusätzliche Community-Funktionen, wie Bewertungen und

Erfahrungsberichte ergänzt werden. Ein Display Owner hat nun entweder die Mög-

lichkeit gewünschte Apps einzeln mit Hilfe von Hyper-Links zu deren Metadaten in

die Media Player auf seinen Display Nodes zu importieren oder er erstellt einen ei-

genen Display-Owner Benutzer-Account für den App-Store und legt dort Kollektio-

nen von Apps an. Kollektionen können benannt und ggf. innerhalb des App Stores

für andere sichtbar gemacht werden. Sie können ebenfalls mit Hilfe eines (öffentli-

chen 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 könn-

ten zudem ein Mittel sein, um langfristig Zusammenstellungen von Apps anzubie-

ten, die für spezifische Bedürfnisse bzw. Umgebungen mit Public Display gedacht

sind und ggf. bestimmte Qualitätsanforderungen erfüllen (z.B. Qualität und Aktuali-

tät der App-Inhalte).

Optional können App Stores Display Ownern dazu dienen, Nutzungsstatistiken von

Display Apps auf ihren Display Nodes zentralisiert abzurufen und darzustellen. Die-

se Funktion könnte jedoch ebenso innerhalb der eigenen Infrastruktur der Display

Owner erfolgen.

Viewer

Wie bereits erwähnt, erhalten Viewer mit Hilfe der mobilen App eine Übersicht der

verfügbaren Display Apps in ihrer Region. Die mobile App lädt bzw. aktualisiert

dazu regelmäßig Display-Metadaten für die Region, in der sich ein Nutzer befindet.

Diese enthalten ebenso die Display-App Metadaten der Apps, die die Public Dis-

plays unterstützen. Möchte ein Viewer jedoch eine Übersicht über alle öffentlich ver-

fügbaren Apps erhalten (die ggf. in anderen Regionen verfügbar 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 da-

raufhin über sein Mobilgerät auf Basis unterschiedlicher Kriterien nach Apps suchen,



bzw. einfach durch das Angebot browsen. Die mögliche implizite und explizite Nut-

zung entspricht dem gleichen Vorgehen wie bisher (siehe Abschnitt Mobile App).

Für erweiterte Funktionen wie dem Schreiben von Bewertungen im App Store oder

dem Erwerb nicht-kostenfreier Display Apps (bzw. dessen Nutzungsrecht) müssen

ggf. auch Viewer einen Benutzeraccount im jeweils verwendeten App Store anlegen.

Schnittstel len

Folgende Schnittstellen sollte ein Display App Store zur Erbringung der beschriebe-

nen Minimalfunktionalität anbieten:

API: Display App Store

Users

registerUser(credentials,profile_data): result

login(credentials): token

modifyUser(credentials,profile_data,token): result

unregisterUser(token) : result

Apps

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

Collections

addCollection(name,settings,token): collection_uri

modifyCollection(collection_uri,name,settings,token): collecti-

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

Die ersten vier Aufrufe dienen dem Registrieren, Einloggen, Modifizieren und Lö-

schen eine Benutzer-Accounts. Diese können 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 ver-

fügbar, nimmt als Parameter diverse Filter an (Keywords, Kategorien, usw.) und gibt

eine Liste von Display-App Metadaten zurück. Die restlichen Aufrufe dienen

schließlich der Verwaltung von App-Kollektionen und dessen Zugriff.



Entfaltungsraum für Geschäftsfäl le

Die konkreten Geschäftsfälle, die auf Basis der in dieser Arbeit beschriebenen Archi-

tektur prinzipiell ermöglicht werden, sind sehr vielfältig. Eine Andeutung dieser

Möglichkeiten soll Abbildung 14 anhand möglicher Geschäftsbeziehungen zwischen

beteiligten Stakeholdern geben.

Viewer Display Owner


Advertiser

Buy Apps /Pay for Use

Buy Apps /Pay for Use

Pay for Providing Apps/Embedding Ads

Pay for Displaying Apps with Ads

Pay for Using Apps ( with Ads )

Buy Right to UseDisplays

Offer RewardsFor Use

Offer RewardsFor Use

ContentProvider

Pay forEmbedding

Pay forDelivery

Abbildung 14: Entfaltungssraum für Geschäftsfälle im Kontext der Tacita Architektur

Eine konkrete Ausarbeitung dieser Möglichkeit geht dabei über den Rahmen dieser

Arbeit hinaus. Grundsätzlich, und insbesondere im Kontext des App Stores, lassen

sich jedoch zahlreiche dieser Möglichkeiten unter Vorbild bereits erfolgreicher Ge-

schäftsmodelle durch die Erweiterung der Basisfunktionalität der Tacita-Architektur

hinzufügen.

5.4 Privacy

Die Tacita-Architektur ist kein Ansatz, der es ermöglicht ohne jegliche Preisgabe von

persönlichen Informationen beliebige personalisierte Inhalte auf Pubic Displays zu

zeigen. Stattdessen gibt Tacita Viewern, durch den App-zentrierten Ansatz und die

Möglichkeit der Wahrnehmung von nahen Displays, die Kontrolle darüber, mit wem

sie interagieren und welche Daten die teilen möchten. Diese Kontrolle beginnt bereits

bei der Art die Präsenz eines Viewers in der Nähe von Public Displays festzustellen.

Übliche Ansätze zur Wahrnehmung von Präsenz basieren typischerweise entweder

auf dem fortlaufenden Tracking des Viewers durch die Infrastruktur oder auf Broad-

cast der eigenen Präsenz des Viewers sowie seiner Präferenzen an die gesamte Um-

gebung. Beim Ansatz des Trackings durch die Infrastruktur, muss ein Nutzer meis-



tens vorher auch noch an mehreren Stellen Profile anlegen (potentiell eins für jede

Public Display Infrastruktur unterschiedlicher Display Owner) und dort ggf. seine

Präferenzen 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 Ansätzen, sendet dagegen oft das Mobiltelefon des Viewers

fortlaufend seine eigene Position mit potentiell sehr genauer Auflösung an eine zent-

rale Stelle, die dann ggf. Aktionen auf Public Display auslösen kann. Ist ein Viewer

jedoch in der gesamten Zeit gar nicht in der Nähe eines Public Display gewesen, so

hat die Infrastruktur trotzdem sein präzises Bewegungsprofil erhalten.

Der andere häufig vorzufindende Ansatz zur Personalisierung von Public Displays

durch das fortlaufende Publizieren seiner Präferenzen an die direkte Umgebung z.B.

mit Bluetooth-Geräte-Name, hat den offensichtlichen Nachteil, dass neben der Ver-

folgung der Präsenz einen Nutzers, auch noch jeder in der Umgebung die Präferen-

zen eines Viewers mithören kann.

Möchte ein Nutzer nun ggf. Inhalte auf Public Display in seiner Nähe sehen wie z.B.

die Anzahl neuer Emails in seinem Postfach, so muss er zwangläufig seine Email-

Zugangsdaten mit allen unbekannten Betreibern von Display Infrastrukturen (oder

auch mit allen in seiner Umgebung, falls Bluetooth-Geräte Namen verwendet wer-

den) teilen, da diese benötigt werden um die Anzahl neuer Emails auf dem jeweili-

gen Display anzuzeigen.

Betrachtet man nun im Vergleich dazu den Tacita-Ansatz, so findet sämtliche Inter-

aktion direkt mit Display Apps statt, zu denen ein ggf. temporäres Vertrauensver-

hältnis aufgebaut wurde, anstatt mit der unbekannten Display Infrastruktur. Zwei-

fellos ermöglicht dies den Applikation Providern dieser Apps das zentralisierte

Sammeln von viel mehr Daten, als wenn all diese Daten auf verschiedene unbekann-

te Display-Infrastrukturen verteilt würden. Warum ist also der App-zentrierte An-

satz 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 Vertrau-

ensverhältnis besteht. So werden z.B. die Kreditkartendaten lieber ein Mal an Ama-

zon anvertraut, als diese jedem unbekannten kleinen Web-Shop mitzuteilen.

Führt man sich nun wieder das Beispiel vor Augen, bei dem ein Viewer auf einem

Public Display gerne die Anzahl seiner neuen Emails sehen würde, so ist es ver-

ständlich, dass ein Nutzer dies Daten eher mit einer einzigen Public Display App

teilen würde (welche z.B. bereits durch eine Vielzahl von Nutzern positive Bewer-

tungen erhalten hat), als mit vielen unbekannten Quellen. Dabei ist es absolut vor-

stellbar, dass große Dienste wie Facebook und Google, mit denen bereits Vertrauens-

verhältnisse 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 Fällen sicher nur eine kleine Ergänzung zu den Daten die über viele



Jahre durch Check-ins, Foto-Tagging, Nachrichten-Korrespondenz usw. bereits ge-

sammelt wurden.

Unabhängig von dem App-zentrierten Konzept der Tacita Architektur, bietet dessen

Ansatz zur Wahrnehmung von nahen Public Displays erhebliche Privacy-Vorteile im

Vergleich zu den häufig verwendeten Ansätzen. Da die mobile App mit Hilfe von

lokalen Display-Metadaten bereits alle benötigen Informationen über Public Displays

in der Umgebung verfügt, bewegt sich ein Viewer durch seine Umgebung solange

völlig unsichtbar, bis eine der verwendeten Sensing-Technologien ein nahes Display

detektiert, dass eine gewünschte App anbietet. Da nun die mobile App die Anfrage

zur Personalisierung des Displays gezielt direkt an das Display-App Backend sendet,

bleibt der Nutzer für die Public Display Infrastruktur weiterhin nicht identifizierbar,

Das angefragte Public Display weiß lediglich, dass irgendwer möglicherweise in der

Nähe ist und eine bestimmte App aufgerufen hat.

Ein wichtiger Privacy Aspekt ist sicherlich der Inhalt, den eine Public Display App

anzeigt und somit für die gesamte Umgebung sichtbar macht. Falls diese bereits sen-

sible Informationen über Viewer anzeigt, können diese durch alle Personen in der

Umgebung, jedoch auch durch den potentiell nicht-vertrauenswürdigen Display

Owner wahrgenommen und durch letzteren ggf. auch technisch mitgeschnitten wer-

den. Somit liegt die Verantwortung einerseits bei dem Viewer, sich vor der Nutzung

einer Display App zu informieren, welche Daten diese auf einem Public Display an-

zeigt 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, nämlich 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 Nut-

zerdaten umgehen, sollten dementsprechend über Mittel wie Bewertungen und

Meldesystemen von Nutzern identifizierbar gemacht werden können.

Kapitel 6 - Implementierung


6 Implementierung

Dieses Kapitel beschreibt die prototypische Implementierung der zuvor beschriebe-

nen Tacita Architektur sowie dessen Integration mit Komponenten der e-Campus

Public Display Infrastruktur auf dem Gelände der Lancaster Universität8 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 meis-

ten Komponenten, jedoch insbesondere als Basis zur Entwicklung von Display Apps.

Die verwendeten Technologien sowie Begründungen für deren Einsatz werden nun

im Folgenden gegeben.

HTTP (HyperText Transfer Protocol) soll als das primäre Übertragungsprotokoll zwi-

schen allen beteiligten Komponenten verwendet werden.

Durch seine hohe Verbreitung wird es praktisch durch alle aktuellen Programmier-

sprachen und Systeme umfangreich unterstützt. Desweiteren wird HTTP als das

Übertragungsprotokoll für Webinhalte schlechthin von allen aktuellen Netzwerkinf-

rastrukturen problemlos weitergeleitet (Proxy-Server, Firewalls, etc.) und von Admi-

nistratoren zugelassen. In Kombination mit RESTful (Representational State Trans-

fer) APIs [47] kann es zudem dazu verwendet werden sauber strukturierte, leicht

nutzbare, öffentliche Programmierschnittstellen zu realisieren. Es lässt dabei offen

welche Inhalte darüber transportiert werden können und ermöglicht dadurch eine

Hohe Flexibilität bei der Nutzung. Durch den einfachen Upgrade auf HTTPS (Hyper-

Text Transfer Protocol Secure) lassen sich zudem Inhalte vor dem Abhören durch Un-

berechtigte schützen. HTTP(S) ist ein zustandsloses Protokoll zur asynchronen

Kommunikation und unterstützt keine persistenten Verbindungen.

HTML5, CSS3 und Javascript sollen zur Entwicklung von Display-App Frontends

verwendet werden.

Eines der wichtigsten Argumente für diese Designentscheidung ist die breite Unter-

stützung existierender Media Player zur Darstellung von Webinhalten. Die Möglich-

keiten zur Realisierung attraktiver, interaktiver Public Display Apps auf Basis dieser

Webtechnologien (und insbesondere seit HTML Version 5) sind beinahe unbegrenzt9.

So lassen sich z.B. mit Hilfe von WebGL (Web Graphics Library) und Javascript belie-

bige 2D und 3D Objekte innerhalb einer Website erzeugen und mit Hilfe von hard-

warebeschleunigten 3D-Grafikkarten animieren. Die Ausführung von Javascript

wurde zudem mittlerweile so stark optimiert (z.B. durch die V8 Engine im Webkit),

dass sie mit manchen klassischen Programmiersprachen konkurrieren kann. Deswei-

8 http://www.lancs.ac.uk

9 Übersicht von HTML5 Features: http://slides.html5rocks.com/

http://www.lancs.ac.uk/

http://slides.html5rocks.com/



teren ermöglicht die Nutzung nativer Web-Technologien einem enorm großen Ent-

wicklerkreis den direkten Einstieg in die Entwicklung von Display-Apps. Im Gegen-

satz zu vorkompilierten Anwendungen können Aktualisierungen von Display App

schließlich einfach an zentraler Stelle durchgeführt werden und stehen bereits beim

nächten Aufruf auf Public Displays zur Verfügung.

XML (Extensible Markup Language) und JSON (JavaScript Object Notation) sollen zum

Datenaustausch zwischen Komponenten und speziell zur Definition und Publikati-

on von Display- und App-Metadaten verwendet werden.

XML ermöglicht aufgrund seiner hohen Flexibilität die Abbildung beinahe beliebiger

Datenstrukturen. In Verbindung mit XSD (XML Schema Definition) lassen sich diese

Datenformate präzise spezifizieren und automatisiert validieren, was die Grundlage

für die Interkation heterogener verteilter Systeme darstellt. Für eine effizientere

Übertragung lassen sich XML-Daten jederzeit in das kompaktere JSON-Format um-

wandeln, welches zudem nativ in Javascript interpretiert werden kann.

PHP5, Zend Framework und SQLite sollen schließlich zur Entwicklung von Dis-

play-App Backends dienen, welche serverseitig den Zustand von Display-Apps

verwalten und als Verbindungspunkt für Viewer-Personalisierung und Interaktion

dienen.

PHP5 wird als populäre, flexible und performante Scriptsprache zur Entwicklung

serverseitiger Funktionalität gewählt. In Kombination mit dem Zend Framework,

einer umfangreichen freien Bibliothek von schwach gekoppelten PHP-basierten

Komponenten, können schnell sauber strukturierte, auf dem Model-View-Controller

Entwurfsmuster basierende Anwendungen entwickelt werden. Durch die Nutzung

von SQLite wird außerdem die persistente, strukturierte, serverseitige Ad-hoc Spei-

cherung von Daten ermöglicht. Aufgrund der somit einzigen Umgebungsanforde-

rung eines PHP-Interpreters, können auf diese Art entwickelten Anwendungen ein-

fach per Copy, Paste & Run verteilt und genutzt werden.

An dieser Stelle sei angemerkt, dass der hier verwendete Grundansatz zur Entwick-

lung von Webanwendungen nicht mehr auf der traditionellen Methode basiert, näm-

lich der serverseitigen Generierung und dem Reload von Web-Inhalten bei jeder In-

teraktion 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 Interak-

tion in „Echtzeit“ zwischen der mobilen App von Viewern und webbasierten Dis-

play-Apps zu ermöglichen.



Mit Hilfe der in HTML5 eingeführten Websockets, lässt sich zum ersten Mal eine bi-

direktionale persistente Verbindung zwischen Webseiten und Server-Anwendungen

erstellen, die insbesondere das Auslösen von Ereignissen auf dem Server sofort an

Webseiten weiterleiten kann und somit Webanwendungen mit hohen Reaktionszei-

ten ermöglicht. Node.js10, einem Konsolen-Interpreter für Javascript sowie Socket.IO11

werden dabei verwendet um einen Websocket-Server zu entwickeln, der die Echt-

zeit-Kommunikation zwischen beliebigen verteilten Komponenten ermöglicht.

Android und Java sollen schließlich zur Entwicklung einer mobilen App für Andro-

id-Smartphones verwendet werden, die als eine der wichtigsten Komponenten die

implizite und explizite Interaktion von Viewern mit Public Display Apps ermöglicht.

6.2 Display Apps

Display Apps dienen in der Tacita Architektur als Mittel zur Gestaltung von Inhalten

und Anwendungen für Public Displays sowie als gemeinsame Interessen-

Schnittstelle zwischen den Stakeholdern. Dabei sollen Display Apps verschiedene

Arten der Personalisierung und Interaktion unterstützen - von der Personalisierung

mit Hilfe von Parametern durch Display Owner und Viewer bis hin zur direkten In-

teraktion per Berührung oder der Multi-Viewer Echtzeit-Steuerung per Smartphone.

Im Folgenden wird zunächst der Aufbau von webbasierten Display Apps beschrie-

ben, die all diese Funktionalität unterstützen. Anschließend wird das App-

Metadaten Format auf Basis von XML vorgestellt sowie ein Developer Kit zur Ent-

wicklung von webbasierten Display Apps präsentiert. 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 können 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 für die

(Vollbild-)Anzeige auf großen digitalen Bildschirmen ausgelegt ist. Die Gestaltung

von Anwendungen und Inhalten speziell für die Anzeige auf Public Displays ist da-

bei ein umfangreiches Thema für sich, welches in dieser Arbeit nicht genauer be-

trachtet werden kann, das jedoch immer noch einen großen Forschungsspielraum

10 http://nodejs.org/

11 Eine Abstraktionsschicht für Echtzeit-Browser Kommunikation: http://socket.io/

http://nodejs.org/

http://socket.io/



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 populä-

ren 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 ausgeführt

(analog zum Browser).

Abbildung 15: Aufruf und Anzeige einer Display App ohne Backend (l.) und mit Backend (r.)

Der lokale Javascript-Code kann nun abhängig von dem Zweck der Display App ggf.

Inhalte aus anderen Quellen nachladen (z.B. News-Feeds). Im Prinzip können diese

Inhalte nun von beliebigen Quellen geladen werden. Falls jedoch eine Same-Origin-

Policy der Render-Komponente in Kraft ist, muss der Abruf von externen Informati-

onen ggf. doch über den Host-Rechner geladen werden, von dem die App aufgeru-

fen 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) Ausführung genutzt werden. Über ggf. angebotene Parameter kann auch

dieser Typ von App zudem durch Display Owner konfiguriert werden (z.B. Auswahl

der gewünschten Themen zur Anzeige durch eine News App). Viewer können diese

Art von App nicht beeinflussen, da sie dafür keine Schnittstellen bietet.

Vollwertige Display App

Eine vollwertige Display App besitzt nun auf Serverseite ein App Backend, welches

Schnittstellen zum Aufruf durch Viewer bietet. Nach dem Aufruf eines App-

Frontends 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 unterstützt 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 ausgeführt, 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/

http://www.webkit.org/



einschließlich ihrer Personalisierungs-Parameter für dasselbe Public Display sofort

an das Frontend weitergeleitet werden können. Zusätzlich kann die mobile App zur

Ermöglichung direkter Interaktion in Echtzeit ebenso eine Websocket-Verbindung

zum App-Backend aufbauen, wodurch eine virtuelle Verbindung zwischen App-

Frontend und mobiler App aufgebaut wird, die zur bidirektionalen Full-Duplex

Kommunikation genutzt werden kann. Ein Display Node erfährt dabei nie von wel-

chem Verbindungsendpunkt Viewer Anfragen stammen – eines der wesentlichen

Ziele der Tacita Architektur.

Abbildung 16 veranschaulicht den inneren Aufbau eines App Backends sowie mögli-

che Verbindungen zum Frontend und Viewer-Mobilgeräten.

App Host

App Backend

App Frontend

PHP-Application

SQLite-DBNode.js Websocket

Server

Display Node

Media Player

App Frontend

RESTfulAPI

RequestData(HTTP)

Near

HTTPAPI

Mobile Requests(HTTP)

Viewer

Direct Interaktion(Websocket)

Realtime Data(Websocket)

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 PHP-

Applikation, basierend auf dem Zend Framework13, dient zur Implementierung be-

nötigter Business-Logik und ist in ihrer Minimalausführung für die Verwaltung von

Viewer-Anfragen und dessen Zustand an Frontends auf verschiedenen Public Dis-

plays zuständig. Die SQLite Datenbank wird genutzt um diesen Zustand persistent

zu speichern. Über eine RESTful API wird genau eine Schnittstelle zur Anfrage von

Display Apps für Viewer angeboten, sowie eine oder mehrere zum HTTP-basierten

Abruf von Daten durch das Frontend. Der Websocket-Server dient als Verbindungs-

punkt für Websocket-Verbindungen von Viewern und App-Frontends. Dieser hat

zudem eine interne Schnittstelle (per Loopback Device) über die er Nachrichten von

der PHP-Applikation empfängt. Auf diese Weise können, über HTTP eingehende

Anfragen von Viewern die für bereits per Websockets verbundene Frondends ge-

dacht sind, sofort über die bestehende Verbindung weitergeleitet werden. Der Web-

socket-Server führt dabei eine Liste von offenen Verbindungen, die über die Display-

ID 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

möglich. Zur Ermöglichung von Echtzeit-Kommunikation zwischen Viewer und

13 http://framework.zend.com/

http://framework.zend.com/



Display App Frontend muss der Websocket-Server zusätzlich Buch darüber führen,

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 unterstützt, und ggf. Verbindungsanfragen

ablehnen. Das gesamte Backend bietet im vorgestellten Aufbau lediglich die Basis für

eine Display-App im Rahmen der Tacita-Architektur. Die Voraussetzungen für die

Realisierung komplexerer Business-Logik werden durch die leicht erweiterbare PHP-

Applikation sowie eine bereits vorhandene und leicht ersetzbare SQL-Datenbank

gegeben.

Bisher wurde jedoch noch die der Nutzungsfall erläutert, bei dem eine Display App

noch gar nicht auf dem Public Display läuft, sondern erst durch einen Viewer zum

Aufruf angefordert wird. Abbildung 17 erklärt diesen Nutzungsfall mit Hilfe eines

Sequenz-Diagramms:

mobile App Display App Backend Display App Frontend Media Player

2. RequestApp(App-URI, Callback_URL)

3. App Allowed? [yes]

1 .RequestApp(Display-URI, Display-URL, Params)

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

gewünschten Display App dessen Aufruf auf einem nahen Public Display an.

Über die Display-URI (analog zu Display-ID) wird das Display eindeutig iden-

tifiziert 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.

Sämtliche Parameter können in Form von HTTP-POST-Body Parametern oder

HTTP-GET URL-Parameter übertragen werden (z.B. /index.php?param1=va-

lue1&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 ent-

hält. Die Callback-URL enthält dabei einen Session-ID Parameter, der eine

anonyme Referenz auf den aufrufenden Viewer darstellt und benötigt wird,

um zu identifizieren, welcher Viewer eine Anwendung angefordert hat, so-

bald diese das Frontend zur Ausführung zurückruft.



3. Der Media Player überprüft nun die Anfrage anhand seiner Policy und been-

det diese mit einer positiven oder negativen Antwort (Basierend auf HTTP-

Response Codes sowie ggf. zusätzlichen Fehlernachrichten).

4. Falls die gewünschte App erlaubt ist, wird diese sofort (App-Tiling) oder zum

nächsten möglichen Zeitpunkt (App-Queuing) vom Host des Application

Providers geladen, gerendert und angezeigt (ggf. als eine unter mehreren an-

deren 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 Inter-

aktion in Echtzeit ermöglichen.

6. Die angeforderte Display App wird nun solange ausgeführt, 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 gleichzei-

tig sowohl von einer Vielzahl von Instanzen seines Frontends, die auf verschiedenen

Public Displays verteilt sind, genutzt werden, als auch gleichzeitig durch eine Viel-

zahl von mobilen Viewern. Zudem können App-Frontends, ausgeführt auf den Me-

dia Playern der Public Displays, Inhalte direkt oder ggf. indirekt über ihr Backend

von Content Provider abrufen.

Viewer 1

Request for Display 1

Display Node 1

Media Player

App Frontend

App Host

App Frontend

App Backend

HTTP/Websockets

Display Node 2

Media Player

App Frontend

Display Node n

Media Player

App Frontend

Viewer 2


Viewer n


HTTP/Websockets

HTTP/Websockets

ContentProvider

HTTP

Abbildung 18: Display App Backend als zentraler Verbindungspunkt



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>[email protected]</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 können.

6.2.3 Display App Developer Kit

Um zukünftigen Entwicklern die Erstellung von Tacita-kompatiblen Display Apps

zu erleichtern, die Viewer Personalisierung unterstützen, wird ihnen eine Developer

Kit zur Verfügung gestellt. Dieses besteht aus dem zuvor vorgestellten Front- und



Backend einer generischen Display App (Abbildung 19). Das Front-End besteht da-

bei aus einer Blanko Webseite (index.html) die bereits die zur Kommunikation mit

dem Backend nötige Javascript Library einbindet (PDApp.js) und eine einfache

Javascript API zum behandeln von Viewer Anfragen und direkter Interaktion bietet.

Benötig ein Entwickler keinerlei zusätzliche serverseitige Logik, so braucht er nur

das Frontend nach seinen Wünschen anzupassen.

Display App Developer Kit to be run on Provider Host

App BackendApp Frontend

PHP-Application

SQLite-DBNode.js Websocket

Server

RESTfulAPI

HTTPAPI

PDApp.js

Index.html

Abbildung 19: Display App Developer Kit

Die Javascript-API des Frontends zum Empfangen von Personalisierungsanfragen

während der Laufzeit besteht dabei lediglich aus zwei Aufrufen, die überladen wer-

den müssen, 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 für den Entwick-

ler, als eine Art virtuelles Keyboard integriert. D.h. Tastencodes, die auf dem

Smartphone betätigt werden, werden als Nachrichten über die persistente Verbin-

dung übertragen und über die DOM(Document Object Model)-Event-API der HTML-

Seite als Tastendruck-Events eingefügt.

Mit Hilfe des Developer Kits wird es somit Entwicklern, die lediglich über HTML,

CSS und Javascript Kenntnisse verfügen, ermöglicht innerhalb kürzester Zeit eigene

Display Apps anzubieten, die bereits durch Viewer-Smartphones personalisierbar ist

und direkte Interaktion unterstützt.



6.3 Media Player

In aktuellen Display Netzwerken werden Media Player verwendet um geplante In-

halten mit Hilfe von Playlisten abzuspielen. Diese Inhalte bestehen zumeist aus Bil-

dern, 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 Funktionalität mit Hilfe von Display Apps

realisiert werden. Die Hauptaufgabe eines Media Players in Tacita ist somit die Aus-

führung und Steuerung von Display Apps. Welche Apps dabei dauerhaft aufgerufen

oder spontan durch Viewer angefragt werden können, muss der Display Owner über

diesen Media Player Konfigurieren können. Zudem muss der Media-Player in der

Lage sein seine Fähigkeiten in Service Directories zu publizieren sowie App-Stores

als Quelle für App-Metadaten einbinden zu können.

Führ man sich nun das im vorherigen Abschnitt vorgestellte Konzept von Web-

basierten Apps vor Augen, so fällt auf, dass die Funktionalität von klassischen Play-

listen 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 in-

terpretieren und die Inhalte (Bilder, Videos, andere Webinhalte) nach dem Zeitplan

sequenziell laden und entsprecht skaliert anzeigen. Diese Art von App benötigt da-

bei offenbar nur eine Frontend, da Viewer Personalisierung nicht gewünscht ist. Eine

Display App namens „eChannel Player App“, die exakt auf diesem Prinzip gebaut

wurde, wird im nächsten Kapitel als Beispiel-App präsentiert und im Public Display

Netzwerk der Lancaster University erprobt.

Da nun gezeigt wurde, dass die Funktionalität 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 Ausführung von Dis-

play Apps benötigten, Tacita kompatiblen Media Player selbst als spezielle Web-App

zu implementieren. Die dazu benötigten 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, können dabei problemlos mit Hilfe von Web-

Technologie realisiert werden.

6.3.1 Web-basierter App-Player als Referenz-Implementierung

Tatsächlicher befreit der eben beschriebene Ansatz den Rechner eines Public Dis-

plays (Display Node) vollständig von der Notwendigkeit einen speziellen Media-

Player installieren zu müssen. Stattdessen, wird lediglich ein aktueller Browser benö-

14 Die Erstellung solcher Playlisten wird üblicherweise mit separater, spezieller Scheduling-Software durchgeführt.



tigt, der den Web-basierten App-Player im Vollbild-Modus (Kiosk-Mode) ausführt.

Abbildung 20 illustriert diese verschachtelte Verwendung von Web-basierten Dis-

play Apps. Auf diese Weise lässt sich prinzipiell jeder Rechner mit Bildschirm inner-

halb Sekunden in ein personalisierbares (Public) Display verwandeln.

Display Node

Browser in Kiosk-Mode

App-Player

eChannelPlayer App

eChannelPlayer App

eChannelPlayer AppNews App

Abbildung 20: Web-basierter App-Player ruft eingebettet andere Display Apps auf

Im Folgenden wird dieser Web-basierte App-Player als Referenz-Implementierung

für die innerhalb der Tacita Architektur benötigte Media-Player Komponente vorge-

stellt.

App Player Aufbau

Die Implementierung des App-Players baut dabei auf dem bereits vorgestellten Dis-

play App Developer Kit auf (Abbildung 19). Dementsprechend besteht der Aufbau aus

einem Frontend, dass primär für den Aufruf und die eingebettete Darstellung von

Display Apps zuständig ist, sowie dem Backend, welches die Erreichbarkeit durch

Viewer ermöglicht. Der wesentliche Unterschied zur einer normalen Display App,

welche eine Viewer Personalisierungs-Anfrage erhält, ist, dass das App Player Ba-

ckend 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 Zusammenhänge nicht ganz einfachen zu begreifen, weshalb diese im

Folgenden Schrittweise erklärt werden. Abbildung 21 zeigt dazu den App Player

(Front- und Backend) im Gesamtkontext der Tacita Architektur sowie seiner Nutzer.



Display Node

Browser in Kiosk-Mode

App-Player Frontend

eChannelPlayer App

eChannelPlayer App

eChannelPlayer AppNews App

Viewer

Display Owner

1 .Configure

Display Owner Host

App-Player Backend

App-Player Frontend

News App Host

App Backend

App Frontend

7. Request

8. Website3. Events (Websocket) 2. (Un-)Register Frontend

5. RequestNews App

on nearDisplay

Download/Update

Database

Service Directory

4. PublishDisplay

Metadata

Available AppsFrom Display App Store

Provides


6. Request to beshown

Abbildung 21: App-Player im Gesamtkontext der Tacita Architektur

Der Folgende Ablauf bezieht sich auch Abbildung 21 und beschreibt das Konfigurie-

ren und Aktivieren des App-Players auf einem Display-Node sowie die anschließen-

de 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 sei-

ner eigenen Infrastruktur gehostet wird, auf und setzt einmalig die zum Be-

trieb des App-Player nötigen Einstellungen. Unter anderem verlinkt der Dis-

play Owner einen Display App Store und kann nun aus dessen Datenbank

Display Apps selektieren, die er dauerhaft auf seinem Public Display ausfüh-

ren will oder zum Aufruf durch Viewer erlaubt. Diese Einstellungen werden

persistent gespeichert und zur Generierung des Display Metadaten verwen-

det.

2. Sobald der Display Owner das App-Player Frontend über einen Knopfdruck

aktiviert hat, wird dieses mit seinen Einstellungen im Backend registriert und

steht für Viewer Anfragen zur Verfügung.

3. Gleichzeitig baut das App Player Frontend zum Backend eine persistente

Websocket-Verbindung auf, die dazu genutzt wird Viewer-Anfragen ohne

Verzögerung zu übermitteln.

4. Weiterhin werden im Backend die Display-Metadaten des gerade registrier-

ten Frontends generiert und in einem durch den Display Owner spezifizier-

ten Service Directory publiziert bzw. aktualisiert.

5. Ist nun ein Display Owner in der Nähe diese Public Displays und möchte im-

plizit oder explizit die „News App“ auf diesem Bildschirm aufrufen, dann

muss seine mobile App dies beim Backend der News App anfragen.



6. Dieses fragt nun selbst das Backend des App-Player an, um von diesem auf-

gerufen zu werden.

7. Das App-Player Backend überprüft 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.

Oberfläche

Die Oberfläche des App Players ist dazu gedacht im Vollbildmodus ausgeführt zu

werden. Abbildung 22 zeigt diese im passiven Modus an (keine ausgeführten Apps).

Die gesamte Anzeigefläche des App Players steht für die Darstellung von Apps zur

Verfügung. Lediglich ein QR-Code auf der Linken sowie ein kleiner Knopf auf der

rechten Seite, der zum Aufruf des Menüs 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 An-

satz zur Validierung der Präsenz eines Nutzers vor genau diesem Public Display mit

Hilfe des sich periodisch ändernden QR-Codes realisiert.

Über das Konfigurations-Menu des App-Players müssen zunächst Grundangaben

wie Display-URI (analog zu Display-ID), Name, Geoposition, Sichtfeld sowie Anbie-

ter Angaben eingetragen werden (Abbildung 23, links). Über den Reiter „Apps“ lässt

sich ein Display App Store durch Angabe seiner URL einfinden. Anschließend kön-

nen aus der Liste verfügbarer Apps, einschließlich deren Beschreibung, diejenigen

ausgewählt werden, die zur dauerhaften Ausführung genutzt werden sollen

und/oder jene die zum Aufruf durch Viewer erlaubt werden (Abbildung 23, rechts).

Ebenso können über die Viewer-Policy grundsätzlich alle Apps erlaubt bzw. verbo-



ten werden. Für jede ausgewählte App können nun ggf. verfügbare Personalisie-

rungs-Parameter für Display Owner gesetzt werden. Hat eine Display-Owner alle

nötigen Angaben gesetzt (u.a. auch die URL eines Service Directories), dann kann er

den „Active“ Knopf betätigen und den App Player und somit sein Public Display am

Backend und im Service Directory registrieren. Display Apps, die zur dauerhaften

Ausführung ausgewählt wurden, werden sofort nach der Aktivierung ausgeführt

und angezeigt. Wurden mehrere ausgewählt, so wird die Anzeigefläche entspre-

chend aufgeteilt (siehe nächster 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 Ausführung von multiplen Apps eingestellt werden. Wie bereits im

vorherigen Kapitel erläutert, können gleichzeitige Anfragen für unterschiedlich Dis-

play Apps entweder auf Basis von Warteschlangen und der sequenziellen Anzeige

dieser Apps als Vollbild oder durch das Aufteilen des Bildschirms und die gleichzei-

tige Anzeige der Apps, gelöst werden. Der App Player implementiert dazu nur die

letzte Strategie. Dazu wird der Bildschirm dynamisch bis zu einer einstellbaren Ma-

ximal-Anzahl von Apps in gleich große Bereiche geteilt (Abbildung 24). Konkret

werden zum eingebetteten Ausführen der Apps HTML-IFrame-Elemente verwendet.

Zusätzlich lässt sich einstellen wie lange eine durch Viewer aufgerufene App maxi-

mal angezeigt wird, wenn der gleiche Viewer in der Zwischenzeit keine neue Anfor-

derung geschickt hat.



Abbildung 24: App Player – Aufteilen der Anzeigefläche zwischen Apps (Tiling)

Eine Reihe von Bildern, die den App-Player und dessen Tiling-Konzept im Einsatz

mit echten Display-Apps zeigt, werden im nächsten Kapitel vorgeführt.

Vorteile des App Players

Die Verwendung des App Players, und damit eines vollständig Web-basierten An-

satzes bietet viele Vorteile:

Plattformunabhängigkeit: Durch den rein Web-basierten Ansatz, lässt sich

der App Player auf jeder Plattform die Webseiten aufrufen kann, ausführen.

Zentralisiert: Dadurch, dass das App Player Backend auf einem Webserver

ausgeführt 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 ermöglicht eine zentralisierte Verwaltung und

Wartung dieser Komponente.

Erreichbar: Der zentralisierte Ansatz des App Player Backends ermöglicht es,

lediglich diesen Rechner dem freien Internet exponieren zu müssen, jedoch

seine Frontends hinter beliebigen Firewalls und NAT(Network Address Transla-

tion)-Netzwerken betreiben zu können. Dies ermöglicht z.B. den Betrieb des

App Players an einem Rechner an einem ggf. öffentlichen WLAN, jedoch wei-

terhin die Fähigkeit von beliebigen Viewer in der Nähe personalisiert zu wer-

den 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 ermöglicht

dessen Aufruf durch traditionelle Media Player (falls diese Webinhalte unter-

stützen) 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: Abs-

trakte Metadaten – Public Display) wurden ebenso wie die App-Metadaten konkreti-

siert und ins XML-Format übertragen. Ein Beispiel der Metadaten eines Public Dis-



plays können 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 regis-

triert.

Möchte ein Display Owner keinerlei Personalisierungs-Möglichkeiten für Viewer

anbieten, so kann er den App Player trotzdem nutzen, braucht diesen jedoch in kei-

nem Service Directory zu registrieren.

6.3.3 Integration mit e-Campus Media Player

Anstatt des im Rahmen dieser Arbeit entwickelten App-Players, kann auch jeder an-

dere Media Player in die Tacita Architektur integriert werden, solange dieser die be-

nötigten Schnittstellen implementiert (siehe. Kapitel 5, Tabelle 3). Genau dies wurde

mit dem an der Lancaster University entwickelten und auf dem dortigen Public Dis-

play Netzwerk betriebenen Yarely Media Player durchgeführt.

Dem in Python implementierten Player, der hauptsächlich zur Wiedergabe von ge-

planten Inhalten auf Basis von Playlisten aus dem dortigen e-Channel-System ge-

nutzt wird, wurde eine Schnittstelle hinzugefügt, 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 höherer Priorität behandelt und haben dadurch die Playlisten An-

zeige einfach überlagert. Die Web-Renderer Komponente dieses Python Players hat

dabei die über die Schnittstelle angeforderten Display Apps Anhand ihrer Callback-

URL aufgerufen und angezeigt. Eine Policy Implementierung sowie eine automati-

sche Generierung von Metadaten und dessen Registrierung in einem Service Directo-

ry, wie beim App Player, wurden jedoch nicht implementiert. Um die Existenz dieser

Player jedoch trotzdem für mobile Viewer sichtbar zu machen, wurden die Display-

Metadaten 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 Me-

dia Playern genutzt um deren Existenz und Fähigkeiten zu publizieren. Auf der an-

deren Seite dienen Service Directories dem Abruf von Metadaten durch die mobile

App von Viewern. Dabei können Viewer Meta-Daten für 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 server-

seitigen Anwendungen dieser Arbeit, auf dem Model-View-Controller Architektur-

muster und verwendet zudem mehrere Abstraktionsschichten zur Realisierung von



ORM (Object Relational Mapping). Weitere Implementierungsdetails sollen an dieser

Stelle jedoch ausgelassen werden.

Die API ermöglicht das Registrieren von Metadaten geschützt durch ein Passwort,

sowie das Aktualisieren und löschen dieser Metadaten unter Angabe dieses Pass-

worts. 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 getätigt, welche im nächsten Abschnitt vorgestellt wird.

Abruf für ganze Regionen

Eine Besonderheit der Service Directory Implementierung liegt dabei in der Bereit-

stellung der Schnittstelle für die mobile App der Viewer zum Abruf von Metadaten

für ganze Regionen, die lediglich über ihre Art (Land, Bundesland, Region, Stadt,

Strasse, usw.) und ein Schlüsselwort („Düsseldorf“) spezifiziert werden. Da diese

Daten nicht mit den Display-Metadaten geliefert werden, müssen diese beim regist-

rieren jedes neuen Displays neu herausgefunden werden. Dazu wird einfach die

Geoposition des Public Display (aus den Metadaten) verwendet, um über den Goog-

le-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 ermög-

licht diesen selbst zu entscheiden, wie genau sie die Position, an der sie sich befinden

und für die sie Display-Metadaten benötigen, angeben möchten.

Alternativ kann der Abruf auch für kreisförmige Bereiche erfolgen (durch Angabe

des Zentrums und eines Radius).

Inkrementel le Aktual isierungen und Datenreduktion

Eine weitere Besonderheit der Schnittstelle zum Abruf von Metadaten, ist ihre Fä-

higkeit inkrementelle Aktualisierungen auf Basis des Zeitpunktes des letzten Abrufs

zu ermöglichen. Dadurch kann die zu übertragende Datenmenge ggf. drastisch re-

duziert werden. Bei Nutzung dieser Möglichkeit werden so lediglich alle Metadaten-

sätze die sich geändert haben, oder die neu sind vollständig übertragen. Für alle an-

dere wird lediglich ihre ID übermittelt, damit die mobile App lokal feststellen kann,

welche Displays gelöscht wurden.

Ein weiteres Mittel zur Reduktion von redundanten Daten liegt in dem Ansatz, alle

von Displays verwendeten App-Metadaten in einem separaten Bereich der Rückga-

bedaten zu sammeln und diese lediglich aus den Display-Metadaten heraus zu refe-

renzieren. Auf diese Weise beinhaltet z.B. ein Suchergebnis mit 1000 Display-

Metadaten die alle die gleiche App unterstützen lediglich eine Instanz dieser App-

Metadaten.

Schließlich wird zur Übertragung an mobile Geräte 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 Architek-

tur (Mobile App), wurde diese auf Basis des Android Plattform15 für Smartphones

prototypisch implementiert. Die Wahl für Android wurde zum einen durch seine

umfangreichen Möglichkeiten zum Zugriff auf Sensoren, wie GPS, Bluetooth, Kame-

ra, usw., sowie seine Multi-Threading Fähigkeiten motiviert und zum anderen durch

dessen hohe Verbreitung und einfaches und flexibles Publikationskonzept (im Ge-

genteil zu z.B. Apple iOS).

Haupt-Funktionen

Die Aufgabe der mobilen App ist es seinem Nutzer (Viewer) die implizite und expli-

zite Interaktion mit nahen Public Displays zu ermöglichen. Die Tacita-Architektur

ermöglicht dabei, dass eine Viewer zu dieser meistens unbekannten Public Display

Infrastruktur keinerlei Vertrauensverhältnis aufbauen muss, um diese nutzen zu

können. In der Tat bleibt ein Viewer, falls er es möchte, für Public Displays und des-

sen Betreiber völlig unsichtbar. Stattdessen wählt ein Viewer Display Apps (ähnlich

zu Apps für Smartphones) aus, personalisiert diese und fordert deren Anzeige auf

nahen Public Displays aus, die diese Apps erlauben.

Zur Realisierung dieser Funktionalität muss ein Viewer über seine mobile App Zu-

griff auf verfügbare Display Apps haben können, gewünschte Apps auswählen und

personalisieren können, sowie den Aufruf dieser Apps explizit oder implizit auf na-

hen Displays anfordern können. Weiterhin soll ein Viewer nach dem Start seiner an-

geforderten Display App über sein Smartphone in Echtzeit mit dieser interagieren

können. 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. Zwi-

schen den Ansichten wird über die angeboten Schaltflächen navigiert. Zusätzlich

sieht das Android-Bedienkonzept eine jederzeit mögliche Rückwärtsnavigation

durch die zuletzt aufgerufenen Ansichten vor, sowie das wechseln zu anderen An-

wendungen oder zur Wallpaper-Ansicht. Activities, die nicht mehr sichtbar sind

werden angehalten und können daher nicht mehr weiterhin Code ausführen.

Das Konzept dieser mobilen App erfordert jedoch für viele Funktionen (wie periodi-

sche Aktualisierungen, Positionsbestimmung, Scans und persistente Verbindungen)

eine dauerhafte Ausführung unabhängig vom Zustand der Benutzeroberfläche. Dies

15 http://developer.android.com



wird durch die Nutzung eines Android Service realisiert. Die Steuerung des Service

und somit der darin ausgeführten Prozesse wird über einen Knopf im Benutzerinter-

face ermöglicht, welcher leicht über jede Activity zugänglich ist. Is der Service aktiv,

so laufen alle wichtigen Prozesse weiter auch wenn eine andere Anwendung in den

Vordergrund Gerät. 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 möchte.

Display- und App-Metadaten

Da die Tacita-Architektur auf dem Modell basiert, bei dem die mobilen Nutzer Pub-

lic Displays in der Nähe detektieren und nicht umgekehrt, muss die mobile App über

Informationen zu deren Position oder mögliche Identifier (z.B. Bluetooth MAC-ID)

verfügen. Diese Display-Meta Daten werden von der Android-App regelmäßig für

die Region des Viewers heruntergeladen und aktualisiert. Der Nutzer konfiguriert

dabei über die Einstellungen eine von drei Regionsgrößen (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 Regionsgröße und Regionsname wird an-

schließend 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 lässt

sich diese URL jederzeit ändern sowie zusätzliche Service Directories hinzufügen.

Falls Public Displays in der Nähe dies anbieten, kann die Android App sogar die

URLs von verwendeten Service Directories automatisch aus den Bluetooth Geräte

Namen dieser Public Display extrahieren (Service Directory Discovery). Die vom Ser-

vice Directory heruntergeladenen Display-Metadaten im JSON-Format erhalten alle

Informationen zu den Displays der Region, sowie die App-Metadaten der Display-

Apps, die sie unterstützen.

Zur Ermöglichung von effizienten, lokalen Daten-Abfragen, wird die auf Android

nativ unterstützte SQLite16 Datenbank zum abspeichern der Metadaten verwendet.

Dabei werden diese in eine Tabelle für Displays und eine für Display-Apps aufge-

teilt, sowie eine weitere, die deren n:n Relation abbildet. Für SQL-Abfragen relevante

Felder (ID, Lat, Lng, BT-Identifier, App-Policy, letzte Aktualisierung) werden zusätz-

lich zu einem Feld mit dem gesamten Eintrag im JSON-Format in separaten Tabel-

lenfeldern abgespeichert. Nach dem Herunterladen der Display-Metadaten vom Ser-

vice Directory werde diese mit einem JSON-Parser gelesen und in die Datenbank

überführt, bzw. dessen Einträge aktualisiert. Dieser gesamte Vorgang passiert im

Hintergrund, wird lediglich durch eine unaufdringliche Progress-Bar signalisiert und

stört den Nutzer nicht bei der Interaktion.

16 http://developer.android.com/reference/android/database/sqlite/package-summary.html



Über den Download der Display-Metadaten erhält ein Viewer auch die Metadaten

der Displays Apps, die durch diese Displays unterstützt werden. Möchte ein Viewer

jedoch noch andere öffentlich verfügbare Apps nutzten (z.B. auf Displays die grund-

sätzlich die Ausführung aller Apps erlauben), so muss er zusätzlich einen Display

App Store einbinden. Die mobile App ermöglicht dazu einfach das Eintragen einer

App Store URL (oder potentiell mehrerer) über die Einstellungen. Anschließend ver-

bindet sich die mobile App periodisch mit der API dieses App Stores, ruft die ver-

fügbaren App-Metadaten ab, und aktualisiert seine App-Datenbank-Tabelle. Der

simple Abruf aller Daten dient dabei nur der Einfachheit. Eine fortgeschrittene Ver-

sion der mobilen App sollte dagegen die gezielte Suche von Apps erlauben (Die App

Store API bietet diese Funktion auch bereits an).

Auswahl und Personal isierung von Display-Apps

Die mobile App erfordert von ihrem Nutzer im Prinzip nur das Auswählen von Dis-

play Apps zur Nutzung sowie ggf. deren Personalisierung durch Parameter. Die

Oberfläche startet deshalb direkt nach der Anzeige des Splash-Screens direkt mit der

Listen-Ansicht aller verfügbaren 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 verfügbaren 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 Check-

boxen, Auswahlfelder, etc. unterstützen. Aus der Detailansicht lässt sich über Schalt-

flächen die App aktivieren, die direkte Interaktion starten (falls verfügbar) oder eine

Kartenansicht anzeigen, die Public Displays im Umkreis anzeigt (und ob die aktuelle

App durch diese unterstützt wird). Die alle Einstellungen aktivierter Apps und des-

sen Parameter werden lokal persistent gespeichert.

Publ ic Display Sensing

Nach dem Abruf der regionalen Display-Metadaten und der Auswahl und Persona-

lisierung gewünschter Apps muss die mobile App wahrnehmen können, wann sie in

der Nähe von Public Displays ist, die die gewünschten Apps zur Ausführung erlau-

ben. Die App verfügt dabei bereits über alle Informationen um, Anwendungen auch

aus der Ferne auf Public Displays anfordern zu können. Eine klare Designentschei-

dung ist es jedoch, Anwendungen nur anzufordern, wenn der Viewer mit seinem

Mobilgerät tatsächlich in der Nähe ist. Außerdem können Public Displays auf Basis

von Presence Token die Validierung der Viewer-Präsenz erzwingen sowie andere Me-

chanismen zur Vermeidung von Missbrauch einsetzten (z.B. Request Quotas). Zur

Detektierung von nahen Displays wurden sowohl der Ansatz basierende auf absolu-

ter Position als auch jener auf Basis von Identifiern implementiert (siehe Mobile App).

Die Detektierung, basierend auf absoluter Position, nutzt GPS und WiFi-

Fingerprinting17 des Smartphones zur Bestimmung der eigenen Position. Dazu biete

Android eine einheitliche Schnittstelle, die u.a. die Angabe der gewünschten Positi-

ons-Genauigkeit benötigt und im Anschluss Positionsänderungen in Form von Er-

eignissen zu melden. Die mobile App verwendet dazu zwei unabhängige Location-

Listener, die Positionsänderungen 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 nötigen Informa-

tionen werden durch Display Owner über ihre Media Player modelliert und mit Hil-

fe 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 quadra-

tischen18 Bereich von 200 Metern um die eigene Position befinden. Dies redu-

ziert alle folgenden Abfragen auf eine relativ begrenzte Menge.

2. Aus dieser Menge werden diejenigen selektiert, die mindestens eine ge-

wünschte App oder grundsätzliche alle Apps unterstützen.

3. Zuletzt wird diese Menge auf alle Displays reduziert, in dessen Trigger-Zone

sich der Viewer mit seinem Mobilgerät gerade befindet (Abbildung 26, mitte).

17 Die Positionsbestimmung über WiFi wird bereits transparent für den Entwickler über Google-Dienste realisiert

18 Punkt in Quadrat SQL Abfragen sind günstiger als Punkt in Kreis Abfragen



Die Bestimmung ob die eigene Position innerhalb eines Kreissektors liegt, ba-

siert 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 Dis-

play Infos(r.)

Zusätzlich zur der gerade erläuterten Detektierungs-Methode wird die Wahrneh-

mung von Public Display Identifieren auf Basis von Bluetooth unterstützt. In einem

separaten Prozess des App-Services werden dazu fortlaufend Bluetooth Inquiry Scans

durchgeführt. Diese periodischen Scans liefern alle Bluetooth-MAC-Adressen und

Gerätename von Bluetooth Geräten in der Nähe. Abhängig von deren Geräteklasse

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

können nun mit einer einfachen Abfrage alle Displays in der Nähe identifiziert wer-

den. Sendet ein Public Display zudem ein Presence Token in seinem Geräte-Name, so

wird dieses als zusätzlicher Parameter in den folgenden Anfragen verschickt. Wie

zuvor werden die detektierten Displays auf App-Unterstützung überprüft und ggf.

Anfragen zum Aufruf von Apps gestartet (jedoch indirekt über deren App Hosts).

Die Häufigkeit von Anfragen an die gleiche App wird durch eine maximale Rate be-

grenzt (z.B. 1 Anfrage / 10s). Außerdem nutzt die App lediglich die ihm gerade zur

Verfügung stehenden Technologien, d.h. ein Nutzer kann GPS, Bluetooth und WiFi

jederzeit aus oder dazu schalten. Desto mehr Sensoren zur Verfügung stehen, desto

19 Ausgehend vom geographischen Nordpol



genauer und zuverlässiger lassen sich nahe Displays potentiell wahrnehmen. Eine

absolute Anforderung zur Ermöglichung dieser Anfragen ist jedoch die Verfügbar-

keit einer Internetverbindung.

Implizite und Expl izite Interaktion

Der Nutzer kann die Anfragen zur Anzeige von Apps nun implizit oder explizit nut-

zen.

Bei der impliziten Nutzung wählt der Viewer im Voraus Anwendungen aus, die er

sehen möchte, sobald er an Public Displays vorbeikommt, die diese Apps unterstüt-

zen. Ebenso muss es bereits vorher seine Personalisierungs-Parameter setzten. Nun

muss er lediglich die Haupt-Kontroll-Schaltfläche betätigen, um den Hintergrund-

dienst und somit die Detektierungs-Prozesse zu starten und kann sein Smartphone in

seiner Hosentasche versenken. Sobald ein Viewer nun in die Trigger-Zone oder Blue-

tooth-Reichweite eines Public Displays gelangt, welches die gewünschten Apps un-

terstützt, 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 nächsten Ka-

pitel). Es ist dabei offensichtlich, dass der Nutzer nicht immer das von ihm implizit

personalisiere Public Display wahrnimmt, allerdings machen die ersten beiden Sze-

narien aus In diesem Kapitel werden funktionale und qualitative Anforderungen für

eine Architektur formuliert, die die anonyme implizite und explizite Ad-hoc Interak-

tion mit unbekannten Public Displays über das Mobilgerät von Viewern ermöglichen

soll. Um diesen Anforderungen mehr Hintergrund zu geben, werden im Folgenden

drei Szenarien verwendet.

Nutzungs-Szenarien die Nützlichkeit dieses Modus deutlich.

Möchte ein Nutzer explizit mit einem Public Display in der Nähe interagieren, so

geht er auf gleiche vor. Er wählt die gewünschte(n) App(s) aus, setzt die Parameter

und aktiviert die App. Die Personalisierung des Displays wird nun so lange fortge-

setzt, bis der Viewer die App wieder deaktiviert oder er aus der Reichweite Gerät.

Der Fall, dass mehrere Displays gleichzeitig in Reichweite und potentiell

personalisierbar sind, und deshalb ggf. nur eins ausgewählt werden muss, wird

durch den aktuellen Prototyp vernachlässigt. Eine weitere Methode zur direkten In-

teraktion wird durch das scannen der vom Public Display generierten QR-Codes er-

möglicht, 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 Abläufen.

Fernsteuerung

Hat ein Viewer bereits eine Display App aufgerufen, die direkte Steuerung per Mo-

bilgerät unterstützt, dann lässt sich, wie in Abbildung 27 gezeigt, die Ansicht zur



direkten Steuerung aufrufen. Im Hintergrund wird dabei eine Websocket-

Verbindung zum Backend der aufgerufenen App hergestellt, die alle Befehle potenti-

ell in Echtzeit an das auf dem Public Display ausgeführte Frontend sendet. Die Reak-

tionszeit des Displays ist dabei insbesondere von der Qualität, Auslastung und La-

tenz der auf dem Übertragungsweg liegenden Mobilfunk-Verbindungen abhängig.

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

gedrückten Tasten werden dabei an das ausgeführte Frontend der Display App ge-

sendet und in das DOM-Event-Model der Webseite eingeschleust. Auf diese Weise

erscheinen diese Tastendruck-Ereignisse der Frontend-Webseite als kämen sie von

einer lokalen Tastatur. Diese einfache Methode ermöglicht 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 un-

terstützen, erweitert dieser Ansatz deren Fähigkeiten zur direkten Interaktion ohne

jeglichen Konfigurationsaufwand. Eine fortgeschrittene Version könnte an dieser

Stelle zusätzlich leicht die Steuerung durch Gesten oder Wisch-Bewegungen imple-

mentieren.

Feedback

Um Nutzer darin zu unterstützen das Verhalten der App nachvollziehen zu können,

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. Wei-

terhin ist die Sensor-Quelle ersichtlich, über die die Anfrage ausgelöst wurde. Die



Kartenansicht bieten dagegen eine Übersicht aller Displays in der Umgebung (sowie

der gesamten Region) und zeigt dabei an, ob die gerade ausgewählte Display App

von den Displays unterstützt wird (Abbildung 26, links). Zudem wird die eigene Po-

sition angezeigt, was dem Viewer die Möglichkeit 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 entspre-

chend viel Energie und führt daher ggf. zu einer stark verkürzen Laufzeit. Der Proto-

typ verwendet dabei zur Erhaltung der Einfachheit die bestmögliche Präzision der

gerade verfügbaren Sensor-Quellen. Ebenso wird, sobald der Nutzer den

Detektierungs-Prozess aktiviert, der periodische Bluetooth Scan dauerhaft gestartet.

Eine fortgeschrittene Version dieser App würde diese Scan-Prozesse auf Basis vor-

handener Informationen intelligent steuern und somit den Energieverbrauch ggf.

drastisch senken ohne die Detektierungs-Genauigkeit zu verschlechtern. Diese intel-

ligente Steuerung könne z.B. auf Basis der jederzeit verfügbaren groben Position auf

Basis von Mobilfunkmasten sämtliche Scan-Prozesse anhalten, da sich weit und breit

keine Public Display befindet. Analog könnte dieser Ansatz auf die präziseren Ebe-

nen übertragen werden, so dass der Bluetooth-Scan tatsächlich erst gestartet wird,

wenn der Viewer sich in der Nähe von Displays mit Bluetooth-Support befindet.

6.6 Minimaler Display App Store

Der Display App Store ist eine architektuelle Komponente zur zentralisierten Publi-

kation 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 vorge-

schlagenen Schnittstelle (Tabelle 7: Abstrakte API – Display App Store) implemen-

tiert, der das Registrieren, Aktualisieren, Löschen und Anrufen von App-Metadaten-

Einträgen erlaubt. Eine Übersicht über die Aufrufe dieser RESTful API findet sich in

[Anhang A1: RESTful APIs von Komponenten]. Da weder User-Accounts, noch App-

Kollektionen implementiert wurden, wird ein Password zum Schutz von Einträgen

verwendet. Desweiteren ist entweder der Abruf aller App-Metadaten möglich, oder

nur derjenigen, die zu einem Suchwort passen.

Die Minimal-Implementierung des App-Stores ermöglicht jedoch bereits die Integra-

tion mit dem App Player sowie der mobilen App und damit deren bequemen Zugriff

auf existierende Display Apps. Eine Webseite ermöglicht zudem die einfache Formu-

lar-basierte Registrierung, Aktualisierung und Entfernung von Apps, ohne die

RESTful API direkt ansprechen zu müssen. Dies dient genau genommen lediglich als

GUI für die API. Die Webseite, benötigt zur Registrierung und Aktualisierung eines



Eintrages lediglich ein Password, sowie eine URL, von der die App-Metadaten her-

untergeladen werden können (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 für

eine Weiterentwicklung und Ergänzung des Display App Stores mit zusätzlicher

Funktionalität dar.

Kapitel 7 - Evaluation


7 Evaluation

Während 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 ver-

teilten Public Display Infrastruktur, zu evaluieren.

Die Evaluation wurde dabei in drei Schritten durchgeführt. Im ersten Schritt wurden

die zuvor implementierten Komponenten mit Hilfe eines mehrwöchigen

Deployments auf Funktionalität und Integrierbarkeit mit der dortigen Infrastruktur

überprüft. In einem zweiten Schritt wurden zunächst experimentell mittlere Netz-

werkverzögerungen gemessen und dann auf Basis eines „Pass-By“-Szenarios in ins-

gesamt 84 Testläufen die Effektivität mit der Display Apps auf Public Displays durch

vorbeigehende Viewer aufrufen werden können, an zwei unterschiedlichen Standor-

ten quantitativ festgestellt. Zuletzt wurde mit Hilfe mehrerer auf Basis des Display

App Developer Kits erstellten Display Apps, der Designraum für Display Anwendun-

gen, die auf der Tacita-Architektur aufsetzen, erforscht und die Nutzbarkeit dieses

Kits durch verschiedene Anwendungen praktisch überprüft.

7.1 e-Campus Deployment

Um die Funktionalität und die Integrierbarkeit mit einer realen genutzten Public

Display Infrastruktur zu testen, wurden die im letzten Kapitel präsentierten Kompo-

nenten für mehrere Wochen auf der Infrastruktur des Lancaster University e-

Campus Systems installiert. Dazu wurde die bis dahin genutzte Media Player Soft-

ware auf drei Display Nodes auf dem Campus sowie drei Display Nodes im

InfoLab21-Gebäude deaktiviert und stattdessen der Web-basierte App-Player im Ki-

osk-Modus des Chrome-Browsers ausgeführt. Da diese Public Displays, wenn sie

gerade nicht personalisiert wurden, weiterhin die über das e-Channel-System publi-

zieren Inhalte als traditionelle Playlist wiedergeben sollten, wurde eine „e-Channel

Player“ App entwickelt, die diese Aufgabe erfüllt und einfach dauerhaft vom App

Player ausgeführt wird (Das e-Channel-System und die e-Channel Player App wer-

den im übernächten Abschnitt genauer vorgestellt). Auf diese Weise konnte optisch

kein Unterschied zum bis dahin verwendeten Player festgestellt werden (außer den

QR-Code in der linken unteren Ecke). Über den App-Player wurden für jedes der

sechs Public Displays der Lage entsprechende Trigger-Zonen gewählt sowie bis dato

verfügbare Display Apps zur Personalisierung ausgewählt (News und Wetter-App).

Diese Daten wurden automatisch im Service Directory gespeichert und konnten da-

her von den mobilen Apps im Einsatz abgerufen werden. Mehrere Mitarbeiter aus

dem InfoLab21, die sich auch regelmäßig auf dem Campus aufhalten, wurden

schließlich geben die mobile auf ihren Android-Smartphones zu installieren und

über die nächsten Wochen zu Testen. Um eine Konfiguration herzustellen, die eher

denen von Display Ownern und Application Providern entspricht, wurden der App-

Player und die verfügbaren Display-Apps auf separaten öffentlicher erreichbaren



Servern installiert (anstatt alle auf einem). Dies sollte bei Messungen zur realistische-

ren Reaktionszeiten führen.

Zu Beginn der Testphase konnten insbesondere einige Probleme mit der Android-

App und unterschiedlichen Smartphones behoben, sowie Verbesserungsvorschläge

integriert werden. Unter anderem wünschten sich Nutzer mehr Kontrolle, z.B. um

jederzeit selbst die Aktualisierung von Display-Metadaten manuell auslösen zu kön-

nen. Bei der Anzeige von Display Apps wurde zudem eine längere Mindest-

Anzeigezeit von >20 Sekunden erwünscht. In den meisten Fällen wurde durch die

Nutzer berichtet, dass sie Inhalte auf den nahen Displays auslösen konnten. Desöfte-

ren mussten die dazu jedoch ggf. bis dahin nicht aktivierte Sensor-Quellen aktivieren

(z.B. Dazu schalten von Bluetooth speziell in Gebäuden). Mit Hilfe der bereits vor-

handenen Display Apps konnte zudem das Konzept leicht demonstriert und Perso-

nen dazu aufgefordert werden, Ideen für weitere Apps zu entwickeln. Als eine der

dauerhaft aktiven Komponenten, konnte sich die e-Channel Player App, trotz Aus-

führung unterschiedlichster Inhalte (Bilder, Videos, Webseiten) über den gesamten

Testzeitraum stabil behaupten. Als besonderer Test wurde ein Display Node für

mehrere Minuten vom Netzwerk getrennt und dadurch eine nicht selten vorkom-

mende Alltagssituation herbeigeführt. Obwohl die prototypisch implementierten

Komponenten nicht bewusst für diese Situation vorbereitet wurden, wurde die Wie-

dergabe von Inhalten über den eChannel Player (danke des transparenten Browser-

Cachings) problemlos weitergeführt.

7.2 Sensing und Aufruf von Display Apps

In diesem Kapitel sollen zunächst die Verursacher der Verzögerung erläutert wer-

den, die zwischen dem Eintreten eines Nutzers in eine Trigger-Zone (bzw. in Blue-

tooth-Reichweite) und dem Einblenden der gewünschten Display-App auf den Pub-

lic Display auftritt. Anschließend werden die reinen mittleren Netzwerk-

Übertragungszeiten für die notwendige Kommunikation der Architektur-

Komponenten experimentell unter Laborbedingungen gemessen.

Schließlich 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 Verzögerungsfaktoren

Die für die Verzögerung verantwortlichen Vorgänge zwischen dem Eintritt einer

Person in die Trigger-Zone eines Displays und dem Erscheinen der gewünschten

App(s) auf dem Public Display können in drei Abschnitte eingeteilt werden:



1. Die Detektierungs-Zeit, die die mobile App benötigt um feststellen zu können,

ob sich der Viewer bereits in der Trigger-Zone eines Display befindet, das ge-

wünschte Apps erlaubt.

2. Die Dauer zum Senden einer Anfrage per Mobilfunkverbindung (3G/GPRS)

oder WiFi an das Backend der gewünschten Display App.

3. Die Anfrage des Display App Backends an den Media Player des Public Dis-

plays und dessen Aufruf und Darstellung der gewünschten App.

Der erste Anschnitt hängt zunächst von den aktivierten Technologien ab. Falls WiFi,

GPS und Bluetooth aktiviert sind haben jede von ihnen andere mittlere Ereignisraten.

GPS liefert bei bester Auflösung 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 während des Scans (oft mehr-

fach da Bluetooth-Geräte Frequenz-Hopping betreiben) gefundene Bluetooth-MAC-

Adressen melden. Daher benötigen Bluetooth-Scans im Durchschnitt ca. 5,5s um ein

Gerät in Reichweite zu finden. Positionsermittlung basierend auf WiFi sind (zumin-

dest auf Android Geräten) stark abhängig von der WiFi Abdeckung und liefern da-

her sehr unterschiedliche Positionsermittlungs-Raten.

7.2.2 Netzwerk-Verzögerung

Da der erste Abschnitt extrem abhängig von dem Standort ist und bei Messung an

nur einem Standort praktisch nichts aussagt, wurden zunächst die letzten Abschnit-

te, welche die Verzögerung durch das Netzwerk darstellen, experimentell unter La-

borverhältnissen 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-Funktionalität erweitert. Die

mobile App (verbunden über 3G) hat dazu bei jeder Anfrage eine eindeutige Log-ID

generiert, die von jeder Station an die nächste weitergegeben wurde und so am Ende

durch Differenzbildung aller gemessenen Zeitstempel genaue Verzögerungsdauern

für Abschitt 2 und 3 ermittelt werden konnten (Tabelle 10).

Mean [s] Median [s] Stnd. Abw. [s]

2) Mobile to App server 1.96 1.70 0.99

3) App server to Display 2.35 2.22 0.19

Sum 4.31 4.13 1.18

Tabelle 10: App Anfrage-Übermittlungsdauern ermittelt aus 20 Messungen

Dabei wurde im Abschnitt 3 der (schlimmere) Fall gewählt, bei dem keine Webso-

cket-Verbindung zwischen App-Player-Front und Backend unterstützt wird, wo-

durch auf HTTP-Polling ausgewichen wurde. Somit wurde eine mittlere Anfrage-

Netzwerk-Verzögerung bis zum Anzeigen der gewünschten App von 4,31+-1.18s



gemessen (durch Einsatz von Websockets wäre Abschnitt 3 um weitere ca. 1,5s redu-

ziert worden). Ausgehend von dieser Verzögerungszeit, 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 wer-

den.

7.2.3 Effektivität unter realen Bedingungen

Zur Ermittlung der Leistungsfähigkeit der implementierten Komponenten in echten

Situationen wurden zwei Public Display Standorte auf dem Campus der Lancaster

University ausgewählt, um dort mehrere Test-Reihen durchzuführen. 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 gewünschte Inhalt gerade eingeblendet werden, wenn ein Viewer in Sichtweite

eines Public Displays gerät und wieder ausgeblendet werden, sobald dieser das

Sichtfeld verlässt. Folgende Standorte wurden ausgewählt um diese Situation zu tes-

ten.

Display-Standort A befindet sich auf der Ecke eines Universitätsgebäudes, welches

direkt an einem vielgenutzten Weg liegt, von dem aus das Display durch eine

Glassfront von außen einsehbar ist (Abbildung 28, links). Standort B befindet sich in

einem Erdgeschoß-Durchgangsbereich innerhalb eines Gebäudes, welches dort mit

zwei Public Displays ausgestattet ist (Abbildung 28, rechts). Für beide Standorte

wurden Sichtfelder geschätzt 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 größer war als die tatsächliche Sichtweite in

Standort B. Dies wurde bewusst auch dort gewählt, um den auf absolute Position

basierenden Positions-Quellen (GPS und WiFi) in dieser Indoor-Situation auch eine

Chance zu geben an den jeweiligen Eingangsbereichen auszulösen. Die gewählten

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 durchgeführt, bei denen einen Person die Rolle des

Viewers übernommen hat und mit einem Mobiltelefon und der mobilen App ausge-



stattet wurde. Eine zweite Person übernahm die Rolle des Beobachters, um mit Hilfe

einer speziell für diese Aufgabe entwickelten Zeitmessungs-App die entsprechenden

Ereignisse festzuhalten. Die mobile App des Viewers wurde eingestellt, um eine be-

stimmte Display App aufzurufen, sobald sich der Viewer in der Trigger-Zone befin-

det. Diese Display-App wurde dann für 10s auf dem Public Display angezeigt, falls

in der Zwischenzeit keine neue Anfrage empfangen wurde. Der Viewer hat sich nun

zunächst weit außerhalb der Trigger-Zone begeben, um anschließen möglichst im-

mer im gleichen Geh-Tempo die angedeuteten Laufwege abzugehen und weit au-

ßerhalb der Trigger-Zone wieder Halt zu machen. Der Beobachter hat dabei jedes

Mal mehrere Ereignisse mit Hilfe der Mess-App zeitlich festgehalten: 1) Den Zeit-

punkt an dem der Viewer in Sicht des bzw. der Displays gekommen ist, 2) an dem

die gewünschte 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 Dis-

play ausgeblendet wurde. Die Ereignisse sind jedoch nicht zwingend in dieser Rei-

henfolge passiert, was über die Mess-App festgehalten werden konnte. Es wurden

auf diese Weise pro Standort jeweils 3 Läufe in jede Richtung durchgeführt, bei de-

nen jeweils immer nur eine Technologie alleine aktiviert war (GPS, WiFi, Bluetooth),

sowie 3 Läufe in jede Richtung bei denen alle Sensor-Quellen aktiviert waren. An-

schließend wurden die Radien der Trigger-Zonen auf 24m (entsprechend des be-

rechneten Mindest-Trigger-Zone-Radius) vergrößert sowie die Winkel der Trigger-

Zonen um 30° auf jeder Seite verbreitert und alle Tests wie zuvor noch einmal

durchgeführt. Insgesamt wurden 84 Testläufe durchgeführt, wobei die von der Grö-

ße der Trigger-Zone unabhängige Bluetooth-Sensorquelle die Zahl der Experimente

minimiert hat.

Ergebnisse

Um die Effektivität des Systems zu ermitteln, wurden basierend auf den Zeit-

Messungen jeweils zwei Werte berechnet:

Content-Exposure spiegelt den prozentuellen Anteil der Zeit wieder, in dem

der gewünschte Inhalt auf dem Display angezeigt wurde, während der Vie-

wer in Sichtweite war. Dadurch wird die Effektivität des Systems ausge-

drückt, den Viewer gezielt Inhalten aussetzen zu können.

Content-Accuracy ist der prozentuelle Anteil der Zeit, in der der Inhalt vom

Viewer hätte gesehen werden können, relativ zu der Gesamtdauer die der In-

halt angezeigt wurde. Dieser Wert spiegelt die Fähigkeit des Systems wieder,

Inhalte möglichst genauso lange anzuzeigen, wie der Viewer sich in Sichtwei-

te befindet (Präzision).

Ein System dass nun z.B. einen speziellen Inhalt dauerhaft einem Viewer anzeigt,

egal ob dieser sich vor dem Display aufhält oder nicht, hat eine hohe Exposure, je-

doch eine sehr geringe Accuracy. Tabelle 11 zeigt die ermittelten Exposure/Accuracy

Werte für alle Kombinationen aus verwendeter Technologie, Standort und Trigger-

Zonen-Größe.



GPS WiFi Bluetooth All

Loc. A 15m 0.2/0.26 0.0/0.0 0.21/0.34

0.38/0.35

Loc. A 24m 0.25/0.16 0.83/0.44 0.89/0.64

Loc. B 15m 0.01/0.01 0.35/0.5 0.58/0.51

0.74/0.63

Loc. B 24m 0.64/0.65 0.53/0.54 0.98/0.26

Tabelle 11: Ermittelte Exposure- und Accuracy-Raten jeweils pro Standort, Triggerzonen-Größe und verwendete Technologie

Es lässt sich feststellen, dass in allen außer einem Fall die Anzeige der gewünschten

Display App ausgelöst wurde (Loc A, 15m, WiFi). Für den gleichen Fall jedoch mit

einer größeren Trigger-Zone lassen sich erstaunlicherweise sehr gute Werte für

Exposure und Accuray feststellen. Dies lässt sich damit erklären, dass auf WiFi-

Fingerprinting basierende Positionierung nicht fortlaufend eine neue Position liefert,

sondern eher sprungartig zur nächsten, immer für einen Aufenthaltsort selben, Posi-

tion springt, sobald neue WiFi Netzwerke gescannt werden. Da die Trigger-Zone

nun größer ist, deckt diese nun auch den auf Basis von WiFi bestimmten Punkt ab,

und löst deshalb die Anzeige von Inhalten aus.

Ebenso kann festgestellt werden, dass in vielen Fällen eine akzeptable Präzision er-

reicht 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 verfügbaren Technologien in allen Fällen bessere Ergeb-

nisse erzielt hat, als jede Technologie für sich alleine.

Durch die Vergrößerung der Trigger-Zonen, konnte wie erwartet meistens ebenso

die Exposure erhöht werden. Gleichzeitig wäre jedoch zu erwarten gewesen, dass

sich dadurch die Präzision verschlechtert, was jedoch nicht immer der Fall war. Dies

lässt sich damit erklären, dass kleinere Trigger-Zonen öfters erst die Anzeige des In-

halts auslösen, wenn dieser die Zone schon fast verlassen hat, wodurch Exposure

und Accuracy schlecht ausfallen. Bei einer vergrößerten Zone ist die Wahrscheinlich-

keit größer, dass die Anzeige früher ausgelöst wird und dann (durch die Mindestan-

zeigezeit von 10s) genauso lange dauert, bis der Viewer die Zone wieder verlassen

hat.

Insgesamt konnte an zwei verschiedenen Standorten einer echten Public Display Inf-

rastruktur gezeigt werden, dass Inhalte basierend auf der Präsenz des Viewers mit

großer Zuversicht aufgerufen werden können, sowie dass die Präzision dabei gleich-

zeitig bei etwa 50% liegt.

7.3 Display App Anwendungsfälle

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 Demonstra-

tion der Möglichkeit, 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 ver-

schieden Anwendungsfällen 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 für verschiedenen administrative Nutzergruppen eine Web-Oberfläche zur

Komposition und Publikation von Inhalten auf der Public Display Infrastruktur des

Campus und entkoppelt Inhalt-Ersteller und Display-Verwalter mit Hilfe von Chan-

nels. Inhaltersteller haben eigene Channels zur Publikation und Modifikation ihrer

Inhalte. Display Verwalter können die Inhalte der Displays bestimmten, die sich in

ihren Gebäuden oder Bereichen befinden und abonnieren dazu einfach einen oder

mehrere Channels für jedes ihrer Displays. Auf diesen Displays befindet sich ein

Media-Player, der für ihn bestimmte Subscriptions regelmäßig aus dem Channel-

System aktualisiert und abspielt.

Diese traditionelle Media Player Funktionalität wurde mit Hilfe der e-Channel Player

App als separate Display App implementiert. Die App sollte dabei die dauerhafte

Ausführung ermöglichen und dem Display Owner die Möglichkeit zur Parametrisie-

rung geben. Eine Personalisierung durch Viewer wurde in dieser Version nicht benö-

tigt, weshalb die gesamte App als reines Display-App Frontend realisiert werden

konnte (keine Verbindung zu einem Backend nötig).

Abbildung 29: e-Channel Player App im Einsatz, geöffnetes App-Player Konfig-Menü (r.)

Zur Implementierung der Channel Player App musste lediglich die vom Display

Owner angegebenen e-Channel-Subscription-URL regelmäßig auf Aktualisierungen

geprüft, heruntergeladen, geparst und deren Inhalte abgerufen und angezeigt wer-

den. Der Inhalt einer Subscription besteht dabei auf beliebig tief verschachtelten

Channel-Playlisten im XML-Format (Content Descriptor Set), dessen Inhalte mit be-

stimmten Metadaten annotiert sind, wie z.B. Priorität, Abspieldauer, Abspiel-

Wochentage und Uhrzeiten, Aktualisierungsrate, Datentyp, Größe und URL der je-

weiligen Inhalte. Auf Basis dieser Metadaten wird nach jeder Aktualisierung eine

interne sequenzielle Playlist erstellt und wiedergegeben. Abbildung 29 zeigt die e-



Channel Player App im Einsatz, sowie das (sonst ausgeblendete) Konfigurations-

Menü des App Players, in dem die e-Channel Player App zur dauerhaften Ausfüh-

rung ausgewählt und mit einer Subscription-URL parametrisiert wurde.

Eine erweitere Version der e-Channel Player App könnte zusätzlich die Steuerung

von Viewern in der Nähe einbinden, damit diese interessante Inhalte z.B. Anhalten

können um sie vollständig zu lesen, oder ggf. auch um durch die Playlist zu navigie-

ren.

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 Nähe aufgerufen werden kann. Die App kann so-

wohl durch Display Owner als auch Viewer personalisiert werden, indem diese ein-

fach Schlüsselwörter angeben, über die sie Nachrichten sehen möchten. Die durch

den Display Owner bestimmten Themen werden standardmäßig angezeigt. Falls ein

oder mehrere Nutzer sich in der Nähe befinden, werden aus freien News-APIs (z.B.

Google News20) automatisch Inhalte zu deren Keywords abgerufen und im vorderen

Teil aller Nachrichten angezeigt (höhere Priorität als die Display Owner bestimmten

Themen). Dabei zeigt die News App exemplarisch, wie die Personalisierungsanfra-

gen mehrerer Viewer, die sich vor dem gleichen Display befinden und die gleiche

App personalisieren möchten, bereits im News App-Backend verwoben und somit in

der gleichen Frontend-Oberfläche angezeigt werden. Alternativ hätte das Backend

der News App auch mehrere separate Anfragen an das Public Display senden kön-

nen, so dass der ausführende Media Player (App Player) z.B. beide News Anfragen

gleichzeitig in getrennten Bereichen angezeigt hätte (Tiling).

Abbildung 30: News App auf Public Display (l.) personalisiert über mobile App (r.)

20 https://developers.google.com/news-search/v1/jsondevguide



Abbildung 30 zeigt das News App Frontend (links) sowie die Personalisierung über

News-Tags (mehrere möglich, über Komma getrennt) aus der mobile App heraus

(rechts). Da die News-App häufig mehr Inhalte hat, als sie gleichzeitig anzeigen

kann, rotiert diese die einzelnen Einträge fortlaufend weiter. Dabei wird ein Eintrag

für mehrere Sekunden angezeigt (einstellbar durch Display Owner), dann langsam

ausgeblendet und der nächste Artikel an dessen Stelle verschoben. Dieser Vorgang

geschieht für Nutzer optisch nachvollziehbar, so dass diese intuitiv das Rotations-

prinzip verstehen. Ebenso werden Inhalte gleicher Kategorie über eine gemeinsame

Kategorie-Farbe verdeutlicht, sowie gezielt Bilder in Verbindung mit Nachrichtentex-

ten verwendet um die Aufmerksamkeit von Passanten zu fangen.

Eine erweitere Version dieser App könnte zudem für jedes Display auf dem es aufge-

rufen wurde eine History von Viewer-Themen sammeln und sich somit, bei entspre-

chende aktiver Nutzung, automatisch an die Präferenzen der Viewer seiner Umge-

bung anpassen. Desweiteren, könnte ebenso die bereits bei der letzten App erwähnte

Funktion zur direkten Navigation durch vorhandene News-Einträge auch hier er-

gänzt werden. Schließlich sollte für jeden News-Artikel eine Möglichkeit geschaffen

werden, diesen auf das Mobiletelefon mitzunehmen und vollständig lesen zu kön-

nen. Eine einfache Lösung wäre jeden Artikel mit einem kleinen QR-Code mit einer

URL zur Artikelquelle zu versehen.

7.3.3 Weather App – Anonymisierungs-Ansätze

PD Weather ist eine weitere Display App, die diesmal Wetterinformationen für be-

liebige Orte anzeigen kann. Der Display Owner gibt in diesem Fall beim setzten der

Personalisierungseinstellungen einen Ort an, für den dauerhaft Wetterdaten ange-

zeigt werden sollen (potentiell den Standort des Displays). Daneben werden fortlau-

fend Wetterdaten für zwei weitere zufällig ausgewählte Orte des Wetter-App

Backends angezeigt.

Abbildung 31: Weather App auf Public Display in InfoLab21-Foyer (l.) personalisiert über mobile App (r.)



Da die Anzeige von personalisierten Wetterdaten auf Public Displays auch für frem-

de Personen in der Umgebung sichtbar ist (z.B. wenn diese angezeigt wird, solange

der Viewer in der Nähe ist), könnte ein Nutzer es als unangenehm empfinden weil

dies z.B. auf seinen Wohnort schließen lässt. Befinden sich z.B. mehrere Personen in

der Nähe des Public Displays und wird die mobile App im impliziten Modus ge-

nutzt (Smartphone in der Hosentasche), dann lässt sich nicht klar identifizieren, wer

welche Personalisierung auslöst. Stehen jedoch nur zwei Personen vor einem Bild-

schirm, so kann die zweite Person klar auf die Personalisierung durch die erste Per-

son schließen. Ein Ansatz zur Anonymisierung ist die Personalisierungs-Anfragen

mit mindestens einem anderen zufällig ausgewählten Ort anzuzeigen (oder mehre-

ren) sowie in gleicher Dauer wie die zufällig eingeblendeten Orte. Dieser Ansatz ist

natürlich etwas naiv, da ein dauerhafter Beobachter ggf. schnell die Liste aller zufäl-

ligen Orte herausfinden könnte und somit die angefragten Orte unterscheiden kann.

Deshalb dient dieser Ansatz mehr zur Demonstration potentieller Strategien zur

Anonymisierung von möglichen sensiblen Inhalten.

7.3.4 Ubi-VM App – Mein Desktop verfolgt mich!

Die ubiVM (Ubiquitous Virtual Maschine) App basiert auf der Idee, dass zukünftig viele

Personen eine eigene VM in der Cloud betreiben könnten, die als spezielle Inhalts-

container dienen könnten um auf Public Displays angezeigt zu werden, wenn ihre

Nutzer in der Nähe sind. Auf Basis von Display Apps und der Tacita Architektur

Implementierung, konnte diese Idee in kürzester Zeit realisiert werden. Dazu wurde

ein App-Frontend entwickelt, dass ein VNC-Java-Applet enthält, welches sich zu

VNC-Servern verbinden kann. Ein Viewer muss auf seinem Mobilgerät lediglich die

ubiVM App zur Nutzung auswählen und dort als Parameter den Hostnamen/Port

und das Passwort seiner über das Internet erreichbaren VM eingeben. Sobald sich

dieser dann Public Display nähert, die diese App erlauben, wird die Oberfläche der

VM sofort dort angezeigt.

Abbildung 32: ubiVM Display App im Einsatz



Um die Performanz dieser Lösung auch noch bei potentiell mehr als einem ubiVM

App Nutzer in der Nähe 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 gleichgroßen Berei-

chen dargestellt werden. Einer der VM-Dektops zeigt dabei nützliche Widgets wie

Kalender, Uhr und Wettervorhersage an. Ein anderer spielt gerade ein Video ab, das

flüssig angezeigt wird. Um diesen Test zu verschärfen wurden noch weitere parallele

Verbindungen aufgebaut. Abbildung 33 (links) demonstriert dabei die Aufteilung in

9 Anzeigeflächen die jeweils eine Verbindung zur gleichen VM aufgebaut haben

(aufgrund nicht genug vorhandener unterschiedlicher Testrechner). Der Graph do-

kumentiert dabei die Zeitdauern aus 10 Experimenten, welche benötigt wurde um

gleichzeitig n VNC-Verbindungen zu externen Rechnern aus einem Kaltstart aufzu-

bauen und seine Inhalte anzuzeigen (mit n = 1 bis 10). Kaltstart heißt dabei, dass die

n Apps erst frisch vom App-Player aufgerufen werden mussten, dies jedoch prak-

tisch gleichzeitig.

Abbildung 33: ubiVM – Start von 9 VNC-Verbindungen gleichzeitig (l.), Dauer des Aufbaus und Anzei-

ge von n VNC-Verbindungen (r.)

Die Aufrufverzögerung bei mehreren Nutzern gleichzeitig ist deshalb interessant, da

ab einer bestimmten Zahl gleichzeitig Nutzer, die VM eines neuen Viewers der gera-

de an einem Display vorbeigeht, ggf. nicht mehr rechtzeitig aufgerufen werden kann,

um noch wahrgenommen zu werden. Abgesehen davon ist eine Aufteilung einer

Public Display Anzeigefläche in mehr als vier Bereiche eher ungünstig um noch er-

kennbaren Inhalt zu liefern, außer die Personen befinden sich direkt vor dem Bild-

schirm, 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 durchgeführt wurden, eine funktionierende

Demonstration dieser Idee vorgeführt werden, um dadurch ggf. weitere Ideen und

Reaktionen bei den Teilnehmern zu stimulieren.



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

für Public Display entwickelt, die traditionelle Kleinanzeigen auf digitale Public Dis-

plays bringen möchten. Die Oberfläche 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 Möglichkeit der Interaktion, wie z.B. die Displays

der e-Campus Infrastruktur, können kaum von dieser Anwendung profitieren.

Da Digifieds jedoch vollständig Web-basiert ist, ließ sich die Anwendung problemlos

zur Display App erweitern. Mit Hilfe der direkten Interaktion über die mobile App,

kann durch Digifieds-Oberfläche nun auch per mobile App navigiert werden. Dazu

werden, wie in Abbildung 34 gezeigt, die Cursortasten der mobilen App dazu ver-

wendet um durch die Kategorie-Bereiche der Digifieds App horizontal und vertikal

scrollen zu können. Desweiteren kann die „Tab“-Schaltfläche verwendet werden, um

den Fokus auf Elementen der Oberfläche 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 Web-

Applikationen für Public Displays mit der Tacita-Architektur integriert werden kön-

nen und zudem von dessen Funktionalität 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 für direkte Interaktion nicht erreichbar ist.

Kapitel 8 - Zusammenfassung und Ausblick


8 Zusammenfassung und Ausblick

8.1 Zusammenfassung

Große digitale Displays sind bereits heute in vielen öffentlichen Umgebungen unse-

res Alltags zu finden. Die meisten dieser Displays dienen jedoch lediglich der sich

ständig wiederholenden Anzeige Kontext-loser Inhalte, weshalb sie mittlerweile von

einem großen Teil ihrer Zielgruppe einfach ignoriert werden. Dabei bieten Public

Displays ein riesiges Potential nützliche, interessante und unterhaltsame Inhalte an-

zubieten, die durch die Personen ihrer Umgebung beeinflusst und auf den Kontext

eines Displays abgestimmt sind. Dazu werden jedoch Möglichkeiten benötigt explizit

und auch implizit mit Public Display interagieren zu können. Eines der Geräte die

problemlos zur Interaktion mit der Umgebung und somit auch Public Displays ein-

gesetzt werden können, trägt beinahe jeder von uns ständig mit sich in der Hosenta-

sche - das Mobiltelefon. Diese Arbeit zeigt, wie das Mobiltelefon als Interaktions-

schnittstelle mit Public Displays eingesetzt werden kann, um potentiell beliebige In-

halte in Form von Display Apps aufzurufen, diese zu personalisieren und sogar in

Echtzeit mit diesen interagieren zu können. Display Apps als Mittel zur Erbringung

von individueller Funktionalität auf Public Displays stellen zudem eine zentrale

Schnittstelle zwischen den Interessen der beteiligten Stakeholdern dar. Application

Provider können kreative Display Apps entwickeln und diese leicht mit Hilfe von

Display App Stores publizieren. Viewer und Display Owner können, aus dieser po-

tentiell großen Menge zukünftig verfügbarer Apps wählen und so bequem beliebige

Funktionalität auf Public Display bringen. Dabei behalten Display Owner weiterhin

die Kontrolle darüber, ob und welche Display Apps sie zulassen möchten. Viewer

können dabei bewusst und gezielt Display Apps aufrufen und diese nutzen oder sie

setzen Präferenzen in Form von Display Apps und Personalisierungseinstellungen,

welche dann dazu verwendet werden Displays in der Umgebung eines Viewers au-

tomatisch anzupassen und seine Umgebung dadurch mit Informationen anzurei-

chern, die für ihn von Interesse sind.

Die Architektur zur Erbringung dieser Funktionalität ist dabei stark verteilt und ska-

liert daher auch (bzw. insbesondere) bei großen 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 Effektivität und akzeptabler Präzision

auf nahen Public Displays aufzurufen und anzuzeigen. Schließlich wurde gezeigt,

dass diverse Public Display Apps einfach und schnell auf Basis des Display App De-

veloper Kits realisiert werden konnten, sowie dass sogar bereits vorhandene Public

Display Anwendungen leicht zur Display Apps erweitert werden können.

Kapitel 8 - Zusammenfassung und Ausblick


8.2 Ausblick

Ein System dieser Art und dieses Umfangs bietet natürlich eine Vielzahl von Erwei-

terungs- und Optimierungsmöglichkeiten jeder einzelnen Komponente.

So könnten Display Apps (wie bereits im Architekturteil vorgeschlagen) um optiona-

le private UIs extra zur Anzeige auf der mobilen App erweitert werden. Diese könn-

ten dann zur bidirektionalen Interaktion mit der laufenden Display App auf einem

Public Display eingesetzt werden und auf diese Weise individuell Steuerungsober-

flächen anbieten (wie z.B. der virtuelle Nintendo Controller für eine Public Display

Tetris App) oder ggf. als privates oder sekundäres Display dienen. Die jetzige Uni-

versal Remote Controller Funktion könnte leicht durch die Nutzung des Beschleuni-

gungssensors um Gestensteuerung und Touch-Gesten (Verschiebung, Rotation etc.)

erweiter werden, was die Qualität der direkten Interaktion mit Public Displays über

die mobile App stark verbessern könnte. Eine weitere Methode zur direkten Steue-

rung einer Display App über einen simulierten und animierten Cursor könnte mit

Hilfe der in [21] vorgestellten Methode erfolgen, die die Kamera eines Mobiltelefons

als visuellen Maussensor nutzt. Die mobile App könnte zudem intelligentere Strate-

gien zur sparsameren Nutzung seiner Sensor-Quellen implementieren und somit

deutlich weniger Energie verbrauchen.

Um in Multi-User Szenarien bessere Erkennbarkeit zu gewährleisten, wer welchen

Inhalte aufgerufen hat (z.B. beim Aufruf gleicher Apps auf einem Display), könnte

ein Konzept für visuelle Identifikatoren entwickelt werden, das jedoch weiterhin

(technisch) Anonymität für Viewer gewährleisten muss.

Um neu erstellte Apps auch entsprechend präsentieren zu können, sollte desweiteren

der Display App Store, welcher bisher nur aus einem Minimal-UI besteht, um eine

visuell ansprechende und funktionale Oberfläche ergänzt werden, welche das Brow-

sen durch Display Apps, dessen Screenshots, Bewertungen, Kommentare, App-

Kollektionen usw. erlaubt.

Eine der wichtigsten Aufgabe ist jedoch die Realisierung weiterer kreativer Public

Display Apps. Der Designraum und die durch die HTML5-Webtechnologie in Kom-

bination mit der Tacita Architektur bereitgestellten Möglichkeiten zur Implementie-

rung von Display-Apps sind riesig. Das nötige Web-Wissen ist bei potentielle Ent-

wicklern meistens schon vorhanden und Einschränkungen durch Vorgaben der Ar-

chitektur praktisch nicht existent.

Vielleicht kann diese Architektur, mit Unterstützung kreativer Display App Entwick-

ler, tatsächlich einen Schritt zur Realisierung Weisers Zukunftsvision [1] beitragen.

Literaturverzeichnis



[1] Marc Weiser, "The Computer for the 21st Century," Scientific American, no. 265,

pp. 94-104, 1991.

[2] Jörg Müller 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] Jörg Müller, Juliane Exeler, Markus Buzeck, and Antonio Krüger,

"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 hue-

difference-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] Jörg Müller, 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), Zürich, Switzerland, 2003.

[29] Jörg Müller, 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 Al-

Muhtadi, "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 Björk, "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 Jörg Müller, "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] Jörg Müller and Antonio Krüger, "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 real-

world 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.

http://www.pd-net.org/



[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, co-

located 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 e-

Campus 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, Björn

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



'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 Today’s Paper-

Based 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 Göthlin, 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.

Anhang


Anhang

A1: RESTful APIs von Komponenten

Info: Die Body-Parameter und Datenformate sind zur Erhaltung der Übersichtlich-

keit hier nicht angegeben.

App Player API:

Resource Action Method URI

Display

Register a new display with its unique dis-play_uri and settings

PUT api/display/{display_uri}

Unregister the display DELETE api/display/{display_uri}

Get current active apps

GET api/display/{display_uri}/app

App Request the start of a display app with pa-rameters

POST api/display/{display_uri}/app

Generische Display App aus Developer Kit:


App Register a new app frontend on a display

PUT api/app/{display_uri}

Unregister the app frontend from a dis-play

DELETE api/app/{display_uri}

Get current active personalisation requests for a display

GET api/app/{display_uri}/viewer

Mobile Request the start of this app on a given display

POST api/app

Anhang


Service Directory:


Display Register display and save display metadata

PUT api/display/{display_uri}

Change display metadata unsing password

POST api/display/{display_uri}

Delete display metadata unsing password

DELETE api/display/{display_uri}

Get displays by positi-ons and radius

GET api/display/{lat}/{lon}/{radius}

?since={ISO8602-format}

Get displays by region type and name

GET api/display/{regiontype}/{regionname}

?since={ISO8602-format}

Display App Store:


App Add new app and set password

PUT api/app/{app_uri}

Modify app-metadata using password

POST api/app/{app_uri}

Delete app using password

DELETE api/app/{app_uri}

Retrieve app-metadate for given app_uri

GET api/app/{app_uri}

Get all apps or filter by keyword

GET api/app/[{keyword}]

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>[email protected]</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>

Anhang


A3 : Display Meta-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>[email protected]</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</metadata-origin-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>

mater thesis

Documents