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:Creating help for Win 31 *and* Win95 From:TREVOR -at- MDLI -dot- COM Date:Tue, 16 Apr 1996 16:20:11 -0800
This is a repeat of a message I sent to the WinHelp list:
I noted with interest the discussion on whether or not to
implement Win95-style "What's This?" help. It opens the greater
question for many writers: How to provide help for Win95 users
AND the many users planning to remain with Win31?
You may be interested in the following document, which I recently
circulated in-house to explain why my group plans to NOT offer
any Win95-specific help functionality for our next application
running on Win31, Win95, Mac, and SGI. (Doc is edited for
Your comments would be welcome.
Senior Team Manager
MDL Information Systems, Inc.
Disclaimer: Usual stuff (I don't represent the company, and so
Subj: Windows '95 Online-Help Functionality
In order to maximize the amount of precious writer resource
devoted to online-help *content* over that devoted to support
activities, the strategy of the writing team has been to create
and maintain ONE set of help source files that can easily be
ported (with no editing) to the Mac and SGI. This strategy
served us very well for version 1.0.
However, for Windows '95 online help, Microsoft has made a number
of functionality changes over Win31 that threaten this strategy.
This message addresses the four most visible changes in Win95
help and explains why we do NOT plan to implement them.
WIN'95 FEATURES WE DO NOT PLAN TO IMPLEMENT
1. CONTENTS TAB: This is what you see when you first choose
Help>Help Topics and is one of the most visible changes to the
end user. For our existing help files, it creates a number of
a. It cannot include graphics. Therefore, we cannot exactly
reproduce our existing ToCs.
b. It cannot be resized. Our ToC topics in this format cause the
window to scroll. We went to great lengths to make our ToCs NOT
c. To get to any topic from the Contents tab requires 2
double-clicks; from the Win31 ToC, it requires 1 single click.
That is, MORE mouse clicks are required of the end user in Win95,
d. Many of our hard-coded "Back" buttons would need recoding,
causing us to maintain two, concurrent versions of our help
e. According to Joe Welinske (of WinWriters; publisher of
"WinHelp" magazine and coordinator of the WinHelp Conference):
"Although the Contents tab can work with Win31 files running
under Win95, it is hard to envision how the same help system can
be constructed to be effective with and without a Contents file."
In summary, unless a help file is redesigned from the outset to
work with a Contents tab, the end result can be LESS effective
for the end user. An effective Contents tab would require
creating and maintaining two concurrent sets of help source
files. This would create unnecessary logistical problems and be
great time sink. We plan to keep our existing (and usability
2. HELP MENU: Microsoft has elected to have one item only on the
Help menu ("Help Topics"). Our end users, on the other hand,
like shortcuts to selected help topics. We intend to maintain
our existing menu commands.
3. "WHAT'S THIS?" HELP FOR DIALOGS: Click the "?" button and then
click a dialog feature to get "balloon" help.
a. As many usability tests have shown (including our own), users
need both contextual help material and associated procedures
available from within dialog-box help. The "What's this?"
functionality, as implemented by Microsoft, does not provide
b. Our current list of dialog-box contexts for insertion in the
executable code would increase from approximately 125 contexts to
about 650, each of which must be implemented in the code and
tested. This makes a huge amount of additional work for Writers,
Programmers, and QA.
c. It is not yet known if this feature will be supported by the
porting tools for Mac and SGI.
d. It would require creating and maintaining two concurrent sets
of help source files for Win31 and Win95 (plus possibly Mac and
SGI). This would create logistical problems and be a great time
4. SHORTCUT BUTTONS: When a user is reading an online-help
procedure, instead of (for example) having to "Choose File>Open"
to access the File Open dialog box, they can simply click on a
"shortcut button" within the help procedure to automatically open
the (real) dialog.
a. Writers would need to create a WinHelp macro for each shortcut
button. Each of these macros would need technical information
(and assistance) from Programmers to invoke the relevant dialog.
There could be up to 125 of these macros. This adds work to
Programming and QA.
b. Currently, this feature cannot be ported to the Mac and SGI.
c. It would require creating and maintaining concurrent sets of
help source files for Win31, Win95, Mac, and SGI. This would
create huge logistical problems and be a great time sink.
Post Message: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Get Commands: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "help" in body.
Unsubscribe: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "signoff TECHWR-L"
Listowner: ejray -at- ionet -dot- net