Multiline time axis: collapsing some of the layers

[monfera]

Multiline time axis: layer collapse

The multilayer time axis was introduced with this PR and has been in production for over half a year. A handful of feedback comments arrived, curated by Product Management. These express a wish to merge some of the layers, specifically, some elements of the time of the day, such as hours and minutes.

The current implementation does not merge time layers, hours and minutes are separate rows:

We're considering to make a change, though the modest feedback is a very weak signal: users who prefer it the current way, or are neutral about it are unlikely to speak up. There's always a potential for ultimately very few people to influence features (including ourselves) and it would require a lot of care to solicit feedback without making users feel that the "right" answer is to ask for a change or the other way around.

This issue explores the pros and cons, and the difficulties of the current layers vs. collapsed layers.

Pros of the distinct layers:

1. It's a simple, easy to grasp concept, as each layer is responsible for a single resolution. It's true for the bottom layer too, it merely appends the larger units of time for context
2. Since the layers are not merged, there's no need to deliberate which layers should be merged under what condition
3. It requires the minimal horizontal space for each tick label. hh:mm or hh:mm:ss (or beyond) need more space than hh or mm. This influences the possible grid resolution. A relatively high tick resolution generally allows quicker localization, because viewers are less reliant on the vertical grid lines, counting them and processing their saliency in the time hierarchy
4. It's already implemented, and the kinks have been worked out
5. It's in production and seems to be broadly accepted or at least tolerated (which is of course not the benchmark of user satisfaction)

Pros of the merged layers:

1. We perceive patterned information more easily, for example, 10:15 is easier to interpret as quarter past ten then two separate numbers on different rows, 10 and 15. While we tried variations, such as postfixing the hour with h (phased out) and postfixing minutes and seconds with prime markers ′ and ″ (currently active) some of the feedback we got explicitly mentioned unfamiliarity with the prime markers. Indeed, it's much less common than hh:mm and it's often reserved for indicating duration, as opposed to a point in time
2. The hh:mm and hh:mm:ss derive from standards, and are more universal and international than other markers such as h for hours or the prime markers
3. It would please a set of users: not just those few who asked for or about it, but those users who may not like or prefer the current one, without reaching their threshold for filing feedback
4. Tools that the user may be familiar with, including in the industries and horizontals we operate in, encounter hh:mm, mm:ss in competitive or complementary tools, even in case of multiple axis layers

The currently proposed layer merges are conservative in that they represent the smallest change, while making good on feedback:

• merge seconds and minutes (hh:mm)
• merge minutes and hours (mm:ss)
• do not currently merge hours, minutes and seconds into one layer, as hh:mm:ss gets long, and the time loses more of its hierarchy; it can still be considered for a future implementation
• do not merge sub-second units into other layers
• do not merge units larger than hour (it'll still be a future option to expand on layer merges)

Proposed logic:

1. As currently, the time raster determination will start with the finest (top) layer
2. If a seconds layer and a minutes layer are both present, merge them
3. If a seconds layer is not present, but a minutes and hours layer is present, merge the minutes and hours
4. The merge frees up a layer compared to the current logic; fill it following the current logic (eg. show day labels below the hh:mm layer)

Note: there's already a generic substitution mechanism in place, because a specific time raster can already be present with multiple tick label lengths, such as months with no tick label (only grid/tick line); 1-letter month abbreviations; 3-letter month abbreviations; full month names

Post implementation tasks:
Filter user feedback, and reach out to the couple of users who asked for a change

[markov00]

Thanks, @monfera for the details. I'm not fully sure how it will looks like in the attached screenshot you provided: are the 1st and 2nd layer merged together? Does that approach keep the number of layers consistent across various resolutions?

[monfera]

In this case, the future layers would be:

• Top layer: hh:mm, so, | 22:00 | 22:15 | 22:30 etc (assuming this wider thing fits between the bars; if not, then | 22:00 | 22:30 | 23:00 etc)
• Middle layer: day of month (as that's the next level of granularity), so | 1st | 2rd etc. (only these two will be present at this zoom/pan)
• Bottom layer: everything else up to and including the year, so in this case, | June 2021 | etc. ( July 2021 of course won't be present with this specific zoom/pan)

Even now there's no static consistency: zooming alters what layers are present. So,

Zoomed in, you may have mm:ss / hour / everything else, while zoomed out and losing the seconds, it becomes hh:mm / day / everything else

[markov00]

@monfera understood thanks
With consistency, I mean consistency in the number of layers and I think we are always keeping the same number of layers correct?

[monfera]

Just to wrap up what we discussed:

• There can be zero to maxLabelRowCount (currently set to 3) number of axis layers; it's always 3 layers with usual zoom labels and only drops to fewer than that if the chart shows several decades, as we don't currently have rasters for centuries, millennia etc.
• But there can be more raster layers than that: unlabeled ones. For example, there may also be an arbitrary number of rendered unlabeled rasters, for example, if the finest raster (binning for the data) is too dense for individual labels, or every nth grid line is made more salient (eg. the 15-minute grid lines, when the finest raster shows 5-minute bins). Currently, the typical number of unlabeled, rendered raster layers is 0...2, so typically, there are 3..5 rendered raster layers, 3 of which are labeled
• As the rasters, and their formatters and replacement rules are rather flexible, consistency is achieved by creating the desired rasters and making suitable replacement rules, rather than something we generate. Each time level (hours, days, etc.) have some human specificities and customs, so in the first iteration there was no attempt to go real generative toward some notions of consistency

What we haven't discussed today: While the rasters and replacement rules give a good deal of flexibilty, one design consideration is the behavior of the time axis during zoom. For example, it would be possible to have a much longer set of rasters: currently, the hour only has subdivisions of 1, 5, 15 and 60 minutes. But there are other divisors of 60, such as 2, 3, 6, 10, 12 and 20. Including these would result a significant number of new rasters, and in that case it's worth considering automating the generation of both the rasters and the replacement rules, otherwise it'd be error prone. However the zoom behavior is a design constraint, consider these examples:

• Zooming out a little bit from a 5-minute labeled raster, it'd probably be a bit jarring to jump to a 6-minute raster, even though it's also a divisor of 60. It's because 6 is not a multiple of 5. So, almost all gridlines vanish, while an almost equivalent number come in. I personally don't think that maximizing tick label density is worth badly breaking the object constancy. Some divisors would be awkward anyway: while a 10-minute raster, on its own, is OK, it's rare that a 6-minute pitch is expressly desired. It's only worth doing if the Elastic data fetch, for whatever reason, should grab 6-minute bins from the server, because in this case, the data and grids/ticks are naturally aligned.
• Even in this case ^, user offsetting, or difference of central vs reporting time zone, the tick/grid lines wouldn't necessarily align with the actual data. So, support for arbitrary bin lengths and offsets would require a serious design iteration. The timeslip prototype/chart doesn't give that level of control to the user, as it has fewer rasters and it dictates the resolution of data to fetch
• If full bin width control is given to users, there can be arbitrary pitches such as bins of 7 minutes. This is even more removed from the purported consistency and object constancy provided by the timeslip concept
• Also, the more salient, unlabelled grid lines should be considered. For example, with a 1- or 5-minute pitch, it's natural to have a more salient grid line at the 15-minute boundaries. But admitting arbitrary unit lengths such as 6 or 12 minutes leads to no, or very different natural grouping, so again, the timeslip concept is compromised