If any part of Beeminder thinks I’m going to check on or update a weekends off goal on the weekend, then it has failed to understand what “weekends off” means.


I’ve been ducking out of the resulting technical / practical part of the conversation because it’s the place where I’m least able to have something to contribute.

The only thing I’d slightly push back on is the idea that this is something unusual in terms of my behaviour. In fact, I’m fairly sure I can date my adoption of this way of using BM to this specific blogpost. In it, the green-ness of a goal is the main thing you’re working to prevent. The colour (or due-ness, or staying-above-the-brick-road-ness or however we define it) is the thing we’re making sure is taken care of rather than the days-to-default.

Now I see that this behaviour has also been removed from the iphone and ipad apps. Those used to be bastions of this old functionality. Now there’s nowhere where I can see what is green or not, since green just means 3+ days till default.

“If any part of Beeminder thinks I’m going to check on or update a weekends off goal on the weekend, then it has failed to understand what “weekends off” means.”


The semantics here is getting confusing, lol.

For me, it’s important to know how many days I have to a deadline, regardless of slope, weekends off, or anything else, and to me, that’s what the colors mean.

So when you say “there’s nowhere I can see what is green or not” - well, I’m not sure what you mean by that. To me, green has always meant 3+ days till default, and the weird bug where the colors didn’t always match up to the number of days as they should has been fixed. (I must be misremembering, but I had thought @drtall had been a fierce advocate of that viewpoint - but now @drtall seems to be taking the opposite point of view.)

What does “green” mean to you?

See, I’d say the exact opposite - if any part of Beeminder thinks that days don’t count as days just because they’re weekends, then it has failed to understand what “weekends off” means.

1 Like

“So when you say “there’s nowhere I can see what is green or not” - well, I’m not sure what you mean by that.”

To me, green means ‘within the parameters I’ve set, including weekends off etc, I don’t have to work on this goal today.’ I think the discussion over what green means is exactly the issue. Beeminder had and promoted two different visions of what green means – however implicitly – in the past, it seems.

“the weird bug where the colors didn’t always match up to the number of days as they should has been fixed.”

I guess what this whole discussion was about is that some of us considered this a feature and not a bug :slight_smile: and that we mourn its ‘fixing’.


Yeah, I think that’s exactly it.

I still don’t understand how you think of green (the other Beeminder vision), though. That blogpost you linked to is completely compatible with my view of green. I’ve tried the “all greens” thing too, and I understand the idea of working on the non-greens to make them green, but I still think of green as meaning 3+ days.

Your view seems very abstract - it’s based on the number of units (“lanes”) above the road you are, right? Why do I care how many units I am above the road? It’s the number of days that matters to me. I’m curious about the motivation.

I guess because I always want to keep 3 days worth of breathing space at any single moment. If I have weekends-off enabled, this means that it needs to be actually 5+ days and then 4+ days (in the way BM seems to work at the moment). If I just followed the 3-days rule then I’d find myself working on weekends (actually, as I currently am) on a goal which is designated as ‘weekends only’ simply because I forgot to take this thing into account.

1 Like

Another hack might be to make meta-goals for Thurs and Fri to prepare for the weekend by giving yourself additional buffer.

Changing the name of the weekends-off goals or moving them all to a different part of the screen is probably the simplest, at least for now, so you stop having to work on the weekend.

Or what if you made them 5/week instead of weekends off?

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”.


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”.

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