I mean no offense at all, and I really love Beeminder, but it seems to me Do Less breaks are really weirdly handled. Either the pessimistic presumptive data derails me even though I’m trying to take a break, or I get a crazy high new limit when I come back and have to ratchet (which I think makes my graph kinda ugly, so I prefer to not). Maybe I’m just really dumb, but why not implement a break by doing a flat road and turn off pessimistic presumptive data? Then my data is where I left off when I come back from break, my history doesn’t look like I did stuff I didn’t (PPD is weirdly close to fake data), and I don’t get accidentally derailed.
5 Likes
Hi! Yeah, I’ve thought about that in the past. I don’t know if this was the rationale behind not doing so to begin with but in practice, I’ve found that some people like to schedule a jump in their graph and leave PPRs on because it ensures they will come back to the goal. With a do-less goal without PPRs, there’s always a bit of a risk you can forget about it, or take a few extra break days that weren’t really intended as a break, when you don’t have PPRs. With PPRs still on, there’s the pressure to come back.
However, you can already turn PPRs off (not just during a break, but anytime) if they’re not useful for you – you can do that via the goal’s settings, in the “pessimistic presumptive” section. I’d kinda like to get that on the breaks page as well, so that folks who want to use the breaks that way can quickly toggle the PPRs off there (and also because then it’d be a good place to check out your PPR settings across all your goals).
1 Like
That’s a good point! I meant toggling PPR with the break, so off when the break starts and on when the break ends. That way the graph more accurately represents what’s happening during the break, and it makes you return to the goal when the break is over. It could even be a special PPR that will derail you if you don’t come back the day after the break ends (instead of how sometimes it just eats at your buffer).
I do like PPRs and I absolutely want them on for most of my goals. I just keep ending up with a situation where I’m trying to take a break for vacations, and on vacations I don’t want to be worrying about derailing, yet even with the break turned on because of the PPRs I have to either add data or spot it too late and derail, and then I have to bug support to fix it. The point of a break is to take a break, not be still having to babysit my goals to make sure they’re not sabotaging me. I just thought auto-toggling PPRs for breaks would be a reliable way to handle breaks, while also making the graphs cleaner. 
2 Likes
Ah, I guess I dismissed that as being a bit too magical, but maybe it’s exactly what people would expect in that circumstance, and thus makes it okay… 
In any case, true breaks for all goals is something we’ve been discussing, so we’re probably more likely to go with that than something only specific to Do-Less goals, but it’s useful to keep the idea in mind!
2 Likes
Almost everything about Do Less goals is really weirdly handled. They’re inherently difficult to manage, which is why we encourage folks to frame their goals as Do More if they possibly can.
I think the origins of the doubly-steep-slope break on a do-less was to mirror (somewhat, and badly) what happens with a flat-slope break on a do-more.
With a Do More goal when it’s on a break, you’re not prohibited from doing the thing whilst on holiday, just not required to do the thing. Any thinging that you do during the break still counts toward future safety buffer.
The doubly-steep-slope idea for Do Less was that you could still do and track the thing, but (likely, hopefully) without worrying about hitting the bright red line.
In contrast, putting a flat spot in a Do Less means that you absolutely must not do the thing whilst on holiday. (Or resign yourself to not reporting it, breaking the true history for Quantified Self purposes.) That’s true regardless of the PPR setting.
Ironically, true breaks would be a prerequisite for doing the automagic PPR off/on that @trb97horsegal suggests because, of course, there’s not currently any such thing as a break, only a scheduled change in slope. (Love the idea, though!)
It’s the human on the other side of the keyboard that brings the semantics that the scheduled change in slope constitutes a break. (As opposed to a temporary slackening, or intensifying, or something else altogether)
I suspect that in true breaks, the commitment line should disappear, datapoints should be accepted, and when the break ends, you’re in the same relative position to the bright red line that you were prior to the break.
4 Likes