Change the sort of the submission list component to be action-based rather than submission ID-based

[alex-wreschnig]

As someone who manages a large journal, like a journal manager or editor, or as someone with a number of roles in a journal, I want to quickly see a list of submissions that require action of some sort when I view the submissions list--especially "My Queue." so that I don't need to scroll through the whole list to see a list of items requiring urgent action.

Background

Related to but narrower than #4099 , the UI/UX group heard a number of complaints of users and journal managers about the sorting used in the submissions list component. The default sort is not helpful, and users repeatedly reported problems using the list as a result.

In the use-cases we identified, when a user loads the list, they are looking to find submissions that require some action to be taken, or to review the status of submissions that they are managing as an editor. Neither of these use-cases are well-served by the current sort, where submissions are sorted by submission ID in descending order.

Solution

The group agreed that ideally, this list should be sorted by:

• Items you were personally responsible for (reviews you owed as a reviewer, revisions requested where you were an author, decisions required from you as an editor, etc.)
• Items that you need to monitor the status of, but are not personally the bottleneck for -- Items that are overdue -- Everything else
• Anything else that might appear on the list

Observation

The group didn’t feel that they needed multiple sorts, or the ability to dynamically sort items in the submission component--filtering would be a powerful tool to help, but they only felt like they needed one sort. The group just felt like that sort should be different from the current sort.

From PKP Sprint Pittsburgh (2019/07): UI/UX group UI/UX group notes from the Pittsburgh sprint

[asmecher]

This is kind of at odds with the original plan described in https://github.com/pkp/pkp-lib/issues/4961#issuecomment-517323921 for two views of content: submission-based (generally ordered by date, but sortable) and task-based (automatically dismissed when an action is taken). Personally, I do think there is a strong case to be made for both views.

[alex-wreschnig]

This is kind of at odds with the original plan described in #4961 (comment) for two views of content: submission-based (generally ordered by date, but sortable) and task-based (automatically dismissed when an action is taken). Personally, I do think there is a strong case to be made for both views.

I'm curious, did you have specific use cases in mind where a date sort performs better than a task-oriented sort?

Over the three days of the sprint the UI/UX group dug into the list with four users with active journals, who all saw the submission list as their primary window into OJS and they strongly identified a need for their primary window into OJS to be organized around their tasks. As with all sprint attendees, I'm sure there's going to be some selection bias involved--but everyone we talked to about it had similar complaints with the sorting, so even if it was biased, it was a very strong signal. Given the management tasks they were trying to accomplish (identify actions needed, and then complete those actions) it seemed like a very reasonable complaint from my perspective.

That doesn't rule out other interaction models (or sorts) as being helpful to those users, but the primary ask was for task-based sorting to be the default.

The task list mentioned in #4961 was frustrating to use for a number of reasons, but a task-sorted submission list would seem to be significantly more helpful. @NateWr talked to us a bit about his plans for building out OJS's understanding of tasks and it sounded like there were a number of potential approaches for solving the issue. Especially if date sorts are important than creating separate lists or adding the option to sort would both be viable paths.

[asmecher]

I'm curious, did you have specific use cases in mind where a date sort performs better than a task-oriented sort?

This is going back -- yikes -- most of a decade now to the initial design work on OMP, but as I remember, we spent a lot of time considering two types of users: the managing editor, who needed a good at-a-glance sense of the current states of the submissions in progress; and the assigned editor, whose work is more task-based. For the managing editor, something more than just a list of outstanding tasks is necessary, I think. Assigned editors seemed more likely to work on a by-task basis. And as always, there's a huge amount of blurring of these roles, especially for small journals.

Moving the submission list to being task-based would risk having content disappear from the managing editor's radar, as part of their job is going to be ensuring that the users who are responsible for the next steps (e.g. reviewers, assigned editors, etc) are doing their jobs. So from my perspective, both approaches (task-based and submission-based) have a purpose.

Of the two, the task-based list is definitely not pulling its weight.

I'm open to redesigning any of this if and when it becomes a priority, but I do think simply flipping the submission lists over to task-based would cause a ruckus.

(Looking over this again, it's possible that I'm reading this wrong -- are you suggesting that we simply change the sort order, rather than the set of data that's included/excluded from the list?)

[NateWr]

(Looking over this again, it's possible that I'm reading this wrong -- are you suggesting that we simply change the sort order, rather than the set of data that's included/excluded from the list?)

Yeah, I think the group was just thinking about the sort order.

I do think there's a case to be made for both sorts. My personal preference is for us to solve these issues through filters rather than through sorting. Indications alongside filters can help reduce the time-to-meaningful-scan (for example, if a filter existed for "Revisions are in" it could say "Revisions are in (2)" when there are two submissions with this status).

I'm not opposed to sorting, but it is harder to do technically and it has to be implemented the same for everyone, whereas filters can be mixed-and-matched on a case-by-case basis. That means we're less responsible for deciding the sort order that everyone wants.

And we may find that after adding these features to filtering, users still want something more. And at that point, having this information will be useful to draw on.

[alex-wreschnig]

[Background information]

That's interesting. Thanks for filling me in!

(Looking over this again, it's possible that I'm reading this wrong -- are you suggesting that we simply change the sort order, rather than the set of data that's included/excluded from the list?)

Yep--that's the idea behind the request. The users made a very strong case for sorting the existing content in the submission list by, loosely, how much attention they needed to pay to it (in descending order).

As part of that, I think there was an understanding that to make this work, OJS could or would be configured (in this hypothetical scenario) to surface things that are overdue--not just from the managing editor's personal tasks but from the journal at large, as poking people and monitoring progress was something that everyone felt very strongly about. Otherwise, the editors would seem to run into the very problems you were identifying.

We had a conversation with Nate about it and it sounded like this isn't feasible now, but could be more feasible after he's completed the work to improve OJS's support for tasks and workflow management.

And yeah--changing the sort is one solution, and maybe one of the cleaner solutions, but not necessarily the only or best solution. If you folks cook up a different approach that solves the same basic issue(s), I think there'd be a lot of happy users.

[asmecher]

:+1: Thanks, Alex, that's very helpful!

[forgive38]

Our editors have similar requests to those expressed here. Indeed, they lack a dashboard allowing them to effectively see at what levels of progress the submissions are (they have between 200 and 600 articles).

And a sorted view allowing them to see the submissions that have not been updated for some time.

It appears that 2 things would be necessary:

• a sorting in chronological order (reverse or not) (it seems to me that the option is already available in the API)
• filters linked to the status of the submission (the list of REVIEW_ROUND_STATUS is probably a good start) with the number of submissions associated

Maybe I can help if you give me the directions to take, especially for filters and counting:

• to add filters related to states, should I use the implementation of the "isOverdue" filter?
• and for the countdown, when each filter is displayed, do I have to make a call to the API which with an option'onlyCount' returns the corresponding number?

Thank you in advance

[NateWr]

@forgive38 thanks for offering to contribute! :+1: Can I redirect you to #4168? That's our highest priority improvement to the submissions list, and I think that it aligns well with your editors' needs.

Sorting is harder right now because we don't yet have a design pattern for sorting our new lists. We need to go through a design process to figure out how we're going to implement list sorting before we can just put code in. For that reason, I would discourage you from working on those options.

For the filters by review round status, can I redirect you to #4103?

And for the counts, I'll redirect you to #2617 where I think you're already active.

I'll follow up with you in each of those issues with more details.