Introduction
Given the glut of content that populates a MindTouch instance, it becomes necessary to add in rating ("how helpful was this page?") of content to help weight the discovery process of content (search + reporting). This feature will allow users to rate pages, files, and comments with the intent of using the ratings to enhance content discovery (through search) and for editors to get reporting on weak areas of content.
Intended for end-users for MindTouch 2010 deployments.
The two most common methods of rating content on the web are either the 5-star method, or the thumbs up/down method. Increasingly, sites are moving towards the thumbs up/down method. Sites which find success with the five-star system (Amazon and Yelp are two) always accompany ratings with high-quality opinions to back up the ratings (notable exception is Netflix). For sites that use the five-star system for fly-by ratings like YouTube see a huge skew instead of the expected normal distribution. If five-star systems are ineffective in providing granular data, then a simple thumbs up/down system will be more effective.
Since the MindTouch content rating feature is meant to gauge the quality of the content as opposed to rating the opinion of the content (which would be beneficial in a more granular rating system), this spec assumes the usage of a thumbs up/down system.
While the first iteration of this feature should focus on the rating of pages, the components should be reusable to eventually be applicable to files and comments.
Implemented in 10.0 as plugin "page_content_rating".
Content rating can be quite an expansive feature, as it serves as the underlying engine for determing content quality. This spec will attempt to capture all the possible use cases of how it might be exposed, although we certainly won't be able to execute on every path forward.
Feature goals:
Here is the page rating component in the Deuce skin (click for full size):
Page rating asks "Was this content helpful?". Users answer by voting, under the following restrictions:
The display goal is to have a clear, non-intrusive way to make a rating and see current ratings. The "2 of 3 found this helpful" style shows information without unduly influencing users. Raw percentages, even when tempered with a vote count, are difficult to keep in the "helpful" range. While 2 of 3 looks fairly helpful, but 66% looks like a poor pass rate on a test.
When a user rates a page poorly, an optional input field will appear, allowing users to post a public comment about what could be improved about the page's contents to offer constructive feedback on improving the page's quality:

See visual states to see all possible UI states for the rating component.
It's convenient to rate a page after reading -- there should be another rating component at the bottom, using the same icons as the floating rating bar.

When a user searches in MindTouch, the result set is automatically sorted with additional weighting given to highly rated pages. The improved search experience may choose to display rating information. The goal is to use ratings as a guide without confusing users about the ordering of search results.
Users, through curation dashboards, will be able to access a dashboard that contains a list of pages of the most lowly rated content (given in absolute terms of number of negative votes). This view will contain:
It will also supply an editor the ability to "wipe" the ratings of the page to allow for the page to be reset (this needs to be stored in the page history somewhere)
With the reporting on metrics, it will be critical for the statistics service to be able to pick these values up and display them in a historical manner.
Every content rating applies a score to the previous contributors of a page to give users an aggregate score of their contributions to a site. This score would then be exposed through the user profile service, with the ability to see the top contributors of a page and throughout the site. User ratings can likewise be negatively impacted by poor ratings, which would be a way of socially engineering active cleanup of the site of bad content (especially content you have authored).
<?php if ($this->hasData('page.rating')) : ?>
<?php $this->html('page.rating'); ?>
<?php endif; ?> The voting buttons will be neutral by default.

Once a user votes, their choice will be highlighted in color in the views above.


Users without javascript will only see the core rating component at the bottom of the page.
Dynamically creating the js-only element will be difficult because of differences in skins. An explicit inclusion of the page.ratings.header makes it easier for skin authors to control where the item will render.
Some points for future consideration?
Several rating bar variations were tried (see file attachments for details). The final iteration is in the use case above.
Edit LocalSettings.php and add this line:
$wgDisabledDekiPlugins[] = 'page_content_rating';
Only pages may be rated in the initial release. Files, comments, and user ratings may be implemented in the future.
The current computed rating for a page is returned in the verbose page XML document. If the current user has rated the page their rating is also included in the XML. This way the UI has enough information to ask the user to change their rating rather than rating it for the first time.
The following XML block will be included in the verbose page XML if the viewing user has rated the content:
<rating score="{float: 0..1}" count="{int}" date="{datetime}">
<user.ratedby id="x" score="{float: 0..1}" date="{datetime}" href="users/{userid}" />
</rating>
A page that has not been rated has the following added XML
<rating score="" count="0"/>
Allows users to rate a page
| Name | Type | Description |
| score | int | A "0" or "1" respectively indicating a poor or good rating |
Input: Empty body
Output:
<rating score="{float: 0..1}" count="{int}" date="{date}>">
<user.ratedby id="x" score="{float: 0..1}" date="{date}" href="users/{userid}" />
</rating>
Rating a page does not add an entry to Recent Changes
Existing database schema is modified to store rating information. The following tables are used:
This table stores raw rating information. If a user changes their vote, the timestamp_reset column in the row representing their current vote gets updated with the current timestamp. Resource_id and resource_type allows concepts other than pages to be rated such as files, pages, users.
CREATE TABLE `ratings` ( `rating_id` int(10) unsigned NOT NULL auto_increment, `rating_user_id` int(10) unsigned NOT NULL, `rating_resource_id` int(10) unsigned NOT NULL, `rating_resource_type` tinyint(3) unsigned NOT NULL, `rating_resource_revision` int(10) unsigned default NULL, `rating_score` float unsigned NOT NULL, `rating_timestamp` timestamp NOT NULL default '0000-00-00 00:00:00', `rating_reset_timestamp` timestamp NULL default NULL, PRIMARY KEY (`rating_id`), KEY `resource_id_type_resetts_user` (`rating_resource_id`,`rating_resource_type`,`rating_reset_timestamp`,`rating_user_id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE utf8_general_ci;
This table has the current ratings already computed. A unique key constraint applies on resource_id and resource_type ensuring that only one current rating exists for a resource. Rows in this table are updated when a new rating occurs.
CREATE TABLE `ratingscomputed` ( `ratingscomputed_id` int(10) unsigned NOT NULL auto_increment, `ratingscomputed_resource_id` int(10) unsigned NOT NULL, `ratingscomputed_resource_type` tinyint(3) unsigned NOT NULL, `ratingscomputed_score` float unsigned NOT NULL, `ratingscomputed_score_trend` float unsigned NOT NULL, `ratingscomputed_count` int(10) unsigned NOT NULL, `ratingscomputed_timestamp` timestamp NOT NULL default '0000-00-00 00:00:00', PRIMARY KEY (`ratingscomputed_id`), UNIQUE KEY `resource_id_type` (`ratingscomputed_resource_id`,`ratingscomputed_resource_type`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE utf8_general_ci;
| File | Version | Size | Modified | |
|---|---|---|---|---|
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| ||||
| Images 27 | ||
|---|---|---|
ux ideas for content ratingcontentrating-ideas.png | ||
sample dashboard w/o anychartsrating_dashboard_nocharts.png | ||
various ui statesrating_examples.png | how it'd be integratedrating_overview.png | |
what it'll look like integrated into acerating_overview_ace.png | what it'll look like integrated with fiestarating_overview_fiesta.png | |
sample dashboardreport_quality.png | ||
Copyright © 2011 MindTouch, Inc. Powered by
I think that a collaboration need to be measured, both the co-authors & the co-created contents.
In my opinion, generated conversation (post comments) also is a contribution, because the content post gain value with it.
About the first challenge, how to share the vote between all contributors, i'm thinking about it...
I agree with Carles that dekiwiki can make the difference in this field :)
This will prevent on a corporate site that people critisism other people, don't do this, I've readed about it on some studies. The votes have to be anonymous on corporate sites, otherwise you will not take what you want to get with page votes.
In any case, the "why did you rate this poorly?" form will be optional, so people can choose not to fill it.
Some interesting readings:
- A wiki as Intranet: a critical analysis using the Delone and McLean model ( Marina Trkman & Peter Trkman )
- WikiFailure: the Limitations of Technology for Knowledge Sharing (Alexeis Garcia-Perez & Robert Ayres )
- Where Is the Theory in Wikis? (Ann Majchrzak)
All of them points to quality on content, and contributors reputation.
- I agree you that up/down system will be more effective than 5-star system, and also easier to use :)
- I think that there are two important indicators to consider: time & quality. then when you've proposed Content Curation Dashboard, you're measuring the quality of the contents but in what time? I think this is great but incomplete..., we need to measure the time, not only the quality distribution, the evolution too.
- Furthermore i think that we need to measure four different variables: visits, edits, comments and ratings, then we can get differents point of views of contents: revision (visits), contribution (edits, comments) and recommendation (ratings).
- About negative votes, i think the author of this criticism is who would consider where want deliver his/her comment: to the author only (and moderators) or to all (public).
- The last, i think that "curation" term don't clarify this is about measuring, i prefer something like "valuation" IMHO ;)
hugs :)
I can't think of any solution to this problem other than a rating system that consists of more than rate-up and rate-down. Perhaps a scoring system that takes into account of the vote, voter's personal rating (See @carles.coll's post), visits, etc. Though this would be much more work than should be spent on v1. :P
However critical this comment may sound, I do like the concept. :D
Hey Blake, long time no... something!
I would like to see the page rating data available in the page variable, and the current user's vote made available somewhere (not sure where to be honest). Having said that, I don't know how super-useful it would be, but it would make it easy to build one's own "find highest or lowest-rated pages" templates.
Also, is there a way to control which pages have this enabled?
$wgDisabledDekiPlugins[] = 'page_content_rating';