Articles - MIX Online

Web Standards: Where the ROI is

Molly Holzschlag — Sat, 06 Dec 2008 01:39:07 GMT

The Web Standards movement is now in its 10th year. The goal of this world wide movement, which we see manifest in such organizations as the Web Standards Project (WaSP), Web Standards Group (WSG); a slew of specialized conferences and workshops is to unify professional best practices for the Web in order to establish a truly interoperable platform.

Whether you're on your Vista machine or a Mac, using your iPhone or PDA should be irrelevant when it comes to the user experience. This is a prime initiative of the movement, and has its roots in the vision of the Web as Sir Tim Berners-Lee, its creator, saw it.

Okay, you think, great. This is a technology issue more than a financial one per se. But with ten years of observation under our belts, those of us within the movement can clearly define the savings, return on investment, and value of using Web standards when creating Web sites and applications. This article will help readers, particularly those interested in better business and technology practices, gain an understanding of where the ROI is when it comes to Web Standards.

Future-Proof Your Investment. The Web is a truly universal platform, and will continue to be supported and maintained long after other platforms have fallen by the wayside. New systems in the future will use the Web as the foundation. When you build using established Web standards, you are using those parts of the web most likely to survive and thrive in the future. You can be sure that your creation will continue to be supported by multiple vendors and devices far into the future. Building on Web standards now protects your investment in the present and continue to reap dividends in the future.
More Efficient Management. Designing across browsers and managing documents efficiently has been the bane of the Web designer/developers existence. Following standards and practices allows for the creation of a workflow that saves not only time, but wear and tear on Web designers and developers working with these difficult challenges. Using a Web standards workflow, time, money and the quality of life for the most valuable of resources: the people on your teams can help improve this ongoing challenge in the standards environment.
Search Engine Optimization. Perhaps the most compelling argument when it comes to value of standards is that if you are writing markup, CSS and JavaScript according to the standards ideologies, you are opening up a world of opportunity when it comes to better SEO. The technical reason is because a semantic markup document holding primarily linear text content allows search engines to find headers and critical keywords within text that much faster.
Universal Access. Whether designing for a PDA or a visually-impaired individual, the concept of Universal Access (which includes numerous modalities such as phones, print, web site all coming from the same document as well as access for those with specific disabilities) is far more easily achieved using the techniques advocated by Web standards, making a document significantly more style-able and scriptable for those multiple reasons.
Scalability. As sites grow, and they have a tendency to do so, a great deal of effort can be saved by having an existing standards workflow and corporate/organizational design guide. This empowers people to scale, refresh and even redesign sites with greater ease than in non-standard design, in which each page "carries" its design with it rather than being controlled by external style sheets. By separating document, presentation and interaction behavior on the technical side, a very significant amount of time, money and frustration can be avoided as a site grows.
Improved User Experience. The lighter-weight files associated with standards-based design mean an improved experience for the user. In order to be effective, sites have to be easy to use and allow the user to get to their goal quickly. A clean infrastructure and the smaller files typically resulting from a Web standards workflow can have a significant impact on the load time and responsiveness of a site, keeping your users happy customers.

These are the key business reasons that Web standards and practices are essential in today's professional Web building. We have process and standardization in almost every other area of computing, but the Web is truly a new frontier. It's the savvy Web pioneers who build strong foundations for future bounty and success.

Web Design from the Gut

Nishant Kothary — Sat, 06 Dec 2008 01:38:46 GMT

Let's Do Something Brutal [1]

First off, check out the prior iteration of MIX Online:

The site used to be a simple blog that, save the prolific content, left much to be desired. It was hardly representative of what the MIX brand stands for. As we started talking about the goals of the site, a few themes emerged:

Content. Content is king, and we agreed that instead of a stream of blog posts, we would invest time in publishing rich articles on topics that web professionals would find interesting.
Bits. The MIX Online team tends to explore interesting scenarios on the Web by building real software. We wanted to somehow weave that into the site in the form of software that we could give away.
Design & Standards. The site needed to be beautiful inside-out. The new MIX Online would connect with the common user to the web designer to the web standards advocate.

We never really turned the above into a vision document, but over the period of brainstorming and discussions, the vision became pretty clear in the minds of all the folks involved. What's important before you dive into any design exercise is to gain a clear understanding of the purpose of your site. It doesn't need to be formal, and it doesn't need to be complete; you can fill in the details as you move forward. But the high-level picture should be crystal-clear.

I can't recall many days when I don't reference the original vision in some conversation or another. As a web site evolves, a clear vision becomes the designer's most frequently used tool in helping ensure a sensible evolution. It becomes infinitely helpful when an executive goes, "Why don't we move that above the fold?" "Well, we could do that, but let me remind you that that pretty much changes our original vision. If that's cool with you, I can go make the change," is always a more effective way to solve the problem than responding with, "You are not the boss of me!" or worse, "You smell like poop."

Paper or Plastic?

Get yourself a vertically-oriented, graph-paper Moleskin, and you will open your world up to all sorts of possibilities.

Yes, this is the customary section on "design begins on paper." Before you get turned off, I'll share a secret that may serve as consolation: until recently, I had always felt that paper got in the way. From design books to shows (like the ones on HGTV), we've been exposed to sketches for everything from web sites to interior design. A couple of things always baffle me about most of these sketches:

They often look exactly like the finished product.
They're beautiful. All the lines are clean, shadows in the right place, perfect grid systems, and so on.

We've been subconsciously conditioned such that whenever we try to sketch an idea out on paper, we're aspiring to produce sketches like the ones I just mentioned. Years of unsuccessful attempts later, I've finally dropped the dream of sketching masterpieces and that's helped expose the true value of the pen and paper in the design process. Specifically:

It's low-cost.
It's quick (and, it's OK for it to be dirty).
It helps you dive into details.

Paper should be used as a tool to facilitate brainstorming. You can use it for any aspect of the design from feature prioritization to layout. If you find yourself struggling to introduce a paper and pencil into your design process, you're likely working against the natural grain of your thought process. Or, you've probably set up unrealistically lofty expectations from the mighty paper and pencil. My advice is to expect paper to help you explore and capture the images and ideas in your head, and nothing more. And if that means that you write down random lists of ideas, great. If that means that you sketch out site layout, even better. If it means that you draw intricate shapes that accrue to logo designs, I salute you. Whatever it is, know this - paper is a very powerful first step to designing something, and embracing it will bring you only good.

Feature Wireframes for the Liberated Designer

As of late, I have found myself creating something I call "Feature Wireframes" because they find the sweet-spot between specifications and real wireframes. Feature wireframes, despite looking exactly like traditional wireframes, only capture functionality without making any guarantee about typography, color, or even, layout. That's where they differ from wireframes as understood by most UX professionals today which often capture layout. I prefer to save the layout exercise for my late night design sessions. There are a few benefits to creating feature wireframes:

Designers think visually; trying to picture the site in the form of a feature wireframe forces you to think about the details, and subsequently, the feature set of page.
Layout is one of the most important parts of a web design, and trying to finalize it within the first couple of weeks of the design phase seems counter-intuitive. Feature wireframes decouple the layout process from writing specifications, and keep the project moving forward.
They unblock the development team who really only care about rolling up their sleeves on the core features of their site.

Before we move on, it's probably worthwhile mentioning that feature wireframes are not for everyone, or every situation. But if you're on a project with a set of stakeholders who trust your design chops, feature wireframes can be extremely liberating because they give you much-needed freedom to explore the best design solution.

I Scratch Your Disk, and You Scratch Mine

Once a rough vision is in place, and feature wireframes are pinned to the corkboard behind your screen, you're ready (and generally itching) to roll up your sleeves, fire up your favorite illustration tool, and start painting pixels. The process I use is very similar to how professional interior decorators recommend designing a room: pick an object in the room as the focal point, and design the room around it. While the feature wireframes aren't completely representative of the layout and elements in the site, they generally have some good ideas that you can use as a starting point for the site design.

Finding Inspiration

"Good designers borrow; great designers steal.

Kicking off visual design for a web site is possibly one of the most difficult parts of the process. It's very difficult to commit to a visual identity; almost as difficult as actually coming up with one. Something that really helps me get over "designer's block" is browsing through CSS showcases. A while back I found Tanya Merone's portfolio through a CSS showcase, and I've been hitting it ever since because her Favorites section neatly lists most of the CSS showcases around. So, Tanya, if you've been getting a boatload of hits from Redmond, WA, that's me.

I spent a considerable amount of time looking for inspiration for MIX Online during this phase. I bookmarked a few sites that inspired me, but nothing really blew me away. In an effort to keep the project moving forward, I moved onto the next phase: visual prototyping.

Visual Prototypes

Whenever I enter the Photoshopping phase without true inspiration (and generally, this happens more often than not), I account for some failed concepts. I call these "Visual Prototypes". If you ever find yourself not entirely sure of the visual direction your site needs to take, but need to stay on schedule without compromising your quality bar, push forward. It'll click eventually, but the key is to not get stuck. Stay unstuck.

And, thus, a good 30 hours of time was spent in Photoshop between two completely different concepts. I completed neither, but each explored different visual motifs, navigation metaphors, and layout. I now boldly go where no designer likes to go. I present to you, the failed concepts.

Yes, they look nothing like the final design, but if you squint, you'll see several elements that made it into the final design. The lesson here, if there is one, is that prototyping is not just for engineers; it's for web designers, too. While visual prototyping doesn't work seamlessly, your comps will likely look like crap, and you'll have to throw most of the work away, it'll help you figure out some key stuff that will be integral to the success of the final pass.

The "Aha!" Moment

As designers, we're conditioned to pretend as if the design process adheres to a deterministic algorithm: gather requirements, create use cases, create wireframes, and so on. When we don't, it makes the rest of the team uncomfortable because it introduces unpredictability into the schedule. But the reality of the matter is that if you're looking to design something unique and excellent, it rarely follows some predictable path. You tend to collect data and iterate back and forth between all the phases I mention above, and at some point, the right nerves fire, the moons align, and you have that "Aha!" moment.

The "Aha!" moment on MIX Online came sometime toward the end of the Visual Prototyping phase. Like many fellow designers, I am on the long list of folks who often visit Veerle's blog not only because she's an awesome designer, but also because she publishes some great content. I came across an art post she did on James White, a Canadian designer [2]. The first piece on this post, titled "Commodore", just blew me away. It had all the elements of a strong visual identity fitting for a site like MIX Online.

Don't fight the "Aha!" moment and don't be ashamed of it. It's natural. Embrace it, and communicate its existence to your team without being arsty-farsty about it. Just be straightforward. If they're smart and value good design, they'll accommodate for it. If not, well, you know what to do, right? It's a win-win.

The Final Pass

Jumping back into color comps after the "Aha!" moment has taken place is a wonderful feeling because you can almost picture the whole site in your head. All the pieces finally fit together. In the case of MIX Online, the inspirational piece allowed me to quickly make some key decisions that you now see on the site:

The Commodore branding has 5 unique and very saturated colors. Coincidentally, we'd decided by then that MIX Online would have 5 unique sections. I decided to pair each section to a dominant color: link colors, footer elements, logos, etc. would all change based on the current section of the site.
The site would embrace sharp edges and a clean grid as these are both characteristics of the retro olden days of computing.
I experimented with type and final settled on a combination of Georgia and Lucida Sans. While Lucida Sans is a pretty commonly used typeface on the Web today, Georgia seems to have become increasingly sparse. All the more reason to help Georgia's wonderful curves make a comeback.
The lab section would provide an aggregate view of all our bits, but each lab would get its own section. This was a pretty natural choice because each lab is different from the next and potentially has a different audience, different elements, and so on.

The 80/20 rule couldn't have been truer than what it was on the MIX Online site design. In the final pass, I created approximately 8 comps. Each captured a core section of the site, and the whole pass took just a work week. Comparatively, we spend a good 4-5 weeks brainstorming, capturing requirements, prototyping, and analyzing the site design.

Slice, Dice, Toss and Turn

Sign-off was pretty easy because pretty much everyone knew what was going on through the process. There's a fine balance to be drawn between showing too little and showing too much through the process, but if you can get away with it, err on the side of too little. This is clearly just a preference of mine and I'll spare you the reasoning. If you don't have that sort of freedom, your ability to communicate clear timelines and status can go a long way in buying you that freedom. In any case, you should always spend a reasonable amount of time communicating the status of your progress and setting reasonable expectations for delivery.

There are loads of services out there that take your PSDs and promise to turn them into standards-based, semantic markup for very reasonable rates. Essentially, these are shops that employ front-end web developers - often in other countries - and project-manage the slicing and markup exercise from somewhere local. In theory, it's a great idea, and if you browse around you'll find that others with good credibility in web design such as Jonathan Snook, have written positively about it.

As much as you may not want to, you may need to farm out XHTML/CSS development due to scarcity of development resources. After reading others' experiences with slicing services, and peering through sample code on several of the services' sites, we decided to go with a different service. While our experience was not as excellent as Jon's, we did get the whole site marked up in a week. And, it validated. But was the code semantic? Not really. It's beyond the scope of this article to cover that, but watch out for an opinion on the topic in our Opinions section.

So, there we were, stuck with markup that validated but often made us cringe. What now?

The Platform Saves the Day

We did what good corporate citizens do: we shipped. We decided to clean it up as much as we could, and shipped it, fully knowing that we were going to refactor most of it in the future. Fortunately, our shiny new platform - built on the same codebase as Oxite - allowed for swapping out views without affecting anything else on the site. Oxite is built on a framework called ASP.NET MVC that was released by Microsoft to help web professionals build standards-based sites, something its parent technology, ASP.NET, always had trouble with. The framework is built on a very popular design pattern - chances are that you've used it unknowingly - known as Model-View-Controller, or MVC for short. The pattern essentially provides a way to decouple the presentation layer from the data model and business logic of a software application.

The capabilities of your CMS are of utmost importance to you as a designer because it informs the requirements exercise early on. If you're designing for WordPress, you will likely have different options available for you than if you are designing for Sharepoint. Of course, understanding the capabilities requires you to delve into some technical aspects of web design. You don't need a Computer Science degree, but an understanding and empathy for programming can go a long way.

I frequently encounter web designers who take pride in not having to think about the "technical" aspects of site development, and avoid anything remotely related to programming like the plague. They create comps and leave it at that. If I may offer my two cents, I believe that attitude is on path to extinction, and those web designers will have to revert back to graphic design eventually. If that's your thing, then cool; there are great careers to be made out of pure graphic design. But if you're serious about building a career designing for the Web, it's time to start sifting through the technical shelves at the bookstore, and biting on a topic or two. If you look across the board, the best web designers out there are very technical. Take Shaun Inman, for instance. Not only does he have a fantastic grasp of graphic design, but he can also take XHTML, CSS, PHP and JavaScript for a good spin.

I know, I know. You hate me for saying this, but I am just the messenger. I suggest that if you're affected by what I just said, bookmark this article, power down your computer, and go buy yourself a few pints of Stout. I promise it'll make it better. When you're done, go buy a book that inches you toward your dream of being an awesome web designer. This one will give you a rock-solid start. OK, I'll get off my soapbox now.

3... 2... 1... 404!

The last few hours are always frantic - emails flying all over the place, assets being created on the fly, last-minute code fixes that cause regressions, managers doing drive-bys to get status updates, your significant other IM'ing you wondering when you're going to be home and if you're going to have time to drop by the vet's to pick up food for the cats whom you can hear frantically meowing in the background. No matter what amount of planning you put into it, the pre-launch hours inevitably get chaotic. But don't read that as, "Don't plan. It doesn't help anyway." On the contrary, plan it all. Get it on paper and get everyone to sign off on it. Even better, create and assign tasks in your bug database. If you don't, it's only going to be worse, and you may slip your launch date.

In no particular order, here are some suggestions on how to make the launch exercise as painless as possible:

Clearly identify the launch owner. There can only be one, and that individual is the axle for the wheel of your launch unicycle. In times of crises, it is critical for one person to be at a vantage point that affords them the ability to "make the call".
If you're the owner, start capturing each and every detailed task that needs to be completed in order to launch. No task left behind should be your motto. Assign an owner and a due-date to each. Delegate. Communicate frequently.
Deflect last-minute design requests like Teflon. A simple way to deflect is to turn it back to the requestor, "Would you block launch if that's not in?" Only accept "yes" or "no" for an answer. Logic always prevails.
Do frequent passes through the site. Expect things to break until the last minute.
Keep a sense of humor about you. As one of my old bosses over at Amazon.com always used to say, "It's just a site. It's not like we're curing cancer."

Honestly, there's an entire article to be written around "Launch". You need to hit the finish line, and all the decisions you make should help you get there. This isn't to say that you need to launch at any cost; I've been on teams that triage ridiculously important bugs to hit launch, and that's just not how it's done. Make the wise choice for both your customer and your company.

The Real Fun Begins

The day after launch is generally a busy day because you quickly switch to maintenance mode. Not to mention, all those feature requests that you punted before launch come racing back into your inbox. However, what's more important is that your site is online. Customers - real customers - are hitting it! It's daunting because all those things you fought for and protected during the design phase for the customer are now in front of that very customer. What if the customer doesn't like the design? Time for a quick pop quiz -

Q: What counts as valid customer feedback?

Someone at your company emails you and says, "I'm not sure that image is encouraging the audience to click."
Your wife emails you and says, "I really don't like that color."
Your colleague drops by and says, "Nice site! But I have one issue with it - I absolutely hate the way I have to click this to do that."
Your boss - despite signing off on it earlier - says, "I think we need to do something about the placement of that text. I don't think it works where it is."
All of the above.
None of the above.

If you picked (e), you win. You thought it was (f), didn't you? Shame on you. It's easy to forget that on the Web, the world is your user base. Some are more important to you than others, and you should absolutely factor that into making decisions around evolving a design. But accept the fact that everyone is a user, and all feedback is innocent until proven guilty. The sooner you accept that, the easier it's going to be for you to design killer sites.

All I'm recommending is that you hear everyone out; you could justifiably ignore all the feedback, but don't do it before you've assimilated it. Try to detach yourself from the need to think of it as criticism, and instead think of it as a clue that something may be broken. Once your site has launched, you're an investigator - always searching for clues - trying to make your site reach its potential Zen (instead of trying to solve a mystery). If you're a perceptive listener, users do all the heavy-lifting for you by giving you these clues. Combine those with site analytics tools and you're bound to succeed.

In a Gist

"I saw the angel in the marble and carved until I set him free. - Michelangelo

My contention is that the web-design process - and more broadly, the software-design process - is barely understood. There are few who, through sheer creativity and experience, have found their own balance and rhythm in designing great web experiences. The wide majority, however, are still struggling to rationalize it and are still a ways from being able to standardize the process. But maybe that's the very problem - one can't follow a one-size-fits-all template when designing web and software experiences, because at some level it's more art than science. Whether that's true or not, one thing is for certain: there's much to be discovered, and the journey has just begun.

Colophon

Jesse Bennett-Chamberlain's most-excellent write-up, Redesigning the Expression Engine Site, served both, as inspiration, and as validation for many of my own trials and tribulations around the web design process.
Tanya Merone's bookmarks have saved the day time and again when I'm seeking some inspiration.
Check out our very own blogging platform, Oxite.
ASP.NET MVC is a framework that allows you to completely decouple presentation from business logic in web development.
Windows Live Writer is how we publish posts on MIX Online. This article was published through Live Writer.

Footnotes

[1] Note to readers. Whenever you see the world "brutal" on this site as written by one of us, it's a good thing.™

[2] Check out James White on Flickr, if you're looking to be blown away by some really original work.

Microformats: The Quiet Revolution

John Allsopp — Wed, 22 Oct 2008 03:05:00 GMT

Web 2.0? More like Web 1.0.

As many suggest the end of Web 2.0, and others announce the coming of 3.0, if we look at the heart of the web experience for most users, has much really happened since 1995?

"By adopting microformats, you'll be helping to fuel the next generation of browser and search engine innovation.

Despite the rise of CSS, Ajax, and Rich Internet Applications, two key aspects of our web experience are essentially unchanged since the days of Lycos and Mosaic (ask your grandparents if those names aren't familiar to you!).

Let's take a look at how this really is the case, how it things could be different, and then see at how microformats can, and are already changing the web landscape, and how you can use them to your advantage in your own projects.

Browsers 1.0

In 1995, what could you do with a web browser? Well, you could visit web pages, print them out, bookmark them. And that's about all. In 2008 - we can still visit web pages, print them out, bookmark them. And that's still about all. The role of browsers, and our experience as users is just about identical.

If you think that's a stretch, here's a screenshot of the first widely used browser, Mosaic.

And here's its great great grand child, Firefox

With the exception of the search field, it's more or less all there on Mosaic.

Search 1.0

The other central aspect of the web experience, one that just about any web user will do several times a day, is search.

Of course, since 1995, several companies, culminating in Google, have dominated search, but the search experience is more or less identical now to the search experience in 1995. Here's the search experience then and now:

We visit a search engine...
We decide on some keywords for the kinds of pages we want to find...
The search engine returns a list of sites that match our criteria...
We choose a link and click it...
We visit the page.

Now, you might argue that since the browser and search engine as they are have served us well for the last decade or more, then there's not need to go changing them - "if it ain't broke then don't fix it".

But both browsers and search engines could provide much more functionality to their users.

What if when we visited a web page, our browser recognized locations - addresses, landmarks and so on, and easily allowed us to map them on Google Maps, Virtual Earth or other mapping site? What if the browser recognized people, and let us add them to our address book? Or events, and allowed us to easily add them to our online or desktop calendars?

Similarly, what if a search engine returned results about a movie or restaurant we searched for with an average rating from reviews across the web, no matter whether they are published - in newspapers, on blogs, in forums, or on any other type of site? What if results which contained information about location were displayed on a map, or results that contained information about dates and times were displayed on a calendar?

Search engines could also enable users actions other than simply visiting a site - they could, like the browser examples earlier, let us add events to our own calendars, or contact details to our address books, with no need to visit the page itself to get those details.

We do see some limited examples of this kind of functionality at search sites, but on the whole, we are still very much in the "Search 1.0" paradigm.

Why is it so?

So, why is it that we've seen so little innovation in browsers and search? For one thing, it's easier said than done. Software is not particularly good at "Natural Language Processing" or NLP (which is basically a fancy way of saying "understanding the written word"). If you think about how most web pages are coded, we don't markup addresses, or locations, or reviews, or events with any specific HTML to help software more easily extract that information from the page. But if we did have a way of marking up this kind of data, then browsers and search engines could very easily extract it, and provide the sort of functionality we just described.

And hopefully by now you've guessed the role of microformats - to provide a way in which we can mark up web pages so that common types of information can be more easily extracted from them by software.

Enter Microformats

So, now we have an idea of what microformats are for, the next question is how do they work? The good news is that If you are a reasonably experienced web developer, familiar with aspects of markup like the class attribute, the abbreviation element, and a handful of other quite commonly used features of HTML, you'll have very little to learn. Even if you have just a basic understanding of HTML, there's really not a lot to it. Let's take a look at an example to demonstrate.

Let's suppose a site has an address - something like this

<p>1164 Morning Glory Circle</p>
<p>Westport</p>
<p>Connecticut</p>
<p>06880</p>
<p>USA</p>

Let's now use a very common microformat, ADDR, to mark this up. We'll discuss ADDR, and where it comes from, after we've looked at the example.

First, we'll want to identify the whole construct as being an address. So, let's wrap it in a containing div (it's very likely the address would already be marked up in such a way):

<div>
<p>1164 Morning Glory Circle</p>
<p>Westport</p>
<p>Connecticut</p>
<p>06880</p>
<p>USA</p>
</div>

Now, we'll add the magic microformats dust - a class value of "adr" to this div

<div class="adr">
<p>1164 Morning Glory Circle</p>
<p>Westport</p>
<p>Connecticut</p>
<p>06880</p>
<p>USA</p>
</div>

This technique of using the class attribute of an element to describe what the element is is one of the key aspects of microformats, and you'll likely find yourself using it most of the time when working with them.

We'll now similarly mark up the components of the address using the ADR microformat.

We'll identify the street address...

<p class="street-address">1164 Morning Glory Circle</p>

... the locality

<p class="locality">Westport</p>

... the region

<p class="region">Connecticut</p>

... the postal code

<p class="postal-code">06880</p>

... and the country.

<p class="country-name">USA</p>

And, altogether we have:

<div class="adr">
  <p class="street-address">1164 Morning Glory Circle</p>
  <p class="locality">Westport</p>
  <p class="region">Connecticut</p>
  <p class="postal-code">06880</p>
  <p class="country-name">USA</p>
</div>

Now, I'm sure many of you are asking, "where did these terms like 'region', or 'postal-code' come from?" To cut a long story short, microformats attempt as much as possible to reuse existing standards, rather than invent new ones. That way, we increase data interchange, and take advantage of the considerable effort that has gone into developing those standards.

The ADDR microformat is a subset of the hCard microformat, the microformat for contact details, which is based on vCard, the more or less universal format for contact details in address book applications. The terms like 'region', and 'country-name' all come from vCard.

All microformats work in more or less the same way as this example - they use existing aspects of HTML, like the class attribute, in ways that conform with the HTML standard. And by far the most commonly used aspect of HTML in microformats is the class attribute, a feature of HTML just about any web developer will be familiar with.

Microformats in the real world

Ok, so even if microformats don't take much effort to learn or implement, is there really any practical value to them? I think there are a couple of very valuable reasons why you should consider microformats.

First, your pages need to be marked up anyway. By choosing an existing format like ADDR, you don't have to do any work developing your own markup conventions, and your code will be much more maintainable and readable, by virtue of using a common markup conventions. If every instance of an address on your sites is marked up in the same way changing their appearance using CSS will be far simpler.

"You'll be part of a quiet revolution in browsers and search that is already underway.

But beyond this very practical reason, you'll also be part of a quiet revolution in browsers and search that is already underway.

The examples of what a browser could do with the data in a page we looked at earlier aren't simply great concepts - they are actually being implemented in browsers today.

There's an Add-on for Internet Explorer that will recognize microformatted content, like contacts, events and locations in any web page, and display them for the user. Here for example, is my personal site, which lists things like my speaking engagements in the hCard microformat, contact details using hCard, and location using the GEO microformat.

The microformats add-on gives me the option of adding an event to one of several on and offline calendars, or contact details to an address book. You can also show any locations in the page on a map.

The add-on is also available as stand alone JavaScript that you can add to your own site, so that your visitors can access and use your microformatted data in the same way, no matter what browser they are using.

There's a similar microformats extension for Firefox that provides a set of actions you can perform on microformatted content on any web page you visit with that browser. This extension, called Operator and created by Michael Kaply, has really led the way in bringing microformats to a wider audience.

On the search front, Yahoo! SearchMonkey now indexes microformatted content - and provides an API so developers can build their own applications on top of this data. Hopefully this and related innovations from other search engine developers will drive a new wave of search experiences, on top of structured data like microformats.

By adopting microformats, not only do you get the practical benefits of a set of well developed conventions for marking up common data, but you'll be helping to fuel the next generation of browser and search engine innovation.

Designing with Microformats

Tim Aidlin — Wed, 22 Oct 2008 03:00:00 GMT

I've been a "web designer" for about 13 years now. After many years working on-and-off for Microsoft in various scenarios, I was led to my current position as a UX Designer for the MIX Online Team.

Having worked in the world of semantic XHTML and CSS, a quick glance at the microformats site was all it took to get my wheels turning. This prototype is the fruit of the great collaboration of a few of us on the MIX Online team.

The Problem

There's so much reusable data in webpages and common types across the sites we build - names, email addresses, physical addresses, dates and locations - but until recently, there had been no way to really *do* anything with that information. It's been all cut-and-paste. Terrible. If we had a way to recognize this information as something specific (like an event or contact), what could we do with this info? How could we take this data and make it useful and standardized?

This led us to microformats.

With microformats in mind, we approached this problem thinking about three things:

Users need to be able to create microformats easily.
Once they've made microformats, users are going to want to make them look good.
Once the microformats are presentable, users are going to want use the microformats in some way.

What are Microformats?

One of the best definitions I've found online states:

"A microformat is a web-based approach to semantic markup that seeks to re-use existing XHTML and HTML tags to convey metadata and other attributes. This approach allows information intended for end-users (such as contact information, geographic coordinates, calendar events, and the like) to also be automatically processed by software. - http://en.wikipedia.org/wiki/microformats

For example, when building a webpage with HTML, a standard markup for my contact information might be:

<ul>
<li>Tim Aidln</li>
<li>taidlin@microsoft.com</li>
</ul>

To change this to a microformat, specifically an "hCard", the additions are quite straight-forward:

<ul class="hcard">
<li class="fn n">Tim Aidlin</li>
<li class="email>taidlin@microsoft.com</li>
</ul>

That's it. By using the standard HTML "class" attribute in a specific way - in this particular case, using "hCard" and other classes, we have made the content within that class useable.

"Through the use of these widely adopted standards, publishers can encode additional semantics into the HTML markup of web pages. This gives the pages meaning above and beyond the face value of the HTML elements, allowing them to be consumed, remixed, and mashed up. For example, by adding some semantic markup to a web page that describes an upcoming event, properties such as the event dates can easily be extracted and used by other services and software, like calendars and personal organizers. - http://www.sitepoint.com/article/microformats-meaning-markup

Using Microformats

As you'd expect, there are already loads of ways for users to create their own Microformats - Wordpress plug-ins, online tools, etc. We decided to add a Windows Live Writer plug-in to the mix to help foster easy creation of microformats.

Let's talk about the fun stuff: designing and styling microformats.

Designing with Microformats

From a Designer's perspective, working with microformats is easy. With an understanding of XHTML & CSS, you can use microformats as a baseline for layout of particular, common information such as contact information, event details, reviews, audio tracks, locations . . .all sorts of things.

Working with these standards makes styling with CSS very easy. As you're using the "class" attribute, and you're using the same class name for the individual data items, you can design styles around a standard. Making multiple styles for an hCard means just creating various stylesheets that refer to the standard hCard classes. For instance, just by changing the CSS and adding an image, this event:

Can look like this:

For a pretty comprehensive list of the attributes one can work with, check out this awesome cheatsheet.

I think the best way to get an understanding of how to style hCards and hCalendars is to look at the .css files provided with the Oomph Toolkit.

Design decisions with the Styles

Possibly the hardest thing about designing styles is trying to anticipate what information people are going to be providing. There are no limitations to the length of a description or the name of a location . if the user provides that information at all. There are many different scenarios. You have to design for as many scenarios as possible and put the others in the task list for version 2.

Reusing CSS on HTML, however, requires that the HTML be the same. For instance, if I have:

<div class="vevent" id="hcalendar">
<div class="summary">Event Name</div>
<abbr class="dtstart" title="2009-03-18">March 18th</abbr> : 
<abbr class="dtend" title="2009-03-21">21st, 2009</abbr>
<div class="description">Description</div>

And I style it so "fn" is bold and large and the address and email small, it looks good in the above. However if my HTML reads like the example below, then my hCard might look wacky.

<div class="vevent" id="hcalendar">
<abbr class="dtstart" title="2009-03-18">March 18th</abbr> : 
<abbr class="dtend" title="2009-03-21">21st, 2009</abbr>
<div class="summary">Event Name</div>
<div class="description">Description</div>

If you know what information you're going to be having to account for, designing using microformats is just like designing using HTML and CSS. Because it *is* designing in HTML and CSS.

The real challenge was designing the JavaScript add-in.

Designing the add-in

The Oomph Microformats Add-in is a JavaScript add-in to your Internet Explorer browser. When you come across a page with Microformats, a small gleam appears in the upper left corner of the page. From there you can spawn an overlay which displays the microformats embedded in the page, and enables export of this data to multiple applications.

When designing the Oomph overlay, there were many, many considerations:

Since we're overlaying on top of site content, how could we do it in the least-obtrusive manner possible?
What is the correct interaction to spawn the overlay, and how does that interfere with the well-thought-out site designs we would be interacting with?
What types of interactions would be a value-add to site-owners, and get them excited to add Oomph functionality to their site, and/or be excited when people had installed our toolbar?
How do we address CSS overrides and code conflicts?

Placement of the gleam and interaction

The gleam is a very critical part of the interaction model: when you hit a page with microformats, it's the little gleam (the notification in the top-left corner of the page) that lights up and lets you know that microformats await your attention on the page.

We do this by injecting JavaScript into the page when it renders.

A benefit of injecting the JavaScript was that we could then make available the JavaScript to site-owners, allowing them to add this functionality to their site, thus not requiring the user to have installed our plug-in. This also enables cross-browser compatibility so the gleam is no-longer IE specific.

Hover versus click

Nailing down the most optimal user-interaction to spawn the Oomph overlay was a problem that we considered at great length. At first, we set the user-interaction to spawn just the top toolbar of the overlay when the user hovered over the gleam. From there the user would choose the list view or map view.

It was our thought that having a "stepped process" would ensure we didn't interfere with the website with which we were interacting, but enabled the functionality provided with Oomph. Some users, however, were surprised to have the top toolbar spawn on hover, rather than click; and were confused on how to close the full window, once spawned. We have since reduced the number of steps required to access the full overlay, and require the user to click the gleam to spawn the overlay. To close the window we kept the standard close icon, but added functionality. Now, if one clicks the gleam when the overlay is open, or if one clicks outside of the overlay it will close.

Color and Transparency

We wanted to ensure that the Oomph overlay was distinct from the site with which we were interacting, so we made the Oomph overlay translucent using a semi-transparent repeating background (a quick hat tip to LightBox which has popularized this technique). This enables the user to still see the underlying information - if obscured - while interacting with the Oomph overlay.

The color of the overlay still remains a bit of a problem. The majority of the sites we found with microformats have white or light backgrounds, which led us to choose a dark, translucent background, which enables the dropdown panel to dominate over the page's content, but not obscure it completely. There are, however, plenty of sites that use dark backgrounds, which makes for a slightly different experience. If you're interested in extending Oomph, may we suggest adding some simple UI on the toolbar allowing users to swap out the translucent background?

Views

The first iterations started in bluesky wireframes. We were originally developing multiple views, where you could show more or less info using a slider. We also had the idea for horizontal scrolling. Building this within two months meant that we had to make choices. Scoping the possible views from four to one was the first big decision.

Now that we have one view, what information do we want to display? The immediate questions were:

What information is the most useful to the user?
What information will probably be available within the page code?
How much visual real-estate is reasonable to take once the overlay is triggered?

We decided that we would create a window that displays two different types of microformats: hCalendar and hCard. The hCalendar would display:

The hCard displays:

The whole overlay together looks like this:

We arranged the two microformat types to display 50% of the overlay screen, and scale according to the users' various screen-sizes. We considered other layouts, each with its own various positives and negatives: stacking, fixed sizes, and various amounts of information. It's our thought that if a user was to add a microformat type to the overlay, it could live next to the current ones, each taking 33% of the screen. We're interested in seeing how contributors extend this and add visualizations.

CSS overrides

An interesting (and frustrating) learning with this project was with CSS Overrides. Since we're working within the confines of someone else's page, if they have defined a .class, then there's a good chance that their definition will affect the way things look in the overlay. We, of course, would never interfere with the display of the webpage itself.

For example, we wrapped all of our overlay code within its own <div> and ensured all the microformat code in the page was never affected:

#iwmf
{
	position:fixed;
	top:0;
	left:0;
	font-family: Tahoma, Arial, Helvetica, sans-serif;
	color:#ffffff;
	font-size:12px;
	text-align:left;
	z-index:50;	
}

And ensured all the classes we called had the iwmf prefix:

#iwmf .iwmf_fn
{
	font-weight:bold;
	font-size:1.2em;
	text-transform:uppercase;
}

Summary

I suppose the summary is this: if you know a little bit of XHTML and CSS, it's super-easy to get started using microformats. If you have a developer buddy, or you're a decent developer/designer ("devigner"), you can start thinking realistically about creating interesting experiences with this smart little idea that has become a movement in recent years. It's broadly-adopted enough at this point that it's worth the time to investigate further.

Here are some links:

Our Microformats approach - Oomph: A Microformats Toolkit
Karsten Januszewski presents Oomph: A Microformats Toolkit at the PDC2008
Check out the Microformats home at Microformats.org
Microformats: The Quiet Revolution by John Allsopp
MICROFORMATS empowering your markup for Web 2.0 by John Allsopp
ThinkVitamin's article on How to use Microformats
BBC Radio Labs removes Microformats from their site

Thanks for reading. Please leave comments and let us know what you think. We take your feedback very seriously, and take to heart our mission of creating vibrant experiences and being good citizens of the web community.