Microformats Primer

By now you’ve probably heard of microformats and wondered what they are, exactly. Officially, they’re a set of simple, open data formats built upon existing and widely adopted standards that are designed for humans first and machines second. What does that mean to you? Fortunately, it’s simpler than it sounds.

Microformats are about using the standards we all know and love to convey as much semantic meaning as possible. Think of them as semantic best practices. They use current XHTML tags such as address, cite, and blockquote and attributes such as rel, rev, and title to create semantically appropriate blocks of code. Microformats are great because they are both usable and elegant—and all you need to do to get started with them is familiarize yourself with the best ways to apply the tags and attributes you already use.

Quick Example

Adoption is starting to reach critical mass, and before we know it, search engines will be interpreting and understanding the increasingly complex relationships between sites, people, ideas and more.

Now that we understand what microformats are, let’s take a look at how they work. To keep it simple, we’ll use the hCard microformat. Say you want to display your business card information on a Web site. The vCard is the standard for electronic business cards, so naturally, we use it as the starting point for creating the hCard format. Again, microformats are built upon existing and widely adopted standards, like the vCard

We’ll start with an example vCard:

BEGIN:VCARD
VERSION:3.0
N:Çelik;Tantek
FN:Tantek Çelik
URL:http://tantek.com
ORG:Technorati
END:VCARD

Now let’s take a look at the microformat equivalent, the hCard. The first thing to note is that it just uses standard XHTML. Second, it uses the same field types as the vCard.

<div class="vcard">
<a class="url fn" href="http://tantek.com/">
Tantek Çelik
</a>
<div class="org">Technorati</div>
</div>

Just by glancing at the example hCard, you can understand what each of the values represents. You can find a more detailed explanation of how hCard evolved from the vCard format on the Microformats Wiki.

Why use them?

Now we know exactly what microformats are and have seen an example, but why bother?

Standards

Standards are critical to the future of the Web. If you don’t agree, ask any Web designer about the challenge of supporting Internet Explorer vs. the ease of supporting Firefox. And while standards like microformats might not be appropriate for every situation, awareness is the first step in knowing when to apply them. Adoption is starting to reach critical mass, and before we know it, search engines will be interpreting and understanding the increasingly complex relationships between sites, people, ideas and more.

CSS Convenience

As an added benefit of using accepted tags and attributes, we can take full advantage of the ability to style our microformats through CSS. Let’s take a look at Extensible Open XHTML Outlines, also known as XOXO. XOXO is simply a way of semantically marking up outlines.

Using the following simple example from the wiki:

<ol class="'xoxo'">
<li>Subject 1
<ol>
<li>sub-point a</li>
<li>sub-point b</li>
</ol>
</li>
<li>Subject 2
<ol compact="compact">
<li>sub-point c</li>
<li>sub-point d</li>
</ol>
</li>
<li>Subject 3
<ol>
<li>sub-point e</li>
</ol>
</li>
</ol>

We can apply the following possible style rules:

ol.xoxo { list-style:decimal; }
ol.xoxo ol { list-style:lower-latin; }
ol[compact="compact"] { display:none; }

And our outline would render as follows:

1. Subject 1
a. sub-point a
b. sub-point b
2. Subject 2
3. Subject 3
a. sub-point e

When you look at it, there’s really nothing fancy going on, and that’s the beauty of microformats. Because we’re using existing and widely supported markup, the formatting possibilities are almost limitless. You could use an outline format for navigation, slideshows, a table of contents, or just a good old-fashioned outline. Best of all, the styling is still entirely in your control.

Plug-and-Play JavaScript

Like CSS, microformats let you to do some interesting things through JavaScript and the DOM. After all, microformats are just a bunch of XHTML. The only difference is that your scripts don’t need to manipulate elements based on custom markup. In fact, anybody can create a script for working with a certain microformat and give it away. When it’s time to integrate the script in your page, it’s a breeze because you’re already using the same semantically valuable markup to identify the bits and pieces for the script to manipulate.

Machine-Readable

We’ve already covered the benefits of microformats being human-readable, but what about “machines”—you know, search engines? One example is the elemental microformat rel="nofollow". By adding this element to your anchor tags, you’re telling search engines not to give any weight to those links. This is just one of many machine-readable microformats.

Imagine for a moment a future where search engines recognize microformats and take advantage of their inherent metadata. You could find reviews for specific products or pages, vote for or against a site when you link to it, or track the development of a conversation across multiple sites with minimal effort.

Implicit Metadata vs. Explicit Metadata

For search engines and machine-readable formats, accurate and appropriate metadata is one of the keys to tying it all together. Providing explicit metadata requires extra effort and has traditionally been extremely challenging or neglected altogether. With microformats, implicit metadata is provided by virtue of using the right markup. It won’t replace the need for explicit metadata, but it can serve as a great supplement or at least a good start.

By using microformats, you’re not only writing better markup, but also adding a wealth of machine-readable information for search engines and other applications—metadata that they can use to establish relationships, draw connections, and improve the quality of search results.

Meaningful Markup is Good Markup

When writing markup against deadlines and priorities, it’s easy to forget that somebody else will eventually have to maintain it. Conveniently, some of the central ideas behind microformats revolve around the fact that they are designed for humans first and created with simplicity in mind. This means you’ll have markup that is easy to understand and maintain for everyone, including:

• The engineer integrating your code next week
• You updating your code next month
• The new guy taking over your job when you get promoted next year

Summary

Now when you’re hanging out and somebody brings up microformats, you’ll be ready to jump right in and hold your own. The details may be a bit overwhelming, but with a little reading, you’ll gain priceless insight into markup and standards that can help you even when you’re not using microformats.

Related Resources

• Microformats.org
• Microformats Discussion List
• Introduction to Microformats
• Usable Microformats by Andy Hume – An in-depth exploration of vCards

By Garrett Dimon

CSS Styling for Print and Other Media

Note: This excerpt from the upcoming book “Pro CSS Techniques” by Jeff Croft, Ian Lloyd, and Dan Rubin, has been edited for this publication with permission of the chapter’s author, Ian Lloyd. The excerpt is approximately two-thirds of the length of the original chapter.

There are many different media types that you can apply to CSS, some of which are more useful than others, and they let you specify the look, feel, or sound of the web page that is linked to the CSS files. In this section, we’ll look at the various media types that are available (as gleaned from the official source, namely the W3C: www.w3.org/TR/REC-CSS2/media.html#q1). However, rather than list them all and suggest wonderfully practical ways to use them, we’ll break the list down into two categories: useful and not-so-useful (read: which ones you’re likely to use on a day-to-day basis in the foreseeable future, and those that you won’t touch in a month of Sundays).

The Useful Media Types

In our experience, the greatest use you’ll have for different media types is with printed output. There are a few quirks to be aware of (and we’ll cover those), but it’s very well supported in general and can be put to great use.

This list includes the media types that you will truly find a use for on regular occasions:

• screen—For color computer screens
• print—For printed versions of the document
• projection—For presentation or kiosk versions of the document (where toolbars are removed, and the display renders completely full screen)
• all—For styles that are suitable for all devices

We’ll be using (or covering briefly) these media types in this chapter’s examples.

The Not-So-Useful Media Types

Remember what I was saying about those media types that you’d never use in a month of Sundays? Well, here they are, listed for your soon-to-be-ignored pleasure:

• aural—For use with speech synthesizers or talking browsers
• braille—For Braille-tactile feedback devices
• embossed—For paged Braille printers
• handheld—For handheld devices (for example, small-screen PDAs and cell phones)
• tty—For media using a fixed-pitch character grid, such as Teletypes, terminals, or portable devices with limited display capabilities
• tv—For television-type devices

We won’t focus on these types because, while the reasoning behind them is good, support for their usage may be nonexistent. However, we’ll expand on the aural and handheld types in the section “Style Sheets for Other Media Types” later in this chapter.

Specifying the Media Type

Next, let’s look at how you can tell the user agent which medium (or media) the styles you are asking it to render should apply to.

Adding a media Attribute to the link Element

Arguably, the simplest method for linking to a style sheet is to use the link element, like so:

<link rel="stylesheet" href="css/mainstylesheet.css">

This code tells the user agent that the link is to a style sheet and where it can find the link (css/mainstylesheet.css). The user agent will then deal with the link however it sees fit. You can, however, scope the use of the CSS contained in that style sheet with the media attribute:

<link rel="stylesheet" href="css/mainstylesheet.css"> media="screen" />

In this example, only devices that will be displaying the content on a large screen will do anything with that style sheet. And where screen is concerned, that pretty much means a PC (Windows, Mac, Linux, etc.) and a web browser (Firefox, IE, and so on).

Adding a media Attribute to the @import Statement

If you are using the @import method for linking to a style sheet (perhaps to throw older, non-standards-friendly browsers such as Netscape 4 off the scent), you could use the following syntax:

<style type="text/css">
  @import url("css/printstylesheet.css") print;
</style> 

There is a small problem with this approach, however: IE versions 6 and earlier won’t deal with this syntax (at the time of this writing, IE 7 didn’t understand this construct either), so you’re probably going to have to use the previous method for linking wholesale to a CSS file.

Note: You can place the @import statement in a style block as shown in the example, or you can embed that @import statement in another style sheet that is already linked to the document, but the @import statement must be at the beginning of that style sheet, not after any other CSS selectors.

Adding the Media to Specific Selectors within a Style Sheet

Finally, you can embed some media-specific styles within another style sheet like so:

<style type="text/css">
body {
  font-size: 62.5%;
}
h1 {
  color: red;
}
h2 {
  color: blue;
}
@media print {
  h1 {
    color: black;
  }
  h2 {
    color: gray;
  }
}
</style> 

Creating a Print Style Sheet

In our experience, the greatest use you’ll have for different media types is with printed output. There are a few quirks to be aware of (and we’ll cover those), but it’s very well supported in general and can be put to great use.

We’ve mentioned the various techniques that you can use to link to a style sheet with different media. Our preference is to do the following:

• Create a basic CSS file that contains generic visual styles that are understood by most browsers. Avoid CSS layout and anything that could be considered intermediate-to-advanced CSS. This CSS file is attached to the document using a link element but without specifying any media type whatsoever.
• Create a second style sheet that is used for more advanced screen styles and use the @import statement embedded in the basic.css file to attach it. Netscape 4 won’t see this advanced file, but other newer browsers will.
• Create a print-only style sheet and attach it using the link element with media="print".

Note: You should declare the print style sheet last (link to it even after any block inside the HTML page). If you declare the print style sheet first, you could undo any values set there in the subsequent generic style sheets if they are not scoped for screen or some other medium.

Translating that English into markup, we get this in the document:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <title>Simple print test</title>
  <meta equiv="Content-Type" content="text/html; charset=iso-8859-1">
  <link rel="stylesheet" href="css/basic.css">
  <link rel="stylesheet" href="css/print.css" media="print">
</head> 

and in the basic CSS file:

@import url("advanced.css");

What Do You Put in a Print CSS File?

There are not any real hard-and-fast rules about what should or shouldn’t go into a print CSS file. However, let’s take a moment to consider some of the characteristics of the printed format. Keep in mind that in print you can’t do the following:

• Click on navigation items to take you to another piece of paper
• Conduct a search or carry out a calculation
• Zoom in or out on a map or resize text using a text widget of some kind
• “E-mail this story to a friend”
• Scroll the page
• Send feedback

What you can do with print CSS is almost the reverse of the previous list:

• Hide all navigation elements that are no longer any use
• Hide search facilities or other interactive form elements
• Hide controls that affect on-screen display
• Hide links that spawn some browser or application functionality

In fact, anything that you can click on or interact with on screen may need some kind of alternative treatment for print. Examples include hiding the element entirely or removing some display attribute that no longer works in the printed format (for example, removing underlines in body text links).

Note: In most browsers, you do not need to be too concerned about dealing with background images that appear on screen; they are usually set not to print by default and, as such, are unlikely to need any special print-only treatment. One exception is Opera, which will print backgrounds out by default (or at least it does in versions 8 and 9 that we tested), but this can easily be unset in the File » TRA Print Options menu. If you have a sufficient number of Opera users, you might want to override background images for given elements, for example, body {background-image:none;}, so that users do not have to specify this for themselves—but it’s not a major consideration that you need to worry about.

One of the first things you should consider with a print layout is resetting any layout mechanisms you’ve used for the screen view. This involves removing floats, absolute positioning, padding, and margins.

Tips for Even Better Printed Pages

Our previous example showed a simple printout that you can achieve by resetting certain CSS properties and redefining others. There is more that you can do to improve matters, though:

• Use serif fonts. Because of the low resolution that monitors provide, and the fact that a large number of users do not have something like ClearType (www.microsoft.com/typography/cleartype/tuner/Step1.aspx) enabled, small-sized serif fonts often look poor on screen—there simply aren’t enough pixels available to render all the little flourishes (or serifs) at the ends of letters. It’s no mistake that a large number of web sites use sans-serif fonts (such as Verdana, Arial, and Helvetica) on screen; the lack of serifs makes them easier to render and thus easier to read. On screen. For the printed version, though, you can quite easily use a serif font, such as Georgia or Times New Roman. Serif fonts provide extra shape to the letters and can often help distinguish among similar-looking characters; the serifs also create an implied horizontal line that’s supposed to aid readability.
• If you’ve lost background images for print, you might be able to work around this by including an inline image that is hidden in the main style sheet (give it a unique id so that you can reference it) with a display:none but is made visible in your print CSS file using display:block or display:inline. The downside is that you are including an image that, for the vast majority of users, will not be seen but will still get downloaded to the client. If that’s something that concerns you (and it probably depends on how big the image is), you could use CSS-generated content to dynamically write in the image—for example, in the print style sheet, div.offer:after {content: "<img src="'printimage.gif'" alt="Special offer" />"}. But remember that IE 7 and earlier won’t pay any attention to that code. Certainly, the former technique enjoys better support.
• Bullet points missing? In the previous chapter, we suggested that applying background images was the best method for creating custom list item symbols. When you print them, though, the images won’t show. For that reason you should redefine the display for print so that the image is attached using list-style-image (or simply remove the custom bullet styles altogether and go with the basic styles that the browser would apply).
• Provide special offers for printouts. While the browser will, by default, print information such as the date, URL, and page number, you can add custom information for the printed version. As an example, if on our travel site you found the perfect vacation and printed out the details, you could include a print-only section on how to make a booking. This section might include a telephone number and a reference number, while the screen view would instead display a link to the e-commerce section of the site to make an online booking.

Things to Watch Out For

With a little care and attention, you can create web pages that perfectly suit the printed medium. Yet be aware that there are some things you need to take into account.

Checking Your Page Width

If you have defined a width for your page using pixels, you will need to redefine that for print using a real-world measurement such as centimeters, millimeters, or inches. Be sure to allow for the fact that the printer your site visitor is using may not be able to print right up to the edges. If you take a US letter or A4 sized piece of paper, measure its width, then take off a couple of centimeters or a quarter inch from either side, that should give you a printable page width.

Printing Errors with CSS Positioning

If you have reset all the positioning properties as suggested earlier in this chapter, you will probably not run into difficulties. However, be sure to try printing a web page with a lot of content—a page that you would expect to run into several printed pages—to make sure that the entire web page prints. Using floats and absolute position can affect the printout, resulting in only the first page getting printed. If this happens, double-check the CSS for the container of the content that is being “clipped” and ensure that you have set float:none and position:static.

Note: In case you’re wondering “What’s that static value? And why haven’t we heard about it before?” it’s because that’s the browser’s default positioning model. You would not normally need to set this yourself—we only have to do this to get around a known printing problem.

Getting Feedback About Your “Funny Printouts”

Despite all your hard work, someone is bound to ask, “Why does your page not print out properly?” Many users expect that what they see on screen will be replicated in the printout. Remember that you can use print CSS itself to address the issue (e.g., perhaps a block of text that reads “This page has been crafted for perfect printing...” that is hidden on screen but set as display:block for the printed version).

Advanced Print CSS Techniques

Hiding and showing or restyling content dependent on the medium is fairly straightforward stuff once you’ve grasped the basics. In this section, we’ll examine some more advanced features that introduce some extra dynamics into the usually static world of print. This is where browser support can get a little flakier, though, so be sure to treat these as nice-to-haves, rather than as essential features that must be available to all browsers.

Inserting URLS in Printed Pages

The great thing about reading a web page with links is that when you see an underlined phrase you can click on that link and immediately investigate another avenue.

With that page printed out, you have no way of following that link, so you have a couple of choices:

• Suppress the underline (or any other link styling, such as bold text) for print so that it doesn’t get in the way needlessly; there’s no point signifying a link that can’t be followed.
• Choose the opposite route—instead of hiding the link styling, expand on it and dynamically create a printed version of the web address (whatever is in that link’s href attribute).

The latter is definitely doable, but it requires some slightly advanced CSS (not supported by IE 7 or earlier) or a JavaScript solution.

Using Generated Content to Write Out the URL

Here is the basic CSS that does the job of writing out links on the page (be sure to add this only to the print CSS file):

a:after {
  content: " (" attr(href) ") ";
} 

This code tells the browser to get the value of an attribute (the href attribute, as detailed in the parentheses) and then place that value in a string that begins and ends with parentheses. If you are familiar with JavaScript, it’s equivalent to

" (" + this.getAttribute('href') + ")"

but there is no concatenation symbol such as + or &. In this example HTML:

<h3>
<a href="/book/bookDisplay.html?bID=10079">
Building Flickr Applications with PHP
</a>
</h3> 

it would render on the printed version like so:

---

Building Flickr Applications with PHP
(http://www.apress.com/book/bookDisplay.html?bID=10079)

---

Tip: You probably wouldn’t want every link on the page to get this treatment, so you may want to scope it by using a contextual selector, for example #bodycontent a:after {content: " (" attr(href) ") ";}.

When looking at a block of content, a long URL directly after the text can make it a little difficult to read, regardless of the benefit offered by having the reference there. Wouldn’t it be great if you could simply create a footnote from each link and just place a number after the link that references the footnote link? Well, you can thank Aaron Gustafson for devising a JavaScript technique that does just that, all ready for you to download and implement.

Selective Printing Using the DOM and CSS

One final advanced technique that you might like to consider is mixing together DOM scripting and CSS to create specific printable areas of a page. An example of how this works is a FAQ page that contains many blocks of content. You might want to print only one section of that page; by using JavaScript you can dynamically toggle display attributes of different sections so that only the part you want printed is shown—but without affecting the screen view.

This is a fairly involved technique, which is covered thoroughly (a chapter in its own right!) in another Apress book, Web Standards Creativity (February 2007), although you can also read about the technique online on my personal blog.

Style Sheets for Other Media Types

As we mentioned at the beginning of this chapter, the support for other media types is very spotty indeed, and what you can do with it is severely limited. We won’t explore all the various CSS property values that you can use with audio style sheets (it’s highly unlikely that such a discussion would be of use to most readers), but we’ll look at a few media types.

The Projection Media Type

Another media type that does have a modicum of support is projection. As far back as version 4, Opera has supported this type, but what does it do? Projection is intended for use with presentation versions of a web page; all browser toolbars and the like are removed, and the information is presented in full screen. A good example is S5, a web-page-based presentation format that CSS guru Eric Meyer devised, and which is used by many web standards advocates throughout the world. In Opera you trigger the Projection mode by choosing View » TRA Full Screen. Firefox and IE will not render the projection content when viewed in full-screen mode, so you have to ask yourself: What benefit can you get from using this?

The Aural Media Type

With the aural CSS properties, you should be able to control the pitch, speed, tone, and other attributes for speech-synthesized versions of the web page to great effect, but support for this is very much lacking. To date, we’ve only seen (or rather heard) one good application of this: a plug-in for Firefox called Firevox, which is definitely worth downloading and checking out to see what should be possible with this technology. You can find out more about the various CSS aural properties and values at the W3C (www.w3.org/TR/REC-CSS2/aural.html), or for a simpler example try the W3Schools introduction to this topic.

The Handheld Media Type

Another example of “great in theory, but almost useless in practice,” the handheld media type is perfect for specifying styles that can be used for a cell-phone-based browser, Blackberry, or similar device. However, the mobile market (phones in particular) are almost a law unto themselves and have devised various strategies for rendering web pages in the struggle to gain a competitive edge. At http://css-discuss.incutio.com/?page=HandheldStylesheets you’ll find a quotation that pretty much sums up the sorry state of handheld support:

Some current phones apply “screen” styles as well as “handheld” styles, others ignore both, and in some cases the phone carrier runs pages through a proxy that strips styles out even if the phone could recognize them, so it’s a crapshoot figuring out what will get applied.

So, all bets are off! It’s good to be aware that the media type exists and what its intended use is, but, seriously, don’t waste effort in trying to design a slick interface for a given handheld device and expect it to honor only your handheld styles and ignore the screen styles—and certainly don’t expect the next handheld to do the same.

The All Media Type

The all media type is pretty much superfluous. If you want a style sheet to be rendered on all devices, you may just as well not set a media type at all and let the device, browser, or user agent work it out for itself.

Summary

The ability to create specific style sheets for different media seems, on the face of it, to be a very powerful tool. However, in practice you are limited in what you can do. It seems a shame to end on a sour note, but we hope the things that you can do with the print medium more than make up for the rest. Now, if only the mobile market could decide on a standard and stick with it, we could do great things with those devices just as we can with the printed medium. Well, we can hope—and a good place to start is with Blue Flavor’s presentation on mobile web design.

Excerpted from “Pro CSS Techniques” by Jeff Croft, Ian Lloyd, and Dan Rubin. Copyright Ian Lloyd 2006. Used with permission of Apress, Inc.

By Ian Lloyd

Web 2.0 for Designers

In Web 1.0, a small number of writers created Web pages for a large number of readers. As a result, people could get information by going directly to the source: Adobe.com for graphic design issues, Microsoft.com for Windows issues, and CNN.com for news. Over time, however, more and more people started writing content in addition to reading it. This had an interesting effect—suddenly there was too much information to keep up with! We did not have enough time for everyone who wanted our attention and visiting all sites with relevant content simply wasn’t possible. As personal publishing caught on and went mainstream, it became apparent that the Web 1.0 paradigm had to change.

Enter Web 2.0, a vision of the Web in which information is broken up into “microcontent” units that can be distributed over dozens of domains. The Web of documents has morphed into a Web of data. We are no longer just looking to the same old sources for information. Now we’re looking to a new set of tools to aggregate and remix microcontent in new and useful ways.

The Web of documents has morphed into a Web of data. We are no longer just looking to the same old sources for information. Now we’re looking to a new set of tools to aggregate and remix microcontent in new and useful ways.

These tools, the interfaces of Web 2.0, will become the frontier of design innovation.

The evidence is already here with RSS aggregators, search engines, portals, APIs (application programming interfaces, which provide hooks to data) and Web services (where data can be accessed via XML-RPC, SOAP and other technologies). Google Maps (in beta) provides the same functionality as similar competing services but features a far superior interface. Flickr’s interface is one of the most intuitive and beloved around. Del.icio.us offers personal and social functionality, and reaches far beyond its own site. Interfaces like these are changing the way we store, access, and share information. It matters very little what domain content comes from.

Web 2.0 has often been described as “the Web as platform,” and if we think about the Web as a platform for interacting with content, we begin to see how it impacts design. Imagine a bunch of stores of content provided by different parties—companies, individuals, governments—upon which we could build interfaces that combine the information in ways no single domain ever could. For example, Amazon.com makes its database of content accessible to the outside world. Anyone can design an interface to replace Amazon’s that better suits specific needs (see Amazon Light). The power of this is that content can be personalized or remixed with other data to create much more useful tools.

There are six trends that characterize Web 2.0 for designers. In this introductory article we’ll summarize each of those trends and give brief examples. In upcoming articles we’ll explore each trend in more detail.

Writing Semantic Markup: Transition to XML

One of the biggest steps in realizing Web 2.0 is the transition to semantic markup, or markup that accurately describes the content it’s applied to. The most popular markup languages, HTML and XHTML, are used primarily for display purposes, with tags to which designers can apply styles via CSS.

These markup languages are not semantically dead, however. Designers can describe content, but only to the extent that it fits within the (X)HTML tag set. For example, designers can mark up content as headers, paragraphs, list items, citations, and definition lists using the <h1>, <p>, <li> , <cite> and <dl> tags, respectively. For some simple documents, these tags are adequate to describe content effectively. For most documents, however, there is no way to accurately describe the content with the (X)HTML tags we have available. In Web 2.0, this description is not only possible, but also critical.

Though HTML and XHTML give us only a glimpse of what it means, there is one technology demonstrating clearly the power of semantic markup. RSS is an XML format for syndicating content. It is an easy way for sites to tell people when there is new content available. So, instead of browsing to your favorite site over and over again to see if something is new, you can simply subscribe to its RSS feed by typing the RSS URI into a feed aggregator. The aggregator will periodically poll the site, notify you if something is new, and deliver that content. It’s a real timesaver.

Providing Web Services: Moving Away From Place

During the early years of the Web, before content had semantic meaning, sites were developed as a collection of “pages.” Sites in the 1990s were usually either brochure-ware (static HTML pages with insipid content) or they were interactive in a flashy, animated, JavaScript kind of way. In that era, a common method of promoting sites was to market them as “places”—the Web as a virtual world complete with online shopping malls and portals.

In the late 90s and especially the first few years of the 21st century, the advent of XML technologies and Web services began to change how sites were designed. XML technologies enabled content to be shareable and transformable between different systems, and Web services provided hooks into the innards of sites. Instead of visual design being the interface to content, Web services have become programmatic interfaces to that same content. This is truly powerful. Anyone can build an interface to content on any domain if the developers there provide a Web services API.

Two great examples of the shift away from place to services on the Web are Amazon.com and eBay, both of which provide an immense amount of commercial data in the form of Web services, accessible to any developer who wants it. An interesting interface built using eBay’s Web services is Andale, a site that tracks sales and prices to give auction sellers a better idea of what items are hot and how much they’ve been selling for.

Remixing Content: About When and What, not Who or Why

Associated Press CEO Tom Curley made an important and far-reaching keynote speech to the Online News Association Conference on Nov. 12, 2004. In it he said, “… content will be more important than its container in this next phase [of the Web]… Killer apps, such as search, RSS and video-capture software such as TiVo—to name just a few—have begun to unlock content from any vessel we try to put it in.”

Curley was specifically addressing journalists and the media industry, but this insight applies equally to the design profession. Web design during Web 1.0 was all about building compelling places (or sites) on the Web. But content can no longer be contained in a single place—at least not without going against the nature of the social Web and locking up your content in a secure site.

Web design in Web 2.0 is about building event-driven experiences, rather than sites. And it’s no coincidence that RSS is one of the key building blocks. RSS feeds enable people to subscribe to your content and read it in an aggregator any time, sans extraneous design.

Searches can also be mixed with RSS to let people subscribe to content via topic and tag RSS feeds (from PubSub or Feedster, for example). These so-called “future searches” not only let people mix content from various sources, but end up being yet another way for users to bypass a site’s visual design.

Because content flows across the Web in RSS feeds and can be remixed along the way, Web designers must now think beyond sites and figure out how to brand the content itself.

Emergent Navigation and Relevance: Users are in Control

As a result of the remixing aspects of Web 2.0, most content will be first encountered away from the domain in which it lies. Thus, much of the navigation that is used to reach a specific item might be far removed from the navigation specifically designed for it. This “distributed” navigation might come in the form of a feed reader, a link on a blog, a search engine, or some other content aggregator.

One of the side effects of this is that the sources of and pathways to useful information will continually change, and users won’t necessarily know where to go to find it. Fortunately, content aggregators have a built-in answer for this—they can track what people are doing. By recording what pieces of microcontent are most often visited, aggregators can use past user behavior to predict what users will find most relevant in the future. This is very apparent in Daypop, Del.icio.us, and Blogdex feeds. What people have found relevant in the past is likely to be useful in the future.

With relevance decided within these third-party interfaces, users might even be able to read content without ever visiting the domain it comes from. Navigation schemes, as we know them, will be used less. The most traveled navigation paths will emerge from user behavior instead of being “designed” specifically for it.

Adding Metadata Over Time: Communities Building Social Information

One feature of Web 1.0 that seemed to change everything about publishing was the ability to make changes to the primary publication at any time. There are no “editions” or “printings” on the Web like there are in the print world. There is simply the site and its current state. We are used to this paradigm now, and an optimist can hope that Web content will only get better with time: metadata will be added, descriptions will get deeper, topics more clear, and references more comprehensive.

What we see happening in Web 2.0 is a step beyond this, to where users are adding their own metadata. On Flickr and Del.icio.us, any user can attach tags to digital media items (files, bookmarks, images). The tagging aspect of these services isn’t the most interesting part of them, though. What is most interesting are the trends we see when we put together everyone’s tags.

Let’s say, for example, that we tag a bookmark “Web2.0” in Del.icio.us. We can then access del.icio.us/tag/Web2.0 to see what items others have tagged similarly, and discover valuable content that we may not have known existed. A search engine searches metadata applied by designers, but Del.icio.us leverages metadata applied by folks who don’t necessarily fit that mold.

Shift to Programming: Separation of Structure and Style

In Web 1.0, there were two stages to visual Web design. In the early years, designers used tricks like animated GIFs and table hacks in clever, interesting and horrible ways. In the last few years, CSS came into fashion to help separate style from structure, with styling information defined in an external CSS file. Even so, the focus was still on visual design—it was the primary way to distinguish content and garner attention.

Enter the Web 2.0 world, which is not defined as much by place and is less about visual style. XML is the currency of choice in Web 2.0, so words and semantics are more important than presentation and layout. Content moves around and is accessible by programmatic means. In a very real sense, we’re now designing more for machines than for people. This may sound like we’re in the Matrix, but in the words of Amazon.com CEO Jeff Bezos, “Web 2.0… is about making the Internet useful for computers.”

What does this mean for Web designers? It means designers have to start thinking about how to brand content as well as sites. It means designers have to get comfortable with Web services and think beyond presentation of place to APIs and syndication. In short, it means designers need to become more like programmers. Web 2.0 is a world of thin front ends and powerful back ends, to paraphrase Bezos.

Summary

The effects of Web 2.0 are far-reaching. Like all paradigm shifts, it affects the people who use it socially, culturally, and even politically. One of the most affected groups is the designers and developers who will be building it—not just because their technical skills will change, but also because they’ll need to treat content as part of a unified whole, an ecosystem if you will, and not just an island.

To summarize, these are what we see as the six main themes covering design in the Web 2.0 world:

1. Writing semantic markup (transition to XML)
2. Providing Web services (moving away from place)
3. Remixing content (about when and what, not who or why)
4. Emergent navigation and relevance (users are in control)
5. Adding metadata over time (communities building social information)
6. Shift to programming (separation of structure and style)

Our purpose in this column is to analyze those themes and figure out what Web 2.0 means for designers. We’ll explore the new technologies that are making it happen, take a closer look at the new interfaces that demonstrate its power, and ponder the social effects it has on the people who use it.

As we move along, we hope that designers who may be wary of the promises of new technology help us focus on the practical aspects of this one, the subtle but real changes that Web 2.0 is having (and will have) on design.

By Richard MacManus & Joshua Porter