Suggestion: Better graphing of bright red line as the final threshold?

Bugabee
1

I find it odd that the bright red line is intended to represent the point of derailment (“stay on the correct side of the bright red line”), but that the graphical representation actually crosses the bright red line as one gets close to derailment. Why do we cross the bright red line when close to derailment? Would it make more sense for there to be no graphical crossing of the bright red line until one actually derails?

Here’s an example.

The above graph was taken at about 1:41 PM, and I had 10h19m to file 15 items, or I derail. But the graph looks like I’ve already crossed the bright red line. This issue might be related to the issue of the graph not clearly representing where “right now” is located.

1 Like
2

@dreev sometimes dreams of real time beeminding, in which the line moves minute by minute, as you were expecting

2 Likes
4

Sounds like a 757 haiku

dreeve dreams of beeminding lines
moving in real time
just as you were expecting

or better:

dreeve dreams of beeminding lines
moving in real time
derailment is approaching

2 Likes
5

I don’t quite view this the same way as you, I think. To me, the bright red line shows you the difference between the right side of the road and the wrong side. You have to be on the right side at your deadline… but you can definitely be on the wrong side before the deadline, and when your data is in the red, it’s correct that you’re on the wrong side – it’s showing you that if you don’t do anything, that’s where you are and you will derail.

Maybe that makes more sense of it?

2 Likes
7

I like @shanaqui’s explanation for why it is currently that you can technically cross the bright red line.

As @philip alludes to, there’s theoretically a way to redesign things so that the moment you touch the bright red line, you derail. But it’s way easier said than done and would involve the red line being staircase-shaped. Further musing on that in this old thread:

I actually will be excited to move to that scheme eventually, and I do think it’s cleaner, but it’s a bigger change than, for example, the yellow brick half-plane project. Also I think it will have less impact for normal users who just want to commit to doing certain things every day by a consistent deadline.

8

Thanks, that really helps me to better understand what @shanaqui was saying! The reason we currently go under the line is because the bright red line is currently represented as a continuous line instead of a stairstep. Or in other words, when your data timeline initially goes under the redline, that’s actually at a point in time on the horizontal axis that is before Beeminder’s actual deadline (typically midnight).

I do think a stairstep might be a more intuitive representation of the current implementation. Keep flappy bird (your current timeline cumulative total) from flying into the wall (the actual deadline). Or an alternative implementation could allow the redline to take various forms (continuous or stair step), but any crossing of the redline would be a derailment.

On the other hand, I can see how a week long stairstep or month long stairstep would give one less visual daily feedback of being “on track” to completing the goal. And I also appreciate that such an overhaul could be a huge undertaking. Clearly there’s a lot of things to consider in making such a change.

Thanks again to both of you for being responsive on this, as usual!