I think this needs no further commentary than “goal value vs. goal mark in graph”.
Oh and “goal date vs. when the road actually hits the goal value”
Oh, yes, and “the suspiciously white area in the road underneath the dart disk which is probably related to the other things”
2 Likes
Ah, this is a very interesting case, related to something we just changed!
Your road specifies that you want to go down at a rate of -10 sections per day until hitting zero. Sounds simple enough but it isn’t so simple because at that rate you’ll hit zero in between June 6 and June 7. Beeminder decides to be conservative and say that that means your goal ends on June 6, even though you won’t actually be quite at zero yet. If it went till June 7 you’d be negative.
This is actually nice and clear visually on this graph of yours where you can see the red razor road hitting zero just before June 7. (And the suspiciously white area after June 6 is in fact for the exact same reason!)
So what’s the right thing for Beeminder to do in general in a case like that? Note the technical (maybe also philosophical?) constraint that your road has to end right at a day boundary – at your chosen deadline.
Possibilities:
- The new status quo where the road ends some hours early rather than go past your specified target value (zero in this case).
- Make the rate slightly shallower (never steeper) than you specified so the road ends at your specified value at the closest possible day boundary.
- Add a kink in the road on the last day, honoring your chosen rate for as long as possible.
- The UI shouldn’t let you even submit a road that doesn’t end on a day boundary, thus forcing the user to decide among the above options.
(Btw, the thing we changed was fixing a blatant bug where it would act like the road ended between day boundaries and just mess all sorts of other things up, since everything else counts on the end date being on a day boundary. I think this fixes the latest bugs @zedmango reported, for example!)
And a workaround in the meantime: include an explicit end date when dialing your road rather than letting it be inferred. Which also suggests a 4th possibility for dealing with this [now edited in to the above list!]
[Note to self: captured as test case phi-bad-aim.bb in the test suite.]
2 Likes
3 seems obviously correct to me - the goal should end on June 7, since it won’t be finished till then, and the rate should change on that last day.
That’s making sense, although it’s messy in the implementation (and maybe for user-impactful ways too – it has to be thought through really carefully) because we have to change the road that was given. I’m starting to think the better option is #4 (let me edit that in to the main list).
1 Like
If you go for #4 you need to consider the API, too. Should it allow that?
1 Like
That might be more anti-magical - just fail loudly instead of trying to make the road conform - though it may be frustrating for users who don’t understand what they have to do and why it’s failing.
This actually might be a good example of an anti-magic/POLA conflict! I think POLA would suggest that beeminder knows how to handle and adjust this type of road.
1 Like
As a user I’d want option #5: Be like #4 but instead of throwing a big fat “NOPE can’t do!” at the user, either
- offer, instead of refusing, to adjust the slope automatically: so offer to do #2 or #3
- don’t offer but just do it and then tell the user a la “We automatically adjusted the last segment of your road so it… blabla”
Because I hate having to do things that a computer could easily do for me.
I say easily but I know that having interactive (!) user interaction on a web app is not necessarily the most straightforward thing to program. Turns out: The web was not made for this (duh!)
But as a user I would frolic if this happened.
(Not that I’m saying I recommend doing this from a developer’s perspective because added complexity and stuff but one can dream right?)
2 Likes
I guess I don’t understand why a user would ever say “no, you’re right, my road doesn’t end exactly at midnight so I should reformulate it.” I don’t think the “no” button would get used much if at all. Doing it and telling the user seems like option 3 with good communication and I think that’s the way to go.