This is a crazy awesome piece of genius from @rem:

As our Web apps become more mobile-aware, having a reliable way to develop and test with a primary consideration of motion was a tedious and difficult task, until today.

Advertise here with BSA

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?

Advertise here with BSA

Advertise here with BSA