One detail we need to figure out here is what we do in the event that someone adds the subcategory and not the parent category… should the parent category always be included for context?
It is more or less must, if sub-categories can have duplicated names.
I’m not a dev, but I’m doing a lot UX/UI-related gigs so I would say that using same name is really bad policy anyway. So one solution would be forcing even real names be unique (and after that out there is tons of broken forums…)
But could you guys give free hand to name categories by admin way that is not related to tech of forum? It is just another visibile name for users — so then one could use something like category:sub-category.
I just went through and renamed all of our sub-categories with a category prefix but I also agree that nesting would a good option. Because we have different security levels on each top category, we went with the same name but I can also see the advantage of having prefixes.
It would also be nice if the categories could be toggled open and close - with over 200 categories, it is a long list.
Our intial thinking is that we may start with some simple improvements here:
Always order categories by parent category, then subcategory
Show the half-and-half badge style for subcategories (so there’s some visual hint of its parent)
It doesn’t solve the whole problem, but the workarounds of either: 1) having users add the parent category themselves or 2) updating category names to distinguish are both available.
We’ll keep an eye on this though and consider what other changes may be warranted.
How many of these categories do you expect a given user will add to their sidebar?
Toggling subcategories in the sidebar is essential. We have nine categories and 19 subcategories already and I haven’t finished sorting. I expect to add 25 more subcategories. I would like them all to be available in the sidebar. Our corpus has been building since 1969 so our forum serves as a reference library as much as it does a symposium. For us, categories are both finding aids and conversation filters.
For that same reason, tags need to be alphabetic and scroll-able in the sidebar. We have 1400 tags and that will double by the time I am done sorting. Without a scroll window it will be impossible to present tags in a useful manner. In fact, a scroll window with a query box on top would be ideal.
It’s probably a separate discussion but putting tags in switchable pop-down windows under topic titles in list view would also be very helpful. Our topics have an average of 18 tags each. Our longest topic has 98 tags. When I present them all they obfuscate the topic titles. I mention it here because implementing a generic toggled scrollbox class could serve multiple useful purposes.
It would also be nice if the categories could be toggled open and close
Why? It would be really horrible to use, because that list will be a mile long. Well, if majority of your users have 24” screen or bigger and you don’t mind smaller screens and mobiles and your users don’t know how to use category page then maybe.
And we are back to the main issue: an user must have the choice what to see and what not. It is not admin’s job to decide.
Because it would make for easy navigation. It would be much cleaner than double width category/list view which is the only current option and which takes up way more screen than a single list with a sidebar if real estate is the issue.
Why
Assuming you are referring to tags, a mile long alpha-numerically ordered list scrolling within a window controlled by a search box above it and a mouse wheel would be pretty convenient, way better than any other tag presentation. That includes the massive list view of the tags page which is absolutely not a convenient navigational aid because it requires whiplash paging back and forth from tag page to topic and for which the only tool is the back button on the browser.
that list will be a mile long.
So two points here.
First, Discourse is built from the bottom up for the future which means it is intended for everybody having generous, high resolution screens. It is nearly a moot point anyway, I just shopped for a new monitor for my daughter last week and found zero available at less than 24-inches.
As for mobile I can only say that navigation designed for those classes of interface is in every way different than for a desktop or laptop. Sidebars are not an appropriate tool.
if majority of your users have 24” screen or bigger and you don’t mind smaller screens and mobiles
The future, that is even normal monday already, is totally opposite. It is builded on mobiles. Sorry, but big screens are yesterday’s news.
Did you know that in Europe mobiles are more common than laptops? But we don’t have landlines or cheques anymore either (except UK/Ireland, but they are lagging behind something like 50 years )
Yeah, didn’t see that coming at all. I do think the slidebar version of the sidebar is well suited to those pesky mobile devices.
So maybe you know, is this the mobile app that comes with the lucky forums at Digital Ocean?
Stephen, thanks for this suggestion. I installed it and am playing with it. It might work for a large set of articles that we have not added yet. What I need for those is the ability to comment in order to draw the reader into discussions. I have been thinking of integrating Ghost with Discourse for the purpose.
I do still think the sidebar will be ideal for desktop/laptop navigation if it comes with a toggling scrollbox for tags, and with toggling categories.
The color badge is very helpful for distinguishing parent-subcategory relationships. Sorting and possibly indenting should solidify the visual identification of subcategories. Here’s what I mean:
documentation is the parent category to admins and sysadmin. In the current setup, they are sorted by alpha and the only indication of a relationship is the half-badge color. Obviously, this is not ideal.
When sorted, we get a sense of order and relationship, but still it’s only a color badge distinction.
A better way would be to give the subcategory a subtle indent which is universally understood as an indication of a category-subcategory relationship. The mockup above shows what that might look like when the subcategory is indented by a half- or full-width of the badge.
Thanks for taking the time to mock up these ideas!
There’s another scenario to think about: when users have all the above categories in their sidebar that you’ve illustrated but not the Documentation parent category. How would you imagine handling that scenario?
I suppose it would depend on the site’s structure. In my OP where I used Ford and GM as an example of a structured community, not including a parent category could make the sidebar hard to read—which is which?
In this case, the parent category should be shown:
Driving
Driving
In cases where each subcategory can stand on its own, the parent may not be necessary.
For categories with subcategories, my community treats the parent as a placeholder that has no topics. Instead the topics are all in subcategories. We do have other standalone categories.
So, ideally an admin would be able to choose whether the parent category is listed in the sidebar.