OJS OCS OMP OHS

You are viewing the PKP Support Forum | PKP Home Wiki



OJS feature requests

OJS development discussion, enhancement requests, third-party patches and plug-ins.

Moderators: jmacgreg, btbell, michael, bdgregg, barbarah, asmecher

Forum rules
Developer Resources:

Documentation: The OJS Technical Reference and the OJS API Reference are both available from the OJS Documentation page.

Git: You can access our public Git Repository here. Comprehensive Git usage instructions are available on the wiki.

Bugzilla: You can access our Bugzilla report tracker here.

Search: You can use our Google Custom Search to search across our main website, the support forum, and Bugzilla.

Questions and discussion are welcome, but if you have a workflow or usability question you should probably post to the OJS Editorial Support and Discussion subforum; if you have a technical support question, try the OJS Technical Support subforum.

OJS feature requests

Postby eliotbates » Tue Sep 29, 2009 10:44 pm

So I've had the opportunity to spend a few hundred hours getting to know the OJS templating system from the inside as we were working on our highly customized install for Dancecult: Journal of Electronic Dance Music Studies, which just went "live" with our first issue yesterday. Basically, not a template went unedited in our quest to provide a "clean" user interface. In addition to customizing style sheets, our web developer determined that the default style handling is not IE6 friendly, and he wrote an entire separate css file in order to ensure that IE6 users have a similar experience to Firefox, Safari, Opera, and IE7-8 users.

While a certain amount of site-specific customization is understandable, there are a few classes of customizations that I believe would be extremely easy to implement, and would simplify aspects of the customization process.

  • Adding about items. Currently, in Setup step 2.5 one can add an item to the About page. Why does this item go by default under "Policies"? It would make most sense to add items under "Other," or to be able to choose where to add additional pages (People, Policies, Submissions, or Other) and to be able to add to any of those headings.
  • Customizing the navigation modules based on number of journals. The browse sidebar option has four options, three of which make sense for all installs (By Issue, By Author, By Title) and one of which makes absolutely no sense for installs of a single journal on a site (Other Journals). Likewise, the ability to remove the (My Journals) nav link for single-journal installs is important. I still have not found where these are generated in the code so that I can remove these links (although I found the text that goes in that slot in the locales file).
  • Articles inheriting nav structure and headers from main site. This will be our next customization dive, but at the moment, there doesn't appear to be an easy way to say that all HTML galleries use the same headers and nav bars as the rest of the site. I've noticed that a number of journals have hacked the article view - FirstMonday being a notable example. They have generated a table of contents in a separate frame that fits where the right nav would have otherwise fit. Interesting idea, it would be great if a variant of this was at least an available option to users without having to re-invent the wheel...
  • Checkbox: in TOC of an issue, PDF/HTML/etc. links open in new window. We modified the .tpl to make this the default behaviour, but again, some users may want a single-window experience; others (like us) believe it's a better user experience to have the article open in a new window.
  • Checkbox: abstract appears as text option (ABSTRACT). With 2.2.3, no longer does abstract appear spelled out - the title is clickable instead (which is not obvious to all users). Rather than one or the other, this as well could be a checkbox item in the Journal Setup.

I'm just focusing in this post on what I believe to be very easily implemented Journal Setup options - ones that, if implemented, would potentially minimize the need for users to delve into template files, and would improve the user interface for end-users.

Thanks,
-eliot bates
Managing Editor: Dancecult: Journal of Electronic Dance Music Studies
eliotbates
 
Posts: 12
Joined: Sat Sep 27, 2008 1:37 pm

Return to OJS Development

Who is online

Users browsing this forum: Baidu [Spider] and 2 guests