Improve editorial decisions UI after usability tests

[NateWr]

Describe the problem you would like to solve Our usability tests of the editorial decision UI (#7265) raised a few areas of confusion with the step instructions, email template finder, language switcher, and file attachments.

Describe the solution you'd like The following mockup from @Devika008 introduces the following recommended changes:

• Move the step description up so it is part of the vertical flow of reading and harder to skip.
• Improve the email templates UI to include a snippet of the email template.
• Change the icon and language of the insert content button.
• Move the attach file prompt up to the text control, so that it isn't confused for the file promotion action.
• Reposition the skip email and switch language buttons.
• Change the email step descriptions to indicate the email will be sent when the decision is recorded.

The following mockup introduces these changes:

• Add file uploaded by and date to the file promotion UI.
• Add more useful labels to the final record decision button.
• Make completed steps show a check.

Who is asking for this feature? These suggestions come from usability tests conducted by @Devika008.

Additional information See all mockups. Other improvements came out of the usability tests. This issue is restricted to those changes we feel we can make for 3.4.

[NateWr]

@Devika008 we are a little constrained in which icons we can use for the buttons inside of the text editor and how well we can style. The icons seem a little too large for the text and I'm not sure they fit comfortably next to the text.

Here is what it looks like with the closest icons I could find:

Here is what it looks like without icons:

And here is the list of icons we can choose from:

https://www.tiny.cloud/docs/advanced/editor-icon-identifiers/

Can you take a look and let me know whether you prefer with or without icons? And if you prefer it with icons, which icons should I use?

[NateWr]

@Devika008 I have implemented the new design for the steps component, using the :heavy_check_mark: to indicate complete steps. One thing that wasn't included in the mockups is how to handle cases where the user has navigated back to an older step that's already been completed.

In such cases, I chose to remove the :heavy_check_mark: and apply the "current step" style. Here is a short video showing what I mean. Does this look alright or did you want to suggest something different?

https://user-images.githubusercontent.com/2306629/203350741-e46b03ca-19a8-4161-88f2-c4fcbcfb53bd.mp4

[Devika008]

@Devika008 I have implemented the new design for the steps component, using the ✔️ to indicate complete steps. One thing that wasn't included in the mockups is how to handle cases where the user has navigated back to an older step that's already been completed.

In such cases, I chose to remove the ✔️ and apply the "current step" style. Here is a short video showing what I mean. Does this look alright or did you want to suggest something different?

steps-design-fixed.mp4

This seems perfect! Thank you Nate for bringing this edge case to my notice! Will include a variant of this in the design system

[Devika008]

@Devika008 we are a little constrained in which icons we can use for the buttons inside of the text editor and how well we can style. The icons seem a little too large for the text and I'm not sure they fit comfortably next to the text.

Here is what it looks like with the closest icons I could find:

Here is what it looks like without icons:

And here is the list of icons we can choose from:

https://www.tiny.cloud/docs/advanced/editor-icon-identifiers/

Can you take a look and let me know whether you prefer with or without icons? And if you prefer it with icons, which icons should I use?

@NateWr It is preferred if its with the icon because it increase accessibility for many users when translations fail to do justice. Hence use the below svgs for the icons-

list-bull-default.svg - for bullet points plus.svg - for insert content upload.svg - for attach files

Also isnt there a way to include underline as well ? Or that is not possible?

I have updated the designs on figma and I think in the inspect mode youll be able to see the padding used. I think youll have to increase the spacing between the icon and the text for it to not look weird and even between the buttons in general.

[Devika008]

Problem as identified by @NateWr

We are running into cases that might be a little confusing. For example, in the request revisions decision (see screenshot), the last step is to notify reviewers. But the button says "Request Revisions", which could be confusing since the user might wonder if revisions are being requested from reviewers instead of authors. In the accept submission decision (see screenshot), the last step is to select files, so "accept submission" might be confusing. Using something else, like "Send files for copyediting", might also be confusing, because it doesn't mention the other actions that are taken (like notifying authors and reviewers). What could we do better to remove the ambiguity wrt to the CTAs on editorial decisions

Possible Solution: In any applications we use on daily basis, an informative text or disclaimer is presented right before the submit button to reinstate with the user what will happen next if they click on a particular CTA and take action. In a similar way, I have removed the contextual CTAs in editorial decisions and made them consistent to "Record Decision" so as to remove any ambiguity. To inform the user the consequences of the decision, an informative alert message will be placed closer to the CTAs. Though this could cause repetition of information, but it would constantly reinforce to the editor the action they will be taking as many have pointed out that sometimes actions are taken and they do not know what is going to happen.

Exhibit A: Accepting submission in Review Stage

Exhibit B: Sending submission for review

Exhibit C: Sending submission another round of review without peer review

Exhibit D: Sending submission another round of review with peer review

Exhibit E: Decline submission

[NateWr]

@Devika008 I'm a little confused about the mockups you posted. Several of them aren't the last step of the decision, so wouldn't say "Record Decision". Instead, they would say "Next" and no action is taken.

The extra text feels like clutter, and it kind of makes me less confident in the application. Like, I think, "Wait, why is it warning me about something?" We've already added extra explanatory text to the step description at the top.

I'm worried about overloading the page with explanatory text that can make the whole process just feel more cumbersome and less intuitive. Would it be better if we showed a confirmation pop-up when the user clicks "Record Decision"? Here is an example:

[NateWr]

The following PRs implement most of the recommendations above:

• https://github.com/pkp/pkp-lib/pull/8461
• https://github.com/pkp/ui-library/pull/234
• https://github.com/pkp/ojs/pull/3640
• https://github.com/pkp/omp/pull/1263
• https://github.com/pkp/ops/pull/405

@jonasraoni do you have time to do a code review?

@Devika008 the UI updates match the recommendations, with some exceptions that we've discussed (eg - use of all caps). There are three things that didn't get implemented:

1. Changes to the Record Decision button. e. I can handle these in a separate PR based on our discussion from above.
2. I didn't implement the changes to the switch language UI. In almost all cases (90+%), there will only be one other language to switch to. For there to be 2 or more, the journal would have to be working in 3 or more languages. I felt the heading with the items under it as in the mockups looked strange with just one language. It was a lot of valuable space on the screen for something small and, I think, not very frequently used. Also, the button doesn't really change the language of the email. It changes the language of the email templates that are loaded. It's maybe a small distinction, but I feel like it should be more closely related to the templates rather than the whole email. It won't, for example, change the recipient names or attached files or anything. I think it's ok as-is, but if you want to suggest another change let me know.
3. Finally, I modified the language a little where I thought it was appropriate. For example, instead of "Templates to get you started!" I left it at "Email Templates". When the user loads the screen, a template will already be loaded into the email composer, so it didn't sound right to say "get you started". If you want to suggest alternate language let me know.

Here's a short video illustrating out the changes that were made.

https://user-images.githubusercontent.com/2306629/205110219-a51d5675-3d7d-43e8-ac05-4098406e5a47.mp4

[Devika008]

@Devika008 I'm a little confused about the mockups you posted. Several of them aren't the last step of the decision, so wouldn't say "Record Decision". Instead, they would say "Next" and no action is taken.

The extra text feels like clutter, and it kind of makes me less confident in the application. Like, I think, "Wait, why is it warning me about something?" We've already added extra explanatory text to the step description at the top.

I'm worried about overloading the page with explanatory text that can make the whole process just feel more cumbersome and less intuitive. Would it be better if we showed a confirmation pop-up when the user clicks "Record Decision"? Here is an example:

@NateWr Im sorry if I wasn't clear enough! I do agree that adding that text seems cluttering. However, adding the pop-up seems like duplication of actions and too many confirmations. I agree with you and think that we could stick to record decision as the CTA for all the last steps.

However, I have noticed this functionality in other softwares in publishing where the confirmation comes as a new page versus a pop-up. Which I feel would be great with respect to scalability in the future wherein if we want to add more things to page we can. Hence I recommend the following with the option to undo the decision which sends them to the last step of editorial decision.

Let me know what you think

[NateWr]

I like the idea of a review step. However, there's no ability to undo a decision once it's taken. Part of the structure of the decision record is that a decision can not be revoked. There are a few reasons for this:

1. We don't want editors to be able to tamper with the editorial record. It's sometimes important to be able to audit the decisions taken and to have an accurate record of the actions.
2. Once the decision is recorded, emails are sent and they can't be withdrawn. They're "sent".
3. Once the decision is recorded, several actions have been taken that are hard to undo: files may be created, DOIs may be generated and assigned, etc. Building in an undo step would be difficult -- and particularly so for third-party integrations which may take actions we don't know about.

[Devika008]

I like the idea of a review step. However, there's no ability to undo a decision once it's taken. Part of the structure of the decision record is that a decision can not be revoked. There are a few reasons for this:

1. We don't want editors to be able to tamper with the editorial record. It's sometimes important to be able to audit the decisions taken and to have an accurate record of the actions.
2. Once the decision is recorded, emails are sent and they can't be withdrawn. They're "sent".
3. Once the decision is recorded, several actions have been taken that are hard to undo: files may be created, DOIs may be generated and assigned, etc. Building in an undo step would be difficult -- and particularly so for third-party integrations which may take actions we don't know about.

@NateWr

1. With respect to the video you posted, everything looks great and I agree with all the points you put up. I will modify mu mockups to the same wrt to language. I have tweaked some text and language. Please review it once in my screenshots below
2. I did play around with the review step since building on our discussion the step for recording the decision is a crucial one and one where editors need to be sure of! Please view the options below and let me know what you think-

Step 1:

Step 2:

Step 3:

Step 4 (Option 1): {this is the one I prefer}

Step 4 (option 2):

Success Pop-up:

[NateWr]

I think I'm going to suggest we postpone the review until the next version. Adding the review page will be a fair amount of work just in testing the 20-25 different decisions. Hope that's alright, @Devika008!

[Devika008]

I think I'm going to suggest we postpone the review until the next version. Adding the review page will be a fair amount of work just in testing the 20-25 different decisions. Hope that's alright, @Devika008!

I think thats completely alright! however

1. I wanted to know your thought/ opinion about adding the review page?
2. I am OK with the CTAs being Record Decision however in the success pop-up please include the but that "if you have chosen to notify participants, emails have been shared with them?"

[NateWr]

I've merged the PRs above to main. Thanks for the review @jonasraoni.

@Devika008:

1. I like it! Might need to spend some time thinking through what/how to show for some edge cases. But we can do that later.
2. I've filed a separate issue for that here: https://github.com/pkp/pkp-lib/issues/8469