Fixing start/endpoints of chart

[philipnye]

Currently the chart can be drawn from a point before the start date supplied to the chart/to a point after the end date supplied to the chart. This is done to ensure 'sensible' gridlines/axis labels are used but causes two issues:

• People who are currently in post can appear to have finished in post because the axis continues beyond 'today' but the bar doesn't NB: We wouldn't want to extend the bar beyond 'today'

• We append "(since XXXX)" to bar labels where a bar starts before the start date supplied to the chart, but this is made redundant in some cases because the chart axis range starts before the start date supplied to it This feels less of a big deal than the first one - it's not likely to crop up that often

[philipnye]

I wonder - is it possible to use D3 to choose the gridlines and axis labels, but then revert to using the original start and end dates supplied to the chart? It's already the case that there isn't always a gridline at the point where the chart starts and ends. Would doing this introduce other problems?

[gilesdring]

There is a very simple fix to this: remove the call to the nice() method of the xScale. If you're happy that the bar start / end are provided by either the first start / last end of the timeline or explicitly provided I can make this fix.

[philipnye]

@gilesdring Yes, the scripts that I've written will always return both a (finite) start/end date for all bars and a start/end date for the chart as a whole. Just to check we're on the same page - this won't affect the choice of gridlines? I.e. Gridlines would be October (on 1 October) rather than 15 October, say?

[gilesdring]

It shouldn't do - all that will happen is that the range won't be rounded to a nice value - so if the earliest timestamp was 2:23 am on 15th Oct (for some reason) that's where the chart would start, unless manually overridden. I think the ticks will still fall on sensible points. Can run some testing to validate this assumption.

[gilesdring]

Confirmed, and removed in code. Will be in next release.

[philipnye]

@gilesdring We've tested this and it's looking good, thanks - definitely preferable to what we had before. We wonder if a further refinement is possible:

• For the page showing all roles held by an individual ('query 1'):
  • Rounding the axis start date down to where the next gridline would be before (or equal to) the start date provided by the Drupal code. So for Nigel Adams it would go to (1 Jan) 2010; for Lord Murray of Blidworth it would go to Oct 2022
  • Not doing anything further to the axis end date (your work above removing nice() has got this as we'd like it)
• For the page showing all individuals who held a given role ('query 2'): keeping the current approach to axis range and gridlines

I could probably find the budget for another hour or two if you think a fix would be doable in that time. If it's a more complicated ask, I think we'd live with what we have.

[gilesdring]

@philipnye thinking about this in generic terms, as it would need to be based on flags passed to the library, which has no knowledge of what it is presenting (!), would something like this work...

round: none | start | end | both

• If round=none, leave as is - this would be default
• If round=start, apply the nice to just the start (I think there is a one-sided nice)
• round end and round both would work similarly - I know you've not requested this, but it would seem logical to provide one option to cover all eventualities.

Let me know if this sounds workable. If so, it's a change to this codebase then further integration with Drupal, including setting the new property, which would likely need @graham73may to make some changes (I've no real insight to the database integration)

[gilesdring]

Hm. On second thoughts there, and having investigated, there does not seem to be a nice which only works on start or end. More digging required. I think the interface would have to be something like described.

[philipnye]

@gilesdring Thanks for giving this some thought. Sounds like there not be a particularly quick solution out there.

Given the limited time we have available + the fact it'd need some work on the Drupal side too, I suggest we park this - the current solution works very well, and this was just striving for perfection. Shout if you think I'm being too pessimistic on timing though.

cc @graham73may