---
title: "Arguments for and Against Tripane Help"
date: 2011-03-17
description: "$( document ).ready(function() { // Handler for .ready() called. $("
canonical_url: https://idratherbewriting.com/2011/03/17/evaluating-tripane-help/
---
# Arguments for and Against Tripane Help
As a quick definition, tripane help is the standard webhelp HTML output that has several frames -- the table of contents pane on the left, the main topic area in the middle, and a pane across the top. For example, here's a [sample tripane help](https://s3.us-west-1.wasabisys.com/idbwmedia.com/wordpressguide/Default.htm) I created a couple of years ago for WordPress:

![This is an example of tripane help. It's all a giant frameset, with the table of contents on the left, a navigation bar across the top, and content in the middle. That's three panes -- hence the name, tripane help.](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/tripanehelpexample-600x337.jpg)

I agree with Ben's arguments that discourage tripane help, and yesterday I even wrote somewhat of  draft rant titled "Rest in Peace, Tripane Help." But as it was still in draft mode, I mulled it over. I also listened to a Scriptorium webinar on [DITA Best Practices by Tony Self](http://www.slideshare.net/Scriptorium/webcast-dita-best-practices), which helped me see another side of the argument. In this post, I want to present a more balanced argument for and against tripane help.

## Cons of Tripane Help

Let's start with the cons of tripane help.

**Hard to modify. **Have you ever tried to modify the look, feel, or functionality of tripane help? It's usually a complicated undergrowth of impenetrable frames and custom code. Hacking RoboHelp's webhelp, for example, requires you to dive into arcane tips and tricks from sites such as Rick Stone's [RoboWizard](http://www.robowizard.com/RoboWizard/NewProject.htm), which still looks, with its outer space background, like websites did back in 1995. Rick's site itself is an example of tripane help.

![Rest in Peace, Tripane Help](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/tripanehelp.png)

Flare gives you finite control over the style of each element, but not over the larger structural elements. What if I don't want frames? What if I want the main search engine on the home page? What if I want the sidebar on the right, with drop-down submenus that slide out? Why can't I just code it with a separate CSS file from scratch like a regular website, choosing what I float, choosing the behavior of my navigation buttons, etc?

Overall, tripane help is hard to modify because of the extensive frameset and proprietary code.

**Looks outdated. **Although you can tweak its styles here and there, you can't make tripane help look like a regular website. It just doesn't fit in with anything on the web that you find post-2005.

The more we move into the future of the web, the greater the divide grows between tech comm and interaction design. That divide worries me. When people see a tripane help site open up, it immediately signals a sense of outdatedness.

**Lacks web functionality. **It's not just about the limitations of tripane help's look and feel, though. It's also about web functionality: RSS feeds, comments, embedded videos, lightboxes, jQuery effects, real-time editing, browser-based authoring, built-in metrics, category links, tags and tag clouds, most popular articles, faceted browsing, instant search, search engine optimization, threaded conversations, and so on. You don't get hardly any of this with tripane help.* Ouch.*

By confining our HTML deliverable to the rigid tripane help, we become distanced from the forward movement of the web. We become publishers of HTML content but without any of the slick knowledge of web design or interaction design.

**Keeps you in book paradigm mode. **As [Ben points out](http://www.gryphonmountain.net/2011/03/why-i-dont-like-tri-pane-help/), we also get stuck in a book paradigm mode, where the only idea we can come up with for organizing our help content is a bunch of topic folders. Ben points out:

> 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.