Monday, January 31, 2011

A fifth Ignite Waterloo is coming

I’ve been involved in organizing Ignite Waterloo, which produces a series of events in Waterloo Region, since the first event in 2009, and it’s been amazing to watch the events grow in popularity since that inauguration of the series. We now easily attract well over 200 people to these things, and, as I was telling someone last week, we have relied pretty much on word of mouth and social media to spread the news about our activities. Of course, there’s much more hard work than that to get an event off the ground — and there are many people who make it happen — but it’s been a big hit with audiences and speakers alike with very little traditional communications.

The next Ignite Waterloo event is scheduled for Tuesday February 8 at the Communitech Hub in Kitchener, and even though we only announced the date and venue on January 11, we’re already pretty much sold out. Still, try to get a ticket if you want one and see if you can get lucky.

Monday, January 17, 2011

Adding albums to the music mix

I spent some time over the holidays updating the music on my iPhone. That’s something that I do periodically, as it has far less capacity than would be required to hold my music collection and I like to vary what I listen to. The sources for the tracks are varied. Some I download from iTunes and other sources. I often digitize music that I have on CD. Less often, I digitize music that I have on vinyl albums or 45s, and doing so recently got me thinking about mix tapes.

I’ve created them, in the distant past, and enjoyed the reverence for the form in Nick Hornby’s High Fidelity (in both novel and film versions). Still, it had been many years since I made a mix tape, and even a few years since my last round of vinyl digitization. In the intervening time I had filtered from my memory just how out tedious it can be to digitize more than a few tracks. I retained only a fuzzily idealized notion of savouring each track while it is transferred to digital form (or, as I did in days gone by, cassette tape). That notion holds for the first few tracks, but the novelty does wear off! Here’s a simplified version of the steps required to digitize a track:
  • Connect the turntable to the computer.
  • Pull the record from it’s sleeve and put it on the turntable.
  • Start the turntable and drop the needle on the track; set recording levels to be loud but not so loud that distortion is introduced during the loudest passages.
  • Once levels are set, drop the needle again, but before the piece starts.
  • Start the digitizing/recording.
  • Enjoy the track while it plays.
  • When the track has finished, stop the digitizing/recording.
  • Remove the record from the turntable and replace it in its sleeve.
  • Edit the digitized track to eliminate any silence at the start and end of the track.
  • Add track to iTunes and add meta data to taste (Track name, Artist, sleeve art, etc.)
  • Repeat as necessary.
Obviously there are workflow optimizations available (e.g., record a batch of tracks, then edit them, then add meta data), but it’s still a laborious process. It was even more so in the past when the target was a cassette tape and the process included selecting tracks to efficiently fill a fixed length tape, manually minimizing silence between tracks, and creating cover artwork by hand.

Anyway, in the end I realized that I don’t at all miss the tedium of creating mix tapes the old-fashioned way, or digitizing analog formats. I do, though, love listening to the iPhone-age equivalent of mix tapes.

Monday, January 10, 2011

A bottle of correcting fluid as a metaphor

I’ve written before, and given an Ignite talk on, the use of metaphor in product design. I occasionally see an icon and wonder if it is recognizable as an object from the real world, and hence whether the metaphor is clear. Here’s an example from Pages, the document creation application that is part of Apple’s iWork product suite. The preferences dialog includes an area for specifying the behaviour of auto-correction of things like capitaliztion, quotation marks, and so on.


The odd thing to my mind is that the icon appears to be a bottle of correction fluid, something used to correct mistakes on documents created using a typewriter. As with using “cc” in email, the metaphor refers to a pretty old technology that is used by far fewer people today than it was in the past. Beyond that, it refers to a tool that is manual and pretty finicky, about as far as automatic as you can get. I wonder how many users of Pages in 2011 have never seen, let alone used, a bottle of correcting fluid? That is, for how many people is the icon unrecognizable and, hence, ineffective as a UI metaphor?

Monday, January 3, 2011

Usability of passwords

Like many people, I have a large collection of online accounts to manage. Examples for me include various email accounts, Twitter, and this blog. My large collection means that I have many passwords to manage. I like to think that I create passwords that are reasonably secure as well as being memorable for me, but its an annoyance to do so on a large scale.

Despite their many drawbacks passwords are currently a pervasive part of online life. While it’s easy for some to mock users for using unsafe passwords, a more nuanced approach is to understand that people are quite adept at circumventing security that gets in the way of their goals. Donald Norman has written eloquently about the challenge of designing a usable product with security in mind.

Some of the usability challenges around managing passwords were reiterated for me when I recently updated the passwords associated with my various online accounts. By sweeping through all my accounts at once, I got a concentrated look at various design solutions used by service providers to support password management by their users. The results were decidedly mixed in terms of usability. This message on restrictions in creating a password wasn’t unusual:
When changing your password, please remember that it must be between 5 and 8 characters in length and should contain both letters and numbers. Special characters (e.g. #, &, @) must not be used as they will not be accepted by the system. Passwords consisting of all letters or all numbers are not recommended.
While the message is clear, the underlying restrictions make it hard to come up with a secure, yet memorable, password. (As an aside, I’ll add that while I have my own strategies for creating and using passwords, I’m not going to describe them here. I hope the reasons are obvious!)

There are approaches to password creation that improve things a little.

One popular UI widget provides immediate inline feedback on the strength of a password that a user has defined for an account. I found several examples during my recent updates. Here’s one in particular that shows the feedback when I type in a terribly weak password for the account.

A screen showing feedback for an unsafe password

Not bad. The wording isn’t optimal but “Unsafe password” gets the job done. Here’s what appears when I provide a more secure password that includes a mix of letters, numbers, and special characters:

A screen showing feedback for a strong password

Again, the wording isn’t optimal but “Very strong” is fairly clear and also reassuring. Of course, the feedback is only useful when the guidance that it provides can be acted upon. Here’s what I see after trying to save the new password:

A screen showing feedback for a strong password that the system won't accept

It turns out that my “very strong” password choice is too strong for this service!

Obviously, security is far from an easy problem to solve, and no single solution fits all needs. Having said that, this particular example from just one small sliver of a secure system is clearly bad design from a user experience perspective. The initial feedback is accurate in its assessment of the security of my desired password, but it’s irrelevant because the system won’t accept the password. The later feedback comes at a point in the workflow where it’s more frustrating than informative.

If passwords have to be a part of a product or service, design for them in a way that doesn’t needlessly decrease usability.