[uf-discuss] awesome examples of microformats, faqs

[Tantek Ç elik]

On 5/8/06 1:47 PM, "Chris Messina" <chris.messina at gmail.com> wrote:

> On 5/8/06, Drew McLellan <lists at allinthehead.com> wrote:
> 
>> I think what Chris is getting at (and forgive me if this is wrong,
>> Chris ...) is that we can all see the massive benefits of
>> microformats - but it's all slightly academic. As technical folk, we
>> know that structured data is important and valuable, and therefore is
>> practical to us. However, your average web designer isn't used to
>> knocking up perl scripts to parse juicy data out of a page to use for
>> something awesome. It's this crowd that needs to see practical
>> examples of full round-trip use (like live clipboard) before they'll
>> 'get it' and see the benefit enough to start implementing in earnest.
>> 
>> Is that right Chris?
> 
> Yes, that captures pretty much what I'm getting at.

I really like Drew's summary.


> And I'm all about getting real/concrete and so on to make
> microformats.org a much more useable resource for all comers --
> whether core "committers" in the community, whether casual web
> developers, whether bloggers, the media, template creators...
> whomever. This stuff isn't rocket science but you wouldn't know it
> with words like "normative" and "n optimization" flying around!

Perhaps we should start a wiki page with a list of "rocket science" words so
that we can seek to avoid them (except in the specifications where you MUST
(RFC2119) be precise :)


> I mean, even the definition would turn most humans off -- and
> microformats are for humans!

With all due respect Chris, I have to disagree.

I'm certainly not saying the current definition is perfect or anything, but
it's been quite effective in at least piquing the interest of folks who have
been able to both use microformats, and help them grow over the past year.

In fact, and I know you and Tara hate this word, but the definition has been
downright *viral* since we launched, and has propagated across HUNDREDS of
websites:

<http://www.google.com/search?q=%22Designed%20for%20humans%20first%20and%20m
achines%20second%2C%20microformats%20are%20a%20set%20of%20simple%2C%20open%2
0data%20formats%20built%20upon%20existing%20and%20widely%20adopted%20standar
ds%22>

Part of the original challenge for microformats was to distinguish it from
all previous (and current attempts).  We needed to answer the implicit
question of - why are microformats DIFFERENT than all previous efforts at
data formats for this kind of thing, and thus we focused on those
differences:

 1. humans first machines second (rather than designed for machines first,
e.g. XML, RDF)
 2. simple (rather than complex and unwieldy for common cases)
 3. open (rather than encumbered by patents, or costing $$$ to buy printed
copies of the specs from various international standards organizations)
 4. built upon existing and widely deployed standards (as opposed to
numerous efforts at reinventing the wheel, e.g. every "profile" format out
there that started from scratch rather than building on vCard
<ahem>hailstorm, foaf, infocard</ahem>)

In essence, the definition is a very tight compression of the core
microformats *principles* - you could do a presentation on microformats just
by starting with the short definition and illustrating each point with
examples and contrasting comparisons.

However, we've both reached those hundreds of early eager propagators of the
message, and built something which stands on its own.  I used to get asked
all the time "How is this different than XML (or whatever)?" and now rarely
see that question (the recent query on the email list was the first I had
heard it in quite some time).  Yes, there are still some "Megaformats"
hold-outs and there will always be.  There are still SGML folks that hate
HTML, but guess what?  They're wrong and you'll never convince them.

Let's not waste any time on trying to convince folks who stubbornly don't
want to be convinced.  At some point, you realize it is worth more of your
time to pursue new folks, and just depend on the larger numbers of new folks
to eclipse the stale ranks of curmudgeons.

Perhaps it is time that we evolved the definition, to reach the thousands or
millions we SHOULD be reaching, those that have never heard of XML, RDF
etc., or have, and are frightened (or just have no desire or time) to learn
more than their comfortable and well established (X)HTML+CSS.

I meant to do this the last time the whole "definition-smithing" email
torrent erupted, but simply fell behind on it.

We don't need to settle for any one definition.

Or rather, if you think you've got a better definition that you're willing
to put your name next, go ahead and put it on the wiki and put your name on
it.  Let's build on each others' work, while allowing folks the freedom to
express "What are microformats?" in their own words.  Perhaps we'll pick one
of the new definitions for the home page, or perhaps we'll pick a set and
rotate them - we can decided that later.

For now, go express yourself on this wiki page:

 http://microformats.org/wiki/what-are-microformats


> One popular definition from our mailing list
> (http://microformats.org/discuss/) (see also: mailing-lists) is
> "simple conventions for embedding semantics in HTML to enable
> decentralized development."

I've added this to the above wiki page.


> More precisely, microformats can be
> defined as:
> 
>   simple conventions
>   for embedding semantic markup
> 
>       for a specific problem domain
> 
>   in human-readable (X)HTML/XML documents, Atom/RSS feeds, and "plain" XML
> 
>       that normalize existing content usage patterns
>       using brief, descriptive class names
>       often based on existing interoperable standards
> 
>   to enable decentralized development
> 
>       of resources, tools, and services

Also added.


> How does rails describe itself? As an "opinionated framework for
> developing web applications and has a considerable amount of
> flexibility in the back end."
> 
> Pretty plain spoken if you ask me.

"framework" ?
"back end" ?

These are not "plain spoken" terms.  These are heavily loaded geek terms as
much as "normative" or "optimization".

And what makes a framework "opinionated"?

The point is, any such "sound-bite" definitions are going to have problems
with either being too vague to be useful, or too "rocket science" to be
accessible.



> So what are microformats?
> 
> "Microformats are simple codes that you can use to identity specific
> kinds of data, like people or events, in your webpages."

Added to the wiki.


> Why would you use them?
> 
> "Microformats make it easy for you or anyone who can see your webpages
> to reuse or your data and content elsewhere -- for example, to
> populate an address book, examine social relationships, share reviews,
> tag content or publish events."

This is good stuff Chris.

In a similar fashion, I'd love to see what other folks think you can do with
microformats and why you use them.

I've create this page and seeded it with Chris's description:

 http://microformats.org/wiki/what-can-you-do-with-microformats

Please feel free to jump-in and add a section describing what YOU think is
important about what you can do with microformats.


> Something like that. On the current site, we have "Designed for humans
> first and machines second, microformats are a set of simple, open data
> formats built upon existing and widely adopted standards" which talks
> about what they *are* but not what you can *do* with them!

I think we need both what they *are* and what you can *do* with them.


> So yeah -- anyway -- improving language is one thing,

Agreed.

> improving the
> site architecture and discoverability is another.

Agreed.

If you have such a list of things you think should be improved, and want to
help do so, please add them under your name on the To Do page:

 http://microformats.org/wiki/to-do


> I've been in touch
> with Drew and a woman named Vera who is an instructional designer
> about improvements to the site.

Great!

If you can capture Vera's suggestions also on the "to-do" page that would be
a big help.  It's best to document thoughts on things like this before
making lots of massive changes.


> I've created a series of icons for the
> Mac for microformats that I'd like to release soon...

Then release them and iterate!  They don't have to be perfect!  Just do it!

Perhaps post them here for starters:

 http://microformats.org/wiki/buttons

with whatever caveats you feel you need to add.


> I want to smooth
> the transition between the great-looking homepage and the wiki.

Add it to your /wiki/to-do


> I want
> more visual examples and, as Drew said, I want more round-trip
> examples that make people go "holy sh!t that's amazing!"

Add it to your /wiki/to-do


> I'm open to ideas on how to organize this work.

Add it to your /wiki/to-do


> I can open up a
> Basecamp account if there's interest (despite Tantek's dislike of the
> tool).

We don't need yet-another-tool - that's my bigger objection.

There's a pattern in organizations where people fall into the trap of
thinking that using a new organizational/project-management/email/calendar
tool/application is the key to solving all their to-do / project management
problems and it is almost always wrong.

The key is keeping process to a minimum and enabling people that want to
help, to actually help with a minimum of process and ceremony.  That's one
of the reasons why "corporate" project management tools almost always fail
(or slow things down horribly) in non-profit/volunteer contexts.  No one
(nearly no-one) actually *likes* using project management tools unless
they're both paid and ordered to do so (which typically happens only in
corporate settings).

While the wiki is not perfect, spending a lot of time
tool-thrashing/rehashing is certainly no better and in some cases worse, if
the tool forces you into a particular way of thinking or working, which is
why I have an aversion to such "project management" tools.  Nevermind that I
just hate data roach motels in general.  Most "project management" tools,
whether binary or ASP have these problems in spades.


> As Ryan pointed out, it's true, it's time for me to quit my
> bitching and start getting something done. Busy as I am, I think we
> can work incrementally -- but my concern at the moment is bringing
> more help in and sustaining the effort.

I think getting at least some amount of work done is actually *more*
important than bringing more help (c.f. mythical man month).

So yes, focus on getting something done, and if there are things you want to
get done but are "stuck" on for whatever reason (like requiring help or
consensus from other folks), go ahead and stick on /wiki/to-do - that may be
just the way to get other folks to help out with what you want to get done.

Thanks,

Tantek