TBNL » jquery

Usability: Autofocus and not breaking the backspace-button

Tibo Beijen — Mon, 14 Mar 2011 11:32:39 +0000

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.

Taming the Javascript event scope: Closures

Tibo Beijen — Mon, 27 Jul 2009 13:52:44 +0000

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.

A simple (and rather useless) example:

html:

<script language="javascript" type="text/javascript">
$(document).ready(function(){
    $('#scope div').each(function(idx) {
        var btnController = new controllerExample(this,idx);
    })
});
script>
head>
<body>
<div id="scope">
    <div>
        <p>p>
        <input type="button" value="btn 1" />
    div>
    <div>
        <p>p>
        <input type="button" value="btn 2" />
    div>
div>

javascript:

function controllerExample(node,idx)
{
    this.node = node;
    this.idx = idx;
    this.clickCount = 0;
 
    this.setEventHandlers();
}
controllerExample.prototype.setEventHandlers = function()
{
      $(this.node).find('input').bind('click',this.handleClick);
}
controllerExample.prototype.handleClick = function(event)
{
    this.clickCount++;
    $(this.node).find('p').text(
        'Button is clicked '+this.clickCount+' time(s)'
    );
}

‘this’ is wrong

Now that doesn’t work… When the click event fires the handleClick() function is executed but the scope is not the controllerExample instance. On execution the ‘this’ keyword points to the input element. So we see ‘Button is clicked NaN time(s)’.

The Prototype javascript library has a solution for this by extending the basic function object type with the bind() and bindAsEventListener() methods. Very nice but to include Prototype just for that… bad idea. It’s perfectly possible to separately implement a similar bind() function method but that still creates an additional (besides jQuery) dependency for that method. Let’s keep the mess to a minimum and keep it ‘in’ the controllerExample object.

Closure

Prototype’s bind() function uses what is called a closure: A function defined within a function. The benefit is that the inner function, which in the following example is returned by the outer function, has access to the outer functions local variables after the outer function has returned.

Properly ‘binding’ the handleClick event handler now looks like this:

controllerExample.prototype.setEventHandlers = function()
{
    var _scope = this;
    var getHandleClick = function() {
        console.log(this); // window
        console.log(_scope); // controllerExample
        return function(event) {
            return _scope.handleClick.call(_scope,event);
        }
    }
    $(this.node).find('input').bind('click',getHandleClick());
}

getHandleClick() returns a function that, when executing, still has access to _scope which is the correct scope. The console.log lines are there to illustrate that inside the inner function we can’t use ‘this’. The getHandleClick() function has no object scope so it’s ‘this’ is the window scope. But the object scope can be passed into by copying ‘this’ to a new variable _scope and use that inside the closure.

More information about closures: Javascript closures 101 (basic) and This article on jibbering.com (advanced).

routeEvent

Now the above is fine if there’s just one or two event handlers to be added but is not really ‘generic’. So let’s create a more generic ‘routeEvent’ method that creates a closure for the eventHandler that is passed in:

controllerExample.prototype.setEventHandlers = function()
{
    $(this.node).find('input').bind(
        'click',
        this.routeEvent(this.handleClick)
    );
}
// ...
controllerExample.prototype.routeEvent = function(eventHandler)
{
    var _scope = this;
    return function(event) {
        return eventHandler.call(_scope,event);
    }
}

Now the handleClick() method will be called with the correct ‘this’ and is also provided with the jQuery event object.

A demo putting it al together can be seen here.

Jumping in and out of jQuery land

Tibo Beijen — Thu, 02 Apr 2009 21:34:59 +0000

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>
<div class="codeBox">
    <a href="#">copy to clipboard</a>
    <code>More code</code>
</div>

Accompanied by the following javascript:

$(document).ready(function(){
    initCodeBox();
});
 
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: 
    alert(htmlNode.innerHTML);
}

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 Beijen — Sun, 15 Mar 2009 10:04:20 +0000

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.

jQuery

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.

Suave

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!