We could use feedback on this but an impactful change is already live. If you try to change the deadline of a goal when it’s a beemergency, you’ll see this:
Warning! You’re about to make your deadline later on a beemergency day. This can dampen Beeminder’s effectiveness. Do you promise that either (a) you really endorse this later deadline as a permanent change or (b) you have a good reason for changing it temporarily and have set yourself a calendar reminder to put this deadline back?
[CANCEL] [I PROMISE]
(If you just really need a break today, we humbly suggest treating yourself to the derailment)
This feels much more principled than the arbitrary cutoff of 6 hours we had before. The key question is whether honor system suffices. What if it made you type out a confirmation, so no clicking “I Promise” on autopilot at least?
Or even 3 explicit things to click:
“Ok ok, I will suck it up and stick to my deadline”
“I solemnly promise this is a principled, quasi-permanent deadline change, not just snoozing it”
“Uncle button! I’ll take the derailment, go ahead and charge me”
If I’m understanding, there’s no cutoff now? So if I have a goal with a 10 pm deadline, this lets me snooze it at 9:59 pm?
If so, this seems strictly worse than the 6-hour cutoff, and like it should be under a post called “long live deadline snoozing” rather than “death to deadline snoozing.”
ETA: To say more about why I don’t expect this to work for me: it seems to be relying on a principle of “users are extremely scrupulously honest in replying to dialog boxes.” I recognize that Beeminder heavily relies on user honesty already, but ubiquitous TOS / GDPR / etc web dialogs have thoroughly trained me to click buttons without thoroughly reading them. I doubt there’s a way to design a static dialog-box encounter that consistently prompts genuine reflection in a user who knows what the buttons do and which button they want to press.
So my sense is that changing the code to be more lenient while simultaneously changing the dialog box text to be more strict nets out in a more lenient system, and it’s not particularly close. I’d much prefer to keep the 6-hour cutoff (perhaps with this adjusted text), or even removing deadline snoozing entirely.
I like that dialog for the Uncle button, but I think it works because your goal is discouraging people from accidentally using the feature.
In the case of deadline snoozing, you’re trying to discourage someone from purposely changing the deadline, after they’ve already gone through all the steps to do so. A user who is motivated enough to open up the website, navigate to “Settings > Deadlines and Reminders,” enter the new value, and click “Update” is probably motivated enough to press whatever additional buttons are needed to make the update stick.
In this setting, I’m skeptical of a static dialog box making a big difference, especially on the >3rd interaction. (I expect it to make some difference, just not enough that you should declare deadline snoozing dead.)
While I’m here and writing all my thoughts about snoozing…
My biggest issue with the 6-hour cutoff is that it isn’t obvious to a new user, so you’re likely to only learn about it the first time you happen to change a deadline on a beemergency day. Other than that, it seems basically fine to me. A stylized case I’ve had more than once: I wake up and realize I’ll be at work late and can’t exercise before 7pm as planned, so I bump the deadline back and get a late workout in that night. If I couldn’t bump the deadline, I wouldn’t have worked out, so this seems like a good outcome.
Another principled case would be “no changing deadlines on beemergency days” (i.e. actually killing deadline snoozing).
But I don’t see what problem is being solved by removing the 6-hour cutoff and prompting the user to reconsider, which is why I’m confused about this update and the way it’s framed.
I was oblivious to the 6-hour cutoff and I’m an old, sun-faded user. It’s pretty rare for me to be surprised by an imminent derail. The way I set my goals, if I’m riding the line so close that I’m counting hours, I’ve already failed. It usually takes heroic effort to push my horizon out at that point, so now I just Uncle it.
For that last one, the idea is to prompt you to consider what it means to be willing to pay the tax of snoozing your deadline. Today you’re busy or whatever and it’s hard to meet the deadline. But you chose that deadline for a reason, presumably. (Note the exception where you can change the deadline if it really is a better deadline in general, not just for today.) So you’re either making Beeminder permanently less effective or you have to muster the discipline to change the deadline back again tomorrow, when it’s especially hard to do, since you’ll be making a beemergency that’s bearing down even more challenging.
Yet another idea: literally charge a fee to snooze your deadline.
PS: Bingo to what @asciimo just said! That’s the right attitude. The “must do whatever it takes to not derail” attitude is… not necessarily all bad but it should have its limits and I think deadline snoozing should be viewed as outside those limits. In practice it seems to amount to digging oneself in a hole.
Huge thanks for the discussion here so far. After mulling these arguments and much agonizing with @bee, we decided to kill the honor system thing for now. Also we blogged about it (repeating some of the things above):
Big fan of this! Despite providing a case where I felt deadline snoozing was kind of useful to me above, I agree it’s overall better not to have it.
I’m sure you’ve considered this already, but the one legitimate case I can think of where this seems tricky is goals with a 0-day autoratchet. Especially if they’re often completed very close to the deadline (maybe as part of a waterfall), they’re in a state of near-perpetual beemergency, making it hard to change the deadline.
…But even in this worst case, it doesn’t seem that bad. You can always change the deadline right after completing the task for the day (surely you can find 3 minutes to do this before the deadline). So the change seems good to me.
I think the only times I’ve wanted to change a deadline have either been on a new goal where I forgot to change the default, or a rethink of how my goals were organised (hence permanent change). As I recall, the cutoff was invisible and hence annoying, since I’d decided on the structural change. So this is a good change.
3 explicit things to click could be good and help us understand why users want to take a particular action.
Relatedly, I find the new Uncle confirmation onerous. (Conversely, the previous confirmation-less instaderail was a bit too friction-free.) Earlier this week I encountered it for the first time and I decided to endure the zeno polling rather than tap out the phrase on my phone.
Me too! But I realized recently that the browser remembers what I typed into that slot the previous time, so no actual typing will be needed after the first symbol in the same browser. (Chrome, at least.)
Crap, I forgot about phones. But seriously, that’s a highly compelling point. How about if we change it to just typing the number of dollars you’ll be charged?
Speaking of things I dumbly forgot: @shanaqui’s feedback spreadsheet which has the following votes:
17 votes: the akrasia horizon should apply to changing deadline
11 votes: snoozing is fine and should always be allowed
7 votes: allow me to change it now while I’m thinking of it, but it won’t take effect until tomorrow
2 votes: the fact that you emailed me about snoozing the deadline made me realise I could use it to cheat, which I’d never considered previously
1 vote: it should be up to me whether changing the deadline counts today, tomorrow, or in two weeks
So that’s a lot of support – + – for letting you change the deadline in an akrasia-proofed way. There’s a bit of a can of worms though. The full one-week akrasia horizon () seems too restrictive compared to the new status quo of letting you change it as long as it’s not a beemergency. And the one-day akrasia horizon () is maybe a surprising amount of complexity. (Is it conditional on being a beemergency day? How do we convey both the current and upcoming deadline? How do we ensure you’re never caught off guard by the switch? And just the anti-magic violation of having an additional flavor of akrasia horizon with new magic constant – a day vs a week.)
If we crudely partition those votes, we have 26 in favor of paternalistic restrictions on deadline snoozing and 12 in favor of laissez faire.
I think that’s leaving me feeling mostly good about the new status quo of just “no touching the deadline when in the red”. Especially with the new “maybe just cry Uncle?” nudge, which may not have been on the table for much of the voting from the feedback spreadsheet.
As context for the Uncle button thing: we added that because people were just pressing it and then demanding refunds, which costs us money (and a lot of support time). The point is mostly to ensure people read the pop-up, which many people point-blank refuse to do unless you absolutely force them.
Given that, it’s possible we could have the best of both worlds somehow, e.g. introduce some kind of checkbox for the first time someone sees it where we say “don’t make me confirm in writing again in future” – analagous to “remember me on this website” or “always allow popups on this website” type dialogues.
(I know this adds to code complexity, but please please please don’t take that confirmation away entirely, I have entirely had my fill of arguing with people who didn’t read the popup and then had regrets! )
I think this feedback (“ 7 votes: allow me to change it now while I’m thinking of it, but it won’t take effect until tomorrow”) is mostly motivated by people who only think about their deadline time when they’re confronted with the goal being due earlier than they want. So the goal being in the red is a trigger to go change the deadline, and people would find it onerous to be blocked from making the change while they remember.
IIRC, someone described that as something that would feel actively malicious and moneygrubbing, because it forces them (an akratic person using Beeminder to help them with forgetfulness and akrasia) to remember to and bother to do the thing at a time other than when the trigger to do so is happening – the exact phrasing might not be right, but that’s the gist! So that feedback kinda stuck with me and worries me about the current setup, that people might feel we’re deliberately trapping them with a deadline they’ll never remember to change.
I suppose one partial answer would be to make sure the support team can help them out of that hole. We were also bound by the 6-hour limitation, even when adminning someone else’s goal; if we aren’t bound by the restrictions now, we can intervene in that situation on the rare occasions it comes up.
Another answer is, of course: look, as soon as you put data in, you’ll be able to change the deadline, so you only need to remember until then! But I’m not sure how satisfying that is.
Completely agree. Given all the boundaries that we put around relatively benign things, the instaderail-without-confirmation was counter to the UX expectation that we set pretty much everywhere else.
It was always a surprise how abrupt and guardrail-free pressing that button was. And I feel as though I pressed it regularly!
17 votes: the akrasia horizon should apply to changing deadline
11 votes: snoozing is fine and should always be allowed
7 votes: allow me to change it now while I’m thinking of it, but it won’t take effect until tomorrow
2 votes: the fact that you emailed me about snoozing the deadline made me realise I could use it to cheat, which I’d never considered previously
1 vote: it should be up to me whether changing the deadline counts today, tomorrow, or in two weeks
)