display known basal settings in tabular form to compare with current day's basals

[jebeck]

As discussed with @HowardLook and Saleh Adi. As an aid mainly for Diasend users to help identify temp basals and settings changes, we will add an additional (show-and-hide-able) pool to the data display below the basal pool. This pool displays the basal schedules we know about (i.e., from most recent upload) in tabular form aligned with the rates above for comparison.

[jebeck]

Trello card: https://trello.com/c/J0pdJVfi

[jebeck]

Also as a comment, I know exactly what Saleh wants for this, and I suggest I put it together and then submit it to @skrugman for prettification.

[brandonarbiter]

@jebeck It's hard for me (or a new viewer?) to understand what this means without some semblance of an image. Is it something you can sketch out in minimal time just to provide context for the Issue?
Cc: @skrugman @HowardLook

[jebeck]

Will do next week.

[jebeck]

@brandonarbiter Here's my quite rough sketch:

Each basal schedule in your current settings is displayed in a tabular row below the basal data, with the cell size according to the timeline as appropriate. A cell that matches the basal rate that actually happened (as displayed in the basal pool) will have somehow more prominent styling than other cells that do not match, to help understand where the differences between actual basal rates delivered and schedules are. I think we said the tabular rows would be hideable/showable (as a unit, not each row individually).

[skrugman]

Option 1 is @jebeck 's sketch - it allows the comparison of 2 (+?) basal rates in numbers in the one day view and uses numbers directly making the tool tips for basal rates not needed but what if there are 10 different basal patterns? Option 2 allows us to see all patterns when you want to compare in one day view. Option 3 Assumes that the comparison of basal patterns happens in device settings and tool tips are used for viewing exact numbers, which pattern is in effect is shown next to the label for Basal Rates. @HowardLook I think the underlying question is do we want to compare basal's in the one day view or in the device settings, which made me think of the design for the device settings in a graph that we haven't implemented.

[jebeck]

@skrugman I'm pretty sure there aren't any pumps that allow 10 basal patterns. Max with Animas is four, and with Medtronic might be three (someone verify?)

But to clarify the use case here: Saleh came up with this idea as a work-around for being able to determine some information for Animas users that we can't otherwise expose because of the quality of the data. The first thing is finding temp basals and knowing what the scheduled rate was supposed to be. This is displayed in the dotted-line tooltips for other users, but we gave up trying to be clever about the data we have and infer the necessary info to populate tooltips like this:

So Animas users no longer have any dotted lines or any of these.

The second issue is the lack of settings history from Animas pumps. The tabular display will help with that because if you've changed your basal schedule, none of the tabular segments will match up. This is why displaying all the patterns at once was the idea.

[brandonarbiter]

@skrugman , when you say "A/B" test, what did you have in mind? It would be
nice to look at both concepts as high-fidelity designs side by side and
review them together, possibly with Saleh. Or did you mean develop both
scenarios and A/B test them with users?

@jebeck , for a patient that has three of four basal profiles, it seems
like having all the basals displayed would get clunky. Maybe we can find a
way to collapse/expand?

On Fri, May 30, 2014 at 8:09 AM, Jana Beck [email protected] wrote:

@skrugman https://github.com/skrugman I'm pretty sure there aren't any
pumps that allow 10 basal patterns. Max with Animas is four, and with
Medtronic might be three (someone verify?)

But to clarify the use case here: Saleh came up with this idea as a
work-around for being able to determine some information for Animas users
that we can't otherwise expose because of the quality of the data. The
first thing is finding temp basals and knowing what the scheduled rate was
supposed to be. This is displayed in the dotted-line tooltips for other
users, but we gave up trying to be clever about the data we have and infer
the necessary info to populate tooltips like this:
[image: screenshot 2014-05-30 08 02 18]
https://cloud.githubusercontent.com/assets/1588547/3132102/a888f730-e80b-11e3-87c1-aa13b1024a22.png
So Animas users no longer have any dotted lines or any of these.

The second issue is the lack of settings history from Animas pumps. The
tabular display will help with that because if you've changed your basal
schedule, none of the tabular segments will match up. This is why
displaying all the patterns at once was the idea.

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

[skrugman]

@brandonarbiter I want to figure out limitations etc before making high fidelity versions. Think we should talk and review at this point, with Saleh too, not A/B test (take two options, show to users and get feedback).

@jebeck To make sure I understand, the limitations are for the data we are getting from Animas - 1. we don't get the temp basal's distinguished from the set basal's - but we can infer when we compare what actually happened in the basal's vs what we get as the settings. 2. We don't have a history given to us in settings but it shows up in the actual basal's, but you could only tell that if they are compared to the current settings. Is it absolutely not a good idea to infer temp basal's and pattern changes? I can see my temp basal (on Animas pump) in Diasend.

Im resistant to adding the tabs because it breaks the structure for tooltips. Could be a good thing but I want to stay consistent with how we display the data. If we do decide to do tabs, I think showing 4 patterns at once is too much - it will be clunky and if the patterns are not actively used it will be showing lots of extra info. (I suspect that many people don't use patterns).

Ill mock up the expandable tabular view but I still question the need to have tabs.

[jebeck]

@skrugman I don't know what you mean by tabs. Please let's talk about this before either of us goes further.

[skrugman]

@jebeck and i chatted this morning and discussed. A few points discussed 1. This is temporary bandaid because of how bad the data we get from Diasend is. 2. because it breaks the structure of the design for the interaction we have with the data but 3. We are going to do it anyways. 4. It made me remember one sketch of an interface that had the device settings as expandable and collapsable pools in the one day view.The thought behind that was to be able to compare the data with the settings. Im not sure why but we decided to keep the settings all in one page. 5. I will mock this up tomorrow and make sure @jebeck and I are on the same page.