Journal2008.12.16

Elastic usability

Amazon.co.uk has always been gifted with an elastic layout, that is, a page layout that resizes to fill the full width of the browser viewport. The home page HTML has recently been improved, dragging the elastic layout from the table-based mess it once was, kicking and screaming into the CSS era. Bravo.

In support of elasticity

One of the reasons for implementing an elastic layout is that it will fill the viewport on all resolutions, thereby giving all users an optimal browsing experience. In the world of e-commerce, and particularly with Amazon's rich inventory range, showing more items on a page will likely convert to a higher number of sales.

When casually browsing, like many others, I have my browser open at almost the full width of my 1680px monitor. Most site layouts are centred horizontally and employ a fixed width (or a maximum width, at least) to keep line lengths short and give pixel precision for replicating the designer's hard work. However Amazon spills across my screen and fills my eyes with glorious Christmas cheer.

Only, upon reaching the home page, I had a surprise when I couldn't see the Search bar usually towards the top and left of the header area. It was there, but I looked straight past it. On a wide screen the search box expands to fill the void, visually becoming a series of horizontal keylines; almost part of the visual design.

At the wider size my eye doesn't scan to the far right to see the orange "Go" button, and I miss that it is a search box at all:

Affordance

The wider search box reduces the level of interactive affordance. Affordance is the quality of an interface suggesting its level of interactivity. In this example the affordance of the search box is reduced in two ways:

1. The keylines and white background appear as more of a design feature than an interface element, thereby masking its functionality entirely
2. A longer text box suggests to a user that a longer search phrase is expected of them

Repeat visitors to Amazon will know the location of the search from previous visits. However a new visitor could mean that users miss the search entirely. Search boxes on other sites tend to be a lot narrower — Google for example — therefore a user may scan for something of a similar size.

This second point above is important, since having to type a longer search phrase is likely have the result that the phrase is either overly specific or overly vague. Both of these have the effect that the search results are likely to be less relevant, therefore providing a poorer searching experience.

Max-width and the elastic limit

This simple interface problem can be solved by applying a maximum width to the search box. A maximum width would ensure that the input element remains elastic up to a certain width, above which a fixed size is be used.

The max-width property in CSS allows developers to achieve this with ease (although a hack for Internet Explorer 6 is required, naturally):

input.search {
    max-width: 300px;
}

Although an arbitrary width could be used, this should ideally be a direct result of both user testing and analysis of search logs to determine average search phrase lengths with the highest conversion rates.

Have we reached the elastic limit?

Although the implementation of elastic layouts is not new, there has been recent renewed discussion of the future of elastic widths. The latest versions of major browsers: Internet Explorer 7 and 8, Firefox 3, Safari 3 and Opera 9, include resizing or zooming functionality to scale pages up when fixed pixel font sizes and widths are used. This has the effect of making elastic and liquid layouts redundant, since the browser is doing the hard work so the CSS developer doesn't need to.

I borrow from the WCAG 1.0 guidelines the often-cited phrase "until user agents support...". In the context of WCAG 1.0, this terminology is used to suggest that the recommendations are making up for shortfalls in user agents (browsers and the like); and once the problems are solved by the user agents natively, the guideline essentially becomes irrelevant to a developer.

Using the same principle, it is my opinion that this usability and accessibility problem is now being solved by the browser manufacturers (albeit with varying degrees of success). As designers and developers we shouldn't feel guilty when implementing fixed width layouts. Not one ounce.