Business to Business
While I’ve always been a proponent of writing code to established standards, when it came to Web front-end development I took those common shortcuts like everyone else. Why? Simply because the browsers let me get away with it and it made coding much quicker if I didn’t have to think about those little details.
Yet over the past 18 months or so, I’ve become more and more adamant about coding HTML to the appropriate standards. I’ve also started pushing for more Web development using the latest markup language of XHTML.
Despite how much I might push for this kind of development, my clients have always responded with the same questions. “How much is this going to cost me?” and “What’s in it for me?” When faced with these types of questions I respond with a question of my own. “How much is it costing you today by not coding to standards?”
The dumbfounded looks I get when I ask this question are astonishing. People simply don’t recognize how much it’s costing them not to code to standards. For too long, people accepted that was the way we should be coding and there was nothing we could do about it.
Let’s start by setting the record straight. First, one of the problems has always been that the browsers didn’t support standard functionality as defined by the W3C (w3.org). Fortunately, since the release of Netscape 6.0, Opera 5.0 and IE 6.0 the browsers have supported all functionality defined by the W3C up to and including Transitional XHTML. Unfortunately, many users around the world haven’t upgraded their browsers to these newer browsers. So before you go out and start coding XHTML you need to define your audience, check your access logs and determine which browsers they are using. Once you know this you can draw a line in the sand and say we’re only going to design for X version of browser Y and above. You may find some resistance to dropping support for a particular browser, but remember there can’t be but a handful of people, if any, still building and testing Web sites to work in IE 3.0 and Netscape 3.0.
Once this business decision is made, you can start immediately saving money. How much, depends on many factors. A significant time consuming aspect of any Web designer’s development time is ensuring that the code works in all browsers and looks the same as well. For example, if your organization is in the advantageous spot to drop support for Netscape 4.7 and IE 4 and 5, then you could expect a reduction of anywhere from 15 to 35 per cent in the HTML development phase of Web development. This equates directly to significant dollar savings.
Another way to save money even if you can’t drop support for Netscape 4.7 and IE 4 is by coding to standards that the lower-end browsers supported. One of the complaints that I hear when I recommend this is, “But the site will look different between the browsers!” So what? How many of your users are using two different browsers and comparing what the site looks like in both of them? The question the business needs to ask is “Does the site still look good?” and “Can the user still effectively use the site?” If the answer is yes to both of these, then don’t waste your time trying to get it to look exactly the same on all browsers. If the answer is no, go back to the visual design and change it so it can work across all browsers. There is no need for a Web site to reflect a printed brochure to smallest detail. One is paper and the other is electronic. By accepting this reality, you can expect savings of five to 10 per cent of your HTML development phase.
Another benefit of coding to standards occurs when a Web developer opts for the use of Cascading Style Sheets (CSS). Even when used to their limited functionality in Netscape 4.7, a developer no longer has to worry about correctly defining every bit of text in terms of colour, size, typeface and positioning. This is done once in the CSS. Then when management reviews the site and says “I want this bit of text to be navy instead of light blue everywhere in the site,” you only need to change one document (the CSS) instead of doing a search and replace through the entire Web site. Then re-test the entire Web site to ensure that nothing was broken during the search and replace. How much will this save you? That depends on how often you are faced with these kinds of changes.
While there are many ways that coding to standards saves the organization money, one of the most overlooked savings is reduced uptime for a new employee. Let’s face it, no one is an employee for life anymore. With turnover in the industry and the need to bring on additional help, the need for a standard way of doing something should be the mantra of every organization. Think about the last time you had to pick up some HTML/XHTML code that someone else wrote. How long did it take you to review it, clean it up the way you like it and then start working on it? When a new employee joined your organization, how long did it take them before they were up to speed on the way the organization said the pages should be coded? Now if everyone was trained and followed the standards, how much easier and faster would it be for you to fix a Web page that you didn’t write or to indoctrinate a new employee? This equates to big savings.
Ultimately the push for standards-compliant code should be coming from the coding ranks. We need to enlighten all levels of management to the savings they can achieve by embracing Web standards. If the people on the front-lines don’t take these recommendations and management learns of all these savings first (and they will), you’ll be faced with the tougher question of why you didn’t use standards instead of why we should code to standards?
For more ammunition in the fight for Web standards and some cool coding tips, visit the Web Standards Project (www.Webstandards.org). These people are fighting on behalf of all of us to achieve standards compliance in all browsers and Web development tools.
K’necht is president of K’nechtology Inc., a Toronto-based consulting company. He can be reached at alan@knechtology.com.
