Weekends?

That wouldn’t work because it’s 5 / week averaged out. So at some point on Thursday or Friday it’d tell me I was done for the week, but then I’d have to work on a Sunday.

hmmm ok. :frowning:

Also really curious what @mary thinks about all this! I think we could use some philosophical help.

That sounds like a reasonable objection. Do you see why others want something like that, though? So that a break really is a break (that is the purpose of weekends off, right)? Could you live with one of the other styles I listed in my examples a post or two later?

I think I’m just repeating the same thought behind weekends off here, but maybe the following illustrates more clearly why this matters to some people, and why I suspect that your “doesn’t generalise” complaint is a temporary failing of beeminder rather than something fundamental to the problem: In my own system, my thought is to have it to know the difference between repeating breaks (e.g. weekends off for a work goal), ad hoc breaks (“I need a break from swimming to enjoy it again”), and flat spots (“I’m doing OK on this and need to spend more time on that; I’ll set this to zero rate for a week”). A flat spot is just a goal rate that happens to be zero – i.e. nothing special. A break is a special case that the system knows about (the distinction between repeating and ad hoc breaks isn’t really relevant for the rest of my post).

Why the distinction?

  1. I’m getting to the start of a 30 day break (not merely a 30 day zero rate stretch). Let’s say before I added the break, I had 1 day safety buffer. I don’t want to see “you have 31 days safety buffer”, because that’s a recipe for slacking before the break and pain after it. I want to see “you have 1 day safety buffer”. When I’m getting to the start of a 30 day stretch of rate zero, because I want to focus on something else more, I do want to see “you have 31 days safety buffer”.

  2. I’m getting close to the end of a 30 day zero rate period (not a break). I want to see my safety buffer falling and start doing the goal again (maybe I was a bit low on safety buffer going in). If it’s a break, I don’t want to see that goal at all over the period of the break. That’s what a break means to me. And because of that, the system tried to make me build up the right safety buffer going in (see 1.).

Caveat: I haven’t implemented that yet, and that’s usually where it all falls apart and I discover why my thoughts make no sense :wink:

1 Like

Following up on zero rate vs. breaks (and hoping that my plan above isn’t shot to pieces shortly after I post this ;-)):

I have the impression beeminder is a little bit like this all over: quite generalized in a mathematical sense, where maybe it would be easier to change and experiment if the system had a bit more “domain knowledge”. I’m thinking of things like:

Some of these things are very cool and make me wish my brain worked as well as bee and dreev’s, and some of that kind of mathematical simplicity allows for needed “slack” that lets different customers work in their different ways, but I suspect too much of that may make it harder to keep beeminder working while making changes to explore different possibilities. I think that’s important because I’m quite sure there’s more space to explore, and because if beeminder had bigger success more people would benefit.

Of course this is very easy for me to sit here and idly say, and very hard to actually do well, especially in a production system with actual customers :slight_smile:

1 Like

Ha, maybe that’s what’s being fixed here right now (I wasn’t aware of it)? Megabreak: Mega-Wishlist

Responding to a few different comments:

If you take a step back, I expect Beeminder to treat a “X days off goal” the same way it would as if those days literally did not exist. As a thought experiment:

In my mind the vanilla Beeminder product (before the weekends off feature’s bizarre implementation) would have been the perfect implementation of a “days off’” feature in the hypothetical world where each week has 8 days, and every user has just happened to choose to have “Flubturday off” in their settings. The UI never says things like “Well I colored this green instead of orange because you might enter data on Flubturday”. No! The UI says “I know this goal has Flubturday off so I’m not considering it even though, yes, in the ‘real world’ there’s a Flubturday in between today and the eep! day for this goal”. On Flubturday time is stopped (but only for goals with “Flubturday off” of course!)

And when you Retroratchet, you don’t end up shifting a “break from Flubturday” into a regular day. The current Weekends Off implementation says “Well, you have a flat road on Saturday so I’m going to gobble it up when you Retroratchet” but the correct answer should be “What on earth is a Saturday? This is a Weekends Off goal”.

2 Likes

So many different confusing things going on in this thread but let me try to at least give some quick reactions to some of the things:

  1. For now (and the Yellow Brick Half-Plane project is about to make this more consistent) colors should just indicate number of safe days. If it’s Friday and you have weekends-off and you’ll have a beemergency on Monday, you have 3 days of buffer and your goal is green. There’s a sense in which that’s really 1 day of buffer and orange, but Beeminder should not try to be clever about that.
  2. At least not yet. We have another project in the works (for some definition of “in the works”) called True Breaks where scheduling a break, including turning weekends-off on, means a literal gap in the yellow brick road where there can still be datapoints plotted but it doesn’t matter what they are. When that’s deployed we can consider whether it makes sense to be smarter about the colors and how we count safety buffer.
  3. Our current implementation of weekends-off and what happens with future scheduled breaks when you ratchet and how these things all interact is a minor travesty and we are definitely working on that. Mary has dubbed it the Playnice Project internally, as in, “making different features play nice together”.
4 Likes

This makes me so happy. :grin:

1 Like

So suppose it’s Tuesday and goals A, B, C, D all need data entered by Monday. So you have 6 days to get those 4 things done.

Now if A and B are weekends off goals, and B and C are also Thursday off goals, under your proposal, the interface would show:

A: 4 days
B: 3 days
C: 5 days
D: 6 days

That just seems incredibly confusing and not helpful for planning when they’re all due next Monday.

On a side note, I’d like to wish you and everyone a very happy Flubturday!! :cake: You may also enjoy this traditional Flubturday story about a secret integer between 3 and 4.

1 Like

I feel like your example proves my point, so either I’m misunderstanding it or something else. :slight_smile:

When you eyeball the list of days, goal B shows the smallest number (3). And isn’t that rightly so? If you are going to procrastinate on a goal, goal B is the most dangerous because it is the most vulnerable to derailing. If we’re thinking in units of days, goal B only has 3 chances to get worked on before it derails. Compared to goal D which is sitting pretty, you’ve got 6 chances to work on D or punt before it is actually going to derail.

If you showed all four of the goals as “6 days” you would think they’re all equally in the green and then you’ll get bitten when it turns out that the four goals are actually in very different levels of danger.

1 Like

I felt the same way. :slight_smile: My first thought on reading the example was, “YES! PERFECT.”

1 Like

I’d get very confused if it didn’t tell me the actual number of days, as in calendar days.

You can still work on it during the other days, though. It just can’t derail on those days, and the slope is 0, but you should still be able to enter data.

@drtall, @grayson: What if you have a goal due Monday afternoon? Should it really be in beemergency status all weekend?

Or, what if you have a goal with slope 0 on Weds and slope 0.1 on Thurs. Why should Weds have the clock off but Thurs have the clock ticking?

That would be ugly, I agree, but I think the idea is that this way, it will already be in beemergency status before the weekend, and you’ll work to get it out of beemergency before weekend hits.

This had us super confused for a while since you don’t actually have the new YBHP setting turned on, so nothing should’ve changed for you (yet). Are you sure that you are seeing different behavior even without YBHP turned on? Recently different?

1 Like

I feel like “[the] sense in which that’s really 1 day of buffer and orange” is the only sense!

I am kind of feeling like a crazy person. I’ll just try one more time and then be done try to persuade people. :slight_smile:

I wonder, do we not actually agree on what a safety day is? My definition of “safety day” is roughly:

A day during which you could work on your goal, but you won’t derail because you accumulated a buffer.

For a Weekends Off goal, a Saturday can’t be a safety day. It’s impossible to derail on a Saturday. You’re not spared the derail because you have a buffer; you didn’t “spend a safety day” every Saturday you do 0 on the goal. You’re spared the derail because weekends don’t exist. It’s a day for which the goal doesn’t apply in any sense whatsoever.


Try counting the number of hours to derail instead of days. If it’s 00:00:01 Friday and the goal derails 23:59:59 Monday, you’ve got 47.99 hours to work on the goal. That’s orange in the world I’m from.

I don’t care about “safety days” - that’s not a useful or meaningful measurement to me. I’ve never thought of the widgets as listing a number of safety days. I’ve always thought of them as listing the actual amount of time I have left.

What I care about is the number of actual days, calendar days, till my goal derails. That’s the actual amount of time I have to work on the goal until I get charged. I can do whatever I want with that time, work on the weekends or not, but at the end of that time if I didn’t do the task I’ll have to pay.

I agree with @dreev that Beeminder should just tell me how long I have and let me do the planning, and not try to be clever and confuse me by changing the time measurement in a non-obvious way just because I set weekends off.

It’s like the dress that appears different colors, or the Laurel/Yanny audio file - apparently to some people it’s obvious that the widget should say “3d” when you have 3 calendar days to go, and to others it’s obvious that it should say “1d.”

The problem is that weekends-off goals aren’t necessarily clearly marked as such, so seeing that “1d” would be misleading and alarming when you really have all weekend to do it - 3 calendar days.

I want to be able to plan what I do over the weekend and the next week, and to do that I have to be able to see the exact amount of time I have till derailment. Let me figure it out from there.

Also, your approach doesn’t nicely generalize - what happens when it’s no longer binary on/off days, but the slope is 0 on Weds and 0.1 on Thurs? Do we count Thurs as a tenth of a safety day?

2 Likes

But in actual fact, you do have 96 hours to work on the goal. Beeminder shouldn’t pretend that that time doesn’t exist when it is actual time that will pass and you need to plan how to best use that time.

2 Likes

Ooh, this could be another case study for my future article on The Anti-Magic Principle (rough notes thereon). What is the dumbest, most predictable thing Beeminder could do? Just a plain old countdown. No attempt to be clever and factor in upcoming breaks.

2 Likes

Can I check that somewhere? I know that something changed maybe 1 or 2 (3?) months ago and since then I’ve been working on weekends fairly regularly as a result. I raised once or twice in support emails, but I was told that the feature was being retired / deprecated or phased out. For a while I could still use the iPhone and iPad apps which continued the old functionality (of colouring that respected the weekends-off) but last week that was also phased out and so now there’s nowhere to find that functionality. (Hence my post here).

2 Likes