please change logarithmic scaling to linear scaling

[iphotostuff]

First, please excuse my tone if it comes off poorly. I've been told by developers I work closely with that I sound cold when making change requests or bug submissions until they get to know me better. Then it's all unicorns and rainbows.

I'd like NS to change the visual representation of BG levels from the current logarithmic scaling to a flat linear scale.

Justification:

1. The current scaling distorts the critical impact lows and highs are having on a user's health. By making the scaling logarithmic the height of the highs and the depth of the lows look less significant than they actually are relative to the "in range" amount of 80-180

2. Once the BG is plotted above the 180 mark and below the 80 mark the velocity of the climb or decline is slowed. Again, this misrepresents the actually behavior of the data. If the data is not changing but the presentation of the data changes the user is being given conflicting information about what exactly is happening with BG levels. The pattern of what is happening with BG levels should be transparent and easy to read and switching scaling interferes with this

3. Logarithmic scaling makes predicting the evening off of highs/lows as well as arc projections more difficult. Since the scaling is heavily skewed towards "in range" levels, the levels that we pay attention to most when they are out of range have been allocated with far less space. This minimized space make it more difficult to see any change in trajectory when highs or lows are evening off and where they are headed next.

Ultimately I think that linear scaling for BG levels is a more transparent and user friendly form of scaling when a user is trying to make medical decisions and predict the trajectory of BG levels for treatment. Even if our "in range" numbers are jut a sliver of the total range someone with T1 may have throughout a week or even in a given day, it does not mean that the scaling should be changed to emphasize the in range numbers only.

Thoughts?

[francescaneri]

@iphotostuff Hi, you tried using Wip / IOB - COB ?

[francescaneri]

http://www.nightscout.info/wiki/labs/the-nightscout-iob-cob-website

[YYGIRL]

Note that @iphotostuff https://github.com/iphotostuff is a professional
user experience designer, and does this for a living. I think he has a
point on showing better trends in the highs and lows areas, and it can be
misleading especially in the middle of the night. The dexcom itself is
shown in a linear fashion. I also realize there is limited space, but there
does seem to be some extra area we could use at the top and the bottom to
show more graph.

I have used iob-cob, and it displays the graph the same way as dreamsicle
and all other websites.

On Mon, Mar 16, 2015 at 8:02 AM, Matteo Neri [email protected]
wrote:

http://www.nightscout.info/wiki/labs/the-nightscout-iob-cob-website

—
Reply to this email directly or view it on GitHub
#487 (comment)
.

Join the Jack Attack!
Fight Type 1 Diabetes
_Give to the JDRF - _www.jdrf.org http://www.jdrf.org

[francescaneri]

master

wip/iob-cob

[scottleibrand]

I'm not fundamentally opposed to providing an option for linear display
instead of logarithmic, especially if we make the min and max adaptive
instead of fixed.

But your #1 and #2 justifications (and to some extent #3), I believe you
are incorrectly conflating the effect of the logarithmic scale on lows vs.
highs. The logarithmic scale does indeed "compress" highs. However, it
actually "expands" lows to magnify the effect of small changes on the low
end. I think that is generally a good thing, as lows are more
time-critical than highs, so it makes sense to have more visibility into
whether things are flatting out, going back up, or continuing down when BG

60 than when BG > 180.

Remember, logarithmic scaling makes it do a given percentage change always
is represented by the same amount of vertical space, rather than holding
constant the relationship between absolute units and vertical space, as
linear does. There is a good argument to be made that % changes are what
matters for clinical decision-making, not absolute units.

-Scott

On Mon, Mar 16, 2015 at 4:47 AM, Alastair Halliday <[email protected]

wrote:

First, please excuse my tone if it comes off poorly. I've been told by
developers I work closely with that I sound cold when making change
requests or bug submissions until they get to know me better. Then it's all
unicorns and rainbows.

I'd like NS to change the visual representation of BG levels from the
current logarithmic scaling to a flat linear scale.

Justification:

1. The current scaling distorts the critical impact lows and highs are
   having on a user's health. By making the scaling logarithmic the height of
   the highs and the depth of the lows look less significant than they
   actually are relative to the "in range" amount of 80-180

2. Once the BG is plotted above the 180 mark and below the 80 mark the
   velocity of the climb or decline is slowed. Again, this misrepresents the
   actually behavior of the data. If the data is not changing but the
   presentation of the data changes the user is being given conflicting
   information about what exactly is happening with BG levels. The pattern of
   what is happening with BG levels should be transparent and easy to read and
   switching scaling interferes with this

3. Logarithmic scaling makes predicting the evening off of highs/lows as
   well as arc projections more difficult. Since the scaling is heavily skewed
   towards "in range" levels, the levels that we pay attention to most when
   they are out of range have been allocated with far less space. This
   minimized space make it more difficult to see any change in trajectory when
   highs or lows are evening off and where they are headed next.

Ultimately I think that linear scaling for BG levels is a more transparent
and user friendly form of scaling when a user is trying to make medical
decisions and predict the trajectory of BG levels for treatment. Even if
our "in range" numbers are jut a sliver of the total range someone with T1
may have throughout a week or even in a given day, it does not mean that
the scaling should be changed to emphasize the in range numbers only.

Thoughts?

—
Reply to this email directly or view it on GitHub
#487.

[iphotostuff]

@scottleibrand Thanks for pointing out the difference between how the lows and highs are being displayed. I agree with you that having more space to view lows is helpful. I think there's a place for that by tweaking the UI (trying to tackle one issue at a time). But I don't agree that the value added of having more space to view lows is greater than a user's ability to clearly see trends in velocity at a glance across the entire spectrum of their BG levels. This is especially difficult when we can adjust what our "in range" numbers are. I do not think that this is a case when "zooming into data" reveals more information. Like dexcom's display of data it's often by zooming out and standardizing the spaces between the BG points that we get a better picture of the trends in BG.

[jimsiff]

What about handling BG scale similar to custom alarms? Set BG_SCALE to linear to get a linear scale. The implicit default could remain logarithmic.

[iphotostuff]

@jimsiff , Yes, I think that would be a good solution. At least having it available to people would make a big difference.

[scottleibrand]

I would support this approach.

Alistair, are you willing to take a stab at making this work on your own
fork? If so, you can make sure you're up to date with the dev branch, make
your changes, push them up to your own fork on GitHub, and then submit a
pull request to start detailed discussion and review of the code changes.

-Scott

On Tue, Mar 17, 2015 at 3:40 AM, Alastair Halliday <[email protected]

wrote:

@jimsiff https://github.com/jimsiff , Yes, I think that would be a good
solution. At least having it available to people would make a big
difference.

—
Reply to this email directly or view it on GitHub
#487 (comment)
.

[iphotostuff]

@scottleibrand , I am willing but not able! I'd like to see it done but am afraid that I am not a capable developer so am unable to make the changes myself.

[scottleibrand]

Well, you don't have to be all that capable to get started, but I
understand if you don't want to start with something this big. :-)

On Tue, Mar 17, 2015 at 1:00 PM, Alastair Halliday <[email protected]

wrote:

@scottleibrand https://github.com/scottleibrand , I am willing but not
able! I'd like to see it done but am afraid that I am not a capable
developer so am unable to make the changes myself.

—
Reply to this email directly or view it on GitHub
#487 (comment)
.

[iphotostuff]

@scottleibrand , I've tried my hand at development before. And while I love exercising that side of my brain and the creativity there is in problem solving that way, I've come to grow in appreciation for those that both love it and are talented at it. Very deep appreciation. I find that if I focus on my skill set and partner with people that are extremely good at theirs, that's the most efficient path and overall produces the best product. With that said, I promise, you don't want me touching this code! :)

[bewest]

It seems reasonable to simply add an option somewhere to make it linear on request.

There is another suggestion that has been proposed that may come in handy for the use cases and sentiments described. The proposal I heard was to allow custom range for the y-axis. Eg, just set the thing to 40 - 280, instead of all the way to 400, this would maximize the space. It would also be possible to combine this with the horizons chart technique:

Another option to think about is simply re-centering, or even choosing different tick labels?

In terms of UI design, it might be good to spend effort on making data entry easier, perhaps using pie menus or something?

• http://onedrop.today/

http://bustavo.com/simpancreas-fuzzy-logic-based-controller/ has a nice intro on "glucose acceleration:"
Some researchers have congratulated us on using log scale without making any bones about it; to my eye the linear display looks stilted somehow, but to each their own.

I think the right way to go about this would be for someone to rip out the display code as it's own standalone library in it's own repo, and for nightscout to simply include it as a bower dependency.

It would also be good to look at AGP, ambulatory glucose profile

• http://abbottnextfrontier.com/agp for a demo

AGP is now an industry standard, one of the original authors and designers of AGP also strongly recommends use of log scale to us.

[francescaneri]

@bewest @scottleibrand Hi, the ability to set their own thing to 40-280 , seems like a nice option and expand it up to 500 according to the need.
regarding AGP would be nice to turn it into nightscout cgm utility.
OneDrop can be a solution for an application of apple watch (practical and functional)

[iphotostuff]

@bwest ability to change y axis limits would be great. I was just trying to limit scope with my request. I mean, ultimately I think the ability to flick through a number of different ways to look at the data would be great. each different way can offer a different type of insight. for me, quick analysis is linear. I have some other ideas about comparing charts day to day to recognize patterns easily, but Ive trying to finish up a number of projects
to get there

[bewest]

Yeah, that makes sense, @iphotostuff. Thanks for touching base on some future stuff.

In terms of keeping small, tight, scope, if there is a "toggle control" of some kind somewhere to flip between linear and log, where might it go and what should it look like?

[iphotostuff]

@bewest Radio buttons in the settings area seems like a natural place doesn't it? I'm not completely sure on what logic you have all come up with with what gets set as a pref in the app compared to a custom setting within azure, but I would think radio buttons in settings would be logical no? Maybe there's an option for tweaking that panel down the road too.

y-axis scaling:
() linear
() logarithmic

[oskarpearson]

I'm closing this, since it appears to have been implemented, but the issue not closed.

Just for future reference, in 0.9.3-dev-20161212b at least:

• There is a dropdown in the user interface. In settings, select 'Scale' and choose from Logarithmic, Linear, and Logarithmic (Dynamic).
• In the reporting interface there's a toggle to change graphs from Linear to Logarithmic

If there are any problems, please re-open the ticket. Thanks!