blog

Photo of the house from the gate

We're nearly done building our replica villa on the Kapiti Coast. This is my blog which has been taken over by updates on the project. You can also see some pics and some technical stuff about systems, insulation, home-networking and the like.

I also use several online forums, interested in folk attempting similar things. (I post as "phptek")

Webstock 09

Posted: 24-02-09

If I took anything away from Webstock 09, it was above all else to cement in what I already knew and the addition of a "shine" to them - "them" being:

To make my stuff on the web just work for as many people as possible. This is something I already try to do, but too often whizzy javascript or time pressures detract me from going all the way to making something truly accessible for example.

Imagine if you will, entering a website or interacting with a Web Application (Google Maps, GMail etc) that Just Worked:

Each link or button selected delivered exactly what it promised and nothing more.

The subsequent interface met your expectations and detracted not one iota from them.

None of any interaction from any user, seemed like it was just a little bit like hard work.

Here then, in this vain of slick, eminently usable user-interfaces, are my musings on Webstock 09.

Jane McGonical said that people are waking up to the fact that amassing materialistic possessions is indeed not what life is about. Are they really!? I thought it was just me!

Matt Biddulph spoke about message queuing in the back-end of web-applications. The core of what he was saying (subjectively of course) I took as re-assessing how your applications function - right from base-assumptions. This latter behavioural facet is something I'm actually very good at. It just seems to others like I'm asking inane questions.

What I'm actually doing is questioning the fundamental precepts of the current system or context.

This is supposed to end in a more efficient way of doing things.

In a conventional web-application scenario, the user submits a form, the server processes everything to do with that submission and when complete, presents the user with a confirmation.

The idea of messaging is simple (as it should be):

The user submits the form, and the application then decides what are priority tasks and which can - quite simply - wait.

It is the latter that are described or marked-up appropriately and sent "out there" as a "message" in a queue.

The queue can then be dipped-into periodically by some daemon or background process which processes the next item on it.

One result is that the user sees his confirmations faster, precisely because less processing had to go on at that instant.

Derek Featherstone has years of experience in the field of Website accessibility. In addition to the other speakers mentioned, it was Derek's Workshop on the Wednesday - and a single slide at that - which sticks in my mind as a demonstration of the difference between standards compliant accessibility and truly usable accessibility.

Derek showed us a slide of a wall sign outside the offices of the Deaf-Blind Institute in some town or other. It had the contrasted lettering for colorblind people - light text on a darker background, Braille and raised text for blind people and the latter two were inset onto an angled surface, so readers didn't need to strain their wrists flat against the wall in order to run their fingers over the text and read it.

Are you starting to see what I mean by "eminently usable"?

Another theme was that HTML or XHTML; it doesn't matter. They both came into this world to mark-up documents, y'know, headings, lists, underlines and paragraphs. What they weren't designed to do was mark-up applications, y'know; Complex interface elements, sections of dynamic content, multi-level navigation.

Up until now, Web Developers have effectively been kludging HTML with JavaScript and CSS to co-erce it into doing something it was never designed to do - if it was, we wouldn't need to kludge-it like this would we?

One answer is on its way, but will of course take years and years to be anyway near widely implemented - that is HTML5. While my own knowledge of HTML5 elements is extremely small, the general idea is that the elements defined for it will be designed to markup Documents and Applications for the web.

But why bother to mark-up in this way if we can already mimic this behaviour with JavaScript you may ask? Well since I'm still on the subject of accessibility , the answer is therefore before you my friend:

While screenreaders can indeed interact with javascript, inadequately written code means that the application in question can be rendered totally inaccessible, even if the markup itself is 100% standards compliant XHTML1.0.

Simplicity is king as Mr Featherstone kindly reminded us (but not in these words, they're mine..!) so when looking at your site or app as a three tiered entity on the client side - thus:

  1. HTML for structure
  2. CSS for visual (and auditory) layout & presentation
  3. JavaScript for behaviour


..you should try to achieve all you can in the first or second layers. Jumping to the third and using javascript/AJAX just because you can is very probably the wrong approach from more than one perspective. This becomes even more critical when you see that HTML5 will not be widely implemented for years and the stop-gap measure ARIA (Accessible Rich Internet Applications) is lightly supported in only the very latest of the modern web browsers (Fire fox 3, Safari 3, Opera 9.5 and IE8 beta if memory serves).

As always after a conference such as Webstock, I discover to my dismay a lot of pretty much at best uncategorisable, at worst unreadable - scrawl, on my (waste of time) conference/venue branded notepad.

Here's a list of them, linked where possible: