Unable to retroactively make a post reply into a whisper

Continuing the discussion from How do I create a whisper post?:

I just wrote a whisper reply and forgot to select the whisper toggle, then saved changes. I then went back during the ninja edit window and edited the post but there is no whisper toggle available. To fix this, I had to copy the text of my post, delete it and then recreate it. <phew>

Better would be to be able to see the whisper toggle. As moderator or admin, it seems to me I should be able to do this anytime on any post, even to help coordinate and stage replies before publishing them.


Er, the cat is out of the bag once you post as a not-whisper. Going back and retconning posts into whispers via editing is not something I can support as a feature.

1 Like

Yeah, it wouldn’t be “honest UX” either, because even if you could change that post to a whisper after the fact, an email might have already gone out. We don’t wanna give users a false sense of security with this type of mishap.

I’d be interested in mockups for an even clearer whisper-on editor though. I think the editor should look quite different when you’re writing a whisper.


How about the other way around, i.e. making a whisper public?

Might not be super hard to do but then again the workaround is incredibly straight forward.

I’m back to this issue - we’ve been doing some frantic whispering in our community, with hilarity ensuing because we sometimes hit the wrong button to reply and forget to make sure we are whispering. Then deleting the public reply, writing a new whisper reply.

I understand the points made by others above and support them. But what if we were able to switch it still during the ninja edit window? The reply might blink in public briefly but then that’s what happens anyway until we rush to delete and recreate as whisper.


That’s a good idea as it avoids the problem that


That makes perfect sense to me.

I just experienced an issue when making a post to explain whispers to my staff through examples, but some mistakes in the example topic have resulted in “hidden replies” (deletes) and whispers in the same view that just make for confusion for new staff members. I wouldn’t blame them for thinking it’s not worth trying to understand the feature.

Is there any reason not to allow changing the whisper state within the ninja edit timeframe?

1 Like

I just feel it is too risky, what is the problem with the delete, cut-and-paste sequence?

My position hasn’t really changed on this. In my community there’s no huge risk involved in accidentally whispering so loud that some members hear it, then retroactively preventing others from hearing it in the future without having to do a whole bunch of juggling (copy, delete post, start new post, paste, explain what happened and action taken, deal with follow up questions from affected moderators and any future moderator wondering why the reply numbers are off, and so on). A toggle is harmless and super helpful… maybe as an admin feature at least if not available to all moderators.

I don’t know where off-hand, but elsewhere we talked about feature to let moderators know that a topic contains whispers, and let them hide/show the whispers for themselves. This might address some of the concerns raised above. I’d definitely love to have it in my community for moderator education and letting them see the flow of conversation without the whispers.

1 Like

It extra work (and confusion) for staff, compared to being able to edit the post state directly. It’s a strange user experience.

@tobiaseigen’s use of “Juggling” is apt; the workaround is a whole lot of manual steps and questions and explanations, instead of a single click.

I understand the risk for posts after the initial edit window has closed, but what is the risk of allowing toggle state edits within the first 5 minutes after a post is created, that isn’t also a risk for the workaround? In both situations, wouldn’t the post be temporarily visible anyway?

1 Like

I find it super hard to justify building a feature for a use case that in practice does not happen once you have done a minimal amount of training.

1 Like

Sure - I can understand that. And on reflection, this typically only happens once or twice for each new moderator as they learn the ropes. Once they realize the implications they are more careful.

But figuring out how whispers works has a learning curve and this accident happens to everyone, and it is a hassle for admins to have to explain it over and over to the new moderators. if it were easy I would be happy to see the feature. But if it is not easy then I agree it is not a high priority. We have learned to live with it.


I can definitely understand it not being a development priority. However, if a specific feature requires any amount of training to overcome initial confusion, doesn’t that betray a non-intuitive design? Is aiming for intuitive ux super hard to justify?

By this argument, any feature with potential for confusion can be explained away by saying “just train them to use it right”, which is seems an odd approach to confront ux issues.

If others have more positive experiences, that’s awesome, and maybe most don’t encounter this problem. For us however, our version of learning to live with it will likely be just not using it because it’s too confusing, and training staff to use forum features isn’t a thing for us because discourse is otherwise incredibly intuitive and requires no training.

1 Like

We did make some improvements here since that was written. The “Reply” button now changes to “Whisper” with the eye-slash glyph, plus the slash-eye glyph is also in black near the reply area at the top.