Allow a cap on how much progress can be made per day.
Let's say that I have a goal of cycling 50km/week. If my goal is to get into the habit of cycling regularly, then I don't want to allow myself to cycle all 50km in one day, and slack off for the rest of the week. However I do want to report my distances accurately to Beeminder, and I do want cycling 50km in a day to be perfectly okay.
What I'd love is for Beeminder to put a cap on how much effort can be applied each day. Perhaps I've cycled 50km, but only the first 15km of each day counts. Changing this cap, like changing other goal-related parameters, would be fine if it's past the akrasia horizon.
Note that this suggestion determines the maximum amount of safety one can build per day. It's related but different to the other suggestion of setting a cap of how much safety one can build in total.
Thanks for creating Beeminder, it's proving to be a great service!
The ratchet and (premium) auto-ratchet features cover this pretty well now!
-
Kuba Stechly commented
Isn't this already implemented as retroratchet?
-
Lars commented
I have a different use case for this idea;
I believe that I don't drink enough during the day (water, whatever - actual research doesn't support the 2, 2.5 liters of water per day notion, but we do need about that amount of fluids in total each day (and more if we sweat a lot due to training or hot weather)).So I'd like to track how much I drink with a goal of maybe 1.5 liters per day, and where I'm beeminded if I'm not on track for that, say 3 times a day (!). In this case it doesn't make sense to be able to build a safety buffer, as the alternative is to retrorachet every day.
Maybe this is a type of goal that doesn't fit beeminder fully, although the tracking/quantifying part of it does.
-
Ellen Dee commented
I really like this idea, as I tend to get overenthusiastic at the start of new goals and burn myself out. I think it comes down to the goal needing to be "do the right amount" rather than do more/less.
Maybe it is something that could be a new goal type, where you set a goal and variation either too high or too low sets you off the road? It might mean you could set two goals for something like cycling, where you might achieve the cumulative total but fail on staying within your limits. It could be linked to the same data so you didn't have to enter everything twice.
I have already planned to try and cap my amounts on some things manually by just not counting anything over a certain amount, but this is not always going to be the best way, particularly if you have an automatic link to something like Runkeeper.
-
Colin Rafferty commented
I definitely like the cap on safety buffer. I have a "fitfloors" goal of 15/day, and I don't want the 50 floor day to make me lazy the rest of the week.
-
Admindreeves (Cofounder, Beeminder) commented
Glenn, that's smart! But the idea of entering anything other than the true data kind of weirds me out. (If you're super consistent in how you notate the true datapoint in the comments maybe we can programmatically put things to rights once we have a proper retroratchet feature!)
-
Glenn Willen commented
I have started manually implementing the 'cap on safety buffer' as follows: In the 'goal' field I put the actual goal and "capped at green" as a reminder to myself. Then if I enter data that would push me into green territory, I cut it down to just what it takes to reach green, and in the comment I put the real value, along with "(capped)".
It would be nice to get the real data on the graph too, and have the road 'rise up to meet it' so to speak (which would also be a good implementation for 'retroratchet', which is indeed very similar), but this way at least I do have the data, just not in a nice graphical format.
-
Tijl Kindt commented
This is similar to the retroratchet suggestion: https://beeminder.uservoice.com/forums/3011-general/suggestions/2289727-retroratchet-
I think a cap on the safety buffer is more useful than a cap on the progress made per day because the cap on the progress made per day will show you false data (you actually cycled more than what is in the graph!) and is just a workaround to get rid of safety buffer.
In your case, I'd probably put the cap on the safety buffer at 2 days for example.