A couple of weeks ago I arranged OJS3 workshops for around 30 journals. I have listed here the feature requests the editorial boards mentioned during the workshop.
Adding a new reviewer. Some journal editors wish to have a title field in the form they can fill in so that the title could be mentioned in the letter that is send to the reviewer (for example Professor John Doe, instead of John Doe).
Sending a manuscript and adding supplementary files. Some of our journals considered the “this is not a revision of an existing file” option confusing while submitting a manuscript. Is this pull down menu needed when submitting the first version of the manuscript?
Custom reviewer recommendations. Many journal editors would like to have their own reviewer recommendations. Most of them mention the options “Minor revisions” and “Major revisions”. These are now hardcoded, but is there any reason why these could not come from the database so that a single journal could customize them?
Choosing an editor/section editor. It was suggested that when an editor is choosing a section editor they should see in the listing how many submissions the section editors/editors are currently working with. Basically the same kind of listing you get while choosing a reviewer.
Save button in the reviewer form. Instead of just submitting the review, it was suggested that a reviewer should have to option of just saving the contents of the review form an come back later to fill in the rest.
Forthcoming articles. Many of our journals like to prepublish single articles before they are published in an issue. Could this be something worth building into the core?
Automatic reminders to authors concerning revisions (this is mentioned already at the forum)
Help for reviewers and authors. OJS3 provides context sensitive help in the dashboard. However, this does not include the submission process or the review process although it is probably the authors and reviewers that would benefit the most.
Production ready files has no select option. I do not know if there is a reason for it, but why would the production ready files panel not have an option to select files, only upload?
Thanks for the detailed feedback. As you can imagine, we get a lot of feature requests. The trouble is figuring out how to prioritise them. Our small UI/UX working group is currently working off of a list culled from our own user testing, and we’ll be discussing your requests and figuring out how to fit them into our development schedule.
Since 3.0, we’ve been doing a lot of small fixes for things that have cropped up and implementing some significant features still missing. But we’re also looking forward to tackling some UX improvements like these.
I’ll run down your list of requests and give my first impression. Maybe others will jump in as well.
Can they not just type the person’s Title into the email? A new field puts an additional cognitive burden on every user, so I’d like to avoid a new field if possible. http://imgur.com/a/CeFfR
The first file that’s uploaded shouldn’t show the article revision option. But any subsequent file uploads do, because people can make mistakes during the initial file upload. I think you’re right that this isn’t as clear as it could be. I’d like to see the revisions option de-emphasized, perhaps turned into an optional checkbox below the file upload control. I’m sure we’ve discussed this but can’t find a specific Issue.
I’m hesitant to add another point-and-click tool for customising the workflow. It’s a road that can quickly spiral out of control. Instead I’d like to see us improve the way we use hooks to expose things like this to plugins for more customization options by developers. Care would need to be taken, though, to ensure that data is not corrupted. If the meaning of a recommendation value is changed, this change won’t be reflected in historical data.
Good idea. Probably not a high priority, but an obvious win if we can get to it (PRs welcome of course. ;)).
Good idea.
Forthcoming articles probably intersects with discussions about supporting the continuous publishing model (where there are no issues). Probably worth thinking about this at the same time because we can probably find a way to support both models with less overhead than thinking about solutions for just one.
Can you link up the post about author revision reminders?
Good point. We planned to roll this out further but it’s been a bit neglected singe initial merge.
Thank you for your thorough response! I of course undestand that you get a lot of requests and can imagine that some of them are also contradicting.
I believe it is not a new field, there is a title field in the user profile. However, this field is not available when adding a new reviewer from the workflow. But I do think that the solution you mentioned should be adequate.
Yes, the other problem here I believe is that when submitting revisions the authors actually remember to choose the right file from the pull down. I’ve also had questions whether it would be possible to upload all the files at once (I once again compare to WP) and define what they are after that. Overall it seems that there is a lot of questions concerning file uploads.
I think this is more a question of journals wanting to rename the already existing recommendations. If they would come from the database, it would be a lot easier. If I understand correctly there is no actual functionality tied to the recommendations.
I have this in my todo list (with a lot of other things)
I would be happy to hear about these plans and would be happy to participate during spring.
Just to clarify, I mean this panel in production stage. In copyedit stage the same panel has the option of selecting a file from earlier stages and I can’t figure out why this would not be a good option in production stage as well.
(2) Yes, multi-file upload is, well let’s say an “aspiration” of mine. This is something I’ve recorded in the following Issue, which is a kind of dumping ground for ideas to improve the submission process:
(3) If they just want to rename the existing recommendations, have you considered doing so through the translation file? The recommendation values are numeric, but they’re used to generate reports (maybe just in a plugin, I’m not sure).
(8) Ah yes, sorry, I meant I don’t really know why it doesn’t have the select option. Maybe there’s a reason. Maybe not .
(3) I have, but we have over 30 journals and only a few want these changed. While figuring this out I found the file where these are hard coded and if I recall correctly if would be fairly easy to add a hook there to enable renaming via plugin. I will try to look for that again.
Edit: The function I was remembering is here: https://github.com/pkp/pkp-lib/blob/ojs-stable-3_0_1/classes/submission/reviewAssignment/ReviewAssignment.inc.php => getReviewerRecommendationOptions
Simply by adding a hook before return $reviewerRecommendationOptions you could already do a lot. As I said, it is not the functionality but the naming that seems to be the question.
I haven’t worked with OJS 3 yet, but in 2.x there was a Custom Translation Plugin, that allowed customizing the translation individually by journal.
Maybe it hasn’t been ported yet to OJS 3, but it definitely is useful, not only for journals, but for any process you’d like to use OJS for that requires some kind of peer-review process-like submission…
Thanks, I actually was thinking if I could do the same thing by adding the new translations to a locale file in a custom theme. Basically a bit the same thing. But I have not had the time to test that yet.
Yes, off the top of my head a theme plugin should be able to add locale content, and theme plugins (again IIRC) are loaded early enough to supply locale keys usefully. You might find that locale keys are added before system locale keys, in which case overrides would be clobbered by built-in keys. If that’s the case, let me know and I’ll have a look and a think.
Regards,
Alec Smecher
Public Knowledge Project Team
Continuing the listing of essential features, here are a few that I think should exist (if not already). If you think I should create a new topic, please let me know. If already available, please notify me so that I can start studying the migration process as soon as possible.
Logged user list: Administrator views list of online users and allows a screen notification that system is going down for maintenance and logging off users.
System down for maintenance: Although it may be hard to implement (and I’ve asked for this a while ago), this is essential for online systems. At least, an option to shutdown access and only view templates on a temporary folder. This will prevent database access and running processes while executing an upgrade or backup, for example.
Log as user on listing pages of editorial process: I believe that this has been implemented, but not really sure. When the Editor needs to execute a task for the user, it would make it a lot faster to have the link available right from the Editorial process pages (review, submit updated version) when clicking user name, or an icon next to the name or link somewhere on the page. If possible. It would also be nice for the system to record the action as “Executed by editor EditorName”, so that there is transparency in the editorial process.
I’d suggest holding off on OJS3 feature requests until you’ve gotten used to it, and then posting feature requests in the Feature Requests area one at a time.
Regards,
Alec Smecher
Public Knowledge Project Team
Regarding the question of changing the labels of reviewer recommendations and the labels in the editor decision buttons, it seems that adding this in the locale file of a theme plugin works:
<message key="editor.submission.decision.requestRevisions">Request Minor Revisions</message>
<message key="editor.submission.decision.resubmit">Request Major Revisions</message>
<message key="reviewer.article.decision.pendingRevisions">Minor Revisions Required</message>
<message key="reviewer.article.decision.resubmitHere">Major Revisions Required</message>
However, what I could not change is the contents of the editorial history. It still says: (Resubmit for Review) for article 67 was recorded by admin .log.editor.decision
You might give the custom locale plugin a shot. It’s by the folks at the Free University of Berlin, but the link is to my fork, which contains a commit to make it compatible with both OJS and OMP. It’s a work in progress. I suspect the problem with adding locale keys to the theme plugin is that different requests will have different lifecycles and in some cases the theme plugin may not be loaded (or not at the right time).
Regards,
Alec Smecher
Public Knowledge Project Team
The order of loading has to be the issue here. I will check the plugin. I was aware of it, but it seemed like a good idea to handle this with a theme plugin for a specific journal. But it does make sense that theme plugins do not work that well for changing things in the backend.
As you know now, at the University of Bordeaux, we are preparing migration of the journals we host on OJS2 to OJS3.
I understood, the custom locale plugin isn’t provide yet with OJS3 but that we can get it from your fork.
Do you know approximatively when you will be able to provide this plugin with OJS3 ?
Thanks in advance for your answer.
Best regards.
Helene
I’m just speaking with the author of that plugin to clarify where it should live and hope to get it added to the plugin gallery shortly after that. In the meantime, if you want to get going, I’d suggest using the version from my branch.
Regards,
Alec Smecher
Public Knowledge Project Team
.