I’ve looked in the forum and I haven’t seen these mentioned as a future plan yet.
A way to filter community post by tier or check what tier a post is visible to. Right now all posts show up as a list with no tags so it is impossible to tell what tier can see the post. As time goes on it would make sorting easier to make sure content is being delivered to correct tier. Or if you move rewards to a different tier that it got done correctly.
Custom categories for Community Posts. Just in case this isn’t on the road map being able to create our own categories on community posts would be nice. For example if do Q&A’s having a tag where a reader/subscriber could just search for only Q&A’s instead of scrolling through the Updates category where most things will get shoved.
I agree that the Community page is a little unwieldy and cumbersome right now. I’m so glad it’s there because it gives us some way to interact with our folx. But I’m looking forward to improved Community features!
I especially would love to be able to have my own categories and/or tags so people can find posts. Right now, as far as I can tell as a reader, the posts fall off the feed at some point and there’s no way to see them again…?
I just want to agree to what others have been saying: community posts are of cental importance to some of us. Please make them taggable. Please don’t make them temporary. They’re how my readers find the downloadable stories I’ve brought out.
These are great recommendations and all things we are super excited to begin rolling out in the near future!!
As someone who has one of their “rewards” shared in community posts, I would like to be able to sort for that reward (in this case, “Plushie Post”). Might also be useful to filter out certain types of posts.
I’m the Ream developer. I’m a bit averse to adding custom book categories for two reasons.
We already have tags which are custom. I was against adding those too. But I added them anyways.
From my experience (I have built systems like these in the past), users tend to unintentionally misuse customized tags/categories and damage their effectiveness in search/discovery. I’ll give some additional reasoning.
2A. Inevitably, there will be the same category listed 6+ times, each with different spelling or wording. This is not ideal for both authors and readers. A reader who searches one of the six categories won’t see your book unless it happens to fall into the category that you spelled/worded. This is bad for authors because their exposure for this category is divided by the number of different worded categories. This is bad for readers because they won’t see many books that they may have been interested in.
2B. Adding things that aren’t categories. People are going to add things that are not categories. This is harmful to the author because they are not going to get discovered. And readers will be confused why they are seeing those listed as categories.
What I suggest
I would be happy to build a system where authors can propose new categories and vote/downvote on them so that authors are the ones choosing the categories.
As for custom post categories, that’s fine as it only affects your account and not discovery in any way.
Don’t mind me, I’m just over here getting triggered by past projects.
Totally support the idea of proposing and voting on categories. Or, proposing and just accepting most, so long as they’re not basically a double-up. I have certainly seen some messy categorising/tagging systems recently! You’re right that they diminish the effectiveness of those labels.
All of this! Without heavy moderation, custom (“free text”) anything intended to be used as categorical data is a nightmare!
I like the idea of being able to propose new ones, but I don’t like the idea of voting.
That suggests there will be some kind of threshold or gatekeeping that could reduce discoverability for niche categories. Or at least it may feel that way.
There should be clear guidelines, such as authors can only upvote (not downvote) and once a category gets X number of authors, it is added. This would be okay with me.
Down votes could lead to a category being suppressed by a group of authors against that category. And the threshold should be reasonable such that not every imaginable word is added, but if several authors of a niche join Ream, their category is able to be added.
If I may suggest a reference for people, the AO3 has been tag wrangling for over a decade. They have a very long set of guidelines for how to do it, which, if nothing else, proves that tagging (and in this case, it’s close cousin, categorization) is a very complicated thing on the backend.
As a former librarian, @Sean, I sympathize with your fears. Like, a lot.
My opinion is that categories should be closely managaged, and I prefer @GaiusJAugustus’s solution of a threshold solution over voting; perhaps a bin of proposed categories where if X number of authors use a category, it become canonical. Any under that threshold are not searchable; any author chosing one of those “beta” categories would have to chose a primary “canonical” category to fall back on.
That said, I like free-form tagging and the organic folksonomies that result. However, they can get unwieldly fast, as the AO3 found out within days of launch. @Sean, I wonder if there is any kind of AI solution for this, down the road? Where the “rules” for tags can be entered then they are all filtered and cleaned up and related? Just spitballing ideas…
I’m desperate for free-form tagging on our own community posts, but I would love standardized tags on our story descriptions. At least a few. I can manage my own system, but trying to guess what other people are plugging in is so draining. Like, is it #comingofage or #coming of age??? Please. I have other things to do today. T-T
I’m also just really bad at thinking up useful tags – again, the mind-reading problem. A pull-down list like the ones provided for Categories and Content Warnings, even if it’s just a backbone of standards to get folks started, would be so helpful to me and greatly appreciated.
Totally! It is without a doubt in our plans to implement both these changes :).