Uncarved

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:

Inches

3″ x 1″

Centimeters

8cm x 2cm

Milimeters

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:

Resolution	Devices
320×240	Blackberry Devices: Curve 8530, Pearl Flip Android Devices: Motorola Charm, Sony Ericsson Xperia X10 Mini, others Symbian OS Devices: Nokia E63, others
320×480	Apple OS Devices: iPhone, iPod Android devices: HTC Dream, HTC Hero, Droid Pro, i7500 Galaxy, Samsung Moment, others…
480×360	Blackberry Devices: Torch, Storm, Bold
360×640	Symbian OS Devices: Nokia N8, Nokia C6-01, others
480×800	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
768×1024	iPad
640×960	iPhone 4
1280×800	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:

(unknown)

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).

300px

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.

720px

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.

960px

Desktop-ish screen size. Full-sized images. Hoist sidebar alongside primary content. Any ad size.

1280px

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.

Last Thoughts

It’s worth mentioning that the above breakpoints were defined considering layout capabilities, and do not apply to other facets of potential experience “enhancement” considerations, like whether a sequence of images is best presented as a list or a horizontal carousel, which is much more a consideration left to device capabilities such as JavaScript and/or support for swipe gestures.

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?

Materials

Here are some related materials that inspired this exploration:

• Considerations for Mobile Design (Part 2): Dimensions
• Responsive Web Design Default Breakpoints Are Dead
• State of the Web: of Apps, Devices, and Breakpoints
• Mozilla Developer Network: Using the viewport meta tag to control layout on mobile browsers

And some tools I had in mind:

• Riloadr
• 960gs (and CSS “grids” in general)
• Responsive PX

Web Design css, html5, responsive design, web

John Gruber of Daring Fireball yesterday wrote about the incredible variety of UI solutions to be found in the various Twitter client apps.

From the post:

[T]hat it is not easy to write a good client for something as small in scope as Twitter hints at just how hard it is to write a good app for anything, let alone something truly complex.

I would add only that I feel like Twitter’s simplicity imposes a number of limitations upon developers, which — I believe — contributes in no small way to the diversity of these solutions; engaging with limits is the most powerful catalyst for creative brilliance.

Check it out, UI Design Design, software, Twitter

In contrast with the spirit of yesterday’s link to Designing Convertbots application comes news of the confirmed continuation of effort to bring Microsoft Office to the iPhone.

Absent an iPhone OS device with a significantly larger screen, I can’t imagine any purpose to cramming the UI of Word (or Excel!) into as space with the iPhone’s screen real estate. If Microsoft had any track record for pulling off surprisingly excellent (or even simple and focused) UI solutions, I’d leave room for a verdict.

Who knows? Maybe they’ll actually impress this time.

UI Design iPhone, Microsoft, ux, wtf

Wu Wei is a Taoist concept that means “act without doing,” or “action without effort.” It is an ideal towards which the Taoist aims in life.

One of the hallmarks of great design—whether in a newspaper layout, the construction of a utility knife, or a human-computer interface (HCI)—is its ability to recede, or “get out of the way.” The kernel of this idea is born from the notion that the layperson is typically most likely to take prolonged specific notice of design when it becomes an impediment; when the newspaper’s layout is too cluttered to follow the flow of an article, or using the utility knife’s scissors requires its serrated blade to awkwardly dangle out at 90º.

When a design presents no such distractions, its end-consumer is able to go about his task smoothly. In these circumstances, when the end-consumer becomes immersed in his task, the design of the item they are using is said to “recede.”

The more its design recedes, the more efficient it can be understood to be.

Successful design allows its end-consumer to take action with minimal effort, or—as Kathy Sierra said on the Creating Passionate Users blog back in 2006—to “help [its] users kick ass.”

And so I’ll say now that the official goal of any design should be to foster wu wei.

Design wu wei

Design essay