Labels - high visibility 'tags' for important info

[chris-huggins]

User need: "As a staff user I would like to add high visibility information to a submission so that anybody (except the author) opening the submission or browsing the dashboard is made aware of these important issues"

This was identified by working with eLife's editorial team and testing/Q&A with the Ed Office team to examine how and why they use sticky notes.

Key features:

• Constrained selection of high visibility "labels" to choose from
• Labels are shown on the submission at dashboard level
• On submission tabs labels are shown as well as additional text for context/further info
• Ability to add the further info/context needed
• Edit/delete etc.

Examples include:

• Authors on a submission that are Editors/BREs that should not be assigned or consulted
• When submissions are co-submissions or re-submissions
• When submissions are delayed or held

There could be an argument made that each of these scenarios could be handled in a "smarter" way, so adding labels would not be a manual action. But each feels like a bespoke solution to a specific problem. Manually adding labels would be quite flexible and would likely be of use for various scenarios we aren't aware of yet or for other journals.

The danger is if they are used as workarounds to solve other problems (e.g. how sticky notes in eJP are used to pass submissions from team to team).

It would likely make sense to allow an admin/management user to constrain the labels to prevent this.

• [ ] Define list of labels needed for QC

• [x] Design interface for adding/editing labels

• [x] Design visuals/layout etc. for labels once added

• [x] MVP for adding custom labels

• [ ] Tech tickets

• [ ] Review/user test how they're being used

• [ ] admin interface for managing the labels available to a journal/organisation (post MVP)

[chris-huggins]

Need to explore more examples of potential labels to decide if it makes sense as a feature.

The user needs this has been designed to provide is to highlight submissions that:

• Are re-submissions (i.e. were rejected and re-submitted based on advice from reviewers/editors
• Have an author that is an Editor/BRE.

Re-submissions could/should be "linked" to the previous/related submission so that the Editors and reviewers etc. can be "re-surfaced" to users to make it easier to identify and re-assign/re-invite. It may make more sense for this feature to be more "bespoke" to this scenario, where the "possible duplicate" is detected and the user "links" the submissions. This could automatically add a "label" of "Re-submission" so would not need the "add labels" feature.

For "Author is Editor" scenarios, the decision has been made to request authors to "self-declare" is an author of their paper is an Editor or BRE. This could also be "flagged" to staff automatically and add a label, so that staff do not need to add a label manually. This allows us to ensure the author is excluded from the People picker so that they aren't assigned to the submission (similar to author exclusions)

With these two scenarios potentially automating the adding of a label, it may not be necessary to add the feature to add them manually. We should explore further if there are additional user needs for "manual labels" and discuss the risks of creating too bespoke a solution for these scenarios.

[chris-huggins]

The prototype for "adding/removing" labels has been tested and well received, however an interface will be needed for admin to define what the labels are.

This interface (or user profile controlled permissions for managing labels) is unlikely to be MVP.

But adding labels automatically (and the label component) will likely be part of the MVP to handle duplicates, authors as Editors etc.

Will the ability for Ed office staff to add or edit labels be requires as part of an MVP of this milestone? e.g. if part of a collection, co-submission etc. I believe it should be part of the MVP to avoid causing Ed Office problems for a prolonged period of time.