louisrosenfeld.com logotype

Home > Bloug Archive

Dec 18, 2001: What Exactly Are IA Components?

I guess that if I'm going to prattle on about how to select information architecture components, as I did in my last posting, then I should probably spend a little time describing what exactly they are.

An IA component is any part of an information system (e.g., a web site) that gets users to content. Navigation bars, site maps, link labels, query languages, all are components of an information architecture.

In the "polar bear" book, Peter Morville and I broke them into four broad categories:

  • Organization Systems: How we categorize information (e.g., by subject, chronology).
  • Labeling Systems: What we call information (e.g., scientific terminology ("Acer") or lay terminology ("maple")).
  • Navigation Systems: How we browse through information (e.g., clicking through a hierarchy).
  • Search Systems: How we search information (e.g., executing a search query against an index).

Like any categorization scheme, this one has its problems. Many have a hard time distinguishing "organization" from "labeling" (hint: you organize content into groups, and then you label those groups; groups can have multiple labels). By "navigation," we've always means something a little more specific, namely "browsing," as opposed to "searching," which is really just another form of navigation or finding.

Oh well, back in those days we were young and silly. Now slightly more wizened, I've come up with yet another imperfect way to categorize IA components (the lists below are by no means complete):

Browsing Aids ("Canned" Finding): These components present users with a predetermined set of navigational paths to help them find their way through a site. Users don’t have to articulate their queries, but they do have to find their way through menus and links. Examples:

  • Site-Wide Navigation
  • Local Navigation
  • Site Maps/Tables of Contents
  • Site Indices
  • Site Guides
  • Site Wizards
  • Contextual Links
  • Exact Hierarchies (alphabetical. geographical, chronological, name)
  • Ambiguous Hierarchies (subject, task, audience)
  • Faceted Classification

Search Components (Automated Finding): These components allow the entry of a user-defined query (e.g., a search) and automatically present users with a customized set of results that match their query. Examples:

  • Search Interface
  • Query Language
  • Search Zones
  • Search Results (including ranking, sorting, and clustering)
  • Retrieval Algorithms (e.g., pattern matching, popularity, citation linking)
  • Personalization Tools
  • Customization Tools
  • Automated Classification Software
  • Automated Indexing Software

Content and Tasks: These are the user’s ultimate destination, rather than separate components that get users to their destination. However, it's difficult to separate content and tasks from an information architecture, as there are components embedded in content and tasks that help us find our way:

  • Headings
  • Embedded Links
  • Embedded Metadata
  • Menus/Lists
  • Chunks
  • Sequential Aids (for tasks)
  • Identifiers (e.g., logo, splash page)

“Invisible” Components: Certain key architectural components run completely in the background; users rarely (if ever) interact with them. These components often “supply” others components, such as a controlled vocabulary which populates embedded metadata fields:

  • Authority Tables (e.g. authors)
  • Lookup Lists (e.g., state abbreviations)
  • Controlled Vocabulary
  • Thesaurus
  • Rule Base/Expert System

So, another perspective on what IA components are and how to group them. Any other approaches out there that you've found useful? Let me know.

email this entry

Comment: ben (Dec 18, 2001)

But, what is the point of all this classification?
I thought the broader categories served _some_ purpose in terms of distinguishing (but on the whole the difference is fairly obvious isn't it?).
As you start to narrow them down and to introduce specific examples isn't there a danger of blurring the distinction?
For example, when is personalisation a search component as opposed to a navigation tool?

BTW - It is also unfortunate to be talking about IA and to present the user with 404 links :( I guess this is a teething problem with the MT system.

Comment: Michele (Dec 18, 2001)

Ben asks a good question about the point of trying to classify IA components. Why bother taking the time to do this, especially when there is some blurring between the lines.

My background is in information and library science, so I have a definite bias towards the value of classification in organizing information resources. Classification allows us to group like things together, as a way of understanding differences and similarities. E.g., site indices and site maps are navigational tools; what traits do they share and how do they serve different needs?

Classification is also important as it gives us a language and a structure for using, discussing and developing these components. If you are looking for a way to improve a site's search, for instance, it's helpful to have a comprehensive menu of things to consider: personalization, customization, search interface issues, etc.

Yes, there is some blurring between the lines (e.g., headings can also be construed as a labeling system), but this doesn't negate its value. This blurring can be likened to cross-referencing in a library catalog system. The fact that a particular item may have relevance in multiple places doesn't negate its value in those places. Obviously the cross-references must be relevant and limited for the classification system to have value.

Structure for the sake of structure doesn't help anyone, but structure for the sake of development, discussion, and description is a worthwhile endeavor.

Sorry for the rant - I guess my LIS roots are showing. ;)

Comment: Lou (Dec 18, 2001)

Good points, Ben, but I think Michele hit the nail on the head with her comment; I can't put it any better than that.

I think that sometimes we confuse categorization with "true" taxonomies (where everything has its place and only one place). That definitely wouldn't work here, and it'd be silly to try to create a taxonomy of this stuff.

Thanks for pointing out the broken link (now fixed); only partly my fault. I pasted from MS Word, with its "smart quotes". That smartness is what hosed the link.

Comment: Andrew (Dec 18, 2001)

As per usual, it seems that IAs conversation veers quickly away from "A Topic" into "Thinking About Classification Schemes for The Topic."

"Ben asks a good question about the point of trying to classify IA components. Why bother taking the time to do this, especially when there is some blurring between the lines."

Yep. Uh-huh. That's a pickle. Know what, who cares if the lines are blurred? At some point, we ought to start thinking of the IA community as a slightly irked client, who just wants the darn web site to work.

What's that, we need more time to tweak the classification scheme? A little more work on the architecture diagrams, just to get them perfect. Er, no. Just upload the thing, we'll pretty it up later.

I think Lou's two posts so far on Components and Attributes are great. I can work with these. So what some of the components sound kinda like each other? Don't care, don't care, the client wants to go live now.

Here's the kind of thing that would push this stuff into the realm of the really really useful: This attribute "Granularity, Specificity, and Volume" is important, I need to worry about that for the next site I work on. So tell us some components that you've seen or made that really work at different levels of granularity. Tell us what components you built that supported some attribute really well, or poorly. Tell us where we can steal ideas for well-implemented components. Tell us about the time you had to solve a problem really fast, and how Search Zones did it cheap.

Comment: Jess (Dec 18, 2001)

In the comments for Lou's previous post Victor gets to the real root of the problem - the need for a language of user experience.

When you have a _language_ then you can model things in your head before you commit them to the whiteboard. A UX Language provides a new way of thinking - something some firms have already developed to some extent (like Cooper).

I rambled about this more in a presentation last January - see slides+notes 22-27 in particular.

And in a natural language, some ambiguity is normal. Looking forward to what we develop as a common language in the IA community...

Comment: Jess (Dec 18, 2001)

Sorry, here's the links that should've been in my last post - you'll have to cut and paste:




Comment: peterme (Dec 18, 2001)

I'm wondering two things.

1) In joining others, I'm wondering what is the *use* of identifying these components. Ought I make a checklist? Make sure I've got my "Site Index"? I mean, it's nice to identify these and all, but to what *end*?

2) I think, in the previous post, you glossed over the more important and interesting point/problem--"First choose the most useful tools and techniques (e.g., card sorting, contextual inquiry) to learn about users' information needs, the characteristics of content, and organizational context and constraints."

I think it's a common trap among designers to want to talk about the elements of the solution without really having attempted to understand the problem.

Comment: Lou (Dec 18, 2001)

Peter, regarding #1: I don't understand your question. I guess I'm just not clear why there needs to be an end to these means. Sometimes it's just interesting to consider looking at something in ways you hadn't before. Sometimes what doesn't have clear value today clicks for you six months down the road. Sometimes it's useful to throw things up against the wall and see if they stick.

Make a checklist if you're so inclined, but I know for a fact that you're not necessarily a checklist sorta guy. ;-) So I'm a little perplexed.

Regarding #2, I agree: that's half of the challenge. I don't see anyone doing this, though I'd love to be corrected. In fact, it's not really fair to say I "glossed over" it, as I said it's essentially half of what IA is about. I just don't know if I want to take a stab at such a topic in the context of this blog...

Comment: Peter Boersma (Dec 19, 2001)

Peterme wrote:
"I think it's a common trap among designers to want to talk about the elements of the solution without really having attempted to understand the problem."

So we need people who can help the problem-owner formulate the problem in ways the designer understands. How do we call these people? Analysts, researchers, consultants, sales (brrr..)?

Jess, does your proposed UX language help problem-owners (clients) do this?

Comment: christina (Dec 19, 2001)

Remember, Lou is writing a book. The real use of this exercise -- I think -- is both to clarify one's thinking and to teach concepts. The client may never see these things, the IA may not consciously consider them, but we are often forced to formalize and articulate our thinking when writing.

Another advantage is that it gives us a common language for discourse.

Finally this is a blog-- Lou gets to ponder whatever he wants here... let he without thoughtwander tendencies cast the first stone...

Comment: victor (Dec 20, 2001)

Peter B. said, '...we need people who can help the problem-owner formulate the problem in ways the designer understands.'

Lots of different people can play this role. I try to describe the problem using *Requirements*, which are fairly common in the software development world. I'm very high on them lately because they help focus on the problem, whether it's at a high level ('The system must authenticate visitors using a name and password scheme') or a lower level ('The navigation must always visually indicate the page currently being viewed').

To bring this back to Lou's idea, you could select components by comparing your requirements against the component attribute values (assuming the monster table he has in mind is all filled out).

This doesn't replace a well-trained IA, it just helps narrow the possible design decisions. As a teacher, I'd love to walk students through such a process so they learn a highly structured way of thinking through design decisions, and once they're comfortable with that they can go break the rules.

Comment: Jess (Dec 22, 2001)

Peter Bo
>Jess, does your proposed UX language help problem-owners (clients) do this?

No, there's still the need to translate:

Client_Business_Problem > UX_Vocabulary

The UX language is something used by people talking about user experience with others who know the language i.e. understand the field (since the field is defined in large part by its language). This is too much to expect clients to learn the "superjargon" of a more complete UX vocabulary - hence the need for us to speak the language of business better.

Comment: a (Jul 4, 2002)


Add a Comment:



URL (optional, but must include http://)

Required: Name, email, and comment.
Want to mention a linked URL? Include http:// before the address.
Want to include bold or italics? Sorry; just use *asterisks* instead.

DAYENU ); } else { // so comments are closed on this entry... print(<<< I_SAID_DAYENU
Comments are now closed for this entry.

Comment spam has forced me to close comment functionality for older entries. However, if you have something vital to add concerning this entry (or its associated comments), please email your sage insights to me (lou [at] louisrosenfeld dot com). I'll make sure your comments are added to the conversation. Sorry for the inconvenience.