I have such mixed feelings about this part. Interested to hear more opinions! The argument against this is that it blurs the bright line. And you can go down a one-more-day-won’t-matter slippery slope where you keep paying the nominal fee and it adds up to more than a full derailment would cost.
You could limit it to one use prior to getting back to the center of your YBR.
Failing would make me question whether to risk it all again by recommitting. This would be less than a failure and eliminate that negative connotation.
well, people already do this with fake data. “i’ll put in 1 today and then i’ll do 2 tomorrow, but only enter a 1 in beeminder!” until they do that so many days in a row the goal is meaningless and they archive it away. at least this option could make you some money, and provides an alternate option to fake data-or-derail (assuming they’re not going to do the thing). if i don’t want to pay $10, i might be willing to pay $5 or $2.50 or something just because it’s less than $10.
I feel like anyone doing that is blithely leaping onto a slope so slippery as to be blatantly abandoning beeminding!
Our friend @anomalily recently said this:
I think that’s beautifully put. We also have a blog post about trying to play catch-up. And another post about cheating. I almost want to suggest that if the idea of entering fake data and catching up the next day even occurs to you then you’re not cut out for Beeminder.
I’m hyperbolizing, but I really don’t like the argument that we should appease cheaters in any way.
Mitigating the slippery-slope of day-after-day deferral could be priced in, so each deferral gets more expensive. Or a limited-use mechanism like @martyh suggested. But here’s the thing:
@chelsea’s point is apt; informal mechanisms exist. Folks put all sorts of things in their fine print (recorded or otherwise) that could let themselves off the hook today. The best examples require actual progress toward the goal, like @malcolm’s incremental progress toward the next integer value. Some of the worst ones attempt to play catch-up and aren’t written down, so it’s hard for the user to apply their own work-around consistently.
That’s not ideal, but it’s also not a blatant abandonment of beeminding. An alarm clock works best if you get up when it goes off. Hitting snooze is a slippery slope, so much so that habitual snoozers don’t even see it as a problem. “I press this button 3 times, and then I get up.” It makes an alarm clock less effective, but not useless.
Start with the assumption that people are flawed yet heroic; they’re beeminding things precisely because they wouldn’t get done otherwise. Even if they hit snooze a few times, they’ll still get more done with our help than without it. Less effective, but not useless.
Official mechanisms supplant informal mechanisms, because: path-of-least-resistance and defaults. Informal mechanisms spring up to work around inflexibility, because: Ashby’s law.
Before we had Take a Break, informal mechanisms existed; some people remembered to flatten and unflatten their roads, others emailed support, others entered a large datapoint to create a week off. Now that there’s an obvious and easy official mechanism, there’s less use of informal mechanisms.
This isn’t about appeasing cheaters. It’s about supporting heroic efforts to stay within self-imposed rules. And because people are flawed, it’s also about giving them the tools to help them to clamp down on themselves, e.g. by closing windows of temptation. And that enables their own personal kaizen.
We’ve all got slowly better at creating the right goals, with more appropriate fine print and sustainable slopes. But it’s slow and incremental, and it relies on us making the best use of Beeminder that we’re able, based on where we are right now. Some of that use isn’t going to be ideal, or as effective as we will learn to make it, but it’s not useless. Flawed, yet heroic.
I have no idea whether I’m for or against this suggestion - feeling a bit ambivalent actually - but I think it is important to note that many users aren’t likely to value the integrity of the datapoints themselves as long as they can be used to steer the users towards their goals. Personally I like statistics and graphs, but I don’t really care that much about them, and I’d never use Beeminder without it solving actual problems for me aka getting things done.
I like the quantified self notion, and I’m a nerd^3, but still I can’t be truly bothered about actually collecting those data (this is where auto goals can come in) unless the goal itself requires me to do it, and this is where Beeminder excels. Besides the nice graphs, I feel that Beeminder have far too few tools to analyze the dataset to be noticably useful in that direction. Even the obvious average lifetime entered value rate is missing under the Goal stats heading.
Fake values aren’t likely to cause major disruption to the data set either (if it does it is because the user is going nuclear on the goal anyway), but if the user feels that that aspect is something that will haunt them later, they’ll probably enter them with a comment that makes them identifiable and thus cleanable.
Necromancy: I’ve just found this thread. I just want to chime in with a plug: my Emacs Beeminder client has this: you can “kill” a goal, which means just hiding it from a list. (Of course, this is undoable.) I used this precisely for this purpose. (Also for other things. I guess I’ll really have to do this screencast about my client - but I keep adding features to it… Also, I’ll try to write in this new “Life” category about how I use Beeminder, that might be helpful for some people.)
I’ve considered putting in the logic to hide goals from my various tools but none of that gets around the issue that the new YBR and derail date aren’t available. Still better than nothing maybe.
Enacting necromancy on this thread to say that, the last couple weeks, I’ve had several “I’m not going to do this, I wish I could just derail and get it out of my face” moments – I want an uncle button!
I juggle a lot of Beeminder goals, and my prices help me prioritize; I don’t want to waste time and brainpower on a $0 “keep this in mind” goal when I’m skating on the edge of a $30 “this is my top priority” goal – but when those little goals are red and sitting on top of my dashboard I have to do that triage over and over throughout the day.
Hahaha, I was really frustrated by the lack of an uncle button, so I went to the forum to see where things stood with this… and, welp, I still feel the same way I did last November.
Is this a technically difficult feature to implement?
Can I sweeten the pot by implying it will make you more money, since sometimes I get so annoyed by these goals that I would gladly pay $5 to get out of my face, that I just do the thing after all and don’t derail?
Once again I find myself wishing I could derail on a goal just to get it out of my face. I don’t have much money, but I’d pay $30 (the largest amount I currently have riding on any goal) for an “uncle!” button!
Here’s a very hacky idea: can you try to add a negative datapoint with yesterday as the date, so that yesterday you would have derailed? This should instantly derail you, if my understanding of the derailment algorithm is correct (big if :P).
I think this would work. Happened to me once accidentally when I created a new goal and then chose to input some lower values below the start of the road in the past.
On the general discussion: +1 for an uncle button (but I would prefer a more beeminderish name than that).
Oh, that SHOULD work! I’ve even done it to myself accidentally, too. It messes with the Quantitative Self stuff but I can always delete/move the fake datapoint later I suppose. Thank you! This will be really helpful!
Yep, I think you should be able to instantly remove the datapoint right after you derailed.
I am, again, very annoyed that I can’t just call ‘uncle’ on an obviously impossible goal to get it out of my face. I got so excited when this thread reminded me of the hack!! But unfortunately, it’s an audodata goal so I can’t put in a fake negative datapoint to force a derail
Well, you say that, but that’s just at the level of the UI… You can add a negative datapoint using the API, and the next autodata sync should tidy up after you by deleting it.
Haha, I’m sure that “one could” add a negative datapoint using the API, and I bet you can, but I personally don’t have the first idea of how to do that. In this case I just… sadly spent all day reminding myself to ignore the red goal.
My new theory is that maybe changing the deadline of the goal to be much earlier / in the past could force a derail? I plan to try that next time I’m in this situation (stating it in this comment because I now look up this thread every time I am annoyed by this problem in order to +1 it).
Sorry for the incomplete reply, here’s a bit more, doubtless still incomplete.
In addition to the API, you should be able to use IFTTT or Zapier to add a negative datapoint. You may need to get creative about how to tell those services which goal to update, what the datapoint value should be, and how to trigger that action.
It’s not every company that has customers begging for an “I give up; take my money!” button.