Der vorliegende Artikel ist der zweite Bericht aus der Einführungs-Serie für Multitouch-Entwicklungsumgebungen und stellt die kommerzielle Software GestureWorks vor. Mit diesem Framework können Adobe Flash Applikationen mit Multitouch-Unterstützung erstellt werden, wobei eine breite Palette von Multitouch-Hardware unterstützt wird. Das Spektrum an unterstützten Gesten ist enorm, was sich u.a. auch in der von GestureWorks eingeführten Gesture Markup Language widerspiegelt. Im Folgenden wird eine kurze Einführung in die Plattform gegeben, einige vorgefertigte Beispiele gezeigt sowie ein kleine Anwendung selbst implementiert.

Einführung

• Framework zur Erstellung von Multitouch-Anwendungen mit Adobe Flash
• Unterstützung aller Adobe Flash-Komponenten
• Verwendung der Adobe Flash Rendering Engine
• Implementierung basiert auf Adobe ActionScript
• Anbindung beliebiger Hardware mit Windows 7 oder dem TUIO-Protokoll
• Über 100 verfügbare Gesten, assoziiert mit der Gesture Markup Language

Demo

Um vor der Vorstellung der technischen Details einen ersten Eindruck zu schaffen, demonstriert das folgende Beispielvideo die Funktionalität einer Applikation mit Flickr und Google Maps Integration:

Historie

Das Framework wird seit 2008 von dem US-Unternehmen Ideum Inc. entwickelt und steht derzeit in der Version 3.1 zur Verfügung. Es werden zwei Versionen vertrieben. Zum einen als Standard-Version für $149, welche auf fünf Gesten beschränkt ist und in jeder Anwendung ein Logo enthält, und die unbeschränkte Professional-Version für $349. Außerdem wird eine Demo-Version bereitgestellt, bei der jede Anwendung auf 30 Minuten Laufzeit eingeschränkt ist. Die Version 2 des Frameworks ist als über das Projekt Open Exhibits als Open-Source verfügbar.

Komponenten und Aufbau

Die nachfolgende Tabelle gibt einen Überblick über die technischen Eigenschaften sowie bereitgestellten Gesten und Komponenten des Frameworks:

Installation

Bevor die Installation starten kann, muss zunächst auf der Homepage eine Version gekauft werden. Alternativ steht auf der gleichen Seite auch eine Evaluationsversion zur Verfügung.

1. Die Adobe Air Laufzeitumgebung herunterladen und installieren
2. Die heruntergeladene Setup-Datei für GestureWorks ausführen
3. Den Installationsschritten folgen
4. Zum Ende der Installation die Lizenznummer eingeben und bestätigen
5. Nach der Installation öffnet sich der Windows Explorer und zeigt den Installationsordner. In diesem sind die Programm-Bibliotheken enthalten, die benötigt werden, um Multitouch-fähige Anwendungen mit Adobe Flash zu kompilieren. Es ist keine ausführbare Anwendung enthalten!

Installation Schritt 1

Installation Schritt 2

Installation Schritt 3

Installation Schritt 4

Installation Schritt 5

Installationsverzeichnis von GestureWorks

Einrichtung von Adobe Flash

Um Anwendungen auf Basis von Adobe Flash und GestureWorks entwickeln zu können, wird die Entwicklungsumgebung Adobe Flash Professional CS5+ benötigt. Im Folgenden wird erklärt, wie diese Anwendung eingerichtet werden muss, damit Applikationen mit GestureWorks erstellt werden können.

1. Dieses vorbereitete Template herunterladen und entpacken. Es enthält die Ordnerstruktur, welche für jedes neue Projekt benötigt wird.
2. Anlegen eines neuen Adobe AIR Projekts unter „Datei“ -> „Neu“ (Adobe AIR Projekt auswählen)
3. Abspeichern des Projekts unter beliebigem Namen in dem Template-Ordner
4. Neue Adobe ActionScript Klasse anlegen unter „Datei“ -> „Neu“ (ActionScript 3.0 auswählen)
5. Die neue Klasse im „src“-Ordner abspeichern unter dem Name „Main“
6. ActionScript Einstellungen festlegen unter „Datei“ -> „ActionScript Einstellungen
   1. Als Klassenname „Main“ angeben
   2. Neuen Quellpfad „.\src“ erstellen
   3. Bibliothekspfade hinzufügen. Alle GestureWorks-Projekte müssen mit den Bibliotheken „GestureWorksCML.swc“ und „GestureWorksGML.swc“ verknüpft werden. Diese Dateien befinden sich im „lib“-Ordner im Verzeichnis von GestureWorks und müssen mit dem Icon „SWC-Datei hinzufügen“ je als neue Bibliothek eingefügt und aus dem GestureWorks-Ordner (C:\Users\“Name“\GestureWorks3\lib) ausgewählt werden.
7. Veröffentlichungseinstellungen festlegen unter „Datei“ -> „Einstellungen für Veröffentlichungen“
   1. Der Pfad für die Ausgabedatei (.swf) ist „.\bin\Main.swf“
8. Nun kann der eigentliche Inhalt der Applikation implementiert werden. Dazu wird mit „Klassendefinition bearbeiten“ von „Main“ eine neue Klasse für ActionScript erstellt.

Einstellungen für Veröffentlichungen

ActionScript-Einstellungen 1

ActionScript-Einstellungen 2

Klassendefinition bearbeiten

Adobe Flash Professional CS5+

Neues Adobe AIR Projekt

Neue ActionScript Klasse

Mitgelieferte Beispiele

Die Beispielanwendungen für GestureWorks sind nicht in der Installation enthalten, sondern als Tutorial und Download auf der Webseite verfügbar. Die Applikationen sind allesamt einfach gehalten und lassen sich mit der Anleitung auf der Webseite einfach nachvollziehen. Für die weitere Betrachtung werden die Applikationen in zwei Kategorien eingeteilt. Zum einen die Beispiele, welche die grundlegenden Touch-Gesten demonstrieren, und zum anderen erweiterte Anwendungen. Letztere haben einen größeren Funktionsumfang und geben einen Einblick in die reale Entwicklung.

Die derzeit auf der Homepage befindlichen Beispiele sind für die Version 2 von GestureWorks ausgelegt.

Grundlegende Beispiele

Diese Beispielanwendungen dienen vor allem zum Erlernen der grundlegenden Touchgesten. Es werden jeweils nur wenige Geste mit einfachen Objekt kombiniert, um die Funktionalität zu erlernen.

Flick (Swipe)

Drag

Zoom

Move, Rotate, Scale

Tap

Rotate

Erweiterte Beispiele

Anwendungen in dieser Kategorie sind für fortgeschrittene Entwickler geeignet und zeigen wie man gewöhnliche Flash-Inhalte wie beispielsweise Karten oder 3D-Objekte mit Multitouch-Gesten versehen kann.

Google Maps App

Multitouch Flint App

StandingWave2 App

Twitter Touch App

Away3D Touch App

Minimalimplementierung

Eine Anwendung mit GestureWorks zu implementieren ist sehr einfach. Es werden nur zwei Dateien und etwas Quellcode (Adobe ActionScript 3) benötigt. Wie bei den anderen Beispielanwendungen für Multitouch-Frameworks dieser Seite soll die Beispielanwendung Bilder darstellen und mit entsprechenden Gesten (Drag, Scale, Rotate) manipulieren können. Für die Applikation wird zunächst ein neues Flash-Projekt benötigt. Dieses muss, wie bereits oben gezeigt, konfiguriert und mit dem GestureWorks-Framework verknüpft werden. Das Minimal-Beispiel steht ebenfalls als fertiger Download zur Verfügung.

Den eigentlichen Quellcode beinhaltet die „Main.as“-Datei. Diese besteht, wie bei objektorientierten Programmiersprachen üblich aus verschiedenen Bestandteilen. Zunächst werden die Grundfunktionen per Import-Anweisung eingebunden. Im Anschluss wird die Klasse von „Application“ abgeleitet und die benötigten Methoden implementiert. Die Methode „initialize“ enthält den Hauptbestandteil der Anwendung. Im Folgenden der vollständige Code für das Minimal Beispiel:

package{
import com.gestureworks.core.GestureWorks;
import com.gestureworks.core.TouchSprite;
import flash.display.Bitmap;
import flash.display.BitmapData;
import flash.display.Loader;
import flash.events.Event;
import flash.net.URLRequest;

public class Main extends GestureWorks{
	private var loader:Loader;
	private var myDisplay:TouchSprite;

	public function Main():void{
		super();
		key = "KEY HIER EINFUEGEN";
	}

	override protected function gestureworksInit():void{
		trace("GestureWorks has initialized");

		myDisplay = new TouchSprite();
		loader = new Loader();
		myDisplay.x = (stage.stageWidth) / 2;
		myDisplay.y = (stage.stageHeight) / 2;
		myDisplay.scaleX = 0.2;
		myDisplay.scaleY = 0.2;

		myDisplay.gestureTouchInertia = true;
		myDisplay.gestureReleaseInertia = true;
		myDisplay.clusterEvents = true;
		myDisplay.gestureEvents = true;
		myDisplay.transformEvents = true;
		myDisplay.disableNativeTransform = false;

		var gList:Object = new Object;
		gList["pivot"] = true;
		gList["n-drag"] = true;
		gList["n-rotate"] = true;
		gList["n-scale"] = true;
		myDisplay.gestureList = gList;

		loader.contentLoaderInfo.addEventListener(Event.COMPLETE, loaderComplete);
		loader.load(new URLRequest("library/assets/pic.jpg"));

		myDisplay.addChild(loader);
		addChild(myDisplay);
	}

	private function loaderComplete(event:Event):void{
		loader.x = 0 - (loader.width / 2);
		loader.y = 0 - (loader.height / 2);
	}
}}

Out-of-Home Displays werden an unterschiedlichsten öffentlichen Orten immer häufiger für Produkt- und Unternehmenswerbung verwenden. Gleichzeitig steigt das Interesse an Gestensteuerung und anderen modernen Interaktionsmöglichkeiten mit Großbildschirmen durch den Erfolg von Spielekonsolen wie beispielsweise Microsoft Kinect stetig an. Vor diesem Hintergrund liefert der folgende Beitrag zunächst eine kurze Einführung in den Themenbereich „Out-of-Home Displays“ sowie die damit verbundenen Begriffe „Ubiquitous Computing“ und „Pervasive Advertising“. Anschließend werden mögliche Klassifikationskriterien zur Strukturierung  von Out-of-Home Displays erarbeitet und anhand von Beispielen vorgestellt. Am Ende des Artikels erfolgt ein kurzer Ausblick über Nutzungsparadigmen von Out-of-Home Displays, die sich auf die Verbesserung der Informationsversorgung innerhalb von Unternehmen übertragen lassen.

Motivation

Interaktive Großbildschirme und andere Display-Technologien sind mittlerweile allgegenwärtig und werden ständig weiterentwickelt ¹. Geeignete Nutzungskonzepte mit informationellem Mehrwert für die unternehmensinterne Zusammenarbeit fehlen jedoch, obwohl sich die bereits erfolgreich angewendeten Methoden im Bereich Pervasive Advertising z.T. durchaus auf den Unternehmenskontext übertragen werden könnten. Um dies in einem ersten Schritt zu ermöglichen, werden im vorliegenden Artikel verschiedene Konzepte von Out-of-Home Displays vorgestellt und klassifiziert.

Begriffsdefinitionen

Um für die spätere Beschreibung verschiedener Anwendungen eine ausreichende Begriffsbasis zu schaffen, werden im folgenden Kapitel zunächst die Begriffe „Out-of-Home-Displays“ sowie die damit verbundenen Wissenschaftsbereiche  „Ubiquitous Computing“ und „Pervasive Advertising“ kurz vorgestellt.

Out-of-Home Displays

Der Begriff “Out-of-Home-Displays”, resp. “Out-of-Home-Media” stellt eine Erweiterung und Weiterentwicklung des vor allem im angelsächsischen Raums verbreiteten Begriffs der “Outdoor Media” dar.(Stalder, Ursula) ²

Out-of-Home-Displays bezeichnen damit alle digitalen Kommunikationsträger, die außerhalb des eigenen Hauses verwendet werden. Sie beruhen auf gemeinsamen technischen Grundlagen und haben gemeinsame medienspezifische Eigenschaften, z.B. Technologie, Informationsgehalt oder Eingabemöglichkeiten, die unterschiedlich genutzt werden. Es existieren unterschiedliche Anwendungsformen für Out-of-Home Displays. Die meisten Anwendungsgebiete sind vergleichbar mit konventionellen Werbe-, Unterhaltungs- und Informationssystemen, wobei sich vier Bereiche herauskristallisieren:

• Out-of Home-Medien: Infoterminals, Kiosksysteme, etc.
• Bild-Medien: TV, Videoclips, Film, Podcasts, etc.
• Display-Medien: TV, PC, Web, MP3-Player, etc.
• Netzwerk-Medien: Websites, Management-Informationssystemen, etc.

Diese unterschiedlichen Anwendungsgebiete lassen eine Kategorisierung nach verschiedenen konkreten Ausprägungen zu. Ihr Kontext als eigenständige Mediengruppe im medialen, sozialen und räumlichen Umfeld sind dabei die maßgebende Eigenschaft ³.

Ubiquitous Computing

Der Begriff des „Ubiquitous Computing“ ⁴ beschreibt die allgegenwärtige Informationsverarbeitung, die Datenzugriffsmöglichkeit und die Vernetzung des Alltages mit „intelligenten“ Maschinen und Geräten. Interaktivität, Automatisierung und Ubiquität sind die Eigenschaften, die für dieses Prinzip stehen und im Rahmen von E-Commerce-Szenarien und webbasierten Geschäftsprozessen nutzbar gemacht werden können ⁵. Das scheinbare Verschwinden der Technologie ist die mitunter wichtigste Eigenschaft:

The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it.(Weiser, Mark) ⁶

Für dessen Verwirklichung werden drei Teilen benötigt: günstige und leistungsstarke Computer, Software für ubiquitäre Anwendungen und ein Netzwerk, das alles miteinander verbindet. Anhand dieser aufgezählten Punkte fügt sich Pervasive Computing „unsichtbar“ in die Umwelt ein und verändert das Leben der Gesellschaft ⁷. Neue Technologien wie Sensoren, Netzwerke, Verarbeitungs- und Speichereinheiten ermöglichen die drei Kernprinzipen: Automation, Interactivity und Ubiquity ⁸.

Pervasive Advertising

Pervasive Advertising ist eine Zusammenführung der Fachrichtungen Pervasive Computing und Advertising. Advertising beschäftigt sich mit jeglicher Entwicklung von Werbung, um bei potentiellen Kunden Informationen zu vermitteln, Emotionen zu wecken und Reaktionen auszulösen. Neue Erkenntnisse aus der Marktforschung ⁹ argumentieren für das Einbinden von neuen effektiveren und insbesondere ubiquitären Technologien in die Werbung. Aus der Verbindung der beiden Fachrichtungen Advertising und Pervasive (Ubiquitous) Computing geht Pervasive Advertising hervor. Daraus ergibt sich die Möglichkeit, die bestehende Art der Werbung zu verändern. Besonders Personalisierung und das Kreieren eines positiven Verkaufserlebnisses stehen im Vordergrund.

„Pervasive advertising is the use of pervasive computing technologies for advertising purposes.”(Müller et al.) ⁸

Durch die Verbindung mit Ubiquitous Computing bietet Pervasive Advertising im Vergleich zu traditionellen Werbemitteln, wie Plakatwänden oder Litfaßsäulen, fortgeschrittene Darstellungsmöglichkeiten. Pervasive Advertising beschäftigt sich u.a. mit:

• Symmetric Communication: Das Abgeben der Bestimmungsrechte der Werbemittelbetreiber in die Hände der Nutzer; der Kunde erhält bei der Auswahl der Werbung ein Eintscheidungsrecht. ¹⁰
• The Long Tail: Auch Kleinanbietern ist es möglich, durch geringen Einsatz eine effektive und individualisierte Werbekampagne zu starten. ¹¹
• Experiences: Neugier und das Interesse von Personen an neuen, unbekannten Systemen; Die visuellen Eindrücke, das Gefühlte und das daraus Reflektierte sind die drei Ebenen, die Pervasive Advertising anspricht. ¹²
• Personalization and Context Adaptivity: Speichern von Vorlieben und Verhalten von Zielgruppen oder -personen, um den Kontext, in dem eine Werbung steht, besser zu erfassen und für die Darstellung der Werbung berücksichtigen zu können. ⁸
• Audience Measurement: Messung von Reaktionen der Passanten oder Nutzer, um den Erfolg oder Misserfolg einer Werbekampagne in Zahlen und Daten noch exakter beschreiben zu können. ¹³
• Automated Persuasion: Überzeugungskraft von Pervasive Displays, die auf die allgegenwärtige, teilweise unterbewusste Wahrnehmung setzt, um das Verhalten von Passanten zu beeinflussen und Kunden anzulocken. ¹⁴.

Beispiele für Out-of-Home Displays

In der folgenden Kategorisierung werden die verschiedene Beispiele für Out-of-Home Displays entsprechend ihrer Nutzung näher beschrieben und kurz voneinander abgegrenzt.

Produktmedien

Produktmedien zeichnen sich durch Bildschirme mit Information, Werbung und Unterhaltungsangeboten an belebten Plätzen aus.

Carrefour Live, Schweiz

Die Carrefour Market-Kette mit über 1000 Filialen nutzt ein neues Netzwerk von Bildschirmen, das neben Produktnachrichten auch lokale Werbung und allgemeine Unterhaltung bietet ¹⁵.

Carrefour Live, Schweiz ¹⁶

Carrefour Live, Schweiz ¹⁶

BBC Launch Kampagne, New York

Während der BBC Launch Kampagne wurden dramatische Fotografien aus Nachrichtensendungen dargestellt, die das Interesse der amerikanischen Bevölkerung an internationalen Nachrichten stärken sollten. Die Rezipienten konnten mit ihrem Handy über wichtige Fragen abstimmen und haben damit unbewusst ein Stimmungsbild der Bevölkerung zu verschiedenen Themen erzeugt ¹⁷.

BBC Launch Kampagne, New York ¹⁸

BBC Launch Kampagne, New York ¹⁸

Architekturmedien

Architekturmedien werden als Markenrepräsentationen in verschiedenen Größenkategorien eingesetzt. Siesind zum einen ein mediales System zur Markeninszenierung (eingebettet in die Architektur), das im Außenbereich an Gebäudefronten oder kompletten Gebäude angebracht ist und zum anderen eine zukunftsträchtige architektonische Inszenierung einer Marke mit Hilfe moderner Technik und Design, um deren Ansehen zu steigern.

Uniqa Tower, Wien

Die Versicherungsgesellschaft Uniqa repräsentiert über die Fassade des Towers hinweg die Unternehmensphilosophie durch die abstrakten und gegenständlichen Motive ¹⁹. Für die visuelle Gestaltung wurde die gesamte Gebäudeoberfläche von mehr als 7000m², bestehend aus einer zweischaligen Glasfassade, genutzt ²⁰.

Uniqa Tower, Wien ²¹

Uniqa Tower, Wien ²¹

Swarovski Kristallwelten, Wattens

Die Firma Swarovski hat in Wattens, Österreich, eine Fantasiewelt geschaffen, die sich über 8500m² erstreckt und das Motto „The Art of Crystal Fiction“ trägt ²².

Swarovski Kristallwelten, Wattens ²³

Swarovski Kristallwelten, Wattens ²³

Forschungsmedien

Forschungsmedien sind interaktive (beispielsweise gestengesteuerte) Displays, die heute meist noch nicht in öffentlichen Anwendungen genutzt werden, sondern sich in der Entwicklung befinden. Es handelt sich meist um Prototypen, die zur Erforschung und Verbesserung von Gestensteuerung, Fingererkennung, 3D-Koordinaten-Verfolgung oder Multi-User-Nutzbarkeit dienen ²⁴. Potential ist im Spiele-, Unternehmens-, E-Learning- und Simulationssektor vorhanden ²⁵. Die Steuerung erfolgt über Bewegung der Hände und Finger, welche über verschiedene Kamerasysteme eingefangen digitalisiert und umgesetzt werden.

Omnitouch

Das System besteht aus einer Kamera und einem Pico-Projektor, die zusammen überall einen Touchscreen erzeugen können ²⁶.

Omnitouch ²⁷

Omnitouch ²⁷

iPoint Presenter

Mit dem iPoint Presenter, einer Entwicklung des Fraunhofer Heinrich-Hertz-Instituts, sollt die Mensch-Computer Interaktion, wie sie aus dem Film „Minority Report“ bekannt ist, verwirklicht werden ²⁸. Die Technologie ermöglicht es dem Nutzer, den Computer mittels einfacher Gesten auch ohne direkte Berührung zu bedienen ²⁹.

iPoint Presenter ³⁰

iPoint Presenter ³¹

Kulturell-Informelle Medien

Als viertes Einsatzgebiet existieren kulturell-informelle Medien, die sich durch interaktive Informations- und Orientierungssysteme, sowie digitale künstlerische Gestaltungsmöglichkeiten im öffentlichen Raum abgrenzen lassen.

Spots Facade, Berlin

Die Spots Medienfassade in Berlin besteht aus 1800 Leuchtstoffröhren, die in einer Matrix angeordnet und individuell steuerbar sind. Das Gebäude am Potsdamer Platz ist elf Stockwerke hoch und wurde durch die Glasvorhangfassade zu einem riesigen, 1350m² großen Display ³².

Spots Facade, Berlin ³³

Spots Facade, Berlin ³³

ibex Touchboard, Luzern

Seit dem 01. Januar 2010 ist in der Lobby des Hotels Continental in Luzern das Ibex Touchboard aufgestellt. Das Informations-Tool bietet den hauseigenen Gästen Informationen über das Wetter, aktuelle Nachrichten, lokale Veranstaltungen, Webcam-Übertragungen, z.B. vom Gipfel des nächsten Berges, Kino- und Restauranttipps und vieles mehr ³⁴.

ibex Touchboard, Luzern ³⁵

ibex Touchboard, Luzern ³⁵

Klassifizierung von Out-of-Home Displays

Die verschiedenen Out-of-Home Displays können nach den folgenden Vergleichskriterien klassifiziert werden. Diese Kriterien werden im Anschluss anhand eines Beispiels in einer Klassifizierungstabelle dargestellt.

Vergleichkriterien

• Anzeigetechnologie: Dieses Kriterium gibt die genutzte Displaytechnologie an, basierend auf den Herstellerangaben oder weiterführender Literatur.
• Größe: Als Größe wird bei Bildschirmen die Diagonale in Zoll oder die Maße in Quadratmeter angegeben.
• Betrachtungs- /Benutzungsabstand: Je nach Funktion des Displays gibt es entweder nur einen Betrachtungs- oder aber zusätzlich einen Benutzungsabstand. Diese Abstände sind in vier Zonen eingeteilt: Eine persönliche Interaktions-, eine subtile Interaktions-, eine implizite Interaktions- und eine Außenzone ³⁶.
• Multiuserfähigkeit: Multiuserfähigkeit beschreibt die Eigenschaft eines Displays, mit mehreren Benutzern gleichzeitig zu interagieren ³⁷.
• Nutzung: Die vorgestellten Modelle können entweder interaktiv sein oder zur reinen Darstellung verwendet werden.
• Verwendungszweck: Die Verwendungszwecke beinhalten z.B. Werbung, Informationsversorgung, Aufmerksamkeitserregung oder Markenrepräsentation und sind eng mit der Zuordnung in die jeweilige Kategorie verbunden.
• Informationsgehalt: Dieses Kriterium gibt das Verhältnis von reiner Werbung und Informationen an, z.B. Aktualität von Nachrichten.
• Eingabe: Die Eingabe an Displays kann über fünf Kategorien erfolgen: optisch, haptisch, akustisch, über Peripheriegeräte und Umwelteinflüsse.
• Ausgabe: Im Vergleich zur Eingabe existieren bei der Ausgabe des Displays an Rezipienten vier Kategorien: optisch, haptisch, akustisch und Peripheriegeräte.
• Umgebung: Out-of-Home Displays finden sich quasi überall im öffentlichen Raum ¹. Dieses Kriterium liefert daher eine Einschränkung der genaueren Umgebung, in der das System installiert wurde.
• Kategorie: Die Out-of-Home Displays werden in die im vorherigen Abschnitt vorgestellten Kategorien zugeordnet.

Beispiel: Hauptbahnhof Zürich

Das e-advertising Unternehmen hat im 2. Untergeschoss des Bahnhofs den ersten interaktiven Ad Screen der Schweiz eingerichtet. Auf dem Display wird abwechselnd, im 30 min Takt, Werbung für Coca-Cola und den VW Golf GTI angezeigt. Durch eine neue Softwaretechnik, die von der Vanija GmbH bereitgestellt wurde, soll die Werbung realistischer werden ³⁸.

Hauptbahnhof Zürich ³⁹

Mehrwerte für Unternehmen

Aus den betrachteten Out-of-Home Displays können verschiedene potenzielle Mehrwerte beim Einsatz von Großbildschirmen zur Verbesserung der Informationsversorgung in Unternehmen abgeleitet werden:

• User Attraction und die Nutzung von Mobile Devices wie im Beispiel der BBC Launch Kampagne: Dadurch wird die Attraktivität gesteigert und zur Interaktion mit einem eigenen Gerät, z.B. einem Smartphone angeregt.
• Gestensteuerung als moderne Interaktionsmöglichkeit wie im Beispiel des iPoint Presenter: Durch diese moderne Form der Interaktion kann die Steuerung intuitiver gestaltet und für ein größeres Zielpublikum nutzbar gemacht werden.
• Mehrbenutzerfähigkeit, bzw. die Mehrbetrachterfähigkeit, wodurch mehrere Personen gleichzeitig an einem Display arbeiten können: Das kollaborative Arbeiten kann effektiver und einfacher durchgeführt werden.
• Die Informationsdarstellung auf einem Display: Aus dem Beispiel des iBex Touchboard können geeignete Visualisierungsarten abgeleitet werden, um die benötigten Informationen auf sinnvolle Weise darzustellen. Dadurch kann ein Informationsüberfluss verhindert werden.

Zusammenfassung

Out-of-Home Displays sind mittlerweile allgegenwärtig und werden ständig weiterentwickelt ¹. Geeignete Nutzungskonzepte mit informationellem Mehrwert für Unternehmen fehlen jedoch. Neue Visualisierungs- und Interaktionsmöglichkeiten, z.B. Multi-Touch, Gestensteuerung oder synchron-mehrbenutzerfähige Darstellung finden aktuell fast ausschließlich Anwendung in der Werbe- und Unterhaltungsbranche.

Gestensteuerungsmöglichkeiten werden beispielsweise bereits durch verschiedene Systeme erfolgreich erforscht ^{24 25 40 41}.
Schwerpunktmäßiger Nutzungskontext sind allerdings Unterhaltungssysteme ⁴² , obwohl Gestensteuerung als zukunftsträchtiges Interaktionsverfahren gilt. Out-of-Home-Medien bieten darüber hinaus viele weitere Verwendungsmöglichkeiten ⁴³. Durch Übertragung der Konzepte können Unternehmen die vorhandenen Mehrwerte für sich nutzen, um die unternehmensweite Informationsversorgung  zu verbessern.

Diesbezügliche Ansätze finden sich u.a. hier auf der Plattform im Bereich CommunityMirrors – Interaktiven Großbildschirmen zur Verbesserung der peripheren Informationsversorgung im Unternehmenskontext.

Dieser Artikel stellt den Auftakt einer Serie weiterer Berichte zu „ersten Schritten“ mit aktuell verfügbaren Multitouch-Entwicklungsumgebungen dar. Innerhalb dieser Serie liefert der vorliegene Bericht einen Überblick über die Entwicklung von Multitouch-Anwendungen mit Multitouch for Java (MT4j). Das Framework bietet umfangreiche Funktionalität für das Arbeiten mit Multitouch-Hardware und einfach adaptierbare Konzepte zur Entwicklung eigener Anwendungen. Im Folgenden wird nach einer kurzen Einführung die Einrichtung mit Eclipse erläutert, einige Beispielanwendungen vorgestellt sowie ein Minimal-Beispiel implementiert.

Einführung

• Java-Framework zur Entwicklung von Multitouch-Anwendungen
• Verwendung verschiedener Komponenten (Bilder, Videos, 3D-Objekte)
• Anbindung unterschiedlicher Hardware und Protokolle
• 10 vorhandene Multitouch-Gesten sowie Möglichkeit zur Erstellung von eigenen Gesten
• Performante Darstellung durch OpenGL

Demo

Um vor der Vorstellung der technischen Details einen ersten Eindruck zu schaffen, demonstriert das folgende Beispielvideo die Funktionalität der mitgelieferten Kartenapplikation:

Historie

Das MT4j-Framework wird vom Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO) entwickelt und basiert (wie der Name schon sagt) auf der weit verbreiteten objektorientierten Programmiersprache Java. Im Herbst 2009 wurde das Framework unter Open Source-Lizenz veröffentlicht und wird seitdem durch die OpenSource-Gemeinde weiterentwickelt. Die Multitouch-Plattform übernimmt alle benötigten Aufgaben, wie beispielsweise die Erkennung von Multitouch-Gesten, deren Umsetzung in Events sowie die erforderliche Grafikausgabe. Es bietet eine umfangreiche Bibliothek mit vorgefertigten Grafiken, Gesten und Schriften und ist sehr generisch implementiert, sodass eigene Gesten und Grafiken problemlos hinzugefügt werden können. Das Framework ist prinzipiell kompatibel zu allen Multitouch Geräten, da es die Inputs der Hardware abstrahiert.  Als Grundlage hierfür wird die Anbindung an verschiedene APIs (z.B. TUIO) bereitgestellt, welche die Eingaben des Touchscreens interpretieren. Die Darstellung erfolgt über die Grafikschnittstelle OpenGL, sodass die Anwendungen auf entsprechender Hardware sehr performant sind.

Komponenten und Aufbau

Die nachfolgende Tabelle gibt einen Überblick über die technischen Eigenschaften sowie bereitgestellten Gesten und Komponenten des Frameworks:

Installation

Das MT4j Framework steht als quelloffener Download, derzeit in Version 0.95 zur Verfügung und ist bereits als ein Eclipse-Projekt strukturiert.

MT4j läuft derzeit nur mit der 32bit-Variante von Java. Soll ein 64bit System eingesetzt werden, muss trotzdem der 32bit JDK installiert werden. Unter Eclipse muss entsprechend die 32bit Variante von Java zum Ausführen der MT4j Anwendungen ausgewählt werden!

1. Java Development Kit 32bit (gekennzeichnet als x86) herunterladen und installieren
2. Die heruntergeladene ZIP-Datei entpacken (MT4j 0.95 full release)
3. Im Paketexplorer von Eclipse mit Rechtsklick importieren wählen
4. In dem Importfenster ein „bereits existierendes Projekt“ auswählen
5. Den unter 2. entpackten Ordner auswählen und importieren

Import Schritt 2

Import Schritt 3

Import Schritt 1

Eclispe mit MT4j

Mitgelieferte Beispiele

Das MT4j-Paket enthält 19 einfache Beispielanwendungen. Diese sind unterteilt in die Pakete „basic“ und „advanced“ und sind im Ordner „examples“ zu finden. Die Basic Examples dienen zum Verstehen und Testen der grundlegenden Techniken in sehr einfach gehaltenen Applikationen. Die Advanced Examples demonstrieren die Leistungsfähigkeit des Frameworks, indem beispielsweise 3D Modelle verwendet werden. Jede Anwendung befindet sich in einem eigenen Paket. Es ist keine weitere Konfiguration erforderlich, da das Framework alle benötigte Komponenten automatisch sucht und auswählt. Zum Starten ist jeweils eine „Start…Example.java“ Datei hinterlegt, die als „Java Application“ in Eclipse ausgeführt werden kann. Nach dem Start öffnet sich ein neues Fenster innerhalb dessen die Multitouch-Interaktion möglich ist.

Basic-Anwendungen

css

helloworld

javagui

mtgestures

scenes

svgexample

Advanced-Anwendungen

drawing

flickrmt

fluidsimulator

models3d

modestmapsmt

mtShell

physics

puzzle

simpleparticles

space3d

touchtail

water

Minimalimplementierung

Eine Multitouch-Anwendung mit MT4j zu schreiben ist denkbar einfach, da sie nur zwei Klassen (Scene und MTApplication) benötigt. Die folgenden beiden Abschnitte geben einen Überblick über die Implementierung eine einfachen Applikation zur Bildmanipulation. Die Anwendung, die zum Selbsttest ebenfalls als Download verfügbar ist, ermöglicht es, ein Bild anzuzeigen und dieses mit Standard-Multitouch-Gesten zu manipulieren.

Scene

Eine „Scene als erste benötigte Bestandteil der Anwendung muss die abstrakte Klasse „AbstractScene“ erweitern. In dieser Klasse wird festgelegt, welche Komponenten angezeigt werden. Es gibt viele vorgefertigte Elemente, die insbesondere Standard-Multitouch-Gesten bereits beherrschen. Hierzu gehören beispielsweise Grafiken, Textfelder und Rahmen für verschiedene andere Objekte. Für unser Minimalbeispiel benötigen wir folgenden Code für die Scene-Klasse:

package MinimalExample;

import org.mt4j.MTApplication;
import org.mt4j.components.TransformSpace;
import org.mt4j.components.visibleComponents.widgets.MTImage;
import org.mt4j.input.gestureAction.InertiaDragAction;
import org.mt4j.input.inputProcessors.componentProcessors.dragProcessor.DragProcessor;
import org.mt4j.sceneManagement.AbstractScene;
import org.mt4j.util.math.Vector3D;

import processing.core.PImage;

public class PictureScene extends AbstractScene
{
  private String picturePath =  "MinimalExample" + MTApplication.separator + "data" + MTApplication.separator;

  public PictureScene (MTApplication mtApplication, String name)
  {
    super(mtApplication, name);

    MTApplication app = mtApplication;
    PImage img = app.loadImage(picturePath + "pic.jpg");
    MTImage image = new MTImage(img,app);
    image.setUseDirectGL(true);
    image.setPositionGlobal(new Vector3D(400,400,0));
    image.scale(0.2f, 0.2f, 0.2f, image.getCenterPointLocal(), TransformSpace.LOCAL);
    image.addGestureListener(DragProcessor.class, new InertiaDragAction());
    this.getCanvas().addChild(image);
  }

  @Override
  public void init() {}

  @Override
  public void shutDown() {}
}

Datei ist zu beachten, dass sich das entsprechende Bild im Paket „MinimalExample.data“ (gekennzeichnet als „picturePath“) befinden muss, damit es geladen werden kann!

MTApplication

Die „Application“-Klasse dient zum Starten der Anwendung und muss die abstrakte Klasse „MTApplication“ erweitern. Die vorher beschriebene Scene wird lediglich hinzugefügt. Anschließend wird die Anwendung mit dem Methodenaufruf „initialize()“ gestartet. Dazu sind lediglich die Folgenden Codezeilen erforderlich:

package MinimalExample;

import org.mt4j.MTApplication;

public class StartMinimalExample extends MTApplication
{
  private static final long serialVersionUID = 1L;

  public static void main(String args[])
  {
    initialize();
  }

  @Override
  public void startUp()
  {
    this.addScene(new PictureScene(this, "Picture scene"));
  }
}

Der vorliegende Artikel widmet sich dem Vergleich aktueller Outdoor-Touchscreen-Terminals im Hinblick auf die verwendeten Hardware-Komponenten und liefert einen kompakten Marktüberblick inkl. Preisangaben zum Jahreswechsel 2011-2012. Der Markt für interaktive Anzeigesysteme ist klein und insbesondere für Outdoor-Geräte existieren nur wenige Hersteller. Der Artikel wende sich an Firmen, Gemeinden oder öffentlichen Einrichtungen und ermöglicht einen transparenten Überblick. Nachdem der Beitrag im Rahmen einer studentischen Arbeit entstanden ist, verfolgt er keinerlei kommerzielles Interesse.

Einführung

Outdoor-Touchscreen-Terminals werden im öffentlichen oder halböffentlichen Raum eingesetzt. Je nach Aufstellungsort können sich die Einsatzbereiche stark unterscheiden und umfassen beispielsweise:

• Touristeninformation in Städten und Einkaufszentren
• Buchungssystem auf Flüghäfen, Bahnhöfe, Hotels oder in Firmen
• Internet- oder Surf-Terminals
• reine interaktive Werbeflächen

Verglichene Terminals

Im Artikel Outdoor-Touchscreens: Hardware und Komplettsysteme wurden bereits Touchscreen-Produkte inkl. der jeweiligen Hersteller oberflächlich vorgestellt. Darauf basierend folgt in diesem Artikel zunächst eine Übersicht konkreter Produkte und aufbauend auf einigen kurz beschriebenen Vergleichskriterien ¹ eine Gesamtübersicht, in der die unterschiedlichen Geräte einander gegenüber gestellt werden.

Kolembar – Hawk

Kolembar Hawk Terminal 32 ²

Das „Hawk“ Terminal ist ein sehr individuell konfiguriertbares Terminal. Das Gehäuse entscheidet über In- bzw Outdoor-fähigkeit sowie die Größe des Displays. Alle weiteren Hardwarespezifikationen können frei gewählt werden.

Weitere Informationen und Kontaktmöglichkeiten finden sie auf der Produktseite des Hawk beim Hersteller Kolembar.

SOLIDD – K8

SOLIDD K8 42 ⁷

Eine Besonderheit am „K8″ Terminal ist die im Preis enthaltene PC – Einheit zusammen mit der Umsetzung des Touchscreens und der Outdoor-Fähigkeit. Die Firma SOLIDD bietet hierzu ein Touchscreen Kit für verschiedene Displaygrößen und ein Outdoor-Kit an.

Weitere Informationen und Kontaktmöglichkeiten finden sie auf der Produktseite des K8 beim Hersteller SOLIDD.

friendlyway – grande 46

Diese Terminal wird von der Firma friendlyway nach aktuellen Informationen nicht mehr als Outdoor-Terminal produziert und zur Zeit als reines Indoorterminals vertrieben.

friendlyway grande 46

Beim „grande 46″ ist zu beachten, dass es ausschließlich als doppelseitiges Terminal zu erwerben ist. Daher ist der Grundpreis der Basiseinheit und ebenso der Preis der verfügbaren Addons höher. Weiterhin benötigt es zwei PC-Einheiten, um die beiden Displays zu betreiben. Der Preis für das Upgrade auf Multitouch wird entsprechend pro Display (und damit i.d.R. zweimal) fällig.

Weitere Informationen und Kontaktmöglichkeiten finden sie auf der Produktseite des grade 46 beim Hersteller friendlyway.

BV-comOffice – iMotion

BV-com Office Touchscreen imotion 52 ¹⁷

Das iMotion-Terminal gibt es in den größsten Display-Ausführungen von bis zu 70″. Dabei ist es möglich, die Displays auch in doppelseitiger Ausführung und (bis zur Größe von 65″) auch im Querformat einzubinden.

Weitere Informationen und Kontaktmöglichkeiten finden sie auf der Produktseite des imotion beim Hersteller BV-comOffice.

Vergleichskriterien

Neben den grundlegenden Komponenten eines Standard-Outdoor-Terminals wurde dabei insbesondere das Angebot an Peripherie betrachtet.

Basisgerät

Als Standard wurde neben der PC-Einheit ein mind. 32“ größes Single-Touch-Display ausgewählt. Die Bewertung des Basisgeräts basiert auf den im Preis enthaltenen Komponenten sowie den angebotenen Variationsmöglichkeiten.

PC- Einheit

Bei der PC-Einheit wurden die Komponenten der direkt miteinander verglichen. Die Bedürfnisse jeder Anwendung sind sehr unterschiedlich, doch die bisherigen Szenarien stellen keine sehr hohen Hardwareanforderungen. Daher werden von den Herstellern meist recht durchschnittliche Hardwarekomponenten verbaut. Single oder schwache Dual-Core-Prozessoren, Onboard-Grafikkarten, wenig RAM und Festplattenspeicher sind die Regel. Dies ist jedoch für die meisten Anwendungen vollkommen ausreichend. ²²

Touchscreen

Das wichtigste Element der Terminals ist das Touchscreen-Display. Es verbindet Anzeige und Eingabe und ist daher die kritischste Komponente des Terminals. Die verwendeten Technologien sind sehr unterschiedlich und bringen entsprechend unterschiedliche Eigenschaften mit sich. ²³ Gegenüber der Entwicklung bei Smartphones und Tablets ist Multitouch bei Outdoor-Terminals noch nicht zum Standard geworden. Im Vergleich hat unterstützt keines der Geräte Multitouch-Gesten oder mehrere simulane Touch-Punkte. ²⁴

Peripherie

Da das Angebot an optionalen Erweiterungen sehr unterschiedlich ist und einige Firmen erst auf Anfrage bestimmte Geräte verbauen, beschränkt sich der Vergleich auf die Anzahl der angebotenen Komponenten.

Gesamtübersicht

Die folgende Gesamtübersicht zeigt die vorgestellten Vergleichskriterien der vier Terminals im direkten Vergleich.

Terminal. 25	Basisgerät 26	PC- Einheit 27	Touchscreen 28	Peripherie 29	Summe
Kolembar – Hawk					5.570,00 €
Solidd – Infosäule K8					5.285,50 €
friendlyway – grande 46					8.150,00 €
BV-comOffice – imotion					9.620,00 €

Zusammenfassung

Der vorliegende Artikel gibt eine grobe Markübersicht über Outdoor-Touchscreen-Terminals sowie deren Komponenten. Oftmals sind bei heutigen Lösungen nicht die Größe der Touchscreens oder die Leistungsstärke der PC Einheiten entscheidend,  sondern je nach Anwendung und Einsatzgebiet bestimmte Komponenten, die nicht jeder Hersteller anbietet. Im Vergleich ist beispielsweise Kolembar der einzige Hersteller, der einen Barcodescanner oder Telefonhörer anbietet. Gleiches gilt für BV-com Office für 3G bzw. UMTS und Bluetooth-Übertragung.

Ansonsten stechen Hersteller und Produkte primär durch Sonderfunktionen bzgl. der Bauweise des Geräts hervor: Beispiele sind

• High Brightness Displays, die auch bei hoher Sonneneinstrahlung gut zu erkennen sind,
• Sonderlackierungen, um mehr Aufmerksamkeit auf das Terminal zu lenken,
• Schutzlackierungen gegen Graffitis oder
• Rollen unter dem Gerät, um es bei Bedarf im halböffentlichen oder privaten Bereich flexibel einzusetzen.

Aufgrund der sonst sehr ähnlichen Eigenschaften bieten insbesondere diese Kriterien Potenzial für Differenzierungsstrategien, da sie für Kaufentscheidungen eine entscheidende Rolle spielen können. Die neuste Entwicklung zeigt jedoch auch ganz andere sekundäre Funktionen für Outdoor-Terminls. Das in diesem Artikel aufgeführte Terminal iMotionvon BV-comOffice gibt es beispielsweise in einer „HELP-Ausführung“, die einen Defibrilator beinhaltet, der im Notfall von jedem Passanten entnommen werden kann. Dabei setzt das Terminal einen Notruf ab und zeigt Videos von lebensrettenden Sofortmaßnahmen.

Danksagung

Besonderer Dank gilt den folgenden Ansprechpartnern der jeweiligen Firmen für die Bereitstellung der oben aufgeführten Daten und die Genehmigung der Veröffentlichung, ohne die der vorliegende Artikel nicht möglich gewesen wäre: Kolembar Industrietechnick: Dipl. Ing Hans Wilhelm, SOLIDD: Derek Owen, friendlyway: Florian Sommer, BV-comOffice: Jan Nätscher.

"Weitere Informationen und Kontaktmöglichkeiten finden sie auf der Produktseite des grade 46 beim Hersteller friendlyway."

Mit dem Erscheinen von Microsoft Kinect als Zubehör für die Spielekonsole Xbox 360 im November 2010 wurde erstmal ein kostengünstiger Infrarot-Tiefensensor für eine breite Nutzerschaft verfügbar und schuf somit die Möglichkeit zur Entwicklung von Anwendungen, die durch eine gestenbasierte Nutzerinteraktion ohne zusätzliche Eingabegeräte das Potential zur Revolution der Gestaltung der Human-Computerrec Interaction versprechen. Daher entstand in kurzer Zeit eine Community, die die Anbindung an einen PC zunächst mit selbstentwickelten Treibern, einige Wochen später dann mit Treibern und Software Development Kit (SDK) von dem ebenfalls an der Entwicklung von Kinect beteiligten Unternehmen Primesense ermöglichte und erste Anwendungen mit vielfältigen Anwendungsgebieten veröffentlichte. Während Microsoft selbst diesen Trend zunächst nicht unterstützte, wurde dann im Mai 2011 ein offizielles „Kinect for Windows SDK“ veröffentlicht. Durch die unterschiedliche Dauer der Verfügbarkeit der verschiedenen Gerätetreiber und der darauf aufbauenden SDKs haben sich unterschiedliche Entwicklergemeinden gebildet. Daher gibt es derzeit mehrere verschiedene Anwendungen, die zur Steuerung eines Mauszeigers durch die Kinect-Hardware eingesetzt werden können. Jede dieser Anwendungen unterscheidet sich in der Art der Bedienung oder Funktionsumfang. In diesem Artikel werden einige der verfügbaren Anwendungen näher betrachtet und anhand der Kriterien Einsatzentfernungen, Genauigkeit der Zeigerpositionierung, Zuverlässigkeit der Auswahlgesten, Stabilität der Anwendung und Konfigurierbarkeit mit einander verglichen.

Kinect Maus-Emulatoren

Die Grundlage des Artikels bilden die Anwendungen FAAST, Kinemote und PCD auf der Basis des von Primesense veröffentlichten OpenNI SDK sowie Kinect Cursor Control auf Basis des Kinect for Windows SDK von Microsoft. Neben diesen frei verfügbaren Anwendungen zur Steuerung des Mauszeigers mit dem Kinect Tiefensensor wird nachfolgend auch eine kommerziell vertriebene Anwendung betrachtet. Dabei handelt es sich um um die Anwendung WIN&I, die von der Evoluce AG angeboten wird.

KinEmote

KinEmote ¹ ist ein Framework, das verschiedene Anwendungen zur Nutzung der Microsoft Kinect bündelt. Es greift dazu auf das OpenNI Framework ² zurück, welches die Verwendung der verschiedenen von der Kinect gelieferten Sensordaten ermöglicht. OpenNI wurde von einer  Non-Profit-Organisation veröffentlicht, an der unter anderem auch Primesense mitwirkt. Primesense entwickelte zusammen mit Microsoft den Kinect-Sensor.

Neben Anwendungen zur Steuerung des Xbox Media Centers und der Medienserveranwendung Boxee mit Handgesten sowie der Emulation von bis zu acht zuvor konfigurierten Tastatureingaben durch das Bewegen der Hand nach oben, unten, links und rechts bei gestrecktem oder gebeugtem Arm kann KinEmote auch zur Steuerung des Mauszeigers genutzt werden. Dazu kommt eine Kombination von relativer und absoluter Positionierung des Zeigers zum Einsatz. Während viele Anwendungen zur Maussteuerung mittels Kinect ein imaginäres Rechteck im Raum aufspannen und die Position der Hand in diesem Rechteck auf eine absolute Position auf dem genutzten Display abbilden, wird bei der virtuellen KinEmote Maus die relative Bewegung der Hand zwischen Start- und Endpunkt der Handbewegung auf eine Bewegung des Mauszeigers übertragen. So kann der Nutzer mit einer schnellen kurzen Bewegung der Hand einen rasche Verschiebung des Zeigers über eine große Strecke realisieren aber auch durch eine langsame Bewegung der Hand über eine große Strecke eine präzise Verschiebung des Zeigers in einem kleinen Radius auf dem Display erreichen.

KinEmote

Andere Anwendungen mit relativer Zeigerpositionierung nutzen häufig einen statischen Referenzpunkt mittig vor dem Körper und bilden z.B. eine Handbewegung nach rechts oben von der Körpermitte auf eine Zeigerbewegung nach rechts oben ab. Da KinEmote den Endpunkt der letzten Bewegung als neuen Referenzpunkt für die nächste Bewegung nutzt, lässt sich die Anwendung ähnlich bedienen, wie eine Anwendung mit absoluter Zeigerpositionierung, wodurch der Nutzer ein direkteres Feedback für die durchgeführte Handbewegung erhält, als bei einer relativen Positionierung mit statischem Referenzpunkt. Die Kombination von absoluter und relativer Positionierung erlaubt also eine schnelle aber dennoch präzise Verschiebung des Zeigers.

Der Benutzer beginnt die Interaktion durch eine Winkbewegung aus dem Handgelenk. Es können sowohl die linke als auch die rechte Hand zur Interaktion genutzt werden. Da die Anwendung in einem Abstand von einem bis vier Metern vor dem Sensor genutzt werden kann und sehr stabil läuft, ist KinEmote gut geeignet, um die Funktionen einer herkömlichen Computermaus zu emulieren. Ein Auswahl-Event wird durch das Vor- und Zurückführen der Hand ausgelöst, mit der auch der Zeiger positioniert wird. Da keine Parameter zur Konfiguration des Select-Events verfügbar sind, kommt es häufig vor, dass beim Versuch einen Klick auszuführen eine versehentliche Neupositionierung des Zeigers erfolgt. Außerdem wird gelegentlich kein Klick ausgelöst, obwohl der Nutzer dies beabsichtigt.

FAAST

Das Flexible Action and Articulated Skeleton Toolkit (FAAST) ³ ist eine am Institute for Creative Technologies der University of Southern California entwickelte, auf dem OpenNI SDK basierende Anwendung, die es erlaubt verschiedene Gesten zu erfassen und damit mittels einer einfachen Syntax definierbare Maus- oder Tastatur-Events zu emulieren. Auf diese Weise können dann andere Anwendungen mit den zuvor konfigurierten Gesten bedient werden. Die Anwendung kann dazu zwischen der Fokussierung bei der Gestenerkennung auf den gesamten Körper, den Oberkörper, den Unterkörper oder die Hand unterscheiden. Je größer der fokussierte Bereich ist, desto mehr Gesten können erkannt werde. Allerdings sinkt damit auch die Präzision der Erkennung der ausgeführten Gesten.

Eine präzise Steuerung des Mauszeigers ist leider aktuell nur bei der Fokussierung auf die Hand möglich. Durch die Fokussierung auf die Hand können jedoch keine Gesten mit anderen Körperteilen erfolgen, weshalb es mit FAAST nicht möglich ist, gleichzeitig eine genau Positionierung und eine zuverlässige Auswahlgeste zu erreichen. Bei einem Fokus auf den Oberkörper kann dann beispielweise konfiguriert werden, dass der linke Arm leicht nach vorne geführt werden muss, um einen Klick auszulösen, während der rechte Arm zum Positionieren des Zeigers genutzt wird. Die Syntax zum konfigurieren der Geste-Event Belegungen hat folgende Form:

<Gestenbezeichnung> <Positionsveränderungzum Auslösen der Geste in Inch/Zoll> <Auszulösendes Event> <Konkretisierung des Events>

Dabei müssen die einzelnen für die Platzhalter in der Syntax eingetragenen Spezifizierungen genau ein Leerzeichen Abstand haben und Leerzeichen in den Spezifizierungen durch einen Unterstrich ersetzt werden. Ein Beispiel für eine Gesten-Event Konfiguration könnte folgendermaßen aussehen:

left_arm_forwards 5 mouse_click left_mouse_button

Damit wird bei einer Bewegung des linken Arms um fünf Zoll (also 12,7cm) nach vorn ein einzelner Klick mit der linken Maustaste ausgelöst. Eine detaillierte Auflistung aller verfügbaren Gesten und auslösbaren Events mit der dafür zu verwendenden Spezifizierung ist auf der Website zur Anwendung erhältlich.

Fokusbereiche von FAAST

Neben den programmierbaren Geste-Event Kombinationen gibt es außerdem eine Reihe von Parametern, die zur Individualisierung des Interaktionsbereichs und zur Feinjustierung der Bewegungsglättung zur präziseren Zeigerpositionierung genutzt werden können. So können unter anderem der fokusierte Körperteil, die Stärke der Bewegungsglättung und die Art der Zeigerpositionierung gewählt werden. So erlaubt FAAST als einzige betrachtete Anwendung die individuelle Konfiguration des Bereichs, in dem die Bewegungen der Hand des Nutzers auf Bewegungen des Zeigers auf dem Bildschirm zur absoluten Positionierung übertragen werden. Insgesamt bietet FAAST die umfassendsten Konfigurations- und Individualisierungsoptionen.

Konfigurationsoptionen von FAAST

WIN & I

WIN&I ⁴ ist eine von der Evoluce AG kommerziell vertrieben Anwendung zur Emulation der Maussteuerung mit dem Microsoft Kinect Sensor auf Basis des OpenNI SDK. Die Anwendung nutzt dieselbe Form der relativen Positionierung wie die Virtual Mouse des KinEmote Anwendungspaketes und erlaubt eine ebenso präzise Zeigerpositionierung. Jedoch wird bei WIN&I bei einer schnellen Handbewegung eine weitere Verschiebung des Zeigers vorgenommen als bei KinEmote, sodass die Steuerung des Zeigers insgesamt einen agileren Eindruck vermittelt und so ein direkteres Feedback liefert.

Außerdem erlaubt die Anwendung die Nutzung aller Mausfunktionen über die Implementierung eines Gestenmodus. Hält der Benutzer die Hand für eine gewisse Zeitspanne, die über einen Parameter grob anhand der Nutzererfahrung konfiguriert werden kann, still, so erscheint statt des Mauszeigers ein Und-Symbol. Ist der Gestenmodus auf diese Weise aktiviert worden, kann der Nutzer nun durch die Bewegung der Hand in eine Richtung einen Mouse-Event auslösen, ohne dabei den Zeiger zu verschieben. Nach der Aktivierung des Gestenmodus löst beispielsweise eine Bewegung
der Hand nach links einen Linksklick aus. Eine Bewegung der Hand nach rechts bewirkt
einen Rechtsklick. Eine Auswahl der Ziele durch Ausstrecken und Zurückziehen des Arms
ist dennoch möglich. Somit ist WIN&I die einzige getestete Anwendung, die ein präzises Positionieren des Zeigers und ein zuverlässiges Auswählen der Ziele zulässt. Zudem läuft die Anwendung sehr stabil und kann in einer Entfernung von einem bis vier genutzt werden.

WIN&I in Nutzung ⁵

PCD

Palm Click and Drag (PCD) ⁶ ist eine auf OpenNI aufbauende Anwendung der Entwickler des KinEmote-Anwendungspakets. Anders als die virtuelle Maus des KinEmote-Paketes kann mit PCD eine präzise Platzierung des Zeigers über eine absolute Positionierung erfolgen. Startet der Benutzer die Interaktion durch eine Winkgeste, so wird ein im Vergleich zu anderen Anwendungen mit absoluter Zeigerpositionierung kleines imaginäres Rechteck um die Position der Hand gebildet. Da bei der absoluten Positionierung die Position der Hand im imaginären Rechteck auf die Position des Zeigers auf dem Display abgebildet wird, kann der Nutzer schnell die äußeren Positionen des Displays erreichen und dabei stets eine angenehme Körperhaltung beibehalten. Die gute aber nur teilweise konfigurierbare Bewegungsglättung erlaubt zudem eine präzise Positionierung im zentralen Displaybereich, die stets ohne ein Springen des Zeigers erfolgen kann.

Den Namen „Palm Click and Drag“ trägt die Anwendung wegen ihrer verschiedenen Interaktionsmodi. Zur Unterscheidung der Modi bildet das Framework eine Umrandung der Hand. Im Modus „Palm“ kann der Zeiger bei geöffneter Hand und gespreizten Fingern positioniert werden. Dabei ist sowohl die horizontale, als auch die vertikale Ausdehnung der Umrandung der Hand maximal. Führt der Nutzer die Finger zusammen, gelangt er in den Modus „Click“, der eine Betätigung der linken Maustaste emuliert. Dazu erfasst die Anwendung die verringert horizontale Ausdehnung der Handumrandung bei weiterhin maximaler vertikaler Ausdehnung. Schließt der Nutzer nun zusätzlich die Hand und ballt sie somit zu einer Faust, gelangt er in den Modus „Drag“ und emuliert so ein Drag-Event (Halten der linken Maustaste), das beim Öffnen der Hand mit einem Drop-Event (Loslassen der linken Maustaste) beendet wird. Die horizontale und vertikale Ausdehnung der Handumrandung haben sich gegenüber dem „Palm“ Modus verringert. Auf diese Weise können alle Mausevents, die mit der linken Maustaste einer Rechtshändermaus ausgelöst werden, stattfinden. Ein Doppelklick erfolgt z.B. durch zweifaches schnelles Zusammenführen und Spreizen der Finger.

Die Anwendung bietet einige Konfigurationsmöglichkeiten, welche die Präzision der Interaktion mit der Anwendung sowie die emulierbaren Events beeinflussen. Mit dem Schieberegler „History amount for averaging (0-10)“ kann beispielsweise die Anzahl der für die Errechung der Handumrandung genutzten Positionsdaten der Hand zwischen null und zehn Frames variiert werden. Mit einem hohen Wert lässt sich zwar die Präzision der Zeigerpositionierung und dieZuverlässigkeit der Klickerkennung steigern, jedoch steigt dabei auch die benötigte Rechenleistung an. Mit dem Schieberegler „Averaging“ kann der Detailgrad der für die Errechnung der Handumrandung genutzten Positionsdaten variiert werden, um die benötigte Rechenleistung zu reduzieren, da Anfangs der Maximalwert eingestellt ist. Mit dem Regler „Open/Close Delta“ kann die nötige Verringerung der maximalen Ausdehnung der Handumrandung bis zum Auslösen der Click- und Drag-Events beeinflusst werden. Jedoch führt auch eine starke Verringerung dieses Wertes nicht zu einer zuverlässigeren Auslösung der Auswahlevents bei einer Entfernung von mehr als 2,50m. Zusätzlich kann die Positionierung des Zeigers und das Auslösen der Klick-Events aktiviert bzw. deaktiviert werden und eine emulierte Tastatureingabe beim Start der Interaktion durch die Winkgeste oder beim Beenden der Interaktion durch Entfernen der Hand aus dem imaginären Rechteck zur Positionierung eingestellt werden.

Palm Click and Drop

Kinect Cursor Control

Kinect Cursor Control ⁷ ist eine Anwendung zur Steuerung des Zeigers mittels Kinect und basiert auf dem „Kinect for Windows SDK“ ⁸ von Microsoft. Die Anwendung ermöglicht eine absolute Positionierung des Zeigers durch die Bewegung der rechten Hand im von der Anwendung angezeigten Bildausschnitt und eine entsprechende Abbildung der Position der Hand im Bildausschnitt auf die Position des Zeigers auf dem Display.

Da jedoch das imaginäre Rechteck zur Positionierung zu groß gewählt ist, können nicht alle Stellen des Displays mit dem Cursor erreicht werden, sodass bei der Nutzung mit der rechten Hand ein Bereich auf der linken Seite des Displays nicht erreicht wird und bei der Nutzung mit der linken Hand ein Teil am rechten Rand des Displays. Außerdem muss der Arm häufig weit angehoben und weit über die Körpermitte bewegt werden, sodass die Schulter bei der Interaktion schnell ermüdet. Zusätzlich kann es bei der Positionierung der Hand direkt vor dem Körper zu einem starken Springen des Zeigers kommen, da dort die Position der Hand nicht klar erkannt werden kann. Andererseits beinhaltet die Anwendung einen zuverlässigen Mechanismus zum Auslösen eines Select-Events. Um einen Klick auszuführen, muss der Arm, der nicht zur Positionierung genutzt wird, gestreckt angehoben und kurz dort gehalten werden. So kann ein Klick ausgelöst werden, ohne versehentlich den Zeiger neu zu positionieren. Die zu starke Bewegungsglättung der Anwendung führt jedoch dazu, dass die Steuerung des Zeigers träge und indirekt wirkt, sodass eine Nutzung der Anwendung zur Steuerung eines Rechners nicht dauerhaft und ohne Einschränkungen möglich ist.

Kinect Cursor Control

Vergleichskriterien

Nachdem die einzelnen Anwendungen vorgestellt und beschrieben wurden, folgt an dieser Stelle eine Übersicht über  im Hinblick auf die für den Einsatz zur PC-Interaktion relevanten Kriterien. Dafür werden zunächst die verwendeten Vergleichskriterien Art der Zeigerpositionierung, Präzision der Zeigerpositionierung, Zuverlässigkeit der Auswahlgeste, maximale und minimale Einsatzentfernung sowie Stabilität der Anwendung erklärt, bevor anschließend eine tabellarische Einordnung der einzelnen Anwendungen anhand der genannten Kriterien erfolgt.

Art der Zeigerpositionierung

Zur Positionierung des Mauszeigers werden bei den betrachteten Anwendungen drei verschiedene Methoden genutzt. Die erste Methode, die absolute Positionierung, spannt ein imaginäres Rechteck im Raum auf und bildet die Position der Hand des Nutzers innerhalb des Rechtecks auf die entsprechende Position des Mauszeigers auf dem genutzten Display ab. Damit diese Methode auch bei unterschiedlichen Entfernungen des Nutzers zum Display funktioniert, muss das imaginäre Rechteck indirekt proportional zur Entfernung des Nutzers skaliert werden. Die zweite und dritte Methode zur Positionierung des Zeigers basieren auf einer relativen Handbewegung, also einer Bewegung der Hand relativ zu einem Bezugspunkt im Raum. Während eine Form der relativen Positionierung einen statischen Bezugspunkt wählt und somit beispielsweise ein Bezugspunkt in der Körpermitte und eine Bewegung der Hand auf die linke Körperseite immer eine Zeigerverschiebung nach links bewirkt, wird bei der anderen Form der relativen Positionierung der Bezugspunkt für die Bewegung ständig an der Stelle, an der die Handbewegung endet, neu gesetzt. Durch die gerade beschriebene adaptive relative Positionierung kann ein ähnliches Nutzungsgefühl wie bei der absoluten Positionierung erreicht werden und dennoch eine genauere Platzierung erfolgen.

Präzision der Zeigerpositionierung

Die Präzision, mit welcher der Zeiger über einem Objekt positioniert werden kann, ist abhängig von der Bewegungsglättung, die die zu Grunde liegende Anwendung nutzt, um die Sensordaten in eine Zeigerbewegung umzusetzen. Je nachdem, wie die dafür relevanten, häufig nicht beeinflussbaren Parameter in der jeweiligen Anwendung gesetzt wurden, kann der Zeiger ein sehr unruhiges Verhalten mit einem starken „Jitter“ (Flattern) zeigen. Außerdem kann es vorkommen, dass die Zeigerposition zu selten aktualisiert wird, sodass der Zeiger wie auf einem groben Raster entweder stillsteht oder einen Sprung von einem Rasterpunkt zum nächsten vollzieht ohne eine gleichmäßige, gut kontrollierbare Bewegung zu ermöglichen.

Zuverlässigkeit der Auswahl

Die Zuverlässigkeit mit der die Auswahl eines Ziels nach der Zeigerpositionierung ausgelöst werden kann, hängt wesentlich von der Geste ab, die von der Anwendung zum Auslösen des Mouseclick-Events genutzt wird. Während einige Anwendungen die Manipulation zur Positionierung völlig von der Geste zum Auswählen trennen, gehen bei anderen Anwendungen beide Interaktionen fließend ineinander über. Liegen die Gesten zum Positionieren und Auswählen nah beieinander ⁹, so wird die Auswahlgeste insbesondere bei einer kurzen Entfernung des Nutzers zum Kinect Sensor häufig als Neupositionierung erkannt, weshalb der Zeiger bei kleinen Zielen versehentlich aus dem Zielbereich bewegt wird. Daher kann eine zuverlässigere Auswahl erfolgen, wenn die Positionierung z.B. mit der rechten Hand und die Auswahl durch Anheben der linken Hand oder eine anderen Geste, welche die Position der rechten Hand nicht beeinflusst, erfolgen. Müssen Positionierung und Auswahl zwingend mit ein und derselben Hand erfolgen, hat sich das Halten der Hand an der zur Auswahl gewünschten Position für eine gewisse Zeitspanne zum „Einrasten“ des Zeigers an dieser Stelle statt einer zusätzlichen Auswahlgeste als zuverlässig erwiesen, da sich hierbei die Auswahlposition nicht versehentlich verändert. Ein weiterer Einflussfaktor für die Zuverlässigkeit der Auswahl ist die Sensibilität der Auswahlgeste. So kann je nach Anwendung bereits bei einer Andeutung der Auswahlgeste versehentlich ein Klick ausgelöst werden, wohingegen eine zu wenig sensible Auswahlgeste dazu führt, dass zu wenige oder gar keine Klicks ausgelöst werden. Beides führt beim Nutzer dazu, dass er die ausgelösten Interaktionen nicht nachvollziehen kann, da sie von ihm nicht beabsichtigt sind.

Maximale und minimale Einsatzentfernung

Der Abstand, mit dem ein Nutzer eine Anwendung zur Emulation der Maussteuerung verwenden kann, wird nicht durch die Sichtweite des Kinect Sensors, sondern durch die minimale und maximale Distanz der zuverlässigen Erkennung der Auswahlgeste bestimmt, die wiederum von dem Sichtfeld und der Auflösung des Infrarotkamerabildes abhängt. Zwar kann die Infrarotkamera des Kinect Sensors Tiefenwerte in einer Entfernungsspanne von einem halben bis sieben Metern liefern, jedoch muss der fokussierte Körperteil vollständig im Sichtfeld liegen, weshalb die Minimalentfernung bei Fokussierung auf die Hand zwischen einem halben und einem Meter, bei Fokussierung des gesamten Körpers jedoch bei mindestens eineinhalb Metern liegt. Da der Nutzer bei zunehmender Entfernung vom Sensor einen kleiner werdenden Teil des Sensorsichtfeldes einnimmt, kann es wegen der geringen Auflösung der Infrarotkamera von 640 x 480 Pixel dazu kommen, dass kleine Bewegungen nicht mehr erkannt und somit manche Auswahlgesten nicht wahrgenommen werden. Daher schwankt die maximale Nutzungsentfernung mit der genutzten Auswahlgeste z.T. sehr stark. ¹⁰

Stabilität der Anwendung

Eine Anwendung ist für die „stabil“, wenn sie während eines Evaluationsdurchlaufs mit einer Dauer zwischen 30 und 90 Minuten nicht unplanmäßig beendet wird. Einige Anwendungen stürzten während der Tests nach einer kurzen Zeitspanne ab, schlossen sich gelegentlich unvorhergesehen, wenn der Fokus des zur Steuerung genutzten Körperteils verloren wurde oder konnten nicht mehr genutzt werden, wenn eine Konfiguration der  bereitgestellten Optionen / Parameter vorgenommen wurde.

Zusammenfassung

Abschließend werden die oben vorgestellten Merkmale der betrachteten Maus-Emulatoren anhand eigener Beobachtungen im Hinblick auf die zuvor beschriebenen Eigenschaften in tabellarischer Form zusammengefasst. Die Beurteilung der Anwendungen erfolgte dazu durch eine einfachen Auswahlaufgabe, bei der der Nutzer den Cursor über einem Ziel platzieren und dieses anschließend auswählen musste. Diese Aufgabe wurde mit jeder Anwendung aus verschiedenen Entfernungen zum Kinect Sensor wiederholt, wobei die verschiedenen Frameworks wie folgt abschnitten:

Bewertungskriterium	KinEmote	FAAST	WIN&I	PCD	Kinect Cursor Control
Art der Zeigerpositionierung	adaptiv relativ	absolut oder statisch relativ	adaptiv relativ	absolut	absolut
Präzision der Zeigerpositionierung		11
Zuverlässigkeit der Auswahl	12	13	14	15	16
Min. / max. Einsatzentfernung	1m – 4m	1m – 4m	0,75m – 4m	1m – 2,5m	1m – 3m
Stabilität der Anwendung

In diesem Howto wird gezeigt wie Interaktionskomponenten für Touchscreen Systeme mit Adobe Illustrator erstellt werden können, um diese mittels JavaFX interaktiv in einer GUI einzubinden. Dies geschieht exemplarisch anhand des in einer Bachelorarbeit entwickelten GUI-Entwurfs für ein Fussgänger-Navigationssystems der UnibwM.

Wichtige Elemente für die GUI eines Touchscreen Systems sind neben Buttons v.a. Elemente zur Auswahl von Listenelementen und Einstellungen. Aus diesem Grund zeigt das vorliegende Howto neben Buttons auch das Erstellen von Dropdown-Elementen und Layern für Texte. Dabei ist der grundlegen Aufbau dieser Elemete gleich, nur im Aussehen unterscheiden sie sich.

Zunächst betrachten wir einen Screenshot der GUI des oben verlinkten Navigationssystems.

Fussgängernavigation Startscreen ¹

Grundsätzlich muss zwischen zwei Arten von Elementen unterschieden werden, zum Einen die, die zur Laufzeit erst erstellt werden und zum Andern die Elemente, die aus bestehenden Dateien gelanden werden. In dieser GUI sind die grauen Elemente des Hintergrunds sowie alle Button-Texte durch den Programmcode erzeugt. Bei den Hintergrundelementen geschieht dies, da sie sehr simple sind und so variabel an die Fenstergröße anpasst werden können. Die Texte werden durch den Namen der Buttons bestimmt und sind daher durch den Programmcode realisiert.

Erstellen von Hintergrundelementen einer Gui

Zunächst werfen wir einen Blick auf die einfachen Element, die nicht interaktiv verwendet werden, und ihre Realisierung in JavaFX.

GUI - Hintergrund ¹

Die Hintergrundfläche wird durch ein einfaches graues Rechteck realisiert. Dabei muss jedes Element das in der GUI angezeigt wird einem „content“ zugeordnet werden. Was es damit genau auf sich hat wird später genauer erklärt.

var rect = Rectangle {
	x: 0  y: 0
	width: FWIDTH  height: FHRaster*(1+4*BLayer)
	fill: Color.LIGHTGRAY
}
insert rect into gui.content;

Linien oder Texte können einer Oberfläche direkt oder einem anderen Objekt zugeordnet werden.

var ddbHline = Line {
	startX: 0  startY: FHRaster*(1+3+4*BLayer)
	endX: FWIDTH  endY: FHRaster*(1+3+4*BLayer)
}
insert ddbHline into ddbFrame.content;

var text = Text {
	font: Font { size: 16 *rate }
	content: BTitle[type]
}
insert text into buttons.content;

Komplexere Elemente können mithilfe der von Sun bzw. inzwischen Oracle bereitgestellten JavaFX Production Suit in Adobe Illustrator erstellt werden und nach dem Exportieren als „FXZ-Datei“ eingebunden werden ². Im Beispiel der GUI des Fussgänger- Navigationssystems wurden die Buttons zur Auswahl der Navigation sowie zur Steuerung der Karte in AI erstellt. Wie diese nach dem Export in das Programm eingebunden werden, beschriebt der letzte Abschnitt dieses Howtos. Zunächst wird jedoch erklärt, wie solche Elemente in AI erzeugt werden.

Erstellung der Buttons für das Fussgängernavigationssystem

Zunächst wurde ein erster Entwurf der erforderlichen grafischen Elemente von einer Designerin anhand von GUI Mock-Ups erstellt. Diese Elemente wurden anschließend weiter bearbeitet und an die Vorstellungen der grafischen Oberfläche angepasst.

Normale Buttons

Die Abbildung zeigt den Button aus dem Mock-Up links, sowie den von der Grafikerin erstellten Button, mit zwei unterschiedlichen Zuständen (Mitte). Rechts befinden sich die Zustände, nachdem sie an das vorgegebene Farbschema angepasst wurden.

Umsetzung der Mock- Ups ¹

Die Buttons besitzen eine Grundfläche und entsprechende Layer. Durch einen mehrfarbigen Hintergrund und weitere Effekte können verschiedene Abstufungen geschafft werden. Hierzu muss es einen Layer geben, in dem Texte oder Symbole eingefügt werden können. Die nachfolgende Abbildung zeigt eine sinnvolle Anordnung der Layer und ihre Bezeichnung, um sie in der GUI zu verwenden.

Aufbau der Button-Ebenen ³

Die Buttons benötigen sinnvollerweise aussagekräftigen Icons, um ihrer Funktionalität zu beschreiben. Die meisten der hier verwendeten Icons stammen von der Internetseite „The Noun Projekt“. Diese Seite sammelt spezielle Symbole, auch Piktogramme genannt, die auf der ganzen Welt einheitlich verwendet werden, um einen bestimmten Zweck auszudrücken. Bei dem sehr hilfreichen Projekt geht es im Prinzip darum, eine visuelle Sprache zu erzeugen, die es ermöglicht, jkulturunabhängig ausschließlich anhand der verwendeten Symbole zu kommunizieren.

Verwendete Piktogramme ⁴

Die Problematik einer nicht fest definierten Sprache ist jedoch, dass man sie schnell missverstehen kann. Die verwendeten Icons müssen daher gut überlegt sein. Im Falle der zu Grunde liegenden Bachelor Arbeit wurden zu jeder Aktion mehrere unterschiedliche Buttons erstellt, die dann durch eine kurze Benutzerstudie bewertet wurden. Fall keines der Standard-Icons ausreichend gut wiedererkannt wird, kann es durchaus notwendig sein, eigne Icons zu entwickeln. Dies geschah im vorliegenden Fall beispielsweise für den Button „militärisch“ der Navigationssoftware, da die Seite „The Noun Projekt“ keine sinnvollen Möglichkeiten bat. Die folgende Abbildung zeigt einige der erstellten Icons.

Button Icons ¹

Dropdown Listen

Für die GUI des Navigationssystem wurde eine eigene Dropdown Box entwickelt. Das Konzept der Dropdown Boxen ist in den folgenden Abbildungen gezeigt. Die Form und Anordnung der Elemente ist an die der Navigationsführung der Cityterminals 2.0 angelehnt. Die linke Abbildung zeigt die Umsetzung auf einem Cityterminal. In der rechten Abbildung ist das entwickelte Mock-Up-Konzept und die grafisch verfeinerte Realisierung zu sehen.

Dropdown Elemente ¹

Institution auswählen (1) ¹

Institution auswählen (2) ¹

Institution auswählen (3) ¹

Institution auswählen (4) ¹

Navigationsfuhrung Cityterminal ¹

Alle Dropdown Elemente sind im Grunde aufgebaut wie ein normaler Button. Durch die verschiedenen Formen ist es möglich die Zustände, wie geschlossene oder geöffnete Boxen, voneinander abzuheben. Wie bereits beim Button, kann als Inhalt hier genauso zwischen Text oder Symbolen gewählt werden.

Leiste zum Zoomen

Zoom Leiste ¹

Die in der Abbildung gezeigte Leiste zum Zoomen der Lagekarte funktioniert über zwei Buttons sowie den Schiebregler in der Mitte. Derartige Elemente sind mit JavaFX natürlich individuell erstellbar und können der GUI eine Vielzahl neuer Funktionen geben.

Sowohl die Textfelder als auch die Leiste wurden an Farben und Formen des vorgegebenen Designs angepasst und fügen sich somit gut in das Gesamtbild. Die einfachen Buttons der GUI haben dabei zwei verschieden abgestufte Orangetöne. Die Textfelder sind grau und können auch durch orange hervorgehoben zu werden (z.B. für einen aktiven Zustand). Alle Elemente dieser Abbildung zusammen erzeugen die GUI der Navigationssoftware. Wie diese in JavaFX eingebunden werden, zeigt der folgende Abschnitt.

Elemente der GUI des Navigationssystems ¹

Einbinden exportierter FXZ-Dateien

Um nach einem Export die Daten verwenden zu können müssen sie in JavaFX geladen werden und entsprechend dem „content“ zugeordnet werden. Das Laden der Elemente wird durch folgendes Codefragment realisiert.

fxdGUI = FXDNode {
	url: "{__DIR__}GUI.fxz"
	backgroundLoading: true
	placeholder: Text { x: 10 y: 10 content: "Loading Gui ..."}
	loader: FXDLoader {
		onDone: function() {
			//Aufruf der Funktion zur Erstellung der GUI
			loadGUI();
		}
	}
};

Das Positionieren in der GUI sowie das endgültige Hinzufügen geschieht durch folgende Ausschnitte aus dem Programmcode:

var button = fxdGUI.getNode(BTitle[type]);
var duplicate = Duplicator.duplicate(button);

//Button wird zuerst an die Koodinate 0,0 gesetzt
duplicate.translateX = -(duplicate.impl_getPivotX()-(duplicate.layoutBounds.width/2)*duplicate.scaleX);
duplicate.translateY = -(duplicate.impl_getPivotY()-(duplicate.layoutBounds.height/2)*duplicate.scaleY);
duplicate.onMouseClicked=buttonpressed;

insert duplicate into buttons.content;
insert text into buttons.content;

Ein wesentlicher Vorteil einer Umsetzung der GUI mit JavaFX und Adobe Illustrator ist die Trennung zwischen Programmierer und Designer. So kann bei guter Programm-Realisierung die GUI vom Designer verändert werden ohne das dabei der Quellcode geändert werden muss. Beispielsweise reicht es, wenn der Designer einen neuen Button erzeugt und ihn nach einem gegeben Muster benennt. Beim nächsten Erneuern der GUI übernimmt der Code den Button einfach und fügt ihn zum „content“ hinzu.

Abschließend noch ein kurzer Einblick in den Aufbau und die Komponenten einer JavaFX Oberfläche. Der gesamte Frame einer Anwendung in JavaFX ist vom Typ „Stage“. Diese ist einzigartig und definiert Aussehen und Eigenschaften des Frames. Weiterhin beinhaltet die „Stage“ genau eine „Scene“, welche sozusagen den Inhalt der Oberfläche bestimmt. Alle Elemente die in der GUI zu sehen sein sollen, müssen entweder direkt in dieser „Scene“ aufgeführt sein oder in einem anderen Element (Container), welches sich in der „Scene“ befindet.

Für jede Klasse, die einen Knotenpunkt darstellt, ist die Variable „content“ die Referenz auf alle Folgeknoten. Somit ist die „Stage“ quasi das Programmfenster und die Scene der Wurzelknoten zu einem Baum, der alle Elemente der GUI beinhaltet. Zur Verdeutlichung dient findet sich unten noch die folgende Grafik der Oracle-Website. Alle starren Elemente der GUI werden dabei dem „content“ der gleichnamigen Variablen hinzugefügt, welche direkt in der Scene auftaucht:

Aufbau JavaFX Frame ⁵

Dieser Artikel enthält eine kurze Übersicht zu Hardware-Lösungen für Outdoor-Touchscreen-Terminals sowie zu Komplettsystemen, die Soft- und Hardware vereinen. Diese einzelnen Arbeiten wurden im Rahmen der Recherche zur Arbeit Touchscreen-basiertes Campus-Navigationssystem für die Universität der Bundeswehr München untersucht und werden hier noch einmal zusammenfassend vorgestellt.

Ziel der Zusammenstellung

Im Rahmen der Anschaffung eines Outdoor-Touchscreen-Terminals an der UniBwM wurden zunächst mögliche Lösungen betrachtet, um Hersteller und Nutzungskonzepte zu identifizieren. Diese Sammlung wurde im Rahmen der oben verlinkten Bachelorarbeit um existierende proprietäre Komplettsysteme (Hardware + Software) erweitert, um für die Umsetzung eines Touchscreen-basierten Campus-Navigationssystems aus den Erfahrungen anderer Hersteller und Entwickler zu lernen.

Terminals ohne Software

Die unten aufgeführten Terminals werden von den jeweiligen Firmen normalerweise ohne Software als reine Hardware-Produkte ausgeliefert und sind mit dem an der UniBwM verwendeten friendlyway artic Terminal vergleichbar. Natürlich erhebt diese Liste keinen Anspruch auf Vollständigkeit, sondern bildet nur den damaligen Recherchestand ab.

Kolembar

Das erste Terminal ist von der Firma „Kolembar Industietechnik“ ¹, diese ist Spezialist rund um das Thema Monitore und Kiosksysteme. Sie ist im deutschsprachigen Raum ansässig, agiert aber auch international.  Das System heißt „Hawk“ und ist ein Outdoor Kiosksystem mit bis zu 32“ Displays, das vom Kunden anwedungsspezifisch bestellt werden kann. Die Firma „Kolembar“ arbeitet zurzeit an einem neuen Outdoor System mit bis zu 46“ das wir jedoch noch nicht vorstellen können.

Hier einige mögliche Konfigurationen des „Kolembar -Hawk“ :

Kolembar Hawk Terminal 17 ²

Kolembar Hawk Terminal 17 ²

Kolembar Hawk Terminal 32 ²

Kolembar Hawk Wandterminal 17 ²

Kolembar Hawk Wandterminal 17 ²

Kolembar Hawk Terminal 17 ²

SOLIDD

Das zweite Terminal ist von der Firma „SOLIDD“ ³, diese hat ihren Sitz in Kusel, Rheinland – Pfalz.  Neben einem weit gefächerten und vielseitigen Spektrum an Standard- Informationssystemen bietet die Firma auch auf Kundenwünsche maßgeschneiderte Sonderlösungen. Weitere Besonderheit ist, dass Sie höhenverstellbare Modelle anbieten, die auch von Kindern oder Personen im Rollstuhle verwendet werden können. Das betrachtete Modell K8 ist eine im Design schlicht gehaltene Infostele in drei Displaygrößen.

Hier einige Bilder des „SOLIDD K8“:

SOLIDD K8 22 ⁴

SOLIDD K8 42 Rückansicht / Geöffnet ⁴

SOLIDD K8 42 Rückansicht ⁴

SOLIDD K8 42 ⁴

friendlyway

Das nächste Terminal ist von der Firma „friendlyway“ ⁵, diese bietet ihren Service und ihre Produkte in Europa, im Mittleren Osten und in Nordamerika an.  Sie bieten digitale Kioske und Stelensysteme für den In- & Outdoorbereich. Der Artikel betrachtet das Modell „grande 46, es besitzt beidseitig ein 46“ Touchscreen Display.

friendlyway grande 46 ⁶

friendlyway grande 46

BV-com Office

Dieses Terminal ist von der Firma „BV-com Office“ ⁷, einer in Deutschland ansässigen Firma und ist erfolgreicher Xerox-Vertriebspartner. Die Firma bietet weiterhin verschiedenste Projektionsgeräte, wie Beamer, Bildschirme und andere Displays. Neben diesen Produkten bieten Sie für Kunden maßgeschneiderte Medien Konzepte.  Das „iMotion“ kann mit ein- oder beidseitigen Displays in Größen von bis zu 70“ bestellt werden. Zudem bietet „BV-com Office“ als einzige der hier vorgestellten Firmen bei einer solchen Displaygröße ein Querformat.

BV-com Office Touchscreen imotion 52 ⁸

BV-com Office Touchscreen imotion 70 ⁸

BV-com Office Touchscreen imotion 52 ⁸

BV-com Office Touchscreen imotion 52 ⁹

BV-com Office imotion Terminalübersicht ⁸

Terminals der Firma ide-tec

Fleximega Outdoor Wall ¹⁰

Fleximega Outdoor ¹¹

Flexioutdoor ¹²

Flexipanorama ¹¹

Terminals der Firma eKiosk

eKiosk - Dala ¹³

eKiosk - Varda ¹⁴

Komplettsysteme mit Software

Die hier aufgeführten Komplettsysteme dienten vor allem als Input für Ideen in der Umsetzung der oben verlinkten Bachelorarbeit.

Pariser Metroplan

Hierbei handelt es sich um eine sehr frühe Art von interaktivem Navigationssystem. Das Pariser U-Bahn Netz wurde durch LEDs auf einer Karte abgebildet. Der Nutzer kann duch das Drücken von Reisezielen im unteren Teil des Gerätes seine Auswahl treffen. Das Gerät zeigt anschließend mithilfe der LEDs die U-Bahn Linien von Standort zu Zielort an.

Parieser Metroplan ¹⁵

Einkaufszentrum Paris

Dieses Komplettsystem wurde für ein Parieser Einkaufszentrum entwickelt. Es verfügt über ein Touchscreen Displays (links unten) und zwei einfache Monitore (oben in der Mitte und rechts unten). Über das Touchsceen Display kann der Nutzer sein Ziel auswählen und zusätzliche Einstellungen vornehmen. Der Hauptmonitor (oben) zeigt ihm dann die Navigation zum Ziel. Der dritte Bildschirm unten rechts ist als Werbefläche konzipiert und zeigt Werbefilme unabhäng von der Nutzung.

Terminal Paris Einkaufszentrum ¹⁵

Interactive City Terminals

Dieses Komplettsystem wird vom Hersteller an an die individuellen Anforderungen von den Städten angepasst, in denen es später eingesetzt wird. Das Terminal der zweiten Generation verfügt über je ein 52″ Display auf Vorder- und Rückseite. Hierdurch kann das Terminal von zwei Nutzern gleichzeitig und unabhängig von einander genutzt werden. Bei der Software handelt es sich um ein Informations- und Navigationssystem, dass über Events in der Stadt sowie verschiedene öffentliche Einrichtungen Auskunft geben kann. Das System enthält Informationen über Hotels, Restaurants, Veranstaltungen und Ausflugsziele in der Umgebung und zeigt zu diesen Bilder und Videos.

Cityterminal v2 ¹⁶

Zusammenfassung

Abschließend ist zu sagen, dass Outdoor-Terminals für immer mehr Einsatzszenarien von konkreten Vertriebskonzepten bis hin zu rein unternehmensinterner Nutzung von Interesse zu sein scheinen.  Einsatzbereich und Umfang entscheiden oft über die verwendete Terminalart. Komplettsysteme werden häufiger für kleinere Unternehmen entwickelt, die nur wenig Anpassungen vom Hersteller wünschen. Reine Hardwaresysteme werden hingegen öfter von größern Unternehmen gekauft, die ihre eigene Software entwickeln oder diese von andern Firmen auf ihre spezifischen Wünschen anpassen lassen. Für das Terminal der UniBwM wurde im Rahmen einer Bachelorarbeit aufgrund der sehr spezifischen Anforderungen die zweite Variante gewählt. Weitere Informationen hierzu sind im Artikel Touchscreen-basiertes Campus-Navigationssystem für die Universität der Bundeswehr München beschrieben.

Ein Großteil der Entwicklungen im Bereich der Natural User Interfaces basiert auf (Multi-)Touch Interfaces und der Steuerung durch Touchgesten. Da diese Form der natürlichen Benutzerschnittstellen beispielsweise bei sehr großen vertikalen Displays oder an für den Benuter nicht erreichbaren Displays nicht verwendet werden kann, besteht die Notwendigkeit, alternative natürliche Interaktionsmechanismen einzusetzen, die eine berührungslose Interaktion mit vertikalen Displays aus einer gewissen Entfernung ermöglichen. Um einen Überblick über bereits existierende Prototypen solcher über die Touchinteraktion hinausgehenden (Beyond Touch) Interaktionsmechnismen zu geben, werden nun einige dieser Prototypen vorgestellt.

Aus der Vielzahl der Prototypen von natürlichen Interaktionsmechanismen lassen sich einige gehäuft auftretende, grundlegende Bedienkonzepte identifizieren. So werden vermehrt Ansätze gewählt, bei denen es beispielsweise möglich ist auch aus einiger Entfernung durch Touchgesten in unteschiedlichen Ausprägungen zu interagieren. Andere Prototypen basieren auf mouseähnlichen tragbaren Eingabegeräten, die eine Bedienung auf intuitive und natürliche Weise anstreben. Andere Interaktionsmechanismen beruhen auf der Gestensteuerung und verzichten auf zusätzliche Eingabegeräte auf Nutzerseite. Des Weiteren wird hier auch ein sogenanntes Brain-Computer Interface vorgestellt, das eine Anwendungsnutzung allein durch Gehirnstrommessung ermöglicht. Zunächst werden nun einige Mechanismen beschrieben, die durch die Körperbewegungen des Nutzers gesteuert werden. Nach diesen gestenbasierten Interaktionsmechanismen werden die Remote-Touch Interaktionsmechanismen, die gerätevermittelten Interaktionsmechanismen und das Brain-Computer Interface vorgestellt.

Gestenbasierte Interaktionsmechanismen

Die natürlichste Form der HCI ist die Bedienung einer Nutzerschnittstelle ohne die bewusste Nutzung eines Interaktionsmechanismus zur Erreichung der Zielsetzung. Dies bedingt einen vollständigen Verzicht auf Eingabegeräte auf Nutzerseite und die Interaktion zwischen System und Nutzer auf Basis der dem Nutzer zur Verfügung stehenden Kommunikationsmittel. Ebenso wie die Interaktion zwischen Menschen kann der Nutzer dem System seine Absichten über die Bemühung von Mimik, Gestik und Sprache mitteilen. ¹ Die Gesture Based Interfaces nutzen zur Interaktion zwischen Mensch und Computer nur die Gestik zur Eingabe auf Nutzerseite und visuelles oder akustisches Feedback durch den Computer.

Magic Window

Magic Window ² ist ein Interaktionsmechanismus, der es dem Nutzer erlaubt ohne die Zuhilfenahme von Eingabegeräten mit Bildmaterial zu interagieren. Dazu wird die Position des Kopfes des Nutzers verfolgt (Headtracking) indem die Position der an der Brille des Nutzers befestigten Infrarot-LED von der Infrarotkamera einer Wii-Remote erfasst wird. Da die Darstellung auf dem Display stets zum Nutzer ausgerichtet wird, entsteht für diesen ein der Effekt, dass er den dargestellten Inhalt wie durch ein Fenster betrachtet. Bewegt sich der Nutzer also nach links, kann er mehr von der rechten Seite des Bildes sehen. Bewegt er seinen Kopf nach unten, kann er mehr von der oberen Seite des Bildes sehen. Nähert er sich dem Display, kann er mehr vom gesamten Bild sehen usw. Diese Form der Interaktion ist sehr natürlich, da der Nutzer das Prinzip der Paralaxe, also der scheinbaren Änderung der Position eines Objektes, wenn der Beobachter seine eigene Position verschiebt, bereits aus der im Alltag gesammelten Erfahrung kennt. Um der Interaktion weitere Freiheitsgrade hinzuzufügen kann z.B. ein weiterer Wii-Remote Controller in die Interaktion eingebunden werden.

MagicWindow benötigte Hardware ³

Interaktion mit MagicWindow ³

SixthSense

SixthSense ⁴ ist ein Interaktionsmechanismus der in die Rubrik des Wearable Computing eingeordnet werden kann, da die Hardware wie Kleidung am Körper getragen wird. Diese Hardware besteht aus einem Projektor und einer Kamera, die vor der Brust getragen werden sowie farbigen Markern an Daumen und Zeigefinger beider Hände. Somit können Inhalte durch den Projektor auf jeder beliebigen Fläche dargestellt werden und durch Handgesten manipuliert werden, die von der Kamera aufgenommen werden. So kann der Nutzer beispielsweise jederzeit und nahezu überall seinen Kalender anzeigen lassen, um seine Termine zu verwalten, Skizzen oder Notizen machen, Kartenmaterial der Umgebung betrachten oder gestengesteuert Fotos machen.

Hardwarekomponenten von SixthSense ⁵

Gestensteuerung mit SixthSense ⁵

Imaginary Interface

Imaginary Interface ⁶ ist ebenfalls eine Wearable Computing Benutzerschnittstelle und nutzt eine Kamera zur Erfassung von Handgesten, verzichtete aber anders als SixthSense vollständig auf eine Darstellung von Inhalten und erlaubt daher eine sehr kompakte Bauweise, da kein Anzeigegerät erforderlich ist. Durch eine L-Geste mit der nichtdominanten Hand wird eine imaginäre Eingabefläche aufgespannt, auf der dann durch das Zusammenführen von Daumen und Zeigefinger gezeichnet oder geschrieben werden kann. So kann der Nutzer jederzeit  Dokumente zu in seinem aktuellen Umfeld relevanten Themen erstellen. Diese auf einfachen Gesten basierende Form der Interaktion ist leicht erlernbar, jedoch sind komplexe Zeichnungen wegen des fehlenden visuellen Feedbacks schwierig zu realisieren.

Imaginary Interface Hardware ⁷

Skizze mit Imaginary Interface ⁷

Multitoe

Mit Multi Toe ⁸ kann der Benutzer eine Anwendung mit den Füßen steuern. Dazu erfolgt die Interaktion auf einem touchsensitiven Untergrund, der sich wiederum über einem Display befindet. Bei dieser Form der Touchinteraktion treten einige Besonderheiten auf. So hat der Nutzer nahezu dauerhaften Kontakt zur Interaktionsoberfläche. Außerdem ist die Kontakfläche um einiges größer als bei der Touchinteraktion mit Fingern, sodass ein Interaktionspunkt an der Sohle des Benutzers identifiziert werden muss, um eine präzise Bedienung zu gewährleisten. Allerdings bietet Multi Toe auch einige Vorteile gegenüber einer herkömlichen Touchinteraktion mit Fingern. So kann der Nutzer anhand des individuellen Profils seiner Schuhsohle identifiziert werden. Außerdem kann eine Gewichtsverlagerung des Nutzers erkannt werden, wodurch eine differenzierte Touchinterakion mit zusätzlichen Freiheitsgraden erfolgen kann.

Setting für großlächige MultiToe-Interaktion ⁹

Interaktion mit MultiToe ⁹

Wii Gesture Interface

Wii Gesture Interface ¹⁰ ist ein Interaktionsmechanismus zur Steuerung vertikaler Displays durch natürliche Handgesten. Eine Platine mit einer Vielzahl von Infrarot-LED leuchtet dazu den Raum vor dem Display aus. Die reflektierte Infrarotstrahlung wird dann von der Infrarotkamera eines Wii-Remote Controllers  in ein Bild umgewandelt, dass es ermöglicht die Hand des Benutzers und ihre Bewegungen zu identifizieren. Somit können einfache Gesten, wie eine Bewegung der Hand von links nach rechts genutzt werden, um beispielsweise den nächsten Inhalt auszuwählen oder eine Berührungsgeste, um einen Inhalt auszuwählen. Um dann weitere Interaktionsmöglichkeiten zu schaffen und die Präzision der Interaktion zu steigern, kann zusätzlich noch ein weiterer Wii-Remote Controller eingebunden werden, dessen Tasten z.B. mit schwer durch Gesten darstellbaren Aktionen belegt werden können.

WiiMote Test Application

WiiMote in Aktion

Nintendo WiiMote ¹¹

Wii Remote in Nutzung ¹²

Wii-Logo

Wii-Mote Plus ¹³

Nintendo Wii Controller

WiiMote in der Medizin ¹⁴

Remote-Touch Interaktionsmechanismen

Diese Form der alternativen natürlichen Interaktionsmechanismen erfordert keine Präsenz des Nutzers an einem vertikalen oder horizontalen Touchscreen sondern verlagert die direkte Interaktion mit dem System auf das vom Benutzer verwendete Gerät. Zwar erfolgt die Interaktion mit dem verwendeten Interaktionsmechanismus wiederum durch intuitive Touchgesten, jedoch ist der Nutzer nun nicht mehr dazu gezwungen sich zur Interaktion in unmittelbarer Nähe des großen vertikalen Displays aufzuhalten. Auf diese Weise können mehr Nutzer und auch entfernt stehende Nutzer in die Interaktion einbezogen werden. Je nach visuellem Feedback des genutzten Interaktionsmechanismus kann auch eine uneingeschränkte Interaktion wie am großen vertikalen Touchscreen selbst erfolgen. Außerdem ist es mit Remote Touch Interfaces möglich auch Displays, die keine Touchscreen sind mittel touchbasierter Nutzerinteraktion zu steuern.

SecondLight

SecondLight ¹⁵ ist ein von Microsoft auf Basis der Technologie des MS Surface entwickelter Ansatz, der die gleichzeitige Projektion zweier unterschiedlicher Bilder auf die Oberfläche eines horizontalen Displays ermöglicht. Während das eine Bild wie gewohnt auf der Darstellungsfläche des Gerätes angezeigt wird, wird das zweite Bild durch diese Darstellungsfläche hindurch projiziert und kann durch weniger lichtdurchlässige Materialien sichtbar gemacht werden. Dies ermöglicht auch eine Projektion auf in einer geringen Entfernung über dem Gerät befindliche Oberflächen. Zusätzlich können auf diesen entfernten Oberflächen auch Touchinteraktion erfolgen.

SecondLight Hardware ¹⁶

Zweier Bilder gleichzeitig mit SecondLight ¹⁶

Touch Projector

Touch Projector ¹⁷ ist ein Interaktionsmechanismus, der es erlaubt Inhalte auf gewöhnlichen Displays mittels Touchgesten zu manipulieren. Zu diesem Zweck wird das Echtzeitbild der Kamera eines Smartphones genutzt. Die darauf sichtbaren Inhalte, die auf dem herkömmlichen Display dargestellt werden, können nun durch Touchgesten auf dem Display des Smartphones manipuliert werden. Anschließend wird die Veränderung auch auf die Darstellung auf dem herkömmlichen Display übertragen. Dabei werden alle Displays in der Umgebung und das Smartphone über eine Server synchronisiert, was auch das verschieben eines Inhalts von einem Display auf ein anderes ermöglicht. Durch diesen Mechanismus können auch für den Benutzer unzugängliche nicht touchfähige Displays via Touchgesten genutzt werden.

TouchProjector ¹⁸

Displayübergreifende Interaktion ¹⁸

Light Space

Auf den ertsen Blick unterscheidet sich Light Space ¹⁹ nicht wesentlich von andern natürlichen Benutzerschnittstellen. Es bietet sowohl eine horizontale als auch eine vertikale projizierte Darstellungsfläche, auf denen die gewohnten Touchgesten zur Manipulation von Bildinhalten ausgeführt werden können. Die Innovation liegt bei Light Space zwischen den Darstellungsflächen, denn ein dritter Projektor sowie drei  Kameras zur Entfernungsmessung erlauben eine Touchinteraktion auf gewöhnlichen Gegenständen aber auch eine Darstellungsübergreifende Interaktion mit den Inhalten. So kann ein Nutzer einen Inhalt auf der einen Darstelungsfläche berühren, danach die andere Darstellungsfläche berühren und so den Inhalt dorthin zu verschieben. Außerdem kann er einen Inhalt vom Rand der Darstellungsfläche auf seine Hand verschieben, wodurch der Inhalt im Sinne der Augmented Reality zu einem projizierten Ball wird, den der Nutzer auf seinem Arm umherrollen kann oder in die andere Hand bzw. auf einen Gegenstand legen kann. Berührt der Nutzer wiederum mit der Hand ohne Ball eine Darstellungsfläche, wird der durch den Ball repräsentierte Inhalt dorthin verschoben. Des Weiteren können durch die präzise Tiefenwahrnehmung der Anwendung Menüs im Raum platziert werden. Hält der Benutzer seine Hand über einen auf den Boden projizierten Menü Schriftzug, ändert sich die nun auf der Hand befindliche Darstellung je nach Höhe über dem Boden zu einem Menüpunkt, der dann durch das Entfernen der Hand ausgewählt werden kann.

Displayübergreifende Mehrbenutzerinteraktion ²⁰

LightSpace Hardwaresetting ²⁰

Gerätevermittelte Interaktionsmechanismen

Zur Interaktion mit den Device Mediated Interfaces benötigt der Nutzer ein zusätzliches Eingabegerät, das er bei der Interaktion bei sich trägt oder in der Hand hält. Entgegen der indirekten Manipulation mit einer gewöhnlichen Maus, die nur über Sensoren zur Erfassung einer Positionsveränderung in einer zweidimensionalen Ebene verfügt und diese auf den Zeiger überträgt, können die für Device Mediated Interfaces genutzten Interaktionsmechanismen ihre Position im Raum oder relative Lageveränderungen durch zusätzliche optische, gyroskopische oder Beschleunigungssensoren ermitteln. So kann der Nutzer direkt mit Inhalten interagieren, denn wenn er mit dem Gerät auf einen Inhalt zeigt, zeigt auch der Cursor auf dieses Ziel. So wird die natürliche Interaktion des Nutzers über die Sensorik der genutzten Interaktionsmechanismen an den Computer übertragen und dort in entsprechende Manipulationen umgesetzt. Der Interaktionsmechanismus übernimmt sozusagen eine Mediatorrolle zwischen dem Nutzer und dem genutzten System, da er die natürlichen Interaktionen des Nutzers in vom System interpretierbare Manipulationen umwandelt. Außerdem bieten die Zusatztasten des jeweiligen Interaktionsmechanismus die Option Shortcuts für bestimmte Funktionen zu nutzen. Auf diese Weise muss der Nutzer keine komplexen Muster von Manipulationen nachbilden, um das System zu Steuern. Zur weiteren Steigerung der Effizienz der Interaktion sind Device Mediated Interfaces ergonomisch gestaltet, sodass der Nutzer gewissermaßen mit dem Gerät verschmilzt und das Gerät die natürliche Interaktion des Nutzers nicht beeinträchtigt.

Soap

Soap ²¹ ist ein Interaktionsmechanismus, der die Steuerung eines Zeigers zur Nutzung einer Anwendung auf großen vertikalen Wanddisplays ermöglicht. In einer flexiblen Kunststoffhülle befindet sich der optische Sensor einer Mouse sowie eine Taste auf der Rückseite der Platine, die durch die Kunsstoffhülle hindurch betätigt werden kann. Die Kunststoffhülle ist wiederum mit einem dehnbaren Stoffüberzug bespannt. Auf diese Weise kann eine Verschiebung der Stoffhülle durch den optischen Sensor registriert werden und so die Bewegung des Cursors gesteuert werden. Eine schnelle Verschiebung des Cursors hingegen ist in vertikale Richtung durch dauerhaftes fixieren des Gerätes durch Zusammendrücken von Daumen und Zeigefinger oder in horizontale Richtung durch Drehen des Gerätes um die Längsachse ähnlich einem nassen Stück Seife in der Handfläche möglich. Aufgrund dieser Seifenmetapher trägt der Mechanismus auch seinen Namen.

Soap Hardware ²²

Soap zur Steuerung großer Wanddisplays ²²

Brain-Computer Interface

Das Brain-Computer Interface ²³ ist eine Form der Mensch-Computer Interaktion, die auf der Messung von Gehirnströmen basiert. Da dies über an der Kopfhaut platzierte Elektroden geschieht, ist dieser Interaktionsmechanismus im Gegensatz zu den bisher vorgestellten Mechanismen auch für Menschen mit eingeschränkter Bewegungsfähigkeit geeignet. Die Anwendung von McFarland und Wolpaw erlaubt z.B. eine Texteingabe ohne die Nutzung zusätzlicher Eingabegeräte. Auf einem Display wird dazu eine Matrix von Buchstaben angezeigt, von denen jeweils abwechselnde Gruppen aufleuchten. Der Nutzer muss während der Blinksequenz eine Buchstaben mit den Augen fixieren. Da jeder Buchstabe eine individuelle Blinksequenz hat und das Aufleuchten des fixierten Buchstaben mittels EEG gemessen werden kann, ist der vom Nutzer ausgewählte Buchstabe eindeutig bestimmbar. So wird eine Texteingabe allein durch das Anschauen der Buchstabenmatrix möglich. Allerdings ist durch die Dauer der Blinksequenz keine schnelle Eingabe möglich und die für diesen Interaktionsmechanismus benötigte Hardware ist im Vergleich zu den meisten zuvor beschriebenen Prototypen sehr teuer.

Brain-Computer Interface in Nutzung ²⁴

Brain-Computer Interface Hardware ²⁴

Fazit

Fallende Preise durch die kommerzielle Massenfertigung von Sensortechnik wie der Wii-Remote oder der Microsoft Kinect aber auch sinkende Preise bei großen vertikalen Displays oder Projektoren haben dazu beigetragen, dass die Zahl neu entwickelter Interaktionsmechanismen zur Gestaltung der Schnittstelle zwischen Mensch und Computer zunimmt. Da gerade im Bereich der NUI bisher nur wenig Forschungsarbeit im Bezug auf die Standardisierung solcher Nutzerschnittstellen und die Eignung eines Interaktionsmechanismus für die Nutzung in einem bestimmten Anwendungsumfeld oder für eine bestimmt Aufgabe erfolgt ist, müssen zukünftige Arbeiten weitere Erkenntnisse über die Leistungsfähigkeit und Nutzerakzeptanz natürlicher Interaktionsmechnismen liefern. Außerdem haben alle der in diesem Artikel vorgeschlagenen Kategorien von natürlichen Interaktionsmechnismen ihre Vor- und Nachteile, sodass eventuell eine Kombination der Merkmale existierender natürlicher Benutzerschnittstellen oder die Entwicklung neuer Ansätze zur Gestaltung dieser Schnittstellen einen Interaktionsmechnismus hervorbringen, der das Potential hat, eine ähnlich hohe Verbreitung und Nutzerakzeptanz zu erreichen, wie es heute bei Maus und Tastatur für die GUI der Fall ist.

Dieser Artikel beschreibt die wesentlichen Ergebnisse der Bachelorarbeit „Konzeption und Umsetzung eines Touchscreen-basierten Campus-Navigationssystems für die Universität der Bundeswehr München“ von Markus Schran. Ziel der Bachelorarbeit war die Konzeption und prototypische Umsetzung eines stationären Navigationssystems auf einem Outdoor-Kiosk-Terminal. Hierzu wurde zunächst zur Verfügung stehendes Kartenmaterial gesammelt und anwendungsspezifisch bewertet. Anschließend wurde der Besucherverkehr der Universität über mehrerer Tage protokolliert, bevor verschiedene Umsetzungsmöglichkeiten im Bezug auf Programmiersprache und Software Entwicklungstools gegeneinander abgewogen werden konnten. Das Ziel der praktischen Arbeit bestand darin, ein benutzerfreundliches und übersichtliches Programm für das touchscreen-basierte Terminal  zu programmieren. Neben den Grundfunktionen des Programms befasste sich die Arbeit vor allem mit späteren Weiterentwicklungsmöglichkeiten. Nach einer kurzen Einführung in die grundlegende Problematik werden in diesem Artikel die wichtigsten Schritte der Arbeit sowie die erzeugten Artefakte vorgestellt.

Problemstellung

Die Universität der Bundeswehr München ist darum bemüht, für ihre Besucher trotz ihres stetigen strukturellen Wandels eine hervorragende Infrastruktur zu bieten. Für externe Besucher ist die geografische Aufteilung der Universität zum Teil sehr unübersichtlich, da Fakultäten und Verwaltungsstellen auf unterschiedliche Gebäude aufgeteilt oder weit über das Gelände disloziert sind. Ähnlich verhält es sich mit Sportstätten auf dem Universitätsgelände, die von vielen Gästen genutzt werden. Aus diesem Grund wurde im Jahr 2010 an der Universität ein neues Schilder-Leitsystem errichtet, das es Universitätsangehörigen und Besuchern ermöglicht, sich einfacher auf dem Universitätsgelände zu orientieren. Aufgrund seines statischen Charakters schafft es jedoch auch dieses neue Leitsystem nicht, alle Anliegen potenzieller Besucher bestmöglich zu unterstützen. Das Leitsystem kann sich nicht optimal darauf einstellen, ob sich die Gäste mit dem Auto, zu Fuß oder vielleicht mit einem Fahrrad über das Gelände bewegen. Eine weitere Problemantik besteht darin, dass dieses Leitsystem dem Hauptanliegen der Besucher nicht entgegenkommen kann. Die meisten Besucher suchen eine bestimmte Person an der Universität, haben jedoch oft keine weiteren Informationen zum geografischen Aufenthalt der gesuchten Person. Da kein statisches Wegeleitsystem die Vielzahl der Personen an der Universität direkt abbilden kann, musste hierfür eine alternative Lösung gefunden werden.

Zielsetzung

Im Zuge der Installation des Leitsystems wurde auch das im Bild gezeigte Terminal „arctic 32“ der Firma Friendlyway an der Wache aufgestellt.

Terminal und Lageplan ¹

Aus den in der Problemstellung beschriebenen Gründen beschäftigte sich die nachfolgend beschriebene Bachelorarbeit damit, für dieses Terminal eine interaktive aktionsbasierte Ergänzung des statischen Stelenleitsystems zu entwickeln, das die Besucher je nach individuellen Präferenzen und Zielwünschen optimal bei ihrer Navigation auf dem Campus unterstützt.

Im Verlauf der Arbeit wurde ermittelt welche Funktionen eine mögliche Anwendung auf diesem Terminal bereitstellen muss und auf welchen Informationen diese Funktionen basieren. So wurde im ersten Schritt der Arbeit, durch Umfragen und Protokolle, erfasst, worin der Informationsbedarf unter den Besuchern liegt. Des Weiteren ist festgestellt worden wie sich der akademische und militärische Bereich der Universität nach außen präsentierten kann und welche Informationen Sie über diese Plattform teilen möchten. Im Zweiten Schritt muss festgestellt werden, woher das System diese Informationen bezieht und welche Art gewählt wird, diese später dem Nutzer zu präsentieren. Nachdem dann eine angemessene Möglichkeit gefunden wurde, diese geplante Benutzeroberfläche zu erzeugen, galt es im vorletzten Schritt diese zu implementieren und auf dem Terminal in Betrieb zu nehmen. Das zu entwickelnde Programm muss später durch Dritte einfach zu warten und erweiterbar sein, um somit auch der Verwaltung zu ermöglichen Veränderungen vorzunehmen. Im letzten Schritt gibt die Arbeit einen Ausblick auf mögliche Erweiterungen und Zusatzfunktionen, die später einmal in die Software mit aufgenommen werden könnten.

Vorgehen bei der Umsetzung

Das folgende Kapitel beschriebt die einzellnen Schritte der Bachelorarbeit. Hierzu fasst jeder Absatz einen Schritte zur Umsetzung zusammen.

Vorstudie – Analyse Besucherverkehr

Um eine Software zu erstellen, die konkret auf die Anliegen der Besucher der Universität eingeht, wurde das Besucherverhalten erst genauer erforscht. Dazu wurden der Besucherverkehr an einem Dienstag und einem Mittwoch von 7:00 bis 20:00 Uhr protokolliert. Dabei wurde genauestens notiert, aus welchem Grund die Besucher das Gelände aussuchen und welches Ziel sie haben. Da alle Besucher das Gelände über das Westtor betreten müssen, um sich dort bei der militärischen Wache auszuweisen, war es einfach, den gesamten Besucherstrom zu erfassen.  Dabei war es sogar möglich, die wichtigsten Informationen zu erfassen, ohne dabei die Besucher aufzuhalten. ² Aus Gründen der Geheimhaltung und des Datenschutzes ist hier nur das Diagramm über die zeitliche Verteilung der Gäste abgebildet.

Zeitliche Verteilung der Besucher ¹

Kartenmaterial

Im nachsten Schritt wurden die Anforderungen an das Kartenmaterial spezifiziert. Die daraufhin gesammelten Karten der Universität wurden anhand dieser Anforderungen bewertet um eine geeignete Karte für die Software zu finden. Alle untersuchten Karten werden an dieser Stelle kurz mit ihren Merkmalen beschrieben. ³

3D- Karte eines FH- Studenten

3D Lageplan ⁴

Die gezeigte Karte ist von einem externen Fachhochschulstudenten vor fast 40 Jahren erstellt worden. Diese zeigt die Universität der Bundeswehr in einer Art Vogelperspektive aus nord-östlicher Sicht des Geländes. Sie zeigt auserdem alle Gebäude des damaligen Geländes in drei Dimensionen, sowie die vorhanden Sportstätten, den Parkplatz an der östlichen Seite, sowie die Grünflächen. Die Vorteile dieser Karte liegen ganz klar in der drei dimensionalen Darstellung der Gebäude. Diese hilft den Besuchern bei der Orientierung auf dem Gelände, weil es ihnen einfacher fällt ein Gebäude anhand des Aussehens zu identifizieren. Die Karte enthält neben den Formen der Gebäude auch noch Informationen über weitere Merkmale, wie z. B. die Farbe oder die Fassade.

3D-Modelierung in Google Earth

Google Earth UniBwM ⁵

Im Rahmen einer Bachelorarbeit entstand Anfang 2010, dieses 3D-Modell der Universität. Dieses ist für die Plattform von Google Earth ausgelegt worden und alle zugänglichen Daten sind im programmeigenen Format. Die Idee hierbei war es, die Modelle zu exportieren, in einer anderen Umgebung nachzubauen und sie dann für die Navigationssoftware zu nutzen. Die Vorteile die Darstellung wären wieder in der drei-dimensionalen Darstellung. Zudem könnte man flexibel agieren und z.B. Probleme wie verdeckte Informationen umgehen, würde man diese Modelle selbst exportieren und auf eigener Entwicklungsumgebung wiederverwenden.

2D-Karte des Stelen Leitsystems

2D Lageplan(alt) ⁶

Diese Karte wurde im Rahmen der Beschaffung eines Leitsystems für die UniBwM erstellt. Sie zeigt alle Gebäude des Universitätsgeländes in zwei Dimensionen sowie alle Straßen und weitere wichtige Objekte. So sind neben Parkplätzen auch Straßennamen auch einige Sportstätten verzeichnet. Der wesentliche Vorteil, der zur endgültigen Verwendung der Karte in der Navigationssoftware führte, ist die Darstellung in Form einer Vektorgrafik. Diese ermöglicht entscheidende Implementierungsvorteile mit der verwendeten Programmiersprache JavaFX ⁷, auf die an späterer Stelle eingegangen wird. Denn durch den Zugriff auf die Vektordaten ist es möglich, Gebäude und Straßen separat zu verändern. Dies ermöglicht es im Programm, das Zielgebäude farblich hervorzuheben oder die Route zum Ziel direkt zu markieren. Weiterhin können einzelne Objekte ein- oder ausgeblendet, verschoben oder in Größe und Form verändert werden. Durch das Vorliegen der Quelldaten ist auch gewährleistet, dass die Karte bei weiteren Veränderungen an der Universität aktualisiert wird. ⁸

Realisierungsmöglichkeit – JavaFX und Production Suite

Zur Umsetzung des Navigationssystems bieten sich verschiedene Programmiersprachen und Erweiterungen an. In der Arbeit wurde zwischen der Realisierung durch Java mithilfe von Baltik SVG Tool oder JavaFX mit Produktion Suite abgewogen.  An dieser Stelle wird nun die zur Realisierung verwendete Möglichkeit über JavaFX aufgezeigt.

JavaFX ist ein recht neues Framework für plattformübergreifende Internetapplikationen. Es basiert auf JavaScript und kann auf Funktionen und Schnittstellen der Java-Klassenbibliothek zurückgreifen. Somit verbindet JavaFX die objektorientierten Vorteile der Programmiersprache Java und die einer webbasierten Applikationssprache wie JavaScript. Zusätzlich schafft JavaFX mit der Production Suite eine Verbindung zwischen Designer und Entwickler. Es stellt Plugins für Adobe Illustrator und Adobe Photoshop zur Verfügung. FXZ-Grafiken können zur Laufzeit mit JavaFX sehr einfach verändert werden. Einzelne Bestandteile können zum Beispiel über eine im SVG-Programm oder in Illustrator zugewiesene ID angesprochen werden und es lassen sich damit sehr einfach Eigenschaften, wie Transparenz, Position, Größe oder Form des Objekts ändern. Die Funktionsweise von JavaFX und Produktion Suite wird im Artikel „Howto zum Export von JavaFX Dateien durch Production Suite“ beschrieben.

Programm Design

Bei der Gestaltung des Programm Designs wurden sehr viele Entwürfe angefertigt die immer wieder die Benutzeroberfläche verfeinert haben, um sie möglichst intuitiv und einfach zu gestalten. Dabei war es wichtig den vorhandenen Platz optimal auszunutzen, und trotzdem keine Informationen zu überdenken oder Bedienelemente an ungünstigen Stellen anzuordnen. Hierbei muss berücksichtigt werden, dass es sich um ein vertikales Display mit kapazitiver Thoughglass Touchscreen Technologie handelt. Dies schränkt zum Einen den effektiv zu nutzenden Bereich ein, in dem Touchscreen-Eingaben getätigt werden können. Zum Anderen müssen die Eingabeelemente eine gewisse Größe besitzen, da die Technologie eine gewisse Ungenauigkeit besitzt. Durch einige Experimente an Modeloberflächen, wurden die Fläche des Displays in gewisse Bereiche eingeteilt, sowie Mindestgrößen für Schrift und Eingabeelemente festgelegt. Diese sind in der folgenden Abbildung  eingezeichnet. ⁹

Bereiche im Display ¹

• Die Rote Fläche zeigt den Bereich in dem eine Touchscreen Eingabe schwer umzusetzen ist und somit nur zur Anzeige genutzt wird.
• Die Blaue Fläche zeigt den zu nutzende Bereich des  Touchscreen Displays.
• Die Grüne Fläche markiert den Bereich in dem der Focus des Nutzers liegt. Alle Hauptfunktionalitäten sowie Programminteraktionen werden in diesem Bereich ausgeführt.
• Die Gelben Objekte zeigen die Größen umzusetzender Bedienelemente, sie besitzen eine Kantenlänge von 50/60/75 Pixel
• Der Text zeigt die zu verwendende Größe einer Überschrift und eines normalen Textes (Arial, Schriftgröße 24/12)

Unter Berücksichtigung dieser Bereiche ergaben sich nach wiederholter Analyse und Überarbeitung das untern abgebildete Model der Benutzeroberfläche. Darin sind im Focus die Suchfunktionen wiederzufinden, sowie die Buttons zum Zoomen und Zurücksetzen der Karte. Im unteren Display-Bereich sind die weitern Funktionen angeordnet, um Informationen ein und auszublenden. Es wurde hier in der Abbildung auf eine zusätzliche Beschriftung verzichtet, da die Button-Titel sehr aussagekräftig sind und dies die Darstellung nicht zu verfälschen. ¹⁰

Fussgängernavigation MockUp V2 ¹

Fussgängernavigation MockUp V3 ¹

Fussgängernavigation MockUp V5 ¹

Fussgängernavigation MockUp V7 ¹

Fussgängernavigation Startscreen ¹

Anpassung der Vektordaten

Die gelieferten Daten Vektordaten mussten im ersten Schritt der Realisierung nun soweit angepasst werden, dass diese mit Hilfe der JavaFX Produktion Suite in das FXZ- Format umgewandelt werden konnten. Da ein Designer die Elemente einer Vektordatei oftmals nur auf das Nötigste gruppiert und in Ebenen separiert, war an dieser Stelle viel Aufwand notwendig. Die erhaltene Adobe Illustrator Datei enthielt jeweils eine Ebene für die Symbole der Karte, die Gebäude, deren Schatten, die Straßen und die Grundfläche im Hintergrund. In diesen Ebenen waren die einzelnen Elemente jedoch nicht weiter sortiert oder beschriftet worden. Ohne eine solche Beschriftung und Gruppierung wäre es nicht möglich, später im Programm, die Objekte anzusprechen und zu verändern. Somit bestand die erste Aufgabe darin, diese Ebenen und Gruppen, neu zu strukturieren.

In der Ebene der Gebäude musste die meiste Arbeit geleistet werden. Hier wurden zuerst alle Pfade die zu einem Gebäude gehören gruppiert. Die Beschriftung der einzelnen Bauteile der Gebäude wurde auch mit aufgenommen, da es bisher sehr wenige Karten des Geländes gibt die auch diese mit abbilden. Nachdem alle diese neuen Informationen in die Karte mit eingezeichnet wurden, mussten dies auch entsprechend benannt und gruppiert werden. Nach dieser erneuten Gruppierung umfasst jedes Gebäude drei Untergruppen. Den Aufbau dieser Gruppe und der Untergruppen Label, Shape und Shadow zeigt die folgende Abbildung.

AI Ebenen ¹

2D Lageplan(neu) ¹

Zusammenfassung und Ausblick

Die Arbeit begann im Oktober 2010 mit der Aussicht auf eine lauffähige Navigationssoftware für das Gelände der Bundeswehruniversität. Dabei haben die Recherchen und Analysen der Problemstellung ergeben, dass diese Software, neben einer einfachen Grundfunktion, eine Vielzahl von nützlichen Zusatzfunktionen beinhalten könnte. Jede dieser Funktionen wäre dabei eine große Bereicherung, sowohl im Bereich der Benutzerfreundlichkeit, wie auch im Hinblick auf die Wartung. Sie könnten helfen die Universität der Bundeswehr positiv nach außen zu präsentieren. Zunächst blieb der Fokus jedoch auf einer gut konzeptionierten Analyse der genauen Anforderungen an die Software. Um möglichst viele Erkenntnisse zur Problematik zu sammeln wurden unterschiedlichste Forschungsbereiche beleuchtet.

Die Auswertungen bezüglich des Kartenmaterials waren äußerst ernüchternd, da sie im Grunde keine Auswahlmöglichkeit lassen. Die Wahl des Realisierungsverfahrens hingegen blieb unterer den vorgestellten Möglichkeiten ausgeglichen. Auch wenn sich die Umstellung auf JavaFX schwerer als zunächst angenommen erwies, bleib es die richtige Entscheidung und wird sich auch an späterer Stelle weiter auszahlen. Dies hatte sich bei der Anpassung der Vektordaten von gezeigt. Dieser vorher nicht bedachte Arbeitsabschnitt hat bei weitem am meisten Zeit in Anspruch genommen. Die Entscheidung, sich an dieser Stelle intensiver mit der Umstrukturierung und Aufbereitung der Vektordaten zu befassen und vorerst von einer vollständigen Realisierung des Programmes abzusehen, war vollkommen richtig. Die eigentlichen Vorteile, die zur Auswahl von JavaFX und einer vektorbasierten Karte geführt haben, werden dabei eigentlich erst an späterer Stelle deutlich. Denn zurzeit beschränken sich die Funktionen des Programms sowie ein Zusammenspiel der angesprochenen Komponenten noch auf ein Minimum, doch nun gilt es dies umgehend zu einer Version zu erweitern, die auf dem Terminal in Betrieb genommen werden kann.

Im Rahmen eines Projektes der Vorlesung „CSCW – Rechnergestützte Gruppenarbeit“ entsteht aktuell in der datArena auf dem Gelände der Universität der Bundeswehr München ein Testaufbau unseres CommunityMirror-Konzeptes. Die datArena ist ein aktiv betriebenes historisches Rechenzentrum mit Computern aus allen Generationen seit den 1950er Jahren und stellt ein neuartiges Lehr-, Forschungs- und Ausstellungszentrum bereit, das zwischen Technik-, Kultur- und Sozialgeschichte vermittelt und zugleich ein Forum für Begegnung bietet. ¹ In diesem Setting steht eine Fläche von ca. 20 Quadratmetern zur Verfügung, um die verschiedenen Hardware-Komponenten von CommunityMirrors in einem konsistenten Laborumfeld aufzubauen, damit ihr Zusammenwirken in der Praxis überprüfen werden kann.

Labor datArena am 09.07.2011

datArena Innenansicht

Blick auf CSCW-Bereich

datArena Außenansicht

Dieser Artikel beschreibt die bisherigen Vorgänge bis zum aktuellen Stand, wobei die Installation noch nicht abgeschlossen ist. Daher wird in der nächsten Zeit abhängig vom Fortschritt des Projektes ein weiterer Artikel erscheinen.

Aufbau

Kernaufgabe war es, die Hardware zu positionieren und aufzubauen. Der Laborbereich liegt in einer Ecke der datArena und ist somit von zwei Wänden begrenzt und von den anderen beiden Seiten zugänglich. Da der Bereich möglichst offen wirken soll und die Wege aufgrund der Fluchtwegsbestimmungen ohnehin frei bleiben müssen, konnten nur wenige Komponenten an den offenen Seiten platziert werden. Das zentrale Element ist der große Wandbildschirm, der natürlich an einer Wand befestigt wird, wodurch sich auch die restlichen Elemente eher an den Wänden orientieren. Des Weiteren sind die Standorte der RFID-Antennen für die Benutzeridentifikation relativ genau vorgegeben, da sie ganz bestimmte Bereiche erfassen sollen.

Komponenten des Labors datArena

Die grundlegende Platzierung der Geräte ist inzwischen abgeschlossen: Der Wandbildschirm als zentrales Element ist in Augenhöhe mittig an der längeren Wand befestigt. Die RFID-Antennen sind seitlich davon in den Raum ragend positioniert, während die Fingerprintsensoren am Monitor befestigt werden. Eingerahmt wird der Bereich von zwei Arbeitsplätzen mit Workstations (PC & Mac). Das Terminal steht mit dem Display zur Wand am PC-Arbeitsplatz, um dort eine private Zone zu erzeugen und gleichzeitig die Geschehnisse am großen Monitor verfolgen zu können. Die Trolley-PCs sind frei beweglich. Am PC-Arbeitsplatz ist in erhöhter Position eine Webcam angebracht, die einen möglichst großen Bereich erfasst, damit sich Aufnahmen und Videos zur Protokollierung von Vorgängen im Interaktionsbereich erstellen lassen. Um zusätzliche „Lounge“-Atmosphäre zu schaffen, ist mittig im Bereich eine Sitzgruppe mit mehreren Sesseln eingerichtet.

Überblick des ersten Testaufbaus

Grobaufbau

Grobaufbau Seitenansicht

Grobaufbau Gesamtansicht

Installation/Konfiguration

Neben diversen Aktualisierungen, die an den PCs und am Setting vollzogen werden mussten (Updates einspielen, CommunityMirrors-Framework aktualisieren, Kabel verlegen, etc.), bestand die Hauptarbeit in der Konfiguration und Integration der verschiedenen CommunityMirror-Komponenten, die im Folgenden kurz in ihrem Gesamtzusammenhang beschrieben werden.

RFID

Die Standorte der Antennen standen, wie oben bereits beschrieben, bereits fest. Daher mussten diese nur entsprechend aufgestellt und an die Lesegeräte angeschlossen werden. Dazu wurden je 2 Antennen an den Mid-Range und den Long-Range Reader angeschlossen. Ersterer dient zur Erfassung von Personen in der aktiven Zone, also derjenigen Personen, die direkt mit dem Wandbildschirm interagieren. Letzterer erfasst Personen, die sich dahinter befinden und das Geschehen passiv beobachten bzw. nur mit den Personen in der aktiven Zone interagieren, nicht aber mit dem Gerät selbst. Da die Lesegeräte beide an den Host-Rechner am Wandbildschirm angeschlossen werden mussten, sind diese in unmittelbarer Nähe davon positioniert.

Die Konfiguration der beiden Lesegeräte musste unabhängig erfolgen, da das eine per USB angeschlossen wird (Mid-Range Reader) und das andere per Ethernet (Long-Range Reader). Mit den RFID-Lesegeräten ist es, anders als es die Namensbezeichnung „Reader“ vermuten lässt, auch möglich, die zugehörigen RFID-Chipkarten mit einer selbst gewählten ID zu beschreiben. Dazu ist eine andere Konfiguration der Geräte nötig, als wenn die gelesenen RFID-Daten zum Host-Rechner übertragen werden. Die Umschaltung zwischen Konfigurationen geht mithilfe des mitgelieferten OBID ISOStart relativ schnell. Das CommunityMirrors-Framework besitzt bereits eine Schnittstelle zur Verwendung der RFID-Daten, sodass die Anzeige des Wandbildschirms in der datArena nun auf erkannte Personen reagieren kann.

Auch im Stand-Terminal ist ein RFID-Lesegerät, sowie eine entsprechende Antenne integriert. Es handelt sich um denselben Mid Range-Reader, der auch am Wandbildschirm Verwendung findet, sodass die Einrichtung hier analog verläuft.

Rückseite der RFID-Antenne

CMF mit RFID-Sicht 1

CMF mit RFID-Sicht 2

Logo der FEIG ELECTRONIC GmbH

ID ISOStart

Oberfläche des ISOStart-Konfigurationstools

OBID Long Range RFID-Reader 1

OBID Long Range RFID-Reader 2

OBID Mid Range RFID-Reader 1

OBID Mid Range RFID-Reader 2

RFID-Zonenkonzept

RFID-Antenne Kopf

RFID-Antenne Gesamansicht

Terminal Frontansicht

Terminal Schrägansicht

Terminal Schrägansicht Detail

Fingerabdruckscanner

Vor allem am zentralen Wandbildschirm kommen Fingerabdruckscanner zur Anwendung, um sich am Gerät anzumelden und sich so zum Beispiel benutzerspezifische bzw. personalisierte Informationen anzeigen zu lassen. Weiterhin können Informationen hierdurch in einer Art Warenkorb gesammelt und per E-Mail verschickt werden, um sie beispielsweise am Arbeitsplatz oder zu Hause ebenfalls zur Verfügung zu haben.

Im CommunityMirrors-Framework sind bereits mehrere Ansätze zur Integration der Geräte vorhanden. Auch am Stand-Terminal wird in Kürze ein Fingerabdruckscanner angebracht werden, um personalisierte Informationsmitnahme zwischen dem halböffentlichen Interaktionsbereich und der privaten Interaktionszone am Terminal zuzulassen.

Fingerabdruckscanner

Näherungssensoren

An einigen Geräten sind Näherungssensoren zur Erfassung einer Person im näheren Umfeld integriert, um zum Beispiel Bildschirmschoner oder ähnliches zu unterbrechen und interessantere Informationen anzeigen zu können. Hier findet jeweils dasselbe Modell Verwendung.

An Trolleys und Stand-Terminal sind die Näherungssensoren bereits integriert und installiert, sodass im Falle des Terminals dieser nur noch richtig befestigt werden musste. Der Näherungssensor vom Wandbildschirm dagegen konnte noch nicht angebracht werden, da zum einen die Frage der Stromversorgung noch offen ist, zum anderen wird der Sensor normalerweise an einen COM-Port angeschlossen, der Rechner im Wandbildschirm aber über keinen verfügt, sodass ein COM-Port/USB-Adapter notwendig ist.

Testen eines Näherungssensors

Echo-Finder HB1033-M

Echo-Finder HB1033-M

Mobile 19 - Näherungssensor

Terminal Frontansicht

Terminal Schrägansicht

Terminal Schrägansicht Detail

Netzwerkkonfiguration

Die im Setting integrierten Rechner verfügen alle über einen Internet-Zugang, der über das Rechenzentrum-eigene WLAN, welches vor Kurzem in der Halle installiert wurde, bereitgestellt wird. Hierüber werden insbesondere die mobilen Trolleys angeschlossen. Daneben existiert eine ebenfalls vom Rechenzentrum verlegte Kabelverbindung.

Um die angebundenen Komponenten (RFID-Lesegerät, Fingerabdrucklesegeräte) vom Uni-Netz zu trennen und sie in einem Subnetz gliedern zu können, wurde im Rechner des Wandbildschirms eine zweite Ethernetschnittstelle integriert.

Weitere Komponenten

Neben den oben beschriebenen, bereits seit Längerem für CommunityMirrors eingesetzten Systembestandteilen, sind vor Kurzem weitere Komponenten hingekommen, die noch installiert und konfiguriert werden müssen. Dazu zählt zunächst eine Microsoft Kinect, eigentlich eine Erweiterung der Spielekonsole Xbox 360, über die sich aber auch der Rechner per Gestensteuerung bedienen lässt. Dazu existieren Open Source Treiber, die dies unter anderem auch für Windows XP ermöglicht. Microsoft selbst hat vor kurzem ein Kinect-SDK für Windows als Beta-Version veröffentlicht, sodass die Möglichkeit besteht, das Gerät noch weitergehend in das Framework zu integrieren.

Auch mit dem sogenannten Headtracker TrackIR 5 Pro lässt sich der Rechner auf andere Weise steuern. Dabei wird eine Tracking-Komponente auf einer Schirmmütze auf dem Kopf eines Nutzers befestigt, ein Sensor ermittelt so die Kopfbewegungen und gibt diese an den Hostrechner weiter.

Zuletzt sind die Wii-Controller zu nennen, die eigentlich Zubehör der Nintendo Wii sind, mit passenden Treibern aber auch eine Maus ersetzen können. Die Steuerung schien in einem ersten Test allerdings nicht sehr präzise, sodass für diese Art der Steuerung eine gewisse Menge an Fingerspitzengefühl notwendig ist.

Headtracker

Microsoft Kinect

Nintendo Wii Controller

Mehrwert des Labors

Mit dem Aufbau des Labors wurde das CommunityMirrors-Konzept, welches bisher eher in theoretischer Form existierte, in die Tat umgesetzt. Im Folgenden können nun Forschungsarbeiten in dieser Richtung direkt am Objekt in der Praxis umgesetzt oder getestet werden. So kann das Labor bei wissenschaftliche Arbeiten, wie zum Beispiel Bachelor- oder Masterarbeiten, eine wertvolle Hilfe beim Testen von Komponenten oder Implementierungen in einem bestehenden Setting sein. Neue potentielle Komponenten lassen sich direkt testen, wie es bei der Microsoft Kinect und weiteren Komponenten bereits geschieht. Außerdem können theoretische Konzepte in der Praxis untersucht und verifiziert werden.

Ausblick

Der Testaufbau ist noch nicht abgeschlossen. Neben den neuen Komponenten, die noch integriert werden müssen, sind auch noch nicht alle ursprünglichen Arbeiten erledigt. So fehlen beispielsweise noch Kabelschächte und ein weiterer Arbeitsplatz. Weitere Informationen dazu folgen in einem späteren Bericht.

Gesamtübersicht