How to improve OJS: a reader’s perspective

Open Journal Systems is a free and open source software package for journal publishing. It’s probably the most widely-deployed platform for publishing open access journals; at least 2,000 journals use OJS. As such, it’s critical infrastructure for the OA movement: authors’, editors’, referees’, publishers’, and readers’ impression of OJS has a big impact on their impression of OA.

I haven’t used OJS as an author, editor, referee, publisher, nor as a sysadmin, but I have used it as a reader. It’s generally very usable, although there are a few areas, mostly related to current awareness, where some simple tweaks to the defaults would make things easier.

  • Make subscribing easier and more obvious. When you visit an OJS using a standard theme, there’s no big button that says “subscribe” or a similar term. Instead, there are two options that lead down that path: “Register” and “For Readers”.

    The “For Readers” page, by default, directs readers to register to receive the table of contents of new issues via email. The “Register” page, by default, requires you to create a username and password, fill out a captcha, and give your full name in addition to your email address. It also asks, optionally, for your gender, mailing address, and other information. That’s a lot of effort just to get an email when new issues are released.

    There’s a reason: OJS uses the same page to register authors and reviewers — situations where more information than just an email address is required. There may be a bit of wishful thinking here, too: the hope of converting readers into authors and reviewers. But let’s cross that bridge when we come to it. For now, let’s just get people on the mailing list. This is a tenant of Web design (and publicity generally): convert one visit into future contacts. That’s why started with a splash page which asked for one thing: your email address.

    A journal should make a prominent pitch for visitors to subscribe before they navigate away from the page and forget about the journal. More subscribers leads to more readers, which leads to more authors and referees and commentary.

    The OJS default themes should include a sidebar section that says “Enter your email to receive free announcements when a new issue is released”. It should ask for only an email address. (The confirmation email can ask subscribers to register a username, if desired.)

  • RSS feeds by default. OJS includes a plugin to produce RSS feeds, but it doesn’t appear to be on by default; many OJS journals don’t offer RSS feeds. See above comments about the importance of turning visitors into subscribers.
  • OpenID support. With 2,000 OJS journals floating around, it seems a bit silly to have to create an account at each one, doesn’t it? OpenID would give users a single login not only across other OJS journals, but any site supporting OpenID. Good news, though: OpenID support is in the OJS roadmap.

As a closing comment, I’ll point out that OJS is under active development and progressing quickly. I was going to make a comment on how feed display is ugly, based on Open Medicine as an example, but I thought I ought to check the versions first, to make sure the problem hadn’t been resolved. Sure enough, Open Medicine is using OJS 2.1.1; the release notes of more recent versions mention improvements to feed handling, so this may have been fixed already.

This entry was posted in FOSS, Open access. Bookmark the permalink.

4 Responses to How to improve OJS: a reader’s perspective

  1. Hi Gavin,

    Many thanks for this blog post: the points you raise are cogent, and clear. I work for the PKP, the developers of OJS et. al: we’ve discussed this post, and generally agree that your points fit into our larger future plans. I’ll address your points one by one:

    * Making Subscribing more obvious: we’ve identified subscription and registration support, as well as notification support, as areas in need of improvement, and we’ve made some strides forward: see specifically (which includes some comments I’d gleaned from this post a couple of months ago), and also subscription bug reports in general:

    In a nutshell, we agree 100% that signing up for notifications, or registering, or subscribing (OJS distinguishes between the two) should be doable with as few clicks as possible; and should also be a front-and-center option, if enabled. Some of these changes may be present in OJS 2.2.3 (which will be released in the very near future), but I believe most are flagged against 2.3 (which should be released in July).

    * RSS Feeds by default: Agreed: see RSS feeds should be enabled by default from OJS 2.2.3 onwards.

    * OpenID Support: Agreed, conditionally. We’ve flagged OpenID support as something we want to implement (see and we’ve had some very interesting discussions on other topics notionally surrounding OpenID support (and better support for social networking sites, etc.). Some of the points are addressed in that bug report. Incidentally, I’ve refactored the OJS roadmap and have taken the specific OpenID support reference out; but rest assured, we do plan on implementing it.

    The scenario that you mention, whereby users could log in to any OpenID-enabled OJS instance and presumably proceed with either submitting a manuscript; or (especially!) join in a discussion on the journal’s content, becomes not only interesting but important to us. Discussion in this vein has also been spurred on by We haven’t mapped out exactly where we’re going in this regard, but at the very least we do want OJS’ commenting function to be more useful (not to mention visible:, and tied in with OpenID support.

    Again, thanks for your comments so far; they’ve been extremely helpful for us, and we’d love to hear more, either at pkp-support at sfu dot ca, or continuing on this post. Now that I’ve used my own OpenID to log in and comment on your site, I’ll also subscribe to your RSS feed as well. :D


  2. Gavin Baker says:

    James, thanks for reading and for your comments. And, of course, thanks for the great work that you and the OJS team do! I’m very glad you found my post useful.

    It’s great to hear that RSS feeds will be on by default in the next release. I suspect this will help boost readership for journals who hadn’t thought to turn on the feeds or weren’t aware it was an option — both directly, via return visits from readers, and indirectly via better inclusion in indexing and current-awareness services like ticTOCs. (I’m glad to see another bug for ticTOCs support.)

    I’m also glad to hear that you’ll make signing up for notifications easier and more prominent in an upcoming release. In my mind, I see this as something like a well-placed box: “Sign up for free alerts for new issues: * via RSS * via email: [textbox].”

    I do think OpenID support would be helpful for authors and referees, to let them avoid registering on several different journals. It’s even more important if you have a comment section, as you say. I do hope you can add support soon. As a note, I meant only that OJS should support OpenID as a service provider, not as an identity provider. The latter might be useful as well (if you’ve registered on one OJS site, you can use it to log in at any other), but they don’t have to come bundled; identity provider service could be added at some later date.

  3. Gavin Baker says:

    James, while I’m thinking about it and while I’ve got your attention, let me throw another few ideas your way.

    Upgrades: A great many OJS installs I find across the Web aren’t using the latest version. What can you do to help keep more installs up-to-date? One suggestion: Add some text on the downloads page, very near to the download links, that says “Please subscribe to release notifications so you will be alerted to future versions or security fixes”, which points to an email list (and, optionally, RSS feed) for those announcements. Another suggestion, if you don’t do it already: Add a call in the admin section to the OJS server to check for the latest version and notify the user if the installed version is outdated. (For instance, WordPress does this.)

    Downloads: What about offering a checksum (e.g. MD5), and/or GPG signing files, so users can verify the integrity of a file before installing it?

    Supporting serendipity/browsing: Some way to display links from an individual article to other articles in the same journal would make for a richer experience, I think. It could be as simple as displaying the titles of other articles in the same issue in the sidebar. Or it could be more complex: other articles in this journal by the same author, other articles in this journal with similar keywords, “readers who read this article also read…”, most popular articles in the journal, etc.

    Multilingual support: It seems a number of journals publish at some of their content in more than one language (e.g. offering translated abstracts and/or keywords). As far as I can tell, it’s all just treated as text at this point. Finding some way to mark this up (e.g. using the lang attribute in HTML) might enable some interesting uses down the road.

  4. Hi Gavin,

    Thanks for the further comments! Here’s a response digest of sorts from the team:

    Upgrades: We’ll be refining the way we handle notifications etc. on our website shortly. We’ll be adding a “Stay Informed” button/subpage to the top, which will include the option to sign up for a low-volume release/security mailing list; a blog RSS feed option (we announce releases on the blog); among a couple of other options. We’ll also be adding this info to the post-install page:

    Downloads/checksums: We likely won’t implement this. Concerned users can validate the source code they download from our website against that found in CVS, and there’s only one point of release for our code: our website. If we were to start offering downloads elsewhere we’d consider it, but I doubt that we will start doing so in the near future.

    Supporting serendipity/browsing: these are great ideas, and suitable for individual plugins. A lot of them may actually make more sense in the Harvester or multijournal site vs. an individual journal, and some may be fairly niche and not likely to be taken on by us specifically unless there’s a great demand. We’ve been tracking plugin suggestions at, and I’ll be happy to chop these up and add them to the list.

    (An aside: we’ve just recently opened the wiki for registration and public editing, but haven’t as of yet opened editing to non-registered users. We plan to do so, but we want to make sure we don’t get clobbered by spam first. In the meantime, please feel free to register and edit as you see fit!)

    Multilingual support: I think your point regarding the lang attribute has been addressed in CVS, although I don’t know if OJS 2.2.3 will include the changes, or if they will only make it into 2.3. We’ve also started up a request for input re: multilingual support on the forum:

    Anyway, I think that’s about it for now. Any further suggestions always welcome, and thanks again for these!


Leave a Reply