Respond II.Responding to IE8

What is "responsive"?

Responsive is not "squishy".

This would imply that a responsive website is simply a site designed for a desktop browser, then shrunk down and rearranged to fit on smaller screens. That is the exact opposite of how we design and develop responsive pages.

Responsive is "fluid".

Developers start with one set of content, then style it in such a way that it flows naturally to fill different screen sizes. Additional styles are added on to direct the flow of content as the room to display it increases with screen size.

Responsive websites respond to the viewing environment when presenting content to the user.

  • Screen size
  • Hardware
  • Network connection speeds
  • Browser capabilities

IE8: The Incapable Browser

Point 1: Internet Explorer versions 8 and below do not natively support responsive web technologies. They will render pages with the same styles that would be applied to small screen/mobile devices.

Point 2: Despite a dwindling browser market share and imminent Microsoft support drop, many clients still want their sites to appear as precisely in IE8 as they do in more modern browsers.


How do we resolve these two points?

On the current, non-responsive TalentBrew product, TMP offers “limited support” for IE8, meaning we only address issues that prevent users from accessing core site content or functionality.

Given the extreme limitations of the browser when it comes to responsive design and development, we need to rethink our support standards for responsive products in order to ensure that we are developing sites capable of delivering a solid user experience to the greatest number of individuals.

"It has to be perfect in IE8 because our CEO uses IE8."

But what browser do job seekers use?

It is important that stakeholders are satisfied with the site's appearance. However, devoting excess resources to IE8 fixes is inefficient from an expense standpoint, given how many job seekers use older browsers.

TMP-hosted site traffic breakdown (as of 15 November 2013):

  • Chrome - 23%
  • Internet Explorer 10 - 15%
  • Firefox - 8.4%
  • Safari 7 - 7.5%
  • Internet Explorer 8 - 6.8%

Why focus more resources on achieving pixel-perfection in a browser used by few, when they could be used to explore new mobile web technologies for many?

The mobile user

  • 77% of job seekers use mobile job search apps [Beyond.com Career Network Survey]
  • 30% of jobseekers think applying for jobs on mobile devices is difficult [Glassdoor.com]
  • 25% would not apply to a job if the company's career site was not mobile optimized [Glassdoor.com]
  • 68% of jobseekers use their mobile device to search for jobs once a week or more [Glassdoor.com]
  • 86% of jobseekers who have a smartphone would use their phone to search for a job if career sites were better optimized for mobile [Recruiter.com]
  • 84% believe mobile devices will be the most common way for people to search for jobs within the next 5 years [Glassdoor.com]

Are mobile styles on IE8 a bad thing?

No, because IE8 still displays all page content and functionality.

  • User is receiving the same information and has access to the same tools they would be able to see in the "desktop" view on a more modern browser
  • Only differences are in the styling
  • Sites are build with the mobile experience at the forefront - IE8 will always render the core experience upon which the entire framework of the site is founded
  • No user will ever be a "second-class citizen" because of his/her choice of browser

Yes, because clients are expecting their page to look identical in all browsers.

It's time to break bad habits.

The expectation that web pages always look exactly the same in every browser is an outdated, print-centric notion that stands as the conceptual opposite of responsive development.

In the past, we attempted to meet this expectation with hacks and stylesheets that attempted to force IE8 and below to render pages as would a more modern desktop browser.

The process of hacking back to try and force older browsers to render pages in ways in which the browser was not natively designed is:

  • Costly (more to come on that in a moment)
  • Resource-intensive
  • Out of line with industry-accepted web standards
  • Detrimental to the user experience
  • Ultimately harmful to the performance and visibility of the client site

In mathematical terms:

More hacks = More potential issues = Less satisfied users = Lower site rankings

The solution:

Responsive development should not be considered part of "limited support" for Internet Explorer 8. New TalentBrew implementations should not behave responsively in that browser, or in any browser versions below it.

  • Content, and core functionality (such as job search on TalentBrew) will still be fully accessible to all users in all browsers.
  • Sites will render in the small screen/mobile layout in browsers that do not support responsive styles.
  • If a client wishes for a site to render identically in all browsers, spanning back to IE8, then their site will not be built responsively. We will no longer “hack back” to support older browsers.

We need to set a hard stop on outdated technologies if we want resources available to explore new ones.

Benefits of dropping IE8 support:

  • Reduction in turnaround time for responsive product implementation, and more efficient use of resources

    • Adding hacks and making IE-specific style tweaks can add days to the development schedule
    • Quality Assurance must already test on multiple browsers and devices - adding another, generally very buggy browser, will also necessitate additional QA resource time
    • Less back-and-forth between development and QA in addressing IE8 issues (which more often than not make up the majority of QA issues on a responsive site) leaves more time for developers to work on other client implementations
  • Lower initial project costs

    • Reducing the project timeline by eliminating resource hours needed for building and extensively testing sites in IE8 and below lowers overall cost to the client
  • Lower maintenance costs

    • Sites can be developed with maintainable, accessible, future-friendly code
    • Will work on all devices, even those yet to be invented
    • No reliance on unstable hacks, conditional statements, or scripts to render the important information on a site
    • No need to revamp the product or undo old hacks every time a new piece of web-capable hardware enters the market

Savings by numbers

The following cost estimates are from a recent responsive content page project for Walmart TalentBrew and Careers Site:

Development Time

  • Total development hours: 69
  • Development hours logged for IE8/7 fixes: 20
  • Percentage of time spent on IE8/7 fixes: 29%

Development Cost

  • Total development cost: $4,761
  • Costs billed for IE8/7 fix hours (rounded): $1,200
  • Percentage of total cost spent on IE8/7 fixes: 25%

Drawbacks to dropping IE8 support:

  • Client resistance to the same site appearing differently on different browsers

    • Requesting a site to be responsive and also fully compatible with older browsers is a sign that the client does not understand the purpose of building sites responsively.
    • As the "digital brand authority", it is our job to educate clients on the benefits of developing sites with their eyes toward the future, rather than the past. This may require extra effort on the part of all members of the digital team: account representatives, project managers, IXD, designers, and developers.

The bottom line:

If clients wish to look toward the future of web browsing with responsive sites, they cannot also be allowed to cling to the obsolete technologies of the past.

The transition away from older browser support will be difficult and may be met with resistance. However, dropping support for IE8 and below will ultimately be both cost effective and beneficial to site users.

We can meet (and exceed) client expectations of site performance by moving our focus from supporting outdated browsers to upholding modern web standards and improving the cross-device user experience.