Spec: Goal Slugs and Goalnames

Review of the principles we’ve embraced for the current website and apps (not always lived up to!):

Goals need a very short, one-word name — called the goalname — plus an optional phrase-length description. The user must thoughtfully pick both. We do not, for example, let the user type a description and auto-generate a goalname. Not even as a suggestion — the user must thoughtfully and explicitly choose the goalname. Whenever there’s room the goal should be shown as “goalname: Optional phrase-length description” or similar. Some interfaces like SMS will use only the goalname. The description must never ever be shown without the goalname. The API should absolutely not use goalnames as identifiers but should use IDs. Those IDs should not be visible anywhere but the API.

(Side rant: Long goalnames are gross and wrong and make Beeminder worse for newbees who don’t yet know better. They should pick cute one-word names and when they don’t we should be like “no, like this”. That’s better for them in the long run. Paternalism! Opinionated Software!)

Alright, enough philosophy, we have a big ole mess to clean up. Currently we still have, in various forms, all of the following:

• Goalname (aka “slug”): the name used in the URL
• Goal title: often the same as goalname but with spaces allowed
• Goal statement: meant to be a one-line statement of the goal
• Fine print: free-form text about the goal
• Y-axis label: another place to describe what’s being measured
• Goal units: concise version of y-axis

One key usability problem to solve is how users confuse themselves changing the title but not the goalname. In the 2016 redesign this was solved rather crudely by just completely deemphasizing everything but the goalname.

What we shall do:

• Keep goalname central
• Keep goal title but call it goal description, still one line (internally: goalblurb)
• Merge goal statement and fine print — we’ll only have the latter
• Keep y-axis label (should this be strictly auto-composed from goal units? how to migrate if so? puntable.)
• Keep goal units

Arguments for keeping the goalname (slug) central, as an explicitly user-chosen field and the ubiquitous goal identifier:

1. Nerds care about URLs. For example, if we inferred the slug from the title I wouldn’t be able to have a title of “More Productive Time” and a URL of bmndr.com/bob/work.
2. Melanie’s argument: It’s a concise, stable way to refer to the goal (matters for smartphone apps, SMS, API, Slack, email bot subject lines). “I take time to think of exactly what I want the slug to be, where the goal title sometimes changes over time as the goal might shift a little for me, but that nice general slug keeps working for me.”
3. Changing slugs is problematic for both technical and akrasia-related reasons, so if the user explicitly chooses a super concise slug they’re less likely to want to change it.
4. Space in the dashboard is precious.
5. Shanaqui: “I find the slugs a much more instinctive way to find the goal I’m looking for, even if I was using the description field 100% the way it’s intended.”

Implentation note: Let’s emulate GitHub’s interface for naming repositories or Slack’s interface for naming channels.

Basically, I have a strong aesthetic preference for Beeminder being very opinionated about slug-like goalnames.

Migration note: Prepend the goal statement (and 2 newlines) to the fine print and then kill the goal statement. (Look at some examples first to sanity check that plan.)

Uservoice complaint (from pre-redesign)

Slug Renaming

Mainly the above lets us punt on the messy issue of slug renaming, currently a Bee Plus premium feature. Here are some of the reasons we haven’t just let anyone do it:

1. It breaks links
2. It breaks IFTTT recipes
3. The loophole of renaming “weight” to “trash27” and then recreating “weight” as a fresh goal with a $0 pledge every time you derail. I think we’re not too worried about those kinds of shenanigans anymore though.
4. Something about a general sense of committing to a goal? I forget all the reasons I’ve been squeamish about willy-nilly slug renaming.

One compromise is to let you rename slugs exactly once so we can just always store the old slug and properly redirect. Or maybe just give an appropriately scary warning about why it’s bad to change slugs but always let you do it if you confirm you know what you’re doing. (I guess that’s what GitHub does for renaming repos.)