Updated every Monday, Wednesday and Friday
22Jul2009

A Solution To E-Mail Validation

Whenever it comes time to validate an email address, I always end up going through the same exact process.

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.

in Programming, Usability — by Gregory
8Jul2009

Masking Passwords?

Recently, usability expert Jakob Nielsen made the case that we need to stop password masking. After a few days of mulling over the suggestion, here is what I came up with.

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.

in Usability — by Gregory

Website by Gregory Koberger
518.339.4652 | gkoberger@gmail.com
gkoberger.net | blog | about gregory