A few weeks ago, I was talking to Eric Willis and he said something I really liked:

Everything that’s easy isn’t if you do a good job.

Take a look at Please Call My Phone.  I used Twilio (my super-easy-to-use obsession), which did most of the heavy lifting.  In fact, I got a “prototype” working in about ten minutes.  So, then, why did it take me a whole day to get the finished product out the door?

It’s the little things that take the time.  The Pareto principle plays a big part in it- 20% of the work always does seem to take up at least 80% of the time.

My original, ten minute version had just a text box that called a phone.  Every little tweak and change took time, though.  Each little addition (scheduling, the design, better error handling, link to my site and Twilio link, JavaScript enhancements, etc) added up quickly.

There are a lot of hidden time sinks, too.  Take a look at scheduling, for example- little things like handling time zones took a ton of time, and nobody will even notice.

People notice when something is done wrong, not when it is done right.

So, remember- if what you’re doing is quick and easy, you’re probably not doing a good enough job.

Lesson #2 and Lesson #3 will be posted soon.

I start with a simple regular expression- for example, this:

(.+)@[\w]+\.[a-zA-Z]+

It works great for a majority of email addresses- however, it’s not perfect. It lets through a lot of invalid email addresses. For example, “.name@something.a” is considered a valid email address by this regular expression. So, let’s take a few steps to correct this:

([-a-zA-Z0-9])([-.a-zA-Z0-9])*@[\w]+\.[a-zA-Z]{2,5}

A bit better, right? But what about valid email addresses, such as john+smith@mail.something.com and $A12345@example.mobile? Same goes for the seemingly invalid email addresses such as “Abc\@def”@example.com. But, alas, these are all valid.

No, I’m not going to even attempt a regex that accommodates these. Others have tried. However, it’s futile; email validation ends up either being too strict with what it rejects, or too liberal with what it lets through. Or, in many cases- both.

But for the sake of argument, let’s assume we do create a regex that follows the RFC perfectly. That still doesn’t stop people from getting through with something like youre.bad@validation.com. Sure, we could even go as far as checking to make sure it’s a real, actual email address. But even then, there is no stopping johnsmith@gmail.com- an email address that surely exists, however probably is not owned by the person filling out the form.

Depressing, huh?

Well, what about this one:

(.+)@(.+)

Here’s the secret. This is not a programming problem- it’s a usability issue. If the user benefits from giving you their real email address, they will. If not, you should not be asking for an email address.

It’s that simple, really. Just make sure they at least attempted an email address (otherwise, they may mix up the fields), and throw in a good reason to hand it over- and you will never have a problem.

Thanks to Chancey Matthews for reminding me checking for an @ symbol is good enough, and haacked.com for reading the RTC so I didn’t have to.

Who’s Job Is It?

In his post, Nielsen implied that the unmasking of passwords should be put into effect by the web developers.  However, his suggestions would work better if implemented at the browser level.  This way, users could easily and globally toggle the feature on and off, and decide for themselves if they want it.  (And, of course, there’s already a Firefox plugin that makes the whole argument moot- users who prefer this functionality can already choose to use it.)

Usability Concerns

Consistency is one of the most basic usability principles.  If users know that the same command or the same action will always have the same effect, they will feel more confident in using the system[...]

-Usability Engineering by Jakob Nielsen, p 132

Nielsen himself claims that consistency is important- so how can users feel confident, if some password boxes protect their passwords while others do not?  Not only is this an argument for it being a feature in browsers rather than websites, it’s an argument why it’s dangerous for web developers to even attempt it.  It would be one thing if all passwords were unmasked- however, Nielsen is calling for it’s implementation on a site-by-site basis.

Breaks Browers

By removing the type=”password” from the input element, we make it so that browsers won’t be able to tell the submitted field is a password- effectively breaking the “Save password” feature that saves us from having to type in passwords constantly.  And, even if this didn’t break the feature- would you want your saved password popping up in plain text every time you hit a site with a login box?  (Of course, saved passwords could be shown masked- but this is again a browser-level feature, as well as defeating the purpose of plain text passwords.)

Perceived Security

It’s true that masking makes no no difference in real security, however Nielsen has completely ignored perceived security.  Users don’t understand that the only thing masked passwords protect them from are people physically standing behind them- having their password show up in plain text will no doubt result in many users believing anyone anywhere can nab it.

Icon

As made obvious by the press this suggestion has gotten, people listen when Jakob Nielsen talks.  If he was serious about people implementing this, he should have attached some sort of pseudo-standards to his post.  Had he created small masked/unmasked icons, he could have done for this what the little orange icon did for RSS.  People could have seen the icon, and known right away that the password field was unmasked (and known that clicking the icon would turn masking on). Rather, anyone who implements it now has to individually explain to the users what’s going on, and how to toggle it.

Testing

One thing that always impressed me about UseIt.com was the research that went into every alert.  He always seems to have statistics to back up everything he said.  In this post, there was none.  Had he found 20 people with various degrees of computer know-how, asked them to register for a mock site, and recorded their reactions?  Then we could be confident one way or another.  He’s forgotten that one of the basic principles of the field of usability is that even the experts can’t be confident until they observe actual users.

My Conclusion

We have to forgive him a little, though- his perspective is from that of usability only, and nobody can disagree that it is easier to type a password when you can see it.  That being said, I would argue that his view of this was too narrow; if he did indeed look at it from a broader context, he didn’t let it show in his post.  Even from a usability standpoint, it’s easy to see how this could be a potential problem.  He answered a very black-and-white question- “Is it easier to type when you can see what you’re typing?”- and the answer is, of course, yes.  While he does spend a paragraph conceding, almost reluctantly, that “sometimes security should win,” overall he stays away from exploring the ramifications of removing password masking- writing it off as Geocities-era “legacy design.”

He is right about one thing, though- those reset buttons need to go.