17 questions when deciding proper webpage length
Jorn Barger
The WWW page-length debate
Say you have a 100k article you want to put on the Web. How many
webpages should you divide it into? The questions to weigh include:
# How long will it take each section to display?
# How much will it disrupt the reader's concentration to load a
new section?
# Is one long page more boring than several short pages?
# Is it easier to understand if different concepts are on
separate pages?
# What if the reader wants to print it?
# What if the reader wants to search it?
# What about net-wide search engines?
# Which will make it easier to find a particular section?
# How many clicks will it take to find the desired section?
# Which will make it easier to maintain the pages?
# Will people scroll all the way to the end?
# Will people forget what's scrolled offscreen?
# Can you make more banner ad money with multiple pages?
# Can you track readers better with multiple pages?
# Is it disorienting to scroll thru a long document?
# Are scrollbars unpleasant to use?
# Are too many choices unpleasant to see at once?
See <URL:http://www.robotwisdom.com/web/pagelength.html> for various
quotations from major web guides on each of these topics.
--
XML for webpages is like plastic bags for comic books.
I edit the Net: <URL:http://www.robotwisdom.com/>
"...frequented by the digerati" --The New York Times
Gary Bunker
'Will people forget what's scrolled offscreen?' question - whether you
have one long page or several short pages, once it's off screen it's off
screen.
But I think they miss the point a little. The main question 'should' be:
"How are the readers of this page going to want to read it?"
Take for example a software review. It's likely that the review is
broken down into segments - an intro, a section about the gameplay,
another about the AI another about scenarios and missions, etc. How is
someone interested in this subject likely to read the review?
It's possible that they are purely interested in the mission scenarios,
and will want to leap to that section, ignoring all others. Possible,
but not probable.
In most cases, the user is going to read the intro, decide if they are
interested enough in the game to read on, and will then continue reading
down until they either hit the end of the review, or find enough
negative information to lose interest.
In other cases, the user may want to know before they read anything if
the game is any good. This type of user is going to want to see a rating
first (10 of 10, a MUST buy!!!) before they read on down.
So the solution here is probably to create either a single page, with
rating synopsis at the top and links to each section. Regardless of how
web search engines will catalog the page or how much money you make
through advertising, this is the right solution for the site users, and
so will in the end succeed.
I'm not saying that these questions are irrelevant - but by focussing on
them, you kind of lose site of the one person who counts. The reader...
Gary
Jorn Barger wrote:
--
Gary Bunker
Usability Consultant
Usability by Design Ltd
http://www.usability.uk.com
To respond to this email, please remove the 'NOSPAM' from the email
adress.
Pio
Just like a teacher does, we should think about our particular audience. A
teacher changes his way of teaching depending on the academic level of his
pupils. We should do the same. There are no perfect recipe. Guidelines
are just guidelines. Know thy user.
Pierre Roberge
Gary Bunker <ga...@usabilityNOSPAM.uk.com> wrote in message
news:38748082...@usabilityNOSPAM.uk.com...
Sim D'Hertefelt
> interested enough in the game to read on, and will then continue reading
> down until they either hit the end of the review, or find enough
> negative information to lose interest.
Isn't that also the ground for Nielsen's advice to write for the web in the
"inversed pyramid"-style (see http://www.useit.com/alertbox/9606.html)?
I.e. put the conclusions or a synopsis of an article at the top of the page,
allowing readers to decide whether they are interested and motivated to
scroll down. I have tried to apply this principle on InteractionArchitect
(see for example
http://www.interactionarchitect.com/research/report20000103shd.htm)
What I would like to know is whether this advice from June 1996 is affected
by changes in on-line behavior. And second, what reusable conclusions can we
draw from our observations that the optimal page design depends on the
specific user group, their tasks and their context of use? Is it possible
to imagine stereotype page designs for recurring user groups, task patterns,
or contexts of use?
Sim D'Hertefelt
s...@InteractionArchitect.com
http://www.InteractionArchitect.com
Jorn Barger
preliminary resource on anchortext at:
<URL:http://www.robotwisdom.com/web/linktext.html>
# Should links be undetectable, from the wording, in a printout
of the page?
# Should anchortext be meaningful in isolation (or when
scanned)?
# Do any web browsers deliver anchortext only?
# Do search engines pay special attention to anchortext?
# Are nouns better than verbs?
# Is 'click here' acceptable?
# How much should you tell the reader about where the link
goes?
# Should you warn about: registration requirement?
# Should mechanical layers like FTP be mentioned?
# Are cute effects like puns acceptable?
# How much abbreviation is acceptable?
# What's the longest acceptable anchortext for a single link?
# Can you use the 'link title' attribute?
# How can you leverage the emphasized styling of anchortext?
# ...with parallel lists?
# Is the target doc's HTML TITLE (or H1) appropriate as
linktext?
# Can you safely change link colors? or turn off underlining?
# How do you place multiple links in the same row? the same
sentence?
# Should you separate (or repeat) links at the end?
# Can you link the same page multiple times from a given page?
[Quotes follow as before.]
Mark Cidade
Criticism of the phrase, "click here," isn't completely universal. Don
Norman once said this in the CHI-WEB mailing list:
"In my not-very-humble opinion, the prohibition against the phrase 'click
here' is someone's bias against what they perceive as tacky, inelegant
writing. (The prohibition) has no empirical backing. I encounter lots of
websites that say 'click here' (usually in catalogs or other ordering
situations) and I find the text useful. It tells me directly what I need to
do rather than making me infer it from the color of the text and the
underline, neither of which are reliable indicators of clickness."
> # Can you safely change link colors? or turn off underlining?
Marc Green would disagree with Jakob Nielsen's opinion that the decision to
make hyperlinks blue are "mother of bad web design conventions ":
"Blue gets a lot of bad ink, not to mention a lot of bad pixels. Guidelines
often say to avoid blue for text and other objects with fine detail. Many
have adopted this mantra without question or inquiry. But studies generally
find blue to be an excellent color for text and foregrounds in CRT displays.
What causes this discrepancy? "
The rest can be found at http://www.ergogero.com/FAQ/Part6/1IsBlueBad.html
Mark Cidade
http://marxidad.editthispage.com
Paul Schlyter
Mark Cidade <marx...@idirect.com> wrote:
Article: 28869 of comp.human-factors
>> # Can you safely change link colors? or turn off underlining?
>
> Marc Green would disagree with Jakob Nielsen's opinion that the decision to
> make hyperlinks blue are "mother of bad web design conventions ":
>
> "Blue gets a lot of bad ink, not to mention a lot of bad pixels. Guidelines
> often say to avoid blue for text and other objects with fine detail. Many
> have adopted this mantra without question or inquiry. But studies generally
> find blue to be an excellent color for text and foregrounds in CRT displays.
> What causes this discrepancy? "
>
> The rest can be found at http://www.ergogero.com/FAQ/Part6/1IsBlueBad.html
small detail, is to not worry so much about color difference, but
instead ensure there's a clear BRIGHTNESS difference between
background and foreground. Dark blue on bright yellow, or the other
way around, is excellent. Even dark green on bright green, or the
other way around, is acceptable, as long as there's a great
brightness difference between the two greens. But you cannot use
e.g. red on green, or green on red, if the red and green are of
approx the same brightness: doing so will make small detial,
including text, unreadable to the human eye.
Color TV work along these principles: brightness difference (good ol'
"black-and-white") are transmitted in full detail, while color
differences is transmitted in reduced detail, to save bandwidth.
It works, since the eye sees color differences at considerably
lower resolution than brightness differences.
--
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pau...@saaf.se paul.s...@ausys.se pa...@inorbit.com
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
Jorn Barger
anchortext are mutually contradictory:
> <URL:http://www.robotwisdom.com/web/linktext.html>
>
> # Should links be undetectable, from the wording, in a printout of the page?
> # Should anchortext be meaningful in isolation (or when scanned)?
> # How much should you tell the reader about where the link goes?
> # Should mechanical layers like FTP be mentioned?
Several authors rightly emphasize that if the linktext leads the reader
to a false expectation about the linked page (what I call a 'gotcha')
then it's very definitely a failure as good linktext design.
Perhaps in the early days when TimBL wrote the W3C guide, it may have
seemed that 'mechanical layers like FTP' would become more and more
transparent, but in fact the range of 'mechanical gotchas' increases
each year. The weblogs community [1] conventionally warns about: large
file size, non-html file format (eg PDF), frames, popups, java,
plug-ins, hard-to-read text, multipage design, slow host, and even bad
spellers. These are all highly important to some surfers, so an
explicit gotcha-alert is just good, considerate design.
Making the alert itself the highlighted anchortext has the advantage of
emphasizing it, but the disadvantage of being unmeaningful out of
context. It seems to me, though, that the out-of-context rule is very
low priority, compared to other issues.
And there's a distinct class of 'gotchas' that I think deserves even
higher priority-- how often have you seen:
...You can read about it in James Thurber's wonderful _book._
where 'book' is a link to (gotcha!) an Amazon sales-page.
I call these 'category errors' and they seem to me the most annoying and
easily solved of web design problems... but it requires throwing out the
undetectable-wording rule altogether, along with the
meaningful-in-isolation rule.
In order to keep the flow of the text readable, while emphasizing the
precise category of the page being linked, I recommend what I call 'text
buttons'-- anchortext consisting usually of a single word set off from
the text-flow by square brackets [like so].
So "...wonderful book [Amazon]" can be distinguished from "...wonderful
book [review]" or "...wonderful book [fanpage]" or "...wonderful book
[full online etext]".
My most advanced current experiment with text buttons is my new
history-of-jazz page [2].
The first thing to notice about that page is that most of the links are
to pages with audio samples of jazz, and I establish a convention, first
thing, that these links will normally be presented as highlighted names
of songs-- not text buttons like [sample] or [RealAudio].
Similarly, because most all the great jazz players are mentioned by
name, and because I want to link the many fine biographical pages about
them, I first added "[bio]" textbuttons after each player's first
mention.
I decided to take this experiment a bit further, though, when I realized
that specifying their ages was usually important at the same point, so
rather than saying "Louis Armstrong (21yo) [bio]" I'm experimenting with
an abbreviated convention like "Louis Armstrong [21yo]" with the
expectation readers will figure out the bracketed age implies a bio
link.
(This has led me to an even riskier experiment, when the sentence
structure requires "21yo Louis Armstrong", where I drop the brackets but
keep his age as the bio-link.)
There's lots of problems I'm still wrestling with-- eg, what if there's
several good biographies? Since webpages frequently 404, it seems good
to link more than one, but where do you draw the line, for readability?
Similarly, if the text-button needs more than a word or two to eliminate
gotchas, should the full bracketed phrase be highlighted, or can you get
away with "Jelly Roll Morton [slow-moving _Flash tribute_ includes sound
samples]"?
If this practice becomes common, we should see a common vocabulary of
text buttons gradually becoming standard:
review, rave, pan, blurb
essay, critique, tribute, memoir
source, cite, definition, info, qv
timeline, history, backgrounder
pix, samples, table
[1] Weblog resources FAQ: <URL:http://www.robotwisdom.com/weblogs/>
[2] Jazz history: <URL:http://www.robotwisdom.com/jorn/jazz.html>
Darin McGrew
> I think several of the most common styleguide suggestions about
> anchortext are mutually contradictory:
This isn't really surprising. Style guides are just someone's opinion of
what looks good and works well. Unless you write for an organization that
enforces a particular style, you are free to use whatever style you like
best at the time.
> Making the alert itself the highlighted anchortext has the advantage of
> emphasizing it, but the disadvantage of being unmeaningful out of
> context. It seems to me, though, that the out-of-context rule is very
> low priority, compared to other issues.
You make it sound like an all-or-nothing situation, either the alert is the
anchor text, or something else is the anchor text. Often it makes sense to
use the alert as part of a larger anchor text, for example:
Before she died, my great-aunt prepared _a genealogy of the
McGrew family (PDF, 1.4MB)_.
> In order to keep the flow of the text readable, while emphasizing the
> precise category of the page being linked, I recommend what I call 'text
> buttons'-- anchortext consisting usually of a single word set off from
> the text-flow by square brackets [like so].
>
> So "...wonderful book [Amazon]" can be distinguished from "...wonderful
> book [review]" or "...wonderful book [fanpage]" or "...wonderful book
> [full online etext]".
This reminds me of the parenthetical references I've seen offline. When
there is an accepted standard, they can be extremely brief. An example
might be:
Jorn Barger (2000) expanded upon text-button theory by ...
An accompanying bibliography includes the full reference details. The
downside is that they become cryptic if you don't know the protocol.
> The first thing to notice about that page is that most of the links are
> to pages with audio samples of jazz, and I establish a convention, first
> thing, that these links will normally be presented as highlighted names
> of songs-- not text buttons like [sample] or [RealAudio].
>
> Similarly, because most all the great jazz players are mentioned by
> name, and because I want to link the many fine biographical pages about
> them, I first added "[bio]" textbuttons after each player's first
> mention.
I think you're overusing the text-button concept here. If I see a person's
name as a link, I usually assume that the link contains more information
about that person. The "[bio]" text-button seems extraneous.
> I decided to take this experiment a bit further, though, when I realized
> that specifying their ages was usually important at the same point, so
> rather than saying "Louis Armstrong (21yo) [bio]" I'm experimenting with
> an abbreviated convention like "Louis Armstrong [21yo]" with the
> expectation readers will figure out the bracketed age implies a bio
> link.
I wouldn't expect a normal bio link in this situation. I would expect some
specific information about Louis Armstrong when he was 21 years old.
> (This has led me to an even riskier experiment, when the sentence
> structure requires "21yo Louis Armstrong", where I drop the brackets but
> keep his age as the bio-link.)
If the bio is about Louis Armstrong in general, then I'd use "21yo _Louis
Armstrong_". If the bio is about Louis Armstrong when he was 21, then I'd
use "_21yo Louis Armstrong_". That way, when the reader scans the page,
the link is meaningful right away.
> There's lots of problems I'm still wrestling with-- eg, what if there's
> several good biographies? Since webpages frequently 404, it seems good
> to link more than one, but where do you draw the line, for readability?
This might be a good time to create a resources page, and to link to it.
That way you have a single inline link in your text, but you can refer to
multiple resources.
> Similarly, if the text-button needs more than a word or two to eliminate
> gotchas, should the full bracketed phrase be highlighted, or can you get
> away with "Jelly Roll Morton [slow-moving _Flash tribute_ includes sound
> samples]"?
That works for me, but so would "Jelly Roll Morton (see John Doe's
_multimedia Flash tribute, 5.7MB_)".
--
Darin McGrew, mcg...@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da...@htmlhelp.com, http://www.htmlhelp.com/
Happy Y2K! Happy Y2K! Happ____o+ooo..___._._.......
Jorn Barger
> If I see a person's
> name as a link, I usually assume that the link contains more information
> about that person. The "[bio]" text-button seems extraneous.
'More info' could be anything, though-- pix, discography, interview,
homepage.
Darin McGrew
>> If I see a person's name as a link, I usually assume that the link
>> contains more information about that person. The "[bio]" text-button
>> seems extraneous.
Jorn Barger <jo...@mcs.com> wrote:
> 'More info' could be anything, though-- pix, discography, interview,
> homepage.
True. It would probably catch me off guard if the linked document included
just pictures or just an interview, but a discography, a biography, or a
homepage (presumably with personal information or links to personal
information) would fit my expectations just fine.
You could use a TITLE attribute on the anchor to clarify exactly what kind
of "more info" the link takes me to, but it isn't a big deal as long as
it's more information about the person.
Mike Anderson
Jorn Barger wrote:
[snipped description of "text-buttons"]
> My most advanced current experiment with text buttons is my new
> history-of-jazz page [2].
>
> The first thing to notice about that page is that most of the links are
> to pages with audio samples of jazz, and I establish a convention, first
> thing, that these links will normally be presented as highlighted names
> of songs-- not text buttons like [sample] or [RealAudio].
>
> Similarly, because most all the great jazz players are mentioned by
> name, and because I want to link the many fine biographical pages about
> them, I first added "[bio]" textbuttons after each player's first
> mention.
>
> I decided to take this experiment a bit further, though, when I realized
> that specifying their ages was usually important at the same point, so
> rather than saying "Louis Armstrong (21yo) [bio]" I'm experimenting with
> an abbreviated convention like "Louis Armstrong [21yo]" with the
> expectation readers will figure out the bracketed age implies a bio
> link.
>
> (This has led me to an even riskier experiment, when the sentence
> structure requires "21yo Louis Armstrong", where I drop the brackets but
> keep his age as the bio-link.)
>
> There's lots of problems I'm still wrestling with-- eg, what if there's
> several good biographies? Since webpages frequently 404, it seems good
> to link more than one, but where do you draw the line, for readability?
Consider a glossary section for your jazz page (or site or subsite or
whatever). Instead of many links to various Louis Armstrong-related items, most
or all mentions of "Louis Armstrong" within the content page(s) would link to a
Louis Armstrong glossary item which would have (among other things) all the
links to the various Louis Armstrong-related items. Links to glossary items
would be visually distinguished from non-glossary links by a special font or
something.
I'm assumming that many links to related topics would be the common case and a
single link topic would be the rare case, so there will not be many glossary
items that contain only a single link.
This format would result in cleaner content (I think the multitude of links to
various topic areas and special link encoded abbreviations is ugly at best,
confusing at worst). There would be no need to use special link encodings within
the glossary item because there's room to spell it out. I also suspect I
would find this structure more usable with all the Louis Armstrong links
grouped instead of scattered throughout the content (of course both sets of links
could be available).
If a glossary is built, it might as well have index info as well: each
glossary item could have a section with a list of links to all references to the
glossary item within the content. (Maintaining many of these two way
references is not something that should be done by hand - does anyone know of a
good tool for this type of task?)
...Mike
Jorn Barger
> Instead of many links to various Louis Armstrong-related items, most or
> all mentions of "Louis Armstrong" within the content page(s) would link to
> a Louis Armstrong glossary item which would have (among other things) all
> the links to the various Louis Armstrong-related items.
I hate hate hate it when every appearance of a name links to the same
URL.
And I'm trying to avoid any sort of two-step (or multistep) navigation.