"interact" property set for Marks or adding "click" events about vega

[jheer]

In addition to update, enter, exit and hover, Vega marks already support any arbitrary, named property set. Such sets can be invoked by name using the view.update method. (Similarly, custom properties within a set are also supported! They are included in scenegraph construction but subsequently ignored by Vega's renderers.) For example, the following is perfectly legal. Note that the "click" property set is a custom addition.

"properties": {
  "enter": { ... },
  "update": { ... },
  "hover": { ... },
  "click": { ... }
}

Interactors that invoke custom property sets can be defined by writing JavaScript event listeners, registered using the view on and off methods:

// invoke the "click" property set for an item upon mouse click
view.on("click", function(evt, item) { view.update({props:"click", items:item}); });

If desired, the default hover behavior can be disabled by including the flag hover: false in the view constructor options. This removes the only default interaction, letting you completely customize chart interactivity.

The obvious limitation here is that, excepting hover, all interactions must be expressed in JavaScript rather than in a Vega JSON spec. Given the complexities in supporting interaction well, we plan to keep it this way for the time being. The larger goal of formulating a "grammar of interaction" -- in addition to a "grammar of graphics" -- is an open research challenge!

In the meantime, it would be very useful to explore the development of pure-JavaScript interaction modules. These might take the form of a bundle of event listeners plus internal logic and state. Once a useful library of interactors (e.g., hyperlinks, tooltips, brushing/selection) and corresponding design patterns begin to take shape, we can further consider how interactions beyond hover might be incorporated into the JSON specification language.

[jheer]

Note: I closed the issue to indicate that there are no currently outstanding development TODO items here. However, I'm happy to carry on a conversation about interaction on this thread!

[milroc]

@jheer, I must have missed the Runtime documentation, thanks for reiterating it here it helped me better understand it.

Do you see the JavaScript interaction modules being part of vega or a tangential component initially? I think I'll probably proof of concept tooltips or hyperlinks and will reference it here soon.

With these interactions there are a lot of inherent underpinnings (voronoi, quadtree in d3.js are some examples) that would need to work well to create quality interactions with the visualizations. I'm beginning to feel like these may clash with the design of vega though, am I wrong?

BELOW: Speculative, and without a lot of knowledge on the subject.
On the open research challenge mentioned, when you're dealing with the 'grammar of interaction' you have a set (which I would assume is the largest set) of interactions that would 'break' the 'grammar of graphics' being used.
Should you try to build the 'grammar of interactions' on top of a 'grammar of graphics', which would likely result in a higher quality interaction with the user?
Or should you attempt to create the set of possible interactions with the information, and let the creator of the experience use both grammars and figure out their own ways to work with both?
My gut tells me the latter, but I am curious to hear thoughts by people with better knowledge on the subject.

[jheer]

For the time being, I see the interaction modules as separate from the main Vega repo. Perhaps initially as a "plug-in" (really, an external layer) package? I would like to experiment and learn more before committing to a specific approach. Ideas and contributions welcome!

As for a "grammar of interaction" -- I do have some thoughts, but need to incubate them further into a full-fledged research project...

[tony612]

Oh, the custom property is VERY COOL 👍