We all know that XHTML is way cooler than HTML. I personally prefer anything that has an X on the name. Three X’s are even better, but one X will do just fine. It’s really cool.
But how good is “cool” for businesses? Can XHTML increase turnover? Can it reduce costs? Can it get you more business? Will your customers like you to change over? How much will you spend on it in the future on maintenance or upgrades? In a world where time is money, can XHTML based development save you time? In this article, I take a look at the business aspects of XHTML, and try to evaluate if it is just “cool” or if it really makes your pocket heavier. Also, hard as it is, I’ll try not to be biased towards XHTML along the way.
I do not talk about CSS in this article, except where it is absolutely necessary. I’ll cover the cost benefits of CSS in detail in a later post. This post is a comparison of the costs of using different markup technologies and doesn’t delve into styling or other such aspects of web designing.
In this article, XHTML would be treated similar to semantic HTML. So, you should be able to get identical results using semantic HTML.
XHTML can reduce the code length of your web pages by a substantial amount. For example, the Adaptive Path website redesign done by Doug Bowman using XHTML and CSS achieved a file-size reduction of 56% (26 kb) in the home page. In a test setup, he also achieved a 62% reduction on a redesign for the Microsoft homepage. In the recent ESPN redesign to embrace XHTML, an estimated saving of 50 kb per page was achieved. Wired News had a saving of around 64% on their site’s redesign.
When hosting a website the costs are split up into two components – cost for the server space and cost for the bandwidth. Since XHTML reduces file sizes, both costs for space and bandwidth come down. Doug has shown that with the Microsoft redesign a saving of 924 GB of bandwidth per day, or 329 Terabytes per year is achievable. Eric Mayer points out that the bandwidth savings of ESPN is around 730 Terabytes per year. When every byte saved is money saved, these numbers should definitely turn heads.
Arguably, Microsoft and ESPN are both huge websites, with a very high amount of hits per day. Smaller sites will not be saving so much. The cost of implementing XHTML might not be justified by the bandwidth savings alone for smaller sites.
Conclusion: XHTML will give a definite reduction in amount of space used on the server, which translates to money saved. Large sites will also benefit from the bandwidth savings, though this might be insignificant for smaller sites.
The consideration here is about which technology to start with. Considering that HTML is dead as we know it, there’s really no reason to think otherwise. However, I’d like to put in some numbers here too.
Developing using traditional HTML would mean that you’d have to have multiple versions of the same page for different browsers. The extent of differences would vary depending on the nature and design of the site. This is very important for cross-browser compatibility. Also, if additional browsers have to be supported, additional versions of the site have to be prepared. Want to support a PDA or other handhelds? Make another version of the site. Need cell phone-browser support? Make another version.
The cost of making each version of the markup increases linearly. So, if you want to make two versions, the cost of the HTML development will be double (or close to it). Three versions will cost thrice as much.
However, with XHTML, you need to make only one version of your site. Instantly, your site is accessible to a host of devices and browsers. The web-site can be viewed with any browser with exactly the same page, irrespective of the browser, manufacturer or platform. Depending on how many browsers you want to support, this translates into huge cost and time savings.
To put in some numbers, lets say that making a webpage work on Internet Explorer 5 on Windows costs you an amount X. Additionally, making it work on IE 4 on windows will cost you roughly 2X (maybe slightly less). Say you want to support IE 4, 5, 6 on Windows and Mac, that’s already 6X. And that is only 70% of the users on the Net. The remaining 30% of the users, who are just as likely to get you business as the first 70% use more obscure browsers like Mozilla Firefox, Netscape, Opera, Safari, or even unheard-of browsers. Supporting them all will only keep mounting up costs. With XHTML on the other hand, you’d only spend the original amount X. (Ok, the 6X is probably an over-estimate for a lot of projects. But you’d have to agree that it is still a large multiple of the cost of development in XHTML.)
Conclusion: If your use of HTML would mean that you’d have to maintain multiple versions of the site, XHTML linearly saves you both time and money depending on the number of versions you have to support.
Upgrading to XHTML is usually difficult to justify in terms of ROI and pay-back periods. Most HTML site owners are generally happy with their sites, and don’t see enough returns in moving to XHTML. They are either unaware of or comfortable with the drawbacks of their site, and can’t justify the additional expense. However, there’s one consideration that cannot be overlooked.
XHTML is both backwards (for all practical purposes) and forwards compatible. HTML is only backwards compatible. Forward compatibility is where new technologies and browsers would still work with your site. Backward compatibility ensures that older technologies would be supported by your site. Up until now, web development has tried to maintain good backward compatibility with older browsers and devices. Besides, backward compatibility in HTML was implemented by maintaining different versions of the site. With XHTML, your site will be available to virtually any device that can read XML. Such devices might not even be envisioned yet. Some alternate-browsers that understand XML sound like they are right out of a science fiction flick. These browsers might read your web-page to you loud, or provide a Braille interface for the visually challenged. XHTML is ready for these browsers already. HTML is not.
This saving in money is more abstract, and one cannot predict a timeline for the ROI. However, this is definitely a saving in long-term efforts.
Conclusion: XHTML will definitely save you money in the long run. However, putting down a number for ROI or payback period will be difficult. The real reason to shift to XHTML becomes a technical reason more than an economic one, for the short term.
Periodically, changes will have to be made to the site. The cost of these changes cannot be overlooked.
HTML files are rather complex. They have so much irrelevant information, it becomes difficult to manage them. XHTML on the other hand, if well planned, will be much easier to manage in the long run due to sheer simplicity of the files. Making changes to the site in the future will hence be very fast and consequently much less expensive.
However very few sites will need markup changes frequently. Updates to a site are generally handled using some server-side code. Even frequent updates usually does not translate into modifying markup.
That said, no site is ever prefect. Any good site will have a way to listen to their users and learn from them and accordingly change to serve them better. This process might be automated, manual, or a combination of both. Generally speaking, the process of getting feedback is best automated and real-time, and the process of altering the web-page is best handled manually. Obviously, the bottleneck here is the manual modifications, and easing this becomes very important. So, if you want to make a good site as opposed to one that just provides an online presence, XHTML would definitely help in the long run. Again, as above, putting numbers down to justify this will be difficult.
Conclusion: Most sites need frequent updates or modifications. The ease of handling XHTML as opposed to HTML in these scenarios cannot be overstated. However, again, since this depends on the Internet Business Plan of the company, quantifying this in terms of amount saved will be difficult.
HTML, as said before, works only in some browsers the way it does. XHTML works on all kinds of browsers, on all kinds of platforms, with all kinds of devices. The market reach of HTML is around 70% and dwindling fast. The market reach of XHTML is around 99.5%, and getting stronger. HTML can support only a limited brand of desktop browsers running on certain operating systems. XHTML can work on devices we haven’t begun to imagine so far, while working just as fine with some of the most ancient setups.
Conclusion: XHTML will increase your market reach by about 30%. Additionally, it will continue to support the largest variety of users coming to the site, now and in the future. HTML has already failed to do this. XHTML will get your more business. Period.
Using XHTML will ensure that your site is compliant with some of the most stringent laws and practices so that your site remains accessible, future-proof, and contributes to the general well-being and goodness of the Internet as a whole. HTML has a lot of trash in it, and chaos attracts more chaos. XHTML is simple, compliant with complex laws and requirements, and helps in making the Internet more cozy and comfortable for everyone.
Though the business implications of this are not immediately visible, one only needs to scratch the surface to see how it helps. A site that is compliant with stringent laws and uses best practices is very easy to use and is highly accessible. Such sites are a pleasure to surf, since the user is always in control. Users will only come back to your site if they had a good experience when they were there the first time. Their every doubt has to be answered and every whim and fancy considered. As much as markup languages can help, XHTML renders clarity and ease of use and puts the user in control, irrespective of his technical limitations. HTML does a poor job of this. A user is more likely to come back to a XHTML site than an HTML site, just because XHTML is more comfortable to use.
Conclusion: XHTML will ensure repeat customers and sustained business in the business in a way that HTML will not be able to handle.
For completeness, here’s the list of conclusions.
To sum it up, XHTML is good for your business. Enough said.
This is in no way a complete list of the business gains by using XHTML. And this is definitely not a list of the techinical benefits of using XHTML. This is only some of the more important factors that businesses need to consider when they are spending on their website.
I am sure I have left out many points. Please leave me comments to fill in the gaps. Also, please let me know if I have gone wrong with my assessment. I hope this article will help developers convince businesses to invest – something that most developers find difficult. I also hope this article will make for a good reference to give to businesses to understand why going XHTML is a smart move.