The practice of defining “breakpoints” (of screen sizes) is a commonly-used mechanism the Responsive Design world as a mechanism for determining what sort of styling rules, experience enhancements, and even types of assets ought to be delivered to users viewing site content with their particular device.
I’ve typically seen these breakpoints chosen with iOS devices in mind:
320px and up for handheld,
786px and up for tablets, and then
1280px and up for laptops and desktops.
But there are loads of devices being shipped by a variety of manufacturers, whose phones are larger, and whose tablets are smaller. And let’s not overlook the possibility that the number of devices will only continue to grow into the future, even if all you might claim to care about is Apple’s iOS mobile devices (which, IMO, isn’t any smarter than slapping a “Best Viewed in Netscape 4″ badge on your website).
So, how better to think of these breakpoints?
One might suggest that a “theoretically pure” approach would be do consider the physical size of the display and to offer up a design and assets that would be experienced well, given that space.
The trouble is that devices have different pixel densities. And before we get all excited about the fact that CSS also supports real-world sizing units, like inches and millimeters, I regret to have to report that these aren’t reliable, either. Even iOS devices, whose screen sizes are extraordinarily well-defined, render real-world measurement units at 3/4 size of the desired sizing (i.e., a 2-inch wide
<div> rendered on an iPad measures 1.5 inches with a ruler).
In case you want to check this claim out for yourself:
3″ x 1″
8cm x 2cm
80mm x 20mm
Purity, as you can see, is rarely practical.
Still, the general goal of matching up layout styling rules appropriately for a given display size is a sound one. And so I’m thinking a more pragmatic approach with similar goals is in order.
Devices and Their Imperfect Pixels
For better or worse, the digital design world uses pixels as the de facto measurement unit. Now, anyone with a lick of experience with digital design (whether it’s creation, implementation, or troubleshooting) will immediately realize that there’s loads of pixel size variety between devices. Very roughly, PC screens have an average pixel resolution of 100ppi, while mobile devices have a resolution of about 160ppi.
This is in no small part thanks to the fact that the original iPhone was a 160ppi device, and to Google’s “device independent pixel” work (also called “dp” or “dip”), which notes:
The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen, which is the baseline density assumed by the system for a “medium” density screen.
So, given this loose “pixel-standard” sizing practice, I hunted around for some reference that outlined the screen sizes of some common mobile devices, and found this handy already-year-old matrix from UX Booth, reproduced here for convenience:
- Blackberry Devices: Curve 8530, Pearl Flip
- Android Devices: Motorola Charm, Sony Ericsson Xperia X10 Mini, others
- Symbian OS Devices: Nokia E63, others
- Apple OS Devices: iPhone, iPod
- Android devices: HTC Dream, HTC Hero, Droid Pro, i7500 Galaxy, Samsung Moment, othersâ€¦
||Blackberry Devices: Torch, Storm, Bold
||Symbian OS Devices: Nokia N8, Nokia C6-01, others
- Android Devices: Liquid A1, HTC Desire, Nexus One, i9000 Galaxy S, others
- Maemo (Linux) Devices: Nokia 900, others
- Windows Mobile 6 Devices: Sharp S01SH
- Windows 7 Phone Devices Venue Pro, Samsung Omnia 7, HTC 7 Pro, others
- Android Devices: Motorola Xoom, Samsung Galaxy Tab 10.1
- Windows OS Devices: Asus Eee Pad EP121
- Apple OS Devices: Axiotron Modbook
Please note that this is a very limited list, and is by no means complete. What is important to take from this data is that a wide range of screen resolutions are out there, and new devices are introduced constantly.
Starting with this survey of device screen sizes, let’s loop back to the idea of using layout capabilities afforded by the display area as the central concern in identifying our breakpoints: which display width offers “enough room” for a image floats, and which for multiple columns of content?
Next, let’s keep the number of breakpoints practical, for each one introduces some amount of development and maintenance overhead. We’ll need to balance “enough to be useful” vs. “too many to manage”.
Here are my recommendations:
Presume “handheld” / feature phone. Single column. No floats. Serve images at their smallest dimensions (up to 64px wide, usually best served at around 40px-ish).
Handheld-ish device. Single column. No image floats in primary content. Serve images at a “medium” dimension (300-400 px wide), allowing users to “pinch” to zoom in, etc. Tile ads OK.
Tablet-ish screen size. Honor image floats in primary content. Larger images. Still presenting primary content in a single column (i.e., not hoisting sidebar alongside primary content, but potentially giving the sidebar section two columns?). Banner and Tile ads OK.
Desktop-ish screen size. Full-sized images. Hoist sidebar alongside primary content. Any ad size.
Desktop “plus”. Consider adding supplemental stuff off to the right, like how Facebook automatically adds user chat to the right for wider screens… might be real-time social activity.
And don’t forget the idea of 2x image assets for high-pixel density devices (like the new iPad, with its Retina Displayâ„¢), which starts to open the bandwidth measurement can of worms.
What do you folks think of these breakpoints?
Here are some related materials that inspired this exploration:
And some tools I had in mind: