In light of our team’s search for the tool that best meets a set of specific requirements, I’ve decided that Redish’s book has everything to do with what I do—or what I should be doing.

My Beef with Tri-pane Help

If you’ve been reading this blog for a while, it’s no secret to you that I’m not a big fan of tri-pane help. I think it’s dated and is associated in people’s minds with unhelpfulness.

But in our search for a tool that will give us a more robust Web output, I’ve discovered the main reason I don’t like tri-pane help.

Tri-pane help appears to have been invented as a way to provide booklike documentation—that is to say, linear documentation. The table of contents, index, glossary are all carry-overs from when all documentation was in hard-copy manuals. While a book’s material isn’t necessarily linear, it still reflects linear thinking.

The Web Offers More

Ginny Redish’s book argues that because the Web is a different medium and holds different possibilities, we shouldn’t hold ourselves to organizing Web content in the same way we organize book content.

Tri-pane help is a pseudo-website; it has a header or toolbar of some kind and a left pane for left-hand navigation. Help authoring tools make it easy to assemble tables of contents, indexes, and glossaries, but they’re only making it easy to perpetuate the linear thinking of books and to not take advantage of what current Web technology has to offer.

Letting Go of the Words talks about performing audience research and then setting up the home page, pathway pages, and information pages in a targeted way. Navigation deliberately and clearly guides users from start to finish, each page and link letting them know they’re on the right track.

You don’t have to set up a help system’s TOC just like you would a book’s. You could organize it in some other way than introduction, chapters, appendix, and so on. But how often do we take the time to do the kind of research we need to in order to make a table of contents even partially effective?

One of the limitations of a TOC is that you can display only topic titles. If you set up pathway pages like Redish describes, you can give the reader more guidance. A risk you take with TOCs is that as the user doesn’t find what he wants, he expands more and more books or folders, and he ends up with an overwhelming list of topics. Instead of holding his hand and leading him along, you’ve paralyzed and frustrated him.

In my experience, help authoring tools don’t lend themselves to dynamic Web outputs that allow you set up this kind of guided experience. You could do it, but it’s not supported well out of the box.

What about Search?

I was talking with my team lead a few days ago about this. He brought up search. Tri-pane help offers search, so how is a website like I’m describing any better?

I’ve got a few responses to this.

• Not everyone searches. Many people do follow links in menus.
• Multiple pathways increase the likelihood that people will find what they want.
• The search function in tri-pane help usually stinks.

I’m a fan of search. If search is well done, it can quickly take users to what they want. If that’s the route they choose. But it shouldn’t be the only way to look, or else we run the risk of the answer to the user’s question being too far down the results list to be found.

Wrap-Up

I think creating tri-pane help tends to lull technical writers into going through the motions. “Okay, I’ve got search, a table of contents with all my topics listed and organized, and as many index keywords as I could come up with. My help is helpful.” We sometimes fool ourselves into thinking that because these boxes are checked, we’ve done a good job at providing quality content and structure.

It would be better for help authoring tools to provide more flexibility so we’re forced to put in the research and thought required for useful content and architecture.

My hope is that in our search for the optimal tool, we find one that doesn’t force into creating tri-pane help and instead allows more flexibility and visual appeal.

Bookmark It

Hide Sites

Related posts (auto-generated):

1. RoboHelp Packager for AIR Critique, Part 2
2. Help Authoring Woes: Index As You Go
3. Time for Online Help to Get a New Wardrobe
4. Could Technical Communication Be Entertaining?
5. Anticipatory Search in Context-Sensitive Help

We’ve come to realize that if we want our department to take us seriously and give us the place we want, we need to be equipped to justify the decisions we make on what user education products are right for any given project. One of the things I’d like to see happen in our team is to develop a menu of products, each with a specific definition and an explanation of the situation(s) in which we would recommend that product.

I’ve taken a first shot at this. I’d like your help to flesh this list out, the descriptions, and the reasons you’d use each one. In the comments, please let me know what I’ve left out.

Quick Reference Guide: One-to-eight-page guide that contains reference information, repeatable tasks, or some combination of these. Used when users have small number of tasks or will frequently need to refer to charts, tabular data, and so on.

Quick-Start Guide: One or two sheets that explain the steps for setting something up. Could also provide a set of most common tasks. A throw-away document. Focus may lean toward one-time training.

Short Guide: Thirty-to-forty-page document that provides task steps and reference information. Used when there is too much information for a quick reference guide.

Setup Guide: Document about the same size as a short guide but that is focused on setup tasks. Used when there is too much information for a quick-start guide.

Comprehensive Guide: A full document with fairly complete information about how to complete tasks with the product. Includes reference information and maybe troubleshooting information. Used when a user will perform a wide range of actions with the product, product uses a specific set of terms, and/or product is complex.

Training Guide: A document about the size of a short guide with a focus on teaching the user how to complete core tasks. Concepts build on each other. Examples and exercises are included. Used when someone needs to be trained to use a product by using the product.

Microsoft HTML Help System: A set of HTML files with a table of contents, glossary, and index, all running within a single file (.chm). Installed with software. Used with software installed on the computer hard drive and the user may not have an Internet connection. Contains instructions on completing tasks. May contain context-sensitive topics, reference information, and troubleshooting information.

WebHelp System (or variants): A set of HTML files with a table of contents, glossary, and index. Hosted on a server. Contains instructions on completing tasks. May contain context-sensitive topics, reference information, and troubleshooting information. Used when an Internet connection is common for users.

Knowledgebase: A set of HTML files that contain reference and troubleshooting information.

Web-based Help or Support Site: A dynamic, searchable website containing a variety of topics. Users can comment on topics and browse topics by tag. Allows integration with social media.

Demonstration Video: A recording of the use of a product, usually software, to show how to complete certain tasks. May be used if no test version of the product is available, and practicing with the product isn’t an option. May include voiceover or text captions.

Overview Video: A short introduction to a product that highlights key features. Doesn’t show how to complete specific tasks. Used to give users a brief exposure before they begin using the product or even as an advertisement.

Static Simulation: A video that relies on actions from the user to move forward, typically in what appears to be software. The user must follow a particular path to complete the task, and choices and exploration is limited. May be used as a scripted demonstration so that the demonstration always shows the same functions (and always works).

Tutorial: A blend of demonstration and simulation. Users are shown how to complete a task and then are given the opportunity to try it out.

Wiki: A set of webpages that are editable by any user with an account on the platform. Users can also add and remove pages. Pages have revision histories, and changes may be subject to approval by an administrator. Used when a product has an active community surrounding it whose members are interested in contributing information about the product.

Blog: A website or webpage that is updated regularly, giving updates about a product. Usually somewhat informal in tone. Used when a product’s users want to receive information about a product in between releases.

Release Notes: Short documents, such as a readme file or PDF, that lists the changes in a major release, update, or patch to software.

Inline Help: Text on websites or in applications added to elements to provide some context or examples for using the elements. Used when users may need minimal information to successfully navigate and complete a task.

Embedded Help: Text on websites or in applications that is contained in boxes, sidebars, or modal windows and explains elements in more detail than inline help. Used when further information is required outside the main flow of the webpage or screen.

Tooltip Help: Text on websites or in applications that appears when the user places the mouse pointer over an element for a few seconds. Used when brief hints or reminders are needed and real estate is scarce.

Autocomplete: A text field that provides a drop-down list of options matching typed characters as the user types. Used when only certain options are available, but there are too many to include in a drop-down box, or to provide recommendations.

What would you add? What information have I forgotten from the items here? I’ll update this list based on your comments.

Update: Added release notes, tooltip help, and autocomplete. I wouldn’t have thought of autocomplete features as user assistance, but after it was suggested and I thought about it, I agree. Autocomplete can give guidance so the user doesn’t enter data that the software can’t handle.

Bookmark It

Hide Sites

Related posts (auto-generated):

1. Findings from an Online Help Usability Test
2. Offering a Menu of Tech Comm Deliverables
3. Why a Transition from Tech Comm to Usability Makes Sense
4. A Way to Get Technical Writing Practice
5. Get Passionate about Tech Comm

If you’re like me, you don’t use browse sequences, and you set the TOC to sync automatically. As a result, the only button there is the hide (“X”) button, so it looks like the following image:

In this situation, the mini nav bar is mostly a waste of space. If you want to save some space by getting rid of it, here’s how to do so:

1. Open your .skn file.
2. Find and comment out both instances of the following:

<frame name="MiniBar Pane" marginwidth="-1" scrolling="no" id="6" />

3. Find both instances of what looks like the following:

<frameset rows="48,*" >

and change them to:

<frameset rows="100%" >

4. Save the .skn file.
5. Generate and view your WebHelp.

One of the nice things about doing this is your skin file is static, so it will apply these changes every time you generate your WebHelp output.

Note: This is how it works in RH7. If no changes were made in the .skn file for WebHelp in RH8, it should work there too.

Bookmark It

Hide Sites

Related posts (auto-generated):

1. Tech Tip: Checking WebHelp/FlashHelp Output Files in to Subversion
2. FlashHelp Tech Tip: Removing IE's "Click to activate and use this control" Message
3. RoboHelp Packager for AIR Critique, Part 2
4. RoboHelp Packager for AIR Critique, Part 1
5. Changing a Topic File Name in RoboHelp and Subversion

Objective

I wanted to find out whether and how quickly participants could find given pieces of information and answers to specific questions in two versions of a help system described in this post.

Specifically, context-sensitive topics in the first version have a screenshot giving an example of how the screen can be used, sometimes with numbers corresponding to annotations in the text below. The newer versions of extensive help topics had the screenshot hidden in a dropdown hotspot and details contained in dropdown hotspots instead of being annotated. Specifically, the hotspots were formatted as green, underlined text with a right double angle bracket afterward.

Method

I wrote ten tasks for finding certain pieces of information within the context of using a particular screen and then clicking Help. (I realize this takes an assumption that users would take the step of opening help, but this experience actually educated them about using it.)

I looked for participants in one of two main roles in the application and also in a certain demographic that we were concerned about: 50 years old and older. Users in Role A had three tasks in the old version of the help and two tasks in the new version. Users in Role B had two tasks in the old and three tasks in the new.

I explained to each participant that I was testing myself (not them) to see how easy it is to find information in the help. I told them that I would be observing and taking notes; I wanted them to speak out loud so I would know what they were thinking; and it was okay for them to give up if they couldn’t complete the task. I didn’t explain that I was having them test two different versions of the help system so that wouldn’t somehow affect the results.

I ended up skipping a couple of tasks, one old task because I could see that the participant would run into the same trouble that he had on the previous two tasks, so rather than frustrate him or allow him to feel like he was failing, I moved on. I skipped another task because another particular user didn’t have a certain required permission in the system.

Results and Observations

This is the part I was looking forward to, of course. Not being a completely objective party, I hoped that the solution I introduced to visually condense information would prove to be on the right track.

Out of eighteen tasks performed by four participants, twelve were completed successfully. In the old help, tasks were either not completed or were completed after a delay of up to ten seconds. In the new help, tasks that were completed went more quickly.

I found that the screenshots at the top of the topic in the old version were problematic. The participants’ screen resolutions were such that the text didn’t appear below the screenshot, and most of the participants didn’t notice that they could scroll to get more information. They tried interacting with the screenshots or looking for answers on them. One user, because she couldn’t see any help text in the topic, began clicking a set of links I’ve included at the top of every topic. This nav bar consists of links to the FAQ, troubleshooting tips, and so on. Only one of the participants—the one who completed all five tasks successfully—caught on to the annotations and realized that if something was numbered on the screenshot, there must be a corresponding number somewhere below.

Overall, participants had a higher success rate in the new version of the help topics. Because the screenshot was hidden in a hotspot, they could see the help text. The dropspot links provided a way for them to scan the types of information available and choose the one they wanted to learn more about. None of the four had any problem understanding that they could click the dropspots for more information. The different color and underlined formatting were a signal to a couple of the participants, and the double angle bracket was the main signal for another.

Due to the number of tasks completed overall, I saw that while it was still possible to find answers in the old versions of the topics, finding information went more quickly in the new versions.

Participant Comments

After each participant went through the tasks, I showed them the old and the new versions together. In particular, I had used both versions of the topic that had become so bogged down with information (as described in the previous post) in two different tasks. I asked for their overall impressions and comments about the old version and the new and have notes for three of the four.

Participant 1: The old version is “busy; I have a phobia about scrolling through a bunch of stuff to find what I want. I would like it to be more concise, take one question at a time. I like the new version better; I can look at exactly what I want to find out. I already know what the screen looks like, so I don’t necessarily need to know that. I can see that on an initial training that the screenshot is good, and if you’ve never seen it before, it may be good. But for a situation for needing quick help, I need something compact. I already know why I’m coming here. I don’t need to look at the screen and identify all parts of it.”

Participant 3 (who completed all tasks): “I need the title at the top so I know where I am [as opposed to having the screenshot]. Having the numbering on the picture sort of flows. With the green links, I had to poke through. I’m not sure which one’s quicker.”

Participant 4: “The FAQ maybe should have a few more selections. Maybe ten choices [per subject or section], maybe you’d find something along the lines of what you’re looking for.”

Conclusions

In general, the participants reacted more favorably toward the new version. I do probably need something to suggest what parts of the screen the green links correspond to because the participants tended to regard them as topical rather than talking about specific items on the screen. So I’ll have to think about that more. As I mentioned previously, I would also like to have a script that would expand all dropspots so they can be printed.

Bookmark It

Hide Sites

Related posts (auto-generated):

1. Six Things to Remember in Your Documentation Usability Testing
2. Dropdown Hotspots: A Solution for Cumbersome Help Topics
3. Results of a Study about Online Experience
4. Time for Online Help to Get a New Wardrobe
5. A Shift in My Context-Sensitive Help Approach

When doing usability testing on documentation, keep the following things in mind. (These apply to any type of usability testing, actually.)

1. The participant isn’t being tested—the documentation is. Make this clear to the participant. You may even want to put it as simply as, “You’re not being tested. I am.” You want to observe how a person interacts with the content. The participant will face no adverse consequences for not successfully completing a task.
2. Come up with scenarios and tasks where the context makes sense to the users. Similar to examples used in documentation, if the situations you present don’t make sense in the participant’s world, she’ll spend time getting confused or correcting you. Think through the context of the tasks you’re using to be sure it holds up.
3. The participant should speak out loud so you can record thoughts, feelings, and reactions. It’s okay in informal testing to ask, “What are you thinking right now?” or “Why did you choose that option?”
4. Any pause in movement of more than a couple of seconds means the user has to ponder what to do. That suggests a potential usability problem.
5. Put together follow-up questions to find out how the participant feels after interacting with the documentation. Of course, you’re looking for objective data and observations; however, one of the important things to find out is the impressions the participant comes away with regarding the documentation and the product. Those impressions could very well affect how much the person wants to have anything to do with your organization and its products.
6. It’s okay for the participant to give up. People do that. Explain this to the participant. Usability testing is about seeing whether people can complete tasks successfully most of the time (or ideally, all of the time). You may wonder whether telling the user that she can give up is somehow planting that idea in her mind. But if the person were on her own and trying to use the documentation, she would think of giving up just as quickly.

Bookmark It

Hide Sites

Related posts (auto-generated):

1. Some Observations from Documentation Usability Testing
2. Where Usability and Documentation Meet
3. Usability and Maintainability Not So Incompatible
4. Usability vs. Maintainability in Technical Documentation
5. Usability and Maintainability: Instructions They Can Follow

Because of the many variables involved in making a payment in various countries around the world, this screen has become functionally dense, leading to a help topic that I finally decided had become cumbersome. The bulk of it was a procedure for filling out the information, but in between steps was a lot of “if you need to do X, enter Y” and such things. Some of those extra explanations were only a couple of extra sentences, but added together, it was a lot of content being spewed at the user.

This is a Web application, so we don’t have field-level help. The growth of this help topic led me to imagine that if a user clicked Help for information about one particular field and had to slog through the text in that topic, they wouldn’t get very far before giving up. That much information punching you in the face would be enough discouragement without even beginning to scan it.

I needed a different approach.

After some deliberation, the thought came to me to try two levels of dropdown hotspots. This screen is divided in sections, so I rearranged the information so that I had a hotspot corresponding to each section. Each hotspot would expose another set of hotspots and any other information about that section in general. This would allow the user to navigate directly to what they want rather than having to scan and scroll through a bunch of text.

I talked to an interaction designer and also demonstrated this idea to the user education team. I received some good feedback, and they were generally in favor of this idea.

The next problem was that in this help system, I have provided a screenshot at the top of each context-sensitive topic. The original reasons for doing this have changed, and the main purpose now is usually to show examples of what the user may see or do on the screen. But even visually condensed text can be pushed out of sight by the screenshot, so I hadn’t won much. So I decided to try putting the screenshot inside a hotspot and allow the user to choose to see it if he or she wants an example rather than having to see it every time. Generally, they already know what screen they’re on anyway.

Next, I explained the concept to the product manager (I run major changes past him because he wrote the help for the application we’re replacing). He said, “That sounds great, and I think people your age will have no problem with it. But I’m concerned about some of the older folks who would have to use it.”

Now, our users consist of two main age demographics: People about 20 and people in their 50s or older. The project team has tried to be aware of the potential gap in familiarity with computers and Web applications.

What the product manager suggested next was music to my ears: “It would be nice to get it in front of some of them and have them try it.” After I demonstrated this new topic structure to him, he was even more in favor of trying it with some of our users. He is setting up a couple of on-site visits for me in our area so I can see how our users navigate in this kind of topic structure.

In any case, using this method makes the information look much less intimidating when the topic opens. I’m trading scrolling for mouse clicks, but I think clicking is the better of the two. The problem I have to contend with is how to provide a control to expand all hotspots, or at least for a print control to print all hotspot contents. I’m using RoboHelp 7.02 to maintain this help system, and I haven’t been able to locate something that would quickly integrate with RH7′s hotspot scripts to expand everything at once. And I’m not a JavaScript whiz. (If you have such a script or know where I can get one, please let me know! What I found on grainge.org didn’t quite address this need.)

So we’ll see how the usability testing goes and whether I can find a way to expand all hotspots. (Come to think of it, I think all a “collapse all” control would have to be is a link to “#,” just refreshing the page.) But having the topic open with screenshot and control details within dropdown hotspots makes the topic look a lot less daunting when it opens. I plan to implement this across the longer context-sensitive topics.

Bookmark It

Hide Sites

Related posts (auto-generated):

1. A Shift in My Context-Sensitive Help Approach
2. Forget the Scry: Find out Why Users Access Help
3. Results of a Team Design Review: A Different Context-Sensitive Help Structure
4. Write Self-Contained Titles to Preserve Context
5. Wishing I Could Start Over

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.

I search first myself, but because there’s still a place for indexes, I still include them. Perhaps due to my attitude toward them, though, I tend to let them slip sometimes, especially in my help systems. Last week and into this week, I’ve had to spend some time in one of my RoboHelp projects getting my index fully fleshed out. The deadlines—and working on other projects—had kept me busy for so long that the index became the ball I dropped.

My neglect has come back to bite me. I’ve realized that if I had but added to my index one topic at a time, I wouldn’t have this problem. It would have been so easy when I finished a topic to review it for keywords and associate that one topic with them. So I’ve resolved to make it my standard practice to index a topic as soon as it’s ready to go into the project repository.

In fact, the best way for me to manage this is along with a conditional build tag that I use. I have a tag in my project called “Unfinished” that I apply to topics that are in progress. My output excludes anything with this tag so that if I have to update other content while new topics are still in the works, they are automatically kept out of the application. A good guideline—no, a rule—would be to index the topic before I remove the conditional tag. Since I have to remove the tag to include the new topic, I enforce the indexing of the topic.

Thorough indexing is one of the signs of a technical communicator who has taken the time to give the users the resources they need. It may not be noticed when it’s there because it’s expected and taken for granted, but when it’s not there, someone will complain (or at least grumble and curse the help author for omitting it). There may be some grumbling out there over my incomplete index, too.

Bookmark It

Hide Sites

Related posts (auto-generated):

1. How I'm Juggling Conditional Build Tags and Localization in RoboHelp
2. Call for Web 2.0–Friendly Authoring Tools
3. RoboHelp Packager for AIR Critique, Part 2
4. Long Help Topics: A Help Author's Crime against Humanity
5. A Shift in My Context-Sensitive Help Approach

These styles involve a background image, though a background color can do just as well. I created an image 1 pixel wide and about 20 high to tile horizontally across the heading. The image is a gradient from tan to white. Here is the CSS for the topic title:

h1 {
font-size: 14pt;
font-weight: normal;
font-style: normal;
border-top: 1px solid #dfd4b9;
border-bottom: 1px solid #dfd4b9;
width: 100%;
text-indent: 12pt;
color: #44536c;
white-space: nowrap;
margin-bottom: 12pt;
line-height: 150%;
background: top left url("images/h1.jpg") repeat-x;
}

The borders and the background image run the width of the document (width: 100% and the repeat-x attributes) to give a complete visual separation between sections. The margin of my document is zero, so the text-indent pushes the text inward; the white-space: nowrap attribute will keep the title all on one line so we don’t get strange indentation on a second line. The line height sets the spacing between the heading text and the borders.

A second way to get the heading to stand out would be to use a background image that is 1 pixel high and a few thousand pixels wide. The image would have a gradient running from left to right and have a repeat-y attribute in the CSS. Otherwise using the above styles, the heading would have a color gradient that would begin at the left edge of the page and thus help catch attention.

Part of the purpose of this kind of styling is not just to catch attention, but also to add some visual interest to the document.

Bookmark It

Hide Sites

Related posts (auto-generated):

1. A Two-Column, Equal-Height Layout with CSS
2. Streamlining Your CSS File
3. I'd Like You to Meet Someone: Mr. CSS
4. I'll Have the Printed Color Surprise, Please
5. RoboHelp Packager for AIR Critique, Part 1

I have usually kept the how-to content separate. In one project, a separate manual described procedures for the various roles in the system. In another, I included how-to information in a second section in the table of contents. This time, I’m going to do something in between.

First, I’m planning to avoid the full screenshots and instead rely on smaller pieces of the application screens. The main approach here, though, is to have a two-column format for each help topic, the right column being something of a sidebar. The main column will describe the screen’s functionality. The sidebar, titled “How Do I…?”, will provide steps for doing certain tasks that relate to that screen.

The reason for this approach is that in my previous experience, it’s been a challenge to appropriately mix instructional content with informational. This approach, I hope, will provide both kinds in the context in which they’re needed by users. The two-column format will allow the user to scan each type of information and focus on the type he wants instead of having to scroll through a topic looking for the type of information he’s looking for. If he wants procedural, he can choose to look just at the sidebar and ignore the rest.

Since this is a small project, it will give me a chance to try this idea out and see how it works for a small user group before I start using this pattern for more projects in the future.

Bookmark It

Hide Sites

Related posts (auto-generated):

1. Forget the Scry: Find out Why Users Access Help
2. Knowing How Much Visual Assistance Is Too Much or Too Little
3. An Experiment with WordPress as a Help Site
4. The Tactile Learning Style in Tech Writing
5. The Reason I Haven't Embraced Single Sourcing

General Bugs

Having Back and Forward buttons is great. However, in Classic Help, they didn’t always seem to follow my navigation path. I don’t use browse sequences (and I turned that feature off anyway in the AIR generation dialog), so I don’t think I’m misunderstanding the purpose of the buttons.

The Classic Help TOC seems a little buggy when the Favorites pane is open. Everything worked except when I had a bunch of books open and had to scroll to get to the last book. When I scrolled, I got behavior like the selected book or another book automatically closing, or the TOC would jump so I couldn’t see where the selected topic was. (If I scrolled back up, the auto-closing book would open up again.)

Where I had Captivate demos in a topic, a huge space was inserted before each Captivate demo about the size of the demo itself. The demos work fine, but that big space is an irritant.

Search, Index, Glossary

The Search (with word stemming), index, and glossary work as expected. I like the index and glossary better in Classic Help, perhaps because they work similar to the way they work in FlashHelp. However, I like the search in Uni-pane better because the search results give the user some context for each find. I wonder why the search isn’t set up the same way in the other systems. I’m sure having a narrow pane on the left isn’t as conducive to search results that show context.

In Uni-pane, I would like to be able to change fonts. The TOC headings are in Verdana, which isn’t my favorite, and my help is written in Arial.

Comments

I think the comments concept is on the right track. The comments XML file doesn’t save with an XML extension by default—I think it should. I’d have to tell everyone who wants to comment that they have to add the extension. The XML file also inserts “%20″ for spaces.

The Packager As an Extra Step

Packaging straight from RH as a single source layout would be quicker, and it would probably allow the dialog to remember the last settings used for that particular help project. As is, with the dozens of layouts I’m doing between several projects, I would have to be constantly changing the settings in the dialog. This would get complicated with variations based on languages and roles.

Suggestions / Wish List (Other than Those Already Mentioned)

AIR help doesn’t seem to support multiple languages other than displaying a translated help topic. It ignores the language setting of my output. I suggest a language setting in the AIR dialog.

I need CSH for Web (Java) applications; so far, AIR help supports only C/C++, Flex, and AIR applications. I tried linking from a basic HTML file on my computer to open the .air help file, and I got a dialog asking me to open or save it.

In my experiments, I’ve had to install every different .air file. My understanding was that users would have to install the runtime support once, and accessing every .air file after that would be transparent to the user. Maybe I’m doing something wrong here.

A brief note for anyone trying out the packager: Opening the .air file by double-clicking runs the installation with the option to “Run Now” or “Uninstall.” If you enabled the option to create a desktop shortcut and open it that way, it doesn’t try to reinstall. I found this in the RH Packager forum.

Conclusions

Adobe seems to be following a good line of thinking here with AIR help. But remember, users want simplicity. Having to install each help system as an application is asking too much of everyday users. The other most important things (and biggest wishes) to me right now are the following:

• CSH for Web/Java apps.
• Multiple language support.
• More options for customizing the appearance (colors and graphics, not pane layout).
• JavaScript support.
• Running the packager as a single source layout out of RoboHelp.

For the time being, the packager and AIR help aren’t robust enough for my deliverables. Thanks to Adobe for releasing beta versions of the packager and letting help authors give feedback. I’ll be keeping an eye on what Adobe does with the packager.

Bookmark It

Hide Sites

Related posts (auto-generated):

1. RoboHelp Packager for AIR Critique, Part 1
2. How I'm Juggling Conditional Build Tags and Localization in RoboHelp
3. FlashHelp Tech Tip: Removing IE's "Click to activate and use this control" Message
4. RoboHelp and Flare: Room at the Table
5. RoboHelp 7.02 Patch Released