Continuous Beeminding; Or, The Yellow Brick Staircase

This is not exactly on the horizon but it’s helpful to have the mental model of the platonic ideal of Beeminder. It sounds a bit crazy at first but is super elegant and with the right interface would be simpler and clearer and intuitiver.

[OK, everything after this point is not ready for consumption, public or otherwise.]

Point from shanaqui 2021-07-09: What about an inbox-zero goal where your datapoints may be arbitrarily over the bright red line all day before your deadline? I guess one answer is that you’d make your bright red line look like a stegosaurus, allowing your values to get bigger throughout the day but they’d hit a wall at midnight (or whatever deadline) where you’d have to get back below the dip.

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. It might feel like a slow-motion Flappy Bird video game where you have to keep jumping up to avoid colliding with the edge of the yellow brick road.

Do Less Goals

Continuous beeminding obviates pessimistic presumptive reports. The current dot is simply on a collision course with the road, moving up with twice the road’s slope. Every time you put in a number, the dot jumps to where you actually are but then immediately resumes a new collision course from there. The lanes of the road (colored zones of the Yellow Brick Half-Plane) make clear how long you have till you derail, same as ever.

Continuous beeminding may not be a prerequisite for ditching pessimistic presumptive reports but the focus on the visual representation of always being on a collision course with the road may make it easier.

Retroratcheting, Deadline Snoozing, and the Uncle Button

With continuous beeminding, you can ratchet the road, retroactively or not, by dragging it around, with the same rules as the current road editor. No making it easier in the next 7 days. If you drag the road past the current datapoint you can cause an instant derailment. It can be visually obvious so you wouldn’t do it accidentally. Which means you naturally have an Uncle Button.

Deadline snoozing is naturally accomplished by just doing a bit more work to push the deadline out. Well, sort of. As we’ll see below, the Flappy Bird version is too unpredictable and so we’ll get the best of both worlds with continuous beeminding but with a yellow brick staircase, so you still have consistent deadlines each day (or each week or multiple times per day, or on whatever schedule you like). But that means no deadline snoozing within the akrasia horizon. Maybe the answer to this is that deadline snoozing is an ugly hack that violates the no-such-thing-as-leniency principle and we don’t want that anyway. If you don’t care about a consistent daily deadline then you can have flexibility in a principled way by having a smooth linear road.

Basically every convoluted feature of Beeminder becomes a natural consequence of this single abstraction.

Everything below is all wrong and confused. The elegant solution is yellow brick staircase, as articulated in


Deadline waterfalls are important so Beeminder should still let you specify ideal deadlines. It would show a visualization of actual and ideal deadlines for all goals. And just like you’re motivated to do enough to push all your deadlines at least 8 hours into the future before going to bed, you’re also motivated to push them all to the point of matching the ideal deadlines so that your waterfall is in place for tomorrow. Being akratic you’ll be tempted to let your deadlines bunch up in the morning but that’s not all bad. Remember it doesn’t mean you have to finish the whole day’s work in the morning, it means you have to bounce between goals doing enough on each to buy enough time to work on the others. It’s like a constantly evolving and constantly reassessed waterfall. To the extent that that’s stressful you’re motivated to work more to push the deadlines to the right waterfall times.

Or maybe constant reassessing and deadline juggling is better than a fixed deadline waterfall and there’s no need for Beeminder’s UI to care about ideal deadlines. You could always make a post-it note with your ideal deadlines and keep Beeminder stress-free by making your actual deadlines always match.

Debate on Continuous Beeminding

Maybe there’s value to the discipline of a fixed, consistent daily deadline? Like say you really need to put in an hour each day by 5pm on your TPS reports at work. With continuous beeminding you can put it off till 4:59pm and then keep buying yourself another hour by putting in 3 minutes of work, which can theoretically continue all night if you put in tiny enough bits of time before resuming procrastination. You really want to force yourself to be done for the day at 5pm but if you’re sufficiently akratic, it won’t happen.

My counterargument: Once you get started on the TPS reports you’ll keep going. So work enough today to push your deadline to 4pm tomorrow. Then tomorrow you’ll have to start at 3:59pm and will naturally keep going for the hour it takes to push the deadline for the next day 24 hours out, ie, 4pm again. If it’s really painful then maybe you’ll quit after pushing the deadline to the next morning, but in that case, all the better. If it’s really so painful that you keep quitting after a couple minutes of work and are forced to resume again an hour later then that’s a clear sign that you need to rethink the whole goal.

Daniel Hilgarth replies: “I thought about goals where it only makes sense to do it in one big chunk. For example, doing two pushups every hour isn’t really useful. You want to do the forty in one go.”

My point is that in practice you won’t do two pushups and then stop. Technically you can stop after two, but then you’d have to do more in an hour. That’s way inside your akrasia horizon and it’s clearly easier to keep doing pushups until you’ve pushed the next deadline till tomorrow. Basically the akrasia is largely in the starting.

More discussion

What’s difficult about implementing this is the transition from current Beeminder. (For those who were around in August 2013, remember how surprisingly hard the transition to the New World Order was?)

Who says akrasia is all in the starting?

It’s true, I wouldn’t characterize my own akrasia as all in the starting. But a critical part of it is in the starting. And continuous beeminding, I predict, provides sufficient inducement to keep going, as well as starting. If you stop too soon (too small of a flappy bird jump on your yellow brick road) then you’ll have to do more again Very Soon. Where “Very Soon” is inside your akrasia horizon. So you won’t want to do that.

But this is speculation. We’d have to try this and see how it felt.

Flappy Bird analogy doesn’t work when the dot is moving at one pixel per hour…

Yes, this is true even if you zoom in to a single day. This might require something more creative to convey the dynamicness of it. Maybe an extreme zoom-in and back out, or a dotted line showing the collision course with a countdown as a label.

Would this require better ratcheting?

Andy points out that it could be pretty annoying to work on your TPS report long enough to buy yourself 36 hours and then have tomorrow’s deadline in the middle of the night. I don’t know whether that problem’s fatal or if it’s down to details of the UI to discourage that or let you do micro-ratcheting to correct it or what.

Feedback from the daily beemail folks suggests that a consistent daily deadline is a big deal. So if we ever seriously consider this I think we’ll need to find the best of both worlds. Maybe something analogous to snap-to-grid in Photoshop? Like you can build up as many full days of safety buffer as you want but if you do an amount that makes your deadline later then the road autoratchets to keep your deadline consistent? I’m not liking this.

Can we fix it with flat spots?

Wait, maybe if we generalize weekends-off to make it easy to schedule flat spots for any regular time periods, like overnight, that ameliorates the problem of wildly varying deadlines? If you wanted a consistent hard deadline of 5pm you could pick a time you wanted to start working by, say 4pm, and just schedule 5pm to the next day’s 4pm as a daily recurring break. The road would need to be super steep between 4pm and 5pm to get the right overall rate. This is potentially the best of all worlds. If you really wanted a single consistent hard daily deadline then you could have that and the road would just go up in daily steps. And maybe that’s the default and it actually helps to have the daily nature visually reinforced like that. Other goals might make sense with pure continuous beeminding, or with continuous beeminding but with flat spots overnight and on weekends.

You could even have complete control over when Beeminder should enforce steady progress. This could finally wipe out all the “chunky time” confusion. You specify exactly what times of day or days of week Beeminder can enforce progress and the road is simply flat during all other times. (Beeminder would need to be clear when adjusting the yellow brick road what the instantaneous rate is as well as the overall average rate. That’s just as much an issue now, with breaks like weekends-off.) You could have something due only at a specific time on Mondays, for example, exactly the way newbees often imagine they can make Beeminder work. Or enforce progress only during business hours.

A practical downside, as Bee points out, is that roads with lots of segments are a mess, at least in our current implementation. But if we solved that problem then this could conceivably be the best of all worlds.