Information Architecture Bottom Up (stc14)

This week I’m attending STC Summit 2014, the annual conference of the Society for Technical Communication. Where feasible, I’ll take notes from the sessions I attend, and share them on this blog. All credit goes to the presenters, and any mistakes are mine.

Mark Baker, author of the book Every Page is Page One, presented a session on Information Architecture Bottom Up. The outline of his talk ends with this summary:

This session will look a practical examples of top-down and bottom-up information architecture and will illustrate where top-down fails, and how to create a bottom-up architecture to replace or to supplement your top-down approach.

Bottom up

Traditionally, information architecture organises knowledge from the top down. As examples, Mark showed us the Map of the System of all Human Knowledge from the Encyclopedia of Diderot & d’Alembert, the Linnaean classification system, and the Dewey Decimal system.

One of the simplest forms is the table of contents. You start with a general concept, and then drill down to the details. Such classifications tend to end with a category of “miscellaneous” items.

Sometimes tables of contents even act as a classification scheme, such as a clickable classification of organisms.

Another form is a system which lets you find out what medical problem you have, by progressively narrowing down your symptoms.

Mark showed us other examples of hierarchical organisation of data. Then he showed how hierarchies don’t necessarily meet a user’s needs. For example, if you’re looking for a convertible car, and the information on a car sales site is organised by year/transmission/price… and eventually by body type, you’ll need to move up and down the hierarchy a lot before you find what you want.

We will never find the hierarchy that will suit all users’ needs, because people have different needs.

Faceted classification

Such systems let you choose the things that are important to you. For example, a car sales site may have a set of various selection criteria in a side panel, such as price, transmission, mileage, year. You can choose to fill in some selection criteria and not others, and so find what you need.

There’s a big technological difference here. Paper can’t provide faceted classification, but computers can.

This is still top down. It’s a collection of taxonomies that define the things people are interested in, with respect to buying cars. It works, because most people buying cars know this particular taxonomy. But it won’t help people who don’t know the taxonomy. There are still classification problems.

Experts classify, the rest of us name things

A nice quotation from Mark:

“Experts classify. Everyone else names.”

Looking at flowers, and pansies in particular, the scientific classification of a pansy isn’t particularly useful to most of us. Looking at a Google search for common names of pansies:

  • Searching for “stepmother flower”, you find plenty of information and images for pansies. That’s good. In such cases, a search engine like Google works.
  • Searching for “football flower” shows images of pansies, and also of footballs made of flowers. Some good, some potentially confusing.
  • Searching for “Three faces under a hood” is particularly interesting says Mark. Looking at the images, you see a pansy (good), a girl in a hood, two people under the hood of a car, and a composite photograph showing the three faces of Mt Hood.

Scalability

None of the classification systems scale well. Tables of contents can get immensely long. Mark showed some examples from a book and an online help system.

There’s often too much variety, which leads to complexity and unevenness

Mark quoted David Weinberger: “Everything is miscellaneous”.

Everything flows to the Web

We shouldn’t attempt to push content into channels. Reuse is a big subject, often for the sake of being able to deliver the same content to multiple channels.

Problem, says Mark! There are no channels any more. All content flows to the web.

If people search for something on the Web, they will find the most popular hit – which will probably be your most popular product, even if published a few years ago.

Moving towards bottom up

What happens when someone does a search and ends up on a page in your content? They don’t start at the top. They start on the page that Google sends them to.

Mark isn’t saying we should throw away all the top down architecture. But we do need to start adding bottom up information architecture to our content.

Subject affinity

Looking at Wikipedia: it’s highly organised. There are various links and ways to move around. But it’s not ordered. Organised, yes. Ordered, no. The links point to related information, which provides a type of semantic clustering.

Dynamic semantic clustering

Mark showed us examples of information clusters that are dynamically organised:

  • Twitter hash tags
  • RSS feeds
  • Forums. Sometimes these are organised by number of votes.

Linking interesting connections without making a bowl of spaghetti

Most of the problems that people find are the irregular associations, and multiple connections. If things are regularly organised, people don’t usually have problems. So we need to help people with the irregular associations.

In a bottom up architecture, it’s easy to link to the interesting associations. If you tried to map all these associations from the top down, you’d soon have an incomprehensible bowl of spaghetti. In a bottom up architecture, the links show connections that are relevant in this context.

“A topic in a bottom up architecture is a hub of its local subject space.”

How do you make sure people don’t get lost?

This was a question from the audience. Marks’ answer was that you have to design the content for a bottom up architecture. You can’t just take the content from a top down hierarchy and put it into a bottom up system.

You must build context into the subject matter. Context in the table of contents doesn’t matter, but context within the subject matter does. Every page is page one, so every page must start by establishing the context. “Where am I.”

How can you filter the links based on the reader’s context?

In a tech comm point of view, you must have a systematic design for linking. A taxonomy is vital here. So, a taxonomy is not used for generating a table of contents, but instead for organising your links.

What about procedures and workflows?

What if a sequence must be performed in order? Mark’s answer is that a procedure should be the subject of a single topic. In top down design, a table of contents should not express a workflow, although it often does. So, workflow is one of the most important use cases for a bottom up architecture.

A person from the audience mentioned that you can illustrate workflow via a progress bar or images illustrating steps, which can link to steps in a complex workflow.

Topic types

Due to lively discussion with the audience throughout the presentation we ran out of time a bit, so Mark ran quickly through the types of topics in a bottom up architecture:

  • Workflow topics. We mentioned these above.
  • Pathfinder topics. These are about how you get from a business topic to an action in the system.
  • Big picture topics.
  • Tasks.

Walled garden or bazaar

Mark finished by comparing the top down approach (a walled garden) to the bottom up approach (a bazaar). The main difference: in the pictures Mark showed us, the bazaar had people in it. 🙂

Thanks Mark

It was a pleasure and a privilege to hear you speak.

About Sarah Maddox

Technical writer, author and blogger in Sydney

Posted on 21 May 2014, in STC, technical writing and tagged , , , , , , . Bookmark the permalink. 6 Comments.

  1. Sarah, I wanted to attend Mark’s session but ran out of steam. Thank you for this detailed, beautifully written summary—published right afterward, too. How did you do it?

    • Hallo Marcia!
      I’m so glad it’s useful. I wrote the post during the session, and then just hit the “publish” button. Writing and organising the information helps me to focus on what the presenter is saying, and helps me to remember it better afterwards. The actual blog post is a bonus. 😉
      Cheers
      Sarah

  2. Can you clarify, “these are about how you get from a business topic to an action in the system.”

    • Hallo Ellis
      Good point. From memory, what Mark said is that the “pathfinder” topics are not so much about the system you’re documenting, but more about linking from business processes to the system. They might contain things like: what are the reasons I’d want to do something; what are the consequences; if I need to kick off this business process, what part of the system do I use.
      Cheers
      Sarah

      • Right, users are basically trying to solve business problems. They understand the business problem, but they don’t always understand how the tools can help them solve those business problems, or what the consequences for the business might be of using the tools in a certain way. Pathfinder topics are about helping the user find a path from the business problem they have to the technical solution they need, or helping them decide among different possible solutions. A pathfinder topic would then point off to more specific workflow or task topics for implementation details.

      • Thanks. I’ve seen them as setting the context, why you might use a particular feature. So I think I’m safe in seeing them in that way.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.