jbrowse-components
jbrowse-components copied to clipboard
GMOD
Auto-adjust track heights to their current layout height
I think many times if a track is auto-adjusted to it's current layout height, which is bounded by a maxHeight, it can be better than if the track has a small height and is scrollable in that small area. This has been debated before but I think having an option for it will be ideal.
Given that the default height of a track is just 100 pixels this is often a good thing to have. Otherwise users have to manually use the track resize handle to increase track height
Proposal for this:
- when a track is opened for the first time, it can auto-adjust its height during the time in which not all of its visible blocks are loaded. After that, its height is solely under the user's control.
- when a session is reloaded, the tracks are at the height that's specified in the session.
what do you think about that, @cmdcolin?
My general feeling is that scrolls within scrolls is generally a problem. We have outer scroll and then each track can have scroll. This results in difficulty in even initiating an outer scroll with a mousewheel or touchpad. So my feeling is that it's better to just have autoadjust
But what about the problem of tracks jumping around as people scroll? Many have complained about that.
On Mon, Jan 27, 2020 at 12:28 PM Colin Diesh [email protected] wrote:
My general feeling is that scrolls within scrolls is generally a problem. We have outer scroll and then each track can have scroll. This results in difficulty in even initiating an outer scroll with a mousewheel or touchpad. So my feeling is that it's better to just have autoadjust
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GMOD/jbrowse-components/issues/534?email_source=notifications&email_token=AAASAFMJJWSUJBZKEH5M7TDQ747X7A5CNFSM4I5ESQY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKA6FSA#issuecomment-578937544, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAASAFKQSO6VUWA47IKIUK3Q747X7ANCNFSM4I5ESQYQ .
What I have heard is that track height was difficult to configure in jb1 and I remember Suzi requesting per track scroll but I feel there are downsides to having too many scrolls
Do you propose going back to the way JB1 does it, just refusing to render anything else once you get "max height reached"?
I think that scrolls within scrolls that cause difficulty interacting with the outer view is my main problem. If there are other usability problems, like having the right amount of info on the screen, and having per track scroll helps, then I may be open to it.
I looked at a comparison for example igv, and it does have per-track scroll in both IGV desktop and web. The per track scroll does not respond to touchscroll though which goes a long way towards not bothering me. Weirdly, the per track scroll is quite stealthy in that way. See https://igv.org/app/ the RefSeq track actually has a scroll that is not really obvious, I looked at it and said "ah yes a gene with only two isoforms, how simple..." and then I realize it actually scrolls down.
Here is a tinyurl of an IGV web with BAM and genes http://tinyurl.com/uko8pob that has per track scrolls, and only one outer scroll
We could make the track scrolls just not respond to mouse-wheel vertical scroll events fairly easily I think, which would make it behave like igv.js is behaving there. How about we just do that?
We could try. I am not a huge fan of how it changes the semantics of scrolling to a custom more-non-functional-scroll but if I need to get over that I can. I feel like adding scroll if a user needs it is not that unintuive
Note that, preventing scroll involves some involved stuff
For one thing
onScroll and onWheel event.preventDefault do nothing, they are maybe passive? useRef+ref.current.addEventListener event.preventDefault prevents outer scroll of the page, it halts outer scroll anywhere inside that element
I demonstrated this at one point but you can see it with a thing like this
<div id="test" style="height:1600px; width:500px;background-color:green;overflow:auto">
<div style="height:10000px; width:500px;background-color:red;margin:20px">
Hello world
</div>
</div>
<script>
document.getElementById('test').addEventListener('wheel', function(event) {
event.preventDefault()
})
</script>
Any wheel/touchpad scroll action of scrolling inside the red or green areas prevents outer scroll on my machine
The way to do it is to fully override any default scrolling I think, using a custom scroller that only replies to click events maybe
The comment above " I feel like adding scroll if a user needs it is not that unintuive" refers to the idea that we keep JB1 behavior for many cases, and add scrolling if needed maybe?
How about we:
- resize the track to fit its block heights during the period between when it is first opened and when all of its blocks are rendered
- implement something keep scrolled tracks from intercepting vertical mouse wheel events
That would mean that tracks, when first opened, will resize themselves to not need scrolling, but after that they will not resize and will be under user control. And when you scroll with the mouse wheel any scrolling tracks won't block that.
How about that?
I'll mull it over. It seems almost like step 1 is very much like jbrowse 1, why not just go full jbrowse 1 behavior. with step 2, it is difficult without a custom scroll as mentioned above.
Alternative to step 1: just have an opinionated stance on what a alignments track height is...on what a wiggle track height is, on what a gene track height is.
I'm going to throw my opinion in here and say that I like Rob's original proposal (adjust a track's height when it's first opened), and if you end up with a scroll within a scroll after that, it's just fine. We're using the browser default behavior for a scrollable element inside a scrollable page, so it should be what most people expect. I, personally, have never had any trouble navigating the scrollable tracks.
I think resizing the tracks on horizontal scrolling is problematic because if a track near the top resizes a lot, it could push another track that you may be looking at off the screen.
In order to perform outer scroll when you have per-track scrolls, you have to carefully position your mouse outside of any area the tracks occupy. I have a problem with this pretty much anytime there is an outer scroll present
Pages are much easier to deal with when there are not scrolls within scrolls
In order to perform outer scroll when you have per-track scrolls, you have to carefully position your mouse outside of any area the tracks occupy.
That's not the behavior I observe. If I scroll down on a track that is already scrolled all the way down, it scrolls the page instead.
@garrettjstevens I do not want to have to scroll a track to the bottom of it's per-track scroll to scroll the outer page
The way I refer to as the special location is the track controls, which will possibly go away, making this problem even more difficult
Here is a good article on the UX perspective of this issue https://baymard.com/blog/inline-scroll-areas
Sort of related https://ux.stackexchange.com/questions/102831/is-scroll-within-a-card-good-or-bad-in-desktop
Some ideas related to that article, truncation design https://baymard.com/blog/truncation-design