Q: How does a spectacularly immense organisation go from tables and HTML 4 to web standards and XHTML strict without breaking a sweat?
A: They don’t.
A large company that shall go unnamed to which I have a particular affiliation has recently updated the standards to which all new websites will be developed. This is after having spent the last nine years using the same, table-based layout for 1000s of sites, mini-sites and single pages. Nearly half of this rubbish contains elaborate CSS hacks for IE 5. Imagine that.
The first, and potentially most difficult battle has been won: getting the support of management across the organisation and the resources to research and develop the new solution.
The second, and arguably most fun part of the task has been completed: you’ve created a flexible, standards-based template using a new brand or design that works in every browser you care about.
Now comes the dirty work.
The particular concoction of 100s of developers, a gigantic online catalogue and nine years of “internet time” has created a labyrinth of hacks, validation nightmares and enough <td>s to crash View Source. Resource-wise it would have been impossible to go through each and every page of HTML to upgrade the templates. We all know that this essentially means a rebuild and in some cases a redesign – not just dumping content into a few div tags.
So what do we do?
I’m not an expert in change management but I have played various roles in the evolution of a company’s code, thinking and practice from old to new. Each experience was different, but I’ll try to provide an outline of what to look out for.
New sites – a new way
It makes sense that all sites in development will follow the fresh standards since you now have your new code and the rules in which you can implement them. This teething period should weed out any structural problems with the code and allow time for designers to explore the possibilities and limitations of their new space. Make sure you share what you have learned!
If you work with a team of developers, get together before starting and ensure that everyone understands how the new code works and should be used.
You can also use this opportunity to document new guidelines and show off recently-built sites to other staff and indoctrinate them in the ways of standards. Content editors in particular deserve a training session in coding for standards and using semantic markup.
Old sites – a new project
You will be updating the landing page of your portal, or parent site. That is clear. However, there will be a period when your network of sites will not be consistent. This may cause some minor panic in the creative or marketing department and elsewhere where brand consistency is considered important.
Take care of the vitals first:
- Your brand – if the branding changes, try to modify this across all your sites first. The process will be a pain but not as great a pain as the designers and brand managers will be when they realise that your sites don’t represent the company’s “brand-spanking new persona”.
- New navigation elements – unless you want people to get lost when moving in between your sites, you’d better update any changes to the global navigation. For example, network bars in the header, footers and links to new content like updated help/accessibility pages (which you will update to reflect site modifications, won’t you?) 🙂
Again, depending on your resources, you should then organise a new project. At the very least you have to:
- Evaluate your online properties and decide upon the sites that are priorities for migration.
- Book time with your most efficient designers and frontend programmers to determine the methods, timeline and resources.
- Start one at a time – after the first site has been completed you’ll have a better idea of what to expect as you go down the list.
Things that will go wrong
A portion of your audience won’t like it and they will tell you. They would have grown accustomed to navigating around the old layout, if indeed that has changed, and the former look and feel. A simple task in web education should suffice to address discontent even if it consists of one page describing the reasons and advantages behind the changes. You can then direct any complaints and queries to this page and then hope that they will understand. You will never please everyone, but an explanation is usually considered polite.
Even though we are in 2008, a few members of staff may not possess the sufficient skills to code according to your new standards. Sometimes it is only a misunderstanding of simple concepts or a gap in their knowledge regarding new standards or elements. For instance, thanks to a generation of “Dreamweavers”, we often see this:
For CSS best-practice and accessibility issues a one-day session should suffice.
Some members of your team may resist. Generally I found it was the content editors who didn’t understand why they had to change what they had been doing for four years. Since you have management support, they will have to comply but being nice and explaining things in simple terms will work better.
Going the distance
After all the hard work is done, keeping abreast of new standards and then advocating them wherever possible is the best way to ride out with greater smoothness the wily waves of the ever-changing web. Given the nature of large companies with disparate teams and financial objectives, a full migration will probably never happen in your employment lifetime but with planning you can go close. You can pick out even the tiniest success story and make it into something huge. Is there someone out there who, because of your changes, can now access your site more easily than before? What are your SEO results like these days?
Don’t stress if you don’t get the W3C green light. Unless you have full control over all aspects of your sites, achieving 100 per cent validation will be like trying to dig a hole with a defrosted fish-finger. Liberating your sites from tables and font tags will feel better than any endorsement anyway and you can always work on these points later.