Navigation Tag

Hi-

I have an idea for a new tag. I've included a rather lengthy (sorry!)
desciption of it below. I have searched through the CSS1 & 2 guidelines, and
some XML specs, and I haven't seen anything like it; if someone knows a
simpler or more effective way to achieve this, please let me know.

I propose a universal navigation markup tag. Using this, the author of a web
page could designate the address of the next or previous page in a sequence.
This would be similar to the site-specific navigation links commonly found
in multipage news articles, search engine results, or photo galleries, with
the advantage that it could be exploited by a browser.

This would allow the reader of a page to utilize a uniform and easily-found
navigation interface, much as one might use the "Back" or "Forward" buttons
of Opera, IE, or Netscape to negotiate the sites one has already visited.

One major advantage to this concept is that a browser could map the
navigation tags to keyboard activities (I am using CTRL+Arrow Keys); this
could be of great utility to emerging web appliances such as webpads,
web-enabled cell phones, and consoles (WebTV, Sega Dreamcast, etc.), as well
as interface devices such as remote controls or specialized mice. In
addition, this could aid navigation by handicapped persons, providing a
voice-accessible or one-button control for people with limited movement, and
a discernable control for visually-impaired persons using text-to-voice
browsers (since many current "Next Page" links are actually graphics, rather
that text, the problem would be compounded for them). No longer would users
have to scroll up or down to the proper link to continue on in the sequence;
they could move forward or back no matter where the link is placed on a
page--if visible at all.

In order to ensure compatibility with older browsers, as well as ease and
consistency of implementation by authors, this navigation tag could be
optionally tied to traditional navigation links. My take on this is that any
particular HREF tag could be given a new argument corresponding to a
navigation direction, or possibly to an element of a list or navigation tags
predefined on the webpage. Obviously this HREF still could be iconically or
textually represented as well. Perhaps the mere presence of such a NAV tag
might be used by a browser to display all the included information in
graphical/text format on the page.

Required arguments to the NAV tag would be the target page, and the label to
be assigned it (for purpose of standardizing controls). Selecting labels
easily mapped to keys would be intuitive in the case of left and right
arrows indicating the previous and following page in the sequence, while the
up or down keys could refer to either top of page and bottom of page or the
ascent or descent in a hierarchic document structure, depending on how the
were targeted and labeled.

Optional arguments to the NAV tag might provide additional information, such
as specifications on the number of pages in the document or the title of the
target page (or ALT text), to be accessed by various browsers in different
ways (displayed, perhaps, in a dedicated navigation text/combo box).

Simple labels such as NEXT, PREVIOUS, UP, and DOWN would suffice, with
additional navigability possible through browser-specific implementations of
the page-numbering system. Using this interface, someone with only a remote
control could successfully and easily navigate a well designed site, with
the browser software interpreting a "beginning of file" button or hotkey to
mean "page 1 of current document", and specific pages of large documents
could be selected as intuitively as TV channel selection. Alternately, a NAV
argument could be assigned to a META tag referring to the current page, to
identify it for enabled browsers. Such a system might even aid authors in
composing well-organized web documents and sites, extending the current ad
hoc hyperlink system, permitting order without imposing it.

To extend this concept beyond the document-specific level, additional
self-referential NAV tags could be created, such as root or home for the
root directory, but this would be cumbersome to assign to each page, and
would be better suited to realization for any given browser, which could
strip off hierarchical extensions one by one. Interestingly, though, I could
see a browser extension that would scan whole sites dynamically, looking for
NAV tags and indexing them for a user (kind of frightening...bit of a server
hog. Perhaps a solution to this would be to have a site map with NAV tag
labels attached, generated statically or semi-dynamically on the server
side. To preserve memory space on stripped-down websites intended for
handheld or low-bandwidth devices, an additional argument might point to
such a site map. That's all a bit down the road, though).

Of course, this scheme does not address the larger related issue of
navigation sidebars (particularly expanding JavaScript menus), as they
generally deal with a hierarchical, rather than sequential, structure. I
believe, though, that it would be a start. Perhaps an additional argument
option (LEVEL=A) could be added, which would add further regimentation to
website construction...not that that's always a good idea. This could
needlessly get very complicated, too, especially in negotiating between
multiple sequential documents on the same hierarchical level. If such an
issue were to be included, I would favor a nested decimal system for page
specification (1.2.3.4) instead of a true hierarchy--it seems less complex.
Sidebars with NAV-defined links might easily serve as the aforementioned
site-map, perhaps.

To return to the simplest implementation of this idea, here is a sample
illustration for the second page of a five-page web document, showing both
the current and target page information in one tag:

<NAV LABEL=NEXT PAGENUM=2 PAGES=5 PAGETARGET=3 TITLE="Building a better
mousetrap" HREF="www.mousetrap.com/howto/build3.html" IMG
SRC="rightarrow.jpg" ALT="Next page...">

In terms of how to implement this idea, there are two main issues. First, it
must be able to be used by a person accessing the webpage; for this, a
simple plug-in for a standard browser could read and interpret these tags,
presenting the user interface and allowing for key-mapping. Second, it must
be adopted by website designers; however, this would be an easy conversion
(or addition) from current unlabeled links that serve this function; it is
easy to understand and use. The advantage of using this scheme in HTML
rather than Javascript is that it could work regardless of the platform,
require few resources of the client computer, and be standardized among
different sites (rather than be a "house" script, with different properties,
on each website).

Sincerely-
Alan Schepers
Programmer/SysAdmin
Its Your Turn, Inc.

Received on Tuesday, 7 December 1999 01:33:28 UTC