TBNL

A while ago during a project we were asked to implement autofocus on the generic search field that every page in the application has. At a first glance a pretty straightforward task, from a technical perspective that is. Not from a user perspective, as indicated by a colleague mentioning his dislike of such autofocus fields “because they prevent backspace going to the previous page”. In this post I will outline some usability considerations and conclude with a jQuery plugin that will take away some of the possible hindrance of autofocusing a field.

Usability considerations

There are some things to consider to determine if such automatic focusing of a search field is actually helpful to the user navigating to the page. Who is the user?

As I was discussing this case with an interaction designer friend (dutch) of mine, he brought up the idea of mimicking the browser’s backspace behaviour, and discussing it further we concluded that this might be useful in some cases but is definitely not a ‘one size fits all’ solution.

Different goals

Different users will probably have different goals when navigating to a page. On the google page or a login screen the majority of the users’ goal is to type something in the first input field. On a lot of other pages this won’t be so obvious. Question then is: Will focusing a search field, if not help, instead hinder the user? For example: A user might have navigated to a page by accident. In that case not being able to go to the previous page by pressing ‘backspace’ might indeed hinder the user.

Different expectations

Not every user navigates to the previous page by using ‘backspace’, some might not even be aware of that possibility. Not every user expects text entered to automatically appear in an input field. Some users might have enabled the option to directly find text in a page when typing text and find this functionality suddenly broken.

Dive into HTML5 has some other nice examples of how autofocus might not be helpful.

What size fits all?

As mentioned before, there is no ‘one size fits all’ solution. Questions that need to be asked include:

• How many users might be helped by adding autofocus to a common search field?
• How many users might instead be hindered by autofocus?
• Are there pages where autofocus on more specific fields (like the main form) is needed which will break consistency throughout the site?

This means studying your site, the target audience, their goals and expectations and based on that finding a balance.

Restoring the backspace: jQuery autofocusBackspace plugin

If the conclusion of aforementioned considerations is that autofocus indeed is helpful, there is more than one way to achieve this: The first is using the HTML5 autofocus attribute. Another is using javascript to focus the field.

As not all browsers support the autofocus attribute yet, and we wanted to preserve the browser’s backspace functionality, I created a jQuery plugin that does just that:

• It focuses the first matching element
• It responds to ‘backspace’ by navigating to the previous page.
  • Only until a user has entered text
  • Only until the element loses focus

Refer to GitHub for the jQuery plugin autospaceBackspace.

Feel free to report problems or ideas for improvement.

About five months after having enjoyed server-side talks at DPC09 it was now time for front-end matters: Fronteers 2009. There’s no exaggeration in the description on the fronteers site: A stellar line up of speakers who are at the front of what’s happening in web-development. Generally speaking I really liked most of the talks and some of them pointed me to some interesting new techniques and ideas.

Slides of the presentation (if online) are listed at the Fronteers site and at the end of this post (same content, read along). I’ll briefly recap some of the (for me that is) most interesting parts.
(more…)

In software development projects, paying proper attention to usability aspects, can greatly help ‘getting the message functionality across’. Usability is a field of expertise on its own and involves techniques like wireframes, prototyping and card sorting. Not every project is the same and (sadly) lack of time or budget can prevent specialized interaction designers to be involved in the project. This means that making the application ‘usable’ becomes the responsibility of graphic designers or developers (or it is neglected altogether). Not an easy combination of tasks…
(more…)

Banners play an essential role in many site’s business models so they are an inevitable price paid for all the free content that is available on the internet. To get a user’s attention a lot of practices are employed like animation, placement or sound (horrible). Today I stumbled on a T-mobile advert on the site nu.nl that indeed attracts a lot of attention but does so in a questionable way: It makes using the visited site almost impossible. (Not a new phenomenon and it’s certainly not the first time I encounter such a banner).

The T-mobile banner is positioned at the bottom of the viewport and is kept in place by javascript or actionscript. This means that during scrolling the banner shakes because the script reacts to the scroll event. No awards won but not a real problem either. But what is bad is the fact that in the orange area (note the little pun there) no link can be clicked. Something I didn’t notice at first resulting in rapid agitated clicking. See screenshot below:

T-Mobile banner on nu.nl

As a ‘normal’ visitor that is just annoying but as a web-professional it irritates me to a great extend that there seems to be no technical need for this misbehaviour whatsoever. So what goes wrong? On a first glance there seem to be four roles involved:

• Nu.nl: They need adds but it seems unlikely they want banners to block parts of their site and thereby cause user frustration.
• The banner merchant. Doubleclick, adclick or whatever their names are. I’m not really into the advertisement business but I wouldn’t be surprised if different advertisement programs exist that site publishers can use: flashy or not, type of products promoted, sound or not, full page mayhem or not. That sort of differentiations. Normally adds on nu.nl aren’t this annoying so something might have gone wrong there.
• The developer or company developing the banner. Perhaps there’s a tight deadline. Perhaps technical knowledge is lacking. Maybe they just don’t care…
• The advertiser, in this case T-Mobile. Bottom line is: they want to get visitors to their site. But perhaps reputation might be a consideration. I think in most cases that the people reviewing a banner proposol don’t have the knowledge to determine that a banner has these unwanted technical side-effects. Or the prototype presented doesn’t show the problems.

So somewhere in the process things go wrong, be it a lack of knowledge or a lack of interest for the end-user. Sadly the result is a lack of quality having bad usability as a consequence.

To conclude this criticism in a more positive and constructive fashion I’ve made a quick css proof of concept showing that it’s perfectly possible to achieve the layout while preserving click access to the underlying site.

Bottom aligned banner proof of concept

It’s positioning is now done by using css position:absolute but could just as well have been javascript. The demo took about 15 minutes to make while watching tv. I haven’t tested it on IE6 so expect about 2 hours needed for that but even then development time seems reasonable. The advertisment html part is displayed below.

<div id="banner" style="background-color:purple;position:fixed;bottom:0;width:100%;height:80px;">
	<div id="bannerCenter" style="width:760px;height:80px;position:relative;margin:0 auto;background-color:red;">
		<div id="phone" style="position:absolute;width:100px;height:160px;left:660px;top:-100px;background-color:#666;z-index"100;">
		</div>
	</div>
</div>
</body>

Of course the real world is more complicated than can be described in a short article but it’s obvious that the examined banner is sub-par. In my opinion it would be wise, or at least nice, to take the user a bit more seriously.

Over the years the display size of the average computer screen has increased. As a consequence nowadays more and more websites are designed with a 1024 width screen in mind. For example: BBC, Adobe and The New York Times. With at least 78% of the users using a 1024 or higher resolution screen the time seems right to move away from the 800px designs. But what about accessibility? And usability? And is full page zooming really better than text scaling?
(more…)

Past saturday (february 7th) I visited Engineering World, a conference organised by Sogeti, as both attendant and speaker. With my colleague Richard de Vries I delivered a presentation on the topic usability. I attended some interesing presentations of which two were about methodologies: One about SCRUM and the closing keynote by Ian Spence of Ivar Jacobsen International about Agile. The latter with all of the myths about Agile (Doesn’t matter where the team is going, as long as it’s going somewhere) being tackled in true Mythbuster fashion. Another (and totally different) presentation was about ‘augmented reality’ and was delivered by Touching Media. Picture yourself (in your younger years) in a Lego store, holding a box in front of a camera, and seeing yourself on screen with a 3D representation of the Lego model coming out of the box. Nice.