Archive for the 'standards' Category

Password masking, and the difference between usability and user experience

Recently Jakob Nielsen recommended removing the little black dots that come up when you type in a password, and having your password come up in clear text instead.  He had some pretty good reasons for recommending this including:

  • Increased password security
  • Mobile usability
  • Error prevention

However, Nielsen also recognises that there are some situations and some passwords (for example banking passwords) where the security outweighs usability. You can read more in his article about the matter here.

Responses to his idea ran the gamut from wholehearted agreement (by a security expert no less)  through tentative disagreement to pretty strong disagreement.

There has been some comment on the sociotechnical aspects of password masking, including using masking as a reminder to users that they ought to keep their passwords secure, and a discussion about the reasons why many people are uncomfortable with masking.

Other responses suggested solutions to the problem, including displaying only the most recently typed character (like on the iPhone), and giving the user the option to unmask (rather than mask) a password.

I completely understand the usability reasons for unmasking passwords, and I agree with what Jakob Nielsen is saying, up to a point.  My preferred option, out of all the ones suggested though, is the last option, where a user can choose to unmask a password, and my reasons for this are a common context of password use, which I will illustrate with an example:

I’ve just finished a large group project to launch a new library catalogue; we did a lot of collaborative work, and spent a lot of time using computers that projected onto a large screen.  We frequently read email to remember discussions we’d had about the system, manage links, manage to-do lists and generally remind us what was going on (this is a really common way–PDF of storing “stuff” in one’s headspace), and the system had components we had to log into.  We were logging into and out of systems left and right, and always on a big screen. I work at an institution with a single sign-on–this means your password for the HR system where you manage your payroll and salary, your library password, your email password–they’re all the same thing (bear in mind, single sign-on is good for security, users are less likely to use bad passwords if they only have to remember a few of them). Even more frequently than we had these meetings, two or more of us would be clustered around a desk testing some aspect of the new library system that required a log in or out.

I can’t imagne that either of these scenarios is uncommon in the workplace, meaning that in Nielsen’s world users would all share their passwords.  Similarly, I imgaine it is fairly common in social contexts, particularly with shared hosues and computers. Sharing passwords is undesirable at best, and I don’t need to describe how much damage one bad apple in a workplace could do under such circumstances–and it would be extremely difficult to track down who that person was, and what they had done when a large group of individuals all knew each others’ passwords.  Not only that, with single sign on passwords provide access to confeidential and sensitive information, including (at my institition) email, leave details, salary details and library details.

Just like with Nielsen’s solution, having characters disappear one character at a time essentially clear-texts your password to anyone who happens to be present, leaving the only options to balance security and usability as the check-box options.  Nielsen suggests that the checkbox be “hide”, but I disagree.  The social implications of a “hide” box are that you have to make the decision to hide your password from your colleagues or loved ones or friends in front of them, which sets up the potential for interesting dynamics around trust in professional and personal social interactions.  My preference would be an “unhide” box that implies it is simply natural to keep one’s password hidden–thereby avoiding any issues of trust in situations where otherwhise passwords might be shared.

The problem with Nielsen’s approach is that it is a purist usability approach.  If all we cared about was making systems more usable, absolutely it would be right to expose everyone’s pasword, and have the option to hide it occassionally as necessary.  This could lead to extremely uncomfortable social situations in both the work and personal spheres, though and as such is poor design of user experience, which takes the context of use into account–and I can’t recommend something that would so frequently lead to bad user experience.

So, what do you think?  Should we all show each other our passwords?

How to deal with ‘too much information’: where should we put search refinement facets?

Swinburne Library is in the process of making some changes; we’re replacing our library system with a fancy new one, and as the user-experience-person-in-situ it is up to me to make suggestions for the search and discovery interface our users will see.  Some of those decisions I will blog about here, and search facet placement is one of them.

Search facets are one of the search tools that I think will be most instrumental in making stuff easier to find (and the OCLC report (PDF) on user expectations vs. librarian expectations suggests library users feel the same way). Facets are the little categories you see on search interfaces that let you narrow down your search results to things that are more relevant to you; they started out in tools with well-defined metadata (like eBay and Amazon, and even some of the newer library systems) and they are slowly working their way into searches with less-well-defined metadata, like Google.

With anything new like this, though, you have to figure out where in the search interface to put it.  So far I have seen facets placed to the left of search results:

facets to the left of search results

to the right of search results:

Facets to the right

and below search results:

Facets below search results

At Swinburne, we talked a bit about facet placement, and in all likelihood ours will be on the left.

So, what are the arguments for and against each position?

  • Facets below search results: When facets are below search results, they don’t distract the user when they are viewing search results, which is a good thing.  However, given that the vast majority of users don’t scroll all the way down, and only look at the first couple of pages of search results (and they look more at the first results on these pages), placing facets below search result is pretty likely to mean that users don’t see them or use them.  This likelihood is reinforced by the fact that this is a significantly uncommon location for facets, so users won’t think to look for them here.
  • Facets to the right of search results: From a user-centred-design purist standpoint, in my opinion the right-hand position for facets is probably the best in an interface where the language is read from left to right.  This position means that user see search result first, and then facets if the search results don’t contain anything immediately useful.  Given the number of commonly used interfaces that put facets on the left, however, this could be a risky proposal.
  • Facets to the left of search results: This is what Google have gone with (possibly because their advertising is on the right).  It is also common in other commonly-used information seeking interfaces, such as eBay, Dymocks (in Australia) and Amazon (for the US and the UK). Use of these interfaces will train users to look to the left for facets; and it would seem that at least a small sample of users have already developed this preference for left-hand search facets.

Swinburne has a real opportunity with this project to provide a search interface for our users that is not “slow motion search, typical library“; however, to do this we must pay as much attention as we can to our users.  Putting the search facets to the left is just one of the decisions we will make with the users in mind, and I hope to blog about more in the future.

Not that helpful

I was filling in an online form the other day and I got to the anti-spam device. This is what I saw:

If I literally “can’t read” then the way out isn’t going to help me much. On the other hand if I am (for example) red-green colourblind (as many people are) I may have trouble reading the text they presented here regardless of my reading abilities. I think it’s probably best to stick with the stock-standard “can’t read this?”, personally.

Inclusive design, standardization, and the iPod shuffle

Remember back in 2001, when in October, white headphones appeared everywhere seemingly overnight, and all of a sudden anything that wanted to be trendy and fresh was an i-Something? Since it was first unveiled, the iPod has captured the attention and devotion of users around the globe — initially just music lovers, but later users of all kinds of media.

So why is it that the iPod was as much a revolution (if not more) than the walkman? I would guess there were four major factors (and Leander Kahney and other commentators would agree with me):

  • The iTunes music store tie-in. In the past few years the iTunes music store has been heavily criticised for selling “DRM infected” m4ps that only play on Apple players, and to my mind this is a valid criticism (though one that is being eroded as music retailers come on board DRM free and competition opens up). However, in 2001, the music store was a music revolution — you could buy a whole bunch of stuff (some that was difficult to get any other way) on a per-song basis, legally and for a reasonable price. And it was all integrated with a device that you could cart all of it around on and play it on.
  • Meeting a need. The iPod was the first small device with long battery life and storage for a significant amount of music. And unlike travelling CD players, iPods almost never skipped. Way back when I bought my first iPod (I have a third generation 15 GB and a second generation 1GB Shuffle), in 2003, it weighed about as much as two CDs in their cases, took up much less space, and could hold about 3,500 songs. It still isn’t full, and my music goes with me when I travel.
  • Not a real iPod ad

  • Design and the cool factor. Apparently they white headphones were a happy accident, but they became iconic, and the iPod became a must have. The advertising campaign helped with this — the primary colours with silhouettes rocking out to their music grabbed people’s attention so much that people started making their own takes on them (as above), and services to iPod your own photos professionally popped up on the web.
  • Usability. Not only did the iPod do something that users wanted, it was easy to do it. The device, the music store, and the software are easy to install and use — and this didn’t happen by accident, it was a designed in feature. Some commentators go so far as to claim that the usability of iPods is the reason why people love them so much.

I don’t actually think usability alone can account for the emotion — I think it is the whole user experience of the right thing that is not only easy to use, but sexy as well.

So, imagine my disappointment to discover a fairly serious oversight in my shuffle. The second generation shuffle is designed in the shape of a clip (see below) . The clip is great, it clips onto clothing or backpacks readily and effectively. But it is designed for men, or more specifically, people who wear men’s shirts. This makes me feel just a little bit like my shuffle wasn’t designed for me, and if it weren’t for the shuffle being otherwise excellent, could affect how I feel about it.

For historical reasons, men’s and women’s shirts button in opposite directions — the buttons on men’s shirts are on the right, and women’s are on the left. Originally this was a usability consideration, men dressed themselves, and women were dressed by maids, so the buttons are closest to the right hand of the dresser — unfortunately, though, we have never moved past this even though women no longer have maids. The second generation iPod shuffle’s interface is up the right way (with the headphones going into the top) when it is clipped to a menswear shirt, but upside down (with all the functions going backwards and the headphone cord looping down and then pugging up into the iPod) when clipped to a womenswear shirt. This is particularly unfortunate, given that menswear is significantly more likely to have a pocket to clip the iPod to, and therefore an alternative where the interface is rotated 90 degrees rather than 180.

Now, this may seem like nitpicking, and it probably is — but for a company and a product that has such an excellent user experience track record, small disappointments like this (particularly when they affect 50% of the potential user population, though maybe slightly less of the actual user population) are surprising. What should Apple have done about it? Well, ideally clothing would all be changed so it was more usable in modern times, but given that this is wildly unlikely (because this is a standard, and they are notoriously hard to change), I would have suggested one of things:

  • An “equal-opportunities” user interface where the clip was vertical instead of horizontal
  • Selling left and right clipping iPod shuffles
  • Having a reversible clip.

Apple have a lot of it right, and I am not about to throw my shuffle out just because I have to work a little bit harder to find somewhere to clip it, but I do think this is an excellent example of how small things matter to a user experience, and that standardization isn’t always a great idea. Still, though…I’ve seen the iPod touch. And I want one.



Some rights reserved.

Comment moderation

If it is your first time posting, your comment will automatically be held for my moderation -- I try get to these as soon as possible. After that, your comments will appear automatically. If your comment is on-topic and isn't abusing me or anyone else who comments, chances are I'll leave it alone. That said, I reserve the right to delete (or infinitely moderate) any comments that are abusive, spammy or otherwise irelevant.