Frances Berriman wrote: > I imagine it will be valuable as a primer for those interested in > creating some type of microformat (or wondering if microformats are > indeed for them) and maybe how the process works.
Good, as that is one of the goals of the document :) > Talking of... I note that one of your encountered problems was with > the process itself. Was it just the shifting/vague targets that were > the main problem, or do you have others? Shifting/vague targets was the most frustrating part of the process. The idea that Microformat authors now are being held to a different standard than the ones that created hCard, hCalendar and hReview. For example, once we had collected around 30 examples for hAudio, we thought we had enough. After all, review-examples (hReview) only has 17 examples collected. However, some on the list kept going on about collecting more examples before a decision could be made. After we had 50 examples, the same issue was brought up that we needed more examples. Thus we went overboard and collected over 100 examples. To us it seemed like this was an unfair argument that was thrown out there whenever we disagreed with somebody that was "more senior" in the community. The argument came across as "Well, you're just not analyzing the correct sites - otherwise, you'd see my point... so why don't you go and analyze more examples until you can prove us right". The person making the previous statement doesn't have to do anything to defend their viewpoint and the person creating the Microformat now has to spend tens of hours collecting more examples. In the end, it made hAudio better - but at the expense of frustrating the Microformat authors. The other issue seemed to deal with being surprised by things that you couldn't do with Microformats, as the wiki doesn't necessarily focus on what you can't do with a Microformat. For example: overlapping Microformats is a problem, so is the lack of namespaces, global identification on pages, and the scoping issue outlined in the hAudio case study. We felt that the community wasn't very upfront about these shortcomings of Microformats. We didn't even know that the community understood that Microformats had these shortcomings until we were 7 months into the process. I think we as a community should be very honest about what one can't do with Microformats. In an attempt to address these issues, I've authored the following document (with help from Martin McEvoy and Brian Suda): http://microformats.org/wiki/how-to-start-a-new-microformat The document attempts to outline The Process more clearly and in a step-by-step manner. We found ourselves missing steps or not understanding what needed to be accomplished at certain points in the process. Our general view of The Process when going through it the first time was that it seemed to be being made up as we went along. There are several community members that have their own take on each step of the process and their advice sometimes conflicted with what other members of the community advised us to do. In short - there didn't seem to be a consensus on the process, which led to frustration when attempting to get to the next step. I think the best thing that the community could do at this point regarding the creation of new Microformats is to smooth and refine The Process. It is not very easy to grok until you've been through it... and after you go through the New Microformat meat grinder, you really don't want to do it again. :) -- manu _______________________________________________ microformats-new mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-new
