Persistent and Multiple Clicking and Unclicking Behaviour

@alexcjohnson

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

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.

@chriddyp

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?

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.

@cpsievert

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?)

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?

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

Per #420 (comment) we're thinking of changing the default hovermode to always be 'closest', so it's not too much of a stretch to say new features could force that behavior before v2. But I'd also be OK with just adding something to the docs for clickmode - like "clickmode: 'select' with hovermode: 'x' can be confusing, consider explicitly setting hovermode: 'closest' when using this feature"

we're thinking of changing the default hovermode to always be 'closest', so it's not too much of a stretch to say new features could force that behavior before v2.

Now that #420 (comment) is been added to our v2 checklist, 👍 for making clickmode: 'select' change the hovermode default. Note that we should make that clear in the clickmode and/or hovermode attribute description.

This is just the documentation of a team internal discussion. It was about the questions if users should be able to deselect a data point that has already been selected by a box or lasso select.

TL;DR is to make sure that if a user deselects a data point in an existing lasso or box area, this point should stay deselected even if another box or lasso selection take place.

Here's a screen recording of the current misbehavior in current development state. Watch out for what happens when the last lasso select takes place.

Other options would have been

to not allow to deselect a data point already selected through box or lasso
to purge all box an lasso polygons when a use selects by click, but keep all previously selected points selected

Apart from boxes and violins, traces with fill: 'toself' and hoveron: 'fills' also feature "special" event data.

Now,

on the assumption that hoverdata is relatively homogeneous across traces.

this would be very nice, unfortunately we're not there yet. But I agree with you: in theory, we should be able to figure out the clicked point based on gd._hoverdata only w/o having to resort to _module.

So, I don't think we should add another method on the module objects (e.g. getClickedPtsFor), adding a few lines of (hopefully temporary) logic in cartesian/select.js should suffice.

Okay, sounds reasonable to me as well. We're putting in temporary logic in one place and weed out parts of it as soon as hoverdata has been harmonized for a special-case trace type. Eventually the detection logic will become clean.

Introduce change of trace selection interface [1852]

@etpinard

Is it correct that one needs to hold both Shift and Alt to subtract from an existing (box or lasso) selection? If true, it seems odd that

plotly.js/test/jasmine/tests/select_test.js

Line 262 in 24b2912

drag([[219, 143], [219, 183]], {altKey: true});

is working. On current master, when testing manually I can't subtract from a selection just holding the Alt key.
CC @etpinard

Is it correct that one needs to hold both Shift and Alt to subtract from an existing (box or lasso) selection?

That's correct.

You're right this test looks odd. I think if you just Alt+click the browser doesn't register clicks.

Does that test fail if we set {altKey: true, shiftKey: true} instead?

Nope, test does not fail with {altKey: true, shiftKey: true}.
With my changes made to support select-on-click though, test fails with {altKey: true} and passes with {altKey: true, shiftKey: true}.

Introduce change of trace selection interface [1852]

With my changes made to support select-on-click though, test fails with {altKey: true} and passes with {altKey: true, shiftKey: true}.

That sounds fine to me!

Is box/lasso select supposed to be supported for scattergeo? (Sorry for asking, wasn't able to find anything about it at https://plot.ly/javascript/)

I was able to fix failing geo_point-selection image test (mock json has selectedpoints set) but when I use box or lasso drag mode the selection doesn't change even when I'm on current master w/o my changes.

Is box/lasso select supposed to be supported for scattergeo?

Looks like they're broken at the moment.

... on master that is.

I'll come up with a fix ASAP.

@rmoestl

Looking at this issue again, I think @rmoestl's remarkable #2944 effectively closed this thing.

@chriddyp ok to close this issue?

Closed in #2944

Navigation Menu

Repository navigation

Persistent and Multiple Clicking and Unclicking Behaviour #1852

15 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Persistent and Multiple Clicking and Unclicking Behaviour #1852

Description

Activity

chriddyp commented on Mar 1, 2018

alexcjohnson commented on Apr 30, 2018

etpinard commented on May 1, 2018

alexcjohnson commented on May 1, 2018

etpinard commented on May 23, 2018

alexcjohnson commented on May 23, 2018

etpinard commented on May 23, 2018

rmoestl commented on Jun 15, 2018

15 remaining items

etpinard commented on Jul 4, 2018

rmoestl commented on Jul 5, 2018

rmoestl commented on Jul 18, 2018

etpinard commented on Jul 18, 2018

rmoestl commented on Jul 18, 2018

etpinard commented on Jul 18, 2018

rmoestl commented on Jul 19, 2018

etpinard commented on Jul 19, 2018

etpinard commented on Jul 19, 2018

etpinard commented on Jul 19, 2018

etpinard commented on Sep 12, 2018

etpinard commented on Sep 14, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions