[Restyle / enhancement] Time series

[shixiedesign]

Time series axis styling, updated (ready for Dev 🤖 )

Specs for axis styling for time series, time interval labeling. Added functionalities requested in #280 , #277 , #258 .

[theiliad]

@shixiedesign The image you uploaded is blank

[shixiedesign]

Corrected the image! I'm working on aligning with the numbering rules in Cameron's designs. So styling is good, but the x-axis labeling is not ready for dev just yet.

[theiliad]

Looking great 🍺

[scottdickerson]

@theiliad when is this coming? We could really use this in IoT

[theiliad]

Hi @scottdickerson. Are we talking about axis breaks here or the entirety of the specs?

[caesarsol]

Hi @theiliad, at Accurat we put some thoughts into the interpretation of this design spec, and this is to explain how we'd implement it on the development side.

We are only talking about the time axis problem, nothing has been thought about the axis breaks, on which we'd like to discuss. (Maybe on a different thread?)

From the design spec posted above, we understand:

• The chart shows a certain number of ticks, depending on the user configuration or available space in pixels.
• The ticks labels are different depending on the timespan of the data series. Not on the number or frequency of datapoints, but only on the distance between first and last temporal datums.
• Every tick label has a specific formatting, depending on its position:
  • if it's in first place, a long label is shown.
  • if it's on the change of a time range (i.e. day, month, year), a long label is shown. The exact time range can be different for every case, detailed below.
  • in the remaining "normal" ticks, a short label is shown.

This is a table interpreting all the different formats in all cases:

15seconds:
  long: MMM DD, hh:mm:ss AM  // hours omitted if 00:00:00 (*)
  short: hh:mm:ss AM
  
  change min: =short
  change hour: =short
  change day: =long
  change month: =long
  change year: ? (**)

minute:
  long: MMM DD, hh:mm AM
  short: hh:mm AM  // minutes omitted if :00 (*)
  
  change hour: =short
  change day: =long
  change month: =long
  change year: ? (**)

30minutes:
  long: MMM DD, hh:mm AM
  short: hh:mm AM  // minutes omitted if :00 (*)
  
  change hour: =short
  change day: =long
  change month: =long
  change year: ? (**)

hourly:
  long: MMM DD, hh(:00) AM
  short: hh:mm AM
  
  change day: =long
  change month: =long
  change year: ? (**)
  
daily:
  long: MMM DD
  short: DD
  
  change month: =long
  change year: ? (**)

weekly:
  long: www, MMM DD
  short: www
  
  change week: =long
  change month: =short (?)
  change year: ? (**)

monthly:
  long: MMM YYYY
  short: MMM
  
  change year: =long

quarterly:
  long: QQ 'YY
  short: QQ
  
  change year: =long

yearly:
  long: YYYY
  short: YYYY

And these are our considerations on it:

• (*) In the minute long label the hour is shown, but nothing is shown in the 15seconds long label. Is that correct? We would consistently show the hour:minutes:seconds in both cases.
• (**) If the dataset crosses an year, the labels would not show it. It would make sense to show the previous year in the first label, and the new year in the label for each January 1. This would mean adding YYYY to the long label only in the case the first and last dates are on different years. It could also be viable to always add the YYYY to long labels, if we want the readers to immediately temporally localize the data.
• The use of verbal labels such as "midnight", "noon" could pose a translation/localization problem.
• Everywhere a hour label is shown, (i.e. in the 30minutes case) we would use "1:00" instead of "1", to make it more clear that it's not a day-of-month number but a hour. (Edge case: in the hourly chart the labels | Dec 31 | 1 | 2 | 3 | would be ambiguous)
• The weekly case only shows the day-of-week. This could make the chart more implicit if an entire month is shown, since only 4 Mondays would contain the day-of-month label. Maybe this is a specific use case we are not aware of?

If everything seems OK to you, we will start with a draft implementation and a PR!

Thanks,
cesare

[caesarsol]

@theiliad @tw15egan Hi, any thoughts on this proposal?