Re: navigating Vs searching

to follow up on what Jon Gunderson said:

> I think the type of searching Al is talking about is very
> useful in the case you know what you are looking for.  But, we
> also want to help user who are just trying to explore new
> pages, so searching just headers by creating a list of just the
> headers is very useful.  The user can then sequentially move
> though just the headers.

>  The question I have is can this be considered a search or
> should we have a different label like direct navigation?

Auto-generating a table of contents by collecting the headers and
find/find-next stepping through the hits for a match pattern
could both be viewed as _sifting_ the document to create a
navigation infrastructure for the document.  But in the common
parlance, I think people will only recognize the second one as
"searching."
 
The left-margin Table of Contents display reduces _structure
navigation_ for the document to _link following_, a more 
primitive class of method.

I think that to communicate with people from outside the working
group we will need to distinguish at least three classes of
transactions:

Structure navigation (e.g. go-to-next-H2)
	(compare: go to start page in immediately enclosing directory)
Direct navigation (e.g. go-to-clickable-number-47)
	(compare: go to URL)
Content searching (e.g. go-to-first-occurrence-of(match-pattern))
	(compare: do you Yahoo?)

Al

> Jon
> 
> 
> 
> At 10:06 PM 11/10/98 -0500, Al Gilman wrote:
> >Searching only the header text or only the link text is
> >potentially of benefit, but only after basic searching of all the
> >text and navigation from hit to hit [probably starting with the
> >user positioned at the first hit] is in place.
> >
> >Documents are a blend of form and content.  Very often what the
> >author provides in terms of form by means of Hn elements
> >etc. fails to expose what makes the content interesting to the
> >reader.  In that case the reader resorts to content-wise access
> >methods such as matching substrings.
> >
> >It is my experience that web wanderers who are blind use string
> >search keys a lot to tell one another how to find something on
> >the web.  I hypothesize that this is because the infrastructure
> >of headers is a) not normally navigable, but more importantly b)
> >not designed with the grain size of their display interface
> >[roughly speaking the line, not the screenful] in mind.
> >
> >The content-addressed mode of getting around is generally
> >applicable to all text, not just structured or hyperlinked text.
> >As a result it is more universal and not dependent on the grain
> >size of the display channel, so blind users fall back on it a lot
> >because the headers that are adaptive for the sighted users don't
> >perform so well in sound.  Higher levels of structuring get
> >captured into the rhythms of one or another display medium.  The
> >more primitive modalities don't, so their utility survives
> >changes in the UI details.
> >
> >Al
> >
> >to follow up on what Jon Gunderson said:
> >
> >> I think we are looking for ways to navigate by content.  One way to think
> >> of searching is to create a list of all the headers allow some one to
> >> search that list of headers sequentially, by numeric position or by
> >> alphabetic letters.
> >> Jon
> >> 
> >> 
> >> At 10:19 AM 11/6/98 -0500, Denis Anson wrote:
> >> >Jon,
> >> >
> >> >I think we need to keep in mind the distinction between searching,
> browsing, 
> >> >and actually getting information from the web.
> >> >
> >> >In my doctoral course, Teaching and Learning on the Web, we are doing a
> >> lot of 
> >> >web based research for focus papers.  We look at resources on the web, 
> >> >including on-line journals and the like.  We frequently read this articles
> >> (at 
> >> >least skim them) on the web.  If our navigation were combined with a
> list of 
> >> >links, we would be able to get to the top of the article, the bottom of
> the 
> >> >article, and perhaps an occasional internal link.  But we might have pages
> >> of 
> >> >information that was inaccessible to keyboard navigation.
> >> >
> >> >No, I think we need a way to navigate the *content* of the page as well as
> >> the 
> >> >links off of the page.
> >> >
> >> >Denis
> >> >
> >> >On Wednesday, November 04, 1998 10:45 AM, Jon Gunderson 
> >> >[SMTP:jongund@staff.uiuc.edu] wrote:
> >> >> I think the current guidelines put direct navigation into searching,
> since
> >> >> when it is discussed it usuaully refers to bring up a list of elements
> >> >> (i.e. links) and have the user use a numeric or aphabetic key board
> >> >> commands to move through the list.  I am not sure there is a big
> >> >> distinction between this type of direct navigation and the general
> concept
> >> >> of searching.  It potentially may be an easier sell, if it is
> discussed as
> >> >> searching (since many user agents already have search functions) than as
> >> >> some new keyboard based technique.
> >> >>
> >> >> What do people think about combining direct navigation with search
> >> functions?
> >> >>
> >> >> Jon
> >> >>
> >> >>
> >> >> At 09:12 AM 11/4/98 -0500, Kitch Barnicle wrote:
> >> >> >
> >> >> >In the "navigation" sections  of the guidelines and techniques it
> seems as
> >> >> >though we primarily refer to sequential navigation. Has the concept of
> >> >> >direct navigation been folded into searching?  To me the notion of
> >> >> >searching implies an extra step. While I think providing multiple
> ways to
> >> >> >search for items on a page is important, I don't want to totally
> lose the
> >> >> >concept of directly moving to a link or active element. What do people
> >> >> >think? Am I missing something?
> >> >> >
> >> >> >
> >> >> >Also, I am not sure what 5.6.3 means, "Allow the user to search for
> a link
> >> >> >in the current document based on its position."  Is this guideline a
> >> >> >substitute for providing numbered links?
> >> >> >
> >> >> >
> >> >> >Thanks,
> >> >> >Kitch
> >> >> >
> >> >> Jon Gunderson, Ph.D., ATP
> >> >> Coordinator of Assistive Communication and Information Technology
> >> >> Division of Rehabilitation - Education Services
> >> >> University of Illinois at Urbana/Champaign
> >> >> 1207 S. Oak Street
> >> >> Champaign, IL 61820
> >> >>
> >> >> Voice: 217-244-5870
> >> >> Fax: 217-333-0248
> >> >> E-mail: jongund@uiuc.edu
> >> >> WWW:	http://www.staff.uiuc.edu/~jongund
> >> >> 	http://www.als.uiuc.edu/InfoTechAccess
> >> > 
> >> Jon Gunderson, Ph.D., ATP
> >> Coordinator of Assistive Communication and Information Technology
> >> Division of Rehabilitation - Education Services
> >> University of Illinois at Urbana/Champaign
> >> 1207 S. Oak Street
> >> Champaign, IL 61820
> >> 
> >> Voice: 217-244-5870
> >> Fax: 217-333-0248
> >> E-mail: jongund@uiuc.edu
> >> WWW:	http://www.staff.uiuc.edu/~jongund
> >> 	http://www.als.uiuc.edu/InfoTechAccess
> >> 
> > 
> Jon Gunderson, Ph.D., ATP
> Coordinator of Assistive Communication and Information Technology
> Division of Rehabilitation - Education Services
> University of Illinois at Urbana/Champaign
> 1207 S. Oak Street
> Champaign, IL 61820
> 
> Voice: 217-244-5870
> Fax: 217-333-0248
> E-mail: jongund@uiuc.edu
> WWW:	http://www.staff.uiuc.edu/~jongund
> 	http://www.als.uiuc.edu/InfoTechAccess
>

Received on Thursday, 12 November 1998 15:31:55 UTC