I'd Rather Be Writing » findability

Webinar Recording — Organizing Help Content: Breaking Out of Topic-Based Hierarchies

Tom Johnson — Sat, 18 Feb 2012 15:21:43 +0000

I recently gave a presentation to the Southwestern Ontario STC chapter called Organizing Help Content: Breaking Out of Topic-Based Hierarchies. Here’s a recording of the presentation:

Blog Sponsors

Looking at Breadcrumbs in a New Way

Tom Johnson — Fri, 06 Jan 2012 04:09:04 +0000

One of the findability features in our help systems that we often overlook is the breadcrumb. Breadcrumbs typically sit above the page title and highlight the hierarchical path that leads to where you are. Here’s a screenshot of a typical breadcrumb, taken from Adobe Illustrator’s help:

Greg Nudelman discusses breadcrumbs in one of his chapters in Designing Search: UX Strategies for eCommerce Success. This post mainly details notes from Nudelman’s book.

One problem with breadcrumbs, Nudelman notes, is that “breadcrumbs cannot show customers where to could go next. They show only where they’ve already been” (p. 199).

Nevertheless, Nudelman says the breadcrumb aligns with a search/browse pattern that supports common finding practices. Nudelman cites a presentation by Peter Morville called “Search & Discovery Patterns,” where Morville explains that “browse and search work best in tandem… The best finding interfaces achieve a balance, letting users move fluidly between browsing and searching.” (p. 203-4)

In other words, when looking for content, users prefer to search and browse, browse and search. Users perform a combination of the two as they try to find what they’re looking for. This is because, Morville explains, “what we find changes what we seek.” For example, search results for your initial query might show you the correct terms, which then informs your next search.

Breadcrumbs are powerful tools because users can easily modify the breadcrumb path to browse the information they want to see. Nudelman explains,

Providing the ability to change attributes while automatically retaining all relevant query information turns the breadcrumbs into a powerful and flexible finding mechanism, without making the resulting interface overly complicated or difficult to use. (p. 210)

For example, in the above screenshot, I may not want instructions for creating a drop-shadow effect. But rather than returning to the raw search and formulating a new query, I can click the Special Effects breadcrumb and browse the other special effects available. The breadcrumb allows me to modify part of my search without starting over from scratch. Nudelman says users would rather salvage part of their search and refine it rather than starting over:

In my research, people seldom want to start the query over completely from scratch, unless they specifically indicated this action. Instead, a vast majority of the people interviewed wanted to retain as much of the query as possible with every change of the facet values and desired the system to help them construct a query that “makes sense,” gracefully dropping facet selections that no longer applied to their modified query. (p. 208)

One problem with breadcrumbs in most webhelp system is that they perpetuate the myth that content lives in just one place, which is not necessarily true. Content in the digital space can appear in many different arrangements and paths.

Nudelman notes that Edmunds.com’s search results show tag selections as breadcrumbs.

I would like to see webhelp move away from a single hierarchical organization of content to one that simply shows tags that are stacked together in the query. This shift would be a new paradigm for the way help is organized. In Edmunds.com, each of these keywords is metadata for the content. There may not be an official hierarchical order to the content, like there is most webhelp systems. The order is dynamically generated based on the metadata you select.

I recently wrote about tags as being more of a web-based method for classifying information. See Using Tags to Increase Findability.

For more information about Greg Nudelman, see his site, Design Caffeine.

Blog Sponsors

Using Tags to Increase Findability

Tom Johnson — Mon, 26 Dec 2011 17:32:21 +0000

Tagging: People-Powered Metadata for the Social Web

I recently read Tagging: People-Powered Metadata for the Social Web (2008), by Gene Smith. Smith dives into tagging as a method for adding metadata to resources, which in turn increases the organization and findability of the resources.

Traditional help authoring tools categorize resources through folders (a carryover from Windows folders), whereas web platforms typically use tags. Tags are actually a quick and easy way to attach metadata to any information object.

For example, you might tag a photo with a geolocation. This would allow the photo to appear in the correct location on a map. Or you might tag a help topic with information about the audience and other relevant facets, such as role, location, goal, task/concept/reference, and so on. The key point is the tags are metadata.

Twitter wouldn’t be nearly as powerful without tags. Adding #techcomm to a tweet makes it findable for the technical communication community, just as tagging tweets with #contentstrategy makes it findable for the content strategy folks.

What’s cool about tags is that you can easily tag the same information with multiple tags. Does the information fall in #techcomm, #contentstrategy, and #findability disciplines? You don’t have to choose one folder to assign the content to. With tags, resources can live in multiple places at once.

Tags can be generated in at least two different ways. If users assign tags to topics, the result is a more free-form, loose set of terms that some call a folksonomy. Del.icio.us is the flagship example of a folksonomy. If only designated authors can assign tags, the result is more of a centralized taxonomy.

Tag clouds, which are visual displays of your top tags, can give you a general idea of topic trends. For example, if you look at the bottom of my sidebar, I frequently tag posts with the terms blogging, creativity, podcasting, screencasts, STC, technical writing, Web 2.0, and WordPress.

The tag cloud highlights only the most common terms. To see 500 tags in a cloud, see this page. When you look at this massive tag cloud, you might immediately realize one of the limitations of tags: lack of hierarchy. Most tag systems lack any kind of hierarchical arrangements (that is, parent and child tags), so as tag systems grow, they become unwieldy. The flat structure of links becomes hard to navigate.

Managing tags in digital photo collections can highlight the limitations of tags. Scott Dart, program manager of the Microsoft Photo Gallery, says,

“Anyone who has tagged their photos for any length of time will tell you that a flat list eventually becomes unwieldy. This is one of the reasons why we have hierarchical folder structures– because a flat list of folders would be too long to manage” (quoted in Tagging, 200).

In other words, the ease of adding tags to resources leads to an abundance of tags that gets to be hard to manage, unless you have some type of hierarchy imposed on your tagging systems.

Some tag clouds do allow you to drill down and explore a list of subordinate tags. Other platforms allow you to leverage tags in combinations of each other. Both strategies can make tags more useful and powerful.

Beyond tag hierarchies, Smith talks about some concepts I hadn’t heard before:

Pivot Browsing: ”Moving through an information space by choosing a new reference point — a pivot — for exploring the system” (105). The ability to look at information based on users, resources, and tags provides various pivot points in the data. Pivot points seem similar to facets but more radical in the way they change the reference point.
Pace Layering: ”Aspects of society change at different rates” (91). For example, tags suit user needs as they’re moving quickly to make sense of new information; taxonomies and ontologies are more appropriate later, when the dust settles and users have more time.
Synonym Rings: “A synonym ring gives two or more words an equivalent meaning” (69). These rings establish synonym equivalents for tags, so that “Web20″ and “Web_2.0,” for example, would be equated with one another.

Some tagging systems present users with the most popular tags, often segmented by time. But knowing that a tag is popular is just one type of information. Popular by whomis another type of information that tagging can surface. Smith writes, ”One of the benefits of tags to object-oriented sociality is to bring people together through their tags” (187). In other words, you can also connect with other users who have tagging patterns similar to you.

Tagging interfaces are characterized by speed and simplicity. As a result, tagging can be messy, with numerous tags having similar spellings, formatting, and synonyms. This is why it’s necessary to regularly clean up tags with tag management tools, which allow you to merge, delete, or change tags in bulk.

Tags have been implemented in a variety of ways with different platforms. For some examples, check out Del.icio.us, Mefeedia, Buzzillions, LibraryThing, Milenix MyInfo, Flickr, and Youtube.

Tagging is emerging as one of the most common ways to organize resources on the web. Smith notes that Delicious, a social bookmarking site that first appeared in 2003, was one of the first instances of tagging to emerge online. However, he also notes that classification and metadata strategies have been ongoing for centuries, with the Dewey Decimal system as one of the prime examples.

My Thoughts

In the larger discussion about findability, tagging brings us right back to the metadata discussion. Tagging is metadata that people apply to resources so they can find the resources later.

Tags present a radical shift in the way we attempt to organize information. Many help authoring tools default to hierarchical folder structures, but tags allow for polyhierarchy and give many more “pivot points” and facets for browsing the information.

The key point about tags is that you can add any number of them to a single resource. You can then manipulate the resources based on the tags you want to leverage. This is something you can’t easily do with a traditional hierarchical organization of information, or in systems where resources are placed in one folder at a time.

For example, with help information, you might add tags related to any of the following metadata properties:

Author
Date published
Release version
Date last revised
Popularity
Task
Concept
Reference
Format
Difficulty
Location
Event

You could then manipulate the resources in different ways based on the metadata that was important to you. You could also manipulate the resources based on combinations of tags — for example, the most popular tasks that are specific to a particular location. Combining tags provides a powerful way to sort and manipulate data, as it allows for a lot of different arrangements and possibilities.

When we start thinking of tags as metadata, they becomes a much more useful tool for help systems.

Although I’ve explored different strategies for findability, it seems that faceted classification through the attachment of metadata (such as tags) to resources remains the most compelling strategy. It can suit a diversity of audiences, purposes, and needs.

Taking it one step further, I think we need to allow users to tag help content. One failure of tech comm is that it hasn’t kept step with the innovation of the web. Many help authoring tools discard the interactivity of the web and the wisdom of the crowd. The revolution that needs to occur to pull help into the current era is to leverage the wisdom of the crowd in an intelligent way to increase the findability of help. Allowing users to tag content, and then leveraging their tags, seems like a good way to start.

Blog Sponsors

Slides from STC Webinar on Organizing Content (Findability)

Tom Johnson — Mon, 05 Dec 2011 07:44:55 +0000

Here are my slides from the STC webinar I presented on organizing content (findability). The official title of the webinar was “Organizing Content: Breaking Out of Topic-Based Hierarchies.” I added detailed notes for each slide. This should make the presentation understandable even without the audio recording. You can download the presentation in two formats:

Feb 19, 2012 update:You can listen to the recording of this webinar here.

Blog Sponsors

My STC Webinar on Organizing Content — This Thursday at 4pm EST

Tom Johnson — Wed, 30 Nov 2011 08:36:05 +0000

I’m giving an STC webinar this Thursday. Here’s the description:

Organizing Help Content: Breaking Out of Topic-Based Hierarchies

Organizing help content so that users can both find and learn information often requires technical writers to break out of the traditional topic-based folders and move toward faceted navigation, search engine optimization, interface text, level-based help, and other methods for organizing content.

In theory, this is the same presentation I gave at the last STC Summit. In reality, it’s a much different presentation. I’ve taken everything I learned from my Summit presentation, including feedback from attendees (which I received just last week, if you can believe it) and made this material much better.

The problem of my original presentation was one of ambition. I tried to tackle one of the most difficult challenges in help authoring: enabling users to find exactly what they’re looking for quickly and easily in a mountain of possible help information. I set up the presentation as a solution, but noted its shortcomings and ultimate failure. That left a lot of people uneasy.

In my revised approach for the webinar, I take a different track. Rather than presenting a single solution, I present 10 approaches to findability that veer outside of a traditional table of contents. These alternative approaches include search, metadata, user research, indexes, quick reference guides, personalization, interface text, tags and categories, alternative modes (such as video), and level-based learning.

My new argument is that while no single method solves the findability problem in its entirety, each contributes toward an increase in findability. If you were to add all the solutions together, the net result would be a dramatic increase in findability.

What I don’t address is how someone would find the time to implement all of these methods. In reality, you can spend more time trying to make your content findable than you do creating the content itself.

This new approach is more realistic. It isn’t as appealing, because most of us like to think there’s a simple answer to the problem, if we can just figure it out. But I doubt that’s the case.

As a bonus for science enthusiasts, I also bookend the webinar with stories about Mendeleev (at the beginning) and Pythagoras (at the end). According to my evaluations, people like it when you bring in science.

If you’re interested in the topic of findability, definitely check out my webinar. You can register here. 81 people are already registered, so there are only about 20 spots left (due to Genesys webinar limits).

For people who can’t make the live webinar, I may make another recording of the content later, perhaps as a podcast.

Blog Sponsors

Podcast: Organizing Help Content: Breaking Out of Topic-based Hierarchies

Tom Johnson — Wed, 18 May 2011 22:59:33 +0000

The recording is available in a variety of formats:

I recently gave a presentation at the STC Summit in Sacramento titled “Organizing Help Content: Breaking Out of Topic-based Hierarchies.” I would have recorded my presentation, but recording is not allowed. I did, however, record a practice run-through in my hotel room the morning before.

I included a variety of links here. If you want to view slides while listening, click the Audio with Slides option.

Comparing the practice presentation to the real presentation, the practice presentation ended up being about 15 minutes longer. This means I had more time for questions and discussion during the real presentation. Some participants gave me great feedback in the discussion and follow-up afterwards. This presentation is only one part of an ongoing journey in my effort to solve the findability problem with help content.

Blog Sponsors

Every Page Is Page One

Tom Johnson — Mon, 16 May 2011 15:10:18 +0000

Mark Baker

The following is a guest post by Mark Baker.

The a-ha moment came for me reading David Weinberger’s Everything is Miscellaneous, a book Tom and I both admire. Weinberger’s central thesis is that miscellany has become more powerful than order. No one ordering of information is ideal for every reader. The web allows readers to find information for themselves, and to organize it for themselves and for others. The power to organize content, Weinberger argues, has passed from the creators of content to the consumers.

What have we always told people our job is? Organizing content so people can find it. That’s how we have justified our existence to sometimes skeptical development and product managers. You need us because we know how to organize information. If you leave it to the developers, it will be a mess and no one will be able to find anything. Miscellany bad. Hierarchy good.

Not so much, it turns out. By digging and liking, and tweeting, and tagging, readers lay down their own paths through the content, paths that are non-hierarchical, miscellaneous, and increasingly well travelled. This is a battle that has been fought out on a global scale. On the side of hierarchy and order was Yahoo, which set out to catalog the entire web with a legion of human editors. On the side of miscellany was Google, with a whacking big search engine. Remember who won? It may put you in mind of an earlier battle between man and machine: John Henry hammering in the mountain, trying to beat the steam drill, until the handle of his hammer caught on fire.

What then must we do? Die with our hammers in our hands? Or find a new way to do this job? Because it is no longer in our power to control the order in which readers read our content. They will read it any way that suits them.

In the age when the search engine is king, writers can no longer direct where the reader will land in the documentation, what they will read first, or what they will read next. The reader may begin anywhere, and that means that any page may be page one for that reader. And if any page may be page one for someone, what that really means is that every page is page one.

That was the a-ha moment: Every page is page one. Any page is as likely as another to be the first page the reader sees. There is no first, last, previous, next, up, or back. There is only page one. This page, that page, every page: all page one.

What if the page that the reader lands on does not work as page one for them? Where do they go? Backward and forward through the document hoping to find page one? No. They go to the next page listed in the search results, click on that, and that becomes their next page one.

Now, you may argue, this may be true on the web, but our docs are not on the web. We have a self contained help system, and we have the power to designate page one for our readers, to structure the reading experience for them. Alas, it is not so. Twenty years ago, readers came to help systems from the world of books, and they expected them to work like books. Some of the more interesting experiments in help system organization actually got smothered out of existence early on by the reader’s demand for a familiar book-like organization of the help system. Help systems vendors and authors complied, and help systems have pretty much been organized that way ever since.

But readers no longer come to a help system expecting it to work like a book. We are all children of the web now, and we come to any information system looking for the search box, and expecting the search to work like Google. Recent user feedback that I have been reviewing made this very clear to me. Our users see the documentation as one thing, not a collection of books, but one seamless whole, and they expect to find things by searching the entire doc set from one place.

If anyone in the tech pubs business thinks they are being innovative by moving from books to topics, I’m afraid that innovative is not the word for it. A little less behind the times that the rest would be a more honest assessment. Our readers are way ahead of us. They are already treating our documentation as if were a collection of topics, and being disappointed when the first topic they land on does not meet their needs, does not work as their page one.

Every page is page one — this is a fact, not a choice. Making every page we write a good page one — that is a choice. And this, I believe, is the single most important thing we must learn to do as technical writers. To be sure, many trends are claiming our attention, and there are a dozen new things every year that we are told we absolutely must master if we hope to stay relevant. But in the end, we exist to give people the information they need to do their jobs, and the way to do that is to create content that works for them no matter how or where they find it. If we do everything else and forget this, we will fail. If we do this and forget everything else, I think we will still succeed.

We will still succeed, even if we do get everything else wrong, because the Iron law of the Internet is that good content gets found. Thousands of recordings, mostly abysmal, are uploaded to YouTube every day. There is no sorting, no editing, no promotion. Yet the great ones go viral, usually within hours. Content that deserves to be found, gets found.

What then must we do? The answer, I am convinced, is that we must write every page as if it were page one. What does that mean? How do we write every page to be page one? That is apt to be a large subject. I don’t have all the answers, but I am exploring the subject on my blog, Every Page is Page One. I hope you will join in the discussion and the exploration, both here, and there.

Mark Baker has been a technical writer for over 20 years and has worked on topic based authoring, structured writing, single sourcing, and SGML/XML for almost as long, including a stint as Director of Communications for SGML pioneer OmniMark Technologies. He has designed and built topic-based authoring systems and has spoken and written frequently on topic based writing and the applications of markup technology. He is currently Senior Staff Technical Writer at Wind River System. He blogs at everypageispageone.com and tweets as @mbakeranalecta.

Blog Sponsors

Book Review: Search Patterns, by Peter Morville and Jeffrey Callender

Tom Johnson — Mon, 28 Mar 2011 06:44:32 +0000

[amazon-product align="right" alink="#082ef6" height="250" region="us" tracking_id="idrabewr-20"]0596802277[/amazon-product]

Search Patterns: Design for Discovery (2010, O’Reilly), by Peter Morville and Jeffrey Callender, explores search in depth, from every possible angle. Search Patterns is a must-read for anyone interested in search and findability. It should be particularly applicable to technical communicators, who rely on search as a key method for users to locate information. The book is foundational and, though brief, highlights ten search patterns that we would do well to implement on any site or help system.

Although it only occupies 50 pages of the book, the Design Patterns section is the core value of the book. Patterns are recurring models that work well. They are “repeatable solutions to common problems” (82).

Morville and Callender highlight the following ten search patterns: autocomplete, best first (similar to recommended results), federated search (searches across multiple collections, sites, databases), faceted navigation, advanced search, personalization, pagination, structured results (embedded charts, videos, music, or graphs in search results), actionable results, and unified discovery.

Throughout the book, Morville and Callender emphasize the need to browse and search in combination. Because of this, they herald faceted navigation as a key strategy. In fact, they call faceted navigation “arguably the most significant search innovation of the past decade” (95).

The genius of faceted navigation is that “incremental clarification and refinement reduce results until the need for paging and scrolling virtually disappears” (116). In other words, faceted navigation allows you to first search and then refine the results by browsing the facets, so it allows search and browse to work together. Some sites even offer scoped searches, which allow you to search within a defined facet.

Morville and Callendar explain that “faceted navigation will surely adapt to every context and platform because the need to narrow exists at the crossroads of behavior and the box” (101). Narrowing is a key behavior with search. Users don’t merely search and find, or browse and locate. We search and learn the right keywords, which informs a new search, which may lead us to browse the right facets or menu, and so on.

The core of Search Patterns involves the design patterns, but the rest of the book isn’t without interest. In the latter third of the book, Morville and Callender explore a variety of search techniques on sites, looking at different approaches to search. At times the exploration of these search techniques seems to be somewhat meandering, but the authors note that we have much to learn about search. We only scratch the surface of our understanding with these ten patterns. In many ways, it feels that Morville and Callender are searching to find and explain more patterns from their large sampling of sites.

The writing can at times be a little thick, but it’s also filled with great one liners, such as “Search ends with an exit” (52). “Predictability assures usability” (74). “Innovation requires improvisation” (80). “What we find changes what we seek” (87). “Discovery requires that we move beyond what we know” (131). I loved finding these nuggets.

The book is also full of visualizations (beyond screenshots). Diagrams, workflows, and other eye candy populate nearly every page, which allows you to move swiftly through the various concepts and ideas in a pleasurable way. Callender, the graphic designer, helps visualize the ideas that Morville expounds. As one critic pointed out, though, with many of the screenshots, the figures often don’t appear on the same page as the discussion. More lengthy captions below the images would have been welcome.

The book gave me a strong understanding of the multi-faceted nature of search. As a technical writer, I’m eager to incorporate some of these patterns into my help systems. But I admit that figuring out the technical aspects of search, including how to implement faceted search, best first (recommended results), autocomplete, or even customizing the display of search results, are still mountains to climb.

Note that this book is not a technical how-to, nor does it contain step-by-step instructions for implementing these techniques. Morville and Callender say that designers must work with engineering teams to achieve more innovation in search, to take it past the magic black box. I wasn’t expecting a technical how-to, but I would have welcomed a few more down-to-earth references on implementation. (They do mention several search vendors.)

Interestingly, with autocomplete, the authors show an HTML Help display with the Index tab open. When you start typing, your keyword matches automatically read from the index entries you’ve added. I hadn’t considered how index and autocomplete might work together like this, but they do. (The index feature in a help authoring tool is probably the poor-man’s autocomplete.)

Finally, as a reader, I wanted to do some of my own “pearl growing” from Search Patterns. (Pearl growing is when you “find one good document, then mine its content and metadata for query terms and leads” (57)). There aren’t many sources for further reading mentioned in the book, but there is a short reading list here. Partly, I think the lack of references is because there aren’t many books written on search. I believe the list of search patterns Morville and Callender write about will be foundational to other books on search that follow.

Overall, Search Patterns: Design for Discovery is a thought-provoking book well worth reading. For technical writers working with large bodies of help content, we should be more innovative with our approach to search. Incorporating the ten design patterns for search is a great starting point. As such, I highly recommend this book — particularly to the technical communication community. We need to implement more of these techniques in our help systems.

Blog Sponsors

Organizing Help Content: Breaking Out of Topic-Based Hierarchies

Tom Johnson — Mon, 21 Mar 2011 14:20:45 +0000

At the upcoming STC Summit in Sacramento, I’m presenting a session titled Organizing Help Content: Breaking Out of Topic-Based Hierarchies. The title is a bit wordy. It’s basically information architecture applied to help content. Or even simpler, making help content findable. In this post, I’ll give you a sneak peak at what this presentation is all about.

One of the biggest challenges technical writers face is enabling users to find the right help topic amid hundreds of topics in a help system. Although the default approach in an online help file is to group the topics by task or topic in a table of contents (TOC), this method has its shortcomings. The traditional TOC only works well if each topic neatly fits into its own group, and if users are familiar with all the terminology.

In reality, topics frequently overlap with each other and can be grouped in myriad ways depending on the perspective. The terms used to describe the topics are also often unfamiliar to users. As a result, when users open the help to find information, they see an intimidating array of topics to look through, with names that don’t mean much.

In many cases, the problem isn’t a lack of information, but that users can’t find the information. How many times has a technical writer grumbled “read the manual” when a user asks a seemingly simple question. How do you make your help content more findable for users? How do you enable the user to find the exact topic he or she is looking for with little effort? That’s the main question I address in this presentation.

Alternative Organization Schemes

Of course you want to implement an organization scheme that will be most familiar to your users. But any group of users will have a wide variety of perspectives, backgrounds, experiences, needs, schemas, skill levels, locations, and learning preferences. How do you help all these different users find a specific topic in a sea of help content?

There are a variety of ways to organize help content. The traditional topic-based organization may not always be the best method.

Fortunately this problem isn’t unique or new. An entire discipline, information architecture, is focused on solving the problem of findability. Information architecture’s goal is to improve the user’s ability to find information in a complex system, whether that system is a website, blog, library, grocery store, or something else with a lot of items.

The organization scheme you choose should be one that makes sense not only for your users, but also for your product. Some products, such as shoes, naturally give rise to certain facets that you could use to organize the information (for example, mens/womens, sports, dress, kids, running, basketball, tennis, color, size, and so on).

With help systems, because the product is information, the facets aren’t always so apparent. But there are still plenty of organization schemes to draw upon. The following are fifteen organization schemes you could use as alternatives or supplements to the topic-based TOC.

Organizing by audience. Audience may be identified by their role, discipline, or department. The idea is the same: by identifying the audience, you can present the topics most relevant to that audience.

Organizing by skill level. Skill level can be divided into beginning and advanced tasks. Users new to the system can see a list of topics appropriate to beginners, while advanced users can see the more difficult topics.

Organizing by format. Format can be grouped by videos, quick references, manuals, online help, diagrams, tables, or other formats. This helps users looking for help material based on their learning preferences.

Organizing by popularity. Popularity can be established by most emailed, most blogged, most viewed, or most searched content. Users know that if a topic is popular for others, it’s probably relevant to their needs too.

Organizing by story. Stories might include persona-driven workflows described for various roles. In the stories, as you describe the actions the users take throughout the workflow or process, you can link to the tasks or topics that describe those actions. This story-driven structure can give users the big picture while providing navigation to each of the specific topics for more detail.

Organizing by chronology. A chronological organization might present topics linearly based on the workflow sequence users step through as they use the application. Alternatively, chronology-based organization could include information based on release date, or it could show the latest topics added to the help.

Organizing by problems/issues. Problems/issues could include frequent support requests or knowledge base articles. This problem/issue-based organization might contain titles highlighting broken functionality, bugs, or non-existent-but-frequently-asked-for features. Highlighting problems is the reverse of traditional documentation: rather than explaining the features, you’re calling out areas of broken/non-existent functionality.

Organizing by alphabetical order. Alphabetical ordering is usually an index, which is more commonly omitted in online help in favor of search. However, indexes can also provide users with a way of learning the official terms used in the help. Once they know the right terms, users can quickly move to the place in the help that provides those terms. Users are usually familiar with referring to indexes as a way to find content.

Organizing by screen. Screen-based organization schemes are usually not a best practice as the default, but depending on the application, this organization might help users stuck on a particular screen. In this system of organization, you list out all the tasks and topics that relate to each main screen. If you already have context-sensitive help, you probably already have screen-based topics.

Organizing by geographic location. Location refers to the geographical context of where the user is located. If some information might be specific to users in, for example, Africa, Japan, or South America (such as time zone notes, terminology, translated material, etc.), this organization scheme can help them locate what they need. Remember that usage of an application often varies based on one’s location. For example, the European Union has specific data privacy laws that might affect what information you can show in your application.

Organizing information in-context. In-context organization groups the help topic in the location where the user needs it. This is often referred to as context-sensitive help or on-screen help. Help icons in the interface, pop-up modals when a user opens a new screen, or embedded on-screen text can help users find information when they need it.

Organizing by related information. Related information contains a series of logically related links placed at the end or along the side of each topic. This method provides navigation directly within the topic, where users often spend the most time. To reduce cross-reference errors, related links might be grouped in relationship tables.

Organizing by next steps. Next steps is similar to related information, except that the next steps are more sequential and appear directly below the last paragraph of the topic. In a modular authoring, because each task is chunked from other tasks, many individual tasks may build on each other but be discrete topics. If each task is chunked as a discrete topic, search results may spread them out in a disconnected way. The next-steps link below each topic gives coherence to these discrete-but-connected topics.

Organizing by business goal. Many times users have general business goals in using an application. These goals don’t often translate into task or topic titles. For example, a user may want to do work in less time, or increase focus in meetings, or encourage communication among employees. Understanding your user’s goals is key to writing help in the first place, but we often forget these larger goals and get mired in more technical specifics. When you organize by goal, you can connect the larger business goals of the user to specific how-to tasks.

Organizing by level. Content can be divided into a series of learning levels, similar to the way video games or karate lessons move users from one level to the next, providing more advanced information as the levels increase. This organization scheme is more of a course-based organization pattern.

Many of these organization schemes can be leveraged by perhaps tagging the topic or assigning it to a specific category, and then calling all of those tags or categories. Additionally, these techniques can be layered on top of each other or used in various combinations.

Search

Invariably in discussing findability, many writers believe search will bail out the user when the TOC fails. Search does work well for known items – meaning, when the user knows the exact term he or she is looking for. But we often make erroneous assumptions about how search works in help systems simply because of our familiarity with Google.

Search algorithms. Google’s search works primarily through a system called Pagerank, where backlinks pointing to a site act as a vote of confidence for that site. The more votes, the higher the Pagerank. The pages with the highest Pagerank rise to the top of the search results.

Your help system probably doesn’t use Pagerank at all to determine search engine results and visibility. Every help authoring tool has its own search algorithm. For example, Flare ranks exact keyword matches highest, then keyword frequency, and then keyword location. WordPress gives more weight to more recently authored content. SharePoint has another system of rank for showing content.

You need to understand the search algorithm that is driving your search results. Once you understand your search algorithm, you can take appropriate steps to increase visibility of help topics in searches.

Terminology challenges. One major problem in optimizing for the right keywords is figuring out which keywords to use in the first place. Users may employ a variety of terms to refer to the same thing. Do you go with the official term the project team uses, or the term more familiar among users?

Some help authoring tools provide synonym features, in which you can equate the same term to provide similar results. Still, helping users locate topics when they don’t know the right terms is a major limitation of search. This is why organization schemes (which allow browsing) are still important.

Multiple algorithms. Another consideration is how to optimize your content when it is searchable within a larger infrastructure than just your help system. You may use a help authoring tool to create your content, but then store this content on a SharePoint infrastructure, or push it out to a website indexed by Google. In that case, users may use another search tool to find your help material. As a result, you have to optimize your site for two different search algorithms – the help’s search and the host’s search.

This can be tricky, because if you stacked a keyword with a lot of frequency in your help topic, optimizing for Flare, Google may penalize you for trying to game the system with overuse of this keyword. Google prefers that you repeat the keyword only about once every 100 words. Flare, on the other hand, won’t penalize you at all for repeating the same word 50 times.

Video and images. If you have video and image content, you need to take extra steps to ensure they appear in the search engine results. With video, about the only technique for ensuring search engine visibility (beyond the title) is to include a transcript below the video. You can also create video XML sitemaps to increase visibility on Google. With images, a lengthy caption can provide the text search engines need to read the content.

Intelligent search results. Ideally, you want the most popular help topics to gravitate higher in the search results, given that more people are looking for them. If you can weight your help topics with metadata other than keywords within the topic, this can improve your search results considerably.

Conclusion

Both browsing and searching are two fundamental ways users can locate the help topics they need. In this presentation, we’ll dive deeply into these two subjects with examples, challenging scenarios, and practical advice.

Blog Sponsors

Podcast: A Practical Guide to Information Architecture, with Donna Spencer

Tom Johnson — Fri, 18 Mar 2011 06:25:21 +0000

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.