Many people will tell you that HTML can't do page layout, but that's not true. HTML -- along with XHTML, CSS, and other Web standards -- offers plenty of functionality. The problem isn't the tool, it's what people do with it. This month, I'll take a look at some of the key page layout concepts and explain where (and why) they tend to go wrong, as well as how to fix them.
Page margins are popular, but they're hard to get right. On a large display you can immediately spot a page that's using margins. You can spot it because the text is crammed into a three-micron-wide segment in the middle of the display, with vast empty areas all around it. I exaggerate slightly, but the problem is real.
In fact, you can specify margins two ways: by the width of the material that they'll surround, or by the size of the margins themselves. Either way, users on displays of the "wrong" size will have a tough time viewing the content. If you specify the size of your content, it will be too large for a small display, or small and forlorn on a large display. If you specify the margins, your content will be horribly squished on a small display, but the content might be usable on a large display.
The notion of a reasonable minimum size has been around for some time. Long ago, Web pages specified that they were designed for 800 x 600 displays. Later, the size grew to 1024 x 768. If you assume a reasonable minimum size and set your margins for that specification, then you'll have no catastrophic failures on the systems that you account for.
To be fair, I don't have a single desktop or laptop computer with a primary display smaller than 1024 x 768. On the other hand, I do a significant amount of browsing on devices with a resolution of 480 x 320, or 640 x 480.
In and of themselves margins aren't terribly useful. They can be useful when applied to creating sidebars and navigation menus.
Some supplemental information is hard to order either before or after the main content of a page. For instance, links to related sites shouldn't distract a user from the page's main content, but if you place them too low on the page some users will miss them. In many cases, a sidebar or navigation menu is the ideal solution for this type of situation, as you can unobtrusively run the information alongside your main content.
Sidebars are mainly used for supplementary content: information the reader doesn't need to follow the primary discussion or theme, but which might be interesting. For instance, I've used sidebars in developerWorks articles to introduce a list of acronyms, to give historical background on a point of trivia, and to otherwise expand on my main theme.
Navigation menus are a good way to offer supplemental or related links that a user might want to follow after reading an article or viewing a page. While navigation menus are conceptually smart (consuming little screen real estate and not distracting the reader from the main page), the question of how they'll render on smaller devices is significant. In addition to being used for links and tangential information, some sites use sidebars and navigation menus for ads. A row of ads running alongside an article or e-commerce page can be less intrusive than ads placed at the top or bottom of the page, though some would argue that they might also be less noticed.(Whatever you do, please, do not use flashing ads.)
One of the fundamental problems of early HTML was that everyone wanted to do layout, but HTML didn't provide any way to do it. When tables showed up, they were immediately turned into a layout mechanism -- and a horrifically ugly one at that. The variety of horrors inflicted on browsers and users was genuinely amazing, and some of that old code still inspires snickers and derision years later. Nested tables (often many deep) were quite common, as was the use of "spacer" graphics to set the width of a table element.
Nowadays most people use CSS -- a much better layout tool -- for these purposes. I used to say that it was impossible to over-stress the importance of representing layout in CSS rather than with a table. Then, a friend of mine spent a day or so trying to use CSS to lay out data in rows and columns. Now I say that it's not impossible, just very hard.
Tables are good for tabular data in most cases. But if you start putting large blocks of text in a table, or using tables for other layout elements, something has probably gone terribly wrong with your design. So rethink it.
Pagination is absolutely central to paper page layout. It's significant in HTML, too, but the goals are radically different. On paper, you need to figure out what is an acceptable page size, then render your text and images to make them as usable as possible within those limits. The most obvious change when you start moving a large document to HTML is that the pages no longer have to be all the same size. A good length for a page can vary hugely from one document to another, or even within a document. Technical articles often run between two and three thousand words; this is typically a few pages in a book, but is often best presented as a single long page on the Web.
In HTML, page breaks become a question of logical continuity rather than length. In some cases, it's viable to break a document into sections of some sort; this is often a good match. While you can pick any length you want, keep in mind that short pages can be wasteful or frustrating. This is especially true when you have a lot of supplemental material that is the same on every page, such as navigation menus. In most cases, it's easier for users if the main content of a page takes up more space and is more central than the incidentals.
In layout, the best is the enemy of the good. A page that is intended to render pixel-perfect on one or two specific browsers is likely to be utterly unusable on browsers that are different from the target. On the other hand, a page that looks decent everywhere is fairly easy to create. Stick to broad concepts: "This menu should appear on the left, if there's room," is a good approach. "This menu should be exactly 240 pixels wide" is an abysmally bad approach.
In many cases, one can argue that the users affected by a given design decision are a minority. This is almost certainly true, but they are often in that minority for good reason. Unless you're willing to pay for the laser surgery yourself, for example, please don't insist that users of your site have excellent vision. Users will have a variety of font sizes, a variety of resolutions, and a variety of screen sizes; so minimize your dependency on specific fonts, resolutions, and screens.
I've seen users give up on a site because they couldn't read it, but I've never heard of anyone giving up on a site because it was only clear, legible, and aesthetically appealing, not pixel perfect.
Likewise, don't try to do full-blown page layout in HTML. It's sometimes suggested to use other formats (such as PDF) for documents that must reflect a particular layout. I once advocated this approach, but I've since realized that it's just as bad as overblown HTML. Most users don't want to have to use a special plugin or tool to view a document. Leave special formats for times when you really do need to present an electronic copy of a paper document. The rest of the time, try adapting to the medium. As a user looking for content, I would much rather encounter clean HTML pages than yet another attempt at reinventing page layout.
Try to adapt page layout to the needs of your users:
- Place crucial information before less important information. A button with a legal agreement below it will result in some users who see the button but not the alleged agreement -- a situation that will not end well.
- Similarly, make menus of related links easily connected and accessible.
- Avoid splitting the menu into two parts, especially if the parts are far separated; a user who looks at one might not realize the other exists, and be unable to find a desired link.
Think of layout tools in HTML as hints, not as directives. They are guidelines for rendering, but ultimately the user's browser is in charge. Since the purpose of most Web documents is to communicate data, this is probably a good thing.
This week's action item: When you view Web sites, set your browser window narrower or wider than you usually have it. Which sites work? Which become unusable, and when?
Learn
-
The cranky user: Oh the pixel pickle (Peter Seebach, developerWorks, August 2005): The pixel isn't the only unit of measurement for building graphical displays, you know.
- Quality busters: Compare Web site appearance and functionality (Michael Russell, developerWorks, April 2006): Learn more about CSS and other Web standards that support and extend the capabilities of HTML.
- XHTML, step-by-step (Uche Ogbuji, developerWorks, September 2005): XHTML does more than just standardize tags and characters, it can
improve your approach to Web design.
- In tune with Tapestry, Part 1 (Brett McLaughlin, developerWorks, January 2006): Try Tapestry for more advanced Web design without all the hand-coding.
- developerWorks Web Architecture zone Expand your site development skills with articles and tutorials that specialize in Web technologies.
- The cranky user columns: Read any of the earlier articles in this column.
- developerWorks technical events and webcasts: Stay current with jam-packed technical sessions that shorten your learning curve, and improve the quality and results of your most difficult software projects.
Discuss
- developerWorks blogs: Get involved in the developerWorks community.
Table of contents
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags