RE: 15.1.2 Navigation

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

[1] http://schepers.cc/svg/focusNavigation2.svg
[2] http://schepers.cc/walkingtalkingsvg.html#DirectionalNavigation
[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