Re: Multi-purpose / Single source

Subject: Re: Multi-purpose / Single source
From: David Neeley <dbneeley -at- gmail -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Wed, 5 Jan 2005 15:44:28 -0600


First, I just discovered on another mail list a compilation of XML
editors of various sources (since you asked!):
http://www.xml-dev.com/xml/editors.html

I'll make several comments inline to continue the discussion just a bit...


On Wed, 5 Jan 2005 15:55:27 -0500, T.W. Smith <techwordsmith -at- gmail -dot- com> wrote:

>
> Yes, but doable, IMHO, morseo than XML + database expertise.

I disagree...and there are various CMS products out there that serve
admirably for data storage of XML...with relatively little complexity
from the user's perspective.

>
> > Next, with Frame and WWP, a complex solution is often outsourced for
> > setup to consultants.
>
> It doesn't have to be.

No, it doesn't *have* to be...but often is when complex
multi-versioned projects are contemplated. Often, this is easier,
faster, and cheaper than trying to develop the expertise inhouse.

> > Remember the post that said that the *manager*
> > must do a highly conditioned Frame project with many variables and
> > couldn't even turn it over to writers in her group because of its
> > complexity?
>
> I recommend considering more seasoned writers.

Not always an option, I'm afraid. Additionally, the conditions can be
much more flexible with XML than with Frame...often making the
resulting process easier, faster, and simpler to manage as the output
is updated in future. Tracking the various requirements of complex
variable text conditions in Frame---and the relative lack of
flexibility in using them and thus designing the conditions well to
begin with--is neither pleasant or fast, in many cases.

> > Do you suppose this is a mark of an "easy" solution? I think not!
>
> Nope. But I disagree that FrameMaker and/or WWP are unusable by
> run-of-the-mill tech writers. They are just tools.

So are XML authoring tools. We would hope to see a minimum of
"run-of-the-mill" tech writers on complex projects, but such is not
always something we can control, either.

>
> Well, I don't agree that FM + WWP must be outsourced. I do agree that
> XML is more flexible. But, I recommend considering what you want to
> use the content for. If for print (incl. PDF and press) and online
> help, then the range of your flexibility is defined and FM +_ WWP
> meets it. Want more flexibility? Go with structured FM for now + WWP,
> so you can go to XML at some point in the future if needed.

You are putting words into my mouth again...it is not a case that
these projects "must be outsourced" and I have not said so. Thus, your
disagreement is not with me on this point.

Since "Structured Frame" *is* XML (or SGML, for that matter), this is
not a case of "for now." In addition, using structured Frame you have
options of incorporating other XML-related tools and processes more
easily. Often, the best solution at any given time is a compound
solution, matching the best tools to the job.

> > Your focus seems to be nearly all on the authoring environment.
>
> My thoughts are that an efficient authoring environment lets the
> author focus on content, yes.

I would submit that most GUI tools are *not* particularly "efficient".
In fact, at some point I am going to learn a great deal more about a
tool called Lyx as it may be developed or extended for tech docs--or a
similar tool created, perhaps, for the purpose. This allows a "What
You See is What You Mean" approach that is much more efficient than
traditional authoring tools. It also may enforce a better use of
styles on projects, with fewer of the style overrides that seem to
accumulate in projects done by the afore-mentioned "run-of-the-mill"
tech writers! http://www.lyx.org

> This
> > is a non-issue today, since more and more XML authoring tools have
> > gained many of the same sorts of "bells and whistles" as other, older
> > tools.
>
> Such as? I submit that FrameMaker, Ventira, and even Word are much
> more efficient as authoring environments than XML Spy or XMetal.

There's that pesky "efficient" again. I would assert rather strongly
that Word is rarely "efficient" from a document lifecycle
perspective...but that is grist for milling during another day's
run...


>
> Agreed. This would be a consideration. In fact, I might be persuaded
> to hold off grand plans of single sourcing until I see what happens
> with FrameMaker with regards to Longhorn in 2006.

Frankly, I'll not hold my breath to discover what Longhorn actually
*is* when it ships. By that time, with any luck I'll be working mostly
in UNIX or Linux (or Mac, which I consider these days a variant of the
first two...).

> Okay. I don't put much stock in what Adobe CEOs say, to be honest.
> But, I see what you are saying. With a large FrameMaker installed
> base, are you saying that Adobe would discontinue FrameMaker without
> providing a reasonable way of migrating content to InDesign or
> whatever?

Yes, that *is* what I'm saying, based upon the rather less than
successful "migration tools" for PageMaker docs into
InDesign...including their special version designed for the purpose.

In my opinon, Adobe has mis-managed Frame from the earliest days they
owned it. Unfortunately, that mis-management seems to have been
continued. Dropping any native support for OSX, for example, I regard
as a mistake.

In addition, Adobe has exhibited a rather extreme reluctance to fix
problems that have existed in Frame from version to version to
version. (Much the same as Microsoft, if it comes to that...).

On the other hand, if they continue to improve InDesign and
incorporate equivalent long-doc features and XML capability into it,
the resulting product may in fact be outstanding. I use InDesign for
various projects now, and for highly styled docs such as marketing
materials and such it is a very nice tool. I also like its continued
integration with Photoshop and Illustrator...but again, that is
another matter.

I am *not* convinced, though, that conversion from the existing Frame
files to InDesign will be less than extremely painful.

>
> FrameMaker is still best of breed. If it were discontinued tomorrow,
> the installed version you have would continue to work on your current
> OS for a decade. No worries.

FrameMaker today has some distinct lacks...such as multiple platform
support, for instance. If your world will be continuing as an entirely
Windows-centric one, then you may continue as you are with little
problem.

However, once Frame is finally gone, getting Frame expertise in new
hires will become increasingly difficult. Again, from a document
lifecycle perspective you had *better* be worried about these issues,
for they affect maintainability greatly.

> Well, InDesign doesn't do XML or long docs, right? So that doesn't get
> your documentation done. FrameMaker is an efficient way to author
> docs, today. FM + WWP can be done in-house, I argue and disagree with
> you there, and FM + WWP does not require database admins, programmers,
> or other technical support ... it's an efficient way of authoring
> content for publication that lets a writer focus on content.

Let's break your argument down a bit. First, I repeat I have *not*
said that FM +WWP projects *cannot* be done in-house. I suggest you
re-read the original description of the problem and my comments about
the existing conditions in the actual shop involved...whether they had
existing expertise in FM and WWP, for instance. This is one point you
seem to overlook consistently.

Although I write quickly, I do try to clearly set forth any conditions
on suggestions I make. Ignoring those conditions to assert what *you*
or *your docs team* can do at the moment is unpersuasive at best, I'm
afraid. I'd be much more impressed if you'd actually read what I wrote
rather than what you assume I wrote.

That said, a "pure XML" solution is also something that can and *is*
being done inhouse in more places than you might imagine. Your
continued assertions that it would *require* "database admins,
programmers, and other tech support" is (pardon the term) rather
silly. You may only be describing *your* capabilities at present
comparing the two approaches...which, I submit, is by no means
universal.

Again, the original proposition I gave was clear:

--->*If you have no advanced expertise in WWP, FM, OR XML*, I believe
the XML approach is similar in learning curve, more flexible for the
*given problem* (multiple variables), and not likely to be obsolete in
tne next year or two.

--->Conversely, if you DO have such expertise with one solution or the
other, then obviously that must be considered, too.

> So, if
> you suggest XML is more flexible than FrameMaker, yes, but what are
> your needs? If you suggest XML will outlast FrameMaker, yes. But
> what's the cost of going with XML now versus using the efficiencies of
> FrameMaker ... will there be a way to migrate FrameMaker content to
> InDesign or whatever comes next, etc. Dunno. It depends on your
> priorities, I guess.

Let me repeat one final time: Frame is *NOT* particularly "efficient"
for the neophyte...and jumping into a complex, multi-variable product
suite is *not* a cakewalk even for intermediate users.

My priorities, as always, involve the best solution for any given set
of circumstances, including all aspects of the product lifecycle. I am
not "married" to any tool or process.

By the way, I have used Frame since version 3.0 -- more years ago than
I care to remember.

>
> It's not a slam dunk. But, why invest in Windows. I mean, do you think
> Windows will be around forever? Consider all those companies investing
> in Microsoft Office ... surely that will go away, too. Etc.

Your point, please? Actually, I would *NOT* "invest in a Wijdows-only"
solution today when starting from scratch. That is why XML is
sensible, too--it is easily used on multple platforms. That said,
creating XML with Frame is perfectly acceptable to me if you have it
and if that is something you are familiar enough with.

> Sounds cool. Sounds like you are suggesting OpenOffice is a better
> choice for long documents than FrameMaker for Windows ... I don't know
> enough to disagree. What's the press output like? Can you get it to
> online help fairly easily? Etc.

Bruce Byfield, on this list, is rather a guru in OpenOffice and has
posted here on using it in documentation. I would not presume to be as
knowledgeable as he is about it...but no, I suspect that "long
document" production is not yet as polished as Frame's in some
respects.

That said, from what I've seen the features that work in OpenOffice
are often more stable than the equivalents in Word. (Can we say
"autonumbering" anyone?).

In addition, since its *native* format is XML--and, with the upcoming
version a standardized version that will be available in other tools,
too--then its ability to handle various XML tasks is far, far superior
to Word's.

For help creation, there are many avenues to get there. If all else
fails, with OpenOffice you can simply export to .rtf or .doc if you
wish and use the resulting file in the help tool of your choice.

David

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP X5 - SEE THE ALL NEW ROBOHELP X5 IN ACTION!

RoboHelp X5 is a giant leap forward in Help authoring technology, featuring all new Word 2003 support, Content Management, Multi-Author support, PDF and XML support and much more! View an online demo: http://www.macromedia.com/go/techwrldemo

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.



Follow-Ups:

References:
Re: Multi-purpose / Single source: From: David Neeley
Re: Multi-purpose / Single source: From: Sharon Burton
Re: Multi-purpose / Single source: From: T.W. Smith
Re: Multi-purpose / Single source: From: David Neeley
Re: Multi-purpose / Single source: From: T.W. Smith
Re: Multi-purpose / Single source: From: David Neeley
Re: Multi-purpose / Single source: From: T.W. Smith

Previous by Author: Re: giving appendices chapter numbers
Next by Author: Re: Help with Outsourcing Tech Pubs
Previous by Thread: Re: Multi-purpose / Single source
Next by Thread: Re: Multi-purpose / Single source


What this post helpful? Share it with friends and colleagues:


Sponsored Ads