Persistent and Multiple Clicking and Unclicking Behaviour

[chriddyp]

Very closely related to Persistent, stateful hover, click, and selection properties and Customized Click, Hover, and Selection Styles or Traces is the ability for users to select one or more points through clicking.

Under the hood, this might just be a new "select" mode (like "Box Select" or "Lasso Select") that allows users to select and de-select points through clicking. Once clicked, the style of the clicked points would remain persistent.

From a UI perspective, the user would be informed that points are clickable and unclickable through:

• cursor: pointer
• customized hover on clickable points like bigger points or an outline or a tooltip
• A persistent or hover-activated "x" for unclicking points.

See this tableau dashboard for an example: https://public.tableau.com/profile/joe3537#!/vizhome/WorldBankIndicator/WorldData

Related to Persistent, stateful hover, click, and selection properties, users should be able to programatically specify which points are selected in order to initialize their graphs with pre-selected data.

---

cc @alexcjohnson @etpinard @monfera @jackparmer @charleyferrari

[chriddyp]

A few requests for this from the Dash community (https://community.plot.ly/t/highlight-clicked-marker-in-scattermapbox-graph/8315, https://community.plot.ly/t/is-there-a-way-to-clear-clickdata/8708).

If you are using Dash in your company or organization and can fund the development of this feature, please reach out.

[alexcjohnson]

A few notes after discussing this offline with @chriddyp

• Using click to create or alter selections need not be mutually exclusive with lasso or box select; those are set by layout.dragmode because the property you're controlling is "what happens when the user drags on the plot." Here the question is "what happens when the user clicks on the plot" and it could be really nice to, for example, draw a lasso to start your selection but then click individual points to add or remove them from the selection.
• I don't think we can make click-to-select the default behavior. A lot of existing apps rely on the click event to trigger something other than selection. Should we make a new top-level attribute layout.clickmode or does this need to be a trace-level attribute? The new behavior could be clickmode: 'select', and later we can add clickmode: 'hover' to trigger persistent hover labels, what do we call the existing behavior, clickmode: 'event'? Do we still emit plotly_click events in these other clickmode settings?
• Multiple selections and deselection: my gut reaction is to have a regular click make a totally new selection, so deselection would be just a matter of clicking a blank spot on the plot (perhaps also when only one point is selected, clicking it again would deselect?), and use shift-click to add/remove points. Is this discoverable enough? Perhaps we add a notifier about it on your first click-to-select?
• Does click-to-select exactly mirror hover data, like the click event data does right now, so that in "compare" mode a single click could add one point from each trace? Or do we do something like in the spikelines feature where after picking the hover data, we filter again to find the best single point and that's the one referenced for selection?

[etpinard]

nice to, for example, draw a lasso to start your selection but then click individual points to add or remove them from the selection.

yeah that would be really nice.

I don't think we can make click-to-select the default behavior

agreed.

Should we make a new top-level attribute layout.clickmode or does this need to be a trace-level attribute?

I like a top-level layout.clickmode and perhaps down the road have a clickinfo attributes in traces with values 'none' and 'skip' similar to hoverinfo to control how a given trace contribute to the click data.

The new behavior could be clickmode: 'select', and later we can add clickmode: 'hover' to trigger persistent hover labels, what do we call the existing behavior, clickmode: 'event'? Do we still emit plotly_click events in these other clickmode settings?

I guess we could make clickmode a flaglist so that users could set e.g. clickmode: 'select+event'. That said, are we ever going to add support for persistent selection via hover? For example via layout.hovermode: 'select'? (see last comment for more on this thought).

Multiple selections and deselection: my gut reaction is to have a regular click make a totally new selection, so deselection would be just a matter of clicking a blank spot on the plot

Agreed.

and use shift-click to add/remove points. Is this discoverable enough? Perhaps we add a notifier about it on your first click-to-select?

👍 for shift clicks!

Does click-to-select exactly mirror hover data, like the click event data does right now, so that in "compare" mode a single click could add one point from each trace? Or do we do something like in the spikelines feature where after picking the hover data, we filter again to find the best single point and that's the one referenced for selection?

I guess this should be configurable in a similar way to hovermode: 'x' | 'y' | 'closest' which perhaps means we need two new click* attributes: one similar to dragmode which tells which interaction to perform and one similar to hovermode which tells which info the interaction should brings up.

[alexcjohnson]

I guess we could make clickmode a flaglist so that users could set e.g. clickmode: 'select+event'.

I like that - so users who already implemented hacks to get a similar result (@cpsievert) or switching between select and some other click behavior could set clickmode: 'select' and not worry about their other event handlers conflicting with the new behavior.

That said, are we ever going to add support for persistent selection via hover? For example via layout.hovermode: 'select'?

Yeah possibly - for immediate cross-plot brushing like https://rd3.now.sh/ perhaps. Doesn't seem to me like the two conflict though, we could add that later and people might even want to use the two together, so you can persistently select some points then add the transient hover selection to it.

perhaps means we need two new click* attributes: one similar to dragmode which tells which interaction to perform and one similar to hovermode which tells which info the interaction should brings up.

Alternatively, don't implement a second attribute, have selection and event data always match hover data, but make hovermode default to 'closest' when you're using the new clickmode values.

I started describing how a second `click* attribute would look and it got really complicated (below), so ^^ is my vote, I think it's both clearer for users (it's obvious what exactly you're clicking on) and easier to implement!

• clickdata: ('all'|'closest') perhaps? Where 'all' means "all the points showing hover data" and 'closest' is just the closest one (but I think hovermode: 'closest', clickdata: 'x' would be confusing, I don't think we allow that - so clickdata would be irrelevant if hovermode is already 'closest')? And this controls both the event data and the selection data? For backward compatibility it seems like with clickmode: 'event', clickdata should default to 'all', but for clickmode: 'select' I feel like clickdata should default to 'closest' AND we should find some way to indicate with the hover tooltip which point is the closest (thicker border? bold text?)

[etpinard]

I started describing how a second `click* attribute would look and it got really complicated (below),

I had a feeling adding a second click attribute would made things confusion. Thanks for confirming that feeling I had. Much of the spikes behavior is tied down to hovermode as well, so this is not untraveled territory for our good friend hovermode. So yeah, a single clickmode sounds 👌 to me.

Maybe the problem with hovermode isn't what it does, but how it's named: something more general like interactionmode might be better.

but make hovermode default to 'closest' when you're using the new clickmode values.

Oof, that might be a little too magical here for my taste. How bad (for most applications) would clickmode: 'select' and hovermode: 'x' be?