or: Delayed password masking with JavaScript.

Jakob Nielsen recently asked us to Stop Password Masking:

Usability suffers when users type in passwords and the only feedback they get is a row of bullets. Typically, masking passwords doesn’t even increase security, but it does cost you business due to login failures.

- useit.com/alertbox/passwords.html

He suggests using plain text input fields by default and offering a checkbox to have the passwords masked.

We do not completely go for the idea of typing passwords in plain text by default as there will be a loss of security! Not a technical one, but a user-driven one.

Password fields on iPhone/iPod touch

Of course Nielsen is right when he talks about users making more errors and feeling less confident when they can’t see what they’re typing while filling in forms. That may have been the reason why Apple developed implemented an alternative method on iPhone/iPod Touch: passwords get masked while typing but the last character in row is shown in plain text. Compared to common password fields on the web this method improves usability, not only on mobile devices. And concerning security risks you’ll probably need James Bond behind your back looking over your shoulders in order to let your password be captured.

So, this method looks to be a pretty good way of typing in passwords, and that is why tried to use it on web forms. It comes as a jQuery plugin which works unobtrusive. Non-JS users get the common masked password fields.

Copy & paste will work as usual. The only thing that will not work is: deleting/inserting single or multiple characters from the beginning/middle of the masked password string.
But, let’s face it, who will do that?

Live demo

Den ganzen Artikel lesen: »iPhone-like password fields using jQuery«

Das iPhone ist so geschickt im Umgang mit dem echten Web, dass unsere Website und das Blog in ihrer Struktur bereits ohne spezifische Anpassungsarbeiten recht gut angenommen wurden. Unsere Inhalte müssen (noch) nicht unbedingt mobil sein, deshalb hätte uns der Status Quo längst ausgereicht. Allerdings gab es eine kleine Anpassung zu machen, die in diesem Fall einen angenehmen zweiten Effekt hinterher gezogen hat:

Viewport-Breite im mobilen Safari

<meta name="viewport" content="width=641" />

(Siehe Safari HTML Reference)

Diese Angabe betrifft den mobilen Safari und schrumpft dessen Viewport auf 641 Pixel in der Breite, was wiederum dazu führt, dass die Methode »Resolution dependent layout« des Man in Blue per Event Listener zuckt und dem body eine CSS-Klasse vergibt, die wir in unseren Stylesheets für kleine Screens verwenden.
Das iPhone nimmt danach diese 641 Pixel breite Website und schrumpft sie auf 320 Pixel im Hochformat oder 480 Pixel im Querformat, je nachdem, wie man das Gerät hält.

Das Ergebnis sieht man in den Screenshots oben. Well done, dieser Zustand reicht uns nun wirklich für ein mobiles Web auf dem iPhone/iPod aus. Kein Bedarf, z.B. die etwas klein geratene Navigation anzupassen oder weiteres Feintuning zu machen.

Fazit?

Die Empfehlung für alle, die die Resolution-Methode des Man in Blue einsetzen — sehr sinnvoll übrigens, wir verwenden sie in vielen unserer Projekte als Alternative zu flüssigen Layouts — und kein Interesse daran haben, ihre Websites mit spezifischen Styles fürs iPhone zu versehen, mag also sein: Schaut mal, ob ihr über die Viewport-Breitenangabe nicht einen geschickteren Zoom erreichen könnt. Es ist nur eine Zeile im HTML, die iPhone-Nutzer glücklich machen kann.

Link: iPhone-FAQ

Wer an dieser Stelle weiter machen möchte und noch einen geeigneten Einstieg braucht, mag einen Blick auf Timos und Stephans Artikel »FAQ: Websites für das iPhone gestalten« werfen.

Opera hat ein erstes Video zum neuen Opera Mobile 9.5 veröffentlicht, der auf dem Mobile World Congress in Barcelona nächste Woche vorgestellt werden soll. Im Video wird demonstriert, wie Opera zukünftig Websites behandelt: er zoomt sie in gleicher/ähnlicher Form wie das iPhone.

In welcher Form betrifft das nun den Webdesigner?
Zur Diskussion im XING-Forum »Webdesign und Usability« bitte hier entlang.

Was ein Gerät kann, interessiert nur beim Quartettspiel. Usability betrifft das, was der Benutzer (machen) kann.

- Basic Thinking Blog, 2008

Auslöser: ein iPhone, das nichts kann. Andere Geräte, die mehr können.
Und überhaupt.