y-axis min/max values should update on scroll #36
Comments
|
Interesting idea. We need to find a strong use case for this. I consider the need to see small variability (which could just as well be sensor noise) less important than potentially confusing users with a dynamically scaling axis. What worries me most about the suggestion is that you would loose the immediate joy that comes from seeing a flat day like this :). With dynamic scaling you'd see peaks and valleys just as with a 'bad' day. Personally, i think something we have to consider. Ideally in a new branch or ever as a hidden setting we can toggle to experiment. I'd like to see what happens if we clip the top range (not lower than 180) when not used but always keep the bottom range fixed. |
|
I would argue that the green color of the line for the whole day gives me the same immediate joy. So, even if I am seeing the peaks and valleys, I still see that my blood sugar has remained within my target range just by looking at the color. I like the idea of limiting the top range to a minimum of 180 and keeping the bottom range fixed. I built a small visualization of my omnipod data a while ago. You can take a look at it here: http://sugarmint.heroku.com/home (creds: [email protected]:123456). When you drag the chart, you'll see the min/max values change. I agree that it is a little confusing for a new user but your ideas will help remove some of the confusion. |
|
We'll bring it up at the design meeting. I like how it works in your visualisation, a demo of it in Tideline will help evaluate its use. Care for a pull request? BTW You might like to see the AGP demo i've been working on http://212.71.251.86:8082. |
|
Hi @virmani! Most of my thoughts echo @ianjorgensen's, and definitely feel free to submit a branch PR on this for us to have a discussion around. FYI, I'm working on fleshing out the README as we speak, so there'll be a bit more guidance on the code and contributing in just a bit. |
|
Hey @jebeck and @ianjorgensen! Frontend is not my strongest suit but I'll try to play around with it as I get some time from my day job. A good README will definitely help. BTW, I was looking for where the source for the APIs serving the patient data was. Is it not on github yet? |
|
@ianjorgensen - I like the AGP demo. I especially like the x-percentile charts for the whole month. As far as daily chart is concerned, I am not a fan of seeing a line of my BGs without any context. I experience this at my endo visit every quarter - she sees a spike or dip in my blood sugar from 3 weeks ago and asks me - "hmm, what happened there? What did you eat?" or "Did you work out right before?". There is no way I can remember what I was doing at a specific time 3 weeks ago in a 15 minute doctor's appointment. The same problem exists outside of the doctor's office at my home too. This is why I strongly believe in displaying my blood sugar data with data from other services. Some time ago, I made a visualization of my omnipod numbers (an enhanced version of the above) and added my foursquare checkins to it. It was helpful as long as I was checking in regularly on foursquare (which did not last very long for me). I think the tideline charts could provide a lot of context if presented with other interesting data from Moves, foursquare, calendar appointments, fitbit, and food-logging services. I have been toying with the idea of looking into Moves apis for this. Let me know what you think about it. |
|
@virmani We in fact have plans to incorporate contextual data from other services, although they aren't on our super immediate road map. If you wanted to get started on one or two of them though, it should be pretty easy once the README is finished. I've looked at what you can get out of the Moves API before, and it's pretty great. As to the README, I am still working on it, sorry! Hopefully it'll be up within the next 24 hours! |
|
@virmani The AGP is a demo, but totally, it should and will include contextual data. First and most important would obviously be pump data, i.e. it'll a part of blip. As @jebeck mentioned we are looking forward to start integrating to external services in the future, i have a ton of Moves data i cant wait to see along my bgs. |
|
Great to hear! I'll play around with tideline and moves when I get a chance. |
|
@virmani Just noticed your question about the source to serve the data. It's open and in tidepool-org/pool-whisperer Unfortunately, all that does is give you a dump of all of the data related to you as it exists in mongo, so there's not much you can do to extract what types of data we are returning and what it looks like. There have been some efforts to document this at varying stages of completion, but @kentquirk is working on finalizing how we document data storage and things of that nature, which I imagine is the type of information you were actually trying to get at. Hope that helps... |
|
There is a longer term plan -- although too much of that plan is still not yet written down. We're very focused on minimum functionality to support our upcoming trial of blip right now -- once that gets settled we'll have some detailed discussions on the longer term data organization for the time-series data. |
|
@jebeck I'm putting this in backlog. If you want to close it out or reprioritize within the labels, go ahead. |
Currently, the y-axis of the blood glucose pool (is that the right term?) has the min and max set as data.min and data.max respectively. But, if I am looking at a day in which the blood glucose numbers are not extreme (see the screenshot below), it is difficult to see the variation of blood sugars.
Expected: The values of min and max on the y-axis change on scroll to the min and max blood sugars in the time period currently displayed in the pool (plus some padding ofcourse).
The text was updated successfully, but these errors were encountered: