Next to the reply link (which is an implied browser/web reply) is solid, but what if they just tap the reply button in their email client?
I’d prefer to deal with the email case first @sam, I think we can defer on the web side a bit.
6 Likes
The information is at least available on the web, even if you have to hunt for it. But there’s no indication on the email.
If we’re in agreement that some kind of indication is required then there are only two things to resolve:
- Position. (Above or below the content of the message?)
- Design. (How large, how subtle, etc.?)
For group PM, I like the design @DeanMarkTaylor suggested (including the positioning):
I suggested the more subtle approach at the bottom as being less noisy, but perhaps noisy in this case is a good idea.
Incidentally, maybe [PM] is not the correct term for the email’s subject. That’s a bit confusing as well.
1 Like
I realised just now that that when I made this comment:
I was thinking of group PMs, where the recipient would be a group such as @volunteers.
Probably the easiest thing to do is put the recipients in the footer, when there is more than one. The basecamp model is a good one.
4 Likes
I’m interested in seeing progress around this issue. I hope it will help if I summarise the three interconnected issues that I see here:
In notifications over email:
(1) Distinguish in the email’s subject between PMs with only one recipient and PMs with multiple recipients.
(2) Clarify all the recipients in the email.
The Basecamp solution is to always mention all recipients at the bottom of the email, beside with the option to reply via the web UI.
I really like the latest iteration of the Basecamp wording:
You can reply to this email or __respond in Basecamp__. This message was sent to Alex Armstrong, ABC, XYZ, JKL. __Unsubscribe__ • __Change your notification settings__
I’m not entirely convinced that the bottom part of the message is the best option. It works for Basecamp, but that has fewer types of notifications than Discourse – which will notify you for watched posts, @mentions, @group-mentions, PMs and group PMs, and probably others I’m forgetting. All these should, ideally, be distinguished both in the subject and in the email itself.
In the web UI:
(3) The recipients should be identified near the reply button, at the bottom of the page.
Basecamp handles this with a label that reads: “When someone comments on this message, a notification will be sent to: Alex Armstrong, ABC, XYZ, JKL.”
I’m not sure what a Discourse-ish design might look like, but Cobb has the right idea.
4 Likes
This has been my favourite, “most-email”, solution so far.
Does this have to be the case?
I see the solution being: if a reply lacks all of the reply keys it was sent out with, a new private message is created, linked to the old one, which doesn’t include any of the users or groups associated with the reply keys which are lacking from the reply.
YMMV, but @sam’s solution seems to be very technical to me. My experience working with students, faculty and academic staff at higher ed institutions is that most of them aren’t adept at handling multiple recipients in vanilla email. Let alone a system such as Discourse. I remain in favor of the Basecamp approach: listing the recipients in the notification email.
3 Likes
I can concur regarding higher-ed institutions. Try using mailing lists plus named recipients if you want even more confusion!
I also spoke with my mother who is in leadership positions with a number of large, international non-profit organizations, mostly run by volunteers. She frequently complains about the lack of email understanding - very frequently emails will go out to much larger groups than expected (should have been reply), or not go out to everyone in the conversation (should have been reply-all).
This will be hard to fix no matter the method selected.
4 Likes
This isn’t our problem though, is it? If users don’t understand email, maybe they should just use the web interface instead? @sam’s proposal, with my amendments, is how someone who understands email would expect things to work.
1 Like
To clarify - I’m not against improving this (and I think Sam’s idea is good), I’m just sharing data points.
1 Like
I think you’re being optimistic about what someone who understands email would expect when receiving an email notification from a forum. I sometimes struggle with how reply/reply-all works in mailing lists, Basecamp, help desk systems, etc., as each one has quirks of its own.
I think your emendation makes things too complex. It would leave open the possibility that people wily-nily create new PMs. I like that Discourse keeps conversations localised. I’d like to see Discourse preserve this mailing list pedigree, and only allow replying-to-all by default, without an option to break up the recipients over email. If someone wants to create a new thread, with new recipients, they can do so independently of the existing one. That’s how they’d do it in the web UI as well.
I doubt there’s a “best” solution here. It comes down to what kind of audience Discourse wants to cater to. A more email-like interface would cater to technical users. A simpler, but less powerful, interface that identifies all recipients in the body and only allows you to reply to all of them would cater to less technical users. Which of these two groups is the majority depends on your forum’s topic and audience – but that’s beside the point.
(You can tell I’m biased, can’t you? ;))
I’ve worked hands-on with a lot of people using interfaces that were considered simple or intuitive by the vendors who made them and which were anything but for their users. I favor the most simple solution that will cover the vast bulk of cases. Technical users are the most adept at finding workarounds and wouldn’t be the primary group I’d keep in mind when designing a general-purpose forum system.
This issue is one tough 
3 Likes
So the solution is adding quirky behaviour to Discourse as well, rather than mirroring how it’d work with mailing lists? 
I think you can tell I’m biased too!
I think this is preserving the mailing list pedigree, but where a group is akin to a mailing list and a user is akin to a person’s email address.
So a PM to reps-council and @leo should behave as an email to reps-council@lists.mo.co and lmcardle@mo.co would. You can reply to all to continue the thread (and, as a parallel, PM), or reply to a specific person to start a new thread (and PM) with them.
Well, sortof - I would see removing recipients working like if someone had clicked the “New Message” button in a PM, and removed the recipients in the composer window which pops up:
Indeed, I don’t think that the Basecamp-style solution is bad, I just favour one with more mailing list and email parity. Ultimately I’d be happy with either, though, so I can move forward with adding group names to group PMs. I think at this point someone just needs to make a decision - what does the @team think?
I can’t quite commit to any development time for this yet, but it’s highly likely that I will be able to work on it.
Adding recipients to the bottom of the mail, combined with adding group names to group PMs, is no doubt the best solution to the topic at hand; “Email Notification recipients unclear when PM is sent to multiple users”. I think both of those UX elements ought to exist, regardless of whether or not we expand upon our mailing list parity.
Personally I’m not too enthused about the “multiple duplicate reply keys” mailing list feature. I’ve always found it confusing and I’ve seen people mess it up multiple times. And mailing list users are predominantly technical.
8 Likes
Can you make a note so we definitely follow up on this one?
2 Likes
I’m with you on both of these points you make here. No need to have mailing list (or even email) parity for PMs. It’s much more important to try to get reasonably close to parity with the discourse web experience. That way everybody involved in a PM has same expectations and understanding of what is going on and there are no unpleasant surprises.
3 Likes
Moved to 2.0 release.
3 Likes
Done via:
https://github.com/discourse/discourse/pull/5797
A list of participating groups and users will now appear at the bottom of email notifications.
10 Likes