Re: hyperlink style question

[Jim Purcell <jimpur -at- MICROSOFT -dot- COM>]

Scott Miller writes:

> Also:  In-sentence hard jumps (jumps that close a topic and open
> another) should
> be avoided.  (In-sentence pop-up window jumps as in WinHelp are fine,
> if they
> aren't over-used.)
>
This statement implies that the very thing that makes hypertext such a
useful advance over print documentation is the very thing we should not
use.  What is hypertext without hard jumps? Just a serial display of
book pages.

> It takes more words to say "See Creating a process," but it
> makes it very clear what the jump is to.  If you say "you must first
> _create a
> process_ in which the server application can run..." the user is not
> certain
> what the jump is to.  An overview topic?  A procedure topic? A
> glossary
> definition?  If you say "See Creating a process," it's clear that this
> is
> probably a procedure topic about creating a process.
>
There's an assumption here that jumping is either difficult or
time-consuming. It also assumes a context-free environment. The
thoughtful help author will insert jumps in such a way that the reader
has a pretty good idea what's on the other side: a definition, a
conceptual essay, or a procedure. In this case, I would be led to expect
a procedure. If I jump to "Creating a Process" and find the topic too
detailed or not detailed enough or not what I expected, I have only to
click the "Back" button to return whence I came. In a help system that
is stored on the hard disk or a CD-ROM, this is a very cheap and easy
operation. In a help system optimized for the Web (no superfluous
graphics, for instance), it isn't bad even over the Internet. Explicit
cross-references still have their place, of course, but hypertext offers
us alternatives that are often better.

For an example of in-sentence hard jumps targeted at the general reader,
see the Atlantic Monthly Web site (http://www.theatlantic.com). They
publish whole articles from the magazine, but they format some article
text as jumps to other sites. These jumps extend the articles in ways
that print cannot match, and they do it very unobtrusively. The
Atlantic's Web designers don't seem to be concerned that readers will
wander off and not find their way back.

> Every time you provide a hard jump, you should conclude that the user
> will get
> lost in hyperspace.
>
Maybe I'm spoiled by writing for programmers, but I can't believe that
this is a serious problem. Most help browsers provide one or more bread
crumb trails. You can repeatedly click the "Back" button, you can view
the history list, or you can bookmark topics you intend to come back to.
As more and more people use the World Wide Web, they will find the
navigational demands of an online help system less and less daunting.
You have to know who your audience is, but I'm guessing that this
assumption that every jump is a leap off a cliff is not as valid as it
may once have been.

> You want to make sure that the user knows if he or she
> needs to make the jump.  A jump to a vague target is likely to get
> used by
> people who don't really need to make that jump. Spelling out the topic
> title
> lets them know exactly what they're jumping to, and they can better
> determine if
> they want to make the jump.
>
There's a good deal of room between a "vague target" and an explicit
guarantee of exactly what you want to read. What is an acceptable level
of uncertainty? What can the help author do to minimize that uncertainty
without shifting the reader's attention away from the topic and toward
the cross-reference? How will the answers to these questions change as
hypertext literacy becomes more nearly universal?


Jim Purcell
mailto:jimpur -at- microsoft -dot- com
My opinions, not Microsoft's

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html