Advantage of Long, Continuous pages over Short, Isolated nodes.

I Find Karma (
Tue, 24 Feb 1998 02:48:01 -0800

There's a long, sprawling stream of consciousness by Michael Hoffman at

that discusses the premise that the scrolling page with hyperlinked
subheadings conveys large-scale information structure better than
isolated cards. The parts I liked I include below.
-- Adam

Tim Berners-Lee's Web-page model visually concatenates and presents
nodes into long scrolling pages. The "page" construct is designed to
have multiple hypertext nodes placed closely together. The Web's "page"
model falls completely outside the fundamental "card" model assumed by
the radical hypertext theorists -- who say that hypertext is so
wonderfully new and radically different, writers now have to maintain
two separate source documents: one designed for hardcopy, and one
designed significantly differently, for online.


In WinHelp terms, there are advantages to presenting a long series of
contiguous nodes within a single scrolling window, over isolated nodes
each in their own window. In WinHelp, it comes down to whether or not to
insert a pagebreak before each footnoted heading, during the authoring

If two nodes are very closely related, the writer should consider
joining them into a single scrolling page, to visually reflect
this close relationship.

Over-fragmentation of nodes weakens the relative context among the
paragraphs and lowers the visibility of the information structure.

It's faster to hit Page Down than to wait for a new page to
download. A long text page takes only slightly longer to
load than a short text page, so overall connect-and-download time
is much less, with long text pages.

About Web site usability, Jakob Nielsen wrote in bold, "speed must
be the overriding design criterion."

You can print a set of related topics easily.

The "Find String within Current Document" feature becomes more
useful, because the scope of 'Find' is expanded to more than just
a couple paragraphs.

You can skim easily, by feeling and pressing the PageUp/Down and
ArrowUp/Down keys, without having to take your eyes of the body
text and aim the pointer at a link.

You can spend more time reading and less time navigating. The
author can suggest a sequence of presentation, yet you can scroll
rapidly to another topic, retaining your orientation in terms of
physical distance.

You can still have links from one subsection to another; a single
long chain of nodes does not lose hypertext functionality compared
to a group of isolated nodes. Either way, each subsection starts
with a heading and hypertext anchor that any other subsection can
jump to.

You can view related sections contiguously and handle them as a
single entity, a set.

Vertical scrolling is far faster than link-traversing, especially
on the Web.

Vertical scrolling has lower cognitive overhead than aiming
the mouse pointer and clicking a hot spot.

Scrolling is much faster than page retrieval or link
traversal time. Scrolling down is a smoother, faster action
than aiming the mouse and traversing a link over the
Web. You can rest your finger on the PageDown key, without
looking or aiming, and concentrate on reading. You
effectively get a larger screen, because contiguous vertical
text is almost seamlessly connected, whereas jumping to
another hypertext page has the effect of abandoning one area
of screen real-estate and replacing it by another.

Longer pages with multiple topics support obvious visual

It takes fewer aiming, mouse, and keyboard actions to scroll
than to select a link.

Your eyes skim much faster than your fingers can aim and
point. You can take in multiple topics almost simultaneously.

It's not really a matter of promoting a certain *node* length as ideal -
let us all assume that the ideal node size is about the size of a large
index card; this is not the real point of controversy. The real issue
with whether to scroll is the issue of when to position paragraphs
contiguously in a single topic, and when to position paragraphs in
separate pages. For most nonfiction, non-reference documents, there
should only be around, say, 5 inches of content between subsection
headings. If there are more than three prose paragraphs in a row, then
try labelling each paragraph, and come up with a subheading or two to
divide the paragraphs into groups. You'll need to decide whether to make
any new subheadings show up in the ToC and other navigation devices; any
subheading is a potential destination anchor (a linked, not merely
visual, entry-point).

There's a popular assumption that if some granularity is good, then a
lot is better, resulting in schizophrenic fragmentation of articles into
separate chunks. This draws too much attention to the flash of hypertext
itself, until hypertext fragmentation actually gets in the way of
reading and comprehension. Even single-sentence nodes would be ok, for
communicating conceptual information, as long as there are higher-level
structures to visually join all these widespread bits of text, and
search structures at the "article" level rather than only at the word or
sentence level.

The most basic principle or technique of information structuring is the
device of subsections, demarcated by a hierarchy of headings, shown with
larger or smaller fonts.

It's equivalent whether you use a hierarchy of modular, hierarchical
subsections in hardcopy or a hierarchy of structured hypertext
nodes. There is little advantage to breaking up a long document into
multiple small windows, rather than just using headings to gently,
visually indicate subdivisions within a single longer window.

The rules of design that apply to task-oriented topics should be
addressed separately from the rules that apply to conceptual
topics. Heuristics for navigation design for an exploratory recreational
environment (such as Myst) are different than those for a technical
document. Learning a new large domain, such as database technology,
requires a different formatting and text layout than looking up a bit of
reference information or an isolated task.

People prefer to read in-depth conceptual material on hardcopy. If
necessary, they print from the online version. Online can partially
emulate hardcopy by using hardcopy-like visual structures -- such as
long topics containing traditionally-formatted subheadings. (The ability
to print the hierarchical outline for a selected branch of a
structured-hypertext tree also bridges the gap between online and
hardcopy, for extended reading.)

Rather than banning scrolling, we should promote modular writing; that
is, small, fairly self-contained subsections demarcated by unambigous
headings. The headings need to be visually formatted to clearly suggest
their relative hierarchical levels. Each subsection can contain
cross-references to the other subsections.

Nielsen's usability labs should have no problem proving the opposite of
"users hate scrolling": that on the other hand, "users hate overly
granular chunking". Just like Nielsen's list of specific problems with
frames, it's possible to make a list of *specific* problems with overly
granular node chunking.

"Avoid long pages" is an overly broad rule, needing so much
qualification, it becomes invalid as a general statement. More to the
point is the issue of *when* to use short pages and *when* to use long
pages. An even more important issue is using headings well to reveal the
information structure. A short hypertext node is equivalent to a
subsection within a book -- for example, a heading level 3 followed by a
section body consisting of a few paragraphs and lists.

Long, scrolling trains of nodes containing plentiful, hierarchical
subheadings are effective. There are parallels between heading-delimited
sections in traditional hardcopy, and single-heading nodes in
hypertext. You can concatenate two short, closely related nodes into a
single longer node, as long as you use a subheading to delimit the
intra-nodal compartments, which are simply traditional subsections, one
after the other.



Linear layout, with scrolling, supports visual contiguity, which is
essential for rapid comprehensibility.
-- Michael Hoffman

No user reads documentation straight through.
-- Rohit Khare