On 5/8/06 1:47 PM, "Chris Messina" <[EMAIL PROTECTED]> wrote:
> On 5/8/06, Drew McLellan <[EMAIL PROTECTED]> 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 _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
