Advise on how to organize my forum categories and tags

Hi there.
I’ve read several topics here about category and tags organization, but I couldn’t come up with a structure that fits my needs.

Basically it’s a support forum that covers many products. There are maybe 50-100 different products, and they are grouped in around 5-10 “departments”.

But I’d also like to differentiate permissions for customer/non-customers. That means non-customers will have read/write access only to the “standard” support, and read access to “VIP” support, while customers will have read/write access to both.

Also, I’d like to use the voting system to create a “feature request” mechanism for users to request features and be able to vote (for each product). Again, only customers will be able to request features and vote; users should only be able to vote on feature requests, not other topics, and of course everyone (staff and users) should be able to easily see the most requested features.

What is the best option? At beginning I though using a gazillion of categories:

  • DepartmentA
    • Product1
      • Feature Requests
      • VIP
    • Product2
      • Feature Requests
      • VIP
  • DepartmentB
    • Product3
      • Feature Requests
      • VIP
    • Product4
      • Feature Requests
      • VIP

But it looks like it’s too many categories.
Tags seem to help in this case, but how they could be used, enforced, filtered and permissions to be applied?

One major downside I see in tags (besides the permission stuff) is that every Discourse forum I visit that is an “example” for tags (like the Car Talking one, but there are others), in the end it looks tags are simply not used. Very few topics are tagged, and everything end up in the same place.

Thank you in advance.

2 Likes

I’m not sure if this will suit your needs, but I’ll share in hopes some nugget of it may help you.

We recently moved our 16-year old community from SMF to Discourse. Our user base was very content with layers of categories, sub categories, and child boards galore. It was quite ridiculous how many we had, really. Poor new users would get so lost in the maze.

Since moving to Discourse, we now have Category > Sub Category > Tags. Tags have replaced the 9172816 child boards we used to have.

I made it mandatory to use a tag to post a topic, and they can only choose from the tags I’ve created for each category.

  • Set the category setting to “Minimum number of tags required in a topic: 1”
  • Create tag groups for each category + uncheck “Also allow other tags” in the category settings:

We opened the doors at New Years, so still a work in progress, but here you can see my tag groupings. the Lettuce Craft Forums

In the topic creation flow, it requires the user to select 1 tag min/max. I customized the wording to “Now select one 1 tag (subcategory)” I’m aware a tag isn’t actaully subcategory, but this is the verbiage we need to use to teach our old dog/new tricks community for now.

If the user tries to skip tagging:

9 Likes

You two have made this topic look like the start of a tutorial with your clear and informative posts. :+1:

I’ve made this long response because I’ve been thinking about how we can think about setting up new forums. So I thought that I’d experiment with your issue to see if I could actually prepare something and see if you find this useful.

I agree with considering tags instead of putting everything into categories which is what I’m doing myself in some private forums. But you need to be aware that, at present, there are two clear advantages to categories:

  • Categories are essential for controlling access
  • Plug-ins allow much more customization of categories

You may want to look at Is anyone else using tags on a Discourse forum in a big way?

New tag features are frequent developments at present and will be a large step to making tags easier to use. These include:

The key issue here is which of your requirements should be handled as categories rather than tags. But we don’t have to decide that at first. We design the categories which are heavy features and then look at what can be converted to tags.

The decision making process

There’s more than one way to approach designing your categories. When not considering tags as the primary mechanism then I would go:

  1. What categories are needed?
  2. What categories require separate user access controls?
  3. Do I now need the default categories?

Here a different route than would normally be used because you can see the minimum default categories that might allow you to do everything else with tags.

  1. Do I need the default categories?
  2. What categories require separate user access controls?
  3. What other categories are needed that don’t require user access controls?

A. What is the overall requirement?

First, what is the rationale for the community that will be used to develop the forum structure - community and forum are different.

From your first post I can say that you have the following requirements for your community:

  • The main purpose is support
  • Support is driven by product i.e. no products means no customers and no support required.
  • Support is segmented by customer status i.e. customer vs non-customer
  • Product has an additional feature request - from customer and non-customer

Additional requirements for the forum are that:

  • Department manages product - but customer/user interacts through product

Notes:

  • Support might be managed by department but the customers/users probably relate to the products they use. So I wouldn’t complicate the forum by including your organization structure unless your departments are brands or subsidiary companies that the customers and users will almost exclusively identify with in their normal dealings.
  • I use Customer here because there should be a caveat on the use of VIP. It removes the option of creating a VIP subgroup of customers later on. I have seen this problem before in a forum for community professionals, so I would reserve VIP for further segmentation.

B. What are the minimum categories to achieve the overall requirement?

1. Do I need the default categories?

I consider all the default categories to be essential but you might not. Just be aware that the defaults are set with a lot of consideration for the requirements of the average forum owner and forum users:

  • #lounge
    By default this is for Trust Level 3 (TL3) users. I suggest that you retain it as a perk for your most active non-customers. You might be tempted to use it for your VIP category by renaming it and reduce the minimum TL to access it. Don’t: keep your VIP group and category separate from the default groups and categories.

  • #site-feedback
    For all users to suggest improvements or point out issues in your forum.

  • #staff
    For admins and moderators so not visible to most users.

  • #uncategorized
    The default setting is allow uncategorized topics.
    You may want to disable the suppress uncategorized badge setting to make such topics more visible in topic lists so they are more likely to be assigned to a more relevant category.

    • This makes a bit more work for moderators and high TL users but makes it much easier for new users who can’t decide on a category.
    • This category is the default shared drafts category which is another reason for keeping it.

Example

At this point your minimum categories would be:

  • Lounge
  • Site Feedback
  • Staff
  • Uncategorized

2. What categories need user access controls?

The only definite requirement is that:

  • Support is segmented by customer status i.e. customer vs non-customer

You want to separate users and customers so categories must be used for this. Any other method will be oh so painful.

That means that you need customers and non-customers each in a separate Group with at least one category where:

  • Customers have CRS (Create, Read, See) access
  • Non-customers have only S (See) access.

Example

At this point your minimum categories would be:

  • Customer
  • Lounge
  • Site Feedback
  • Staff
  • Uncategorized

3. What other categories are needed that don’t require user access controls?

Your requirements are:

  • Support is driven by product
  • Product has an additional feature request

Even without your requirements, the structure so far looks decidedly inadequate because it is not clear where to put product support requests. So you need at least a product support category which then requires a Customer sub-category. I would leave a high level Customer category as a place to address issues that are only shared with and probably only visible to the customers.

You can rank product feature requests by using the Feature Ranking plug-in. This works by ranking topics in a category so you need at least one category. Then you might have two options to display the rankings by product:

  • One category with views filtered by a product tag. :warning: AFAIK, this might be a show stopper now but I haven’t tried it.
  • One Feature Request sub-category per Product category

Whichever option is chosen, it will be easier to place the Feature Request topics in a sub-category.

Example without individual Product categories

At this point your minimum categories would be:

  • Customer
  • Lounge
  • Site Feedback
  • Staff
  • Support
    • Customer
    • Feature Request
  • Uncategorized

Example with individual Product categories

At this point your minimum categories would be:

  • Customer
  • Lounge
  • Product 1
    • Customer
    • Feature Request
  • Product 100
    • Customer
    • Feature Request
  • Site Feedback
  • Staff
  • Uncategorized

Now comes the question of the relationship between products and those who use them.

Issue One Category for Support One Category for Each Product
Do most/all customers use most/all products? Yes No
Do most/all customers relate to individual products No Yes
Which has better support in core Discourse Tags are more limited Categories have better support
Which has better support in plug-ins Tags are more limited Categories have better support
Easier category management Yes No
Easier view and report management No Yes
Easier for new Discourse user No Yes

On balance, I think that you should go with individual categories for each product as it will work and the main disadvantages are the long category view and a boring period spent setting up category and sub-category details and group access.

Example with individual Product categories (as shown above)

At this point your minimum categories would be:

  • Customer
  • Lounge
  • Product 1
    • Customer
    • Feature Request
  • Product 100
    • Customer
    • Feature Request
  • Site Feedback
  • Uncategorized

4. What other categories might be useful

I’m sure that you are aware of other categories you might want that you haven’t specified here, e.g.:

  • Company documents e.g. generic terms and conditions across all customers and products
  • Product documents e.g. product-related documents
  • Downloads e.g. product-related software such as old versions of a software product itself
  • How To tutorials
  • FAQs

C. What features should be tags?

As to what tags you should use, I’d need more info e.g. on how departments manage support.

At the start, I would leave Department out your forum because you can develop reporting based on Product with summaries by Department that wouldn’t need any visible tagging.

I’m referring you to existing topics here to give you the flavor of what can be done with tags in a support forum. These topics are newest to oldest:

Also some useful plug-ins:

And useful theme components:

6 Likes

Thank you both @soraiden and @Remah for the very detailed answers. Really appreciated.
I’m still not decide yet though. Really hard.

Suggestions from @Remah seems to be more appropriated to my situation, but then when you say: “then you will have Documentation, HowTOs, FAQs, etc.” - won’t they also be related to products?
This increases the feeling that products should be tags, otherwise I will have to keep duplicating subcategories all over the place (like the suggested “Customers” and “Feature Requests”).

On the other hand, it’s desirable that each customer has different access per product, as indeed, Customer1 might have registered ProductA, while Customer1 might have registered ProductB, and they are different. Even though I could live without this, if really needed.

I’m also afraid of setting up things tag-based to only discover later that some key feature is only available for category but not tags…

One thing I didn’t understand from @Remah suggestion: why would I need a top-level “Customer” category and then a sub-category “Customer” inside each product?

But again, thank you very much for very detailed and organized answer.

2 Likes

What is your lead time for getting this forum going? If it is short and time limited then the opportunity to experiment with tags may not be there.

By the way, while trying things you can setup both tags and categories side by side. It won’t matter if your tag structure duplicates the category structure. If you use categories then tags won’t need to be used so they just won’t be seen because nobody has to use them.

That is the issue that concerns me too. My heart says try tags but my head says they are not quite there yet. I already identified one potential road block with tags - the :warning: in my earlier post about filtering by tags not working with the Feature Ranking plug-in. However, the Discourse team are motivated to enable heavy use of tags so they may see opportunities to develop some new features to help out.

You can start developing the forum structure by using tags instead of categories. If you can’t achieve what you want at this time then your fallback would be to create all the product categories and subcategories.

Make sure that you record everything that you can’t do and don’t understand. Then come back to this forum with those issues and ask for solutions.

Categories are very visible and exist independent of the topics whereas tags the tag structure is not so visible and tags only exist when there are topics that use them. So to seed the forum with the tags you want to use, you will need to have “example” topics that use them e.g. a product list topic.

One additional advantage of tags is that you can create tag groups so your products can be grouped under tag groups for your departments. The departmental tag groups won’t have to be added to topics because adding the product tag to a topic will indirectly associate the tag group with that topic. So tags will offer some unique options that you would not implement with categories.

:+1: Yes, I would say that is very likely. But you should work through the process of deciding the pros and cons of each option.

If you have a Customer sub-category for each product then where will you put topics that relate to all customers but not all users? It doesn’t need to be a separate category but it is worth thinking about what you might need or could leverage to do new things

A new forum is an opportunity to adopt new ways of doing things.

2 Likes

Read this topic about the current state of tags.
https://meta.discourse.org/t/is-anyone-else-using-tags-on-a-discourse-forum-in-a-big-way/132555/10?u=remah

3 Likes