8

Recommending a screen size

Recently I have been doing some research on screen sizes and realized that I had to rethink many of my previous assumptions. As a UX professional I feel it is of utmost importance to understand and confidently communicate which screen sizes to target. Searching this forum gave nothing recent enough.

And so here is a bit of synthesis of my current thinking on two things and I want your input on them:

  1. What the considerations are when deciding on standards?
  2. What the most current screen size standards really are?

1 - Considerations when targeting screen resolutions

960, 980 or 900px? Which ones do we chose and why?

  • Based on current statistics (see links at bottom)
  • Grid systems (dividable by 12)
  • Standards based (what is the industry doing?)
  • Safe zones (smaller than the screen-res)
  • Don't forget mobile (320 or 480)
  • Looks at your site analytics

1 - Current screen size standards

When a design grid is considered:

  • 320 or 480 ?
  • 960 (captures 1024 > 1279) {http://960.gs}
  • 1140 (captures 1280 > ?) {http://cssgrid.net}
  • ?
Screen statistics

From StatCounter - May-June 2012

Screensizes: (market size in %)

  1. 1366x768 - 20.5%
  2. 1024x768 - 17.43%
  3. 1280x800 - 12.24%
  4. 1280x1024 - 7.16%
  5. 1440x900 - 6.47%
  6. 1920x1080 - 5.57%

Width percentages: (market size in %)

  1. 1920+ - 7.06%
  2. 1440-1680 - 14.13%
  3. 1280-1366 - 46.37%
  4. 1024-1152 - 21.71%
  5. 768-800 - 3.23%

General Thoughts

  • What are the safe sizes in most browsers?

    There are "safe zones" but the reality is that these restrict design A LOT. No source has been found showing a breakdown in terms of the actual inner width of the browser.

Links

Statistics on screensizes

Don't use:

4
  • 1
    The grid used by a designer in layout is a tool; I do not think choice of tool is really a UX issue. A better question (and one that has been answered before) might be 'what maximum resolution should I target' or 'Should I limit my layout to a maximum width, or flow to use the full width of the browser'. Those are UX issues. But the limitations a particular tool imposes upon your design (such as a layout grid) is not. Commented Jul 11, 2012 at 20:37
  • 1
    Why are you looking at screen size rather than application-window size? On a phone or tablet that makes sense; on a desktop machine, unless your application is guaranteed the entire screen, it doesn't. Commented Jul 11, 2012 at 21:09
  • @MonicaCellio, true but it is the only thing I have statistics on in order to inform my choice on whether to design for a certain screen size or not. Commented Jul 11, 2012 at 22:24
  • This is going to sound trite, but collect the stats, then. It's a better measure all round, so no reason not to collect the data.
    – kastark
    Commented Jul 12, 2012 at 6:18

3 Answers 3

5

First, to my knowledge, there are no standards here (at least no formal ones). The de-facto standards we have (like the 960px one) come about because of manufacturers more-or-less standardising hardware screen resolutions (lately with the help of VESA).

Microsoft recently posted their telemetry data in this area for Windows 7 users:

Windows 7 screen resolutions chart

Image from Building Windows 8 (MSDN Blogs)

As the chart shows, classical 4:3 and 5:4 resolutions form a tiny chunk of users compared to newer 16:9 and 16:10 displays. It shows, too, that the horizontal resolution (which seems to be what you're asking about) is effectively always at or above 1024px.

Depending on your audience that may be enough, but some factors should be considered:

  • Designing against a fixed width tends to mean you cater to the smallest displays you target; are you making the experience rubbish for users with very large (27-inches and greater) displays in order to make it OK for netbook users?
  • Mac users behave very differently to Windows users—Windows users can (and in my experience, generally do) run their applications maximised full-screen. On the Mac (which doesn't use a taskbar to represent open windows), it's far less common to see a user with their windows occupying their full screen width (e.g. the "zoom" button in Mac OS X only increases the window to "the size and location that your application considers most convenient, considering the function of the document and the screen space available", as explained here)
  • Scrollbars are being increasingly hidden (or changed so their width doesn't affect the content area)—in Metro IE in Windows 8 and Windows RT, the scrollbar starts hidden:
    IE 10 Metro interface, running full-screen
    …but if you begin to scroll, a scrollbar is shown over the content area (which then fades away). Here's the touch-screen and mouse scrollbars respectively:
    IE10 touchscreen scrollbar IE10 mouse scrollbar
    The same goes for OS X Lion, which (by default) uses hiding scrollbars:
    OS X Lion scrollbar in Safari
    …and naturally the same applies on iOS devices like iPads.
  • Speaking of iOS devices—the proliferation of tablet computers and smartphones means even on a single device, you generally need to design around two possible orientations. So just because an iPad has a 1024×768 resolution doesn't mean you can use a 960px grid as you might on a 1024px-wide desktop display; many (or even most) will experience your site at 768px wide.
  • In Windows 8, Microsoft is introducing a new "snapped" view 320px-wide in which your site may be loaded. They're currently advising developers to use responsive design to adapt dynamically to the narrow window (which resolution I presume was chosen because of the proliferation of sites being designed to accommodate the iPhone and other similar smartphones).
  • There is a long-standing principle in typesetting of limiting the line length of your content to make it easier to read (ostensibly making it easier to track your eye from the end of one line to the beginning of the next), although there is evidence to suggest that limiting line lengths may be unnecessary (which would make it more a question of beauty than of actual readability). Nonetheless, this may be a factor in your decision to use a fluid layout. Anecdotally, very long line lengths are extremely annoying on a smart phone where the user will need to zoom in to read the text and then perform a lot of small tracking pans to read a single paragraph of text.
  • There is a significant cost involved in designing and testing a responsive layout (which increases as the number of distinct layouts increases). That may make it impractical to design around.
5
  • Am I the only one who finds the 1px gap beside the Win8 scrollbars look broken?
    – Jonathan
    Commented May 8, 2014 at 9:13
  • @Jonathan: If you look at it closely, it's a 1px border around the whole scrollbar. I can't say for sure, but I think it's to help outline the scrollbar on grey backgrounds (backgrounds that are the same colour as the scrollbar itself).
    – Kit Grose
    Commented May 8, 2014 at 23:59
  • It's not a border, it's the background.
    – Jonathan
    Commented May 9, 2014 at 8:03
  • @Jonathan: nope, it's a border (it is semi-transparent, though)
    – Kit Grose
    Commented May 9, 2014 at 8:07
  • Well, in that case they shouldn't have made it transparent, since this will solve nothing on a grey background and still looks broken ;)
    – Jonathan
    Commented May 9, 2014 at 8:07
3

Ignore all of that and research 'responsive design'.

The reasons:

  • screen sizes are getting more varied by the day...both larger AND smaller
  • screen sizes are rarely the actual issue...it's browser viewport sizes that actually matter
10
  • I know what responsive design is. I read the ALA article when it came and have read the ALA book. I also have and have read the Mobile first book by LukeW. That is actually one of the main reasons I ask this, because these days I need to design for both 1024, 1280, 1366 and 1440 screens and responsive can be either fluid or change on "width stops" - what my conclusion is so far is that designing for 1024 catches the 1280 size (just has a little extra margin on each side) and the same goes for the other to sizes. Design for one below and capture the size above it as well. Commented Jul 11, 2012 at 22:35
  • Right now I am actually totally confused where to put my money, 320 or 480? There is a big difference there. Commented Jul 11, 2012 at 22:37
  • 1
    The point of Responsive Design is not to let it do what it do. When responsive design is either sketched by a UX Designer, or designed by a Visual Designer or built by a Developer someone needs to think "Am I designing this for 1024 or 1440?" because the layout is different and so you need to know that. What do you tell your developers when they ask you which screen sizes to target? If "have it work for anything between 320 and 1440px" is you answer then then I feel you don't understand what responsive design is and how it is built. Commented Jul 11, 2012 at 22:52
  • 2
    We obviously have fundamental difference of opinion on what responsive design is. To me, it's not dealing with specific screen resolutions. It's making sure that the site functions appropriately regardless of the resolution. You have to design things to accommodate the resolutions, but you don't need to get hung up on specific screen resolutions.
    – DA01
    Commented Jul 12, 2012 at 0:05
  • 1
    "because the layout is different and so you need to know that" Ah, I see what you are getting at now. I agree with you, and that is the purpose of responsive design. But you're not necessarily designing separate layouts for every conceivable resolution. Rather, you're hitting 'sweet spots' as you go and building with lots of wiggle room. What those are depend on a number of factors, but I wouldn't aim for too many of them. Stay loose.
    – DA01
    Commented Jul 12, 2012 at 0:10
0

As with almost everything in UX "it depends". To directly answer your questions:

What the considerations are when deciding on standards?

You could look at this a couple of ways a) what are your current users using? or b) what are the users you intend to target using?

If you don't have any data to go on specific to your product (which would be the best kind) you can fallback to industry trends. Look at device ownership if targeting mobile, look at aspect ratios and monitor size usage and default resolutions for desktop etc. You (and likely need to) can make a call as to what you want to support, either through specific inclusions and exclusions based on what your product is, what the market for the product is, business drivers, client support requirements etc. This is the same rationale for saying something like you don't support IE6 anymore as the market share is not relevant for many products.

What the most current screen size standards really are?

As above, this totally depends on what you're making and for whom, but as a rough rule you should look at physical maximums and minimums, what's the smallest common mobile device out there (I consider something like the iPhoneSE/5) and what's the largest desktop resolution out there (probably safe to say 4k for now). Now within that, as you've commented, you could make everything fluid, but this will force some awkward design compromises which aren't for everyone.

Another approach is to define breakpoints which match common device sizes, start at the bottom, and work up, utilising progressive enhancement to add more if it is needed(not for the sake of it). It's perfectly reasonable to keep your body widths narrower than the device resolution when you consider aspects such as reading line length, image sizes, or just whatever the content is, stretching to fill all the available space is very often undesirable.

So what am I saying? really I could sum it up by saying:

  • Find your breakpoints based on usages stats and common devices you need/want to support. Aim for fewer and only add them if you really need them, more breakpoints is more work.
  • Consider your design first across these breakpoints, you don't always need to change things to fit, centre aligning and keeping the same width is perfectly acceptable if it fits the design.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.