Bug 8315 - Clarify notification process for copyeditors
Clarify notification process for copyeditors
Status: RESOLVED FIXED
Product: OJS
Classification: Unclassified
Component: User Interface
3.0a
All All
: P3 normal
Assigned To: Jason Nugent
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-16 16:26 PDT by Alec Smecher
Modified: 2014-11-12 11:54 PST (History)
2 users (show)

See Also:
Version Reported In:
Also Affects:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alec Smecher 2013-07-16 16:26:45 PDT
Once copyeditors are assigned in Stage Participants, they need to be notified about the assignment somehow. This is the only part of the workflow that still requires the use of the Notify tab (in the Modal-Based Tabset Previously Known As The Information Centre) which is buried and has never been intuitive.

I suggest integrating the notification with the Editorial page and doing away with the Notification tab entirely, but that's not yet well-considered. Proposals welcome.
Comment 1 Jason Nugent 2013-07-17 16:41:23 PDT
Alec, would an email notification of "you have been assigned as a 'whatever role' to 'submission name.'" be useful here?  We could make the email an option by putting a checkbox for sending the new participant an email on the stage assignment modal.  That would eliminate the need to go back into the Notify tab and would be relatively easy to implement.
Comment 2 Alec Smecher 2013-07-17 16:48:42 PDT
I like the idea of including notification tools along with the stage assignment grid. We would need a row action to allow e.g. reminders too.
Comment 3 beghelli 2013-07-30 07:37:05 PDT
Alec, I was thinking about the idea to use notifications to warn editors that they need to notify other users so they know that they have to do something. I liked it.

Here are some suggestions:

1 - create NOTIFICATION_LEVEL_TASK to warn editors of what they can do inside each stage. This notification should be created for each editor user that's assigned to the submission, and deleted for all of them as soon as one do the process.

2 - those tasks notifications to editors should be created when a new stage is initiated.

3 - the notification link action should lead to the notify tab of the information center. We have two scenarios:
  - if no user is assigned to the current stage that can do the work, we don't present the recipient listbuilder but only a text telling that a user needs to be assigned to the stage and something like the stage assignment form.
  - if there's already a user to do the task, we can present the notify tab the way it is now, but adding an option to notify users that are not stage participants (presenting again the stage assignment form).
  In both scenarios, if editors chooses to notify users that are not stage participants, the email will be sent, the related task notification will be created (copyediting, for example) and the user will be added as an stage participant automatically.

4 - we can add an option to editors hide the notification. So editors that don't want to create a copyediting task notification for someone, for example, will be able to hide the task notification that says that they can do that.

4.1 - hidden notifications can still be accessed inside the notifications grid. We have just to add a filter option, so users can see what they dismissed and can make it visible again if they want.

5 - the editors notification is deleted as soon as an user is notified (and a task notification is created for them). But it can come back if this exact users is removed from the stage. 

Using this process we accomplish what Juan and I were discussing last year related to tasks and stage assignments in a way that can be easily implemented using the structures that we have now.

I think that the most difficult part is item 3, but that's not too much. We can add both the listbuilder and the stage assignment form inside tabs, named "stage participants" and "others" respectively.

If you liked it I can draw some quick mockups for this process. Just let me know.
Comment 4 Alec Smecher 2013-07-30 08:56:53 PDT
I like the general idea, but I do worry that adding show/hide options to notifications will start to blur the distinctions between notifications and the grid help text.

Also, I wonder how typical it will be for someone to assign a participant without notifying them. Currently assigning and notifying involves a lot of extra clicks:
- Assign the user to the participant grid
- Open the new participant grid row
- Click "Notify"

If (as I suspect) immediately notifying the user is the most common route, I'd prefer to just pop up the notification tool immediately after creating the assignment; if they don't want to notify, one extra click closes that modal.
Comment 5 beghelli 2013-07-30 09:51:41 PDT
show/hide should be considered a dismiss (should we name it delete?), and will only be available for things that are not required to complete the workflow process. Maybe we can implement something like 'don't show me this again'?

The biggest problem with the workflow is the absence of tips to what to do when a new stage begins. What editors can do in copyediting? They will have to figure it out that they have to assign an user to copyediting task. In your suggestion, they will know that only when they assign an user to the stage, but before that happens they will know nothing.

And more, if an user is already selected to the stage (because there's only one), how editors will know about the notify and the creation of the copyediting task?
Comment 6 Alec Smecher 2013-07-30 10:04:28 PDT
Bruno, are we talking about several notifications then?

- One for users who first arrive in Editorial, where no Copyeditor is automatically assigned, guiding them to the Participant grid
- Another for submissions that have Copyeditor(s) assigned, but to whom notification has not yet been sent, guiding them to the Notification step

I still prefer triggering Notify immediately after an assignment, since I suspect that'll be what people almost always need. But I take your point about missing guidance on the Editorial stage as a whole. How about combining the two approaches?
Comment 7 beghelli 2013-07-30 10:43:38 PDT
(In reply to comment #6)
> Bruno, are we talking about several notifications then?
> 
> - One for users who first arrive in Editorial, where no Copyeditor is
> automatically assigned, guiding them to the Participant grid
> - Another for submissions that have Copyeditor(s) assigned, but to whom
> notification has not yet been sent, guiding them to the Notification step

My proposal is to use only one editor notification for this, telling something like this:
"you can assign an user to do the copyediting task. Click here."

Then the link should lead to the notify tab. If there's already an user assigned to the stage, it should be used. If not, the editor should have a chance to choose an user from the system (see step 3 in my first description). That will automatically assign the user to the stage, that way removing the double steps to assign and notify. Makes sense?
Comment 8 Alec Smecher 2013-07-30 11:11:44 PDT
I think I see what you mean.

In my opinion the role of the Notify tab in the Information Center (now called Editorial History according to a wording change by John) is very weak; moving stage assignments into it would reinforce that weak role and at the same time weaken the Stage Participants grid by diluting its role in assigning users.

Personally I think the Notify tab should be removed entirely from Editorial History as it doesn't make sense there. A logical place to move it would be the Participants grid.

The kind of notification I favour is the kind that draws attention to the regular workflow, rather than providing a shortcut around it. For example (just visualizing, not making a concrete proposal) if we want to guide the user through assigning an Editor, the notification should draw the user's eye to the link they need to hit to open the participants grid, rather than attracting the eye elsewhere where another button can be hit to do the same thing. In the latter case, if we're making these notifications optional, or having the notification only appear under certain circumstances, the user will be trained to look in the wrong place and won't know to open the Stage Participants grid.
Comment 9 beghelli 2013-07-30 12:18:40 PDT
> In my opinion the role of the Notify tab in the Information Center (now
> called Editorial History according to a wording change by John) is very
> weak; moving stage assignments into it would reinforce that weak role and at
> the same time weaken the Stage Participants grid by diluting its role in
> assigning users.
> 
> Personally I think the Notify tab should be removed entirely from Editorial
> History as it doesn't make sense there. A logical place to move it would be
> the Participants grid.

Agreed, and it's already there, but it opens the editorial history modal. Maybe we can create a modal just for the notify that will be accessed only using the stages participants grid.  

> The kind of notification I favour is the kind that draws attention to the
> regular workflow, rather than providing a shortcut around it. 

Agreed.

The only problem that still remains is the cumbersome process to add an user and only after that notify to create a task for him. Maybe we can add mix stage assignment and notify in one screen?
Comment 10 Alec Smecher 2013-08-01 11:52:41 PDT
Bruno, agreed on all points. I'll give it a crack.
Comment 11 Jason Nugent 2013-08-02 10:37:56 PDT
Hi everyone,

Alec asked if I wanted to steal this bug.  Just wanted to outline my proposed plan.

1.  Remove the "Notify" tab from Editorial History modal.
2.  Keep the "Notify" link action on the stage participants grid, but have it open a single modal with the notify form (instead of currently opening the editorial history modal).
3.  *Also* include a notify form on the stage assignment form, as a single step.  So, choose a participant, choose a user group, and then have the subject/template chooser and message body form.  One click does the stage assignment and (optionally, if the form is filled out), the notification.

Sound good?

Jason
Comment 12 Alec Smecher 2013-08-02 10:52:19 PDT
Jason, that's what I was imagining. I figured the "assign & notify" modal could probably be a subclass of the normal "notify" modal, though YMMV.
Comment 13 Alec Smecher 2013-08-02 14:25:02 PDT
Notification tweaks from OJS
https://github.com/pkp/omp/commit/fd2dfb1818fbc4055033178bc7f8292e13873cba
Comment 14 Jason Nugent 2013-08-06 10:57:03 PDT
move Notify functionality to stage participants grid
https://github.com/pkp/pkp-lib/commit/38d309b18da2700e27a1452cd0c28a743e20afae
Comment 15 Jason Nugent 2013-08-06 10:58:01 PDT
move Notify functionality to stage participants grid
https://github.com/pkp/ojs/commit/59df6c0d31eaff2a1bdf26969439c89e6bc3e0f8
Comment 16 Jason Nugent 2013-08-06 11:07:02 PDT
move Notify functionality to stage participants grid
https://github.com/pkp/omp/commit/f461582455c6739861c58aceee6911b61fa99377
Comment 17 Alec Smecher 2013-08-09 08:49:46 PDT
Jason, I finally got a chance to look at this -- much clearer, thanks!
Comment 18 Alec Smecher 2014-06-11 14:15:40 PDT
See https://github.com/pkp/pkp-lib/commit/38d309b18da2700e27a1452cd0c28a743e20afae#commitcomment-6639430 for an additional issue this causes.

In the code linked, $stageId is the submission's stage ID; elsewhere (e.g. AddParticipantForm) it's the stageId that the user is currently looking at. This can lead to mismatch -- e.g. if submission is in the submission stage and the user is trying to assign a copyeditor, the copyeditor suggestion list will come back blank because it will look in the submission stage for copyediting users.
Comment 19 Alec Smecher 2014-06-12 09:58:03 PDT
Pull request opened (not merged):
prevent stage id clobbering
https://github.com/pkp/pkp-lib/pull/103
Comment 20 Alec Smecher 2014-06-12 09:59:03 PDT
Pull request opened (not merged):
prevent stage id clobbering
https://github.com/pkp/omp/pull/23
Comment 21 Jason Nugent 2014-06-12 09:59:35 PDT
Reassigning for review.  Alec, there should be two pull requests.  I think I did the submodule stuff right.
Comment 22 Alec Smecher 2014-06-13 06:33:02 PDT
Pull request synchronize (not merged):
prevent stage id clobbering
https://github.com/pkp/pkp-lib/pull/103
Comment 23 Jason Nugent 2014-06-13 10:20:03 PDT
prevent stage id clobbering
https://github.com/pkp/pkp-lib/commit/344a76c8fc58c06da92598fcde7c8db35c8b39b6
Comment 24 Jason Nugent 2014-06-13 10:20:03 PDT
fix variable names, remove extra template assignment
https://github.com/pkp/pkp-lib/commit/81c7d4db8e9232fa09cf9309c362b775fd0615d0
Comment 25 Alec Smecher 2014-06-13 10:20:03 PDT
Pull request closed (merged):
prevent stage id clobbering
https://github.com/pkp/pkp-lib/pull/103
Comment 26 Jason Nugent 2014-06-13 10:24:02 PDT
prevent stage id clobbering
https://github.com/pkp/omp/commit/5d4a435b9ff5cc0efd15cdec2e45109330f090d6
Comment 27 Alec Smecher 2014-06-13 10:25:02 PDT
Pull request closed (not merged):
prevent stage id clobbering
https://github.com/pkp/omp/pull/23
Comment 28 Jason Nugent 2014-06-13 10:29:02 PDT
prevent stage id clobbering
https://github.com/pkp/ojs/commit/65404d686261639573d5b8d3459c6804ec31e18f
Comment 29 Jason Nugent 2014-06-13 10:56:02 PDT
prevent stage id clobbering
https://github.com/pkp/pkp-lib/commit/bf5d2107320ee797e6f14260e328b2b097a0642a
Comment 30 Alec Smecher 2014-11-12 11:54:02 PST
Fix missing constructor parameter
https://github.com/pkp/omp/commit/f504729a358695e1b1f3ae6a3592eae07e52965f