Re: navigating Vs searching

to follow up on what Markku T. Hakkinen said:
> From: "Markku T. Hakkinen" <hakkinen@dev.prodworks.com>
> Subject: RE: navigating Vs searching

> Navigation Styles: Does Separating Content from Presentation include
> Navigation?

Yin/Yang: "separating" content from presentation involves _adding
more different ways_ to _connect_ content and presentation.

Likewise, divorcing action from device does not mean leaving the
action without a connection to a device; it means relaxing the
hard-coded association and giving an opening for later binding
of devices to action-opportunities.

> In pwWebspeak 1, we originally provided just direct navigation keys (e.g., H
> to move to headers, P to paragraphs, etc.). In later releases we updated the
> browser command set to allow definition of parameter driven searches to
> provide more navigation options:
> 
> find-next-element (target-tagname)
> find-prev-element (target-tagname)
> 
> find-next-text (target-text-size)
> find-prev-text (target-text-size)

What is the definition and role of 'size' in this situation acceptor pattern?

I would call this a "find next/previous instance of category characterized
	by <pattern of characteristics>."  It can be decomposed as two
	steps: a) build a bag of all matches in the document to said
	pattern, b) step to the
	text position in the un-filtered cycle of text positions which
	is closest after/before the current text position and is the starting
	text position of one of the instances in the bag defined in a)
	Otherwise there needs to be a text-order scan of the document
	representation such there can be a step-and-test search for
	the next/previous match without finding all matches.

> Using this facility, a user can customise the keyboard commands, creating
> their own navigation key set for the browser.
> 
> We have expanded this to include the class value, and the basic approach
> supports XML nicely.
> 
> This flexibility can lead to either a very large keyboard command set,
> accomodating many different pages, or invites a more generalised solution
> that can keep the navigation model simple, but adaptible to meet the needs
> of different page styles or structures.
> 
> In navigating documents (which is where we spend a lot of our time in the
> digital book world, but not to the exclusion of those pages which are
> basically like host OS dialogs), we have been considering the idea of a
> "navigation sheet". Rather than defining a single navigation key set (which
> is what we do now by default), the UA can dynamically reassign the
> navigation search targets based on the loaded documents' structure
> (structure being loosely used with HTML).
> 
> As a UA, we can of course attempt to do this from the H1 .. H6, if present,
> or directly from the XML structure, but we have no notion of the author's
> intent. Realistically, we see XML as the far richer approach to provide
> structure, but without some additional author supplied information, we can't
> determine what are significant structural elements or even how they should
> be identified.

element TITLEs are a way of providing human-comprehensible
author-provided data answering to some degree the questions "What
is this?" and/or "What is this for?"

I believe the dialog which elicits TITLEs from the author (we are
talking about ideal XML stuff here, not HTML with legacy
constraints) needs to echo the element tree structure back to the
author so that the author will understand that this element's
TITLE is prone to be presented as an immediate sub-part of the
element of TITLE "blah blah blah."  This will get the titles to
relate to one another better.

> 
> For example, in the NY Times web site, "XML" mark up provides semantic
> wrappers around text (e.g., NYT_SUMMARY, NYT_HEADLINE) and I've defined keys
> to allow a webspeak user to easily navigate around that page, but we could
> not have done this automatically with the mix of HTML and XML markup
> present. At least we can allow the user to adapt his or her audio style
> sheet to vocalise NYT_HEADLINE as "Headline", once they learn that this is a
> significant tag, and add keys to navigate to it.
> 
> At a minimum, we (PW) are looking at providing something on the order
> user-definable "navigation sheets" that can be associated by the UA with a
> given page, providing a way to adapt the keyboard on the fly.  I think a
> more generalised long term solution is the idea of "NavCSS" extensions to
> CSS which might include a "level" and "role" style.  Mixing ACSS and with
> NavCSS (which is what our webspeak styles do), we might end up with
> something like:
> 
> NYT_HEADLINE {nav-level: 1; role:"News Headline"; cue-before:
> url("tonesweep.wav")}
> NYT_SUMMARY {nav-level: 2; role:"Summary"}
> 
> In well formed XML documents, nesting level can be used to determine levels,
> but this is practically impossible in HTML, and in both cases author intent
> with respect to the navigation significance of any element is unknown.
> Nav-level provides an indication of the element's significance for
> navigation. We have been using a version of Nav-level in the webspeak style
> sheet since version 1; it is used to indicate whether a given tag is a
> navigable element, and also includes information on how tags "fold"
> together.
> 
> Role provides a way of "naming" the elements. A user agent (or assistive
> technology) can enumerate the elements on the page and, for example,
> announce "There are 6 headlines on this page. Press F8 to move to the next
> headline and F7 to move to the previous headline."
> 
> To address the issue of changing keys from page to page, and completely
> confusing the user, we (speaking for pwWebSpeak) would implement a set of
> standard "prev/next item in a level" functions. Though the name of the top
> level navigation element may change, (Heading in one case, Headline in
> another), the same keystrokes would be used to navigate across top level
> elements across pages.
> 
> I also wonder whether a NavCSS approach provides a mechanism to clear up
> what some of us see as problems with ACCESSKEY. When we look at things like
> voice browsing/tv-web/small device UA's, I think moving the ACCESSKEY
> concept into a stylesheet makes sense.
> 
> The idea of cascading the AccessKey definition can take into account the
> specific requirements of the user agent or host operating environment. The
> idea of auto-numbering "accesskeys" for telephone browsing is one obvious
> use. Pre-fixing the Accesskey for visual or auditory presentation with ALT
> for Windows, OPTION for Mac, or something specific for a given accessibility
> aid is also possible.
> 
> Comments?

AccessKey is a single-community accelerator, not a
universal-benfit technique.  There needs to be articulation of
what the action-opportunities do in human-comprehensible language
in addition to the option to use single-key commands for those
for whom the conservation of command tokens is the paramount
concern.

Letters are not graceful command tokens when operating without a
keyboard.  Text is the main broadly-redirectable content
representation and the keyboard is the main broadly-redirectable
command acceptor metaphor.  This doesn't mean that verbatim sound
doesn't sound better than synthetic speech, and that there aren't
better command vocabularies for speech than keyboard emulation.

The basic capability required includes:

	a) the basic unit of binding is an assertion or action rule.

		a.1) assertions are predicates with the injunction
		"ensure that P is always true."

		a.2) action rules take the form
		in the situation that (instance acceptor pattern, 
			projectively expressed)
		take action in the form (bindings, constructively expressed)

Example rule (for safe form operation under reduced visibility):
	If the action is to submit a form and the current focus is
	not the submit element itself, require confirmation from
	the user.

The situation-acceptor clauses that define the applicability of
the associated pattern of action are generalizations of CSS
selector clauses and draw on the functionality of query
languages.  In general they apply filter criteria to both the
markup and the content.  Schemas associated with application
domains may be part of the usage profile such that tokens
appearing in the content outside the markup are recognized as
denoting restrictively defined notions such as ISO units in
Engineering and currencies in commerce.  It should not be assumed
that XML marks will be used to replace all text that has
semantics comprehended by the schema for the current domain of
discourse.

Al

> 
> Mark
> 
> > 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?
>

Received on Monday, 16 November 1998 12:10:13 UTC