Document range handles and other parts of the interface

[blubbers122]

Grabbers on the range selection would be a good feature to have as it helps with ease of use. The range selection is next to mouse-controllable time segments for the events so it would be intuitive to have the range area adjustable. Also when someone uses the hotkeys to move the range start and end to the playhead accidentally at the same spot it gets stuck. And first instinct is to drag it back to where it was but there is no way to undo it (sadly no Ctrl+Z) without knowing about the field in the left panel or the project.meta field (which aren't documented to my knowledge).

stuck range:

The grabber could look and work similar to the grabber you get when you hover the bottom panel's top edge, just horizontally facing and on both start and end edges of the range area

[aarthificial]

Changing this to a documentation issue since, as mentioned on the Discord server, these handles already exist, it's just that they are available when holding SHIFT

I think a page dedicated to describing the functionality of the editor is necessary since right now there's no easy way for newcomers to find that information.

Additionally, the status bar at the bottom could list SHIFT alongside other shortcuts.

[AlbertMarashi]

I agree with this issue, also got very confused by this and had no way of exiting the range mode - It seems very confusing so definitely a UX issue, I had no idea about the shift thing until someone mentioned in discord

[hhenrichsen]

I wonder if another option here is to have the handles for the range extend beyond the range itself on either end, so there are dedicated click areas for moving the play head and moving the range. I think that would prevent the two areas from fighting and make it a little move obvious without needing to find the shift hotkey.

[aarthificial]

@hhenrichsen This would conflict with #970

[AlbertMarashi]

@aarthificial can't we have both?

UI to modify range on the outer edges of the range, then ability to drag the playhead where ever.

[aarthificial]

We used to have that, people would edit the range by mistake while trying to drag the playhead. That's why it's now disabled by default.

[AlbertMarashi]

@aarthificial putting them on the outer edges seems like it would solve that problem and then having the SHIFT for power uses to prioritise those to me seems like the most ideal approach.

As a new user, I had no idea how to change them at all and found it terribly confusing

[aarthificial]

putting them on the outer edges seems like it would solve that problem

That's what I mean by saying that it would conflict with #970
That feature will allow people to seek past the limits of the range, encouraging them to click outside of the range to snap the playhead there, again introducing the same problem.

I need to emphasize that people struggled with editing the range even back when the handles were always there. Sadly, objective intuition doesn't exist, there will always be people who are not used to something and find it confusing.

Making two interactive elements overlap the same space is always a bad idea and it will be an annoyance to existing users because they'll have to remember to avoid the handle when seeking.

As a side note: SHIFT is already meant for power users. The main way of editing the range is through the video settings tab.

[AlbertMarashi]

As a UI/UX person, I still think that this approach is better if it conflicts, but personally I do not even view it as a conflict if we have that feature too.

The overlap would be rare as the playhead exists on the inner side, whereas the drag handles exist on the outer sides. The only time it would occur is if the playhead was at the very edge already, in which pressing SHIFT would allow you to move the area, otherwise dragging the playhead backwards would move the range (the same as if you clicked the dragger anyways)

That's just my thoughts.

[aarthificial]

The only time it would occur is if the playhead was at the very edge already

That's not true, the position of the playhead doesn't matter because you can seek to any point of the animation by clicking anywhere on the timestamp track. The overlap would not be rare, it would exist always.