In the past few weeks I've noticed some innovative new solutions with comments rolled out on a few sites. I thought it might be worth sharing them here and then discussing whether any of these changes are feasible for consideration of future core development. One of the main things I like about both of these two examples I'm about to share is they utilize AJAX in a meaningful and significant way. It seems like this would provide performance for high traffic sites while providing some "wow factor" for lower traffic or personal sites.
The first example comes from DailyKos which just launched a new commenting system last night. This post explains what they did and you can check out any post to play with the comments. http://www.dailykos.com/story/2006/3/13/25058/9474 You may need to be logged in to see some of the features. One of the cooler things here is the autorefresh feature.
The second example you may well have seen before, and that is Digg's new comment system. This thread is just a good representative example: http://www.digg.com/apple/Optimized_Firefox_builds_for_Mac_processors . Again you may need to be logged in to see everything.
One thing that both of these approaches have is the ability to "rate" or "recommend" comments and the system does certain things with them after they exceed a threshold. Now I know there are a few contributed modules that do some of this, but 1) it isn't in core and 2) they don't really function like this.
Personally I think this is where we should be heading (combining the best features of both of these) but I wanted to see what everyone thought. If there is sufficient excitement I'm sure we could get into discussions about who is willing to work on what or fiscally sponsor what.
So, thoughts?
Comments
Some thoughts
I believe strongly that there is no one 'right' implementation of content rating and community moderation. I think that putting a specific comment moderation solution in core would be a mistake; I'd much rather see a healthy ecosystem of content rating solutions that can work together nicely. It's one of the reasons I wrote VotingAPI -- to provide a common data storage mechanism and a common way of approaching the problem, without forcing sites into a specific rating algorithm, scale, or what not.
Ther are now a number of modules springing up for the 4.7 release -- userrating, mediumvote, Vote Up Down, and others. I'm working on a more complex CustomVote module for code0range.com, and it should be completed shortly. Some implement Digg-style moderation as well.
If there's a specific style of rating and moderation that you think would work well, it should be pretty straightforward to implement with the VotingAPI...
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
Agreed--this is a direction to be moving in
This kind of user moderation of comments appears to be the way interaction on the web is moving. For large, active sites, it is becoming a necessity.
The most frequent requests of people looking at Drupal for the first time seem to be "how can I have a site like Digg," and "how can I have a site that works like Scoop." For those who are coming to Drupal through the "back door" of CivicSpace, this kind of functionality and interaction is probably one of the key features missing at the moment.
I don't see this as something that is going to make it into the core right now though and that's probably a good thing. Personally, rather than a "digg-like" system or a "scoop-like" system, I'd like to see a flexible system that allows you to easily create systems like digg, scoop, reddit or something entirely new.
This strikes me as something that would be good as a joint project as a major contrib module or module group (something like Organic Groups, the VotingAPI or CCK). My preference (which matters not in the least, of course *gr*), would be for something like this to be tackled by a small group of developers who would work on it as a "crash project" to get it up, running and functional with 4.7 as soon as possible after 4.7 itself is up, running and out of beta.
Why? Because we're at the point where lots of different people are trying to develop lots of different separate modules that do bits and pieces of this. Six or nine months down the road, there are going to be a lot of different modules with people not knowing which ones work and play well with others and which ones work as advertised. A year or so down the road we'll have a bunch more unmaintained orphans. If several of the people who are working independently on these things could get together and cooperate on one flexible effort, I think the whole community would be served better in the end.
There is a huge demand for this sort of system, and nobody is filling that demand at the moment. Whoever does fill it is going to garner a lot of attention.
Some notes...
The problem of unmaintained modules and incompatable voting systems is part of the reason the API was written. When a module uses it to store voting data, any other votingAPI-based module can step in and use the same data (within reason, of course -- a module that rates based on raw points can't easily exchange data with one that rates based on a percentage scale, but they all use the same underlying types, etc.)
In my opinion, there are four key aspects of voting/rating/moderation that can differ from site to site.
Right now, VotingAPI allows modules to implement custom solutions to any/all of these problems while using a shared stack of voting data. The next challenge is to figure out ways of letting different solutions to each of those four problems operate interchangably with each other. For example, I'd like to use the spiffy AJAX star widget from BobsVotingModule with the karma algorithing from FranksVotingModule. Any thoughts and feedback on this would be greatly appreciated. The API is a first step -- subsequent versions will have to build on the current features to make more interoperability possible.
If anyone's interested in helping out, there is at least one issue in the VotingAPI queue to integrate the functionality of Voting_Actions module directly into the API itself. That would allow modules to cleanly define voting UIs, as well as the actions that various votes would trigger, without any other user interaction. If anyone has the urge to help out with that code, it's of course appreciated. ;)
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
I feel the urge *gr*
I'll take a look at the issue you're referring to a little later today after I finish up some work. I like the VotingAPI (and all of your projects, for that matter) and think it has the potential to provide a solid basis for a lot of useful, usable "real-world" applications for end-users who need plug-and-play modules to make Drupal a viable solution for them.
Interesting blog you have there also. My wife and I have Tuxedo cats--all the attitude and twice the haughtiness of others I've had in the past. The fork idea is also a good read.
I'll be in touch.
Thom
Voting API is a great step
The voting API is definitely a great place to start. It establishes a "core" method of doing this that will play with any custom solutions.
I'd picture a "core" voting API providing some of the basics for all of the items you listed above and allowing people to go off and exercise the API to do whatever they wanted it to with other modules. And by core I don't necessarily mean in the core of Drupal, but we should establish Voting API (or something else) as the thing that binds it all together and pour effort into it.
Things very well may have advanced since the last time I looked at all the solutions but it seems like a few months ago there were some things being developed to do flashy things in the UI (e.g stars) but they didn't have any substance behind them driving action in the system. Voting_actions sounds very promising in that regard.
============================================
BuyBlue.org