Basic commenting features

[chris-huggins]

Definition: The basic functionality for adding requests or questions to an author on specific parts of their submission when they need to make a change in order to pass quality checks. This should be a flexible pattern for commenting on anything within a submission, initially on form elements, but eventually also annotating an HTML version of a manuscript. It must be relatively consistent with the design of equivalent features in "Libero Producer" where similar "Author queries" are raised in the Production process.

Commenting on a submission should create a "to-do list" for authors to work through, and the expectation is for authors to complete the requested changes (or answer questions) and either "mark as done" if they feel they have sufficiently completed them, or "reply" if they need clarification, help or disagree. We need clear feedback of the progress of the to-do list to encourage authors to complete all requests.

We then expect staff to "resolve" anything they deem "complete", reply to any comments from the author or reply to comments "marked as done" if the author has not sufficiently completed the request. The alternative is for staff to make changes on the authors behalf.

User testing has highlighted the need for authors to add optional replies to comments even if marked as done (to explain or add context), and for staff to add an optional reply when "resolving" an issue to ensure the author has explanation for why it was resolved or simply to inform authors of changes they've made to make them aware.

Testing also highlighted potential for "questions" to authors, which aren't asking to mark as done but require a reply, and for simply adding information comments to authors to inform them of changes that require no action at all.

Potential comment types:

• "Update request" - asking author to update - options are "mark as done" or "reply"
• "Question" - asking author for info - option only to reply
• "Note" - informing the author of something - no action possible except "hiding"?

This prototype was used to test the basic interactions for adding and replying to comments.

This prototype walks through the commenting feature within the submission detail tabs

User stories: "As a staff user I would like to make requests to the corresponding author for changes to their submission metadata so that I can guide them to get their submission in a state ready for an initial decision or peer review."

"As a staff user I would like to ask questions of the author to help them update their submission, or inform them if I have made changes on their behalf so that I can be sure their submission is correct by making edits on their behalf if minor changes or they're having trouble updating their submission."

More user stories

[chris-huggins]

I've been reviewing our findings from user testing in terms of whether we have an overall "Send comments" button for staff and authors to work on their comments or responses, then "send" them all in one go.

There have been user stories and input from Production that the equivalent "author queries" in Production will need this...and ideally we'd have consistency.

My thoughts are in this document but the outcome was to continue with "real-time" comments to trial or test with an actual build. The production use cases and outcomes of user tests have not made a strong enough case for going to an overall "send comments" feature from the start.

[chris-huggins]

After some testing, it seems google's commenting notifications are based on a 5 min timer. It seems (but not certain yet) that after adding a comment a 5 minute timer starts. If another comment is added while the timer is less than 5 mins, the timer is reset. Once the timer reaches 5 mins (i.e. long enough to presume the user is done) do they sent a notification email with "bundled" notification of each comment added.

We could do the same. So any comment added or responded to starts a timer, but is reset and "bundled" with each comment added/responded. Only once the timer reaches our max do we send the notification. We could be more conservative e.g. 30 mins.

Dropbox Paper appears to use the same model but waits 10 minutes before sending notifications.

[chris-huggins]

Some rules:

• For staff, status switches from "to-do" to "done" once a single comment is added/responded to

• But the comment is not actually sent immediately but instead a timer is started

• If another comment is added before timer reaches target, the timer is reset

• If the timer reaches target, all "unsent" comments are "sent" and the author receives an email

• If additional comments are added/sent without the author "sending back" then no additional email notification is sent? Unless the author has responded to all comments/status is updated to done? -- In this case should/could the additional comments be added/sent to author immediately? i.e. they would see the counter increase or comments 'appear' while they look at the submission

• For authors, the status doesn't change until they've updated/completed all updates

• However, staff should see comments added immediately (but status doesn't change) so they 'could' watch in real-time if they want

• Staff are only informed/receive notification/status changes to "to-do" after the author responds to all comments (whether marked as done or replied) - until that point authors will only see "updates requested" and a count of the remaining to-dos... so this should be ok as it's clear they still have to action something...

• For comments to staff or editors, no notifications occur unless the user is directly mentioned. In the case of mentions, the same "set a timer and reset if more are added" approach would make sense.

• If staff/editor comments are added there are no notifications, but we need to clearly show their existence to the correct role/people

• When responding to direct mentions, it would make sense to use the same timer approach, resetting the timer every time a comment is responded to (and presumably if the person adds a new comment mentioning the same person)

The risk is that staff take a break or exceed the timer when in the middle of responding to comments, then an author will receive multiple notifications/emails. I guess this is acceptable assuming we set the timer sufficiently. Do we need to allow a manual override (send now) type function if it is urgent?

Could there be a situation where the author cannot finish everything but expect staff to be informed?