-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Description
As I was working on the sketches for the new Time Conductor and reviewing the current implementation, I’d like to suggest that we could and should do better with our time axis ticks. Currently, we take whatever pixel width we have, sub-divide it evenly, and then label each tick with whatever it’s value is at that pixel. So we often get a result like this:
If you accept the premise that ticks are meant to useful and human-parseable delineations, ours do not fit the bill. It's way too much cognitive overhead to have to parse out Z391.83:44:80 62-01-3102
when dragging a slider or looking at a plot. Also, we often display levels of granularity that are meaningless in the current overall time context: including milliseconds when the overall timescale is hours or days. They either get rendered as repetitive and space-using zeroes, or have a value other than zero solely because that's where the tick fell when we evenly sub-divided the space.
Instead, could we do these things, given a time span of a length:
- Find tick positions that round up to easily parseable numbers, based on the overall time scale that needs to be displayed. This will mean that we are not evenly sub-dividing the space, but instead, finding good value-parseable positions as close as possible to even sub-divisions.
- Show the lowest level of granularity needed in the label, and only show additional higher levels of granularity when one of those is crossed. For example, if we only showed seconds as 58, 59, etc. we'd need to display the new minute value when 59 goes to 00.
I put together this matrix as a first take on some examples for different time scales. This may not make sense on casual inspection, we should collectively review this together. My hope is that there's a library out there (D3?) that we can use for this. Mark Shirley has also done some good work on this problem.
Assigning to Kress to get this on the radar.