The interface is not letting me retrorachet to 0 days (for a goal that just recently derailed). It is requiring a minimum of 1, but this is a goal that should always be in the red.
The exact message I get is:
Number of days cannot be less than 1
This is intentional, not a bug. If you retroratchet the day after a derailment, you will immediately derail again because it looks like two days in the red.
It’s a thing that’s being worked on; in the meantime, you’ll be able to ratchet tomorrow(/the day AFTER the derailment).
While it may be “intentional” as a patch to deal with the “two days in the red” bug, I disagree that it’s not a bug. It’s still a bug in its own right:
- The error message is very confusing from a new user’s perspective
- Retroracheting to 0 works most of the time, but not the day after a derailment, but this is nowhere explained to the user, and the error message reads as if it is never possible
- There is an odd situation where if you log a data point, you can retrorachet again sometimes, even if you did derail the previous day
- This is still not how it should work, both because two days in the red should not derail you, and because users should be able to keep the continuity of doing the action every day
- From the point of a just-in-time user (doing things only when they’re in the red), it is important to always be able to retrorachet to 0 so you keep up the streak of doing the action every day.
As I said, it’s something that’s being worked on – no need to convince us, we’re already convinced! Though it’s good to know how much people want a thing, and all feedback is good feedback to us.
Given the current set-up, the “odd situation” with adding data and then being able to ratchet is not odd at all: adding the data prevents you from having two consecutive days in the red. So it’s all of a piece, rather than an extra issue.
I don’t understand this. If I add data and I’m still in the red, shouldn’t that still be two consecutive days in the red?
Even if the data you added is for the previous day (when you were in the red) and wasn’t enough that we could fix the road, you’re now at the center-line of the road post-derailment. Most of Beeminder’s goals are cumulative, so adding any data will push your most recent datapoint higher above the road and potentially prevent the ratchet causing two consecutive days in the red.
I may be wrong about how it works since my job is fixing derailments and answering more basic questions, and anyway this is probably going to be moot once you’re able to ratchet straight after derailment. But it makes sense to me and I don’t think it’s actually inconsistent.
I think everything in this thread is entirely correct. Quick summary/clarification:
- It’s super dumb that we don’t let you have an eep day the day after a derailment (I’ll say more about that in the other thread – http://dreev.commits.to/clarify_2-red-days-in-row_bug).
- If we don’t fix that soon then it’s worth improving the UI and/or error messages and/or documentation to make the user understand that eep days the day after derailments are not possible currently, and, embarrassingly, cause an insta-derail if you somehow force them to happen. dreev.commits.to/either_fix_2-red-days-in-row_bug_or_improve_UI_or_docs
- Agreed that the poor error message alone counts as a bug even if we rationalized the underlying beehavior.
- Well said about the beehavioral economic reason this is important. Beeminder is all about catering to edge-skaters.
- We’re super grateful for bug reports – keep them coming!