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 …

Here’s a little walkthrough of the Linked-in user experience:

1. When you register, it encourages you to add weak links to your network.
It does this by trying to get you to add your entire address book to join your network (as shown below). I don’t know about you, but many of the people I have in my address book are “weak links” – people I only sort-of-know.

2. Even if you dont fall for the trap, people you sort-of-know will.
So you end up with a mix of strong links (close friends and colleagues) and weak links (people you have met a couple of times, or have only ever had email contact with).

3. One of your contacts requests an introduction with someone you don’t know, but one of your weak links does.
Linked-in allows your contacts to request “an introduction” with not just people on your network, but people they know. So if you’ve never met Bill Gates, but one of your weak links knows him, another of your contacts could ask you to ask your weak link to introduce them.

4. You are given two options: “forward” or “decline”
This chain of vague association would probably make you feel a little awkward at this point. If you go ahead with it, you’d could find yourself saying “I know you don’t know me that well, but this other person I don’t know that well wants me to introduce you to someone you are linked to”. What if you don’t want to do this? Is there a polite way of getting out of this situation?

Basically linked-in shows you two buttons (as above), which force you to make a choice. The problem is that this is so black and white. You are either actively helping, or you are actively blocking. In a face-to-face conversation, you might change the subject, or be non-committal - “I’ll see what I can do”. The requester might then realise you don’t feel hugely comfortable about it and drop the subject. Also, with voicemail or email, one of your options is inaction. You can postpone indefinitely. Basically, in the “real world”, there are many shades of grey, and both parties have many options to avoid socially awkward interactions.

But in the Linked-in world, their system forces you into a direct confrontation. You can end up saying to yourself “I feel awkward about forwarding, I feel awkward about declining”

5. If you ignore the email, linked-in keeps hassling you
So Linked-in now sends you a reminder email again, and again, and again. How very, very annoying.

Here’s what Linked in should do to sort this mess out:

• Don’t allow people to add their entire Outlook contact list. If they must offer this feature, they should add a step where the user is encouraged to remove the weak links. Weak links dilute your network.
• Allow users to set their chain length. I personally would only want chains of 3 (a friend asks me to introduce them to another friend). Other users might be happy with 4.
• Don’t force direct confrontations: Allow people to gracefully ignore or “sidestep” thorny requests.
• One reminder email is enough. Two is nagging. three is ridiculous.

Proponents of various abuses of Flash and Ajax cleverness have a frequent defence of their sins: “I’m allowed to break the back button, bookmarking and ‘open in new window’ and all that other stuff people take for granted because that stuff only applies to websites. This isn’t a website - it’s a web application!”

Well I am prepared to accept this argument if we agree on a proper definition of ‘web application’. I’m tempted to be snarky and state that a web application is a web site where I would never deam of bookmarking or using my back button but for the sake of making my argument in good faith I will endevour to present a slightly more useful definition.

Websites have pages. Web Applications have states. An application can be spread over several pages of a website in which case the back button and bookmarking should work between pages. It’s OK for them not to work between states.

How do we differentiate between ’states’ and ‘pages’? Here’s my not very well thought out rule of thumb. GET’s are pages and POST’s are states. For the less HTTP involved among you then here’s it put another way. If you’re changing data on the server then that’s a POST and I don’t need to bookmark or go back. (However you’re welcome to implement an ‘undo’). If, however I’m just moving to a different view of the data then I will probably want to be able to bookmark that view, send the URL in an email, open it in a new window and all that other stuff a normal website gives me for free.

SitePen Blog » Blog Archive » why splitpane views suck..

He’s got a point and Gmail is a marvel in it’s range of subtle usability tweaks.

But on the desktop splitpane views are pretty much becoming the norm. And as I’ve said before they suck a whole lot less than floating palettes and overlapping windows.

But they still leave too much of the decision making about use of screen space to the user. Jesse Kuhnert praises Gmail for removing those decisions from you and I must say I’ve never wished I could resize bits of the Gmail UI. Could this strategy work for a wider range of desktop apps too?

Want your podcast audio transcribed each week automatically? Got a big image database that needs meta tagging? Well the future’s here, and you only need to pay a few cents per item.

Enter the mechanical turk, which everybody seems to be talking about at the moment. It’s a fancy name for hiring in a bunch of temps to do a bunch of 60 second jobs for you, via the web (and via an API if you’re a programmer).

Apparently there are thousands of people out there willing to take on your monotonous tasks for a pittance. The great thing is, you never have to meet them, deal with pesky employee rights like minimum wage, or look at their faces gradually crumple in the drudgery of the job you have given them, since it’s all done using the wonderful anonymity of the internet.

As a mechanical turk worker you just log into a website like Amazon’s mturk.com, select a job and start doing it, all through your web browser. Each task pays just a few cents but if you take on tricker tasks, you end up with a small supplementary income. Translation of foreign language audio to English text pays pretty well. After a year you might be able to buy yourself… something small.

I don’t know about you but I find this quite depressing. Read more at the mechanical turk monitor blog.

Andy Budd (the other slightly better known AndyB - he scolded me once on a mailing list for signing myself AndyB. Cheek!) demolishes thetrainline.com rather nicely.

I wonder if companies get to read this kind of stuff and whether they take it seriously? Andy has provided free gold-dust here and they should be sitting around a laptop in their boardroom frowning and holding their collective chins.

Not every critique is of this calibre and not every criticism is valid. Casual users often don’t understand the constraints that force you to implement things a certain way. But in it is amazing how many products get out the door containing howlers. If you were too cheap to do a usability study in the first place then google for yourself occasionally and you might get some valuable free advice!

Read every email that contains complaints and suggestions and repond humbly to them all - even if you disagree. And check your server logs to see if lots of people end up departing your site at the same place.

(Almost forgot. He just wrote an update to the original post which is what reminded me about it in the first place)