One day tideline scroll inconsistent location of time

[cheddar]

When I scroll the one-day view in tideline, sometimes it shows me midnight to midnight. Other times it shows me 3am to 3am. Other times still, it's 6pm to 6pm.

Given that it is a day view and that the thingie at the top tells me which day it is, I expect it to be midnight-to-midnight. This has caused me confusion multiple times when trying to figure out what is going on with basals. The basal tooltips don't have the time included either, so it's really hard to figure out what time I'm actually looking at.

I'd prefer that it always show me the same time range, if we do that, then you cannot see clearly what happened over night, but that I think should be solved by adding a 3-day view (or 2-day view). At a minimum, though, I'd like to have something that will allow me to "snap-to-day" so that I can be confident that it's showing me midnight to midnight.

[jebeck]

@skrugman @HowardLook @brandonarbiter Passing this to you.

The scrolling behavior is, I believe, as designed (namely, the arrow buttons scroll you exactly 24 hours from your current location), and I don't find it confusing myself, but I'm not a good judge of these things anymore.

Also, I believe Jenise commented that she found this confusing as well.

Snap-to-midnight would probably take me a day or so of work, maybe less.

[cheddar]

Here's an exact reconstruction of how I got confused.

I know that a temp happened on March 14th at 3am. I was looking for it in the data, so I arrowed it back to March 14th. I look down at the basals, and oh $|-|!7 it's not there. OMG, what did I screw up in the processing? I worry. But, I just click the arrow some more to see if I screwed up the dates or something, and now it's March 13th. My temp basal shows up, Eureka!

But wait, why does the temp that should happen on the 14th happen on the 13th? I ponder it for a bit, finally look at the legend at the top of the graph and notice that I'm looking at 6am to 6am. So, it says March 13th because that is the "primary" day, but it's actually showing me March 14th. All said and done, I've been scared into thinking I screwed something up, when really I just didn't know what the UI was trying to tell me.

Jana told me in chat that it is done this way so that a user can define what they believe a day is (i.e. 7 to 7 or whatever) and then just look at that over and over again. The current UI doesn't actually allow me to precisely define my "day" (I can click and drag the graph, but have no indication of what time it's actually on). It also doesn't seem to be consistent on a per-user basis, so if you are a doctor looking at 50 patients and each of them have data that ends up with a viewport centered on different times, it's gonna cause confusion for them to try to figure out what they are actually looking at.

[jebeck]

So a note to add to the discussion: the other thing this relates to is showing one vs. two date strings in the top bar. I had two contra Sara's design at one point because I found myself confused in the same way @cheddar is. The compromise @skrugman and I reached was to use one, and it changes over when midnight crosses the centerline of your viewport, so the label always reflects whatever day is taking the majority of your viewport (where majority here is > 50%) and to replace the '12 am' ticks in the horizontal axis with date indicators (e.g., Mar 12).

So, something to think about is that instead of changing the scrolling behavior (by snapping it to midnight or whatever), it may also make sense to rethink the feedback provided in the navigation bar as to what your viewport domain is. Perhaps we can make that more descriptive and precise somehow. (Even just adding the time you're seeing at the left edge would help, I imagine.)

[kentquirk]

Could the label stick to the time of day?

                             Tuesday
    ----------------------------+------------------------|---------
                               noon                     mid

                     Tuesday
    --------------------+------------------------|----------------
                       noon                     mid

     Tuesday                                                 Wedne
    ----+------------------------|--------------------------------
       noon                     mid

    sday                                                Wednesday
    -------------------|--------------------------------------+----
                      mid                                    noon

[cheddar]

Kent, the one on the x-axis at the top sticks to midnight. The label that I actually look at is the one between the arrows.

[brandonarbiter]

weather.com addresses this in a clever way. See attached [or of course you
can type in a city name and navigate to the hourly view. (I recommend you
use a city where it is currently between 7:30 - 9:29pm when you look. :) ]

They do four things that caught my attention and make it pretty easy to see
which day you're looking at:

1. The date is persistently displayed alongside the first timestamp on
   the screen. I think this is the key piece. Having the date appear alongside
   the first timestamp in Blip's x-axis would immediately orient the viewer to
   what he is looking at. (Whereas one of two possible dates included in the
   scroll header people report as confusing.)
2. If there is a midnight event, the new date is also displayed
   alongside that time.
3. To accommodate 1 & 2 above, the date is listed in addition to the
   time. Whereas in Blip, we write the date instead of the time.
4. To be easier on the eye, the date is also differentiated by color:
   the date is gray while the hourly timestamp is black.

I mocked it up in a PDF and provided the sample, attached. I do not applaud
my design skills - this is just to help as you read the above in case
anything is confusing.

Thanks,
Brandon

Brandon Arbiter
VP, Product + Biz Dev
Tidepool http://www.tidepool.org | brandon@tidepool.org
917.536.0505 (m)

On Wed, Apr 16, 2014 at 2:59 PM, cheddar notifications@github.com wrote:

Kent, the on the y-axis at the top sticks to midnight. The label that I
actually look at is the one between the arrows.

Reply to this email directly or view it on GitHubhttps://github.com//issues/88#issuecomment-40657867
.

[jebeck]

@brandonarbiter I don't think you can attach things to GitHub comments. You'll have to send it to us outside of GitHub.

[HowardLook]

You can paste images that are copied to the clipboard. I do it all the time.

Howard Look
President and CEO, Tidepool
howard@tidepool.org
C: 650-823-0021

Tidepool is an open source, not-for-profit effort to build an open data platform and better applications that reduce the burden of Type 1 Diabetes and accelerate the commercialization of closed-loop systems.

On Apr 16, 2014, at 8:59 PM, Jana Beck notifications@github.com wrote:

@brandonarbiter I don't think you can attach things to GitHub comments. You'll have to send it to us outside of GitHub.

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

[brandonarbiter]

[jebeck]

So @brandonarbiter there are already dates instead of 12 am labels... I don't know what old version you created your images from, but it's not what's been in the tideline code for some time now...
For example:

I could try replacing the 12 am and stacking the date on top, and also can try always having a date atop the leftmost tick, but that'll be mighty fiddly, I believe. (The tick labels on axes are one place where D3 really doesn't like to let you access things very easily. Possible, but takes some work.) Definitely I need to hear what priority this is before digging in.

[skrugman]

@jebeck I think the problem comes from the size/spacing. I would say this is a P3.

I would make the .d3-axis text 10px and put the day date above it 11px (in screen shot mock up)
I would also use the day format so it looks like "Friday, Apr 4" or "Fri, Apr 4" if there isn't enough room for the whole day.

[brandonarbiter]

Yes, this design from @skrugman is nearly what I was going for, if I wasn't
clear in my email. Thank you Sara! I'd just suggest we try adding one more
thing: that the date be displayed not only at midnight, but also
(persistently) at the first time label.

So Sara, in the example you just sent out, while above "12 am" it reads
"Friday Apr 4"; additionally, above "6 am" would you try adding "Thursday
Apr 3".

I hope this would address the confusion @cheddar and Jenise report. They
should take a look and let us know their thoughts.

Regarding prioritization, Jana would you offer some indication of time
required and competing tasks?

Thanks,
Brandon

Brandon Arbiter
VP, Product + Biz Dev
Tidepool http://www.tidepool.org | brandon@tidepool.org
917.536.0505 (m)

On Thu, Apr 17, 2014 at 6:03 AM, skrugman notifications@github.com wrote:

@jebeck https://github.com/jebeck I think the problem comes from the
size/spacing. I would say this is a P3.

I would make the .d3-axis text 10px and put the day date above it 11px (in
screen shot mock up)
I would also use the day format so it looks like "Friday, Apr 4" or "Fri,
Apr 4" if there isn't enough room for the whole day.

[image: screen shot 2014-04-17 at 2 58 42 pm]https://cloud.githubusercontent.com/assets/5529057/2731662/71d81b32-c630-11e3-9584-9e2ba692bc5b.png

Reply to this email directly or view it on GitHubhttps://github.com//issues/88#issuecomment-40711214
.

[cheddar]

Speaking of weather-related sites, have you guys ever seen http://www.weatherspark.com?

I'm not sure if it's helpful or not for us, but it's my favorite weather thing. They default to a 2-day view and have a pretty constant mouseover that gives you tons of information.

Regarding the proposal to adjust what's in the x-axis, the problem is that I don't look at the x-axis. Jana pointed this out yesterday, but I apparently did a bad job of explaining that the only thing my eyes are drawn to is the date between the arrows. Adjusting the x-axis might make it easier for me to orient myself after getting disoriented by looking at the date between the arrows, but it's still a 2-step process

1. Get disoriented
2. Fix it

So, in my mind, it's better but is not a resolution.

[brandonarbiter]

Point taken @cheddar , thanks for clarifying. I bet that being more explicit about multiple dates in the x-axis will help. But I also think you're right that having a single date highlighted in the header, while two days of information are being displayed, is a bit confusing.

@skrugman , do you want to take a stab at this? Cheddar's weather link shows a viable method to display multiple days in the header. Screenshot attached.

[cheddar]

It's cold where you are Brandon. Go somewhere better :P

[brandonarbiter]

Arg. #Boston.

Brandon Arbiter
VP, Product + Biz Dev
Tidepool http://www.tidepool.org | brandon@tidepool.org
917.536.0505 (m)

On Thu, Apr 17, 2014 at 9:00 AM, cheddar notifications@github.com wrote:

It's cold where you are Brandon. Go somewhere better :P

Reply to this email directly or view it on GitHubhttps://github.com//issues/88#issuecomment-40730591
.

[jebeck]

@brandonarbiter To answer your timing question, it's really hard to say given the number of ideas flying around. If we really want to explore lots of different possibilities, it feels like a couple to three days effort to me, with rounds of feedback and then trying yet more things, like we did to some extent for the two-week view labels.

I believe that many of the issues around modifying the dates (except for the sticky on the left thing you've suggested) are things that I've more-or-less solved because of two-week view, but I don't want to underestimate how long it could take to get things perfect.

[kentquirk]

Reminder -- on the list of priorities, this is rather low. Although it's
fun to debate, our focus should be on delivering the pilot. I'm also guilty
of fanning the flames. Can we leave this one in Sara's hands and move on to
the stuff that's on the critical path, please?

On Thu, Apr 17, 2014 at 9:28 AM, Jana Beck notifications@github.com wrote:

@brandonarbiter https://github.com/brandonarbiter To answer your timing
question, it's really hard to say given the number of ideas flying around.
If we really want to explore lots of different possibilities, it feels like
a couple to three days effort to me, with rounds of feedback and then
trying yet more things, like we did to some extent for the two-week view
labels.

I believe that many of the issues around modifying the dates (except for
the sticky on the left thing you've suggested) are things that I've
more-or-less solved because of two-week view, but I don't want to
underestimate how long it could take to get things perfect.

Reply to this email directly or view it on GitHubhttps://github.com//issues/88#issuecomment-40733718
.

Kent Quirk
VP of Engineering, Tidepool

Tidepool is an open source, not-for-profit effort to build an open data
platform and better applications to reduce the burden of Type 1 Diabetes.

[brandonarbiter]

I agree. We have a bunch of input for sara to consider. Let's leave this in design for now. Once we have some suggested solutions from sara, we will revisit development timing. Sound good?

Sent from my iPhone

On Apr 17, 2014, at 1:35 PM, Kent Quirk notifications@github.com wrote:

Reminder -- on the list of priorities, this is rather low. Although it's
fun to debate, our focus should be on delivering the pilot. I'm also guilty
of fanning the flames. Can we leave this one in Sara's hands and move on to
the stuff that's on the critical path, please?

On Thu, Apr 17, 2014 at 9:28 AM, Jana Beck notifications@github.com wrote:

@brandonarbiter https://github.com/brandonarbiter To answer your timing
question, it's really hard to say given the number of ideas flying around.
If we really want to explore lots of different possibilities, it feels like
a couple to three days effort to me, with rounds of feedback and then
trying yet more things, like we did to some extent for the two-week view
labels.

I believe that many of the issues around modifying the dates (except for
the sticky on the left thing you've suggested) are things that I've
more-or-less solved because of two-week view, but I don't want to
underestimate how long it could take to get things perfect.

Reply to this email directly or view it on GitHubhttps://github.com//issues/88#issuecomment-40733718
.

Kent Quirk
VP of Engineering, Tidepool

Tidepool is an open source, not-for-profit effort to build an open data
platform and better applications to reduce the burden of Type 1 Diabetes.
—
Reply to this email directly or view it on GitHub.

[jebeck]

Sounds good @brandonarbiter, with one caveat: This is a place where the technical limitations of what is easy and hard in D3 really matters, IMO, so I would like to be involved at an earlier stage in terms of discussing redesign possibilities, not just expected to implement whatever new version @skrugman comes up with, as has been our pattern up to now. Is that fair?

[brandonarbiter]

That is fair and my expectation. My suggestion is simply let's pause active
dialog for now and let Sara work with the input that we've provided in the
last 24(?) hours. Once Sara provides some ideas, we'll jump back in.

I'll just make sure you are in the loop on all email/Git/meeting
communication so you can follow along and jump in when you feel it is
beneficial. I prefer you make that determination rather than me. :)

Brandon Arbiter
VP, Product + Biz Dev
Tidepool http://www.tidepool.org | brandon@tidepool.org
917.536.0505 (m)

On Thu, Apr 17, 2014 at 12:27 PM, Jana Beck notifications@gh.neting.ccwrote:

Sounds good @brandonarbiter https://github.com/brandonarbiter, with one
caveat: This is a place where the technical limitations of what is easy and
hard in D3 really matters, IMO, so I would like to be involved at an
earlier stage in terms of discussing redesign possibilities, not just
expected to implement whatever new version @skrugmanhttps://github.com/skrugmancomes up with, as has been our pattern up to now. Is that fair?

Reply to this email directly or view it on GitHubhttps://github.com//issues/88#issuecomment-40752909
.

[skrugman]

Without changing the overall layout (top bar and date in center top) I think this is the best option for making sure days/dates are clear. I tried a few different things but there's not much wiggle room.

[brandonarbiter]

Just posted a time for early next week to discuss this design. Currently
@skrugman, @jebeck, @brandonarbiter are on the invitation. If someone else
should join, let me know and I'll add them.

Brandon Arbiter
VP, Product + Biz Dev
Tidepool http://www.tidepool.org | brandon@tidepool.org
917.536.0505 (m)

On Fri, Apr 25, 2014 at 4:15 AM, skrugman notifications@github.com wrote:

Without changing the overall layout (top bar and date in center top) I
think this is the best option for making sure days/dates are clear. I tried
a few different things but there's not much wiggle room.

[image: screen shot 2014-04-25 at 1 07 55 pm]https://cloud.githubusercontent.com/assets/5529057/2799963/11426b84-cc6a-11e3-8e9b-564dc6938a20.png

Reply to this email directly or view it on GitHubhttps://github.com//issues/88#issuecomment-41381932
.

[jebeck]

Thanks @brandonarbiter. @skrugman can you provide a little more information on the proposed design? The interaction is not 100% clear to me. Is the proposal that the dates on appear at midnight and move as you scroll? That is, we're not going with any "sticky" labels?

[skrugman]

@jebeck yes, the dates scroll with the timeline. Im not sure what you mean
by sticky labels.

On Fri, Apr 25, 2014 at 6:30 PM, Jana Beck notifications@github.com wrote:

Thanks @brandonarbiter https://github.com/brandonarbiter. @skrugmanhttps://github.com/skrugmancan you provide a little more information on the proposed design? The
interaction is not 100% clear to me. Is the proposal that the dates on
appear at midnight and move as you scroll? That is, we're not going with
any "sticky" labels?

Reply to this email directly or view it on GitHubhttps://github.com//issues/88#issuecomment-41412349
.

[brandonarbiter]

@skrugman - See the example from Weather.com for "sticky labels". (The
example is on GitHub, but I'll also forward it to you in a moment so it's
easy for you to find. :)

In the image, the first hour displayed is 8pm. Under the time label that
reads "8pm", a date label appears, reading "Wed Apr 16". In this example
(the Weather.com hourly forecast), the date always appears with the first
hour that is displayed. The date also appears any time midnight is shown.

When Jana refers to "sticky labels", she's referring to the first idea -
that the first hour displayed always has a corresponding date, regardless
of whether it is midnight.

Brandon Arbiter
VP, Product + Biz Dev
Tidepool http://www.tidepool.org | brandon@tidepool.org
917.536.0505 (m)

On Sun, Apr 27, 2014 at 12:13 PM, skrugman notifications@github.com wrote:

@jebeck yes, the dates scroll with the timeline. Im not sure what you mean
by sticky labels.

On Fri, Apr 25, 2014 at 6:30 PM, Jana Beck notifications@github.com
wrote:

Thanks @brandonarbiter https://github.com/brandonarbiter. @skrugman<
https://github.com/skrugman>can you provide a little more information on
the proposed design? The

interaction is not 100% clear to me. Is the proposal that the dates on
appear at midnight and move as you scroll? That is, we're not going with
any "sticky" labels?

Reply to this email directly or view it on GitHub<
https://github.com/tidepool-org/tideline/issues/88#issuecomment-41412349>

.

Reply to this email directly or view it on GitHubhttps://github.com//issues/88#issuecomment-41505847
.

[cmakler]

https://trello.com/c/yFdyqn3Y

[jebeck]

From my notes, here's what we agreed to try @skrugman:

This includes the following changes:

• add a "sticky", always-there day of the week label on the left edge
• ticks for midnight go back to saying '12 am' (instead of date)
• ticks for midnight have the day of the week above them

[brandonarbiter]

Thanks for providing that picture, Jana. To me, the two key takeaways, both
of which you have displayed in your drawing were:

1. There is a static dddd on the far left, indicative of the day
   represented on the far left of the 24 hour view.
2. There is a traveling dddd that is aligned with midnight on the 24
   hour view. As the user pans, the dddd pans along with midnight.

On Wed, May 21, 2014 at 10:53 PM, Jana Beck notifications@gh.neting.ccwrote:

From my notes, here's what we agreed to try @skrugmanhttps://github.com/skrugman
:
[image: 2014-05-22 00 43 27]https://cloud.githubusercontent.com/assets/1588547/3050218/02a06480-e175-11e3-89b9-ffe1ede68883.jpg

This includes the following changes:

• add a "sticky", always-there day of the week label on the left edge
• ticks for midnight go back to saying '12 am' (instead of date)
• ticks for midnight have the day of the week above them

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/88#issuecomment-43850996
.

[skrugman]

Okay awesome.

On Thu, May 22, 2014 at 6:10 PM, brandonarbiter notifications@gh.neting.ccwrote:

Thanks for providing that picture, Jana. To me, the two key takeaways,
both
of which you have displayed in your drawing were:

1. There is a static dddd on the far left, indicative of the day
   represented on the far left of the 24 hour view.
2. There is a traveling dddd that is aligned with midnight on the 24
   hour view. As the user pans, the dddd pans along with midnight.

On Wed, May 21, 2014 at 10:53 PM, Jana Beck notifications@gh.neting.ccwrote:

From my notes, here's what we agreed to try @skrugman<
https://github.com/skrugman>
:
[image: 2014-05-22 00 43 27]<
https://cloud.githubusercontent.com/assets/1588547/3050218/02a06480-e175-11e3-89b9-ffe1ede68883.jpg>

This includes the following changes:

• add a "sticky", always-there day of the week label on the left edge
• ticks for midnight go back to saying '12 am' (instead of date)
• ticks for midnight have the day of the week above them

—
Reply to this email directly or view it on GitHub<
https://github.com/tidepool-org/tideline/issues/88#issuecomment-43850996>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/88#issuecomment-43909451
.

*Sara Krugman *
Lead Interaction Designer

*Tidepool *An open source, not-for-profit effort to build an open data
platform and better applications that reduce the burden of Type 1 Diabetes
and accelerate the commercialization of closed-loop systems.

Phone : +45 42 74 68 17
*Email : *sara@tidepool.org
*Web : *Tidepool.org http://tidepool.org/

[jebeck]

Addressed in https://trello.com/c/yFdyqn3Y, change came in via #151.