From Microformats Wiki
examples /
Revision as of 04:59, 7 April 2013 by Tantek (talk | contribs) (Reverted edits by ABIDEEN10 (Talk) to last version by Tantek)
Jump to navigation Jump to search

<entry-title>Best Practices for Examples Pages</entry-title>

*-examples pages are the first stage of the exploration The microformats process which must precede proposing a new microformat. Current explorations are listed on the Welcome to the microformats wiki!. You can use the *** examples to help you create your own page.

Purpose of Example Pages

(adapted from The microformats process)

Document current human behavior on the Web. 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 analysis.

Current Human Behavior on the Web



  • This is what people are doing now on the Web.
  • This is not:
    • what people did 50 years ago
    • what you expect people to do in the future


Explicit user entered and published information. While automatically published information such as logs from an eletronic thermometer can be interesting, they are not human produced (unless said thermometer is stuck in a human, and that's only indirect/implicit/uncontrolled) and thus do not reflect what humans themselves explicitly do.


  • What people actually do. Think empirical evidence, much as in the same way that the scientific method requires gathering of empirical data.
  • not:
    • what they might do
    • should have done
    • would do
    • Intention/Desire/Want. A common mistake done by folks researching background for formats is to explicitly *ask* folks what they *want* or *prefer*, as opposed to *studying* what they *do*. It is well known among behavioral researchers/surveyors that *asking* people what they *want*, or even *asking* people what they *do*, will give you very different (and worse / less accurate) answers than actually *studying* what they *do* in the real world.
    • Formats. Formats are prescriptions for behavior, not behavior itself. For documenting formats, create a *-formats page.


  • The examples MUST focus on examples actually published on the Web, at a publicly available URL, which should be documented along with the example itself on the wiki page.
  • Non-web examples are ok *only* for secondary/tertiary consideration, and by no means outweight (no matter what their quantity etc.) the Web examples.
    • private files
    • paper
    • etc.

Recommended sections

Top level (<entry-title>):

  • Introductory sentence

The following items can be used as second level headings == ... ==

  • purpose
    • What is the purpose of this exploration?
    • What real world problem(s) / user-scenarios are being solved?
  • real world examples
    • Links to public web pages, either popular or insightful
  • analysis of publishing practices
    • Summary and analysis of common patterns discovered from above examples
    • Other attempts to solve The Problem (other actual Best Practices for Formats Pages belong in the *-formats page)
  • see also
    • Link to related pages as they become available
  • next steps
    • *-formats
    • *-brainstorming

Details on specific sections:

real world examples section

  • Flat list at a minimum. The real world examples section should be at a minimum a flat list of examples. See further down for what a good example has.
  • Grouping into categories can help. A giant flat list of examples can sometimes be difficult to navigate and analyze as a whole. Consider grouping related examples into a flat list of categories. If you're not sure how to categorize the examples, or if there are multiple axes across which you could categorize the examples, ask on the #microformats chat channel or mailing list.

Good Examples of Examples

The following pages are some of the best examples of instantiating this design pattern:

A Good Example Has

A good example has several things:

  • URL to the actual example on the Web
  • Link text of that hyperlink should look like a citation of that example, e.g. who, what site
  • Perhaps an illustrative snippet of code (markup) from the example
  • Analysis of the implied schema represented by that snippet, with at a minimum a flat list of the "fields" present in the example snippet.

When Adding Examples

When adding examples to an existing *-examples page, please try to add the examples into the existing organizational structure in the page. E.g. if the examples are grouped or categorized in a certain way, try to add new examples into those existing categories, instead of a new section.

If you have to add a new category or subsection, do so, but try to do so in harmony with existing categories. If it is not obvious how to do so, or if the categories don't seem to make sense, then it might be a good time to ask a question on the #microformats chat channel or mailing list.