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

Content warnings aren't preserved when replying #113

Open
sk22 opened this issue May 2, 2022 · 16 comments
Open

Content warnings aren't preserved when replying #113

sk22 opened this issue May 2, 2022 · 16 comments
Labels
wontfix This will not be worked on

Comments

@sk22
Copy link
Contributor

sk22 commented May 2, 2022

In other major Mastodon apps, the content warning gets preserved when replying to someone else's toot. Here, only replies to one's own toots with CW get tagged with that CW as well.

In case this is intended: One could argue that replies don't necessarily require the same content warning, so one could just add the appropriate CW manually - but I think that mostly, the same CW still applies. Also, it's way quicker to remove it than to re-add it from before.

@grishka
Copy link
Member

grishka commented May 13, 2022

This is by design.

@grishka grishka added the wontfix This will not be worked on label May 13, 2022
@realpixelcode
Copy link

This is by design.

But why? 🤔

@sk22
Copy link
Contributor Author

sk22 commented May 15, 2022

This is by design.

Again, this is kind of bad in terms of communicating with other users who use other apps (like Mastodon's web client). In threads with content warnings, people are used to the CWs staying in place when replying. It has occurred to me that I replied to a mutual's post that had a CW, accidentally dropping the CW in the reply. They kept replying, manually adding the CW back and asked: "Also, you keep removing the content warning. Is that a bug with your client?" It's annoying.

It also makes the most sense to preserve the CW, imo. When replying to a post about a specific topic, you usually stay on that topic (some non-standard clients prepend a "re: " to indicate that the CW isn't specifically about the reply post itself) - and if you don't, you can still remove the CW with the tap of a button. And if the reason for not including this behavior really is that the CW might not apply to the reply, then why is the CW preserved when replying to one's own posts?

I really hope this decision is reconsidered as it does negatively affect how communicating with people works; it breaks an established netiquette that, to me, makes total sense to keep in place.

@SamStephens
Copy link

@grishka please explain the logic here. As others say, this differs from the other applications. But this also differs from the official web application itself. It's a bad look that the Mastodon official applications cannot even manage to be internally consistent in this handling. I've recently upset a few people because I've expected the same behavior from both web and Android, and because of this omitted Content Warnings from replies that really should have had those warnings.

@yretenai
Copy link

I would argue that consistency is important on primary clients (i.e. the Web interface and the Mobile clients.)

At the moment the advanced web interface does preserve CW when replying, a lot of other clients also replicate this behavior.

@Gargron
Copy link
Member

Gargron commented Dec 13, 2022

I'm thinking of adding an explicit "copy CW from parent post" button.

@SamStephens
Copy link

SamStephens commented Dec 13, 2022

@Gargron

I'm thinking of adding an explicit "copy CW from parent post" button.

Why not just use the same behavior as the Web App and copy the CW by default. It's easy enough to then remove the CW if it doesn't apply, and copying the CW works well because generally an entire thread is about a topic such as politics or harm that the same CW applies.

Basically, the web application behaviour is well known and effective, and would be just as useful here.

I could see a case for copying the CW and then providing a "Remove CW" button, if removing the CW is otherwise too clunky on mobile.

There's also a principle here that a lot of people use Mastodon across both their mobile and computer (aka Web), and every way behaviors across the applications differ adds additional cognitive load to users of both mobile and computer. Which isn't to say there should never be a difference in behaviour, but is to say that behavioural differences have a cost for users that needs to be considered.

@Gargron
Copy link
Member

Gargron commented Dec 14, 2022

Always copying the CW creates a lot of unnecessary CWs which in turn ends up frustrating people who have to click/tap to see something that doesn’t contain anything worth hiding in long threads. I think that a button to copy the CW would bring a better balance between convenience and deliberation.

Also, the web app was not designed with professional UX designers, so it should not be held up as the gold standard. Yes, people are used to how it works but that doesn’t mean how it works is optimal. These apps are a way to try new approaches without bothering anyone used to the old ways since they can just not use them.

@SarahGreyWolf
Copy link

I don't feel there is really an amount of CW's that are "unnecessary", if a reply chain originates at a content warning then it can be pretty certain that all future replies should also contain content warnings, if not for the content of the reply, then for the fact that people may end up exploring up the chain to find the original message.

If you wish to change the functionality of the web app in the future, I feel you should atleast be supporting the way this works currently so that people who use the web app won't get nasty surprises from the functionality being different.

@grishka
Copy link
Member

grishka commented Dec 14, 2022

This behavior does also get annoying on non-Mastodon servers especially. This, for example, is Smithereen (my personal fediverse project) and it doesn't treat replies the same way it treats the top-level posts:

image

Since in Smithereen a comment/reply can't appear on its own in a timeline, the CW copying doesn't make sense. Then there's also the fact that not all replies to a post with a CW warrant their own CWs — after all, if someone replies to an NSFW image, the reply itself would probably not be NSFW, and thus doesn't need a CW.

@realpixelcode
Copy link

I don't feel there is really an amount of CW's that are "unnecessary", if a reply chain originates at a content warning then it can be pretty certain that all future replies should also contain content warnings

The vast majority of replies to basically all CW posts I've seen had CWs themselves despite not needing them, since they merely read something like “Yeah, I completely agree” or “Oh no, that's bad 😕”.

That's not only frustrating, it also undermines the very purpose of content warnings. Just like the name suggests, they are used for NSWF, gore or disturbing content. When you open tons of non-CW-worthy replies, you're much more likely to accidentally open posts with valid CWs.

We shouldn't provoke such accidents (that have happened to myself) by issuing CWs for replies by default.

if not for the content of the reply, then for the fact that people may end up exploring up the chain to find the original message.

...and they'd notice that the original post might be NSFW/gore/disturbing and choose not to open it. In contrast to a conversation completely covered by one single CW, they'd be able to tell harmless replies apart from potentially harmful ones.

@sk22
Copy link
Contributor Author

sk22 commented Dec 14, 2022

I think it's good that CWs are preserved when replying to a post that has a CW. Say people are discussing a sensitive topic (like trauma or topics that are actually triggering people - or even, say, "thoughts about twitter") and replies don't contain a CW - the CW probably still applies to the reply (even if semantically better to be prefixed with "re:").

Also, when discussing a topic, people obviously don't always mention the name of the topic they're discussing. And replies can also be boosted, so if CWs (containing the topic name) aren't preserved, filters won't work either.

And for Smithereen, since replies are handled differently to regular posts, maybe you can automatically hide the CW if its contents are equal to the parent's CW?

@sk22
Copy link
Contributor Author

sk22 commented Dec 14, 2022

I'm thinking of adding an explicit "copy CW from parent post" button.

But yes, maybe this isn't too bad of an idea after all. But that button should be very visible and not easy to forget - maybe like a full-width warning-style bar above the toolbar at the bottom (that contains the "Add media"/"Add CW"/...) button - but that'd of course be for the UX designers to decide.

@grishka
Copy link
Member

grishka commented Dec 15, 2022

Sometimes people use a CW as a kind of caption, and then this looks even more ridiculous:

image

@koyuawsmbrtn
Copy link
Contributor

I also stumbled upon this issue. Then at least implement such a button in the Web UI.

@sk22
Copy link
Contributor Author

sk22 commented Jul 14, 2023

Always copying the CW creates a lot of unnecessary CWs which in turn ends up frustrating people who have to click/tap to see something that doesn’t contain anything worth hiding in long threads.

what i've done in my fork is that i have an option (that's enabled by default) that expands replies' CWs by default if they're the same as the opened post's CW. something like this might be an option? (i think copying the CW still is good practice on fedi)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants