The IE6 Strategy

We wouldn’t exactly say that Internet Explorer 6 is alive and well; but the pulse of the beast is without a doubt still beating. For ourselves and our clients we have to account for a browser that makes up between five to twenty-five percent of a potential user base. In doing so, like with all things we do, we develop and deploy a proper strategy – one that evolves with time and adjusts on a case-by-case basis as necessary and appropriate.

Why Do We Still Care?

An obvious first question that deserves answering, why do we still care about IE6? An especially important question today, as Internet Explorer 8 was released to the public just yesterday. This now making Internet Explorer 6 seven years and two versions old; what some would consider to be too old.

We are not looking to have this debate or even extend it; we simply design and develop websites for users, not for browsers. We cannot control the mechanism in which a user will access a website we’ve created; we can only try our best to accommodate for that experience to the best of our abilities. We pride ourselves on creating unique, usable and stylish designs for the web, regardless if the user can see our style sheets, has JavaScript disabled, is using a screen reader, is running an older browser or viewing through an older or modern mobile device. And in most cases, the user can’t control these things either.

Fundamentals of Best Practice Process

When beginning the design process of a website we strive to hold true to the “if you can dream it, we can build it” mentality; ensuring that our knowledge of code and its possibilities as well as limitations does not interfere with our visual design ambitions. But when beginning that front-end development, it is always HTML first and CSS/JavaScript/Flash/etc second as complimentary visual enhancements.

At its core, every website should fundamentally be cross-browser compliant; they should also be pretty decent out of a printer or on a WAP mobile device for that matter. This is where the foundation of our process (or our IE6 Strategy) begins, with the idea that our markup from inception is compliant and optimized for discrepancies between browsing applications and their devices.

Enhanced Complexity comes with Reduced Compliance

Once the initial structure (a base foundation for the lowest common denominator) is constructed, it is enhanced using CSS, JavaScript, Flash and other front-end technologies. These enhancements are often for visual aesthetics and increased interactions and functionality, but rarely for required content or structural support. HTML is a fairly consistent, stable and supported language across all browsers; if all you have is content and pure HTML mark-up, being cross-browser compliant should not be an issue – not even for IE6.

As we introduce enhancements such as CSS and JavaScript into the presentation layer, the complexity of our website increases and it is there that compliance across browsers becomes harder and harder to efficiently and effectively achieve. As each enhancement is implemented we check for compliance issues across the major browsers (including IE6) and make a decision as how to handle the situation case-by-case. The majority of the time, the fix is clear and will take less time to correct for than to even have a conversation about – those are what we call “no-brainers”. We’ve found that the longer you’ve been working with a set of browsers the easier it is to spot a no-brainer before it even comes up; to even implement the solution before testing for it (ex: clearing floats).

Becoming more evident is that our IE6 strategy is no different than our standard front-end development best practices. As our JavaScript gets more complex and won’t support browsers such as IE6 as elegantly with respect to our increasingly complex CSS, we work to ensure that these enhancements do degrade gracefully for both those users without JavaScript as well as those on devices (or browsers) that don’t support the particular JavaScript in use. The same support is had for our Flash and CSS; we ensure that the alternative for those users without Flash or CSS is taken into consideration.

Simply put, we design and develop websites with the lowest common denominator in mind; striving for gracefully degradation at every turn, as appropriate and necessary – and that is our IE6 strategy.

The Difference Between Being Compliant and Being Perfect

There is without a doubt a difference between making an element work in IE6 and making an element pixel perfect; we always strive for the latter. However, our end objective with IE6 is graceful degradation; that is “graceful” not “perfect”. Whether a user is on a screen reader, a WAP mobile device, is without JavaScript or Flash or even running IE6; our objective is to create an alternative and graceful user-experience – always ensuring that the content and message are accessible, usable and stylish. The style might not be in perfect sync with the original visual design intention, but an alternative will come as close as possible, appropriately so.

While our default “best practices” account for a “good” experience for those users on less than optimal viewing devices or browsers, we prefer good over bad and always over non-existent.

“Progressive” Enhancement & “Graceful” Degradation - A Little Bit of Both

Progressive enhancement and graceful degradation, the two terms can appear synonymous at times (or perhaps just confusing); but we ultimately do a little bit of both with all projects. This combination of practices plays a fundamental role in our definition of “best practice” as well as our IE6 strategy.

Essentially, we start with a base foundation (our lowest common denominator), which is typically just raw HTML with the most limited and basic of elements required. Then we enhance that base foundation, but not necessarily in a progressive format – we jump right to the top of the food chain. We develop for what we consider to be the best in breed of browsers at the time, traditionally the most recent public release of Firefox. We then look for discrepancy among all modern and current browsers and account for those discrepancies in an effort to maintain pixel perfection with respect to design intention; normalizing the user experience. This often spawns creative debate between questioning our original code or the integrity of the browser that implemented it, always a fun and healthy debate worth having. We strive to ensure we develop our front-end the “right” way as opposed to the way that simply just “works”.

The distance between our base foundation and the best in breed browser will ultimately dictate how much time and effort is put into maintaining perfection the farther we get from modern compliant browsers. The shorter the distance IE6 is from the current release of Firefox for example, the more attention we place on ensuring pixel perfection (or normalizing for the experience). However, the greater the distance the less time is devoted and alternate means of presentation are implemented and at this point we begin to more radically (or “gracefully”) degrade.

At its core, our base foundation will always be more accessible and usable than nothing at all; so as the distance between things like IE6, screen readers, WAP devices or even printers get from best in breed viewing experiences the less graceful degradation occurs from the top and the more progressive enhancement occurs from the base.

Long story short, we’ve relegated IE6 to a second-class viewing experience – and that is our IE6 strategy.

Practicing What We Preach, Our Own Solution

There is something that is often forgotten when normalizing for the user experience, degrading or enhancing the front-end – and that would be, reality. The reality of time, a reality that has a strong influence on both money and stress.

Being the best practices type of organization we strive to be, we will develop our front-end to be as pixel perfect as possible across all modern browsers, regardless of time. We believe that our clients hire us to make great code from inception, not make decent code and charge them hourly to be great. We do our best to account for IE6, as we size-up each bug we evaluate the time and thus cost to understand the true opportunity cost of correcting for the bug. With most bugs they are simply “no brainers” and are accounted for at inception. And for more significant bugs we treat IE6 truly as a second-class viewing experience much as we do with printers and WAP mobile devices for example. And when the desire to have IE6 be as near pixel perfect as the modern browsers we hold close to our hearts, we do accept the challenge and do in-fact charge hourly for it.

With the recent realign of nclud.com, reality played a very large role in how we decided to handle IE6. The reality for us was more about time than about cost; especially as we are our favorite non-paying client. We had a strong desire, for good or bad, to launch our new website on the two-year anniversary of the previous design as well as the week before SXSW, one of the largest conferences for web designers and developers.

We evaluated the opportunity cost and decided the place more of an initial emphasis on the iPhone version of our site than the IE6 version, but we knew we had to accommodate IE6 to the best of our abilities. A lot of our clients work in large corporations (one being one of the largest PR agencies in the world) that force their employees to use IE6. And since we are more interested in ensuring that our clients have access to our content over asking them to quit their job or fight their IT department, we developed a specific short-term IE6 strategy for nclud.com realign. We simply redirected IE6 (and below) users to our previous version – the content and portfolio was already fairly up-to-date and the experience is very nicely designed for IE6; it felt like a win-win for us.

Like with the meat of this strategy, it isn’t really just about IE6, our previous version was also designed for the 800x600 screen resolution, so we apply this same strategy to users who visit nclud.com on 800x600 screen resolutions; giving them an accessible, usable and well designed experience (one that we were fortunate enough to have of already created).

As we mentioned, the pulse of the beast is still beating, IE6 is still a force we address. However, we will continue to evaluate the current state of the browser every few months and will continue to modify our strategy accordingly, ensuring to always take appropriate and necessary actions. We always aim to do the least (reducing time and thus cost) that will do the most amount of good; currently addressing IE6 is a part of doing the most amount of good, for now.