14 February 2010

Bad Browser Behaviour. You Know Who You Are!

Its the weekend - its Valentine's Day so my post for today is about how much Travel Sites love their Customers. Sadly its not enough.

My rant is focused today on people who consistently ignore the user community and create bloated websites with poor usability. The "everything and the kitchen sink" approach is something that really bothers me. After 15 years of web + travel we should have developed some good practices usability should be refined and the tools for the consumer should be simple and easy to use. We should have moved beyond the explicit process of having to enter large amounts of data in order to get a simple nugget answer to the question that I asked.

Do we have that? No!!!

What we have is bloatware of the worst order. We have inefficient, confusing and often times broken processes. Because I am a bit of a curmudgeon - I even keep examples of the number of times I have seen broken or illogical even very bad processes.

So to share my love to all the Professor's readers today - I will concentrate on just two aspects. Page Weight and Browser Window size.

There are a lot of people out there who are waiting for great content. The typical user is ADHD. Ten Seconds and you have lost him. For travel ecomm sites the engine is typically going to take about 5-10 seconds to load new content. Cached content can be served a lot faster but then when its cached its out of date data. Lots of things to consider when making a decision. My basic rule of thumb is don't confuse, lie or delay providing information.

So back to my basic two peeves today.

Page Weight - what is the ideal page weight? Today most people are serving up pages in the 100K range. I try to advise people who are outside of the USA to try and bring it in at under 70K. To justify pages that often exceed 150K, the websites try to justify their behaviour to their users by using the quoted speeds of upload/download. Yet the speeds of download range across the board. I use a rule that says take the maximum quoted bandwidth and divide by 4. That gives you the true speed that the user will experience in serving up that home page you spent all that money on. Page Weight is however not the only criteria in loading a page. Consider which bits of information are useful to the consumer. Ajax pages are vile terrible things but quite useful. Flash pages are just vile terrible things. If you can use techniques for speedier loading of the important information first. (For example the commit button shouldn't be the last thing that loads!!!). For a good article on page weights and what you can do about things - go here.

Now my other real peeve is the poor use of real estate. We have now several issues related to screen real estate.

There are a greater number of mobile users. They are not all using the big Dell Notebooks. They are using iphones and crackberries. The proliferation of small PCs is also an issue. They are using very slow 3G connections and a small aka slow processor speed netbook. Even public Wifi is slow - frequently I see 3G speeds and Wifi at the same page serving rate. (That is not because 3G is fast - its because the wifi is slow). if you have not mobilized your site in some way shape or form you are looking out on a lot of users. In many countries there are many times the number of mobile users than fixed users. Bear that in mind when designing your apps.

Also the growth of letter box format screens has advanced significantly. For full stats from the official source (W3C) go to their website for a summary of the formats and browser shares etc. The nice thing is that now you can interpret this data using information from Google Labs (which is analogous to the W3C) data. For this you can load the Browser Size screen template. I am amazed at how many sites fell outside the 90% window. Tsk Tsk. Forcing a user to scroll around your page is a NO-NO!

So treat this as a little Valentine's day card from the Professor to all of you.

Enjoy the day with your loved ones.

Cheers (and Kisses)

No comments: