06 Jul 2010

Designing the Web for today's devices

rudge's picture
Senior Front-end Developer
3

Consider the devices that we use to interact with the Web. Most of the time we use a mouse, keyboard and screen. Sometimes we use small touch-sensitive screens on a phone. Our notebook computers usually have smallish screens. Sometimes we view the Web on large or very large screens. Or use completely different devices like the iPad and video game consoles.

There is an extremely wide range of devices and screen resolutions that we regularly use to interact with the Web.

Consider the devices and sizes of screens we used just a few years ago, before the iPhone and when large screens were expensive and uncommon;

Popularity (by percentage) of screen widths (by 200px segments), 2007 versus 2010

In 2007, most Web users had screens that were 1024 pixels wide. A few had wider screens. Even fewer were still on older hardware with 800 pixel-wide displays. And mobile browsers were barely used — or even very useful for that matter! Note the narrow bell-shaped curve (in blue), which is heavily centered around 1024 pixel-wide displays, with very few outliers and a low spread.

Now fast forward to today (the red curve), where display technologies are more advanced, have denser pixels and are larger and cheaper. A graph of the same data barely has a distinct center. It is lower and wider, and has many outliers.

Web designers and front end developers face a challenge when designing and implementing layouts for web sites. When the majority of screens were 1024 pixels wide (and most of the rest were only a little smaller or a little larger), fluid-width layouts offered little advantage over fixed-width. And the technical challenge of fluid-width layouts usually offset their advantages for many designers and implementers.

But considering the devices and displays we browse the internet with today, is it worthwhile designing and implementing fluid-width layouts? I think so!

One of many complaints about fluid-width layouts on large screens (like those now commonly found on desktop computers) is that the lines of text become too wide across the page, making it difficult for the reader to follow the whitespace between lines back to the left edge of the paragraph and find the next line. Similarly, fixed-width layouts leave giant margin(s), which often break the background image or other design features. Essentially, the Web breaks when you maximize the browser window on many common displays.

"Adaptive-width layouts" are a great solution for all issues that result from layouts being rendered on displays that are much larger or smaller than what the layouts were intended for.

Adaptive-width layouts adjust the layout of content on the page depending on the width of the display. However adaptive-width layouts are not jello-width (flexible width, with max-width and min-width limits). Nor do they need to be fluid or fixed width. But they can draw on features of both fluid and fixed width layouts. Characteristics that are likely to change in adaptive-width layouts include the number of columns and the visibility or placement of sidebars and/or meta content

As a demonstration of adaptive-width layouts, I have created a userstyle.org stylesheet (inspired by techniques presented in "Responsive Web Design") that formats A List Apart article pages into 2 and 3 columns when the browser resolution is wide enough. It is a proof of concept, so is not widely tested nor complete, and far from perfect.

This screenshot shows the stylesheet in action in Firefox:

Screenshot of an A List Apart article page spread over three columns in Firefox

This adaptive-width layout technique is convenient for large monitors, like the 30-inch monitor (2560x1600 pixels) that I use. It is necessary to note that the stylesheet does not affect page layout when the browser resolution is "small". "Small" is defined as less than 1570 pixels in this stylesheet.

It did not take much effort to translate the original design and layout of AListApart.com to be more convenient and usable for larger displays. About 20-30 minutes for that stylesheet actually. But the enhancements are quite valuable and noticeable for readers using large displays.

This proof of concept demonstrates just one idea for adaptive-width layouts. Similar techniques can be used to adjust layout for devices and displays of other types and sizes, including small screens and mobile devices.

What other ideas and techniques for adaptive-width layouts are there?

The Web is a highly adaptive medium for delivery of content. Web pages are viewed increasingly more on an increasingly wide range of devices & displays, from the iPhone, to large LCD panels, text-only mobile browsers to the iPad, screen-readers to command line web browsers and browsers embedded in gaming consoles like the Wii, Xbox and Playstation.

Web standards, semantic markup and best practices go along way towards making content accessible on all these devices. But in order to create stunning user experiences on these devices, we need to use more flexible layout techniques that readily adapt to any display size.

Footnote

Four different surveys were referenced and used for the statistics and graphs in this article: W3Counter, W3Schools, ScreenResolution.org and Steam. No survey can be completely unbiased or entirely comprehensive, but these all use real data and are the best data that is readily available and easily found. The range and average of these statistics, as well their likely bias, age and possible inaccuracies, has been considered. Note that data could not be found for 2007 for devices in the 0 to 800 and >1600 pixel segments — probably because the numbers for these screen sizes was negligible.

Tags

Comments

no but seriously… did you see that CSS?

from Responsive Web Design:

.figure {
  float: left;
  margin: 0 3.317535545023696682% 1.5em 0;   /* 21px / 633px */
  width: 31.121642969984202211%;             /* 197px / 633px */
}

This isn't realistic, is it? 19 significant figures? I used to try to achieve this level of flexibility and precision, but one little spec change (or different media widths!) made it expensive and unsustainable. I didn't try it again that way.

For this kind of output, I need to use Compass. I'm still stuck on the Blueprint framework, but I want to check out the Susy CSS grid framework (which has a Compass plugin too) because I've heard it's good for flexible layouts.

flexible ?

Nice article and I like where you're going but how is this a good solution ?
The multiple columns create a messy overview (whitespace is gone) and is harder to read than to just scroll down.

Would it be better if the width of the text area would resize instead of cramming everything on one page ?

Too wide

That's one of the points that he's making, I believe. If you just let the main content area stretch wider and wider and wider, you get lines that are 1500 pixels wide. That's very hard to read. OTOH, if you have a fixed width design you get 1500 pixels of whitespace. That's no good either. We need layouts that will adjust smartly to their display size, since we as web developers have even less control over the display size than we used to.

Add comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <sub> <blockquote> <hr /> <pre> <h2> <h3> <table> <th> <tr> <td> <div> <span> <a> <br /> <p> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <c>, <cpp>, <drupal5>, <drupal6>, <java>, <javascript>, <php>, <python>, <ruby>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options