One of the most frequently asked questions I get from clients and other designers in regards to web design is, "What screen size do you typically design for?" This question gets harder and harder to answer as we have more mobile devices in addition to the larger and smaller HD monitors and laptops in the market. The short answer is, "I don't have a standard screen size anymore. I have been designing my GUI as liquid to adjust to users screen size and browser size for many years now and that solves many issues." Now, I still try to maintain a minimum and maximum content area, but this is relative to the type of content and objective of the site, so to keep it simple, let's just talk about how to answer that question for yourself.

The case is more often than not that the standard "Stats" tracker on your server will track 'OS' and 'Browser' version, but not actual screen size and resolution. Finding a system to do just that off the shelf was not commonly known to me at the time and no one had any answers to this in the form of a tutorial or something straight forward enough for me. You have to understand that this is a piece of data NOT related to anything a Marketing Director will evaluate, so that is why most stat trackers don't implement this data. So a few years back I actually built a small system to help answer some of the more design oriented questions. How I tracked this was using Coldfusion, Sql, Javascript and Ajax. I'm big on simplicity, so the code is pretty straight forward.

Now the code I put together here is a quick and dirty version of what I started with years ago to get something up and running. I recommend using stored procs and other functional and security measures to help streamline your full application, but for this article, you can use this to test things out and then develop your own application. It's simple, but works.

Let's break this down. The ajaxproxy tag simply identifies the component and method, just as a typical cfinvoke would, but here the jsclassname creates a simple object class for the javascript to call instead. Let's look at the java variables.

The "cWidth" & "cHeight" vars will capture the size of the browser window. "sWidth" & "sHeight" will capture the users screen size and screen width. You want to track both so you know the average screen size, but also you might want to consider that not everyone has their browser window opened "Full Screen" all the time so you want to capture the browser size and evaluate the difference. Determining a proper range of screen real estate is key. The "ip" is important because you don't want the same person coming back again and again directly affecting your stats so when you pull your data make sure to use "DISTINCT ip, sWidth, sHeight" in your SELECT query to get the data according to the single IP. We want this information to be as accurate as possible right! Use "s" to track your data source. If you have multiple websites contributing to a single database you want to make sure you have a way to separate the website and their result in addition to possible id's for each page. This is important when looking at the big picture and then just the individual site or groups of site.

The ss.setCallbackHandler will handle any population on the page we need to provide. For this example we are simply capturing information so there is no view or result to populate. The setErrorHandler will provide the information needed from an unsuccessful asynchronous call. Finally the addSS sends the variables to the new test object and the method called "addSS".

When you set up your test page you can activate the script by adding the following

That's it! You should have a fast and fairly clean way to track some basic resolution stats. Now how you pull the info is another article. Here is a Sample Report to help you get some ideas of what this data will provide.