From: Doug Schepers <doug@schepers.cc>
Date: Sat, 13 Nov 2004 03:45:41 -0500
Message-Id: <20041113084540.6E60386262@plunder.dreamhost.com>
```
Hi, Peter-

Thanks for the follow-up.

I wouldn't say I have algorithms so much as strategies. I have made two
implementations of directional navigation in SVG, using 2 different methods.
I laid it out in my experimental page on navigation in SVG [1].

There are two basic ways I approached the problem. The key issue is whether
to judge directionality or proximity as the more important attribute. The
first method I tried favored closeness to the axis of the direction chosen;
I found that this wasn't very satisfying, since it would often choose a very
distant element as the next focus element.

Next I tried distance from the current focus centerpoint to the candidate
centerpoints, a candidate being any element whose centerpoint is in the
chosen direction; you can see this in action on my site [1], along with a
detailed explanation[2]. Basically, just apply the simple Pythagorean
distance formula. Since I only used circles in this example, I had the
luxury of measuring the distance from centerpoint to centerpoint; also, the
shapes are regular, so proximity was easy to judge (no odd edges that might
give other expectations). But I think it would work equally well by finding
the centroid of any given shape [3], and using that as the point from which
to measure distance, rather than edge-to-edge. I found that it worked pretty
intuitively.

Given this method, you will still get conflicting options, when there are 2
equidistant options, or when objects overlap. In this case, the larger
object can be chosen, since it will probably have a closer edge (being more
spread out). If they are the same size, you have to make an arbitrary
decision; at that point, you could just go by document order, or to reveal a
Western bias, in preferential order of left over right, top over bottom. The
same arbitrary decision could be made in the case of table cells, a case
mentioned earlier.

While there is a certain lack of precision, there is an equal lack of
commitment; if a person is slightly surprised by an unorthodox navigation
decision, they can quickly figure out the system behind it and navigate to
the correct option, and the can't get "stuck"; with document order, they
have no cues at all to try to recover from a mistaken direction navigation.

There are other, more complicated approaches, like using a Voronoi diagram
or Delaunay triangulation, but in this case, I think that the Good-Enough
principle holds. There are drawbacks to every approach I could think of, and
the one I went with finally was the simplest to do, and equally intuitive to
the end user. The point is, any directional solution is better than a purely
"hidden" document order selection.

Regards-
Doug

[3] An added advantage of having the UA calculate centroids is that you
could expose the method that does that (myShape.getCentroid() ),to the
benefit of GIS people, who like centroids; while it's fairly trivial to do
in C/C++/Java (lots of existing algorithms/implementations), it's a bit of a
pain to do in JS.

Peter Sorotokin wrote:
|
|
| At 06:00 AM 11/11/2004 -0500, Doug Schepers wrote:
|
| >Hi-
| >
| >Directional navigation seems a little confusing. Am I
| understanding it
| >correctly to say that nav-up, nav-down, nav-left, and
| nav-right depend
| >on the document order? Is there no other way to specify the
| order? If I
| >misunderstand this, forgive me.
| >
| >I appreciate that this is a property inherited from CSS, but CSS had
| >HTML as its use case, which is a document format in which
| elements and
| >text defined at the beginning of the document most typically will be
| >visually depicted at the top of the page, and in which the
| document and
| >location order of those elements rarely changes. This is far
| from the case with SVG.
| >
| >Consider:
| ><svg>
| >   <circle id="c1" focusable="true" cx="300" cy="500" ... />
| >   <rect id="r1" focusable="true" x="100" y="100" ... />
| >   <circle id="c2" focusable="true" cx="50" cy="50" ... /> </svg>
| >
| >If the current focus were on Rectangle 'r1', and the user
| pressed the
| >up arrow key, triggering a nav-up event, the focus would shift to
| >Circle 'c1', which is earlier in the document order but
| "down" in the
| >visual field. This is compounded by the fact that often elements are
| >repositioned dynamically, making the authoring of a document
| that has
| >consistent behavior regards directional navigation via
| document order vs. visual location impossible.
| >
| >This would be completely unintuitive to the user. I
| *strongly* suggest
| >that the SVG WG reconsider the use cases for this feature and its
| >behavior. My suggestion is that nav-[direction] operate on
| the visual
| >location, not the document order. I think that this should be the
| >default, if not only, attribute value.
|
| Do you have specific algorithm in mind? How would you
| determine what the visual order is in SVG? It seems that it
| would be very fragile.
|
| Peter
|
|
| >I have use cases and demos if you are interested.
| >
| >
| >Regards-
| >-Doug
|
|
```
Received on Saturday, 13 November 2004 08:45:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:01 UTC