What's your top feature request for FrameMaker 11?

[Joseph Lorenzini]

Hi all,

I replied to the adobe forum post soliciting feedback for feature requests.
I got some push back on this. So I am curious what other people think of
the following idea. Am I all wet or is this just far less important than I
think?

FrameMaker should be converted into a true XML authoring environment. There
should be no structured or unstructured frameamerk. There should just be
FrameMaker, which has XML files. When I upgrade to the latest version of
FrameMaker, all my binary files should be converted into XML documents. You
should publish a XSD that defines the XML doc structure and leverage the
existing XSLT engine, so that out of the box any FrameMaker book can be
converted into any publishing format the user would care to. And also allow
the user to design their own XSLTS to convert into some other format that
people haven't even thought of yet. That way I can truly single source all
my content in FrameMaker instead of having to use the buggy Framemaker to
Robohelp integration.

In addition, provide a GUI that allows me to design a template and
structure (similar to structured framemaker ) that allows me to perform
schema validation of the structure and enforces controls on what the
template may contain. Basically, this would just be a port of EDD more or
less.

the point is that FrameMaker fundamentally needs to be an XML authoring
environment instead of XML authoring kinda sorta supported if you are
willing to bite the bullet and convert to structured FM. Increasingly few
people can do so because the cost is so high, its hard to make a business
case. I know I can't and I have looked into this extensively.  Adobe has
tried to pretend that converting over to structured authoring is easy but
in order to do this they have to have SEVEN webinars or a 7 hour training
session just to give the basics!! While a huge change, I believe this one
architectural change will provide the framework to address many of the
other problems and competitive disadvantages framemaker has with other
products out there.

These other problems are: version control, data structures, and publication
formats.

I currently place framemaker files in SVN and that works decently but
because they are binary files I can't ever do diffs and FrameMaker's built
in diffing capabilities is incredibly clunky and doesn't scale well at all.
Furthermore, hello binary bloat in the source control repository. It would
be amazing if instead I was committing XML files.

In my opinion, FrameMaker's core competitive disadvantage is that the Book
to PDF paradigm is dead. By that I do not mean PDFs and user guides are
dead, I mean that instead of having only one format to publish to (PDF) and
data structure (user guide or book) there are many other publication
formats and data formats (e.g knowledge base) that are of co-equal
importance.

As long as one stays strictly within book-to-PDF only paradigm, FrameMaker
is awesome. The moment you go outside of that FrameMaker becomes very, very
clunky, where you need to either use special tools (like Mif2Go) or use
RoboHelp as a publishing engine (which has its own pain let me tell you).
 One of the things i love most about FrameMaker is its powerful single
sourcing capabilities. I want to use FrameMaker to be a single repository
of all my content and I want to be able to publish that content in whatever
format i choose. I believe one way to do this is to make FrameMaker a true
XML authoring environment and use a powerful XSLT engine to convert the
content into whatever format I want. The benefit of this particular
approach is that its not just a solution but its an extensible framework.
In theory, if the next hot format and data structure comes out tomorrow, I
should be able to contract out,  design myself, or buy an XSLT that will
generate the output that I desire.

Put another away if I didn't need acrobat professional to handle PDFs, I
would have switched to a tool like Flare a long time ago. If there comes a
day when my audience no longer needs or cares about PDFs, that's the day I
get rid of FrameMaker. That day isn't now but that could quite easily
happen in the next 5 to 10 years. I really like FrameMaker but it has
failed to stay current with the needs of technical communication industry
and its only stayed alive because of a currently large dedicated user base
and because PDFs are still one of the primary modes of communication.  I
predict that when the later goes away so will the former unless Adobe can
present a value proposition that no longer relies on vendor lock in and PDF
usage.

Sincerely,
Joseph Lorenzini
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frameusers.com/pipermail/framers-frameusers.com/attachments/20120602/6e802194/attachment.htm>