The key trends are as follows:

• Help is embedded in a browser because the browser is the predominant mode people use to find information.
• Search is the main method for navigating content. There’s still a table of contents, but no more index.
• When you choose a topic, you see contextual topics related to the topic you’re viewing.
• You can choose to include online content into the search.
• The help is “decoupled” from the Visual Studio application, so the help authors can update the help without waiting for the next release of Visual Studio. (This is what I referred to in my content independence post.)

The direction the Visual Studio Help team is moving reflects my own trends as well: moving towards a web-like experience with help, relying more on search, adding contextual topics based on what the user is viewing, and publishing help in a location I can update on the fly.

(Thanks to Keith Soltys for the link.)

Blog Sponsors

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

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

• 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