Improve submission wizard accessibility and usability

[NateWr]

Description

Describe the problem you would like to solve
The submission wizard relies on older forms components that do not meet accessibility requirements. Also, the submission wizard is not as easy to use as it could be, because the steps are not clearly explained and the wizard-like UI looks more like tabs than a step-by-step process.

Describe the solution you'd like
Rebuild the submission wizard using the new forms components. Build it to meet accessibility requirements for use by keyboard or mouse, with or without assistive technology. Redesign the submission wizard to give a clear indication of the step-by-step process.

Who is asking for this feature?
This rebuild is required before we can commission an accessibility audit of the submission wizard.

Additional information
We hope this work will incorporate additional features requested in the submission wizard project, but we can't yet commit to this within 3.4's timeline.

Mockups

@israelcefrin, @ewhanson and I have worked together to identify ways to improve our existing submission wizard. Israel conducted a benchmark analysis of other submission systems. And we completed a card sorting exercise together to figure out how to break the wizard down into different steps.

The mockups below were made based on this work, as well as some of the technical requirements of the wizard. Israel will conduct UX walkthrough testing with these mockups and we are now looking for feedback from our community.

The mockups below do not include all possible submission data. They show the wizard with a typical configuration in OJS, which doesn't require every field. All fields will be accounted for when the new wizard is built.

Pre-flight

Before the author begins their submission, they are shown the pre-flight screen. This step is necessary to collect some information before the submission begins. The "Before you begin" text will be customizable for each journal.

Step 1: Upload files

Once submission has begun, the user is shown the submission wizard with a step-by-step design. Each step of the wizard has a description to tell the author what they must do on that step. This text can be customized by the journal.

The file upload panel is identical to the new file upload process introduced in 3.3.

Step 2: Contributors

Authors are asked to provide details about contributors to the submission. The mockup below shows features that we would like to implement in the future, where author lookup occurs by email or ORCID. However, for 3.4, we are likely to use something more like the existing authors list where each author is added manually.

Step 3: Details

Authors are asked to provide the key details about their submission. If enabled during submission, references would be collected during this step as well.

OJS / OPS:

OMP:

Step 4: For the Editors

All other metadata and submission information is provided in this step. We chose to group this information under the heading, "For the Editors", because authors often lack the confidence or ability to provide accurate metadata such as keywords, subjects, etc.

The help text for this section is written to indicate to the author that this information may not be final, but it should be provided to help the editors manage the submission. We hope that this will reduce an author's fear of making a mistake, and also help them understand why they are being asked for the information.

In OPS, the default text would be changed to reflect authors' greater control over metadata for preprints.

Step 5: Final Review

The final review step provides an opportunity for the author to review all of their submitted information. Any errors or missing information will be highlighted, and the author can go back to the step with the error to complete the information.

The final review step is also where the author will be asked to confirm any legal terms for the submission.

With errors:

Autosave

When viewing the submission wizard, all changes will be autosaved. The author does not need to click the save button to have their changes saved, and the UI will show them when the last change was saved.

Save for Later

Authors can save their submission and come back to it later at any time. When they click the Save for Later button, they'll be taken to a screen that confirms the submission was saved. They will be shown a link to access their submission again, and this link will be emailed to them.

Phone/Mobile Layout

On a small screen, the wizard will be collapsed into an accordion that shows the current step. It can be expanded to show all steps and move between them.

Wizard expanded:

Pull Requests

See comment.

• pkp/pkp-lib#7191 Implement new submission wizard ui-library#221
• pkp/pkp-lib#7191 Implement new submission wizard #8349
• pkp/pkp-lib#7191 Implement new submission wizard ojs#3579
• pkp/pkp-lib#7191 Implement new submission wizard omp#1220
• pkp/pkp-lib#7191 Implement new submission wizard ops#371

[asmecher]

For the ORCID invite, I envision a "ghost" entry that lists unconfirmed invitees along with conventionally entered authors. Otherwise users will probably try an ORCID invite, see no immediate effect, then enter the record manually, leading to a duplicate.

[NateWr]

👍 This part will need a lot of fleshing out. I don't plan to do it for 3.4, but I envision it working alongside a confirmation workflow for authors that includes ORCID authentication and CRediT assignment. Broadly speaking:

1. Submitting author only enters email or ORCID for each author during submission.
2. Each author is emailed to notify them of the submission. They are asked to click a link to confirm they are authors.
3. When they click the link, they are asked to provide full details (name, affiliation, CRediT roles) and to authorize their ORCID.

This would reduce the burden on the submitting author, ensure we're getting author information "from the horse's mouth", and provide built-in protection for predatory authorship behaviour (authors listed that shouldn't be, disputes over CRediT role assignment, etc).

[asmecher]

Sounds great, though I do think we'd need to check with the user community in some form before dropping support for submitting authors just filling in what they want, since that's the long-standing habit. I can ping the TC as a community proxy when we're ready to start thinking about that. And I think we should integrate the ORCID profile plugin into the core codebase before doing the ORCID aspects of what you've proposed.

[alexxxmendonca]

We should be mindful that as best practice, ORCID no longer recommends free-text input of ORCID IDs.

Adding the email should be enough and ideally the system would automatically send an e-mail to that address requesting the ORCID association.

[aguen]

Hi Nate, thank you for working on this! I like the "Save for Later" option (including email with a resume link), also the "Final Review" page (including legal terms).

One question on the "For the Editors" page: Will this page be configurable, meaning that journal managers are able to choose which metadata fields are presented to submitting authors and which not? In addition, a possibility to add custom fields would be great. (Perhaps the review form editor could be re-used for this?) (BTW: It is good to NOT use the technical term "Metadata" here!)

[NateWr]

We should be mindful that as best practice, ORCID no longer recommends free-text input of ORCID IDs.

This would kick off an authentication process, so it shouldn't be subject to the problems of unauthenticated or inaccurate ORCID IDs.

One question on the "For the Editors" page: Will this page be configurable, meaning that journal managers are able to choose which metadata fields are presented to submitting authors and which not? In addition, a possibility to add custom fields would be great. (Perhaps the review form editor could be re-used for this?)

The same metadata configuration options will exist. So things like keywords, subjects, references, etc can be included or not included in the submission wizard. We don't plan to support custom fields in the next major version (3.4), but it should be easier to add support for this feature in later versions. In the meantime, plugins can be written with custom fields.

cc @ViRuSTriNiTy if I recall, you wrote a plugin to add custom fields to the submission wizard. This work will impact your plugin, but it should make it easier to add your custom fields.

(BTW: It is good to NOT use the technical term "Metadata" here!)

🙌

[NateWr]

@israelcefrin conducted usability tests on these mockups, with the following recommendations.

• The page title "Make a Submission" should include the current step, such as "Make a Submission: Upload Files".
• When an error appears in the review step, add a link to the message at the top of the screen that will jump down to the first error.
• For each error on the review step, add a link to the step to fix the error. For example, in teh mockup above. The abstract error might read: "The abstract must be at least 200 words. Edit"
• Add the Save for Later button to the top of the page, in addition to the button at the bottom of the page, so that it is easier to find.
• On the pre-flight step, the section selection should be a radio button.
• The description text in the Upload Files step should tell the author that they will be able to write a comment to the editor at a later step, where they can describe the files that they have uploaded.
• All mandatory fields should show that they are required.

In addition, we had some feedback on the contributors step. Unfortunately, we won't be able to implement the contributors mockup for 3.4, so I have filed that as a separate issue for later development: #7223

[ronste]

Hi @NateWr ,

I very much like the new layout of the submission process as you suggested. My question would be what exactly happens when you press the submit button? I presume mails will be send to the author and the journal acknowledging the submission.

Will these mails contain information about the terms and conditions the author agreed to? Or do you have plans to document the legal act of agreeing to the terms and conditions in any other way (e.g. logging)?

The context of my question is of cause our previous discussion: https://forum.pkp.sfu.ca/t/documentation-of-the-state-of-submission-checkboxes-at-time-of-submission/62631/8.

Best wishes,
Ronald

[NateWr]

Hi @ronste,

My question would be what exactly happens when you press the submit button? I presume mails will be send to the author and the journal acknowledging the submission.

The email notifications will be the same as before. There are some complex rules about who gets what, but we don't currently plan to change this for 3.4.

Will these mails contain information about the terms and conditions the author agreed to? Or do you have plans to document the legal act of agreeing to the terms and conditions in any other way (e.g. logging)?

We've discussed this need at #7062 (and slightly different, but similar need, related to privacy consent at #6180). In the mockups above, I've included a checkbox in the final step that would address this, but I'm not yet sure that it will be implemented for 3.4. I hope to get to it, but we may run out of time.