IMO, a popup on the dashboard is a good place to show the fine print. It’s not so good for titles. Making them that hard to get to is actually encouraging people to make long, ugly slugs so they can actually remember what their goals are.
I understand the claim that there isn’t space on the dashboard, but it’s simply not true. The information density of the current dashboard is low. The fonts are large and there’s a lot of empty space. It is pretty, I’ll admit (though I agree with @drtall that all-caps slugs are unreadable and would greatly prefer lowercase). I’m not a designer and I don’t know exactly where to put it or how to change the other elements, but I’m quite confident it could fit. (The most logical way given the existing UI affordances would be to have clicking on the slug toggle to the title, and vice versa, but I’m sure you threw up a little in your mouth just considering that ;-))
My own slugs are actually pretty short and I mostly keep the meaning in my head, like @dreev. So it actually works okay for me, in this respect. I really think it’s not good for newbees and casual users though.
I think most websites do this. Gmail, Google Calendar, Amazon, Reddit, etc. The wider the window the more information you can see. I think Facebook and Google+ are some of the only exceptions I can think of.
I’m suggesting something more like how email works, where the actual protocol is case insensitive but I can choose a display that’s to my liking. I think this is another case of “I don’t care how the unique id thing works under the hood, I just want to choose how my dashboard displays it to me.”
What’s the logic behind this? I never want to see my slugs anywhere on the website, ever.
we should make you pick both your slug and your goal name/description/whatchamacallit. now that you can change both willy-nilly, i don’t think this is a showstopper. i mean, we make you pick a username, and then you can enter more profile details. same thing. sort of.
we should let you view things as either slugs or goal names, whichever you fancy.
when you are talking to support, if you use the slug instead of the goal name or send us URLs, we will love you forever and ever.
If titles are going to be supported, I’m still wondering what benefit slugs serve? People can just make terse all-caps titles if they like that style of naming. (And then use a different source of unique ids for goals).
for me personally, mostly #3 – slugs are used in reminder and legit check subject lines, you need them for a couple data entry methods, they’re what IFTTT recipes hook into, if i have the slug i know exactly how to get to your goal via url, rather than entering your gallery and clicking, probably more stuff i don’t even know about…
is it worth it to revamp all that to use a unique id, when the slug already is a unique id (just one you have to choose, instead of us autogenerating it), that is, for the most part, a short, sweet, & memorable one, rather than /nanowrimo-2016-writing-my-first-novel/75933819/ or whatever? versus like… working on other stuff that either 1) doesn’t already work or 2) doesn’t already exist (paypal anybody???)
i am on your side about showing titles everywhere for those who want it! just not axing slugs.
(yes, some people pick crazy long/embarrassing/unattractive slugs imo, but that’s their prerogative. now they’re editable!)
IMHO solutions like Intercom or any other on-the-website means of contacting support are preferable. Then you’d get my username, the goal id, etc. for free with every communication.
Whether it’s worth doing now, I can’t say. And the answer is probably no. But the website redesign seems to be doubling down on slugs rather than backing away from them, which seems backwards even if slugs are ultimately still kept around.
I will always prefer the option to use spaces and mixed capitalization over not having that option - because I’m not a programmer who looks at code (or Slack) all day long. Maybe some nerds care about URLs, but I’m sure not one of them. Even if I was, the old approach would still have worked fine for me.
In general, assuming that users have - or should - put a lot of thought into nominology doesn’t seem like a user-friendly approach to me. It adds an unnecessary chunk of mental effort in the goal creation process - right at the point when an akratic is likely to bail because it’s too much hassle.
As for space in the dashboard being a concern: If you allow spaces, you can wrap words to a new line. And it’s not like you’re enforcing a character limit on the slugs anyway.
Oh my, so much Wrongness On The Internet over here!
[PS: That’s describing my own mindset, not saying anyone else is being too combative or anything. Quite the opposite. Really good to have such pushback!]
First, to avoid confusing ourselves with terminology, there are only two fields relevant to the debate:
goalname (internally still sometimes called slug but we should stop that)
goal description (internally: goalblurb)
Has everyone noticed what http://beeminder.com/gallery now looks like when you’re logged in? That’s showing “goalname: description” below each thumbnail.
Like @chelsea said, you can change your goalnames and descriptions now so I’ll be surprised if anyone still feels like there’s anything really showstopping now.
As a design philosophy, to @drtall’s chagrin, the UI is going to treat goalnames as central and descriptions as ancillary so I think folks just need to edit their goalnames and goalblurbs to conform to that convention. If it weren’t for the sordid history I think that design choice wouldn’t be remotely controversial. Actually I know it wouldn’t be because the utter trainwreck of overlapping settings (slug, title, statement, etc) never was. So we just have to make the transition. Really sorry for the bad design choices in the past that made that necessary!
Btw I’m not necessarily opposed to the idea that @kenoubi predicted would make me throw up in my mouth, namely, letting you click to toggle between goalname and description in the dashboard. But that’s the farthest I can imagine going in suppressing goalnames in favor of descriptions. Mostly you can’t have the description without the goalname. Because the way users will be prompted to create those fields you’ll have things like a goalname of “pushups” and a description of “do more of them”.
Short of creating and then immediately deleting goals as a way to test out the goal creation scripts, is there a way to see the text that will accompany the fields during goal creation? Because if I’m going to update everything to a new system, I want it to be consistent with how I’ll respond to those prompts in the future.
The reason the new design choice is controversial is because that “trainwreck of overlapping settings” allowed for shades of nuance that people could use according to their preferences. Before, there were lots of ways to add more information, but they could be ignored if the user didn’t find them interesting. Now there’s less opportunity for nuance and flexibility. So it makes sense that the forum users - people who probably care the most about nuance and flexibility - are upset about it.
@dreev Changing the goal names to all caps was a deliberate design decision. The reason for the change was to make the goal name visually distinct from the deadline information. These designs were responsive, and designed from the mobile up, so the capitalization solved a problem that is accentuated with only 320 pixels width on a tiny mobile. It is important for the goal name to be immediately identifiable from the deadline information, otherwise it just looks like one long blurb and you can’t immediately identify which goal is which.
If you do decide to remove the capitalisation, it is important to keep the visual distinction so that you don’t just get one long line of text, particularly when the mobile screens get developed. Bolding or emphasis will do, or you could swap the typeface so that goals names use the display font instead of the sort buttons.
Can you clarify if changing a slug will break any of the integrations with IFTTT and Zapier?
The UI mentions “Changing the URL of a goal can break existing links and IFTTT/Zapier recipes” but it does not sound definitive, more like a gamble.
(As you also mentioned) font size and weight can cover that adequately without forcing capitalisation (which removes flexibility from the users to capitalise as they prefer)
Hi @drtall - totally understand. I really think there’s a solution here to fit all use cases, and I know that we’re going to get to it.
I think the beehive residents are all (painfully) aware of the problem and we just need some time to fix it. This was our fault for moving a few too many things at once with the redesign, so sorry (no, really, sorry) about that.
I’d respectfully suggest that we close off this thread now, or at least the part pertaining to goal slugs/names/descriptions/fineprint/etc, since that part does feel like we’re now beating a dead and no one likes a dead .
Confirmed. The goalname (formerly known as “slug”) is the unique identifier of a goal, and part of the URL for the goal. If you change it then anything that referenced that goal will break.
I disagree with @gretchen’s point about shades of nuance in the old design. We were just conflating things left and right, making the user manually pick a unique identifier and then sometimes but not consistently suppressing it in the UI. So if you were careful or lucky or used the right subset of features then things worked the way you wanted but it was all wrong and, believe me, caused bigger problems than lack of spaces or mixed case causes now.
I’m pretty obsessive about every improvement being a pareto-dominant one, but we desperately needed a clean break from the old system of two name fields with no clarity about which did what. So we’re doubling down on goalname=ID.
To implement @drtall’s vision (I personally disagree with it but I understand the preference – btw, I often click for posts even if I disagree if I like the contribution to the discussion) means having auto-generated unique IDs that you can find in advanced settings or somewhere and opens up a can of worms with URLs (doing what Discourse does, for example, is out of the question; I have strong feelings about URLs!).
Which, as @apb and @chelsea have suggested, means resurrecting the at the soonest after we’ve tackled the next priorities, including Todoist integration and Paypal. (Or maybe we’ll stick in @kenoubi’s togglability idea for the dashboard but that’s it until Christmas!)
Ah yeah, earlier I was referencing Dropbox Paper’s URL scheme but I didn’t realize Discourse does the same thing. For the record, I think the Paper/Discourse scheme is ideal. The URLs are easy for humans to read but also don’t suffer from all the problems of renaming the unique id portion. It seems win/win to me