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.
Especially if you have multiple goals that track different aspects of one of the same thing!
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!
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.
Why is it currently so difficult?
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).
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?
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.
You derail when you were in the red yesterday and are in the red today. See
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.
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.
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:
Thanks so much for the nigh-infinite patience, everyone!
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:
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.
Yes! This is what I’ve done when I needed breaks.
Also, the inability to changing settings for multiple goals at once came up as #2 in the annoyingness poll:
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!
Almost. What I think is still true and horribly confusing is:
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”.