 | Level: Introductory Peter Seebach (crankyuser@seebs.plethora.net), Writer, Freelance
03 May 2006 When you have more control over page layout, more things seem to go wrong. This month, Peter explains how page layout goes awry.
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.
Margin(s) of error
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.
Sidebars and 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.
|
Like this, see?
The question many people have about sidebars is When do people
read them? I suspect some read sidebars only when they're finished with
the article, while others read them as soon as they see them. And of
course there are probably some people who don't read them at all.
Which one are you?
|
|
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.)
Layout tables
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.
Page breaks
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.
Mistakes to avoid
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.
Some helpful hints
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?
Resources 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
About the author | 
| | Peter Seebach has been using computers for years and is gradually becoming acclimated. He still doesn't know why mice need to be cleaned so often, though. |
Rate this page
| |
