process: Difference between revisions
mNo edit summary |
|||
Line 1: | Line 1: | ||
=So you wanna develop a new microformat?= | |||
__TOC__ | |||
==Why?== | ==Why?== | ||
Line 11: | Line 11: | ||
==Document Current Behavior== | ==Document Current Behavior== | ||
Document current behavior. Remember, we're [http://ifindkarma.typepad.com/relax/2004/12/microformats.html paving the cowpaths]- before you do that you have to ''find'' the cowpaths. Your documentation should be a collection of real world | Document current human behavior. Remember, we're [http://ifindkarma.typepad.com/relax/2004/12/microformats.html paving the cowpaths]- before you do that you have to ''find'' the cowpaths. Your documentation should be a collection of real world sites and pages which are publishing the kind of data you wish to structure with a microformat. From those pages and sites, you should extract markup examples and the schemas implied therein, and provide analyses of the same. | ||
This collection of examples should be public, preferably on a wiki because there's no way you can do it by yourself (no matter how many of you there are) [[reviews-formats]] is a good example. Before developing [[hreview]], the collaborators | This collection of examples should be public, preferably on a wiki because there's no way you can do it by yourself (no matter how many of you there are). The [[reviews-formats]] page is a good example of research done before the creation of a microformat. Before developing [[hreview]], the collaborators went out, documented current practices around reviews on web sites, and provided some analysis of the schemas implied therein. | ||
It's quite possible during this step that you'll find someone else who has dealt with the problem you're addressing. Perhaps even solved it. Do your best to open a dialog with others who have encountered the same problem. We don't want to build walls between competing communities - we want people to work together to develop a good solution which will cover the majority of cases. | |||
==Propose a Microformat== | ==Propose a Microformat== |
Revision as of 23:51, 23 June 2005
So you wanna develop a new microformat?
Why?
There must be a problem to be solved. No problem, no microformat.
Once you've found your 'problem,' ask yourself: 'is there a simpler problem here?' If so, let's solve that problem first. We want to deal with the simplest problems first and only then build up to more complex problems.
Also, ask around on the web. Chances are that someone else has encountered the same problem as you. If you still believe that you have an unsolved problem, post something to the [microformats-discuss] mailing list or any other public channel (see mf.org/discuss/) We want to involve all interested parties in the discussion.
Document Current Behavior
Document current human behavior. Remember, we're paving the cowpaths- before you do that you have to find the cowpaths. Your documentation should be a collection of real world sites and pages which are publishing the kind of data you wish to structure with a microformat. From those pages and sites, you should extract markup examples and the schemas implied therein, and provide analyses of the same.
This collection of examples should be public, preferably on a wiki because there's no way you can do it by yourself (no matter how many of you there are). The reviews-formats page is a good example of research done before the creation of a microformat. Before developing hreview, the collaborators went out, documented current practices around reviews on web sites, and provided some analysis of the schemas implied therein.
It's quite possible during this step that you'll find someone else who has dealt with the problem you're addressing. Perhaps even solved it. Do your best to open a dialog with others who have encountered the same problem. We don't want to build walls between competing communities - we want people to work together to develop a good solution which will cover the majority of cases.
Propose a Microformat
Actually, DON'T!!!
There are other things to try before developing a microformat. First, ask yourself these questions:
- Is there a standard element in XHTML that would work?
- Is there a compound of XHTML elements that would work?
- Ok, if the answer to the above two is 'no,' we can talk about a microformat.
For more details on semantic XHTML, examples of using XHTML elements, and constructing XHTML compounds, see The Elements of Meaningful XHTML.
First you should observe the microformats principles
After you understand the principes, ask yourself: "are there any schemas we can look at which address this problem?" For example, hCard and hCalendar were built on top of the IETF standards for vCard and iCal, respectively. The developers of those standards had already developed the schema, and it became much easier to map that schema into XHTML than to develop a new schema.
Remember, microformats should be designed for humans first and machines second. If you want to know whether a proposed microformat passes this principle, ask yourself these questions: 1. If I looked at this microformat in a browser that didn't support CSS or had CSS turned off, would it still be human readable? 2. Are this format's elements stylable with CSS?
If the proposed format doesn't pass these two things, its not likely to gain any acceptance. Remember: humans first, machines second.
Iterate
After proposing a microformat, you'll likely get a lot of feedback from others' interested in microformats. The proposal needs to be iterated and adapted. Microformat developlment should be collaborative and communtiy based.
Here's an ASCII-art flow diagram:
DIAGRAM: problem statement---->research/discussion---->proposal/draft---->standard ^________________V ^___________________V ^______________V
Note that each stage involves iteration. That iteration consists of discussion and feedback and may result in major changes. Do not be afraid to make major changes and please don't get too attached to any particular solutions.