Main Page Content
Real-World Browser Size Stats, Part I
Rated 4.17 (Ratings: 9) (Add your rating)
Log in to add a comment
(6 comments so far)
Adrian Roselli
User since: December 13, 1998
Last login: September 01, 2006
Articles written: 48
Everybody has their own take on what resolution their users have. Sometimes that target resolution is based on hard data, sometimes it's a best-guess, and sometimes it's just based on the designer's own personal preferences.
One thing this ignores, however, is the window size of the user. Not all users at 1,024 x 768 resolution surf at full screen, so designing a page at 1,000 pixels wide would not be a good idea. Some of you may recall my article "640 x 480 Isn't Dead Just Yet." This article offers a way to determine if that's true for your site.
Instead of just guessing what resolution users of my company's site have, I decided to test it for myself. In addition, I wanted to know each user's window size and each user's bit-depth. This article will describe my methods. In Part 2, I'll discuss my results.
The Methodology
In order to capture the screen resolution, browser size, and bit-depth, you have to use client-side script. Unfortunately, both Internet Explorer and Netscape Navigator can report these numbers a bit differently. Netscape Navigator will tell you the size of the user's screen after it subtracts the Windows Task Bar, as well as the Microsoft Office Bar, or any other tool bars. This means a screen set to 800 x 600 could report itself to Netscape Navigator as 720 x 560, depending on the tool bars and the user's windows settings for icon and text size. Internet Explorer will report the full 800 x 600, however.
Also of note is that the script used to gather this information works only on the 4.x+ browsers. So you immediately have skewed data in case your site is hit by a lot of 3.x and older browsers. One could reasonably assume that a 3.x user has a smaller screen resolution and lower bit-depth, but there is no way to verify that using this method. As such, keep in mind that you are still only capturing data on a sub-set of your visitors, unless you have 100% 4.x users.
Finally, keep in mind that the web is a moving target in general. The information you collect is really only valid for the time it was collected. Newer systems and browsers are always coming out, so if you are relying on this information a year from now, you may be doing yourself a dis-service.
The Client-Side Script
It is important to know that you cannot write the screen and window information to the server via JavaScript. To prevent requiring the user to submit a page, and to prevent writing all the data to the URL, I opted to set cookies with the data. Please note that I attempted to name the cookies close to plain English so users who have cookie warning enabled will know just what I am trying to write to their machine. By writing to a cookie, the next page the user visits on my site can execute server-side script to pull the values from those cookies and write that data to somewhere on the server.
To prevent capturing a user's information over and over I coupled this script with my splash page, which already has code to prevent a user from seeing it more than once a month. You can get information on how to do that from the tutorial, "Let the User Skip the Splash Page." In this case, I use the ASP (server-side) version, reducing the load on the client to manage the cookie reading and page reloading. If you do not use any method to capture and write the data once per user, then you will have to manually pull all records with duplicate IP addresses, potentially removing different people from behind one firewall. Also keep in mind that an AOL user could get recorded many times under multiple IP addresses thanks to AOL's proxy methods. If the user does not accept cookies, then you have nothing to worry about, you just won't get any data from that user.
Below is the script I used to capture the information. I had this script in the <body> tag, after all the content. You'll note that I am not concerned with the browser window size, but instead with the viewable area within the window. Every user can have a different combination of browser chrome settings, tool bars, button bars, etc., taking up space. So, instead of trying to guess who has what tool bars open, I just find the viewable area.
<script language="JavaScript"><!--
var wHeight, wWidth, sHeight, sWidth, bitDepth;
if (document.all)
{ wHeight = document.body.clientHeight;
wWidth = document.body.clientWidth;
sHeight = screen.height;
sWidth = screen.width;
bitDepth = screen.colorDepth; }
else if (document.layers)
{ wHeight = window.innerHeight;
wWidth = window.innerWidth;
sHeight = screen.height;
sWidth = screen.width;
bitDepth = screen.colorDepth; }
document.cookie = "wHeight=" + wHeight + ";";
document.cookie = "wWidth=" + wWidth + ";";
document.cookie = "sHeight=" + sHeight + ";";
document.cookie = "sWidth=" + sWidth + ";";
document.cookie = "bitDepth=" + bitDepth + ";";
// -->
</script>
The Server-Side Script
Since our site uses Active Server Pages, the following code is VBScript. However, it's very basic code, so if you can read cookies, concatenate strings, and write to a file or database on the server in your server-side code, you'll be all set.
You may wish to modify how I write the data. In the script below, I write the x-value, the letter 'x', and then the y-value. You're probably better off not concatenating them, and instead, given my example, using a pipe (|) instead of an 'x' to create two fields instead of one. It's hard to crunch numbers that aren't numbers.
You'll note I also write the date, the time, the browser, and the IP address. These fields are handy to prevent duplicates, and to see which browsers are giving you trouble with the script. I also write another cookie just to make sure I don't log a user's information more than once per month - in case that user gets by my splash page script.
<%
'## Screen Resolution Logging
strBrowser = Request.ServerVariables("HTTP_USER_AGENT")
strIP = Request.ServerVariables("REMOTE_ADDR")
strNowTime = FormatDateTime(Now,vbShortTime)
strNowDate = FormatDateTime(Now,vbShortDate)
IF
NOT Request.Cookies("ScreenRes") = "TRUE"
AND
NOT Request.Cookies("bitDepth") = ""
THEN
wHeight = Request.Cookies("wHeight")
wWidth = Request.Cookies("wWidth")
sHeight = Request.Cookies("sHeight")
sWidth = Request.Cookies("sWidth")
bitDepth = Request.Cookies("bitDepth")
TextRecord = sWidth & "x" & sHeight & "|"
TextRecord = TextRecord & wWidth & "x" & wHeight & "|"
TextRecord = TextRecord & bitDepth & "-bit|"
TextRecord = TextRecord & strNowDate & "|"
TextRecord = TextRecord & strNowTime& "|"
TextRecord = TextRecord & strBrowser & "|"
TextRecord = TextRecord & strIP
'## OPEN TEXT FILE
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objNewFile = objFSO.OpenTextFile("X:/XXX/scrlog.txt", 8)
'## WRITE TO TEXT FILE
objNewFile.WriteLine TextRecord
'## CLOSE TEXT FILE
objNewFile.Close
'## Cookie Setting
'## Adds 1 month onto current date
'## so cookie will expire 1 month from now
strNowDate = FormatDateTime(Now,vbGeneralDate)
NewDate = DateAdd("w",1,strNowDate)
'## This sets the cookie so that
'## the next time the user comes back
'## they will skip the splash page
Response.Cookies("ScreenRes") = "TRUE"
Response.Cookies("ScreenRes").expires = cdate(NewDate)
END IF
%>
Reporting
Once you have this in place, you can sit back and watch the data roll in. You should designate a time-frame or target date in advance. My goal was 1,000 entries, which for our site was three months. From there it's just a matter of importing the data to a spreadsheet or database and sifting through the data to find the numbers.
Results
This article has shown you a method to write your own screen resolution, browser size, and bit-depth tracking. Part 2 will show you the results from my site, http://algonquinstudios.com/
