We are using OJS 3.0.2.
I am currently testing Notification mailing list features.
I would like to discuss about a few aspects.
1) Access to Notification mailing list page with the back-end view
When you are not logged in, you access to a page which permits you to register your email to subscribe to Notification mailing list: notification/subscribeMailList
This page is with a back-end view. When you are not a registered user of the journal but just a visitor which wants to subscribe to the Notification mailing list, it could be a bit confusing. It would be more logical to access to this page with the front-end view.
So in my opinion, I think “templates/notification/maillist.tpl” template should include “frontend/components/header.tpl” and “frontend/components/footer.tpl” templates instead of “common/header.tpl” and “common/footer.tpl” templates.
And for notification index page (referenced by “templates/notification/index.tpl” template), I don’t see the value to permit to show it when you are not logged in and to have a back-end view with no valuable informations. It’s just my opinion. It could be interesting for other people.
2) Captcha on notification mailing list registration
The Captcha on notification mailing list registration is no longer displayed. Besides, there is no more “captcha_on_mailinglist” variable in the “config.inc.php” file.
Is it a choice or it’s because it has not been implemented yet ?
3) unsubscribeMaillist URL
When you enter your email address to receive notifications, you receive an email with 2 URLs, 1 with a confirmMailListSubscription link and 1 with a unsubscribeMaillist link.
But if you loose this email or delete it, you can’t unsubscribe anymore. It would be useful to have a section to enter the registered email to receive the mail again to be able to unsubscribe.
Maybe it could be the same section that for subscription and when you enter an email already registered in database, it will send you the email again with only the unsubscribeMaillist link.
4) Manage email registered in notification_mail_list table
The journal Manager can’t manage (view, add, delete) emails registered with Notification mailing list form which are stored in notification_mail_list table. Only a system administrator can do that by a direct access to database.
Is it planed to add an interface in the back-end to manage (view, add, delete) emails stored in notification_mail_list table ?
Hi,
As I didn’t have answers to my questions yet, I allow myself to ask again my questions about how to handle Notification mailing list in OJS3 ?
Thanks in advance for your answers.
Helene
This feature is unfortunately old and not maintained – a left-over from OJS 2 Before it will be rewritten/migrated to OJS 3 and improved, a new look at/investigation of the requirements has to be done and eventually an integration with an external tool/service considered. This is however not a priority for now. But any contribution and ideas are very welcome!
Could you tell me if you have planned to implement what you request in OJS 3.x?
All the points indicated by @hcl are really important …
1.- When you are not logged in, you access to a page which allows you to register your email to subscribe to Notification mailing list: notification / subscribeMailList …
2.- Captcha on notification mailing list registration …
unsubscribeMaillist URL …
Manage email registered in notification_mail_list table …
I would love to receive help on how to implement subscription notifications on the front page (from end) for both registered users and for non-registered users.
We used to use the left-over “Notification mailing list” features until OJS 3.1.1. Since we migrated to 3.1.1-1 this old feature has been removed.
Do you know if this feature will be rewritten/migrated to OJS 3 and improved ?
All of our journals are interested by this feature which permits to people to register their email to subscribe to Notification mailing list without creating an account with login/password.
If not, is there an other way to do that ?
Our sense – mostly informal, as we didn’t survey on this – is that the mailing list feature was not well designed and rarely used, so it’s interesting to hear that you found it useful. We’re doing a review of the notification system and considering some broad improvements for the 3.2 release, so it would be helpful to hear what you were using the feature for.
Regards,
Alec Smecher
Public Knowledge Project Team
We are looking for a way for users to fill out a simple email field in order to they receive notifications.
We want to send notifications to all registered users, but also to non-registered users which are people who are interested in the journal but that don’t necessary want to go through the huge registration process.
And it could be done in OJS2 and in firsts OJS3 versions with “Notification mailing list features.” Visitors could register their email and receive notifications as they suscribed to a digital newsletter of the journal.
This feature was very interesting but needed some improvments such as better way tu unsubscribe and access for the manager to emails registered in notification_mail_list table
I believe we are several journals interested with this feature. They are all journals that still use OJS2 and they continue to benefit of this feature.
On the old forum I could see similar requests:
Thanks, that’s helpful and I’ve passed it around our UI/UX group, which is currently reviewing emails and notifications. Some of that work will definitely make it into OJS 3.2, though I’m not sure yet whether this aspect will.
I view mailing lists as one of those areas where we’ve overstepped our expertise and capacity and would probably be better served with third-party tools or libraries. Ideally we could integrate with something else that provides better support, and maintain less code ourselves in the process.
Regards,
Alec Smecher
Public Knowledge Project Team
Adding to what Alec has said, here are some of the things that a dedicated mailing list provider can give you which OJS either can’t do out-of-the-box or will probably never implement:
Interactive email layout and design
Reliable delivery of bulk emails
Bounced email tracking with automatic removal from lists
Read/interaction analytics (with user history)
Sign-up forms you can embed anywhere (OJS, Facebook, Institutional websites)
User list management (import/export, segmenting, etc)
You may not necessarily use all of these features, but one or more them are part of just about any successful bulk email marketing campaign. For that reason, I think we should encourage users to pursue a third-party solution to this need. We’ll probably never be able to implement a fully-featured solution to do bulk emails at a high standard of quality.
If you (or anyone else) have a chosen third-party provider in mind, we’d be happy to talk about how best to integrate sign-up forms and other tools into your OJS site.
At university of Bordeaux, we use the Sympa mailing list server.
We could imagine to have a plugin that interacts with our Sympa mailing list server.
This plugin could display a form with at least an email to fill in and a captcha.
We need as parameter of the plugin the name of the mailing list to subscribe and the name of the mailing list robot.
When user will click on a send button, it will send an email to the mailing list robot, to ask it to send a subscribe notification of the email filled in for the list.
Our mailing list server will then send a notification to the email with a link to confirm the subscription at the mailing list.
After confirmation, mailing list server will send to the email a notification with a welcome message for the list with a link which permits to unsubscribe.
On your side, when a notification is send through the journal, can you include to send it to emails registered in this mailing list ?
That could be done. I took a quick look and didn’t see an existing hook in place that would allow this. But I imagine that we would probably try to get to a place where this is possible for most major notifications that can be enabled/disabled by users (issue published, new announcement, etc).
We don’t have anything like this planned for the next major release, v3.2. Each list server will typically have it’s own API for sending emails, so it is something that would need to be implemented on a service-by-service basis.
thank you. We also have one publisher that is asking for a personalisable newsletter subscriptions.
However, the editorial board has more the requirement that users be informed about new publications in individual sections. One option would be to modify the RSS feeds, so that the section abbreviation could be used as a query parameter.
This way, no additional preferences would have to be stored in the user profiles.
Would this be an easily-to-implement addition to the webFeed plugin?
That’s getting off-topic for this thread, but briefly yes, it would probably only be a few lines of code added to plugins/generic/webFeed/WebFeedGatewayPlugin.inc.php in the fetch function to watch for a specified sectionId in the parameter list and deliver only those results.
Regards,
Alec Smecher
Public Knowledge Project Team
Before it will be rewritten/migrated to OJS 3 and improved, a new look at/investigation of the requirements has to be done and eventually an integration with an external tool/service considered. This is however not a priority for now. But any contribution and ideas are very welcome!
