Die Probanden bekommen Zugangsdaten und können sich danach in das System einloggen. Danach werden sechs vordefinierte kleine Aufgaben durchgearbeitet. Alle Beobachtungen und Anmerkungen der Testperson werden dabei notiert und danach noch ein paar offene Fragen gestellt.

Warum Usertesting?

Durch diese Tests können wir unsere App laufend optimieren. Außerdem bekommen wir zusätzlich Informationen über das Nutzungsverhalten abhängig von Alter und Beruf. Hier werde ich die bisher wichtigsten Erkenntnisse beschreiben. Die folgenden Screenshots sollen helfen die nachstehenden Punkte besser verstehen zu können.

1) Persönliche Übersicht

2) Projektübersicht ohne Aufgaben

Beschriftung/Wording

Viele Begriffe die in Herculess verwendet wurden, wie beispielsweise “Dashboard” oder “Task” waren den Testpersonen nicht geläufig. Während für uns als Webprofessionals diese Begriffe Gang und Gebe sind, haben die Probanden ihre Bedeutung teilweise nicht verstanden. Deshalb haben wir die Begriffe gegen Deutsche Wörter ausgetauscht: zum Beispiel wurde aus Dashboard Übersicht und aus Task Aufgabe.

Datum

Das Datum für Aufgaben war im Format “20. Mai, 2014” angegeben. Die Tests ergaben, dass Zusätze wie heute, morgen oder gestern hilfreich wären. Außerdem wurden Wochentagsangaben gewünscht, sowie relative Zeitzusätze wie “noch 2 Wochen”.

Layout

Besonders positiv wurde von allen Probanden das “aufgeräumte” Layout erwähnt. Die Tester haben schnell erkannt, dass das Plus rechts oben für das Erstellen von Aufgaben und Projekten vorgesehen ist. Auch wenn zu Beginn keine Aufgabe vorhanden war, haben sie durch den kurzen Beschreibungstext sofort gewusst was zu tun ist.

Icons

Das Thema Icons ist sehr schwierig, besonders wenn man ein Icon nicht nur zur Unterstützung einer Beschriftung in einem Button verwendet, sondern es keine Beschriftung hat. Das Plus für Hinzufügen und der Haken zum Abschließen wurde von allen Probanden verstanden. Probleme gab es aber bei dem bekannten Hamburger Icon für das Menü. Besonders ältere Probanden erkannten das Icon nicht. Im Gegensatz zu den jüngeren Testpersonen, die das Icon dann einfach “ausprobiert” haben, hatten die älteren hier mehr Scheu. Gegen das Hamburger Icon gibt es zurzeit einiges an Kritik in der Online-Community. (Siehe beispielsweise: Before the hamburger button kills you). In der Erstversion werden wir das Hamburger Icon so belassen, wobei wir wahrscheinlich “Menü” dazu schreiben werden, dazu werden wir aber noch ein paar Tests machen. Am Desktop ist das Menü ohnehin immer eingeblendet. Allgemein hatten aber nach dem Test alle Probanden angegeben keine Probleme beim Navigieren durch die App gehabt zu haben.

Gesten

Während wir in einer anderen Studie “Touchgesten in Webbrowsern am Smartphone”, welche diesen Sommer publiziert wird, untersuchen ob User Touchgesten überhaupt verwenden, haben wir während des Herculess-Tests herausgefunden, das kein Proband bisher Swipe-Right für Details oder Swipe-Left zum Aufschieben verwendet hat. Der Indikator für Optionen in der Listenansicht ist aber bei einem Großteil der Nutzer gut angekommen. Diese haben darauf geklickt & somit die Optionen in der Liste eingeblendet, um eine Aufgabe abzuschließen.

Die Liste mit gefundenen Optimierungsmöglichkeiten könnte ich hier noch viel länger fortsetzten, jedoch sind das meist sehr spezifische Dinge. Falls jemand noch mehr darüber wissen möchte oder einfach nur allgemein Fragen zu der App hat, stehen wir jederzeit zur Verfügung.

Fazit

Solche Tests sollten keine einmalige Sache bleiben. Einen kurzen Testleitfaden mit kleinen Aufgaben zu erstellen ist, wenn man seine App kennt, wirklich kein großer Aufwand & diesen Testleitfaden kann man dann, mit kleineren Adaptionen, über eine längeren Zeitraum verwenden. Jeder unserer Tests hat nicht  länger als 10 Minuten gedauert und viele wichtige Erkenntnisse für unser Projekt gebracht. Es ist sehr wichtig, dass man bei solch großen Projekten nicht das Gefühl für die “echten” User verliert, denn im Normalfall ist der Durchschnittsnutzer kein Computerprofi, der den Großteil seiner Zeit online verbringt.

The post Usertesting einer Webapp appeared first on Mobile USTP MKL.

Die Themen der Konferenz waren sehr vielfältig. Das Spektrum reichte von Entwickler-Themen wie Angular JS und weiteren JavaScript Vorträgen über Responsive Web Design und SASS bis hin zu User Interface Design und Daten Visualisierung. Dadurch konnte sich jede/r die interessantesten Themen heraussuchen.

Einer der spannendsten Vorträge war der des Gründers des bekannten Smashing Magazine, Vitaly Friedman (Twitter: @smashingmag), über Responsive Web Design. Der Talk mit dem Titel “Real-Life Responsive Web Design” deckte sehr viele wichtige Aspekte ab, die heutzutage für die Erstellung von flexiblen Web-Projekten wichtig sind.

Auch sehr spannend war der Vortrag von Monica Dinculescu (Twitter: @notwaldorf). Sie arbeitet bei Google an der Entwicklung des eigenen Browsers Chrome und sprach über sechs Tricks, wie Google seine Chrome User glücklich macht. Damit gab sie einen spannenden Einblick hinter die Kulissen der Arbeit von Google.

Die Designer/innen und Entwickler/innen der Masterklasse Mobiles Internet konnten sehr viel aus den verschiedenen Vorträgen mitnehmen und werden auch bei der nächsten Konferenz in Österreich wieder dabei sein.

The post codefront.io appeared first on Mobile USTP MKL.

Lea Verou hielt eine der beiden Keynote Vorträge mit dem Thema “The Chroma Zone Engineering Color on the Web”. Dabei zeigte sie die unterschiedlichsten Methoden der Farbimplementierung in CSS auf. Neben der Analyse des Farbraumes RGB und der Erweiterung um den Alphakanal RGBA, erklärte sie auch die anderen Möglichkeiten um Farbwerte auszudrücken, wie HSL (Hue, Saturation, Luminance) und HSLA (Hue, Saturation, Luminance, Alpha). Neben zahlreichen nützlichen Javascript und Sass Funktionen zur Berechnung der Farbwerte stelle sie auch die Neuerungen im neuen W3C Color Modul 4 vor. So ist vorgesehen, dass es eine neue Möglichkeit für den Ausdruck der Farbwerte gibt, nämlich HWB, diese Möglichkeit kennt man auch aus Photoshop. Außerdem gibt es erstmalig Variablen direkt im CSS. So gibt es dann die neue Variable currentColor, die verwendet werden kann um die aktuelle Farbe in einer Regel wieder zu verwenden. Außerdem gibt es eine Funktion gray() über die mit der Angabe von Prozenten der Grauton direkt im CSS gesteuert werden kann. Die Neuerungen werden kaum von Browsern unterstützt, jedoch zeigte Lea Fallbacks um die Neuerungen jetzt schon zum implementieren. Alles in allem, war es ein sehr spannender Talk und Lea überzeugte nicht zuletzt mit einer interaktiven Präsentation und einigen Live-Code Beispielen.

Pascal Precht präsentierte in seiner ebenfalls interaktiven Präsentation Dependency Injection und Two-Way Data-Binding mit Angular.js. Darüber hinaus behandelte er das Thema Internationalisierung und Lokalisierung und zeigte, wie man über die Möglichkeiten von Angular hinaus, mit Angular-Translate Texte und Formate einfach asynchron laden und dynamisch anpassen kann.

Mikael Konutgan von All About Apps zeigte in einer Gegenüberstellung von Objective C mit Ruby, die von vielen unerwarteten Gemeinsamkeiten. Er verglich den Syntax der beiden Programmiersprachen und vermittelte den Zuschauern, das es viel mehr Ähnlichkeiten als Unterschiede gibt, vor allem wenn man von “modernen Objective C” ausgeht. Und für alle die den gewöhnungsbedürftigen Block Syntax von Objective C im Kopf behalten, verwies Mikael noch auf die Seite http://fuckingblocksyntax.com/, wo er selbst täglich nachschlägt. Seine Slides mit dem genauen Codevergleich sind unter https://speakerdeck.com/kmikael/objective-c-for-rubyists zu finden.

Steve Scott gab uns in seiner Keynote “Going Native” einen amüsanten Einblick in sämtlich Programmiersprachen, mit denen er selbst in der Vergangenheit gearbeitet hat bzw. heute noch arbeitet. Anhand dieses Streifzuges durch die Zeit zwischen 1987 bis heute zeigte Steve, wie sich die “native” Programmierung von damals, wo Entwickler Code auf Systemeben schrieben, im Vergleich zur Gegenwart, wo großteils Frameworks wie beispielsweise Cocoa Touch für iOS verwendet werden unterscheidet. Auch die Entwicklung von mobilen Webapplikationen setzte Steve in seiner Keynote auf dieselbe Ebene, wie die Entwicklung von “nativen” Apps für Plattformen wie iOS, Android oder Windows. Der Browser bietet in diesem Fall die Plattform und HTML, CSS und Javascript ein Framework zur Entwicklung von Applikationen. Den wesentlichen Vorteil von plattformspezifischen Apps sieht Steve vor allem in der User Experience, die aus seiner Sicht bei crossplatform Apps zu kurz kommt.

The post Das war die Kod.io 2014 in Linz appeared first on Mobile USTP MKL.

Während Ember-Data somit extrem hilfreich ist und auch für sehr komplexe Applikationen geeignet ist, stießen wir auf das Problem, dass man zwar einstellen kann, ob man die Daten über eine REST-API oder den LocalStorage persistieren möchte, aber nicht beide Optionen gleichzeitig nutzen kann. Für Herculess brauchen wir aber eine Funktionalität, die standardmäßig Daten vom REST-Server holt und nur im Offline-Fall auf zwischengespeicherte Daten aus dem LocalStorage zurückgreift.

Der Weg zum Ziel

Die Lösung dieses Problems war nicht ganz einfach und hat erst einmal zu diversen Fehlversuchen geführt. Erste Ansätze waren es, den bestehenden LocalStorage-Adapter von Ember-Data umzubauen und um eine Hintergrund-Synchronisierung zu ergänzen. So hätte Ember immer lokal im LocalStorage gearbeitet und nur im Hintergrund wären die Daten von der REST-API in den LocalStorage geschrieben worden. Das Problem hierbei war jedoch, dass Ember, um stets eine Datenintegrität zu gewährleisten, es nicht ermöglicht, zur Laufzeit alle Daten aus dem LocalStorage zu erneuern. Es hätte stets nach dem Update von der REST-Schnittstelle eine kompletter Seitenrefresh durchgeführt werden müssen, was wiederrum die unbemerkte Synchronisierung unmöglich gemacht hätte.

Nachdem diverse Experimente in diese Richtung fehlgeschlagen sind, haben wir einen neuen Ansatz ausprobiert: Wenn die App offline ist, sollen die Ajax-Calls einfach statt an den Server an eine (offline verfügbar gemachte) Datei geroutet werden und diese dann aus dem LocalStorage zwischengespeicherte Daten in derselben Form wie die richtige REST-API zurückgeben. So könnte der Client immer gleich arbeiten und nur die URL der AJAX-Calls müsste geändert werden. Das Problem hierbei ist natürlich, dass man lokal nur JavaScript/HTML zwischenspeichern kann und diese clientseitig keine reinen JSON-Responses zusammenbauen können: Die AJAX-Calls parsen die Responses ja nicht, sondern geben nur den Dateiinhalt zurück.

Somit sind wir schlussendlich bei einer Adaption dieser Idee gelandet. Anstatt eine Pseudo-API zu implementieren, fangen wir alle AJAX-Calls ab und liefern mithilfe des jQuery-Plugins jquery.ajax.fake selbst zusammengebaute JSON-Responses zurück.

Unsere Lösung

In der Praxis sieht das wie folgt aus:

Der erste Schritt ist es, die Daten überhaupt einmal zwischen zu speichern. Dafür haben wir eine JavaScript-Klasse erstellt, welche für alle Synchronisations-Vorgänge zuständig ist. Diese ist komplett unabhängig von Ember.

Diese Klasse hat eine „sync()“ Funktion. Diese Funktion holt sich von der REST-API über eine eigene Route „/downSync“ eine Kollektion aller wichtigen Daten für diesen User. Diese Kollektion enthält alle Tasks und Projekte, die für diesen User wichtig sind.

Das Sync-Objekt speichert diese Daten dann in den LocalStorage. Danach wird nach einigen Sekunden erneut sync() aufgerufen und die Daten im LocalStorage aktualisiert. Somit sind die Daten im LocalStorage immer (bis auf seltene Ausnahmen) eine Spiegelung der Daten von der REST-API.

Der nächste Schritt ist es, abzufragen, ob gerade eine Internet-Verbindung besteht. Das machen wir beim ersten Seitenaufruf über „navigator.onLine“, welcher den Online-Status zurückgibt. So wird ein Cookie „is-offline“ auf true oder false gesetzt. Danach wird bei jedem Sync-Versuch dieser Cookie angepasst, falls der Sync-Versuch fehlschlägt oder doch wieder klappt.

Falls die App erkennt, dass man plötzlich offline geht, schaltet sie auf jquery.ajax.fake um. Dafür verändern wir über die jQuery-Funktion „$.ajaxSetup“, welche Voreinstellung für alle folgenden $.ajax-Calls setzen kann, das Attribut „fake: true“. Dieses braucht jquery.ajax.fake, um zu wissen dass dieser Request gefakt werden soll.

Zusätzlich dazu muss man, damit die Fake-Responses funktionieren, für jede URL einstellen, welcher Response kommen soll. Da es unmöglich wäre, hier im Vorfeld alle möglichen URLs einzustellen (da wir ja auch Parameter wie IDs mitsenden), muss das automatisch geschehen. Das haben wir so gelöst, dass wir in der Ember-Data Methode, die für die AJAX-Aufrufe zuständig ist, noch eine Zeile hinzugefügt haben, die – vor dem Senden – zu der nun gleich gesendeten URL immer die gleiche Funktion aufrufen soll.

$.ajax.fake.registerWebservice(url, function(data) {
    return restSyncer.fakeAjax(data);
});

Außerdem fügen wir vor dem Senden die URL als Parameter zum AJAX-Request hinzu.

Die Funktion, welche die Fake-AJAX-Responses zusammen bauen soll, kann dann über den so mitgelieferten Parameter „url“ ermitteln, welche Route angesprochen wurde, und dann aus dem LocalStorage entsprechend einen Response zusammenbauen und zurückgeben. Die eigentliche App merkt so nie, ob die Daten jetzt wirklich vom Server oder aus dem LocalStorage kommen. Sobald die App wieder online ist, wird automatisch umgestellt – ohne, dass der User es merkt.

Während diese Methode, soweit bisherige Test gezeigt haben, sehr gut und nahtlos funktioniert, hat sie auch zwei Nachteile: Jede Änderung der REST-API muss genau im Client gespiegelt werden, und es entsteht zusätzlicher Traffic durch das Syncen im Hintergrund. Letzteres werden wir in späteren Versionen optimieren, indem wir einen Timestamp der letzten Synchronisierung mitschicken und so nur neue Einträge erhalten. Außerdem soll man in der App die Frequenz der Sync-Abfragen einstellen können oder auch nur manuell synchronisieren.

Die aktuelle Implementation funktioniert bereits für alle GET-Requests. POST, PUT oder DELETE Requests sind aber genauso lösbar: Hierfür werden wir alle solche offline getätigten Requests eigens im LocalStorage speichern, und wenn die App wieder online geht werden diese gespeicherten Requests einer nacheinander erneut an den Server gesendet. Hierbei ist es besonders wichtig, den Status mitzuspeichern: Erstens muss der User immer wissen, ob gerade etwas synchronisiert wird oder ob alle Daten aktuell sind, und zweitens muss die App immer wissen, ob ein Request erfolgreich beim Server angekommen ist oder ob es wieder einen Fehler gab und es später erneut versucht werden muss, um den Verlust von Daten zu verhindern.

The post Offline REST Fallback via LocalStorage appeared first on Mobile USTP MKL.

Die wichtigsten Eckdaten für die erste Version unserer API schauen wie folgt aus:

• PHP-basiertes Backend
• Gibt JSON zurück
• Aktionen: CRUD: Create, Retrieve, Update, Delete
• CRUD soll passende HTTP-Header verwenden
• Authentifikation soll später über OAuth2 gehen, erstmal eine simple Pseudo-Implementierung zum Testen

Mit diesen Daten im Kopf haben wir also begonnen unsere API zu entwickeln.

Dafür verwenden wir das PHP-Framework Slim Framework, welches ausschließlich für solche REST-APIs gedacht ist. Nachdem wir das Framework nach dem (sehr einfachen) Tutorial der Webseite eingebunden und initialisiert haben, war hier schon mal ein wesentlicher Grundstein gelegt. Das Slim Framework nimmt uns im wesentlichen das Routing ab. So müssen wir uns nur noch um die eigentliche Datenverarbeitung kümmern.

Für unser Framework verwenden wir Routen, wie sie mittlerweile von den meisten APIs genutzt werden. Sie folgen dem Prinzip:

/projects: Gibt alle Projekte zurück

/projects/1: Gibt das Projekt mit der ID 1 zurück

/projects/1/tasks: Gibt alle Tasks des Projektes mit der ID 1 zurück

/tasks/1: Gibt den Task mit der ID 1 zurück

…

Alle diesen Routen können grundsätzlich mit verschiedenen HTTP-Headern (GET für Retrieve, POST für Create, PUT für Update, DELETE für Delete) genutzt werden. So wird ein GET Aufruf an /projects alle Projekte zurück geben, während ein POST Aufruf an /projects, zusammen mit mitgesendeten Daten, ein neues Projekt erstellen wird.

Wir werden nun kurz erläutern, wie wir bei der Entwicklung dieser API bisher vorgegangen sind. Die Authentifizierung werden wir in einem späteren Blogbeitrag behandeln, in diesem einfachen Beispiel gehen wir davon aus das alles öffentlich zugänglich ist.

Wir haben folgende Ordnerstruktur:

• /Slim (Framework-Dateien)
• /classes
  • ApiObject.class.php
  • ApiResultBuilder.class.php
  • Project.class.php
• index.php
• .htaccess

In der .htaccess haben wir folgenden Code, der dafür sorgt dass wir “schöne” URLs wie “http://api.com/tasks/1” statt “http://api.com/index.php/tasks/1”:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [QSA,L]

Wir werden nun zeigen, wie wir beispielsweise die Routen /projects und /projects/1 implementiert haben. Andere Routen werden im Grunde genauso gehandhabt.
In der index.php binden wir die nötigen Klassen ein und kümmern uns dann in einem späteren Schritt um das Routing:

// Don't forget to load all neccessary classes!

// Initialize Slim Framework
require 'Slim/Slim.php';
\Slim\Slim::registerAutoloader();

$api = new \Slim\Slim();

$api->get('/projects', function ($) {
  // todo
}

$api->get('/projects/:uid', function ($uid) {
  // todo
}

$api->run();

Hier sehen wir, wie das Routing mit Slim funktioniert. Die eigentliche Datenverarbeitung passiert in den entsprechenden Klassen, in diesem Fall in der Project.class.php.
Aber was machen eigentlich die anderen drei Klassen, die wir erstellt haben?

Die Klasse “ApiObject” ist die Vorlage, von der die anderen Api-Klassen wie Project oder Task erben. In der aktuellen Implementation gibt es eigentlich keine besonderen Vorgaben hier, wir haben das nur für zukünftige Erweiterbarkeit so umgesetzt.

Die ApiResultBuilder-Klasse ist für den eigentlichen Aufbau der JSON-Response zuständig. Wir haben das so implementiert, damit es immer eine einheitliche Rückgabe gibt, und bei einer ggf. API-Änderung das nur an einer Stelle geändert werden muss.

Wir wollen eine Rückgabe wie folgt erreichen:

{
    "status": {
        "code": 100,
        "message": "OK"
    },
    "projects": [
        {
            //Objekt1
        },
        {
            //Objekt2
        },
        //...
    ]
}

In einer eigenen Tabelle in der Datenbank haben wir uns die möglichen Statuscodes mit passenden Messages gespeichert. zB. ist 100: OK oder 205: ENTRY NOT FOUND.

Schauen wir uns zuerst die ApiResultBuilder-Klasse an.

Diese verfügt über folgende Methoden: addObject(), setStatus(), setDataType(), getStatusMessage() und out().

Die Methoden setStatus() und setDataType() setzen im ApiResultBuilder-Objekt die Attribute “status” bzw. “dataType” auf einen übergebenen Wert. DataType entspricht dabei im obigen Beispiel “project”, also dem Model-Name. So können wir die JSON-Response theoretisch mit mehreren Objekttypen zurückgeben. Die Methode getStatusMessage() liefert zum Status die entsprechende Status-Message (zB. “OK” oder “ENTRY NOT FOUND”).

Die spannenden Methoden sind addObject() und out(): Ersteres kümmert sich darum, Daten zur Ausgabe hinzuzufügen, und letzteres kümmert sich um den Zusammenbau der Ausgabe. Die Methode addObject() nimmt ein normiertes Objekt als Übergabe-Parameter und speichert es im Objekt ab. Die Methode out() baut dann aus status, statusMessage, dataType und den gespeicherten Objekten die obige JSON-Response zusammen und gibt diese als Text aus.

Die Verarbeitung der Route /projects kann dann wie folgt passieren:

// Load all Projects from Project class
$projects = Project::getAll();
$apiBuilder = new ApiResultBuilder();
$dataType = "projects";

if(count($projects) < 0) {   // No results   $apiBuilder->setStatus(205);
} else {
  foreach($projects as $project) {
    $apiBuilder->addObject($project);
  }
  $apiBuilder->setStatus(100);
}

$apiBuilder->setDataType($dataType);
echo $apiBuilder->out();

Somit kümmert sich die index.php nur um das Routing, die ApiResultBuilder nur um die Ausgabe und die eigentlichen Klassen kümmern sich rein um die Datenverarbeitung. Natürlich ist dieses Beispiel recht vereinfacht und muss um Abfragen und Authentifizierung erweitert werden. Es lässt sich aber ausgezeichnet vergrößern und bietet eine ausreichende Trennung der verschiedenen Codeteile.

Wer sich fragt, wie man zB. mit POST-Anfragen umgehen würde: Auch das lässt sich mit Slim ganz einfach machen:

$api->post('/projects', function () { ...}

In diesem Block kann man dann einfach normal mit $_REQUEST arbeiten, um die mitübergebenen Daten zu verwenden.

In diesem Blogpost haben wir nun einen kleinen Einblick in unseren Ansatz zum API-Design gegeben. Natürlich gibt es tausende Ansätze, Formatierungen und Möglichkeiten, um solch eine API umzusetzen. Wir freuen uns über alternative Ideen in den Kommentaren!

The post Erstellung einer einfachen REST-API mit PHP appeared first on Mobile USTP MKL.

Aus diesem Grund ist es besonders wichtig, das Design, die Eingabe und die Gesten so aufzubauen, dass es leicht erlernt werden kann und dem User eine gute User Experience bietet. Denn wie Steve Jobs es schon sehr passend formuliert hat: Es geht nicht nur darum wie aus aussieht oder wie es sich anfühlt, sondern auch darum wie es funktioniert! In den nächsten Wochen werden wir also laufend aus unseren Erfahrungen mit dem Projekt berichtet. Aus meiner ersten Recherche ergaben sich die folgenden Punkte, die man zu smarten UX Design beachten sollte:

Transitions

Transitions (Übergänge) helfen dem User sich zu orientieren. Wenn man zum Beispiel ein Akkordeon öffnet und sich dieses langsam ausklappt, fühlt sich das für den User viel natürlicher an, als wenn es einfach plötzlich erscheint, das es so etwas in der Realität auch nicht gibt. Ein gutes Praxisbeispiel ist auch das Plusicon, was sich beim Öffnen des Inhalts zum einem „X“ dreht.

Menü Transition (Dribbble – Zarin Ficklin)

Inhalte anbieten, wenn der Nutzer sie braucht

Es sollte auf den ersten Blick zwar ersichtlich sein, aus welchen Komponenten die Seite besteht, jedoch sollte nicht zu Beginn alles geladen werden. Man sollte die UI Elemente also auf das wesentliche reduzieren und erst nach und nach enthüllen, wenn der Nutzer sie braucht. Eine übliche Vorgangsweise ist es zum Beispiel bei Blogbeiträgen die einzelnen Kommentare erst zu laden, wenn der Nutzer an die jeweilige Stelle scrollt.

Angebotscharakter der UI Elemente

Hier ist gemeint UI Elemente so zu stylen, dass der User die richtigen Schritte macht, um sein Ziel damit zu erreichen. Ein besonders gutes Beispiel dafür bietet das Kamera-Icon am Sperrscreen ab iOS6. Die doppelten Linien oben und unter dem Icon sollen dem User klar machen, das es sich hierbei nicht um ein normales Icon handelt sondern um eines mit einer besonderen Funktion dahinter. So kann man leicht herausfinden, dass man mit einer Geste nach oben, die Kamera öffnen kann. Unter iOS7 wurden diese doppelten Linien jedoch entfernt, wahrscheinlich weil die User die Geste nun schon gelernt haben, und iOS7 ja auf „Einfachheit“ setzt. Etwas schwierig könnte es jedoch bei neuen Nutzern werden, die auf Apple Produkte umsteigen. Manchmal ist Reduktion nicht das beste Mittel für gute UX.

Abläufe/Gesten verwenden, die der User bereits kennt

Hier ist es vor allem wichtig zuerst herauszufinden, wie etabliert manche Gesten oder Abläufe sind. Kennt man die Gesten/Abläufe nur aus einer kleinen eigenen App, so zählt diese dann nicht zu häufig verwendeten. Ein schönes Beispiel hier ist das „Ziehen zum Aktualisieren“, was man aus der Facebook, Gmail, Twitter und noch vielen weiteren Apps kennt.

Pull to refresh (dribble Mikael)

Inhalts-abhängiges Verstecken

Google Chrome unter iOS und Android sowie Safari unter iOS 7 haben das Inhalts-abhängige Verstecken der Statusbar sowie der Navigationbar eingeführt. Scrollt man also über eine Site so verschwindet die Navigation, bleibt man stehen erscheint sie wieder. Diese Verhalten soll den User auf den Inhalt fokussieren, sowie mehr Platz für den Inhalt schaffen.

Gesture-Interaction

Nachdem Statusbar und Footer sowie Icons natürlich eine gute Sache in mobilen Design sind und die Interaktionselemente auch immer eine entsprechende Größe haben sollen, um sie sinnvoll bedienen zu können, nehmen diese Elemente aber auch einen großen Platz des Screens ein. Da auf mobilen Endgeräten dieser Platz aber sehr kostbar ist, sollte man sich nicht nur auf diese Elemente beschränken, sondern auch etablierte Gesten verwenden, um Platz zu sparen und dem User eine gute User Experience zu bieten. So kann man sich beispielsweise für ein Flyout Menü, das man mit Swipe von rechts nach links öffnet entscheiden, anstatt eines überfüllten Navigationbars. Gute Beispiele dafür sind Facebook und Gmail. Man sollte also Mut dazu haben, solche Gesture Interactions zahlreich einzubauen. Sei es ein einfaches Tapping, ein doppeltes Tapping, ein Tap and Slide oder ein Drag & Drop. Instagram zum Beispiel hat als Core Feature ein doppeltes Tapping, um ein Bild zu liken. Hier geht es nicht mehr nur um das Design der einzelnen Seiten sondern um Fragen wie: Was passiert, wenn der User tapped, wie kann man das visualisieren? Wie lange dauert eine Transition, etc….?

Swipe Gestures (dribbble Vin Thomas)

Lernkurve der User

Jedes Mal wenn ein UI Element durch eine Geste ersetzt wird, steigt die Lernkurve für den Nutzer an. Aus diesem Grund sollte es visuelle Hinweise oder einen App Walktrough, der die wichtigsten Schritte erklärt, geben, um den User bei Erstbenutzung anzuleiten. Der User soll kleine Hinweise zum rechten Zeitpunkt bekommen, ohne sich davon gleich überfordert zu fühlen. Oftmals ist es schwer eine Balance zwischen diesen beiden Faktoren zu finden.

Konzeptionsprozess

Besonders schwierig ist hierbei der Konzeptions/Wireframing Prozess, da es schwer ist diese Interactionspattern nur in Wireframes und Scribbles darzustellen. Hier sind vorhandene After Effects (o.ä.) Kenntnisse von Vorteil, weil man hier schnell solche UX Effekte simulieren kann und die fertigen GIF’s auch zur Präsentation ausschicken kann ohne lange Erklärungen. Es gibt auch einige Onlinetools, die zur Unterstützung dienen können, wie z.B. PopApp, hier kann man schnell Papierprototypen interaktiv machen. Hier kann man nur empfehlen, schon vor der Implementierung mit solchen Prototypen Usability Tests zu machen, um herauszufinden ob die angedachten Gesten und Interaktionen auch wirklich Sinn machen.

Fazit

Jedes noch so kleine Interaction Pattern kann die User Experience um ein Vielfaches erhöhen. Man muss sich nur im Vorhinein überlegen, welche man sinnvoll anwenden kann und welche Overkill in einem Projekt wären. Besonders wichtig finden wir, dass man sich für ein Interaction Pattern entscheidet, weil es dem User eine bessere Experience bringen würde und nicht weil es einfach nur „fancy“ wirkt. Wer sich eingehend mit Touch Gesten beschäftigen will, sollte sich unbedingt den Touch Gesture Reference Guide von Luke Wroblewski näher ansehen.

The post Smart Interaction Patterns appeared first on Mobile USTP MKL.

Arduino Yun goes Cloud

Der Arduino Yun verfügt standartmäßig über einen WLAN Chip und Ethernet. Dies ermöglicht eine permanente Verbindung zum Internet. Weiters kann der Yun erstmals über WLAN programmiert werden. Vorgängermodelle mussten bislang via USB  programmiert werden.

Neben dem ATmega32u4 bekam der Arduino Yun einen Linino AR 9331 Mikroprozessor auf welchem eine MIPS Linux Distribution basierend auf Open WRT läuft. Diese Linux Distribution läuft unabhängig vom ATmega32u4 und regelt unter anderem den Zugriff zum on Board WLAN Chip und zum integrierten SD Card Modul. Da die alt bekannte Arduino Komponente des Boards unabhängig von der Yun spezifischen Linux Komponente arbeitet wird durch die Bridge, eine Kommunikationen zwischen diesen Komponenten ermöglicht. Die Bridge ermöglicht beispielsweise das Erstellen von umfangreichen API’s mit reinem Arduino Code, welche auf Features der Linux Komponente zugreifen können. Ebenso können durch die Integration von Temboo zahlreiche Informationen von öffentliche API’s ausgelesen werden und direkt im Arduino Sketch verwendet werden.

Durch den Yun wird die Arduino Welt mit der Linux Welt kombiniert. Ein klein wenig erinnert der Yun an den RasperryPi, welcher etwa 40€ kostet und somit im Vergleich zum Yun um rund 20€ günstiger ist. Der Arduino Yun kann aber durchaus bei Usern mit wenig Erfahrung im Umgang mit Linux Systemen punkten. Weiters kann der Arduino Yun als eigenständiger WLAN Hotspot verwendet werden. Dadurch wird beispielsweise eine direkte Kommunikation zwischen mobilen Devices und dem Arduino Yun über WLAN ermöglicht.

The post Arduino Yun appeared first on Mobile USTP MKL.