WebHelp gives me flashbacks from the 1990s. A client of mine recently looked at a WebHelp project and said it was not “sexy enough.” I had a hard time disagreeing.
Tripane help is like the K‑car (I know, I am dating myself here): reliable but a relic of another decade. The table of contents and skin look like they belong in a museum.
I subsequently created a version of browser-based Adobe AIR help. It’s much more modern looking. But it’s still fundamentally an old technology and paradigm. Sure, there’s the sleek exterior and the more modern presentation of the content but there’s still the tried-and-true vestiges: the table of contents, index (if you still create one), search, and content in the right-hand pane.
Other writers have critiqued the tripane online help too. Technical communicator and blogger Tom Johnson wrote in his blog:
“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.”
Ben Minson, another technical communicator, wrote a blog entry about why he does not like tripane help.
Other than the outdated look, my main issue with tripane help is that there are versions of it that do not play well with iPads, iPhones, and most smartphones—all of the devices that one could argue are the future of computing. When I ran WebHelp on an iPad and iPhone, it was almost too slow to be considered usable.
PDF files
PDFs are another old-style technology that writers still churn out (myself included). I don’t think PDFs are quite yet on life-support but I am interested in exploring alternatives. I plan to attend Bob Boiko’s talk about “Life after PDF” at the upcoming WritersUA conference in March 2013.
Creating PDFs is a snap for authors. But when the documents are long, they risk being monolithic and unwieldy for users. For instance, imagine having to read a 50- or 100-page PDF on a smartphone or even tablet. Painful.
To be fair here, help authoring vendors have innovated. We can create EPUB files, “mobile friendly” versions of help, and HTML5 files. But the enduring popularity of old technologies like tripane help and PDFs makes me wonder whether it’s time to ditch the familiar paradigms and embrace newer technologies that look like they belong in this century.
I have worked as a
Good points, Robert. As writers in the high tech. field, shouldn’t we be leading the way into better technologies and methods? Much too often, I see technical writers still insisting on very old paradigms — like the ones you mention here — and actually holding back their employers and other writers from moving into this century.
Things like triplane, TOC, search, index, PDF, hardcopy manuals, etc. are just tools to help users do their job. If the tool is good, use it to its full capacity. If the tool is passe, toss it out and use something better. If better tools don’t yet exist, demand them. If there is enough demand, developers will fill the demand (and make money in the process).
Hi Yippee,
Thanks for your feedback. Yes, sometimes employees are holding back their employers (fear of change) and sometimes employers hold back the writers (lack of budget or interest in newer technologies).
I know it sounds vague and obvious but some industries will not want / need / be able to use anything else than PDFs.
Hi Małgorzata,
Yes, I agree. There are many firms that just want the traditional technologies, like PDFs. Several times, I’ve faced objections from clients or employers that do not want to embrace new ways to deliver technical documentation.
Thanks for your comment!
I’d like to read more about what newer technologies you think should be embraced. Where do we go from here?
Have to disagree about K‑cars; they were hardly reliable, just profitable. That picture makes me shudder.
Hi MaxWedge426,
In my opinion, I think we still use the traditional technologies but continue to look at newer ways to deliver content like using HTML5, EPUB, and help apps. Most of the help authoring tools support these deliverables already.
As far the K‑car reference, sorry I made you shudder. My parents owned one and they were quite pleased with it from a reliability perspective. As a teenager, I wasn’t so impressed with how it looked. 😉
Thanks for mentioning me in this post. I agree that tripane help is especially problematic with mobile, and that’s a much stronger case than simply saying it looks outdated.
One good thing about tripane help is how quickly pages load. You can also build a really complex table of contents if you want. But try skinning a tripane help to look just like your company’s website, and good luck. Including all those frames gets complicated.
(By the way, if you want to link directly to the post, it’s here. I also talked briefly about tech comm tools versus web based tools here.)
Thanks for sharing your thoughts on this topic!
Hi Tom,
Thanks for responding and sharing more links!
Good points agreed. But there is no point leading the way unless we know how users want to access help and what they expect to see. Quite a challenge. I am of the same mind regarding tri-planes and pdfs, as new users are young users who have different expectations from what we currently deliver. I can only suggest single-source, multiple output at the present time.
Hi Bernard,
Yes, I agree with you–we need to make sure that what we deliver will meet the needs of our users. As far as younger users, it might be worth exploring RoboHelp 10’s ability to generate a help app. Other vendors may have the same feature.
Thanks for your feedback.
Good points specially about tripane. HTML5 and CSS3 can aleady be used to overcome tripane in a great many aspects.
However, pdf files still seem to have their individual spark from a version control and signature approval point of view. True enough I haven’t delved much into alternatives for document making so which options would you recommend for documents which needed easy view access and signature approvals? Thanks for the North star!
Hi Alex,
I have not had a lot of experience with signature approvals. PDFs might be your best option for that requirement. But there may also be some third-party apps that can help you manage signatures for other deliverables, such as HTML files.
Thanks for your feedback.
Just my views and experience here.
It so depends on your audience and what your user assistance supports. I find that most clients want a mix of outputs and are prone to changing their mind. That is why I always try to stick with a single sourcing solution (e.g. RoboHelp). I don’t think the tri-pane look is outdated, I still get a lot of requirements for tri-pane help but clients do want the skins tailored to match their branding. I may use traditional Webhelp, Airhelp or Browser-Based Air Help. They may want to reuse/single source some of the content from the help system (using content for knowledge bases/FAQs for example) but the online book with a table of contents, index and search still keeps a lot of people happy.
The real change that is needed here is not simply one of format. We have to move away from creating linear content in isolation. The Web is a hypertext medium. We have to learn to create non-linear connected content.
Robert:
It’s gratifying that you and a few others are shaking us writers of user docs from our lethargy. Our PC-era deliverables are not meeting the needs of today’s end user. Or, for that matter, today’s software developer.
Our trade is in an existential crisis. STC chapters are closing across America. Employment listings for writers of user docs are becoming rare. (Developer docs like API and SDK documentation are a different story and not germane here.) In their narcissistic way, iOS developers consider the need for user docs to be an admission of poor UI design, and turn a blind eye. The only safe abode for us would appear to be the enterprise, where we can blend into the woodwork and busy ourselves with content management. The result, all too often, is impenetrable towers of Babel like MS Office help. (I’ll take my chances with Google.) As upper management culls departments that do not generate income, even our tucked-away sanctuaries are in peril.
I feel there is still a strong need for providing the user with help within their app, delivered as a context-sensitive help topic just-in-time. This is, of course, the performance support model. It pretty much requires that the help be a part of the UI. That once-ubiquitous question mark icon still has a lot of mileage left in it and is already familiar to users. Let’s put it back to work!
Providing performance support for commercial applications is going to require working with the engineers to embed the doc, perhaps with the assistance of RH’s content-sensitivity tools. Now that Adobe’s TCS4 has put video within our grasp, we should be ready, willing, and able to create rich-media help topics. We have got to stop ignoring the fact that today’s users have rejected the Boomer generation’s text-based learning paradigm. We should study what our cousins in eLearning are up to as their deliverables, which have contained rich media for years, are now using video to create “hosted” lessons where a human is presented as a talking head or in a separate window. Learner engagement and knowledge retention skyrocket when they are “guided” through the learning process by a person they can see as well as hear. See Adobe’s hosted eLearning tutorials on YouTube, created with their easy-to-use but immensely powerful Presenter authoring application.
About the only use for a free-standing, monolithic help entity I can see would be as procedural documentation for a hardware product. I can visualize a forestry worker consulting the “owner’s manual” for their new chain saw via their smartphone.
Such a document’s search feature would actually be an index in disguise. Today’s user doesn’t know what an index is, but they enter index-centric terms in the search text box. The index we create but do not publish would ensure that keywords entered by the user are not referenced trivially, but only where they introduce related procedures, or provide useful definitions. By thinking a step ahead of today’s post-literate user, we can sneak in the instructional power of text where appropriate, and via rich media create an immersive learning environment that to this user type is more appealing than blocks of text — and thus more likely to be invoked.
Other ways to give today’s user what they want include publishing to the socials and making help topics Google-searchable. But I don’t want to wear out my welcome.
When you say that tripane help is past its prime, are you saying the technology or the presentation methodology? For example, I can create a “help” system using HTML5 that has 3 panes — a header a TOC and main content. It has a full search capability, and I plan to build connectivity to our Web portal interface so that users can also explore our full content library. All of our usability testing is extremely positive and it works on iPads/Android tabs, etc.
So if you are saying the old technology is past its prime, I completely agree. If you are saying that presenting information in three content areas is old fashioned, I would have to disagree.
Hi Laura,
Primarily, I think the technology is past its prime.
I know that tripane help can be delivered as HTML5 (a newer technology). But help authoring vendors have delivered tripane help for decades. If a help authoring vendor introduced a new and innovative way of delivering help, I think it could potentially be a disruptive technology, at least for technical communications.
Thanks for your comment!