For example, if you were trying to figure out how to schedule a projector on a calendar (to use a scenario from my treejack), where would think you would find it in the navigation tree? The user then navigates a series of labels to drill down into what he or she feels would be the location.

The method is called a “treejack” because Treejack is the name of the online tool from Optimal Workshop. (I’m sure there’s a more general term for the activity.)

While you could do this same usability test using a series of document folders (nested inside each other), the treejack shows you the unsuccessful paths that participants follow. What I’ve learned is that users have a lot of success when the labels are clear, but when you have vague navigation labels, such as “Managing Calendars,” where a lot of different tasks and topics could be grouped, success rates decline. Words that have subtle distinctions in meaning, such as scheduling versus reserving, also mislead users.

Here’s what a sample treejack output looks like. This is a graph from the Optimal Sort site:

This is what the results look like from a treejack. It shows you all the paths the users took. The green paths are the successful paths. Red paths are wrong paths. (Image from Optimal Sort.)

As I looked down the treejack paths to see where users clicked, I could see the logic that would lead a user to think the topic would be organized in that folder. For example, in my treejack, setting up and migrating calendars could have been grouped under Getting Started (it wasn’t), just as “turning off the old calendar,” a somewhat random miscellaneous topic, could have been grouped under FAQs (it wasn’t).

The problem with organizing help is that words have so many nuances and subtleties, they can be used in a lot of different ways. There are shades of meaning, words that accommodate multiple definitions. Using general terms such as “managing,” “viewing,” or “working with…” leads to a variety of topics that the folders could contain. Only when words have unmistakably singular meanings do users navigate to the right topic in the navigation tree almost every time.

Naming Conventions for Concepts and Topics

Another challenge users faced is how to distinguish between concepts and topics. In navigating the webhelp tree, it wasn’t clear to users if a topic was conceptual or task-based. In my content model, I start the first topic of each help folder with a conceptual topic, phrased as a gerund (“Managing the calendar”). I include the bulk of that folder’s conceptual information on that folder’s conceptual topic, and then let all sub-topics in that folder be tasks. I do this because I found that separating each concept out into its own help topic bloats the help and makes it seem unnecessarily complex.

For tasks, I use the imperative form (“Create a calendar,” “Approve a calendar”). I do this partly because I’ve found that the imperative form is much more search friendly. When searching for words, most users type active keywords that express what they want to do – for example, “create a new calendar.” Users rarely type “creating a new calendar” if they’re looking for information on how to create a calendar. However, the help engine in many webhelp files (such as Author-it) doesn’t interpret “create” and “creating” as the same form of the word. Only words that have matching stems (“edit” and “editing”) are treated as the same keyword.

Regardless, this distinction between gerunds for concepts and imperatives for tasks wasn’t clear to users. I could preface concept topics with “About,” perhaps. But as the landing page for the webhelp folder, my page usually matches the folder name. So unless I want “About” included in every help book title, I tend to omit it.

I’m curious to know if others have adopted a standard convention for distinguishing between task and concept topics. If so, I would be interested to hear what it is.

As always, the usability study opened up my eyes to a lot of the difficulties inherent in organizing help. There’s a reason why users often can’t find what they’re looking for, and it’s not just a matter of organization. It’s due to the slippery nature of language. Perhaps I need to think about ways to make language more exact, to shy away from words with vague meaning. I also need to provide more abundant cross-references in various topics to redirect users toward the “right” path.

Blog Sponsors

• 3Rabbitz book
• 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

Carol Barnum

The following is a guest post by Carol Barnum, a professor at Southern Polytechnic State University.

My university recently purchased a content management system (CMS) as part of a complete redo of our website, long overdue. A content management system is supposed to simplify the process of managing content on the web. Maybe some CMS systems do, but not the one chosen for my university.

As the person responsible for managing the content on the Usability Center’s website, I have been trying to rewrite the pages in my site, using the content management system. Despite two hours’ training on the system and a manual to help me figure out how to do the basic functions, the process has been anything but easy, intuitive, learnable, or efficient.

Shouldn’t a content management system be useful, usable, and desirable?

Useful, usable, desirable. As these are the basic tenets of usability, it would be logical to assume that a content management system should earn high points in each of these areas. But no — at least not the one I am forced to use.

A quick check of ratings of CMS brings up a website called TopTenReviews.

The top rated CMS systems (the one I’m using is not among them) rate the systems on the categories of

• features
• management
• security
• ease of use
• help and support.

Good and important categories, all.

The site’s explanation of the ease-of-use category for CMS is this:

When shopping for a CMS, whether you are a blogger, developer or designer, ease of use is probably the most desirable feature, second only to the actual publishing and performance components. If you aren’t able to immediately pick up a software application and start building your site, odds are it isn’t entirely user friendly. A CMS should enable both technical and non-technical users to create a truly comprehensive web presence with ease.

I like it. I just wish I liked the CMS system we are required to use. Because our CMS violates the principles of the “ease of use” category, and because this category is “the most desirable feature” of an effective CMS, I have to wonder whether the company did any usability testing on their product prior to, or even after, the launch. I can’t imagine that they did, or, if they did, that they tested with “real” users like me.

How do you determine the cost of a CMS?

You start with the cost to purchase the system, obviously. But then what?

If the cost of the product is a significant factor in the purchasing decision, and surely it must be, I wonder whether the cost of support to get the users to use the system was factored in as well.

I doubt my university took this cost into consideration. They should have, however, if my experience has been any indicator of the need for “customer support” to get me up and running.

Is Customer Support ready for the phone to ring?

At my university, customer support is basically one person—the university’s webmaster—who offered to help me if I got stuck anywhere in the process of making the conversion.

Little did he know, or could anticipate, the number of phone calls he would receive from me, often adding up to 4 or 5 calls in a single day. And calls every day for at least a week.

He was always patient, walking me through the steps to do—or undo—the content I had created.

Often, however, the method to undo something was more problematic to explain than to just fix the problem himself. Although the goal of the webmaster was to teach us to fish, rather than supplying us with fish (you know the metaphor, I presume), in the cases of the complex problems I created in my bumbling attempt to add new content, the webmaster determined, in more than one or two instances, that it would be easier for him to fix the problem, which he viewed as a one-time issue, rather than to teach me how to undo it and redo it myself.

I couldn’t have been the only person needing his help.

Does learnability improve after exposure?

Learnability is a usability principle, often hard to measure if you are testing only with first time users. But it’s vital to a system’s usability to support learning and relearning the system so that first time users get better quickly at navigating the system and so that repeat users (especially those who don’t use the system regularly) can retain their ability to use the system when they return.

As for the learnability of the system, I have to give our CMS a failing grade, or put the blame on me for failing to learn the system. Very little of what I did on one day was retained to the next day.

Because of the lack of learnability of the system, I dreaded opening up the software, as I knew I would be confused and frustrated about how to get up and going . . . every time. And if someone else had been working on my pages in the system and forgot to “check the page back in” when they signed off, then I couldn’t access the page until I had contacted the other person and asked him/her to check the page back in. You would think that when you logged off the system, it would check your work back in, but that didn’t happen.

Which page would need the most frequent updates?

After many days of “learning” the system, I was finally ready to do the last thing I wanted to do—create news and events pages. This task turned out to be the most difficult part of the process. First, creating these pages required a separate tutorial, as they were handled differently from other pages. Then, there was no easy or obvious way to create hotlinks to full stories or full articles I wanted to cite in the news/events. Then, the events page did not provide a way to include a picture, although the news page did. The list of issues is much longer, but suffice it to say that these were the least usable sections of the CMS. Yet, they are very likely to be the most frequently updated pages!

Calls to my webmaster brought a strange silence, which puzzled me, as he had been so responsive up to this point. I wouldn’t blame him if he decided not to pick up the phone when he saw me calling in, but it turns out that wasn’t the reason he had not called back. Rather, he and his boss had met to discuss the problem I and I’m sure many others were having with these pages. They determined that the system was not usable enough to allow for quick and easy updates on these pages. So these pages were put on hold (!) until a better system could be located and, I presume, purchased.

Why did we end up with such an unusable system?

For starters, no one asked the UX or content management folks at our university to review these systems and make recommendations. An expert review would have gone a long way to uncovering potential show-stopper problems. Usability testing with some target users would have exposed even more.

Now, with the site launch date pushed back, we may have to launch the site with incomplete information regarding news and events and no easy way to update this most time-sensitive information.

If I have learned by doing, it’s a lesson I hope will not have to be repeated by others getting ready to adopt a content management system.

As technical communicators and information designers, we may “own the content,” but if we don’t have a major stake in the decision of which content management system to adopt for our work, we may end up being “owned” by the system.

Fittingly, the TopTenReviews website ends its description of its reviews of the top CMS this way:

Our trademark side-by-side comparison can only compare the types of features offered by each CMS, but it doesn’t really address the power or usability of those features. It is in this way that each of these systems distinguishes itself from another. Ratings and check marks fail to really capture the full worth of any CMS; only each specific user can determine which is the “best” CMS. Every one of the systems reviewed here has a demo version that gives a more accurate picture of its capabilities.

Although I agree that the usability of the features of a system is best determined by users, I do not agree that this has to be done for “each specific user.” A quick study of five users in a particular subset of the user population will expose enough overlapping issues to identify quickly and easily whether users deem the system useful, usable, and most of all satisfying.

Carol Barnum is director of graduate studies in Information Design and Communication at Southern Polytechnic and director of the usability center. Her latest book is Usability Testing Essentials: Ready, Set…Test! (Morgan Kaufmann, 2011).

Blog Sponsors

• 3Rabbitz book
• 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

What is surprising about usability testing is how much valid information you can gather from so few subjects. With a handful of people unfamiliar with an app who are thoroughly trying to use it, you can find out most of the major problems with the app.

As the usability researcher asked participants to perform various tasks, eventually the participants forayed into the help. I was eagerly waiting for them to click the help icon, and when they did, I was a bit surprised what happened.

New Users Watch Videos, Skip Text

Only a few of the users read the help.  Most just watched the videos. Keep in mind that all of the users were brand new to the app.

With one user, he didn’t realize there were videos at all, as I had them buried in a side option called “screencasts.” Screencasts seemed something similar to screen sharing, he said, so he didn’t click there until later. When he did, he felt that the videos were just what he was looking for in help material.

Another user watched one of the videos twice, and after watching the video, was somewhat successful in completing a task (or at least a lot more successful than before — there were still challenges).

Given the popularity of the videos, I soon stuck all five of the videos right on the home page. Here’s the introductory video that most people watched:

(You can view the rest of the videos here, by the way.)

Intermediate Users Skip Videos, Scan Text

Despite the popularity of the videos, I found that videos appeal to different users in different contexts. For more tech savvy users just looking for an answer to a specific question, they were less likely to watch a video and more likely to search/scan the text for answers to their specific questions. Even so, these intermediate users were interested and encouraged by the videos available and sometimes watched one. One user saw the Youtube logo on the videos and immediately said, Cool.

I also noticed that when users did venture into the text, they tended to discover information they hadn’t anticipated. I found this fascinating. I’ve written before that search doesn’t allow you to discover what you aren’t aware of. Most users seemed pretty confident that they already knew how most of the app worked. When they actually read the help, though, there was a lot they didn’t know.

The Help Paradox

Almost invariably, users tried to figure the app out themselves from the interface first before resorting to the help — especially advanced users. In watching users play guessing games, proceed with trial-and-error mentality, and generally click everywhere trying to figure things out, I realized it would have been easier if they viewed several tutorials first before trying to complete the tasks.

One of my colleagues explained that at one company, they did usability testing that involved a laptop, mouse, keyboard, and a 40 page quick reference guide. Of about a dozen users, one person read the entire guide before doing the tests. When this user started on the tests, he moved right through the tasks quickly.

We know this is probably true of software usage. It’s more efficient to read up on how to use the application first before diving into it. Despite this, most of us will resist help until the last resort, and turn to it only when we get stuck. We’ll struggle and struggle and struggle and only after spending 30 minutes or more guessing, then we’ll read the instructions for 5 minutes to figure it out.

One reason, my colleague explained, is that we need a certain context before information in a help file or video becomes relevant. Without having seen the app and wondered, for example, about the use of tags, a video called “About Tags” doesn’t become relevant.

Perhaps on-screen text that contains snippets of instruction, with links to more information in the help, would be a way to move people from the interface into the help.

What’s the Value of Writing?

Overall, if there’s one thing I’ve learned from watching users, it’s that they prefer video tutorials to text — especially new users. Having come to this conclusion about video, it makes me wonder whether I should be focusing more on video than writing. Maybe I have to reevaluate the importance of written communication? My blog is called, after all, I’d rather be writing. Shouldn’t I change it to something like, I’d rather be creating videos?

One limitation of video is that it’s harder to dive into complexity and sophistication. In writing, you can explain concepts, explore ramifications, analyze, assess, and synthesize all you want. Like in this blog post, for example. I’m doing all kinds of little mental explorations. In a scripted video, however, it’s much harder to do explore a topic in a structured, logical, interesting way. Perhaps videos force you to stick with the basics.

I haven’t tried doing more “thinking” in videos. As a test, I recorded the following short video last night:

As you can see, it’s somewhat rambling and meandering. But would you rather watch the video or read this post? I tried to essentially cover the same material.

Testing Content

My biggest takeaway from usability testing is that it opened up my eyes to the need for testing — not just testing design and functionality, but testing content as well. At Confab, I had breakfast with one of the presenters, Angela Colter, who was presenting on testing content. We test interfaces with all kinds of users, but if people are really interested in content, if that’s what they go to a site for, shouldn’t we be testing content instead? Shouldn’t content be the primary thing we test for, and then design?

I missed Angela’s presentation, but as I recall, she said something to the effect that when they tested content for a group of users, they found the content didn’t answer many of the users’ questions. I’d love to pull about 10 users into a room and have them review the content of a website or help system, based on various goals and questions they have. I don’t know why I haven’t done this before. Now I realize that not doing it for content has the same effect as not doing it for interfaces — you may think it’s fine, but if you’re the one who designed/wrote it, you become blind to its failures.

While the interaction designers’ pride pretty much crumbled while watching users try to use the interface, I imagine technical writers would feel the same way watching a usability test for their help. I have no doubt that users would experience as much or more frustration looking in the help file for various questions and answers. Perhaps this is why we tend to avoid usability testing for our help systems — the reality of how much help fails would be too much burden for us to bear. The results would force us to reassess and reapproach how we do help. Based on my experiences in watching users explore help, videos and on-screen help will now be my top priority.

Blog Sponsors

• 3Rabbitz book
• 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 talked with the lead customer, and he hadn’t given much thought about help. I talked with the project manager, a quality assurance engineer, and a developer. The PM didn’t know what kind of help the app needed either. The QA engineer thought it needed a few pages of help; a developer said it needed maybe 150 pages. After floundering around for about a week, I realized I was shooting in the dark.

I asked the interaction designer for some names of users I could contact, and he supplied me a name. After talking on the phone with the user for 5 minutes, I knew that my entire previous direction was wrong. They didn’t need a robust wiki. “If you created a help system,” the user said, “I’m really not sure anyone would use it. We all know the process so well here. The only thing we may need help with is to find where something is in the interface.”

This lightened my load incredibly. The way our department often works, we create applications so customized to a specific business process that only users within that business department understand how the application will actually be used. Trying to penetrate this business process requires learning an entirely new culture and knowledge base. But often it isn’t necessary to document this business knowledge — it all depends.

When I started the project, I was fixed on creating documentation that explained not only the how, but the why and who and where and other context. Now I’m basically creating a slideshow of screenshots with some callouts indicating where things are in the interface. I figure it will save me about 2 months of work and will actually be looked at by the users — all because of a brief phone call with users. I realized that I can learn more from talking with users for 5 minutes than I can from 2 weeks of project meetings. Why is it that I don’t talk to users more frequently?

photo from Flickr

Blog Sponsors

• 3Rabbitz book
• 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

• 3Rabbitz book
• 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 what my friend explained: project members see the usability deliverables, but they don’t see the tech comm deliverables. When the usability experts create wireframes or prototypes, the whole team meticulously reviews the designs. But when a technical communicator creates a 200 page user manual, a smooth-looking online help, some video tutorials and other deliverables, almost no one sees them except the person assigned to review them. As a result, people see and appreciate the usability specialist / interaction designer’s work, but they continue to undervalue the technical communicator’s work.

Blog Sponsors

• 3Rabbitz book
• 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

Oh, that field? he said. I never really understood that feature, so I left it alone.

The user wasn’t a novice. He used this application several hours a day, if not more. How could he be so comfortable leaving alone a feature that could be integral to his workflow, which could save him hours of time and make his life easier? I could hardly believe it.

Knowledge Intake Thresholds

As I related the feedback to my colleagues, they noted how we often do the same thing with applications we use. For example, I use iTunes to download podcasts, create playlists, and sync the audio to my iPod. I know iTunes can do a whole lot more, such as create smart playlists based on the music I most often play, but I’m not interested in that. I don’t quite know how to set it up, and frankly I’m happy with my current level of understanding.

Photoshop is another example. I can get by in Photoshop all right. Only when I absolutely have to learn something, such as layer masks, do I start pushing my knowledge deeper by going into the help.

I often give one-on-one WordPress training. This past Saturday I scheduled a two-hour call with someone implementing a wootheme. At about an hour and a half into the call, I could tell the person’s brain was saturated. I had hit the threshold on her knowledge intake for the day.

My own knowledge intake threshold maxes out at about an hour. This is why classes at schools aren’t longer than 50 minutes. After an hour, the amount of new knowledge you can continue to absorb goes downhill.

Long-Term Learning

As technical writers, it’s hard to feel empathy for users when they refuse to learn. It’s all in the manual, if they would just read it, we often say. But we have to remember that we spend months ramping up on a software application — users don’t. Our first experience of the application is usually in a development environment where features are only half-coded. As time passes and new features are developed, and we attend project meeting after meeting, we slowly add the new knowledge to what we’ve already learned. After six months of gradual ramping up, we’re experts on the application. We then try to teach users to be experts in a day, or more realistically, in about 20 minutes.

Do you see the problem? We get six months to learn little by little, being paid handsomely to do so. The user gets 20 minutes and must often take time out of his or her schedule to do it. It’s no wonder the user doesn’t naturally move into the expert knowledge range.

A more practical way to learn new software is to approach it bit by bit. An hour a day over the course of a month can be more helpful than a crash course. But how do you keep the user learning every day or week?

Strategies to Keep the User Learning

I’ve seen at least four methods to help users keep learning an application:

• Daily tips. Some applications show a daily tip in an attempt to increase your knowledge little by little. However, these tips are often as successful as ad pop-ups on websites.
• Regular newsletters. Some companies provide a regular newsletter about their products. For example, TechSmith provides a periodic newsletter that usually has a couple of tips for using Camtasia Studio and Snagit. I scan this newsletter and will watch a video tutorial on a feature I’m unfamiliar with.
• Product blogs. Some products are robust enough that the company has an entire blog focused on the application. Microsoft Office is one example.
• Interface tips. When there’s a new feature added to the application, the interface often highlights what’s new through a little bubble caption. This is common in Gmail.

Encouraging Desire

Besides these methods, I’m not sure what you can do to help users continue to increase their knowledge of an application. The problem is that even if you provide the means for advanced learning, whether through tips, newsletters, blogs, or interface notes; users already familiar in performing a core set of tasks are inclined to remain in their comfort zone.

In their minds, they already know the application. Or they know it well enough to get by. As with most things in life, the problem in helping users learn isn’t so much strategy as awareness and desire. They often don’t know what they’re missing. So they don’t care about missing it.

Blog Sponsors

• 3Rabbitz book
• 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 project I’m working on is critical, but it has only about 3 to 4 users, most of whom are already familiar the application. One of the users even drives the design. The manual I’m writing, which is nearly 200 pages, is mostly a safety measure for business continuity planning. I don’t expect anyone will ever read it.

It’s a project I managed to procrastinate for months, working on other projects, even outside the scope of my regular assignments. The main deterrent, I believe, was my perception that no one needed the manual. The users seemed to be getting along fine without it.

And so as the year ticked to a close, instead of learning more about Mediawiki and screencasting and After Effects, I spent my time updating a 200-page manual that I don’t think anyone will ever read. It will be printed out, three-hole punched, and placed in a binder to collect dust on a shelf.

The idea that “no one reads the manual” is certainly not new. But despite this accepted truism, most of us don’t entirely believe it. I think we always have an imagined audience in mind when we write. I often imagine a confused user searching for questions in the help, or a new employee printing out the manual and reading it, making notes in the margins and going step by step through tasks a manager marked. I imagine a user familiar with an application suddenly dumbfounded on a specific screen, clicking help and scanning for answers.

I need this fantasy about the way my manuals are used because without it, there’s no motivation to write.

Charles Hurwitz, a technical writer in Israel, recently had an experience that confirmed the idea that no one reads the help. Charles writes,

Early on in my tech writer career I had the eye-opening experience of walking into an engineer’s office and seeing a multi-volume set documentation on his bookshelf still covered in shrink wrap. I thought to myself that after all the months work on the manuals he should at least have the common human decency to take off the shrink wrap. It’s like buy a painting and hanging it with the painted side facing the wall. Since then when people ask me what I do I tell them I write books that nobody reads. (It’s Official–Nobody Reads the Manual)

In his post, Charles also references a survey by Gadget Helpline that found 64% of men and 24% of women don’t read the manual before calling support (Gadget Problems Divide the Sexes).

It’s not just a matter of putting the manual gently aside. Users actually despise long manuals. Ron Jeffries writes, “Your customer hates big manuals. He has shelves and boxes full of them just like you do.” (Manuals in Extreme Programming).

I believe the discomfort of reading a 200-page manual compares with the pain a dentist administers when removing a tooth, or the frustration an IRS writer creates when he or she makes a long, complicated tax booklet users will have to figure out.

Joel Spolsky, a programmer and web entrepreneur, says,

Even if they have the manual, frankly, they are simply not going to read it unless they absolutely have no other choice. With very few exceptions, users will not cuddle up with your manual and read it through before they begin to use your software. In general, your users are trying to get something done, and they see reading the manual as a waste of time, or at the very least, as a distraction that keeps them from getting their task done. (Designing for People Who Have Better Things To Do With Their Lives)

When I interviewed Mike Hughes several months ago for a podcast, he said the conclusion of most studies about how people use help is that they don’t actually use help.

Some writers still find hope in the rare instances when users will consult the help. Sheila Fahey of Cherryleaf explains: “When things go wrong and it matters to the user, they will seek assistance. They will look for the easiest way to get to the information they need to do the task. If this is the manual, then they will use it.” (If no-one reads the manual, then why bother?)

Looking at help this way is seeing the help as an emergency kit in a car. People won’t normally need the emergency kit, but when you’re stranded on the side of the road in the middle of nowhere and hungry and cold, you will use it. You will break it out of the plastic wrap and actually use it.

Flipping Sides

Not many writers consider the positive aspects of users not reading the manual. If you do a lousy job on the manual, or if some SME discovers typos and inaccuracies, you can just laugh it off by saying no one really reads the manual anyway.

But consider the opposite scenario where everyone reads the manual. Is this a scenario you want? No. Because if everyone has to read the manual to figure out the product, it means the product is so unintuitive and user hostile it’s probably going to tank on the market and you’ll soon be out of a job anyway.

Also, if so many people are consulting the help, you probably aren’t contributing enough on the design/usability side of your technical writing role. Remember that you’re part of a team building a solution to a problem. You want the user interface to be simple and intuitive enough to not require a manual. So if only 10 percent have to consult the manual to figure out the product, that’s a good thing.

No One Knows

Knowing exactly how often help is used and by whom is hard to measure. If your help is entirely online, you can measure basic hits easily enough. But if it’s distributed in print, you can’t really know.

For example, on Christmas day, my sister-in-law was putting together a fish tank and filter for her boyfriend. (By the way, a Betta fish is a cool present to give someone.) Installing the pump and filter was confusing. Was the pump supposed to be above or below the waterline? Was it supposed to be making that humming noise?

At one point, just as she and other family members were getting frustrated, one person jeered, I can’t figure it out, and there’s no manual at all!

More people get frustrated assembling things on Christmas than on any other day of the entire year. It’s a day manuals are both cursed and blessed. But in this scenario, no doubt the company that created the filter was unaware of the frustrated user stuck without a manual. We’re often in the same position of ignorance about our users.

If you think about it, the technical writer is in an unusual role. Users hate the presence of manuals as much as they hate missing manuals. They despise lack of detail yet curse length. If no one reads the help, your position lacks value. If everyone reads the help, you’re on a sinking ship. Ideally, you want the user interface to be simple enough not to need help. But the more you contribute to this user interface simplicity, the less you’re needed.

Conclusion

As the year closes and the project manager is off skiing and the developers are playing video games and the quality assurance engineer is organizing his closet, I’m pounding out the last topics of a 200-page manual that I will soon deliver to a group of users who will smile and thank me for the manual, knowing they don’t have to read it or critique it anymore, but can just put it proudly on their shelf, or maybe even in a storage box.

If I find out, through feedback or on-site visits or other means, that they don’t ever read the manual, that they have never actually opened the manual beyond the table of contents, that’s okay. I hope they never have to.

Blog Sponsors

• 3Rabbitz book
• 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

Reading Instincts

A while ago I moved The Content Wrangler to WordPress and used a Massive News theme as a starting point. I liked the way the Massive News theme looked, but something kept bugging me about it. The text seemed tiny, and the layout was busy. But Scott didn’t complain about this, so I ignored it.

Massive News theme -- the text of the posts isn't very readable, and the layout is busy

A couple of weeks after the launch, I found myself constantly pressing Ctrl++ to increase the font size so that I could read the posts. Increasing the font size reminded me of another site I read regularly: Lorelle.WordPress.com. Lorelle’s font and leading (space between lines) always struck me as large and spacious, but very readable. I could lean back and comfortably read the content.

Lorelle.wordpress.com -- you can lean back and comfortably read the content

I finally asked Scott if he wanted me to increase the font size a bit and change the layout from three columns to two. He said yes. I also increased the leading and narrowed the main column width.

Now when I visit Scott’s site, my eyes focus on the text in the main column, and I can read it without strain.

Making the content more readable on The Content Wrangler

In this post, I focus on the following ten elements for making your blog more readable: font size, line height, line length, typeface, background, subheadings, paragraphs, white space, graphics, and invisibility.

Font Size

Smashing Magazine’s study on typography recommends using “a range between 12 and 14 pixels” size for body copy. Jakob Nielsen recommends using at least 10 point, with 12 point for senior citizens. Johno on ILoveTypography.com says,

Don’t set body text below 10 or 12px and, if possible, make it bigger. Remember, what’s legible on your 65 inch High Definition Plasma monitor, might not be so on a 15 inch MacBook. If in doubt, make it bigger. The body text on ILT is set at 16px.

Here’s a screenshot of the 16px font on I Love Typography:

16px font size on I Love Typography

(The smaller text in the graphic is added deliberately to show how difficult it can be to read smaller text.)

How big your font looks depends somewhat on the typeface, but you get the picture: make your font largish. If you look at sites like Techcrunch or Copyblogger, the font size is readable at a distance. You don’t have to squint or strain.

Although I don’t plan to address headlines much, Smashing Magazine recommends “a range between 18 and 29 pixels” for your headlines.

To modify your font, look for the font-size property in your stylesheet.

Line Height

Line height, or the distance between lines, also affects readability. Smashing Magazine recommends something rather formulaic: “Line height (in pixels) ÷ body copy font size (in pixels) = 1.48.” You may have to do a little algebra to figure this out, but if your font size is 13px, your line height should be about 19 pixels in order to equal 1.48.

Mark Boulton adds more reasoning to line height:

A simple rule is your leading should be wider than your word spacing. This is because when the balance is correct, your eye will move along the line instead of down the lines.

When you see a site that has line height (leading) narrower than the word spacing, it does disrupt your visual flow across the page. To change your line height, look for the line-height property in your stylesheet.

Line Length

Line length refers to the column width of your paragraphs. Mark Boulton says that “a general good rule of thumb is 2–3 alphabets in length, or 52–78 characters (including spaces). ” Smashing Magazine also notes that classic studies in typography recommend a width between 55 and 75 characters.

This makes sense for readability, because newspapers have narrow columns. Narrow columns make it easier to read (for a good example, check out the Washington Post). However, despite the ideal of 55 to 75 characters in length, Smashing Magazine found that popular sites have an average width of about 89 characters. This is due, I believe, to the need to fit a 600 pixel wide image or HD video into a post.

To adjust your line length, look at the div tag that starts your main content column. Usually there’s a width property for this div tag. Just decrease it appropriately.

Typeface

The Smashing Magazine study found the most common typefaces for body copy on popular sites to be “Arial (28%), Verdana (20%) and Lucida Grande (10%).” About 60 percent of the popular sites they analyzed use sans-serif for the body copy. For sites using serif fonts, Georgia is the most common.

It’s common to use a contrasting font for headers, with Georgia and Arial being the most common. Basically, a good typeface doesn’t draw attention to itself. Stick with the norms.

Background

Smashing Magazine says that invariably, all websites they studied had light backgrounds. You may run across a dark website with white font, and in some cases the combination may be readable. But mostly, popular sites have light backgrounds. Johno on I Love Typography.com adds:

Personally I dislike reading long stretches of reversed out text (i.e. light text on a dark background); how often do we see books set like this? It may well be appropriate for shorter stretches of text on-screen, but I find it very tiring to read for any length of time.

If you do have contrasting colors, Johno recommends grayscaling the colors to see if it is still readable. Also note that sites with dark backgrounds are typically seen as entertainment sites, so unless you want that connotation, stick with light background. With a light background, people reading your site at work won’t be embarrassed.

Subheadings

Subheadings refresh the reader’s eye, allowing readers to quickly skim and see what your post contains. Here’s a good example of subheadings from CopyBlogger:

Subheadings break up long chunks of text and make the content more readable

CopyBlogger Sonia Simone explains,

Blog and newsletter readers want meaty content, something that’s worth the time they take to read it.

But piling a mountain of words in front of readers doesn’t work too well. A page of solid black text looks like, well, work.

So in front of your 20-foot tall stack of words, you put a series of steps. You break your content into manageable pieces, separated by mini headlines or subheads. Each subhead is a step up the staircase.

Each time your reader comes to another subhead, she thinks, “Well, I’ll just read to that next little headline there.” Then she reads another section, and another.

Subheads break your copy into little potato-chip tasty bites. And we all know how hard it is to stop at just one potato chip.

In other words, subheadings help you get around a problem with blogs: readers want substantial content but dislike reading large stretches of text. The subheading breaks up the text and allows the reader to move step by step through your content. Subheadings also facilitate skimming. Where possible, add a subheading every several paragraphs. It goes without saying that you should keep your subheadings parallel. I also recommend making your subheadings a different color for contrast.

Paragraphs

Have you ever landed on a web page that looks like the writer’s Enter key was broken? Long chunks of text without paragraph breaks are extremely unreadable. If you’re accustomed to academic styles, you may have been taught that a good size paragraph covers 2/3 of the page. This is what a literature professor once explained to me, because he wanted to see me “develop my points.”

However, online reading experiences tire people out much more quickly than print. Content isn’t double-spaced as it is in academic essays. Newspapers often break paragraphs every couple of sentences just to make it easier to read. In the Sonia Simone blockquote above, you can see how generous she is with new paragraphs.

White Space

Apple has increased the appeal of simplicity in design. Simplicity often involves removing rather than adding. When you simplify or declutter a blog, you often increase the amount of white space. One site that shows good use of white space is Z-oc.com.

Good use of white space makes your site both breathable and readable.

White space has an interesting paradox: The absence of graphics and text plays a significant role in increasing comprehension of the content. The absence of content is what draws the eye towards content. The negative blank space (which possesses nothing) creates a sense of sophistication and elegance. The sense of simplicity and absence of graphics and text is what contributes toward a richer, deeper and more complex artistic expression.

Donald Peterson explains,

In western culture we associate uncluttered spaces with good taste, refinement and affluence. It is also more restful to the eye to read or view items that have a generous amount of white space surrounding them. That is why museums always use broad white walls as a backdrop for paintings on display.

On the Web, white space is essential when the viewer is required to read large amounts of content. Generous margins and clear simple layouts make it easier for the eye to work. Cluttered layouts tire the eye quickly and hinder clarity. Also, just as in advertising, uncluttered layouts convey a sense of good taste and refinement.

You can increase white space in a variety of ways — increasing the padding in your columns and around images, decluttering your banner area, increasing the leading and font size, increasing the space between the body and sidebar, increasing margins between paragraphs, and adding space in other places.

Graphics

One of the common documentation formats I create is the quick reference guide. Quick reference guides provide one or two page instructions in a brief, concise format. I often look through magazines to get ideas for layouts. After creating quick reference guides for several years, I’ve concluded that adding a strong graphic to the quick reference guide significantly increased the appeal of the guide. However creative I could be with text layout, it is the image, especially a diagram, that makes the quick reference guide attractive.

In web design, images also play a key role in increasing appeal. An image can break up what might otherwise be a long essay. Images provide concrete examples to communicate what you’re saying. Images provide balance and eye candy to give variety to the reader’s eye. For example, I’ve tried to add images to this rather lengthy post, both to break up the text and provide examples.

Invisibility

My final point about readability is to keep your design invisible. You want the reader to focus on the content, not the design around the content. Guilherme Zühlke O’Connor explains,

While the purpose of art is to draw the attention to itself, to make the viewer forget the world for a while and concentrate on it, the purpose of design is just to sit there, without being noticed, while the viewer pays attention to something else.

Design is a support area, the designer’s job is to leverage someone else’s message and not to draw attention to his own work. Design is an area for team players, for group work. And design must take the user into account.

Good design doesn’t jump out at you. It makes the content jump out at you. You find yourself disregarding the design instead of focusing on it.

Conclusion

Although there are other ways to increase your blog’s readability, these are the most important elements to consider:

• font size
• line height
• line length
• typeface
• background
• subheadings
• paragraphs
• white space
• graphics
• invisibility

Blog Sponsors

• 3Rabbitz book
• 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

Theresa explains,

The traditional way of providing content in a context-sensitive help link has been to link to the procedure for the page. Not only can this be limiting for the user, but it also can be limiting for the writer and the company. By picking a specific procedure, the writer is guessing at what the user wants to do on the page. While usability testing would give us more insight, if we don’t have this option, we can make the context sensitive help link more applicable to more people by providing a link to both a How topic and the Why, When, and Who information.

If we don’t provide additional options in the context-sensitive help, we are, in effect, making it more difficult for users to have their questions answered. By forcing them to browse and search through a help system they may be unfamiliar with, and by not highlighting the various options available for that screen, window, or page, we limit the options for the user and perhaps contribute to higher support costs.

To provide a variety of links to the user, you can manually list them, which is tedious and prone to error. Or you can use something like Related Links or  Concept Links, which shows a list of links in a hard-to-see pop-up. However, there’s also another option: relationship tables. I’m new to this concept, but my initial experience with them has gotten me excited.

Relationship tables come from the world of DITA, but Madcap now gives you the ability to create them in Flare 5. From one table you can manage all the related links for your entire project. Although you can define exclusions and inclusions, basically links in the same row are part of a family, and that family can appear on each topic that you embed the relationship table on.

For example, in the following table, I have four columns.

After inserting a relationship table proxy into your Flare masterpage, and setting each link type as a “Family” link type, here’s what automatically shows up on each page.

On all the plugins pages, you’ll see the following:

Related Concepts

• About Plugins

Related Tasks

• Installing Plugins
• Editing Plugins
• Removing Plugins

Reference Reference

• Lists of Recommended Plugins

Note: If you’re viewing the Installing Plugins page, the Installing Plugins doesn’t appear in the list of links. (The same smart exclusion isn’t true of Flare’s Concept links.)

On the themes pages, the list of related links would look like this:

Related Concepts

• About Themes
• Theme Hierarchy
• Columns in Themes

Related Tasks

• Installing Themes
• Modifying Theme Stylesheets
• Customizing Theme Categories

Reference Topics

• Best Magazine Themes

The cool thing is that you can manage all your related links from this one table. You can also specify more details with relationship tables, such as having links only appear on certain pages and targets, and applying conditional tags. But the basic concept is simple.

I’ve even styled my relationship table links so that they float in a narrow side column to the right of the main topic. My approach for context-sensitive help is to list the most common task for the page in the main column, and then provide the list of related links in a sidebar on the right. If the user clicks the help and says, no, that’s not what I want, he or she won’t need to scroll down to the end to see related topics.

For more information on relationship tables in Flare, see About Relationship Tables in Flare’s help.

Blog Sponsors

• 3Rabbitz book
• 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