aggregate-review-brainstorming

(Difference between revisions)

Jump to: navigation, search
(What is the proposal?: captured a few more details from past IRC discussion, root class name "hreview-aggregate", new property "count")
Current revision (06:34, 16 December 2009) (view source)
 
(6 intermediate revisions not shown.)
Line 1: Line 1:
Ideas for how to support aggregate reviews via microformats.
Ideas for how to support aggregate reviews via microformats.
-
 
== Common themes amongst examples (that we might want to support) ==
== Common themes amongst examples (that we might want to support) ==
Line 7: Line 6:
** the number of reviewers
** the number of reviewers
** the average rating
** the average rating
 +
 +
''number of reviewers, really? unique people? what if there's more than one rating per person? Number of ratings would be simpler.''
 +
 +
''Google Rich Snippets makes mistake of assuming that number of ratings equals number of reviews, but users may leave rating without leaving review''
 +
 +
''These are good points -- added a separate section below to discuss ratings vs reviews vs reviewers. Note that the first comment referring to the number of "reviewers" caught a typo -- it should be number of reviews, not reviewers.  -- Kavi, Nov 2 2009''
* Other elements that occur in the example set include:
* Other elements that occur in the example set include:
Line 22: Line 27:
* Define a new microformat for aggregate reviews (root class name "hreview-aggregate").
* Define a new microformat for aggregate reviews (root class name "hreview-aggregate").
* The format will contain only value (the number of reviews) with a new property "count" and embedded [[hReview]]  properties that contains details like the average review score, summary, and a reference to the object of the review.
* The format will contain only value (the number of reviews) with a new property "count" and embedded [[hReview]]  properties that contains details like the average review score, summary, and a reference to the object of the review.
 +
 +
'''This proposal should be written up on a separate page as a microformats draft, e.g. [[hreview-aggregate]].'''
==== Why was this proposal preferred? ====
==== Why was this proposal preferred? ====
Line 27: Line 34:
* Supporting only the number of reviews (rather than scores per rating, etc) is probably sufficient for 80% of sites with aggregate reviews.  
* Supporting only the number of reviews (rather than scores per rating, etc) is probably sufficient for 80% of sites with aggregate reviews.  
-
== All proposals suggested ==
+
== Other proposals suggested ==
==== 1) Do nothing. Aggregation must be done by the microformats parser ====
==== 1) Do nothing. Aggregation must be done by the microformats parser ====
Line 43: Line 50:
* Cons: some redundancy with hReview. Extending hReview might be sufficient
* Cons: some redundancy with hReview. Extending hReview might be sufficient
 +
==== 4) Do not use hreview classes in hreview-aggregate ====
 +
* This causes a collision when hreview includes an hcard that contains review aggregates per google specification http://www.google.com/support/webmasters/bin/answer.py?answer=146645 . In that case, the hreview has its own rating, and a second rating imported via the include pattern.
 +
Currently Yelp implements review aggregate as an hreview-aggregate block that include the entire hcard inside it, and the aggregate rating. Importing this hcard from an hreview using the include pattern, imports the rating as well.
 +
* review-aggregate can be included INSIDE hcard block, or can surround that block.
 +
* review-aggregate can point to a '''self contained''' hcard (include pattern):
 +
** Without repeating any of the information in the hcard
 +
** Without including empty links, example <code>&lt;a class="item include" href="#my_business_hcard"&gt;&lt;/a&gt;</code>
 +
** Without including links with duplicate redundant information that is part of the hcard, example <code>&lt;a class="item include make_me_invisible_to_user" href="#my_business_hcard"&gt;Business Name&lt;/a&gt;</code>
 +
** Without adding listing information, such as the type of listing: <code>&lt;span class="type"&gt;business&lt;/span&gt;</code>.
 +
** Without using non-semantic HTML, such as object tag.
 +
* An hreview should be able to safely import an hcard that may contain hreview-aggregate '''without name collitions''' especially the rating tag (using include pattern).
 +
* An hreview should be able to safely import an hcard that may contain nested elements of hreview-aggregate, such as count and average rating, '''without name collitions''' (using include pattern). If this is not possible, pages will have to default to non semantic HTML, and markup that contains a lot of hidden content, making them less accessible.
 +
 +
== Reviews vs ratings ==
 +
 +
Note -- this proposal has been incorporated into the hreview-aggregate draft spec version 0.2 in December 2009.
 +
 +
Adoption of hreview-aggregate has been strong, but one issue that arisen is the notion of reviews vs ratings. The original hreview-aggregate spec as described below uses a single property called "count" to specify the total number of reviews for an item that contributed towards an aggregate review. This works well for a site like Yelp, where the aggregate rating is based on the number of individual user reviews.
 +
 +
However, many sites allow users to provide a rating without actually writing a review. So there should be some way of allowing sites to mark up the number of "ratings" (or "votes") separately from the number of "reviews."
 +
 +
A couple examples of sites that have separate rating counts and review counts:
 +
* Urbanspoon: http://www.urbanspoon.com/r/6/88896/restaurant/Patxis-Chicago-Pizza-Palo-Alto
 +
* Download.com: http://download.cnet.com/Mayura-Chess-Board/3000-7562_4-10525218.html
 +
* Longer list of examples is here: [[aggregate-review-examples#Ratings_without_reviews_examples]]
 +
 +
==== Proposed solution ====
 +
 +
* Add a new property called "votes" to hreview-aggregate.
 +
** Pros: it is simple for webmasters to understand and is consistent with the terminology that many sites actually use (for example: Urbanspoon, Download.com, IMDb). It also doesn't change the interpretation for any site that has already implemented the existing hreview-aggregate spec.
 +
** Cons: it's not completely obvious that "count" means "number of reviews" whereas "votes" means "number of ratings."
 +
 +
==== Alternative options ====
 +
 +
* Add nested sub-properties to the "count" property: "reviews" and "votes"
 +
** Pros: terminology is clearer than the proposed solution above. For backwards compatibility, if users don't specify reviews vs votes, assume they meant reviews by default.
 +
** Cons: in practice, adding additional layers of nesting creates more chances for webmasters to make mistakes. More nesting is also more verbose.
 +
 +
Note that we shouldn't remove the ability for people to mark up the actual number of reviews -- for anyone who wants to read reviews, it's very useful to know how many reviews there are on a page even if there are more votes contributing towards an aggregate rating.
== See Also ==
== See Also ==
* Aggregate reviews: [[aggregate-review-examples|examples]] - [[aggregate-review-formats|formats]]
* Aggregate reviews: [[aggregate-review-examples|examples]] - [[aggregate-review-formats|formats]]
 +
* [[hreview-aggregate]]
* [[hreview|hReview]]
* [[hreview|hReview]]

Current revision

Ideas for how to support aggregate reviews via microformats.

Contents

Common themes amongst examples (that we might want to support)

number of reviewers, really? unique people? what if there's more than one rating per person? Number of ratings would be simpler.

Google Rich Snippets makes mistake of assuming that number of ratings equals number of reviews, but users may leave rating without leaving review

These are good points -- added a separate section below to discuss ratings vs reviews vs reviewers. Note that the first comment referring to the number of "reviewers" caught a typo -- it should be number of reviews, not reviewers. -- Kavi, Nov 2 2009

Proposal discussed over IRC

What is the proposal?

This proposal should be written up on a separate page as a microformats draft, e.g. hreview-aggregate.

Why was this proposal preferred?

Other proposals suggested

1) Do nothing. Aggregation must be done by the microformats parser

2) Extend existing hReview format to include "reviewcount"

3) Define a new microformat type for aggregate reviews

4) Do not use hreview classes in hreview-aggregate

Currently Yelp implements review aggregate as an hreview-aggregate block that include the entire hcard inside it, and the aggregate rating. Importing this hcard from an hreview using the include pattern, imports the rating as well.

Reviews vs ratings

Note -- this proposal has been incorporated into the hreview-aggregate draft spec version 0.2 in December 2009.

Adoption of hreview-aggregate has been strong, but one issue that arisen is the notion of reviews vs ratings. The original hreview-aggregate spec as described below uses a single property called "count" to specify the total number of reviews for an item that contributed towards an aggregate review. This works well for a site like Yelp, where the aggregate rating is based on the number of individual user reviews.

However, many sites allow users to provide a rating without actually writing a review. So there should be some way of allowing sites to mark up the number of "ratings" (or "votes") separately from the number of "reviews."

A couple examples of sites that have separate rating counts and review counts:

Proposed solution

Alternative options

Note that we shouldn't remove the ability for people to mark up the actual number of reviews -- for anyone who wants to read reviews, it's very useful to know how many reviews there are on a page even if there are more votes contributing towards an aggregate rating.

See Also

aggregate-review-brainstorming was last modified: Wednesday, December 16th, 2009

Views