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.
You can see sketches and a bit of the process on my website.
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.
Go home, IE6!
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).
- @vodafonenz: Now official – Twitter coming soon to a TXT near you: [url] at 9:16 AM May 12th
- Vodafone NZ’s press release says they will use the shortcode TWTR (8987) and says “The service will launch in the coming weeks.”
- Twitter have yet to post on their blog that they now support New Zealand. I speculate that they will not do so until the service is actually live to customers.
- @telecomnz: We have partnered with Twitter to bring you Twitter to your Mobile via TXT msg from May 29! at ~3:00 PM May 12th
- @telecomnz: Telecom Mobile Customers from May 29 can msg 8987 (TWTR) to update their twitter account or receive tweets via TXT at ~3:00 PM May 12th
- Yet, Telecom’s media department doesn’t back it up: no press release has been made at Telecom’s Media Releases page as of yet.
- National Business Review fails at journalism and provides more proof that old media just doesn’t get it: copy/pastes from Vodafone’s press release, forgets that Twitter SMS is available in the USA, UK and India and may have just missed Twitter’s news of adding Canada, adds word ‘exclusive’: Vodafone scores exclusive Twitter deal
- @nzben: @TelecomNZ Is that a piggy-back on Vodafone’s connection, or a separate agreement? at ~2:00 PM May 12th
- @telecomnz: @nzben a seperate agreement with Twitter. at ~2:00 PM May 12th
- Google News: “vodafone new zealand” twitter shows that other old-media sources FAIL and think the deal is exclusive, including NetGuide.
- Twitter announces official support to New Zealand SMS, with update support for all, but Twitter to handset delivery for Vodafone NZ customers, with other networks, and Australia support to follow!
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.
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.
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.