hello,
to be consistent with the exchange with @pierre-gilles during the 4.12.1 release post,
regarding the display of data in the charts:
furthermore, on the 7-day, 1-month etc. data I notice that where we should have the day’s max data (or summed?) we display a smoothed (or averaged) value (ex: on 8/11 I had more than 20 mm of rain, and the chart on that date shows 12.96 mm! not what’s expected!)
a small addition to remind of this request!
rather than averaged, for data >24h we should have Min/Max or summed values; averaging smooths the data (it’s good for statistics or other analyses…) instead of showing the real values which are expected for this type of data!
this need may not be relevant in all cases (maybe?) but for measurement-type data (weather, heating temperature…) it seems most appropriate.
I also suggest that a development or dev change be made in this direction
As mentioned in the post, the Graph widget currently uses an average function by default when the number of data points exceeds the display capacity (currently limited to 300 points per chart).
For example, if you display a month of rainfall with 10 measurements per hour, that’s 7200 values… which are then averaged into only 300 points. That’s clearly not optimal for all types of data!
To address this need, I’m proposing an update to the widget with a new parameter
Warning: this PR is not production-compatible, because it modifies the database, so I don’t recommend running this image on your production environment.
Since editing the widget was getting a bit long for charts, I also added a button to hide advanced options by default. The user can then expand them only if they need to:
I think it’s great, and I admit that I hadn’t suggested that kind of thing because I know that in Gladys’s philosophy we avoid too many options so as not to turn it into an overcomplicated mess.
When I criticize excessive configurability, it’s not this kind of setting that I’m questioning!
What I question is a common tendency among many developers: as soon as a design choice appears, they prefer to externalize it as a parameter, rather than fully own it. Out of caution, or sometimes from a lack of conviction, they thus delegate to the user a decision that should fall under design.
I take a different approach, inspired by the design philosophy of companies/projects like Apple, WordPress or Elementary OS: projects that make strong, coherent choices and aim to offer a clear, deliberate experience, rather than burdening the user with options.
That doesn’t mean being opposed to functional richness — quite the opposite
Warning: this PR is not production-compatible, because it modifies the database, so I don’t recommend running this image on your production environment.
A little bonus for this new feature
(group by day + « sum » function)
I think I had grasped the essence, but it’s always useful to read it again!