[UI] Improve submission process

[NateWr]

This is a general ticket to track improvements we can make to the submission process. It's incomplete but it can be a central place for tracking stuff that occurs in discussions or ideas we don't want to lose.

• Improve file component type (Deprecated in favor of [OJS] Improve submission process #1528 (comment))
• Single-file upload component [UI] Single-file upload component #988
• The file type selection step is getting missed by most people. Fixed as part of [UI] Single-file upload component #988
• There's lots of confusion around when multiple files can be uploaded. I think there's room for a bit of a re-think in the file upload process.
• Users want to see an overview of their submission data before hitting submit. [OJS] Improve submission process #1528
• Improve initial submission flow [OJS] Improve submission process #1528
• Enable keyboard accessibility Submission file upload can not be performed with keyboard controls #1411

[NateWr]

We could make primary or common file component types easier to select. The list is long and sorted alphabetically so you have to go digging for the "main file".

[beghelli]

I like this idea. I've already used optgroup labels in the UserUserGroupListbuilderHandler.inc.php, but I didn't implemented in the select.tpl file. I did it in JS, but if we are going to use it anywhere else, I think it's better to implement it in the FBV and let the UserUserGroupListbuilderHandler.inc.php use it that way also. Just a note to not forget.

[NateWr]

👍

[asmecher]

We actually have three types of files:

• Submission files (what you've called "primary files", though it's possible that presses will want to use this for files that don't neatly fall under that heading)
• Supplementary files
• Artwork files

The difference between these is in the indexing metadata available to each. Submission files get a title only, and presumably inherit the rest of their descriptions from the submission as a whole; Supplementary files get a full Dublin Core set of their own; and Artwork files get some art-specific fields such as credit, DPI, etc.

My first thought was that this distinction might not be relevant to the user, but I'm not so convinced that it's not useful for end users like authors to see as well when uploading.

Generally I think we'll recommend that presses remove the types that they won't be using, so in practice many presses will have fewer options. Maybe as few as two or three.

[NateWr]

Sounds good @asmecher. My main priority is to raise the profile of the primary files, so that users can find the one they're most likely to use in most cases quickly. We don't need to replicate the under-the-hood file distinction. But having "submission files" separated out visually might make it easier -- particularly for that first file upload when they're most uncertain of what they're doing.

[NateWr]

The initial submission flow is disorienting because users have to first learn that they have to register and then once registered they get dumped in a very different-looking backend display. This could use a pretty big makeover. Some ideas:

• Add a prominent Make Submission button on the frontend, perhaps next to Search, that links to the Submissions Page.
• Add a prominent Start Submission button on the submissions page.
• Create a frontend landing page for a completed registration. The page should say prominently "Thanks for registering with the Journal/Press of ..." and followed by a list of actions: "Make a Submission", "Complete Profile". Only then should it jump to the backend. This landing page could be used for logging in too, and include other actions based on user role, eg: "View assigned submissions" for reviewers.

[beghelli]

@NateWr I like the idea of the Start Submission next to the search bar... I would appear even if the user is not logged in? I think that it could be the case, and if the user is not logged in, then it could lead to the login page, where he could login or register...

[bozana]

When I am logged in as a reviewer, I can see the "New Submission" button on my submissions page. When I click on it, I get the page with the message "The current role does not have access to this operation.". Wouldn't it then maybe be better not to show that button at all?

[beghelli]

Sure. I think we can check for the user roles before showing this button,
right on the template file. We have an object that's always accessible in
templates that stores the roles the current user has. An example:
https://github.com/pkp/pkp-lib/blob/master/templates/common/header.tpl#L73

2016-03-09 10:17 GMT-03:00 bozana notifications@github.com:

When I am logged in as a reviewer, I can see the "New Submission" button
on my submissions page. When I click on it, I get the page with the message
"The current role does not have access to this operation.". Wouldn't it
then maybe be better not to show that button at all?

—
Reply to this email directly or view it on GitHub
#975 (comment).

[NateWr]

@bozana Would you create an issue for that against the OMP 1.2 milestone so it doesn't get forgotten? The rest of this issue will probably not get tackled until after 1.2 is out.

[NateWr]

Dumping a quick thought on improving the clarity around file revisions.

[asmecher]

+1 to that mock-up, @NateWr. That's much clearer and a totally obvious improvement in retrospect.

[bozana]

@NateWr, the commit above is just a small fix, I believe. The "submit in my role as..." section was/is usually not visible, so maybe you haven't seen it yet -- when displayed, it was in the same line with the "submission type" section:

Now I change it so that the next section is below it, i.e. now it looks like this:

If this is OK so, I can make a PR, or you could take/integrate the commit... or else, you could solve it differently... or else, just forget it... :-)

[NateWr]

You're right. Never seen that! The fix looks good.

[bozana]

@NateWr, thanks! I made the PR: #1282

[asmecher]

@bozana, is this ready to be closed?

[NateWr]

@asmecher no, this is a long-term ticket collecting ideas for a future overhaul of the system. It's not pegged to any milestone.

[asmecher]

Forgive me if I sound eager to get that bug count back under 20 :)

[NateWr]

The remaining items are better covered in other tickets. Closing.