Complice should show goalnames, not just descriptions

Bugabee
1

Thanks to @zedmango for pointing this out! This is mainly for @bee and @malcolm to discuss and might involve cruftiness in the Beeminder API.

I think it’s important for Complice to always show the short goalname in addition to the description when listing Beeminder goals.

First question for @malcolm: Is Complice using the title field of the Goal object?

Questions for @bee: Are slug and title in the API aliases for goalname and description? Or is there an additional title field that wants to be migrated? Ugh, and “goal statement” too? Messy. I advocate rolling up sleeves and getting this sorted out, having aliases in the API for backward compatibility etc.

Related but outdated: http://doc.bmndr.com/slug

2 Likes
2

I live for the day that slugs are called “slugs” in the interface and names are called “names” instead of “description” :stuck_out_tongue:

3

By the way, I would argue that you are losing users by asking them to come with a machine-friendly slug instead of creating one automatically (editable later) based on the name of the goal :slight_smile:

2 Likes
4

If only I could heart you more than once

2 Likes
5

The relevant things that we return in the api are called slug, title, and description. Those map to things that we show in the beeminder interface like so:

slug => Goalname
title => Goal Description
description => not used
4 Likes
6

Reading that cracked me up. Clear as mud! So what does “description” actually return?

You mean the description, aka “title” in the api?

Then you’d get things like work_on_2, work_on_3, etc.

There are definitely two semantically distinct items here - what you call the goal, which should be a couple words, and a description of what the goal is, which should be a couple sentences.

2 Likes
7

@zedmango yes, what @dreev insists on calling a “description” is actually the title of the goal. In fact, the API actually has fields properly named: you have a title (human understandable), a slug (machine friendly for URLs and connections with other API) and a description (ironically left empty in the API)

Having the slug be automatically created would not mean that you end up with “work_on_2, work_on_3”. A title like “Weight (KG)” can easily be converted into “weight_kg”. WordPress is a quite popular example of what I’m describing. The software creates a slug from the title automatically and you can edit the slug if you don’t like it. This is quite straightforward and user friendly.

Asking people to come up with a “short name” that is actually a slug, correcting them as they go along to not enter spaces or other characters, and then asking them to put their actual title in another field is not so friendly.

1 Like
8

Disagree! I have a goal to do laundry once a week. I think of it as my laundry goal. The title, or slug, is “laundry.” That’s a title - a short term that refers to the goal. It’s a handle or label for the goal. It’s the goal’s name.

This goal currently has no description, but if I were to put in a description, it might be “Do at least one load of laundry at least once a week.” That’s a description - a more lengthy explanation of what the goal actually requires, which goes into more detail. That’s clearly not a name.

If beeminder automatically named a goal after the description, it would be something like do_at_least7 which isn’t helpful.

So most of my goals don’t have a description. They don’t need one, because the name, which is the title and the slug, is sufficient.

Another example: I have goals to meditate in the morning, afternoon, evening, and night. They’re called amsit, aftsit, evesit, and nightsit. Those are the goal names. That’s how I think of the goals.

The descriptions are things like “>6 min 12-4pm” and those are just there to remind me of the requirements. It starts with a greater-than sign, so it wouldn’t work as a slug, and if beeminder automatically turned them into goal names, they’d be 6_min, 6_min2, 6_min3, and 6_min4.

So no, descriptions are not human-understandable titles - they’re additional explanatory notes that often only make sense with reference to the titles.

For instance, suppose you had goals for pushups and situps. In each case the description might be the same: “do 1 set of 15.”

Why? Because when you create a goal, you first think of what you want the goal to be. Say, to do pushups. Then, you give it a name based on that, like “pushups.” Then, you go into the description, where you flesh out how the goal works: “I want to do 1 set of 15.”

So the descriptions, which just enlarge on and expand the goal names, are not themselves helpful. Just the descriptions, “1 set of 15,” can’t even tell you whether you should do pushups or situps!

1 Like
9

I think you misunderstood me. In general, in all web based applications, a machine-friendly field (“slug”) is separate than the human-readable field (“name” or “title”). See WordPress (slugs vs titles) or Twitter (usernames vs full (human!) names).

The fact of the matter is that Beeminder is confused and confusing about what is a name and what is a description. The result is a field name titled “goal description” that in the API is referred as “title”
Obviously, “Do at least one load of laundry at least once a week.” sounds like something you would put in a “description” field, but not what you would put in a “title” field. And of course, you can hardly use “Do at least one load of laundry at least once a week" as a “goal description” when the field in the interface only allows for 19 visible characters…

I’m surprised you remember what these mean :smiley:

So all your goals do not have spaces in their names. Non-geeks (and some geeks like myself!) like spaces in their titles, but Beeminder doesn’t really help them that much in this regard.

2 Likes
10

The fact that you prefer terse titles is not really a valid argument against the notion that people should be free to choose the titles that they prefer. If things were fixed as @apolyton describes, you could still keep your terse titles, but everybody else would be able to have the titles they want too.

1 Like
11

@drtall @apolyton

Let me see if I understand. We now have two fields: a title and a description. The title is restricted in length and characters allowed because it does double duty as a slug.

So is the idea that there should be three fields, a title, a description, and a slug, with the title unrestricted, and the slug automatically created from the title but changeable later?

So I could put in:

title: laundry
description: do at least one load of laundry at least once a week

And it would auto-create the slug “laundry”

And you could put in:

title: this is my !very long laundry goal #name with /\special characters
description: do at least one load of laundry at least once a week

And it would auto-create the slug “this_is_my5”?

1 Like
12

I don’t see why slugs needs to be so short (10 characters) and how you would end up with a “5” at the end in any case (slugs are user-specific they don’t need to be unique on the entire beemiverse (term just invented))

13

“Should” is maybe too strong. Frankly I don’t care about the slug at all. I get it that we need URLs to navigate to goals, but I don’t care what they are at all. Beeminder forces me to choose what goes in the URL when I actually don’t really want to.

To support both types of people (people who care about their URLs and people who don’t), it can be accomplished in the way you describe. But I think the point is that you end up with 3 fields for compatibility and not because any one person really wants all 3?

2 Likes
14

My point was that a lot of sentences are going to start with the same few words so autoslugs will end up often having a number at the end. I could have written “this_is_my_very_long3”.

15

I don’t care about the URL either. But it’s clear that we need short goal names for display purposes.

My ideal would be to allow spaces and other characters in the goal names, but still require them to be short. Then if the goal name needs to be processed to make it into a slug, do that.

By the way, what’s wrong with spaces in a URL? Why can’t we have spaces in our slugs?

16

When you name a field as a “title” you’re not asking people to put in long sentences. Just a human-readable label of 3-5 words. I have over 30 goals and the only cases where the first word is the same between two goals in the “description” field are “Weight” and “Weight trend” (and the body fat ones).

Meta: LOL, the forum software says we need more people here (“You’ve already replied 3 times to @zedmango in this particular topic. Have you considered replying to other people in the discussion, too?”). Pinging @dreev :smiley: :smiley:

17

Well, if there wasn’t an effort to force in the interface both the slug/“name” and the title/“description” and just show a title field, this wouldn’t be such an issue.

18

I thought we were talking about the “title”/slug/name field, not the “description” field. Can you clarify how you use each of these fields and how you think they should work?

I don’t understand what this means - can you please explain?
The title is the slug/name - the description is something else.

19

The slug is a lot more than short. It’s restricted to lowercase ASCII and underscores. One of my goal titles is “:cut_of_meat::slightly_smiling_face:”. That’s two characters which is shorter than every single one of my slugs. So if it was about being short, I should be able to use whatever characters I want.

Works for me!

They’re illegal according to the specification, probably to make it clear that if I type http://thing and keep typing that you know the URL isn’t actually “http://thing and keep”. But it doesn’t really matter why, somebody made the decision a long time ago and it can’t be undone.