I say “Pooh” to 2 by 2 by 2
5 February 2001
Given that we are not yet in a world where Web standards are actually followed, how extensively should one test one’s (standards-compliant) site? Should one validate the markup and leave it at that? Or test in real browsers in case some bug rears up and bites you? Some people think it’s enough to test in a limited number of browsers. I call this the 2 by 2 by 2 mindset: test in two browsers (Internet Explorer and Netscape), two versions (4 and 5 for IE; 3 and 4 for Netscape, or maybe 4 and 6 nowadays), and two platforms (Windows and Mac OS). I also think it’s nuts.
My employment background is in the government sector. Public sector and educational websites aren’t there to entertain, to enchant or to gain ad revenue. They’re not there to be sticky. In the public sector, we have an obligation to taxpayers to make information easily available. Get in, find the information, get out. We aren’t here to waste your time. We certainly aren’t here to dictate your browser choice. So maybe it is my background talking, but I don’t think it’s enough only to care about the 2 by 2 by 2. There are other browsers out there, and the people using them ought not to be disenfranchised. They should at least be able to read the information you publish, even if it doesn’t look the same as in the latest version of IE or Mozilla. The way to ensure that is to use syntactically correct markup and to avoid silly mistakes, but testing for graceful degradation is also important.
Different but equal
If you look at many Web site logs, you will see more than just 2 by 2 by 2. At MacEdition, about four percent of our hits come from iCab, on average. Linux-oriented sites will get a lot of Konqueror, and PDA browsers and text browsers can pop up anywhere.
Maybe you can aspire to a site that looks the same in IE and Netscape, and maybe also Opera and OmniWeb’s forthcoming final version. But if you use stylesheets, it won’t look the same on non-CSS browsers like earlier versions of Netscape or pre-release versions of iCab. Text browsers like Lynx and WannaBe will render the page differently again. If you don’t use CSS, things can still look different depending on the font size settings of the viewer. How many browsers must your site look “the same” in? And how similar must it be, to be “the same”?
To start with, if you want vision-impaired readers to be able to view the text, it pays to not get too obsessed about enforcing font sizes. Font-size definitions are fraught with problems. Jeffrey Zeldman has argued that pixels or ems are the only way to go. Points are definitely out: they are a print-oriented unit of measure irrelevant to the Web (until browsers start supporting separate stylesheets for print and screen, the way the W3C intended). Points are also are the reason so many Web sites look tiny on some Mac browsers and huge on Windows browsers.
This is why I have let go of the idea that a site must look the same in all browsers. It’s a myth. Try too hard to achieve it, and you risk disenfranchising or alienating part of your audience. If you run an information-oriented site, even if it is not a public sector or education site, the information is more important than showing off your design skills.
Know your audience
Still, nobody wants to run an ultra-bland site for fear of spoiling things for Netscape 0.9 users. That’s why it’s so important to have a good feel for the population of browsers out there. You need to see logs, preferably for that site. You also need access to the raw logs so you can run customized reports, not just whatever spits out of the stats package offered by your hosting service.
Most of the standard log analyzers don’t give you enough detail on browser versions, like distinguishing between Netscape 4.04 and 4.7 (this matters a lot for MacEdition because of the stupid bug in those earliest versions). They also don’t identify minor browsers like iCab and OmniWeb very well, throwing them in the “Netscape (compatible)” too-hard basket.
On the other hand, looking at the raw browser tags is a pain if you have to comb through 4000 variations of the same browser version because some ISP customized the browser tag. You also have to be careful to base your information on pageviews, not just hits. Hits can be misleading if you have a lot of items like graphics on one page and only a few on others. Having access to your own logs may be essential to really understanding your audience. I find that running Analog with some customized settings allows me to work out what’s going on, and even then I have to run a search over the browser tag report to pick up all the AvantGos, iCabs and OmniWebs.
Share your knowledge
Now, all this is fine if you are redesigning an existing Web site, but it’s not feasible if you are still developing a new site, since your stats won’t yet exist. There are services that publish information on marketshare of different browsers; some you have to pay for and some are free (there’s a good source of links to sites like these here: kudos to Zeldman.com for the link). However, these are general statistics and might not be appropriate to your audience. This is especially relevant for Mac-oriented sites like MacEdition, but also for other demographics – for example, older people who are likely to have older computers.
This is where sharing of browser usage information could come in handy. Even if you want to protect your actual traffic volumes for commercial reasons, there is a common-good argument for sharing information about percentage shares. I know that Netscape 6 / Mozilla is only getting just over a percentage point of pageviews on MacEdition now, but are other Mac sites experiencing the same thing? I’d like to know, and I suspect some of them would, too. Should I be expecting more Mozilla in the future? Well, maybe not after some of my previous articles, but perhaps the experience of other sites will be informative about what I should expect.
There are some details that would need to be finessed before embarking on a statistics-sharing initiative. No actual traffic data need be shared – just the domain, the percentage of pageviews (or sessions), the date and the browser version (identified to a reasonably fine level of detail, but not as detailed as the raw browser tag). There could be a searchable site, so I could see if the half of a percent of Netscape 4.04 and occasional CyberDog users are just outliers specific to MacEdition (like our staff!) or not. Some enterprising XML expert could generate something workable, I’m sure.
Under the threshold?
So now you know your audience. But this raises another issue: just how minor can a browser be before you start ignoring it? If you take the view that you want to be viewable in every possible browser, to what extreme should you take the commitment? One percent? Half of a percent? And even if you accept that things don’t look the same for the half of a percent of, say, Netscape 3.0 users, how much degradation is really graceful? I can’t answer those questions for you and your site; you do have to ask them of yourself.
At least there are some age extremes you needn’t worry about. I got a 1994-vintage pre-release version of MacMosaic working on my G3 the other day. (Yes, it really runs on a G3: here’s a screenshot to prove I’m not lying) Guess what? The only Web site that it can view is the MacMosaic home page at NCSA. Every other Web site runs on servers using HTTP 1.1, which MacMosaic didn’t support. So you don’t have to worry about those seriously old browsers.
— CodeBitch (email@example.com) is the grumpy cow who does the HTML production for MacEdition.