Which is better: FrameMaker or InDesign?
[Note: This guest post was written by Peter Gold, who has been using and training both FrameMaker and InDesign for a number of years.]
Levi wrote:
Could someone explain to me the key differences between InDesign and FrameMaker and when I would use one or the other for technical writing?
This is such an easy question to answer! Ready? I’ll answer it with a question: Which software application does the person or company who is paying you want you to use?
It sounds like a smart-alec response, but it’s easy to see what whoever pays the bills gets to choose. There’s a little bit of wiggle room here: If an employee or team can convince the PTB (Powers That Be) to change software, by submitting a compelling case for changing applications, it’s possible to achieve the change. “Compelling” means convincing all the stakeholders — all documentation-team members must agree to embrace the product, and the PTB must agree to pay for training, and for converting the old content to the new product, and the cost of running the old and new systems in parallel during the transition. Of course, the chance of that happening is about equal to the likelihood of turning a supertanker within its own length.
Okay, let’s try a second question: What special outputs or deliverables are required by the project? That’s an important one, so let’s look at it a little closer.
Being a Technical Writer
Remember that good technical writing — gathering, organizing, digesting, and explaining complex material — is tough. But even if you do a great job of it, that information is useless unless it’s distributed.
Delivering the content, in usable form, is where technical publishing tools come into play. Here’s where that second question about special outputs and deliverables can dictate the choice of software tools.
Comparing Features
Can you use either InDesign or FrameMaker to create technical documentation? Yes. Do they both perform as well? Mostly. Can they do them as easily? Some features yes, some not so much. Are there any pluses and minuses that are deal-breakers for choosing one over the other? Definitely! So… what are they?
Recent FrameMaker releases have been steadily improving its ability to work with DITA (Darwin Information Typing Architecture). Briefly, DITA is a method of writing that breaks information into very small units, each with a specific purpose for organizing the information. The idea is that once an architectural plan is created for a project, and all the stakeholders agree to stick to it, then those bits of information can be stored logically, reused efficiently, and delivered promptly. If you’re thinking “ouch!” then you get the point.
The same goes for creating help systems. FrameMaker is part of the Adobe Technical Communication Suite (TCS), which includes RoboHelp, software that converts FM content to a variety of online help systems, and testing, training, and response-tracking abilities. InDesign isn’t made for this.
FM also has powerful XML abilities that are used for publishing from databases and converting among many different data formats. InDesign’s XML abilities are no match for FM here.
On the other hand, FrameMaker’s typographic composition ability is no match for InDesign’s cutting-edge abilities. FrameMaker can do many layout tasks that can compare reasonably well to InDesign’s layouts, but they’re usually easier to do in InDesign because it’s specifically made for this kind of work. The key question here is: How important is great, typographically-sophisticated, cool-looking, creative design to communicating technical information?
Both FrameMaker and InDesign have good e-publishing abilities. Depending on which release, one or the other is ahead. Both have room to improve, but then, the e-publishing field is evolving so quickly, probably no application is able to keep perfectly up-to-date.
Here are some specific feature comparisons between InDesign and FrameMaker that may influence your choice toward one or the other:
| Feature | InDesign | FrameMaker |
|---|---|---|
| Adding pages when typing, importing, or pasting content | Learning curve | Easy |
| Import comments from PDF for editing in creating application for efficient editing workflow | Requires third-party plug-in (See Annotations plug-in from DTPtools.com) | Yes |
| Text variables for running headers, footers, and user-defined text | No text wrap; don’t support multiple character styles | Yes |
| Multiple TOCs, lists, and indexes, entries create hyperlinks in PDFs | Possible | Easy |
| Paragraph, character, table, and object styles | Supports many more text attributes, can base styles on others | Fewer attributes, can’t base styles on others |
| Cross-references for text become hyperlinks in PDFs | Cross-document x-refs are fragile | Cross-doc x-refs are stable |
| Multi-file books, and operations across book files, like find/replace, spell check, synchronize settings | Yes | Yes |
| Manage and publish books within books for complex document sets | No | Yes |
| Importing many text and graphic file formats, and maintaining links to sources | Yes | Yes |
| Importing content from word-processing software like MS Word | Yes | Yes |
| Updating multiple instances of linked content | Yes | Yes |
| Managing styles when importing and loading documents | Yes | No |
| Managing styles used and unused | Yes | No |
| Master pages that control body page layouts | Yes | Yes |
| Master pages based on others | Yes | No |
| Conditional text for outputting different versions | Yes | Yes |
| Auto-numbered and bulleted lists | Yes | Yes |
| Page, section, chapter numbering within documents and across books | Yes | Yes |
| Anchored frames in text flows | Yes | Yes |
| Keystroke shortcuts for almost all commands | Yes | No |
| Saved workspaces | Yes | Yes |
| Professional drawing tools with layers and transparency | Yes | Basic tools only, no layers, no transparency |
| Interactive multi-media and e-publications creation | Yes | Yes |
| Data merge for data publishing | Yes | No |
| Support for third-party plug-ins and scripts | Many | Fewer |
| ExtendScript Toolkit provided | Yes, from the beginning | Only recently |
| XML authoring and round-tripping | Weak | Strong |
| DITA authoring and publishing | No | Yes |
| Specialized help systems authoring | No | Yes, with RoboHelp |
Why Does Adobe Sell Both Programs?
As to why Adobe maintains these two applications, it’s not so easily answered now, as in the past, when there were more differences between the products. FrameMaker was early-on the best-respected and most widely-used technical publishing software, especially in high-tech industries, and government-regulated industries like pharmaceuticals, automotive, and airplane and aerospace. FrameMaker had many of the essential features that were essential to creating complex, long, information-rich technical publications. Many or most of the software and hardware user manuals that “nobody ever reads” were written by technical writers using FrameMaker, years before InDesign was even an inkling in anyone’s eye.
InDesign debuted as a layout program for designers who created and produced print publications. As users requested and demanded more abilities, features, power, etc., ID evolved. Many of InDesign’s long-document features – multi-file books, cross-references, indexes, multi-level auto-numbered lists, adding new pages automatically as content grows, conditional text, change-tracking, among others, were added as users requested these abilities that are necessary in working with documents that are longer than typical designed documents like brochures, posters, and booklets. You could have said that InDesign was channeling FrameMaker.
Two Users, Three Opinions
Converting FrameMaker content to InDesign, or InDesign content to FrameMaker, is imperfect at best, and round-tripping is even more imperfect. Because converting back-and-forth is complicated, it’s important to make a choice rather than hoping to exchange files between users by converting them from one to the other. In other words, collaboration requires that all users use the same application. This could mean that all users create in a neutral application, like MS Word, or a plain-text application, and then import the completely-finished content into the chosen winner.
I’ve posted more than a few times in various Internet forums about comparisons, contrasts, and considerations that go into choosing between InDesign and FrameMaker for technical writing projects. In looking back, it’s interesting to see that I’ve not changed my position about which product is better… it’s still: “it depends.” Of course, because I’m writing from my personal and professional point of view, remember that every statement starts, contains, or ends with: “in my opinion.” So, if you want more opinions, search the Internet for terms like “technical writing indesign,” “technical writing with framemaker,” “technical writing with adobe technical communications suite,” and “choosing software for technical writing and technical publishing” (without quotes).
In particular, visit https://www.techwr-l.com to get insights from members of one of the largest technical-writing communities in the world. Folks there use InDesign, FrameMaker, RoboHelp, ArborText, QuarkXPress, MS Word, TextWrangler, and so on and on, every day, and overall they have experienced everything to love and hate about how these tools satisfy their needs as technical writers.
 |
It’s been at least ten years since I used FrameMaker for daily work but I miss its speed, especially when working with tables. But, it had a most irksome flaw, its inability to break footnotes across the page. (Has this been fixed?) And, it’s now Windows only. I ditched it when the Mac version was canned.
LTM
I completely agree, and as of FrameMaker 2017, NO, this has still NOT been fixed. It’s a big drawback for serious writers!
A good summary, but you missed one very important consideration: Framemaker ONLY runs on Windows computers. That means Mac users MUST use InDesign. They don’t have a choice!
True, but with a caveat. If they have an Intel Mac and a copy of Windows installed, they would be able to use FrameMaker.
I think at this point the primary reason Frame still exists is that it can do structured authoring while InDesign can’t. It is a shame that the “XML support” of InDesign is so useless and irrelevant to true structured authoring, but it does give Frame a niche market that will probably go on for many more years.
While InDesign failed with XML authoring, there was a time when InDesign had far worse long document features across the board (I remember the days when it didn’t even have tables!) yet these have been steadily added over the years. It does not appear Adobe will ever have the guts or budget to add true XML support, which would be a huge effort.
Every so often we see tech doc groups forced to work in “DITA with InDesign” which is a pretty good prescription for disaster. InDesign is the ultimate rendition engine for XML but the superficial “marketing only” level of XML authoring support is one of the few historical screwups in the history of this otherwise amazing product.
To give some historical perspective as to why the XML support was built in such a comical, useless way, remember that at that point in time InDesign had still not defeated Quark, and Quark would literally hire people to show up at Adobe presentations and call from the back of the room, “does InDesign support XML? Quark does…”
Getting the word “XML” on the InDesign box as fast as possible was the primary goal, and the only goal attained by the InDesign team regarding XML. Later they did come up with the “XML rules” concept to express some comprehension of the fact that their XML support was so ridiculous, yet XML rules was still only useful for publishing, not authoring, and any serious InDesign automator had zero use for these either.
Good history, Max.
It’s no surprise that market demand accounts for many new features, or enhancements to the, in most products.
Over the years that InDesign’s long-document features have become increasingly competitive with those of FrameMaker, I’ve not seen many requests various forums from FrameMaker users asking for help with migrating legacy documents to InDesign, or assistance with using InDesign to accomplish tasks they formerly did in FrameMaker.
Does anyone know of reliable data on the number of technical-writing users who work
* in FrameMaker, on native Windows (or even use old releases on Macintosh or UNIX platforms)
* in FrameMaker within a Windows emulator on Macintosh
* in InDesign (on either Windows or Macintosh)
Does anyone know the number of technical authors who remain with FrameMaker even with the option to move to InDesign because
* migration – document conversion, training, vetting with parallel systems – costs can’t be justified
* InDesign can’t perform all the requirements of their projects
Without useable data, the relative value of either application is opinion and speculation.
Oh, BTW, the rumors that FrameMaker is at end of life are and have been seriously premature.
John Warnock, in an interview with Knowledge@Wharton:
‘In the case with FrameMaker, the FrameMaker architecture was infinitely better — infinitely better — than the Aldus architecture. I could never get anybody except the ex-Frame employees at Adobe to understand that the architecture was fundamentally more sound in FrameMaker than in Aldus. The Aldus side won, essentially, with [the development of Adobe’s page layout product] InDesign. We’re still trying to catch up to FrameMaker.’
It would be great if some neutral and knowledgeable person would make the case, feature by feature, module by module, etc., for which application’s code architecture is more robust and uses development resources more efficiently in extending the product’s features and performance.
I don’t doubt John’s view has lots of validity. But, for example, from the FrameMaker teams over the years, we’ve heard that new feature development and enhancements have been difficult to achieve, because the code was based on early designs that weren’t easily extensible. And from the InDesign side, from the beginning, there was the claim that the design – a main engine that powered independent plug-in modules for almost every feature and function – was easy to maintain and extend.
Perhaps John’s referring to specific design choices, such as the InDesign decision to treat text variables as single characters, which prevents them from wrapping across line endings and other boundaries, and prevents the insertion of multiple character formats with them. FrameMaker text variables have always been able to do these things. So, at least in this case, early design decisions have obvious user advantages or disadvantages.
Adobe will never give away official numbers but from what I have seen over the years, my impression is that Frame users number in the low hundreds of thousands.
Both applications have their brilliance in terms of the level of abstraction: InDesign was created far later and is definitely very powerful in terms of exposure to automation. I wrote a blog about this at https://medium.com/tech-talk/a708cda55921
Frame has lasted so long, it certainly was built with a very brilliant architecture, yet:
1. The code base is so old, it is nowhere near as fun to automate, and
2. It is really not at all as graphic-intensive; it is really a different beast in terms of the challenges it solves.
Frame is very flow-centric: Frame allows you to pour in content and formats in a consistent way. It is fantastic when you have long documents that have the same layout page after page.
InDesign, on the other hand, allows for content being managed from an almost purely graphical perspective: it is good you want to do more unique, page-oriented layouts.
The differences were more obvious when InDesign started out and the long document features were so absent. Over time InDesign has covered some of the gaps in managing flowing, long, documents, but they never found justification to tackle anything at all like the “structured mode” of FrameMaker.
Only an extraordinary genius such as Lynne Price could have invented such a thing, and certainly the flow-centric nature of FrameMaker provided some fundamental limits and focus that helped her build such a strong and well-proven approach to WYSIWYG XML authoring.
If InDesign were to tackle XML authoring it would probably require something as extreme as a “structured mode” and even then it would not be obvious exactly what approach to take. Adobe has generally had far greater success with rendition than with data/semantics.
While I would love to see Adobe accept this “toughest possible challenge” (I wrote the XML Handbook chapter on WYSIWYG XML Authoring, and have run an InDesign-centric company for 13 years) I have to accept that their economic analysis that caused them to punt back in the CS2 era was probably correct. IF successful (a big “if”), it would make the world a far better place, but would probably not generate the $100s of millions they could attain from, say, buying another company like Omniture.
When I first got into publishing in 1999, I used FrameMaker because it was vastly better (in different ways) from the alternatives, Word and PageMaker. I moved to InDesign when Adobe quit upgrading the Mac version.
There’s an important distinction between the two that matters a lot if for someone working on long, constantly changing documents with numerous illustrations. InDesign is page-centric. It assumes that users are defining how a page looks. In many cases, that’s precisely what is needed.
FrameMaker cares little about where pages break. That makes all the page reflow that results when an additional paragraph is added much easier. Even more important, FM can display intelligence in that reflow. A graphic can be tagged to appear in the outer right corner of the page accompanying that text and it’ll be there no matter how many pages of text or added or removed. With ID, you can either fix a graphic on a page, where it will remain no matter how much the text on that page reflows, or you can make that graphic a part of the text itself, with results that can be unpredictable when text is added or removed.
There’s an aspect of FrameMaker’s core philosophy that those who’re working on ePub standards have yet to realize. Graphics are typically big and bulky, which can pay havoc with page breaks if they simply come where they come. We’ve all seen ebook readers where a page breaks halfway down because a picture won’t fit in the space that remains. The result is most ugly.
FM does right what ePub should already know how to do. Those doing Ppub documents need to be able to dictate that a graphic in the text flow doesn’t go “here” with all the bad results, but in some fixed place, i.e. at the top of the next page. Then there would be no awkward text breaks and the text can then refer to it as “the picture that follows.” Even better would be the ability to dictate that on every page from Point A to Point B, the ereader page would contain a thumbnail that links to a large illustration for that text segment.
In short, FM was designed to handle constantly reflowing text well. If that’s what you are working with, it is ideal. That’s also why it’s unfortunate that those who’re laying down the standards for ePub aren’t more aware of FM’s many handy features. Documents in ePub are also constantly adjusting their text reflow. At present they do it very badly.
I’m now using pictures in my ePub books, but only because I realized that, if I break the page for each chapter and then start each chapter with a title followed by a picture, all the problems with pictures triggering awkward page breaks go away.
–Michael W. Perry, author of My Nights with Leukemia: Caring for Children with Cancer
Which is correct?
Max Dunn: FrameMaker’s old code base is hard to rework
John Warnock (via Lindsey Thomas Martin’s reference to Warnock’s interview with Knowledge@Wharton): FrameMaker’s architecture is more sound than Aldus
It’s not clear if “Aldus” refers to the then-page-layout application, PageMaker, to the freshly-born InDesign, or to the proposed plans of Aldus’ developers.
What is clear is that it’s easy to pick on particularly frustrating weaknesses in one or the other application that you’ve encountered, and characterize the whole complex product based on a small part. Look up the fable of the blind men who encounter an elephant and try to describe it fully by the characteristics of the part they’re touching.
Regarding Michael’s issues, if I understand them correctly: I don’t know how any or all e-pub documents manage page breaks. I don’t know if any of them convert FM or ID cross-references to active links, but if they do, then this is one approach to helping users navigate from a text reference to the object it refers to.
As to how print or PDFs break across pages when a large object won’t fit on the current page, FM’s floating anchored frame lets text back-flow to fill the gap when the object moves ahead. It manages itself, though it’s not always perfect. Compared to FM, ID has a mild ability to manage anchored objects and text flow. Again, I have no idea how every or any e-pub responds to these mechanisms.
The original poster’s question was about what technical writing requirements would influence the choice of FrameMaker over InDesign, or vice-versa. It’s good to hear about specific weaknesses that may not be deal-makers or deal-breakers in choosing a tool for a project, so this debate is productive. But, keep in mind, neither perfectly solves some or all project requirements automatically, and neither can automate everything in the chain from authoring to distributing published deliverables.
In Max’s blog post, there’s a terrific detailed history of how the need to solve publishing need influenced the various tools. One that wasn’t mentioned, though it’s the public-domain application TeX (pronounced “tek”) and its various supporting utilities. Occasionally on both ID and FM forums, someone will post “This blankety application isn’t doing what TeX did back in whenever, so I’m going back to it.” Not knowing TeX at all, I’m wondering what its superior abilities were, and which, if any, have been adopted by FM, ID, or other mainstream publishing applications.
As to Lynne Price’s fabulous ground-level structured-authoring design, get real! Over 20 years old and still here, and still soundly informing a whole industry’s approaches and working methods? “Priceless?” NO! “Price-ful!”
As to pet FM features I’d like to see in ID, my main one is the ability that was in structured FM from the start. It’s the ability to constantly monitor components for their compliance with structure rules, and adjust whatever gets out of line. For example, a FrameMaker context formatting rule can test a list’s items and apply formatting to the first, notfirst, last, and notlast, items. When an item is moved to a new position in a list, if it becomes first or last, say, the former first or last item becomes notfirst or notlast, and the new first or last item takes on the defined format (“style” in ID lingo.) This means that only one paragraph format/style definition is needed for all the items in a particular type of list, because one rule adjusts the formatting, automatically. Currently, ID and unstructured FM require one style for each position in a list that an item can occupy, and they require the author to apply the style whenever the position is changed. I have no idea how complicated this would be to develop, but I propose it on the feature request wish list here https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform regularly.
This is a feature would be genuinely useful to an InDesign author who works on documents whose content changes almost constantly. Note that this benefit is only obtainable in structured FrameMaker; there’s a learning curve for authors who use it, and also a development curve to create the structured supporting components. But, when the rules are in place, and the author knows how to work in a structured document, it’s automatic.
Michael seems to imply that ID is page-centric only, and can’t be used for flowing constantly-changing content like FrameMaker. Well, that’s not quite true. It does take some frustrating effort to learn how to set up and use InDesign’s Primary Text Frames (new in ID CS6.) However once a template is created with them, the mechanism is in place, and it’s just as easy to type and paste, move, and reflow content into the long text ID story of threaded text frames as it is in the main text flow of a FrameMaker document. In earlier ID releases, master-page text frames could do the same thing; essentially Primary Text Frames are a new name on an existing feature.
[EDIT] I noticed that I didn’t give InDesign some important credit where it’s due, in my earlier comment, that FM’s “ability to constantly monitor components for their compliance with structure rules, and adjust whatever gets out of line. For example, a FrameMaker context formatting rule can test a list’s items and apply formatting to the first, notfirst, last, and notlast, items,” implying that ID has nothing like this.
I completely overlooked InDesign’s similar ability to monitor paragraphs and format them according to a set of rules. This great intelligence is in ID’s Nested Paragraph, GREP, and Line style feature. It searches paragraphs that have the feature, and applies specific named character styles according to author-defined rules. For example, it can apply a distinctive character style to the first so-many words of a paragraph, or from the beginning of the paragraph to a specific character, like a colon, and apply other styles to specified portions within the remainder of the paragraph. This automation saves tons of manual effort, and I blush to have overlooked it. Thinking back to my formal feature request that ID be enhanced to provide automated list-formatting rule ability like FM’s, I did note that nested styles use a similar mechanism, so it didn’t seem that major reprogramming and development resources would be needed to make this logical next step. Of course, things that look simple to us users aren’t always that simple to the developers, so it may be a while until this feature gets incorporated in a future revision of ID.[/EDIT]
Peter, the problem is that those “rules” (such as nested styles, etc.) tend to only apply to a single paragraph. No, you are absolutely right about the need for InDesign to become increasingly aware of the position of a paragraph inside a story. While ID does have some important features in the Keep Options dialog box, it needs far more.
Your example of a list is a great one: the same paragraph needs different formatting depending where it is in the list. Similarly, a paragraph should look different in the middle of a section vs. immediately following a heading (no indent, perhaps), vs at the end of a story, vs. at the beginning of a story. Currently, we have to make lots of paragraph styles, where we should just require one, with Location conditions.
Hi Peter:
Nested Styles is an incredibly complex feature. Applying only within a Paragraph simplifies it a lot – there are no external dependencies and we are essentially applying extra Character Styles on top of what may or may not be already there.
Applying the same concept to paragraph styles, where you would change the style applied based on neighboring context, would be a lot, lot more messy for us. Those complexities, and the limited nature of the target audience, results in us not seriously considering it.
Perhaps a more successful tack is to narrow down the needed functionality to the bare minimum and not compare too closely to Frame. We need a model that works for ID.
The best I heard some years back was to target specific attributes, such as space before and space after, which would take on alternate values based one context. That’s much more narrow focus and easier for us to mentally process.
What are the 3 critical paragraph attributes which need this treatment?
[Editor’s note: It’s difficult to leave a string of replies on a blog post, so instead we’ve started a forum thread here for people to respond to this.]
Yes, we did try TeX… It is admirable in some of the programmatic perspective: hey, we love automation and this is the sort of approach we would take if the real world didn’t have designers or human beings (who require WYSIWYG interfaces the past 30 years or so) living in it.
While TeX has produced an incredible percentage of academic output, we found ultimately that many of the criticisms at https://www.adequacy.org/stories/2001.9.10.12576.3793.html were quite legit, such as:
“The output of TeX comes in a special TeX font, which appears to have been specially designed to make people think that their printer is running out of toner. The spindly letters clash wonderfully with their bulky, overbearing bold versions, while the typesetting puts an extra pica or two into the line-spacing, guaranteeing that no matter how polished a TeX manuscript, it will always look like a rough draft that’s been printed out double-spaced for editing…”
Of course we could have invested in making a decent font, and we would have loved to converse with the illustrious Mr. Knuth about algorithms, but one thing we love about InDesign, Frame, PageMaker, Quark, etc. is that designers can use the tools completely independent of coding. We just love ingesting InDesign templates made by people who know nothing about code and automating the mapping of their InDesign objects (designed with artistry and typographical aesthetics we will never glean in a hundred lifetimes) to data with code. Code alone only goes so far.
I have maintained a (comparatively) in-depth comparison chart between InDesign, FrameMaker, and QuarkXPress on my website for about 6 years now.
The latest is available here at this link
That’s a great resource, Dave! Thanks for sharing.
(There’s no Reply button on your comment about context formatting style rules, so I’ll reply here, David.)
I’ll just emphasize the point about this kind of intelligent mechanism: it only knows what to do because it’s programmed to do the job. You’re correct about nested styles only working in one paragraph. I’ll disagree about perspective, though: I like to see it as working in any paragraph that’s defined that way, so there can be scads of paragraphs through a document set, each only minding their own business. But, you are correct in describing the larger picture. It’s a big step to get ID there. Interestingly, the Next Paragraph Style feature is a taste of that ideal world. Yes, all applications can set a specific style to follow Enter/Return, but ID can read the next-style specifications of all selected paragraphs and apply them – a useful semi-automation, but not what we’d all love to have.
The larger point is that a structured document environment is required for jobs that need intelligence beyond a single paragraph, or a selection of paragraphs. Even FrameMaker requires a structured project to perform the necessary constant context monitoring, and apply the rules. ID’s limited XML does have the ability to incorporate a structure into ID documents, but it’s for controlling content and data import and export, not for controlling live ongoing authoring operations. To get to this level requires several magnitudes of new programming, PLUS several magnitudes of training for the authors who would work in the structured environment.
FrameMaker already offers this niche-y feature, so there’s little payback to expect were ID to compete for a share of a very small market, and win it totally.
Sooner or later with a list like yours, David, there won’t be anything left to discover for comparison. Terrific!
David, I know you wrote your comment more than 3 years back but I see your resource is no longer available.
Is the link just broken or have you removed the PDF completely?
hi David Creamer , The link is dead.
“With ID, you can either fix a graphic on a page, where it will remain no matter how much the text on that page reflows, or you can make that graphic a part of the text itself, with results that can be unpredictable when text is added or removed.”
You can set an anchored frame to a fixed position in ID (like ‘always left top on margin on the page the text is on’) and even make a object style for that without any problem.
@Frans: What ID cannot do is set the anchored frame (or table) to fall at some point on the page *following* the anchor and, as Peter phrased it, have ‘text back-flow to fill the gap’, which is what one often wants both in print and in reflowable publications. This, and treatment of tables as in-line objects, are ID’s greatest failings as far as I’m concerned.
I’ve made multiple attempts over the years to interest ID customers familiar with Anchored Objects in this “float” behavior and it just doesn’t resonate – or my explanation is just bad.
Anyone familar with Frame gets it immediately, but ID customers have never seen it before and so, seemingly, find it complicated. I think it is because they are inclined to hand position where things go – especially outside the TextFrame – so having the composer do it feels somewhat awkward.
I’d be up for the technical challenge but it is lacking a strong customer push IMHO.
Your detailed research on TeK’s suitability or lack of it, for your needs isn’t wasted effort, I’m sure. Others who might think of looking into TeK will save time. You’ve done a good service for the community.
The difficulty of working with TeK illuminates how skilled with it those folks who declared they were dropping because of , and were returning to TeK, for its superior suitability to their needs and abilities to use it.
Just another example of the right tools for the particular product at hand.
Keeping the idea of “the right tool for the project at hand” department: This topic was posted on the Adobe InDesign forum: “Publish an InDesign file as a SCORM package” The poster asks for a quick solution to employing InDesign for this purpose. The link is here:
https://forums.adobe.com/message/5689488#5689488
What’s SCORM? There’s a link in one of the postings on the thread to another thread in which there’s a citation of WikiPedia’s definition of SCORM, and some discussion.
The point: Even skilled and experienced FrameMaker technical authors who’ve never used FrameMaker with RoboHelp and other applications in Adobe’s Technical Communications Suite, a “quick” solution doesn’t exist. It’s a TON OF WORK, even if you know what you’re doing with this proper set of tools for creating a SCORM project. The discussions on the threads make the point that InDesign isn’t the right tool. Often the choice of an appropriate tool isn’t so clear.
I’m responding to Douglas Waterfalls questions about position-aware paragraph formatting on the forum that David Blatner started.
In case you missed David’s note above, the forum is here:
https://creativepro.com/topic/changing-formatting-based-on-story-location
@Douglas Waterfall: Thanks for commenting and I’m not surprised at the lack of demand for float. In an way, this answers the question with which Peter started the article: the minority who are inclined to want strong control over the logical structure of documents and whose publications would benefit from such control should use FM; others should probably use ID and will no doubt feel more comfortable doing so.
But, this calls into question the usefulness of ID as a hub for both print and digital publishing, despite our being able to establish logical order after the fact by anchoring frames to a point in the text flow. I coming more and more to the conclusion that a better workflow would be one that starts with semantic HTML mark-up and sends that, on the one hand, to the web and epub and, on the other, to ID via IDML, using a system along the lines of John Maxwell’s experiment, Book of MPub.
@Lindsey: yes, the workflow you talk about is what we’ve been doing primarily, for the past 13 years: although we never found a reason to use IDML (and of course it didn’t exist in the beginning). We actually go from XML or HTML to InDesign with our own transforms (outside of InDesign entirely) that trigger object automation, inclusive of things IDML can’t do (like in-flow continued headers and state-based automation where you react to available whitespace *after* content has flowed).
We employ similar transforms for other outputs, again with a non-InDesign source. There are some simple cases where it makes sense to export from InDesign to some sort of ePub or HTML format, but when Adobe punted on making InDesign a structured authoring tool they really left it as more of a rendition engine than anything else, at least for those serious about multi-channel publishing.
I am a technical writer trying to learn Framemaker for the first time, and I can hardly believe the amount of time I waste searching back and forth for acronyms that are these so called standards. They are referenced constantly as acronyms. EDD, DITA, DTD, CMS, DocBook, UCA. And then there are all the language references; XML, XSLT< SGML, MIF, MML.
It would be funny if it wasn't so ironic, that as communicators we can't communicate quickly and simply. I understand the need for consistency, structure, formatting, but enough is enough.
I think about how much work we all could get done if they stopped introducing new "standards" and just said what they need to say. I think each document user manual or online article should include a single page, if it would all fit, of all the acronyms used so that it could be printed and referenced QUICKLY. Wasting more and more time every day.
I welcome all comments from technical writers, instructional designers, developers, and anyone else that has some relevant input, and could maybe offer some solutions to simplify this world of communications.
Thanks, BobN
I used Framemaker in 1998-9. I remember horrible UI for design work.
Speaking of right tools for the job I see three jobs in making technical litarature:
writing (vim)
design (paper & pencil)
publishing (TeX)
InDesign is jack of all three trades. Where lays its mastery is open to discussion
“Which is better,” for normal people: “PTB” is the best, most useful information this (or most any) article offers, especially for those who discovered this article after a “FrameMaker vs InDesign” search.
A firm I worked for last year used FM for page layout ONLY and none of the DITA, TCS, etc. extras that *might* make FM reasonable to use. While I appreciate FM over MS Word as a document creation program (that’s how FM was most often marketed, according to my research, rather than against its sibling Adobe product, ID, or even QXP), if a company won’t be using FM’s “meta” functions, avoid it at all (practical) costs. FM is the WordPerfect of document design programs.
Further, practically speaking: has anyone tried to take a native FM file to a printer for output? Thank the Adobe gods that Acrobat was invented!
The version I used (7 on a Win XP machine that I had to upgrade to SP3) didn’t have such modern “conveniences” (otherwise known as expected UI tools) as marquee zoom and ruler guides. My guess is that FM still doesn’t offer these.
Technical colleges (or even high schools) rarely — to the point of never — offer FM courses, practice or experience, though they regularly offer the same for ID (and the other Adobe CS products like Photoshop). (Consider: MS Office programs are taught, not Corel Office programs). Sure, online training is available, but I would bet a year’s paycheck that no one takes the course out of a casual interest to learn FM: people take the courses because they are already hired into a job that uses FM.
At the end of the day, it is most cost-effective to hire someone with experience using pan-industry-standard document design software (not all document developers have to be the tech writer, too), rather than more or less esoteric software, if that’s the entirety for which the software is going to be used.
In other words: there are more kinds of jobs available for skilled ID users than FM users and, based on personal experience, the pay is about the same.
I’m a content developer (writer, designer, photographer, MarkCom manager, etc.) and I’ve used document design software since Pagemaker 2 and QXP (to 3.4; all-in InDesign since). Working in FM felt like going back to DOS after using CS6 on the latest Mac OS or Win 7 machines.
Lotus Notes? Compuserve? Nah, FrameMaker!
Donald, thanks for your comments.
With respect, FrameMaker is one of the best “right” tools for technical writers. You’re correct to refer to it as a document-creation application, but you omitted that it’s also a document-maintenance application. Technical documents almost always need to be revised. FM is good at this.
FrameMaker is not an efficient or advanced page-layout program, though it is capable at that task. Even though the version you used, FM7, is quite old, it does have the ability to create usable non-printing ruler guides which can be displayed or hidden. No need to spell it out here, since you’re no longer using FM and probably will not in the future.
In my opinion, the premise from which your opinion arises is the issue here. That company was not using the right tool for the job. Whatever hardships you encountered while following your employers’ requirement to use FM for page-layout were most likely due to using it in its weakest manner. In addition, if you were new to FM, congratulate yourself on using it successfully for your purpose. Experienced FM users probably would have had a less-troublesome time.
Looking at it from the reverse angle, as noted in the article and responses to it, InDesign was not a capable long-document creation tool until suitable features were added and enhanced in version CS4 and later. InDesign does require a skilled user to set up and maintain the kind of long technical document that’s FM’s “normal.”
Whatever the application one uses for documents with “visually-creative layouts,” maintaining it through revision cycles will be difficult and inefficient. Planning for efficiency in revision cycles usually is not considered when attractive page layout is the primary goal.
As to bringing native FM files to a print provider, regardless of what rationale requires it, it’s the same with all proprietary software: the print vendor must have the same software, and sufficient experience. From the truly old days, the early 1990s, even before Acrobat, FrameMaker has been able to output PostScript files, which have been suitable for print vendors. If revisions are needed at the printing stage, it’s always good practice that they be performed by the document’s originator, no matter what the application.
It’s highly unlikely that your employers would have granted any requests you made for changing their workflow by adopting a different application, unless they already owned it and have had success with it.
Thanks for the insight.
Where does ID CS6 stand vis a vis document build/maintenance? Starting from scratch with software, hardware and operator/designer/writer with hyperlinks appearing in the resultant PDF files as the only cross-functionality required?
FWIW, I presented a couple of fiscal proposals to the company (one of which was the Tech Comm Suite upgrade, since I was a BYOD candidate for Illustrator; the other InDesign w whatever iteration CS best fit the environment), but this was (is?) a firm that amortized its hardware/software long ago when those costs still amounted to capital expenditures. (AS/400 was/is in use.)
Donald, I’m afraid I can’t quite understand your telegraphic style.
I think you’re asking how satisfactory the current InDesign might be for an unspecified kind of document. I suggest that you read through the postings in this thread, review my feature comparison list, and follow the link in David Creamer’s post, to see his FM-ID comparison. Then, download a 30-day InDesign trial version, and try it out on a project that’s representative of the work you expect to do.
To make the best use of the limited lifetime of the trial copy, before you install it, you might want to search the ‘Net for InDesign tutorials.
The Tech Comm Suit has a later version of FrameMaker, but its improvements and enhancements do not include any changes to its page-layout behavior.
PDFs created by InDesign create hyperlinks for cross-references, as well as for TOC and index entries. In addition InDesign offers tools to create forms with interactive links and buttons.
Thanks: this is precisely what I sought.
I found this article quite helpful, but it didn’t exist yet in February 2012 ;)]
Glad that you find this information useful, Donald.
The comparison information in the beginning of this article was at least one of a number of replies to questions that appeared in FrameMaker and/or InDesign Adobe user forums, about how FrameMaker’s feature compare to InDesign as early as 2010, IIRC. Most of them appear in browser searches for “compare InDesign FrameMaker features,” without quotes. This article and its comments contain and concentrate most of the information that’s spread among those many search results.
This is great stuff. Thank you. I am old Frame guy that might be forced to use InD soon, so I am trying to see what I need to know. I was living in the Bay Area and knew people working AT Frame when Adobe bought them (back in the day). Adobe had no idea what they were buying (I was told). Couple that with almost daily reports of Frame’s demise for a while makes the co-development of InDesign more understandable. Clearly everyone (except the odd project manager at Frame) wants ONE product to do everything. Look for it around 2019…
You’re welcome, Bill.
It’s not about the software, it’s about the communicators who have something to say with it, and the audiences they inform and enrich, whatever the tools.
2019? You are an optimist!
Artikel keren tentang busana muslim ini luar biasa bagus.
Keren sekali dan penting. Semua orang yang pakai ataupun sedang cari busana muslim seperti gamis dan koko di Indonesia harus baca tulisan ini.
Mampir juga situs saya ya, banyak artikel menarik yang pasti bermanfaat buat para fans busana muslim dari Baju Muslim Keke.
Terima kasih.
Although this is nearly 3 years old, this post is still very relevant and helpful. Thanks for posting.
Cupcakes in the form of cute doll faces can be added to the list along with sandwiches, burgers and
fruit juices. The easiest way to cut down on paper waste is to reduce usage
and reuse paper as needed. Even if your dishwasher claims
to have a ‘knife basket’ to supposedly prevent the blades from banging around, don’t do it.
Great article. I am going through some of these issues as well..
This is the perfect website for anybody who really wants to understand this topic.
You understand so much its almost hard to argue
with you (not that I personally would want to…HaHa). You definitely put a fresh spin on a subject
that’s been discussed for years. Excellent
stuff, just great!
I’m in a Techpubs group that uses Word, because we have to collaborate with a team that are all contributing content (words and images) and get to monkey with the document. Since they all use Word, we have to use Word.
We’d like to move to InD or Frame. Since InD has the free InCopy tool to permit contributions, it has a leg up. Has anyone used Frame in a collaborative context like this?
It is not uncommon for exile politicians to mount an opposition from abroad, something blogs
tend to make easier, so caution is advised for that reason. Then write the way looks
like to you and be aware as you lay they in the
market to find out more about yourself watching the method that you will quickly realize the hidden lesson. Advertising
may be used in your website that gives the
recording or you can also embed the advertising within it.
Really no matter if someone doesn’t be aware of after
that its up to other visitors that they will assist,
so here it happens.
There really is no replacement for experience, because that’s how your Realtor is able to zero in on properties that
meet your needs and get away from wasting time on properties
that don’t. But while using soaring rental values apparently purchasing flats
in Bangalore has become a distant dream. There will
likely be certain houses that fall in your price range
and several which might be too expensive.
I’m an old technical writer. I use both Frame and ID, with Word as a collaborative word-processing input. I use them on my Mac running parallels since Adobe does not have the ability or has some stupid historical stubbornness to port Frame to the Mac (in my opinion, of course).
You use what is needed in this business. Today, paper is only a small part of the information media required by businesses. So, one has to be prepared to produce web sites, animation presentations, and complete video scripts. Pick the editorial process and your output then pick the software. Great article David and comments!