TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Dead-end Online Help Path? From:Roy Anderson <royanderson -at- MINDSPRING -dot- COM> Date:Fri, 2 Apr 1999 13:14:41 -0500
Most of you will find my situation and musings odd. I seem to have reached a
dead-end insofar as online help development is concerned. While I enjoyed
acclaim for developing tight, no-nonsense, user-friendly online help systems,
my "old dinosaur" skills set don't sell well in today's market.
I'm at a career crossroads. Continue to waste time seeking contracts in online
development, or move to Y2K programming? Since I help cause Y2K problems by
programming COBOL legacy systems decades ago, the latter is a natural. I,
however, much prefer developing online help systems. It's rewarding to hear
grateful users express how my online help files helped them understand
and overcome problems.
It seems that most of you develop online help for specific applications
and are intensely involved in said applications. My programming background is
isolated to large-scale mainframes. I have no experience with Windows, Mac,
and Unix internals. Nor am I an engineer.
In 1994, I was asked to do something to reduce the hundreds of calls to our
corporate help desks. I chose to use WinHELP to distribute FAQs in online
help files over our LANS--we had no intranet in those days--and this became
wildly popular. We expanded the daily help file until it included 600 Word
files embracing FAQs, contacts, news, and so forth. This online help file
reduced calls to the Help desk by seventy percent, and later became the
nucleus for the corporate intranet.
I've written over 350 RoboHELP projects during the past four years--including
two custom replacements for SAP enterprise software help--a process whereby
we unlinked SAP online help from F1 keys and substituted online help tailored
to the client's business processes and transaction screens. In this process,
Worked closely with business process SMEs but not software SMEs. In this
effort, Software engineers linked our custom online help files to the SAP
help system. Online help developers were not allowed to discuss software
links with SAP engineers. Go figure.
None of our SAP help files (RoboHELP 4 and 5) used "What's this?" or secondary
screens. When users are confused about something, they simply press F1. SAP
esponds by displaying the online help (with screen captures) appropriate to
that process or transaction screen. Our rather boring online help systems
are vital to users but are not very impressive to today's hiring managers.
A hiring manager recently laughed at my example file. "You call that an online
help file? You don't use secondary screens. You don't use 'What's this?' This
is s---!"
I had to agree the example was dull. All it does is communicate what the user
needs to see to resolve questions and issues. We wrote online help for users--
not to impress anyone. The users adored my efforts but...
At my age (55), it's unlikely I'll acquire the skills to develop online help
for modern software applications--to intelligently discuss GUIs with Dilbert
and Wally types.
Is there a market for stand-alone (not a component of a software application),
online help projects these days? It seems that every example I can think of
for creating non-software related topics can now be handled by webs and PDFs.
My online help development days seem rather bleak. Any advice?