"Rate cannot be 0"


#1

Trying to create a new goal and getting this error.

Why can’t my rate be 0? I don’t want to set it now. I want to use the road editor / “advanced” road dial to set up my road.


#2

It did let me set the rate to 0.000000001 (I forget exactly how many zeros), which was functionally identical for my purposes. But that makes it even more pointless to prevent it from just actually being zero.


#3

Hm, yeah, that’s a pretty good point, especially with the 0.00001 loophole… I think there was some philosophical reasoning behind this - along the lines of “the entire point of beeminder is to commit to doing something in the future, and a goal with an infinitely flat road isn’t committing you to anything, so let’s not allow that.”

I can see why it’s frustrating if you actually know what you’re doing and know about the road editor, though.


#4

Having also run into this issue, I think this would be better handled by a pop-up warning along the lines of “Are you sure? You’re not committing to make any change if your rate is 0.”


#5

Yeah, I can see why it might sound like a good idea. I just don’t think it actually achieves that.

Another legitimate reason for starting with a flat road might be “I want to start Beeminding this, but I have no idea what the rate should be, so for now I’ll just collect data and later I’ll dial the road to something that looks reasonable”. Which I suppose you could work around by setting an enormous initial flat spot, but again, why should you have to?

There’s nothing necessarily magical about 0, either. Say I want to Beemind sleep. Setting an initial rate of 8 hours / week would be just as useless as 0. The latter is at least obviously fake, whereas I could misread 8 hours / week as 8 hours / day.

So while I appreciate the intention behind it, I don’t think it’s possible for Beeminder to force you to set a useful road, and I don’t think “disallow 0” is close enough to doing that to justify disallowing it.


#6

This also doesn’t make sense, since you can set the rate to zero after the goal is created. You could start a goal with 7+ days of buffer and an arbitrary rate, then immediately change the rate to 0 after the goal is created.


#7

These counterarguments are excellent but I still think there’s a lot to be said for hard nudges and opinionated software. It used to be horribly common for newbees to set the initial slope to zero for lack of having thought of something better. Then Beeminder would just never make them do anything and all the mustering of willpower that made them set up the goal was wasted. Or, worse, they’d not understand anything about setting slopes of yellow brick roads and such and Beeminder would just seem broken.

So Beeminder saying “no, a zero slope defeats the whole point” is not crazy. If you’re sophisticated enough to know that you really do want a zero slope then prove it by working around it (the 0.000001 trick or dialing it back to exactly zero after you create it).

I also appreciate the argument that we should just give you an “are you sure?” pop-up. But the counterargument is that users just breeze through things like that without reading them. (It’s pretty amazing how much that’s true, even for super nerdy users. [1]) So making you think about whether you want a zero slope instead of telling you to think about it might be important. Or there may be a different UI that achieves the best of both worlds!


[1] Funny story: I once submitted a Beeminder bug report (probably by complaining to @bee) because some UI thing (I forget what now) wouldn’t let me click on it. Right next to the unclickable thingy was a little block of text, that I myself had written, explaining, with much wit and eloquence, I’m sure, exactly why the thingy was unclickable. My eyes passed right over it and I jumped to the conclusion that there was a bug because I had an expectation and the UI violated it and it just seemed obviously buggy. The point being: (1) designing stuff is hard, (2) I’m an idiot, (3) as both a user and a designer. But also, even hardcore Beeminder users are totally like that and adding words to explain things is usually a bad idea. You have to make the right thing happen when the user breezes through the UI on autopilot.

This concludes my defense of not letting you create a goal with a zero slope.


Breaking things with a fake goal for API tinkering
#8

I think I have a better idea: goals should derail if you never enter any data. Sort of like pessimistic presumptive reports but for all goals. Premium users should probably be able to turn it off, but not new users.

This forces users to actually pay attention to the goal. By doing that, it also creates a touch point where you can suggest that they change their road – not just away from zero, but potentially other suggestions, like noticing that a goal appears to be too easy or way too hard. (You should probably be able to turn those off too though; maybe you want this particular goal to be very easy, or it guesses wrong about how hard it is for some idiosyncratic reason.)

Anyway, as a moderately advanced user, I find the goal creation process pretty laborious. My preferred goal creation process would actually be nothing but name the goal and choose whether I want autodata or not, and then Beeminder creates a zero road, turns on custom for me, and dumps me into the road editor. Yes, seriously. This error message was just one more hurdle to actually setting up my goal the way I wanted it.


#9

Indeed. FYI this particular thread is steps #6 and #7 of the goal creation nightmare: New goal road dial


#10

Seconded. Defaulting to a nanny-bee auto-slope setting à la @chipmanaged would seem to be just the ticket; it starts at zero and then finds the level of average actual effort.