Archive for February, 2010

The pagefold, does it exist?

Posted in Uncategorized on February 23rd, 2010 by Chris Gray – 1 Comment

This week we came across this tweet:

Cennyd Bowles Twitter Update, reads: "There's no fold, you say? Do you keep listening to an album if the first three songs are shit? There's you fold"

There is some lively debate about the actual existence of the pagefold on websites (see http://www.thereisnopagefold.com/).  The main arguments as far as I can tell, is that the pagefold does not apply to the web because, unlike the physical world where a newspaper fold applies to all readers, online users can view pages in a variety of screen resolutions which alter the placement of the fold and there is a scroll bar on most websites to find more content.

My take is a little more pragmatic;

When we observe users in labs, time and time again we see some people not using the scroll bar.  While good designs help to avoid this, it does happen.  As such we recommend to our clients that they present key information (not all content) above the page fold in common screen resolution formats (eg. 1024 by 768).

Whilst I agree that we should think about websites outside of the newspaper paradigm I do believe that talking about the fold encourages website owners to think about the placement of key information on the page to make it easier for users to undertake key activities.

What do you think?

Photo Friday: Kaffe, Coffi, Kahve…

Posted in Photo Friday on February 19th, 2010 by Owen Hodda – Be the first to comment

There are some serious coffee drinkers in the UsabilityOne office, and a number of us are fairly fussy about our coffees too. So when our new coffee machine arrived we were keen to fiddle with the settings and configure it just the way we like it.

Coffee Machine Control Panel
Several weeks later, we still haven’t worked out how to do that. We do know how to change the language on the menu though.

When designing an interface, design for the most likely and frequent activities your users will undertake.

Helping users find their way

Posted in Usability Tips on February 15th, 2010 by Jo Squire – Be the first to comment

Mapping applications are a great way to present your contact information, particularly when your company has multiple stores or locations. However, if executed poorly they can actually add to the difficulty of you customers finding your stores. The following are some important design considerations when presenting information with a map.

Take care when starting on a map at the country level as the only way to find locations. Maps like the one below typically rely on visitors zooming and panning controls of that particular mapping application, something not all users are familiar with. Forcing visitors to use the map to drill-down from a country to suburb level can also be time consuming and error prone. When testing the example below, participants who were experienced with using online maps took an average of 19 mouse movements to locate the South Melbourne store.
map1
Users like to be given options so they can choose a means of interaction that suits them best. Some users prefer drilling down using a map, others do not. Displaying alternatives to the map, such as a postcode search or state selection, allows users to choose the option that best meets their needs.

Below is a good example where users are given flexible choices in locating their nearest store. They can enter their postcode for an exact match, drill-down by state or interact with the map. The state selector still gives users an overview of locations, but eliminates extensive zooming on the map from the country level.
useful_map

As with all features of your site; design your mapping feature so that the user can use it as they wish. Offering multiple ways to interact with the feature means users will be able to find one that best suits them.

Self-serve credit crunch

Posted in Usability Tips on February 5th, 2010 by Shefik Bey – 4 Comments
Woolworths Self-Serve Checkout
I hadn’t used the self-serve checkout at my local Woollies as my trolley is normally stacked high, however, this weekend I seized the chance to finally test it out when I dropped in to purchase a few essential items.

The process was slower than I had expected it to be, but the real crunch came at the point of making a payment; my credit card signature needed to be assessed by the self-serve assistant.  It was apparent after a moment or two of scratching my head and looking about like a idiot, that it was I (rather than the system) that was required to notify an assistant that they were required to complete this transaction.  As the assistant was busy attending other customers I had to wait, for what seemed a long time, for my turn.  This seemed completely counter-productive.

I have used my credit card in a number of other comparative self-serve systems recently including car park and public transport ticketing machines.  In these instances signature validation was not required.  Of course, Woollies level of security with signature assessment is a notch above these systems, however, this experience for a first time user will undoubtably put many off from self-serving again.

When you consider how vital credit cards are for self-serve transitional purchasing, surely some revision is required to aid consumer adoption of the service?  I would encourage Woollies to consider one of the following:

  1. Scrap the signature validation completely (consistent with comparative systems), or
  2. Electronically match/validate the signature.
Whenever you develop a system that puts the user in control, you must ensure they are in complete control.  As the saying goes ‘a chain is only as strong as its weakest link’, and this too is true of checkout systems, registration forms and online transactions. If in the process of making something easier and more streamlined you introduce a step that is hard or frustrating for users, then you have not successfully achieved your goal.  It is important to always be reviewing and assessing each step of a new process to ensure this does not happen.