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

Features

1. Doesn’t need any HTML modification as it finds password fields by type.
2. Unobtrusive: Non-JS users get the common masked password fields.
3. Supports copy & paste.
4. Options: Interval, delay, replacement character, prefix, debug mode.

Instructions

It’s very simple.

1. Just load jQuery, of course ;-).
2. Load the Plugin
3. and then initialize dPassword.

You are done!

<script type="text/javascript" src="/js/jquery.js"></script>
<script type="text/javascript" src="/js/jQuery.dPassword.js"></script>
<script type="text/javascript">
  $(document).ready( function() {
    $('input:password').dPassword();
  });
</script>

There are some options you might want to configure:

• interval
  Time in msec the scripts checks for newly entered characters.
• duration
  Delay in msec of converting the last entered character.
• replacement
  The character to be replaced, for unicode characters use the following format: %u25CF
  You may check these ressources: Overview of unicode characters or a more comprehensive overview.
• prefix
  This is the prefix of the newsly generated elements. Default is password_.
• debug
  For debugging issues. You need FireBug enabled!

Example:

<script type="text/javascript" src="/js/jquery.js"></script>
<script type="text/javascript" src="/js/jQuery.dPassword.js"></script>
<script type="text/javascript">
  $(document).ready( function() {
    $('input:password').dPassword({
      duration: 2000,
      prefix: 'my_'
    });
  });
</script>

Known Issues

1. Adding/deleting chars from the middle doesn’t work. Works at the end of the password only.
2. View will not follow cursor if input field is too small.
3. If #id based CSS styles are assigned, these styles will not be taken over.

Download

Project page with SVN repository: http://code.google.com/p/dpassword/
JS download: jQuery.dPassword.js
Complete ZIP download: dpassword.zip

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.

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.