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);
	}
}}

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"));
  }
}

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.

Durch die immer größer werdende Anzahl an verschiedenen Multitouch-Tablet-Modellen, sowie deren Vielzahl an Einsatzmöglichkeiten in den unterschiedlichsten Szenarien, ist die Auswahl eines geeigneten Gerätes für einen konkreten Einsatzzweck in der heutigen Zeit schwierig und aufwendig. Die hier dargestellte Bachelorarbeit „Konzeption eines Analyserasters für die szenario-spezifische Eignungsfeststellung von Multitouch-Tablets“ beschäftigt sich daher mit Szenario- und Geräte-Variablen, sowie deren Bedeutung und Einfluss auf die Eignungsfeststellung von Multitouch-Tablets. Dazu wird ein Analyseraster für einen einfach durchzuführenden und nachvollziehbaren Bewertungsprozess geschaffen, in dem verschiedene Geräte-Alternativen nach gewählten szenario-spezifischen Kriterien untersucht werden, um schließlich in einer Rangordnung platziert werden zu können.

Problemstellung & Zielsetzung

Das Bedienkonzept und die in der Regel hohe Anpassungsfähigkeit scheinen Multitouch-Tablets zunächst für eine große Bandbreite an neuen Einsatzgebieten zu qualifizieren ¹. Doch je nach Einsatzzweck unterscheiden sich die Ansprüche, die an das zu verwendende Gerät gestellt werden. Ziel des europäischen Forschungsprojektes SI-Screen (Social Interaction Screen) ² ist es, vor allem Senioren die Interaktion mit anderen Menschen zu ermöglichen (beispielsweise über Facebook u. a.). Denkbar ist  dafür beispielsweise der Einsatz eines Multitouch-Tablets. In der hier dargestellten Bachelorarbeit wird dieses konkrete Szenario daher herangezogen und das geschaffene Analyseraster darauf angewendet, um seine Praxistauglichkeit zu erproben.

Die heutigen Modelle unterscheiden sich teilweise sehr stark in ihren Merkmalen und Eigenschaften, sodass eine sorgfältige Auswahl besonders wichtig ist. Insbesondere in Szenarien, in denen konträre Aspekte gegeneinander abgewogen werden müssen, ist dem Auswahlprozess ein hoher Stellenwert zuzusprechen. Dieser Prozess gestaltet sich derzeit noch schwierig, da man auf keine oder kaum Erfahrungen zurückgreifen kann, welches Tablet für einen definierten Einsatz geeignet ist und es an geeigneten Bewertungsschemata fehlt, die den Entscheidungsträger in einer Auswahlsituation unterstützten könnte.

Rocketfish iCapsule ³

Alphyn Industry PADX-1 Ledge ⁴

TouchType SwiftKey ⁵

Artikelbild ⁶

Alupen iPad Stylus ⁷

Clamcase iPad Tastatur ⁸

Felix Schmidbergers Compenion Konzept ⁹

Tablets vs. eReaders vs. Smartphones ¹⁰

Asus EeePad Transformer TF101 ¹¹

elisa User Interface ¹²

elisa Tablet-Computer ¹²

elisa Standfuß ¹²

elisa Tragetasche ¹²

iPad Gesture Control ¹³

Evigroup Paddle Pro ¹⁴

eyeSight Gestenerkennung ¹⁵

iPad Joystick ¹⁶

HTC Flyer ¹⁷

Touchpad PC Shows A Cooking Website

Businessman with digital tablet PC

123►

In der dargestellten Arbeit wird nun ein Analyseraster geschaffen, mit dessen Hilfe es möglich sein soll, geeignete Multitouch-Tablets für ein konkretes Szenario zu identifizieren. Die Eigenschaften eines Gerätes sollen dabei anhand einer szenario-spezifischen Bewertungsgrundlage bewertet werden, um so schließlich eine nachvollziehbare und begründete Empfehlung für ein oder gegebenenfalls mehrere Geräte aussprechen zu können.

Konzeption eines generischen Analyserasters

In diesem Abschnitt werden die Gesichtspunkte angerissen, die zur Konzeption des Analyserasters notwendig sind. Dazu werden die Fragen einer allgemeinen Bewertungssituation aufgegriffen und besprochen.

Aspekte einer Bewertungssituation

In einer allgemeinen Bewertungssituation stellen sich die Fragen nach dem Bewertungsziel, dem Bewertungsobjekt, dem Bewertungszeitpunkt, dem Bewertungsverfahren, dem Bewertungsträger und dem Bewertungsmaßstab ¹⁸. Um das Analyseraster so simpel wie möglich zu halten, sollen diese Fragen, so weit möglich, bereits beantwortet werden. Der Durchführende hat die Aufgabe die Spezifikationen des konkreten Szenarios in das generische Analyseraster einzuarbeiten.

Aspekte einer Bewertungssituation

Das allumfassende Bewertungsziel wird im Analyseraster in der Szenario-Beschreibung aufgegriffen und muss hier individuell beantwortet werden. Die Frage nach dem Zeitpunkt der Durchführung des Analyserasters, sowie die nach dem Bewertungsträger stellen sich an dieser Stelle nicht. Dies sind dem Analyseraster vorgelagerte Fragen, die bereits beantwortet worden sind, wenn mit der Durchführung des Analyserasters begonnen wird. Das Bewertungsobjekt wird hier grob auf die Klasse der Multitouch-Tablets eingegrenzt. Welche Modelle konkret bewertet werden, muss jeweils beim Anwenden des Analyserasters festgelegt werden. Die komplexeren Fragen nach dem Bewertungsverfahren und dem Bewertungsmaßstab werden durch die Vorgabe eines (groben) Schemas beantwortet.

Die Nutzwertanalyse als Basis für das Analyseraster

Als Basis des Analyserasters dient ein Verfahren der Entscheidungstheorie, die sogenannte Nutzwertanalyse. Sie ist ein multikriterielles Verfahren ¹⁹, sodass gleichzeitig mehrere unterschiedliche Aspekte berücksichtigt und bewertet werden können, was bei Szenarien, die in der Regel verschiedenartige Bewertungskriterien vorgeben, unumgänglich ist. Zudem hat sie sich früh als praxistauglich erwiesen ²⁰ und kann strukturiert und nachvollziehbar durchgeführt werden. Dabei wird ein hierarchisches Zielsystem erstellt, in dem sich in der untersten Ebene die Bewertungskriterien eingliedern. Eine Zielertragsmatrix gibt an, welche konkreten Ausprägungen das jeweilige Kriterium für jede Alternative hat. In der Zielerfüllungsmatrix wird auf einer Skala angegeben, inwieweit die Ausprägung einer Eigenschaft für das Ziel von Nutzen ist. Zusammen mit einer Gewichtung jedes Kriteriums können dann die Nutzwerte berechnet werden, welche den Nutzen jeder Alternative hinsichtlich des Zielsystems angeben. Die Nutzwertanalyse darf dabei allerdings nicht als feststehendes Ablaufschema verstanden werden, da es eine allgemeingültige Schrittabfolge, die für jede Situation passt, nicht geben kann ¹⁹. Aufgrund dieser Eigenschaft kann sie im Folgenden im Sinne der Zielsetzung der dargestellten Arbeit angepasst werden.

Phasen der Nutzwertanalyse

Von der Nutzwertanalyse zum Analyseraster

Aufbauend auf die Nutzwertanalyse wird das Analyseraster entworfen. Jede Phasen der Nutzwertanalyse wird besprochen und an die Gegebenheiten einer Bewertungssituation von Multitouch-Tablets angepasst. Die unten stehende Abbildung zeigt die dabei entstehenden Phasen, welche wiederum teilweise aufeinander aufbauen, aber ebenfalls nicht als starres Ablaufschema verstanden werden dürfen. Der folgende Abschnitt geht näher auf die einzelnen Phasen des in der Arbeit entworfenen Analyserasters ein.

Phasen des Analyserasters

Das Analyseraster

Im Folgenden werden die Bestandteile des Analyserasters dargestellt, wie sie auch in der oben stehenden Grafik zu sehen sind.

Szenario-Beschreibung

Die Szenario-Beschreibung dient zunächst der Beantwortung der Frage, aus welchem Grund das Analyseraster durchgeführt werden soll. Außerdem werden die verschiedenen Eigenschaften des konkreten Szenarios dargestellt. Zur besseren Strukturierung werden diese in die Kategorien Ort/Lage, Nutzergruppe und Nutzungskontext eingeteilt ²¹, sodass die Gefahr gemindert wird, wichtige Szenario-Eigenschaften zu übersehen. Die Grafik zeigt mögliche Merkmale eines Szenarios ²², die je nach Notwendigkeit erweitert werden können. Die Feststellung der Szenario-Eigenschaften soll auch eine Überleitung zu den Aggregaten darstellen, um eine Grundlage für deren Auswahl zu schaffen.

Szenario-Eigenschaften

Aggregate

Aggregate sind in diesem Kontext eine Zusammenfassung von Kriterien zu abstrakteren Kriterien ²³. Die Geräte-Eigenschaften sind hier also zu sinnvollen Gruppen zusammengefasst, welche als Aggregate bezeichnet werden. Bei konkreter Anwendung des Analyserasters kann so von den festgestellten Szenario-Eigenschaften zunächst auf die Aggregate geschlossen werden. Dies soll es dem Anwender erleichtern vom Szenario auf die letztlich zu bewertenden Kriterien zu schließen und kann als Zwischenschritt angesehen werden. Aggregate können darüber hinaus auch bei der späteren Gewichtung der Kriterien eine Rolle spielen. Um eine Hilfestellung für die Auswahl von passenden Aggregaten zu geben, zeigt die unten stehende Grafik eine Auswahl an möglichen Aggregaten. Diese kann individuell erweitert werden.

Mögliche Aggregate

Zu bewertende Kriterien

Theoretisch ließen sich bereits die festgelegten Aggregate bewerten, was in den meisten Fällen aber wohl zu grobkörnig wäre. Daher wird im Folgenden ein Überblick über die allgemeinen Eigenschaften und Merkmale von Multitouch-Tablets gegeben. Je nach Szenario können die Eigenschaftsausprägungen eines Gerätes zur Eignung beitragen. Die Abbildung zeigt exemplarisch eine kleine Auswahl an Eigenschaften von Multitouch-Tablets. Diese wurden direkt den Aggregaten zugeordnet, um das Schließen von Aggregaten auf Eigenschaften zu vereinfachen. Eigenschaften können dabei mehreren Aggregaten zugeordnet sein. Zu beachten ist, dass auch die in der Arbeit dargestellte Charakteristik von Multitouch-Tablets nicht als vollständig angesehen werden darf und weitere Eigenschaften eingepflegt werden können. Auch die Zuordnung von Eigenschaften zu Aggregaten sollte nicht als feststehend angenommen werden, sondern je nach Szenario an die eigenen Bedürfnisse angepasst werden. Weiterhin lässt sich der Detailgrad vieler Kriterien noch erhöhen. Dies muss ebenfalls bei Bedarf für ein gegebenes Szenario geschehen.

Auswahl an Aggregaten mit zugeordneten Geräte-Eigenschaften

Gewichtung

Die Gewichtung von Kriterien ist von entscheidender Bedeutung, insbesondere bei Vorhandensein von Kriterien, die in Konflikt zueinander stehen ²⁴. Dabei sind mehrere Verfahren für den Gewichtungsprozess möglich. In der Rregel wird bei allen Verfahren von 100 zu verteilenden Gewichtungspunkten ausgegangen ^{25 20}, sodass die relative Relevanz jedes Kriteriums anhand der ihm zugeteilten Gewichtspunkte abgelesen werden kantn. Die Kriteriengewichtung ist ein komplexer Vorgang, sodass hier oftmals Fehler entstehen, die sich auf das Ergebnis eines Bewertungsprozesses auswirken ²⁶. Daher wird hier die Präferenzmatrix-Methode für diesen Prozess vorgeschlagen ²⁷. Dabei wird jedes Kriterium paarweise mit den anderen verglichen und in einer Matrix vermerkt, welches Kriterium das relevantere in Hinsicht der Zielsetzung des Bewertungsvorganges ist. Anhand der Matrix lässt sich dann für jedes Kriterium das jeweilige Gewicht errechnen. Bei sehr vielen Kriterien ist es auch denkbar, schrittweise zunächst die Gewichtung der Aggregate zu bestimmen (Grobgewichtung), daraufhin die Gewichtung der Kriterien innerhalb jedes Aggregates (Feingewichtung) und daraus die Gewichtung jedes Kriteriums zu berechnen (Gesamtgewichtung des jeweiligen Kriteriums). Die Abbildung zeigt ein examplarisch durchgeführtes Gewichtungsverfahren mit Hilfe einer Präferenzmatrix. Dabei werden einem höher bewerteten Kriterium zwei Punkte, einem niedriger bewerteten Kriterium null Punkte zugeordnet. Gleichwertige Kriterien bekommen einen Punkt. Anhand der Nennungen eines Kriteriums wird dann sein Gewicht errechnet.

Exemplarische Darstellung des Präferenzmatrix-Verfahrens

Bewertungsgrundlage

In einem weiteren Schritt ist festzulegen, anhand welcher Bewertungsgrundlage die Kriterien bewertet werden sollen. Für das Analyseraster wird eine dreistufige Skala mit den Zielwerten 0 („schlecht“), 1 („zufriedenstellend“) und 2 („gut“) gewählt. Diese Auswahl wird getroffen, um die Komplexität des Bewertungsvorganges nicht weiter zu erhöhen. Eine noch feinere Unterteilung würde den Anwender vor die Herausforderung stellen, Eigenschaftsausprägungen sehr fein skalieren zu müssen. Für jedes zu bewertende Kriterium muss nun geklärt werden, welche Eigenschaftsausprägungen welchen Zielwert erhalten. Dies wird anhand der möglichen Ausprägungen und der Szenario-Eigenschaften beziehungsweise den Aggregaten ermittelt. Ist in einem Szenario beispielsweise das Aggregat Ergonomie von Bedeutung und soll infolgedessen die Gerätegröße bewertet werden, so kann aus Gründen der Handhabung einem große Gerät eine höhere Punktzahl zugeordnet werden als einem kleinen Gerät. Ist dagegen das Aggregat Mobilität festgelegt worden und es soll daraufhin ebenfalls die Geräte-Größe bewertet werden, so wird eher dem kleinen Gerät eine höher Punktzahl zugeordnet. Dieses Beispiel zeigt auch, dass das selbe Kriterium mehrfach im Bewertungsprozess vorkommen kann (hier: wenn die Geräte-Größe in Hinsicht Ergonomie \underline{und} Mobilität bewertet werden soll). In solch einem Fall kommt insbesondere die Gewichtung zum tragen.

Beispiel für eine Bewertungsgrundlage in tabellarischer Form

Ermittlung der Alternativen

Die Alternativen sind in einem Entscheidungsprozess oftmals vorgegeben ²⁸, wie es zum Beispiel bei Standort- oder Produktalternativen der Fall ist. Da hier letzteres zutrifft, kann davon ausgegangen werden, dass die Alternativenfindung für das Analyseraster zunächst nur die Frage nach der Verfügbarkeit von Geräten bedarf. Dazu sollte eine aktuelle Marktübersicht genügen. Kommen dabei zu viele Geräte zur Bewertung in Frage ist es möglich an dieser Stelle Anspruchniveaus zu definieren, welches eine Grenze der Ausprägung für ein ausgewähltes Kriterium festlegt ²⁸. Eine Gerät wird dann nicht weiter betrachtet, wenn seine Merkmalsausprägung diese gesetzte Grenze nicht über- beziehungsweise unterschreitet. Sind weiterhin zu viele Geräte zu bewerten, kann die Grenze restriktiver gesetzt werden oder es werden weitere Anspruchniveaus für weitere Kriterien festgelegt.

Berechnung der Nutzwerte

Nun können die Nutzwerte der Geräte anhand ihrer Eigenschaftsausprägungen und deren Zuordnung zur Bewertungsgrundlage errechnet werden. Dazu werden für jedes Gerät separat die erhalten erhaltenen Punkte für ein jeweiliges Kriterium mit der Gewichtung für das Kriterium multipliziert und anschließend diese Teilnutzwerte zum Gesamtnutzwert addiert. Die Alternative mit dem höchsten Gesamtnutzwert kann als die optimale Alternative betrachtet werden ²⁹. Zur besseren Darstellung, können die Geräte anhand ihrer Nutzwerte noch in einer Rangordnung dargestellt werden. Abbildung zeigt eine exemplarische Berechnung von Nutzwerten. Die Punktwerte wurden anhand einer (fiktiven) Bewertungsgrundlage vergeben.

Exemplarische Berechnung von Nutzwerten

Schwachpunkte

Die Schwachpunkte des dargestellten Analyserasters lassen sich auf die Schwachpunkte der Nutzwertanalyse zurückführen. So baut der Bewertungsvorgang oftmals auf vorher gemachte Annahmen und Folgerungen auf, die immer auf der Interpretation des Durchführenden beruhen. Dementsprechend ist die letztlich gemachte Bewertung subjektiv ¹⁸, was das Einschätzen der Qualität schwierig gestaltet. Indem man allerdings die Forderung nach Begründbarkeit stellt und so jede Annahme und Entscheidung nachvollziehbar rechtfertigt, kann die vorgeworfene Subjektivität gemindert werden ²⁰. Ein weiteres Problem kann die Interpretation des Gesamtergebnisses sein. Die Ergebnisse sind nur als relativ zueinander anzusehen, da sie aus Vergleichen entstanden sind ³⁰. Es lässt sich daher nicht unbedingt eine Aussage darüber treffen, wie gut ein Gerät zu einem Szenario passt. Bestehen Zweifel an den Ergebnissen eines durchgeführten Analyserasters, so kann eine Anwendung der sogenannten Sensibilitätsanalyse sinnvoll sein ²⁹, bei der geprüft wird, wie sich Variationen von Annahmen auf das Gesamtergebnis auswirken.

Zusammenfassung & Ausblick

In der dargestellten Arbeit wird ein Analyseraster zur Durchführung einer einfachen und nachvollziehbaren Bewertung verschiedener Geräte-Alternativen für Szenarien konzipiert und besprochen. Für die zu untersuchenden Multitouch-Tablets werden dabei hinsichtlich der Szenario-Merkmale Kriterien gewählt, der Ausprägung für jedes Gerät überprüft wird. Die Geräte können anhand entsprechend erhaltener Punktwerte in eine Rangfolge gebracht werden. Diese trifft eine Aussage darüber, welches der Geräte am geeignetsten für ein Szenario ist und hilft so bei der Auswahl eines entsprechenden Geräte-Modells.

Das Ergebnis kann als richtungweisend, nicht aber als über alle Zweifel erhaben angesehen werden. Da das Analyseraster eher auf dem Papier stattfindet und wohl auch selten alle zu bewertenden Geräte zum Testen zur Verfügung stehen, liegt der Schwerpunkt auf einem der Anschaffung vorausgehenden Bewertungsprozess. Vor Erwerb einer unter Umständen größeren Stückzahl an Geräten, sollte das jeweilige Modell auf Praxistauglichkeit geprüft werden.

Für einen mathematisch berechenbaren Bewertungsprozess ist das Analyseraster nicht geeignet. Um dies zu gewährleisten, hätte als Basis zum Beispiel der Analytische Hierarchieprozess (AHP) gewählt werden müssen, der mathematisch deutlich fundierter ist. Denkbar wäre, beide Verfahren, Nutzwertanalyse und Analytischer Hierarchieprozess, als Basis zu kombinieren und so die Stärken beider Verfahren im Analyseraster zu vereinen. Allerdings ist dabei zu beachten, dass ein höherer Anteil der Schematisierung in diesem Fall deutlich zu Lasten der Verständlichkeit geht und weniger Freiheiten lässt. Das kann je nach Anwendung natürlich gewünscht sein. Eine solche Anpassung könnte Teil zukünftiger Arbeiten sein.

In Hinsicht auf die Zukunftstauglichkeit des Analyserasters kann festgestellt werden, dass diese durchaus sichergestellt ist. Zunächst ist sie gerade nicht auf ein konkretes Szenario festgelegt und kann auf beliebige, auch zukünftige, Szenarien angewendet werden. Auch die durch die fortlaufende Entwicklung neu hinzukommenden Geräte-Eigenschaften können problemlos in das Analyseraster eingepflegt werden, während die Struktur des Analyserasters selbst nicht verändert werden muss.

Danksagung

Dieser Beitrag steht im Zusammenhang mit dem Forschungsprojekt SI-Screen, das mit Mitteln des Bundesministeriums für Bildung, und Forschung (Förderkennzeichen 16SV3982), sowie durch das Europäische AAL Joint Programm (AAL-2009-2-088) gefördert wird. Das Vorhaben wird von der innovationsmanufaktur GmbH (ehemals SportKreativWerkstatt GmbH) koordiniert und gemeinsam mit der Universität der Bundeswehr München realisiert. Weiterführende Informationen sind verfügbar unter http://www.si-screen.eu.