90 percent of everything : Usability Blog

Written by Harry Brignull

I’ve finally got a copy of Vista running at home. I’m mainly going to use it as a Media Center and I’d like to say that there’s lots of thing I like about it. I’d like to say that because I’m probably going to spend the next few months bitching about it

Number one. It does look pretty. That’s the first time I’ve said that about a version of Windows since i spotted Windows 3.1 in the window of Dixons (and that was coz I’d never seen a 256 colour graphics card before)

Number two. I’m judging it as a media center. That means the whole 10 foot interface with no mouse or keyboard. And in that field there isn’t much competition. Nothing Apple is doing? (Please correct me…)

Number three. I’ve got way too many music files. Vista isn’t doing that well at not choking on my music library. That kind of sucks but I’m going to let it go. I’m not a typical user and I’ll have to fight this battle some other time.

Ok I acknowledge that I’m no security expert and this probably isn’t a major security risk, but do you recognize this scenario?

You’re on some two-bit website trying to log in. Maybe its a royalty free photo bank, maybe a discussion board, or some random online game.You’re in a hurry, not thinking too hard, and suddenly find you’ve tapped in the username and password for your email account, or - even worse - your work VPN. It comes up as “incorrect username / password” so then you go on to try another likely candidate - and then another again. By the end of it you’ve hammered in pretty much every username and password you’ve used in the last 10 years.

Have you ever considered the possibility that this site is storing all the rejected username and passwords? They may be storing them with or without nefarious purposes, but either way, it’s a genuine possibility. It seems reasonably possible that if you were a nasty person, this kind of list would be useful for a dictionary attack. I’d love to be enlightened by an expert on this stuff.

Password security seems to be primarily a human problem… I’m no expert but I’m really intrigued to read more about this…

Now I’m a Mac lover, but there are some things about iTunes and iPods that drive me nuts.

• When you’re listening to your ipod and a crappy song comes on, there is no option to trash it.
• If you import a CD when your computer is offline, it gives the tracks generic names (”track 1, track 2″ etc), and then they stay like that. This isn’t very helpful. What it should do is watch out for when you are next online, and then get the real song names off Gracenote in the background, without requiring any intervention from you.
• Podcasts are listed under Albums. A podcast is not an album.
• iTunes doesn’t do anything intelligent with tags. It doesn’t parse tags for similarities (e.g. “BobDylan” and “Bob Dylan” are obviously the same artist), and it doesn’t try to improve them with any social webby magic either.
• It copes badly with compilation CDs. You end up with hundreds of artists listed (e.g. itunes puts a song by “Javis Cocker & Thom Yorke” in its own artist category, rather than listing it twice: under “Jarvis Cocker” and under “Thom Yorke”). And if you have one 4 minute song by an artist, it lists it as an album when you browse by album on your iPod.
• iTunes expects you to make your own playlists. I hate making playlists, but I want something better than “random-everything” or the crappy smartplaylists that come preloaded when you install iTunes.
• iTunes thinks it owns your bandwidth. When it starts downloading two big podcasts simultaneously (which it often does), your web browsing experience slows right down. It should throttle itself!
• iTunes thinks it owns all the audio on your computer, and always tries to put things into your music library. So if you double click a music file, iTunes will load itself and automatically move that file into your music library. I hate that.

I know there are work-arounds for many of the things I’ve listed here, but that’s my point - that they are work-arounds. You have to think, tinker, learn, try out alternatives, and become a mini-expert. Some of us don’t want to!

The Help Desk (via My Confined Space - be warned some of the other stuff there isn’t particularly safe for work - or particularly good - but the video clip is a corker)

The Museum of Lost Interactions (via Boing Boing)

and finally - and with slightly more information content - How much control should our users have?

I’ve recently been talking to a number people about the “release early, release often” mantra. If you’re working on a new web app for the mass consumer market, be very wary. “Release early, release often” was written with open source software in mind.

If your first public release is too raw and too hard to use, there’s a risk of it not “going viral”. People won’t start shouting off the rooftops about it. The first blog posts and reviews that appear may have a negative tone, and this sort of thing is so hard to wash off in later releases.

In the open source community, people are keen to pitch in and help with the development in whatever way they can. They are tech savvy people who will put up with bugs, teething problems and constantly changing user-interfaces. They will happily give you their feedback and opinions - open source code is a worth cause. This is the world where the saying comes from.

If you are making a web app for the mass consumer market, “release early, release often” is dangerous. Sure, you want to get it out there and get some momentum, but first impressions count. In this day and age user-experience is one of the key differentiators between similar services. Also, your early adopters aren’t going to appreciate you forcing a poorly designed UI on them just because you were too tight to spend a bit more time and money in the design phase. Your early adopters are your nearest and dearest customers. They will make some effort and give some you feedback but you have to begin the relationship by giving them something that’s up to scratch.

So, throw away the old mantra, here’s what you should do:

• Involve users early, involve users often (do UCD!), but do it behind closed doors until you’ve got something you’re proud of.
• Cut back to a core set of functions, and concentrate on making them work well.
• Release to the public only when feedback from your test users is mainly positive.

I realise I may be preaching to the converted here - but if this article is helpful to just one or two people, then it was worth it …

There’s been a lot of talk lately about Snap’s “preview anywhere” mouse-over menus lately, and how they are a usability nightmare.

Well, I’d like to add my 2p by turning this discussion on its head and pointing out a couple of sites where mouse-over menus are done right (Amazon US & Yahoo), and how they’ve managed it.

On Amazon US, if you mouse-over the “See all 36 categories” tab, (or “Find Gifts”), a large menu pops-up. On Yahoo, something similar happens if you mouse-over the dynamic “mail / messenger / etc” area on the righthand side of the front page.

When you use these menus, they somehow “feel right”. They are different to the Snap Preview Anywhere menu, and all the other old school mouse-over menus that usability people everywhere have moaned about since the beginning of time.

So how come they are being done right? It seems to me that there are three main factors: (i) the delay, and (ii) the hit area and (iii) the context of use.

The delay needs to be long enough to distinguish an intentional “hover” (Scenario: user pauses cursor over the link and thinks “… I wonder what that is…”) from a mouse that happens to be flying by on its way somewhere else. But also, the delay needs to be short enough to happen before the user clicks the link or they move their mouse-away.

In the case of overlays (menus that cover up the content beneath), you need the menu to dissapear pretty quickly on mouse-out, since when users are done with the menu they want to get on with reading the site. This brings us onto hit areas. With small menus, if the user “wobbles” their mouse and accidentally moves the cursor outside of the hit area, the menu disappears while they are trying to read it, which is extremely frustrating.

Amazon avoids this problem by having a huge menu with a big gutter around the clickable items. This makes it easy to close the menu on purpose (a clear, purposeful push of the mouse outside of the hit area) and hard to close it by mistake.

Finally this brings us onto the context in which mouse-over menus are used. Mouse-over menus are a high prominence techique that should be used sparingly, and only for things that are likely to be very important to your users.

So, in conclusion, lets apply this framework to the Snap Preview Anywhere menu:

• The delay: interestingly, the default delay is set to 0.5 seconds which isn’t too bad- this doesn’t seem to be their problem.
• The hit area: is a small, awkward shape, making it easy to accidentally mouse out when you are moving your mouse from the hyperlink into the menu, or when trying to hit the controls (e.g. the “options” link) which are too near the sides.
• The context: the Snap Preview Anywhere menu is normally found all over a page like a bad rash, all it gives you is a low res, highly compressed screengrab of the linked-to page.