hlisting-feedback

From Microformats Wiki
Jump to navigation Jump to search

Default Action

I think it's good form to have a default for every required field, since someone out there is going to drop any given requried field in the land of microformats. In that spirit, the default for listing type is offer, since wanted ads are << 10% in the real world. What I don't know is what the default action should be; the most neutral of them is announce, which I am using in my parser.

-- Rohit

Donations

Sell and Rent are obvious enough verbs; what does Trade mean, though? Barter? And what about one-sided gifts, like donations or "free to recycle"? Should we replace Trade and offer Donate in its place?

-- Rohit

Desire to Inherit Context

When it comes to blog posting, I’d like to see us address the following:

1. Less is more. Or in reverse, people are lazy, and the less fields they need to fill in order to sell a couch or find a date, the more they'll use the plugin. So I'm trying to visualize how this plays in with the user interface and how we can keep it as simple as possible.

2. DRY. We want to capture as much information as possible from what is already available in the blog post. We already have summary (title), listing date/time (post date/time), permalink, author information, tags/categories.

3. Keep it simple. And here I'm talking about setup and being able to extend your blog's functionality without too much fuss. This one is a bit more tricky, so I'll go into details.

WordPress uses templates to render the blog post. The template then calls the WordPress API to render the title, a second call to render the content, and another call to render any additional metadata (e.g. publish date, categories, author). These separate calls allow people to play with the formatting and apply any styling they like.

The way uPress works, is by processing the blog post before it goes back to the filter, creating the hEvent (to be: hListing) element around it, and adding any relevant fields into the blog post. So what you fill in the form, finds its way to the post content. As a result, setting up the plugin requires two steps: drop it to the plugins directory, and activate.

Unfortunately, I only get to process the content of the post. I can't easily include the title inside the hListing element, or any other metadata about the post, even though I have access to it. If I duplicate that information, the post stops being readable. And to wrap the entire post (not just body) inside a microformat element, I need to tweak the template. Except people use different templates, and I can't tweak all of them.

So the more context we use, the better the plugin becomes.

-- Assaf Arkin

Make Info/Photo fields Optional

WordPress has a great WYSIWYG editor that lets you drag & drop images. But the only semantic identification it uses is the HTML <img> element. So how do we get a photo to be identified from all the images inside the description?

1. Manually edit the HTML that WordPress creates to add the class. 2. Add another UI doubling the one already used by WordPress, sans drag & drop, strictly for images designated as photos. 3. Tag every single image as photo. 4. Have the crawler interpret every single image as photo.

I'm not sure we want to push the complexity to the edge, that's like asking people to create only valid XHTML pages and not rendering anything that refuses to validate. This is about humans first, machines second. If complexity needs to exist, it should be not in the blog, but in the crawlers.

-- Assaf Arkin


On hReview

This draft was heavily influenced by hReview. That's a good thing. We don’t want to duplicate efforts; are learning from the mistakes of others; and converging on a cohesive set of specifications. I want to eventually add hReview and hCard to my plugin. So this strategy of borrowing from existing microformats helps me get it done quicker. It took me all of five minutes to leverage address formatting from hEvent.

But we also need to recognize that hReview could also be more blogging friendly. The specification is great, but the implementations are lacking. I think the reason is that hReview was designed for greenfield applications that specifically deal with emitting reviews. The design did not take into consideration applications that already deal with content, but want to supplement it with reviews, listings, etc. There's no mention of such consideration in the spec.

We want to appeal to the wide populace of bloggers who just want to get stuff done. Rather than put the burden on millions of bloggers out there, we should place the burden on the few companies developing crawlers.

What would Tantek say? I think he'd ask us to focus on use cases, real examples. I'm presenting one such example. The use case involves a blogger who just wants to sell something on their blog, with the minimum amount of effort and cognitive friction. They want the listing to be discovered, aggregated and searched by others.

-- Assaf Arkin


Neighborhood Name

With the exception of housing, most classified listings don’t contain a specific address (e.g., if I’m selling my couch, you don’t need to know where I live in the listing). Some location information, however, is important. In most suburban areas, the name of the town is sufficient. In cities, however, neighborhood is important and more contextually relevant than zipcode (simply a region defined by the post office).

This is a tough problem that needs to be solved but outside the context of this discussion. We think there are other cases the could benefit from it, including hReview and hEvent. We recommend that this debate be surface in the adr microformation discussion (e.g., perhaps extend the locality field (city) to optionally include a neighborhood)

-- Craig Donato & Assaf Arkin


Listing Action, Listing Type, Item Type

We heavily debated how to classify a listing. Search engines or marketplaces typically need to understand what type of listing it is (e.g., personal ad, house for sale, music) to effectively reference or index a listing.

We initially considered proposing a single category field that contained tags (in addition to the tags field). Not only did this seem duplicative, it also seemed like too much of a good thing. In a previous project, Assaf managed to successfully overload everything into tags (including dates and locations), and run time-based and location-based searches, and ended up concluding it's a bad idea.

We eventually decided to propose the use three parametric field that when used together could define any type of listing independent of the words use to describe. These ended up being: listing-type (are you offering something or looking for something; listing-action (are you trying to sell, rent, or announce something); and item type (what item is referenced by the action such as a job opening, product, housing). By making small modifications to this vocabulary, users can specify an extremely wide range of potential transactions. This seemed more feasible given that the UI used to produce the hListing could abstract some of this from the user (as Assaf demonstrated in his demo plugin).

For example:

Desired Transaction Listing Type Listing Action Item Type
Merchandise For Sale Offer Sell Product
Looking to Buy Merchandise Wanted Sell Product
Selling Tickets Offer Sell Event
Apartment For Rent Offer Rent Housing
Looking for Apartment Wanted Rent Housing
Room for Rent (Roommate) Offer Rent Housing
Looking for a Date Offer Wanted Announce, Meet
Job Opening Offer Announce Opening
Looking for a Job (Resume) Wanted Announce Opening
Music Lessons Offer Service Business
Trade Couch for TV Offer Trade Product
Pet for Adoption Offer Announce Animal?

-- Craig Donato