MMOL/L: Graph displays same BG different distances from x-axis

[g5WS]

This is a UI bug that contributes to confusion interpreting data.

In the images below, we see four separate readings of 4.1, but one of the readings is a different height from the others.

Please [graph the MMOL/L reading], and [not plot the mg/dl reading then draw a mmol/L y-axis].

[paulplant]

Is this really an issue that could confuse users? It would have been like this for the last 6 years since the project started and nobody has ever gotten confused before?

All graphs and basically all calculations and data is mesaured in mg/dL. This is common for ALL apps manipulating CGM data. Remember that your sensor doesn't read in mmol/L at all. The actual values are either reported as raw values or directly as mg/dL values (depending on the transmitter type).

The only thing is that the values are reported on the y-axis in mmol/L if needed. There is no real need to actually draw the graph in mmol/L.

This is clearly just a rounding issue. I wonder if you can switch to mg/dL and show the values from this time (using the BG Reading view from the homescreen).

[g5WS]

The question is: should the displayed data and the graph match?

I would say yes.

Rounding has caused issues before with this app, yes: #118 . Seems like Johan chose to fix it.

When user expectations are not met, especially regarding data accuracy, it can cause a loss of confidence in the software.

A user who sees four 4.1 readings in a row expects the graph to be flat for those four readings.

[jonisaksson]

When user expectations are not met, especially regarding data accuracy, it can cause a loss of confidence in the software.
A user who sees four 4.1 readings in a row expects the graph to be flat for those four readings.

Really!? I really struggle to see how anyone would loose confidence in the software due to that one of readings is displayed ever so slightly lower than the other 3 in a graph. But then again, I am equally surprise anyone actually pays that much attention to the graph that they even notice the difference. I would assume that the 4.1 is rounded but where the dot ends up is in the exact position, hence you will see slight variation..

[paulplant]

This is clearly just a rounding issue. I wonder if you can switch to mg/dL and show the values from this time (using the BG Reading view from the homescreen).

Can you do this?

[g5WS]

This is clearly just a rounding issue. I wonder if you can switch to mg/dL and show the values from this time (using the BG Reading view from the homescreen).

Can you do this?

Yes. It’s a rounding issue. I flipped to mg/dl and confirmed it.

Most users do not reflect on possible rounding issues and the technical details of which unit of measure the system records data in.

Paul and Joni, you have both responded with some sceptical comments. I think the important question here is: should the graph match the data?

I don’t think anyone would intentionally design a system where the graph and the data didn’t match. This seems like a bug.

[paulplant]

Sorry, when I asked if you could do it, I meant to ask for a screenshot of the values.

I think we're responding with sceptical comments to just define if it makes sense to define this as an issue and even bother fixing this and if so, what sort of priority should be given.

I don't think we're arguing whether it is a "bug" - clearly it would be expected that the values match the graph but as nobody has ever worried about this before, it's just a question of thinking if it makes sense to worry about it enough to fix it.

I've got an idea to do something that doesn't involve too much work. Let me have a think about it.

[paulplant]

I've had play with this and have written a new function to store the mmol/L chartpoints with a special rounding function that forces when two mg/dL values can have the same rounded mmol/mL value to plot always the same value and therefore avoid this issue.

The basic idea:

This means that the below chart in mg/dL:

Would be rendered/plotted with discrete mmol/L "steps" as shown below:

If I'm honest, I don't really like it that much. The "blocky" jumps make it look like sensor error, rather than just a nice smooth curve as we've always had, but it would avoid what @g5WS claims makes the chart look confusing to users.

Opinions?

[g5WS]

The "blocky" jumps make it look like sensor error, rather than just a nice smooth curve as we've always had, but it would avoid what @g5WS claims makes the app look incoherent to users.

Incoherent? That’s some strong language that I never used.

I appreciate your attention and energy on this issue, Paul.

[paulplant]

You're right, I was paraphrasing from memory.

I'll change it to "confusing to users". I wasn't trying to use strong words, just trying to convey the issue you were describing.

[jonisaksson]

I dont have strong feelings either way. My initial reaction, surely no one pays that much attention to the graph that it is is an issue that the graph displays the true value from the sensor but the number displayed is rounded for convenience (as noone would want to see the 5 decimal number). But clearly some people do, I guess it depends on how people use the graph. Personally i use the graph to see directionally where my blood sugar is going, so the last 2 readings might be more or less static but overall it is rising/sinking so i will make adjustments accordingly.....
So I guess do we want a smoother graph that shows the actual values recorded from the sensor or do we want a graph that shows rounded values that better represent the value displayed .... Personally i would lean towards keeping the true values for the graph rather than trying to round them but seems like such a small issue to worry about I cant get excited either way