Web Form Design

In an uncharacteristic change, I've been reading some non-fiction on the train to work in the last couple of weeks and thought I'd blog about it here (albeit briefly) before moving on to some related web analytics stuff.  The book that I've been reading is Luke Wroblewski's Web Form Design.  It is a very practical book on the all the intricacies of designing and building forms for the web environment.  And to be quite frank, I didn't even realise that there was so much to know about.  What I'm going to do here is do a brief bit on what is in the book and then some more web analytics stuff afterwards (which isn't really covered in the book).



Rather than go through the book in complete - I thought I'd share the bits that caught my eye particularly.



Clear Scan Lines:  



Firstly Luke has clearly done his research in this area.  He has done a lot of work in the past and studied other website's forms to see how they change.  More importantly he has done lots of eye tracking studies.  Through this eye tracking studying Luke has established that the best way to build forms is so that users can scan their eyes down it easily.  This means getting everything justified in the right way to give users a straight line down the page.



The advantage of this is that the user doesn't have to move their eyes around the page to find all the input fields and information that they are after.  This should help them complete the form without missing out any elements (which is a common reason for users failing to complete a form).  It will also give the user a flow from the start to the end, finishing up on the submit button, rather than zig zagging around and trying to work out which they should do first (the left hand column, across, etc).



Label Alignment



I didn't think that having labels aligned left, right or above would make any difference to how a form is perceived, but apparently it does.  How do we know?  Well Luke has been looking at his eye tracking again and more importantly there are advantages of each system.  Sometimes you need right aligned to make it obvious which field goes with which label.  Sometimes you need left aligned to get a better scan line (people read from left to right).  Sometimes above is better because then it is obvious what the fields are for.



Help Text, Errors and Success



These are the three things that I think are most commonly overlooked.  How do you tell people how to fill in a field, how do you tell them they've done it wrong and how do you tell them that they have been successful.  These should be important bits of the design process and need to be thought about thoroughly.  Help text should be short and concise.  Out of the way for the user who doesn't need it.  Think about how the labels are set up - if you need too much help text, the question probably isn't obvious enough.



Errors on the other hand should be the complete opposite.  It should be bold.  It should be red (nothing else on the form should be red).  It should point out what is wrong and how you can fix it.



Success pages should be short, sweet and helpful.  You should tell your users what the next steps are now that they are have spent their valuable time filling in the form.  You should give them some other options of things they can do in the mean time whilst whatever it is they are waiting for arrives.  You should tell them how long it will be until it arrives.



Selection Dependent Inputs



I think Luke could have written a whole book on this subject.  He provides a fascinating look into which method of revealing selection dependent inputs looks best and works best in a set of situations.  Whether it be Vertical tabs, horizontal tabs, drop down lists, exposing below radio buttons, exposing within radio buttons, exposing just the active setting or exposing the whole lot and then just selecting the active one.  I think I could probably blog about it too forever, but without any real examples there is no point.



A/B testing



One area I think that Luke could mention in a future book is A/B testing.  One of the advantages of the advanced web analytics tools that we have now is that we can put two different forms up onto a page and work out which one works best in an A/B or multivariate test.  The advantage of this method over the eyetracking is that you can find out what large groups of people find the easiest form to complete and get through to the other side.



What I always suggest with A/B testing though is that the research is done thoroughly beforehand.  It is far too easy to start at the wrong base point and end up at a version which works the best given the starting design, but isn't the best form because the wrong route was taken early on.



Funnel Analysis



My favourite topic (and I've mentioned how to do conversion funnel analysis before) here.  The reason that I am so keen on it is that I am a strong believer that like suggesting that you do research before you start your design process (and A/B testing) you also do your funnel analysis before you start your research.  The advantages of the funnel analysis are that you can work out the points that your site is failing you much more easily through this route and use this information to feed into your research.  Doing lots of research on a form to get a 5% increase in conversions is nothing if it turns out you could have done some research on an earlier part of the form that would have given you 20%.



Form Abandonment



HBX has a great form abandonment section that will tell you the point that a user gets up to before they quit the form and go somewhere else.  It's in your pages menu, second from the bottom.  You'll have to search for the particular form that you are looking for (especially if you have site search running).  But when you do, you might start to find some interesting information.  For if you click on the little grey button next to your form page and choose 'form abandonment' you can see the last field the user got to before quitting.

 

This is immensely useful to see if users are hitting certain stumbling blocks.  In the case above the first one on the list is the field that you are defaulted into, but some of the others make interesting reading.  This should flow into the questions of:

• Does this field need to be on this page?


• Should we give some help text to explain what to enter into this field?


• Should we give some help as to what format it should be?


• Should we give some explanation as to why we are collecting this?


• Should we tell our users beforehand that they will need to know this to get through our form?

A bit of food for thought there on ways to improve your form.  If you are going to do any form redesign or analysis, I recommend reading Luke Wroblewski's book on Web Form Design though - it will give you lots of ideas on the best ways of creating them and may give you some approaches that you hadn't previously thought about.

The iPhone Changes the ball park for Mobile Analytics

I'll start this post today by saying that I've got a new iPhone.  Is it great?  Well it is according to cnet, and not so according to others.  Needless to say, I am impressed because I've gone from a horrible old Sony Erikson K600i to a modern phone for the first time in 2 and a half years.  Having said that, I did have to go through the nightmare process of changing networks (because my old one didn't sell an iPhone), porting my number across and moving all my contacts across.  But I am finally back in the 21st century.  Needless to say, I think the iPhone is going to change how we think of mobile analytics.

Traditionally Mobile Analytics is difficult.  June Dershewitz has a very good post on her blog about mobile analytics and the challenges we face at the moment.



Primarilly amongst the major issues was people like me using old phones like the one above.  Why was that an issue?  Because we were using strange browsers that wouldn't render the pictures properly.  We were getting other systems to transfer images into smaller formats so that we could view them over our shitty GPRS systems.  Needless to say, most of the time we weren't even loading javascript.



What did this mean for mobile analytics?  Well firstly it meant that we had to set up systems that could detect mobile usage.  This meant either:

• Putting your old style noscript tags on pages - this usually works best for those that set up mobile versions of their site.  You can do some clever user agent detection and redirect users to a mobile site (low on pictures, etc to speed up the process).  The downside is that you still don't really have a unique identifier (no cookie), the useragent is too consistent across browsers and the IP is too inconsistent across the same browser.  Therefore you have to use more than these two things to get a unique user (like Bango do)
  
  


• You do some packet sniffing.  This has a whole host of privacy issues and hence has always been something that I am reluctant to get involved with (if I am finding out stuff about what you are doing on my sites, I could find out a whole load more too that could infringe on your privacy using this method)

What are the big Web Analytics players doing about this?  Well the news today is that Omniture have announced that they have a new tool that can be used for this very purpose.  Stephane Hamel has yet again written up a very nice piece on what he thinks this will do to the world.  The important piece out of this is the integration factor - mainly I would say in terms of support (both in house and from the provider).

But I think that this announcement is too late.  I think the iPhone will change the whole arena for mobile analytics.  Why?  Because the iPhone runs javascript, it accepts cookies (it doesn't run flash rather annoyingly), but overall because it is actually an internet experience.  You are browsing the 'web' on your iPhone as opposed to the 'mobile web'.



What difference does this make?  It means that you should be able to track it in the same conventional way that you do with all your other web analytics - they can run on javascript tags that look at cookies and you can link what the person is doing.  The analytics will be simple.



And the real reason I think that the iPhone will change mobile analytics is that because you can do it on the iPhone and because the iPhone is so cheap, all the other people making phones who isn't already doing these things will have to from now on otherwise they'll be out of the market.  Who is going to get a new phone which can't do the new basic standard (which this surely is).



In the UK I reckon most people keep their mobile for 12 - 18 months before upgrading.  That means that in the next 12 to 18 months everyone who hasn't already got a phone with a 3G capability and a browser that can load javascript and accept cookies is going to get one.  In the US, I am expecting similar things, Europe should close behind.  In the emerging markets over in India and China, this will probably take a bit longer.  In 12 to 18 months we won't have the issues that June talked about in her post.



In the meantime I'm going to go back to playing with my new 3G iPhone.

AVG and the fake traffic debacle

No, this isn't the start of my latest fantasy novel - where the schoolboy hero (Larry Plotter) of the story breaks into the realm of (final) fantasy to destroy the evil AVG from taking over the world (its the sequel to the one where he stops Google).  I think I'll leave J K Rowling to her set of books.  Actually this is actually AVG the antivirus software company and their new version of their free virus software (version 8).

It all started off on April 24th when AVG released version 8 of their antispyware product.  In this version they included an updated version of linkscanner which prefectched pages in search results.  Not only did the prefetch the page, they would also prefetch all the content, including any images or javascript.  They wouldn't execute the javascript, but they'd certainly take it from your servers.

The Register were relatively quick to pick up on this story and whilst they had their angle, I am also going to have mine in a minute as well.  There were a flood of comments in the section after this article and I think they are well worth a read.  A week after The Register got hold of it, Slashdot posted their story onto the front page and generated a huge volume of response.  There was also a huge volume of response down under in the Whirlpool forums because of their long tail of traffic.  Peter Cameron of AVG NZ eventually went online and told them that they were taking it down.

I think in terms of what it does for the user of linkscanner, the comments over on the WA Yahoo! group by Steve McInerney put the ball down very well.  But lets step back and look at the reason they might do it:

• Most of the new sites that people find are through search results
• It is impractical to have a list of all sites that have a history of giving malware to your computer on your computer
• If you click on a link on a search engine results page (SERP) to go to a new site, you don't want to be slowed down by your virus software checking the page before you get there (it just adds to the misery)
• If your antivirus software knew which link you were going to click on before you clicked on it, it could get the page before you go there and check that it doesn't have any malware
• The antivirus software doesn't know which link you are going to click on, so it gets all the pages and checks for viruses and malware before you go there
• To do this, it has to download all the pages on each SERP that you look at
• It also has to download all the images and javascript to make sure they aren't linking to known malware/virus providers

The theory is there, the downsides for the user are this:

• It eats up your bandwidth
• Anything horrible that can get loaded by the javascript won't be tested (that is virtually everything)
  
• It eats up your bandwidth
• It'll slow your computer down
• It eats up your bandwidth

So it is great if you have unlimited bandwidth?  Well not quite, because of the downsides from the other end of the spectrum.  This is what it does to your webmaster (or the website it is prefetching from) when it loads everything from that page (read Judah Phillips interesting post on it too):

1. It eats up bandwidth
2. Any site with 'noscript' tags on their analytics solution will have bad data
   
3. Any measurement system that uses images will have bad data
4. Any measurement system that relies on log file analysis will have bad data
   
5. Any measurement system that uses javascript based tags will be fine
   

Well, that's all well and good, you might say, but so what?  As an end user with no bandwidth issues then I'm completely covered.  Or so you think.  Well, there are solutions for webmasters for options 2, 3 and 4 above.  We can just filter those people out by looking at their useragent (which had a strange string in it that you could use), however we were sure at one point they were just going to go with the useragent of a normal browser.

Option one is more interesting though.  The only way around this here is to block the user agent from accessing your servers.  Or reroute it to another set of servers.  What does that mean?  It means from an end user perspective, they are using up their bandwidth when they aren't even checking the sites they think they are safe from.  Then when they click through, they'll be even more unsuspecting because they think that AVG is protecting them.


Interestingly this has manifested itself on our sites in a slightly different way.  Firstly our adserving technology uses a 1x1 gif to tell how many times each ad could have been loaded (which it will compare with the number of each type that have been loaded).  So this in theory has inflated all of our ad impressions, without increasing our ads.

The other issue is that AVG linkscanner didn't cope with question marks (?), equals signs (=), etc, very well and actually instead of trying to get the real page it was looking for, ended up just picking up the error page (I think this is actually a 403 error, but I can't work out why). This meant that mainly we had a big increase in ad impressions on the error page that weren't really there.

Fortunately it looks like AVG have backed down and are going to remove this 'feature' from their next update to the tool.  In the meantime we need to go back over our traffic stats and start excluding this useragent from our stats so that we can give real impressions on pages.  It'll be interesting to see if the auditing body for online metrics, the ABCe, will retrospectively go back and start filtering these out of their audited sites data.  It'll also be interesting if they do, to see whose traffic goes down by the most, given the recent arguments about it.

Social Bookmarking is about Brand

I've just been reading a couple of blog posts about social media that stemmed from Jakob Nielsen's Alertbox on reducing bounce rates.  I'm not entirely sure Jakob Nielsen meant to do it, but he has started a bit of a conversation on Mashable about whether 'Digg traffic sucks'.  It sounds like an interesting discussion, so I am going to join in.  For those of you not famliar with the format, I have written about how Digg works before (at the bottom of that article) and briefly about the benefits of social bookmarking.

Does Digg traffic stay on the site?

No.

There is no other answer to this question.  Digg traffic bounces.  It bounces a lot.  90% or more.  It's high.  If you're running an eCommerce site that is really high.  Far higher than you could ever imagine one traffic source.  If your a news/media site, that is probably just relatively high. 

Why does it bounce?  

Well that is the easy part of the question - it bounces because the people on that site are engaged with Digg and they aren't really engaged with your site.  If I'm searching around Digg and I find a funny article that someone has linked to that has got to the home page of Digg (eg 'The Transparent Canoe') then do I want to know what the people of that site think about the story?  No, I want to know what the people on my site think about it, because I interact with them every day anyway.  I want to be able to Digg up some comments about how it wouldn't work properly.  Or some crude comment about looking at people's bottoms.  It's all part of the banter, the conversation.  That's why I am on Digg and not searching out for canoe designs in Google.

Do Diggs Convert?

Yes.  Why not?  Because they mostly bounce.

Hang on a second, did I say Yes at the start there?  Yep they do convert.  

Do they convert well?  Of course they don't - 90% of them bounced straight off.

Is this a problem that they don't convert well?  No - because we're not paying for these people.  Our ROI on these people is huge.  We don't put any extra effort in and then they give us conversions.  Ok, so they only give us a small volume of conversions, but this is better than none.

Does it affect our conversion rate?  Sure it does.  It destroys it.  If you have 100 qualified leads and they convert at 10% (for an eCommerce function that sounds just about realistic, although I'm prob a tad on the high side).  If you have 10,000 diggers they'll probably give you fewer conversions.  This mucks up your conversion rate.  So what?  You've just got more conversions for no extra money.

So now what we're doing is suggesting that we'll take a hit on our conversion rate, if we can get more money for our spend.  This is a nightmare for the guy who lives and dies by his conversion rate, rather than his ROI figure.

For eCommerce sites it is more difficult.  You can't spend time and money on it because you don't get it back.  If you create good content then you can get it back.

For all sites though there is another aspect.  That aspect is Brand.

Brand is vitally important to us all, especially in online media.  There are ways of increasing your site traffic through organic search and social bookmarking directly, but essentially our job is to get people to come back to the site.  This is where Social Bookmarking is brilliant.

Think about buying an advert on a website.  I'm talking banners, skyscrapers and MPUs here.  Do you read it?  Probably not - half the time they pop up and leave you annoyed that you can't get to the story.  More often than not, you probably ignore them.  People pay for those banners and skyscrapers.  Clickthrough rates are low and ROI is near on minimal or negative.  Why do people put them up there?  They do it for branding purposes.  Sooner or later you are going to need what they are advertising and hence the reason that you remember the ad that you saw bouncing around.

Social Bookmarking is a bit like that.  You get traffic to your site, it doesn't stay long, doesn't look around, but it remembers you.  Next time they are looking for your product or service they will think of you.  Hey, I need a new canoe, why don't I look on that toxel.com website.  This branding exercise is great for media publications because it's not as simple as just canoes, because the more Toxel gets on Digg, the more Digg users are going to think Toxel is a design site.  Then when they are looking around the web for quirky designs, they are going to think of Toxel first.

Not only that, people have seen the post and your going to have people who blog about that sort of stuff there.  These people are going to be really keen and link to your site.  This is good for two reasons:

1. They might generate some more traffic - a bit more qualified because they are coming from a specialist blog
2. The extra inbound links will give your site some nice link juice that will be spread across the site and push you up the search rankings.

Before you know it, getting linked to on a social bookmarking site has:

• Just given you a spike in traffic
• A ton of interesting comments that you can use to create your new stories
• Given you an idea of the level of interest around a subject in the world outside your blog
• Given you an increased brand awareness
• Given you more inbound links generating traffic
• Improved your search rankings