Tag Archives: Firefox

Fun with site usage stats

OK, “fun” may be an exaggeration, but it is interesting to look at these stats for room34.com courtesy of Google Analytics.

The usage statistics that are always of the most interest to web designers and developers are the web browser and operating system breakdown among site visitors. “Conventional wisdom” is that Windows makes up about 90-95% of most sites’ users (with Mac OS X making up almost all of the rest), and that among Windows users, Internet Explorer is at about 80-90%, with Firefox making up the bulk of the rest, while on the Mac about 90-95% are using Safari and the rest are on Firefox.

The stats for my site paint a much different picture. Now, granted, I am probably by at least a couple of orders of magnitude the most frequent visitor to my site. I can accept that. So that means Mac OS X/Safari should skew high in the results. But just how high? Let’s take a look.

The following are room34.com stats from the past month, January 19 to February 18.

Web Browsers

Here’s the breakdown of web browser usage among my site’s visitors:

Site Usage: Web Browsers

Firefox appears to be winning this war, with Safari close behind and Internet Explorer strong, but decisively in third place. Chrome trails far behind in fourth place, but I get a twisted pleasure from seeing Opera disappearing into irrelevance.

Operating Systems

And now for the operating systems:

Site Usage: Operating Systems

Well, how about that? There are enough other people looking at my site that Windows manages to still be the most widely used OS, though its 56% share is far below the roughly 92% share it (supposedly) holds among the general populace of computer users. And what do you know, the iPhone is third! Actually, iPhone and iPod should be identified together, since they run the same OS. I’m not sure why Google breaks them out (but doesn’t break out something much more useful: the different versions of Windows). Look at #7: the Wii! Sweet. Those were not from me. I must confess I’ve never heard of Danger Hiptop, but it’s obviously a mobile OS. Perhaps I should care, at least 0.04% of the time. (That works out to about 2.9 hours a month. Considering the average time on my site is about 3 minutes, one could [carelessly] deduce that Danger Hiptop users like to spend nearly 60 times the average amount of time per visit!)

OS/Browser Combinations

And now, all together:

Site Usage: OS/Browser Combinations

It’s no surprise that the Windows/IE combination manages to land the top spot, but it is surprising that the combo’s share is less than 29%. I’m a little surprised that Windows/Firefox also edges out Mac/Safari, although I should be glad that I represent, at most, about 1/5 of the visits to my own site. (I’m sure it’s actually only about half that!) Fully 12% of visitors to my site are coming to it on an iPhone or iPod touch. That’s incredible. And almost none of those are me. I guess it’s time to make sure I’ve optimized for that platform! I think this represents a turning point in the viability of mobile browsers, and we web designers and developers had best take notice.

OK, Microsoft, you’re off the hook…

But not in the way that the Cheat is off the hook.

I fixed the IE6 CSS problem I ranted about yesterday, and it was perhaps one of the more satisfying solutions I’ve encountered where IE is concerned, because all it required was that I remove a few lines of CSS code that turned out to be unnecessary anyway.

My approach to CSS is one of building a solid page structure and then fine-tuning the details until I have exactly what I want. A side effect of this is that sometimes I leave in unnecessary definitions along the way. If they don’t alter the output in the browsers I test (Firefox always, Safari often, IE7 at least once or twice along the way), then it’s good.

But in this case I had an entire definition that was completely unnecessary. It wasn’t hurting anything in Firefox or Safari, but it was doing all sorts of crazy crap in IE6. Naturally, in such a situation, I blame Microsoft.

To be honest it’s not really (entirely) Microsoft’s fault. I have to recognize that I’m building pages to be interpreted by different rendering engines (the latter part of which is where Microsoft’s blame, to the extent it exists, resides). But there are an unlimited number of ways to write standards-compliant code (which I think I do pretty well, most of the time), not all of which lead to the same desirability of output. So if there’s a standards-complaint way to also accommodate IE’s quirks, that’s the way to go. My biggest problem is that my access to IE6 is fairly limited, and IE7, although it has its own quirks, is a lot closer to what Firefox and Safari produce.

So… there you have it. The site should now look good in every major browser currently in use (Firefox, Safari, IE7 and IE6). If not, complain below!

On a side note, Steve Ballmer sticks out his tongue a lot. (Even when you’re not deliberately looking for it.)

The pleasure (and pain) of independent discovery

Menu screenshotI was pretty proud of myself when I came up with the solution for the dropdown menus I use in the navigation bar in my current site design. They don’t require all of the cockamamie JavaScript most older solutions did. They surely don’t work in older browsers (I’m guessing), but that really doesn’t matter now. Most significantly to me, though, I had never seen a solution that worked like what I am doing.

I guess it was just a lack of looking. There’s even a term for this approach, Suckerfish Dropdowns, although I’m not doing exactly what they recommend as far as IE support is concerned. However, I haven’t actually noticed it being necessary.

Now that may well be because I’m not even trying to support versions before IE 7, what with all of the transparent PNGs I’ve got everywhere. But still, the solution I’m using works great across all of the browsers I’ve tested: Firefox 2.x, Safari 2.x/3.x, and IE 7. The only complaint I have with it is that the positioning differs slightly between the browsers: the menus appear a few pixels higher in IE than in Firefox or Safari, such that they’re jammed up against the text of the menu header. But if I move them lower, the necessary contact (or really, probably overlap) between the menu header and the menu itself doesn’t happen… and if there’s a gap of even 1 pixel between the bottom of the header and the top of the menu, the menu will disappear if you don’t mouse over it fast enough.

Geez. I read a paragraph like that last one and I just have to ask myself, what am I doing with my life???

The Case of the Missing Nav Bar

I will admit, sometimes the problems I encounter in Internet Explorer are simply due to slight differences in browsers’ implementation of HTML or CSS or whatever, and I’m just not properly accounting for the way IE does certain things. Other times, it’s true, they’re due to a flat-out bug in my code that Safari and/or Firefox (usually “and”) will just graciously accept, whereas IE will not. (The cases where IE catches errors that Safari and Firefox permit, however, are rare compared to the vast, cluttered landscape of bad code that IE welcomes with open arms but that Safari and Firefox rightly reject.)

And then there are the cases such as the one I encountered today. There’s no way around it. I can’t find a nicer way to put it, IE is just plain fucked up.

Yesterday I was going along innocently enough, demonstrating to a coworker the site I had been working on for him. As usual I had worked with Safari and Firefox as my test browsers, firing up IE through a remote connection to my PC as needed to make sure things weren’t completely off track. (In a perfect world, I would never have to do this, of course. But, well…) And then, wham! Of course this kind of problem only rears its head when you’re showing your work to someone who has the authority to reject it. I was convinced it was a fluke on his computer, but sure enough when I went back to my desk, I observed the same thing happening in IE on my own PC. Time to hit the brakes once again and go into IE debugging mode.

I tested all of the obvious things. No luck. So I dug a little deeper and started testing the more obscure, but at least logical things. Still nothing. And like so many times before, I was reduced to just randomly trying anything to see if I could get a different result, no matter how seemingly absurd.

Fortunately it only took about an hour to track down the problem this time. But as usual there was no satisfying resolution, no “Aha!” moment as I suddenly recognized a stupid mistake I had made. Oh no. The problem was that the CSS definition for the <div> tag containing the entire body of the page specified a background color. Of course! (No, not of course, as this should not have any impact whatsoever!)

*SIGH* Seeing as how that background color specification wasn’t technically necessary, I removed it. Problem solved. Frustration with Microsoft, higher than ever.