Category names with spaces

Now that my category names are different to the category slugs, and have spaces in them, it would be nice to be able to do something like #“Questions & Suggestions” and have it work instead of just changing it to #general.

This is a UX problem if your own making. Why would you make the slugs and names totally different? You could rename the slug “questions” without creating any code. I think that when you change a slug it creates a Permalink redirecting the old one to the new one.

The slugs are different because the original name of the category was “general” for general questions, and now the name is “Questions & Suggestions”. “general” is still a vlid slug name since it is for general questions and suggestions. I’m happy to hear about the permalink for redirecting old slugs - where do you configure or control that? But even so, I wouldn’t necessarily want to change it from general to questions since that would not cover suggestions.

But ok, no worries anyway, it was just a suggestion, feel free to ignore it if you don’t want to support category references with spaces in them.

1 Like

FYI, @pfaffman is not a Discourse team member so you’ll have to get one of the team to give you a categorical (maybe pun intended) reply.

2 Likes

Why don’t you do what most other sited do? Which is what I think @pfaffman is saying?

As an aside, I had a look at your forum after following the links through your blog from your user card because I’m always interested in anyone from the Antipodes.

I honestly don’t understand why you’d put “questions and suggestions” together because the drivers seems to be so different. Is this the category that is used if you need help with a problem or bug in the software?

  • My questions are based on my needs, want answers, are often bug-related, generally have some time urgency, and can be closed when they are answered/solved.
  • My suggestions are far more about discussion, can have slow but thoughtful responses, and often lead to topics in a potential new life as features.
1 Like

I do that as well. We found separate categories created a lot of admin busywork moving things between categories, and user confusion as they might search in the wrong category.

Users often think they’re making a feature request when the feature already exists and they really just need help finding it.

Other times they assume something’s already possible and ask for help in how to do it, when it’s not possible yet and their question is really a feature request.

Similarly with bugs, which often aren’t.

Now we’re on Discourse I did add some feature-request and bug-report tags to our Help & Support category, but to be honest I mainly did that to encourage people to use them instead of putting huge prefixes on their post titles. The tags are still often wrong and need changing but it’s a lot quicker to change them than to edit titles, so it’s a lesser evil if people insist on categorising things even when ~50% of the time they’re wrong IME.

1 Like

@LeoDavidson covered the issue exactly.

Users think they are making a feature suggestion, when really they are asking for help on how to do something already possible. They think they are reporting a bug when really they are not understanding how things work (which, of course, may be an indication that things should work better or differently, so might be a feature suggestion too). Or they are asking for help on something that can’t be done (feature request) or should work but doesn’t (bug report).

From the user’s perspective, the real thing is “I want to do x - help me please”. Whether it is a support request, feature request, or bug report is not something they can determine.

For a typical, example, I wrote a bug report on this form recently which was promptly moved to the “ux” category. Deciding whether something is a user interface concern or a bug report is not something that even well meaning users and discern clearly.

Hence the combined category.

And as I’ve said, the category originally was called “general” to cover pretty much all questions that were not specific to some case (like plugins for example), and to fit with meta’s and Discourse’s initial prompting on how to set up a forum. After experience, we’ve moved to more complete names, but this leads to experiencing the disparity in Discourse handling.

I would say, at the end of the day, Discourse categories have two names, a slug and a title, and it seems to me self evident that both should be equally and fully supported by discourse in every place that one or other would work (maybe not the title in the URL). Certainly everywhere you can use # or category: you should be able to rightly use either slug or title (IMHO). I value consistency highly as a mitigator of complexity. But it is not my software to change, I am just an appreciative user of it.

You’re right that I hadn’t thought about that aspect of administration: combining categories to save admin time. :grinning:

But I don’t see you doing the same thing with respect to naming the category. Yours is called Help & Support which are synonyms terms. Whereas Questions and Suggestions are not synonymous.

[quote=“LeoDavidson, post:6, topic:57583”]
Users often think they’re making a feature request when the feature already exists and they really just need help finding it.[/quote]

I was highlighting attributes of questions and suggestions which are good reasons to manage them separately. I wasn’t directly discussing features but it does relate to the topic because Feature questions and suggestions does make sense. This is what meta.discourse.org does: the Feature category takes all those feature requests, queries and suggestions.

The difference between the OP’s category name and this is that the first word unifies the category. Without a context 'Questions and suggestions` could be Wiki questions even if the Wiki category has more specifically included them.
You can see the OP’s categories at https://forum.keyboardmaestro.com/

@peternlewis might be better off leaving it as General if it is a catch-all category. All his other categories are so clearly described. General questions & suggestions would be too long and mainly superfluous.

@peternlewis, I saw your reply after I wrote this and I’d basically say the same again…

Why can’t you use questions-and-suggestions without spaces like other sites do?

Like @Remah said, I’m not making decisions on what gets implemented. :slight_smile: Sorry if my response sounded harsh or rude.

Though I don’t know enough about your community to make a recommendation about whether “questions and suggestions” is too much for one category, but do think that changing the slug to “questions” or “questions-suggestions” would solve the problem you describe.

I can’t remember for for sure, but I think that when you change a category slug, Discourse automatically creates a permalink for the old one, so any old links to it are not broken. You can check after you change it. If I’m wrong, you can find permalinks under /admin/customize.

4 Likes

Your reply seemed good to me; clear and concise. I should have made that clear in my first reply. :blush:

2 Likes

Why would I want a user visible title like “questions-and-suggestions” when I could have “Questions & Suggestions”? This isn’t the '90s…

Thanks, that is helpful. I changed the slug to questions, and it did indeed add a permalink for me, and I can edit it as necessary.

I still think both title and slug should be fully supported, but it is less problematic now.

1 Like

I was describing the slug not the title. I’m not aware that users see the slug anywhere else other than the category URL. What other scenarios are you aware of?

What are you suggesting in the category URL: spaces, %20 or something else? URL-safe encoding of spaces still raises other issues which are currently avoided by not allowing spaces.

By the way I see that for the moment you’ve settled on Questions in your forum.

Fair enough, but the issue is not the slug, the slug works fine.

the issue is dealing with referencing the category name when it contains spaces in either the search or in text.

I presume this is why Categories have a slug (short, URL safe) and a title (user visible).

My problem is that with a user visible title with spaces, it is difficult/impossible to use as a reference in text or searching.

Specifically, it would seem useful to reference a category in the text of its post with the full title since it is use visible.

I suppose if I had a slug “questions” and a title “Questions & Feedback”, and I typed into a discourse post “#quest” and it does its nice pop up thing and inserts #questions and then displays to the user the title in the markup render, that would be a solution. The problem as it stands is that it displays #questions, using the slug (intended presumably for use in URLs) in a user visible location rather than the title. If it displayed it something like #Questions & Feedback (or some other highlighting, perhaps using the category color), then the display would have no need for quotes, and the user would never really need to deal with seeing the slug (even though it would be there in the raw text).

4 Likes