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.

Man könnte natürlich, wie Luis von Ahn im Google-Talk »Human Computation«, das Gute darin sehen: Menschen verbringen weltweit bestimmt tausende Stunden damit, Captchas auszufüllen – diese Zeit muss man für Gutes nutzen wie das digitalisieren von Büchern über sein reCaptcha-Projekt.

Für mich macht das das Ausfüllen von Captchas aber nur wenig besser. Aber es gibt noch etwas, das noch mehr nervt als Captchas einmal auszufüllen:
Captchas mehrmals ausfüllen müssen, weil aufgrund einer Meldung das Fomular nicht abgeschickt wurde.

Dabei ist die Lösung wieder sehr einfach und Twitter macht es uns vor:

Ryan Carson hat diesen Fall entdeckt und schön mit Screenshots in seinem Blog dokumentiert: »How to Increase Sign-ups with Easier Captchas«.

Man könnte jetzt noch Fragen, ob dieser Aufwand gerechtfertigt ist, wo doch schon die JavaScript-Validierung im Formular selbst alle Fehler abfängt. Dem würde ich auch zustimmen für ein so einfaches Formular – leider können aber nicht alle Fehler direkt abgefangen werden, weil beispielsweise nur Serverseitig überpfüft werden darf, ob die eingetragene E-Mail-Adresse schon von einem anderen Account verwendet wird.

Mich interessiert jetzt:

Habt ihr diesen Umgang mit Captchas schon anderswo beobachtet?

Oder kennt ihr weitere Formulare, deren UX auf ähnliche Weise verbessert wurde?