A Practical Guide to Information Architecture

Download MP3
Length: 40 min.

Donna Spencer is the author of A Practical Guide to Information Architecture as well as two other books (on card sorting and writing for the web). She’s an experienced information architect, based in Australia, who gives regular workshops on information architecture at conferences such as the IA Summit and also runs the UX Australia conference. In this podcast we talk about information architecture, especially in the context of technical communication. Some of the topics we cover include the following:

• What information architecture is, especially in contrast to content strategy and user experience
• Why writers are well suited for information architecture
• Reasons for doing user research prior to building your information architecture
• Determining user terminology (and dangers of choosing the wrong terms, even if people use them)
• Evaluating browse versus search, and the problem of looking for information without knowing the right terms
• Strategies for dealing with overlapping categories and difficult-to-fit topics
• Why organizing content by audience can be tricky
• Using focused entry points to serve different audiences
• Finding what you need when you don’t know what you need
• Organizing content by popularity, and other alternative classification schemes
• Scenario driven testing with index cards
• Card sorting strategies, tools, and limits
• Reasons for brainstorming IA off-screen, without your computer.
• Determining the number of top-level navigation options
• Providing navigation through next and related links
• Beginning the information architecture at the content page rather than the home page
• The kind of content to add to your home page

I highly recommend this book as well as learning more about information architecture in general. For more information about Donna Spencer, see her site, Maad Mob. For more information on her book, see A Practical Guide to Information Architecture. You can follow Donna on Twitter @maadonna.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

BlogEngine? That little startup blog platform that runs on .NET and Windows? Yes, I will explain in a moment. But first a quick recap on where we are in the Organizing Content series.

We left off at 15, and there are nearly 20 comments on that post alone. In that post, I asked what the scope of help content should be. Should you document everything, adding topic after topic based on every question users ask, on every incident logged at the support desk, and so on? Following such a model will result in more challenges with content organization than merely documenting the basics.

In previous posts, I also highlighted the shortcomings of help authoring tools (HATs). Not only is their search feature usually primitive and hard to customize, content produced by HATs is less visible on the web. I noted that wikis are one platform that seems particularly suited to help authoring in a web environment. And then I explored ways to organize content on Mediawiki.

But what if you’re in a corporate environment that restricts you from using PHP and MySQL based tools, such as Mediawiki? What if your IT department is a Microsoft shop that requires you to use ASP and .NET solutions that can run on a Windows server? Yes, I’m taking about my situation (at least for some internal projects).

After writing those posts, I wanted to explore ways to deliver help through a web format compatible with Windows server. All of my first choices — Mediawiki, Drupal, WordPress, Joomla — rely on PHP and usually MySQL. This means they are “off the menu,” as our enterprise architects put it.

As I was lamenting the lack of WordPress one week to our application systems engineers, one of them asked if I had ever used BlogEngine, which is similar to WordPress but runs on .NET rather than PHP. At first I resisted using any other blog platform besides WordPress, because WordPress literally has 10,000 plugins and themes, which make it one of the most robust blogging platforms available.

But the more I thought about it, the more open minded I became. The engineer (who was, I should add, a .NET developer) noted that some even say BlogEngine is better than WordPress.

I decided to investigate BlogEngine more. It is a full-featured blog platform with similar functionality as WordPress (but probably not as flexible). As far as they relate to content organization, the blog features that help you organize and navigate your content are as follows:

• Categories
• Tags
• Related Posts
• Menu navigation

With the menu navigation, if you integrate jQuery, you can achieve the same effects as an expandable/collapsible table of contents in a help authoring tool. For a few jQuery TOC like navigation features, see the first few examples at 50 Amazing jQuery Examples from Noupe.com.

Apart from the TOC, the main way to organize content on blogs is through categories and tags. Instead of putting content into folders, you arrange it into categories. When the user clicks the category, the latest posts within that category appear, and the user can navigate to older posts through links at the bottom.

Tags are more granular than categories. Tags function more like index keywords that you use to describe the content. Whereas a post usually belongs to just one category, you might use a dozen tags within that post.

The best example of a software application that uses blogging software (in this case, Movable Type) as a help platform is Jing Project.

Jing's help is on Movable Type (a blog platform)

When you click a category in the help, such as Get Started (scroll to the footer to see this), all other topics within that category (or at least the last 10) appear in reverse chronological order.

Tags function the same way. When you click a tag, all other topics with that same tag appear in reverse chronological order. (Jing Project’s help doesn’t use tags, but they easily could.)

Organizing content via categories and tags gives you a lot of freedom and flexibility, because you can group content quickly and easily. The problem is that categories and tags lose the hierarchy that is necessary to logically arrange the content within the category. The posts within the category or tag are ordered in a flat way (chronologically or alphabetically). This flat organizational model doesn’t let the user know which topics are most important.

You could manually change the publish dates to better control the sort order, but the effect is still a flat list of posts, with no parent-child relationships or folder groupings. Because of this flat list of topics, categories would need to be limited in scope, with no more than 20 topics per category and preferably only 10.

A lot has been written about categories versus tags, particularly for the WordPress blog platform. In the next post, I’ll look at these two organization systems (categories and tags) in more depth.

(By the way, how are you liking these footnotes?)

Update: Due to the negative feedback about the footnotes in this post, I decided to take them out and use more conventional hyperlinks instead.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

An Electricity Fast

First, a brief bit of news. All the lights in my house are off because Jane wants to do an electricity fast. It’s a Thoreauvian experiment to see what you gain when you give something up. For the past couple of days I’ve been moving about with a candle, or staring at a computer screen in total darkness. I can’t cut off all electricity because that would be a little too extreme — food in the refrigerator would go bad, my side job with WordPress consulting would tank, my blog would slow to a halt. We made agreements about certain allowances. But by merely turning off the lights, it’s amazing how this puts you into a rhythm (or would if I were to turn the computer off).

Time to Take the HAT Off

Back to the topic at hand. In my last post, as I diligently looked into SEO and the importance of help’s visibility in Google, I found that help authoring tools have poor SEO. This is partly due to frames, partly due to the fact that few users will link to help content, and also because HAT code isn’t architected in an optimal way for the web.

If we plan to keep step with the web, we have to use a web platform. As a general trend, I think help authoring tools are going to fade because (a) they do a terrible job at SEO, (b) help authoring tools are poor at collaborative authoring, (c) help authoring tools fail at social media and interactivity, (d) help authoring tools don’t leverage the plugins and extensions of web platforms such as WordPress, Drupal, and Mediawiki, and (e) help authoring tools are expensive compared to web tools.

Additionally, the importance of single sourcing the long print manual is becoming less of a demand (have you handed someone a 100+page manual lately that someone accepted with eagerness? ) I predict that in several years time, we’ll see a major shift towards web-based tools in tech comm, especially wikis.

As a final nail in the coffin, check out this video on social media. It argues that social media presents the biggest shift since the Industrial Revolution.

After watching this video, it seems unlikely that the traditional HAT will be the default tool for software user instruction in a few years.

On to Wikis

Until now, I’ve explored ways to organize content with the assumption that we’re using a help authoring tool. Now I would like to shift to the same discussion but with a web-based platform in mind: the wiki.

Wikis pose serious challenges when it comes to content organization, because all you have are essentially links. In describing different information architecture patterns, Donna Spencer calls wikis a flat model. With wikis, you often don’t have a table of contents feature to organize your topics. You have a page that links to another page that links to another page ad nauseum.

Which Wiki?

Given that there are more than 100 different wiki platforms, it will be difficult to generalize about wikis, because surely some wiki out there (for example, Confluence) probably has a fine TOC feature that collapses and expands. Other wikis may not have flat structures (for example, SharePoint’s wiki system, which provides you with metadata and views). But I will take as my example the quintessential wiki plaform: Mediawiki. (Wikipedia uses Mediawiki as its wiki engine, in case you didn’t know.)

A Maze of Chaos

A few years ago, at a Doc Train West conference, I interviewed someone who asked to remain anonymous. It’s the only anonymous podcast interview I ever conducted (out of about 130 podcasts). The next day, the person asked me to not publish it. Why? The conference had a lot of sessions about wikis. The interviewee explained that at her work, they had created a wiki. It started out okay, but it soon degenerated into a maze of chaos. It had become an embarrassment, an impossible black hole of content. She was cautioning against wikis.

Part of the problem with organizing content on wikis is lack of control. As soon as wikis become a collaborative effort, with multiple authors, the organization becomes much more challenging and is likely to suffer from inconsistency and chaos. I don’t know if this is inherent in collaborative authoring projects, or if it’s inherent in the wiki architecture, but eventually wikis become so disorganized that search becomes the only method of navigation.

Case in point, check out the WordPress Codex. If you have a body of information this size, there’s no clear way to organize it. You end up with links that you can kind of group together, into Getting Started, Design and Layout, Advanced Topics. But then you also have general groupings under vague topics like Working with WordPress and About WordPress. There’s no clear path through the content.

Wiki Categories

One way to organize wiki content on Mediawiki is through categories. Many people reading Mediawiki wikis don’t realize this, but each page is usually tagged with a category. For example, the Wikipedia page on Technical Communication is labeled with the category Technical communication (scroll to the bottom to see it).

The category label appears at the bottom

Categories on Mediawiki work just like categories on WordPress, except that the method for adding them is less intuitive. Somewhere on the page, you just add the text [[Category:Technical Communication]]. This creates a category link that will pull together all other Wikipedia pages tagged with this same category, as shown in the image below:

All topics in the Technical communication category on Wikipedia

This method of content organization isn’t bad, except that the category link is buried in the page’s footer and is practically invisible. Some Mediawiki skins display the category link more prominently.

Still the Same Challenges

Despite this system of categories, you still run into the same issues of content organization. If you click the Discussion tab for this Technical communication category page, you see the following exchange between users:

Does Category:Specification languages really belong in this category?—iFaqeer (Talk to me!) 04:25, Nov 30, 2004 (UTC)

I’m not totally sure. I’m still trying to get my head around how this category system is supposed to work. I think there’s definitely some connection between technical communication and spec languages (like UML) but I don’t know whether it belongs as a subcategory. It certainly looks strange to be all by itself. If you’d like to remove it, I wouldn’t object. –LeeHunter 23:06, 30 Nov 2004 (UTC)

I don’t think it needs to be a subcategory. Perhaps it belongs as a link from an article discussing how some technical writers deal with them in their day to day jobs. Maybe as part of the main Technical communication article??–GeoffPurchase 04:33, 2004 Dec 1 (UTC). The contents of Specification language don’t quite co-relate with the contents of that category. Does it? I mean, do they? The category seems to list what I would call “mark-up languages” while the definition is for a kind of programming language (which might be a superset of what is in the category). If I am right, the latter is definitely TC-related; the former is only marginally so.

I am not very well-informed on either of the two areas my confusion spans, so I would like someone else to chime in. And the reason I keep posting this here is that it’s kinda lonely at Category talk:Specification languages.—iFaqeer (Talk to me!) 05:12, Dec 1, 2004 (UTC)

Does specification language fit into the Technical communication category? Maybe. I’m not even sure what a specification language is. Strangely, when I looked at this more closely, specification language didn’t make it into the Technical Communication category. But Specification did.

Categories and Subcategories

The fun doesn’t stop here. Each category can also have subcategories. Or looking at it from another perpsective, each category can also be grouped under a parent category. When you’re looking at a category, such as the Technical Communication category, scroll to the bottom to see which parent category it belongs to. You’ll see that Technical Communication is categorized under Written Communication | Communication | Technology. Technical Communication is a subcategory for these categories.

Larger categories that Technical communication is grouped under

If you click these parent categories, you’ll see that they’re also grouped into higher-level parent categories, namely, Human skills | Information systems | Language. Human Skills is a subcategory of Skills | Humans | Human behavior. Humans is a subcategory under Anthropology and Hominina. Hominina is a subcategory of Apes. Apes is a subcategory under Primates. Primates under Mammals. Mammals under Vertebrates | Tetrapods | Synapsids.

Vertegrates is a subcategory under Chordates. Chordates is a subcategory under Animals | Phyla. Animals is a subcategory of Life | Natural Sciences. Life is a subcategory of Nature | Phenomena | Fundamental | Main topic classifications. Nature is a subcategory of Main topic classifications | Fundamental. Fundamental is a subcategory of Articles, and then it goes to Content > Parent Categories > Categories > and Contents.

The exact taxonomy depends on how you climb up the topics. Like a pedigree chart of ancestors, you can take multiple paths. But here’s the general layout of categories and subcategories. I bolded the path I took to climb up to the highest level of categorization:

Contents
Categories
Parent Categories
Content
Articles
Main topic classifications | Fundamental
Nature | Phenomena | Fundamental | Main topic classifications
Life | Natural sciences
Animals | Biology
Eukaryotes | Zoology
Animals | Phyla
Chordates
Vertebrates | Tetrapods | Synapsids
Mammals
Primates
Apes
Anthropology | Hominina
Skills | Humans | Human behavior
Human skills | Information systems | Language
Writing / Communication
Written communication / Communication / Technology
Technical Communication

I don’t know about you, but I feel a special pride in the way this plays out, and how in just a few levels, you move from Technical Communication to Chordates. Maybe this is why the Category label appears at the bottom of the article and search appears at the top.

At the Highest Level, Categories Fail

It’s especially interesting to look at categories at the highest level: Contents.

One of the highest levels of categorization on Wikipedia

At this level, content is grouped into such general categories that it’s almost useless — categories by status, by topic, by function, by association, by type. If you were starting out here, would you ever drill down into Technical communication? It would take a miracle. But at the lower, more specific level, the category model does seem useful.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Faceted Browsing

According to Tony Self, one of the strengths of a help authoring tool (HAT) is the table of contents (TOC) feature. Through the TOC, you can easily create a quick system of navigation.

It’s common to use this TOC to create a system of topic-based containers for users to navigate, but there’s no reason why you couldn’t instead dedicate the folders to facets. In the prototype below, each of the “Browse by … ” books in the left pane represents the facets by which users can navigate the help content.

Faceted browsing system showing alternative methods of navigation

Users can browse the content by the following facets:

• Browse by Topic. Topics are arranged in the traditional topic-based, hierarchical containers.
• Browse by Role. Topics are arranged by role (super agent and regular agent), and then broken down by topic containers.
• Browse by Skill Level. Topics are broken into two books, Advanced and Beginner. And then most likely broken down by topic containers.
• Browse by Popularity. Only the top 20 most popular topics are listed.
• Browse by Concept or Task. Topics are divided into concept and task groupings, and then probably broken down by topic containers.
• Browse by Status. Topics are organized by facet. (In Swordfish, statuses play a prominent role for operations. Depending on the status of the operation, you can perform certain tasks, so this provides a way to organize the tasks.)
• Browse by Help Format. Topics are divided into video, diagram, and FAQ groupings.
• Browse by Problem. Topics are arranged by problem, somewhat like a troubleshooting grid.
• Browse by Screen. Topics are arranged by screen. These are the context-sensitive help topics.

Almost every HAT allows you to create multiple TOCs. Each of these facets is simply a secondary TOC that is integrated into the master TOC.

One of the problems with these facets is that they don’t entirely get away from the topic-based containers that I am resisting. With 200 topics, I can’t simply divide all topics in the help into two groupings, such as Advanced and Beginner. A second tier facet is also necessary, and the only second-tier facet that makes sense is the topic container.

However, some inclusion of topic containers isn’t necessarily a bad thing. The main reason topic containers fail is because of the abundance of topics. In small help systems, the topic containers provide easy navigation and aren’t as frustrating for users. The first facet, such as Advanced or Beginner, breaks down this large number of topics into a smaller subset, which makes the navigation more feasible.

Faceted Search

When a user clicks the search tab and searches for an item, the user can narrow the search results by using similar facets, as shown in the following image.

Faceted Search

I’m not sure how it would be implemented in other HATs, but in Madcap Flare, you can tag each topic with a keyword (this is called inserting Concepts). You can then add this set of tags/concepts below the search box by adding a “Search Filter Set” to your help.

The challenge here is to provide the same facets that users get by browsing. Tags work a bit differently than TOCs, but the idea is the same. You can limit the search results by the following:

• Regular Agent Role
• Super Agent Role
• Advanced Level
• Beginner Level
• Conceptual Topics
• Step-by-Step Topics
• Most Asked About
• Video Format
• Diagram Format
• FAQ Topic

Not all of the TOC facets end up as tags. The Browse by Role facet has two roles, so I can tag topics within these books as either a Regular Agent Role or Super Agent Role.

The Browse by Skill Level facet has two levels, Beginner and Advanced, so I can tag the topics within this facet as Beginner Level or Advanced Level.

For the Browse by Concept or Task facet, I can tag the topics as Conceptual Topics or Step-by-Step Topics.

The Browse by Popularity is tagged as Most Asked About (or Most Popular).

Finally, the Browse by Format allows me to tag the topics as Video Format, Diagram Format, or FAQ topic (these are the only three main formats in the help material apart from the concept/task distinction).

Shortcomings of Faceted Search

One of the most difficult problems with setting up faceted navigation is to identify facets for information topics. With merchandise or other products, you can often identify a clear set of attributes that define the product. With shoes, you can classify and filter the shoes by brand, style, color, cost, gender, sport, size, and other qualities.

With Google, you can classify the content by a plethora of information formats, including news, books, videos, images, maps, discussions, shopping, blogs, twitter (“updates”), and more.

In a library, you can classify books by author, publication date, genre, period, subject, book type, etc.

Help topics don’t seem to have a set of clearly identifiable facets. Some of the facets that you could classify a help topic with — for example, length, format, reading level, information type, corresponding screen, etc. — aren’t that helpful to users.

Help content is, however, rich in topics. But using topic tags as the attributes seems like the same game as the topic-based, hierarchical containers. For example, look at the faceted search filters that I’ve circled in the following image.

Topic facets on a search for a topic

If a user searches the help for “run a black operations campaign,” what benefit is there in limiting the results to the facet “Related to black ops”? Won’t the results already contain black ops topics?

Further, what if a user searches for “coordinate informants for black ops”? Which facet would I then choose to limit the results — Related to Black Ops or Related to Informants? It’s the same problem as the topic-based, hierarchical containers.

Searching for a topic and then limiting the results by topics seems redundant to me.

Moreover, if these facets are simply topics, there’s a likely chance that you’ll include dozens of topics. Adding too many topics in the Search Filter Set will bloat the number of search facets beyond what is usable. If you look at the search filter set in Flare’s online help, you’ll see that they use about 80 different topics in their search filter set, which seems excessive.

It’s clear that faceted classification and faceted search have benefits for many product websites, as well as for many information-heavy websites with many types of content. But the lack of a clear set of facets for help material makes it more challenging to implement in a way that is clearly beneficial.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Faceted Classification

In a faceted classification system, you tag your content with a specific set of attributes. You then provide different arrangements and sorting of the content based on those attributes.

For example, if you have an online paint store, the set of attributes for your faceted classification system might include brand, color, texture, shine, thickness, and cost. You can then allow users to navigate the paint products by each of these attributes.

Sarah Maddox notes that in Matthew Ellison’s Turning Search into Find presentation at the AODC 10 conference, he gave an example of faceted classification with the shoe store sportsshoes.com.

Faceted classification system

Many times faceted classification systems allow you to combine and narrow down the attributes to get closer and closer to your information. Sarah notes that

Matthew introduced the concept of the “scent of information”: If people can see that they’re getting nearer to the information that they’re want, they’re quite happy to keep combining facets to narrow down their search.

Faceted classification and faceted search systems are actually quite common on the web. When you search for something on Google, the left pane provides a list of facets that you can use to limit the search results to a specific category of information.

Google's faceted search

In the above example, I searched for “undercover agents.” Using the facets, I can limit the results to show images, videos, news, discussions, shopping sites, maps, books, or other formats that contain the words “undercover agents.”  This is the way Google has categorized the different types of information it indexes.

Amazon also provides a faceted search. When you search for a product, such as Beauty and the Beast, you see a list of facets in the sidebar to narrow the results.

Faceted browsing on Amazon

Grooveshark also provides a faceted search based on the term you search for.

Grooveshark's faceted search

Navigation Features

The most popular sites on the web may not all be set up with faceted classification and faceted search, but they do offer other types of navigational features. These other navigational features could informally be called facets, but according to Peter Morville, author of Search Patterns and Ambient Findability, these organization systems are more like features rather than facets. But they still organize and arrange the content into structures that aren’t based on hierarchical topic containers. Here are a few examples.

Hulu allows users to choose among the following:

• Gallery content
• Channels
• Most Popular
• Recently Added
• Collections
• Trailers
• Spotlights
• TV
• Movies
• Search

Wikipedia provides users with these navigational features:

• Featured content
• Current events
• Random article
• Today’s Featured Article
• In the News
• On this day
• Today’s featured picture
• Categories
• Index

The New York Times provides these features for navigating the content:

• Today’s Paper
• Video
• Most Popular
• Times Topics (like an index)
• Categories
• Most E-mailed
• Most Blogged
• Most Viewed
• Most Searched
• What We’re Reading
• Reader’s Recommendations
• Most Recent

Coming back to Amazon, when you view a product on Amazon, you get a ton of interesting navigational features for finding more content:

• Customers Viewing This Page May Be Interested in These Sponsored Links
• What Do Customers Ultimately Buy After Viewing This Item?
• Customers Who Bought This Item Also Bought
• Tags Customers Associate with This Product
• Customer Reviews
• Customer Discussions
• Look for Similar Items by Category
• Your Recent History

You can see the wide variety of faceted classification, faceted search, and other navigation features on the web. Why don’t we borrow more of these faceted navigation models to provide alternative organization systems for our help content? Why is it that, despite the abundance of these alternative navigation systems, most technical writers still stick with a traditional topic-based, hierarchical folders? In contrast to many sites on the web, the organizational structure of most online help files hasn’t changed in 20 years.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

I think traditional help authoring tools (HATs) will fade in place of more collaborative tools like wikis

This wasn’t just a fleeting thought. I spent the last couple of days last week getting buy-in from project leaders on wiki formats for all of my upcoming projects. I thought we might be using Confluence in addition to Mediawiki at my work, but because learning and maintaining two different wiki platforms is onerous for both engineers and content contributors, we decided to stick with just Mediawiki.

Surprisingly, when I explained the need to collaborate with multiple contributers, and also expressed for business departments to own the documentation after I created it, the senior leaders gave me immediate approval to use a wiki format.

So I’ve been ramping up on Mediawiki lately. In some respects Mediawiki is similar to WordPress, and in others it’s not. For example, both WordPress and Mediawiki are open-source PHP web-based platforms with MySQL database backends. After creating a database and user, you set up the sites through an installer script and configure the display through CSS.

Both platforms have themes/skins that you can download and apply to your wiki. Both platforms have thousands of plugins/extensions that will extend the functionality of the software. Both platforms have vibrant online communities with thousands of users participating in forums, blogs, and other groups.

However, there are also some key differences between the two. The main difference is that Mediawiki has no user interface for managing the content, whereas WordPress does. With Mediawiki, you work a lot with a file called localsettings.php, which you have to FTP back and forth.

Additionally, with Mediawiki you sometimes search for the files you want to modify and then edit them within the browser interface. Mediawiki has a lot of namespaces, so creating a page with a certain prefix before a colon puts the page into a particular group and it gets treated differently.

I previously thought wikis were fairly primitive and limiting in terms of format. I’m now realizing that wikis — at least Mediawiki — is incredibly robust. There’s a lot to learn. For example, to impose structure on a wiki, you can label pages with categories and subcategories. When you add [[Category:Oranges]] to a page, it puts the page in a category called Oranges. Then you can dynamically pull together all pages with this category label. And you can add subcategories by opening the subcategory page and adding the parent category tag.

“Category” is in a Mediawiki namespace, and there are dozens of these namespaces. Through the Category Extension tree, you can automatically show all pages within a category in a collapsible tree. The tree uses AJAX to collapse and expand. To install the extension, you add some code to your localsettings.php file and upload the extension files to your /extensions folder. You can also access a special page for browsing categories by searching for special:categorytree.

Templates are snippets of reusable code. For example, if you have a note style that you want to reuse again and again, you create a new page like this: [[Template:Note]], and add your style. Then when you want to use your template on a page, you just add {{Template:Note}} and the code appears. It’s essentially a php-include.

I only add this detail here as an example of the underlying robustness of the software. Previously I thought wikis might be limiting because the formatting options seemed so primitive — either bullets or numbers or headings, and not much else. Now I realize that I have so much to learn. I’m only on stair three of about a hundred stairs.

Over the next year I’ll have my head deep in Mediawiki, so expect to hear more about it from me on this topic (and wikis in general).

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

The sixth sin in my ongoing series on the Seven Deadly Sins of Blogging is being unfindable. (The other sins include being fake, irrelevant, boring, unreadable, irresponsible, and inattentive). Admittedly, lack of findability seems more a sin of omission than commission. Being unfindable seems like a sin bloggers commit against themselves.

I’ve written more than 1,000 posts on my blog, but usually the posts on my home page are the only posts people read. In this sense, blogs are like the news. A newspaper that’s several days old lines bird cages. Reading blog archives is like reading yesterday’s news — there’s no appeal.

And yet, many times archive posts have more substance that news commentary. The posts incorporate research and get into issues in depth. They don’t deserve to go into the garbage can once they slide off the home page.

Michael Arrington of TechCrunch.com compares blogging to reaching down and grabbing a handful of sand. The sand slowly slips through your fingers. You have to reach down and grab another handful of sand, and another, and another. In the metaphor, your readers are the sand; your reaching and scooping — those are the new posts. Perhaps if the content were more findable, you wouldn’t have to do so much reaching.

How can you enable readers to naturally find the content in your archives? How can you make the hundreds of posts you write more visible and prominent, especially if readers are looking for it? This is partly what the field of findability is all about.

Peter Morville, author of Ambient Findability, wants to move toward a world “in which we can find anyone or anything from anywhere at anytime.” He admits we might never achieve it, but it’s the direction we’re moving. To start, Morville says to ask three questions of your content:

1. Can people find your website?
2. Can they find their way around your website?
3. Can they find your content, products and services despite your website?

Aggregation Techniques

You can implement several easy aggregation techniques to increase the findability of your content. You can add tags and categories to your posts, and readers can navigate your content this way.

Tags function similarly to categories. You usually add tags as you would index keywords, including as many as you want to describe your content. Categories, on the other hand, are more like folders. You usually have only about a dozen categories on your site.

You can display your categories in a list on your sidebar, which could be helpful except that hardly anyone reads this way. And you can aggregate your tags into one of those jumbled masses of words called tag clouds. But like the list of categories, tag clouds don’t seem that useful to readers. At least I never use them. They’re merely a visual novelty.

Another way to increase the findability of your content is to add a string of related posts below each post. A variety of WordPress plugins do this for you (for example, the Contextual Related Posts plugin). Their matching algorithms vary a bit — some match by tag, others by keyword, others by custom keywords. Mostly, I think lists of related posts help searchers who land on your site from search engine results. These searchers are usually looking for information and sometimes prefer to drill into additional content on the same topic.

You can also aggregate your content through plugins that compile your most popular posts, such as the Popularity Contest plugin. Popularity is defined by hits, links, and comments. Your most popular posts may not be the posts you want to showcase, though. This is why I chose not to implement the Popularity Contest. My most popular posts are apparently posts on grasshoppers that look like aliens, a WordPress image gallery plugin, and notes from a keynote on WordPress 2.7.

You can also manually pull together your best posts. I recommend using the links feature in WordPress to manage your lists. You can also use the Section Widget (a tabbed widget) to show various lists in a compact way. Note that the tabbed section widget slows down your site’s loading time a little (I was intrigued by it earlier, but I removed it). It also seems to consume a lot of memory on the backend.

SEO

Let’s recognize a basic fact about websites. The majority of your readers — anywhere from 50 to 85 percent of visitors — find you through search engines. The web is mainly used for research, so these stats make sense.

But if visitors mainly find you through search engines, shouldn’t your content be optimized to rank high in search engine results? Search engine optimization (or SEO) should be a key influence in the way you write your posts, right?

Jakob Nielsen agrees. He says,

Web users are growing ever-more search dominant. Search is how people discover new websites and find individual pages within websites and intranets. Unless you’re listed on the first search engine results page (SERP), you might as well not exist. So, the first duty of writing for the Web is to write to be found.

Yes, you must write to be found. To do this, to make your posts SEO rich, you have to integrate the right keywords into your title, first paragraphs, headings, image alt tags, and other places (without going overboard).

However, in Google’s search engine results algorithm, links pointing to your content from other sites matter more than anything you can do alone. So more than anything, write compelling content. Compelling content invites links back to your site.

One trick that allows you to get the best of both worlds is the All in One SEO plugin (if you have a WordPress blog). This plugin allows you to make two titles: a title that Google sees and a titles that readers see.

For me, I sometimes don’t bother with SEO because I’m not sure my content would rank for a specific topic. I’m not necessarily writing just to attract more hits. Maybe with some posts, sure. With other posts, not so much.

Formats

Another technique for increasing findability is to push your content across as many formats as possible. Recognize that readers have a variety of preferences. Some like Facebook, others Twitter, others email, others RSS readers.

You can automate all of this so that when you publish a post, notification of the new post is syndicated across each of the formats. The RSS feed is automatically pushed out (if you’re using any standard blog platform). Twitterfeed allows you to hook up your RSS feed with a Twitter account. Facebook allows you to pull in a Twitter feed. And Feedburner allows you to create email subscriptions for RSS feeds.

Audio and Text

One challenge that still remains with formats is the interchangeability of audio and text. I regularly publish podcasts, and people who don’t listen to podcasts often request transcripts of the podcasts. It can take hours, however, to record and produce a podcast, and 5+ hours to render a transcript of the audio. It’s a tall order to fill just to make the content more accessible.

I believe Adobe Sound Booth will transcribe audio (though this is application isn’t free). You can also outsource transcription for about $1 a minute (and a two-week turnaround). A direct transcription of the audio, however, often sounds incoherent and unreadable.

Going from text to audio is much easier. Services like Odiogo will automatically read your post. For an example, see Todd O’Neill’s Doing Media blog. The problem with these text-to-audio services is that they’re read by a machine, so it sounds like robot. Additionally, people who are blind probably already have screen readers that perform with similar functionality. Odiogo is really designed for people who want to listen to your content on the go, while they run or drive or work in the yard.

Nevertheless, if you want to make your blog perceivable, a conversion to other formats is what Glenda Watson Hyatt recommends. In her book How POUR Is Your Blog, she writes,

Content must be perceivable through sight, hearing or touch. Since not everyone has the same abilities or equal use of the same senses, one of the main keys to accessibility is ensuring that content is transformable from one format into another, enabling your blog readers to perceive it in multiple ways. (p.6)

(POUR stands for perceivable, operable, understandable, and robust.)

Apart from making your content findable for the disabled, rendering your content into text and audio increases your reach. An hour long podcast transcribed into text theoretically gives you rich SEO keywords that will bring in many more search results from Google. (Of course, the extra time you spend transcribing the content means less time to produce new content, so perhaps it balances out.)

Mobile Platforms

Finally, as you design for different formats, make sure your content is visible on mobile platforms. Mobile browsers are getting to the point that they can display many websites well regardless of whether you have a mobile stylesheet, but it’s still a good idea to add a mobile plugin.

Hyatt recommends going to http://ready.mobi to test how your blog displays in a mobile browser. If you receive a poor rating from MobiReady, try installing Alex King’s WordPress Mobile Edition plugin and rerun the test.

MobiReady also has several emulators that show you how your blog looks on various phones.

Other Findability Tips

To wrap up findability, I suggest adding a few more simple, commonsense practices.

1. Let your URL match your blog title. This helps readers remember how to get to your site without having to google it each time.
2. Include an About page. Your About page is one of the most visited pages on a blog because people want to see information about the person whose opinions and advice they’re reading.
3. Use Feedburner to route your RSS feed. If you ever change platforms (for example, from Expression Engine to WordPress), you can update your RSS feed on your new site so you don’t lose all your readers who subscribed to your old RSS feed.

To conclude, remember that the goal of findability is to help your audience connect with your content. On A List Apart, Aarron Walter writes,

The fundamental goal of findability is to persistently connect your audience with the stuff you write, design, and build. When you create relevant and valuable content, present it in a machine readable format, and provide tools that facilitate content exchange and portability, you’ll help ensure that the folks you’re trying to reach get your message. A website that ignores findability is whispering into the wind, hoping that someone passing by might catch a hint of its message. (A List Apart)

Don’t whisper to the wind. Don’t let your content blow around aimlessly. Make it findable. When it’s findable, you get to keep it forever. When it’s not, it disappears into the wind.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

• Top level: .cat-item a { }
• Second level: .cat-item ul li a { }
• Third level: .cat-item ul ul li a { }

Styling Categories in WordPress

I created a five-minute video showing how the addition of these category classes to your WordPress stylesheet will change the style of each category level.

Watch the video

I also uploaded it to Vimeo, although the quality isn’t as good.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

Here’s an excerpt from her latest post:

Optimism afflicts me in both my worlds, web development and fiction writing. The flip side of optimism is, of course, despair: when I realize it’s impossible to reach the dizzying heights to which I so casually aspired at the beginning of a project, my brain siphons away every happy chemical and erases my buzz, leaving me with a creative hangover and a depressive unwillingness to finish the project and thus prove my incompetence.

One reason I like Beth’s blog is because she seems to write for herself, for the enjoyment of writing, for keeping a journal of her thoughts and challenges she encounters. Her journal is a literary journal and you can see the expression of her creative mind through her posts. Whether she receives a lot comments or not seems irrelevant to her purposes.

Although I have many feeds in my feedreader, mostly chosen for their topics, hers is one I read regardless of the topic. I once wrote a post titled Counterargument to the Importance of Categories, in which I argued that for some writers, the category or topic is less important than the style. Beth’s blog is one of those blogs, and I hope to move mine in the same direction.

In a presentation Char James-Tanny gave to the Suncoast chapter a few months back (which I just published on Tech Writer Voices), Char was talking about blogs and mentioned that I tend to focus more on people than tools in my blog. This is partly because I periodically spotlight new bloggers to let others know of their existence. But also because blogging is often more about people than tools. It is often just as much about our style of expression than the content of what we say.