I basically want to reset any buffers to zero every day to make sure I work on my goal every (week)day and just because I worked better today should not mean I get tomorrow off.
From the information I gathered, this could be achieved by retroratcheting. But this seems have also changed my scheduled break which now no longer fall on weekends. Can anyone explain why this should be and how to fix it?
Thanks.
Sorry about the confusion and frustration here! Part of the answer is that ratcheting a yellow brick road is inherently confusing. To get rid of safety buffer on a do-more goal when youâre above the road there are multiple things we could do:
Well, (1) has the problem you encountered, of changing the dates of the scheduled breaks. And (2) changes the eventual target value, sometimes making the goal impossible to achieve (like reading more pages of a book than exist, for example). Best of both worlds could be (3) but that can also be confusing by making the upcoming road shallower than you wanted, or if you have enough safety buffer to carry you past your next break then itâs especially confusing how to make the new road nonconfusing.
Itâs probably common for (2) to be just fine, like for open-ended goals. But (1) turned out to have the cleanest implementation. Sort of.
I think the right answer is to improve the road editor interface and let that be the only way to ratchet and schedule breaks and everything else. Then the user always has full control and sees the repercussions of all their changes, with everything easily undoable, etc.
We shall get there! In the meantime, when your road gets messed up, holler at us at support@beeminder.com and weâll fix it.
Thanks so much for reporting this buggishness! Hugely helpful to us!
I think retroratchet is really useful. It could be implemented as assisted editing for the road editor, but I wouldnât want it to go away.
Can I suggest making use of the information the user has already provided? Specifically, if they havenât entered a goal total, you should shift the road up. If they have entered a goal total, you shouldnât touch the total (see New UI date/total/rate pain point). In this case, if theyâve also entered a goal date, you should change the current segment (this is a hard deadline). If not (theyâre using total and rate), shift the goal left.
EDIT: Iâd advise adding some explanatory text to the advanced âCommit Toâ settings as well, saying that whichever fields youâve set explicitly here, Beeminder will try to preserve them as much as makes sense across ratchets, derails, and other things that change your road.
Agreed about keeping the notion of ratcheting â a simple way to shed excess safety buffer â regardless.
And @kenoubiâs proposal sounds right â shifting the road up or left (or the equivalent for do-less) depending on what subset of {goaldate, goalval, rate} the user cares about. But the amount of magic entailed should be setting off lots of alarm bells. My hunch is that the UI should only be so presumptuous â guessing the right way to adjust the road to achieve the ratcheting â if itâs also very transparent and undoable. So having this be part of the general road editor.
I think this is just a symptom of the more fundamental problem that the YBR doesnât have any notion of why each brick was created. This is why retroratchet, take a break, weekends off, derailing, etc. often interact with each other poorly.
IMHO manipulating the road would be a lot easier if it were build in layers like a Photoshop image. The road dial and retroratchet work on the same terms and you can shift that layer up or left easily. But take a break and weekends off are fundamentally not the same and ought to be layered on top.
Iâll keep repeating this until it sinks in: Every action that decreases your safety buffer* should prompt you, asking whether you understand whatâs going to happen, and give you a way to back out of it.
If just that one thing were true, the âmagicâ here would no longer be scary.
* EDIT: with the possible sole exception of âbadâ data points (e.g. negative data points on a do more road). Though it still should not be possible to instaderail yourself this way.
Reasonable! But the fully general case of asking if you understand amounts to
your yellow brick road used to have you getting to this value by this date at this rate and then to that value by that date by that rate, etc etc ⌠and now itâs going to change to blah blah blah blah blahâŚ
Or a more generic version would amount to
WARNING: this changes things about your road you might not want changed; are you sure?
But just having an undo button would help a ton.
On the one hand, itâd be awesome to be able to more easily edit the road.
On the other hand, this also sounds like pushing the burden of complexity onto users.
On the gripping hand⌠[rant] let me just hijack this thread for a bit, soz in advance.
Some of the magic that @dreev perceives might drop away if we knew explicitly whether the goal parameters were somehow ârealâ and related to the outside world, or if itâs part of endlessly striving to do/be better. (Some endless striving goals are just being tried on for size, like a 30 day challenge, which itâd also be great to support for real.)
I donât read this thread as being about the road segments, but about the symptoms that result from us hacking âbreaksâ in over top of the data structure that we had. (Not dissing the implementation, Iâm much happier to have it than not!)
Weâve got a growing list of things that should be proper entities in their own right, rather than being disguised as ordinary entries in the road matrix or the datapoints. Breaks are one, ratchets are another, derailments too.
At some point weâll sit down and revamp the entity model, and thatâll also give us somewhere to hang milestone markers and other features that occasionally come up in discussion.
Also: undo++
[/rant]
Indeed, I think this is why I ended up finding the road editor trial less useful than I expected I would. (Well, that and lacking control over the critical edge.).
Can I suggest the middle ground of âthis will decrease your safety buffer to N daysâ (or âthis will immediately derail youâ)?
The other replies here are true, but they amount to creating a big new project. I really think just doing this one fairly simple thing would make Beeminder significantly better (and reduce the amount of work I personally create for support, and I imagine other power users as well).
Ooh you said milestone markers! So glad this is indeed in the works.
Iâm liking a lot of what @philip has said here. In my experience,
is pretty much the opposite of the general road editor. I really appreciate being able to give it a try, when I want to get fiddly with a road, but I think more than half of my attempts end in emailing support to ask them to fix my terrible mistakes.
Between âretroratchet magicâ and âa perfect road editor,â I think Iâd experience the benefit of retroratchet magic more often â Iâd love to use the road editor to set of a road with a basically-exponential curve toward a deadline, with breaks/resets at key points, in accordance with my work patterns (which I am sure I could technically do now, but havenât taken the hour+ to figure out how), but I would get 80% of that benefit by being able to more reliably control the road via a real-life target and deadline. (My current annoyance is that breaks seem to steepen the road only after the break, when really Iâd like to steepen it beforehand also, and retroratchet+fixing the deadline gives me flat spots at the end.)