Sarah O’Keefe (@sarahokeefe) of Palimpsest tweeted today that according to a webinar she was attending by Ellis Pratt (of Cherryleaf, @ellispratt), nine times more people visit help websites than traditional help systems. This really got me thinking throughout the rest of the day.

If It Looks Like a Help System…

Why would people be nine times more willing to go to a website than an online help system? Since this may have been explained in the webinar but all I have regarding it is Sarah’s tweet, my initial guess is that people tend to think a help system is static and easily outdated (they don’t know about the Agile technical writer?), while a website is fresh and frequently updated. Whether those things are actually true isn’t as important as the fact that the audience perceives them as being true.

This led me to thinking that all is not lost for help authoring tools, though. I’m sure with some effort, I could make an online help system look like a website. Of course, it would take WebHelp to do that convincingly, so this approach may not be possible for all software products.

The first step would be to use some term other than Help. Next, get rid of that traditional side pane, one of the dead giveaways that you’re looking at a help system. RoboHelp and Flare, and maybe others, enable this.

Part of the problem here, though, is that the side pane contains much of the navigation. So it would take putting on the Web designer hat to work out the best way to offer navigation through the help.

› Continue reading…

Bookmark It

Hide Sites

I’m becoming increasingly convinced that a help system is the dead last thing that people use for assistance. (Sometimes, though, if customer support is sufficiently lacking, that’s the dead last thing.) No matter how much we optimize help systems to make the information accessible, we just may never overcome the bad reputation that online help has.

I’m more and more persuaded that quick reference guides and videos are preferred formats. Brainwashed by Tom Johnson? Maybe. But users of an application where I’ve provided these materials have provided feedback about them, and not much about the online help. If something’s not right with the QRGs or videos, people are noticing much sooner than if something isn’t right with the help.

Don’t get me wrong—help has its place. But I think its place is as an information repository that acts as a backup if the quick reference guides and videos don’t do the job.

But how to get people to go to the QRGs and videos first? Easiest is probably from the help system. But if people don’t go to the help, how will they find these materials?

› Continue reading…

Bookmark It

Hide Sites

I’ve got some bad news if you’re a die-hard RoboHelper. No, Adobe isn’t shelving RoboHelp, nor are they reintroducing kadov tags.

I’m being switched to Flare.

Once you’ve come out of cardiac arrest, let me explain.

I’ve said before that I’m not married to any particular tool; I don’t carry around a sign or a mentality that says, “If you don’t use RoboHelp, go jump off a bridge!” The whole HAT wars thing is a bit tiresome. I don’t have any particular feeling toward Adobe, though I’ve heard their customer support leaves something to be desired. And MadCap’s idea of what qualifies as a separate software application bothers me. But they haven’t committed some personal offense against me. (Though back when I evaluated Flare v1 and received a call from MadCap, the person sounded a little offended that I declined to purchase it.)

So since I don’t have some conflict of interest, it comes down to the tools themselves—and what our team is doing. We just hired two new User Education team members, and one is Flare MVP Paul Pehrson, AKA DocGuy. He sits next to me, and in a discussion about Flare that he and another colleague had the other day, let me tell you that the dude knows what he’s talking about. He told me he hasn’t used RoboHelp. The other new guy has used both and prefers Flare. And Tom Johnson is already using it.

› Continue reading…

Bookmark It

Hide Sites

RoboHelp has been a bit infamous for bad Word output. That’s a reason one of my colleagues picked Flare (he also got a free copy, so that helped)—Flare smoothly moves CSS styles over to styles in Word that preserve the appearance.

I’ve been trying to figure out how to get my default list styles in a Word template to align the way I want so when I output from RoboHelp to Word, they’ll automatically take on that alignment. (Come to find out that there’s no way to tweak the list styles for “Normal.” Lameness.)

I know the Word-to-RH import and RH-to-Word output have been improved in RH8, but that doesn’t help me right now.

Anyway, while I was messing with this list problem, my eyes opened and saw the reason for bad Word output.

› Continue reading…

Bookmark It

Hide Sites

Yesterday, I called a user of the application I talked about on Friday to ask about his use of the documentation. It’s kind of refreshing to find out how people actually use the documentation. I found out that the dilemma I had on Friday really wasn’t a big problem, at least for this particular guy.

I had done a questionnaire among the user group, and some of them responded. The results suggested that people generally used the documentation more as they first began using the system, and as they got to know it and know how to complete the tasks, they referred to the documentation less and less until the frequency was about only once a month.

The documentation consists of (1) a context-sensitive help system, which provides information about the specific screens, and (2) a manual that explains how to complete certain tasks that may take the user through a number of screens. This particular user, whom I’ll call George, says he tends to use the help system for quick reference. He pops the help open, looks for the answer to his question and performs a text search if necessary, and then goes back to the app.

I had him open the manual, which is accessible in the app as a PDF, because in moving his office a few times, he had lost his hard copy. I pointed out the note boxes and asked him to tell me what he thought the difference was between the information in the boxes and the information in the main flow of the pages that went along with the task instructions. George really didn’t know and guessed that they were summaries of the information in the main column.

They’re just notes—things that aren’t essential but may be helpful. So I’ve got some work to do there to make it clear what type of content is in the boxes. I suppose that’s where “document conventions” sections come from, but I’d rather find a way, such as using icons and short headings, to make those kinds of things more apparent. Besides, how many people actually read introductions?

› Continue reading…

Bookmark It

Hide Sites

I’ve been using the FlashHelp format for my help systems for the last few years. FlashHelp is a variant of WebHelp, basically running on the same logic. Instead of being made up of static images, though, the skin consists of Flash movies. The idea is to have a spiffy-looking help system that will look and behave the same across operating systems and Web browsers.

I use this format for those benefits, and actually, when I first started using RoboHelp, a related project had a FlashHelp system. I used that project to familiarize myself with RoboHelp in general, so I figured I’d just use FlashHelp too. I had attended a couple of workshops on Flash in college, so I knew some basics and could get into the .fla files to make edits to them and customize the skins.

However, after using this format for nearly four years, I’ve had thoughts of using WebHelp instead.

Security Warning

Our Web apps run in secure environments, and when a FlashHelp system is called in IE, we get the nonsecure items warning. With Captivate demos, I’ve tracked this down to the http references in the Flash <object> tags. I’m in the middle of trying it out with the Flash files, but there are a lot of them with these tags, and I’m waiting to see the results. But to have to click “Yes” every time I want to see the help system is annoying, and I can’t see that IE actually blocks anything whether we click Yes or No. I can do without that warning, and I’m sure the users can as well.

Load Time

It takes several seconds for the entire FlashHelp skin to load. WebHelp comes up in just over a second. Especially when they’re in the middle of a task and pressed for time, people don’t want to wait for a fancy-schmancy Flash movie to load before they can start getting answers.

Lack of Support

In RoboHelp 8, the WebHelp search was improved. That improvment apparently didn’t extend to FlashHelp even though it’s WebHelp based. It seems that hardly any effort is spared for FlashHelp improvements, probably because the FlashHelp forum on the Adobe site has hundreds fewer threads than many of the other forums, suggesting that not many help authors use the format, so it’s not worth the expense. That in turn probably discourages people from using it, and so forth.

I hesitate on this point only because if I abandon FlashHelp, I probably won’t keep up on it, so I may not be able to help anyone who comes to the forum looking for assistance with that format. There aren’t many people who respond to FlashHelp questions, and I’d like to still be able to do it. But it’s not a good reason to keep a format that I don’t think is benefiting my users.

Lack of Know-How

I mentioned that I know some basics of editing Flash files. But that’s as far as it goes. I don’t know a thing about ActionScript. Not being a Flash developer, I can’t expand the functionality of the help systems if I’d like to—I can only edit what’s there. If there are bugs, they aren’t likely to get fixed (see the previous point), and I probably can’t fix them myself. I can discover a workaround here and there, but I can’t get into the guts of things and fix them, I’m letting some time go to waste.

I’m not sure when I’ll take the plunge and switch formats. Fortunately, since FlashHelp is a WebHelp variant, making the switch wouldn’t affect the help calls in the applications. I may have to get to the point where I have some extra time, but that looks like it’s not going to happen right away, which is a good thing.

Bookmark It

Hide Sites

Last week, I was writing some help and, in the process, was asking some “what ifs,” more particularly, “What if a user has things set up this way and then wants to change it this certain way?” It was something I thought the application would allow, but when I was writing the help, I tried to do it and couldn’t.

I talked to the interaction designer and a SME, and they said that users’ situations would rarely if ever call for the kind of change I was trying to document. I’m glad the system supports the process properly. I’m just glad I asked the question and experimented before I stuck my foot in my mouth.

Today, the designer showed me his prototype of the screen I was writing about. The drop-down box where this certain change wasn’t allowed now had a little question mark icon. When he moused over it, alt text appeared that explained that this certain change couldn’t be made. The designer figured that if I had asked the question, users may ask it too.

I like offering a part of that perspective—coming to the interface fresh, thinking through various situations, and asking “what if?” Some of those what ifs may not apply, but at least if the question is asked, it gets people thinking.

Bookmark It

Hide Sites

In a group discussion earlier this week with some others in the Intermountain STC chapter, we talked about task-oriented vs. feature-oriented documentation. One of the people there mentioned that he rewrote one help system to get it that way. “Developers do it all the time,” he said, meaning redoing something after they realize they didn’t do it right the first time.

I’ve seen that myself. One project for which I maintain documentation was originally built using Vignette, a content management system. However, it was discovered later that to accommodate localization, they would have to rewrite the system as a Java app. (I don’t know the details, but the concept of why a CMS can’t handle localization is beyond me.)

I found myself wanting to do that to one of my help systems specifically.

› Continue reading…

Bookmark It

Hide Sites

This week, Cameron Moll gave a design presentation to a small group, including our team. He discussed some principles of good versus great design. One of the concepts he brought forward was problem-centered design. As I understand it, a solution-centered design says, “I’ve got this product, so how do I make it do what I want or solve my problem?” Problem-centered design involves focusing on a problem statement to help identify the objective and see the way to design a solution.

I wondered how to implement problem-centered design myself. Applied to documentation, a problem-centered approach seems given to forms like troubleshooting guides and FAQs. The user has a question or problem, so here’s the answer. Simple as that.

I made myself think about it more, though, because if I dismiss it as meaning just troubleshooting or answering questions, I miss a chance to broaden the way I look at what I do and thereby improve it.

› Continue reading…

Bookmark It

Hide Sites

The prevalence of search engines hasn’t pushed out indexing yet. I’m not an avid fan of indexing because of the time involved in putting one together, but a search capability is not always what users will employ to find information.

Search functions are generally included in help systems and is built in to Adobe Reader, so usually, users will not neglect the search with the excuse that there isn’t one. Like other conventions from when the only documentation was a manual, however, indexes continue to be a standard component, and I’m sure some people use them out of habit. But in cases where you provide a PDF and users print it, there’s no search, and it’s up to the table of contents and the index to tell them where to find what they’re looking for.

› Continue reading…

Bookmark It

Hide Sites