introduction: Difference between revisions
m (→Stub note) |
|||
Line 43: | Line 43: | ||
This page is a stub and could certainly use some contributions, especially from folks new to [[microformats]], and what key points and details from their perspective helped explain to them what microformats are, why they matter, what benefits they provide to web designers, information architects, web developers, web programmers etc. - [http://tantek.com/log/ Tantek] | This page is a stub and could certainly use some contributions, especially from folks new to [[microformats]], and what key points and details from their perspective helped explain to them what microformats are, why they matter, what benefits they provide to web designers, information architects, web developers, web programmers etc. - [http://tantek.com/log/ Tantek] | ||
== Miscellaneous Reference == | |||
These are various intro-related links/articles which I haven't figured out yet how to incorporate. You may find them of interest. - [http://tantek.com/log/ Tantek] | |||
* [http://www.betaversion.org/~stefano/linotype/news/93/ Data First vs. Structure First] | |||
** [http://tantek.com/log/ Tantek] says: In many ways it is actually *far* worse than that post conveys. The "typical" programmer literally loves spending far more time worrying about and designing the structure for structure's sake, than data, and even less so, "real world" data (current behaviors etc.). Hence we have taken the directly opposite tack with microformats when looking to solve a problem. | |||
*** Zeroeth, define the real-world problem. If you can't do this, then stop. | |||
*** First, look at real-world usage (data). | |||
*** Second, what previous standards are people actually using today? If there is more than one, then lean towards those with the better adoption. | |||
***And only after those first two do we bother to pay attention to theoretical standards, those that have been invented (whether by individuals, committees), but haven't seen much if any actual adoption. |
Revision as of 01:54, 30 July 2005
Introduction to Microformats
- Andrew D. Hume has written a blog post introducing microformats and another one on usable microformats.
- See microformat presentations for more background and introductory material on microformats.
- Recent press interviews and articles are also a good introduction.
Why Microformats
Why did we come up with microformats?
In short, microformats are the convergence of a number of trends:
- a logical next step in the evolution of web design and information architecture
- a way for self-publishers to publish richer information themselves, without having to rely upon centralized services
- an acknowledgment that "traditional" metadata efforts have either failed or taken so long to garner any adoption, that a new approach was necessary
- a way to use (X)HTML for data.
Evolution of Web Design
In the beginning (1990), there was HTML and it was good. It was simple, minimal, and used to semantically markup user visible data (text) and share it on the World Wide Web.
Then came the browser wars (1994-1999) where dominant browser manufacturers took their turns introducing "innovative" presentational tags, giving the typical web author/designer what they wanted: a semblance of control over the presentation of their webpages. The result: HTML 3.2 "standardized" these defacto presentational innovations.
The introduction of CSS1 (1996) and the semantically richer HTML4 (1998) brought a glimmer of hope, but it wasn't until years later (2000-2001), with the introduction of fully compliant (or almost) implementations of CSS1/HTML4 (IE5/Mac, IE6/Windows, Netscape 6) that it became practical for web designers to depend on CSS in their web pages. Leaders in the community began to furiously adopt and promote CSS (even if it took a hack or two) and the efficiencies and enhanced productivity that separating presentation from markup brought them, yet remained a small vocal minority.
The introduction and growth of the CSS Zen Garden (2002-2003) was CSS's tipping point. With the clear and obvious presentation of visual beauty and broad creativity, designers world-wide "got it" and realized that this was the future of web design. The presentational markup of <FONT>
, <TABLE>
, and spacer.gif
were tossed aside by any and all self-respecting web designers, who discovered the near infinite flexibility of <div>
, <span>
, and the 'class' attribute. A few in the community even began adopting some of the more semantic elements in HTML: <p>
, <h1>
...<h6>
, <ol>
, <ul>
, <li>
, <em>
, <strong>
. Leaders in the community exercised the semantic limits of strict HTML4 (experimented with XHTML) and documented best practices.
As the community followed rapidly in the footpaths they had worn, the leaders began to run into the limits of semantic (X)HTML. Other subcultures were attempting to rewrite the world in their own language(s) (RDF, "plain" XML, SVG), yet not having much of an impact on the World Wide Web, which required human presentable data, compatible with the browsers people already used. Social Software and Blogs, written by this new generation of web designers and programmers, began to take off.
Natural patterns emerged from the way people used blogging systems, putting things into lists, for example lists of other bloggers (known as blogrolls), and annotating them with information representing relationships such has having met, friends, family, etc. The first microformat, XFN, was designed to match these behaviors, and introduced to the blogging community (2003-2004), who adopted it within weeks. The GMPG was formed as a home for XFN, and documentd a few key design principles later adopted for microformats. The key notion, that semantic (X)HTML could be extended, had been introduced and accepted by the community.
By understanding, using, and combining semantic (X)HTML building blocks, as well as determining that semantic (X)HTML could be validly extended via new rel, meta name, and class values, defined in (X)HTML profiles in the XMDP format, the community began to design and develop many more microformats (2004-2005). More patterns emerged from the blogging community, and each aggregate human behavior drove the design of simple, adaptive microformats to meet its needs. Creative Commons licensing became popular and rel-license was proposed. Outlines and lists: XOXO. Contact info: hCard. Calendars and events hCalendar.
Using these new found building blocks, the web design and information architecture communities were no longer limited by the predefined semantics of HTML4 (nor did they have to compromise human presentation and ease of authoring which other attempts sorely lacked). 2005 may well be the year that microformats became the next step in the evolution of the web.
The Appeal to Simplicity
- Microformats are a simple effort which has appealed to many frustrated with previous complex efforts. One parallel that can be drawn is to REST in the web services world, i.e. see this comparison of microformats and REST.
- See also: Web Services and the Innovators Dilemma by Justin Leavesley
Stub note
This page is a stub and could certainly use some contributions, especially from folks new to microformats, and what key points and details from their perspective helped explain to them what microformats are, why they matter, what benefits they provide to web designers, information architects, web developers, web programmers etc. - Tantek
Miscellaneous Reference
These are various intro-related links/articles which I haven't figured out yet how to incorporate. You may find them of interest. - Tantek
- Data First vs. Structure First
- Tantek says: In many ways it is actually *far* worse than that post conveys. The "typical" programmer literally loves spending far more time worrying about and designing the structure for structure's sake, than data, and even less so, "real world" data (current behaviors etc.). Hence we have taken the directly opposite tack with microformats when looking to solve a problem.
- Zeroeth, define the real-world problem. If you can't do this, then stop.
- First, look at real-world usage (data).
- Second, what previous standards are people actually using today? If there is more than one, then lean towards those with the better adoption.
- And only after those first two do we bother to pay attention to theoretical standards, those that have been invented (whether by individuals, committees), but haven't seen much if any actual adoption.
- Tantek says: In many ways it is actually *far* worse than that post conveys. The "typical" programmer literally loves spending far more time worrying about and designing the structure for structure's sake, than data, and even less so, "real world" data (current behaviors etc.). Hence we have taken the directly opposite tack with microformats when looking to solve a problem.