include backlog cards in today in future due graph

[jakeprobst]

(when backlog option is not checked)

sort of a followup to the comment from #3368. this should be an accurate count of cards due for today.

[brishtibheja]

For example for today the graph says I have 197 due but I actually have 208 due. Checking Backlog does show additional cards that would explain the difference.

Isn't it weird though that you don't check backlog and backlog still appears in graph? It's not really is:due that the graph should show right?

[user1823]

Like brishtibheja, I too think that the changes in this PR are unintuitive.

In my opinion, a more reasonable change would be to include the cards that are due today (or in the past) but are currently buried in the count for tomorrow. This allows the user to get a better estimate of the load that they would encounter the next day.

But, there is a problem with this suggestion. These cards would be included in the backlog section, not in the today bar once the day changes. So, there would be some inconsistency.

[user1823]

Replying to your comment in the previous PR:

changing it to due <= 0 does not seem to make a difference in how the chart ends up.

This may be because you don't have any cards that are due in the past and are currently buried.

But, changing it to due <= 0 seems reasonable.

[jakeprobst]

It's not really is:due that the graph should show right?

I would argue that the exact thing this thing should show is how many cards I am going to be doing that day.

In my opinion, a more reasonable change would be to include the cards that are due today (or in the past) but are currently buried in the count for tomorrow. This allows the user to get a better estimate of the load that they would encounter the next day.

This is a reasonable idea.

This may be because you don't have any cards that are due in the past and are currently buried.
But, changing it to due <= 0 seems reasonable.

This was the conclusion I also came to and why I included it in this PR.

[brishtibheja]

In one sense of the word due, you have cards getting due at each day their interval lands them on. In this meaning, you have the concept of overdue. But in another sense of the word, due includes all overdue cards.

My point is, when we talk about dates it's the first kind of due that we're talking about (which many probably dislike).

If we go with this, I'd suggest we change the category name to Daily Reviews instead as there have been people confused by this before. In the browse screen we make a distinction between due and overdue so we shouldn't fuzz the boundaries here.

[user1823]

To make the distinction between the due and overdue cards clearer, we can use a different color (say, red) for the overdue cards so that the graph looks something like the Reviews graph.

[brishtibheja]

That would be unnecessary I think if wording is changed. I also don't think jake likes working on UI too much.

I have one more thing in mind, I'm not sure whether this is a problem we should care about. I currently have over 2K cards due in backlog. My daily reviews are 12 per day (avg.) so this change makes the graph completely meaningless, unless I view past dates when again, there are too many bars it gets a bit hard to look at the graph.

[dae]

Thanks for looking into this Jake. I too am a bit surprised that the backlog is still included even when the checkbox is unchecked - I'd expect disabling it would hide the backlog from the graph, instead of moving the overdue cards into the current day. The original goal of the toggle was to allow the user to see their future workload without their backlog making the graph harder to read. Moving the count to today reduces the x axis, but increases the y axis, so we're sort of trading one distraction for another.

In my opinion, a more reasonable change would be to include the cards that are due today (or in the past) but are currently buried in the count for tomorrow.

While I can see the logic, I'm not sure we should do this. Buried cards are not guaranteed to be shown the next day - the user may manually unbury them, or they may end up getting buried again the next day.

[dae]

Do you think you'll have time to return to this soon Jake? Do you still feel we should be showing the backlog in that case?