Major New Features in Upcoming OJS 3
As we approach the upcoming OJS 3 release (date soon to be announced), we wanted to share some of the major new features you’ll see, including editorial discussions, flexible workflows and roles, easier theming, and more. All of the critical features and functionality you expect from OJS have been included in the new release, but we are particularly excited about these new additions. We have been listening to your suggestions for improvements to OJS and hope you will see them reflected here. Let us know what you think!
To help track the communications that are a critical part of a submission’s workflow, we’ve built a new internal discussion feature for each editorial stage (Submission, Review, Copyediting, Production). Discussions work much like an online forum — a user creates a discussion topic, invites others to participate, and sends a message (including with attachments):
Anyone involved with the submission can be included in a discussion (the editor, section editors, authors, copyeditors, etc.). Recipients receive an email notification to inform them of the new message. Replies happen just like in a blog comment or forum post:
OJS 3 consists of 4 editorial stages: Submission, where new submissions are dealt with (rejected, assigned to section editors, etc.); Review, where peer review and author revisions take place; Copyediting, where the reviewed and revised files are sent for copyediting; and Production, where the final, copyedited version is converted into publishable formats (PDF, HTML, etc.), proofread, and scheduled for publication.
To increase editorial flexibility, you can easily move a submission from one stage to another without completing any of the possible tasks on that stage. You don’t do copyediting? No problem, just skip it with the Send to Production button.
Our aim is to make OJS 3 flexible enough to fit just about any workflow. While we will continue to outline steps similar to what you currently see in OJS 2 in our documentation and online courses, you can easily follow your own path through the editorial workflow.
In addition to making the workflow more flexible, you can now easily change the names of existing roles. If you’d rather have Production Managers rather than Journal Managers, you can simply rename that role.
As well, if you want to create a new role, you can do that to. OJS 3 let’s you make up any role you wish, and associate with any (or all) stages of the workflow.
You can also set them to have similar permissions to existing roles, such as authors, reviewers, section editors, etc. For example, if you create a new Editor-in-Chief role, you could give that role access to all 4 editorial stages, and the same permissions as editors and journal managers (the ability to do anything with the journal settings and anything with submissions).
Flexible Task Access
A common annoyance with OJS 2 was the need to switch roles to do different tasks. For example, if you were a user enrolled as both a Journal Manager and an Editor, you had access to both the submissions as well as the journal settings. However, if you were in the middle of editing a submission, but realized you needed to tweak a setting on the web site, you needed to go to your user home page, select your role as Journal Manager, go to the Journal Manager home page, and then select the appropriate setting. In OJS 3, if you are logged in as a user with permission to access both the submissions and the journal settings, you no longer need to make that complicated switch. The settings are simply available in the left sidebar.
In OJS 2, authors can submit a single “main” file (typically the article manuscript) and then other “supplementary” files that are handled differently. In OJS 3, the author can now upload an unlimited number of main files (article manuscript, images, tables, data sets, etc.), using the Add Another File option.
Our aim here is to reduce the artificially imposed distinction between the article manuscript and any other files. For example, images of figures are central to the manuscript and should have the option of being treated as part of the main submission.
In addition to making the workflow more customizable, we have also tried to make the user interface more flexible. In OJS 2, creating a new theme was often a challenge due to the extensive number of style sheets that needed to be modified. To reduce this burden, we have separated the style sheets and underlying templates for the administrative interface and the reader interface.
This brings two benefits: first, users who work with multiple OJS 3 journals (e.g., as an editor for one, an author for another, and reviewer for a third) will always have the same user experience in the administrative interface — it will always look the same on the inside; second, separating out the reader interface templates and style sheets means that they will be significantly smaller and easier to modify.
We are hoping to see a wider range of themes develop for OJS 3, as these will be simpler to create and implement. Although OJS 3 will ship with only a basic theme, we are working with a graphic designer to develop some additional themes to share.
At our most recent sprint, work was done to allow you to easily upload an existing bootstrap theme to OJS 3. This is still a work in progress, but shows a great deal of promise for making your journal look unique and polished. This may make it into the OJS 3.0 release, or may not be available until 3.0.1 later this year. You can read more about it on our PKP News Blog.
Lack of responsiveness (the ability of the journal’s web page to adjust to the reader’s screen size — from a phone to a desktop computer) was a major issue for OJS 2. As part of the theming enhancement described above, the OJS 3 reader interface will be fully responsive.
One final change worth mentioning is the simplification of registration in OJS 3. We received much feedback that OJS 2 required too many fields, even if they were optional, and this often deterred prospective authors or reviewers from signing on.
To help, we’ve prioritized a small set of required fields on a single screen (e.g., name, affiliation, email, etc.), and allow the registration to proceed once those few are completed.
The new user can then proceed directly to make a submission or accept a review request. She has the option to fill in a more complete profile if she wishes, or can be asked by the editor to fill in details at a later point (such as upon acceptance of her submission).
OJS 3.0 contains a lot of new concepts and code, so it’s important to plan your migration from OJS 2.x to OJS 3.x in a way that doesn’t disrupt your publication schedule overmuch. Additionally, some features that are available in OJS 2.x will not be immediately available in OJS 3.0, such as subscription-based access. Most of these features will follow in later releases according to community interest; please feel free to inquire about details on our community forum.
OJS 3.0 will include migration tools to upgrade your OJS 2.4.x installation, preserving all content and workflow details. We recommend performing a test upgrade and exploring the new version of the system before performing a production upgrade.
OJS 3.0 will perform best for open-access publications with small to medium-sized amounts of content. As the new codebase matures we will improve its performance with larger collections and high traffic volumes.
We will continue to maintain OJS 2.4.x for a considerable period of time to allow users to migrate at their own pace.
We hope this brief overview of some of the significant changes in OJS 3 gives you a sense of how we’ve tried to respond to several years of user feedback and the results of our usability testing. Let us know what you think.
Stay tuned for an announcement of the official release date of OJS 3 in the next couple of days!