Tag: IA

If you’re in higher ed web development, you probably saw this article making the rounds criticizing university web sites. Melonie Fullick put this together along with the feedback of other Twitter users after trying to research some information from various sites. I, too, recently had some complaints doing some research on programs at institutions and finding it infuriating at times trying to get relatively simple information. I’ve talked with a couple folks about the article as well, and thought I’d give some additional commentary. Not necessarily counterpoint, or refutations, just an additional viewpoint as someone who spent years behind that curtain. Read More

I apologize in advance, because this is going to be more of an article of philosophy, than a technical how-to. A while back I wrote a piece on the subject of breadcrumbs. In it, I made a comment about how breadcrumbs are a tool that helps expose the information architecture (IA) of a site to a visitor. A discussion ensued where a rebuttal was offered that visitors simply don’t care about a site’s IA. David Poteet said about IA (or rather a breadcrumb’s effect on IA) that certain ideas “…make the assumption that users understand or want to understand the structure of our sites.” I ceded that point based on the fact that I believe he was, in part, correct. Today, however, I wish to expand the topic some, and explain that while I believe they don’t care, they also certainly DO care. Your information architecture plan is very important, and you should understand why things get placed where they are.

Information architecture is not science, it is art. Like conducting a symphony. It’s one part knowledge, two parts skill, and three parts just saying stuff like you know what you’re talking about and hoping others will go along with you (How often have you had to defend why page X was in folder Y instead of subdomain Z? And with all the XYZs, imagine you did the site for Sesame Street! I think my head just exploded…). But at the same time, if users don’t care about it, why bother with it at all? I’ll tell you why. Let’s take, for example, two sites: my blog and your university site. Both have very different IAs (In theory. If they don’t, one of us is in serious trouble, and my “I’m with stupid” t-shirt is at the ready.). My blog’s IA has very little active thought behind it, and is almost totally informed simply by the functionality of the CMS that I use for it (WordPress). That’s not to say I didn’t put actual thought into a couple areas, I did, it just wasn’t much as far as these things go. A university site, on the other hand, is vast, and generally requires constant thinking and rethinking and questioning of why and where things go. You need a blueprint to inform that construction process. Even the best CMS can’t just spit out a functional IA based on how you put information in to it for a site of that scale.

In a way, this compares to two businesses – let’s say Bob’s Lumber and Home Depot. Bob’s Lumber is your local, downtown lumber yard. They’ve been there for 50 years (But unfortunately due to the economy, probably won’t be there for 50 more. That has nothing to do with the example, just trying to build a whole picture). Then there’s Home Depot. They carry ten times as much stuff, and have eight times the square footage of floor space. In terms of these two stores’ “information architecture,” no one would argue that Bob’s needs to have maps posted around his store. No, you might look overhead for a sign (landmark) once in a while, but you would assume it’s small and structured enough that even if you’d never been there, within a minute or two of walking in the door, you probably would feel like you could track down what you wanted (this would be like my blog). Home Depot, on the other hand, has a map as soon as you walk in the door. Then they have more posted throughout the store. There are big signs over every aisle, and each aisle has additional itemization of what’s there. They still have stuff organized in a familiar and (semi)logical format, so why the difference?

The difference is wayfinding. Peter Morville talks about this at some length in his book Ambient Findability (which, for the record, is a great book and I’ll be reviewing it here shortly). The way we navigate space and the web, and the way we assign symbolic references to the web that mimics space is intriguing. Also, Jared Spool from User Interface Experts has a nice mini e-book on this subject that David mentioned call Designing for the Scent of Information. The reason I bring it up is that the idea of the way we apply “scent” to words, layout, and structure is absolutely part of the “instinct” of wayfinding we use. David talked about scent in the breadcrumb article’s comments, explaining that to be useful, breadcrumbs need to be properly scented. That notion applies to many things though. Header/footer links, primary navigation, even the header tags and descriptive text. Like a bloodhound, our brain digs into that page to smell out where it is the instant we land there, because assuming you need to continue on from there to accomplish your goal, or because your interest has been piqued about something else, you’re going to have to know where to go from there. This isn’t something you do consciously, it’s just the reaction of our wayfinding instinct kicking in. If you haven’t put a structured IA in place, that instinct will get lost, and the ability to use a site will go down.

Another example: imagine you are driving down the highway. You have no map. But at least you know you’re on a main highway (it’s four lane and has a 70mph speed limit) and that you’re headed where you want to go (sign just said “Kansas City 45mi.”). But oh crap, you’re out of gas! So, you pull off at the next exit to stop at a gas station to fill up, after which you get back on the highway, and continue your trip (eventually arriving safe and sound in Kansas City, even though a stupid bird flew right into your grill and cracked a headlight. Stupid birds.). But you never looked at a map, so how did you do it? Scent and wayfinding. And more specifically the “information architecture” of the road system. You didn’t get out a map to figure out where a gas station was, and you didn’t need one to get back on to the highway. You didn’t even need it to know you were on the highway to begin with. And the best part, you don’t care. You don’t want to know all the intricacies that go into road planning and exit ramp design, at least not consciously. Unconsciously, however, is another story. The whole time you travel you’re noting signs, landmarks, inferring direction, relationships, etc. Assuming it’s all well designed. Try dropping a new person on the highways in and around Atlanta, GA and watch their confusion. This is because their road system grew at such a frantic pace, it didn’t have time to be well thought out necessarily.

Back to one of my first points, I agree with David that users don’t care about how our sites are ultimately organized. They don’t care how we set up folder architectures, page heirarchy, or content cataloging. They don’t care if we have breadcrumbs, footer navigation, or tag clouds. What they do care about, is that we’ve made some effort to expose enough markers to them that their instincts can orient them. The bigger and broader a site is, the more important this is. They come with a goal, and that’s that. But that’s all conscious thought. Unconsciously, it all matters a great deal. We are constantly positioning ourselves in the web. We like to think of it in spacial terms, because it allows us to reference locations easier and describe how we got places. On a small site (Bob’s Lumber Yard), this is all less important, because there’s less to infer, and thus we build an accurate assessment faster. But on a large site (Home Depot), you want as many maps, symbols, artifacts, and signposts as you can muster. A breadcrumb trail, for instance, may never get used. But, that doesn’t mean it isn’t a component of the visual cues we pick up and make mental notes of when we land on a page. We don’t usually land on a page going “Where on this site am I?” as our first thought. But our brain certainly does, because if you come with a goal, you can’t accomplish that goal without inferring aspects of the information architecture.

My point is, always keep in mind how your site grows. Universities and colleges have been terrible in the past about letting things just happen willy-nilly. That’s no longer effective. We should have plans, and goals, and intent with respect to what happens where on our site. The next time someone asks “Can I put this on the site?” be sure to consider if it’s best under their department, or maybe as a special area in their college site. While it’s not about being right or wrong, it’s all about wayfinding.

Several days ago (or more, seeing how long it actually took me to get this finished, whoopsie), Twitter user @stomer brought up a question to the Twitterverse regarding a common tool we use any time we work in social media these days: “This a fair description?: categories are like table of contents items, tags are more granular like items that would be in index?” I happened to be on right when this hit the feed, and replied: “Categories are for organizing, tags are for identifying.” It was a simple exchange which prompted a third comment from @jdwcornell asking for some expansion on this idea, to which I am happy to oblige.

Categories and tags are two functional elements that many of us who use things like blogs, Flickr, YouTube, or many content management systems are familiar with using on a day to day basis. It’s easy for us to see how they work and what they are for because we have such a high level of exposure to them. But that’s us. I know that I’ve found myself on more than one occasion explaining the tag cloud on our university’s home page. These systems are very smart, and apply these things in cool ways, but users can tend to be, well, not so savvy. To some people, functionally, they seem very similar, which is exactly why I came up with my simple description that categories are an organizational tool while tags are for item identification. Generally this helps people get over the hump of understanding them. YouTube does a pretty good job of exemplifying this, where they have just over a dozen categories (like “Pets & Animals”) that you choose from, and then a blank field where you could freely tag a video (like “dog, boxer, barking, trick”). The first tells you where it goes, the second tells you what’s in it. Flickr lets you tag photos as well, and you categorize them through the use of sets. In that case, you get to name the sets (as opposed to YouTube where they are predefined by them), but they are basically serving as a category the same as anywhere else.In our case, we use both categories and tags in the university CMS (we use dotCMS). When a user creates content for the university in the content management system, we ask them to do both of these things. The first question that usually follows is: “What?” This is quickly followed by the second question: “Huh?” In all fairness, I can’t blame them on this. Both of these fields can be used on the front end of the web site (or not, depending on what it is), but we also use them in the CMS to enhance internal searching for content. Under this setup, categories form the basic structure of the college: office names, departments, organizations. Tags then allow specificity in identification. The result of this is searching for content categorized as the “Admission Office,” and then tagged with “checklist,” or “forms.” Or if you needed more generic information, you could search for content tagged as “contact information” and pull it from all the areas, or categories. This exposes the idea that the tags are simply identifying what is in the content. We use a similar mechanism for the calendar, categorizing by area, and tagging by topics. Then, any department or office can get a customized event feed of their category, or more general areas can pull from them all by tags. Seeing this type of stuff in action usually really helps people understand the difference when they didn’t before.

To make further comparisons, categories are kind of like folders. They are designed to help users located related content based on the implied relationship of the category name, usually based on a theme or topic. Generally, categories are predefined by some kind of administrator ahead of time, and aren’t added willy-nilly. For instance, there’s the “Admission Office” category in our CMS. It’s there in a list for the contributor to select from when they make content, and so they couldn’t make a new category called “Admissions Office” or “Undergrad Admission Office.” They are bound to what we have set up. This makes them useful for building things off of because they are predictable and structured.

Tags are almost never preset like that. Instead of folders, these would be like contextual post-it notes you stick on papers in the folder. You might agree on a policy to use some kind of convention (like always pluralize words, never capitalize, don’t include spaces, etc…), but generally there are no restrictions on their use, and authors can create and assign them during authorship of content without any extra help. In many ways, tags are a type of visible meta information, and you will hopefully break out a thesaurus if using them well. Not to confuse the matter, but it is possible to also create tags that can serve the purpose of categories, a kind of “super tag,” if you will (but it would rely on use of a convention to function properly). That kind of functionality will normally depend on your infrastructure, but the idea is that a tag, in a way, is basically a type or subset of categories. But they tend to be much more fluid and less predictable than categories. I could pull information based on the tag “student,” for example, but at the risk of missing stuff tagged “students,” or if you have the ability you could use the tag “student” to match things like “student employment,” “student events,” “student groups,” etc… In this way they are less useful functionally, but far more useful in identifying, connecting, and relating items. And looking at the big picture, properly implemented tags get picked up by sites like Technorati to help identify and group similar information from thousands of web sites on a macro level (for more information on this, take a look at the rel=”tag” microformat).

So there you go – categories organize, tags identify. Ultimately, their basic function and usage might change depending on what you’re using them in (a blog, Flickr, a CMS, etc…), but that basic principle will generally always stay the same no matter where you are. When users question their function, try to give them a simple example to go off of. If they don’t get it in our CMS at first, I tend to find refering to Flickr and YouTube to be nice examples that everyone seems to get. For more information on the discussion, I recommend the Categories vs. Tags articles at Haacked, or Usability Post.