Elements or Lower

Mon, 28 Nov 2005

Woking gets a makeover

Way back in May 2004, I set myself the mission of reworking the design of the Woking Borough Council web site in CSS.

I managed to let it take me until September this year to actually get this done, and even now there are parts of the site where old, tables-based markup, riddled with presentational attributes and spacer GIFs, is nested inside the new CSS-driven templates. This is largely a product of the different ways the CMS can acquire content — parts of the site are derived from legacy CGI scripts massaged into the newer CMS processes. But at least the templates are done.

Of course, the Council themselves weren’t motivated to change the site templates for the same reasons I was. I felt it was high time I made the transition to rigorously separate presentation from semantics, and to put into practice the CSS techniques in which I’d only recently begun to dabble. The new implementation would have some key, measurable benefits for the site, however, and these prompted their enthusiasm for the project.

Notwithstanding the many and varied concerns over their accessibility testing, the monthly SiteMorse league tables furnished us with a number of key target areas for improving the performance of the site as a whole. We’d done well with metadata, improved our error count, and remained focussed on accessibility — but our download speeds were consistently poor.

As part of my proposal document for the project, I ran a small experiment here. The breadcrumb trail at the top of each page had been implemented as a table, but my thoughts on the CSS version led me to believe it should be an ordered list. Taking the breadcrumb trail from one example page of the site and re-coding it in this way resulted in the following delightful realisiation:

The two different approaches result in an identical visual appearance. The first approach, however, uses 846 bytes of code. The second — taking the HTML and CSS together — uses only 575 bytes. This saving is compounded by the fact that the stylesheet would only need to be loaded once, and would then be applied to any page, whereas the HTML approach is included in full for every single page on the site. The HTML alone in the second approach is only 279 bytes.

In itself, this is a small saving — but the templates contained many, many similar examples. Moreover, each page on the site contained dozens of small graphics to drive the presentation. Each primary navigation button contained the text of the button as part of the graphic, and had a rollover state — for our (at the time) 10 different navigation buttons, we therefore had to load 20 different graphics onto the page. Plus background images (specified as attributes to individual table cells, of course), spacer GIFs, drop shadows, rounded corners, and (on the homepage) a further 10 buttons and text-in-graphic headers to different blocks on the page.

We’d recently introduced a series of links on each page to run the page through Google Translate — which worked well enough for the actual text of the page, but of course didn’t touch all the text rendered as graphics, leading to a page mostly in one language, but with navigation in another.

The CSS project therefore had three key goals, other than quelling my shame:

  1. Help our download times by trimming the code itself as much as possible.
  2. Further help this by reducing the size and number of graphics used as part of the templates.
  3. Remove instances of text rendered as graphics, whilst staying pretty.

Additionally, we hoped to be able to achieve two more:

  1. Improve our accessibility through semantic code.
  2. Improve our error quotient through simplifying the HTML.

Finally, it was important that the finished version resembled the existing design as closely as possible. It was clear that the two versions wouldn’t match exactly — if nothing else, rendering text exclusively as text would guarantee that — but this wasn’t so much a redesign as a re-implementation of the existing design.

The work was completed in two main stages. The first was to take an existing page from the site and recode it; the second was to then implement this new design in the CMS’s XSLT templates.

In recoding the HTML (essentially a case of throwing away all the presentational cruft and getting down and dirty with the semantics), I had a notion that we would be able to make life easier for JAWS users (et al) by placing the primary site navigation towards the end of the HTML source rather than at the beginning, and then using a touch of creative CSS to keep them in the left-hand “ribbon” column. The principal blocks we ended up with for most pages, then, are as follows:

  1. The borough logo
  2. The breadcrumb trail
  3. The page header
  4. The “This Section” navigation
  5. The main page content
  6. The search box, primary site navigation and translation tools
  7. The page footer

The next stage was to create a range of background graphics in Fireworks, with the intent of excessive use of the CSS Sprites technique to minimise the number of graphics which needed to be downloaded, without sacrificing our multicoloured rollover effects, or the range of button imagery on our homepage.

I had been worrying about the rounded corners I’d implemented on many of the panels we had in the previous design — I didn’t want to lose them altogether, but equally, I didn’t really want to have to include separate corner graphics and the extra DIVs necessary to embed them. About this time, I learned of Alessandro Fulciniti’s Nifty Corners — some presentational Javascript to round off the corners of specified blocks without needing images. Like sIFR, Nifty Corners is resolutely unobtrusive — if you don’t have Javascript enabled, your corners merely remain sharp. No big deal. Lovely.

In order to get sign-off on the changes, I then (after spending a short time on other projects) incorporated the new design into a fresh set of XSLT templates using a system built into the CMS whereby the presentation layer can switch to a different context based on a small change to the URL of any given page. This enabled us to compare the old and new implementations of the design for any page on the site very easily, and we used this to obtain some measure of the success of the project:

[We ran a] speed check on two pages with their closest counterparts on the real site. The existing homepage was estimated at a 54 second download on a 56K modem. The new implementation weighed in at 19 seconds. The comparison of the inner page is less dramatic, with the old design at 16 seconds and the new at 10 seconds. The old inner page needed a total of 71 individual HTTP requests (mostly images), whilst the new needs 27.

Once the implementation was signed-off, all I had to do was make the new XSLT templates the default ones, and the work was largely complete.

Because the new implementation of the design addressed everything that our old “Easy Access” version was intended to do, we also switched off that feature from the site. The new site has a print stylesheet that removes much of the navigation from a printed page, and the implementation is frankly more accessible than the Easy Access version itself actually managed. With a few recent tweaks, many pages on the site (including the homepage) now seem to be WAI-AAA accessible — although of course it’s really not possible to be sure of that without further real-world, non-automated testing.

While all this was being worked on, the format of the SiteMorse benchmarks changed somewhat. The monthly league tables no longer specify a score for HTML errors (although the new implementation validates consistently), and the automated WAI-A and AA scores are now given as a percentage of pages assessed that contained at least one accessibility error. For October, we had 13.6% of pages with at least one WAI-A error, and 38.4% of pages with at least one WAI-AA error. Unfortunately, of course, you have to buy the full report to find out just what your errors are perceived to be. We might just go ahead and do that, and I’ll be sure to follow up here with any conclusions that may be drawn from this.

On the positive side, whilst SiteMorse consider our actual download times to still be unacceptable on a 56K connection (though they’re now a “Pass” for ADSL), our server has furnished us with the fastest actual response time of all 463 assessed local government sites for the past two months running. This has much less to do with the CSS makeover than the beefy hardware and the CMS’s own caching strategy (more on which another time), but I’m awfully pleased about it anyway.