Amazon.de – Statt des Bewertungs-Elements zeigt Amazon bei eigenen Rezensionen einen 7-zeiligen Hilfetext an:

Warum gibt es an dieser Stelle keine Buttons zum Abstimmen? Kunden können nur über die Rezensionen anderer, aber nicht über ihre eigenen Rezensionen abstimmen. Aus diesem Grund erscheinen die Buttons für eine Abstimmung nur, wenn Sie die von anderen verfassten Rezensionen ansehen.

Was haltet ihr davon? Ist das die beste Lösung für dieses Problem?

Um sich ohne ein Maßband sich die Größe eines Bild besser vorzustellen, zeigt talentarena.de die Bildgröße im Verhältnis zu einer Person, sobald der Nutzer eine Größe ausgewählt hat.

TNW: If you had to give a software designer some basic advice on how to take what they’ve designed as a user interface and make sure that they’re applying real-world rules to it, what’s the best way for them to anticipate the needs of users?

Andy: Well, feedback. I believe it’s an iterative process. It’s never good enough, you can always make it better. So, you have to get as many users as you can as quickly as you can. Even to this day, like what I’m working on today, the second I have my feature working, the first thing I’ll do, I’ll turn to the guy next to me, “Hey what do you think of this?”

So, you’ve just got to be hungry for feedback, but you also have to be open to it. One thing I learned from Bill Atkinsonwhen I was working on the Macintosh is you really can’t get attached to code. The code that you’ve written could be an impediment to the code that should be written. You have to be willing to throw things away when you have the better idea.

I think it’s really the main difference between the good designer and the great designer is as soon as you see a better way, you have to be willing to go with it, even though it could be very painful to throw away what took you two months to develop. Just because you’ve done that, doesn’t mean it’s the way you should do it. Often each iteration of the design is a stepping stone to the next one.

Aus einem ansonsten meiner Meinung nach nicht weiter interessanten Interview zwischen thenextweb.com und Andy Hertzfeld, der als der Designer hinter Goolge+ gesehen wird. Via @tamimat.

Steve Krug ist ein hervorragender Autor. Seine Bücher sind präzise, eingänglich, gut anzuwenden und dabei noch dünn und sehr nett geschrieben. Das gilt sowohl für sein erstes Buch »Don't Make Me Think« als auch für dessen Nachfolger »Rocket Surgery Made Easy«. Während Krug im ersten Buch Usability- und Webprobleme in der Breite betrachtet, stellt der Folgeband eine direkt umsetzbare Anleitung für Discout Usability-Tests dar – und genau dafür möchte ich euch in diesem Artikel begeistern.

Schritt 1: Begeistern

Wenn ihr noch nicht überzeugt seid, ob Steve Krug euch etwas zu sagen hat, schaut euch diesen Vortrag von 2008 an. In einer Stunde erklärt Steve nicht nur anschaulich, wie unglaublich es ist, dass viele Firmen immer noch nicht aktiv daran arbeiten die Usability-Mängel ihrer Produkte zu beheben, er stellt euch die Kern-Thesen seines Buchs vor und – besonders beeindruckend – führt live einen Usabilitytest durch.

Übrigens: Auch Ryan Singer von 37signals empfiehlt dieses Video: I can’t think of a better intro to the essential points of usability than this presentation…

Schritt 2: Lesen

Im Vergleich zum Video mag das eigentliche Lesen des Buches auf den ersten Blick unspannender erscheinen – Aber es sind nur 140 Seiten, die sich sich sowohl in Englisch als auch in Deutsch sehr gut lesen… Und wie gesagt: Krug schreibt sehr nett :)

In jedem Fall solltet ihr in Kapitel 2 Steves Bitte folgen, das Lesen unterbrechen und euch sein Demo-Video (Download) anschauen:

Schritt 3: Loslegen

Spätestens nach der Buchlektüre dürftet ihr das Gefühl haben »Das kann ich auch!«. Das ist gut, denn jetzt heißt es loslegen und Praxiserfahrung sammeln. Die ersten Tests, die ihr macht, werden unpräzise und etwas unsauber sein. Bedenkt das bei eurer Auswertung, lasst euch aber nicht davon abschrecken.

Eine Hürde gilt es aber zu nehmen: Die Dokumente sind alle in Englisch. Dank uxzentrisch muss euch aber auch das nicht abhalten: Wir haben den Testleitfaden ins Deutsche übersetzt.

Eine Geschichte aus der Praxis: Ende 2009 war meine Pfadfinder-Ehemaligen-Community StayScout gerade in die Betaphase gestartet. Ich bin ehrenamtlich neben dem Produkt Management besonders für das Konzept verantwortlich. In dieser Zeit habe ich mehrere Usability-Tests im Krug-Stil durchgeführt. Mein Testleitfaden sah dabei sehr einfach aus: Ich wollte herausfinden, wie Pfadfinder sich zurecht finden, die die Plattform noch nicht kennen. Sowohl auf der öffentlichen Seite (verstehen sie, worum es geht?) als nach der Anmeldung. Meine Vorbereitungszeit war daher minimal – insbesondere, weil ich zuerst einmal Pfadfinder aus meinem direktem Umfeld angesprochen habe, die zur Zielgruppe passen. Das Ergebnis war für mich aber unbezahlbar wertvoll. Es hat mich beispielsweise darin bestätigt, dass unsere öffentliche Startseite zu dieser Zeit schon gut erklärte, worum es geht, dass aber die Usability des Registrieren/Anmelden-Formulars schlecht war. Wir haben dann in schnellen, kleinen Schritten an diesem Thema gearbeitet. Augenöffnend war für mich auch, daran erinnert zu werden, wie betriebsblind man wird: Mehrere Nutzer wollte auf der Startseite ihren Pfadfinder-Stamm suchen. Also klicken sie in das nächstbeste Suchfeld und geben den Stammesnamen ein. Dass sie dabei den Titel des Suchfelds »Freunde finden« (oder »Mitglieder-Suche«) übersehen, bin ich schon von anderen Usability-Tests gewöhnt. Dass aber meine Suchergebnisseite überhaupt keine Hilfe bot, um diesen Fehlerfall abzufangen, hatte ich nicht mehr im Blick. Noch nicht mal die Überschrift »Freunde finden« fand sich auf der Suchergebnisseite wieder. Ein weiteres Problem, dass sich schnell und unkompliziert lösen ließ.
Fazit: Es sind genau solche qualitativen Erfahrungen, die eine Webseite stark verbessern und die man am schnellsten und unkompliziertesten über kurze Usabilty Tests erlebt.

Schritt 4: Weitere Links

Glückwunsch, nach dem Schauen, Lesen und Ausprobieren dürftet ihr vom großen Potential kurzer, qualitativer Usability Tests überzeugt sein. Hier sind noch ein paar Link-Empfehlungen, die euch nach euren ersten Tests helfen, noch besser zu werden und die Botschaft zu verbreiten:

• 3 Things Steve Krug Didn’t Tell You About Usability Testing von George Saines – Steve Krug antwortet selbst in den Kommentaren
• Meine Präsentation vom UXcamp Europe 2010 in Berlin (Slideshare) – Ohne eine Tonspur nicht sehr aussagekräftig, inspiriert euch aber vielleicht auf dem nächsten Webmontag die Discout-Usability-Testing-Botschaft zu verbreiten.
• Nicht häufig genug wiederholen kann man Krugs Botschaft, nach einem Usability-Test nur so wenig wie gerade nötig zu ändern: Lazy Person's Guide to a Better World - UX Lisbon 2010 – Aus Steve Krugs eigenem Slideshare-Account
• An Interview With Steve Krug: Everyone should do usability testing mit Susan Weinschenk (Autorin von »Neuro Web Design: What makes them click?«) – Wird euch zwar nicht viel Neues sagen, gehört aber in die Krug-Fan-Favoritenliste

Ich hoffe, diese Videos und Links haben euch motiviert und inspiriert.

Bitte teilt eure Erfahrunge, Meinunge und Link-Empfehlungen in den Kommentaren. – Danke

PS: Die Amazon-Links unterstützen greenanysite.com

Kickstarter-Guidelines – Das Label der Nutzungsbedingungen-Checkbox wechselt von Rot auf Grün. Gleichzeitig wird der Button aktiv.

Screenshot Rot (PNG), Screenshot Grün (PNG)

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.

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:

Für eine deutsche Zielgruppe als Anmelden/Abmelden der gute Weg.
Die Begriffe werden am häufigsten verwendet und dazu meist auch in der Kombination Anmelden/Abmelden. Alternativ wird auch Einloggen/Ausloggen und manchmal gemixte Versionen gerne verwendet.

Mein Fazit für den Sign up:

Die Aufforderung zur Nutzer-Konto-Erstellung sollte im Kontext betrachtet werden um eine Abgrenzung zum »Anmelden« zu schaffen. Dabei ist es wichtig, die Einmaligkeit des Vorgangs hervorheben.

• Es fällt auf, dass es keinen einheitlichen Standard gibt.
• Auch »Registrieren« setzt sich nicht durch, ist aber in Variationen der am häufigsten vorkommende Begriff.
• Viele Seiten verwenden ihre eigene Sprache, eigene Begriffe/Varianten.
• Seiten verwenden häufig sehr kontext-bezogenes Wording
• Die Hälfte versucht dabei die Einmaligkeit des Vorgangs hervorzuheben (»Erstmalig«, »Neu hier?«, …)

Die Daten aus unserer Recherche:

(Die Tabelle kann gerne ergänzt werden!)

Für meinen StayScout-Anwendungsfall war ich inzwischen übrigens schon auf die gleiche Lösung gekommen. Ich spreche von »Anmelden« und »Jetzt Mitglied werden«, wobei ich letzteres im Kontext noch verstärke, zum Beispiel durch »Für neue Besucher«.

Welche Erfahrungen habt ihr gemacht mit der Unterscheidung zwischen Anmelden und Registrieren?

PS: In der Schweiz sieht das übrigens anders aus. Dort spricht man gerne von »Login« statt »Anmelden«.

PS2: Wie auch schon Tanin in dem oben verlinkten Artikel konnte ich auch keine Systematik bei den URLs finden. Hier herrscht fröhliches Chaos :-).

Ich habe eine Kaffeemühle, die grundsätzlich eine recht einfache Funktion erfüllt: Kaffee mahlen. Zwei Dinge kann ich einstellen: die Menge, die pro Druck auf einen Taster gemahlen wird, und den Mahlgrad.

Das Foto zeigt das Einstellrad für den Mahlgrad. Auf dem Einstellrad befinden sich Zahlen von 1 bis 17. Die aktuelle Einstellung ist in etwa bei 8, die Zahlen 1 bis 7 sind auf der linken Seite des Rades, die von 9 bis 17 auf der rechten. Nun meine Frage:

In welche Richtung muss man das Rad drehen, um feineren Kaffee zu bekommen?

Nein, das ist kein Gewinnspiel. Ich frage mich nur, ob die Designer meiner Kaffeemühle mit ihrem Design Klarheit geschaffen haben. Auflösung folgt.

Update von Montag, 27. September 2010

Ihr habt gesprochen. Insgesamt wurden 52 Stimmen abgegeben. So habt ihr abgestimmt:

• Nach links (im Uhrzeigersinn): 25 Stimmen (48 %)
• Nach rechts (gegen den Uhrzeigersinn): 27 Stimmen: (52 %)

Klarheit sieht anders aus, würde ich sagen. Vom Ergebnis der Abstimmung ausgehend hätte man gar keine Piktogramme und Nummerierung gebraucht und hätte vermutlich ein ähnliches Ergebnis zu erzielen.

Tatsächlich verhält es sich so: wer will, dass der Kaffee feiner gemahlen wird, muss das Rad nach rechts drehen. Dann erscheinen auf dem Rad die niedrigeren Zahlen.

Aber wie hätte man es besser machen können?

Dabei ist es von vielen Plattformen bekannt, dass bei dieser Anordnung auch die Beschriftung der Checkbox oder des Radio-Buttons anklickbar ist.

Auch HTML gibt uns die Möglichkeit, das entsprechend umzusetzen. Alle modernen Browser interpretieren das <label>-Tag so, dass der Inhalt dieses Tags als Klickfläche dient. Dadurch reicht es meist schon, eine Checkbox bzw. einen Radiobutton einfach in ein Label-Tag zu »verpacken«.

Der Vorteil durch die vergrößerte Klickfläche vergrößert sich, je länger die Beschriftung wird. Das gilt insbesondere dann, wenn Beschriftungen mehrzeilig sind und sich dadurch nicht nur die Breite, sondern auch die Höhe des Klickziels vergrößert.

Wer es noch nicht kennt und gerne auf die wissenschaftliche Ebene wechseln möchte: Hier geht es um Fitt’s Law.

Auf mobilen Geräten mit Touchscreen ist die Größe des Klickziels besonders wichtig, denn dort zeigt der Nutzer nicht mit einem kleinen, spitzen Mauszeiger auf das Kontrollelement, sondern mit dem Finger. Und der ist in der Regel größer als die eigentliche Checkbox bzw. der Radio-Button (»fat finger problem«).

iPhone und Android sehen daher standardmäßig in vor, dass in Formularen genau ein Formularelement pro Zeile steht. Der Nutzer kann die gesamte Zeile antippen und damit ein Element auswählen bzw. aktivieren/deaktivieren. Die nachstehende Abbildung zeigt einen Screenshot von Android 2.1. Links ist der am Gerät angezeigte Zustand zu sehen. Rechts ist die gesamte klickbare Fläsche des Checkbox-Elements hervorgehoben.

Diese Anordnung ist beim iPhone und bei Android – anders als in den Weiten des Web – ziemlich konsequent umgesetzt worden, so dass Ausnahmen hier besonders unerwartet sind.

Eine solche Ausnahme ist die Einstellungen-Seite von Foursquare, die ausgerechnet direkt über den Einstellungen-Dialog aus der Android-Applikation verlinkt wird (foursquare.com/settings).

Wer hier eine Option aktivieren oder deaktivieren möchte, muss – je nach aktuellem Zoom im Browser – ziemlich geschickt sein oder viel Glück haben. Denn die Beschriftungen sind leider nicht als <label> anklickbar. Und um die Schwierigkeit noch etwas zu erhöhen hat man noch zusätzliche Hyperlinks direkt unter die Checkboxen gesetzt (Hype-Thema »Game-Design« in der Formulargestaltung?).

Also: <label> nicht vergessen!

Vor einem Jahr war Yahoo! unter den 20 meistbesuchten Webseiten Deutschlands die einzige Ausnahme, bei der – zumindest in Teilen – besuchte Hyperlinks als solche zu erkennen waren. Nun, ein Jahr später, haben wir eine neue Bestandsaufnahme gemacht. Dabei haben wir die 50 deutschen Sites mit den meisten Besuchen (nach IVW-Ausweisung) und international die 50 meist besuchten Sites (nach Alexa) betrachtet.

Das Ergebnis: Unter den deutschen Sites hat sich nach einem weiteren Jahr praktisch nichts verändert. Gerade einmal 3 von 50 Sites nutzten die Möglichkeit, besuchte Links zu kennzeichnen. Das sind yahoo.de , heise.de und ciao.de.

Bei den internationalen TOP 50 sieht das schon anders aus. Die nachstehende Tabelle zeigt alle Sites, bei denen wir besuchte Hyperlinks von anderen Links unterscheiden konnten. Die komplette Liste ist als Google-Docs-Tabelle einsehbar.

Hierbei kristallisiert sich ein ganz anderes Bild heraus. Zur Recherchezeit waren 2 Seiten offline. Berücksichtigen wir zudem die Doppelnennungen von google (11. mal) und yahoo (2. mal) mit  unterschiedlichen Domainendungen, und  zählen diese nur einmal auf, so kennzeichnen immer noch 16 von 35 unterschiedlichen Webseiten besuchte Links aus.

Jetzt stellt sich mir die Frage, warum der Unterschied  zwischen deutschen und internationalen Seiten so groß ist? Hinken deutsche Seiten den internationalen hinterher? Oder sind deutsche Webseiten ein Vorreiter für diese Tendenz?

Auch nächstes Jahr werden wir wieder überprüfen, ob die Deutschen sich dann (zumindest bei diesem Detail) mehr um Usability bemühen. Es bleibt spannend!

Aber was kann man für die ca. 8% der erwachsenen männlichen Bevölkerung (Frauen deutlich weniger, die glücklichen) tun, die mit einer Farbfehlsichtigkeit zu kämpfen haben? Den Klassiker »Kontrast verstärken«, der alles in mehr oder weniger heftiges Schwarz-Weiss oder ähnliche (oft unschönes) umwandelt?

Vielleicht kann aber schon im Grunddesign ein paar Dinge berücksichtigen, sodass solch drastische Maßnahmen wie Schwarz-Weiss-Darstellung nur für einen Bruchteil der Farbfehlsichtigen nötig sind. Denn auch Menschen mit einer Farbfehlsichtigkeit, werden trotz allem eine schön gestaltete Website als positiver empfinden. Zumal das Einschalten einer Funktion wie »Kontrast verstärken« durchaus die Botschaft kommuniziert: »Dein Problem war uns nicht wichtig genug, um es grundlegend zu berücksichtigen.«

Ein schönes Tool, um zumindest einen groben Eindruck von (Farb-)Fehlsichtigkeiten zu bekommen ist Chrometric – What you see is not what everyone gets. Eine kleine aber feine und kostenlose Air-App, die wichtige Fehlsichtigkeiten oder Darstellungsprobleme simuliert, wie hier zu sehen:

Glücklicherweise schneidet »uxzentrisch« in den Simulationen ganz brauchbar ab, auch wenn wir die Barrierearmut nicht wirklich in der Diskussion hatten – zumindest nicht jenseits einer allgemein guten Lesbarkeit. Doch vielleicht genügt das ja auch schon?

Und was macht ihr?

Wie berücksichtigt ihr Farbfehlsichtigkeiten bei der Konzeption von Websites? Welche Lösungen habt ihr bisher gefunden und umgesetzt? Wie geht man mit tobenden Grafikdesignern um, deren wunderschönes aber unleserliches Design gerade zerpflückt wurde? Welche anderen Tools in diesem Bereich kennt ihr, die erwähnenswert sind?

Verivox.de zeigt, wo diese nicht so optimal steht:

(Video bei Youtube)

Das klassische Label (a) steht vor dem Textfeld und hat hoffentlich auch einen Label-Tag, so dass man es anklicken kann.

Das nett gemeinte (b) zeigt den Labeltext innerhalb des Textfelds, löscht einem dan aber die eigene Eingabe, wenn man erneut in das Textfeld klickt.

Das macht das gute (c) besser, in dem es auch den Fall abdeckt, bei dem Nutzer mit und ohne eigener Eingabe mehrfach in die Textfelder klicken und vielleicht sogar farblich zwischen Hilfetext (Grau) und Eingabe (Rot) unterscheidet.

Bisher war ich damit auch glücklich und zufrieden. Bis 37signals jetzt noch einen drauf setzt und für die Anmeldemaske in ihrem Launchpad zwei sehr schöne Details umsetzt und damit (d) sehr gut ist:

• Der Hilfetext verschwindet erst bei der Zeicheneingabe. Nicht wie sonst üblich beim Klick in das Textfeld.
• Sie verwenden eine zweiten helleren Grauton dafür um zu signalisieren, dass jetzt getippt werden kann.

Natürlich machen sie auch all die anderen Details richtig, die ich oben erwähnt habe.

Hier kommt das ganze als kurzer Screencast. Und wer jetzt nochmal sehen möchte, wo genau die Unterschiede sind zum heute sonst üblichen Verhalten (c), dem empfehle ich den A List Apart Artikel zu diesem Thema mit  seiner Demo und dieses jQuery Plugin.

(vergrößern)

Kürzlich habe ich mit The Unarchiver ein Archiv entpackt. Offensichtlich gab es dabei ein Problem bei der Interpretation von Sonderzeichen wie dem Ö. Wie geht The Unarchiver damit um? Anstatt mir eine technisch-abstrakte Auswahl von Zeichensätzen anzubieten, zeigt er hübsch eingerückt daneben direkt eine Vorschau des problematischen Namens. Hervorragend!

Besonders überrascht von diesem Verhalten war ich, weil The Unarchiver eigentlich eine kleine, kostenlose Software ist, die kaum GUI verwendet sondern einfach ohne Dialog bei Klick ein Archiv entpackt.

Aber was nützt mir das Wissen das ein ein Bus im Stau steht? Soll ich mich nach Alternativen umschauen? Aber woran mache ich das fest? Bedeutet Stau, dass der Bus viel später kommt? Ist es so schlimm, dass die KVB nicht wagt zu vermuten, wann er endlich eintrifft? Man kann es schlecht einschätzen, die Information »Stau« ist reichlich nutzlos.

Dann doch lieber wieder die alte Angabe der erwarteten Ankunftszeit und einfach ein paar Minuten draufschlagen. Damit kann ich was anfangen.

Eye tracking is a technology that allows you to see and record what a person is looking at, and for how long. (…)
It’s a pretty interesting technology, one of the benefits being that you don’t have to rely on what people SAY they are looking at, but can collect the data directly. (…)
We underestimate the effect our instructions have on where someone looks. (…)
In research by Yarbus, people were shown this picture, and then given different instructions of what to think about while looking at the picture. Below are the eye gaze patterns matched with the instructions that people were given.

Weitere Beispiele findet ihr in Susans Blogpost.

Susans Fazit aus dieser Studie:

• Auch wenn Eyetracking objektiver ist als andere Methoden, hängt das Untersuchungsergebnis entscheident von den Fragestellungen ab.
• Die Fragen für eine Eyetracking Studie sind besonders wichtig und alle Probanden müssen exakt die gleiche Frage gestellt bekommen.
• Da Nutzer nie mit den gleichen Zielen zweimal auf eine Website kommen, wird sich auch ihre Blickführung immer unterscheiden.

Übrigens: Beim UX Book Club im Januar in Köln werden wir Susan Weinschenk Buch besprechen. Kommt gerne vorbei!

Diese Regel wurde schon 2001 in einer Studie anschaulich visualisiert.

Trotzdem ist es aus Usabilitysicht sinnvoll, in der Nähe des Logos noch einen textlichen Indikator zu platzieren, der die Funktion des Logos als Startseitenlink bestätigt.

Auf der anderen Seite möchte man das aus gestalterischen Gründen ungerne machen.

Amazon, Facebook und Zappos haben eine sehr gute Lösung gefunden um beide Ziele zu vereinen: Sie zeigen die Zusatzinformation nur, solange die Maus über dem Logo ist:

Ein besonderes Lob muss man dabei Amazon und Zappos aussprechen: Sie zeigen diese Effekt auch nur an, wenn man sich auf einer Detailseite befindet. Facebook dagegen lässt den Nutzer auch auf der Homepage zurück auf die Homepage gehen…

Als Jakob Nielsen kürzlich behauptete, alle Passwortfelder sollten unmaskiert sein, gingen Welle des Jubels und der Entrüstung gleichermaßen durch die Blogo- und Twittersphäre. Und egal ob Nielsen mit seiner Aussage recht hat, er hat uns alle nachdenken lassen über ein Interface-Pattern, das wir in dieser Form schon immer kennen und das bisher viel zu wenige in Frage gestellt haben.

Ich möchte heute ein anderes bekanntes Pattern in Frage stellen:

Registrieren vs. Anmelden

Nahezu jede Webapplikation erfordert heutzutage einen Benutzeraccount. Und meistens muss man sich zuerst Registrieren (d.h. einen Account einrichten), bevor man sich mit diesem Account anmelden kann.

Die Differenzierung zwischen der Anmeldung und der Registrierung ist dabei eine rein technische und dem Nutzer eigentlich egal. Er will nur rein. Hinzu kommen weitere Probleme:

• Wording: »Login«, »Anmelden«, »Registrieren«, »neu hier?«, »Wiederkehrer«… – das alles sind Begriffe, die nur verständlich sind, weil wir gelernt haben, sie mit Aktionen zu verknüpfen.
• Positionierung: Was ist wichtiger auf der Startseite, die Anmeldung oder die Registrierung? XING beispielsweise legt auf der Startseite den Fokus auf die Anmeldung, Facebook dagegen auf die Registrierung.

Lösungsansatz

Akademisch gesehen, ist die die Registrierung nur ein Fehlerfall der Anmeldung: Der Nutzer versucht sich anzumelden, das System erkennt, dass es diese Anmeldedaten noch nicht kennt und bittet um die Vervollständigung der Registrierung.
Es besteht kein Grund, den Nutzer auf der Startseite die Entscheidung abzuverlangen, ob er wohl schon eine Benutzerkonto hat oder sich jetzt registireren muss Für ihn geht es nur, darum rein zu kommen.

»Ja, aber…« sagen meine Kollegen jetzt. Und ich stimme ihnen dabei auch zu: Das ist erstmal eine sehr akademisch-theoretische Lösungsansatz und ich bin selbst unsicher, ob er wirklich funktioniert oder gar besser ist. Aber das sollte uns ja nicht davon abhalten, ihn zu durchdenken, nicht wahr? Also, was denkt ihr?

Wireframe:

Vergrößern

Hier die original Balsamiq-Datei zum downloaden, erweitern und kopieren (CC-by).

Pro Argumente:

• Ein Formular auf der Startseite, das sowohl registrierte als auch nicht registrierte Nutzer abholt.
• Der Nutzer muss nicht mehr wissen, ob er schon einen Account hat oder nicht.

Contra Argumente:

• Das klassische Anmelden-Registrieren-Pattern ist gelernt und wird erwartet. Diese Erwartungshaltung zu brechen lenkt mehr ab, als die Frage nach dem richtigen Prozess.
• Man muss das Wording auf der Startseite ändern. Der Button darf nicht mehr anmelden oder registrieren lauten, sondern »weiter gehts«, »los gehts«, …
• Man muss serverseitig einen Schutz gegen das Validieren von E-Mail-Adresse einbauen. Denn diese Lösung ist nur etwas für Webapplikationen, die sich erlauben wollen, konkrete Fehlermeldungen anzuzeigen (›Benutzername unbekannt‹ und ›Passwort falsch‹ vs. ›Benutzername oder Passwort falsch‹).

Alternativen?

Die eingangs beschriebenen Probleme hat übrigens nicht jede Webseite. Der Dienst Screenr.com beispielsweise braucht nur einen »Anmelden mit Twitter«-Button. Er profitiert davon, dass er aus Nutzersicht ohnehin kein Benutzerprofil speichert. Nur, wenn der Nutzer einen Twitteraccount hat, kann er sich dort anmelden.

Denkt man diese Lösung weiter, kann es gut sein, dass sich das hier diskutierte Problem in ein paar Jahren ohnehin von selbst erledigt: Dann werden nur noch einige wenige Dienste wie Google eine Registrierung benötigen. Alle nutzen dann das »Anmelden mit…«-Pattern (Stichwort: OpenID und oAuth) um ihre Besucher zu authentifizieren.

Der Workflow, den er dabei skizziert, ist einfach und gefällt mir gut: Beim Einfügen fragt Balsamiq nach dem Dateinamen, unter dem das Bild gespeichert werden soll und bindet es dann wie jedes andere Bild ein. Ein schneller, einfacher Prozess der normalerweise in Webapplikationen häufig ein weiteres Programm zum Speichern des Fotos oder aber ein Spezialprogramm zum Erstellen des Screenshots bedarf, mindestens aber vieler überflüssiger Klicks beim (meist temporären) Speichern und Löschen der Screenshot-Datei.

Aus Usability-, Protuktivitäts-, und User Experience-Sicht kann hier unstreitbar viel gewonnen werden.

Wie kommt es dann, dass es immer noch keine Lösungen zum Einfügen von Bildern in Webapplikationen gibt? Zum Beispiel beim Schreiben von Artikeln in einem Weblog-Editor, wie ich ihn gerade im WordPress-Backend nutze? Oder in Google Docs und Google Mail.

Neben Balsamiq kenne ich nur Jira (Issue-Tracking-System) als Onlinetool, dass über ein Java-Plugin erlaubt, Bilder direkt aus der Zwischenablage einzufügen. Mich selbst treibt dieser Mangel immer wieder zurück zu Weblog-Editoren wie Blogdesk – Ein Workaround der zunehmend ungeeignet wird, da sich die Weblogsysteme schneller Weiterentwickeln als ihre Schnittstellen und die Software, die darauf aufbaut. Abgesehen davon, dass Tools wie Blogdesk immer nur für genau eine Webapplikation eine Lösung sind.

Es ist schon erstaunlich, dass wir inzwischen Webapplikationen haben, die mit zwei Klicks Screencapture unseres Desktops erstellen, aber Alltagsaufgaben wie »Copy & Paste« von Bildern noch nicht anwenderfreundlich gelöst sind.

Kennt ihr andere Tools, die das Einfügen von Bildern direkt in den Browser ermöglichen?

Wie müsste das Problem aus eurer Sicht gelöst werden? Browsersupport für Image-pasting?

»Our participants were faster, more successful, less error-prone, and more satisfied when they used the forms with inline validation. Eye-tracking also showed that they ›fixated‹ on the forms with inline validation less frequently and for less time, which shows that they found these forms easier to process visually than the forms without inline validation.«

Luke Wroblewski in seinem neuen A List Apart-Artikel »Inline Validation in Web Forms«

Er beschreibt darin anschaulich und ausführlich seine Usabilitylabor-gestützten Nutzerbeobachtungen im Umgang mit einem Webformular.

Lukes Buch »Web Form Design: Filling in the Blanks« aber vor allem die verschiedenen Artikel, die er dazu im Netz publiziert hat, sind eine sehr nützliche Referenz und Argumentationshilfe wenn Formulare konzipiert und gestaltet werden müssen.