Jakob Nielson rides again

Just had this one come through the wire:

Jakob Nielsen’s Alertbox, June 23, 2009: 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.

This sounds like Nielson kicking up publicity. This is shorter than his normal articles and he hasn’t backed this one up by mentioning his latest rounds of usability tests. He’s often got really good points, but this is one that I have issue with.

Nielson has forgotten that the reason password masking exists is if you type it out but don’t submit the form right away, then it won’t be on the screen for a long length of time for passers-by to ‘shoulder-surf’. The form could be really really long and/or you might be a really slow typist.

Padlocks and deadbolts keep honest people honest. The same goes for password masking.

Not to mention that password masking is visual shorthand reminder for the personal habits of “you should remember what you right in this box, cos even you won’t see it” and “no-one else should see this but you”. If we removed this ‘tell’, what would become of the culture of ‘protect your password’?

Think of where, other than web sites, that password masks get used. ATMs, EFTPOS machines, computer software, the Operating System uses it. Western culture is conditioned to this design pattern, and I speculate that the only people who have trouble remembering passwords are the ones who were born before 1980.

I guess a compromise would be to have the field in plain text when it has focus, switching to a password mask on blur…? Not a difficult solution.

IE6 denial message for Momentile.com

Momentile.

You can see sketches and a bit of the process on my website.

UPDATE:
There have been many requests to use this image on other websites, so I’ve decided to release it under a Creative Commons license. You are free to reuse the image on your own website as long as credit is given and linked back to RobotJohnny.com.

For prints, contact me directly.”>

IE6 denial message for Momentile.com
Uploaded to Flickr by John Martz.

Go home, IE6!

New Zealand TWTR SMS Roundup

This is a work-in-progress timeline of all the news surrounding Vodafone New Zealand and Telecom New Zealand announcing their support for Twitter SMS through the shortcode TWTR (8987).

Any news, just leave a comment including any and all links to public sources and I’ll do my best to keep this up to date.

The truth about iPhone Emoji

There has been a few posts going around the internet talking about the enabling of Japanese emoji on the iPhone. I was curious, and after enabling and experimenting, here’s the truth about emoji on iPhones.

Once enabled, you get access to a staggering amount of icons! To be exact, 469 symbols, ranging from smiley faces to weather icons, flags, animal faces, (clean) hand gestures, and much more. Here’s what they all look like, screen-grabbed right on my iPhone after I put them all in an email. FYI, scaling has occurred, these are not perfect.

Diagram listing all Emoji for iPhone and iPod Touch v2.2.1

Diagram listing all Emoji for iPhone v2.2.1

The trick here is that while these icons look fantastic on the iPhone, when sent in SMS text messages and emails, the beautiful pictures you see above are sent as Unicode characters, as they came through to me via my Gmail:

These characters are part of the Private Use Area of Unicode. Which is why, if you’re viewing this page on a browser not running on an iDevice, you will see a whole slew of question marks or boxes with little letters in them, followed by the copyright, registered trademark and trademark symbols.

Doing some more research, it turns out a bug has been filed on OpenRadar outlining how Apple’s implementation isn’t even that compatible with NTT DoCoMo’s de-facto standard on ‘Pictographs’, even though it would seem they’ve implemented every single icon in that standard.

I’m not expert, but it seems that pre-Unicode, Japan standardised on Shift-JIS, a modification to ASCII that would allow the storage and display of the Japanese Hiragana and Katakana characters that make up Japanese written language. This was pressed forward into the design and manufacture of the Japanese handsets, and even into the operator’s networks, and for the time being, this means both NTT DoCoMo, the biggest telco in Japan, and Softbank, the telco serving iPhones in Japan.

NTT DoCoMo created the defacto standard on emoji on Japanese mobile phones, and have outlined the character encodings for both Shift-JIS and Unicode. Every handset in Japan supports this standard.

When the iPhone was first released, it apparently was criticised in Japan for not supporting the sending and receiving of emoji glyphs. Eventually Apple got around to it, but according to rdar://6402446, iPhone Firmware 2.2 currently implements the encoding of emoji using Unicode characters in the private use area, but not the same private use characters as the NTT DoCoMo Pictographs standard.

So it would seem that, to cut a long story short, Apple’s emoji are directly incompatible with every other handset in the world.

According to Apple, Softbank doesn’t even do translation for iPhone SMS to other Japanese handsets. It will however, translate emoji in emails, but only if you have a Softbank email address and SIM.

And because the rest of the world doesn’t have handsets that work with emoji, that’s why Apple only enables the emoji keyboard for phones with Softbank SIMs.

Still, it wouldn’t be too difficult to write a script to support emoji characters in your web app, supporting both NTT DoCoMo Unicode and Apple Emoji Unicode. Apple have done a nice job with their icons. Interesting times.

Sources: