[Date Prev][Date Next] [Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]

Long--Single Source - Continued



There are a few pressures here, that pull in opposite directions. On one
side, we all want to produce *useful* documentation - user guides, help
text, and so forth. While I don't see such a chasm between single-sourcing
and multi-sourcing, there are others that obviously do.

I write this after I just went through part of the process of following the
electronic version of Macromedia's Dreamweaver MX setting up to use a
tutorial (with ASP/database connectivity). Part of the documentation refers
to open a specific dialog box, and I quote:

To create a DSN: 
Open Windows' ODBC Data Source Administrator as follows:
In Windows 95, 98, or NT, choose Start > Settings > Control Panel, then
double-click the ODBC Data Sources icon. Depending on your system, the icon
could also be called ODBC or 32bit ODBC.
In Windows 2000, choose Start > Settings > Control Panel > Administrative
Tools > Data Sources.
In Windows XP, choose Start > Control Panel > Performance and Maintenance >
Administrative Tools > Data Sources (ODBC).
In the Dreamweaver dialog box you use to create a DSN connection, click the
Define button.

----[End Quote]----

Note the last sentence of the above where the doc makes reference to "In the
Dreamweaver dialog box...".

There is an assumption here that the users knows how to open that specific
dialog box. This type of writing has become more and more common as TTR
(Time To Release) of product shrinks. But, IMO, there is no excuse for
making these assumptions. (By the way, this part of the Dreamweaver
electronic doc is in the Appendix, reached after a link from "Database
Connections for ASP Developers").

I prefer some linearity <g>, at the very least, allow me to process the
steps in their proper order while I have the application open. I do not mean
to pick on Macromedia exclusively. Most of us see this all the time from
many documentation producers.

A relatively few years ago we were lamenting moving towards electronic
documentation and now, now that they are commonplace and accepted (?), we
discuss the means to produce them: chunking, linear, hypertext, and so
forth.

The shrinking margins of production, the dot-com deaths, and the dropping
stock market have added untold pressure to management to look for less
expensive means to get a product, with documentation, out the door. As a
result, in some instances, the user gets the product, but only an
after-market book gives proper credit to the application.

The real premise, the through-line of all that has been mentioned on this
forum, is developing *useful* documentation. I have repurposed,
single-sourced, Clustared (thank you, Jerrilynne Sanders), PDFed, chunked,
and hypertexted--as necessary to produce procedures and instructions that, I
do dearly hope, are meaningful. And that, I think, no matter what you
produce, is the key.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Zen meditation isn't what you think...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Dennis:Hays
Publishing Strategist
New York State Human Services Project
518.473.2579

and InFrame Publisher


** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **