At Web-Op, we’ve heard some prospective clients look at our bids and announce “We’ll get ourselves a $200 commercial template”.  Wow!  Think of the up-front cost savings!  Of course, that’s ALL you get with a $200 template.

First off, a canned template is likely to need customization immediately to fit your logo and corporate colours, unless your name is “The Lorem Ipsum Corporation”.  The sample images may show your competitor’s products, or nothing useful for your business.  Chalk up 10 to 20 hours of graphic design time, at $50 an hour or more, to fix these problems.  In tne end, the requisite changes may be so severe that your purchase ends up only a “skeleton” of tables and boxes that you can hang appropriate imagery on.

Running Tally:  $700-1200

Now you have a website, but it’s a shell.  That template probably only came with enough text to stretch the boxes on the screen to their intended width, or generic copy.  Someone has to write it, and in addition, someone else should read it.  It’s always worth the expense to have a second set of eyes scanning that content.  You need someone with the guts to say that “Interactive Business Synergy Solutions” is a lot less clear than “Wholesale Janitorial Supply and Uniform Service”.  If you hire professional developers, they’re reading and checking the content as they put it into the new site.  But if you have to stick with in-house staff, it’s worth paying a few users fifty bucks a head to be in a focus group.

Running Tally:  $800-1300, plus the cost of copy

If you knew you had a specific need ahead of time, you might have started with a template designed to work with a back-office system like Drupal or Zen-Cart to do the heavy lifting.  This decision shows some foresight.  You’ll have the facilities to manage an updated news site or a shopping cart.  However, even the easiest to use of these systems requires you to do a significant amount of setup to ensure that when you go live, credit card payments don’t get sent to the Central Bank of Zimbabwe.  An experienced developer may well have done this several times over, so he knows the catches and the correct choices.  You can either spend $300 to eat the first order that went astray or locate a press-release that disappeared, $300 worth of extra time testing and bug-fixing these components ahead of going live, or pay an experienced developer $300 to do things right in the first place.  The choice is yours.

Running Tally:  $1100-1400, plus copy

Finally, all web development contains significant amount of repetitive work.  It could be fixing the bad HTML Microsoft Office dumped into fifty documents.  It could be describing 30 new products for a shopping cart.  But these are hours that you won’t get back with a template.  If you earn a reasonable $20 an hour, expect to spend between $200 and $500 on this, for a small site.

Running Tally:  $1300-1900, plus copy.  You’ve already spent over a thousand dollars more than you originally planned, and the site isn’t live yet.

Finally, spend $1,000 to hire someone to go through your site, add keyword-focused your titles and headers, and remove the boosted Wikipedia article copy to ensure that Google sees the site in a reasonably positive light.  Now, at last, you can go live!  Once you buy hosting and set the site up, of course.  Depending on the type of backend you’re working with, this can easily be a day’s labour.

Running Tally:  $2100-2900 plus copy and hosting.   The site is finally ready to go live, but now every corner you cut to get it even THAT cheap will begin to show.

After a few weeks, you’ll probably find you long for certain features, perhaps ones you wrote off in order to accept the affordable template.  Either you’d better start learning PHP, or you’re going to have to hire a new developer.  Since he’s new to your particular project, it might take 20 hours for him to do what someone who had built the site from zero could do in ten.  So add another $1,350 to cover that extra ten hours of labour.

Final Total:  $3,450-4,250 plus the cost of hosting and acquiring copy.

You chose to accept a wide range of compromises, little if any on-going support, and only minimal expert guidance, and it still ended up costing in the same ballpark as having professionals do it right the first time.

Building your own website should be approached like other do-it-yourself projects.  While many of us can change an oil filter and save $20, or even add a new phone jack to save $75, few of us would try to replace our transmissions or install central heating.  We simply don’t have the skills to do the job.  Producing a quality web page requires at least four distinct skills:  research, programming, graphic design and writing.  Many smaller organizations, and even some larger ones, don’t anticipate that they’re going to have to call in professionals when they reach their limits.  That’s when $200 turns into $3000+.

If you frequently visit personal or non-commercial websites, you’ve probably noticed the small badges at their footers announcing “W3C valid HTML / XHTML / CSS”. Some web developers strongly argue the merits of standard-compliant design, as though it has value in and of itself, and some people seeking a new site will boldly insist that it complies with official standards. However, people chasing the conformance badge often lose track of the real objectives of web design: developing useful, attractive tools with the audience in mind.

Standards can be limiting.

At first, this argument sounds like a whine, issued by developers who can’t be bothered to find ways to work within the new standards. I’m sure many designers were heartbroken when the <marquee> tag didn’t quite make the cut. However, in certain cases, the standards actually DO only provide a subset of the functions developers need, and little recourse. An excellent example of this problem is with the XHTML STRICT spec– the “target” option on links has been removed. You can, therefore, no longer specify a link to open in a new window without either requiring a client-side script, or breaking the spec. Since many sites make use of this feature for user benefit, the standard actually moved the state of the art backwards.

Standards often get misinterpreted

In some situations, the W3C has supplied sample implementations which should clarify how standards are supposed to be implemented. A good example of this is “Amaya“, the obscure browser which serves as a model of how recent HTML specs should work. Sample code is, in theory, the best specification, because it eliminates any ambiguity left in a written guideline. However, not only are many specs without sample implementations, those that do have them are often ignored. This often leads to inconsistent interpretations of the specification, and poor cross-browser compatibility.

An example: Although all major web browsers “support” the CSS standard, only Opera 9 navigates the ACID2 “torture test” page as its designer intended. If your developers write code to the actual CSS spec, they’ll find it looks bizarre in real browsers.

Standards can represent a cop-out for real testing.

A poor designer may try to use the excuse “It’s standard HTML/XHTML/CSS” if you have trouble rendering under a specific browser. He’s blaming the browser because HE chose to ignore compatibility with the real world. This is an unacceptable excuse at any time; the first lesson of web design is that no mainstream browser implements the standards 1000% accurately. Would you trust a car that was built with every part in tolerance, but never test-driven?

Know your audience: Sometimes, standards just don’t work.

The best of modern browsers (IE7, Opera 9, Firefox) generally come within shouting distance of supporting the W3C standards. If you don’t “game” the standards or make excessively complex designs, compatibility is generally good. However, the rules are completely thrown out the window when those aren’t your target market. Internet appliances (WebTV and similar), mobile phones and PDAs, and even just users stuck on specific older browsers can torpedo standards-compliant code instantly. Advanced markup simply goes over their heads, or worse, is interpreted in ways ranging from comical to unusable.

Much like newspapers are written to the lowest reading level of their target audience, so webpages must be written to accomodate the buggiest and most primitive browsers they will encounter. If that means IE-specific tags and browser-detection code to keep order, so be it.

Like the United Nations

I have no problems with the standards-setting bodies themselves. They remind me of the United Nations: well-intentioned, but with little actual enforcement power.

Their lack of power comes from two sources:

First, since HTML and CSS have reached an adequate level for most design needs, there’s little that can be offered in new standards to make them worth embracing. There is very little you can render in XHTML that you couldn’t render in HTML 4.0, so why bother changing existing designs and habits to meet XHTML standards unless you have a very specific need?

Second, the real standards are, perfectly honestly, the behaviours of Internet Explorer 6 and 7 and Firefox 1.5 and 2.0. For an eye-opening experience, try surfing with Amaya (mentioned above), and see how many successful commercial sites have chosen to appeal to the real standard, and not the official demonstration of how HTML and CSS are supposed to behave.

What can make standards matter?

Right now, standards-compliance tends to earn you nothing except a feeling of superiority and likely several more billable hours for fixing the tags that actually work in browsers but cause the validator to puke. Instead, standards need to present a clear value-add to the developer and user. If new standards allow developers to easily add desirable effects you couldn’t do before, then browsers will clamor to embrace them and the standards will succeed. May I suggest:

• A tag structure for the definition of nested, collapsible or drop-down menus.
• The ability to have multiple languages or character-encodings in a page, and let the browser display only the relevant ones
• An embedded font system.

People will embrace those standards, because they fit clear design needs, while things like “Now your webpage is valid XML too!” didn’t.