Tag: Firefox

Fun with site usage stats, part two

Back in February, I wrote about web browser usage by visitors to my site. Some of the discussion over my recent redesign has prompted me to do it again. Here we go!

Web Browsers

browser-20091021.png

Compare to last time: Firefox has jumped from 34% to 47%. That gain has come at the expense of both Safari and IE, which have dropped from 33% to 27% and from 28% to 17%, respectively. (Note, of course, that I’m rounding the actual percentages to whole numbers because talking about “16.88%” makes me feel like Spock on Star Trek, and I’m enough of a geek without that.)

Also worth noting: Chrome. It is stuck in fourth place, but its share has jumped by 4.1% from 1.44% to 5.54%. (OK, in this instance I needed to Spock it up a bit.)

Operating Systems

os-20091021

Once again, as a Mac user who also (unfortunately, despite my feeble efforts at self-promotion) represents a hugely disproportionate amount of the total traffic, I’m skewing the results here a bit. Still, I have not significantly altered my own usage of the site since February, but in that time Windows has nonetheless dropped from 56% to just under 50% of my total traffic, while the Mac has gone from 29% to 43%. Interestingly, in February, iPhone/iPod represented over 12% of the traffic but now they’re just over 4%. Linux has stayed pretty even, in between 2 and 3%.

OS/Browser Combinations

browser-os-20091021

In February, IE/Windows was the dominant combination, at 28%. Now it has dropped to fourth place, at 17%. Firefox/Windows has gone from #2 to the top spot, even though it just inched up from 25% to 26%. Safari/Mac and Firefox/Mac each went up a spot as well, moving into second and third, and going from 21% to 24% and from 8% to 18%, respectively.

Conclusions

This is far too small and skewed a sample to say a whole lot about trends on the Internet as a whole, but what I’m seeing here overall is that Mac usage vs. Windows is up, and Firefox usage vs. anything else is also way up. Specifically I’m seeing a significant surge in Firefox/Mac… which may suggest, I suppose, that I have been visiting the site a lot more lately than I did in February. Or maybe not.

It’s also worthwhile to look at the raw total numbers in the traffic. In the time between then and now I’ve split up room34.com into a number of separate sites. The totals back in February were across the board on room34.com; for October we’re looking at stats strictly from blog.room34.com. The date range is the same: 30 days. (The original data was from January 19 to February 18; the new data is from September 20 to October 20.) Back in February, the data I analyzed represented 2,845 unique visits to my site. This month’s data represents 3,810 visits, an increase of 965, or 34%. Since the old stats included visits to a lot of pages that are now parts of other sites, the increase in blog traffic is even greater. So while it’s probably true that I’ve been spending more time looking at the blog myself in the past month, vs. February (considering I just did a redesign this weekend), the majority of the traffic increase is most likely not from me. In fact, it’s probably quite likely that my own percentage of the total traffic is quite a bit less than it was in February. Traffic here spiked on October 13-14, when I posted a reply to Derek Powazek’s blog on SEO — visits to that single page, just on October 13, represent more than 10% of the total traffic the entire site saw all month.

Let’s take a look at the OS/browser breakdown for just that one day, October 13, 2009:

os-browser-20091013

The traffic from this one date was likely responsible for some overall skewing of the totals. Derek Powacek’s blog appeals most strongly to Mac users, which would explain why the Mac/Safari combination is in the top spot (Safari being far more popular in general on Macs than Firefox, for the same reason IE dominates Windows — it comes with the OS).

Lessons to be learned? Well, if I want traffic, I should write about SEO. The SEO bots (both human and software) seem to love it. But beyond that, I think there probably is some valid evidence here that there’s some real movement in the directions of both Mac and Firefox. Something that sits just fine with me!

Final Thought

What’s the deal with this “Mozilla Compatible Agent” on iPhone and iPod? I haven’t seen that before, but I assume it’s one of two things:

1. A Mozilla-derived alternative to Mobile Safari, available only on “jailbroken” iPhones.
2. An embedded client in an app like Facebook, which allows you to view web pages without leaving the app.

I’m inclined to guess that #1 is correct. I’d be surprised if any Apple-approved apps were running a Mozilla-based web browser; it seems it would be far easier and more logical to develop legit apps using the official WebKit/Mobile Safari engine. I haven’t seen any hard numbers (nor do I think it would be possible to obtain them) on the percentage of iPhones in use that are jailbroken, but if this assumption is correct, and we can assume that the ratio of “Mozilla Compatible Agent” to Safari on the iPhone/iPod platform represents at least the percentage of iPhones that are jailbroken (since I’d assume some jailbroken iPhone users still use Mobile Safari), then the numbers are staggering indeed.

However… given the fact that over 8% of the total traffic on October 13 came from this user agent, and I myself visited the site numerous times on that day from my (non-jailbroken) iPhone, to monitor and respond to comments, I suspect a much more innocuous explanation. But a brief yet concerted effort to find an explanation on Google turns up nothing. Anyone in-the-know out there care to shed some light on the situation?

Sponsored Links

Download those PDFs!

Wow, I really like these 512x512 icons in Snow Leopard...This post is strictly for web developers/server administrators. The rest of you can resume your daily activities, confident that nothing that was even remotely relevant to you transpired here.

PDFs. Web browsers. Both are a daily, or at least frequent, part of the lives of most computer users. But not all web browsers are created equal when it comes to the matter of handling PDFs. Some browsers (say, the ones developed by commercial OS makers) take the approach of trying to manage everything for the user. They include PDF readers that are embedded right into the browser, and PDFs load almost like another web page. Other browsers (most notably Firefox) treat PDFs as downloadable files, and when the user clicks a link to one, the file gets downloaded to their hard drive to be opened in a “helper app” — usually Adobe Reader.

Most website owners prefer the latter approach, and I suspect most users do as well. PDFs in general are not much like web pages, and it does not seem logical that they should be viewed within a web browser. Generally when people are accessing a PDF, it’s because they want to download the document to their computer to be used offline or to print. It is illogical for these actions to take place in a web browser. Sure, savvy users can right-click (or on Mac, Ctrl-click) and select “Save linked file as…” or some such nonsense from the contextual menu. But a lot of Windows users don’t even know their mouse has a right button, a lot of Mac users have no idea that you can press keys and click the mouse button simultaneously to perform special actions, and a lot of both would be confused by this entire process.

So we come to the matter of web developers (such as myself) trying to find ways to force the web browser to download the file instead of loading it directly. A trick I have used often is to link not to the file directly, but to a special PHP script that reads the file into the server’s memory, changes various aspects of the response (such as the MIME type), and then streams the content out to the browser. This is especially useful when you want to restrict access to files, say only to logged-in users, or only to users who have entered a special passcode. The PHP script is perfect for that, because it allows you to execute some code before sending the file to the browser. It even lets you store your files in a directory on the server that web browsers cannot access directly, ensuring (more or less… this article isn’t about hacking) the security of your files.

But what if your files aren’t in a protected area? What if you don’t want to bother with the mucky-muck of the PHP wrapper — you just want to link directly to the (browser-accessible) file, but you still want to force the download? Well, if you’re using Apache, you’re in luck. I found this great explanation of a small block of code you need to add to your httpd.conf file to achieve the same effect.

Ultimately, what you want to do is change the MIME type of the response. Browsers that are inclined to load PDFs internally perform this magic by seeking out files that are sent with the application/pdf MIME type. But there’s a very handy, “generic” MIME type for binary files, which all browsers treat as files to be downloaded rather than displayed directly: application/octet-stream. It may sound like a group of 8 singers standing in a small river, but it really just means… a generic binary file.

Here’s the complete block of code to put into your httpd.conf file, or into the appropriate virtual host configuration, however it’s stored on your particular server. I placed the code just within the virtual host configuration for the client in question, so the change applies only to their site, and not to any others that are also running on the server:

<FilesMatch "\.(?i:pdf)$">
ForceType application/octet-stream
Header set Content-Disposition attachment
</FilesMatch>

If you’re not the server admin, you should also be able to put this in a .htaccess file in your site’s root directory, but I haven’t actually tested that to see if it works.

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…

ballmer_tongue.jpgBut 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???

Aliens prefer Firefox

Last August, a group of aliens Oregon State University students created a Firefox logo crop circle in a field near Salem, Oregon. The goal? Why, to have it appear on Google Maps, of course!

If you think that’s cool, rather than incredibly geeky, dorky and nerdy (yes, it qualifies as all three), then there’s a shirt for you.

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.

Refresh the Page. Twice.

Although the tan-on-brown color scheme was… er… unique, and crisp to read on an LCD screen (which is all I own), I got tired of how smudgy and illegible it appeared on the ultra-X-treem high resolution CRT I use at work. (Uh… I mean… not that I… uh…)

So it was that I changed the color scheme of the site. But most browsers (at least Firefox, which is what I use) keep the CSS and image files cached more persistently than page content, so on first glance the pages here come off with the same circa 1978 color palette as before, just with a white page background instead of black.

If that’s what you’re seeing, for the love of Jehosephat* refresh the page now!

OK. Now I know what you’re seeing (at least if you’re using Firefox). This time around everything’s blue… except a little less than halfway across, the header graphic changes from blue to the old orange scheme. Ack! Refresh again!

Ah… that’s the stuff.

If it still looks like crap, maybe it’s your browser. You might need to actually clear the cache or something. Just don’t blame me. I already told you to use Firefox.

* Side note re: Jehosephat. What little I know about biblical King Jehosephat comes from hearing the phrase “jumpin’ Jehosephat” in passing, and the few minutes of Googling I did right after I posted this. (After all, I figured if I was enticing my reader [sic] with the love of Jehosephat as a reward for doing as I command, then perhaps I should know whether or not said love is desirable.)

From what I gather, King J. was a respectable fellow. For more on the matter, I direct you to the very Google search I myself undertook. But beware… as is often the case in life, that road is fraught with peril… and completely impertinent links. Seems the king himself is not exactly a hot topic around the virtual water cooler. Oh well… off you go!