Thinking out loud here about my own (yet unpublished but to-be-open sourced) beeminder-like tool, but maybe this is of interest to beeminders as well as to me since I believe beeminder is heading in a similar direction re half-plane, and maybe with how losing safety buffer works? Certainly I’d love to hear feedback from people’s experience with beeminder.
This is all about recommits, and also losing safety buffer, which I’ve modelled essentially just as a recommit that goes up instead of down.
How should recommits and losing safety buffer work? At least in my system it seems there are two obvious choices, one of which only became clear to me after using it for a while.
Choice 1: (I believe this is at least similar to what beeminder does currently?), recording a recommit causes the goal line to drop a little bit to the cumulative value of the last datapoint, followed by a flat period where the line stays horizontal. After that it starts going up again at the same rate as before the derail.
After using that for a while, I found two problems with it:
a. I found I was encouraging myself to ignore the goal after a recommit, because “I’m losing nothing”: after all, the horizontal distance from the last datapoint to the goal line stays the same if I do nothing!
b. I was encouraging myself to ignore it ALSO because the drop from where the line would have been without the recommit, to its new value (that of the last cumulative datapoint) was quite small. That felt like I was leaving motivation on the table, because it made the consequence of derailing look less bad than it really was.
So, Choice 2: Recording a recommit causes the right hand side (the future side) of the goal line to “slide down” so today’s value matches the last cumulative data point. Then instead of the flat period, the line just starts increasing again immediately from that much lower value. It slides down just enough so you have 7 days of safety buffer.
I think of choice 2. as “plummet”, because it makes the real effect of a recommit visually very clear.
The situation for losing safety buffer is similar (again, in my system losing safety buffer is basically just a recommit that “slides up” instead of down). I believe beeminder currently “slides left” instead for losing safety buffer, which has different problems (e.g. moving scheduled breaks).
I’ve switched to the “plummet” scheme now both for recommits and losing safety buffer, and it does seem an improvement. Still, maybe there are advantages of the “flat period” scheme that I haven’t noticed?