Taming wild PM notifications


(Sam Saffron) #1

At the moment, if you ever find yourself in a private conversation there are 3 very painful side effect.

  1. You will get one green notification per message.
  2. The green notification will not go away till you read the particular message.
  3. You have no way to get off the boat.

Effectively this limits the usefulness and prevalence of private conversations.

I suggest.

  1. 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.
  2. 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.
  3. Add a subscription control at the bottom, with watching / tracking / mute at least to allow user to get off the train.
  4. Add back in the [PM] string which was always supposed to appear on email notifications from private messages.

Thoughts?


(Jacob) #3

Sounds great. Hopefully this can get fixed in the process. =)


(Jeff Atwood) #4

Yes please. PMs are currently a bit of a nightmare.

Also @illspirit that is sort of an edge condition and could be cleaned up either at remove time or by the daily consistency check.


(Arpit Jalan) #5

:thumbsup:

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.


(Sam Saffron) #6

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.

If you want to opt out you can always mute.


(Sam Saffron) #7

FYI 1) and 2) are now complete and committed to master.


(Sam Saffron) #8

FYI 4) is now complete


(Sam Saffron) #9

Status completed:

https://github.com/discourse/discourse/commit/7e5a17f277f3572021a52b80edb9bb158e37317e


"View older notifications" doesn't show you the same stream
"View older notifications" doesn't show you the same stream
(Kane York) #10

Suggestion for copy:

You will recieve notifications because you were added to this PM.


(Ronteras) #11

What about having the dedicated PM button next to the notifications? clicking on it would open conversations view with compose new message etc.


(Erlend Sogge Heggen) #12

Any reason why this hasn’t been applied to thread notifications as well? I just encountered this:
//discourse-meta.s3-us-west-1.amazonaws.com/optimized/2X/e/ee400b9907a14f94669c8f8b495bcfea7fa2bdec_1_689x225.png


(Dave McClure) #13

Any reason not to do (1) and (2) for notifcations from any topic?


(Jeff Atwood) #14

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.


(tim) #15

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.

My current notification widget:


(Sam Saffron) #16

Jeez it seems like you are using PMs for something that you really should be in groups. Can you expand on what you are trying to achieve here?


(tim) #17

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 :smile:


(Sam Saffron) #18

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.


(Dave McClure) #19

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.


(Sam Saffron) #20

Sort of, its complicated, eg “@bob999 is plagiarizing all my work please help”


(tim) #21

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?