Articles, Opinions & Lab - MIX Online

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.

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.

MIX Online, The Next Chapter

Thomas Lewis — Wed, 22 Oct 2008 03:58:00 GMT

You probably noticed the site looks a little different today than the last time you visited.

MIX Online has been a community site for web designers and developers who believe that the web is a great place for innovation. In the past, the site has given you a varied perspective of what is happening on the web, a view into our conference called MIX, and interviews with amazing people with incredible ideas and stories on how you can take advantage of the web.

But we were not content with resting there. We began thinking about how we could make MIX Online even better based on your feedback, audiences at our sister event, and people who have never even heard of MIX. We wanted to continue to be practical, conversational, innovative, unexpected and open.

Our site will continue as a community site for web designers and developers who build and believe that the web is a great place for innovation.

Here are some of the changes we have made based on your feedback:

We will take more of a scenario focus around emerging web trends. For example, Microformats is an interesting movement in the web community and we want to introduce you to it and give you some practical guidance around it.
We will continue to have our traditional blog, but we are renaming it under the heading "Opinions" that provides a more natural conversation with our small team.
We will provide practical articles with each scenario we cover that are written by people in the community, not always Microsoft's perspective.
We are providing freely downloadable, open source, and immediately useable prototypes. We not only encourage you to use these prototypes for your own projects, but to also submit code to the prototype project on CodePlex.

We have a sister conference called MIX. We hope you have the opportunity to attend and continue to engage with us before, during and after the event.

Please take the opportunity to visit, give us your feedback and ideas, download prototypes, subscribe, and most of all: keep talking to us, we are listening.

Our First Labs Project: A Microformats Toolkit Called "Oomph"

Joshua Allen — Fri, 05 Dec 2008 20:16:42 GMT

Oomph: A Microformats Toolkit

< Back to lab main page

Microformats are about enhancing the web, representing data in HTML and moving that data around. Oomph: A Microformats Toolkit is for web developers, designers and users, making it easier to create, consume, and style Microformats. In short, Oomph makes consuming and producing content for the web just a little easier, more efficient, more fun.

You need Silverlight to view this video. It’s fast, it’s free and it’s awesome. Click here to get it.

Consume

With the Internet Explorer Add-in, web pages with Microformats light up. Want a cross-browser experience? Add a slick overlay that aggregates Microformats to any web page with one line of Javascript. Read More
Style

Written for the hCard and hCalendar Microformat specifications, this set of 14 CSS styles will make your Microformatted content look beautiful and stylish. Read More
Create

Do you publish content through a blog engine? Easily add Microformatted content to your blog posts with this Windows Live Writer Plug-in. Read More

Go Microformats!

The crew here at Mix Online believe in Microformats. But don't just believe us: look at the adoption of Microformats in the wild. There are over a billion web pages with content formatted to the hCard specification and nearly 100 million formatted to the hCalendar specification. Top web properties including Yahoo, LinkedIn, Eventful, Twitter and YouTube are using Microformats. At MIX06, Bill Gates, gave props to Microformats in his keynote: "We need Microformats and to get people to agree on them. It is going to bootstrap exchanging data on the web."

Oomph: A Microformat Toolkit

With the momentum of Microformats burgeoning, we decided to build Oomph: A Microformat Toolkit. Our main goal with Oomph is to make Microformats more accessible for developers and designers. Oomph is an amalgamation of applications: an Internet Explorer Add-in built in C++ that finds Microformats on a page; a cross-browser HTML overlay built using JQuery that aggregates Microformats; a set of beautiful CSS styles for Microformats; and a Windows Live Writer plug-in written in WinForms for inserting hCards. And, the entire project is up on Codeplex, ready for community contribution and extensibility.

Consume

Perhaps the most ambitious aspect of Oomph is the Internet Explorer Add-in and the accompanying cross-browser HTML overlay. For those who install the Add-in, pages with Microformats will "light up" aggregating and mapping the content as well as providing options to export the data. Architecturally, the Add-in actually injects a line of Javascript into web pages with Microformats. This Javascript can also be manually added to web pages, providing a cross-browser experience. You can see an example of this here.

Style

Because Microformats are based on a standard set of HTML class attributes, styling Microformats with CSS makes a lot of sense. As such, we are providing a set of CSS styles that can be used to make Microformatted content look great, including even a grunge themed style!

Create

Before you can style or consume Microformats, you need to create them. With this in mind, we have built an hCard Windows Live Writer Plug-in for adding contact information to your blog posts. The great thing about WLW is that it targets most blog platforms, including Windows Live Spaces, SharePoint, Wordpress, Blogger and many others. As blogs are becoming the CMS systems de rigueur, adding Microformats to blogs certainly adds up.

Shout Outs

We would like to thank a whole range of people who have inspired and helped the project get off the ground:

Michael Kaply and his Operator Add-in for Firefox, which was inspirational.
John Allsopp, whose book on Microformats was essential reading for the whole team.
All of the folks on the microformats-discuss alias, whose passion for Microformats kept us invigorated.
The authors of jQuery, whose library we have fallen in love with.

Oomph Video

Karsten Januszewski — Fri, 24 Oct 2008 20:50:24 GMT

Here’s an eight minute demo of microformats and Oomph, so you can get a taste of what we’ve built:

<a href="http://video.msn.com/video.aspx?vid=b205ba06-8956-423c-adf2-4d25c959afa1" target="_new" title="Oomph: A Microformats Toolkit">Video: Oomph: A Microformats Toolkit</a>

Oomph Live at the Microsoft Professional Developers Conference

Karsten Januszewski — Mon, 03 Nov 2008 21:17:24 GMT

I will be speaking about Oomph at the PDC, which you can see up on the PDC sessions page. Tim, the designer on the project, will be there as well as Thomas, our fearless leader. We'd love to meet with folks if you are down in LA, so please feel free to get in touch if you'll be there.

Here's more on the session itself (formatted as an hCalendar using the event Windows Live Writer plug-in.)

Oomph: A Microformats Toolkit @ PDCMicroformats are about enhancing the web, representing data using HTML. Targeted at web developers and designers, Oomph makes it easier to create, consume, and style Microformats. Oomph is an amalgamation of applications: an Internet Explorer Add-in written in C++; a cross-browser HTML overlay written in JQuery; a Virtual Earth visualization that geocodes on the fly; a set of beautiful CSS styles; and more. Hear how and why we built it, as well as how you can be part of the burgeoning Microformat movement.Wednesday, October 29, 2008 3:00 PM to 4:15 PM

Los Angeles Convention Center

1201 South Figueroa Street

Los Angeles, California 90015 United States

I'll also be hanging at the client track lounge on Tuesday. From what I understand, Scott Hanselman, Jesse Liberty, and some other interesting MS folks will be there at that time as well. Here's that event formatted as an hCalendar as well!

Hanging Out at Track Lounge Tuesday, October 28, 2008 3:00 PM to 6:00 PM

Los Angeles Convention Center

1201 South Figueroa Street

Los Angeles, California 90015 United States

UPDATE: We're back from the PDC and sorting through how all the announcements will affect our plans for Mix Online. The folks over at our sister site, Channel 9, did a great job of getting all the sessions recorded and posted. As such, our talk about Oomph is now available for viewing and can be found here.

Three Examples of People Extending Oomph

Karsten Januszewski — Thu, 20 Nov 2008 01:20:49 GMT

Since we released Oomph last month, we've seen some exciting uptake from the community as people take the Oomph script and make it available in interesting ways:

WP-Oomph

Meitar Moscovitz has made a WordPress plug-in called WP-Oomph. The plug-in injects the Oomph script into your WordPress blog posts for you.

GreaseMonkey Script

Pascal Van Hecke implemented the Oomph script for GreaseMonkey, which is a plug-in for Firefox that does javascript injection. He has it hosted up at User Scripts.

Bookmarklet

Lastly, a thread on the Codeplex discussion resulted in making Oomph a bookmarklet which works across browsers.

Please let us know if there are any other Oomph implementations or extension so we can let people know about them. And thanks to all who have helped to spread Oomph thus far!

Embrace Smallness

Thomas Lewis — Mon, 24 Nov 2008 23:25:41 GMT

In a world of super-sizing and "Go Big or Go Home!' tag-lines, it is sometimes hard to go against convention and embrace your smallness. Success appears to be made of quantity more than quality. I tend to believe that you can be successful by embracing your smallness.

Smallness requires you to focus on what is important.

For example, our team is small. We cannot afford to do every thing. When you try to be good at everything, you find yourself not being good at anything. It is better to focus on the important things and do less, than to try to do it all.

Smallness allows you to change quickly.

Question: what can change course faster, a battleship or leisure boat? Have you ever tried pulling a meeting together with 9 people to make a decision? I once tried, and the only hour where everyone was available was 8am, 2 months away. Smallness can help create nimbleness.

Big organizations can embrace their smallness too.

Just because you are in a large organization does not mean you cannot take advantage of smallness. You can break up big teams into smaller ones. You can look for the right behavior, not incremental behavior. You can apply constraints that force you to be more innovative. For example, ask yourself questions like "What if we didn't have a budget for marketing, what would we do?" or "What if we had to cut 50% of our upcoming feature set, what would we keep?"

Smallness can make you define success in a different (and sometimes better) way.

Many web sites look at quantitative measures for success. They may look at page views and consider success when they reach the 1M daily visitors mark, but is that the right measure of success? If you have an e-commerce site or a portfolio site, you don't want a high bounce rate, you want customers! Take time to think what success should be, you will be surprised how qualitative it just might be. Albert Einstein had a sign on his wall at Princeton that said: "Not everything that counts can be counted, and not everything that can be counted counts."

Smallness can help to create a personal connection.

People don't connect with faceless entities. They connect with people. Social networking is huge because of this. With smallness, people can learn about you, your opinions and ideals and connect with those things. There are great examples in my opinion of folks who have embraced their smallness like 37signals and our own local Jackson Fish Market.

So let me ask you web designers and developers, how have you embraced your smallness?

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.

A Bright Future for Software

Joshua Allen — Wed, 03 Dec 2008 21:17:32 GMT

It seems like everywhere you turn these days, there is more bad news about the global economy. Bankruptcies, layoffs, and bailouts continue to mount. We are hearing the words "recession" and "depression" more frequently than ever before in our lifetimes. The truth is, the world is in the midst of a severe economic crisis, and the end isn't yet in sight. But if you do software, web development, or media, you have good reason to be hopeful about the future. This is the time to hunker down and continue growing your skills and experience, because what you do will be more important than ever.

Unlike some of the other industries hard-hit by the crisis, we've already been through this before. The information technology sector alone lost 700,000 jobs when the Internet bubble burst in 2000. These were permanent job losses, never to be recovered, and even the most pessimistic estimates predict only a fraction of the losses this time around. Our industry is paranoid by nature, and we've watched a number of failed business models go by the wayside since 2000, while new models have emerged. There will still be some painful lessons to learn before the worst is over, but our industry as a whole is much stronger than we were 8 years ago.

The real reason for hope, however, is the nature of software itself. Software is one of the most scalable forms of human value creation ever achieved. When you write a piece of software, your skill and effort can benefit thousands, millions, or hundreds of millions of people with almost no incremental cost to you. Web developers understand this intuitively. Facebook expends almost zero incremental effort to propagate new features to 100 million users. The same holds true of traditional skrinkwrap companies. Adobe Software, who spend heavily on research and development, still enjoy 80% profit margins when expenses are accounted for. Microsoft, Google, and Apple enjoy similarly high margins, and it's not because we are geniuses -- it is because software is such a superbly scalable way to provide value.

This wasn't always a matter of common agreement. There was a serious debate in the 1990s about the value of software. Some companies felt that software was simply free "bait" that could be used to sell hardware. Those companies are now defunct. And most importantly, companies like Google and Apple (and of course, Microsoft) who focused on software, have done well. This isn't to say that hardware is defunct -- back in 2004, Steve Jobs famously explained that the iPod is simply "software in a box". The complete experience requires you to purchase the proprietary hardware and pairs you with the iTunes software service, but these are essentially mechanisms to prevent piracy. The real competitive advantage is in the software. The mobile handset companies who have done very well, all realize that their hardware is a mechanism used to sell their software experiences, and not vice-versa. Likewise, Google's crown jewel, the pagerank software, is kept secret from most Google employees and is hidden behind a service, yet can benefit millions of users by being made available over the web.

You already know that creating software is hard. Skilled user experience professionals, developers, and testers don't grow on trees. Traditional software (whether in a file, in a box, or in a cloud) will be more important than ever, and the massive changes taking place in the world economy will present some new opportunities for skilled people to contribute to the common good. Software will be needed to help fill the holes left by the decline of mainstream news organizations. Software will be needed as spending on energy independence increases drastically. Software to make healthcare more efficient, software to help citizens connect more effectively with government and social programs, software to educate, inform, and inspire. Yes, software will be more important than ever. There may be lean times ahead for all of us, but there is no better time to start getting better at what you do.

So, what are the trends in software that get you excited about the future? Where do you think the biggest challenges and opportunities lie? We'd love to hear from you. And don't forget to subscribe to the RSS feed or follow mixonline on Twitter to get future updates.

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.

Oxite

Nishant Kothary — Fri, 19 Dec 2008 21:23:07 GMT

Oxite

Oxite (alpha) is an open source, standards compliant, and extensible content management sample that can run anything from blogs to big web sites. We know this because it runs MIX Online.

Download Oxite (alpha) from Codeplex but if you must, scroll to learn more

What's in the bag?

Everything you could ever want When you roll your own blog or web site, you are faced with a huge list of protocols and features that you need to implement, but all you care about is building the best web experience you can dream up. Oxite provides you with a strong foundation you can build upon - pingbacks, trackbacks, anonymous or authenticated commenting (with optional moderation), gravatar support, RSS feeds at any page level, support for MetaWebLog API (think Windows Live Writer integration made easy), web admin panel, support for Open Search format allowing users to search your site using their browser's search box, and more - so, you can spend time on designing a great experience.

Create more than just blog posts. Oxite includes the ability to create and edit an arbitrary set of pages on your site. Want an 'about' page? You got it. Need a special page about your dogs, with sub-pages for each of those special animals? Yep, no worries . the ability to add pages as a child of another page is all built in. The web-based editing and creation interface lets you put whatever HTML you want onto your pages, and the built-in authentication system means that only you will be able to edit them. And if that's not enough, well, you have all the code, don't you?

We heart web standards. Web development isn’t easy. Oxite shows that you can build a standards compliant website, starting with design and markup and realizing that vision into a web application using ASP.NET MVC. The current iteration is an alpha release and we'll continue to ship periodic updates based on all the great feedback we're hearing. We’ve also made it open source so that people can look at the code and even contribute changes along the way.

Lone blogger, or part of a pack? Oxite includes support for multiple blogs on one site, as well as the ability to contain the data for more than one site in the same database.

Learn from MIX Online. We know how frustrating it can be to get going on building a great site on a powerful platform. We're providing a default template to get you started, but fret not if that's not enough. If you're anything like us, you learn best by sifting through code. So, we figured that we'd package up MIX Online codebase for your perusal. If nothing, it should give you a rockin' good start at building your own site.

Screenshots

Video

You need Silverlight to view this video. It’s fast, it’s free and it’s awesome. Click here to get it.

A Quick Overview of Oxite

In this video, Adam Kinney, one of the early cofounders of Oxite, talks to Erik Porter and Nathan Heskew about what exactly Oxite has to offer. Erik and Nathan take you on a whirlwind tour of everything in the Oxite bag. If reading is not your thing, this video is for you. (6m42s)

Other versions: MP4 | High Quality WMV

Be sure to check out our lab for more cool stuff.

Quick Links

You can download the Oxite source as well as check out example implementations of Oxite on CodePlex.
Got questions about the project? Check out the discussion forums.

Oxite: Putting Your Design Front and Center

Joshua Allen — Tue, 16 Dec 2008 22:07:49 GMT

If you're a professional front end web developer, you care deeply about web standards and professional best practices like semantic markup, unobtrusive JavaScript, and CSS. And you're used to seeing Microsoft's web products painted in a not very flattering light regarding these best practices. It's practically cliche to see a litany of standards validation errors on a random Microsoft web site; especially ironic on web sites which are intended to sell the Microsoft web platform. And if you've been in this industry for any amount of time, you probably know people who have turned down contracts with clients who demand that the site be developed in ASP.NET or Sharepoint, because of a perception that "it's impossible to use ASP.NET to produce clean, semantic markup".

While some of these past criticisms were warranted, things are changing rapidly. With the release of Oxite and the accompanying articles, you have everything you need to accept ASP.NET projects without abandoning professional web standards and practices. Oxite is the first and only ASP.NET based open-source CMS and blogging engine that encourages you to do "standards first, markup first" web site creation; a professional best practice on other platforms like Django, Ruby on Rails, and PHP. Nishant's article takes you step-by-step through "standards first, markup first" web site creation and the process of leveraging Oxite. And Molly's article can be used to convince skeptical business decision makers who might not yet be sold on standards-first web site creation.

It's Our Job

In the past couple of years at Microsoft, we've redoubled our efforts to support web standards. Examples include IE8 passing Acid 2, Visual Studio supporting JQuery, Expression Web built from the ground up to support web standards, and our web services stack baking in REST and JSON support. Because of our unique market position, Microsoft has a unique obligation to interoperability. In fact, Steve Ballmer and Ray Ozzie recently made it official -- it's our commitment and responsibility.

So, if respect for web standards is Microsoft's official policy, why is it still so common to see skepticism regarding Microsoft products and web standards? This may be due to some lingering historical bias, but this alone isn't sufficient to explain the perception. The simple truth is that there are still plenty of sites and projects out there which don't produce clean, semantic markup (let alone markup that validates). I think this can largely be explained by historically different perspectives.

For starters, many of the most vocal and influential .NET developers come from a background similar to the people in the Enterprise Java community (in fact, many are converts from EJB). For them, the markup and JavaScript are a side-effect of the backend code, and the most important priority is to factor the server-side object model, state management and code as elegantly as possible. The server code is the starting point and purpose, and the markup is essentially a "necessary evil" that is used to connect the code with an end user.

Conversely, people coming from a professional front-end web development focus tend to see the markup (and JavaScript and CSS) as the most important part of the application. Elegant semantic HTML plus unobtrusive JavaScript make your application future-proof, open the door to automation, accessibility, and numerous other benefits. To these professionals, the server side code is less important -- a necessary evil that exists to connect their elegantly factored client markup and code with a database or other service.

This isn't to say that one perspective or the other is "wrong", but it does help explain the historical dearth of focus on "standards first, markup first" samples on the Microsoft web platform. When the most vocal and prolific community members have historically seen professional web standards as being secondary to server-side code factoring, it's not surprising to see their samples, recommended practices, and products reflect those priorities.

Enter Oxite

We created Oxite, first and foremost, to show how easy it can be to support professional web standards best practices on ASP.NET. Nishant's article walks you through the process we used, and you'll notice that it's very similar to the best practices you would follow in Django, Ruby on Rails, or PHP. Don't ever let anyone tell you that ASP.NET is a different beast -- it *is* possible (and easy!) to start with clean semantic markup and have it emerge from the framework unscathed.

In addition, we created Oxite to be something that you can download and use in your own projects. We provide source and a liberal license, so you can use and modify the software how you like. We provide you with fully working code, so that you don't need to become a backend coder yourself, but it's exciting to see people from the community already creating tutorials and providing information about how to extend and improve Oxite.

Finally, you should know that there are other CMS and blogging platforms available for .NET, and Oxite isn't intended to be a competitor or replacement. One of the most exciting things we've seen as a result of the Oxite launch, is renewed attention to "standards first, markup first" functionality across the board. While the other engines don't claim to be focused on "standards first", you can fully expect that some will be tweaked soon to encourage and support professional front-end web engineering best practices. The positive feedback from those of you doing "standards first, markup first" development has been encouraging, and will undoubtedly influence all of us who build platforms.

We’d love to hear what you think. Is there room for a "markup first" CMS running on ASP.NET? What direction would you like to see Microsoft products move regarding web standards?

Articles, Opinions & Lab - MIX Online

Designing with Microformats

The Problem

What are Microformats?

Using Microformats

Designing with Microformats

Design decisions with the Styles

Designing the add-in

Placement of the gleam and interaction

Hover versus click

Color and Transparency

Views

CSS overrides

Summary

Microformats: The Quiet Revolution

Web 2.0? More like Web 1.0.

Browsers 1.0

Search 1.0

Why is it so?

Enter Microformats

Microformats in the real world

MIX Online, The Next Chapter

Our First Labs Project: A Microformats Toolkit Called "Oomph"

Oomph: A Microformats Toolkit

Consume

Style

Create

Go Microformats!

Oomph: A Microformat Toolkit

Consume

Style

Create

Shout Outs

Related Content

Oomph Video

Oomph Live at the Microsoft Professional Developers Conference

Three Examples of People Extending Oomph

WP-Oomph

GreaseMonkey Script

Bookmarklet

Embrace Smallness

Smallness requires you to focus on what is important.

Smallness allows you to change quickly.

Big organizations can embrace their smallness too.

Smallness can make you define success in a different (and sometimes better) way.

Smallness can help to create a personal connection.

Web Design from the Gut

Let's Do Something Brutal [1]

Paper or Plastic?

Feature Wireframes for the Liberated Designer

I Scratch Your Disk, and You Scratch Mine

Finding Inspiration

Visual Prototypes

The "Aha!" Moment

The Final Pass

Slice, Dice, Toss and Turn

The Platform Saves the Day

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

The Real Fun Begins

In a Gist

Colophon

Footnotes

A Bright Future for Software

Web Standards: Where the ROI is

Oxite

Oxite

What's in the bag?

Screenshots

Video

A Quick Overview of Oxite

Related Articles

Quick Links

Oxite: Putting Your Design Front and Center

It's Our Job

Enter Oxite