By guckie on

I'm no programmer... *sigh*...

But I think this module idea could be useful to a great many Drupal community members - so I'm throwing it out to the Drupal community for feedback and offering a bounty (which I've personally kicked off with $300 USD).

Donations to increase the bounty can be made via donorge.org here and donation progress can be monitored here.

This module would be an enhanced hybrid of the existing Node Vote and Hall of Fame modules. Its objective would be to provide comprehensive node-scoring and user-performance-recognition mechanisms. Intended usage could include various online “artistry circles” whose primary purpose is to provide peer review and feedback among authors/creators. (Examples: writing circles, photography circles, music circles, etc.) This module could probably easily be extended to a multitude of applications.

I've done my best to draft design specifications which you can review here.

Drupal consumers:

Please feel free to contribute suggestions regarding my design draft for this module! And please step up and make a donation if you believe this module would be useful for your site!

Drupal developers:

I have a hunch that several of you out there already have partial code for this idea already laying around!

I realize that my initial donation is just a drop (or a drupal) in the bucket... If you are interested in developing this, please contact me with your requirements/cost estimate so I can convert this thread to a Reverse Bounty! [ pam .at. web-function .dot. com ]

Suggestions and help are appreciated!

Thanks,
~ Guckie

Comments

robertdouglass’s picture

robertdouglass commented

I look forward to watching your success :-)

- Robert Douglass

-----
My sites: HornRoller.com, RobsHouse.net

jasonwhat’s picture

jasonwhat commented

Thanks for jump starting this. I'm curious how this migh relate to the user points module and api developed already.

guckie’s picture

guckie commented

Hey Jason,

I looked at how user points are tied to node vote currently. It looks like a tie-in could probably be arranged with this proposed module, though from what I can tell, it will need to be done mostly from within the userpoints.module. (There would also need to be a couple of lines of code included in this Peer Review module.)

I'll make a note in the ongoing design draft referenced in my initial post.

Once this module is developed, I think we could try submitting a patch for the userpoints.module to include point assignments.

andre75’s picture

andre75 commented

Very interesting. Would be nice to have the capability to convert node vote tables.

nevets’s picture

nevets commented

I am working on a bid that includes many of the features you outline. The one major difference is labels would be set soley by the admin based on taxonomy term and the scoring code be enabled/disable based on content type. In this system all nodes using the same taxonomy term would use the same labels. In this system instead of have just a term called poetry, there would be a term called poerty with childen like 'metered poerty', etc.

One challange with the approach you have outlined if you include the ability to define lables by taxonomy term is that when a node is created by a user the taxonomy term is not know. Two ways to handle this are using ajax (picking a term changes the list of choices) or have have the user pick the terms after saving the content (more then one approach to this).

Something to consider, in the case the content has been voted on, can the user change the taxonomy term and/or the labels?

guckie’s picture

guckie commented

@robert:

Thank you! Fruition will be a fantastic reward here! Appreciate your support. :-)

@jason:

You're welcome! Good point there! I haven't wrapped my head around drupal programming concepts yet (or programming in general really)... but just guessing based on my nutshell understanding, I'll bet "where there's an API, there's a way".

Since I'm fairly adept at looking at projects like this from a 'features-desired point of view', I'll be happy to toy around with the user points module on Wednesday or Thursday, at latest.. then revise the design draft I've posted here to include options to bump the user's (submitter's) points according to high-scoring submissions. (Also to bump the voter's points for voting... and whatever else I notice.)

When we achieve something we would (as a group of interested parties) consider a near-final design plan, then let's give it a fierce combing-over for technical feasibility (I'll have to stay on the sidelines for that.. LOL), make adjustments as necessary, then finalize. Between now and completion, I'm sure we'll think of (and receive suggestions for) more great ideas like the ones already flowing here! :-)

@andre:

Another good point! How to handle integration with sites already using Node Vote and/or Hall of Fame?...

Here's my first thought about actually converting the Node Vote tables... I'm not sure how well the average of a singular 1-thru-10 ranking will import into an aggregate-ranking model from a calculations standpoint... (math wizzes, help me out here?) If, mathematically, it results in a fair and equitable carryover (for the users being ranked) then I don't see why it couldn't be accomplished. This is good food for thought.

If for some reason that doesn't work out... what about this as an alternative?

Leaving the Node Vote table intact and disable the Node Vote module on the conditions that:

the Peer Review module would check to see if values correlating to a node exist in the Node Vote table and if so, present them in a different table view below the node content (& cancel the display of the new rating schema - for that node)

perhaps the Peer Review module could also produce a message to users that the singular voting format is now obsolete

I'm sure you see where I'm going with that... we may have a couple of options here... either convert the node vote table OR "grandfather" the node-vote ranked nodes and let them coexist happily alongside the nodes in the new ranking system?

Andre, I think you've "stumped the chump". I'm at a loss for much of an answer to your question, at this time. (And yet I've typed sooo many wordssss!)

@nevets: Hooray! Thanks for letting us know about your similar work! What a great opportunity for idea-exchange!

I think we have two neat parallel ideas for associating criteria with nodes.

I believe I stated something in a confusing manner in the design draft. I didn't actually envision tying criteria sets to terms. Instead admin would define one array of labels (global) to include ranking Elements applicable to all terms. (What I did suggest tying to terms, however, is the scoring mechanism itself - the options to score & be scored.)

Let's say a site administrator comes up with 8 elements for scoring 'metered poetry', 6 elements for scoring 'free verse' poetry, and 7 elements for scoring 'short stories'. Admin would define one array of 21 elements and specify in settings that users being scored should select exactly 5 elements on which to be rated. (I know this is a really simplified number of terms!)

An obvious downside to this is that a user has to look at some extraneous scoring elements when choosing the criteria set they want to be scored on.

It could be taken as a positive or a negative that users submitting to a particular term would all be scored on the same number of elements, but the actual list of elements used in scoring would be able to fluctuate from node to node and user to user, even within that given term.

Plus sides to this might be:

Sometimes Elements are cross-compatible between genres (categories, or terms) of art. In this scenario, more power is given to the submitter to choose what he/she wants to be scored on, as well as what he/she feels is relevant to a specific submission.

Also, since Element label options are global in this model, moving a submission from term to term shouldn't impact the labels (criteria set) the user chose at time of node creation. (And to answer your question, I think Element labels should not be changeable - on a node - once voting has started.)

Now that I see your method for creating criteria sets, I think there is a different type of power/flexibility in each model.

In your model, specifying elements per term in taxonomic fashion provides for tight uniformity within categories of submissions.

I have a couple of questions of you in order to help those following this thread to draw some comparisions.

Would admin be required to define the same number of elements in a set for each and every term? Or would # of elements in a criteria set vary between terms?

Could this module be developed with BOTH models of criteria-definition coexisting? (i.e. Admin specifies in settings >> peerreview whether to use 'global' elements or 'term-based element sets') Just a curiosity, since I think both models have strong points to them.

Thanks again for getting into the conversation here! As specifications are nearer to being ironed out as a group, do feel free to evaluate the work involved and speak up for Reverse Bounty!

@everyone:

I'm elated to have this much interest surface for this module idea already! Thanks to all for chipping in good suggestions! Keep up the great discussion & don't hesitate to debate the merits of any suggestions or ideas I toss out here - diverse views and insights are welcome!

andre75’s picture

andre75 commented

Andre, I think you've "stumped the chump". I'm at a loss for much of an answer to your question, at this time. (And yet I've typed sooo many wordssss!)

I am very much in favor of keeping things small. My site already uses too many modules that make me dread the upgrade to Drupal 4.7. Also I would like to keep the number of database queries and the memory usage minimal. That is why I am against keeping nodevode intact.
It does not matter if the model for conversion is accurate (who would notice anyways).
A simple mathematical model can be deduced easily. I guess the main problem is that each site is different, meaning the importance of nodevode content is. A parameterized conversion would be best.

Andre

-------------------------------------------------
http://www.opentravelinfo.com
http://www.aguntherphotography.com

guckie’s picture

guckie commented

...keeping it simple.

I guess the main problem is that each site is different, meaning the importance of nodevode content is.

True. To make a valuable contribution into the Drupal community, this module should be designed to meet as many universal needs as possible (which is why I'm not at all opposed to your suggestion to incorporate a conversion method - and your points are well taken). Some site admins will place more importance on nodevote information more than others. And fresh installations of drupal 4.7 sites may not even have a nodevote table.

Conversion opens up quite a few questions, not all of them answerable at this time because it's not yet solidified how the Element label structuring will go... but here are a few considerations:

First of all... should a conversion approach aknowledge the "subjective value" of a singular 1-thru-10 rating? What does it mean in your own mind when you place a singular 1-thru-10 vote on a piece of art? Your 1-thru-10 vote essentially represents your overall mood about that piece of art after having viewed it (and interpreted it according to your own private set of elements, formulated in your own mind, and based on your personal taste as well as knowledge of that genre of art). If "subjective value" of a singular 1-thru-10 rating is to be considered, then in a new Peer Review system, results stored in the old Node Vote table could be ported into a fixed (and required) label in the new system called "Overall Impression", or something similar.

Now, maybe we don't account for subjectivity at all... and go with strictly a raw numeric conversion formula... then what do you envision?

Would "old" nodes show votes for only one label, wheras nodes created under the new system would show votes for {$n} labels (however many admin configured)?

Or do we mathematically pad results into however many remaining labels there are to fill in the new system? (Using a parametric equation, as you mentioned)

How do you account for a node that has, say, 47 votes in the old system (for ONE label).. now it can continue being scored by new voters on, say, 5 labels? How would you weight those prior votes, since they only applied to one element previously?

Would you allow content that had been singularly voted to be eligible for the automated Hall of Fame selection process under the new system?

These are just some example questions. I'm not trying to play devil's advocate here because I LIKE your suggestion on providing a conversion path. I'm only trying to arrive at some clarity as to how you would like to see this applied to your site/circumstances. Would you mind elaborating on your conversion wishes with a few more details? Would you be willing to document (at least an overview of) how the conversion method(s) should work in terms of impact to the admin/user/voter interfaces? I think this project would benefit from having such a plan, and yet I am probably not a good candidate to attempt it.

guckie’s picture

guckie commented

Sorry, but I am withdrawing this bounty offer while I am the sole contributor on it. I've elected to proceed with a different CMS application altogether.

Congratulations on the impending release of 4.7 & best wishes to the Drupal community!

jasonwhat’s picture

jasonwhat commented

What system are you going with?

eaton’s picture

eaton commented

I'd just noticed your post after a week or so working on other projects. Even if the bounty has been taken down, please --keep the information you put together about the specs! Post it to this thread, by all means. :)

I've been trying to jump-start a generalized 'voting/scoring API' for drupal, and this sort of application is one of the things it would be good for once it's completed (knock on wood). Looking at the requirements you put together could certainly help see what a real world scenerio would need.

--
Jeff Eaton | Click Here To Find Out Why Drupal "Sucks"

--
Eaton — Partner at Autogram

guckie’s picture

guckie commented

Hey Jeff,

Sure, no prob! I struck donation information and put the docs back up online here.

My biggest concern with what I outlined is that the scoring criteria sets are completely node-specific - when, for db reasons, it may be much better to go with criteria sets tagged to vocab/terms. My aim was to highly cater to the user (members) of a community site (with the flexibility for them to choose their scoring elements).. other admins/webmasters might not want to be so generous with the server resources.

Anyway, it's back up where it can be seen.

Glad to hear you'll be working toward an API - sounds good!

*smile*

eaton’s picture

eaton commented

Thanks for putting the information back up! Figuring out how to best handle multi-criteria votes is actually one of the specific design questions being hashed out for the voting API. I'm taking a look at the details of your proposed system and trying to see how it might be implemented.

One idea that I've been tossing around is using a slightly less efficient voting mechanism (one that stores a separate vote record for each criteria, for example) then uses a nightly cron hook to collect those 'inefficient' votes and consolidate them into an official 'daily score' for the node type.

--
Jeff Eaton | Click Here To Find Out Why Drupal "Sucks"

--
Eaton — Partner at Autogram

kbahey’s picture

kbahey commented

Sorry I came in late to the discussion. I am the author of Node Vote.

Too bad to hear that you decided against using Drupal.

For the sake of completeness, and for others who may want a Drupal solution, here is what I would do:

The assumption is that this is an academic setting with papers being submitted by some people, and reviewed by others.

1. Install Node Vote.

2. Create a role called "reviewer"

3. Assign voting to only the reviewer role.

4. Enable upload module, so submitters can attach a OpenOffice/PDF/Word attachment of their paper.

5. Reviewers read the paper then vote on the node

All the above is doable using the standard node vote.

Now, for evaluating a user's submissions, we can have a PHP snippet that joins the nodevote table with the node table, and the users table for a particular user. Then we can list all the submissions of that user with the number of votes each got, and the average vote for each.

We can do a summary for the user without listing the individual nodes, and that becomes the user's "rating" (the aggregate of what people think of his work).

If you want that with taxonomy, then we do a similar join with the term_nodes, then evaluate by terms.

We can even have a cron hook that updates the user "ratings" depending on the above joins or some other variant.
These are just a few ideas to do this with node vote.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba