Request: Easy way to schedule a break for multiple goals simultaneously

[narthur]

Often, when I need to schedule breaks, I need to schedule breaks for the same time period for multiple goals. Right now this is a somewhat tedious process of opening multiple tabs and then adding the break to each one individually. It would be great if there was an interface much like the reminders management interface where I could tick the boxes on all the goals I need to schedule a break for, enter the date range, and hit save to add the break to all relevant goals at once.

[phi]

Especially if you have multiple goals that track different aspects of one of the same thing!

[shanaqui]

I think we recently had another thread about this! In general, we’re kind of opposed to the idea. My thoughts on it last time it came up!

[drtall]

I’m still mildly optimistic that writing a tool to do this via the API will be non-nightmare difficult level after yellow brick halfplane launches.

[zedmango]

Why is it currently so difficult?

[drtall]

It could be that I’m just dumb. But I ran into problems accounting for the width and how it changes relative to the rate you want. It’s possible that 0 slope road is a special case that isn’t horrible, but I had trouble dealing with the general version where you want to be able to say “The critical edge of my road will be at X on date D” because you have to mimic the math that Beeminder is going to do as it transforms the center the road (the thing you control) into the critical edge (the thing you care about).

[phi]

@drtall

[…] after yellow brick halfplane launches.

Aaand just a few blog posts, a couple maniac week time lapses, more blog posts, the dollar sidekick company, …, later… The sun has set and yet I still don’t know what this glorified golden halfpipe is other than “everything depends on it!”. Something tells me I should set up a do-less goal for Beeminder blog posts. /Sigh/
I thought the js graphs are going to be the new cool kid in town but apparently this takes the biscuit. So, what is it?

[drtall]

Imagine a rate tracking system where you specified something like “On January 1, I’ll start doing 10 units per day and if my average rate falls below that ever, I’ll call it a ‘derail’”. Beeminder is not that system.

If you have a flat road for a Beeminder goal and then set your road dial to “10 units per day starting January 1” you probably won’t derail if you do 9 units that day instead. This is because the goal’s road has a “width” which is the thing that creates the “lanes” and all the related concepts.

The road width on Beeminder goals is dynamically calculated based on a number of factors such as its current road slope. So when the slope of your road changes, the width changes. But it gets better because the graph UI renders your graph using today’s width at every data point. So if you’re looking ahead or looking behind, you can’t see the width as it was yesterday or the width as it will be in the future.

You derail when you’re in the red relative to the width as it is today, so if you want to make prospective edits to the road or even just guess “Will I derail tomorrow if I do X units?” you need to understand all this stuff and be able to model the width system in your mind or code.

The “yellow brick halfplane” project is the effort to turn Beeminder into the simple system I described in the first paragraph. One where your road dial and the derail behavior match directly.

[zedmango]

@drtall

You derail when you’re in the red relative to the width as it is today

You derail when you were in the red yesterday and are in the red today. See

Mother of Bugs: Two Consecutive Days In The Red

Currently, as I understand it, Beeminder has a patch to fix some problems, and this patch makes it so that the derail condition is something like: IF you were in the red at your last deadline, and IF you will be in the red at the next deadline if no additional data points are entered, THEN derail. This is, of course, a counterintuitive derail condition that will often cause derails when it shouldn’t. Because of this problematic derail condition, numerous other patches were introduced to fix…

@drtall

The road width on Beeminder goals is dynamically calculated based on a number of factors such as its current road slope. So when the slope of your road changes, the width changes

My understanding is that this has changed and the colors are now based on number of days since derailment - it would be helpful if @dreev or @bee could confirm!

[drtall]

@zedmango

You derail when you were in the red yesterday and are in the red today

My point was that the definition of “in the red” depends upon the width of the road. I understand the strange semantics of derailing but I didn’t think it was relevant.

@zedmango

My understanding is that this has changed and the colors are now based on number of days since derailment

Sorry but I don’t know what the colors have to do with what we’re talking about here. Changing the colors to be based on days until derailment instead of lane doesn’t change the relationship that the road dial has to the derailment semantics.

[dreev]

@drtall

Imagine a rate tracking system where …

I was going to link to my YBHP summary but @drtall’s is actually way better! This did induce me to update that thread though:

Progress Report on Yellow Brick Half-Plane

Content warning: Way more nitty-gritty than an end user of Beeminder could reasonably care about. But maybe you unreasonably care about it? Either way, Beeminder is going to be way better for everyone when this is done. Background: Yellow Brick Whatnow? To start at the very beginning… The Yellow Brick Road is the path on your graph that starts at the current value of the metric you’re minding and ends at where you want it to be, or perhaps soars upward indefinitely. (Related: Why Beeminder like…

Thanks so much for the nigh-infinite patience, everyone!

[zedmango]

@drtall

Changing the colors to be based on days until derailment instead of lane doesn’t change the relationship that the road dial has to the derailment semantics

Sorry, I should have been more clear. What I meant was: my understanding is that this has changed and the lanes (along with associated colors) are now based on days till derailment.

Does that clear things up?

I asked @dreev to clarify here:

Progress Report on Yellow Brick Half-Plane

Thank you for this! Very exciting that we’re so close. Would you please clarify how the width of the new, sans-autowidening roads is determined? Is it just 1 day’s worth? And would you clarify the relationship between the width of the road, the color of the goal, and the number of days till derailment? Is it just that the lanes correspond to different colors and the colors represent different numbers of days till derailment?

[lanthala]

I now just email support with a list of the goals that I need to take breaks on, if it’s more than one or two. I already have RSI issues, clicking 8 clicks (yes, I just went and counted) for each of my 13 goals is not something I’m honestly going to put up with.

Also, my theory is that by perpetually annoying support with these requests, THEY will petition for a better system for adding breaks to goals I think this was actually something Bee suggested herself.

[zedmango]

Yes! This is what I’ve done when I needed breaks.

Relevant:

The Shirk & Turk Principle

Also, the inability to changing settings for multiple goals at once came up as #2 in the annoyingness poll:

February's Annoyingness Straw Poll

We did this in January and it was super helpful so we’re doing it again! Vote for as many as you like – whatever you think we should prioritize. And the one that ends up with the most votes we plan to drop everything and make so! (Ok, @bee says I can’t quite promise that – some of these are easier said than done – but it will strongly influence us!) poll UPDATE: Here’s the status on those a couple years later: FIXED: Graphs taking too long to generate sometimes Difficulty of changing settings…

I definitely think it’s beeminder’s most annoying problem after the lack of YBHP. The objections to it can be addressed by making the interface say something like “select goals and change a setting in the selected goals,” thus requiring the user to think about which goals to select and what settings to change, rather than something like “take a break” which admittedly oversimplifies things.

But like @drtall says, after YBHP is implemented, this will all be easy to automate. Yay!

[drtall]

@zedmango

Sorry, I should have been more clear. What I meant was: my understanding is that this has changed and the lanes (along with associated colors) are now based on days till derailment.

Does that clear things up?

Almost. What I think is still true and horribly confusing is:

@drtall

But it gets better because the graph UI renders your graph using today’s width at every data point. So if you’re looking ahead or looking behind, you can’t see the width as it was yesterday or the width as it will be in the future.

For example, suppose you’re looking at your graph today and trying to figure out what the state of the goal will be tomorrow. You use the x-axis to find tomorrow and you see where the lanes line up. So you say to yourself “Ah, I see that if I get to value V on the y-axis today, then tomorrow I’ll be in the orange.” So you do enough work to get the goal total to V. Then you go to sleep and wake up to find the goal in the red about to derail.

This is possible because the width of the road is recalculated every day and the graph lies to you. In fact, there is no way to determine where the lanes will be tomorrow if your goal’s slope changes between today and tomorrow. This is what I meant by “you can’t see the width as it was yesterday or the width as it will be in the future”.