Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Label context field #16

Open
chaoaretasty opened this issue Jun 24, 2023 · 3 comments
Open

Label context field #16

chaoaretasty opened this issue Jun 24, 2023 · 3 comments

Comments

@chaoaretasty
Copy link

I haven't dug deep into the specs or anything nor do I know how feasible this would be. However I think it would be useful for labels to include a freetext context field (optional at the label label though potentially required for specific labels).

This would enable two key ways to interact:

First for warn settings you can display the context to have an idea of you want to click through.

Secondly it allows communities to build up unofficial taxonomies that an advanced UI could allow more fine grained control of.

These thoughts were mostly inspired for the spoiler label. On its own it's too broad to be useful but also too broad a topic to ever definite a taxonomy.

Having a mandatory freetext context means those wanting to be careful in general can warn on the label, see the context isn't a shoe they care about or are you to date on, and click through.

Likewise if the community has coalesced to say MamdalorianSeason4 and it's the only one I'm worried about I could have an advanced filter that only works on that, knowing it's imperfect but will catch most of them.

Many of the other categories could similarly do well with optional contexts, particularly around eg sexual or poem where context could help a user decide if maybe it's a link they would rather not see. Or maybe would want to filter out anything but a certain context tag (this would filter a lot out but communities again may start coalescing)

@bnewbold
Copy link
Contributor

Currently labels are basically free-form tag strings, and communities could come up with their own arbitrary tag hierarchies and cultures. AO3 (archive of our own), delicious/pinboard, tumblr, and stackexchange all have interesting emergent ontologies of specific tag values.

We aren't certain if we will stick with free-form-tags for labels, or if we formalize them in one way or another to more controlled or documented vocabularies. The values we have documented in the current proposal are an initial set that we would expect virtually all clients to support.

I'm a bit skeptical of free-form text fields. They don't compose well if the situation is many labels from multiple subscribed-to labeling services all being synthesized together. There is a tension between being able to communicate very richly and being able to deliver a consistent and easy to understand experience to new accounts. I think the experience of content warnings as free-form text fields in activitypub has been pretty mixed: very successful and flexible in some contexts and communities, but difficult for new accounts or in "big world" contexts.

@chaoaretasty
Copy link
Author

I absolutely agree on your points of the limitations of freeform text, which is why I was specifically bringing it up in the context of secondary information on the labels to give context to the label itself.

Displaying the context text for warning CTAs is still a relatively basic user experience and I think the value/user complexity payoff here is quite high.

Beyond that it's more an enabler of secondary functionality. Opening up to many individual labelling services means the various ways it could be used can be up to those various services. Maybe some will define their own sub lexicon, others might use it as a way to pass extra info to the various internal algorithms.

Secondary filtering based on community conventions is the sort of thing that could reasonably be built up by other clients or hidden behind advanced filtering UI is it's a feature that is wanted, but also just an example of the usefulness of having a second level of information where the information is too broad to satisfactorily come up with a useful lexicon.

@Heartade
Copy link

Heartade commented Jul 5, 2023

I totally agree. For example, the "spoiler" label would definitely need more context for users to know what the post spoils, while having something like "SeriesName season finale spoiler" as a label would be terrible for algos to handle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants