Help MVPs‎ > ‎Help History‎ > ‎

Sageline-Blog

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

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

Getting Started
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 industry.

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

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

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

How do you contact us?
Leave us e-mail at Sageline.com

Comments