Does Beeminder use too much jargon?

[narthur]

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.

[zedmango]

@mufflon

I hope they adjust all the mentions in blog posts and the glossary that mention the week.

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.

[narthur]

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

[dreev]

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

@rmoulange

how might one investigate this more formally, randomised-controlled-trial-style?

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.)

@mufflon

Beeminder is for the people that do the Krypt puzzle and wish it had more pieces and less symmetry

Yes, that looks way too easy.

@mufflon

explain the jargon in place in the UI

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

@mufflon

new email with a non-explained jargony word

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

@narthur

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

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.

Conclusions

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.

[zedmango]

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?”

[mary]

@dreev

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’m in complete agreement.

[mufflon]

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.

[halfplane]

@dreev

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

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?

respite

I like that.

Max safety buffer

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

I’m kind of convincing myself more and more here.

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!)

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

[zedmango]

@halfplane

Why is “recommit” not a good enough word that “rerail” is needed too?

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

[dreev]

@halfplane

Why is “recommit” not a good enough word that “rerail” is needed too

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

[mufflon]

@dreev

oh my goodness, yes of course “yellow brick half-plane” is just a codename, not something newbees ever need to see.

Announcement: The Yellow Brick Half-Plane Has Arrived

I see that held up well.

[zedmango]

Discussed further here:

Let's never say "Yellow Brick Half-Plane" again

In the recent thread about jargon, Danny made a promise: oh my goodness, yes of course “yellow brick half-plane” is just a codename, not something newbees ever need to see. … 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. Then he went and wrote a blog post about the yellow brick half-plane, right where the newbees can see it To celebrate our new te…