Re: Single Sourcing, Design more than tools

[Susan Harkus <susanh -at- CARDSETC -dot- COM -dot- AU>]

Kathy Stanzler wrote...

But for those of us who are not programmers and don't have either the
desire or the ability to create our own solutions, we have to work with
what is available commercially, such as it is. What options are available
to us?

Kathy, I think we have lots of options because I don't believe that
single-sourcing is just a tool/technology issue. It is much more a
designing-information-for-use issue.

I take single-sourcing to mean "have a single source for each part of the
information domain".  The key is identifying discrete parts that can be
produced in one form and delivered, as required by users, in several forms.
That is, you have two high-level tasks: divide the information domain into
parts and choose a source development approach for each part that enables
appropriate delivery.

How do you?

Well, in my current project, I divided the information domain up in much
the same way as any writer would, determining which information the user
would require as task and product reference, and which information would be
tied directly to the product as context-sensitive Help.

Naturally, there was context-sensitive, field level Help. Then there was
context-sensitive product task Help = the information, hints, warnings,
guidance you might want if you were at a dialog (application context) and
wanted to feel more comfortable about what you were doing. Microsoft calls
this "task Help" in their guidelines but it shouldn't be confused with help
about the real task as seen from the user's perspective of task objectives
and constraints.

It was easy to assign both types of context-sensitive information to the
Help source.

Reference (=administrative and business operations) information was more
interesting. Some people like printed versions of up-front or reference
reading materials. Some people like to have online access to that type of
information and the same information is also the umbrella for the Help. I
had to choose a source  development strategy that would enable three
different outputs.

At this point, tools really do count. My Help authoring tool, HDK, is very
powerful and provides the Help and HTML solutions. So I am creating Word
documents using Word features such as heading styles, bookmarking and
cross-references in particular ways and am generating the Word documents
    as pdf for user printing
    HTML with embedded TOC for standalone online reference
    Help file which is merged with the multiple context-sensitive Help
    files and which becomes the browse path of the merged Help files

Sarah O'Keefe stressed the importance of modularity and modularity has to
be a primary design objective, right down to the thoughtful packaging of
information within documents. For example, you need to plan document
sections that are acceptable Help topic or HTML page chunks. It really
isn't difficult and it doesn't constrain the ever more important objective
of grouping information atoms to answer user questions.

Down the track there will be training materials to position within the
information domain... that will be another challenge

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=