Y-axis scaling can lead to confusing views

[christian-rummey]

Hi - I just posted this in the xDrip FB group, and someone asked me to replicate it here:

The y-axis (BG value) currently is auto-scaled to the highest level within the last 24h - see an example on the screenshot (there was a 20+high the afternoon before). This makes sense during the high, and maybe few hours thereafter, for high insulin loads, or similar issues after the high.

But one day later, the curve can give confusing impressions. As we all know, the slope is actually more important than the actual value, and if the y-axis is scaled up to very high values, really steep slopes (eg, +/- 1.5 or more) apper much flatter than they are.

My suggestion is to let the y-axis scale to a normal range by default (e.g, 0-12 or so?), and only scale it up if higher values are visible on screen. Or at least let the user decide how he wants to scaling to work.

hope that makes sense?
thanks

• Christian

[Navid200]

@jamorham @tzachi-dar

This comes up a lot.
Was there ever a thought to change it?

I can think of setting the last 6 hours to determine the max of the vertical axis instead of the past 24 hours.
In that case, if the user scrolls back, they could see a screen with no dots on it. I can think of seeing a pointing up arrow in that case.
And the user will always be able to use "History" to see the entire 24 hours with the real max vertical axis.

Would there be an objection to such a PR?

[tzachi-dar]

Well, from the UI perspective I absolutely agree.
We need to check if doing this is possible (using our UI library). In other words, we need to make sure if we can give different values for the real time values and to the history. Assuming that we can, you need to understand what to show when scrolling is going on.
If you can make it, I'll be very happy.

[jamorham]

If there are items beyond the max Y scale can you pan the screen down to see them? I think that would be ideal in that situation.

[Navid200]

And in that case, what should happen if after, we scroll back and now there will be readings below the min because we have panned down?

Do you think someone may be confused if they accidentally scroll the screen and when look at the screen see no points?
That's my concern too.

Can you think of any other solution?

What I have suggested is what I think is simple enough for me myself to implement. But, I can think of only one thing I am not happy about in that solution, and that is the possibility of confusion as you have pointed out.

[Navid200]

How about a work-around?
I have converted this PR to draft because of xDrip updates having made it have conflicts. #2081

I can clean it up and add an option of 6-hour span.
If/when someone gets a reading that is very high, they can change the setting to cover only 6 hours. Then, they only have to wait 6 hours for the vertical axis to go back to normal.
After 24 hours, they can change the span back to the 24-hour default if they like.

[christian-rummey]

Thanks everyone for commenting and even work on this so quickly!

Thinking about this again, my personal favourite would even be much less than 6 hours. I don't need the past high values to interfere with my current window of managing values, i.e. y-scaling could go back to normal once values are back.

But I appreciate your efforts a lot, thanks so much again!

[Lupum1001]

Out of curiosity @christian-rummey, what were your motivations for turning off that timeline preview across the bottom? That's usually the first place my eyes go when I'm trying to get my bearings regarding scale. In your scenario for example, that peak up to 20mmol/l would always be visible on screen.

One idea did occur to me, and I'm curious to see if it would be any good... If the goal is having a consistent/recognizable sense of slope, we can potentially scale the initial width of that sliding window when there are really high numbers compressing the Y axis. As long as you match what you do to both axes, the slopes won't flatten or stretch between sessions.

• The Y axis would still set itself to the maximum in its 24 hr window
• the user can still only pinch and scroll along the X axis once the chart is loaded, just like now.
• if the chart needs to be twice as tall as usual, the chart would initially load with a horizontal window that was equally zoomed out compared to how the user last set it.

I suspect that time-consistency is probably more important than slope, but as long as the 24hr timeline is visible in both cases, I honestly don't know. Visually it'd be like zooming out

Another idea is to improve the visibility of vertical cues, so it's easier to see how compressed it is at any given time. I noticed the "High Blood Sugar" line in the screenshot kind of blends into the background. 🤔

[christian-rummey]

I think it's really a matter of personal preference. The data scientist in me likes the 24h window as well, but then there's the T1D-person that during normal day-to-day use wants to spend as little time on the screen as possible. How often do we look, 20-30 times a day?

Then the only things that matter are insulin on board, current slope and prediction. That's it. I guess that's why I want this screen to look as familiar and similar as possible (all the time).

ps.
remind me where to switch on the 24h overview?
(can't find it :-) )

[Navid200]

Long press the xDrip icon. That will bring up the home shelf. One of the options is to show the chart preview, which is one of the first things I disable because I personally hate it as it takes so much space and doesn't show me anything I need to see all the time.

[jakobheyman]

In a modified version of xDrip, I have made the min and max value of the main graph Y-axis adjustable in the preferences and then let the main graph move up when the glucose goes higher than the max value (both the min and max then moves up in order to keep the Y range constant). The main graph then moves down again when the glucose goes down, keeping the glucose of the last one hour in the main graph. That way, the difference between the min and max Y axis value is always the same (except if zooming) and the impression of the glucose level slope stays the same also when the glucose is or has recently been very high. The Y axis in the preview graph at the bottom expands if having glucose higher than the max value (or lower than the min value) but not in the main graph. If not using the preview graph, I can still pan (or zoom out) to see prior values higher than the max value.

I believe the main part of the changes to the code related to this is here (there is also some change related to landscape/portrait view): https://github.com/jakobheyman/xdripJH/blob/3fa86a22af791b221be4a651b96315030e0de1f9/app/src/main/java/com/eveningoutpost/dexdrip/UtilityModels/BgGraphBuilder.java#L2165-L2219

If there would be a wish for it, I could try to make a PR for something like this (although I have done no other java work than my modifications to xDrip). One would then first need to decide on issues such as:

• Should the min and max Y values be preferences or rather just set to something lower than the present min/max?
• Should the main graph move up when the glucose moves higher than the max Y value or should the min and max always be kept the same? (this could perhaps be controlled by yet another preference)

[jakobheyman]

I see the point in not adding more settings and the potential problem with a panned screen. A less radical change could be to just let the main graph go back to the default min and max Y-axis values based on the glucose values in the displayed time span instead of 24 hours. This would shorten the duration of an extended Y-axis range in the main graph, and to see glucose values higher than the main graph max value within the prior 24 hours one could pan the screen.

[christian-rummey]

I second that last statement.

But I think the discussion about "too many options" really is quite futile. It's a matter of choice.

No one is forced to move away from default options and I am sure everyone has a specific option or preference where she/he would prefer to have the choice.

[Navid200]

Too much of nothing is a good thing. Everything needs to have a balance. There are currently too many settings in xDrip. Many of them are not needed any longer and should be removed. Instead, we keep adding more.
We should only add a new setting only if absolutely necessary.

How would you like driving a car with 10,000 switches on the dashboard? Do you think that is good because it gives you options?

[christian-rummey]

I have experience with "removing options" and features (different context), and I am probably not aware of most things xDrip has to offer. So it's not on me to tell you guys how to figure that out.

I am convinced though that this option here makes a lot of sense and calling something useful for people "too much of nothing" is just not appropriate

I also don't mind 1000 switches under the hood, as slong as default options work well.

[Navid200]

I'm perfectly fine to use it with many options myself. But, there are children who go to school with xDrip on their phone.
Children don't know all the settings.
I cannot change xDrip only thinking of myself. Neither should anyone else.

I am working on this to address it. I wouldn't if I didn't think it was important.

[Lupum1001]

if the y-axis is scaled up to very high values, really steep slopes (eg, +/- 1.5 or more) appear much flatter than they are.

Can we try to collectively put our finger on what drives perceptions of what the "real" slope is at any given time?
What then makes a slope look "too shallow" to us?

• is it that the slopes look safe, when we should actually be worried about them?
• is it that the height of a peak doesn't draw our attention because it looks shorter than we're expecting?

Even now, when we only have control over the x-axis, we can stretch/squeeze any curve to look arbitrarily shallow or steep. If inconsistent "steepness" is what's causing confusion, Y-axis adjustments would add more of the same problem, wouldn't they?
Here's another example of "flattened" data at 4 different levels of x-axis zoom:

I'm not actually convinced that the Y axis would be the key to improving the clarity there. I feel like there's something else we could do.

[Navid200]

But, the x axis is automatically reset as soon as you minimize and reopen xDrip. Even if you don't, I believe after a while the x axis is reset.

There are individuals who open xDrip occasionally to ensure that everything is alright and minimize it right away. A glance is enough to give you everything you need. However, what this discussion has correctly highlighted is a problem that could occur if such a person does not pay enough attention. I can provide a scenario for that:

A child is with one parent when he experiences a very high reading. It is treated and the readings come back down to in range.
In 8 hours, the child is picked up by the other parent. Looking at the readings now, the second parent sees the reading being in range but does not realize that the y axis max is much higher than it usually is. So, he gets a wrong sense of how fast the readings are changing.

[Lupum1001]

I confess that I didn't actually notice how readily the x axis resets. It seems to load with DEFAULT_CHART_HOURS = 2.5f each time.

That tells me that our perception of good/bad slopes relies entirely on past experience. We aren't even registering the axes, we're just recognizing shapes.

In theory, this means that the opposite problem exists, where a peak up to 360mg/dL (20mmol/L) has the same shape as a 220mg/dL (12.2mmol/L) peak due to the scale change. I'm pretty sure I've overlooked curves like this. For example, when I forget to bolus for a meal, and AndroidAPS quietly drags it back down later.

That part wouldn't be fixed by a dynamically expanding Y-axis unfortunately. 😟

[Navid200]

If you use Dexcom app, I believe the y axis max will always be very high even if your readings never go high.
xDrip has a dynamic y axis. This is a good thing for xDrip in my opinion. But, there is a minor side-effect that this discussions is about.

In my opinion if xDrip uses the readings from the past 4 hours to decide what the y max should be instead of the past 24 hours (what it does currently), we will have addressed the concern to a significant degree.

[jonprogers]

@Navid200 I agree totally, the way the dexcom app doesn't auto scale doesn't allow me to get the info I need and is a major factor in my choice of xDrip as my management tool of choice.

[Navid200]

@christian-rummey

Would you please open an issue, as a feature request?

Thanks

[christian-rummey]

Sorry, can you instruct?
I didn't know I had to anything else.

[Navid200]

I can convert this discussion into an issue. But, I think it will then be as if it's my issue.
Please go here: https://github.com/NightscoutFoundation/xDrip/issues
At the top, tap on "New issue".
Click on the "Feature request" button.
Explain the request as you have here already. If you like, you can copy from here and paste there.
Please make sure to include a link to this discussion in the post.

[Navid200]

It's up to you. Please let me know if you are OK with that and I will convert this to an issue.
It will contain your first post and a link to this discussion and note that you originally suggested the issue.

Or, you can go ahead and open an issue.

[christian-rummey]

Apologies, I am travelling and not online a lot.
Totally fine if you convert it, please go ahead and let me know if I can do anything else.
Thanks!

[ANDREAPIPPI]

Hi.
I am writing this here because it's an Y-axis problem, or simply a misunderstanding.
As you can see in the image,

on the left is a mix of today's and yesterday's curves, showing the ugly enormous scale on the left.
As far as I can see here, the only cause of this could possibly be the forecast curve, which started yesterday at about 23:20 (11:20 PM), midway between the old sensor ending at 22:50 and the new sensor starting at 23:50.
Is this what it is supposed should do?
If yes, I don't understand the reason why, can someone please explain?
I'm using 2023-02-11 Nightly.
Thank you very much.

Andrea

[Navid200]

@ANDREAPIPPI You could have opened a new thread.
Please do that if you have more questions. This thread is about how long the modified range lasts. It's not about why the range gets modified.

This image shows why your axis has got modified. It's because of these readings I have circled.

Please open a new thread if you have any questions to avoid derailing this discussion.
Thanks for your understanding and help.

[ANDREAPIPPI]

OK Navid, thank you. I added this to the previous discussion just to avoid increasing the number of threads ... Andrea

On Mon, 06 Mar 2023 12:04:44 -0800 Navid ***@***.***> wrote: @ANDREAPIPPI You could have opened a new thread. Please do that if you have more questions. This thread is about how long the modified range lasts. It's not about why the range gets modified. This image shows why your axis has got modified. It's because of these readings I have circled.  Please open a new thread if you have any questions to avoid derailing this discussion. Thanks for your understanding and help. -- Reply to this email directly or view it on GitHub: #2144 (reply in thread) You are receiving this because you were mentioned. Message ID: ***@***.***>

Andrea Pelloni

[allanlaal]

Bug: Y min graph range value is ignored
Expected: graph bottom starts at Y min value

Even though there are no readings ever below 3.3 in my case:

[Navid200]

You have enabled G6 prediction, under xDrip display settings −> graph settings.

As a result, you have data points less than 2 at 12:45, 12:50, 12:55 and 13. Those are the reason for your min axis being less than what you have chosen.