OJS Roadmap

From PKP Wiki
Revision as of 09:12, 18 April 2008 by Kstranac (Talk | contribs)

Jump to: navigation, search
OJS Roadmap
Future directions for OJS
Less linear workflow
Status: TBA
Less downloading and uploading req'd for workflow
Possibility of using a single file for all workflow and tracking changes rather than submitting new files for each stage (perhaps with drag and drop, with copies left behind for documentation)
Better support for pre-prints
Status: TBA
"In press" section for articles that are currently in holding for actual publication.
Thesis Workflow Tool
Status: TBA
OJS as a thesis submission and tracking system.
SFU Library has a project on the books to develop a more robust thesis workflow tool.
Submission as single file
Status: TBA
Submission model might be made better by including the option to make a .pdf containing the article, all supplementary files and appropriate metadata. Advantages include no need to de-identify properties, and review document is a single document - no need to download all figures, supplementary documents, etc in order to review. Of course, letter to editor and other documents not for reviewers would need to be submitted not to be included.
Miscellaneous
Status: TBA
add option to "display ISSN in sidebar" near the ISSN field in journal setup
add 'Former Journal Title' and 'Former ISSN' as repeatable fields, for journals that have changed their names and/or ISSNs once or twice or more.
announcements should display newest to oldest by default; and also allow for re-ordering by the JM
import transaction/rollback
more flexible statistics
arbitrary metadata gateway
Dspace export
support alternate stylesheet for PDA viewing
support for embedded video (youtube style)
user/article thesaurus/controlled vocabulary
user tagging
ACL:based permission classes
WYSIWYG special character handling (e.g., tinyMCE extension for latek)
"login as" behavior should be limited in certain contexts
centralized role management for plugins
featured article plugin/block
user friendly error handling/logging
local private messaging system a la phpBB
scholar's portal plugin interface (UTL)
advanced search options / interfaces (eg. zend lucene index plugin)
mobile / WML plugin (athabasca)
exporting to LAC web interface
option to make abstracts a required field for journal sections
add DOI to citations
"Advice Tool" - integrating links to publishing references directly into the interface (or in the Help files). - from Mark Weiler, email Nov 6, 2007
Allow reviewers to make additional comments after completing their review.
Allow Journal Managers to create customized email groups for sending out messages (i.e., they could create an email 'group', select the users to include, and then send to that group whenever required).
Make the CSS and/or templates editable within the web admin interface -- see WordPress as an example
Enabling specific reading tools at a section level
Submitted: Mark Weiler (mweiler@sfu.ca)
Description:
Currently, when reading tools are enabled, they are enabled for all the

issues (current, future, past) in the entire journal. Thus, the decision to enable reading tools is global (affecting all sections) and is diachronical (affecting all past/present/future) issues.

It would be useful feature if the journal manager or editor could create

sections and specify what reading tools are enabled for those particular sections and even particular issues.

With respects to the reader comments reading tool, this would allow editors

to create innovative sections. For example, a journal may want to have a section that is unique in that editorial team actively seeks readers to add comments to the articles. Or a journal that is in the practice of enabling readers to comment for all sections, may wish to create a section that does not have reader comments enabled.

There may be similar creative editorial decisions that could be made for the

other reading tools and additional reading tools that may be on the horizon.