request: postpone big-break option

[wolftune]

Sometimes I am not in position to take a big break until some work is done. I can still do small breaks. "Take a small break instead" is a one-time decision, and I don't want to keep having to choose that in this case.

What I'd like is a postpone function that only acts on big breaks. I'd like to say postpone-big-breaks-for-90-min rather than just postponing this immediate one or postponing all breaks.

[AllanChain]

Great suggestion! The postpone feature definitely needs some rethinking (see also #106 and #107). I'll take some time to think this through carefully and come up with a good solution.

The goals are:

1. Let users postpone breaks when necessary — for example:
   • They're in a meeting.
   • They're handling something urgent. (Better only postpone big breaks in this case.)
2. Discourage habitual postponing — because sometimes:
   • Users are "in the zone" and don't want to stop, even though they should.
   • Tasks feel urgent ("I need to finish this today!"), but really aren't time-sensitive.

[wolftune]

I wonder if there's something to be said for a prompted-postpone like just brainstorming… something like asking if I'm ready to be back to the break-routines. That's dangerous in a way… but I'm thinking about how to have a postpone function when I need it without the temptation/habit of using it too readily.

So, say I'm in a meeting and I'm not sure if it will last 30min or as much as 60min. Today, I might postpone for 60m to be sure not to get interrupted. But if there were a postpone mode where a prompt showed up asking if I'm ready for taking breaks again… that would not be as intrusive as being told to take a break. I could tolerate that coming up in a meeting sometimes maybe (speculating here), and so I might turn that on and click "continue postponing" a few times until I'm ready to be back…

Here's what I'm imagining:

• I want the least amount of reinforcement of a habit of going over to the postpone function
• I do have times I need to not be prompted for any break
• I do have times I need to be not taking big breaks

So, maybe there could be postpone-all-breaks-for-now mode which could be set so that it checks after a preset amount of time "ready to do breaks again?" and again after that if I say no. And there could be another postpone-big-breaks-for-now.

So, my choices normally are: let it go as usual, postpone-all, postpone-big (and maybe not with a set of time options, though if they existed it would be how long before the first prompt to turn off postponement)

The conscious decision to not return to breaks feels different than saying "aigh no break now, postpone!".

I'm thinking this might really resolve some issues here. For one thing, saying "yes" to going back on break routine wouldn't itself trigger an instant break, so I could manually trigger a break, but it would be set to be inviting because I'm welcoming that the break can indeed return in a few minutes from now…

[Cwpute]

Wen you're working on something that you don't want to be stopped by a break, are you able to tell when this work should be done and when the big break would be able to start again ?

I can see myself postponing a big break, saying "I must do this work now, i have until 1PM then i'll be eating and i can resume big-breaks after that" so essentially instead of postponing by relative time ("show big breaks again in X minutes from now") you'd be postponing until a fixed time ("re-enable big breaks after 1PM today") which anchors you a little more in a whole day's work instead of minute tasks that you could lost yourself in (this happens to me quite a lot, hence my use of Sane Break).

So in your use-case, you'd postpone big-breaks until the time of the day when the meeting should be over.
This is still compatible with your idea of asking the user whether they want to re-enable big-breaks or not ! if the meeting isn't over for example.

[wolftune]

Yeah, I'd be fine with postponing being until a clock time rather than a number of minutes

[AllanChain]

I have created a parent issue at #116 to focus on the next-version plan. Perhaps we can move discussions there and address the next-version design as a whole.