I’ve been tasked with coding the front-end on a new-fangled wish list app for my dear Co., Inc. While that isn’t particularly exciting or interesting, these days I’m always looking to throw a little semantic twist in there, usually along the lines of a rel tag here, full-on microformat there. Since we’re talking product lists here, I’d be remiss if I didn’t use the emerging hProduct draft spec in my markup, which is already part of the plan.

In talking with the project brain wizards and a colleague, it appears one of the requirements is to make these lists “portable”. This I’m a fan of. I sport a dataportability.org sticker on my laptop, but haven’t necessarily found an outlet to use the portability techniques prescribed. This could be a perfect opportunity.

It should be relatively straight forward to build unique list-based Atom feeds (I’m assuming the best out of our technology partners here, they’ve been much maligned in my blog comments before). This may be perfect to build a basic list to share via a feed reader. But what about an open standard similar to hProduct that would more fully define the products in lists to the apps that want it?

Extending the data elements of hProduct to an atom feed may be just the fix. With a simple hProduct namespace (or other aptly-named namespace) we can define rich product details outside of the current atom spec to machines and applications while preserving the integrity of a basic feed for those who want to utilize it in a reader.

A quick example:

<?xml version='1.0' encoding='UTF-8'?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:hproduct="http://microformats.org/hproduct/namespace/1.0">
        <id>http://www.jaysstore.com/gifting/lists</id>
        <updated>2008-01-14T08:06:21+01:00</updated>
        <title>jaysstore.com Gifting list for Bill Morgan</title>
        <link rel="alternate" type="text/html" href="http://www.jaysstore.com/gifting"/>
        <link rel="self" href="http://www.jaysstore.com/gifting/bmorgan/list" />
        <author>
                    <name>jaysstore.com</name>
                    <email>gifting@jaysstore.com</emai>
        </author>
        <generator version="1.0" uri="http://www.jaysstore.com/gifting">jaysstore.com gifting list generator</generator>
        <entry>
                  <title type="text">Flip Video MinoHD Camcorder</title>
                  <link href="http://www.jaysstore.com/gifting/lists/bmorgan#minohd"/>
                  <id>urn:uuid:26d11340-c155-11dd-9711-0002a5d5c51b</id>
                  <category term="Products"/>
                  <updated>2008-12-03T08:06:21+01:00</updated>
                  <content type="html">Product short description</content>
                  <author>
	                      <name>Bill Morgan</name>
	                      <email>bill@billmorgan.com</email>
                  </author>
                  <hproduct:availability type="online">This product is available online</hproduct:availability>
                  <hproduct:brand type="text">Pure Digital</hproduct:brand>
                  <hproduct:buy type="url">http://www.jaysstore.com/site/minohd/9077054</hproduct:buy>
                  <hproduct:category type="text">Video Cameras</hproduct:category>
                  <hproduct:condition type="text">New</hproduct:condition>
                  <hproduct:description type="text">This camcorder offers true high-definition recording in an incredibly compact body, so you can be sure you won't miss a minute of recording time</hproduct:description>
                  <hproduct:model type="text">F460B</hproduct:model>
                  <hproduct:n type="text>Flip Video MinoHD Camcorder</hproduct:n>
                  <hproduct:photo type="url">http://images.jaysstore.com/images/products/9077054.jpg</hproduct:photo>
                  <hproduct:price type="sale">206.99</hproduct:price>
                  <hproduct:quantity type="int">1</hproduct:quantity>
                  <hproduct:shipping type="text">Usually leaves our warehouse in 1 business day</hproduct:shipping>
                  <hproduct:url type="url">http://www.jaysstore.com/site/minohd/9077054</hproduct:url>
                  <hproduct:version type="text">1.0</hproduct:version>
                  <hproduct:identifier type="sku">9077054</hproduct:identifier>
                  <hproduct:p-v>
	                               <hproduct:property type="color">black</hproduct:property>
	                               <hproduct:property type="height">3.9"</hproduct:property>
	                               <hproduct:property type="width">2"</hproduct:property>
	                               <hproduct:property type="format">Flash memory</hproduct:property>
                  </hproduct:p-v>
        </entry>
</feed>

I’m thinking out loud on this one. Please feel free to poke holes in my idea here…

hProduct parsers and crawlers, rejoice — there is an even better reason to use bby.com shop URLs… if you knew what they were. A while back, a forward-thinking gentleman had the insight to put these human-readable URLs on the site, which deliver a result set of products, based on term. Now that an experimental version of hProduct has made it out to the site on some pages, it could be a nice asset for people to use.

In simple terms, a query looks like this:
http://www.bestbuy.com/shop/term

Some examples:
http://www.bestbuy.com/shop/cartman
http://www.bestbuy.com/shop/eee

More complex example with additional search parameters:
http://www.bestbuy.com/shop/tv+samsung+1080p

No matter how you feel about the hListing vs. hProduct argument, or Microformats in general, I’m always excited to see experimentation with new and existing Microformats across the web. In an experimental move, we are adding hProduct to all search result, listing pages (faceted navigation), and “shop URLs” (http://www.bestbuy.com/shop/term) on the site with a pre-holiday code deployment.

Admittedly, there is still much work to be done. The source is only a little closer to being truly human-readable, and there are always those “other” things: UI/UX considerations, business “needs”, poor data, and non-semantic markup welded to critical back-end files. In order to get to a better place with hProduct and semantics, I have a personal agenda:

• Get closer to POSH templates with front-end template refresh
• Recognize and perform data cleanup operations, and start teaching out the importance of clean data
• Deploy fuller, more complete hProduct to product detail pages

All this being said, within the confines of this big corporate machine, it feels like progress… or at least a cool experiment that we happened to sneak in without anyone seeing.

Lately I have been hot on the Microformat trend, and have an opening to push hProduct into our product listing and product detail pages, which number in the 300,000+ pages. I believe it could serve as a great example of what the format COULD be, given the correct implementation.

I have posted out a couple times to [uF-new] around the progress we’re making with the new hProduct schema, and am also attempting to solicit feedback from the community. Much to my dismay, I have only received one response (albeit a positive one — thanks Hayes). It’s a bit discouraging to see multi-threaded emails around theoretical formats that in my opinion (I’m biased here) may not have as much of an impact as hProduct. Imagine the kinds of things one could do with an accepted hProduct standard — the partnership between retailers, manufacturers and the end consumer has implications that would heavily impact the e-commerce industry, potentially changing the way consumers find data and shop both online and in the store.

At the risk of bucking the process, my plan is to move ahead and provide real world examples (300,000+ examples!) of hProduct in production, let the jury decide whether this is a worthwhile pursuit, and iterate off of the findings.

Onward.

If you look on microformats.org you’ll see the beginnings of a draft for hProduct. Unfortunately it looks like it hasn’t gotten much attention in the last few years. I fielded an internal request here to start looking into hProduct for our product detail pages, but clearly hProduct really isn’t ready for prime time. There must have been a reason it has basically been abandoned by the microformat community.

Upon further research, I’m seeing that hProduct’s complexity and breadth could be the issue here. Products are so diverse and can carry so many different attributes — how can you possibly marginalize it into a standard microformat without including huge amounts unstructured data?

There’s also a design aspect to this. Our current PDPs have product attributes strewn about the page in a logical “order”. Without muddying the codeblock, how would one introduce or enforce style and visual standards?