What do the colors actually mean?

[kenoubi]

The colors are determined by the quotient of your current headroom (measured in units not days) and your current road slope.

This doesn't seem to be true. I have a goal which is orange and has a current road slope of 0.

(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).

This does seem to be true though; I am visually in the "wrong lane" of the road.

[drtall]

Oh I think when the slope is zero it uses the next non-zero slope in the road?

[kenoubi]

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

[drtall]

I think so but you might want to test it and find out. I've mostly trained myself to ignore the colors.

[kenoubi]

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

[dreev]

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:

How is "days until wrong lane" being calculated?

Yes, but it's a big, very multi-faceted fix that involves getting rid of the whole concept of lanes of the road and how we've treated the centerline as most fundamental. What's now obvious (and thanks to @insti for making the case for this) is that the only thing that matters is the critical edge of the road and that's what the road dial should adjust, not the centerline. We're calling this project "Yellow Brick Halfplane".

[kenoubi]

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?

[dreev]

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.

[kenoubi]

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.

[philip]

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.

[drtall]

Thanks so much for what is indeed a bug report.

This isn't exactly new. I've been posting about this for years:

New feature: Dashboard view

I feel like color coding by number of safe days remaining would be a lot easier to understand. Take a look at my dashboard: [image] I don't think a newbie would ever infer how the color scheme works without referring to the hidden graphs.

[dreev]

isn't exactly new

I know, I'm just grateful for people reporting bugs, even known ones.

[grayson]

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

[philip]

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.

[grayson]

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.

Right, but this thread requests making the colors track days of safety buffer rather than road lane, and Danny himself says above:

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.

So my request is an extension to that request / fix.

[philip]

Absolutely. I even added my vote by 'liking' the suggestion.

My conundrum is that for some goal types there is no such thing as 'days of safety buffer'. Do we need a colour to represent 'who knows?'

[dreev]

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!)

[adamwolf]

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.

[kenoubi]

Addendum: Beeminder is actually inconsistent with itself about colors! When you load the goal page for https://www.beeminder.com/kenoubi/bike (for example) the HTML returned says <span class="doom blue" data-doom="2147306399">, but then the Javascript doom counter immediately changes it to green. The behavior of the updateDoom function is responsible for this (IMO better) behavior.

@dreev @bee Would you consider just changing the API for roadstatuscolor to match this code (from the Beeminder Javascript that updates the doom counter):

  function doomColorClass(doomStamp) {
    if ($(".goal-panel").data("coasting")) {
      return "green";
    }
    var doomDate = moment.unix(doomStamp + 1);
    var now = moment();
    var diff = doomDate.unix() - now.unix();
    var days = Math.floor(diff/(24*60*60));
    if (days < 1) {
      return "red";
    } else if (days < 2) {
      return "orange";
    } else if (days < 3) {
      return "blue";
    } else {
      return "green";
    }
  }

I don’t think this would be very hard. The field appears to be undocumented, so it shouldn’t break anyone who’s only using the documented API.

That would fix it everywhere… in the meanwhile I have some hacky Javascript that works for the web, but I can’t do much about mobile. (Actually, I’m not even sure whether mobile uses roadstatuscolor rather than recomputing the color itself… but it should use roadstatuscolor )

[nectar]

That would fix it everywhere… in the meanwhile I have some hacky Javascript that works for the web, but I can’t do much about mobile. (Actually, I’m not even sure whether mobile uses roadstatuscolor rather than recomputing the color itself… but it should use roadstatuscolor )

Both the Nectar mobile app and the Beeminder watchapp use roadstatuscolor. We wanted consistency with Beeminder’s apps.