As the developers of Open Journal Systems, Open Conference Systems, Open Harvester Systems, and Open Monograph Press, the PKP team are experts in helping journal managers and conference organizers make the most of their online publishing projects. PKP Publishing Services offers support for:

As a customer of PKP Publishing Services, you will not only receive direct, personalized support from the PKP Development Team, but will be contributing to the ongoing development of the PKP applications. All funds raised by PKP Publishing Services go directly toward enhancing our free, open source software. For more information, please contact us.

1. Search the forum. You can do this from the Advanced Search Page or from our Google Custom Search, which will search the entire PKP site. If you are encountering an error, we especially recommend searching the forum for said error.

2. Check the FAQ to see if your question or error has already been resolved.

3. Post a question, but please, only after trying the above two solutions. If it's a workflow or usability question you should probably post to the OJS Editorial Support and Discussion subforum; if you have a development question, try the OJS Development subforum.

- create an option to switch of all this "blind review" nonsense. not all journals use blind reviews!
- our journal works with days or hours as turnaround time, not weeks. why are "weeks" displayed in the overview table, not days?
- years missing from dates in overview tables: we have a history of 9 years, and not displaying the year but only month and day is a nightmare
- decisions/ratings should be displayed in the overview tables (ms queue)?
- different email templates for different recommendations!
- customize recommendations!
- assignment of a new editor a very timeconsuming and awkward process. rather than just filling in name and email address and the click a button to assign a new reviewer, i have to create a new username (with >16000 users in the database it takes me 5 attempts to guess a new username which is not already used - why is the system not able to create a new username itself??), then go back to the reviewer list, search for the newly created reviewer, and then assign it. usabilty, usability, usability ! VERY annoying process!

and so on and so on... i had so hoped that all these annoying usability issues would be fixed in OJS 2.x ...

Another flaw of OJS 2.x is that there doesn't seem an easy way for the editor to see in the "Submissions in Review" view whether an author has uploaded a revision, or to filter the manuscripts only showing those where his action or an editorial review is required (submitted but no reviewers assigned, reviews in but no decision yet, revision submitted but no editorial decision made, etc.). In our journal I have at any time between 30 and 100 manuscripts in the "Submissions in Review" queue - still really difficult with OJS to keep an overview of where editorial action is needed.

Date formats can be customized in config.inc.php. The month-day format, for example, is the configured default for the date_format_trunc setting. See http://php.net/strftime for the possible tokens that can be used.

Some of the issues you point out are fairly specific to your situation, i.e. short turn-around time, frequent creation of new user accounts in a large database, etc., and they are probably best fine-tuned via customizations to OJS. We constantly struggle to find a balance between flexibility and simplicity -- if we incorporate options for every variant, the user interface will become unwieldy and the codebase will become unmanageable. These forums also serve as a developer exchange, and I'm happy to help with customizations.

while we are at it, in a future version, please provide a structured way for the reviewer to
- suggest other reviewers (email adr/name), if he declines, with a one-click possibility for the editor to assign these suggestions to the ms
- agree or disagree (radio button) with doing a rereview of the manuscript, when he submits his review.

We also had to customize our system to include reviewer-suggestions by the author.

Thanks for this.
However, allow me to disagree.
Usability issues are NOT a specific requirement for my journal. If the process "assigning a new reviewer" requires three different steps (create a new reviewer, create a new userid, go to the reviewer database to find the reviewer), which should in theory only require a single step (enter the new reviewer information, all other steps are done by the system automatically in the background), then this is NOT specific to my journal.

I am in the permanent business of having to give tech support to authors and reviewers etc because of the many, many usability issues which have not been taken into account during development. Most of these are not rocket science but really simple to address and to avoid. IF YOU HAVE SOME FUNDING LEFT, PLEASE PLEASE HIRE A USABILITY ENGINEER TO DO A SIMPLE HEURISTIC USABILITY ANALYSIS.
Alternatively I invite you do work as a managing editor for 1 week in my editorial office to get a feel for the issues higher-volume journals face.

OJS should be scalable, but at the moment it is still really only suitable for microjournals with few submissions.

In the last 24 hours alone, I had already authors who accidentally did not upload their supplementary files because they press the "continue" button before they press the upload button, reviewers forget to click the "submit" button because it is counterintuitive having to press yet another button after already uploading the comments (why isn't the "recommendation" drop-down list simply in the window with the comments textboxes?), etc etc etc. The list is longer than I can document.

What is "journal-specific" is merely the fact that I am dealing with an extraordinary number of manuscripts, and even more reviewers (we assign 4 reviewers to each manuscript. If one step - such as assigning a new reviewer - takes 5 minutes instead of 1 minute (would be possible with a better algorithm), and I have to do this 10 times a day, I have spent 50 minutes for a task that could have been done in 10 minutes.

Where other editors may get only 1-2 emails from authors or readers who have problems, I am getting 3-5 per day.

That's a LOT of wasted time.

Low-volume journals with one submission per month may not be bothered by these problems, but OJS is (still) not really recommendable for high-turnover journals (and my journal is still small compared to larger journals with >1000 submissions per year).

Don't get me wrong, I have the utmost respect for the OJS development team, and OJS2 seems very well engineered. However, I still wish you had a usability engineer (or at least somebody with an eye for usability) on your team.

And as I said elsewhere, the issue of not being able to load email templates into the decision emails to the author, as well as the issue of providing wrong status information to the author, ... i don't know what to say about that, but it almost makes me want to change back to OJS1.

asmecher wrote:Hi Gunther,

Some points on your suggestions:

Date formats can be customized in config.inc.php. The month-day format, for example, is the configured default for the date_format_trunc setting. See http://php.net/strftime for the possible tokens that can be used.

Some of the issues you point out are fairly specific to your situation, i.e. short turn-around time, frequent creation of new user accounts in a large database, etc., and they are probably best fine-tuned via customizations to OJS. We constantly struggle to find a balance between flexibility and simplicity -- if we incorporate options for every variant, the user interface will become unwieldy and the codebase will become unmanageable. These forums also serve as a developer exchange, and I'm happy to help with customizations.

The one-step login URL for reviewers is a big improvement, but another suggestion for a future version of OJS would be to allow for separate URLs in the reviewer invitation emails (as is standard in many other ms management systems) which would allow reviewers to accept or decline a review invitation with a single click. This would greatly improve the response rate from reviewers.
Or am I missing something and this is already possible in the current version?
Speaking of which, where can I find a list of variables which are allowed in email templates?