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:
ratchet = (irreversibly) reducing your number of safe days
autoratchet = premium feature that does that for you automatically, capping your safety buffer at an amount you specify
road dial = where you change the amount you’re committing to, starting after the akrasia horizon
akrasia horizon = now + 1 week, the time window after which changes to your yellow brick road (including ending the goal altogether) take effect
yellow brick road = the line on your graph indicating what you’ve committed to
mercy = how much safety buffer you get as respite after derailing
derail = to fail to keep your datapoints on your yellow brick road, causing Beeminder to charge you money (aka, to get stung)
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
weaselproofing = opting in to stricter criteria for what counts as a non-legit derailment, and also the closing of various loopholes
autodata = data that Beeminder adds to your graph from another app or service automatically
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
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)
maxflux = max daily fluctuation, used for weight-loss goals, chosen by the user as the most their weight ever fluctuates in a day
legit check = the email Beeminder sends when you derail asking if there was any reason it shouldn’t count as a legitimate derailment
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!)
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.
I think that’s the best of both worlds, yes.
Please do hit reply on those to ask; that will help us immensely.
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.