One of the hottest topics of 2011 in web design and development was “responsive web design”.
Articulated in “Responsive Web Design” from A Book Apart:
The goal of Responsive Web Design is “write once, view anywhere.” As the number of devices with different screen sizes and features increases, and we undergo a huge shift from desktop to mobile computing, the Responsive Design paradigm uses CSS Media Queries, polyfills, and the usual suspects to create a web page that adapts its layout to the device automatically. The benefits to User Experience are obvious, as well as the huge plus of not having to maintain multiple websites for desktop versus mobile.
While Responsive Web Design is a great move in the right direction, it doesn’t go far enough. The responsive apprach doesn’t specify how to make dynamic, device-sensitive layouts – it only points out the value of same. For example, consider the following media query in responsive design:
<link rel="stylesheet" media=" only screen and (-webkit-min-device-pixel-ratio: 1.5), only screen and (-o-min-device-pixel-ratio: 3/2), only screen and (min-device-pixel-ratio: 1.5)" href="css/2x.css">
In newer devices, a “CSS pixel” is not necessarily the same as an actual pixel onscreen, or “device pixel”. The CSS px is an absolute length unit equal to 1/96 of an inch, but many devices now have resolutions higher than this.On older iPhones, points and pixels are equivalent – 1 pixel in CSS corresponds to 1 pixel onscreen. But on an iPhone Retina, one CSS pixel corresponds to 2 pixels onscreen. Various Android systems have different relationships, and the resolution can be selected in the <viewport> directive using target-densityDpi=”device-dpi”, as described at:
This reminds me a little of the difference between vertex pixel shaders in”shader” languages attached to OpenGL and DirectX programs. You can define vertex colors in a 3D model easily, but depending on the videocard, there may be a lot of pixels colored by that directive. A second system handles the pixels comprising one vertex.
Now, there are a couple of ways of using the responsive web design to provide improved image quality on Retina-style devices. One is to test for ALL pixel combinations, and create a series of high-resolution images adapted for a particular device. But a common method in responsive design boilerplate just uses the highest-resolution images, and scales them down. The iPhone Retina will use the extra pixels, while older devices will throw them away during the scaling process. The end result is an image that is the same size on both displays, one sharper than the other.
What’s wrong with this? It invites page bloat. While this example might not be too bad, and the strong caching of mobile devices limits the number of downloads for a high-resolution image, the net effect is to download more pixels. Extra processing is also required for scaling, and that happens on the local CPU. With web pages tending to an average of 1 megabyte, this could be a significant problem.
An alternative formulation using responsive web design principles would put more emphasis on minimizing downloading and CPU processing. We avoid grabbing extra pixels, and we avoid running scaling filters on the CPU to conserve battery life. Interestingly, an HTML5 boilerplate for this exact approach recently appeared:
32o and Up:
According to the description, 32o and up incorporates principles of Progressive Enhancement along with responsive design. The initial stylesheet is a ‘primitive’, downloading the minimum for all devices. CSS media queries are then used to progressively download additional assets only as needed. To quote:
“…Think of this as responsible responsive design. ‘320 and Up’ is a device agnostic, one web boilerplate…”
I call it Sustainable Virtual Design. While responsive design is a great leap forward, its early incarnations haven’t always included the principles of Progressive Enhancement, which is equivalent to minimizing resources. It may require more effort on the designer’s part (e.g. making more high-resolution images) but there will be a payoff during subsequent use.
This interpretation als implies a specific direction for creating “boilerplate” One should go from simple to complex, rather than the other way around – Progressive Enhancement instead of Graceful Decay.
- Starting from simple devices, chose styles that will work everywhere. This might be most of your design, especially if you go for a “beautiful type” approach like Windows Metro
- Put as many images in the CSS background as possible, then use CSS media queries to download only what you need.
Here’s hoping we see more of this thinking as 2012 unfolds.