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"

To help during development (or design) it helps to keep in mind that a user using an application is all about interaction and exchanging information. At any given moment while using an application, a user might wonder things like:

• What did that button do?
• What will this button do?
• What does this label mean?
• How can I find the page I’m looking for?

Summarized: action and information, past and future as illustrated below:

Usability: Application State Diagram

Four quadrants

I. Past actions

This translates to ‘feedback’. Is it at any point clear to the user what the application is doing or has done, following the user’s commands? Is the feedback form sent? Are modifications done through the CMS visible online? Is the application really still busy or is something going wrong?

II. Future actions

Feed forward. For a user to ‘trust’ an application he needs to be able to predict what will happen when he performs certain actions. Take for instance a webshop: After clicking ‘place order’, will there be a screen to review and possibly cancel the order process? Or, after saving a page in a CMS, will it be possible to preview a page before it’s visible on the live site?

III. Past information

This focuses mainly on how information is displayed at a given point. Is important information clearly recognizable? Is it clear what is displayed? For example a product page on a webshop: Can editorials and user comments be clearly distinguished?

IV. Future information

This covers navigation and thereby how all the information and possible interaction of an application is structured. To efficiently use an application a user needs to be able to predict where to find information and how to get there. This involves structuring navigation and perhaps also tailoring navigation to accommodate for common usage scenarios.

What this diagram does not

The above diagram focuses on the state of an application at a given point and therefore doesn’t look at the bigger picture. This means it doesn’t:

• Cover consistency throughout the application.
• Prioritize functionality.
• Match functionality with user goals.
• Look into characteristics of the targetted users (like experience with similar applications) or the environment the application is used in.

What this diagram can do

Taking back a step once in a while during development and applying this diagram on the application that is being created, can help to quickly point out certain usability flaws. This is especially true when there is no dedicated usability expert in the team. Having a certain amount of knowledge of the more elaborate checklists mentioned earlier will help. Besides being used as a quick evaluation tool this diagram can also be used to structure usability-related thoughts and ideas and predict their effectiveness. Hopefully that will help creating a better user experience.

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.

Screen resolution

Take the february 2009 stats of thecounter.com. Based on those stats a target resolution of 1024 seems reasonable: At least 78% of the people view websites at that resolution or higher.

Of course the need for the increased width depends on the specific elements that have to be displayed. When left- and right columns are narrow, a width of 1024 might lead to very long lines which are hard to read.

Accessibility guideline: text size

Accessibility guidelines (W3C WCAG 1.0 point 3.4) state that relative units are to be used when specifying text size. That way, users can easily adjust the size of text. For some time, browsers (except *sigh* IE6) allowed users to adjust the displayed text size by using key combinations or ctrl+scrollwheel. This posed a challenge to CSS coding as it wasn’t always easy to keep everything in place when text size was increased. Or, probably worse, text would flow out of the box and become unreadable. See below image of a page on eurogamer.net. In the left-column navigation and bottom parts of the page elements will overlap when text size is increased.

Eurogamer text size example

Nowadays quite some web browsers have replaced text scaling with page zooming. This definitely makes life easier for CSS coders. It will also help user experience when increasing text size because relative placement of elements is preserved, as opposed to situations where some columns are stretched in different amounts. But there is a side-effect.

The misinterpretation of statistics and its disastrous consequences

When a website already fills the entire viewport in it’s original size, as soon as display size is increased, horizontal scroll bars will appear and the rightmost content will move out of view. So now let’s turn the aforementioned stats around. At least 51% of the visitors have a screen resolution of 1024 or less. So basically this means that when a page is designed to have a minimum width of, say, 1000px, half of the visitors will have problems increasing the displayed size.

Although official accessibility standards don’t seem to mention horizontal scrolling, it’s safe to say that having to scroll horizontally doesn’t help accessibility. And from a usability perspective it’s most certainly bad practice.

Regarding accessibility standards not mentioning horizontal scrolling: I searched the standards document of the dutch government which includes all WCAG guidelines (and more). I searched for the words screen (dutch: scherm), horizontal (dutch: horiz) and scroll. Nothing. A downside of these kind of checklists: technology moves on continuously while standards only get update once every x years. But that’s a different subject…

Browser overview: Text scaling or Full page zooming?

Acknowledging this side-effect it’s good to know exactly how today’s browsers perform zooming. See the table below.

Browser zoom characteristics

Conclusion

Although stats suggest 1024 is a solid choice, it’s obvious that there are considerations to be taken into account. If liquid design with a minimum of 800px is not an option and one chooses to design for a (minimum) resolution of 1024px the least one can do is try to avoid putting essential navigation or use cues in the rightmost part of the site.

See image below of Play.com: The top part with the currency selectors and link to the visitor’s account-page do sticks to the right size of the screen.

In this case I think it’s a coincidence as the cart button does extend beyond the visible area. The selectors are positioned absolutely from the right size of a container that doesn’t have it’s css attribute position set to ‘relative’. So positioning is done with respect to the BODY element. Although that has a min-width of 990px it somehow works out this way.

Play.com header example

One last tip: IE7 keeps a centered column centered when zooming in, as opposed to Firefox and Opera. So when in IE7 horizontal scroll bars appear, bits are falling of the left side of the screen as well.