Big Data. Big Decisions
InformationWeek
Special Coverage Series

Commentary

Dave Methvin

The Hidden Internet Explorer Tax

It's easy to tally the costs of upgrading Internet Explorer, but the costs of not upgrading are harder to see.

Many companies justify their reluctance to upgrade from Windows XP and/or Internet Explorer 6 by pointing to the high costs of buying new systems or upgrading old ones. These are the costs that are easy to see, since they end up as a line item in the IT budget. When management asks the question, "Is this really necessary?" it can be hard to make the case for spending that money when faced with other priorities.

Yet there are hard costs associated with not upgrading, and they can be significant. This past weekend I was at the jQuery Conference in Mountain View, Calif. Yahoo's Nicholas Zakas presented data showing that although IE6 and IE7 only comprise about 20% of browser market share, they require as much as 40% of the development time for large Web projects. Several Web development companies at the conference confirmed that basic estimate. One developer put it this way: "We're very up-front with our clients about supporting older versions of IE. It usually takes about 30% more work to support them. Our company bills by the hour so it's the client's choice, but even then we'd prefer not to support them. It's tedious work and never seems to come out to anyone's satisfaction."

The differences can be enormous. On Internet Explorer before version 9, the CSS-related features like rounded corners, drop shadows, gradients, and transitions don't come for free just by mentioning them in a style sheet; transparency for PNG graphics doesn't work in IE6 either. Scripting features like geolocation, cross-domain AJAX, client-side storage and caching, and canvas are missing as well. Instead, the developer must include special code or images to make any of it work in a minimally-crippled fashion when the user has an older version of IE. It is nearly a completely different code path and has to be tested extensively to make sure it works within the limitations of these workarounds, which cannot do exactly what the native functionality can do.

Zakas made a short but elegant argument about whether Web sites need to look exactly the same in every browser. In essence, your site should look different in every browser, because it provides the incentive to upgrade. The trap we have fallen into is thinking that just because it is sometimes possible to make IE6 work using an expensive Herculean effort, that it is a good idea to do so. When the CEO of the company is using IE6 on their own computer, the demonstration of the latest internal Web app will look like something from 2001. When it's running in IE9 or Firefox 4, it will be good looking and responsive. Is that a bad thing? Perhaps not, as long as it works to some extent, doesn't throw errors, and reminds the CEO that their corporate priorities are what made the app look that way in the first place.

So there you have the hidden tax of staying with the older versions put into some hard numbers with some concrete justifications. It is somewhere between 30% and 40% more expensive (and time consuming) to develop for the older IE browsers that hang around on XP. This isn't a one-time tax, either. Every project a company develops will have to pay the price, and every third-party service will fall prey to it as well.

One reason why developing for older IE is so expensive comes from something that Zakas calls a faulty development model of Web pages. He says that although we often try to compare a Web site to a book, a Web page is not a printed page. Instead, a better model is that a Web site is like a television channel, and the Web browser is like a TV set. Clearly, the channel will only look as good as the TV it is being shown on.

To Zakas' analogy, IE6 is like an old black-and-white tube set whereas the newer browsers are like 3-D flat-screen sets. We are unfairly expecting developers to deliver a flat-screen 3-D experience on a black-and-white TV set. It is possible to use the "shims and polyfills" technique to coerce older browsers into running some new features, but inevitably those Web apps will end up being slower, harder to debug, and longer to develop than when the browser supports them natively.

There are some encouraging signs that users and companies are upgrading their PCs. Just this month there was a report that Windows 7 has surpassed XP in the United States. This milestone has already been reached in several other countries, particularly in Europe. Internet Explorer 6 and 7 usage in particular continues to drop along with the Windows upgrades, further strengthening the argument that older browsers should not be a focus of--or impediment to--Web-based development.

Microsoft has given XP users a difficult choice when it comes to browsers. Since IE9 doesn't work on XP, companies that want to stay with XP for a few more years can't go any further than IE8 if they want to stay with Internet Explorer. They can, however, move to Firefox or Chrome, which do support Web standards well and run on XP, so the lack of IE9 on XP is not a reason in itself to avoid the old-IE development tax. Transitioning to a new browser may not be completely painless in cost or time, but staying with an ancient browser will hold back your Web development efforts and cost money as well.




Related Reading


More Insights




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

BYTE encourages readers to engage in spirited, healthy debate, including taking us to task. However, BYTE moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. BYTE further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.

Follow InformationWeek

By The Numbers

What Are Your Primary Concerns About Using Big Data Software?

Base: 417 respondents at organizations using or planning to deploy data analytics, BI or statistical analysis software
Data: InformationWeek 2013 Analytics, Business Intelligence and Information Management Survey of 541 business technology professionals, October 2012

What Do You Think?

What's your attitude about SQL analysis on top of Hadoop?
We want fast, standard SQL analysis capabilities on Hadoop ASAP
Hadoop is for unstructured data; SQL is for relational databases
We'll give SQL on Hadoop a try, but relational DBs will remain the mainstay
Given strong SQL support on Hadoop, we'd nix the data warehouse
We're not interested in Hadoop
No opinion



Related Content

From Our Sponsor

Five Big Data Challenges and How to Overcome Them with Visual Analytics

Five Big Data Challenges and How to Overcome Them with Visual Analytics

Business leaders often need a visual snapshot of data to quickly grasp and use it. This paper identifies five challenges in presenting data and how visual analytics can resolve them. Solutions are suggested to overcome the challenges of: speed, data clarity, data quality, displaying meaningful results, and dealing with outliers.

Game-Changing Analytics: How IT Executives Can Use Analytics to Create Innovation and Business Success

Game-Changing Analytics: How IT Executives Can Use Analytics to Create Innovation and Business Success

Today's competitive advantage requires a deeper understanding of your business, your market and your customers. As an IT executive, you can drive that knowledge transformation. In this white paper, learn how to make decisions as a strategic business leader and three steps to begin an analytics initiative within your enterprise.

Data Visualization Techniques: From Basics to Big Data with SAS Visual Analytics

Data Visualization Techniques: From Basics to Big Data with SAS Visual Analytics

High-performance data visualization turns sophisticated analyses into meaningful graphics, leading to faster and smarter decision making. In this white paper, learn how visual analytics can transform big data, with additional features such as real-time functionality, mobile compatibility, robust applications for technical groups and accessibility for nontechnical users.

Big Data: Lessons from the Leaders

Big Data: Lessons from the Leaders

Financial performance, competitive advantage, operational efficiency, strategic decision making - every business goal can extract value from big data, and the time for doubt or inaction has long passed. In this Economist Intelligence Unit report, in-depth interviews with data pioneers reveal the link between the effective use of big data and the bottom line among other results.

Decision-Driven Data Management: A Strategy for Better Decisions with Better Data

Decision-Driven Data Management: A Strategy for Better Decisions with Better Data

Which came first, the data or the decision? This white paper makes the case for having a decision in mind, then tailoring big data's volume, variety and velocity to achieve business results such as overcoming customer dissatisfaction or creating well-informed strategies in real time.

Informationweek Reports

Research: The Big Data Management Challenge

Research: The Big Data Management Challenge

The challenge of big data is real, but most organizations don't differentiate 'big data' from traditional data, and nearly 90% of respondents to our survey use conventional databases as the primary means of handling data. We'll help you understand what constitutes big data (it's not just size) and the numerous management challenges it poses.