Here we go! What’s planned for 3.4
Since the release of OJS/OMP/OPS 3.3, we’ve been hard at work planning our next major release. In this post, I’ll kick off our 3.4 development cycle by sharing our plans for the next six months, including major work on email notifications, DOIs, accessibility, and code modernization.
The hardest part of planning a major release is deciding what to focus on. There are dozens of major features listed on our Roadmap and every one of them is a priority to someone in our community.
Large institutional publishers, including our own hosting services, want us to build new features to help maintain and run lots of journals. Scholarly communications librarians are eager for us to adopt new standards like CRediT or provide better support for publishing to audio and video.
We have to balance these needs against the requests we receive from our diverse community of editors, who are using our software every day to manage their editorial workflows and want us to make common tasks more easy to accomplish.
In order to decide what to focus on in 3.4, we relied on conversations with development partners, UI/UX tests and focus groups that we conducted with users, as well as feedback we received on our community forum and development repositories.
After weighing up these needs, and our own budgetary constraints, we decided to improve how we handle emails, give editorial staff better tools to manage DOIs and Crossref deposits, and advance our mission to audit and improve the accessibility of our software. Alongside this work, we’re also continuing to invest in vital code maintenance and modernization, ensuring our software is stable, performant and long-lasting.
Comprehensive improvements to sending emails
Email notifications are the heartbeat of the editorial workflow for journals, presses and preprint servers that use our software. Emails are used to solicit reviewers, request revisions, update authors, and notify copyeditors and production assistants.
Emails appear again and again in user feedback. Editors want to know what variables they can use when editing an email template (#3253), to be able to add CC and BCC recipients to any email (#743), to send emails in the recipient’s language (#3525), and to load any email template at any time when opening a discussion.
To address these requests, we’re revisiting our workflow for sending notifications and building a new UI for sending emails (#5717).
Our plan is to pilot this new UI for editor decisions and discussions in 3.4. We’ll roll it out to other workflows like review assignments in later versions.
We’re also undertaking a comprehensive audit of our email templates. Our partners from OpenAcademia, Emma Csemiczky and Veronica Svärd, are helping us make our default email messages more informative and kind, and eliminating the use of robotic or alienating language (#5730). They’re also identifying actions in our editorial workflow where we may be missing email notifications.
This is a substantial effort that requires support and coordination between our developer and UX teams alongside copyeditors, editorial staff, and system administrators in our community. We hope 3.4 will be a major step forward for authors, reviewers and editors interacting with publishers using our platform.
Managing DOIs and deposits
DOIs are simple on their surface. But in practice, it often requires trained editorial staff to ensure that DOIs are generated, minted and deposited correctly.
We support a wide variety of differences in how DOIs are generated, what kinds of published objects receive DOIs, and when they are registered and deposited. Unfortunately, this means that it can be cumbersome to generate, check and mint DOIs, with editors needing to jump across dozens of screens before publishing an issue.
With funding support from Crossref, we are consolidating our DOI management into one screen, making it easier to identify where DOIs are missing and providing quick tools to generate, mint and deposit them in bulk (#6062).
For 3.4 we are focused on depositing to Crossref. But we are building the improvements to ensure that we can easily support minting DOIs in bulk with other agencies, such as DataCite, in the future.
A better, more accessible submission wizard
With the last major version, we remediated all of the problems raised by our last accessibility audit. That audit was conducted on our default theme and addressed all parts of OJS that a reader would see.
Next, we’re tackling our submission wizard. But before we get a third-party audit, we’re going to rebuild our wizard with all of the lessons we’ve learned so far.
In the end, we hope to have a submission wizard that is more accessible, but also more configurable and user-friendly. We plan to redesign the wizard’s workflow to make it easier to toggle fields on and off, and to present the author with a preview of their submission before it’s completed.
At the moment, our UX researcher, Israel Cefrin, is conducting a benchmark analysis to see what we can learn from other systems. We plan to use that to redesign the submission wizard, conduct UX tests, and implement it in time for 3.4.
Code maintenance and modernization
This development cycle we are investing heavily in code modernization projects. We’re introducing namespacing and autoloading throughout more of the codebase (#6091, #6092), adopting major pieces of Laravel’s framework for events and job queues (#6915), and restructuring our services, DAOs and query classes to make use of strict type hints and automated code completion (#6867).
Most exciting of all, we’ve finally adopted a documented code style and implemented php-code-sniffer to automatically format our code to the PSR-12 standard (#5678). Now, whenever a commit is made to our software, it’s automatically formatted to a modern, consistent, and widely used style.
This version is shaping up to be one of our biggest leaps forward towards modernizing our code and aligning with widespread standards in the PHP community. But it is going to be a disruptive release, with lots of breaking changes.
If you deploy, maintain or customize our software, and you want to learn more about how these changes might impact you, sign up to our new mailing list for developer updates.
When will it be available?
We plan to release 3.4 in the fourth quarter of this year. We’re working hard on the major tasks and hope we won’t encounter any serious blockers. But if we do, we may need to reschedule the release or consider shifting some of this work to a later release.
We’re optimistic about our timeline for now. If you have any questions or comments about our plans, let us know on our community forum.