/ dashboard

Arbeit am ersten Eindruck

Wir haben ein bisschen gefeilt und die Seite überarbeitet, die einen neuen User direkt nach der Registrierung erwartet. Dabei haben wir versucht, drei wichtige Bereiche abzudecken und jene dahingehend zu verbessern, dass wir eben nicht nur Experten-User haben, sondern auch User, die eben erstmal was lernen wollen und müssen, und denen der Einstieg dafür leicht gemacht werden soll, ohne dabei aber den versierteren Usern Möglichkeiten zu nehmen.

Die Sache mit der E-Mail-Adresse

Wir machen ja bekanntlich durchaus ernst damit, keine persönlichen Daten zu erheben und damit auch keine E-Mail-Adresse. Es liegt aber auf der Hand, dass wir User durchaus auch mal initiativ kontaktieren müssen: Um sie zu informieren, wenn sie ihr Konto aufladen müssen, oder wenn ihr Speicherplatz knapp wird, oder wenn wir z.B. einen ihrer Mailaccounts oder auch ihre Website wegen einer Kompromittierung sperren müssen - ganz besonders aber dann, wenn User keinen Zugang mehr zum Dashboard haben und einen Passwort-Wiederherstellungslink brauchen. Unser Konzept war (und ist weiterhin) das der "primären E-Mail-Adresse" in der Form user@host.uberspace.de, die man sich zwar an eine externe Mailadresse weiterleiten lassen kann, aber eben auch via IMAP abrufen kann, ohne uns dazu irgendwelche Daten von sich bereitzustellen. User, die keine externe Mailadresse hinterlegt haben, haben wir bisher im Dashboard unter dem Punkt "Wichtig" mit dem Titel "Wir erreichen dich noch nicht!" darauf hingewiesen, dass sie ihre primäre Mailadresse abrufen sollten (der Hinweis verschwindet automatisch, wenn die Mailbox in den letzten 30 Tagen einmal abgerufen wurde). Dennoch gibt es im Support leider immer wieder Fälle, wo User ihren Zugang zum Dashboard verloren haben und dann konsterniert feststellen, dass wir tatsächlich keine hellseherischen Fähigkeiten haben und eben wirklich nicht überprüfen können, wem ein Account gehört - eben eine der unpraktischeren Seiten der Datensparsamkeit: Wer keine Daten angibt, was ja legitim ist, sollte dann eben auch wirklich, wirklich sein Passwort nicht vergessen.

Interessanterweise sind es aller Erfahrung nach aber eben in der Regel nicht die User, denen jene Datensparsamkeit besonders wichtig ist (denen ist dann auch klar, dass wir ihnen bei Verlust der Zugangsdaten keinen Zugang mehr verschaffen können), sondern eben Leute, die im Eifer des Gefechts schlicht keine Mailadresse angegeben haben, aber auch versäumt haben, das primäre Mailkonto via IMAP einzurichten, und auch den Hinweis im Dashboard geflissentlich ignoriert haben.

Wir haben daher beschlossen, die Option, eine (externe) E-Mail-Adresse zu hinterlegen, deutlich prominenter anzubieten, nämlich direkt als erstes. Das ist natürlich eine Gratwanderung, denn wir möchten natürlich die User, die eben keine Mailadresse preisgeben wollen, auch nicht dadurch vor den Kopf stoßen, dass es unmittelbar nach der Registrierung so aussieht, als wenn wir dann doch Daten haben wollten. Wir versuchen das textlich so abzufedern, dass wir einerseits kurz deutlich machen, warum wir einen User per E-Mail erreichen müssen, und andererseits darauf hinweisen, dass die Angabe optional ist - mit dem expliziten Hinweis darauf, dass man dann IMAP nutzen sollte und wir ansonsten keine Möglichkeit haben, einen Recovery-Link bei Zugangsverlust zuzusenden.

Die Sache mit dem Passwort

Bisher wurde man direkt nach der Registrierung mit einer Seite begrüßt, die alternativ dazu aufforderte, ein Passwort zu setzen oder eine OpenID zu hinterlegen. Grundgedanke dahinter war, dass OpenID eigentlich der überlegene Anmeldemechanismus ist und wir ermöglichen wollen, Accounts vollständig passwortfrei anzulegen. Mit Blick auf die Statistik wird aber deutlich, dass im derzeitigen Accountbestand - obwohl bisher beide Möglichkeiten gleichwertig nebeneinander präsentiert wurden - rund 85% aller Accounts ein Passwort, aber nur rund 25% aller Accounts eine oder mehrere OpenIDs haben (Accounts können auch beides haben, daher kommen da über 100% bei raus). Gleichzeitig gibt es eine nicht unerhebliche Menge von Fällen, wo User aus welchen Gründen auch immer sich "erstmal nur den Usernamen reservieren wollten", sprich, sich einen Account geklickt haben, und dann ... den Browser geschlossen haben, ohne sich darüber im Klaren zu sein, dass sie ohne Angabe irgendeiner Authentifizierungstechnik sich ja nie wieder als jener User ausweisen können werden.

Wir haben daher nun einen etwas abgewandelten Default. Der besteht darin, dass wir automatisch ein gutes (langes) Passwort generieren und dies in einer Form vorschlagen, die es dem Browser - oder einem entsprechenden Plugin - ermöglicht, das Passwort auf Wunsch des Users zu speichern. Denn machen wir uns nichts vor: Ein gutes Passwort, das in einem - vorzugsweise verschlüsselten - Passwortspeicher hinterlegt wird, der sich in den Händen des Users befindet, ist besser, als wenn der User sich ein schlechtes Passwort aus den Fingern saugt, oder ein Passwort nimmt, das er schon an zig anderen Stellen verwendet, oder ein Passwort generiert, das zwar gut ist, aber das er dann kurz darauf vergisst. Der Vorschlag ist selbstverständlich optional - er kann bearbeitet oder auch ganz entfernt werden; uns ist aber wichtig, dass ein User, der nach dem Prinzip tl;dr verfährt, beim Klick auf "Make it so!" vom Browser angeboten bekommt, das Passwort zu speichern, und damit dann eine funktionale Login-Möglichkeit hat, auch wenn er das Passwort nie gesehen oder eingegeben hat.

Die Sache mit dem Speichern des Passworts war nebenbei ein überraschend großer Krampf. Zum einen beinhaltet das HTML-Formular ja kein Feld für einen Usernamen, sondern nur für ein Passwort, denn der Username steht hier ja bereits fest - damit der Browser das Passwort sinnvoll speichern kann, muss er es aber ja kennen. In der Regel verwenden Browser dafür das <input>-Feld vor dem Passwort-Feld - das muss aber auch type=text haben; type=hidden tut's nicht. Wir wollen aber das Feld mit dem Usernamen eben gar nicht anzeigen, sondern nur dem Browser übermitteln - also wird es via CSS mit display: none; ausgeblendet. Das Passwort-Feld selbst ist dann noch eine Nummer ärgerlicher, denn an dieser Stelle, wo lediglich ein ganz neues Passwort gesetzt werden soll, möchten wir entsprechend, dass der Browser es nicht schon automatisch vorausfüllt, z.B. mit dem Passwort eines anderen Uberspaces, den man mal eingerichtet hat. Dafür ist eigentlich autocomplete="off" da - aber Chrome 34+ hat nun beschlossenermaßen eingeführt, diese Einstellung nicht mehr zu berücksichtigen und Passwortfelder immer vorauszufüllen, wenn es das für sinnvoll hält, und auch immer eine Speicherung anzubieten, unter Verweis auf The Priority of Constituencies - was im Grunde auch sinnvoll ist, aber unserem Vorhaben zuwiderläuft, Usern lieber ein gutes, automatisch generiertes Passwort vorzuschlagen (das sie dann ggf. noch ändern können), statt sie zu zwingen, sich eins auszudenken, was dann potentiell schlechter wäre.

Wir "missbrauchen" daher an dieser Stelle die Eigenschaft readonly="readonly", um dem Browser klarzumachen, dass das von uns via value="<randomstring>" vorgeschlagene Passwort eben nicht durch irgendwas aus seinem magischen Passwortspeicher übergangen werden soll. Sobald das Feld dann angewählt wird, entfernt ein onFocus-Handler den Read-Only-Status, und das Feld kann frei bearbeitet werden. Der Browser bietet dann beim Absenden an, das Passwort zu speichern, wenn der User dies denn wünscht.

Entfernt der User explizit das vorgeschlagene Passwort, wird er anschließend auf die bisherige Seite geleitet, die ihm ermöglicht, eine OpenID zu hinterlegen. Das Dashboard ist wie gehabt erst dann vollständig nutzbar, wenn ein Passwort gesetzt oder eine OpenID hinterlegt wurde. Dass OpenID als Alternative zum Passwort zur Verfügung steht, wird natürlich schon auf der Willkommens-Seite klar erwähnt.

Die Sache mit dem Preis

Hier geht's nicht mal um eine Einstellung, sondern nur um Kommunikation. Die Sache ist die: In der Vergangenheit hatten neu angelegte Accounts einen undefinierten Wunschpreis, mit der Folge, dass jene Accounts dann mit dem symbolischen Mindestpreis von 1 Euro abgerechnet wurden. Neu ist, dass wir einen Wunschpreis von 5 Euro vorschlagen, der selbstverständlich wie bisher frei angepasst und auch wieder runter bis auf 1 Euro reduziert werden kann. Diese Änderung betrifft nur neu angelegte Accounts: Wer bisher keinen Wunschpreis eingestellt hatte und daher nur den Mindest-Euro bezahlt, bei dem bleibt das auch weiterhin so, bis er seinen Wunschpreis anpasst.

In unserer Accountdatenbank ist gut unterscheidbar, ob sich User dazu entschieden haben, nur den Mindestpreis zu bezahlen, oder ob User sich einfach gar nicht für einen bestimmten Preis entschieden haben. Von den Usern, die derzeit faktisch nur den Mindestpreis zahlen, hat das etwa die Hälfte explizit so eingestellt - die andere Hälfte hingegen hat sich einfach schlicht nie für einen bestimmten Preis entschieden, zahlt also eigentlich nur deshalb den Mindestpreis, weil sie der Aufforderung "Entscheide selbst, wieviel du bezahlen möchtest" nie nachgekommen sind.

Wir machen keinen Hehl daraus, dass wir uns wünschen, dass ein größerer Anteil von Usern mehr als den Mindestpreis bezahlt, der ja eben nur ein symbolischer und nicht kostendeckender Preis ist, der mit den Einnahmen von Usern, die für ihren Account mehr bezahlen, querfinanziert wird. Dabei haben wir weniger diejenigen im Auge, die den Mindestpreis explizit eingestellt haben, denn bei jenen gehen wir davon aus, dass sie das aus Gründen so getan haben - auch wenn wir hier gerne jeden ermutigen möchten, ob die Gründe, die dazu geführt haben, auch heute noch bestehen: Wer zum Beispiel während des Studiums jeden Euro zweimal umdrehen musste oder wer arbeitslos war und nun aber einen festen Job hat, kann sich überlegen, ob er seine finanziell hinzugewonnene Freiheit nicht vielleicht auch dafür aufwenden möchte, künftigen Usern mit geringeren Mitteln zu ermöglichen, bei uns zu hosten, so wie man selbst diese Möglichkeit mal in Anspruch genommen hat. Gleiches gilt natürlich auch für Firmen, die z.B. mal eine ziemliche Flaute durchlitten haben und froh waren, da zumindest ihre Hostingkosten runterschrauben zu können, und die sich nun aber wieder in besserem Fahrwasser befinden.

Wir haben aber diejenigen im Fokus, die sich der freien Preiswahl aus schlichter Untätigkeit entziehen - also die tl;dr-Fraktion, die keinen Blick auf uberspace.de/prices geworfen hat, wo wir unser Modell und auch unsere Kosten beschreiben. Dort kommunizieren wir immer schon, dass wir uns einen monatlichen Preis von 5-10 Euro wünschen. Mit unserem künftigen Default-Preis von 5 Euro bleiben wir also am unteren Rand unserer immer schon kommunizierten Preisempfehlung. Damit dies insbesondere für User, die sich ggf. auch schon mehrere Uberspaces geklickt haben, keine böse Überraschung wird, wird die neue Default-Preis-Einstellung ganz explizit nach der Registrierung angezeigt. Sie soll zusätzlich motivieren, sich mit unserem Preismodell vertraut zu machen.

Ebenfalls keinen Hehl machen wir daraus, dass wir uns von diesem Vorschlag einen gewissen psychologischen Effekt versprechen. Nicht zuletzt aus vielen Supportanfragen, die sich um den Themenkreis "Was soll ich denn zahlen?" drehen, war zu entnehmen, dass viele User den symbolischen Mindest-Euro sozusagen als Einkaufskostenpreis ansehen und in deren Vorstellung jeder Euro, den sie mehr zahlen, bei uns direkt die goldene Glocke erklingen lässt, auch wenn wir an verschiedenen Stellen inzwischen deutlicher als früher kommunizieren, dass es sich beim Mindest-Euro um einen querfinanzierten und nicht kostendeckenden Preis handelt und es bei einem Preis unter 5 Euro schwer wird, unsere Kosten zu decken. Unser Gedanke ist, dass es User, die einen bereits vorgeschlagenen mittleren Preis aktiv reduzieren müssen, deutlicher spüren lässt, dass sie sich damit in einen Bereich begeben, der unsere Kosten möglicherweise nicht mehr deckt und sie damit für sich in Anspruch nehmen, ihren Account von anderen Usern querfinanzieren zu lassen - statt umgekehrt einen User, der im bisherigen Dashboard initiativ z.B. 3 Euro einstellt, mit dem Gefühl zu belohnen "Ich habe sogar den dreifachen Mindestpreis eingestellt, also muss da jetzt richtig die Kasse klingeln", obwohl er damit gerade erst so langsam in den Bereich kommt, bei dem wir zumindest nichts mehr drauflegen.

Natürlich ist das Preisthema ein heißes Eisen, und der Preisvorschlag von 5 Euro in erster Linie ein Experiment, von dem wir möglicherweise auch wieder abkehren, wenn wir den Eindruck haben, dass es User zu sehr "in den falschen Hals kriegen". Wir möchten auch klarstellen, dass das Motiv für die Einführung keineswegs bedeutet, dass es uns finanziell schlecht ginge und wir deshalb nochmal an den Portemonnaies unserer User rütteln wollen. Uberspace.de steht in keiner Weise auf der Kippe! Ein wesentlicher Aspekt des freien Preismodells ist aber eben, dass sich User für einen Preis entscheiden, der wie bisher auch über oder unter unserer Empfehlung liegen kann, und wir möchten, dass User, die aus welchen Gründen auch immer diese Entscheidung nicht treffen, dann zumindest einen mittleren Preis zahlen, der unser Modell schlicht mitträgt - nicht zuletzt auch aus Gründen der Fairness gegenüber den Usern, die von sich aus einen noch höheren Preis bezahlen und damit ja eben gerade auch finanziell schlechter gestellte User mitfinanzieren wollen und nicht unbedingt die, die einfach nicht dazu kommen oder vergessen, einen Preis zu wählen.