Stop point-in-time annotations from overlapping the start and end of the timeline

[JulianKniephoff]

And maybe even the start and end of the currently visible area (which might be different due to zooming).

Context: Once the proposed solution to #299 is merged, we will have the problem that point-in-time annotations, which are now rendered as an "anchored box" that is always wide enough to hold its entire text, will stick out of the timeline if the point in time they describe is very close to the beginning or the end of the video.

This is of course undesirable, and #299 has a few thoughts on the issue, a few of which I tried while working on that issue. Here is what I tried explicitly:

1. Nudge point in time annotations slightly to the left or right, depending on their relative position on the timeline, that is: An annotation in the exact middle of the video will be centered to it's anchor, one at 1/4th through the video will be pushed 25% of its width to the right, etc.
2. Only push the annotations when they are overlapping the current viewport of the timeline, and just enough so that they don't overlap the edges anymore.

The latter is only possible in a changed event handler for the timeline, because only then do we know the exact absolute positions of the annotations and can test whether or not they stick out. However, when we move annotations in this hook, we break certain assumptions that the timeline makes. For example its layout algorithm ensures that no two annotations ever overlap, which is a property we want. By arbitrarily moving annotations in the changed handler, we might create overlaps, though, and there is no practical way to redo the layout after our changes.

The former is also possible while rendering the annotations themselves, which we can hook into as well. This happens earlier, before the annotations are laid out. This means we don't have the absolute positions yet, and can only do 1. However, this also happens before some of the elements that are used to enable the interactions with the timeline are rendered. In practice this means that while we can nudge the content of the timeline items here, we can't influence the drag handles. This desyncs the visible area of the annotation and the area where you can drag and resize it, which is super confusing.

A third solution I have in mind which I couldn't try yet is to just have some padding around the timeline. Currently the viewport of the timeline is constrained to exactly the length of the video. We could of course insert some blank space to the left of the start and to the right of the end. The big question here is: How much? Because dynamically finding out exactly how much might run into similar problems as the approaches above: Not being able to hook into the library at the right time to have all the data that you need and being able to influence everything you have to at that point.

[dagraf]

One short comment: We do NOT want «point-in-time annotations, which are now rendered as an "anchored box" that is always wide enough to hold its entire text». With for example free text annotations containing couple of sentences this is not feasible. See first bulletpoint in #299:

• The minimum width of point of time annotations is as wide as the letter "W". So all newly inserted annotations are this wide.

[JulianKniephoff]

@dagraf you are right. I set the width of point-in-time annotations to 4ex in #327. In my testing, this contains a W pretty precisely. However, there is no real way to set this width to "the width of a W," so we will have to test around a bit here.

[dagraf]

• Please make witdth of point-i-time annotation slightly smaller. But first please fix: https://github.com/opencast/annotation-tool/issues/331#issue-564239550
• Please add some padding around the timeline.

[JulianKniephoff]

As it turns out, even the padding idea is not as easy as I thought. I think I could make it work like the following, which I don't really like, yet.

• The padding would always be visible, on both sides, even when zoomed in, and always have the same width.
• When you scroll horizontally in a zoomed in state, annotations would overlap the padding.

This seems a bit confusing to me. It's also a bit hard to describe with words, so if I have enough time I will post a mock-up here so we can discuss it further.

Thoughts?

[dagraf]

I get it. So it's described well enough.

After discussing it with our interaction-design-expert (Yvonne Seiler): It would work for us. But please consider the following specs.

Specs:

• Padding area should be white.
• Insert a thin grey line between the padding area and the tracks.
• An active track should be in a transparent grey: rgba(170, 170, 170, 0.2) > See attached screenshot.