In dieser Woche hielt ich beim 9. UX Monday in München (#uxmm9) einen Vortrag mit dem Titel „Mobile Prototyping mit Axure RP“. Neben einer Live-Demo und Tipps zum Erstellen von Prototypen mittels „Dynamic Panels“, stellte ich vor allem die Flexibilität von Axure heraus. Durch die (manchmal verschreckend) umfangreiche Funktionalität und den HTML-Export ist Axure geeignet, Prototypen für Websites, Apps oder TV-Anwendungen zu bauen.

Smartwatch-Prototyping

Ebenfalls in dieser Woche hat Apple vorläufige Richtlinien zum User-Interface-Konzept veröffentlicht, die nun ein ungefähres Bild geben, wie Apps auf der Smartwatch aussehen können. Aufgrund dieser Guidelines habe ich zur Demonstration eine schlanke App mit Axure erstellt. Die App zeigt die abfahrenden Nahverkehrsmittel umliegender und häufig genutzter (Favoriten) Haltestellen.

Standard-Interaktionen

Da es sich bei diesem Beispiel um eine App nach dem Muster „Hierarchical“ handelt, ähneln die Interaktionen stark denen von iPhone-Apps und sind daher mit Axure leicht umzusetzen. (Die neue „Force Touch“-Eingabe könnte leicht mit einem Longpress umgesetzt werden.) Einzig die „Digital Crown“ muss nun mit Trick als Eingabemöglichkeit mit der Maus bedienbar gemacht werden. Schließlich ist das Anzeigen der App noch nicht auf dem tatsächlichen Gerät möglich und es ist unklar, wie das künftig funktionieren kann. In diesem Beispiel dient die Digital Crown als weitere Möglichkeit zu scrollen.

Axure-Datei

Die Axure-7-Datei der Demo-App kann heruntergeladen werden. Zur Verwendung müssen die Schriften FontAwesome (für Icons) und „Roboto“ (Light + Regular) installiert sein. (Ich verwende Google’s „Roboto“, da sie „San Francisco“ – der eigentlich von Apple verwendeten Schriftart – stark ähnelt und frei verfügbar ist.)

Durch Rachel bin ich auf „Rocket Surgery made easy“ aufmerksam geworden, sie empfahl es beim #uxmondaymunich. Steve Krug („Don’t make me think!“) hat ein Buch über Usability-Testing geschrieben. Darin sammelt er unterhaltsam und äußerst komprimiert seine Erkenntnisse aus langjähriger Praxis- und Consulting-Erfahrung.

„Nebenher“ testen

Der Leitfaden richtet sich an Konzepter und Designer, die Usability-Testing „nebenher“ betreiben möchten und bietet eine Anleitung, um kontinuierlich Usability-Schwächen in digitalen Produkten zu erkennen und zu beseitigen.
Mit Ironie und Nerd-humorigen Zitaten gewürzt räumt der Autor mit einer Vielzahl üblicher Vorurteile auf und zeigt, dass es auch anders geht – schneller, einfacher, pragmatischer. Müssen die Testteilnehmer wirklich aus der relevanten Zielgruppe rekrutiert werden? Sind nur drei Testteilnehmer nicht zu wenig? Neben der Klärung dieser und vieler weiterer Fragen gibt Krug praktische Tipps zur kontinuierlichen („A morning a month, that’s all we ask!“) Durchführung von Inhouse- und Remote-Usabilitytests. Themen wie Rekrutierung von Teilnehmern, Screen- und Voice-Recording-Software, Test-Aufgaben, Vergütung von Teilnehmern (z.B. über Amazon-Geschenkgutscheine) werden abgehandelt.

Macht Lust auf mehr

Bei der Lektüre hatte ich einige Aha-Momente, die meine künftige Arbeit sicherlich beeinflussen. Die Kompaktheit des Buches ist angenehm, da die Inhalte so verdichtet sind, dass es als Leitfaden und Werkzeug dient. Es inspiriert aber auch, bestimmte Bereiche tiefer zu beleuchten. Hierfür ist eine kommentierte Empfehlungsliste weiterführender Literatur am Ende des Buches aufgeführt.

Responsive-Webdesign ist voll angekommen. In den letzten Monaten habe ich kein Web-Projekt gestaltet, das nicht responsive umgesetzt wurde. Für die Konzeption von derartigen Projekten habe ich mir einen Prozess angeeignet, der die Aspekte Responsiveness, Visual-Design und Microinteractions abbildet.

Visual-Design und Microinteractions

Wie schon beschrieben, definiere ich die visuelle Sprache mit StyleTiles, Microinteractions dagegen werden traditionell mit Axure umgesetzt und getestet.

Tools

In diesem Beitrag sind kurz die Werkzeuge und Techniken genannt, die ich für das „Responsive-Prototyping“ verwende. Es geht in dieser Phase darum, alle Inhalte und Elemente (der App, Website, …) sinnvoll und vollständig auf Seiten zu verteilen und anzuordnen. Dabei liegt der Fokus auf Layoutänderungen bei verschieden großen Viewports, also vom Smartphone bis zum Desktop-Bildschirm.

Sublime Text

Ein Texteditor für HTML und CSS/Sass.

Hammer for Mac

Hammer stellt Funktionen bereit, statische Seiten (ohne Server) unkompliziert zu generieren. Insbesondere die @include-Funktion hilft bei wiederkehrenden Elementen wie Header oder Footer und erspart mühsame, doppelte Arbeit. Variablen, Platzhalter-Bilder und Navigation-Helper sind ebenfalls hilfreich. Darüber hinaus wird Sass ohne weitere Installationen compiliert.

Sass

Sass hilft mit seinen bekannten Funktionen (Variablen, @extend, …) schlichtweg weniger Zeilen CSS schreiben zu müssen und wiederkehrende Passagen (@mixin) effizient zu handeln. Insbesondere bei Responsive-Webdesign-Projekten wird vorwiegend in wiederkehrenden Modulen gedacht, hier spielt der CSS-Preprocessor seine Stärken aus.

Chrome

Ein Browser mit mächtigen Analyse-Tools („Element untersuchen“). Außerdem werden neuere Funktionen wie (z.B. Flexbox, SVG, Verläufe, …) unterstützt. Für das Erstellen von Prototypen ist Kompatibilität ein nachrangiges Thema.

Viewport Resizer

Dieses Bookmarklet verändert den Viewport des Browsers auf Knopfdruck. Dabei können voreingestellte Gerätegrößen (z.B. iPad Querformat) oder individuelle Dimensionen gewählt werden. Das erspart ständiges, manuelles Verändern des Browserfensters.

XAMPP

Mit XAMPP lässt sich schnell eine Umgebung erstellen, in welcher der Prototyp unter der URL „localhost“ läuft. So können Webfonts einfach eingebunden werden und der Prototyp ist im Netzwerk abrufbar. So kann das Testen auf den tatsächlichen Geräten (Smartphone, Tablet, …) frühzeitig stattfinden.

Github

In meinem aktuellen Projekt bei inserteffect war eine enge Zusammenarbeit mit Entwicklern notwendig, so dass ich den bekannten Versionierungs-Service erstmals einsetzte. Ich werde es künftig für alle Web-Projekte nutzen. Es unterstützt den Prototyping-Prozess immens, da es durch das Ablegen von Zwischenständen (commits) das typische „Vor-und-Zurück“ eines Designprozess vereinfacht. So ist immer ein Backup der Vorversion verfügbar, es lässt sich experimenteller Arbeiten.

Bootstrap

Von Bootstrap habe ich mir eine Custom-Version geladen, die nur das CSS-Grid und die Responsive utilities enthält. So ist es durch einfach Hinzufügen von CSS-Klassen möglich, schnell mehrspaltige (auch verschachtelt) Layouts zu bauen. Die aktuelle Version 3 ermöglicht zudem, je nach Viewport den Elementen eine unterschiedliche Spaltigkeit zuzuteilen.

Für Payworks sollte ich in einem kurzen Projekt die Unternehmenswebsite neu gestalten. Nachdem die Seitenstruktur im Vorfeld erarbeitet wurde, lag der Fokus auf der visuellen Sprache und der Umsetzung nach den Prinzipien des Respsonsive-Webdesign.

Moodboards von UI-Elementen

Max Müller hat mich vor einiger Zeit auf Samantha Warrens Konzept der Style-Tiles hingewiesen und endlich hatte das einen Namen, was ich schon länger in ähnlicher Art praktizierte. Es geht dabei um Moodboards von User-Interface-Elementen zur Exploration der visuellen Erscheinung einer Seite. Es wird also keine Einzelseite mit realen Inhalten und realer Struktur gestaltet, sondern eine Tafel mit verschiedenen Elementen wie Überschriften, Hintergrundmustern, Bildrahmen, Farbfeldern, Typografie-Stilen, Formularfeldern, Buttons, etc. Auf diese Weise wird erreicht, dass beim Gestalten und beurteilen der Entwürfe ausschließlich die visuelle Gestaltung zählt, und nicht die Struktur, der Inhalt oder andere Faktoren. Auf diese Weise wird also – zumindest in dieser kurzen Projektphase – Inhalt und Design einer Website getrennt behandelt, wie es auch der Natur des Web entspricht.

Über die Schulter geschaut: Erstellen von Style-Tiles

Branding mit Style-Tiles

Trotz Kundenbriefing ist das Herausarbeiten des visuellen Stils, der Tonalität und somit der Positionierung des Auftraggebers eine Aufgabe mit einigen Unbekannten. Style-Tiles sind somit auch ein effektives Brandingwerkzeug, anhand dessen der Kunde entscheiden kann, wie er von außen gesehen werden will. Folgende fünf Style-Tiles habe ich bei diesem Projekt vorgelegt:

Konzept ohne Bildelemente und prominenter Typografie

Verspieltes Konzept, welches den Baukasten-Aspekt des Produkts verdeutlicht, mit Serifen-Schrift

Konzept mit abstraktem Illustrativen Stil und leuchtender Akzentfarbe (Illustration von hwaal)

Die „Abschuss“-Variante mit dunklem Hintergrund und 3D-Icon (Icon von romanjusdado)

Hierfür fiel die Entscheidung: Konzept mit gefärbter Fotografie im Hintergrund und hellgelber Akzentfarbe. Schriftart: „DIN“

Nach einer weiteren Ausarbeitung zweier Style Tiles ist dann eine Entscheidung gefallen. Zugegeben, das Briefing hätte keine so große Varianz zugelassen, wie ich sie gestaltet habe. Insbesondere die dunkle Variante mit 3D-Icon entspricht nicht dem Briefing. Ich habe sie trotzdem gezeigt, damit sich alle Projektbeteiligten einig sind, dass sie das nicht wollten. Dieses Vorgehen festigt die Entscheidung für ein anderes Konzept und lässt im Projektverlauf weniger Zweifel aufkommen, ob die anfängliche Entscheidung richtig war.

Responsive Prototype

Nachdem bei der Erstellung von Style-Tiles globale Aspekte wie Farben, Muster, Typografie definiert werden, eignen sie sich besonders als Ausgangspunkt zu Erarbeitung eines responsiven HTML/CSS-Prototypen. Ab diesem Zeitpunkt habe ich die Entwurfsarbeit im Browser fortgesetzt. (Für komplexe visuelle Aufgaben nutzte ich dann vereinzelt wieder Photoshop, oder Axure für Usability-Studien.)

Durch mein aktuelles Projekt – die Umstellung einer e-Commerce- und Community-Website auf responsives Design (RWD) – konnte ich weitere Erfahrungen sammeln, welcher Arbeitsprozess und welche Werkzeuge hier nötig sind. Ist eine Website nach den Prinzipen des Responsive Webdesign erstellt, ist sie auf allen Geräten, vom Smartphone über Tablet-PC bis zu Desktop-PC mit großen Bildschirmen ideal nutzbar. Separate Versionen für verschiedene Geräte oder Geräteklassen werden hierbei nicht erstellt, vielmehr wird die Website so flexibel gestaltet, dass Sie unabhängig vom Ausgabemedium perfekt dargestellt wird. Die Veränderungen des Entwicklungs- und Design-Prozesses derlei Websites im Vergleich zu Websites mit statischem Layout, wie sie die letzten Jahre üblicherweise produziert wurden, könnten nicht größer sein. Auch die Rolle des Designers wird neu definiert.

Agiler Prozess

Designer- und Entwickler müssen parallel – am besten im gleichen Raum – am Projekt arbeiten, das klassische Wasserfall-Modell hat ausgedient. Trotz sorgfältiger Vorarbeit tauchen erst bei der Umsetzung des Entwurfs Fragen auf, die unmittelbare Zusammenarbeit von Design und Technik erfordern. Das ist unvermeidbar, man sollte vielmehr dieses Phänomen bewusst fördern und einkalkulieren. Trotz aller Parallelität ist man gut beraten, dem Designer einen zeitlichen »Vorsprung« zu gewähren.

Dokumentationen ade

Bis heute ist es üblich, dass Webdesigner nach Erstellung der Photoshop-Seitenlayouts diese in einem umfangreichen PDF platzieren, beschriften, vermaßen und Interaktivität beschreiben. Das führt zu hohem Arbeitsaufwand für Designer und zu mühsam zu entschlüsselnden Dokumenten für Entwickler. Kurzfristige Änderungen bei der Umsetzung führen zu abermaliger Aktualisierung der Dokumentation. Zeitraubende, bürokratische Arbeit.

Photoshop alleine reicht nicht

Als Designer ist man gefordert, verschiedene Tools und Techniken parallel zu nutzen, um ein flexibles Interaktions- und Layoutsystem zu erstellen. Ich nutze:

• Papier und Stift für schnelle Wireframes
• Adobe Photoshop für die Erstellung von Style Tiles und die Produktion von Assets/Sprites
• Axure RP für Interaktionsskizzen, also zum Gestalten von Use-Flows unter Vermeidung statischer Wireframes (Rapid Prototyping). Diese Prototypen lassen sich anschließend auch für Usertests verwenden.
• HTML und CSS zur Gestaltung des flexiblen Layoutsystems. So können das Verhalten der einzelnen Elemente bei Veränderung des Viewports sowie die Breakpoints – also die Schwellenwerte für diese Layoutänderungen – definiert werden. Ein Framework wie Bootstrap oder Zurb Foundation kann hier als Basis dienen. Darüberhinaus können vom Designer Schriftstile als CSS-Klassen definiert und bereits in verschiedenen Viewports/Browsern/Geräten getestet werden. Durch den Einsatz von CSS können auch Objektstile (Klassen mit Farb-/Outline-/Text-…Definitionen) für z.B. das Aussehen von Buttons gestaltet werden. So wird dem Entwickler das »Nachbauen« von Photoshop-Effekten erspart und der Einsatz von Hintergrundbildern (Ladezeit!) minimiert. Darüberhinaus profitiert man bereits in der Entwurfsphase von einer realistischen Darstellung (Rendering) im Browser, insbesondere bei der Darstellung von Text.

Designer »programmieren«

Designer aller Disziplinen mussten schon immer um Produktionstechniken und Materialien Bescheid wissen, um für die Produktion ihrer Entwürfe adäquat gestalten zu können. Wichtiger denn je ist es heute für Webdesigner, profunde Kenntnisse in Webtechnologien zu besitzen, um technisch umsetzbare Lösungen zu entwickeln und die Möglichkeiten neuer Technologien voll ausschöpfen zu können. Wie erwähnt gehört das Gestalten im Browser nun auch zu den Aufgaben des Designers.

Teilen = Transparenz

Gerade in multidisziplinären Teams ist Transparenz ein wichtiges Mittel um Verständnis für die eigenen Ideen zu schaffen und alle in Kenntnis zu setzen, wie der Projektfortschritt ist. Daher muss der eigene Arbeitsprozess offen und zugänglich für alle Beteiligten sein. Ich nutze aktuell geteilte Ordner in Dropbox, Tabellen in GoogleDrive, Skype-Chat. Denkbar ist auch der Einsatz von Diensten wie Basecamp oder das Pflegen eines Wikis. Entscheidend ist, dass für jeden das Angebot steht, sich über den Fortschritt des Anderen zu informieren.

Deliverables

Die Frage, was konkret der Designer dem Entwickler in die Hand gibt, damit dieser das Projekt eigenständig umsetzen kann, ist schon falsch formuliert. Bei Responsive-Design-Projekten ist enge Zusammenarbeit ein Muss. Dennoch gibt es Deliverables, also Dokumente, welche die Ideen des Designers dem Entwickler verständlich machen und zur Diskussion anregen. Wichtig ist, dass es nicht mehr ein »finales« Dokument gibt, sondern im Laufe des Prozesses mehrere »Pakete« und Updates an bestehenden Dokumenten erstellt werden. Darüberhinaus muss es Dokumente verschiedener Art geben, z.B. Listen, Sitemaps, Interaktionsprototypen, responsive Layoutentwürfe. Einen voll funktionalen und durchgestalteten Prototyp zu Erstellen kann der Designer nicht leisten und das ist auch gar nicht notwendig.

Fazit

Ich bin gespannt, ob sich für Responsive-Webdesign-Projekte künftig ein einigermaßen standardisierter Prozess etablieren wird. Sicher ist, dass die Zusammenarbeit mit Entwicklern ganz unmittelbar und parallel stattfinden muss. Es gibt immernoch Agenturen, welche die Entwicklung nach Erstellung der Designs außer Haus geben. Das wird künftig bei derlei Projekten kaum mehr möglich sein.

Marco Spieß hat ein Buch geschrieben. Über „markengerechte Gestaltung interaktiver Anwendungen“, auch Branded Interaction Design (BIxD) genannt. Das über 350 Seiten starke Werk ist in fünf Phasen gegliedert, welche als Eckpfeiler jedes Interaktionsprojekts definiert wurden und als Anleitung dienen, kleine wie große Projekte in diesem Feld (Interaction Design, Service Design, Experience Design) zu stemmen. Mit wohl dosierten Praxisbeispielen und aufgelockert durch Interviews mit Branchenkennern ist es gelungen, den Wandel der Branche im letzten Jahrzehnt abzubilden. Veränderungen an allen Positionen, auf Agenturseite, beim Kunden sowie der Berufsbilder werden verdeutlicht. Spannend ist insbesondere die Darstellung von Arbeitsabläufen und wie diese künftig bei komplexen Projekten aussehen können (agile). Nicht zu letzt erhält der Leser Grundlagen der Markenbildung, Researchmethoden und Ideenentwicklung (u.v.a.) sowie Gedanken zum Verhältnis von Design und Technik. Es ist kein Buch über graphische Gestaltung von Webseiten oder Apps, sondern schafft vielmehr einen holistischen Überblick, welche Faktoren für erfolgreiche digitale Markenerlebnisse über alle Touchpoints hinweg wichtig sind. Zudem ist das Buch klar und dennoch spannend gestaltet. Kaufempfehlung!
Branded Interactions, Verlag Hermann Schmidt Mainz, ISBN 978-3-87439-830-5

Für den Usertest einer iPhone-App habe ich nach einer Lösung zur Anzeige des Prototypen gesucht, die folgende Eigenschaften erfüllt:
– lokal auf dem iPhone gespeichert, für ideale Performance und Unabhängigkeit vom Netz (Test vor Ort)
– Fullscreen-Modus ohne fremde UI-Elemente und Interaktionen (z.B. Gesten oder versteckte Buttons) um Irritationen beim Test zu vermeiden
– Erstellung des Prototypen mit Axure RP (= HTML-Output)

Mit PhoneGap Build

Nach einigen unbefriedigenden Versuchen mit Kiosk- und Browser-Apps kam die Idee auf, dass es ideal wäre, eine App zu haben, die nichts weiter macht, als eine lokal gespeicherte Website im Fullscreen-Webview darzustellen. Schon vor einigen Monaten habe ich Anselm Hannemann um Rat gefragt und er verwies mich auf PhoneGap Build.
PhoneGap Build (mittlerweile von Adobe gekauft) ist ein Online-Dienst, der aus einem Paket von HTML-, CSS- und JS-Dateien native Apps für verschiedene mobile Plattformen kompiliert. Folgendes Vorgehen habe ich ausprobiert:
– HTML-Prototyp aus Axure RP exportieren
– Prototyp zu PhoneGap Build hochladen
– iOS-App herunterladen und auf dem iPhone installieren

Das hat soweit geklappt und es läuft schnell, stabil und wie erwartet ohne Einschränkungen, welche die Testperson verunsichern könnten. Cool!

Man benötigt dazu:

1) HTML-Prototyp
2) Account bei PhoneGap Build
3) Apple-Developer-Account für iOS (80 Euro)
4) iPhone-Konfigurationsprogramm

zu 1) HTML-Prototyp

Ich exportiere den HTML-Prototyp aus Axure RP. Dabei heißt die erste Seite „index“, so dass später eine index.html generiert wird. Diese wird dann von PhoneGap Build als Startseite erkannt. Außerdem lege ich in den Prototyp-Einstellungen verschiedene Parameter für mobile Geräte fest, z.B. den Viewport. Der fertige HTML-Prototyp wird nun gezippt, um ihn als einzelne Datei auf PhoneGap Build hochladen zu können.

zu 2) PhoneGap Build

Bei PhoneGap Build muss ein Account angelegt werden, mit dem eine private App kostenlos erstellt werden kann. Wer mehr Apps generieren will, muss bezahlen. Nach dem Hochladen der Zip-Datei wird automatisch mit der Kompilierung (Erstellung) der App für mehrere Mobil-Plattformen (iOS, Android, Windows, …) begonnen. Bei iOS erscheint sogleich eine Fehlermeldung aufgrund des fehlenden Entwicklerzertifikats und Provisioning-Profils. Die .ipa-Datei (iOS-App) kann so noch nicht erstellt werden.

zu 3) Apple-Developer-Account

Hierfür ist ein Apple-Developer-Account für iOS nötig, der 80 Euro jährlich kostet. Drei Dinge sind zu tun, welche durch einen Wizard im Entwickler-Portal von Apple angeleitet werden.
– UDIDs (einzigartige Gerätenummern) der iPhones und iPads müssen angegeben werden, auf denen die Test-App laufen soll.
– Ein Entwickler-Zertifikat muss erstellt werden. Dieses wird im Anschluss mit dem OS X-Programm Schlüsselbundverwaltung als .p12-Datei exportiert und mit einem Passwort versehen.
– Ein Provisioning-Profil muss erstellt werden (Datei mit der Endung .mobileprovisioning).

Auf PhoneGap Build müssen dann das Provisioning-Profil und das Zertifikat samt Passwort als „Signing Key“ hochgeladen werden. Einige Momente später steht die .ipa-Datei zum Download zu Verfügung.

(Dieser Nerd-Stuff hat mich mehrere Versuche gekostet und ist wohl der schwierigste Teil des Setups!)

zu 4) iPhone-Konfigurationsprogramm

Eigentlich kann die App nun auch mit iTunes auf das Gerät übertragen werden (.ipa auf Mediathek ziehen). Ich empfehle jedoch Apples iPhone-Konfigurationsprogramm (auch für iPad), da es besser klarkommt, wenn man neue Versionen der App erstellen und alte Versionen überschreiben will. Mehrmaliges Updaten der App ist so mühelos möglich.

Fertig!

Für mich ist so ein gangbarer Weg gefunden, Prototypen ohne Internetverbindung mit guter Performance für User-Tests oder Kundenpräsentationen zur Verfügung zu stellen. Cool!

Im Folgenden zeige ich Möglichkeiten, wie man Kunden und anderen Projektbeteiligten Prototypen, Wireframes und Design-Mockups von iPhone- und iPad-Apps vorstellen kann. Interessant ist hier vor allem die Entscheidung, ob das Gegenüber selbst die App steuern soll oder ob es sich um eine konventionelle Präsentation handelt. Das hängt von dem Ziel der Präsentation ab und der Vollständigkeit des klickbaren Prototypen. Außerdem ist die Anzahl der Zuschauer entscheidend, ob auf dem tatsächlichen Gerät präsentiert werden kann (realitätsnah) oder ob ein Beamer genutzt werden soll.

iPhoto-Album

Nur der Vollständigkeit halber nenne ich die Möglichkeit mit der »Fotos«-App Visual-Design-Entwürfe zu zeigen. Dazu einfach in iPhoto ein Album mit den Entwürfen anlegen und synchronisieren. Ich lege die Screen-Designs mit iOS-Statusleiste an, so wird der Entwurf bei der Anzeige nicht skaliert oder zentriert. Die Darstellung mit »Fotos« ist im Vergleich zu anderen Apps wie Dropbox besser, da der Fullscreen-Modus clean ist und das Blättern zwischen mehreren Entwürfe auch von ungeübten Nutzer sofort verstanden wird.

Ideal für die Präsentation von pixelperfekten Visual-Designs.

Ideaflight fürs iPad

Die App Ideaflight bietet die Möglichkeit, die Screens von mehreren iPads zu synchronisieren. Der Presenter (Pilot) steuert die übrigen iPads (Passagiere) im Raum. So wird verhindert dass z.B. Kunden die Präsentation schon weiterblättern und abgelenkt sind. Eine WLAN- oder Internet-Verbindung ist nötig.

Ideal für eine Präsentation von Visual-Designs und Wireframes auf den tatsächlichen Geräten, ohne das Ruder aus der Hand zu geben.

Reflection

Die Windows- und Mac-Software Reflection bringt die AirPlay-Technologie auf den Rechner. Somit kann der Bildschirminhalt von iPad (ab 2. Gen.) oder iPhone (4S) einfach auf den Computer gespiegelt werden, inklusive Ton. Sobald Reflection gestartet ist und Rechner und iOS-Gerät im selben Netzwerk sind, kann wie üblich bei apple tv oder Airport-Express-Station auch der Rechner als entferntes Gerät angesprochen werden. Die Übertragung funktioniert leider nicht in Retina-Auflösung, die Qualität ist aber ausreichend für Beamer-Präsentationen.

Ideal für Demonstrationen, wo es auf Animation, Interaktion und die Einbettung in iOS ankommt.

Axshare

Aus der Prototyping-Software Axure lassen sich nun direkt HTML-Prototypen auf die Platform Axshare.com hochladen. Mit Axure lassen sich umfangreiche, voll bedienbare Prototypen in unterschiedlicher visueller Ausformulierung (sketchy bis pixelperfekt) erstellen. Prototypen auf Axshare verfügen über einen individuellen Link und können mit einem Passwort versehen werden. Außerdem kann in den Export-Einstellungen unter anderem definiert werden, wie der Protoyp als Link auf dem Homescreen aussieht und sich verhält (App-Icon und Browserleiste ausblenden für echtes App-Feeling).

Durch Axshare kann nun der Prototyp auf beliebig vielen iOS-Geräten auf dem Homescreen abgelegt werden und zur Präsentation ausgeteilt werden. Eine schnelle Internetverbindung ist dann aber Pflicht.

Ideal für Demonstrationen, wenn Teilnehmer selbst die App testen dürfen. Außerdem lässt sich der Axshare-Link einfach und sicher mit anderen teilen.

HTML-Prototyp mit Beamer

Wenn die Zuhörerschaft zu groß ist oder die Interaktion mit dem Prototyp nicht aus der Hand gegeben werden soll, bietet sich eine Präsentation mit dem Beamer an.

Google Chrome im minimalistischen Fullscreen-Modus bietet sich an, um Prototypen aus Axure anzuzeigen. Ich habe mir zwei Dinge einfallen lassen, welche die Präsentation überzeugender und verständlicher machen können.

1) Durch Installation der Software PinPoint wird der Mauszeiger als großer Kreis angezeigt. Die Größe des Kreises sollte auf einen Fingertipp angepasst werden. Das hilft die Proportionen des UI-Designs besser zu verstehen (»riesige« Buttons bei Touch-Eingabe) und hilft, dem Mauszeiger besser zu folgen.

2) Ich habe für iPad und iPhone eine HTML-Seite erstellt, die das Gerät als Rahmen zeigt und den Prototyp in einen iframe lädt. So kann der Prototyp, der auf dem Gerät funktioniert einfach auch für die Präsentation verwendet wird.

Hier können meine Vorlagen für iPad und iPhone kostenlos heruntergeladen werden. Jeweils in fotografischer und linearer Ausführung.

Zur Verwendung muss der Ordner »data« als Exportziel des Prototyps gewählt werden und sicherhergestellt sein, dass die erste Seite »Home« heißt. Mit Basis-HTML-Wissen kann das natürlich angepasst werden. Durch Vergrößern und Verkleinern in Chrome (⌘ + / ⌘ –) kann die Darstellungsgröße perfekt auf den Beamer angepasst werden.

Für mein aktuelles Projekt teste ich nun seit einigen Tagen die neue Beta-Version (6.5) der Prototyping-Software Axure RP. Ziel ist es, in kurzer Zeit einen klickbaren Dummy einer iPad-App zu erstellen, um das Interaction-Design vor der Programmierung zu optimieren, Nutzertests durchzuführen und Projektbeteiligte in die Entwicklung einzubinden.

Touch-Gesten und Fullscreen-App

Die Beta-Version bietet einige Neuerungen, die umständliche Workarounds unnötig machen und schnell echtes App-Feeling erzeugen. So können beispielsweise Touch-Gesten (Swipe) leicht integriert werden. Diese können einfach auf Dynamic-Panels angewendet werden. Sehr interessant ist auch die Möglichkeit, den HTML-Prototyp als Webapp zu exportieren. Die Webapp wird dann mit individuellem Icon (apple-touch-icon) vom Home-Screen des iPad im Vollbildmodus geöffnet, ohne die störende Leiste von Mobile Safari. Es entsteht nun wirklich fast der Eindruck, es handle sich um eine native iOS-App. Insbesondere, wenn man im weiteren Verlauf die groben Wireframes durch pixelgenaue, polierte Grafikdaten ersetzt. Natürlich kann die Webapp in Sachen Performance nicht mit nativen Apps mithalten. Animationen können leicht stottern. Der Seitenaufbau ist schnell, aber man merkt, dass es sich eigentlich um eine Website (HTML, CSS, JS) in einem Container handelt.

Prototyp online zur Verfügung stellen

Wenn die Teammitglieder an unterschiedlichen Orten arbeiten, kann der Prototyp auch auf der Austauschplattform AxShare anderen zur Verfügung gestellt werden. So ist bei jedem Beteiligten immer die neueste Version des Prototyp installiert. Beim Öffnen der Web-App vom Homescreen werden dann selbstverständlich die Onlinedaten bevorzugt und die App aktualisiert.

Timesaver!

Diese und viele weitere Detailverbesserungen in Axure RP ermöglichen, dass schon nach wenigen Stunden die ersten interaktiven Ergebnisse direkt auf dem Gerät getestet werden können.

Im Deutschen werden Sie „intelligente Ordner“ genannt. Es handelt sich um eine häufig implementierte Funktion in Desktop-Software. Smart Folder sind Ordner, die Datensätze enthalten, die bestimmten, vorher festgelegten Kritererien entsprechen. So ist es in iTunes möglich, neben normalen Wiedergabelisten (individuelle Sammlungen von Liedern) auch „intelligente“ Wiedergabelisten anzulegen. In meinem iTunes findet sich beispielsweise eine solche Liste mit dem Namen „Partyhits“. Alle Songs, die ich mit vier oder fünf Sternen bewertet habe, befinden sich darin. Wenn nun weitere Lieder der Mediathek mit z.B. 4 Sternen bewertet werden, werden diese automatisch den „Partyhits“ hinzugefügt.
Weitere Beispiele sind Intelligente Postfächer in Apple Mail (Bsp: Postfach mit allen Mails von Amazon) oder eine gespeicherte Suche in der Seitenleiste des Finders (Bsp: Liste aller Dateien, die heute erstellt wurden). Typischerweise wird als Icon dann ein Zahnrad oder ein anderes Symbol in Verbindung mit einem Zahnrad verwendet. Man hat davor „Einstellungen“ vorgenommen.

Mainstream-User

Giles Colborne teilt in seinem lesenswerten Buch „Simple and Usable“ Softwareanwender in drei Gruppen. Er definiert zunächst den Experten, der gerne Zeit investiert um neue Funktionen auszubrobieren, die Möglichkeiten ausreizt und eigene Anpassungen vornimmt. Desweiteren gibt es den engagierten Nutzer (willing adopter), der ebenfalls offen ist, neue Funktionen zu verwenden, jedoch nur, wenn der Nutzen spürbar und die Einarbeitung mühelos erfolgt. Außerdem hat dieser schon ähnliche Produkte verwendet. Als dritte Gruppe benennt Colborne den Otto-Normal-Nutzer (mainstreamer), der Technologie nicht der Sache wegen nutzt, sondern um eine bestimmte Aufgabe zu erledigen. Er lernt einige Schlüsselfunktionen und dabei bleibt es meist.
In einem Diagramm erleutert der Autor die typische Verteilung: Experten 9%, engagierte Nutzer 23%, Otto-Normal-Nutzer 68%. Er erleutert, dass es einfacher ist, für die ersten beiden Gruppen zu gestalten, da diese leichter zufriedenzustellen sind. Erst wenn ein Produkt für die Mainstreamer zugänglich ist, ist es wirklich einfach zu bedienen. Wer für Experten und Engagierte entwickelt, schießt über das Ziel hinaus und beeinträchtigt die User Experience der größten Nutzergruppe.

Zurück zu den intelligenten Ordnern

Im Moment arbeite ich am User Interface einer Business-Software für OS X. Auch hier stellt sich die Frage, ob die Smart-Folder-Funktion integriert werden soll. Technisch ist das kein Problem, aber ist es auch für den Nutzer sinnvoll? Im ersten Usertest wurde ein defaultmäßig angelegter intelligenter Ordner jedenfalls nicht richtig verstanden.
Dennoch bin ich der Meinung, dass die Funktion integriert werden muss, obwohl sie ganz offensichtlich nur für Engagierte oder Experten interessant ist. Jedoch muss bei der Gewichtung darauf geachtet werden, welcher Usertyp angesprochen wird. Als Entwickler einer Software gehört man gewöhnlich zur Gruppe eins und zwei. Man muss sich aber klar sein, das der Otto-Normal-User nie einen Smart Folder anlegen wird!