Beeminder Forum

Does Beeminder use too much jargon?

Ok, I have to ask… which half of the airplane :us: are you visualizing?

I don’t think the graph is a quarter-plane. For one thing, you can have negative data, which is meaningful for some goals, so it’s at least a half-plane. You can also add data to the past. For another, the road divides the plane into two half planes, even if some regions of both half-planes are in the past and not part of the region we’re concerned with.

It’s really a literary reference. But no, I doubt the half-plane would have been called that otherwise - especially because the whole half-plane isn’t even colored yellow! @dreev what’s up with that?! And of course you can’t really “follow” a half-plane since it doesn’t lead you in one specific direction.

Love your suggestions about land, sea, and honey zone! I personally think of it as the Half-Plane of Death, or the Half-Plane of Doom, because you die upon crossing the line! I suppose we could call it “wrong side of the tracks” as well but that might not be politically correct.


I assume that’s the project name rather than language that will be used on the website.

1 Like

Why would you assume that?

As a normal person—not a super nerd, not a mathematician, not a software engineer—I’d say @mufflon is essentially correct.

Do you want to be cultish, or do you want to be accessible? Clearly, thus far, you prefer to be difficult and cultish, which is a legitimate choice.

I find it interesting that @dreev is now asking this question.


Because “yellow brick half plane” is such an obviously laughably horrendous terrible name. Imagine encountering that as a newbie!


Because it seems quite opaque, unless you both frequent this forum and remember that much mathematics? I suppose the “yellow brick” part would make sense to some existing users, though.

1 Like

I don’t know why the region that’s yellow needs to have a mathematically correct name. Just referring to yellow (or yellow brick if you must) seems like it ought to be enough? I’m not sure there are that many outside-the-forum accessible-to-newbies references to it?

Looking through the FAQ most of the references are to something like “keep your datapoints on the yellow brick road” which could just be “keep your datapoints in the yellow”. The ones that refer to “the steepness of your yellow brick road” need more of a rewrite anyway.

By the way, I looked at which still refers to yellow brick road and keeping your dots on it, but the weight loss graph right above it clearly shows the dots wandering away from the yellow bit. The explanation will make more sense when that graph has been changed to a half-plane version.

Overall, I’m inclined to think that just sticking to calling it the “yellow brick road” even when it’s only technically got one side is probably more newbie friendly.


I agree.

  • Yellow-brick road is okay for US folks that grew up with the movies and for legacy reasons.
  • Yellow-brick half plane is a laughably bad name that is jargon-y obscure for its own sake.

However, I just don’t know how Beeminder can resist calling it the sweet spot. :honeybee:

1 Like

Different perspective:

I remember well how intimidating Beeminder was for me when I first joined, and all the jargon definitely didn’t help. But I think a big reason why it uses so much jargon is because it’s such a powerful tool. Beeminder’s abstractness means the number of ways you can use it to solve your real-world problems is practically limitless. But that same abstraction means it’s super hard to find names for things inside Beeminder that are both terse and concrete. So Beeminder has come down on the side of (usually) terse neologisms, and I don’t think that’s an unreasonable decision.

Beeminder could decide to prioritize newbees over power users. That would be a reasonable decision, too. It’s the decision I’d argue Stickk made. But the tradeoff that would have to be made in order to do that would be to cater to a limited set of concrete use cases instead of providing a limitlessly-configurable abstract system.

And, frankly, as a Beeminder power user, I’m glad Beeminder made the decision they did, because, in my opinion, the pain required to learn all the jargon was well worth the power that came with mastering the abstract system it represents.

None of this is to say that making things easier for newbees is a bad thing. I think it’s an important thing. And I’m certain there are things that Beeminder could do to ease the pain for newbees who still haven’t learned all the lingo. But I think condemning Beeminder for using abstract neologisms misses the reason all these terms were introduced in the first place.


My point was that the term “commitment week” wouldn’t ever allow the akrasia horizon to be changed. It’s like how you shouldn’t name a variable int three; in case you need to change it later.


Or allow the user to change it, as I seem to recall some users would like to be able to do…

1 Like

Thanks so much for the feedback on this, everyone!

It was interesting to see people’s guesses on the jargon I mentioned. For the record, here are the answers:

  1. ratchet = (irreversibly) reducing your number of safe days
  2. autoratchet = premium feature that does that for you automatically, capping your safety buffer at an amount you specify
  3. road dial = where you change the amount you’re committing to, starting after the akrasia horizon
  4. akrasia horizon = now + 1 week, the time window after which changes to your yellow brick road (including ending the goal altogether) take effect
  5. yellow brick road = the line on your graph indicating what you’ve committed to
  6. mercy = how much safety buffer you get as respite after derailing
  7. derail = to fail to keep your datapoints on your yellow brick road, causing Beeminder to charge you money (aka, to get stung)
  8. rerail = what automatically happens when you derail, where beeminder makes a new yellow brick road for you to continue from where you went off track, with the chosen amount of respite
  9. weaselproofing = opting in to stricter criteria for what counts as a non-legit derailment, and also the closing of various loopholes
  10. autodata = data that Beeminder adds to your graph from another app or service automatically
  11. beemergency = a day when your graph is red and you’re about to derail unless you get your datapoint on your yellow brick road by your deadline
  12. aggday = the function Beeminder uses to aggregate all your datapoints on a given day to determine the official datapoint for that day (eg, sum, max, min, last)
  13. maxflux = max daily fluctuation, used for weight-loss goals, chosen by the user as the most their weight ever fluctuates in a day
  14. legit check = the email Beeminder sends when you derail asking if there was any reason it shouldn’t count as a legitimate derailment
  15. pledge = the amount of money you’re agreeing to get charged if you derail

Not saying all of those should be user-facing terms though. Actually in writing that, I’m realizing that the term “mercy” really would rather be “respite”. It acquired the name “mercy” because we used to have a checkbox for “no-mercy derails” and then we generalized it to a parameter but calling that parameter “mercy” is… insufficiently evocative.

“Yellow Brick Half-Plane”

Speaking of which, oh my goodness, yes of course “yellow brick half-plane” is just a codename, not something newbees ever need to see. I know that’s a weird thing to say after I’ve used the term more often than the Bible mentions Jerusalem (956 times, if you were wondering) on the forum and the blog (including in the title of the last blog post). But the point of yellow brick half-plane is ultimately a huge simplification with much less that Beeminder users will need to understand (namely, all the crap with lanes of the road). So when the transition is done there will be no concept of “yellow brick half-plane”. It will just be how Beeminder works. Again, the name is only needed for the transition.

(PS: Sorry I was so slow to clarify that!)

Localized replies

Excellent question. I don’t think we have enough traffic to do A/B tests on webcopy but we may try anyway, just in case! (When it doesn’t defeat the point of having a common vocabulary.)

Yes, that looks way too easy. :slight_smile:

I think that’s the best of both worlds, yes.

Please do hit reply on those to ask; that will help us immensely.

:heart_eyes: Beautifully said, @narthur! But I do think there are a ton of places where we can have the best of both worlds. Like @mufflon said, just being more careful to include explanations in place in the UI will go a long way.


I do feel pretty strongly that, in the minority of cases where we may have to make a tradeoff between accessibility to newbees (not to be confused with accessibility to those with disabilities!) and maximum utility for power users, we’re philosophically on the side of the power users. But we don’t need to debate that in the abstract! We can wait for a concrete instance where the two philosophies unambiguously diverge. My claim is that they typically don’t. Examples:

  • “Yellow brick half-plane”, as I said, won’t be needed.
  • “Aggday” should be buried in advanced settings where it doesn’t much matter if we give it that nerdy name because newbees needn’t care about it or encounter it.
  • Max daily fluctuation is newbee-visible for weight-loss goals and we don’t currently ever mention the internal name “maxflux”. It may be handy (for greppability, etc) to expose that name but if we did we’d do it subtly enough that a newbee wouldn’t feel like they were ever expected to know it.
  • I’d like to expose “autoratchet” similarly because I find it unwieldy and confusing to talk about “the field where you can cap your safety buffer if you don’t want to manually ratchet each time you have more safety buffer than you want”. And, yes, sometimes it’s clear enough if you just say “max safety buffer” but often it isn’t. There’s always so much more ambiguity than it seems like there is. To those of us who understand the autoratchet setting it can be hard to imagine how “max safety buffer” could ever be unclear. But it can! “Max safety buffer I’ve gotten so far? Max safety buffer until what?” So many ways for newbees to be confused!
  • And similarly for “road dial” instead of “the ‘commit to’ section of the Commitment tab where you can specify the 2-out-of-3 of date/value/rate that represents how steep of a yellow brick road you’re committing to”.

Getting abstract again, I think people have the sense that jargon impedes communication because of how opaque it can be. Why would you ever use a word your audience won’t know when you could use a handful of simple words that they will know? Well, let me answer with a quote tenuously attributed to George Bernard Shaw:

The single biggest problem in communication is the illusion that it has taken place.

Consider my last two examples – “autoratchet” and “road dial”. Those are words newbees won’t know but at least newbees know they don’t know them. It’s like @narthur said, those terms represent powerful abstractions and if you try to avoid the jargon then you risk … wait, I have another quote, also tenuously attributed, this time to Mark Twain:

It ain’t what you don’t know that gets you into trouble. It’s what you know that ain’t so.

Jargon can prevent that!

I’m kind of convincing myself more and more here. Beeminder is a powerful system and so some technical terminology is inevitable.

But I’m hearing the countervailing voices too and I don’t disagree. Beeminder can and must do much better at newbee-accessibility.


It’s worth making the meta-point that “jargon” is a word which can have very negative connotations - it can refer to both useful technical terms as well as nonsensical business talk with no substance.

I’d rather rephrase the question as “Are Beeminder’s technical terms sufficiently explained? Are the names sufficiently clear?”


I’m in complete agreement.


On top of that, it does also give you the opportunity to link to a canonical explanation that goes into depth. Maybe like:

Akrasia [?]

[?] -> mouseover -> Lack of self-control or the state of acting against one's better judgment. (Read more)

(Read more)  -> click -> Link to longform explanation and supplemental material.

Then you could in theory attach a class to [?] that could be hidden if the user enables “Expert mode” or “Hide Explanations” in the account settings. The keen eye will notice this is inspired by good Python docstrings that have a single sentence explanation, followed by more in depth explanations and Usage examples. (Read more)

Apart from the technical, this would provide more granular control over the learning curve, the user experience, and also satisfy the ultra nerds that would genuinely like to read more about akrasia etc, but not necessitate it.


Why is “recommit” not a good enough word that “rerail” is needed too? Do they mean the same thing? If not, are the meanings different enough for “rerail” to carry its lexical weight?

I like that.

I think I’ve seen “max safe days” too? Again, why both?

I feel I should remind you that you did just ask for validation on a forum that presumably self-selects towards cream of cream of geek, specifically the subset of geeks who already like beeminder A LOT (not everybody of course!) :wink:

Edit: by “not everybody”, I was referring to “geek”, not “like beeminder”!


“recommitted” is the term used by the interface in the comment on the data point when you recommit:


Oops, correct! “Recommit” suffices and is in fact what we normally say. (Note to self to avoid “rerail”!)


I see that held up well. :grin:


Discussed further here: