Re: Sequential Navigation within a View

I still want a "go to specific link" capagility in there.  if that link
list is hundreds long and I want to go to 150, I don't want to have to
perform repetitions of a next or previous or up arrow or down arrow. the
method for accomplishing this would be to provide a dialog box when the
"go to specified link" item is activated and you could type in a number if
it was availabe or a string.
otherwise, this is quite possibly an approach which solves much.

 On
Fri, 14 Aug 1998, Napoleon Maou wrote:

NMThank you for your comments.
NM
NMIn their current form, the guidelines refer to two mechanisms, which are
NMused together to provide sequential navigation functionality within a view.
NMThe first is described in section 6.1, "Sequential Navigation Within A View",
NMand the second in section 7.2, "Menu Commands", Item 1.
NM
NMOur proposal combines the functionality of these two mechanisms, into one
NMgeneric sequential navigation mechanism. We believe that the strongest points
NMof the proposed approach lie with the simplicity and uniformity with which a
NMuser will be able to navigate a document. Please note that this is independent
NM
NMof the actual types of elements that the user will be allowed to navigate by.
NMThis way the user will have to perform fewer interaction steps to navigate
NMamong elements of the same type, having, furthermore, only one set of
NMnavigation
NMcommands to memorize (compare this, for example, to having to remember
NMdifferent
NMkeyboard commands to move to the next heading, previous form element, etc.)
NM
NMLet us now move on to the issue of which elements should the user be allowed
NMto navigate by. The term "any elements" used in the initial proposal, was not
NMmeant to imply that navigation by *every* HTML elements should be possible.
NMRather, it was meant to refer to those elements in the rendered page that the
NMuser can distinguish from the rest, and identify as having particular
NMcharacteristics.
NMIn our view, the guidelines already assume that the user has a rather
NMgood understanding of what a formatted text document is, as well as of the
NMfunctional and non-functional attributes of elements that may be encountered
NMwithin an HTML document.
NM
NMThe above is evident from the fact that the mechanism in section 6.1, allows
NMthe user to sequentially visit links, form elements, images and image maps. A
NMdirect implication of this is that the user knows what links, form elements,
NMframes, images and image maps are. In the opposite case, a truly novice and
NMinexperienced user will think that the browser arbitrarily scrolls to
NMdifferent
NMparts of the document. Furthermore, by proposing the use of menus for header
NMnavigation, the guidelines assume that the user knows what a header is. This
NMmeans that it is already assumed that the user comprehends at least part of
NMthe
NMdocument's formatting.
NM
NMBased on the above, the elements we believe the user should be at least
NMallowed
NMto navigate by are the following: links (including image map areas), elements
NMwith
NM"longdesc", forms and form elements, tables,  lists and list items, elements
NMwith
NMDHTML events, paragraphs, sentences, headers. All these are elements that the
NMuser
NMcan distinguish from the rest of the elements in a page, and identify them as
NMhaving
NMa particular property / functionality.
NM
NMA second point you raised in your email concerns the employment of menus to
NMprovide
NMan overview of the document. Although it is a very good idea to allow the user
NMto
NMget different overviews of the document, menus might not be the best approach
NMto
NMpresenting them to the user. Menus excel when used to provide the user with an
NM
NMoverview of the functionality of an application and are rarely used when they
NMare
NMvery long, not to mention when they entirely different (with the exception of
NMthe
NMfirst few items) for every document the user visits. Imagine for example a
NMmenu
NMcontaining the headers of a long research publication with descriptive section
NM
NMheadings. The menu would be hardly usable. Or, what about a menu containing
NMthe
NMlinks in a "Links" page that is becoming a norm in almost all types of sites.
NMPresenting a limited list of the elements in the menu, as specified in Section
NM
NM7.2, is a partial solution to the above problem, but introduces, in turn, a
NMnew
NMproblem, that of not allowing true "random" access to elements. If, for
NMexample,
NM10 headers are included in the list, and there are 15 in the document, then
NMthe
NMuser will not be able to directly access the last 5 ones, which compromises
NMthe
NMvery usefulness of the current approach.
NM
NMWe believe that a far more usable and elegant solution for providing document
NMoverviews and enabling "random" access to document elements, would be the use
NMof separate views, along with view synchronization, as specified in section
NM4.7 "Alternative Views of the Document", Item 1.
NM
NMIn summary, we propose that the navigation mechanism for sequential access to
NMdifferent types of document elements should be harmonized and, even better,
NMunified across elements types. We further propose that overviews and "random"
NMaccess to document elements are achieved through separate, synchronized views
NMas already proposed by the guidelines, rather than through menus.
NM
NMTo better clarify the proposed approach I am including below the communication
NM
NMwith Bryan Campbell, in which specific examples of operation are included.
NMComments and
NMsuggestions are always more than welcome.
NM
NMBest regards,
NM
NMNapoleon
NM
NM
NM
NM+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
NM
NM
NMHello Bryan,
NMAgain I would like to apologize for taking such a long time to reply to your
NMmail.
NM
NMThanks for commenting on our proposal.
NM
NMThe number of keyboard commands the user needs to go through in order
NMto use the navigation mechanism we propose depends on the specific
NMchoices developers will make in implementing the mechanism. Instead
NMof referring to key presses, therefore, please allow me to briefly
NMdescribe the idea in terms of "interaction steps". Naturally, the
NMideal implementation would manage to allocate single (combined) key
NMpresses to each interaction steps.
NM
NMThe enhancement to the navigation model we are proposing involves
NMtwo main tasks: (a) selection of the type of element (or elements, I
NMwill explain this further below) by which the user will navigate the
NMdocument, and (b) navigation within the document itself, including,
NMbut not necessarily limited to, the ability to move to the next
NMprevious elements of the selected type in the document, as well as
NMthe ability to move to the very first and very last such elements in
NMthe document.
NM
NMIn terms of functionality one can distinguish between two variations
NMfor task one. If navigation is limited to a single type of element at
NMany time (of course this does not include "normal" document navigation
NMwhereby all elements are visited sequentially), then this is a task of
NMsimply selecting an option among mutually exclusive alternatives. The
NMnormative way of doing that would be through a menu (e.g. a menu
NMentitled "Navigate" and items such as "By Header", "By Paragraph",
NM"By Link", etc.) Very common, or frequently used options should of
NMcourse have keyboard shortcuts, making them accessible in a single
NMinteraction step, from any point in the interface.
NM
NMAn alternative to the above would be for the user to be allowed to
NMselect multiple types of elements to be visited during navigation.
NM
NMOne way to implement this would be through the use of a dialog, which
NMwould present the user with a list of navigational elements and allow
NMhim/her to selecting multiple types of elements to navigate by. In
NMthis case, the implementation of the navigational mechanism requires
NMthe following interaction "steps"
NM1) Open the dialog
NM2) "Next" and "Previous" commands, to scroll through the list of
NM   items
NM3) "Select" / "Unselect" command to add an element type to the
NM   current set of navigable elements
NM3) An "OK" and a "Cancel" command to close the dialog
NM
NMThe "OK" and "Cancel" commands above would be the standard "OK" and
NM"Cancel" keyboard commands used for all dialogs. The "Next" and
NM"Previous" commands could be the same keyboard commands used to
NMnavigate between elements in the view.
NM
NMAlthough this approach would significantly enhance the flexibility of
NMthe navigation model, it would also be very demanding on the user,
NMimposing considerable load on short and long term memory, both in terms
NMof interaction, but also in terms of anticipated system behaviour (I could
NMelaborate on this if necessary). Furthermore, we don't believe that the
NMadded flexibility outweighs the resulting increased complexity. Therefore,
NMwe would prefer that only the former approach be included in the
NMguidelines.
NM
NMIn terms of interaction, the functionality of the second task (navigation
NMin the document itself) can be implemented using four "commands": Go-To-Next-
NMElement, Go-To-Previous-Element, Go-To-First-Element, and Go-To-Last-Element.
NMOf the four, only the first two (next and previous element) are of vital
NMimportance. The latter two (first and last element) would be invaluable
NMthough in long documents, especially ones of a known structure.
NM
NMAttempting to address your question of how many keystrokes it would take to
NMmake effective use of the proposed navigation model, I will go through a
NMvery simple scenario (for the needs of the scenario I assumed that the
NMfollowing correspondence between commands and keys exists: next element -
NM"Arrow-Down", previous element - "Arrow-Up", last element - "End", first
NMelement - "Home"):
NM
NMAssume you know that you want to select a link in a long document, but you
NMare not sure if it was the third from the end, or the second from the end
NM(note that the fact these is no other link between them does not imply that
NMthese two are necessarily close to each other). Using the proposed approach
NMyou would:
NM1) press "Alt-L" to switch to link navigation mode (assuming that because
NM   it is a very important mode it has its own shortcut)
NM2) press "End" to go to the last link in the document
NM3) press "Arrow-Up" to go to the second link from the end, review the link
NM   and possibly
NM4) press "Arrow-Up" again to go to the third link from the end
NM
NMI would like to iterate that the rationale for proposing this modification
NMto the guidelines, is to ensure that the very good idea of supporting
NMalternative navigation models (modes) in the document, is supported in an
NMintuitive way, imposing as little interaction burden on the user as possible.
NMIt is interesting to note that in most cases (I am tempted to say all but
NMperhaps I am missing some complex cases, so I will refrain from that) the
NMproposed approach is faster in terms of interaction steps and requires
NMfewer keyboard shortcuts than the one currently included in the guidelines.
NM
NMWe would be very interested to find out what you and other people on the
NMlist think, especially after the above, more detailed description.
NM
NMBest regards,
NM
NMNapoleon
NM
NM
NMNapoleon Maou
NMSoftware Engineer
NMAT&HCI Laboratory
NMICS-FORTH
NMvoice : +3081391742
NMemail : maou@ics.forth.gr
NMWWW   : www.ics.forth.gr
NM
NM
NM
NM
NMJon Gunderson wrote:
NM
NM> Your approach I think may work for an experienced user who understands
NM> tags.  But what about the niave user who won't know want to look for or
NM> situations where a user just wants to get an overview of the document with
NM> out having to read every element.
NM> Jon
NM>
NM> At 09:17 PM 7/31/98 +0300, maou wrote:
NM> >Hello,
NM> >My name is Napoleon Maou and I am a staff member at the Assistive
NM> >Technology and Human computer Interaction (AT&HCI) laboratory , at the
NM> >Foundation of Research and Technology Hellas (FORTH).
NM> >
NM> >I am interested in technologies that will make the Web, or any other
NM> >information system, accessible to people with disabilities.
NM> >At FORTH I have participated in the development of the AVANTI unified
NM> >browser, a browser that in addition to motor abled users, is accessible
NM> >by blind and motor impaired users.
NM> >
NM> >I would like to comment on the subject of sequential navigation within a
NM> >View.
NM> >
NM> >I believe that there should be only one generalized mechanism to
NM> >navigate elements within a view. Section 6.1 talks about a mechanism for
NM> >sequential navigation of links, form elements and elements with
NM> >longdesc( using keyboard commands ) , and section 7.2 talks about
NM> >another mechanism that can be used for sequential navigation of Headers
NM> >or other elements ( using menus and menu shortcuts ).
NM> >
NM> >The problems I see with the existence of two mechanisms are the
NM> >following
NM> >1)  There exist more than one keyboard commands or menu keyboard
NM> >shortcuts, which have essentially the same meaning. "Move to next item".
NM> >For example if we have menu items to navigate Headers and Paragraphs
NM> >then there will be a "Next Header", a "Next Paragraph" and a "Next
NM> >link/longdesc/form element" command.
NM> >2)  If the user wants to navigate Headers and paragraphs then the
NM> >current mechanisms does not allow him to do that. He can navigate
NM> >Headers or Paragraphs but not both at the same time.
NM> >3)  For people with motor disabilities using menus to navigate will be
NM> >very time consuming.
NM> >4)  For blind people there is the problem of having to memorize more
NM> >keyboard commands than are needed.
NM> >
NM> >Proposed Mechanism
NM> >---------------------------
NM> >I believe that the UA should provide to the user a simple generalized
NM> >mechanism to navigate any elements in the view. This mechanism should:
NM> >a)  Allow the user to select the elements he wants to navigate.
NM> >b)  Provide  commands to move among the elements of the view.
NM> >
NM> >A mechanism like that I believe will be easy to use and is general
NM> >enough to allow the user to navigate any element combinations.
NM> >
NM> >Napoleon Maou
NM> >
NM> >--
NM> >Napoleon Maou
NM> >Software Engineer
NM> >AT&HCI Laboratory
NM> >ICS-FORTH
NM> >voice : +3081391742
NM> >email : maou@ics.forth.gr
NM> >WWW   : www.ics.forth.gr
NM> >
NM> Jon Gunderson, Ph.D., ATP
NM> Coordinator of Assistive Communication and Information Technology
NM> Division of Rehabilitation - Education Services
NM> University of Illinois at Urbana/Champaign
NM> 1207 S. Oak Street
NM> Champaign, IL 61820
NM>
NM> Voice: 217-244-5870
NM> Fax: 217-333-0248
NM> E-mail: jongund@uiuc.edu
NM> WWW:    http://www.staff.uiuc.edu/~jongund
NM>         http://www.als.uiuc.edu/InfoTechAccess
NM
NM
NM
NM--
NMNapoleon Maou
NMSoftware Engineer
NMAT&HCI Laboratory
NMICS-FORTH
NMvoice : +3081391742
NMemail : maou@ics.forth.gr
NMWWW   : www.ics.forth.gr
NM
NM

-- 
Hands-On-Technolog(eye)s
touching the internet
voice: 1-(301) 949-7599
poehlman@clark.net
ftp://ftp.clark.net/pub/poehlman
http://www.clark.net/pub/poehlman
Dynamic solutions Inc.
Best of service for your Small Business network Needs
Http://www.dnsolutions.com

Received on Friday, 14 August 1998 10:22:49 UTC