In our Discourse forum, we have a few top level categories that exist to group their child categories. For instance, we have Feature Requests which contains Client/Studio/Web Features, Bug Reports which contains Client/Studio/Web Bugs, and Lounge which contains Off Topic and Platform Discussion.
The top level categories are locked because we had too many people posting in them instead of the appropriate subcategory – we would rather them guess which subcategory and get it wrong so their thread can be seen and moved versus posting in the top level and no one noticing it. The results of locking the top levels have been mostly positive, but we’ve also had an issue of users thinking the category is locked for them.
Instead of recognizing that there are subcategories to post in, they see the locked top level and think “Oh, I don’t have enough permissions to post feature requests.” I suspect that this is because the “New Topic” button is greyed out rather than the top level not appearing in the Create a new Topic category dropdown because the complains have always been “The category is locked”.
It would be nice if there was a way to communicate to users that a thread can’t be posted in because you’re meant to use its subcategories rather than them not having appropriate permissions. For instance, the ability to mark categories as top-level and have them show no topics in their list on Latest, but instead just a list of their subcategories similar to the category list.
We do explain this in the pinned category description, but nobody ever reads the pinned threads (which is why users never knew they weren’t supposed to post in top-level) – they just look for “New Topic” and click.
What the New Topic button is greyed out? I can’t post feature requests! Ignores pinned thread which even says don’t post here in preview
This UX is regularly confusing users because it’s impossible to tell the difference between not having access to an entire category along with its subcategories as opposed to just the top level being locked. There needs to be an improvement in some form so users aren’t confused so easily. Maybe a better suggestion would be making the New Topic button functional but it gives an error like with no title when a subcategory hasn’t been selected?
Hmm. I’m not sure what the correct solution is. Could you use tags instead, maybe? That’d be more flexible. However, looking at your list I would agree that Xbox bugs are very different animals than, say, mobile bugs so the hard walls of categorization are probably useful / warranted in this specific case versus the softer, more nebulous grouping of tags.
The other thing you could do is just allow posting in the root category and then hope the user selects the correct sub category – or recategorize on their behalf as new topics come in. Your topic template could indicate this… assuming the user reads stuff.
It really depends on your users; how disciplined are they / can they be?
We used to have the top levels unlocked, but they were locked because users were posting in them when they never should have. PMs asking us why a category is locked is preferable to them posting in the wrong category. We had templates when the top level categories were unlocked, but the first thing anyone does is delete them. It didn’t make a noticeable difference in top level categorization.
We used tags in the past for the Nomination category, but tags caused problems of their own. We might have someone tag a bug in Mobile Bugs, Xbox Bugs, Client Bugs, and Studio Bugs because it happens in all of them, where we prefer categories like mobile being used for platform-exclusive bugs, with Client Bugs hosting universal issues.
This is not an issue of discipline. We never see the same user making the same mistake with categorization over and over – once they make the mistake, they’re done. We have the most important rules for our site communicated on signup, but this isn’t one of them. If we added every little nitpick to the intro PM or forum rules, it’d be information overload and they’d never read them, if they even do now.
The correct solution seems clear to me. We have an unambiguous rule that all users must follow, and so we configure our forum to never allow this incorrect behavior, much like we would with min_trust_level for a category. Discourse successfully empowers us to do this, as it usually does. The only problem here is that users are being confused by UX. Is there a problem with enabling the New Topic button and giving an error similar to no title when no subcategory is selected?
I can’t think of a way to do that in the code that isn’t an incredible hack, no. You could maybe add a tooltip to the button? Some kind of CSS customization specific to this page, perhaps? That’d be best.
Let me check with a few of the users who PMed us and ask if they moused over the button before PMing us.
If we could replace “New Topic” with something that said “Post in Subcategory” maybe that would work. What are your opinions on this?
Edit:
What about defaulting to no category for “New Topic” where threads are locked, and letting the users search in the category dropdown? If I search for “Feature Requests”, I see the subcategories and will end up categorizing my thread correctly. Same behavior as from Latest, so I don’t think it’ll cause confusion.
I replied to users who had PMed me, and they all said they determined the category was locked because it was greyed out, and didn’t even mouse over it. A tooltip wouldn’t help in this case. We’d either have to:
Not grey out the New Topic button, but give it a mouseover saying “Did you check the subcategories?”
Allow the New Topic button to be clicked, but pop up a message saying. “Did you check the subcategories? This top-level is locked.”
Replace New Topic button with some sort of indicator to check subcategories
Similarly to Latest, allow New Topic to be used, but default to no category for locked categories, requiring the user to search for categories where they’ll find the subcategories.
Allow the user to select the category. If it is not writable, then pop up the red tooltip thingie that says something like: “You should not post here, noob! Try picking one of the sub-categories such as foo, bar, baz…”
Just reading the category description/ pinned topic, I can see why some users are confused.
If you’re not sure where your feature request belongs, please do not post in in Feature Request category itself, just guess.
The part that I’ve bolded makes it sound like posting in the feature request category is something that is possible, just not something users should do.
I would myself change it to something along the lines of
It is not possible to post in the Feature Request category itself, so please use an appropriate subcategory. If you’re unsure about where your feature request belongs, just guess.
You just swap out Category_name in the selector with the actual name. It’s case sensitive.
Edit: This won’t be of much use if the user clicks the new topic button (which is disabled in your case) - while in the category. Because the composer is then open with the current category pre-selected.
Ideally this would work the same as when allow uncategorized topics is unchecked, coupled with the standard logic for when you’re starting a new topic from within a category:
user clicks New Topic and starts to compose
no category is selected but the only available categories are the sub-categories. The parent category is not an available option.
user may not post without a category selected.
So instead of blocking the New Topic, we merely block the selection of the parent category.
It is a good idea but it is a bit of a special case and I have no idea how weird that will be to implement, or when we could get to it.
In the meantime, a CSS text substitution for this particular page would be VERY easy to implement in the next 15 minutes by anyone with enough CSS skills, who is able to click on Admin, Customize…
Users usually don’t like guessing and getting it wrong. I’ve usually seen research on this depending on input/checkout forms, but I think the same principle applies here.
It’s a tough one to give a solution for though.
I know this is quite a drastic change but, maybe change the buildup of the forum? Instead of going category -> platform, go platform -> category?
So instead of Bugs -> Xbox Bugs have an Xbox categorie with the subcategory of ‘bugs’?
I would be surprised if no research has been done on this before.
I have started looking into this, and the first item is a fairly easy fix:
user clicks New Topic and starts to compose
The second item of the logic has three parts:
a) no category is selected but b) the only available categories are the sub-categories. c) The parent category is not an available option.
a) and c) make sense to me, but I’m wondering whether we should change the available categories as described in b). Currently, the available categories aren’t ever filtered (AFAIK). All categories where the user can post are always available in the composer.
Should the categories be filtered down to the subcategories only in the context where the user is in a parent category with permission to post only in its children? (FWIW, I think, no.)
For the third item:
user may not post without a category selected.
Should we force a category selection even in the case when allow uncategorized topics is checked? It would be easy to change nothing here, i.e. let the composer default to no category and let allow uncategorized topics decide whether topic can be posted without a category. (When uncategorized topics are allowed, this would result in topics not being categorized correctly. But my feeling is that those sites are likely OK with some topics wrongly ending up in uncategorized.)
