[uf-discuss] Microformats.org usability review

[Mark Rickerby]

I have been working away at this over the past week, and I'm starting
to realise that simplicity and minimalism is sometimes more tricky to
get right than complexity and overabundance.

Before going further, I thought I'd post some initial analysis of the
problems identified (thanks Tim!), and make some comments on how these
issues could be improved. Please recognize that I do think the whole
site and wiki is great, both in terms of content and design, I hope
this comes across as constructive criticism, I'm totally not trying to
detract from the hard work that people have put in which I am very
appreciative of.

Think of the feedback as adaptive strategies to suit a growing
audience. Also feel free to criticise me for any irrelevant
assumptions and prejudices you see here. It would be good to pare down
exactly what incremental things can be done on the main site, that
maximise usefulness for the microformats community, while minimizing
effort to organize, write, and implement.

=== Homepage (http://microformats.org) ===

The homepage is structured very much like a blog, which has both
drawbacks and benefits. The best thing about this layout is that it is
bold, intuitive, fast to skim, and doesn't overwhelm with navigation.
The drawbacks are mostly related to the brevity of the links and
descriptions. It looks like a complete site at first, it's not
immediately clear exactly what each link is about, nor that most of
the links are jumping off to the wiki.

For example, as Joe Average User, I would know based on the homepage
text "People and Organizations: hCard", that this is a data format for
displaying people and organizations, but then what? The link takes me
to a complicated table of contents entitled "Draft Specification". I
have to scroll down to see anything more concrete, and it's not
immediately clear where to begin reading, nor how I can start using
the format, without having to spend a few minutes hunting around the
wiki for information, or searching for a tutorial somebody wrote and
published elsewhere. If I'm not familiar with blogs or wikis (maybe a
client heard about hCard, and asked me to implement it), it's going to
take even longer.

=== About Section (http://microformats.org/about/) ===

The about page itself provides an excellent visual introduction to
microformats. The diagram is displayed prominently, and gives an
immediate context to where microformats lie in the "space" of semantic
markup technology. The bullet points do a good job of explaining what
is unique about microformats, especially emphasising the importance of
process, and adapting to existing behaviour.

What is less clear is exactly how this page functions within the rest
of the site context. It seems this "tip of the iceberg" is aimed at a
very specific audience (those who responded immediately, when the site
went live last year). But what about those new to microformats? The
content here is conceptual and general, and makes too many assumptions
for a general audience (I see what microformats *are*, but what do
they *do*, what are the immediate *benefits* for my website?). Apart
from the diagram image, this page doesn't really reiterate the fact
that they are built on top of XHTML. Stating the obvious? Perhaps, but
I've learned time and time again not to assume that just because the
information is on a site somewhere, that people will read it, or get
it, even if they do read it.

The other weakness of this section is that despite the landing page
providing a general overview, the sub-pages in this section are
actually more meta/socially oriented ("People", "Thanks"). It is
extremely important to provide respect and credit to all the people
involved in pushing this initiative forward, but again, this
organizational context is not immediately obvious for new users. The
expectation of an "about" section is to find all the simple, dumb
facts.

=== Discuss (http://microformats.org/discuss/) ===

A spartan section, but very useful and well presented. Could
potentially be more friendly and inviting? I know the notion of
"community" is overused, but might still be a good idea to  reflect it
here somehow.

=== Code (http://microformats.org/code/ ===

Possibly useful to some people, but really doesn't have a lot to offer
in comparison with the information on the wiki. and is very skewed in
favour of XFN. I also find the labelling of this section slightly
confusing, in that I would never expect a non-programmer to think that
the term "Code" is aimed at them, yet the links on this page are
generally of interest to non-programmers. "Tools" might be a more
accurate description, which doesn't scare off those who are tech savy,
but don't consider themselves hard-core coders.

=== Analysis & Suggestions ===

A very common question from new people on the mailing list goes like
"Is there a microformat for X?" A (not always obvious) variation of
the same question is "Here's my proposal for a microformat for X". It
seems like the answer to almost all of these questions and proposals
is "A combination of Y microformat and a semantic XHTML compound will
solve your problem".

>From a meta perspective, these questions seem to be stirred from a
mismatch in vocabulary between defining a problem ("my content type is
X") and defining a specific microformat oriented solution ("use hAtom
and hCard"). The irony is that content types and usage of the formats
is already very well documented on the current website, in terms of
the current blog sidebar, and the faq and use wiki pages. So why do
smart people continue to miss this?

It strikes me that with a general audience, it is far more important
for content to communicate as closely as possible to mental models of
content. This means that information like "hCard is a 1-to-1 mapping
of the vCard standard in XHTML" is far less important than information
like "hCard is a standard approach to marking up contact details in
XHTML", and the navigation and organization of the site should reflect
this. I know some of you may think this sounds trivial or stupid, but
it's important to appreciate that even the most literate people are
busy, have limited attention spans, and often prefer to skim web pages
rather than pore over them word by word.

The homepage should provide immediate visual cues for those who have a
vague idea of what microformats are, but are looking for a direct and
pragmatic value proposition. The current featured text explains what
microformats are, but not why they are useful or how simple they are
to implement.

A "Get Started Now" link would be a great compliment or replacement
for the existing "Find Out More" link, acting as a subtle call to
action, and communicating to readers that they can potentially
implement one or several microformats with their existing content in a
matter of minutes.

http://microformats.org/wiki/use is a perfect example of the sort of
content that might lie behind such a "Getting Started" link.

A logical progression from this, is the consideration of the more
creative uses of generalized formats such as hCard. It may not be
immediately obvious, even to those who already know what hCard is,
just how broad the range of things that can be done with it.

For example, how would I, as Joe Average Designer, know that I could
easily use hCard to mark up a logo? I'd have to somehow find my way
to: http://microformats.org/wiki/hcard-examples#3.5.3_LOGO_Type_Definition
. Landing straight on the homepage, my chances of finding this
information directly are *not good*.

Incidentally, this hcard-examples page is great, but perhaps falls
more in the realm of "reference" than "tutorial". Even a "This is what
you can do" oriented section of text, linking into this examples page
would be a great step towards encouraging new designers to play.

=== Where To From Here ===

I have some more related material to accompany this analysis (a site
map), which I'll send through when I get a chance this week. If we
look at doing incremental updates, my thoughts are that the greatest
mileage would come from hand-picking the best introductory content
from the wiki, and condensing it for the main site pages. If Tantek,
Ryan, or anyone else feels that this is *not* a good way to approach
the content process, please advise me, otherwise I'll go ahead and
start tweaking some of the writing to suit, and pass it on to Tim, who
has created a mockup of the main site for testing how pages look.

It would also be great to hear from anyone who feels there is
something immediate and obvious missing from the website, or has
something that they would really like to see!

Regards,
Mark