Open mdrasmus opened 10 years ago
I can see the advantages of this, but it seems to me like something that you'd want to toggle on and off rather often.
Might it make more sense to use a modifier key (i.e. ALT+trackpad == vertically-constrained scroll)?
I can see the advantages of this, but it seems to me like something that you'd want to toggle on and off rather often.
Might it make more sense to use a modifier key (i.e. ALT+trackpad == vertically-constrained scroll)?
That's an interesting idea. Just in terms of UX though, myself and several other users didn't understand why the pileup was "drifting" to the side when we were scrolling "vertically" through it. We first attributed it a bug until we realized the trackpad was performing movement in all directions and was picking up on a ever so slight horizontal component. In this case, the "alt+trackpad" technique wouldn't be immediately obvious to the user, although once discovered would seem to solve the issue.
Another issue is when your reach the top or bottom of all the tracks, your "momentum" seems projected entirely horizontal so that there is always a sudden horizontal drift at the end of a large vertical scroll. That also was unexpected and came off as buggy until we figure out what was happening.
In order to avoid having more options or keys, maybe just "snapping" is what's needed. For example, if the vector of the scroll is mostly vertical or horizontal, then you snap it to be perfectly vertical or horizontal. I could try to experiment with this and let you know if it helps. I don't know if a threshold for the projection would also help, e.g. only mostly horizontal vectors get projected horizontally.
I apologize if most of this is low-level default behavior and out of your control. Just thought I would let you know about some of the user experience so far.
I like the snapping idea. May take a little bit of tuning to make it "sticky enough" without being annoying when you do want to scroll horizontally, but seems well worth prototyping.
I'm not able to reproduce the large-horizontal-movement-when-reaching-the-end-of-the-vertical-range issue. It's possible this is down to personal scrolling technique, but also wonder if there could be some platform-dependent behaviour here? (for what it's worth, I mostly test on a recent-ish Macbook, using Chrome or Firefox).
For large pileups and large number of tracks it is nice to be able to scroll only vertically through a lot of information. The slight horizontal scrolling that occurs is usually unintentional and seems to trigger computation than if scrolling what purely vertical. This behavior could be an option in the configure panel.
Horizontal scrolling could still be done by click-and-drag.
Great project BTW!