Improve the startOfWeek + month + year multi-layer time raster

[markov00]

Describe the issue
The current multi-layer time axis has a visible defect when rendering the raster: startOfWeek + month + year raster .
In some situations, it can be interpreted that the last start of week of a month is shown as conflicting with the next month label creating a visible confusion when rendering it.

To Reproduce
Steps to reproduce the behavior:

1. Go to Timeslip prototype
2. Zoom at Month/Weeks of year level

Screenshots

Screen.Recording.2023-01-13.at.19.22.04.mov

Kibana Cross Issues
elastic/kibana#148872

Checklist

• The proper chart type label has been added (e.g. :xy, :partition)
• The proper feature labels have been added (e.g. :interactions, :axis)
• Every related Kibana issue is listed under Kibana Cross Issues list and the kibana cross issue tag is applied

[nickofthyme]

I see the issue regarding the day/month cross over at the start of some new months but I think the real issue is how we handle the general sticky interval label behavior.

this behavior of showing the previous tick interval is a little strange when the tick is no longer visible.

Screen.Recording.2023-01-17.at.02.50.41.PM.mp4

Take the screenshot below for example...

Looking at the 13 | 20 tick, this can be confusing because the 13 label is right next to the 20 label even though the respective tick for the 13 value is well out of view to the left. This stick behavior feels really nice but could easily lead to confusion.

I imagine the benefit of this behavior is to give the user the best context of the current time interval and rather than having then scroll back to see the previous interval it simply shows it in view until the next interval takes over.

Solutions

The way I see it there are a few solutions to this problem and subsequently also the day/month cross over issue too.

All these solutions should be applied to both the left and right cases.

Fill in minor ticks

This solution would fill in the minor ticks as the previous ticks leave the field of view. Only the major interval values would be bolded where the minor ticks would be subdued and fade in and out as needed, max of two visible at a time.

A slight variant of this approach could be to keep the interval to the left of the active day to show the previous interval context. In such case the previous interval would be bold and the

Arrow to indicate the value is for a previous interval

This solution would be to add an arrow or carrot icon that would appear when the sticky positioning takes over.

⚠️ This would not solve the day/month cross-over. To solve the day/month cross-over issue, we could persist the previous interval label to the left for each new month. Something like below where the far left bold grid line is the start of the chart area...

This creates the need for a larger right and left margin for longer month names.

This solution is not ideal for transitioning to a new month because we now run into the same issue with the first of the month sticking to the right of the month grid line. Having two things pointing to the right would be a little much so a variant to this approach would be to push the month label out to the first tick of the next month, not the 1st of the month, with an optional arrow. Then once the first tick of the new month is reached the new month label will stick and the previous left-most month will be wiped away with the new one.

The bold line to start the new month would not be sticky as the time is scrolled to the right. So this would create a gap between the year and the new month for a small period.

[markov00]

Great ideas @nickofthyme I particularly like the first arrow idea, that notify the fact that the 13 is referring to something that happened before.
I think that could solve the start-of-week/month crossover if we push back the start-of-week at the beginning of each new month instead of at the beginning of the nest-start-of-week as of today. See the following example:

Screen.Recording.2023-01-18.at.09.31.20.mov

Showing the arrow, or "fading" the number linearly as the start-of-week is far away from the current position (similar to your first idea) could be a good solution too

[nickofthyme]

Yeah that's a big improvement. But the one thing I don't like about this is that the behavior for the first week interval label is now different (i.e. non-sticky between month changes) than other weeks. That was what I was trying to fix with the offset month like this 👇🏼 .

That being said, it is a difficult problem to solve and both solutions have pros and cons. Your solution is much cleaner and succinct.

[markov00]

I don't fully understand what is the reason to add an offset to October. October actually starts at the major tick, so there is no need to offset it.

Another "solution" is, if we are showing start of weeks, we probably want to show the month name aligned with the first week contained in such month, so, in your screen you got a long major tick on the 4th October (this can justify the offset you have added). The only problem with that is, when zooming, the October label will jump from 4th October to 1st October when you zoom in.

[nickofthyme]

Yeah the reason for that is that the line you circled there is not sticky, it will scroll past to the left and the October will just be floating next to the September with no line to delineate the two, until it reaches the first month where that grid like with be sticky.

The only problem with that is, when zooming, the October label will jump from 4th October to 1st October when you zoom in.

Yeah that's true

[markov00]

Yeah the reason for that is that the line you circled there is not sticky, it will scroll past to the left and the October will just be floating next to the September with no line to delineate the two, until it reaches the first month where that grid like with be sticky.

Oh that's not true, September will be pushed by the highlighted line, that represents the beginning of the month. So September will disappear and will stay always at the left of the October label and a line will always separate the two.
The "overlapping" problem can only be visible when one layer is divided into intervals that doesn't match exactly with the layer below. I think this could happen only if one is showing beginning of week and the other months, all the other combination are always aligned: days/month, month/years, hours/days, minutes/hours, hours/months etc.

[nickofthyme]

I think this could happen only if one is showing beginning of week and the other months, all the other combination are always aligned

Yeah I think that's correct

[markov00]

@nickofthyme if I'm not wrong, the solution here is to check whenever the weekStartDays raster layer is fully contained within the month or not, and if not, its interval should be shorter (just referring to the number of days contained within the month)

[nickofthyme]

I think we keep this issue open to track the changes described in #1934 (comment). These changes would be better for the dynamic timeslip chart with pan and zoom.

One variant of this approach could be to provide a different raster layer for labels describing the interval start (i.e. 30th) verses the interval as a whole (i.e. Week 12), some property to designate this for each layer.

[stratoula]

@nickofthyme @markov00 as we fixed the main bug we can de prioritize it for now right? Or do we want to move it to 8.10?

[nickofthyme]

Yes, I updated the project item. I think this task is most impactful for the dynamic timeslip, whenever that starts to be used in kibana we should prioritize this.

[nickofthyme]

Temporary fix for this suggested in #2536