You are reading an article. Lots more of these in the archives. Tim Aidlin Meet Tim Arrow

Articles

17Comment Retweet

Designing with Microformats

Oct 21, 2008 In Design By Tim Aidlin

What if there was a way to recognize information common among webpages 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 easy to work with? Enter microformats. With a keen eye toward UX, the MIX Online team created the Oomph: A Microformat Toolkit to help the creation, style, and consumption of common types of data found on the web

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:

  1. Users need to be able to create microformats easily.
  2. Once they’ve made microformats, users are going to want to make them look good.
  3. 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 a, something, contact, the, a, contact, you’re, many, possible, something 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:

basicStyle

Can look like this:

grungeStyle

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

oomph_insitu

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.

gleam

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.

listandmap

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:

hCalendar

The hCard displays:

hCard

The whole overlay together looks like this:

oomph_insitu

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:

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.

Follow the Conversation

17 comments so far. You should leave one, too.

Levi Freeman said on Oct 22, 2008

this is exciting stuff, i decided to test this out on my own (newly created) website http://www.levidesigns.co.uk/me/me.html

i am teaching myself webdesign from scratch and i am studying graphic design. I must say this was the easiest thing to implement, only a few lines of code and away you go.

thanks for the article.

Levi Freeman said on Oct 22, 2008

WOW was not expecting that!

a quick question. how did the site fetch my avatar...and from where was it fetched from?

i have this image i think on my windows live profile and on my wordpress profile. im guessing it grabbed it from WL. amazing!

Duncan Mackenzie said on Oct 22, 2008

Levi, we are using gravatars ... so at some point you must have gone to gravatar.com and created an image that was associated with your email address. We take your email address and do a MD5 Hash on it, which is then used as part of a URL to fetch your image from the gravatar.com site.

no said on Oct 23, 2008
  • taidlin@microsoft.com
  • Missing ". You''re fired!

    Joshua Allen said on Oct 27, 2008

    Yes, the gravatars are maintained by automattic, who are the company who make WordPress, so that''s where it would have found it.

    JellyBeen said on Nov 4, 2008

    Microformats are definitely on the to-do list of design elements and features. Great posting to help summarize and point to more information.

    Ian Muir said on Nov 16, 2008

    This is great. I know Tantek and the Microfotmats crew have been trying to get some traction with the developer community since SXSWi in 2006. It''s nice to see a solid toolkit for ASP.NET to help move forward.

    Tim Aidlin Tim Aidlin said on Nov 17, 2008

    Thanks, Ian. I''m glad you''re finding the toolkit useful/solid ... this was a great project to work on and we''re glad that it''s having some resonance with the community. We''re please to see that Oomph is being extended and implemented in the wild, and look forward to seeing what''s next with microformats. ::: systim out :::

    Hugo Tait said on Nov 10, 2009

    I really hope microformats become universally adopted, and soon. I want to encode my companies email footer information with microfomats, it seem to me like an ideal application, but it is proving problematic.

    Tim Aidlin Tim Aidlin said on Dec 18, 2009

    @??????? , I totally agree that one of the hardest things is to anticipate how users and web-providers will implement styles. Similarly, it''s a difficult issue when designing web-sites that allow for user-generated content. As a designer, you have to build restrictions into your designs, that are flexible enough for *most* situations.

    However, to be honest, there are always cases in which your design/style will break down. And sometimes you have to say "sorry, I just didn''t think about that" or "we did think about that, and just had to defer it."

    One of the greatest things about working on MIX Online Labs, though, is that we try and make all of them as extensible and open to the public as possible. It''s our hope that we can help with those cases where our labs/designs/styles *do,* in fact, break down, so we can learn from those experiences and make the offerings better.

    Thanks for the note and be sure to check visitmix.com often!

    diyaliz diyaliz said on May 1, 2010

    Microformats are definitely on the to-do list of design elements and features. Great posting to help summarize and point to more information...

    Property Guru Property Guru said on Aug 6, 2010

    Nice writeups. Only learn this microformat after seeing this article. Any useful resource book on this topic that i can buy?

    Tim Aidlin Tim Aidlin said on Aug 19, 2010

    @PropertyGuru, I really liked Microformats made simple by Emily Lewis.

    Wealth Bingo Wealth Bingo said on Nov 20, 2010

    wow...that''s cool. I will test it in the next few days. :)

    T3B T3B said on Nov 20, 2010

    Microformats are surely a necessity to implement.

    Ebook Reader Ebook Reader said on Jan 7, 2011

    Didnt know about microformats until bumping into this site. Great info and i willl try it out.

    Ebook Reader Ebook Reader said on Jan 7, 2011

    Didnt know about microformats until bumping into this site. Great info and i willl try it out.