Die unsichtbare Rolltreppe
Auch abseits der digitalen Welt fallen einem ja manchmal faszinierende Details auf. Ein solches Erlebnis hatte ich neulich, als ich wieder einmal irgendwo in Köln auf eine leere Rolltreppe zusteuerte und dann selbstbewußt und ohne zu zögern die Fahrt aufwärts antrat. Dabei kam mir in den Sinn, dass ich in einer zeitlich unbestimmten Vergangenheit mit unbenutzten Rolltreppen nicht so selbstverständlich umging. Was war passiert?

Weiterlesen und kommentieren (2 Kommentare)
ESPN, Beispiel für eine Multi-Device-Strategie
Im Google Tech Talk über die Dos and Don’ts of Mobile Strategy weist Jason Grigsby (@grigs) auf die gute Userexperience der ESPN Website hin, die auch auf mobilen Endgeräten gut funktionieren soll. Wir haben uns die Mühe gemacht das ganze mal genauer unter die Lupe zu nehmen. Da wir nur die Userexperience der Website untersuchen, haben wir die App aussen vorgelassen.
Aarron: Do you consciously consider emotion in your design work?
Aral: Definitely. My apps are an extension of my character. I see them as authored works; as a conversation. There is a lot of myself in there and I want to have pleasurable, fun conversations with my users.
Most of our industry is still talking about features this and features that – the age of features is dead, we’re living in the age of user experience; _execution_ is everything.
We should be talking about building empathy into apps – does the app try to understand what the user is feeling and react accordingly?
In Avit, for example, if you have a slow internet connection, the little Manto blob gets ashamed, apologizes, even bursts into tears if it takes to long. Even though the problem isn’t with the app itself (slow Internet connection), the app tries to emphatize with the user. It doesn’t just display an indeterminate progress indicator that is emotionless and uncaring.
Aral Balkan im Interview mit Aarron Walter. Aral ist der Designer und Entwickler der iPhone-Twitter-App »Feathers« im Interview.
mobile User Experience erklärt auf einer Serviette
Kürzlich saß ich in einem Meeting zum mobilen Internet und brauchte etwas, das die Gedanken aus meinem letzten uxzentrisch-Feature über die Vor/Nachteile von mobilen Websites vs. nativen Apps visualisiert.
Hier im besten Back-Of-A-Napkin-Stil die Skizze:
Die Kernaussagen:
- Y-Achse: Die UX mobil kann positiv oder negativ sein. Besonders bei Plakaten fällt mir letzteres seit Marians Artikel immer häufiger auf.
- X-Achse: Die Nettobotschaft soll sein: Mobil heißt nicht gleich native App. Mit HTML kann man häufig sogar mehr erreichen.
- A / Nicht optimiert: Eine klare negative mobile UX haben Seiten, deren Kernfunktionen mobil nicht funktionieren. Beispielsweise durch Flash am iPhone mit fehlendem Alternativ-Content.
- B / Standard Website nutzbar: Meine Entscheidung für StayScout. Es ist nichts kaputt aber es ist auch nichts besonderes.
- C / Website mit mobilem Template: Nicht alle UseCases einer Website sind für mobile Szenarien gleich wichtig. Wir beginnen typischer Weise die Optimierung mit denen Teilen der Seite, die mobil am wichtigsten sind.
- D/E / besondere mobile UseCases: Hier denke ich an Barcode-Scannen, Geo-Lokalisierung und dergleichen. Szenarien also, die am Desktop keinen Sinn machen aber mobil ein besonderes gutes Erlebnis bieten. Ob dabei eine native App oder eine besonders fancy HTML-Seite gebaut wird, muss auf Basis der benötigten Feature und Vermarktung entschieden werden.
Kritik:
In besagtem Meeting hat diese Visualisierung gut funktioniert. Ein berechtigter Kritikpunkt ist, dass das Diagramm ausdrückt, dass D/E besser sei als C. Beispiel: Es gibt eine Produktsuche auf der Website. Diese wird von Vertrieblern vor Ort mobil ebenfalls genutzt. Ein mobiles Template für nur diesen Teil der Website, ist schon eine super UX. Für diese Vertriebler wäre es unter Umständen gar keine Verbesserung im Workflow, wenn eine optimierte Seite/App die Suche anhand von Handy-Fotos des Produkts durchführen würde… – Fazit: Man darf die Linie nach oben hier nicht so genau nehmen.
Update: Gerade finde ich einen Google Tech Talk, der sehr gut zu diesem und meinem letzten Post passt. Jason Grigsby illustriert an einer Reihe an guten Beispielen »DOs and DON‹Ts of Mobile Strategy«: Unter anderen die schlechte mobile Nutzbarkeit von Apple.com, die Notwendigkeit seine mobile Site und Desktop-Site miteinander richtig zu verknüpfen (Kommunikation, URL-Design,…) und sein Gedanke, dass der Wechsel von der mobilen zur Desktop-Site nicht im Frontend, sondern auf CMS-Ebene erfolgen sollte. Wer wenig Zeit hat, sollte zumindest die ersten 30 Minuten schauen :).
Kommentieren (6 Kommentare)
Nutzer verunsichern in zwei Sätzen
Wir weisen ja immer gerne daraufhin, dass auch Texte und Formulierungen ganz erheblich wichtig sind, wenn es darum geht, wie ein Nutzer eine Website wahrnimmt. Gerade bei Kaufprozessen und Produktbeschreibungen ist es wichtig vertrauensbildend und eindeutig zu sein. Hier mal wieder ein Gegenbeispiel, wie man es auf keinen Fall machen sollte (Hervorhebungen durch mich):
»[…] Diese Software verwendet Digital Rights Management-Software („DRM“). DRM kann die Anzahl der Installationen, die Sie mit dieser Software auf einem Computer durchführen können, und/oder die Anzahl der Computer, auf denen Sie die Software installieren können, begrenzen. Um ordnungsgemäß zu funktionieren, lädt DRM bestimmte Daten und Dateien auf Ihren Computer herunter, die deinstalliert werden können oder nicht, wenn Sie die Software deinstallieren.«
Ja, nach dieser Beschreibung bin ich mir völlig sicher, was ich da nun kaufe und was die Software mit meinem Rechner anstellt. Ironie Ende.
Gefunden bei Games for Windows von Microsoft. http://www.gamesforwindows.com/de-DE/Games/AgeofEmpiresIII/
UX-Tipp: Setzt den Fokus des Cursors beim Seitenaufruf ins Eingabefeld
Mit JavaScript (oder HTML5) kann man den Cursor beim Laden der Seite automatisch in ein Formularelement setzen. Das spart in vielen Fällen Zeit und führt gerade bei Vielnutzern zu einem guten Nutzungserlebnis.
Ein Beispiel aus dem Alltag: Wenn ich google.de aufrufe, kann ich direkt mein Suchworte eintippen und Enter drücken und schon bin ich auf der Suchergebnisseite. Dafür muss ich nicht ein Mal meine Hand von der Tastatur zur Maus bewegen. Dieses ideale Nutzungsverhalten, das mir bei jeder Suche laut KLM allein 1.9 Sekunden reine Bewegungszeit spart, ermöglicht uns Google, in dem sie beim Seitenaufruf den Fokus auf das Sucheingabefeld setzen.
Beispiel StayScout: Dank unseres OpenInnovation-Forums setzen wir in StayScout seit einigen Wochen ebenfalls bewusst den Fokus in Eingabefelder: Auf der Startseite können Nutzer direkt mit dem Tippen ihrer Anmeldedaten beginnen. Auf dem Dashboard und den Gruppen-Übersichtsseiten sitzt der Fokus im Suchformular (dem wichtigsten Formular der Seite).
Negativ-Beispiel Bit.ly: Wie schon Björn in Tamims uxzentrisch-Artikel zu Bit.ly richtig kritisiert hat: Warum eine Seite wie Bitly den Fokus nicht direkt auf das Eingabefeld legt, ist mir ein Rätsel!
Technik: Für StayScout verwende ich ein einfaches Inline-JavaScript, das ich in den Formularen einfüge, um den Fokus zu setzen. Aber wer schon stärker auf HTML5 setzen möchte, sollte sich diesen tollen Artikel »A Form of Madness« anschauen, in dem das neue HTML5-Attribut »autofocus« verwendet wird – inklusive einem JavaScript-Fallback, der sehr ähnlich aussieht wie mein Einzeiler hier.
<script type="text/javascript">$(function() { $("input#email").focus(); } );</script>
Nachteil: Es gibt einen Nachteil bei dieser Technik: Setzt man den Fokus in ein Eingabefeld, ändert sich damit auch automatisch der Modus für Tastenkürzel im Browser. Nutzer (wie ich), die gerne per Tastenkürzel den Back-Button nutzen (Alt + Pfeil nach Links), müssen jetzt erst aus dem Eingabefeld heraus klicken, damit der gewünschte Shortcut funktioniert.
Fazit: Gerade in Such- und Login-Szenarien und gerade bei Funktionen mit Applikationscharakter, werde ich zukünftig in meinen Konzepten gezielt den Fokus setzen (lassen). Diese Hilfe ist fast immer sinnvoll und wird noch viel zu selten genutzt – man darf es nur nicht übertreiben.
Kommentieren (2 Kommentare)
Suchergebnis als Liste und Karte: Yelp zieht den Publikumsjoker
Wer schon mal versucht hat, eine Suchergebnisliste mit einer Kartendarstellung zu kombinieren, in der die Treffer der Liste zusätzlich angezeigt werden, der wird sich auch diese Frage gestellt haben:
Was soll mit der Liste passieren, wenn der Nutzer den Kartenausschnitt verändert?
Das Problem begegnet uns seit der allgemeinen Verfügbarkeit von interaktiven Karten (vor allem dank Google Maps) immer häufiger. Ob wir bei Qype nach einem Café suchen oder bei einer Handelskette unserer Wahl nach einer Filiale, meist wird das Suchergebnis sowohl als Liste, als auch als Karte angezeigt. Oft beschäftigt man sich dann mit der Karte und stellt fest, dass man sich nicht exakt für den angezeigten Ausschnitt interessiert. Also verschiebt man den Kartenausschnitt, zoomt hinein oder hinaus.
Qype macht uns erfolgreich vor, was dann nicht passieren sollte: Nichts. (Beispiel gefällig? Pizza in Deutschland)
Die Antwort könnte nun lauten: Wir lassen einfach nach jedem Ändern die Suche aktualisieren, so dass der auf der Karte angezeigte Raum als geographische Eingrenzung gilt.
Die Frage ist aber: Erwarten die Nutzer so viel Cleverness, wenn sie bisher an vielen Stellen erlebt haben, dass das Suchergebnis einfach so bleibt wie es war, unabhängig von der Interaktion mit der Karte? Und wenn sie es erwarten, wollen sie es auch so? Oder wird das Neuladen der Suchergebnisliste, in der man sich dann immer wieder neu orientieren muss, sogar als Nachteil wahrgenommen?
Auch Yelp (das amerikanische Vorbild für Qype) muss diese Frage beantworten und zieht hierfür sozusagen den Publikumsjoker. Wenn man im Suchergebnis von Yelp die Kartenansicht verändert, erscheint beim ersten Mal eine Sprechblase mit dem Text:
Hey map mover! If you want to see new search results as you move the map, you can check this box.
Dazu werden direkt zwei bequeme Links »Yes, turn it on!« und »No, thanks« angeboten.

Wäre ich Yelp, würde ich längerfristig beobachten, in welchem Verhältnis die Antworten zueinander stehen. Wenn sich irgendwann eine signifikante Präferenz für die dynamische Anpassung des Suchergebnisses ergibt, könnte man das zum Anlass nehmen, diese Funktion standardmäßig zu aktivieren. Ob man weiterhin durch eine Sprechblase darauf hinweist, kann darüber hinaus entscheiden werden.
Ich halte das für einen guten Ansatz, um bei einer einfachen Entscheidungsmöglichkeit an eine breite Basis von Nutzermeinungen zu kommen. Insbesondere in der Implementierung von Yelp kommt man um die Beantwortung der Frage kaum herum, wenn man die Karte weiter nutzen will. Aber nicht zuletzt gibt man dem Nutzer auch das Gefühl, die User Experience ganz eng nach seinen individuellen Bedürfnissen zu gestalten.
Allerdings darf man das sicher nicht übertreiben. Joker hat man eben nur in einer begrenzten Anzahl zur Verfügung.
Kommentieren (3 Kommentare)
Kurz-Benchmark: »Anmelden« ist Standard, »Registrieren« dagegen nicht
Das Fazit vorweg: Wenn ihr einen Login und Sign up in einer Website integrieren wollt, empfiehlt sich für den Login von »Anmelden« und »Abmelden« für das Erstellen der User-Session zu sprechen. Diese Begriffe sind sehr weit verbreitet und sinnvoll. Für die Erstellung des Benutzers (Sign up) dagegen, hat sich kein eindeutiger Begriff durchgesetzt. Statt dessen ist es sinnvoll, die Registrierung im Kontext von Design und Copytext zu verlinken und die Einmaligkeit des Vorgangs hervorzuheben.
Das ist interessant, denn für andere Begriffe, Elemente und Positionen haben sich im Netz, schon klare Quasi-Standards herausgebildet. Zum Beispiel das Disketten-Symbol zum Speichern, das Haus als Link zur Startseite oder die Position des Logos mit Startseitenlink oben links auf der Website. Solche Standards sind für Konzepter und Designer natürlich praktisch, denn sie sparen uns, ständig grundsätzlich über jedes Detail nachzudenken.
Mit dieser Erwartungshaltung war ich auch Anfang des Jahres in die Entwicklung der Startseite für mein probono-Projekt stayscout.de gegangen. Ich war erstaunt, wie knifflig es ist, Anmelden und Registrieren absolut klar voneinander abzugrenzen. Als ich meine erste Version der Startseite in Steve-Krug-Usability-Tests getestet habe, sind zu viele Probanden darüber gestolpert.
Inspiriert durch den Artikel »Login/Logout vs Sign In/Sign Out vs Log in/Sign out – A short roundup«, der der gleichen Frage im englischsprachigen Raum nachgeht, habe ich zusammen mit Christina, die auch schon an unserem Artikel »4 Jahre Designevolution des YouTube Players« mitgeholfen hat (Danke!), einige große deutsche Webseiten verglichen.
Mein Fazit für den Login:
Weiterlesen und kommentieren (11 Kommentare)
4 Lösungen für Mobile am Beispiel einer mobilen Version von StayScout.de
StayScout.de ist ein junges, wachsendes Socialnetwork für Pfadfinder, das ich ehrenamtlich konzipiere und betreue. Wir sind vor ca. 5 Monaten online gegangen und konnten seitdem mehr als 5.500 ehemalige und aktive Pfadfinder aktivieren.
Seit langem schon denke ich auch darüber nach, wie sich StayScout im mobilen Umfeld (iPhone, Android-Phone u.ä.) platzieren sollte. Da diese Überlegungen auch auf andere Projekte angewendet werden können, teile ich sie hier gerne mit euch.
Unsere Ausgangsbasis dafür ist also eine bestehende Webapplikation/Community, die bisher nur für den Desktop-Browser optimiert wurde.
Optionen
Zuerst einmal stellt sich die Frage, welche Optionen wir überhaupt haben:
Weiterlesen und kommentieren (6 Kommentare)
Vergrößern





Die Auflösung und das Abstimmungsergebnis sind da!
Umfragen sind was tolles und hier dürft ihr mal wieder mitquizzen, nachdem unser Kaffeemühlenquiz so gut bei euch angekommen ist. Die Umfrage läuft bis zum 31.1.2011. Ach ja, Personen, die den Schalter aus der Anwendung kennen, sind von der Umfrage und Spielverderber-Kommentaren ausgeschlossen. Hier also das Interface im Schlaglicht:
Auflösung
Ihr habt gesprochen: Eine sehr deutliche Mehrheit ist der Ansicht, dass der Schalter anzeigt, dass er eingeschaltet ist. Was ich auch immer wieder tue, obwohl der GUI-Designer das wohl anders sah, denn der Schalter ist in diesem Zustand ausgeschaltet. Eingeschaltet sieht er so aus:

Zu finden ist der Schalter übrigens in der aktuellen Version des Synchronisation-Clients von HTC für das Desire.
Jetzt bleibt nur noch die Frage offen, warum sich der GUI-Designer sich so vertun konnte. Ein Problem hatte er offensichtlich schon identifziert, sonst wäre der eingeschaltete Zustand nicht so deutlich hervorgehoben worden. Aber die Lösung des Problems »Aus« und »An« zu unterscheiden ist sicherlich nicht die eleganteste und mir passiert es tatsächlich immer wieder, dass ich auf den Button klicke, um eine Synchronisierung auszuschalten nur um dann festzustellen, dass der Schalter ja schon aus war. Wenn ich etwas nur selten nutze merke ich mir solche feinen Details einfach nicht, sondern agiere unbewusst und gelernt scheint ja genau der andere Fall zu sein.
Kommentieren (6 Kommentare)