Right now I have a goal that’s orange. It has 21 days of safety buffer, but also has a long take-a-break with a rate of 0 upcoming.
In the past I’ve noticed goals that were blue when I’d expected them to be green. It seemed to have to do with not entering data for them that day, but then again, I have many goals I haven’t entered data for that are green.
I’ve heard that “do less” goals have unintuitive colors sometimes as well, though I haven’t used them.
What is the actual logic that decides what color a goal will be?
The goal colors actually have nothing to do with how much time is remaining (days of safety buffer).
The colors are determined by the quotient of your current headroom (measured in units not days) and your current road slope. (For weight loss goals there used to be (still is?) automatic adjustments to the road width based on data you enter) This determines your “lane” on the “road”. The positions are colored red (off the road bad), orange (wrong lane), blue (right lane), and green (off the road good).
TL;DR for a goal whose slope never changes (implying also that you never derail) the colors correspond to number of safe days. But if you ever change the slope (or you derail), all bets are off and you will need to do some maths to figure out what the colors mean.
Hmm, if that’s a special case, would I get more intuitive (to me) colors if I used an extremely small non-zero slope for my take-a-breaks?
EDIT: Or I could set the road width manually, but I do want it to be automatically determined when I’m actually adjusting the goal slope vs. using take-a-break…
Yeah, the more I think about it, the more this is turning into a feature request / bug report for the colors to be based on something understandable like number of safe days (perhaps with a dial for how many safe days would trigger blue / orange / red).
Thanks so much for what is indeed a bug report. The only sane thing is for color to represent actual days of safety buffer (red 0, orange 1, blue 2, green 3+) and we are definitely working towards that. There’s a stupid amount of technical debt to deal with and … wait, deja vu:
If you really want the colors to correspond directly to days of safety buffer… you’re already calculating days of safety buffer accurately (at least, way more accurately than the colors). Shouldn’t it be very easy to just change the color selection to be based on the same thing as the thing at the top of the goal page that tells you how long it is until you derail?
I think you’re right, this needn’t depend on the full Yellow Brick Halfplane revamp. At least for non-noisy goals. For noisy (eg, weight loss – goals with auto-widening yellow brick roads) things are a bit messier but that’s a sub-mess that we’re also cleaning up.
To help prioritize, is this especially irksome because you find the colors really throwing you off? I agree it has to be fixed regardless, I just want to get a sense of how acute the pain is here.
It hasn’t been that bad yet, but due to the way I use take-a-breaks it would make an all-green goal basically useless for me, which is something I’d otherwise like to try. And having too many goals that are frequently close to derailing is a serious problem for me, so this is one level removed from a serious problem.
While we’re talking colours: I would like my goals not to go red until the morning of the day that I need to do something. This is the biggest thing stopping me from making the most use of arbitrary deadlines; I like reducing the number of red goals on my dashboard as the day progresses, not have them mount up because of things that are due tomorrow.
While we’re talking about feature requests for the colors: I’d love it if “seven or more days of safety buffer” could use a darker shade of green. That would give me a visual cue to take action on green goals that are “near” becoming non-green, and safely ignore goals that are “far” from becoming non-green, when I’m prioritizing what to work on each day.
Would anyone else be interested in this change? (Please “like” this post, if so.)
Bearing in mind of course that ‘days of safety’ only applies on predictable monotonic sorts of goals. It’s a nonsense on weight graphs and gmail zero goals, for instance.
Longer term I’d actually like to make safety buffer be meaningful for weight loss and inbox zero goals by generalizing the Pessimistic Presumptive Reports that currently are only used for Do Less goals. This is an ongoing debate with @bee but I think I’m going to win eventually.
Here’s my latest thinking on it: First, assume we’ve switched to the yellow brick halfplane new world order where there is no centerline or lanes of the road. Instead there’s only the critical edge, plus colored zones indicating how close you are to hitting the critical edge. [1] Next, we ask you as part of goal creation what’s the most amount of weight you can gain in a day or the most your inbox count can jump up in a day. That’s the Pessimistic Presumptive Report – explicitly chosen by the user.
(Technical aside: The colored zones should have width of yaw*(rate - ppr) where yaw is +1 if the good side of the road is up and -1 if the good side is down; and rate is the daily rate of the yellow brick road.)
The result is that it becomes universally true for all types of goals that you transition from green to blue to orange to red – one per day – if you don’t report new data. For example, imagine a weight “loss” goal that’s in fact just to maintain a constant weight. And say you put in 1 pound as the amount your weight can fluctuate day-to-day. Even if you get the stomach flu and lose like 8 pounds and are way below the yellow brick road, you still can’t stick your head in the sand not weighing in while you gradually end up hopelessly far above the road. You just have 8 days before the PPRs catch up to you. This also makes it much nicer for maintaining a safety buffer for vacations.
In short, safety buffer needs to always be meaningful and reasonable.
[1] Totally on board with @grayson’s dark green idea, btw, which may not need to wait for yellow brick halfplane – keep clicking on her post especially if you don’t want to wait that long!)
I have a good number of goals that are meant to track the oldest item I
have in an inbox, like my todoist inbox, or my gmail inbox, or even my
oldest pocket item.
I currently have scripts set up that post the age of the oldest thing in
either hours or days, and they run every few hours automatically.
This means that if I do nothing, and my last posted data point is not zero,
I would like Beeminder to expect that my value will increase at a rate of 1
or 24 per day, depending on my units.
While I’m not necessarily pro-this PPR thing, it would be slick for me (who
is admittedly a weird Beeminder user), if I could get Beeminder to know
that these datapoints will increase on their own if I do nothing.