Pkp-lib: Author Confirmation Notice that Revised File Has Been Received

[stranack]

A good suggestion from the forum. Revision handling was a priority for improvement in OJS 3 and this would be an additional enhancement. Well worth considering.

Once the author has uploaded the revised document under ‘revisions - upload review file - confirm’ and have clicked ‘complete’ the new revised file appears in the box but then the author is ‘left hanging’ - there’s no save/complete/ inform editor button or notification sent to finish off the session and from my observations the author/user is left wondering what to do next/ did it work? It’s likely (from my experience) that they’ll then try to contact the editor out of OJS to find out if it worked.

I was wondering if it was possible to include a notification to confirm to the author that their submission was received after submitting the revised file? I know the upload submission box tells them so (but users seem to want final confirmation it worked - if that makes sense?).

Original post: https://forum.pkp.sfu.ca/t/ojs-3-notifying-authors-their-revised-submission-has-been-received/32296

[alexxxmendonca]

I agree with this. It happens to our authors as well.

Even a simple modal window with a confirmation text saying the the Editor has been informed would already be very helpful.

[ajnyga]

A related issue is that the automation only works (to my knowledge) when you choose the original version of the file from the pull down menu when uploading a new revision (instead of choosing "this is not a revision.."). If you choose that "this is not a revision", the editor is probably not informed at all.

So, instead of having that automation there, how about just having a button that you use to confirm that you have uploaded the requested revisions. This could a button that appears when there is at least one file uploaded to the revisions grid.

[asmecher]

See also https://forum.pkp.sfu.ca/t/notification-of-revision-upload/31676/10.

[NateWr]

We had some discussion about this related to some work @bozana is doing for 3.1.1 Here's a quick set of mockups illustrating the kind of wizard-like workflow I'd like to see for revisions at some point in the future.

1. User is prompted to submit revisions directly in the notification. The link opens up a modal.

1. The user has a modal where they can upload 1 or more files. As they upload, it lists the files that have been uploaded. When done, they click a button to submit them.

1. The user is given a confirmation prompt that makes it clear this will complete submission. The editor will be notified if they click ok.

Then around this workflow the review pane would display. The notification could change to: "You have submitted revisions. The editor will now review them. If you need to share more files, please add them to the revisions below and notify the editor through the discussion tool." Or some such stuff.

[ajnyga]

Where do you define to which file you are sending a revision? I mean if there are for example two original submission files.

[NateWr]

That would be in (2). I didn't take the time to mock it up in a detailed way. Just an outline of the process.

[bozana]

In this forum post it is wished that also journal managers are informed about the revision upload, s. https://forum.pkp.sfu.ca/t/submission-acknowledgement-email-upon-submission-of-revised-manuscript/43703/5 -- just to eventually consider and discuss it as well...

[NateWr]

it is wished that also journal managers are informed about the revision upload

That runs counter to the more frequent requests we get to cut down on emails to journal managers. I think we need to consider requests like this when we take a more comprehensive look at emails/notifications in the system. Perhaps it should be possible to configure at the journal level a CC on any specific email/notification. Then a journal manager can decide what they do and don't want to receive.

[ajnyga]

Perhaps it should be possible to configure at the journal level a CC on any specific email/notification. Then a journal manager can decide what they do and don't want to receive.

Can not find a thumbs up icon big enough for this. For installations with several journals this would be an absolutely great feature and would really make the whole notification system more transparent!

[bozana]

it's :+1000: ;-)

[sabrinaeck]

This is something we are missing from version 3.0.0.0.0... on. We would love to have this "CC" feature too!

[ajnyga]

This is not the same issue but basically discussed above.

After upgrading to OJS 3.1.1.2 I have received emails from several of our editors complaining about the frequent emails they get when authors upload revised files. Sometimes an author may first upload something and then delete the file and upload again. The latest message I got from an editor mentioned that she had received the notification email on new revisions over 20 times for a single submission.

So instead of sending automatic messages for each uploaded file, how about the suggestion I had here: https://github.com/pkp/pkp-lib/issues/2665#issuecomment-320590391 . It would make the process of sending revisions more clear to the author and clicking the suggested button could open a modal window containing a email template and sending the notification to the editor could start a new discussion.

Or the solution @NateWr mentions here https://github.com/pkp/pkp-lib/issues/2665#issuecomment-364944236

@asmecher this is something I could start coding fairly quickly if we can reach an agreement on a good solution? This has been a high demand since upgrading to 3.1.1.2 so I would like to solve this (I too hate situations where you end up getting tens of automated emails).

[NateWr]

So instead of sending automatic messages for each uploaded file, how about the suggestion I had here: #2665 (comment)

If we add a button that says "submit revisions" or "notify editors of revisions", we'll be implying that revisions remain private to the author until this button is clicked. But as soon as a revision file is uploaded it is available to the editor.

To get around this, you'll need a new file stage that's private to the author until revisions are submitted. And then we introduce a category of data we have to manage forever even though we don't plan to keep this mechanism (private author revisions) around. What do we do in the future? We can't migrate these files to a shared bucket that the editors can access. They'll just end up dropped from the UI, possibly losing in-progress revisions.

The only workaround I can see here would be to remove the revision files grid from the author dashboard and replace it with a button. That button would open a modal with a wizard-like flow. Step 1: upload files to a grid, but don't save these files anywhere (it's just in the browser). Step 2: submit revisions with email dialogue.

To do this, you'd need to figure out how to do the file upload process, use the temporaryFileId to display the list of revision files, without ever actually saving them. If the user browses away, they have to start again. It keeps the files private and doesn't introduce a new file stage, but at the cost of forcing the user to do all that work in the modal, which users are prone to closing accidentally. And all that work would be obsolete in a year or so as we refactor our forms.

Or the solution @NateWr mentions here #2665 (comment)

This is actually a lot more work than it appears at first. You'll need to build a whole multi-file upload UI that allows the original file to be selected for each uploaded file. And whatever you build will be obsolete in a year as we refactor our forms.

[ajnyga]

I can not see how a button stating "Notify editor of new revisions" implies that the files are private before that? I think it implies that the editor has not been notified about the uploads yet. It would just be a button that would open a modal window with maybe a preformatted message the author could send as such or add some more details. And sending it would just create a new discussion with the editor as the receiver.

The Learning OJS guide already says:

Upload the new file in the revisions section. To upload a new file click on ‘Upload file.’ A new window will open allowing you to upload your file(s). Select the appropriate option from the dropdown menu to indicate you not submitting a revision of an existing file.

Add a discussion to notify the editor that you have re-submitted.

I can not see a big difference having an actual button to guide the author to do the last part? I mean the authors do not even know that the automatic messages are being sent when they upload something.

[NateWr]

I can not see how a button stating "Notify editor of new revisions" implies that the files are private before that? I think it implies that the editor has not been notified about the uploads yet.

I disagree. I don't think users interact with button labels in such a literal way. Create > Save > Publish is a common pattern that is likely to influence how users perceive what is happening. It's a shame the author revision isn't already built to follow that flow.

The problem you're facing (too many emails) is a good example of how a quick fix for one UX problem only tends to create more. That's why I'm reluctant to address this in a piecemeal fashion. But that does mean we often move slowly on issues.

One suggestion would be to hook in to the notification and record when it is sent. Also record when an editor last looked at a submission. When the same notification for the same submission is sent, you can check these dates and not send multiple emails when an editor has not accessed the submission in the interim. That would be a welcome long-term feature and might be reusable in other areas.

[ajnyga]

Ok, the thing is I have received so many complaints about this, I have to solve this in our own installation.

[ajnyga]

This is how we solved the problem with too many new revision messages: https://github.com/pkp/ojs/pull/2152

[twakeford]

This has been an issue for us as well, and having a nice big 'notify editor' button, available once the author has completed their task has been requested. There are 2 issues that I don't think have been mentioned above:

1) currently the editor gets sent a template email each time there is a file uploaded, but a) if the author is uploading a number of files then the editor receives a lot of emails but doesn't know why there are lots or which one indicates that all files are now uploaded. If an author uploads one file but delays uploading a separate file then the editor is notified about this first file and it looks like revisions are in = editors can be spammed and/or they still do not have a good idea of when the complete and final revision has been provided

2) the author may want to add a comment to the editor - e.g. they have deliberately not done a specific revision and want to justify why. Having a very clear process of closing the task and providing the option to add comment seems to provide a very distinct closure for the author and a clear opening of the editor task

[NateWr]

1. There's been some discussion of that here. But admittedly this has been scattered across a few issues.

2. :+1:

[fgnievinski]

I've commented on the side issue of too many editor notifications in #4228 (recently split).

About the main issue here, how about if we simply cc authors in REVISED_VERSION_NOTIFY?

[twakeford]

Certainly having the author receive a confirmation email when they submit revisions is something that has been requested by authors. A cc would work but wouldn't be ideal - a separate template would be better as you could give them information specific to the author rather than them see the editor instructions. E.g. an email to the editor may include a reminder of what they now need to do/press or links to editorial checklists that they need to adhere to. The journal may not wish an author to see such information.

[epistemehealth]

Having editors receive a notification after every file is uploaded but authors not receiving any email is confusing. The editors get over-notified and the authors get no resubmission confirmation.

There is also no option to disable the revision upload notification (OJS 3.2.1RC or 3.1.1.x) so that we can ask authors to create a review discussion when they are ready as a workaround.

Ideally, the revision submission process should be very similar to the initial submission process - authors should get a chance to revise any metadata (for example, in case they have changed their title or abstract), to upload their rebuttal and article files, then to press a submit button when ready which sends separate email notifications to the editor and a receipt to the author.

[jnugent]

+1 from the hosting team, for a related but slightly different problem. We have an open ticket right now regarding editors who receive an email notification regarding a revision having been uploaded, but if the author cancels the revision upload, the file is deleted, and the editors are confused because there is no longer a file to view.