graph widget thoughts

[mackenza]

Moving from the text widget changes I did, I am going to focus on Graph now. These are some thoughts and I am looking for feedback from the community:

value - is currently calculated in the widget as the last value of the points passed from the job. I think this could be more flexible by allowing the author to decide what value is displayed (like maybe it's a max for the time series, or min, or avg... you get the idea). I propose that I add a data property to be passed from the job like broadcast! %{value: <some#>, points: ...}

add in moreinfo and updated-at to the widget for consistency. With text (and eventually others) widget. The issue here is that the x-axis text is where we normally put these fields. I could put these field underneath the x-axis labels? Or above? Or... thoughts?

title and moreinfo allow to be passed dynamically from the job as we did with text widget.

SCSS needs a little clean up. For instance there is a .more-info class that overrides the one in application.scss whereas the text widget does not override in the widget stylesheet.

That's all I have at the moment.

[zorbash]

We can add a moreinfo field for consistency, but I don't think we should add an updated-at field. If we were to add it, it should be placed at the same bottom position in the widget as everywhere else, but then it'll hide the x-axis. Our core graph widget will most probably be used for quite frequently updated time series data and not displaying the last update time doesn't seem like a problem to me.

Feel free to create a PR with scss clean up changes.

Concerning the value for the graph, I'm still not convinced, I think that the displayed value should follow the graphed points. If the user wishes to apply for example a smoothing function on the points, the last computed point should still be displayed as value.

[mackenza]

for updated-at I think it depends on how often the data is updated. I think there are likely lots of use cases where it's relatively infrequent. This is a dashboard, possibly of the kind that is on a monitor in the lunch room or in the stand up space of your dev team. For that type of application, it's likely not updating so frequently that the time stamp is unimportant. I think if you update a widget any less frequently than, say, every 15 mins, you likely want to know what the time-frame of the data is. I think finding a way to add the updated-at would be useful. I will play with some CSS and see what makes sense maybe.

for the value... I see little downside to allowing the author to specify a value from the job here. If they change it to be, for example, a MAX(), then the addition of the moreinfo would allow them to give the value, and then in moreinfo explain it... like maximum bug count or something like that. It can always default to the last point if the job doesn't supply a state property for it.