Here we go! What’s planned for 3.4

April 28th, 2021 by  | Comments Off on 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.

Setting priorities

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).

A mockup of how the new discussion workflow might be improved in 3.4.

A mockup of how the new discussion workflow might be improved in 3.4.

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.

A screenshot showing the changes made to our acceptance email.

The new email messages will help authors understand what they can expect to happen next.

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).

A screenshot of the new DOI management screen

Manage all of a journal’s DOIs in one place.

 

A screenshot of the tool to deposit DOIs in bulk

Bulk actions to deposit all unregistered DOIs at once.

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.

A screenshot of the code formatting commit showing more than 150,000 lines of code changed.

More than 150,000 lines of code were modified in the pkp-lib repository alone!

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.

Tags: , , ,

Comments are closed.