Thesen zur Erstellung von Multitouch-Applikationen

Multitouch … Multi Touch … Wörtlich übersetzt heißt das „mehrfaches Anfassen“, und das trifft es auch recht genau. Multitouch Applikationen sind zum Anfassen, zum Berühren, zum tatsächlich interaktiven Agieren. Schluss mit schnödem Anklicken von Buttons, die Berührung und Bewegung der Hand wird zum Instrument, zur Steuerung, zum Erlebnis. Dieser Anspruch an eine Applikation ist hart aber machbar – vorausgesetzt man Bedenkt einige Grundregeln und geht mit dem passenden Konzept an Multitouch-Projekte.

Konzeption und Usability: Erdenke eine greifbare Welt.

These: Multitouch nur, wenn es Sinn macht. Spielen Sie mit dem Touch-Verhalten.

Die Multitouch-Konzepte müssen dem Nutzer einen Mehrwert durch die Multitouch-Funktionalität geben. Nur durch die reale Abbildung der Applikation als begreifbarer Paper-Prototyp kann man das Multitouch-Erlebnis in einer fast spielerischen Erfahrung aufbauen.
Multitouch ist ein wunderbares Mittel, um Dinge – welcher Art auch immer – begreifbar zu machen. Das ist die Kernaufgabe hinsichtlich Konzept und Benutzerführung. Multitouch-Applikationen bedürfen Konzepte, die sich von klassischen unterscheiden. Es macht keinen Sinn, Konzept zu übertragen, sondern es bedarf einer vollkommenen Neukonzeption einer Applikation, um auf Multitouch-Oberflächen überzeugen zu können.
Bei der Konzeption gibt es Themen, die dankbar sind, andere machen eher Mühe, sich auf das greifbare, haptische Medium übertragen zu lassen. Ein dankbares Thema ist ein Mischpult für DJs. Hier liefern klassische Applikationen, die mit der Maus bedient werden, keine hinreichenden Ergebnisse. Daher lassen Profis im wortwörtlichen Sinne meist die Finger davon und bedienen sich „normaler Technik“ in Kombination mit der digitalen. Wie soll man Turntables bedienen mit der Maus? Welchen langweiligen und traugigen Effekt zieht nur ein mausbedienbarer Slider nach sich?
Weil Multitouch so angesagt ist, wollen es alle haben. Das führt leider auch zeitweilig zu unsinnigem Transfer von Singeltouch oder klassischen Button-Klick-Applikationen in die Multitouch-Welt. Multitouch bedarf anderer Konzepte, als das bisher Bekannte aus der Software- und Webwelt. Ein Jump and Run Spiel macht klassisch umgesetzt auf einem Multitouch-Screen genauso wenig Sinn, wie ein aus der Erfahrung des Nutzers tastaturgestützte bedienbare Formularapplikation, die Massendaten aufnehmen soll. Das eine kennt der Nutzer als klassisches Maus-Steuerung, das andere als Tastaturkontrolliert. Setzen Sie hier auf Multitouch, wird die Welt des Nutzers ins Sinnlose verdreht. Die Mulittouch-Verliebtheit und ihre recht dummen Stilblüten in manchen Konzepten hat hier schon einige Nutzer sich wieder von Multitouch entfernen lassen. Nicht weil Multitouch in seinen Möglichkeiten so dumm ist, sondern vielmehr weil die dafür geschaffenen Applikationen nicht sinnig entworfen waren. Texteingabe über Multitouch führt bei der derzeitigen Benutzung zum Ein-Finger-Adler-Such-System. Man sieht viele I-Pad-Nutzer schon daran verzweifeln …
Beginnen Sie also vor allen Dingen mit einem Konzept, wo Multitouch Sinn macht. Portieren Sie die Nutzer-Realität in den Bildschirm, statt dem Nutzer mit vermeintlichen Sonderfunktionen die Lust auf Multitouch zu vermiesen. Multitouch bei Bildersortierung und Bearbeitung kann Sinn machen, weil der Nutzer hier den Leuchttisch oder Fotocollagen als Umfeld kennt. Der DJ kann mit einem begreifbaren Pult echten Mehrwert durch Multitouch erleben. Ein Küchenkonfigurator für Möbelhäuser mit ausgefallen Kamerafahrten. Spielerisches Lernen ohne Lesen zu müssen. Alles, wo Anfassen Sinn macht. Das Spektrum ist sehr weit. Schließlich lernt man haptisch am besten und kann sich auch Dinge besser einprägen. Fokussieren Sie sich im Kundengespräch bei einem Multitouch-Projekt bitte nicht auf die ausführenden Funktionen, sondern beteiligen Sie sich am Erspinnen von Mehrwert-Ideen und sinnhaftem Multitouch.

These: Visualisiere die Situationen, in denen der oder die Benutzer sind.

Wenn Sie schon über den Nutzer und den Wert der Applikation für ihn nachdenken, beziehen Sie bitte ein, dass es verschiedene Multitouch-Szenarios gibt. Eine DJ-App für einen Surface macht keinen Sinn. Ein Produkt-Konfigurator, der an der Wand hängt, ist nicht geeignet für Beratungssituationen, weil es zu Monologen führt, bei denen dem Kunden der Rücken zu gedreht wird. Ein Brettspiel mit 4 Benutzern macht auf Mini-Multitouch-Screens wie bei Smartphones keinen Sinn.
Machen Sie sich also auch Gedanken über die Situation, in der Multitouch-Screens auftauchen.
Es gibt folgende Szenarien:
–    Solo-Bedienung für Single-User.
–    Duale Bedienung für Dialog-Situationen z. B. in einem Beratungsgespräche
–    Multiuser-Bedienung für mehr als 2 Nutzer z. B. bei einem Spiel

These: Bedenke, dass die Medien von winzigklein bis riesengroß sein können.

Neben den Szenarien bedenken Sie auch die Größe der Ausgabegeräte. Auch das bestimmt ein sinnvolles Bedienkonzept. Das Spektrum liegt zwischen den kleinen Bildschirmen eines Smart Phones und geht bis hin zu extrem großen Screens, die auf Bewegungen des ganzen Körpers reagieren. Witzigerweise wird ja auch bei Gestensteuerung von „Multitouch“ gesprochen, obschon hier gar keine echte Screenberührung stattfindet.

These: Finde spielerisch den Weg zurück zu Paper Prototypen

Wahrscheinlich finden Paper-Prototypen bei Entwicklern keinen Einsatz, weil diese selten Zeichnen können oder wollen. Bei Designern ist das zwar anders, aber diese bewegen sich oft in erster Instanz an ihren Photoshop ran, statt wie in alten Tagen den Bleistift zu schwingen. Dieser ist hier aber eigentlich das Mittel der Wahl, um eine Idee für eine Multitouch-Applikation für Kunden, Umsetzer und künftige Anwender begreifbar zu machen. Mit schnellen Skizzen, die wiederum ausgeschnitten sind und die auf einem Flipchart bewegt werden können, kann man wunderbar das ganze Szenario abbilden. Um absolut ganzheitlich zu sein, kann man sogar die Usability und den Umgang mit der Applikation filmen. All das hat zwar ein bisschen was von kindlichen Bastelstunden, aber genau das ist es, worauf es bei Multitouch-Apps ankommt: Auf ein hohes Maß an Spieltrieb, auf ausprobieren, auf bewegen und immer wieder ändern. Und darauf, dass eine Applikation so schlüssig ist, dass sie ein Kind bedienen könnte und man fast mit kindlicher Faszination daran hängen bleibt.

Interface Design: Natural statt Graphical

 

These : Content is King. Der Inhalt ist Teil der direkten Interaktion.

In der Vergangenheit haben wir gelernt, dass sich die Navigation und Interaction um den direkten Inhalt aufbaut. Das ist nun anders. Wir haben Möglichkeiten, die es zu nutzen gilt. Der Inhalt wird Zentrum der direkten Interaktion. Man kann alles mit ihm machen, was die Touchbefehle zulassen. Somit braucht z. B. eine Karte wie wir sie aus Google Maps kennen keine Zoomslider mehr oder Buttons zum Schieben in andere Bereich der Karte. Vielmehr wird mit der Karte selbst agiert. Hier gilt es dem Nutzer seine Möglichkeiten als direktes Feedback zu zeigen.  Mit einem vierfingrigen Wischen gelangt er in andere Quadranten, mit zwei Fingern kann er in die Karte rein zoomen, mit dreien kann er die Karte drehen und mit einem einfingrigen Tippen kann er weitere Informationen aufrufen. Mouseover gibt es in dem Sinne nicht mehr, aber beim Gleiten mit einem Finger über einen Bereich, können dennoch weitere Informationen angezeigt werden.

These: Bei der Navigationsstruktur zählt nur der Blick auf das Jetzt und Hier.

Multitouch-Applikationen in all Ihrer Inhaltszentriertheit und Inhaltsinteraktion bedürfen keiner klassischen Navigationen mehr. „Alte“ Navigationen sind geprägt von der Einstellung, dass man von jedem Punkt einer Website zu jedem anderen mit kurzen Schritten wechseln kann und das alles immer komplett verfügbar sein muss. Das führt dazu, dass Screens vollkommen überladen sind und man nichts mehr findet. Bei Multitouch-Applikationen dagegen zählt der Blick auf das Aktuelle, das Wesentliche, das Jetzt und Hier in Bezug auf den Inhalt, die Anforderung und die Interaktion. Diese Denkweise hat die posititive Folge, dass Screens nicht mehr zugeballert werden mit Tonnen von Navigationselementen, einer Überflut an auswählbaren Boxen und tausenden kleinen Funktionsbuttons. Hier wird die alte Spielregel, dass der Benutzer ohnehin nur fünf bis neun Elemente gleichzeitig gut erfassen kann wieder beachtet … und das ist auch gut so!

These: Greife zu Metaphern aus der Umgebung der Nutzers und aus dem Zusammenhang der Applikation.

Analog zur Benutzerführung und User Experience sollte auch das Interface von Multi Touch Applikationen das natürliche Umfeld der User abbilden. Metaphern aus der Realumgebung des Nutzers versteht er erheblich besser als Buttons. Im ausklingenden letzten Jahrtausend hat der Designer David Siegel mit seinem Buch „Killerwebsite“ von sich Reden gemacht. Sein Ansatz den Nutzern auf Website eine Metapher zu ihrer Realität zu liefern wird mit heutigen Multitouch-Applikationen aktueller denn je. So braucht es z. B.: bei dem eingangs erwähnten DJ-Pult keine an den haaren herbeigezogenen Bildwelten, sondern ein Blick in die Realität der DJs genügt, um zu wissen, wie ein Mischpult designed sein muss, um auf einem Multitouch-Applikation gut gestaltet zu sein.  Die Bildsprache von einem PictureViewer ist schon schwieriger, weil die Realität da verschiedene Möglichkeiten anbietet. So kann sich das Design semantisch irgendwo zwischen Leuchttisch, Album oder Collage anbieten.

These: Adäquate Größe macht die Dinge greifbar und erfassbar.

Da Multitouch-Applikationen im Unterschied zu den „klassischen“ das natürliche Verhalten des Nutzers mit seinen Händen bei Gestensteuerung mit ganzem Körpereinsatz zu nutzen macht, versetzen Sie die Nutzer in eine andere Welt der User Experience. Winzig kleine Buttons wie man es aus dem Pixelstyle-Webdesign des ausklingenden Jahrzehntes gewöhnt ist, sind für Touchinterfaces absolut untauglich. Microfonts und Microiconagrafie könnnen für einenTouchinterface getrost eingemottet werden. Pixel sind als Einheit einfach nicht greifbar. Hier gilt es groß  zu denken und große Zeichen zu setzen, damit der geneigte Nutzer auch herzhaft zupacken kann. Pixeliges wird ihm hier wie Sandkörner durch die Finger rinnen und unbegreifbar bleiben. Machen Sie als bitte Interface-Elemente in adäquater Größe.

These: Das Endformat bestimmt den Detailgrad.

Egal auf welchem Endformat die Applikation angezeigt wird, gilt für jedes Format das gleiche Paradigma: Der Nutzer muss die Dinge erfassen, also greifen können. Bei kleinen Formaten wie z. B. einem iPhone oder Windows Phone 7 hat man als Designer eine Mindestfläche von 50 an 50 Pixeln zur Verfügung, die noch antippbar ist. Große Gesten wie Wischen oder Zoomen bedürfen entsprechend größerer Flächen, weil hier zwei oder mehr Finger zum Einsatz kommen. Das bedeutet also bei kleinen Geräten, dass nur wenige Elemente auf den Screen dürfen, die mit entsprechenden Abständen zueinander verteilt sind. Für große Ausgabegeräte – hier als krassestes Beispiel eine großer transparenter Multitouch-Rahmen fürs DJing – müssen die Elemente schon so gross sein, dass man sie in einem rasanten Bewegungsfluss mit mehrfingrigem Agieren gut zu „packen“ bekommt. Auch hier ist wieder weniger mehr, andererseits kann auf einem großen Screen natürlich mehr positioniert werden, damit der Nutzer das Gefühl einer geschlossen Applikation eben für dieses Medium bekommt. Hier liegt die Kunst des Layoutens dann eher in dem entsprechenden Arrangement der Elemente zueinander.

Erst die Programmierung dahinter macht das Multitouch-Erlebnis möglich.

 

These: Mehr als nur ein Punkt

In klassischen Eingabesteuerungen hat man meist nur einen Input. Die Maus zum Beispiel sendet immer nur einen Event anhand dessen man eine Aktion ausführt. Im Bereich des Multitouches hat man es immer mit einer Vielzahl von Inputs zu tun. Diese Inputs werden als Blob oder TouchhPoint  bezeichnet. Je nach Gerät ist die Anzahl der gleichzeitigen Blobs unterschiedlich. Leider ist die Multitouch API nicht konsistent auf den verschiedenen Plattformen. Wpf und Silverlight unterscheiden sich zum Teil erheblich. Beide Plattformen teilen aber das gleiche Prinzip. Jedem TouchPoint  wird eine Device-ID zugeordnet an dem er eindeutig identifiziert werden kann. Jeder TouchPoint  hat eine Action (Up, Down, Move) und eine Position. Bei Veränderung des Inputs wird ein Event geworfen, welcher die Veränderung der Inputs repräsentiert. Die Auswertung der Rohdaten der einzelnen TouchPoints führt dann zur Manipulation des berührten Objekts. Malipulationen wie z.B.: Skalierung, Rotation und Bewegung werden hauptsächlich über Matrizentranformationenen realisiert. Zum Glück übernimmt ein Großteil der Mathematik das Framework. Also keine Angst vor Neuem. Wichtig ist noch zu sagen, dass es einen PrimaryTouchPoint gibt. Dieser wird vom System wie ein Mausklick behandelt, und repräsentiert den Finger der als erstes das Eingabegerät berührt hat.  Was man mit ihm machen kann … lesen Sie weiter.

These:  Ein paar Punkte macht noch Gesten

Nachdem wir uns nun mit den Touchpoints angefreundet haben, sollte doch jetzt alles klar sein. Aber weit gefehlt. Oder wissen Sie, wie man einen DoppelTab von einem Tab unterscheidet? Wann ist eine Bewegung eines Touchpoints ein Flick? Wer auf .NET arbeitet wird jetzt sicher sagen „WM_Gesture“. Aber unter Silverlight geht das nicht und Systemhooks sind nicht wirklich schön. Gesten sind eine Abstraktion der Rohdaten des Touchinputs. Und wie jeder Entwickler weiß heißt Abstraktion immer auch Arbeit. Leider gibt es z. Zt. nicht viele fertige Bibliotheken zu dem Thema. Aber die meisten nutzen Interpreter um die Touchpounts in Gesten zu transformieren. Klingt schwer, ist es aber meist nicht. Ein Interpreter benötigt die aktuellen Touchpoints und deren Aktionen und kapselt die Logik zur Erkennung einer einzelnen Geste. So tut ein Interpreter zum Erkennen einer Doubletab Geste auch nichts, wenn gerade 4 Touchpoints auf dem zu manipulierendem Objekt registriert sind. Nur wenn es ein Punkt ist versucht er den Input zu interpretiern. Und was ist nun ein DoubleTab? Eine im Abstand von maximal 0.4 Sekunden aufeinander folgende Berührung des Objekts mit einem Finger. Der Interpreter verarbeitet also eine Down- und eine Up-Aktion eines Touchpoints mit dem gleichen Geräte-Id und dann innerhalb von maximal 0.4 Sekunden eine erneute Down-Aktion eines Touchpoints mit einer anderen Geräte-Id. Bei Gestenerkennung kann auch der schon angesprochene PrimaryTouchPoint interessant sein. Ist es wirklich ein Zweifinger-Tab wenn die verarbeiteten Touchpoints nicht mindestens einen PrimaryTouchPoint enthalten und beide Down –Actions haben? Leider gibt es hier noch keine klaren Definitionen oder Richtlinien. Bei der Gestenerkennung muss man noch viel ausprobieren und immer wieder feinjustieren, denn unterm Strich müssen Gestensteuerungen den Ansprüchen der Anwender genügen.  Und der geneigte Entwickler ist meiste nicht geeignet zu bestimmen was natürlich ist und wie es sich anfühlt 😉

These: Nutze die Physik

Jetzt haben wir schon mit Matrizen gespielt und Rohdaten verarbeitet. Jetzt auch noch Physik? Muss das wirklich sein? Ja muss es. NUI zeichnet sich dadurch aus, dass es sich natürlich verhält. Wenn ich einen Stein werfe, fliegt er auch nicht mit gleichbleibender Geschwindigkeit weiter. Warum sollte also dieRotation eines Objekts enden, nur weil ich die Finger vom Objekt entferne? Ausgehend von der Rotationsgeschwindigkeit würde man ja auch in der Natur erwarten, dass es sich weiter dreht. Diese meist nicht linearen Easings verbessern nicht nur die Haptike einer Oberfläche, sondern erleichtern es auch dem User. Nehmen wir z.B.: eine Kontaktliste mit 1000 Einträgen. Das mittlerweile von der Scrollgeschwindigkeit abhängige Nachlaufen der Liste erleichtert ungemein um von „A – wie Anton“  bis „Z – wie Zeppeline“ zu kommen. Das Inertia getaufte Feature ist schon länger unter Surface bekannt.  Unter Silverlight und WPF gibt es kostenlose Bibliotheken um das Feature nachzurüsten.  Sehr schön an Inertia ist, dass man sehr einfach das Verhalten der Kraftwirkung anpassen kann. Will man z. B. dass ein Objekt nach dem loslassen sich nur noch Vertikal  weiter bewegt, geht dies ohne großen Aufwand. Als Beispiel nehme ich wieder die Kontaktliste. Selbst bei einer Diagonalbewegung über das Objekt bewegt sich der Inhalt der Liste nur Vertikal, abhängig von der Initial wirkenden Horizontalbeschleunigung, und kommt dann zum Stehen.

Abschluss-Statement

Dass Multitouch ein faszinierendes Thema ist, braucht wohl kaum einer Erwähnung. Wir hoffen, dass wir Ihnen mit diesem Artikel die Berührungsängste nehmen konnten, das Thema anzupacken und es in Ihr Portfolio aufzunehmen. Wenn man sich an die Spielregeln in allen Disziplinen hält , ist es leichter als vermutet. Ersinnen Sie also mutig sinnvolle Applikationen. Gestalten Sie spielerisch drauf los und machen Sie mit ihren Programmierkünsten die Multitouch-Welt für Ihre Anwender begreifbar. Kein Grund zu zögern. Packen Sie es an.