hProduct - Google Experimenting with Markup for Product Data

[pageoneresults]

Did you know that Google is experimenting with markup for product data?

Google is experimenting with markup for product data. We do not currently display this information, unless the product is part of a review.

Properties

Each product can have a number of different properties, such as name, category, price, and brand. You can use either Microformats or RDFa markup to label these properties.

Google Webmaster Central > Products > About Product Information
[google.com...]

[tedster]

Thanks for the link, pageone. I hadn't read that post and it adds some meat to the microformat discussion. Since the microfomat mark-up involves adding a class to a span tag, anyone wanting to introduce this mark-up would probably want to RESERVE these class names for that special use and not use them for adding CSS styles in any other element:

brand
category
description
name (fn)
price
photo
url

[Tonearm]

Wouldn't this be redundant if you're uploading the same products to Google Base?

Edit: Ah, I see. Microformats is not a Google-only thing.

Should microformat markup be added to a product listing page listing 20 different products, or a product detail page listing only 1 product?

[pageoneresults]

Should Microformats markup be added to a product listing page listing 20 different products, or a product detail page listing only 1 product?

Anywhere that product data may appear is a prime candidate for Microformats. Think of it this way, you have the existing HTML elements which help define a page or section it, semantically speaking that is. Then along comes Microformats which allows you to further refine the data within those elements, hence the term Microformats.

If I had an existing ecommerce platform, I'd be reworking the templates this weekend to include the hProduct and hReview Microformats if your site qualifies.

We do not currently display this information, unless the product is part of a review.

I can understand why they chose the Reviews to be at the top of the list for testing. It all ties in with everything they've been doing from Local to Social. If you've got a shop that does ecommerce with product reviews, you've got another set of semantic properties to work with and, there are a bunch of them, hCard being just one of them for the representations of people, companies, organizations, and places.

tedster mentions reserving class names which I would like to reiterate. You SHOULD make sure that your existing class names do not interfere with the Microformats Property List.

hCard Property List
[Microformats.org...]

Even if your ecommerce site does not support reviews, I'd make the leap and start implementing hProducts as soon as possible. Not to mention hCard where applicable. If you have hReviews setup, you may even want to use hCard for the Authors. ;)

The [Microformats.org...] website provides all the information you need. You'll also find Google referencing Microformats consistently throughout their documentation.

Google Webmaster Central - Help us make the web better: An update on Rich Snippets
Monday, October 26, 2009 - [GoogleWebmasterCentral.Blogspot.com...]

Tags: Microformats, vCard, hCard, hProduct, hReview, hCalendar

[tedster]

I can understand why they chose the Reviews to be at the top of the list for testing.

Me too. I've written before about what a huge challenge it is to do REAL sentiment analysis. But if review information is all nicely packaged up, then you don't need full blown SA.

I've even read recent articles that call review data "sentiment analysis". What garbage! There's no analysis involved at all, just data retrieval. You might as well call a visual inspection of a TOC "information retrieval".

[dstiles]

Probably not the right place to say this, but I think over-loading Class structures is typical of the abysmal quality and abuse of web programming languages in general.

The original HTML tags more or less happened (and were good for the original purpose), then other tags were added or deprecated with, it seems to me, too little thought.

CSS as a language was certainly very poorly designed, with several inconsistencies, no constants or variables, and no structure beyond tha actual Class definition itself. Now this LAYOUT language is being over-loaded to perform non-layout markup, which it was never intended to do, and is already set to cause extra work to change some older Class names on well-established web sites.

What's wrong with a custom designed HTML tag with a proper structure that could still take CSS markup IF it was needed? And that would be ignored by User Agents if they didn't understand it?

Obviously, it's too late now, but that's pretty much the whole story of the internet. Patch and mend.

[TheMadScientist]

Personally I see the extra work on older sites argument, but... Most of the sites I work on apply a slightly different style (layout) to most of the elements you can define, so if I can style text and define what it's about all at once it doesn't seem like an all bad idea to me. To me it actually seems quite a bit simpler than having to add an extra HTML tag to do the same thing... Essentially all people have to do is change their class names if they already apply a different style to the elements involved.

Seriously, on one site I basically use Book_Description as the class for the description and Book_Left for the image, so it doesn't bother me a bit to change those to 'description' and 'photo' respectively so a search engine can interpret what each is. It's a simple site-wide find & replace. Personally, I would be much more reluctant to go back and recode sites to add an HTML tag.

IMO, all quite a few of us have to do is change the name of the style applied to elements. I can't see how that's not well thought through or an issue for most people or even the web in general. Basically all people have to do using the microformat version of the hProduct or hCard is name the class of the style they apply according to the names specified and it's done.

How does it hurt or do anything detrimental to use a specific set of class names to allow search engines to know what each element is about rather than making them up as you go? It actually seems like it would add some good (needed?) consistency for other types of things, such as screen readers...

[pageoneresults]

I've written before about what a huge challenge it is to do REAL sentiment analysis.

There's a language for that! ;)

Emotion Markup Language 1.0
[WebmasterWorld.com...]

but I think over-loading Class structures is typical of the abysmal quality and abuse of web programming languages in general.

This can be minimized by taking into consideration the class properties and then designing with those in mind. I understand where you're coming from but I don't see any abuse taking place. The overloading typically occurs from the developer standpoint. You can minimize the amount of markup involved by taking a look at the entire structure to see what can be nixed, to compensate for any additional class markup.

IMO, all quite a few of us have to do is change the name of the style applied to elements.

It really is as simple as that for many. For others, it is going to be constant whining and an ongoing battle to make things happen.

I'm already in the process of setting up default style sheets for all the confirmed and common properties. I will now start designing with those in mind and at the same time, begin retrofitting existing sites. I've already done a few. :)

I've spent the last two weeks engulfed in Microformats. I've read just about every topic Google have posted on the subject. I can tell you that this is not something new but it is now becoming a reality for many of us. So, what is new? For one, Google's documentation have been updated and contain many references to Microformats including their experimenting with hCard and hReview Microformats. Here are just a few you'll want to review and act upon if you haven't already. ;)

• Google - Marking up Data Using Microformats
  Updated 2010-02-24 - [Google.com...]
  
• Google Knol - Rich Snippets Tips and Tricks
  [Knol.Google.com...]
  
• Google - Products > About Product Information > hProduct
  [Google.com...]
  
• Google > Reviews > About Review Data > hReview
  [Google.com...]
  
• Google > People > About Contact Information > hCard
  [Google.com...]
  
• Google > Businesses and Organizations > About Organization Information > hCard
  [Google.com...]
  
• Google > Events > About Event Information > hCalendar
  [Google.com...]
  

[Tonearm]

Can microformat classes be added to any HTML tag? How about the anchor tag for example?

Edit: It looks like they can be added to the anchor tag. Does the microformat need to be placed on the innermost tag? For example, can they be placed on a div that surrounds some anchor text and some non-anchor text?

This seems like a front page item to me.

[TheMadScientist]

Personally, I would try to go with the 'best fit' for each one, meaning if it was the 'description' and there were other styles (text, links, images, etc.) applied within the description I would (probably) use the surrounding <div> but for an <a> I would (probably) go with the actual linked text, IMO usually meaning the inner most for <a>s.

[tedster]

There's a language for that! ;)

Emotion Markup Language 1.0

True enough - but when emotion is marked-up, then you don't need to extract sentiment from text content through analysis (if you trust the author's mark-up, that is.) You'll also not be picking up 99% of the sentiment that is actually being expressed, especially in UGC.

[Tonearm]

What about class="hproduct" on a td? What about something like class="hproduct otherstyle"? Are those OK?

Does anyone have any ideas on how Google might use this data?

Anywhere that product data may appear is a prime candidate for Microformats. Think of it this way, you have the existing HTML elements which help define a page or section it, semantically speaking that is. Then along comes Microformats which allows you to further refine the data within those elements, hence the term Microformats.

I'm struggling with this a little bit. If Google will use this product data as "rich snippets" like it does with reviews, I think I'm better off only using it on product detail pages and only to define the main product on that page. Otherwise, where does it stop? Should I use hproduct and title whenever I mention a product's title on a page? What if I mention the title and show the photo? What about a photo and a link only?

Considering how rich snippets work, isn't it better to send a clear signal regarding which product a page is about, if any?

[CainIV]

Nice post guys, with the myriad of tasks involved with ecommerce website it is very easy to stay in the present as opposed to looking forward to these technologies which are really on the doorstep.

[pageoneresults]

Can microformat classes be added to any HTML tag? How about the anchor tag for example?

Yes they can. The links posted above show examples such as <strong class="fn"> and <img class="photo">.

For example, can they be placed on a div that surrounds some anchor text and some non-anchor text?

No. That's what HTML Elements are for. Microformats take the Elements and allow you to refine them further. Your root class can be assigned to the <div> that surrounds that content. And then you assign additional properties to those items within the root class.

What about class="hproduct" on a td? What about something like class="hproduct otherstyle"? Are those OK?

Ah, you'll need to review the links posted. I'm more than happy to assist but, these questions are answered in the links posted above. Most of those are single documents so there isn't much reading involved. ;)

Does anyone have any ideas on how Google might use this data?

I'm going to reference the links above again. Google states how they are currently using this data. Now, if you want, there are some Google Patents that tie in with all of this. Once you've read those, you'll see the bigger picture and what is taking place. Google wants Machine Readable Grammar properly formatted. I think they always have, they've just taken it to new micro-levels.

I'm struggling with this a little bit. If Google will use this product data as "rich snippets" like it does with reviews, I think I'm better off only using it on product detail pages and only to define the main product on that page.

From my perspective, anytime that product appears, whether it be an on site snippet or the full product page, I'd have it wrapped in the proper semantic markup, there are no exceptions. You need to keep the integrity of the data intact and having some with and some without is not optimal from my perspective.

Otherwise, where does it stop? Should I use hproduct and title whenever I mention a product's title on a page?

Most likely, yes.

What if I mention the title and show the photo? What about a photo and a link only?

Yes, yes, and yes. :)

Considering how rich snippets work, isn't it better to send a clear signal regarding which product a page is about, if any?

You can send clear signals from anywhere. If the content is wrapped in the proper semantic containers, the signal is there. Whether it be a partial signal or full signal, it is all part of the process.

As opposed to looking forward to these technologies which are really on the doorstep.

I think we're a little late to the party. RDF has been around for years and apparently IS being used for data acquisition. Microformats is the alternative to RDF. I can tell you from all of my research that RDFa is much more complex. The code required to wrap content is a bit more bloated and requires that you understand vCard. Plus, you now have to use namespace declarations which you do not with Microformats.

[pageoneresults]

Get in on the action if you can. You'll need to meet the requirements for inclusion...

Type(s) of structured content that's available, or will be available, on your website (please check all that apply): Reviews, People profiles (i.e. social network), Local business information, Products for sale, Events

Interested in Rich Snippets?
[Google.com...]

You'll need to provide 4 URIs where your structured content is available. I would strongly suggest that you validate those pages before submitting. You should also run your documents through...

Google's Rich Snippets Testing Tool
[Google.com...]

...to make sure the data is being extracted properly. If it is not, you've done something wrong. Go back to Step 1 and do not submit until you're able to extract proper rich snippet(s) from your document.

Please take note, this is not something that is specific to Google. Microformats are being imported by a variety of resources with the Search Engines being just one of them. How do you think the Search Engines are getting some of their Social Media data? ;)

[Tonearm]

For example, can they be placed on a div that surrounds some anchor text and some non-anchor text?

No. That's what HTML Elements are for. Microformats take the Elements and allow you to refine them further. Your root class can be assigned to the <div> that surrounds that content. And then you assign additional properties to those items within the root class.

I'm not sure if we're talking about the same thing. I'm wondering about this since part of the category is anchor text and part is not:

<div class="hproduct">
<div class="category">
<a href="page.html">Red</a> Widgets
</div>
</div>

Does anyone have any ideas on how Google might use this data?

I'm going to reference the links above again. Google states how they are currently using this data.

I should have been more specific, I meant how will they use it in the future. They do state how they're using it now, and I think we can agree that the best way to apply hproduct considering the current state of Rich Snippets is to use it only on the main product appearing on each product detail page. That seems in-line with the way Google uses the data now, as demonstrated by the tool you linked to:

[google.com...]

If I "preview" a page with that tool that has more than one hproduct definition, Google only shows the main product.

The question for me is, how will Google use hproduct in the future? It seems they want to break up a site's data into well-defined portions for display on their own site. I don't see how defining hproduct on more than the main product on each product detail page will help that along.

Considering how rich snippets work, isn't it better to send a clear signal regarding which product a page is about, if any?

You can send clear signals from anywhere. If the content is wrapped in the proper semantic containers, the signal is there. Whether it be a partial signal or full signal, it is all part of the process.

This seems similar to the question of whether or not to use alt image text on every product image. For example, on a product detail page, should alt image text be used on the photos of items that are displayed for cross-selling purposes? That alt image text doesn't speak about the main theme of the page, which is the detailed product. I think some would say include it, and some would say don't, but I bet you would include it. :) You could be right too, it's just an example of defining pages vs. defining page elements.

Shouldn't we be sure the search engine signals we include on a page define the page in accordance with the search engines' usage of those signals?

[claus]

RESERVE these class names for that special use and not use them for adding CSS styles in any other element:

brand
category
description
name (fn)
price
photo
url

Those are very poorly chosen class names. Words that are so generic as "photo", "url", "description" should not be used for application-specific stuff. That only opens up possibilities for a whole lot of mis-classifications.

If Google wants to do this properly, they should at least introduce a generic class prefix for those class names, e.g. "Product Microformat Class Name", pr "pMCN_" so that:

"brand" becomes "pMCN_brand"
"category" becomes "pMCN_category"
"description" becomes "pMCN_description"

... and so on. Anything else is asking for trouble down the road.

[TheMadScientist]

I'm wondering about this since part of the category is anchor text and part is not:

In thinking about it a bit more I would only use it on the anchor text. You've already defined the surrounding information and the class="url" IMO is to let machine readers know where the URL for more information is.

You could also have this:
<div class="hproduct">
<div class="category">
<a href="page.html">Red</a> <a href="/another-page.html">Widgets</a>
</div>
</div>

To define which URL is more information for the product and which is the general overview page you would use class="url" on the product link and not on the other URL.

The question for me is, how will Google use hproduct in the future? It seems they want to break up a site's data into well-defined portions for display on their own site.

Me too... and on some sites, this is totally okay with me and others it's not, so how and where and what site I use hProduct on will be based on whether I want to allow them to show the product on their site or not.

For example, on a product detail page, should alt image text be used on the photos of items that are displayed for cross-selling purposes? That alt image text doesn't speak about the main theme of the page, which is the detailed product.

I don't do everything for search engines... IMO, and my way of doing things, (mostly) yes, because most sites I build are also accessible to screen readers because I think it's a good way of doing things, so if there are other products on a page I use the alt, but as far as Search Engines go, I try to keep everything well related, so SEO helps me keep things 'organized', which means the alt text on all images helps both.

IMO People who would say you should not use the alt on a site where IMO it should be accessible to screen readers are really, IMO, building sites for search engines rather than people. I don't make all the sites I work on 100% accessible to screen readers, but they're all now very close, mainly because I think it's cool to do for people who are a bit less fortunate... There was one I didn't make accessible from the start, but have since recoded most of it.

That only opens up possibilities for a whole lot of mis-classifications.

Doesn't it have to be surrounded in an hProduct 'div' according to the spec?
[google.com...]

In the first line, class="hproduct" indicates that the HTML enclosed in the <div> describes a product

IMO No hProduct = You can use whatever class you feel like, because you haven't defined anything as an hProduct, so I'm thinking there shouldn't be an issue.

[albo]

emotion {
background: blue;
border: 3px outset gray;
clear: both;
display: block;
margin: 0;
padding: 2arms; }

[pageoneresults]

If Google wants to do this properly, they should at least introduce a generic class prefix for those class names, e.g. "Product Microformat Class Name", pr "pMCN_" so that:

Remember, this is not a Google initiative although they are probably one of the more aggressive users of the protocol.

In reference to the above statement, you use what is referred to as a Root Class Name...

Microformats - hCard parsing
[Microformats.org...]
[Microformats.org...]

Each compound microformat starts with a root element with a relatively unique class name. By that I mean a class name which isn't simply a common word, and is unlikely to have been used outside the context of the microformat.

Root Class Name Examples: vCard (the Root Class Name of hCard is vCard), hProduct, hReview, hCalendar

More information on the Class Design Pattern...

Microformats - class-design-pattern
[Microformats.org...]

Use the class-design-pattern to indicate semantic meaning about XHTML elements. Always use the most appropriately semantic (X)HTML element for the content. If an appropriate semantic element is not available, use <span> or <div>. Always avoid presentational (X)HTML. Add semantics to (X)HTML by using semantic-class-names. The class attribute is a space separated list of class names. Always choose names following the microformats naming principles.

[httpwebwitch]

basic question.

We do not currently display this information, unless the product is part of a review

If my site has "hProducts" but not "hReviews" (ie, these are pages that actually sell the product - these are product descriptions, not UGC reviews), will I benefit putting these microformats in place?

And what if I wrap them in the context of an hReview, even though it's not a real review? Will my hand be summarily slapped?

[httpwebwitch]

this is news to me:

Hidden div's -- don't do it!
It can be tempting to add all the content relevant for a rich snippet in one place on the page, mark it up, and then hide the entire block of text using CSS or other techniques. Don't do this! Mark up the content where it already exists. Except in special circumstances (for example when marking the best possible rating for review sites that don't use a 5-point rating scale), Google will not show content from hidden div's in Rich Snippets.

source: [knol.google.com...]

[pageoneresults]

If my site has "hProducts" but not "hReviews" (ie, these are pages that actually sell the product - these are product descriptions, not UGC reviews), will I benefit putting these microformats in place?

Based on Google's public statements, this is still in Beta and requires that you have both hProducts and hReviews in place. You also need to submit your site to be reviewed for inclusion in the beta.

And what if I wrap them in the context of an hReview, even though it's not a real review? Will my hand be summarily slapped?

Heh, that's a choice you'll have to make although I wouldn't recommend it.

That hidden div part should probably cause quite a few to start making some changes.

[pageoneresults]

Today, we’re happy to announce support for microdata for use in rich snippets in addition to our existing support for microformats and RDFa. By using microdata markup in your web pages, you can specify reviews, people profiles, or events information on your web pages that Google may use to improve the presentation of your pages in Google search results.

Microdata support for Rich Snippets
Tuesday, March 09, 2010 at 5:51 PM
[GoogleWebmasterCentral.Blogspot.com...]

Google, I am thoroughly enjoying all of this, thank you so much for your continued support of machine readable grammar, you rock!

[tedster]

Here's a flagship program that may be related - so far only rolled out to 5 retailers and only on a mobile app. However, it could also become a very big deal:

Google App Shows Shoppers What's In Stock Nearby

Starting today, Google will let you use your cellphone to check the stock of products at participating retail outlets. Unfortunately, so far only five retailers are participating in the new services: Best Buy, Sears, Williams-Sonoma, Pottery Barn, or West Elm.

[itmanagement.earthweb.com...]

[pageoneresults]

tedster, let's see how much traction all of this new stuff gets. I don't see many discussing these features and a good portion of them have been in use now since last year. I don't think the bulk of the community is catching on just yet.

I'm also finding that many can't take these steps just yet. There are some semantic challenges and it comes down to well formed markup. I want to say 100% valid markup is mandatory but I'll get spanked by who knows how many because they have 100s of errors and rank number 3 for their primary keyword phrase. ;)

We're all over this! We've already configured multiple templates to utilize hCard, hProduct, hReview and hCalendar. Now, if we can just keep up with the rate of information that is coming out - finally! Hurry folks, you'll want to hop on board this train.