I've been away for a couple of days so I'm late to this discussion. As a strictly Frame to PDF user (with heavy use of conditional text), I have no XML or Structured Frame experience, but I can see huge value in what Joseph is proposing.
There is no way I can make an ROI case for moving to Structured Frame - and I've done my homework on this - though I can see real potential in it. But it would be even better if I could do some of the things suggested in the discussion below, eg single sourcing to include knowledge base output without jumping through hoops. I can also see the potential long term business value for Adobe - even if they have their heads stuck in the last century. So in answer to your initial question... No, I don't think you're all wet. And if Adobe continues to ignore this potential, maybe there's someone out there with a business plan who can take this idea and run with it. Alison Alison Craig Technical Documentation Lead 604-279-8550 | fax 604-279-8559 | toll-free 1-866-437-9508 Ultrasonix Medical Corporation | www.ultrasonix.com<http://www.ultrasonix.com/> [cid:image001.gif at 01CD43D1.1DB995A0] From: framers-bounces at lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] On Behalf Of Joseph Lorenzini Sent: Saturday, June 02, 2012 8:01 AM To: FrameMaker Forum Subject: What's your top feature request for FrameMaker 11? 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/attachments/20120606/5710ff8f/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2038 bytes Desc: image001.gif URL: <http://lists.frameusers.com/pipermail/framers/attachments/20120606/5710ff8f/attachment.gif>
