Posts Tagged ‘javascript’

Usability: Autofocus and not breaking the backspace-button

Tibo BeijenMonday, March 14th, 2011

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.

Fronteers 2009

Tibo BeijenSaturday, November 7th, 2009

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.

Taming the Javascript event scope: Closures

Tibo BeijenMonday, July 27th, 2009

When doing client-side developing there are times that jQuery’s get-this-do-that nature doesn’t provide all that is needed. For more complex applications I usually find myself creating javascript objects that ‘control’ a specific part of the page’s interaction. In the objects the application’s state is tracked, references to other objects (could be relevant DOM nodes) are stored and event handlers are set.

One of the problems typically encountered when dealing with javascript event handlers is that they have their own take on the ‘this’ keyword. Closures to the rescue.

Annoying banners: A plea for quality

Tibo BeijenMonday, April 27th, 2009

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 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

T-Mobile banner on

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:

  • 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 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;">

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.

Jumping in and out of jQuery land

Tibo BeijenThursday, April 2nd, 2009

Recently I started using jQuery in some projects. In past projects I have mainly been using Prototype and the fact that jQuery also has a $() function made me feel at home right away. That same fact put me a bit off-guard as both functions are in fact quite different:

  • Prototype extends the selected HTML node with added functionality and returns it. Argument should be a HTML node or element id.
  • jQuery selects the HTML node (or nodes) and stores the selection in a jQuery object, which then is returned. Argument should be a css-like selector.

So, as opposed to Prototype, jQuery’s $() method can select a single element as well as a collection of elements. The existence of Prototype’s $$() function also kind of suggests that Prototype’s $() doesn’t do that. And… when passing just an id to jQuery’s $() (e.g. $(‘myDiv’)) it is discovered soon enough that nothing is selected but air.

By using jQuery’s $() functionwe’re leaving the DOM-zone and enter jQuery land. Although jQuery can do a lot, situations might occur where one needs to get the ‘real’ DOM elements. For instance, to pass them as argument to components that don’t talk jQuery. Luckily it’s just as easy to go back, by using the get() accessor.

Some simplified HTML code example boxes:

<div class="codeBox">
    <a href="#">copy to clipboard</a>
    <code>Some code</code>
<div class="codeBox">
    <a href="#">copy to clipboard</a>
    <code>More code</code>

Accompanied by the following javascript:

function initCodeBox()
    $('.codeBox a').bind('click',function() {
        var htmlNode = $(this).siblings('code').get(0);
        if (htmlNode) copyContentsToClipboard(htmlNode);
        return false;
function copyContentsToClipboard(htmlNode)
        // js selecting the text contents of a DOM node, simplified to: 

It’s clear that, as long as existing code doesn’t conflict with the $() function, it’s very easy to start using jQuery in existing projects.

Fronteers: Meeting march 10th

Tibo BeijenSunday, March 15th, 2009

At the PHPgg Frontend Special I first heard of Fronteers, an association of dutch front-end developers. Past tuesday they had a meeting at Media College in Amsterdam. As meetings are open for non(yet)-members it was a nice opportunity to get to know more about Fronteers. Two topics were scheduled: jQuery and SUAVE.


Until now I have mainly used the Prototype framework for Javascript projects. As the prototype library, escpecially when bundled with scriptaculous, is quite ‘big’ I was interested in hearing some more about the ‘lean and mean’ jQuery. In a short (but focussed) presentation of Edwin Martin some of the key aspects of jQuery were illustrated, most notably: Method chaining, Plugins (nice for keeping things organised) and Live events (curious about performance). The jQuery motto ‘do more, write less’ definitely stands although the functionality seems really focused on selecting, modifying and event-binding. I was missing Prototype’s class inheritance but as I read from the Fronteers meeting report that’s being worked in in the form of Classy Query.


Next was a presentation, delivered by Marcel Beumer and Vincent Hillenbrink, about Suave, a stand-alone front-end. It’s a MVC based framework that allows front-end developers to communicate with a ‘back-end’ that exists solely in the viewer’s browser. This way front-end developers can start creating templates and interaction and show working versions, without being dependent on properly functioning back-end software. In the background there is some XSLT databound templating going on thereby allowing for easy integration with back-end software once it’s ready. Suave isn’t finished yet so no online information is available. They aim at releasing a first version in about half a year, bundled with examples demonstrating it’s potential.

Of course there was plenty of time after the presentations to meet some people and chat with co-front-end-developers. Nice meeting!

PHPgg Frontend Special

Tibo BeijenSunday, February 8th, 2009

Last saturday (2009 jan 24th) I attended the phpGG Frontend Special. phpGG stands for ‘PHP Gebruikersgroep’ which translates to ‘PHP user group’. The meeting was held in a nice little theater in The Hague and was attended by what looked like about 50 people. The four main presentations scheduled:

  • Microsoft – User Experience on the web
  • Adobe – Flex/AIR
  • Javascript – 8 Reasons every PHP developer should love it
  • The frontend is your friend


FireScope – Firebug extended

Tibo BeijenWednesday, January 28th, 2009

Today I stumbled across an interesting new Firefox extension: FireScope. It’s developed by Sitepoint, a site I visit regularly. I was aware of their reference material on html, css and javascript and now they use that content to feed this extension. FireScope is an extension to Firebug, assumably known and installed by anyone interested in FireScope. On the official firefox add-ons page it has the status ‘experimental’ and hence requires logging in. On the FireScope page it can be installed after selecting ‘allow’ on the Firefox warning. It looks like Firefox for developers got even better…

Bye bye old site, welcome new site

Tibo BeijenThursday, November 6th, 2008

As it looks like the blogging phenomenon is there to stay I finally considered it safe to take my first steps into the blogosphere. Until recently this domain showed the website I developed in 2003 and haven’t updated since. It’s a technology-push javascript showcase. Something I liked back then (the days when dHTML was fancy) but would never build again now. For starters: It’s not accessible and thereby not search engine friendly. The popups, if they get past popup-blockers, don’t help usability either. There are two things I still like though:

  • It still works. The css, the javascript that keeps everything in place, the event-handling. It proves that standard-compliance can get you far.
  • It uses a technique similar to what now is called Ajax. Content is loaded by javascript using hidden iFrames and then moved to the visible areas. I liked the days when there was less talking about Ajax…

Judge for yourself.

Maybe before the end of the decade I’ll look into that ‘twitter’ I keep reading about…