90 percent of everything : Usability Blog

Written by Harry Brignull

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.