At the moment, if you ever find yourself in a private conversation there are 3 very painful side effect.
You will get one green notification per message.
The green notification will not go away till you read the particular message.
You have no way to get off the boat.
Effectively this limits the usefulness and prevalence of private conversations.
I suggest.
We roll up notification so you only get a single green notification for all messages in a PM. As new messages come in we roll them up. Display something like “(4) my awesome private convo” in the notification.
Change the clearing logic, so the notification goes away as soon as you visit the PM regardless of the number of messages you have left to read on that private conversation.
Add a subscription control at the bottom, with watching / tracking / mute at least to allow user to get off the train.
Add back in the [PM] string which was always supposed to appear on email notifications from private messages.
Adding to the above suggestion, as soon as the user clicks on the notification icon, the green notification will disappear, and will come back again when the user receives say 5th message, and the notification will now say “5 new messages”, again when the user clicks on notification icon, the notification will disappear, following the same pattern for upcoming messages.
That’s just how I envision it.
Edit: The gist is, to remove the notification, as soon as the user clicks on notification icon. The sole purpose of notification being to inform the user that he had received a new message, not to force him to read the message.
We tried that and it ends in tears. You end up forgetting you have PMs and never reading them. A middle ground requiring you visit the PM seems like a sane compromise.
The only reason is that it tends to come up a lot less often on regular topics, whereas it comes up all the time on PMs.
PMs are frequently super mega noisy with replies and notifications (since you are watching a PM by default), so they got fixed first. But I agree, we should extend logic to all topics.
It would be great to extend this to all topics. We have extended PMs to go to groups of users. There is a large set of people A who can PM a small set of people B so that anyone in B can respond. For everyone else in B who does not participate in this message thread, there’s no easy way to clear unread notifications.
We use Discourse as part of our learning to code platform, specifically as part of the tutoring stack.
The forums provide a way for students to discuss and solve problems in a public environment. However, if a student wishes to ask a tutor a question not in public (e.g. they might be embarrassed or the public forums aren’t providing any useful help, etc), they can send the tutors a PM. We’ve disabled person-to-person PM’s and finished the existing partial implementation of person-to-group PMs. Students PM the tutors group to do this. Each of the tutors receive the PM. Any tutor who is online can reply at the time and tutors pop in and out of conversations when they’re available to help assist. For the rest of teh tutors who were not directly involved in the conversation, there is no way for them to clear the notifications.
We use PMs for this instead of groups as we don’t want a group per student. These messages are meant to be confidential between the student and the tutors.
Many thousands of students over many weeks leads to a lot of PMs
We discussed this before in another spot, the solution I find most appealing is a new type of permission. “allow read for topics you create”.
That way you just create a category for this and it becomes much easier to tame without clogging the PM system. Using the PM system for this feels to me like a misuse of it.
An “allow read for topics you create” permission would be pretty nice… one potential gotcha is the ability to include others in the conversation selectively though… For instance in a B2B support scenario, there may be a handful of users from the company requesting support… There may be other cases where the current PM architecture is better suited for this right now because people can be added to the conversation in a fashion similar to what people are used to with cc in email.
If it were “allow read for topics you create or are mentioned in”, it might take care of that.
In Zendesk, there was a concept of a user belonging to an organization, and you could set it up so that tickets were all visible within the ticket creator’s organization.
That kind of works, except I didn’t explain all of our constraints. We have different courses, and different sets of tutors per course. Each week of each course has its own Category, and each of these categories have an associated Group associated with them that indicates the set of tutors to PM when a PM is tagged with being associated with that Category.
I believe what you’re proposing then would mean having two Categories per week per course: one for public topics and one for student-to-tutor topics?
