-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bar | histogram lasso / select box dragmode #2045
+193
−17
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,52 @@ | ||
/** | ||
* Copyright 2012-2017, Plotly, Inc. | ||
* All rights reserved. | ||
* | ||
* This source code is licensed under the MIT license found in the | ||
* LICENSE file in the root directory of this source tree. | ||
*/ | ||
|
||
'use strict'; | ||
|
||
var DESELECTDIM = require('../../constants/interactions').DESELECTDIM; | ||
|
||
module.exports = function selectPoints(searchInfo, polygon) { | ||
var cd = searchInfo.cd; | ||
var selection = []; | ||
var trace = cd[0].trace; | ||
var node3 = cd[0].node3; | ||
var i; | ||
|
||
if(trace.visible !== true) return; | ||
|
||
if(polygon === false) { | ||
// clear selection | ||
for(i = 0; i < cd.length; i++) { | ||
cd[i].dim = 0; | ||
} | ||
} else { | ||
for(i = 0; i < cd.length; i++) { | ||
var di = cd[i]; | ||
|
||
if(polygon.contains(di.ct)) { | ||
selection.push({ | ||
pointNumber: i, | ||
x: di.x, | ||
y: di.y | ||
}); | ||
di.dim = 0; | ||
} else { | ||
di.dim = 1; | ||
} | ||
} | ||
} | ||
|
||
node3.selectAll('.point').style('opacity', function(d) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
return d.dim ? DESELECTDIM : 1; | ||
}); | ||
node3.selectAll('text').style('opacity', function(d) { | ||
return d.dim ? DESELECTDIM : 1; | ||
}); | ||
|
||
return selection; | ||
}; |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🆘 debatable logic alert 🆘
I chose to make a bar selected when the lasso/select polygon contains this point here which corresponds to the middle of the position coordinate at full size length.
Looking for 👍 s from @alexcjohnson @rreusser @monfera @chriddyp @cpsievert
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, that's a good question. The way you did it makes sense from a data perspective - the endpoint on the size axis is really the salient position of the bar's data, which is why we put the hover label there. But as far as the metaphor of "grabbing an object" goes, the center might be more intuitive. Usually I go with the data perspective though, and it seems to me like that might be more useful ("select all bars above 100" etc) and I bet people will get used to it. So I'm a 👍 but curious to hear others' perspectives - particularly @cpsievert
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems reasonable (especially with a 1-to-1 mapping from the (input) data value to bar), but another important question is what data do you attach to the select event when a single bar represents an aggregation of multiple values? It seems important to provide options as to how you'd like to respond to the event, so I if it were me, I would emit the raw data, the aggregated data, and the selection region (on the data scale).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now, we emit raw data and selection region. Adding the aggregated data is an interesting idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And, maybe I should point out that, assuming the model doesn't allow for partially selecting a bar that represents multiple values, I would actually vote for the selection region to cover the entire bar in order for a selection to be made...
The problem with that though is that it could be confusing for most users if we implement two different selection criteria based on whether an aggregation is taking place
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would offer a few arguments in favor of just keeping the "select the end" behavior:
bar
trace that conceptually represents a histogram. What would we do in that case, introduce an option for whether to select the end or the whole thing?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would lean towards a consistent logic for bars & hists (and maybe the possibility of adding modes in the future). I think having a different behaviour across those two charts would cause more confusion than benefits across users, especially given how often I see users creating their own "histograms" with the
bar
trace as @alexcjohnson mentioned above.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More attributes are probably not a good idea, but perhaps the bar default would be data endpoints and the histogram default would be centroid. And if you dig deep enough to notice this subtlety, it'll lead to an attribute that can be toggled. If additional attributes had no cost, that'd be my preference, but additional attributes do have some small but nonzero cost (bundle size, documentation size, discoverability, maintenance, sprawl, configurability over good defaults, etc.) Realistically though, I would not actually expect the attribute to ever be toggled intentionally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. I think there should be one simple and predictable way for this to work.
If the app developer really wants to allow users to select "partial bars" because it represents important aggregated data, then I'd argue that they should be more explicit about this in their UI and draw a rug plot below their histogram and allow users to select the exact partial sets of points that way. Or even a box plot with points or eventually a violin plot with points.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. Thanks everyone for your input. I believe the keep-as-is side wins.