Pessimistic Presumptive Reports (PPRs) are kind of controversial, for good reasons. (If you’re just tuning in, see our 7-year-old blog post where we introduced them.) Here’s a just-crazy-enough-to-work idea that @mary put in my head today: What if we replaced the PPR setting with a much simpler and much more draconian auto-derail setting? Like instead of PPRs that derail you by gradually eating through your safety buffer if you stick your head in the sand, we just force-derail you immediately if you hit your deadline without having entered data for that day. It’d be like an ultra-PPR, but wouldn’t touch your data.
If you don’t use PPRs currently then this wouldn’t affect you. You’d opt out of auto-derail just like you opt out of PPRs. So my question is for those of you who count on PPRs to make their do-less goals meaningful. (And especially for newbees who don’t know what any of this is but would have this as the default.) How would you feel about the more hardcore auto-derail where you had to enter data by the deadline or else?
(I should also clarify a hard constraint before people get too creative: A do-less goal, unless you explicitly opt out of this, must make you derail if you ignore it. As naturally happens with do-more goals that assume you didn’t do anything if you ignore them.)
I’m personally (as user-me) nervous about this proposal because on, for example, my sugar goal I generally let PPRs come through and then every couple days I correct them if I can or let them stand if I can’t. But now that I’m saying that out loud it sure sounds lazy and dumb and I think user-me would welcome the greater discipline of a red goal screaming at me to enter my number by the deadline. It becomes like any other beemergency that way.
What about scheduled breaks, you ask? It’s already the case that you need to turn PPRs off before going on vacation. (Actually there’s a trick you can use to give yourself safety buffer for a vacation without turning off PPRs but it’s obscure enough that it might as well not exist. The right answer to this is a future feature we call True Breaks.) So with auto-derail you’d just also have to remember to turn that off before going offline for more than a day. Either way, that’s quite bad but the point is it’s not really worse than the status quo.
I think it might make more cohesive sense with how other goals work, and I’m for it in that sense.
However, sounds like a potential UX nightmare, because people do see goals where you have to avoid doing a thing as different to goals where you have to do a thing. I am just picturing how badly I could get yelled at about something that automatically derails you if we don’t do a super good job of communicating the change to people who are used to the old way, and communicating what you’re committing to for newbies.
I will admit that your proposed changes to PPRs worked to stop a lot of the confusion and frustration people were experiencing, against my expectations… so maybe it wouldn’t be as bad as I fear.
What if this change only occurred for new do-less goals, and old goals were grandfathered in? That might make less of a support burden. (I am all in favor of derails if you don’t enter data, fwiw).
Honestly, I feel like that could be worse (as people who are used to their do-less goals acting one way then create new goals and expect them to behave the same, for instance). Also, then we’d have to maintain both PPRs and the new world order, simultaneously, potentially indefinitely.
As someone who turns off PPRs on all my goals, auto-derailing looks way more appealing to me, as it would actually do what PPRs are supposed to do–ensure I enter data consistently–while avoiding one big disadvantage of PPRs–fake data.
An argument against it might be that this, in effect, makes two goals into one. Might it be better to instead make meta minding a first-class Beeminder feature?
Of course, the argument against the argument against is that expecting new users to create two goals to make a do-less goal work right seems like a bit too much.
I don’t like it, because it makes every day into a Beemergency.
With the current system, I can do enough work in advance that I can look at my goals and know that I don’t have to think about doing anything the next day - an earned day off. With the proposed system, that can never happen (unless it’s scheduled a week in advance, of course)
I may be in the minority though, and if so I’ll just stop having do-less goals and figure out some other sort of solution.
PPRs are kind of weird, because they do also auto-derail you, just at a slower rate with inaccurate data.
Users like myself who skate on red would find the change to be good, maybe unnoticeable even. But users that enjoy having buffer for their goals suddenly have one that has no buffer. If you have a do-less goal, you suddenly have to use Beeminder each day, in some capacity.
This is definitely tangential, and an increase in options, but selfishly, I would love to have a setting that causes detail for do more and odometer goals unless data is entered that day (without the clumsiness of having an additional goal to track data entry). Even if I’m just entering a 0, forcing myself to check in with important goals would be nice.
Personally I would be all for this if there were more absolutely zero friction ways of entering data.
Personally I’d love to see this paired with a “smart sms bot.” What I mean is a bot that tries hard to figure out what I meant if, say, it’s sent a reminder for my “weight” goal and I respond cryptically (in regex terms) with “160”.
Ideally for a smart bot I’d be able to respond with any of the following answers after a text of “ +00:01 in <8h for plank ($30)”
0:04
yesterday 0:04
Today p 0:04
pl 0:04
Plank 0:04
21 0:04
21 p 0:04
This kind of incredibly easy entry in response to a reminder would be a really nice thing to do alongside ratcheting up the draconian-ness of PPRs like this.
I posit that it would still feel like a day off despite having to enter how many desserts or whatever you had. You don’t have to do anything on the day off, just enter what you did. And I hate to suggest the following but it would work: you could enter tomorrow’s datapoint ahead of time. Maybe a manual PPR of twice your daily rate if you had the safety buffer for it and wanted to splurge/indulge without having to think about it further.
Is that persuasive that auto-derail could feel ok for your use case?
I kind of love this but probably we should do one thing at a time. But conceivably it’s an elegant generalization: for any goal, how often do you want to be forced to enter data before it auto-derails. For do-less we’d strongly encourage you to choose 1 day but you could pick any number of goals for anything.
Funny you should mention that. We have a spec that’s getting us closer to that – Spec For Smarter SMS Bot – but unfortunately it’s a ways down the list, probably after implementing email digests. It’s a really good point though, that this proposal makes it even more important to reduce friction of data entry.
All these replies are pushing me more in the direction of wanting to do this. Thanks everyone! (And especially @mary for arguing for it in the first place.) Keep the feedback coming!
How about implementing True Breaks before doing this? I really, really dislike the approach of “well, you have a legitimate use case for this feature that we’re thinking about killing, but once we change something else later, that will be covered!” IMO, it gives people the impression that they can’t rely even on features they’re already using. (I personally almost never use do-less goals, so wouldn’t really be affected, which makes this the right time IMO to raise my principled objection.)
The use case in question is “I would like to earn some safety buffer and not have to think about my do-less goal” and I’ve made an argument for why, even without the True Breaks feature, the proposed change wouldn’t hurt that use case much. We’ll see if @minstrelofc or others with that concern are persuaded.
We’ve been ridiculously thoughtful about killing features – see our Pareto Dominance Principle or the monumental pains we took to convert to Yellow Brick Half-Plane without negatively impacting users – so I’d be pretty surprised if anyone were getting the impression they can’t rely on existing features.
I think we already have a semi-serious problem along those lines that makes true breaks something I think we need badly: breaks as they are don’t actually work for some canonical, non-edge-casey use-cases. Do-less goals with PPRs are one of those things; whittle-down goals attached to autodata sources are another.
I am honestly surprised that we don’t get more complaints about that (I haven’t fired up my spreadsheet to check, but I’m fairly sure no one has complained about it at all in the last year+), but as a consequence I sort of have my doubts that breaks + auto-derail would cause anyone to blink an eyelid either.
Theoretically a manual PPR in advance could work. I’ll try it if I have to, but (kneejerk response) isn’t the point of computers to do the manual work for us?
I feel I’m somewhat atypical in my use of Beeminder in that (with the exception of Odometer goals) I’m less concerned about accurate data than I am about ensuring that I don’t forget or lose track of longer-term goals.
An enforced auto-derail just for do-less goals still seems non-ideal to me. Consider if all goals had an enforced 1 day auto-derail - you do the once-a-month task, then every other day of the month you have to enter that you didn’t do that thing. (I realize this extreme example doesn’t necessarily fit the purpose of most do-less goals; I’m just changing the framing exploratively)
Perhaps the solution is a customizable auto-derail period for all tasks, defaulting to 1 day for do-less?
(auto-data all the things is likely a better solution, but sadly not everything is autodatable yet)
Long time reader, first time caller. I have a pretty decent number of goals overall, but only 4 do-less goals, only one automated. Initially I was enthusiastic about the end of PPRs, but the more I think about this implementation, the less enthused I become about my specific workflow. It probably doesn’t generalize so I can definitely see the positives for the greater good.
I’m a fan of early evening derailment times for all goals, as this keeps my evenings more stress free (as @dreev and others have written about). Given that sometimes my day job has very variable ending times (sometimes an overnight call through the next morning), it forces me to keep goals as blue (or ideally green) as possible on a day-to-day basis so I don’t have to worry about completing tasks on days when I’m busy (almost by definition staying late == busy).
Forcing users to have daily mandatory emergency days when they didn’t ask for it (opting-in with auto-trimming, etc.) or “earn” it (by skimming emergency days) feels like bad practice.
I see @minstrelofc replied as I am typing this and agree with many points, particularly a customizable auto-derail period (I would probably set it to 2 or 3 days on my manual do-less goals).
You wouldn’t necessarily derail the first time you failed to enter data, right? You’d just eat through your buffer in real time until you got to zero, then derail. The first case seems way too harsh. The second case would behave more like other goals.
What I’m imagining is if I had a do-less goal with 3+ days of buffer, if I didn’t enter data, the next day of not entering data I’d have 2+, after that 1+, and on the third day I’d be in the red.
But then what would happen if I entered a non-derailing amount of data for one of those three days at a time. Would I have till the end of the day before I derailed, so I could clean things up for the three missing days?
Especially given the magical nature of the current PPR datapoints that they disappear themselves once you enter the actual data, which wouldn’t obviously be the case with the manual ones!
I don’t have many Do Less goals, but I really don’t want them cluttering up my gallery and screaming for data unless I’m skating the edge. Suspect that I might hate that sufficiently to automate a daily report of 0, which defeats the purpose.
The current scheme seems to suit me; they shout loudly if I’m approaching the danger zone, and sit quietly lower down my dashboard when they’re not. Much better than the (non?)warnings we used to have.
+00:01 in <8h for plank ($30)”
