Trend: change X axis resolution

[gregallensworth]

In trend window, change the X axis to not necessarily aggregate by every month. Provide a UI for switching between “bucketing resolutions” of 12, 6, 3, and 1 months.

Both Trend charts should use the same X axis resolution.

This would literally start counting back from whatever month user has selected as the end date; not a fixed Jan-Mar quartering sort of deal.

[gregallensworth]

See the new gda-issue101-trendx branch, which may do just what they need.

There are some potential usability items, that we won't be able to work around.

• The total time-distance between the right-side and left-side is the selected time scale, irrespective of the aggregation/chunking to smooth out individual months into larger trends. As such, the jump between two tooltip points will be larger than previously (as it's jumping 3 months or 6 months or 12 months). The workaround for this it to change your time scale, so it's showing more/less time in the viewport.

• Some points in time may be off the edge of the viewable area, and this can affect tooltips. This wasn't a significant issue when there was a notch every month, but with larger jumps it can be unacceptably far off the edge. See screenshot below. I may be able to futz the tooltip code to force a minimum X offset so this won't happen as badly.

• Depending on your time scale and aggregation, there may or may not even be a tooltip available, e.g. showing a 6-month period on the viewport, with 12 month aggregation. Nothing we can do there.

Next steps:

• [x] Tooltips, can they have a minimum X so as not to fall past the left-hand side?

• [x] Save the month-aggregation setting to URL params, and set it from URL param on page load.

• [x] Adjust default aggregation to 1 month. The default is still 3 months from debugging + development.

• [x] Current aggregation starts at the beginning of time (August 2011) so 3-month periods are always Aug/Sep/Oct, Nov/Dec/Jan, Feb/Mar/Apr, May/Jun/Jul.

  • Ideally aggregation could be based on the calendar month of the selected date range, e.g. selecting Apr 2017 - Jul 2018, would choose aggregates starting in Apr such as Apr/May/Jun. No ideas for how to do that...
  • It is clear that chunks at the start & end of time could fail to flesh out a full block of X months (e.g. at the start of time, Aug + Sep 2011 would be a block by themselves, followed by Oct/Nov/Dec; Jan/Feb/Mar; Apr/May/Jun which is finally in sync).

[gregallensworth]

Tooltip X position fix:

[danrademacher]

I see based on chunks starting at the beginning of time going forward vs starting present and going back is why most current 2 months are always separate from the larger agg summarization:

If we have to start at the beginning, I wonder if we hard-code in a Jan 2012 start date, so at least fixed periods align with familiar calendar years, semiannual, quaters.

[gregallensworth]

I don't see any way around that fact, that if you want data divided into buckets of X then the number of data points should be divisible by X. When the number of months (currently 85) is not divisible by X, then at either the beginning or end there will be a "undersized remainder" block.

But if it is preferable that this remainder be back in 2011 on grounds that it is "probably relevant less often", then it should be a small change to reverse the list and chunk it, then reverse it again. That should give us X-month blocks starting present and leaving the "undersized remainder" back in 2011.

The good news though, is that the blocks are labeled so it's clear when your block is not the right size: the most recent block is Aug-Sep 2018 which is clearly not 3 months. I could even add to the a tooltip a "X months" notation, so it's doubly clear for those blocks that they aren't full blocks.

• [x] Reverse the aggregation so chunks form from the last month, and back into time. Thus the remainder blocks will appear at the start of time (Aug 2011).

• [x] Add to the tooltip the number of months, so it's visually obvious that this block is N months. Bonus points: do so only if the block is under the selected chunk size so as to make less visual noise.

[gregallensworth]

Tooltip behavior: If block size is < X then the tooltip explicitly states the length.

[gregallensworth]

Chunking behavior: Starts at the present, works backward.

Commit dc57ab7 brings the first round of chunking behavior. But commit e77b006 changes the plotting position of a block on the chart/timeline, as being the block's ending date This gives the more pleasant visual effect, that the Jul/Aug/Sep block now extends past July but not quite to Oct -- just what one would expect visually.

At the beginning of time, it looks like the screenshot below. The visibly drawn line starts at September, as that it the plotting point of the three-month aggregate.

[gregallensworth]

One last UI item:

When the text of the tooltip is not sufficiently lengthy (e.g. with no comparison areas selected), and also one adds to the months readout "X months" wording, then the tooltip may not be wide enough to contain the text and it overflows.

[gregallensworth]

As of commit 3083c34 the tooltip width & height are calculated to look good, regardless of how many lines of text are displaying (minimum 2, maximum 4). Prior version was optimized for having both primary + secondary case.