Kyle needs your help!
Submitted by
kclarks.
on 2006-09-14 13:06.
I need advice for the text of the email notifications that RhaptosSubscriptionTool will send out
As everyone should know, I am working on a subscription tool for subscribing to forums and other objects in the system. I need advice on what the text of the email be, though. We can have templates that are completely general, something to the effect of:
"Something you are subsribed to has been updated, please check it out - [link]"
Or we can have templates that are specific to a type of object like:
"A forum that you are subscribed to has a new reply in it, please check it out - [link]"
Of course, the more general we make them, the fewer there are to maintain, but the less specific the more people might be confused as to what it points to.
My first attempt at an email body yeilds this on my development server:
There has been a new topic posted on the Connexions system in the
DSP Community forum.
To view the topic, please visit
http://yoda:9080/communities/Community2/.ws_forum
You are recieving this email because you have chosen to subscribe to
this forum. If you wish to cancel the subscription, please do so at:
http://yoda:9080/subscriptions
Thank you for your interest in Connexions!
--
The Connexions Project
- What do you think?
- More specific?
- More General?
- Does it need more text?
- Less text?
- Any thing left out that I should include?
- Should I take out anything?
Re: Kyle needs your help!
Posted by
jccooper
at
2006-09-19 18:32
I think it should really include the change, if feasible. New messages or comments, at least, should include the text of the message. New instances of more complex types possibly shouldn't include the whole thing. Revisions might contain a notice or a diff or the whole thing (I would like a diff, but then I'm a geek.)
Notification is okay, but if you don't have to visit the site to see, then it's really useful.
I would suggest template assignment to be like to workflow-to-type mapping in the workflow tool. We might have a general purpose one as default but be able to be more specific as necessary.
Notification is okay, but if you don't have to visit the site to see, then it's really useful.
I would suggest template assignment to be like to workflow-to-type mapping in the workflow tool. We might have a general purpose one as default but be able to be more specific as necessary.
Re: Re: Kyle needs your help!
Posted by
jccooper
at
2006-09-19 18:34
In fact, with new messages/comments, I would like to see the content first thing in the message, with the thread title in the email title. This allows you to easily ignore what's useless, esp. with GMail, which shows you the first line.
Re: Kyle needs your help!
Posted by
cbearden
at
2006-09-27 16:44
I think it can be pretty bare-bones, as long as important information isn't omitted.
The kinds of things that belong in such a message are, in my view:
* event type (role request, module revision, forum topic, etc.)
* description of event (topic subject, change message, object title)
* event-driver(s) (persons, community)
* timestamp
* location (workgroup, community) (where it makes sense)
What subscribers are essentially receiving notification of are events. We might indeed need a template for each type of event. I'd need to think about that a little more.
Here are some candidates for event types. By listing them here, I am not necessarily endorsing them.
* role requests to you
* rejection or acceptance of role requests from you
* revocation of role requests to you
* suggested edits to you
* acceptance or rejection of suggested edits from you
* being added to a workgroup
* new topics (threads) in discussion forums (community, workgroup)
* new content published by author x, community x
* new version of object z (module or collection)
Ultimately, I think, anything to which one can subscribe for email notification ought also to be available via RSS. And vice versa. Ultimately.
We might want to consider giving message aggregation options, where all messages to a user, or all messages of a certain kind to a user, are sent out periodically instead of when the event of interest occurs. Consider: it's very likely that in large content projects, an author may be sent 20 or 30 role requests in the space of an hour. Do users want to receive emails for each individual request? And yet I think we want to let users receive email notification of role requests. These large projects are only going to grow in frequency with RUP and other initiatives. Perhaps we need to allow for hourly, daily, and weekly digests of messages from the system.
There now, I've helped Kyle. :-)
The kinds of things that belong in such a message are, in my view:
* event type (role request, module revision, forum topic, etc.)
* description of event (topic subject, change message, object title)
* event-driver(s) (persons, community)
* timestamp
* location (workgroup, community) (where it makes sense)
What subscribers are essentially receiving notification of are events. We might indeed need a template for each type of event. I'd need to think about that a little more.
Here are some candidates for event types. By listing them here, I am not necessarily endorsing them.
* role requests to you
* rejection or acceptance of role requests from you
* revocation of role requests to you
* suggested edits to you
* acceptance or rejection of suggested edits from you
* being added to a workgroup
* new topics (threads) in discussion forums (community, workgroup)
* new content published by author x, community x
* new version of object z (module or collection)
Ultimately, I think, anything to which one can subscribe for email notification ought also to be available via RSS. And vice versa. Ultimately.
We might want to consider giving message aggregation options, where all messages to a user, or all messages of a certain kind to a user, are sent out periodically instead of when the event of interest occurs. Consider: it's very likely that in large content projects, an author may be sent 20 or 30 role requests in the space of an hour. Do users want to receive emails for each individual request? And yet I think we want to let users receive email notification of role requests. These large projects are only going to grow in frequency with RUP and other initiatives. Perhaps we need to allow for hourly, daily, and weekly digests of messages from the system.
There now, I've helped Kyle. :-)

- Community forums
- Workgroup forums (isn't this one of those "we'll get to it someday" things)?
- Rhaptos Blogs
- Bugs/tasks
- Content revisions (i.e. updates to modules/courses)
- Suggested Edits (opt-out for that content's editors)
- Perhaps it could also be used somehow to notify people of role requests, though I know this one is stickier since role requests can be removed immediately after they are requested.
All these very different things make it seem to me like you might have to make the text a little more specific to each type of subscription ("There has been a new suggested edit posted on the Connexions system in the 'Identifying Historical Figures: The Souvenir of Egypt' module" sounds kind of weird to me, even with the inclusion of the quotes around the module name").
Two things that I think were left out of your message which would be useful are 1) the name or id of the person who made the change, and 2) some kind of indication of what the change was. The latter, again, would depend on what kind of thing was being subscribed to. For a content revision, it could be the commit message, for a forum post it could be the text or partial text of the post, for a suggested edit it could be that explanatory text that we require users to include along w/ the edit.
I was going to say that we should probably try to be consistent in this message with the other piece of mail we currently send out: the one about Connexions account approval when users first sign up. But I see by your inclusion of the "--/The Connexions Project" at the end that that's what you have probably done. I, of course, have been trying to encourage us to stop including the word "Project" in our name, but if signing off with just "--/Connexions" sounds too odd, how about "--/The Connexions team"?
One final note: I would change "If you wish to cancel the subscription" to "If you wish to cancel or change your subscriptions" because I imagine that the following URL leads them to a page where they can change all their subscriptions, right? Or is it one of those URLs that cancels that specific subscription simply by going to it?
Ok, another final note. "Thank you for your interest in Connexions!" sounds a little too enthusiastic to me, especially if people see this every time they get one of these e-mails (the similarly enthusiastic final sentence in the join e-mail is only sent out once).