Generic ticket for the graph constraints - will need to be broken up into smaller tickets/stories before being actioned.
Note:
One thing we probably need to discuss is what constraints admins should be able to set. It would be best to allow the greatest possible flexibility rather than focusing on ease of use here. For example, a solution where I would have to type in something like 1 < 2; 2 < 3; 3 < 4; 4 < 5 would be more clunky than ticking a “monotonically increasing” box, but it would also allow me to specify things like an “inverse-U-shape” (i.e. 1< 2; 2 < 3; 3 > 4; 4 > 5) or any other distribution shape demanded by the question. That would also make it easy to apply this to something like a pie chart, where monotonicity is poorly specified. Not sure how it would work for a line graph—perhaps it would suffice to have mon. increasing and decreasing options as well as an option to specify a range (on the x-axis) for the max and min points (e.g. on a 0-100 x-axis, if I want some variant of an inverted u-shape, I could specify that the min should be at 0 or 100 and the max between 25 and 75. That would still technically allow weird shapes but would set a reasonable constraint).
constraints idea:
when the graph values are updated, check the constraints and if one fails reject the graph value update
comma-separated (or line separated, or individual boxes - easier error reporting, although could highlight text?)
eval-based - downside doesn't provide approximations or corrections (as easily?)
Generic ticket for the graph constraints - will need to be broken up into smaller tickets/stories before being actioned.
Note:
constraints idea:
e.g.
tool to generate constraints based on presets/common constraints (e.g. increasing, strictly increasing, etc.)