DRAFT: Data navigator research

[c-lamoureux]

This branch contains proof of concept behavior, code is poorly written but conceptually allows us to meet the feature requirements. Major cleanup of code required before merge.

Requirements:
TAB to navigate to the chart

Navigator enter button appears on the center of the chart with user friendly text

In all cases:

• ENTER drills in a layer of depth.
• ESC goes up a layer.
• Arrow Right and Down share the same behavior.
• Arrow Left and Up share the same behavior.

ENTER enters the chart which has this navigation tree structure:
Axis (one for every axis):

• Initial focus is on the entire axis and it's title/labels.
• ENTER focuses a visible axis label.
• Arrow keys navigate between labels on the axis.
• ESC returns you to the whole axis focus
• Axis label focus triggers highlight of connected bars when relevant.

Legend:

• Initial focus is on the entire legend including the title/legend items.
• ENTER focuses the first legend item symbod+label(s)
• Arrow keys navigate between legend items
• ESC returns to the whole legend focus

Bar Chart Content:

• Initial focus is on the chart content (within the axes)
• ENTER focuses the first Bar
• Arrow keys navigate between the bars in sequence
• Navigation ends at the last bar (not circular)
• In a stacked bar, first focus is on the stack, ENTER again to focus the individual bars within a stack.
• In a stacked bar, arrow navigation in the inner bar stack can still navigate between stacks.
• Focus and interaction behavior occurs when focusing a bar. This includes tooltips, and if navigating to a bar where the axis label is hidden, we should display the axis label (once that feature is implemented for non-keyboard nav).
• Additional planning to be done for grouped and trellis bars.
• Additional planning to be done for popover behavior.

[frankelavsky]

Howdy!

I've finally gotten around to taking a look at this in-depth. Many thoughts. Tagging #890 too, to link the discussion over here.

---

1. The good stuff

I love all of this:

• Region composition is fantastic.
  builds each region's structure independently, namespaces the ids, and stitches the roots together. Nice.
• The scenegraph geometry work is perf
• Filtering out overlap-hidden axis ticks is great.
  getVisibleAxisLabelColumns drops items with opacity <= 0 so keyboard focus never lands on a tick
  Vega decided not to draw. I have not seen another library do this.
• Bridging keyboard focus to the hover signals is the ideal pattern (${legendName}_hoveredSeries +
  ${barName}_dimensionHoverArea_hoveredItem)

---

2. Questions/thoughts/open problems

Why a lack of complex structure?

The main thing to me is the mark-level navigation, which is primarily just forward/backward through a chart. In our prior work on Bokeh, we did forward/backward (one direction) for a chart like a bar, but patterns progressively get more complex depending on chart type/usage:

• A line chart as a classic "tree" hierarchy (lines each contain a list of leaf nodes, this is a similar pattern as what has been implemented in bar, except that at the end of each grouping, navigation loops back to the start of the group rather than all children)
• A line chart where users can navigate by line or by x-axis interval, and also jump between lines (to each point on an interval) when at the leaf level
• A stacked bar where you can go up/down/left/right (similar pattern conceptually/structurally as the cross-line above)
• And even a scatterplot where you can navigate in grouped spatial subregions along the x or y axis as well as categorical groupings (tied to a legend/color encoding)

The additional structure adds quite a lot to the user's experience (and is the main justification for data navigator in the first place). So, I mostly just wonder: why not have at least 2 degrees of navigation? (up/down and left/right)?

In the previous prototype that I made, we had this multi-directional nav enabled. Genuinely curious if this was taken out for a reason (scoping, design choice, too complex to figure out how to wire, etc).

And this leads me a bit into my second main question:

Why keep ARIA on VegaChart?

One of the commits (1781e1a) adds ARIA back to VegaChart, which I think is interesting. ARIA basically creates a list out of elements, which is similar to what is happening with the navigation pattern I see (based on my comment above). If ARIA is on, and the goal is to have serial/list-style navigation, then is data navigator needed?

But that being said: ARIA can be a great fallback for mobile experiences, so it is worth keeping as a fallback. Data navigator could be considered a progressive enhancement, then, over ARIA as a baseline.

Region navigation is childless?

I love the region navigation (to axes/legend elements). Fantastic work. But there isn't a navigation down into the children from this point. And for this reason, x axis seems redundant with the main "navigate into children" region (the main marks). Like, in storybook the "Bar Navigation" example (the stacked bar) uses legend nav for operating system (amazing) as well as axis navigation for the browser (love to see it)... but then the mark area also appears to use axis navigation and enables drilling into children.

I think the ideal pattern would remove the third navigation type, since it is redundnant with the x axis, and then keep legend and axis navigation, each being able to drill into children from those levels (by pressing enter).

The bokeh example (previously linked) does this for stacked bars, but you can also see a stacked bar pattern here (with a schema inspector, in case it is helpful to see where your focus is located in the "structure" that data navigator also sees).

Here's my rough approximation of what the "bar navigation" example is doing:

Here's my rough approximation of what I might suggest for a stacked bar chart, instead: