OpenEMS
UI: dashboard energy monitor: gauge diagram does not match textual values
Description
Dashboard energy monitor widget: There is a mismatch between the bars within the gauge diagram and the textual values. See below screenshot, there the bars of the gauge show approx. following fractions:
- 1/3 from gird
- 2/3 from pv inverters
- 3/3 consumption Looking at the textual values, there is a total different split, approx.:
- 4/5 from grid
- 1/5 from pv inverters
- 5/5 consumption Looking at the clouds outside, the textual values seem to be correct, and the diagram seems to be wrong. The arrows seem to follow the textual values.
Screenshots
Operating System
Edge/UI: docker; Client: Linux, Firefox
How to reproduce the Error?
Install Edge, UI, add some pv inverters and a grid meter.
The bars in the gauge are not based on the current power distribution but on the maximum values ever recorded for each source. So they do not represent the actual live ratio between grid, PV, and consumption. Instead, they show how the current values compare to their respective historical maximums. That’s why the textual values and arrows (which reflect the real-time power flow) can differ significantly from the bar lengths, which are only scaled to the peak values seen so far.
@da-Kai am I right here? So i do not see this as an "Issue"
@Sn0w3y you are correct. So its not a functional issue but maybe a UX flaw.
We could probably clarify this behavior in the UI or add a tooltip.
Thanks for your comments and eagerness to improve the situation. I'm tempted to respond with
What's the commonality between a joke and a UI? -- If you have to explain it, it's not good.
IMHO #3392 is a hot-fix, that improves the situation, but probably not the best solution. Not knowing what is possible, I would suggest to conduct user testing to find out if I'm the only person miss-reading the diagram, and if not, redesign the visualization. Tbh, I don't have a better design off the top of my head, ideally a UX designer with a graphical background would be involved.
ideally a UX designer with a graphical background would be involved.
- you mean the Graphical Designers which already Designes the one how it is right now? I guess the Energy Monitor is one of the Core Components which has the same exact Style and Functionality since OpenEMSes Start. Changing it seems not to be a solution in mz Opinion.
you mean the Graphical Designers which already Designes the one how it is right now?
I just meant what I wrote: a UX designer with a graphical background. I have no idea if a graphical designer or a developer designed the current visualization. If a graphical designer did it, they may be involved again (if still available). But as I wrote, this would be the second step I suggest. The first step would be conducting a user test. And then maybe refine the requirements. Having these results at hand, IMHO it really doesn't matter if the redesigning designer was involved in the design before or not.
I guess the Energy Monitor is one of the Core Components which has the same exact Style and Functionality since OpenEMSes Start. Changing it seems not to be a solution in mz Opinion.
Well, in general, I'm not too much inclined to follow a "we have always done it like this"-argument, if it just used to stop a sensible discussion. :) It would obviously be sensible to understand the design rationale of that time and if it is still valid (which I assume), ensure that it is taken into account for a redesign. Additionally there is indeed with every redesign a performance/usability dip, until people have relearned and reach the former level, and then finally arrive at a higher usability level. It's IMHO a valid aspect to calculate this in and then decide if its worth to accept the temporary dip. But without having a validated alternative design, the calculation is IMHO pretty hard.
you mean the Graphical Designers which already Designes the one how it is right now?
I just meant what I wrote: a UX designer with a graphical background. I have no idea if a graphical designer or a developer designed the current visualization. If a graphical designer did it, they may be involved again (if still available). But as I wrote, this would be the second step I suggest. The first step would be conducting a user test. And then maybe refine the requirements. Having these results at hand, IMHO it really doesn't matter if the redesigning designer was involved in the design before or not.
I guess the Energy Monitor is one of the Core Components which has the same exact Style and Functionality since OpenEMSes Start. Changing it seems not to be a solution in mz Opinion.
Well, in general, I'm not too much inclined to follow a "we have always done it like this"-argument, if it just used to stop a sensible discussion. :) It would obviously be sensible to understand the design rationale of that time and if it is still valid (which I assume), ensure that it is taken into account for a redesign. Additionally there is indeed with every redesign a performance/usability dip, until people have relearned and reach the former level, and then finally arrive at a higher usability level. It's IMHO a valid aspect to calculate this in and then decide if its worth to accept the temporary dip. But without having a validated alternative design, the calculation is IMHO pretty hard.
You are invited to provide a PR with your suggested Changes aswell :)
You are invited to provide a PR with your suggested Changes aswell :)
I know. Please reread my comments:
- I don't have a better design at hand
- I suggest to do user testing and clarification of requirements first and additionally, I'm not a graphical designer myself. In case I can attend next hackathon, I can offer to facilitate a workshop about user testing.
@HaSp97: A UI/UX designer is required here. :-) I think this is actually an interesting perspective and valuable discussion.
Just want to add two common situations:
- a large warehouse with a 300 kWp PV and only 30 kw grid power.
- a manufacturing company with high electricity consumption with 100 kWp PV and 750kW grid power.
The exiting implementation works quite well in this cases. Adding this feature makes at least one of the gauge bars almost useless.
Also I like the idea that a full gauge bar represents a max value within the respective area , but I may already be too accustomed to the existing visualisation.
