You may have heard about the Browser Wars. The battle for dominance among browsers. What happens when this browser war hits home and you are caught in the fray and trying to decide on your battle plan?

Discovering the Enemy

As mentioned in the previous post on the biggest design challenge one of the first steps is to find out what browsers your clients are actually using. Sean Colombo, of LyricWiki has discovered this about his users:

In 2008, Internet Explorer dropped in prominence significantly, with my Google Analytics account showing that it has only 50% market share. On top of that, IE7 and the older IE6 are have approximately equal sized shares of the market, so you have to program for both of them. On my largest site (which is admittedly is skewed towards a more high-tech younger demographic), FireFox has more than 35% of the market share (also split up between their new version 3 and older version 2, but not as badly as Internet Explorer: only about 10% of FireFox users appear to still have version 2), Safari has more than 5%, and Opera has around 4%. All of these segments are far too large to just ignore. If you want to build a website, you now have to write it and then test it in at least 5 browsers (I tend to also test in Google Chrome because it is rising in prominence and the tech-oriented industry magazines tend to use it quite frequently).

One of the most popular and easiest to setup ways to discover information about your users as Sean suggested is Google Analytics. You setup an account, paste some javascript into your page template or the bottom of each page and then update your site. Once this done you will get daily analysis of who is visiting your site, where they came from and for the purposes of this article what browser they are using. The browser is considered the “User Agent” in many statistics programs. If you haven’t setup Google Analytics, check with your hosting provider they may already have User Agent statistics available with AWstats or Webalizer two popular Open Source statistics packages.

Once you have opened your statistics look for a list of browsers and their respective percentages. Pay attention to these three pieces of information: Operating System (Mac, PC, Linux), Browser (IE, Firefox, Chrome…), and Version (0.4, 1.0, 7.1…). Also look at the current month and previous couple months. This will give you a good idea of trends. If you see a browser trending up even from 0.5% to 1.5% it is probably worth adding to your test plan. Now create a spreadsheet, list, or mind map with each popular browser and details listed.

Analytics Browser Statistics

Analytics Browser Statistics

Details could also include screen resolutions, which is important from a design perspective to know what might find itself “below the fold” or outside the viewing area and require scrolling. The rule of thumb in web design was to create web pages for the lowest common demoninator. Kelley Perry, Information Architect, from McMurry Interactive, says that “another ongoing issue is dealing with monitor resolutions, and determining best practices for developing sites which scale gracefully across the range of monitor sizes.” 1024×768 or 800×600 are no longer accurate guidelines with the increase of larger widescreen monitors and smaller portable devices.

Also don’t forget about plugins if your application requires Java or Flash. Different plugins can cause different behaviors between browsers. For instance a flash upload script worked fine
in Internet Explorer and Firefox with the Flash 9 plugin, but when they were upgraded to Flash 10, the Firefox version no longer worked. A security adjustment caused it to stop accepting certain javascript actions. I eventually found a work around, but it required quite a bit of testing in both new and old environments, again a challenge to run both at the same time.

Congratulations, you now know your enemy for now. Remember, you also need to check this on a regular basis as a new browser can make your amazing web application look awful.

Create A Battle Plan

Now create a battle plan. This is something you should start to implement today and throughout the life of your web application. Catching issues early in the life cycle of your application will save a lot of headaches later. Here are some things you might want to include in your plan:

  • Browsers & Platforms to Support
  • Test cases
  • Reference screenshots – what the designer had in mind
  • Style guidelines – stylesheets & templates
  • Coding guidelines – Keeping business logic separate, etc.
  • Bug Tracking – Trac, Bugzilla, etc.

Track Results

Find out whether you are winning or loosing by tracking your results. Are the tests you are running resulting in positive or negative results? Do you have a bug tracking tool or other shared resource to share results. Can your end users also submit issues to be tracked? These results will be important to not only solve current issues, but also to avoid future ones.

Next we will look at tools for identifying issues with a web application in various browsers again with an emphasis on discovering issues early and solving them, preferably before a client finds them first.