Oct 31 2007 at 1:10pm

1280×800 Overtakes 1024×768? + Stats Variations by Audience

When I checked the site stats last month on my (old) work site I found a big surprise. That’s right, 1280×800 had overtaken 1024×768 as the most common resolution. And not just overtaken it, but surpassed it by over 6%.

Note: All screenshots were taken on October 23, 2007.

September 2007 Screen Resolutions for Housing.uwaterloo.ca

September 2007 Screen Resolutions

October 2007 Screen Resolutions for Housing.uwaterloo.ca

UW Housing Screen Resolution Stats, October 2007

Disclaimer

Now, I have to disclaim this by saying that this is a University site, targetted to University students, who tend to buy new laptops before they start their first year. However, widescreen laptops are becoming more and more common, and I’d expect to see similar trends on sites targetting more technically aware audiences.

October 2007 Screen Resolutions for the UW Home Page

Similar trends can be seen on the UW home page:

UW Home Page Screen Resolutions, October 2007

Disclaimer: the problem with these numbers is that the UW home page is set as the home page in all the computer labs across campus plus a lot of staff/facutly/student computers. About 40% of traffic to this site is internal.

On this site, 1280 hasn’t overtaken 1024 but it’s getting close. Notice that 800 x 600 is at 2%. I’d also like to point out that all of the resolutions bigger than 1024 add up to 57.6%. So why are we catering our design to 2% of visitors??

October 2007 Screen Resolutions for the UW International site

UW International Screen Resolutions, October 2007

This site sees a much bigger percentage using 1024 x 768 and more users at 800 x 600. However, the resolutions above 1024 still add up to over 40%.

Implications

Which Resolution to Design for?

Many designers tend to optimize for users at 1024 x 768 or even 800 x 600. In fact, I had a big debate at TWF about which resolution to comp for (deriving from Cameron Moll’s suggestion that most designers were comping for 1024 x 768). Many of the respondents instisted that it was necessary to comp for 800 x 600, even though the majority of their visitors were using 1024 x 768 or higher. I argued that a design should look “best” for the majority of visitors, look “good” for the widest range possible, and at least work for the rest. (In reality, I usually comp much bigger than that while staying within a 1000 px wide frame. Or 960, as Cameron suggests!)

As we can see here, for some sites there may be very few visitors using 800 x 600. Why optimize your design for that small group instead of catering to the majority?

But, Do Users Maximize?

The short answer is that we don’t know. Roger Johansson did a survey not too long ago which found that 50% of respondents maximized their browser window. However, this was on a site targetted to web developers so it certainly can’t be applied to most audiences.

Then there are the assortment of toolbars and browser chrome that could be taking up even more space. How do we know about that? We don’t.

This is quite a change in how we think about design. When users had smaller screen resolutions we could assume that they usually maximized. Therefore, we could count on a certain amount of available screen width. As monitors grow larger these screen resolution stats become increastingly difficult to interpret, since users will be more likely to have added toolbars or non-mazimized windows when they have the space.

So Which Resolution Should I Design for?

My current preferred method is to do a layout that is flexible within limits. This site works that way – it scales between 800 and 1024 px. However, although I don’t have the screen resolution stats for this site I would imagine that most are using larger resolutions. Shouldn’t I take advantage of the screen space they have available? When I redesign this site I may consider doing it flexible between 1024 and 1280.

Update: This post was published briefly last week but I had to updgrade my database and lost my most recent version. Sorry for any confusion this may have caused

Comments RSS

Leave a Comment


(will not be published) (required)