I have a custom Todo system that supports “DueDate” items. I want a goal that derails when any item becomes overdue, shows as EEP when any item is due today, orange for due tomorrow, blue for the day after, etc.
I want it binary, as in, ANY due item should cause a derail.
I can enter data using the Beeminder API’s in whatever format will work, but I can’t quite figure out how to configure a goal and what data to enter to get the behavior I described.
Ideas?
If you know how to use the API, you can actually just have Beeminder charge your credit card with an HTTP POST request if you go past your due date.
What you’re describing with the blue for the day after, orange for due tomorrow, red for due today etc. sounds a lot like GTBee. The Android version isn’t finished (GTBee for Android forum post) but the iOS app I believe is on the app store.
Maybe an odometer goal with a flat YBR at the level of 1, and with a thin road width, and something feeding the number of days to the nearest deadline? (if you said you can set it up to feed something into beeminder through API) so that you are in the red when you have “0” days to any deadline, and you should make it to the orange at least before midnight, or you derail… The aggregation method should be “max”, of course. And I don’t remember if you can specify that “0” is not an accidental odometer recent, but this is necessary for it to work…
I do something like this with my ‘birthdays’ goal. (Which I use as a reminder to send people birthday greetings.)
You want a do more goal.
Use the API to manipulate the road. (see: roadall)
On any day that is a due date increase the road value by 1 and the rate should look after itself.
However, I have my lanewidth set to 0 which means the goal is only ever red or green.
If you want to also have orange and blue you will need to investigate the black magic that is the lane width calculations and compensate accordingly. (But maybe setting it to 1 would work.)
I have a similar (but completely different!) goal, and after some trial and error ended up with a flat odometer road, fed with data via the api. @Scarabaea’s suggestion of days-to-due is a good one.
Odometer roads default to using the last datapoint entered, which could be handy if you want to be able to get back on the road. Though as stated, overdue is overdue, and always a derailment, in which case ‘max’ or ‘min’ seems like what you want (depends which way up the graph is).
Turns out that I didn’t have to worry about the road width, though that was my first thought too. For @patimen’s use case, the road width would be the mechanism for the graph going blue-orange-red as the deadlines approach. So presumably a width of ‘1 day’ would be the right setting.
I did indeed have to turn off accidental odometer resets, because my api regularly feeds it zeroes.
Confirmed that that’s what the odometer setting does, for custom goals. Thanks for helping figure out this creative beeminding!
I ended up with a slightly different approach that seems to work well.
I’ve set a “Do More” goal with a pace of 1 per day. The aggregation is set to “last”.
In my software, I calculate days until the next item is due, then add the “baseline”, which is essentially the number of says since the goal started.
This gives me a countdown with teeth, unlike many of the other approaches suggested. If my software doesn’t run for a day (very possible), I will still derail when the due date hits.
The only wrinkly will be if I derail, I will have to re-adjust the baseline.