ContentedLife

I wrote this in reply to an insightful article by Jenni Tennison giving an insider’s view of the UK government’s current project to unify all of its websites into a single one. I agree with the doubts she raises about this project, because I’ve been there, done that before…

Some years ago, I worked on a long-term project which was funded by the then Public Record Office. When that institution was rebranded as the National Archives, complete with shiny new website, they decided that our hitherto independently-styled and -managed website must be rebranded to mimic theirs in look and feel.

This was far from easy, partly because their design had a horrendously messy implementation, and partly because (of course) it had been designed without any reference to us or how our data delivery might fit into it. It was imposed on us as a fait accompli, and we had to – somehow – squeeze our square peg into their round hole.

We spent a full year smashing our clean, lightweight design into pieces and gluing it back together in order to fit their restrictive, bloated one. I didn’t much enjoy doing it (can you tell?), but I like to think we did a good job.

Possibly too good. What we found when it went live is that users got confused: our site, now a subdomain of theirs, looked and felt so similar to the main site that users expected it to work in exactly the same way, but this was ultimately impossible as ours had a fundamentally different set of functions than theirs. Those areas where we overlapped had been made to work identically, but this just led to confusion where the functionality diverged.

One size does not fit all. And the more distance there is between those responsible for the design and management of a site, and those producing the content for it, the more likely it is that some of that content will be presented poorly, or not at all.

I don’t think people really want all government websites to look the same, or to be in the same domain¹. I think what they want is for information to be easy to find and easy to access. The best way to ensure that is to keep the designers and managers of the website as close as possible to the people producing the information. By all means have standards to ensure best practice, but keep them as minimal as possible, with a mechanism for those bound by them to suggest changes if they find them too restrictive.

And let different things look different, because that helps people to realise that they are different.

I’ve tentatively placed a toe aboard the AJAX bandwagon, thanks largely to Rails which makes it possible, even painless, to achieve AJAX functionality without having to learn Javascript.¹

While AJAX, done properly, can be a big win for Usability for those whose browsers support it, I am also concerned with issues of Accessibility, and indeed keeping things usable for those with non-AJAX browsers.

Standards-Schmandards have come up with some useful hints about how to make AJAX pages more accessible to screenreaders, such as providing an option to pop up an alert box instead of, or as well as, simply updating the page. This is good advice, but it’s only half the story. These methods don’t help those without Javascript at all, or with non-AJAX-aware browsers.

In this article I will detail one method to help ensure accessibility for such people, without compromising on AJAX spiffiness, and most importantly without causing much extra work for us poor developers. The example is in Rails, but may be of interest to those using other frameworks. (more…)