Scribbles: benefits of Web standards

One of the ongoing discussions in The Biz has to do with the business benefits of {x}. Since I’m formally attached to the Web Standards Project, the {x} on my mind today (as on many days) is Web standards. (Betcha didn’t see that comin’.)

So… there are three ways I can think of to improve a process or deliverable:

1. make it faster,
2. make it better, and/or
3. make it cheaper.

For the sake of note-taking and reading aloud as much as any other, I’m writing to answer the implied questions as they relate to standards-friendly site development.

Web standards are faster because…

…The reduced overhead of standards-friendly markup improves load times — sometimes a little, sometimes a lot.

…That same markup improves the signal-to-noise (i.e., content-to-markup) ratio, resulting in content that’s easier to maintain.

…Given effective project management and sufficiently trained operators, standards-friendly processes and tools allow for narrower specialization by virtue of separation of content, behavior, presentation, and business logic. This in turn makes it possible to throw more people at projects in parallel.

Web standards are better because…

…They make feasible technologies such as Ajax and third party applications which can add depth to the user experience.

…The same separation and cleanliness benefits that can improve time-to-delivery and load times also simplify modularization and thus provide greater facility for extending sites and applications in lieu of redesigning them from the ground up to account for new features.

…Well informed use of CSS makes possible layout techniques that table-constrained producers and designers can only dream of.

Web standards are cheaper because…

…The same parallel production approach outlined above can be eschewed in preference to a serial approach involving smaller teams, reducing capital investment in projects down to a manageable rate. (This is one of the more important reasons behind my preference for small teams.)

…Modularization and cleaner production values at the code-and-markup level reduce maintenance requirements.

…Improved load times result in incrementally reduced investment in bandwidth and hardware.

Sounds great, but why the hard sell?

The only reasons these plusses do not make a slam-dunk case for Web standards are:

• increased testing requirements, and
• the need to re-train.

The more important of these issues is re-training, which is usually difficult, but not always difficult.

A wealth of resources such as w3schools, the MSDN Library, CSS Zen Garden, and A List Apart (among many) exist to bring along those who are just starting to learn about the current state of Web technology.

For those who need ongoing support in their education, css-discuss and other communities keep the fledgling learner in good company.

The rest of the re-training task is taken up in the course of actually doing, a process which culminates in the production of a site built entirely to the spirit, and quite possibly the letter, of established W3C Recommendations and other recognized best practices… entirely from arbitrary design documents.

Once an operator is properly trained, testing is simplified, because he or she will already have become quite familiar with many of the bugs and other pitfalls faced in the course of undertaking standards-friendly development. The others can — as a rule — be sussed out in community/form threads and, as a last resort, via search engine queries. I can speak for the effectiveness of both of these avenues for avoiding and working around browser bugs.

This leaves the conscientious project sponsor with two questions:

1. Who bears the cost to train my people?
2. How can I best make the switch?

The answer to the first question is somewhat academic, in part because your people will learn in the course of applying knowledge to their work on your projects, and elsewise because the added skill will make them more valuable to the marketplace. Either way, operators will rightly expect you to share some of the wealth gained from your improved bottom line. If you do not pay for formal training, you’ll only be putting off raises demanded either by your operators directly, or by the marketplace.

However, the share you give up from the improved bottom line will only be incremental; your organization will still enjoy the lion’s share. This is a fair expectation because among other benefits, your people will experience fewer hassles and less tedium in their jobs (all other factors being equal).

The answer to the second question is more complicated, because you've essentially got two choices: either go cold turkey from one approach to the other, or travel slowly.

Of these the latter offers the least aggravation for all participants. If you can start with some smaller projects — e.g., product marketing microsites and internal applications — you can set up your operators to act on what they’ve been learning, while simultaneously reducing the risk to your bottom line.

The reduced risk does not automatically translate to reduced hassle or delays, but when people are being trained, when is that ever the case?

One other contingency: transitioning from the contract build to ongoing maintenance

Let’s suppose you hire some hotshot hired gun (like, uhhh, meeeeee!) to equip your site with the newest, shiniest standards-friendly bells and whistles. Let’s suppose further that your fulltime Web team can’t tell asses from elbows when it comes to Ajax or CSS. What then?

This scenario requires multiple remedies.

Excellent documentation

Exhaustive explanation of the template, stylesheet, and code structures used during the design of the project is a must-have.

Onsite training

Somebody should come onsite and put your team through an ad hoc boot camp. Alternatively — if your hired gun isn’t especially facile at public speaking — there should be an internal forum or mailing list set up for the benefit of maintainers, along with contractually defined support requirements. This turns your contract team into little more than a glorified helpdesk, and they may choose to refer some other team for the job. The bottom line is that untrained people will have questions — and lots of them. Someone should be on tap to answer those questions.

Effective management

Project and department managers with the communication skills required to successfully track and define problems at the appropriate level — who have a clear idea of the obstacles their people are facing — can make the best use of the time and other resources spent to ensure that the problems are solved.

In short, Web standards adherence is an endeavor that rewards those with initiative. Why not become one of them?