The idea is to have no fixed deadline nor specific time that the graph refreshes for the new day. Rather, the graph is refreshed continuously and the flatlining happens second-by-second. So the countdown to derailment is always a function of the exact amount of work you’ve done so far. If you’re about to derail, do a bit of work and bump your datapoint up a bit. If you do a tiny bit of work you might bump up your datapoint enough to give you another hour of safety buffer. If you want to go to sleep, do enough to give yourself at least 8 hours of safety buffer. If you do the full daily rate you’ll buy yourself another 24 hours of safety buffer. The deadline is always whatever you want it to be without any UI. The entirety of the interface is: do stuff that makes your datapoint move, graph tells you how much time you have before you have to do more.
There is more philosophy on the linked page, but that’s the quick summary of continuous beemiding.
Aside: this topic arose (once upon a time) because part of my argument against implementing freebees was that (substantially) all of the mechanisms in beeminding should flow naturally rather than being artificially imposed. The day boundaries themselves are arbitrary (and now no longer universally fixed) and so imagining continuous beeminding is a useful thought experiment for evaluating proposed restrictions against a platonic ideal form of beeminding.
I like the idea of continuous beeminding, it’s a much more elegant solution. You could emulate the current system by having 23:59 of flat road every day, you would end up with a ‘steppy’ graph, but that may be a feature.
I found myself thinking about this, and came across this forum post, so I feel like I should add my strong second for this feature.
In my opinion it simplifies a lot of thinking about Beeminder - rather than having to worry about deadlines, how much work there is left for the day, and some of the odd stepwise behavior on do-less goals (where you can technically derail every other day), everything is very straightforward: when you’re off the road, you’re off the road. The road increments gradually throughout the day, which avoids some of the within-day akrasia and makes incentives more constant.
Particularly for do-less goals, there’s an urge to (for example) drink all the day’s allocation of coffee in the morning, leaving none left for the afternoon. Or to spend the allowed amount of RescueTime unproductive time all in one chunk, leaving none left for rest breaks. Continuous beeminding would smooth this out - there’s nothing particularly privileged about the time unit of “day” for aggregating goal progress, I’d much rather have allocations accrete slowly, and derails occur as they happen. It would also solve the “uncle button” issue where you have to wait until the deadline for a derail to process.