Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[OJS] Make notification emails for new announcements and issues optional in OJS3 #2561

Closed
ajnyga opened this issue Jun 2, 2017 · 28 comments

Comments

@ajnyga
Copy link
Contributor

commented Jun 2, 2017

Hi @NateWr, I was a "bit" slow with this...

Issue described here: http://forum.pkp.sfu.ca/t/make-notification-emails-for-new-announcements-and-issues-optional-in-ojs3-0-2/29513

Basically a lot of journals would like to disable the notification sent to all registered users when an annoucement is written or a new issues is published. Also, the very short notification messages usually cause questions among the users.

Three options with this one:

  1. Journal settings for enabling/disabling the notifications for new annoucements and issues
  2. No settings, but a unsbuscribe button: "I do not want to receive these kinds of notifications anymore" (see @ctgraham's comments in the forum thread)
  3. A combination of the two options

Number 1 would be fairly easy to accomplish, the biggest question is where to put the setting selections. Number 2 is clearly a lot of work, but would be a very nice if combined with the settings you already have in user profile.

@NateWr NateWr added the Major Feature label Jun 5, 2017

@NateWr NateWr added this to the OJS 3.1 milestone Jun 5, 2017

@NateWr

This comment has been minimized.

Copy link
Contributor

commented Jun 5, 2017

I flagged this as a Major Feature for the first part, to disable emails on announcements and new issues. There seems to be a lot of requests for this.

I think the other work, looking at how users can manage their email notifications, would align with other work we want to do on pinning down the notifications used throughout the system.

@ajnyga

This comment has been minimized.

Copy link
Contributor Author

commented Jun 6, 2017

Hi @NateWr

I could do a pr if you decide where the options should be. As I said in the original forum post, there are three options (in my opinion)

  1. A separate page under workflow
  2. In workflow => emails
  3. The other one in Annoucements tab and the other one under Issues
@NateWr

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2017

I'd like to get some feedback from @asmecher about the best way to handle this. I'm not very familiar with the email notification system.

Unfortunately, we're a bit busy right now prioritizing two big merges -- versioning and the JS changes. So I don't know if he'll have time to put more thought into this until closer to OJS 3.1's release.

@ajnyga

This comment has been minimized.

Copy link
Contributor Author

commented Jun 6, 2017

Hi,

Controlling the notifications in both cases is fairly straight forward. There is already a rule in the new issue notifications that they are not sent if OJS is not used for publishing content (just the editorial process). So extending that is not a problem.

No rush, I am going for a vacation starting from tomorrow, so I would not have time to look at this until around the 20th.

@asmecher

This comment has been minimized.

Copy link
Member

commented Jun 6, 2017

In OJS2, we had a manual "Notify Users" feature that I think Editors appreciated and used heavily. We don't have that yet in OJS3, and I think most users find the automatic notification annoying and unpredictable. I'd favour removing the automatic notification entirely and rewriting the manual notification.

@ajnyga

This comment has been minimized.

Copy link
Contributor Author

commented Jun 6, 2017

I think that the notify users feature was only related to the publishing of new issues? I could be wrong.

Maybe we could have:

  • title field
  • pull down menu for prefilling the notification content (like in add participant feature)
  • free text field
  • checkboxes for choosing which roles receive the notification (these could be hidden by default)

Would this be under Users&Roles?

@asmecher

This comment has been minimized.

Copy link
Member

commented Jun 6, 2017

Would this be under Users&Roles?

I was picturing this under Tools, but I don't have a strong opinion on this.

I think that the notify users feature was only related to the publishing of new issues? I could be wrong.

Yes, that's correct. For announcements, I was imagining simply a "Send Notification" checkbox on the announcement create/edit form. (But as above, I haven't thought about this in depth.)

@ajnyga

This comment has been minimized.

Copy link
Contributor Author

commented Jun 7, 2017

Thanks, it's your call. Both solve the original issue.

Do you see problems in having a multipurpose notification tool? I started to think that this could be very handy for journals, that is if they do not use it too much.

@asmecher

This comment has been minimized.

Copy link
Member

commented Jun 7, 2017

@ajnyga, I do think a multi-purpose tool will be valuable. There's potentially some overlap, too, with the Discussions tool -- I think we may need to eventually add some templating support, so that commonly-used boilerplate can be easily accessed.

The current notifications system is mostly a holdover from OJS 2.x, and never felt smoothly integrated, either by user experience or coding. I think we should be open to major changes there. @NateWr, pie-in-the-sky user-oriented thinking is welcome here.

@NateWr

This comment has been minimized.

Copy link
Contributor

commented Jun 7, 2017

When we talk about a "multi-purpose tool", are we just talking about something to email all or a segment of users? Or are we talking about addressing the whole notifications system (batch emails, workflow emails, tasks)?

@asmecher

This comment has been minimized.

Copy link
Member

commented Jun 7, 2017

The existing notification system does a lot of different things:

  • Instant notifications ("your form was saved")
  • Persistent notifications and tasks ("all reviews are in, make a decision")
  • Emailed notifications

There's room for improvement in all three, but I suspect the emailed notifications are by far the weakest link. We tried to design it so that overlap between them was shared (e.g. a task would also send an email) but I'm not convinced that it was worth binding these together.

@NateWr

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2017

I agree, and I think the email-all-users-on-new-issues/announcements is a separate issue altogether. I'd recommend just addressing the bulk emailing aspect in this issue.

I've done some work in trying to handle status issues in the submissions list work. I'd like to continue in that vein for the other notification use-cases.

@ajnyga

This comment has been minimized.

Copy link
Contributor Author

commented Jun 8, 2017

Hi,
How about

  1. adding an on/off setting to the new issue notification.
  2. and then changing the announcement function so that you can choose if you want to send the new announcement you are writing to users (+ choose which roles as well) AND choose, if you want to show the announcement publicly (or just send the email).

This way the announcement function would work also as the "multi-purpose email tool".

As a separate but related issue, I think it would be important that in the case of announcements the actual title and content would be in the notification email. At the moment the email just says something like "a new announcement was added" which does not serve the users well (a whole different thing are the notifications related to the editorial process, where you do not want to receive replies to the email itself).

@jmacgreg

This comment has been minimized.

Copy link
Member

commented Jun 13, 2017

Hey @ajnyga we've received reports from clients being surprised by the frequency of these two notification types (new content published; announcement notifications). I think your solution here sounds great: it allows for folks to opt in/out of notifications, and also makes the Announcements function a more useful general tool. So +1 from me. I'd be happy to help test anything you develop, if you like.

@ajnyga

This comment has been minimized.

Copy link
Contributor Author

commented Jun 13, 2017

Thanks @jmacgreg. I can do a pr on this issue, but let's see what @asmecher and @NateWr decide. I like the idea of a general email tool, but just the ability to control these two notifications is fine too.

@NateWr

This comment has been minimized.

Copy link
Contributor

commented Jun 13, 2017

  1. I'm in favor of adding settings to turn issue and announcement notifications off at the journal level (one setting for each).
  2. I think that @ctgraham's comment about user unsubscribing is also just as important. A user should be able to unsubscribe from issue and announcement notifications.
  3. I'm conflicted about turning announcements into a general email blasting tool. I like that it provides a feature with very little technical investment. However, I worry about the general consequences of trying to shoehorn one activity into a tool built for another (this is part of the problem we have with the internal notifications/tasks/alerts system), as well as the hazards of making it easier to send out email blasts.

I understand that email alerts and lists are the norm in the academic community (although every academic I know is drowning in their inbox so I'm not sure it's serving them well). Looking at emailing services, there's usually a whole bunch of parallel features that go into managing email lists: email previews, scheduled sending, results reporting, bounce tracking, unsubscribe flows, spam flag tracking, etc.

These things help people send better email by making the sender take it more seriously. Mailchimp's big red button is a good example. There's a whole ceremony to the process which kind of clarifies the enormity of the act in the sender's mind.

So I'm hesitant to slide in a feature like this as a kind of off-shoot of an existing feature. Though, fair enough, maybe I'm just bikeshedding.

Other issues to consider:

  • Will email-only announcements have an Announcement Type? What would someone understand that to mean in that context?
  • I think we'll at the very least need a confirmation step: "You're about to send an email to 1,231 recipients. Are you sure?" This might be good to add to issues and announcements anyway when the emailing is enabled.
@carzamora

This comment has been minimized.

Copy link
Contributor

commented Aug 19, 2017

Hi @NateWr, I'm Editor in three journals and have some knowledge about code, so I'm talking from two sides of the problem.

I don't know how and how much you are work in this issue, but I have an idea for implementing an easy way to stop sending short notifications for announcements and when a new issue is published (in this case we have problems too because we make some proof before the final publication of the issue, and users receive a lot of notifications): I think in a checkbox, like when you are in the revision workflow, and you can choose for not send an email to the author:

image

this way is a probably faster implementation for announcements notifications and new issue notifications, and permit you to work independently in a solution for unsubscribing users.

My idea is similar to @ajnyga but maybe not identical, I just try to help.

Thanks to all of you for your work!!

Sorry for my English, my native language is Spanish.

@NateWr

This comment has been minimized.

Copy link
Contributor

commented Aug 21, 2017

Hi @t4x0n,

Thanks for your feedback and don't apologise for your English. It's very good! I think we'll probably include a toggle option like you describe. But I'm hesitant to rely completely on it. It's very easy to miss in a normal workflow and introduce human error which can't be taken back (the emails are already sent). So it'd be good for a Journal Manager to be able to set a default or preferred behaviour for a journal to minimise these mistakes.

@carzamora

This comment has been minimized.

Copy link
Contributor

commented Aug 26, 2017

Hi @NateWr,

thanks for your answer. I am according with you about the human error, so yes, is good to have an option for control a default behavior and avoid sending emails by mistake.

@ajnyga

This comment has been minimized.

Copy link
Contributor Author

commented Sep 8, 2017

@NateWr I would be happy to help here with a pr here, but I am unsure on how you want to solve this?

If we just add the settings for turning on/off the notifications for new issues and announcements, then this will be a very fast addition. The only question is, that where exactly do we put these selections? For the announcements it is quite clear, but how about the issue notifications?

@NateWr

This comment has been minimized.

Copy link
Contributor

commented Sep 8, 2017

@ajnyga I've just reviewed some of the discussion. It doesn't sound like we've come to any hard conclusions, but there does seem to be a consensus that options for disabling are important. My preference would be:

  1. Journal-level settings for sending/not-sending email with an announcement and a new issue. These should act as defaults.
  2. When sending an announcement, by default the send/not-send checkbox is based on the journal setting. This can be overridden for each announcement.
  3. Issues could also have an override when choosing to publish an issue. I could take or leave this though.
  4. User profile forms should have an option to choose to not receive announcement and new issue notification emails on a per-user basis.

I'd probably want to hear from @jmacgreg on how it fits the requests he's heard. And you'd probably want @asmecher to sign off before starting on anything, but he may be busy in the next few weeks as we're getting ready for 3.1 to go out.

@ajnyga

This comment has been minimized.

Copy link
Contributor Author

commented Sep 8, 2017

Thanks! I could cover 1-3 fairly fast. However, with 4 I am not sure. I am not familiar with the code there.

@asmecher

This comment has been minimized.

Copy link
Member

commented Sep 21, 2017

@ajnyga and @NateWr, sorry for the wait. @NateWr, I agree with your recommendations on this comment, with a few minor caveats:

1/2. I'd prefer not to add journal-level settings for defaults -- I can see the logic in what you propose, but in the interests of combating settings form bloat, I'd suggest just fixing a default state on the annoucement form and leaving it up to the JM to uncheck it if they don't want to send anything. Suggest "send the announcement" as a default state for new announcements, and "don't send the announcement" as a default for editing existing announcements.
4. There's already a notification settings form available to each user on Profile > Notifications. It's not the crispest implementation we've ever done but extending this with the same pattern to include Announcements and New Issues should be straight-forward.

These are just suggestions, and I'd trust either of your judgment on details, @ajnyga and @NateWr!

@ajnyga

This comment has been minimized.

Copy link
Contributor Author

commented Sep 21, 2017

Thanks @asmecher! No problem, I realize that this is not the only open issue here.

If we would just add the profile setting for these, then I think that the problem would not be solved in the extend many editors would hope. Many journals have hundreds of users and I would say that at least about 80% of those have not visited the journal site in the recent years or are familiar with OJS3.

So if the only way of opting out of these notification emails is editing the user profile, most of the users do not know how to do that and/or do not want to find out. What they may do is to reply to the email they received and say please stop :)

The other problem for leaving out journal defaults is the situation where the journal is adding old issues. In these cases the journal probably never wants to send a notification email, because we are not dealing with an actual new issue, but at the same time may want to send one when publishing an actual new issue.

So my suggestion is:

  • No journal settings for these two notifications
  • When publishing an issue a modal window will open where you can check/uncheck if you want to send the notification by email
  • When publishing/editing an announcement add an extra checkbox to control the notification email (+ add the actual text of the announcement to the email, ok?)
  • add profile settings to disable/enable the two notification types (AND add unsubscribe link to the notification emails which enables the user to disable the type of notification with one click, this could be added later on, but it would fit the overall design there very well)

If this sounds good, I can start working on it.

@asmecher

This comment has been minimized.

Copy link
Member

commented Sep 21, 2017

Absolutely! This sounds perfect.

@ajnyga

This comment has been minimized.

Copy link
Contributor Author

commented Sep 21, 2017

Hi @asmecher and @NateWr
These two pr's solve 1-3 but without the journal defaults as discussed above
Announcements: #2804
Publish issues: pkp/ojs#1542

@asmecher

This comment has been minimized.

Copy link
Member

commented Sep 22, 2017

Wow, @ajnyga, that's probably the quickest community contribution I've ever seen.

I think this deals with 90% of the frustration over this issue -- I've filed the remaining piece as #2805 for tracking purposes, in case it doesn't make the threshold for OJS 3.1. Huge thanks as always, @ajnyga.

@asmecher asmecher closed this Sep 22, 2017

@ajnyga

This comment has been minimized.

Copy link
Contributor Author

commented Sep 22, 2017

Great, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.