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:
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.
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.
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”.
I feel like your example proves my point, so either I’m misunderstanding it or something else.
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.
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?
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.
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?
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.
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.
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).
@strickvl, did you perhaps change the absolute lane width parameter on your goals 1 or 2 months ago? (It’s under Custom at the bottom of the Settings tab. If that doesn’t sound familiar, then this isn’t it )
I can’t agree. If Beeminder is going to treat me like I have more time than I do, there was nothing gained by Weekends Off that wouldn’t have been accomplished by some dumb script to flatten the road automatically.
The mistake here is thinking that the slope of the road being 0 is the same as the day being a day off. This is related to the above comment as well. If I have a goal that is Weekends Off that also happens to have 0 slope on a Wednesday, the Saturday and Wednesday are not equivalent. For example, a Retroratchet should be able to gobble up the flat road on the Wednesday but it cannot alter the Saturday.
Edit: To be clear, the “yellow brick road” data structure is insufficient to represent what I claim is the ideal implementation of Weekends Off and I think that is why there are so many bugs related to how Weekends Off interacts with other parts of the product. When you treat Weekends Off like just another 0 slope brick you end up with lots of problems. Maybe I’m not right about what colors things ought to have but I’m pretty sure I am right about this much.
I have just discovered that there is still a vestigial part of the old way of being in the Beeminder code. (I hesitate to describe it here lest you take it away from me, but perhaps it helps me in the meanwhile).
Even though the full goal borders don’t turn blue when a goal is due, I have realised that the dot that is currently positioned showing the current status of the goal moving up (or down) the graph actually DOES show the colour (blue or orange) that takes into account weekends off etc etc as described above.