Re: link navigation

On Tue, 03 Nov 2015 00:07:02 +0900, Fred Esch <fesch@us.ibm.com> wrote:

> Chaals,
>
> The sparse chord example does indeed show issues.  The first time I ran  
> it using Firefox my default browser, I saw wedges of the chords
> disappearing and it reminded me of search lights in the sky.

Yeah, that was due to a bug :)

> I did not follow the navigation pattern as my focus was drawn to
> wondering why chords were changing.  I tried it on Chrome and saw
> different highlighting - a blue bounding rectangle of the left bar +
> chord (or a horizontal blue line if the rectangle was clipped) and
> less noticeably a gray blur on the chord boundary.  IE was similar
> to Chrome, but in IE the gray blur was more noticeable than the box.

Yes. I agree that the highlighting needs to be pretty clear. I think it is  
useful to have standard highlighting from a browser, with *additional*  
highlights. For example, the browser focus highlights tend to be square,  
covering the bounding box, whereas things in SVG might have different  
shapes - and indeed not reach anywhere near their bounding box in practice.

> I ran it several times and  I realized that navigation was walking down  
> the left side. It took me several more minutes to realize that the
> pattern was left bar, chord, left bar, chord - I think.

Well, that's something. (I don't think you can get that in Firefox since  
it doesn't respect tabindex in SVG).

> Hitting the ENTER key turned chords gray on Chrome. I don't have a
> clue as to what that is supposed to mean.

Nor do I. If you hit enter on a link, I would expect it to move focus to,  
and highlight somehow, the target of the link. But that doesn't seem to  
happen much yet.

> If navigation was simply walking down the left bars, I would suggest  
> strong highlighting on the active left bar so the user can see
> the navigation pattern.

Even if it isn't that I think you're right that there needs to be strong  
highlighting.

>  I don't think this is a workable pattern as I
> will have to look at the DOM to verify the navigation order.
>
> Connectors may help, but users won't know how to use connectors in
> navigation.

They are links, associated to both of their endpoints - in practice the  
strong native semantic version of aria-flowto. I agree that there is a  
question about whether this makes sense to users, which might explain why  
the implementation of flowto is weak, but the alternative of making  
reciprocal links is pretty painful. Although I believe I can use SVG  
animation to significantly improve the visual hints - except of course in  
IE.

> I will go out on a limb and say, it is pretty easy for sighted
> users to pick up using the arrow keys for navigating.

That's good news if true.

> However, sighted users don't have a natural or learned association for
> using connectors.

I suspect they do if we start with the right kinds of diagrams. Undirected  
graphs, such as circuit diagrams, roadmaps, chord graphs, social graphs  
based on confirmed links…

> Training a user on a chutes and ladders (snakes and ladders) game would
> help for nodes with single connections, but not for nodes with multiple
> connections.

Right. And I don't think snakes and ladders is any better than a lot of  
other examples.

> My experience is, when you get multiple connections, the user
> will have additional keystrokes to learn and use. Since most users won't
> learn and use additional keys for infrequent use cases, connector based
> navigation will be mostly ignored.

I'm not sure that additional keystrokes are the right answer. Instead, I  
would expect something more like a text-based adventure game from the  
1980s - "you can (1) go to the pub (2) go fly a kite or (3) go back where  
you came from..."

If the browser handles the fact that there are options, as it already  
needs to do for flowto, then the user doesn't need a lot of magic  
keystrokes.

Another example is a menu for a voicemail system. The user might know the  
keystrokes in advance and be able to skip through the whole thing in half  
a second, or they might have to listen to all the options. Likewise a lot  
of mobile phones from 2 decades ago had complex option setting which  
expected power users to learn the options and simple users to just  
navigate successive menus. (Modern phones dropped the mechanisms for power  
users).

Anyway, I'd love to get more issues filed on the worked examples. Thanks  
for taking the time to play and write.

> I made something like this, mostly just for thinking my way through:
> http://svg-access-w3cg.github.io/use-case-examples/sparse-chord.svg
>
> It shows there are some issues for making visual representation and
> navigation match, especially when what I really want is a connector.

cheers

-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Monday, 2 November 2015 21:01:48 UTC