Pkp-lib: [OJS 3.1] Declined submissions not appropriately highlighted as such

[pkel]

Updated (2019-07-03)

A mostly ready-to-go version of this request is implemented in PRs here: https://github.com/pkp/pkp-lib/issues/3386#issuecomment-477642290. However, it needs to be rebased after the versioning changes and tested to make sure it still works correctly.

Also, it would be good to include more prominent Published/Declined indications at the top of the new workflow UI that is being introduced with versioning.

Original Report

I got reports, that users don't recognize the declined status of submissions.

The status is reported, but it seems to be not clear enough. The Accept Submission and Decline Submission buttons are the two most prominent items on the page and distract users from seeing the actual information. Similar issues arise on the submission tab, where declined information is missing and both Send to Review and Decline Submission are highlighted.

I suggest to hide actions on inactive stages and adapt their coloring dependent on the outcome of the review process.

[asmecher]

@pkel, would you mind marking up a screenshot or two to make your suggestions concrete? Tagging @stranack, in case he's seen similar feedback in UI/UX tests.

[pkel]

Submission tab now:

Submission tab proposal:

Revision tab now:

Revision tab proposal:

Similar approach for the other tabs. Generally speaking, the buttons should be replaced by a submission status. Only on the active stage, when it makes sense to record a decision, the buttons should be visible. Advanced features, like publishing twice or accepting without review should be less accessible.

[asmecher]

Thanks, @pkel -- tagging @stranack and @natewr.

[stranack]

Yes, thanks for putting this together @pkel -- I like what you're proposing here. We'll examine this further, get back to you with any questions, and report back on next steps.

[NateWr]

We should probably look at how @bozana did the Editorial Recommendation notifications and mimic that approach.

[larsvilhuber]

I second the proposal here, with an additional twist:

• when DESK REJECTING (without review), there is NO indication whatsoever on the "Workflow" page of the current state ("Submission" tab). See screenshot of a declined article (note the absence of any indication thereof on this tab).
  

At a minimum, a similar notification to the "Review" tab should show up.

[retostauffer]

The pull-request https://github.com/pkp/ojs/pull/2072 contains a proposal on how we think this issue could be dressed. Following our original idea (comment https://github.com/pkp/pkp-lib/issues/3386#issuecomment-367314848, @pkel ) I've tried to hide the buttons whenever a decision has already been made and show the latest recorded decision (dictionary only defined for en_US).

As this was my first pull-request I am not sure whether everything worked as expected :).

Some screenshots of how the changes look on the admin front end:

[asmecher]

Thanks, @retostauffer! I think the PR was created against the wrong branch (as commented on it); see if you can straighten that out, and I'll leave the review to @NateWr (though it may be a week or so before he can get to it).

[retostauffer]

Hy @asmecher , thanks for your reply. My bad, pull request against ojs:master rather than ojs:ojs-stable-3_1_1. I've made a new pull request where only the local changes are visible.

https://github.com/pkp/ojs/pull/2075

Most of the changes, and there will be some logic-issues, have been made in the pkp-lib, followed the guidelines, hope that's done correctly (I kind of think .. not: https://github.com/retostauffer/pkp-lib/commit/88059b057702377c1b727d7ef43ea8eee39b2e50). Sorry for that, new world for me :).

[NateWr]

Thanks @retostauffer. Can you make a pull request for the pkp-lib changes as well? It's easier to review and comment on the changes once they're in a PR.

[retostauffer]

Sorry for my messed up pull request a month ago. I found some time for a new attempt:

• Small changes in the ojs repos (3_1_1): https://github.com/pkp/ojs/pull/2108
• Corresponding changes in the pkp-lib (3_1_1): https://github.com/pkp/pkp-lib/pull/4018

The changes affect the action buttons on the admin interface. The idea is to hide (but not completely disable) these buttons as soon as an action has been recorded. At the moment it is hard to see for an editor whether or not he has to trigger an action (or the action has been triggered already). This could cause confusing situation if the editor triggers two different actions for the very same submission.
I hope that, this time, the pull-request is as it should be.

[NateWr]

Great work @retostauffer! I made a few small changes to this and I think it's ready for some tests. What I've changed:

• The messages indicating the decision that was taken now refer to the decision taken _in that stage_, rather than the most recent decision. (See screenshots below.)
• Removed some unused locale strings after the above changes.
• Added a new handler to toggle the display of editorial actions.
• Adjusted the styles of the decision message, change button, and actions.

PRs:
https://github.com/pkp/pkp-lib/pull/4641
https://github.com/pkp/ojs/pull/2346
https://github.com/pkp/omp/pull/658

@retostauffer would you be willing to do a bit of testing on this to make sure I haven't missed anything? I changed some of the conditional logic, so it'd be good to have a second round of testing.

Submission stage

Review stage

Review stage in old round

Copyediting stage

When a submission is declined (all stages)

[NateWr]

@amandastevens @kaitlinnewson This issue will effect docs.

[retostauffer]

Hy @NateWr

Awesome! Thanks a lot in advance, looks great so far! I am more than willing to do some testing. We start testing 3.1.2 next Monday and I'll try to set up a blank installation (I assume that your commit is in the current master branch?) such that we also test this feature and provide some feedback a.s.a.p.

Thanks again and all best from Austria,
Reto

[NateWr]

Yes, this is pegged against master, which will be quite different from 3.1.2, unfortunately. But if you can test it that'd be great! All the best from Scotland. :wave:

[retostauffer]

Hy @NateWr

Took longer than planned to go trough it. I was not able to migrate our full system and tested your pull request on a fresh installation. Overall it looks pretty cool! Thanks a lot!

I/we have noticed some things (maybe there's a reason for it), I hope it's OK to just list them here (t.b.d.). Well, it's basically one issue (and one smaller comment).

The "_Send to Production_" and "_Schedule for Publication_" action buttons:

• Fresh submissions show both, "_Send to Production_" and "_Schedule for Publication_"
• Submissions which are in review shot both, "_Send to Production_" and "_Schedule for Publication_" (1)
• Submissions with an open review stage which have been "_Sent to Production_" show "wrong" message on the Submission tab ("_Accepted for Review_") (2)
• Accepted submissions: all fine.
• Declined submissions show the "Schedule for Publication" button ("_Send to Production_" is hidden)

My suggestion: it would be an idea to _hide these two buttons_ as long as no editor decision has been recorded? Even if no review process is needed we should still record the "_Accept and Skip Review_" decision. If the "_Send to Production_" and "_Schedule for Publication_" buttons would only be shown after a valid decision one could avoid sending stuff into the final stages without a decision. Or is there a technical/user need for this?

• (1) This is especially critical in combination with the "Assignment privileges: This participant is only allowed to recommend an editorial decision."
• (2) This will be obsolete if one cannot send submissions to production/schedule for publication as long as no editorial decision has been recorded.

One small comment: after recording a decision the page does not change. Would it easily be possible to refresh the page (and restore the active tab) such that the action buttons will be hidden and the message appears (e.g., "_Submission declined: Change decision_"). Kind of a visual confirmation for the editor that the decision has been recorded by the system.

What do you think? Unfortunately have not had time to try to implement this on my own ... sorry for that.

All best and many thanks,
Reto

[retostauffer]

Hey @NateWr
Just a shy question: have you had any time to address this issue? It is summer again and we are trying to find out whether or not we should migrate before autumn, and this is one of our "critical things".
Thanks and all best,
Reto

[NateWr]

My apologies again for the delay. Thanks for running some tests to make sure it worked out ok! Unfortunately, the pull requests will need to be refreshed, and there are some big changes coming to the workflow screen due to the introduction of version management. I will try to work this in with those changes in time for 3.2, which will probably go out Q3/Q4 (no promises!).

The "Send to Production" and "Schedule for Publication" action buttons:

In OJS 3 we've introduced a flexible workflow, so there are no hard boundaries regarding the use of every stage. For that reason, we allow editors to activate all stages at any given time. Yes, this does introduce some ambiguity, but with the rise of preprints, early access, open review and other models, we need to be able to support non-linear workflows. So, for now at least, these buttons are available even if a review decision has not been made.

Submissions with an open review stage which have been "Sent to Production" show "wrong" message on the Submission tab ("Accepted for Review") (2)

The message on the top of each stage tab indicates the last action taken on that stage. So even if the submission has "moved on", the submission stage will always say accepted for review if that was the decision made in that stage.

after recording a decision the page does not change

In most cases, we reload the page after a decision is made. But I remember hearing that this didn't happen in some cases. However, I can't seem to find the issue filed for this. If you can document the editorial actions that are taken that don't refresh the page, we can file that and try to address it in a future issue.

[NateWr]

FYI, I've updated the original post to reflect changes we're introducing with the new versioning feature. The work put into this has lingered longer than I would like so we're planning to roll it in with these changes to make sure it ships with v3.2.

[NateWr]

Merged to master so this will ship with v3.2. Thanks @pkel and @retostauffer for your patience on this one.

@amandastevens and @kaitlinnewson: reminder that this will effect docs. See https://github.com/pkp/pkp-lib/issues/3386#issuecomment-477642290 for screenshots of how the view of editorial decisions changes after a decision has been made in a stage.

[retostauffer]

Hy @NateWr

Great to hear! Thank you so much. I've patched our (test) system and it works very well. Love to see it being part of v3.2!

Thanks for your efforts,
R

[forgive38]

Hi

@retostauffer @NateWr @pkel : Thank you for this great work !

Just one point : when we decline submission in submission stage, we don't see immediately that the status changes, we have to refresh page. Maybe it's possible to update submissionEditorDecisionsDiv when decision is raised ?

Thank you in advance

[retostauffer]

Hy @forgive38

Ai, that's something I had on my todo list. Check @NateWr's comment https://github.com/pkp/pkp-lib/issues/3386#issuecomment-505783195

In most cases, we reload the page after a decision is made. But I remember hearing that this didn't happen in some cases. However, I can't seem to find the issue filed for this. If you can document the editorial actions that are taken that don't refresh the page, we can file that and try to address it in a future issue.

Not sure if we should wait for OJS 3.1.2-2 and see whether this issue has been addressed or not.
As you currently have this on your personal radar: may you check where this happens (see quote) if you can find some time and open a new issue? Would be great if you tag me, I'll try to keep an eye on it as well (we plan to migrate soon; will do some testing anyways).

Thanks a lot,
Reto

[NateWr]

If you can determine which actions are missing a page reload, then please file that as a new issue. I don't think that will have been addressed as part of this work.

If you want to work on it yourself, look for the method redirectUrlJson, which will be used to send a response to an editorial action that says to reload the page. It's probably just missing in the responses of whatever actions aren't reloading the page.

[matheusotoni]

If you can determine which actions are missing a page reload, then please file that as a new issue. I don't think that will have been addressed as part of this work.

If you want to work on it yourself, look for the method redirectUrlJson, which will be used to send a response to an editorial action that says to reload the page. It's probably just missing in the responses of whatever actions aren't reloading the page.

Hi @NateWr, how are you? I have a similar problem, when reload a submission, the page is not updated, so the user needs to reload the page to check the status of the submission. I saw that the file controllers/modals/editorDecision/EditorDecisionHandler.inc.php has a redirectUrlJson, but I was unable to redirect after rejecting the submission. Can you help me with that?

BR,
Matheus Otoni

[NateWr]

@matheusotoni can you file a new issue and include details on how to reproduce the problem you're facing and what version of OJS/OMP/OPS you are running?

[matheusotoni]

@matheusotoni can you file a new issue and include details on how to reproduce the problem you're facing and what version of OJS/OMP/OPS you are running?

Hi @NateWr, I created a new issue: https://github.com/pkp/pkp-lib/issues/6270