I’m using Discourse internally at a large organization that has people working in many different offices on vastly different types of research projects. We’re getting complaints that users are unable to really “parse” the default landing page and would prefer to have an easier way to get to the categories specific to their research areas.
What I propose is this:
allow users to “favorite” or “star” or “bookmark” categories of interest.
when they visit the categories or bookmarks page, those categories appear at the top of the list.
This would just give users a simple way to isolate categories of most interest.
I’d love to see an alternate landing/latest page that only showed posts from the favorite categories, but IIRC, that’s been debated here previously and shot down.
I believe members can remove “unwanted” categories from (some of?) the lists by Muting them in their Preference Settings
But I don’t think there is a way to “prioritize” the “wanted”
Yeah, I thought about that… We have tons of categories, so I can’t really ask people to do that. It would take them too long and be confusing to new users.
It would be more interesting if this category preference was learned automatically, e.g. this user only ever goes to the Sports category, ever… as measured by topic entry data, so show Sports at the top for them.
This was discussed a long time ago as something we wanted to build but have not had time.
Automation is cool, but there are some functions that the topics have that I think the category could benefit from, like inviting and sharing. Our categories are our communities, but the category page does not expose many options for users beyond creating and browsing topics.
2 - The user can then ‘favourite’ one or more categories by clicking on the appropriate stars - which then change to solid white. As each category is added, the view is re-sorted and the the favourites are moved to the top of the view.
3 - Once favourites have been selected, the user can optionally remove non favourites from the view by clicking the star top right of the page. This applies a filter to the view. (This functionality can easily be expanded to filter by additional attributes)
This is all working in my prototype although I have yet to persist the user's preferences to the server. I'm still reworking client side code so this may take some time to achieve. But in principle, this is a very light weight way to achieve what you need, at least on the category page. Once favourites are persisted, it shouldn't be difficult to retrieve them and sort and filter topic views using the same methodology.
In the short term, these preferences could be stored in a cookie, although clearly the above 1,2,3, process would need to be executed on every device the user uses to access the site.
I really like the work you’re doing, though it’s heavy for my current needs. We have per-project categories - about 80 of them, at the moment. The group/category management is getting to be a real bear. (On another note, I’d love to see group creation/management optionally bound to category creation/management). About 60% of our categories are private b/c the projects are under NDA.
As you continue your design work, I’d suggest trying some edge case mock ups to see how well they handle large numbers of categories. FWIW, our company worked on over 10k different projects last year. I’ll never agree to support that many categories, but it does make you think about the scalability.
The problem is, where do the founders turn next in terms of roadmap? They can’t preempt every use case, although if they provided a little more on the client side in terms of hooks and functions, a wider cross section of the community could contribute solutions.
I’ve no need to develop this beyond my own requirement, which is limited to a maximum of 20 or so top level categories and 50 to 100 in total.
Going back to my first point, well developed client side tools, sitting on top of a supported client side API, opens up the possibility to take the UX in any direction, especially for batched requirements such as:
Create Group(s)
Assign Users to Group(s)
Create Category
Assign Group(s) to Category permissions
Notify Group(s) members of new Category and their CRUD permissions
This type of batched process lends itself to very large numbers, but also opens up the potential need for additional levels of normalisation - although that’s probably a bridge too far at this stage.
Hi ccdw, I was wondering if you had success with integrating packery with discourse? If so I was hoping you’d be able to give me a hand with our forum. please feel free to PM so we can chat. Thank you!
