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.

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.

Thursday

After a pre-conference meeting tuesday at Mirabeau (Where Chris Heilmann and Peter Paul Koch hinted at what was to come) Thursday started with two talks concentrating on the mobile web. Summarized: Webkit is not webkit (and webkit is just one of the mobile browsers) and mobile devices are more different from each-other than desktop PC’s. So, developing for the mobile web (and not just the iPhone) is challenging.

Next on was the presentation with the most hilarious title of all (and arguably content also) by Chris Heilman: Of Hamsters, Feature Creatures and Missed Opportunities. Some highlights: Be passionate about what you do as a developer or leave that aspect for someone who is. Don’t reinvent the wheel just because you like to apply a (your favorite) technique. The web is information, not sites. The feature creature (just check the slides) and YQL, which basically is querying the web and looks really great (kinda missed out on that one having done a lot of back-end development lately).

After the lunch-break Stephen Hay covered three drafts that exist for CSS layouts that will take away the limitations that exist today: CSS3-Grid (Microsoft), CSS3-Flexbox (Mozilla) and CSS3-Layout (W3C). Very interesting as it makes very clear that, although a vast improvement over tables, today’s CSS capabilities with respect to layout (and thereby the way we work) are far from perfect.
Following Stephen, John Resig went in-depth on javascript testing techniques covering unit testing as well as functional testing. Furthermore an interesting testing concept that can be used for testing JS frameworks was introduced: TestSwarm. Steve Souders, fully aware of being the last barrier between the crowd and the after-party, concluded the day with some interesting techniques that can help speed up websites.

Friday

Douglas Crockford kicked of day 2 with a presentation about javascript security. He explained Object Capapability Design, a security model in which objects can only access objects they have a reference too. I liked the part about using ‘facet objects’ to control whether or not references are maintained or broken. After that Pete LePage showed some HTML5 stuff that’s found it’s way into IE8. The presentation had a (not the only one) funny moment where in Expression Web’s IE6 emulation it showed the fronteers website with the ‘your (IE6) browser is obsolete’ warning. Jonathan Snook then extensively covered the topic of getting fonts on the web. It was very interesting that he addressed the licensing issues involved with using tools like sIFR. Something I think is often overlooked.

After the lunch Robbert Broersma lifted the hood (just slightly) of the engine powering the Xopus editor. He showed some tips with regard to improving and maintaining performance, most notably Google for ‘leak free closures’. Thomas Fuchs took over and explained some of the animation scripting going on in scripty2 and showcased his lightweight animation library emile.js.

Next presentation was by Nicolle Sullivan and the title ‘Object Oriented CSS’ made me quite curious. Rightly so cause I really enjoyed this presentation. OOP concepts like code reuse, encapsulation, singletons and inheritance were put into the perspective of organizing CSS. Quite a different approach really but it addresses problems I think a lot off css-coders can relate to. I found it interesting to realize that OOP thinking, which for me is day-to-day practice when working with PHP, somehow hadn’t made it to my CSS approach. At least not to the extent as shown in this presentation.

The day concluded with Dion Almaer and Ben Galbraith talking about ‘The Future of Web Applications’. Very entertaining presentation covering new technologies like Google Closure Tools (Quoting: ‘If you want to write code that looks like java then it’s a great tool for you’), canvas, web workers and webGL.

Conclusion: Very nice conference with indeed a stellar line-up. As always the hallway sessions are not to be underestimated as I usually (unless I’m tired or need to get things done) find it interesting to talk to other people and pick up some new ideas or approaches. To conclude with the closing presentation’s very fitting last commandments (yes, I wrote those down):

• Thou shalt make thine interfaces responsive
• Thou shalt keep the data of thy users holy

• Twitter: #fronteers09
• Flickr: fronteers09

Presentations

Just to show that YQL literally is ‘querying the web’: The YQL below extracts from the Fronteers 2009 presentations page those elements in the list that have a link. And… it always returns valid xml which makes it ideal for parsing the HTML cruft generated by some applications.

SELECT * FROM html 
WHERE url="http://fronteers.nl/blog/2009/11/presentations-fronteers-2009" 
AND xpath="//ol/li/p/a/ancestor::li"

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.

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.

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

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!

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

Microsoft – User Experience on the web

First speaker was Bram Veenhof, of whom I allready attended a presentation two months ago. Here the available time was more limited so less subjects were covered. He started with some coverage on the forthcoming Windows 7. Interesting features were addressed like: Dockable windows, swappable taskbar buttons and functionallity in preview windows. Next on was Silverlight and most specifically the video and deepzoom capabilities.

Two parts that were both interesting in their own right but not really connected to each other. In my opinion he had better addressed the XAML, Javascript integration some more. I think that is one of the strong points of Silverlight when it comes to smooth integration in a PHP driven application.

Adobe – Flex/AIR

Next on was Mihai Corlan, Adobe Platform Evangelist as he described himself. First part of his presentation was about Flex. For me it’s been a while since I’ve done Flash Development so I was curious about what’s happening on the Adobe front. Mihai summarized Flex as ‘Just another way to create a Flash app’. The Flex platform consists of:

• 2 Languages: MXML and Actionscript 3
• Compilers
• Rich Component Library
• Debuggers
• Flex SDK (Open Source)
• Flex Builder IDE (Eclipse so it runs nice alongside Zend Studio)

As for the benefit of RIA’s he showed a little demo of a very graphical intuitive interface allowing users to report details about car damage.

After the topic was Adobe Air. Adobe Air allows web developers to develop beyond the browser. Api’s like file access, drag & drop, allow for desktop apps to be developed using techniques familiar to Flash/Flex developers. Very interesting and probably much easier than starting to learn writing apps in Objective C or Java.

The link to PHP was addressed by the way Flex and Air applications communicate with online back-end software: REST, Web Services and RPC. Areas where PHP is at it’s best, especially with the arrival of Zend Framework’s AMF component. The AMF component provides RPC connectivity that is easy to implement and very efficient.

Javascript – 8 Reasons every PHP developer should love it

After a good lunch and a couple of short talks by phpwomen, fronteers and phpGG it was Boy Baukema’s (Ibuildings) turn to (try to) make PHP developers like Javascript. On the technical side he pointed out some similarities like closures and closures. Furthermore he showed statics telling us that less than 1% of today’s user agents don’t support javascript. This includes search engines and paranoids. After his presentation he repeated his question about how many of us like javascript. I couldn’t tell much difference but then again, 40 minutes is very little time to convert server-side freaks. In my opinion liking javascript starts with liking to create a good user experience. If you do, you’ll probably also like Flash and Silverlight. If you don’t, no problem. Leave it to people who do.

The frontend is your friend

The last presentation of the day was given by Robert Jan Verkade (Eend). Interesting and graphically of high quality. Something tells me Robert Jan is a fan of Queen. He focused on the different stakeholders involved in a project and how they interact: The front-end (HTML, CSS, JS), The back-end (PHP), the users and the contractor. He showed some examples of good and bad practice. Most notable advices on of good practice where reducing the number of external css and javascript files and placing javascript at the bottom of the page. Furthermore he had some good tips on how php- and frontend developers can make eachother’s lives a bit easier. (PHP-ers: Don’t mess with the HTML! :)).

He put quite some emphasis on valid HTML so I couldn’t resist asking about wether he meant ‘valid’ or ‘well formed’ and what his opinion was on using non-W3C attributes to drive javascript behaviour (something I’m very pragmatic about). An entirely different discussion that doesn’t need a winner but I was curious if he or someone else would have some interesting (for me new) views on the subject. Somebody in the audience mentioned that custom attributes are part of the HTML5 recommendation. So the topic is definitively ‘out there’.

Conclusion: A nice day. Interesting subject and interesting presentations. And of course it’s nice to meet some new people working in this field. As it pointed out phpGG has just recently become more active again after having been dormant for a long period. So on that part 2009 looks promising.

For the web 2.0 afficionados: Flickr & Twitter

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