Improving Your Process: The Browser Gauntlet

Posted: March 09, 2009 Comments(7)

Learning of the requirement to test in multiple browsers is one of the most frustrating things to pick up when starting out in Web design. When I graduated from IE5.5 and found myself having to reopen it to test websites, it made sense, but it also made me depressed. Every Web designer has gone through the same thing at an early point in his or her career, as you pick up what’s right, and try to break the bad habits you formed as you taught yourself everything you know.

The building process

Over the past couple years I’ve wavered back and forth between building websites in Firefox and Safari. With the release of Safari 4 beta, I’m 95% sure I’ll be sticking with Safari this year (the Web Inspector alone is stunning). The main point I’d like to get across is that you begin work on every website using a modern, standards-respecting browser.

Using a well built browser will help keep your markup and style lean and clean. Starting out with a substandard browser will bloat everything from the start; not something you’re looking to do. After your initial build, you can then take your work through The Browser Gauntlet.

It’s a familiar feeling for any Web designer — you’ve completed the first series of pages, you feel great and go get a cup of coffee. The next time you sit down, it hits you: time to test. To this day I still get a few butterflies as I come to that very realization.

My Browser Gauntlet

My primary workstation is a Mac, so I’ll begin testing using browsers native to OS X. After building the site in Safari I’ll quickly test in Firefox. It’s been a long time since any discrepancies have appeared during this first test, so it’s more of a quick sanity check and move on. From there I’ll test in the latest stable, public release builds of Opera and Camino. I’ll also check things out in the latest WebKit Nightly to future-proof a little bit.

Although I test in five browsers at this stage, it usually takes only a few minutes since each browser is extremely capable as far as standards are concerned.

The next thing I’ll do is boot up Windows XP via VMware Fusion. I’m a huge fan of Fusion, but using a virtual machine (in OS X or otherwise) is a serious timesaver.

I’ll begin testing in Windows with standards capable browsers. First I’ll test in the latest public release of Firefox (3.0.7 at the time of this writing). I’m also still testing in the latest version of Firefox 2 (2.0.0.16) as I’ve found some discrepancies when working with Flash between Firefox 2 and Firefox 3. I’ll also test in the most recent versions of Opera, Safari, and Chrome. Again, this testing usually takes a few minutes at most.

Next I’ll test in Internet Explorer. I’ve tried a mix of Snapshots to test each version of IE, but found that process to be a bit slow for my tastes. I’ve had great luck with IETester, a free Web browser that lets you easily switch between Internet Explorer rendering engines. As of this writing, IETester is at version 0.3 and includes engines from IE8 RC1, IE7, IE6, and IE5.5 on both Vista and XP.

Some designers I’ve talked to feel IETester is a bit buggy for their taste, but I’ve found a trick that works for me and has absolutely no technical backing. If the first tab you open is of the default browser on your system, switching between various rendering engines is quite stable.

Using IETester, I will first test in Internet Explorer 7, and correct inconsistencies using conditional comments. Once things are stable in IE7, I’ll move to IE6, which is the longest stage of The Browser Gauntlet. Again using conditional comments, I’ll make my way through the shortcomings of IE6, gracefully degrading where applicable. I don’t make a big deal about it, just make things tolerable and move right along. Last, I’ll quickly look at the site in IE8 (latest release) and tidy up there as well where I can. I no longer test designs in Internet Explorer 5.5 as our metrics don’t call for that attention to be provided.

The final steps of my Browser Gauntlet reside in Ubuntu. Ubuntu is my Linux distribution of choice, and I always keep a stock installation available in Fusion not only for testing purposes but also to play around with from time to time. I feel it’s important to test in a Linux environment not because a significant number of people are using Linux, but because the operating system gives us some variables we may not have otherwise expected. The most obvious differences are with type rendering in the browser, so I make sure to keep only the default font installed that come with Ubuntu. This helps me validate included font stacks and make sure nothing breaks for Linux users.

Once I’ve booted into Ubuntu, I’ll first check renderings in Firefox. From there I’ll check things out in Opera, Epiphany, and Konqueror. These browsers often use the latest releases of either Gecko or WebKit so it’s rare that any significant trouble pops up. The most significant thing I’ll keep an eye out for at this stage is type inconsistency.

Once testing in Linux is complete, I’m quite comfortable moving on to the later stages of development (integration with a CMS, adding behavioral JavaScript, integrating Flash elements, etc.). I’ll repeat this process before showing the client anything, just to make sure the design is properly reflected after the bulk of the work has been done.

Testing in mobile browsers

The mobile space will continue to advance, and when a client requests a mobile version of their website, there is an additional step to browser testing that takes place. While I don’t have a wide array of mobile devices on which to test, I’ll do what I can with the tools I do have. Primary testing takes place in the iPhone simulator, as iPhone optimized sites are primarily requested at this time. The iPhone simulator is available in the iPhone SDK and allows really quick and easy testing of iPhone-optimized designs. Blackberry optimized sites are also requested from time to time, and although much less streamlined, there are a series of device simulators available. The simulators are Windows-only, so I’ll do my Blackberry testing using those tools made available. Another popular platform to test with is Opera Mini. Many handhelds use Opera Mini, and the Opera team offers a simulator (demo) for that as well.

Unfortunately, not many of my clients have requested mobile optimized sites, but I will be integrating that testing pattern into my process as more websites come through the door.

Effectively testing for the mobile space is not as easy as the desktop, but more tools are becoming available, and there is always the device itself on which to test. Unfortunately quite a bit comes down to the client budget and how much has been allocated for the mobile space. We’ll be seeing more mobile-optimized clients over the coming years, so it will definitely be in your best interest to learn about the available tools and become familiar with them.

Your turn

Browser testing is a bit of a pain for Web designers, but it’s also a responsibility. One thing I’ve noticed as I continue refining my skill, is that browser testing takes up less time with each website I build. With each website, you’ll more than likely pick up something new. With each piece of knowledge, you’re preparing yourself for upcoming projects. You’ll have in the back of your head the knowledge that building this layout is going to cause the same headache as the last one, and you’ll be able to take a more aggressive approach to solving the issue before it’s even a problem. Don’t look at browser testing as a hassle, instead think of it as the finishing touches on the best work you can do.

Is your Browser Gauntlet similar to mine? Are you testing in a browser that I’ve overlooked? Do you have any tricks up your sleeve to make browser testing less painful?

Get my newsletter

Receive periodic updates right in the mail!
  • This field is for validation purposes and should be left unchanged.

Comments

  1. I’ve been using IETester lately as well, a great program they’ve got going (now if only they could get an OS X version…). Sure beats the screenshot generators.

    I haven’t heard that about making the first tab the default rendering engine, I’ll have to try that.

  2. Having just got my first Mac, my process is quite similar. But I admit to being hooked on Firebug, so I start with Firefox. Incidentally, Multi-Firefox is a boon – Mac only, I believe.

    For IE testing I have Tredosoft’s Multi-IE. Sadly, IE 8 overwirtes IE 7, but the “compatibility mode” emulates IE 7 quite well.

    You wrote: “I no longer test designs in Internet Explorer 5.5 …” – Be aware that anyone coming to your site from the Google cache puts IE into Quirks mode. (All versions, I think.) IE quirks is IE 5.5 to all intents.

  3. If I’m at work I start with IE6, as a large proportion of our readers (40%+) use IE6 (depressing, I know).

    I made the mistake of designing in Ubuntu FF (my home set up) first and then testing in the “nice” browsers. This meant lots of retrograde changes and a conditional style sheet. I find that starting in the worst browser cuts down on work and avoids these workarounds: there are normally ways of getting IE6 to behave without resorting to if IE6. If you have a Windows machine, multipleIE is very useful.

    On my own site I do IE6 last and spend no more than 15mins on it: it accounts for about 1% of my readers.

    I always assume Ubuntu users download the common MS fonts. As Ubuntu grows with netbooks, I need to revise that.

  4. @Elliot Swan: I’m glad you’ve found the tool useful as well. Yeah, it’s funny about making sure the first tab you bring up is the systems default IE, but it’s worked wonders in making the app that much more stable for me.

    @David Hucklesby: Firebug is an absolute gift, but I’d like to suggest that you check out the Safari 4 beta and its Web Inspector. It’s definitely inspired by Firebug, but has a definite Apple touch to it. I think you’ll quickly find that the Web Inspector is on par with Firebug at this point. I used Multiple IE prior to IETester hitting the market, but found that it sometimes had trouble accurately obeying conditional comments, is that no longer a problem?

    @Leon Paternoster: That’s a very interesting take! Many of the designers I’ve spoken with have indicated (similar to me) that starting out with the worst browser actually hinders progress. It’s very intriguing to hear that you’ve found the opposite. Have you had any trouble with conditional comments using Multiple IE?

  5. It’s mainly down to our weird audience: as I say, over 40% use IE6, and IE 5.5, 6 and 7 amounts to just under 90%. If I start in, say, FF I have to work backwards in order to get IE to behave properly. Starting in IE6 rarely has the reverse effect. If I was working on a “normal” site I wouldn’t do it that way round.

    I can’t say I’ve had any problems with Multiple IE: doesnt it install a real copy of IE6 (or whatever) on a WIndows PC?

  6. The process that you follow is really professional. Reading this, i just thought about ‘Progressive Enhancement’, where the page is built with the basic structure and using the widely used modern browser as the rendering platform. All the testing and advanced functionalities can be added gradually … Your process is a very good standard that should be followed by all the web developers for a standard compliant web 🙂
    Nice One !

Leave a Reply

Your email address will not be published. Required fields are marked *