navigation order RE: svg and events

The drawing order in SVG is important. Last thing drawn is on top - whether
it comes from a use element (i.e. provides indirection to the informaton
about what is drawn) or is there directly. And there are some CSS things that
are important too - masking, filtering, etc especially - if you are going to
try and create some level of automated descriptions.

Although heirarchical grouping doesn't work for everything, it works for a
lot. It should be possible to define very simple RDF that would link the rest
up. (I have a current hobbyhorse plan to spend time with Dan Brickley writing
about SVG and metadata - there is a lot of easy winnings in that area.)

Patrick Roth has been developing a tool for exploring SVG-type graphics (I
hope he will be able to demonstrate it for SVG itself soon) with audio/haptic
feedback, including speaking descriptive text and providing sound, and
force-feedback from the right kinds of mouse. The project Dave mentioned also
provides sound feedback from the mouse. But neither of these projects seem to
have addressed the question "what is here?" for the user who doesn't actually
care at all about the layout, and doesn't want to explore the shapes
themselves.

So finding a more useful structure than just straight tree navigation or
"feel your way around" is probably worthwhile investigation. An interesting
starting point might be to work backwards within siblings, given the drawing
order thing.

just some thoughts...

chaals

On Wed, 13 Mar 2002 DPawson@rnib.org.uk wrote:

  Hi Al.
  > >My principles to date are:
  > >
  > >1. document order to match 'described' order,
  > >i.e. logical progression from overview down to detail.
  >
  > In general this cannot be done.  You have to use the
  > define/use cycle in SVG to first provide text in some
  > plausible narrative order and then reference the text in the
  > encoded drawing structure which is not a linear order but a
  > hierarchical scene graph.  It is not practical to try to
  > force the 'g' drawing group hierarchy into a narrative order.
  >  The prior declaration of the text in narrative order can be
  > in an embedded foreign object in XHTML Basic, for example.

  OK, taking my defs as being 'data' or hash defines, substitute
  use instead of actuals.

  I think it is practical. I hope you can't prove me wrong.
  The drawing order is only relevant in terms of what overlays
  what, and (I think) that can be sorted.



  >
  > >2. Each document entity to be wrapped in a g element,
  > >   with min of desc and otionally both title and desc children.
  >
  > That is to say each distinct scene object of enough
  > conceptual significance to be mentioned in the description.
  >
  > Catch:  The 'g' drawing groups are part of the strict XML
  > hierarchy.  The conceptual objects one wishes to describe
  > form a general Venn diagram -- not a strict hierarchy.  There
  > are intersecting groups in the display that have both common
  > and distinguished sub-elements in them.  So some of the
  > notional elements may have to be documented as collections of
  > drawing groups, presumably via RDF in the 'meta' section.

  Agreed, re-use will limit that. Simplistically any 'object'
  will be within a group, though its children maybe uses of
  def'd content.


  > The first navigation assistance to think about is
  > hierarchical, not linear.
  >
  > It is presumed that you can create a contents tree for the
  > display without too much mental sweat.  A possible
  > orientation technique is a one-level contents summary list in
  > the 'desc' element or in SVG attached to the 'g' structure
  > containing articulable substructure.  In any case, the way
  > you present the navigation hierarchy is by some emulation or
  > approximation of the DAISY book Table of Navigation and
  > associated navigation techniques.

  Since I never 'describe' a figure in this way, I'd rather approach
  it by providing a 'summary' / precis initially (This diagram shows... )
  then go into the diagram. The missing elements will be the reader
  commentary which says something like 'which is adjacent to the xxx'.

  I want to avoid a 'special' nav table if possible, since it fits
  unnaturally into a visual diagram.

Received on Wednesday, 13 March 2002 03:47:33 UTC