This is the definition that got me interested in Web 2.0 in the first place. It makes sense, easily contrasts with “desktop as platform”, and is accurate: we are seeing a tremendous platform move to the Web.

Unfortunately, sometime after Tim used this definition way back when, it went haywire and eventually ended up meaning nothing more than the Web itself. And really, that’s all it is…just a trend on the Web. In addition, O’Reilly went the VC route, focusing on business people while alienating technologists.

I don’t harbor negativity for someone who has a meme that helps people understand what’s going on. Ajax, web standards, SAAS, P2P, and other things are all figments of the imagination…they’re just other words for technologies that do certain things. And holding events is fine, too. People make the choice to come, let them come. Everybody has a flag to fly.

So, I applaud Tim returning to the original definition, after all this time. Don’t try to be everything to everyone.

However…it’s still not nearly as compact as it *could* be, and it’s not really a business revolution…it’s a technological trend.

In addition to “leveraging” this or that, how about focusing on building stuff that people love? Could that be part of all this? Or does it have to be about “network effects applied to user contribution”?

My guess is that if you focused on one and not the other, you’ll be much more successful than vice-versa.

“Some things are clearer with hindsight of several years. It is necessary to evolve HTML incrementally. The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn’t work. The large HTML-generating public did not move, largely because the browsers didn’t complain. Some large communities did shift and are enjoying the fruits of well-formed systems, but not all. It is important to maintain HTML incrementally, as well as continuing a transition to well-formed world, and developing more power in that world.”

Read Re-inventing HTML

Web technologies, yes, but these sites certainly do not validate, which if you ask any standardista, is absolutely necessary. Joe Clark states the most extreme view: “It indicates not merely unprofessional Web-development practices but outright incompetence.”

However, I think this is the wrong message to send to fellow web designers. Designers should not dismiss sites simply because they don’t validate. They should judge sites on completely different criteria: usefulness. After all, the three sites I mentioned above are some of the most useful sites out there…are their designers unprofessional or incompetent?

The answer is not “no”. It’s “who cares?” Who cares whether or not the designers are incompetent if they consistently deliver their users a great user experience? Certainly not the folks who are happily using the sites…they wouldn’t care a whit. The fact that a site doesn’t validate says more about the designer’s priorities than it does about their competence.

So instead of tearing down designers whose code doesn’t validate, let’s re-evaluate our work by asking what is the most important thing we can do to make our user’s experience better? Let’s question the questioners, and not view the world in black (does validate) and white (doesn’t validate). Some time ago I wrote a long riff about why we are having trouble articulating design.

Anyway, here’s a start:

The most important standards on the Web are not technological, they’re social. They are the standards that software and web sites need to reach before people find something useful. If you can, yes, use web standards to make your app more accessible, or to save on your bandwidth costs, or give you better visibility among your peers.

But standards are a false idol, and praying to validation is putting technology before humans. The mere act of validation doesn’t suddenly make something accessible to all, so judging designers on validation doesn’t say much either. Don’t make standards validation an absolute necessity if they’re going to hold you back from coming up with something like Gmail that completely changes the way we use the Web.

Features

• SVG support
• Support for the <canvas> element
• CSS 3 Columns
• DOM inspector
• Javascript console
• Syntax highlighting on view source

Supported web standards

• Hypertext Markup Language (HTML) and Extensible Hypertext Markup Language (XHTML): HTML 4.01 and XHTML 1.0/1.1
• Cascade Style Sheets (CSS): CSS Level 1, CSS Level 2 and parts of CSS Level 3
• Document Object Model (DOM): DOM Level 1, DOM Level 2 and parts of DOM Level 3
• Mathematical Markup Language: MathML Version 2.0
• Extensible Markup Language (XML): XML 1.0, Namespaces in XML, Associating Style Sheets with XML Documents 1.0, Fragment Identifier for XML
• XSL Transformations (XSLT): XSLT 1.0
• XML Path Language (XPath): XPath 1.0
• Resource Description Framework (RDF): RDF
• Simple Object Access Protocol (SOAP): SOAP 1.1
• ECMA-262, revision 3 (JavaScript 1.5): ECMA-262

See the Mozilla Firefox 1.5 Beta for Developers page for more info.

Mark Pilgrim has written a book on the subject: Dive Into Greasemonkey.

The article he was writing is now online: Battle lines drawn again between browsers. In it Fontana provides an overview of the current browser tension between Firefox and IE.

You’ll find a short quote in the article from me (and thankfully it is one that I still agree with):

“I would say going forward that AJAX is going to have a ton of focus and support behind it,” says Joshua Porter, research consultant and director of Web development for research firm User Interface Engineering. “Because it is built on open standards, it is going to be the next plateau that we reach on the Web, like with HTML.”

On this note, I was listening to a podcast earlier today called The Platform Revolution that included Kevin Lynch of Macromedia. He talks about HTML not being robust enough for most web application needs, and suggests that Flash is becoming the front-end application tool of choice.

I think that developers will soon prove Lynch wrong, as they (WE) value open, de facto standards over proprietary tools.

I had the writing duties on this one, and it wasn’t easy. What I tried to do was to use a relatively innocuous definition of “semantic” and expand on it to show how we might be writing markup going forward. I also had to balance the idea that XHTML had semantic elements but wasn’t really fulfilling that purpose, for better or worse.

Let me know what you think.

To begin, what would this new site, a self-proclaimed “anything and everything” microformats resource, say about them? A little surprisingly, nothing all that new description-wise (we’ve had this and this for a while now), but very nicely laid out and all in one place, which is useful for folks trying to learn about them. (I did find it interesting that the developers have migrated the discussion away from the corporate Technorati site). Anyway, here is the microformats “elevator pitch” from the home page:

Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards.

Formats for Content Markup

So, they’re formats for marking up content. Here’s an example of a calendar entry using the microformat hCalendar:

<span class="vevent">
 <a class="url" href="http://www.web2con.com/">
  <span class="summary">Web 2.0 Conference</span>:
  <abbr class="dtstart" title="20051005">October 5</abbr>-
  <abbr class="dtend" title="20051007">7</abbr>,
 at the <span class="location">Argent Hotel, San Francisco, CA</span>
 </a>
</span>

The idea is that another application can read this hCalendar snippet within your XHTML page and instantly recognize it as such. So, Search Engines (an application, don’t ya know) can now come to your site, find all the embedded hCalendar snippets, and then know more about what your page’s topic is. Your search rankings would presumably rise as a result.

So this is cool, right? We’ve got a more semantic way to express our data, so that in addition to the people who actually read our content it is more meaningful to the machines that suck our sites down as code. The only problem is that to succeed the machines that suck down this code must know what an hCalendar entry is, and then must know what to do with it once it finds one.

Microformats Have to Be Supported to Work

Therein lies the rub with microformats. If they aren’t known about by the applications that are reading them, then they’re essentially a waste of our development time (to put it bluntly). In other words, only when application developers agree to “support” the microformats will they actually lead to any of the benefits that have been promised.

So, what about support? Are there widely supported microformats? I suppose that would depend on who you asked, and if they were part of the group that was supporting them. Technorati, for example, whose employees are behind a lot of the development of microformats, supports them rather well. If you use the rel-tag microformat, for example, Technorati will recognize it when it is notified of your post, and include your page on their corresponding tag page. Here’s an example of using the rel-tag microformat to create a “microformat” tag (in effect I’m tagging this page as having to do with microformats):

microformats

The code is this:

<a href="http://technorati.com/tag/microformats" rel="tag">microformats</a>

Besides Technorati, there are few services that actually support microformats. They are all potential at the moment, but with this new site they just might gain momentum.

Trend Toward Markup that is More-Semantic

Microformats get really interesting, however, when we take a wider look at them. For example, notice that in using microformats developers are starting to write semantic markup that actually distinguishes content in a meaningful way, providing much more meaning than the 100 or so XHTML tags can on their own. You’ll notice in the above hCalendar example that the <span> tag is used in conjuction with the class attributes to provide semantics. Not pretty, but at least one rung higher on the semantic ladder than plain old XHTML.

The level of semantic integration is also interesting. Instead of going “all the way” and writing new XML formats for these types of data, the microformat folks want us to write extended XHTML formats. Still XML, but not a separate format free of the <span> tag affliction.

To this we must ask: WHY?

Why Microformats and not a New XML Format like RSS?

Could it be for developer adoption reasons? If we ask HTML coders to simply alter their code rather slightly, adding some attributes, would they be more willing to change their markup than if we asked them to write in a completely new format? This makes some sense, assuming that folks are willing to adapt their coding styles to anything other than what they’re currently doing. Unfortunately, the instances where coding conventions are widely adopted are few and far between. (we’re still vacillating with web standards in the first place). We’ve all got our own way of writing tags, and changing that is a big challenge.

Could it be for application adoption? If we create microformats that merely extend XHTML, will that mean that they offer greater utility because we’ve already got browsers that understand that markup? I’m skeptical about that, because right now browsers can understand microformats only as XHTML, with no further meaning. In other words, as of right now browsers don’t do anything special with microformats other than to display them as XHTML. They won’t do anything special until they are programmed to explicitly. This is the same with any new XML format, whether they extend XHTML or not.

We Need a Showcase Application of Microformats

My main concern is that microformats aren’t obviously useful yet, despite such excellent resources as Eric Meyer’s Potential of Microformats presentation. Specifically, nobody has come up with an application for them (that I’ve seen) that makes the benefits of them plain as day. What I’m looking for is an analogue to Housingmaps.com, which shows in an instant why anyone would want to hack Google Maps. There is no such example yet, that has me wanting to go back and rewrite part of my content as well as write it that way in the future.

Interesting notions exist, however. Back in March Adrian Holovaty suggested a rel-proof microformat, which would be applied to facts within news articles to let other applications know about other supporting facts. Interesting, until you think about how political parties might use it as they attempt to control the news. Alas, no implementation of that one has surfaced.

What I’m really excited about, though, are the brand new XML formats that don’t extend XHTML, but live on their own. Several examples come to mind: RSS, OPML, and Google Sitemaps. All three of these formats require their own, separate XML file to work. But all are receiving as much and more attention than microformats. RSS, in particular, has gone to the moon. So at first glance it doesn’t seem that being a separate format is a detriment to adoption: my guess is that usefulness is the real barrier.

To re-address these formats in terms of the goals of microformats…it seems that the three specialized formats that I mentioned are fulfilling those goals nicely. They are a way of thinking about data. They’re easy to use by humans and machines. They solve a specific problem. They’re simple. They take advantage of what people are already doing (tagging). They reuse building blocks from widely-adopted standards (XML). They enable and encourage decentralized development, content, and services.

Not on the Bandwagon Quite Yet

So, given that we have very successful XML formats like RSS, aren’t microformats a step backward? Even though they are a stepping stone on the way to semantic purity, microformats still don’t offer a good clean cut from the muddle of XHTML tags like the other formats do. They’re playing nicely, which is, well, nice, but they’re still obscured by the semantic limitations of XHTML. That’s not to say that they won’t work. I’m just saying that they seem rather messy compared with their independent counterparts: thinking about my content as part non-semantic XHTML and part somewhat-semantic microformats is confusing. I think this is is a challenge that will need to be faced if microformats are to be widely adopted. As a result, I’m still not on the microformats bandwagon. However, given that tomorrow morning something in the world of formats will be different, I’m still open to discussion.

Update: David Weinberger interviews Tantek Çelik and Rohit Khare about microformats. They offer some good details about the issues, and address concerns that came up in the article and comments.

In particular, Tantek talks about keeping all this simple: that microformats are written in XHTML because that’s what developers are used to. This is right, of course, but we also see that developers are now “used to” RSS in very nearly the same sense. RSS is easy, because the tags don’t change…and there are no superfluous span or div tags cluttering it all up. That’s the beauty of XML…I don’t know why we would want to get away from that. That said, I do believe that Tantek and the folks working on microformats are pushing this with enough zeal that they may be able to build up momentum to have it work, but this developer would much rather write simple, semantic tags like I do in RSS than hack an already over-extended XHTML.

Update: Bud Gibson, in addition to adding comments below, has written a post highlighting further his vision of why microformats are important. I’m very happy that he’s taking the time to explain all of this. He says that microformats fill dual roles, one as XHTML and one as XML. His clincher is this: “they can fulfill the data transmission role without requiring any sort of translation prior to presentation to the user”. This is absolutely correct, but I don’t see this as a big problem: millions of blogs are being simultaneously transmitted in XHTML and XML daily. That is one of the reasons why we’re using XML, in my view, because it allows translations between formats with ease.

I think I see now another reason why I just don’t like microformats. I don’t buy them as playing the XML role, as in Bud’s view. The main tag used is <span>, and is stuck in an XHTML file with a whole bunch of non-semantic code. How does it fulfill the XML role, in the same ways that RSS does? I love that with RSS we have a separate URL and every tag is semantic, accurately describing the content it contains. With microformats we have a bunch of code in between used to make it XHTML. I want simple, efficient code used for a single purpose only. I can imagine a separate URL on bokardo, something like bokardo.com/calendar for example, that is simply my personal calendar published for all to see (not in the hcalendar microformat, but perhaps xcalendar?). If my calendar is wrapped up in an XHTML file, how will people find it and parse it out? What if there is no calendar information, or my most recent post doesn’t contain calendar information? How will we be able to generate metadata about microformats if we don’t have static feed URLs that we can rely on? I think I find separate URLs comforting…

Join the microformats discussion | microformats.org | Bokardo Interface

I don’t think it is a stretch to say that the Web and blogging is a huge turning point in media coverage in particular and democracy in general. Ideas are spreading (and being forgotten) faster than ever before. If we can represent each of these ideas clearly and thoughtfully discuss them, then democracy will blossom.

Two battles, though, seem to be resistant to this democratic openness that the web exhibits every day. They are battles that we shouldn’t have to fight: that are, I believe, supported less fervently because they seem so obviously unnecessary; these battles shouldn’t exist.

One is the Battle for Peace, and the continuing struggle to show those in power that War should be the last of all possible resorts, no matter what people are involved, what party is in control of the White House, or who wants to win the next election. This battle has been waged ever since humans had the intellectual power to decide not to fight. But the battle has been getting louder since 9/11 and its aftermath, when the U.S. responded to terrorists by bombing Afghanistan and then, after failing to capture Osama bin Laden, began the subsequent bombing of Iraq, which to this day has not been directly connected with the terrorist acts that started it all.

Almost every American supported the country’s initial response of going into Afghanistan. After all, these were the terrorists who killed thousands of people in New York and Washington and Pennsylvania. But the war in Iraq was a different story. Many people, including myself, saw that the U.S. was not in the position of last resort. There was no imminent threat, and simply put, these were not the terrorists who threatened us at that time. To us, there is simply no question that this was Wrong. Thousands of web sites, including this one, protested the War on Iraq by replacing their home page with ones sharing the same sentiment: War in Iraq is Not the Answer.

Because this was, and remains, an unnecessary act of War to many Americans, we tend to become cynical about it, not knowing what we can do to help stop it. We suppress our basest feelings of disgust and jump feverishly into the fray of the political arena: but we only end up distracted from the real issue of innocent Americans and Iraqis dying. We try to show those who continue this treachery that we know better than them, and we tend to do this in the language of sarcasm, Doonesbury-style. But has this been effective? Or has sarcasm become the refuge of the powerless?

The other battle, though not as timely as the one currently in the news, is the Battle for Web Standards. More specifically, the battle for widespread implementation of Web Standards on the Internet. This affects Americans nearly as often as the Battle for Peace, but it goes on in a much less spectacular fashion and the stakes aren’t life and death. This one is near and dear to me, though, because I make my living, in part, by designing web pages using Web Standards.

The Battle for Web Standards is being fought against an equally powerful juggernaut as the Battle for Peace. The foes are large corporations like Microsoft who control the software that most people use every day to communicate with all our loved ones, our friends, our colleagues, and fellow researchers in life. By failing, in such obvious fashion, to support Web Standards and choosing, instead, proprietary implementations, these corporations are stifling the good of everyone for selfish reasons. They place their own monetary gain above all else, and hinder the efforts of groups like the World Wide Web Consortium, whose efforts are focused on providing a place for new standards to grow.

The benefits of Web Standards are far-reaching. But for all the niceties they provide us designers, like the ability to design cross-platform, accessible, backwards (and forwards?) compatible web sites, the vision realized by their implementation is much nobler. It is a vision of enabling communication between all people of the world in the hopes of increasing understanding across cultures and countries. In other words: enabling democracy. This understanding could not come at a better time.

Thus the corporations who stifle the growth of standards alienate people who recognize the obvious goodwill of those who push for their adoption: technologists, designers, and thoughtful companies. It is an anomaly to us: we cannot understand why one company or a small group would want to control something that has such potential to benefit mankind in innumerable ways. Like the War on Iraq, this perversion of power seems to us just simply Wrong.

To state that we support these battles less fervently because they shouldn’t have to be fought doesn’t mean that they are not being fought. The protesters in New York City during the Republican National Convention and grassroots groups like the Web Standards Project fight them every day.

But what if they don�t succeed? What if the powers that be continue on?

Should they continue on, the powers that be would have to ignore the growing voices echoing in that great democratic medium now enjoying a proliferation unlike any other medium in history: the Web. Thankfully, this can only happen for so long.

Witness the recent flap over Wikipedia, started by a staff writer of a Syracuse, NY newspaper who told librarians not to use the publicly-editable online encyclopedia because it was “untrustworthy” and the idea was “repugnant”. However, further debate and discussion has suggested that Wikipedia actually heals itself relatively quickly, with contributors overwriting vandalism�in about 5 minutes.

5 minutes. That’s how long it takes Right to overcome Wrong on some parts of the Democratic Web. I only wish we could win all such unnecessary battles so quickly.

What was I doing the other 20% of the time? Creating content, of course. I was putting together what a huge percentage of my site visitors come for. When I thought about it in these terms (time spent), I felt like styling with CSS was a lot of work for comparatively little gain. After all, people will still be able to find the site, read the content, and click on the links, whether or not I’ve styled it.

Why did I care so much? Why was I spending so much time to get my code to validate? Why was I applying margins and padding until my head spun? Why didn’t I simply drop the content into a couple <Hn> and <p> tags and just display it unstyled?

I’m not sure, but my internal debate went something like this:

Josh #1: Just get it styled, you lazy wimp. Be a craftsman. Look at all the pretty sites out there. You know how to do it, take the time to do it right. Patience and time, my friend. Rome wasn’t built in a day.

Josh #2: Nobody really cares about style, Josh. You know this, even though many folks argue otherwise. Don’t worry about that. The most successful sites on the web aren’t even close to pretty. Amazon, Yahoo, Ebay, CNN: their ugliness not cared about by millions of visitors every day. Why don’t you try to be more efficient with your time? Just get it into semantic code (assuming that it alone will help users) and be done with it.

Josh #1: Not so fast, Bizarro. Even Don Norman just published a book about how pretty things are more desirable. It goes for teapots and it goes for web sites. Don’t you find pretty women more desirable? And about those sites, those sites happen to be business sites and are therefore mostly successful because of their business savvy. They’ve got marketing money to tell people how great they are. People put up with their crappy web sites because they want to get stuff done. They muddle through. I’d even venture to guess that if their sites were pretty, then they’d have even more visitors than they do now.

Josh #2: Pretty women are a dime a dozen, my friend, and pretty web sites, too. Smart & pretty, now that’s desirable. Get the content down first, and then you can worry about how it’s all going to look. Give stylesheets a rest. Wouldn’t it be nice to have a stylesheet shorter than 300 lines? Wouldn’t that be desirable? Let’s get real here: user behavior shows that people were happily devouring web pages back when they were a mass of links on a gray background and years before stylesheets showed up. Thus, the same behavior predicts they will be happily devouring web sites after the next great technology comes along. It’s information they’re after, not tools. Tools aren’t great. What you build with them can be.

Josh #1: Ok, so in the last 30 minutes all we’ve done is stare out the window at brick chimneys and haven’t written a lick of code. On this pace we might even get zero done today. So let’s focus here on what is truly important. Without that XHTML we won’t have anything to write CSS for. Sounds simple enough, right? So let’s get the content done, and if we’ve got more time, then we’ll add the icing on the cake. But if we do add the icing, let’s make sure it’s that nice whipped cream cheese icing with the pretty chocolate cocoa dusted on the top.

Pretty Please?

The discussions concerning web standards have never been hotter: some view that there is too much focus on them (and not enough on users), while others are called hypocrites because their site doesn’t validate. And still others pondered some of the reasons why standards are difficult to learn.

I believe these discussions are definitely worthwhile: they help designers learn the tools they need to use. After reading many of them, however, it occurred to me that very little of the talk was directed toward how the standards affect users. Nearly all of the talk is about how standards help designers, not users.

That being said, users aren’t the ones who implement standards, designers are. So getting that train moving is certainly good. However, most of us would agree that we can always focus more attention on user needs.

But what if we’re designers who don’t do that sort of thing? What if it’s not in our job description? What if we simply code what is given to us? (I coded a site recently that I did not design, and I wondered if the code could actually have an effect on the user experience). So does the act of coding to standards/writing semantically correct code help users in and of itself?

Thus I come to the ways that web standards positively affect users.

Improved Accessibility

Designers who write semantically correct code make much more accessible web sites. Screen readers have a chance of deciphering them: titles and headlines make sense when read in order. Tables used for layout no longer confuse those users whose browser doesn’t support them. Imported stylesheets can be hidden from browsers that were written before the standards push. Improved techniques such as using images in the background of headers while retaining the header text drastically improve the accessibility of the page. And I haven’t even mentioned more font control, multiple user agents, or user-defined style sheets.

Improved Search Results

Huge improvements in both in the search itself (spiders will index them better) and on the results pages (good title and header tags are much easier to read) make semantically-correct pages much easier for users to find. On one site that I made simply changing paragraphs to headers on the home page tripled my traffic. That was enough evidence for me to attempt to never use a tag incorrectly again.

Speed

If everyone changed pages coded in the old style to pages coded in semantically-correct XHTML, the web would lose almost half it’s volume in terms of bandwidth. I’m basing this assumption on numbers like those attained by the folks who redesigned ESPN.com. In addition, rendering speed and caching speed are improved. Now, if we could just ensure that the content we were displaying (faster) is worthwhile, that would be an increase in the speed with which we complete our tasks.

So, while much of the discussion focuses on whether sites validate, whether there is too much focus on standards, or which image-replacement technique is preferable, I’d like to humbly point out how these amazing new technologies affect those we design for.

The Box Model is Difficult

It seems like the box model shouldn’t be difficult to learn, but it is. I’m not sure why, but I think it may have to do with complexity that arises when you have boxes within boxes. At that point, it becomes an exercise of adding margin here, taking away padding there, and setting margins and paddings to 0 over there. Combine that with floating and positioning: relative, absolute, fixed, and it gets hard to know where the spacing between objects comes from, even when you’re working in standards-supporting browser like Mozilla. On top of this you have the box model hack…which only complicates things further. Even browsers get the box model wrong.

Separation of Content and Style is a Progammer’s Trick

Back when I was a computer science undergrad, separating parts of a project into conceptual pieces was pretty much the hardest thing I had to do. The best programmers could write code 10 times (literally) faster than I could, and it was because they used the highly-efficient object oriented methodology as easily as they ate with a spoon. I hadn’t learned the object-oriented paradigm in high school like they had. CSS and XHTML is a very crude (though good) attempt at this sort of efficiency, and it will only improve with time. XHTML 2 will also add more features in this spirit, further separating markup language into separate, logical pieces. But, as I learned a few years ago, it takes a lot of work to get used to when you’re new to it.

Browser Support is Still Spotty

Until designers can code things once and not have to check renderings in multiple browsers this will be an issue. I guess that over 50% of my time designing is spent checking the design in multiple browsers. In other words I could work twice as fast if browser support was equal. One thing I can say is this: lack of browser support has made me learn more about XHTML than I otherwise would have had to. Perhaps that’s a silver lining.

One Goal, Two Syntaxes

With XHTML 1 we’ve moved completely to a straightforward XML syntax: <tag>content</tag>. With CSS we’ve introduced a seemingly unrelated syntax. Why? I don’t know, but it sure complicates things. There may be an excellent reason why the two look so different, but wouldn’t it be great to have one syntax instead of two, with a doctype to declare the difference?

So Much to Unlearn

The turning point in Luke’s Jedi training with Yoda. “You must unlearn what you have learned”. For anybody who created web pages using table-based layouts, this is definitely an issue. Countless hours unlearning spacer gif techniques, valign, align, and padding for layout. Perhaps this is why the box model seems so hard…I’m a stubborn unlearner.