Stephanie Lemieux's blog

We all know that metadata can be a challenge, especially in Digital Asset Management (DAM) contexts, where metadata is the only thing making those assets searchable and reusable. To all those who work with data architecture, content management, search or taxonomies for Digital Asset Management, we'd love to hear from you...

Earley & Associates has put together an industry research survey on organizational maturity and its correlation with metadata and information development best practices.

What do you get in return? Take the survey now and receive free passes to the webinar where we will review survey results and an upcoming Taxonomy Community of Practice webinar (a $100 value).

On a roll and want to yell from the rooftops about your frustrations? Take this short poll from CMSWire on your biggest DAM challenge.

Card sorting is a popular technique for getting at users' understanding of content structure, relationships and terminology. I often will break out a card sorting exercise early on in a taxonomy project using terms extracted from the client's content or pre-existing taxonomies to get a sense of what kind of organizing principles are important to the users. I also find it to be a great way of socializing the project and educating people in taxonomy and information architecture.

Recently, I've been doing a lot of digital asset management (DAM) projects, where our taxonomy is meant to help organize and give access to a collection of images or other visual assets, usually through faceted search. While the typical card sorting activity is still relevant, given that we'll be using words/labels to create the taxonomy for the assets, I've found it to lack a certain something in this context.

So during my current project with a global pharmaceutical company, I decided to try a different approach: a visual card sort.

The same rules apply here as they do with traditional card sorting: you can do an open card sort (no pre-defined categories given), or a closed card sort (established set of primary categories). The only real difference being you do it with pictures, not words. And it tends to be a bit easier and fun, as many people are inherently visual.

Best Practice #3: Use concise and precise terminology.

As I've mentioned in previous best practices (#1 Less is more and #2 Grouping and chunking), a lot of these design principles apply to any navigational construct -- using concise and intuitive labeling seems like a no-brainer. Given the textually charged interface and the amount of thinking you are asking people to do to navigate your site, mega menus simply force you to follow these rules more strictly.

Hunting and pecking for the right label to click on in a mega menu is no small task, so you really need to avoid the 2 major categories of labeling problems:

1. Excessive length & concatenation: 

When you're trying to cram 20+ links in a hover pane, every character counts. If you've got extraneous words in your labels that make your links harder to scan, or even worse cause wrapping (*gasp*), take out the scalpel and try some creative rewording or restructuring. Labels should be short, sweet and precise, leaving nothing to guessing. Call it what it is as simply as possible, don't try to be fancy - you'll just end up confusing users.

Additionally, avoid concatenating (joining) more than 2 items in one label. Laundry list labels (this, this, this & this) are much harder to scan, as you force the user to read all the way to the end before they can move on. We also recommend you avoid having too many concatenated items in one menu or group. Ampersand-farms can make a menu much harder to scan and it usually means that you have tried to put way too much in one category and need to think about restructuring.

Here's an example of some labelling that breaks these rules:

Subtitle: The Future of Taxonomy... Ad Nauseum

This year's Taxonomy Bootcamp conference was much like years prior: full of great information, knowledgeable speakers, and a ton of self-doubt/-defense/-definition. Which is ironic: professional organizers who struggle to classify themselves. There were at least 3 major sessions dealing with the taxonomist's identity and future (in a 2-day conference with a single track, that's a lot), which left me feeling a bit estranged.

The opening session by Patrick Lambe discussed the identity of the "new taxonomist" in the field, using results from a survey of members of the Taxonomy Community of Practice. His findings were unsurprising to me at least: 

I finally got around to reading the preliminary info on MSDN in regards to how SharePoint 2010 will be treating taxonomy and metadata. As most of you know, MOSS 2007 had some serious challenges in this regard that caused IAs like me much consternation when trying to implement effective content structures (e.g. no hierarchical metadata, no sharing controlled vocabularies across site collections, etc.).

It would appear that SharePoint 2010 includes many new features under the umbrella of Enterprise Metadata Management to solve some of these issues. Here are the highlights...

1. Terms & Keywords

SharePoint 2010 has a few types of vocabularies with different levels of control:

Terms: Basic construct - a word or phrase that can be associated with content. A term can become a managed term or a managed keyword.

Managed Terms = A controlled term that can only be created by those with appropriate permissions. Term sets (can also be considered taxonomy facets) are collections of related terms that can be hierarchically structured.

Managed Keywords = User-generated keywords (aka tags) kept in a non-hierarchical list called the keyword set.

What's nice is that you can easily turn a managed keyword into a managed term, which essentially sets up SharePoint 2010 as a decent platform to blend taxonomy and folksonomy approaches (more on this later).

2. Managed metadata & the Term Store

Once you have managed terms in place, you can create a new column type called "managed metadata". This column type is like the 2007 lookup, but points to the managed term sets instead of lists. 

I'm now back home in Montreal fighting jet lag (yawn) after a great week at the J.Boye 2009 conference in Aarhus, DK. It was a great experience I hope to repeat. Perhaps my favourite event was the last one - the town hall debate, reserved for the die-hard attendees who hadn't run off to the airport. In this session, we were given 6 statements to consider and vote upon, after hearing from two "debaters" who represented the pro and against. In this case, we had the "good doctor" (David Ott, attendee from World Health Organization) and the "panda" (Neil Morgan, attendee from Word Wildlife Federation).

This is a seriously fun session that not only drew lots of laughs (I'll point out the memorable quotes), but also some intense debate. Here's a recap for those who missed out, but also this can serve as a checklist at J.Boye 2010 to see if our predictions came true. (You can also watch the video)

#1. CMS is a commodity.

Pro (Ja): Sure, "CMSs are like water - get it from one company or another, it's all dirty". (Janus Boye) There's not much difference between all the systems and vendors, so it'll eventually be like choosing a brand of shampoo. Lather, rinse, repeat every 3 years.

Against (Nej): CMSs are actually quite different - there are some that are industry-specific, scenario-specific, there are no real standards governing their architecture. You need the appropriate tool for the appropriate task - choose wisely.

Result: AGAINST - CMS is NOT a commodity. It'd be interesting to count how many in the audience were vendors... Let's see how we feel about this one after the web idol contest in 2010.

After braving the high winds, rain and herring here today in Aarhus, Denmark, I had the pleasure of sitting in on the J.Boye keynote session by BJ Fogg of the Stanford University Persuasive Technology Lab.

BJ's topic was how social media uses (and we can leverage) persuasion techniques to influence behaviour. As an intermittently avid and lapsed Facebook and Twitter user, most of this talk felt like a session "on the couch" trying to deconstruct why we do what we do...

Triggers, Motivation & Ability

BJ started his talk with the notion of hot vs cold triggers. Hot triggers give users an immediate and obvious call to action (e.g. a sandwich board inviting you to come inside a store to have a coffee for 1$). Cold triggers are calls to action that can't be immediately acted upon (e.g. an advertisement for a movie or play - you have to call or go to a location to buy tickets).

Social media often uses hot triggers, sending you notifications to see people's feeds, see who has friended you, etc. But as BJ explains, triggers are not enough to create behaviours. You also need motivation.

Motivations for behaviour include:

• Pleasure / Pain
• Hope / Fear
• Social Rejection / Acceptance

So, I might decide to get involved in Facebook because I enjoy seeing what my friends from high school look like 15 years later (which counts for both pleasure and pain in many cases), or because I fear being seen as a old fuddy-duddy who doesn't keep up with the times, or because I want to relive the awful dance of social acceptance and rejection from high-scool.... ugh.

Best Practice #2: Use chunking and grouping to increase scanability and learnability

So you’ve taken the mega-menu plunge and you now have more labels to fit into your drop-down. How do you make sure it doesn’t look like a mess of text?

There are a couple of options:

Grouping:
Create clear and logical groupings within the menu and give them prominent labels that can easily be scanned.

There are four elements to this approach

1. Logic: Groups have to be internally coherent and logical. Either they are all children of a common parent or somehow conceptually related in a way that is evident and quickly learnable.

2. Labeling: Use simple, unambiguous labels that convey the nature of each group. Decide if your labels will be “clickable” – is there a landing page behind them or is it just a visual way-finder? The mega-menus tend to discourage clicking on such intermediate levels, but marketing may want the space to provide category-level merchandising.

3. Volume: Follow general good practice on number of items in a category. We can thank cognitive science for an easy rule of thumb of 7 +/- 2, but I would say that in a mega-menu, space being limited, I would reduce that to 5 +/-2. This will reduce visual noise and fits well with best practice #1 (less is more).

4. Visual distinction: Use striking colors, increase white space between groups, use shading or dotted lines… anything that you can do to make a visual separation between the groups so that they eye can quickly skip from one group to the other without much thinking.

Let's look at some examples.

"How many content types should you have?"

This is the question that came up in a conference call last week on SharePoint architecture. This organization had implemented their corporate portal on SharePoint 2007 and was interested in going forward with more portal sites but had some concerns about the approach to information architecture they had undertaken.

I answered what I would answer no matter what technology it was - "Only as many as you really need to implement the appropriate level of metadata, workflow and templates." Which is of course vague, as most good consultant-ese is. I followed up with some stats: when we work on web content management implementations, we typically end up with about 10-15 content types for a site of medium complexity. We always try to keep the structure simple and number of content types few for many good reasons, ranging from ease of content structure management to content publisher user experience.

The folks on the phone were quiet for a minute... You see, the previous consultant they had worked with had a bit of a different (read opposite) approach. The philosophy they described was that SharePoint content types should be created to the maximum degree of granularity (e.g. one content type per library) so as to reduce the need for content publishers to select a content type and tag metadata values. For example, if you had a site for human resources forms, you would have one library and content type for medical forms, one library and content type for dental forms, etc. Each content type would be extremely specific and require little tagging. "If you need 30,000 content types, then so be it" is the idea. (insert eye twitch.)

No matter where I run, I cannot seem to hide from them.

They fly out of website navigation menus with no warning. They assault my senses with link overload.

...they are...mega menus.

Are they a new navigation paradigm or just a bad fad - like acid washed jeans?

And whose idea were they anyways?

It's difficult to trace the starting point of the mega menu (or mega fly-out, or maxi menu, or whatever you call them); they started popping up on e-commerce sites a couple of years ago. The first one I bumped into one, my brow got that wrinkle it gets when I am at once curious and horrified - horrious? curified? I remember thinking, really? This is what we are doing now instead of putting effort into making our drop-downs more usable? Let's just add more drop-down...

Once the initial feeling of horriosity passed, I just forgot about it (aka denial). None of our clients were using them, so I didn't really have to pay attention. And THEN, this March Jakob Nielsen put out an Alertbox saying "Mega Menus Work Well." That was really the clincher. If Jakob/NNG says it's ok, well there goes the neighbourhood.

Since then, we've had a couple of clients go down this road. And I've kind of gotten used to mega menus... in the way that one gets used to white noise or a bad hair cut. To the point where I think that it's time that we acknowledged that a lot of websites are using them - for better or for worse - and that they are here to stay until the next navigation fad comes up. So it's probably a good time to set some basic best practices, to "limit the disasters" (limiter les dégas, as we say in French).