Beebudget: Beeminder Goals and Time Budgeting

Check out this tool that @aad made:

(It requires your personal auth token to log in, which you can find at beeminder.com/api/v1/auth_token.json and in this case I can vouch that it’s safe to put that into Aad’s app. In general one should be careful with one’s auth token since it’s basically the keys to your Beeminder kingdom.)

The idea is to specify how long progress takes per unit for each of your goals in order to sum up how much time you need to allocate per day to dispatching beemergencies (or to stay in the orange or blue or green or however much safety buffer you want).

For a while I’ve been mulling having something related to that built in to Beeminder. What I really want is something smarter than zeno polling that only nudges me at most once per goal.

Excerpt from our internal spec document:

We can replace zeno polling with something much more useful and less spammy and more nannybotty. You get exactly one reminder per goal such that you’ll finish everything just under the wire, or however close to the wire you like, depending on how conservative you are with your [estimates of how long a goal unit takes]. No lead days or reminder start time, just one reminder at the right time, on each medium/modality you specify, based on [two settings].

(Which means technically this whole proposal reduces the number of settings! Generalize the existing [precision field] slightly, add [estimates], and kill reminder start and lead days.)

In the meantime, maybe you’ll find Aad’s tool useful? Huge thanks to him for building it!

5 Likes

I think I’d still prefer a modified version of the zeno schedule, where you get notifications on the zeno schedule, but only for the next-due goal. So you don’t get spammed for every goal you have, and you can gauge how much you need to worry based on the time between the last two notifications you received.

I’ve used this modified schedule for years now and can’t imagine using any other notification schedule.

3 Likes

I’ve implemented a two-notification-per-goal strategy: one as Daniel describes, and one five minutes before to give me transition time. It’s because I don’t want to decide how much to worry and when to start. And it means I don’t get notification fatigue and start ignoring my phone.

This also forces me to be specific and realistic with my estimates. Will this actually take this long? Can I actually spend the time when I’m planning to?

3 Likes

Thanks for introducing this in the forum, @dreev.

I’m thinking of putting more time into this.

While I was preparing for that, and aut of curiosity, I checked my server logs and noticed sporadic user activity. So… If anyone has feedback, this is the moment to share it! :slight_smile:

2 Likes

I might try playing with it a bit.

One related thing is that I have an urgency load goal, and something I sometimes find frustrating is that it doesnt care how some goals require way more effort per day to add a day of buffer than others, which occasionally creates bad incentives. Not sure what the best “time estimate” based metric to replace it with would be. Maybe a very similar thing, but instead of being days and capping at a week, could be hours, capping at 7? Unsure.

I would really like to use this, but it doesn’t seem to let me put values of less than a minute per unit of progress, and a lot of my goals use very small units (characters read rather than pages, for example, where i’m aiming for 5000+ characters per day).

2 Likes

I would like to subscribe to this observation. Being unable to use smaller units also, unfortunately, renders this useless for me. I have goals to write X words in a draft (typing a word way faster than a minute) or to revise words in Anki (just a few seconds per word). And while for some goals it might make sense to reimagine what the units are, for these specifically this is how autodata works, zero control on unit choice from the user’s side.

I am writing this to second @rubygagotoku’s observation, offering some examples, to suggest there might be more people silently passing by because of the same reasons :slight_smile: Of course when we build some add-on tools, we build them first and foremost to fit our own use cases :slight_smile:

1 Like

I can relate to the frustration this causes. This simple app was my attempt to help myself with that.


Thanks @rubygagotoku and @scarabaea. You must now be able to use smaller units. Thanks for the feedback.


There’s one thing that I regret not highlighting in the app itself. The app reports your time commitment based on your goal configurations, and not your actual red lines. Especially if you’re making advanced adjustments using graph editors, this may be misleading.


Just so I’ve mentioned it here, my current plans for this app are vaguely in the following direction: being able to relate this to one’s “life compass” (a la ACT). Curious whether that resonates with anyone here.

3 Likes

Thank you for allowing smaller units, I’ve put all my goals into it now and seeing the total time cost is super cool!

I’ve just deployed an update that makes the app’s urgency numbers line up with the bright red line. I’ve also added a mode switch so you can keep using the mode you’ve been using and compare that to the older config-buffer approach, and I’ve done some general UI cleanup.

I’d appreciate feedback on two things:

  1. Should I treat config-buffer as legacy?
    I’m considering removing it eventually to keep the app simpler. Do you have use-cases where config-buffer is still useful or more intuitive than brightline?

  2. General feedback
    Anything confusing, missing, or especially helpful? Quick thoughts are totally fine.

1 Like

This is so much more useful, thanks for the update! (The previous version mostly had theoretical / QS value for me, while this now - this really shows how much more effort is due before certain day.)

What does it mean, “log due 0…6”?

Oei sorry that was a button I added while developing, that I apparently forgot removing :sweat_smile: it logs the underlying data to the console, I’ll remove it soon!

1 Like

One more possible improvement that shouldn’t take a ton of time to implement is that upon reload the page currently returns back to the “legacy” way of calculations on its own and needs to be switched back to the “recommended” one manually. But I agree with your idea:

I took care of this :+1: (You’ll need to switch once per device/browser/browser-profile.)

1 Like

I wanted to revamp the UI with LLMs. This cost me about $2.5 :money_with_wings:

(I hope the change in what bars indicate has also made them more useful.)

1 Like

I wanted to reiterate again how useful this tool is for me since it started to calculate based on the bright line / road. Just ran into another situation when I am really happy I can see all of that for a week ahead in one place. Thanks @aad :slight_smile:

1 Like