Return to Help History
More Help memorabilia from Bill Meisheid's (Sageline Publishing
and early WinHelp MVP) Sageline.com archives. This time Bill's News Blog from 1996 (a time when WInHelp was at it's peak and HTML Help is coming soon).
Thanks Bill Meisheid for allowing us to republish on www.helpmvp.com.
Front Line News© and Editorial Meanderings©
Past postings from the edge of the wave...
4-08-97 EM© - Hypertext and Vaporware
12-5-96 EM© - Living on Internet Time and Other Technological Black Holes
8-22-96 EM© - WinHelp: Microsoft's poor stepchild
10-7-96 FLM© - The Dallas WinHelp Developers Conference
10-8-96 EM© - WinHelp & HTML Help: Siblings bridging the information gap - The Past Meets the Future
Confessions of a WinHelp Newbie by Jamie Yaeger
So what if Winhelp is the most powerful add-in to Word the world has ever known. If you don't get to use
it, you can't feel the power. With a Lamborghini you ought to be able to go faster than Fords, right? Well,
in Winhelp as in traffic, it all depends on the road conditions.
I only understand a little bit so far about how hypertext actually works; but it turns out that's enough to
be getting on with. The rules Winhelp has for generating topics and for creating links to them are fairly
straightforward, although possibly it only seems that way because I know so little that their complexity
has not yet been revealed. At least it's been pretty easy for me to jump right in and start writing crude
but effective help files after taking a three-day basics course taught by the internationally well-reputed
William Meisheid. (Slip me the promo money later, Bill.)
But as with almost all commercial writing, the major difficulties in writing on-line help occur in the
pre-writing stage. Once you've started generating topics it seems fairly easy to keep on generating them
until you've at least covered the basics of whatever it is you're explaining. My rules of thumb are:
Strip-mine text from other sources as appropriate. Ask questions of managers and co-workers who
actually understand the program. Summarize ruthlessly at all times.
If Only... but Who's Counting?
Getting to "start" is the trick. The thorniest problem I've faced so far in generating online help is best
expressed in the old joke about how to make a mink coat cheaply: "First catch your mink." A fellow-writer
with a different company than mine who was in the same Robohelp class I took has not yet been allowed
to work on generating help files at all. While she was in class a palace revolution took place at the
agency for which she is a contractor, and the new decree from on high says that tech writers will not
write help, only software developers will write help.
Of course, if software developers actually could write help files, there would be no need for Winhelp.
They could just bury the help files in the program as they went along. But Winhelp's tools lets writers use
a fairly simple programming language that attaches help files to Win programs in a uniform and accessible
way and allows the miracles of hypertext to be manipulated by regular wordsmiths.
At my firm, where we develop high-speed imaging software and also integrate it with other image
capture, image enhancement and image database systems, we plan to use on-line help not only in the
software itself but to provide help to operators on our integration jobs. This should cut our support costs
In the meantime, my first assignment was to take some existing help files for one of our imaging software
products and change a few words in it. This was to reflect an OEM sales relationship we have with a
hardware manufacturer who bundles our product with his scanner equipment. An expert would have taken
about 4 hours to do what it took me all day: decompile the two dozen or so old help files (they were not
kept as one big file but as individual modules, a mistake I will not be making in my own work
henceforward), pull out the .RTFs, make the changes in the .RTFs, and recompile them.
I was pretty panicked by 5 PM when I had the decompilation done and had started making changes but
was getting error messages when testing the first of the new text in recompilation. Mercifully, it turned
out the errors were from the original authorship and did not prevent the file from running. So I went
ahead with my changes and ignored the error messages and got done by 8 PM. The OEM was
subsequently reported to be happy, so it was worth the sweat and long hours.
Since that minor triumph I have begun writing all the on-line help for a newer imaging enhancement piece
of software, and have been assigned to do a full rewrite of several sections on an older piece of
software's on-screen help where the underlying program has been updated for NT with new functionality.
And a document-management software product of ours that has been on the market some years is
awaiting a complete set of on-line help if the powers-that-be want to squeeze out the development
money to pay for it.
It Works Already
My overall experience to date has therefore been that, when I can get time to work on it, it works. The
fight is not with the complexities of the Winhelp-generating software. My struggle has been with the task
scheduling constraints that all business must function within: too many deadlines chasing too few fingers.
And that's just normal wear and tear on the writer's stomach lining.
4-08-97 EM© Hypertext and Vaporware
For years, hypertext online information has been like the best of
vaporware; it would solve all your information access problems if only
you could get your hands on it. With the recent success of the World
Wide Web, hypertext has moved from vaporware to betaware--not quite
there, but iterating at a dizzying rate as "Internet Time" redefines
the cycle time of ideas and products.
Ideally, online documentation would be relatively easy to
construct and most of the concerns would be related to authoring:
planning, writing, and editing, rather than forcing writers to become
semi-programmers just to deliver their information. I admit that I
speak from the writer's viewpoint. I tried to be a programmer, I really
did; but though I am able to successfully construct a reasonably decent
Word macro, I don't fool myself. I am a writer. However, slowly and
surely the mechanics are becoming less of a hassle. As time passes, we
writers are beginning to focus more on content and less on the
confusing (for us) aspects of construction.
I know that some of you will immediately argue that the new HTML
paradigms (HTML Help, et al) will up the construction ante again. There
is a dizzying array of possibilities staring us in the face. Maybe in
the short term, but I believe the tool vendors will very quickly
insulate us from the need for meta tagging, CGI and Java scripting, and
Active X expertise. Within the coming year the issues will be less like
programming and more like writing. As a result, we need to consider
that online documentation projects have problems very similar to other
forms of technical writing.
There is one problem I consistently find as I teach an
Introduction to RoboHELP class to a wide variety of people from a broad
cross section of business and industry: lack of online methodology.
When I ask what sort of planning and procedures they have in place, my
students mostly give me blank stares or look away in embarrassment. I
don't report this to cause anyone discomfort, least of all my students.
I only want to illustrate what appears to be the current state of the
Our overall documentation plans also need to include our online
documentation. There is just as much need for planning, writing,
editing, and review cycles in the online world as there is in the
traditional paper-based world. I would argue that there is even more
need, due to the pressure to make idocumentation available "NOW" and
keep it current. However, very few organizations have a firm
methodology in place for their online information. It is mostly ad hoc.
Everyone has heard the maxim that no planning is planning for failure,
so I don't think I need to convince anyone the need is there. What is
needed is the resources and commitment to plan online properly.
For some time our concern has been deciding what portion of our
information we wanted to put online, trying to determine the overlap
between paper and screen. The Web has changed all that. With intranets
becoming the latest corporate darling, the question instead is what do
we leave off-line, not what do we put online. Add to these distribution
decisions the need to structure our writing and information design for
online readability from the start of the implementation, and we easily
see that this cannot be an ad hoc process. It definitely needs a
Over the coming months we will look at what things constitute that
methodology and how you can develop yours. The first step on any road
is the commitment to make the journey. This is one journey we all need
to make, and we need to get started ASAP!
More to follow...
12-5-96 EM© Living on Internet Time and Other Technological Black Holes
In New Media magazine I recently read a round table critique of
the web and the whole online publishing industry that touched on a few
nerves. The group was composed of top flight design and production
people from a number of the leading edge web sites. Every body, and I
mean everybody, was 24 X 7. I don't mean having their site up 24 X 7
but trying to work 24 X 7.
Of course they couldn't physically carry out this desire, but they
are all sacrificing sleep to stay on the edge of the curl as the
Internet wave is breaking. My first thought was, "get real or get dead
people." Recently, I have been exposed to a new term called Internet time.
This is defined as a compressed time frame for the same activity when
compared to normal time. For example, development that formally took
4-6 months in regular time is now required to be done in 2-4 weeks.
This is called working on Internet time, since the immediacy of the
medium has demanded much quicker response and delivery times. Ralph
Walden, the lead HTML Help programmer at Microsoft, when handing out a
2 week old CDRom of the HTML Help pre-beta at the Dallas WinHelp
Developers Conference, told everyone attending that it was already
severely out of date, but that was to be expected since they were
working on Internet time. Golly, since I wasn't able to get any time to
examining the handout for the first two weeks after getting it, I guess
it and I are now downright retrograde.
Time hasn't really compressed. However, demands on our time and
expectations on how quickly we can accomplish something have changed
dramatically. In the end we are just going at it longer -- 18 rather
than 8 hours. The high tech industry is the new purveyor of the sweat
shop mentality. Not the low pay, long hours of the NY garment district
that drives a 35 year old woman to ill health and near blindness after
10 years of constant grinding. No, this sweat shop is the high pay and
long hours rationale of the various research triangulations or gossamer
threaded valleys, that drives the 20/30 something crowd to ill health
and near blindness after 3-4 years of no sleep, no friends, and no life.
This is not an outside observation. I speak from several years of
experience, as a self employed consultant, working 70-80 hour weeks on
a regular basis with a few 95-105 hour weeks thrown in to meet a
deadline. This is not to say that I am condemning working hard. Who
hasn't had to put in an incredible effort to push a product or project
to completion. But those efforts, while considered necessary for the
moment, were still looked at as exceptions to the daily necessity. That
is not true of the demands of Internet time. They are incessant and
devouring -- the black hole of demands.
One might ask, is this really necessary? Has the curve really reached vertical? What hope is there for the future?
Those questions need to be asked and we might not like the answers.
10-7-96 FLN© The Dallas WinHelp Developers Conference
Generally, the conference was a success, with lots of useful information, particularly in the
interactions between the attendees. Everyone especially enjoyed the Microsoft Party on Friday evening with the free
complimentary Microsoft Microbrewery glasses, not to mention the wonderful suds filling them up. There was
plenty to eat, plenty to discuss, and good company to do it with.
One good thing about going in person to a conference like this is the opportunity to connect your online
contacts with their faces. There were people from England, South Africa, Australia, New Zealand and
points in between, not to mention Canada and the US. Jerry Mead, from the "Mother Country" said that
everyone looked and sounded pretty much as he expected. The assembled multitude took that as a compliment.
Ralph Walden's opening Keynote remarks about Html Help and Corey Bridges' closing Keynote session on Nethelp
provided a nice wrapper to the theme of the conference: WinHelp is still WinHelp but will soon have a bigger brother
fueled by HGH (Html Growth Hormone) that will be a Renaissance relative, well versed in all things online.
The sessions were uniformly informative but especially impressive was the team from Forth Shift
Corp. Their "Zen and the Art of Help Automation" was an interesting presentation of an impressive
development effort. The problem throughout the conference was triage: how to allocate one's time to the
wonderful plate of possibilities.
The Vendors reception on Thursday provided opportunities to see what everyone was
doing with the new html paradigm. All of the tool vendors had something to show. For WinHelpers, Blue Sky
showed their new utility for field level (What's This?) help that will revolutionize the process and also includes
workflow features. This is must buy for program help authors. It was good to see HelpBreeze putting their
toe in the Vendor waters, since they have a good, though relatively unexposed tool. Those who left early missed
the talented clown who closed out the evening with a prenuptial tribute to HyperAct's Ron Lowey.
The html heavyweights were there also showing their wares. Both Netscape and Microsoft had
booths. Ralph Walden and Peter Plamondon represented Microsoft and showed Html Help to anyone who
wanted to see it and discuss their pet issue or functionality. Ralph is exceptionally open to
suggestions. He made a point to make sure all your issues were noted and either addressed or he gave you
an explanation of why not. Get your ideas to him ASAP - his venue of choice is the Compuserve Hypertext
forum run by WUGNET and our own William Meisheid is a sysop. The keyword is Go Hypertext.
The guys from Netscape, Corey Bridges and Jim Horn of Netscape were in their booth discussing anything
anyone wanted to see in NetHelp and enthusiastically representing their approach to the help future.
They also plan on showing up on the Compuserve Hypertext forum Real Soon Now...
The advantage of staying up late Thursday night at the downstairs bar, not to mention the fine
company of the people from Blue Sky, Doc-To-Help and HyperAct and others, was that Joe Welinski of
WinWriters started showing his hospitality by buying three rounds of beverages for all. Thanks Joe.
You are a gentleman and a scholar to boot.
Saturday night a few of the remaining troops went out to dinner at a fine Cajun restaurant, that
demonstrated its quality by having truly tender calamari, which Paul Neshamkin assured everyone was rare.
Afterwards a number of the attendees went to see Extreme Measures at the AMC Grand, a 24 theater entertainment mall. It was a
unique experience for those not used to the stadium theater design with SDDS sound (every one of the 24 is setup that way).
They do things in a big way in Texas.
Well folks, that's the overview. We now look forward to Seattle in February. But first, here's hoping MJ Pilaster and Alec
Sonenthal got some rest because they were both wiped out on Saturday, winding down the post-conference items.
Also, best wishes to Ron Lewey of HyperAct as he gets married this week.
10-8-96 EM© WinHelp & HTML Help: Siblings bridging the information gap - The Past Meets the Future
WinHelp accidentally became the most used hypertext medium in the world, only surpassed by the recent emergence
of the World Wide Web. Though originally designed for program help it soon became obvious that WinHelp was a flexible
online hypertext publishing medium.
Authors and users immediately saw WinHelp's potential and began stretching the limits of the environment. Once the help
authoring tool vendors added tracking TOC's and full text search to WinHelp, such as Blue Sky's High Performance Tools
or Doc-To-Help's Navigator coupled with Viewer version one's search engine, information poured online using the environment.
It was WinHelp's extensibility through DLLs that fueled this growing cottage industry. Everyone was becoming information
publishers, from the corporate technical writing group to a person on their home PC.
However, the WinHelp environment was generally ignored by Microsoft.
There was little funding for the release of the 32 bit version of
WinHelp and the feature set all but ignored its real world use as a
general purpose online information medium. Users screamed at the
non-tracking, non-persistent Contents tab. The beta only included
programmers, not technical writers, so bugs and functional holes
abounded in a product that never got stretched. For the first seven
months after its release, first as part of NT 3.51 and later in Windows
95, 32 bit WinHelp languished. Even people releasing 32 bit products
were still prone to use the 16 bit version since they needed backward
compatibility to their 16 bit products.
Then two things altered the landscape forever. In November of 1995
Microsoft did an about face and openly switched the whole company to an
Internet foundation. Everyone wondered how this would play itself out.
Then on February 6th at the WinWriters'
WinHelp 96 Conference in Seattle, Ralph Walden, the help programming
lead, in the statement heard round the world dropped the HTML Help
bombshell. WinHelp was frozen and all new development and releases for
Windows Help would use an HTML environment, which would include a
compiled/compressed version similar to current WinHelp. In one fell
swoop the landscape had been changed. Compiled/compressed HTML would be
It is interesting to note that hypertext on the PC began as file-based hypertext but creators and users clamored for a compiled
version to make the creation and distribution of information easier. WinHelp was and is compiled hypertext. The Web came
along and HTML pushed us back into the filed-based hypertext era, in some ways a serious step backwards. In his
announcement, Ralph Walden, whether by accident or design, moved HTML back to the future with compiled/compressed
creation and delivery.
The weeks and months that followed included extensive speculation about where the HTML Help team would take us.
Netscape responded with NetHelp, their own vision of the online help future. In small and large corporate environments
everywhere, people began to wonder when to shift and how to prepare. If was not a concern. It is only when and how.
Everyone looked forward to the public release of Microsoft's specifications and Netscape's response.
The two week period between the end of September and the first week in October, sandwiched by WinWriters' HTML
Help JumpStart Conference in Seattle and The WinHelp Developer's Conference in Dallas, marked a convergence of
Windows-based and Web-based hypertext concepts. Between Ralph Walden's opening Keynote remarks
about HTML Help and Corey Bridges' closing Keynote session on NetHelp in Dallas, the reality of the finality set in.
As the cloud of future shock began to dissipate, help writers and
designers realized that their underlying skills and knowledge base had
found a new field in which to grow. Everything has changed, yet in a
way everything is still the same. WinHelp was still WinHelp, whether
delivered from an RTF or HTML environment. The new paradigm, fueled by
HGH (HTML Growth Hormone),
will give the current authoring community the chance to be Renaissance
people, well versed in all things online. One of the corporate
realities was that WinHelp technical writers were being kept out of the
HTML expansion. Turf battles over who owned HTML in the corporate
landscape were common and the writers generally lost and were locked
out. However, now these writers had a legitimate way in the door. The
marketing department can't do HTML Help, but the technical writers
could and will soon have to.
So, the more things change, the more they remain the same. Good writing, information chunking and presentation skills
are sorely needed in the HTML world. Check out almost any web page if you have any doubts. Microsoft and Ralph Walden
have given the vast field of technical writers proficient in WinHelp and online hypertext a way into the HTML ballgame.
Thank you guys. We are indebted to you.
8-22-96 EM© WinHelp: Microsoft's poor stepchild
WinHelp is the hypertext environment it is today by accident. It was not by Microsoft's design.
WinHelp has always been a poor stepchild that made most of its advancement in life by being adopted by
people other than its original parents. Those parents could at best be called neglectful, at worst, self-interestedly
destructive. They are not unusual, however, among technological progenitors.
Abandoned except when the parents had a specific need, WinHelp was immediately adopted
by the larger community, which cared for it well, bringing out potential the parents still fail to acknowledge.
They instead showered accolades and family resources on WinHelp's better cared-for siblings, Multimedia
Viewer and MediaView. It was not long before they also suffered WinHelp's parental neglect, but they have
not had the eager fostering that has been WinHelp's good fortune.
More to follow...