Creating help for Win 31 *and* Win95

[TREVOR -at- MDLI -dot- COM]

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
external use.)

Your comments would be welcome.

Trevor Grayling
Senior Team Manager
MDL Information Systems, Inc.
Disclaimer: Usual stuff (I don't represent the company, and so
on).

--------------------------
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
problems:

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

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,
not less.

d. Many of our hard-coded "Back" buttons would need recoding,
causing us to maintain two, concurrent versions of our help
source files.

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
tested) ToCs.


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

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


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