-
Notifications
You must be signed in to change notification settings - Fork 0
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
Proposal for graphics-centric minimized time slider #505
Conversation
Video on Slack https://epvb.slack.com/archives/CMQ8K9XRS/p1694787354770699 If you look carefully, there's a bit of a clash of drop shadows (in the join between header and the slider) - not sure how to fix that. |
Ready for review. Open to styling/layout suggestions as always! |
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 think this is looking good, but I have some questions/comments that come to mind that may serve as a start to a future UX discussion.
- Should we have an info icon w/ tooltip as part of the on/off toggle that articulates what the actual component is doing? Or does this icon w/ tooltip need to be in a position that would render in the "unexpanded" state?
- Because I'm clearly seeing something in the "unexpanded" state that first renders, my brain sort of overlooks the toggle as a way to expand the filter. Instead, my brain sees that toggle as a way to collapse the filter in spite of the arrow down (which should suggest to me that it expands). Perhaps the cognitive dissonance is specific to my feeble brain, though!
- Nothing comes to mind as a fix for the drop shadow clashing, though it's not that severe either.
Thanks @jernestmyers - I think we need a small group to figure out the UX issues. Maybe unexpanded is still showing too much? |
…estion1 Timeslider help icon and further slimming
I merged the filter-sensitivity into this PR. Then I found an edge case where if you make a selection in the time slider and then change the filters so that the old selection is outside the time range of the current filtered data, that selection lives "off screen" and is still applied as a little filter, giving no results and a 500 (see VEuPathDB/EdaDataService#312) I thought it would be better to remove the selection/little filter if it has gone off-screen, so added this in the recent commit. It uses a |
I'm not sure I like the UX here, since it might not be obvious that the time filter was removed. Instead, could we extend the range of the filter to include the selection? Or maybe we should always show the full range (at least for this phase)? |
Yes, this is a good point. I was wondering about a snackbar. But extending the range to include the selection might be good - hadn't thought of that! |
One other idea... we can turn the slider off and have a message indicating that it contains a selection outside of the subset, and that the user must change the selection to enable it again (or something like that). |
Thanks @dmfalke - I have been working on this today and will have something available for testing soon. I got into a bit of a rabbit hole with semantic zooming and making sure the histogram is robustly showing the correct bin start/ends etc. Nearly done! |
Hi all - @jernestmyers @dmfalke @moontrip @chowington On Friday I did some major readjustments:
|
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.
Thanks to @dmfalke and @jernestmyers for the sync review. Notes below
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.
Call it TimeSlider.tsx?
@@ -143,23 +149,28 @@ function EzTimeFilter(props: EzTimeFilterProps) { | |||
() => | |||
selectedRange != null | |||
? { | |||
start: { x: xBrushScale(new Date(selectedRange.start)) }, | |||
end: { x: xBrushScale(new Date(selectedRange.end)) }, | |||
// The +2 and -2 are a nasty hack that seems to solve a problem |
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.
Suggestion to remove fake controlled behaviour - bring it back only when we need to (date picker inputs)
Investigate need for adjustment +2/-2 when loading saved analysis - check for no "drift" at either end of range after adjusting the other... - remove it if not needed.
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.
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.
Also take care of non-date number handling
I removed the "controlled" nature of the Brush. If you duplicate a browser tab with a pink date range, it will shift to the left a bit, but the underlying little filter does not change. I think this OK. |
This is ready for final review. Feedback from our meeting has been taken on board and sorted, thanks! :-) @dmfalke @jernestmyers |
end: xAxisRange | ||
? endDate > xAxisRange.end | ||
? xAxisRange.end | ||
: endDate |
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.
Just spotted I need to fix up the dependencies below. Will do so.
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.
Done ✔️
With react-query's client-side caching we are a step closer to DIY timeline animations. If we add the ⬅️ and ➡️ buttons that move the selection left/right, that will eventually all get cached. However, such controls will need re-enabling the fake controlled component behaviour. |
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.
This seems good to me
new Date(filterRange.max as string), | ||
unit as DateMath.Unit | ||
); | ||
return diff >= 12; |
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.
How did you arrive at 12?
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 left home at about 11:30 !
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.
But it was more "if there are more than 12 days, use weeks. If there are more than 12 weeks, use months, and so on."
Maybe it's too small. If there are 13 months, do we really want year bins? Perhaps 30 would be better.
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.
Yeah, I'll go with 30. And leave a comment.
Yes, and/or lat/long and/or the marker variable (though species has 100% coverage - a rarity) |
Fixes #514
This is a draft until we get UX approval.
I went further than anticipated and did the following
=== 'VectorBase'
that I copied - do we not have a VectorBase theme? @asizemore was asking about this the other dayStill do to