Trade Me Browser Stats

I’m pleased to see Trade Me have started posting their browser stats again, something I used to do here, way back in the day.

Here is the latest update, for May 2010: Browsers and Operating Systems

When people talk about Open Data they are nearly always referring to government data.  But, I think there are also lots of examples like this, where private companies have data which has a public good, and which they can open up at no material cost to themselves.

Trade Me is such a popular site that their audience can pretty much be used as a proxy for the internet in New Zealand, so this gives developers working on smaller or less popular sites a good idea of the sort of browsers they should be targeting.

Remember, if the equivalent numbers for your site are different from these there are two possible explanations:

  1. Your audience is a subset of the population which has a browser bias (e.g. if you attract more technical people you’ll probably tend to see a higher proportion of newer browsers and also some lesser known browsers that are not widely used in the mainstream)
  2. Your site makes it difficult for people with older browsers to use your site, so they choose not to.

Just about everybody assumes #1, when #2 is often more likely.

Remember that the 5% of Trade Me visitors using IE6 is still 31,500 unique visitors per day, or nearly one Westpac Stadium full.  Are you happy to turn all of those people away with a message telling them to upgrade their “browser”, what ever that means to them?

The career path of a heads-up developer

… as pointed out by Eric Ries at Kiwi Foo:

  1. Write software
  2. Lead a team of people writing software
  3. Manage people who lead a team of people writing software
  4. Advise people who manage people who lead a team of people writing software

What’s the next step after that?

What do you do?


Heads Up vs Heads Down

Form Fail

The quality of form design, in general, on the web continues to be a huge source of frustration for users and an embarassment for all of us who are involved in designing and building sites.

Here is a payment page that I needed to traverse recently…

Firstly, as originally served:

Payment Page

And, here once I’d disabled CSS:

Payment Page - No CSS

It took me a few attempts to even work out what was happening. Initially I just assumed that the page had somehow not completely loaded.

Then I highlighted the area where the labels should be and realised that they were actually white text on a white background!

I’m guessing that in this case the design is incompetent rather than malicious.

Perhaps it works fine in Internet Explorer? Who knows.

I was determined, so worked it out.  But, I expect I’m an exception.

If they measured their conversion rates on this page, surely they would find that a significant number of people simply give up, unable to work it out.

So, you have to assume that they probably never bothered to measure.

Of course, none of the intelligent and experienced people who take the time to read this blog would ever make a mistake as outrageous as that. Would you?

You might be surprised …

Let me try and debunk some axioms of registration page design, and in the process highlight a simple mistake that I would guess many of you have made without even realising it (I can only say that with confidence because I’ve made it myself many times).

To start, a question… what is the difference between these two forms?

Form Fail - With Tick Box

Form A: with tick-box

Form Fail - Sans Tick Box

Form B: without tick-box

Which is easier to use?  Or, to ask the same question in a more measurable way: which would have a higher conversion rate?

As we’ll see there is evidence to suggest that Form B is a much better design.

So, why are registration pages like Form A nearly ubiquitous?

Here are some possible reasons I can think of (if there are others, please let me know)…

Legal reasons

In case it’s not obvious, I’m not a lawyer!

If there are any lawyers reading I’d be interested to get an informed opinion on this.

My guess is that it doesn’t make any material difference.

Just think about how this would sound in court: “But, your honour, they ticked the box when they registered!”. Yeah, right.

And, even so, at what cost this additional legal protection? How many fewer registrations can you afford before it’s worth taking the risk?

Because everybody else does

This is probably getting closer to the major reason for the ubiquity.

And, there is something to be said for consistency. But, surely only when it doesn’t hurt!  Lemmings!

Just because everybody else does something, that doesn’t excuse us from measuring and understanding the impact of our design decisions.

How hard is it to tick a box?

Now we’re getting to the interesting bit…

I was recently talking to Nigel about some of the work he did on improving the StarNow registration page. This is the first example I’d come across where somebody had actually taken the time to measure specifically where people were failing on this sort of registration form.

It turned out, in their case, that 27.9% of people didn’t tick the box the first time, and as a result got a validation error. What’s more this only compounded other problems. When the tick box validation error was displayed the password fields were reset (as is common, unless you explicitly set these values when the page is returned, which is frowned upon by security types). So, of course, many people would read the error message, scroll down and tick the box, only to find that the form still didn’t submit successfully as they also needed to re-enter the password.

Does this sound familiar? I know I’ve been through this exact dance myself many times, and I consider myself a pretty savvy web user.

Overall they found that over 34% of people who attempted to complete the page (i.e. pushed the submit button at least once) abandoned the site without successfully completing their registration process.

By making simple changes they decreased this to 17%. That’s a staggering 26% improvement!

So, some suggestions:

  1. Ditch the tick-box from your registration page.
  2. If your lawyer complains ask them to justify the cost, which you will now be able to quantify.
  3. Re-populate password fields on post-back. Or, if you’re not comfortable doing that for security reasons, at least highlight the fields that people will need to re-enter to avoid further error messages.
  4. Most importantly: take the time to measure and understand exactly where people are failing on your site, then do something about it!

Visualise your audience

I love the buzz of a big crowd.  It’s exciting to soak up the atmosphere created when lots of people are all in the same space at the same time.

If you’re lucky enough to be the band, or sports team or speaker who is the focus of the crowds attention, then that is quite powerful.

(Or terrifying, I suppose, depending on their mood!)

If you design or develop software it’s much harder to get feedback like this.

But, it’s still useful to think of crowds to help you visualise the audience of people who are using what you’re building.

This was the idea behind the photo I use in the header this site.

Another from the same shoot is below, for those of you reading via my feed:

Idealog Stadium

These come from a 2006 article about Trade Me in Idealog, and were taken at the Westpac Stadium in Wellington on a wet and wild day (hence the slightly damp windswept look and the Icebreaker jacket).

The stadium seats about 35,000 people when it’s full.  At the time there were about that many people online at once every evening on Trade Me.

(As I type there are over 80,000 online, showing how much it has continued to grow since then!)

When you think of that many people all in one space together, and the noise and activity they generate, it changes the way you think about the people using your site.

One of the things that software developers do all the time is dismiss a percentage of their audience as unimportant for one reason or another, without thinking of them as a distinct group of people.

If you don’t think you need to worry about people stuck using IE6 (for whatever reason) or a dial-up connection, or people who struggle to read small fonts, or people who are colour blind (or completely blind), or people who don’t know how to use a command line, or people who are still nervous (paranoid or otherwise) about entering their credit card details into a website, or people who want help from a real person, or people who use Firefox on a Mac … because on a percentage basis they are not that many … calculate just how big that group is (take your unique visitor count and multiply by the percentage, however small), and then imagine standing up in front of that group and telling them to their face that they don’t matter to you.

If you don’t think it’s a big deal for your site to be broken or off line while you make changes … think of all of the people who happen to be visiting at that point and imagine what it would feel like to have them all in the room with you while you flick the switch.  No matter how small the number it would probably feel like a lot of people.  And, you might be motivated to get the site back up more quickly if they were all standing behind you impatiently looking over your shoulder.

You can use the same technique to help put other numbers in perspective.

It’s amazing the difference it makes when you start thinking of your metrics as real people.

For example…

  • 2 people = your mum and dad!
  • 5 people = a car full
  • 15 people = a rugby team
  • 30 people = a school class
  • 100 people = a bus full
  • 120 people = a parliament full of MPs (actually 122, to be precise)
  • 380 people = all of the passengers on an Air NZ 747-400
  • 550 people = the audience at Webstock earlier this year
  • 1,500 people = capacity of the Aotea Centre in Auckland
  • 2,500 people = all of the students at Auckland Grammar school
  • 6,000 people = capacity of the TSB Arena in Wellington
  • 10,000 people = population of Gore :-)
  • 12,000 people = capacity of the Vector Arena in Auckland
  • 18,000 people = all of the students at Otago University
  • 20,000 people = population of Levin
  • 25,000 people = the crowd at Augusta National each day this week
  • 35,000 people = capacity of Westpac Stadium in Wellington
  • 60,000 people = capacity of Eden Park in Auckland, post-renovations
  • 100,000 people = capacity of MCG in Australia (also, incidentally, approx. the number of people who voted for NZ First at the last election)
  • 250,000 people = capacity of St Peter’s Square in Rome
  • 475,000 people = population of greater Wellington region
  • Etc, etc.

Help me out with some more examples…

Ski Lodge

Here is an example of a beautiful iPhone app and a simple promo website:

Ski Lodge (for iPhone)   

The UI is very easy to look at – little things make it obvious this was designed rather than just developed: like the wood grain background, bold easy to read fonts and navigation elements which have clearly been designed to be touched rather than clicked.  

I especially like the trail map link on the resort page which includes a bar chart showing the percentage of runs that are beginner, intermediate and advanced – a nice way to communicate a lot of information without adding lots of noise.

Their website is great too – a single page with screen shots and an obvious link to the App Store.  

At the moment they only cover the US and Canada, but according to ReadWriteWeb they have plans to add NZ and other countries soon.

Other apps from the same developers, all of which look just as impressive:

Also, something fun… check out Burn Ball by Tim Haines!

PS: If there are any aspiring iPhone developers out there looking for a project to get stuck into in 2009 drop me a note.