how-to-start-a-new-microformat

The New Microformat HOW-TO

Before getting started, please familiarize yourself with the microformats [process | process]

This HOW-TO provides a step-by-step tutorial in the process of creating a new Microformat from beginning to end.

1. Propose a Microformat

Actually, DON'T!!!

There are other things to try before developing a microformat. First, ask yourself these questions:

  1. Is there a standard element in XHTML that would work?
  2. Is there a compound of XHTML elements that would work?
  3. 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 (http://tantek.com/presentations/2005/03/elementsofxhtml/).

First you should observe the microformats principles.

After you understand the principes, ask yourself: "are there any well established, interoperably implemented standards 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, both of which are widely interoperably implemented. The developers of those standards had already spent many years in standards committees arguing about and developing the schemas. Better to leverage all the hard work that others have done before you, than to go off as a solo cowboy inventor, and waste time repeating all their mistakes. It's also much easier to start from a well established schema, and map into into XHTML than to develop a new schema.

1. Create a Problem Statement
   1. The Problem Statement is a very specific paragraph that outlines a commonly published piece of data on the web. If you need an example of an initial problem statement, one can be found here: hAudio Problem Statement. Once you have finished your problem statement, proceed to the next step.
2. Apply pre-existing Microformats to your Problem Statement
   1. There is a large list of Microformat specifications, drafts and exploratory discussions that could be applied to your Problem Statement. Make sure to check the list and see if your problem can be solved using a combination of the pre-existing microformats. If you have not found a combination of microformats that can address your problem statement, proceed to the next step.
3. Ask the microformats-new mailing list for guidance
   1. There are a number of people that have been active in the community for a long time. If you have done the previous steps and you still think that your problem is not being addressed by an existing microformat, ask the microformats-new mailing list. Make sure to include your Problem Statement and let the list know that you are considering creating a new microformat to address the issue. Be ready for a variety of answers - the community rarely agrees when a new topic arises. It may take a bit of discussion to determine if a new microformat is needed.

Step 1: Determine if a New Microformat is Needed

In many cases, a new Microformat is not needed. Microformats are meant to be combined with one another, therefore most problems can be solved by combining a number of Microformats.

There must be a problem to be solved. No problem, no microformat.

Also, search 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-new (http://microformats.org/mailman/listinfo/microformats-new/) mailing list or any other public channel (see http://microformats.org/discuss/) We want to involve all interested parties in the discussion. Start the discussion BEFORE you start creating any pages on the wiki. We're not using the wiki as a general "scratch pad". If you can't summarize the problem you are trying to solve in a short email, and feel like you need a long document, you're probably trying to solve too big of a problem

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.

Step 2: Gather Examples, Similar Projects and Documenting Current Behavior

Document examples of current human behavior. Why examples first?

Remember, we're paving the cowpaths (http://ifindkarma.typepad.com/relax/2004/12/microformats.html)- before you do that you have to find the cowpaths. Your examples 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 analysis.

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.

If several people on the microformats-new mailing list have stated that they are interested in working on your problem statement, and gather examples. You should also note every file format

1. Gather example URLs
   1. Example URLs that contain publishing behavior should be gathered. For example, if you are attempting to come up with a new image metadata microformat, you would collect website URLs that publish image metadata (such as Flickr).
2. Gather example file and markup formats
   1. Example file formats and markup formats that demonstrate publishing behavior should be gathered. For example, if you are attempting to come up with a new image metadata microformat, you would collect file formats that are capable of encapsulating image metadata (such as as the EXIF file format).
3. Create and populate the examples page
   1. You will want to create an examples page on the wiki. For example, if you are gathering image metadata examples, you could name the page image-metadata-examples. Place all example URLs into this page. For more guidance, take a look at the audio-info-examples page.
4. Create and populate the formats page
   1. You will want to create a formats page on the wiki. For example, if you are gathering image metadata formats, you could name the page image-metadata-formats. For more guidance, take a look at the audio-info-formats page.

Step 3: Analyze the Examples for Common Attributes

Microformats are based on sound research, logical analysis and thorough vetting of the data that you have gathered. This is one of the most tedious parts of the process, and if you do not perform a thorough job at this stage, it will come back to bite you.

1. Determine common properties
   1. It is important to define and keep track of common properties found throughout the process. If you were analyzing image metadata, for instance, you would probably define the title, summary, formatted name, and publish date properties. The list will grow as you perform more analysis. Make sure to clearly define each common property so that others will know what you mean in your analysis. For an example of defining common properties, here is the definition for the audio-info title common property.
2. Analyze each example URL
   1. Once a set of common properties have been defined, start analyzing each example URL that you have collected. Note which common properties are published on each page. You will have to add common properties to the list as you find new trends while analyzing your data. Here is an example of how you can document this analysis on the wiki: audio-info analysis documentation
3. Analyze each format
   1. Perform the same type of analysis that you performed on the example URLs on the file formats and other semantic formats you have gathered.
4. Perform aggregate statistical analysis
   1. After you have completed analysis of all URLs and formats, you should perform a statistical analysis on the aggregate data. You will need hard numbers that are backed up by data to prove your point on the microformats-new mailing list. For an example of what the aggregate analysis should look like after it is completed, the aggregate analysis of music services section of the audio-info page may be of help.

Step 4: Check your work, Start Brainstorming, and Ask for Feedback

It is important that all of your findings are thoroughly documented on the wiki. You will be able to make process easier if everybody understands the data gathered. It is important that your analysis is sound and doesn't leave any open questions.

1. Ensure that you have the basics
   1. At this point you should have an examples and formats page. The examples page should contain:
      1. A Problem Statement
      2. Common Properties and their definitions
      3. A statistical analysis of all aggregate data
2. Create and populate the brainstorming page
   1. The brainstorming page is where most of the discussion on the mailing list will be documented. It is important to propose a starting point to the mailing list. Identify the common properties that you think should be included in the microformat based on the analysis. Be as minimalistic as you can. Do not propose anything that is not backed up by hard data. An example of how to propose common properties, also known as Discovered Elements, can be found on the audio-info Discovered Elements section of the audio-info-brainstorming page.
3. Ask for Feedback
   1. Send an e-mail to microformats-new stating that examples gathering and analysis has been completed for your microformat and that you would like to start brainstorming usage scenarios, markup and work toward a microformat draft specification.

Brainstorming is best done with as much community involvement as possible. There are a number of people that have been involved with microformats for years and can provide valuable direction for your microformat.

1. Discuss each Discovered Element
   1. Each discovered element that you identified in the previous step must be discussed thoroughly. See if there are any objections to your proposal and discuss alternatives.
2. Update the brainstorming page
   1. For every element, you will want to discuss re-using property names from other microformats, alternatives, benefits and drawbacks. Make sure to document the discussion in a way that is non-confrontational and fair to both sides of the argument.