I’m wondering why the “goal statement” under a goal’s settings (Basics) is of type “text” instead of “textarea” like the “Fine print” is.
It seems to me that a goal description/statement has the potential to be a bit lengthier than what a text field would suggest (that’s the case for my first goal). It would also avoid the browser keeping an auto-complete that is probably unwarranted since it’s not exactly usually reuseable text and I feel compelled to delete it (especially after an edit).
What do you think? possible uvi? Am I misunderstanding most people’s use of the field?
Great question and great suggestion! We need to redesign this. Currently it’s super confusing how we have all of the following:
Goal slug: the name used in the URL (for technical reasons we don’t normally let you change this)
Goal title: often the same as the slug but with spaces allowed
Goal statement: meant to be a one-line statement of the goal
Y-axis label: another place to describe what’s being measured
Fine print: free-form text about the goal
We’re thinking of, for starters, merging goal statement with fine print. Like anyone who has a goal statement we’ll just prepend it as the first line of your fine print, and make the fine print a bit more prominent.
-1 for merging them. I think it’s good to have a separate concise goal statement.
I realise this is still possible when using a single field, but wanted to make it clear I disagree with all the +1’s here.
Is anyone willing to post/link to some examples of their goal statements?
I’m biased, since I think I was the one who asked for the “fine print” area to be added (ages ago). And I was going to reply that I like having both goal statement and fine print. But after looking at a few goals (mine and others’), I think you’re right: it doesn’t seem that many people fill in both the statement and the fine print, so the only argument in favour of keeping both would be that the statement is public whereas the fine print can be private, and that argument is feeble.
So merging the two into something called eg “About this goal” would be fine by me, despite my gut reaction.
I appreciate having both fields available. I use the goal statement to declare the measurable goal that I’m using Beeminder to break down into doable chunks. I use the fine print to define the weasel lines that I might be tempted to cross and, more commonly, the things that actually do count as progress so that I’m not too hard on myself.
If I bother to fill in one field I usually fill in the other as well. I like the way they display together but separately under the goal info heading. I feel like the goal statement should also display under the goal name on the dashboard view of current goals, where the derailing time is at the moment. Was it previously displayed there? I have just been surprised, yet again, to not find it there.
I think I’m closer to integrating the goal title and goal statement than I am to integrating the statement and the fine print. Up until this point, I thought the goal title had limited characters because it was pulled into the slug. And while we’re making suggestions, I really wish the slug would automatically remove the spaces from the goal title and start with that. I hate having to type everything out again because I made my title something like “Be at work by 9am” and the suggested slug is “be”.
Here’s an example of how I’ve used the fields for one of my goals.
Title:
Declutter
Goal statement:
Get rid of 50 things in a month
Fine print:
An item can be counted as progress when it has left the house or is committed to leaving the house (e.g. listed in an auction, in a rubbish bag).
Things that belong in pairs or sets shall be counted as a single item. So, a pair of socks would be one item. An odd sock would also be one item.
Duplicates of the same item may be counted as separate items, provided they are not dependent on each other to fulfil their function. So, three pairs of socks will count as three items. This rule may be modified if the challenge is deemed too leisurely.
Items must have been kept, rather than just having missed the rubbish.
Giving an item away to somebody in the same household does not count, unless they have a legitimate use for the item and ownership is transferred.
Facilitating the removal of a household item can count, even if the item is not explicitly owned by the individual.
Confirmed, we bumped it in favor of the deadline. I’m liking the idea of having everything in one big text area that supports markdown and if you give it a title then that can be displayed in other places, possibly the gallery again, or maybe at least as hovertext. Now I’m wondering if we could have everything except the goal slug be incorporated into a single text area and use conventions for parsing out the y-axis label and the title and anything else. We could start with a template like…
TITLE: This Is Your Goal Title
STATEMT: This Is A Subtitle That Says In A Sentence What You're Committing To
YAXIS: This is a short phrase describing what your graph is actually measuring
Say more about your goal here, including any fine print you want to impose on
yourself, like defining exactly what counts as "a workout" or how you measure
productive time.
I feel like most of the existing suggestions are too attention-hogging for this.
How about renaming slug to title, leaving y-axis label alone for now ('cause it’s related to units and magic stuff), and merging the rest of the fields?
If you want a short goal description, you can take the first line of the full description, and if you want a long title, you can take the slug plus the first part of the goal description.
I agree that eliminating the slug/title distinction would be good, but I think that is a different discussion.
I’m worried that things seem to be getting out of hand.
The initial request was just changing from a textbox to a textarea, and the discussion seems to be drifting towards a complete overhaul of the goal description system.
I don’t want to be the ‘goal police’ or directly criticise chaoticmind’s goal, but in my opinion his/her goal statement is too long, and includes elements that belong as fine print. If (s)he’d just used the first 4 words, then we have a perfect goal statement that easily fits in a textbox, and the rest goes under fine print.
Moving to a larger freeform markdown textarea makes things more complicated, rather than simpler. Now you have to invest time in learning new markdown syntax, and there is nothing encouraging you to have a short specific goal statement. The goal statement and fine print are already ‘extra’ options that you don’t need to fill out when creating a goal.
Maybe it is a Beeminder company goal to make it ‘easier’ to make goals but I think these changes go against the ideal of helping people achieve their goals, by doing too much to encourage vague non-specific goal statements.
How to make Goal statement/fine print connection more clear:
Add some more help text in one of those little info pop-up boxes.
Currently the help text is:
For example: Get down to 150 pounds
Popup help might be:
This should be a simple one line statement, that can easily be answered with a
yes or no. If you find the goal statement is too long for this box then you've probably
included elements that could go in the fine print box below.
<Link to a page of example goal statements/fine prints.>
Put the goal statement and fine print entry boxes next to each other so it’s
more obvious that they go together and the overflow from ‘Goal statement’ belongs
in ‘Fine print’.
I’m sure that this was true at one point, with spaces replaced by dashes. Inadvertent breakage or deliberate change? I don’t see a related uvi listed. @dreev@alice@bee
One reason was that everyone was ending up with completely unwieldy slugs which was hideous and generally hard to deal with, especially in the smartphone apps.
To @peppertoni who doesn’t like typing “Be at work by 9am” as the title and then retyping “be-at-work-by-9am” as the slug… that’s why we need to revamp this stuff. But also, we’d like to encourage you to make the slug more like “earlybird” or something super concise like that.
PS: My meta-markdown idea was no good. Thanks so much for the awesome feedback here, everyone! Here’s my latest thinking, though I haven’t finished reflecting on the latest suggestions, mainly from @insti, here…
Replace {goal slug, goal title, goal statement, fine print} with two fields: slug (super short, no spaces) and goalinfo (full textarea, can be pages long if you like). For a longer title like for displaying above the graph, use the first line of goalinfo. Probably appended to the slug, since that needs to be kept pretty central.
The main problem to solve is how users confuse themselves changing the title but not the slug. And goal statement and fine print should be merged since we never need to do anything distinct with those two things.
Arguments for keeping the slug central, as an explicitly user-chosen field and the ubiquitous identifier of the goal:
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 beeminder.
@mel made an argument for keeping slugs central: concise, stable way to refer to the goal (matters for smartphone apps, SMS, API, 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.”
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.
I don’t use super concise slugs because of the inability to change them afterwards. If I start a goal called ‘earlybird’ about getting to work by 9 am and then later decide that actually what’s important is to get up by 7:30, I can’t use ‘earlybird’ for the getting up goal any more. So I now generally give suffixes to my goal slug and make them very verbose.
Anyway, how difficult could it really be to allow goals to have alias slugs that redirect to the canonical slug, and automatically create an alias when someone changes the slug?
Yeah, it’s nontrivial to implement though, I think. What do you do if the user renames “foo” to “bar” and then tries to create a new goal “foo”? [1] I think a reasonable compromise that keeps things somewhat simple to implement is you can rename a goal exactly once and both old and new name are permanently reserved.
PS: GitHub might be worth emulating here. github.com/new
[1] Probably the new “foo” should just supercede the redirect. But we also have the anti-weaseling consideration of not making it too easy to wipe clean your weight – bob – beeminder goal by renaming /weight to /weight-nevermind and then recreating weight – bob – beeminder
You disallow creating a new goal ‘foo’ until the alias named foo is deleted, just like you would disallow creating a new goal ‘foo’ if a goal already exists with that slug.
That link doesn’t work.
I don’t see how that’s a problem. So let’s say you change the slug for your goal to weight-nevermind. So what? You’re still on the hook for it, subject to the akrasia horizon. How does simply changing the slug get you off the hook?
What I would do is just allow aliases for goals (I don’t see why there couldn’t be unlimited aliases either), which should simply be a table that maps aliases to the goal, plus a page for each user to administer their aliases. Then you can deal with disappearing URLs when a slug is changed by automatically creating an alias from the old slug to the goal (which the user can manually delete if they want). It doesn’t seem very complicated to me unless there are issues specific to the Beeminder code base.
(I’m not saying you should implement it immediately. There is still some development to do, and there may be more important things to do first. But it doesn’t seem to me to be an especially delicate change, either in terms of technical implementation or in terms of user interface/experience.)
You have to be logged in to GitHub I guess. It just shows their interface for picking what we call the slug for the new repository along with an optional description. Looking at that I’m vacillating again. Maybe GitHub has the right idea: a goal name, which we make obvious must be URL-able, a one-line description, and then something like a goal readme or goal wiki for what we now call the fine print.
I guess that’s the biggest reason we’re gun shy about this. But sounds like we agree that we want a robust solution to goal name changes eventually but not the highest priority yet.
In combination with the new death-to-freebees plan (hover for summary) we don’t want you to be able to easily restart a goal at $0 each time you derail (unless you pay for that with Plan Bee).
