Feature Request: article ranking / alternative ordering

[Jonathan.Kaplan]

I'm one of the editors of a new journal. We're planning to use OJS, and are wondering whether there are any plans for developing the following sort of feature.

What we'd like is a feature that would permit registered users to "rate" the articles (on, say, a 1-5 point scale, or something like that), and then would permit readers to display the articles in order of their average user-rating. On a related topic, it would be nice if readers could display a list of the published articles by number of down-loads.

I've searched the Discussion and Support forums for any mention of anything like these, and not found any, but if I'm missing something obvious I apologize.

Thank you for your time.

Jonathan Kaplan

[jmacgreg]

Hi Jonathan,

We don't currently have any plans for an article ranking mechanism, but that's not to say we wouldn't develop it if there was enough interest. Alternatively, if your group has any development expertise on hand, we are more than happy to assist in creating a plugin.

We're currently working on developing software roadmaps so that users can see what we have planned down the pipe; a rough one for OJS can be seen here: http://pkp.sfu.ca/wiki/index.php/OJS. There are a few feature requests there that may be of particular interest to you, including Article of the Day; tag clouds for submission keywords; list most searched-for words; etc.

Cheers,
James

[davidmaymudes]

James, I'm a programmer friend of Jonathan, I was taking a look on his behalf to see how complicated adding this feature would be.

The main question I have at the moment is about whether this can be done as a plugin, or whether it would be more straightforward to do as a patch to the main codebase...

To keep track of the rating of an article, or the number of downloads for an article, it seems like the obvious thing to do is to add an extra column to the "articles" table , but I presume that would require changes to ojs_schema.xml and ArticleDAO.inc.php, and thus couldn't be done in a plugin, right? (actually, I suppose perhaps the "published_articles" table would be more appropriate, and it already includes a "views" column, though I'm not sure exactly what it's counting.)

It looks like plugins can create their own separate tables, so one could presumably instead have a "published_article_extra_stuff" table rather than changing the main table, but that seems clunky.

One option would be to add the database columns to the main codebase, but then do the rest of the UI for the "rating" feature as a plugin so it would be easy to turn on or off...

Anyway, at this point I'm just trying to understand how things are done in your project; apologies if I'm not making enough sense!

--David

[mcrider]

Hi all,

Though it would likely be easier just to hack OJS in this case, I would suggest making this a generic plugin, as it will ease upgrading, and will more easily allow you to share your work with the community (and I think this is a good idea that deserves to be shared!)

Secondly, It would be better to give the plugin its own table, both for database consistency, and as you say, it would require changing a lot of code just to add the ratings/visits as attributes to the published_articles table. Look at the plugins/generic/thesis plugin for an example of a plugin that creates its own table. Also, I would suggest looking at the OJS technical reference (http://pkp.sfu.ca/ojs/OJSTechnicalReference.pdf) for more information, esp. the chapter on plugin development.

Let us know how it goes and if you need any help...

Cheers,
Matt

[asmecher]

Hi all,

Just to add to Matt's comments --

Another option that wouldn't involve modifying the database schema would be to use the article_settings table. This is intended to provide a way to extend the built-in set of metadata without needing to change the database schema. Have a look at the updateSetting and getSetting functions in the article class. (Of course, you'll need to consider concurrency, as you won't be able to atomically increment a counter unless you write a new database query to do it -- but that may not be crucial.)

One thing that may be tricky with a plugin-based approach is modifying the user interface to include the new information where you want it. I'd suggest deciding where the new information should go, then seeing whether or not a plugin would be able to easily place it there.

The "views" column in published_articles counts the number of times the abstract for that article has been viewed. (There's a similar count in the article_galleys table for the number of times each fulltext format has been viewed.)

Regards,
Alec Smecher
Public Knowledge Project Team