By Jang F.M. Graat
FrameMaker’s product development team shows no signs of fatigue. After adding big chunks of functionality in the previous releases, the latest edition shows important improvements in a variety of domains.
The most apparent change in FrameMaker is, of course, its naming convention. Eighteen months after the release of FrameMaker 12, Adobe has now decided to avoid the unlucky number 13 and went for the year instead. Many other software companies have done the same over the past decade. It will come in handy when, years from now, the tech authoring team is trying to convince their management that an upgrade is required. “But our current software is 5 years old, just look at the version number!”
More important is the contents of the new software package. At first glance, most of the known features have not changed much. But once you go through the menus and functions with a little more attention, it is apparent that a lot of effort was put into the product. This is not merely a cosmetic release. In this review, I cover the new features that I feel to be important, even if that importance is not the same for all users.
Embracing Diversity: Bi-directional Language Support
Most of us accustomed to reading and writing in English tend to forget there are languages that require a radically different approach to creating an authoring environment. Since the introduction of Unicode (in FrameMaker 8) has gotten rid of most translatability issues, by allowing all possible character sets to be incorporated into the same document without having to get down and dirty with codepages, the next big reform concerns the direction in which those characters are strung together.
Supporting right-to-left (RTL) languages, such as Hebrew and Arabic, is not as easy as simply reversing the direction. When authors write about products that have their names written left to right, these product names will have to show up as LTR, no matter the text direction of the paragraph. Also, product manuals or Web pages might contain text in multiple languages on the same page. This implies that one language direction switch on the top level, as is the case in Madcap Flare, is not going to solve the issue. True RTL language support requires support for bi-directional content. If a paragraph is RTL, it may still contain a term that is LTR. It is this mix of RTL and LTR components that make things complicated.
And there are even more aspects to consider. It is not just language that may have to be rendered in one or the other. What about sidehead alignment of content, or the appearance of graphic items? It is not enough to allow defining such features while creating the content: you will want to pull translated content back into FrameMaker to do the final checkup and creation of Arabic and Hebrew versions. This means that you should be able to switch from one alignment to another, using the language direction settings that may be defined on every individual object.
This is exactly how it works in FrameMaker 2015: each element on the page, as well as on the master page, can be explicitly set to “right-to-left” or “left-to-right.” When the default “inherit” setting is selected, higher elements in the hierarchy of objects are queried until an explicit setting is found. If no direction settings are found in the entire document, the default LTR direction is used. Flipping the direction after a translation is returned is easy, and when you have marked page elements, tables, graphics, paragraphs, or text sections with an explicit text direction, they will not be affected. Playing around with these new direction tools feels like magic (see Figure 1).
Of course, things become really interesting when you are working in a structured environment that supports text direction, such as DITA. With the “dir” attribute that was already present in DITA 1.1, any piece of content can be made to remain RTL or LTR as desired, or can use inheritance from elements higher up in the structure. Again, the definition of content direction works along the entire structure and may lead to publications that contain chapters in both directions. With this level of bi-directional support, it is a shame not to have a lot of customers in the RTL language areas (yet).
Simplifying the XML Experience
In the previous FrameMaker release, Adobe introduced an author view as a kind of middle ground between the sophisticated WYWIWYG environment and the somewhat geeky XML view. The author view provided a simplified structured authoring experience, from which all direct formatting and visual page references were removed. The authors get visual feedback on the structured content they are creating, but do not have the ability to tweak that content explicitly by setting characteristics such as font sizes and styles, line spacing, or other types of overrides. Those buttons and commands were removed from the interface in this author view.
In FrameMaker 2015, the author view has received another option, which is designed to allow subject matter experts (SMEs) access to sections of the content in a further simplified authoring environment. This simplified XML editor is enabled via a preference setting. Once chosen, a form-like authoring screen is shown from which all structure is removed. Elements can be inserted via a special toolbar, which can be configured in various ways to accommodate different types of structured documents. In one document, you might want to allow an SME to create a basic topic from scratch, whereas in another the SME is supposed to fill in the blanks without touching what is already there.
Whether this novel approach to simplify XML editing is going to be popular remains to be seen. It seems that dumbing down an XML standard, to a point where a non-structure-savvy SME can use it, might lead to poorly marked-up content, in which case the use of XML does not add much value over WordPress or plain HTML. The quality of the markup may depend on the amount of work put into setting up the templates for each particular case. The good news is that roundtripping to either the full WYSIWYG or the formal XML views remains possible, so that you are not obliging your tech docs department to minimize their use of the full standard. As a new approach to XML editing by non-XML authors, it is an interesting path to follow, even if it will be from a safe distance. We will see what this simplified future will bring.
DITA 1.3: More and Less DITA at the Same Time
FrameMaker was one of the early adopters of DITA, and it is a good sign that all of the documentation for the FrameMaker and RoboHelp products was created in DITA. The cows may be holy, but they are eating their own dog food in India. To me, it was not a big surprise that FrameMaker 2015 features support for the latest version of the standard, as I was involved in the creation of the DITA 1.3 EDDs and templates myself. This does give me an advantage in explaining what are the most important enhancements in FrameMaker’s DITA support.
The timing of the FrameMaker 2015 was excellent: shortly after the new FrameMaker version was officially released, the DITA 1.3 draft for public review was published. If no dramatic errors in the specifications are found, the new standard should become official early next year. And as this is an evolution rather than a dramatic redesign, all the signs tell us that nothing dramatic will happen.
There are several new domains in DITA 1.3. Notably, these are the SVG and MathML domains, the release management domain, and the XML mention domain. Also, there is an important new “deliveryTarget” attribute and several elements and attributes to better support contextual help delivery. Although these new domains and attributes make it possible to apply DITA to new business areas and media, I will not cover them all here.
If your organization wants to take no chances and stay with DITA 1.2 for a while, there might be good reasons to go for the DITA 1.3 support in FrameMaker 2015 and leave out the domains and elements that were added. Effectively, you will be working with DITA 1.2, but you will have the advantages of using the redesigned DITA EDDs and templates. Here’s why this would be a good move to make.
The true added value in the new DITA 1.3 implementation is the option to easily implement constraints. These were introduced in DITA 1.2 as an effective way to limit the exposure of the standard to your authors. Instead of changing the DTDs, templates, and transformation scenarios, you could simply add constraint modules to the full standard, which effectively removes elements from the available catalogs. This became a necessity as the number of elements in DITA grew steadily with every business domain for which the basic elements were specialized.
Nobody in their right mind should be using DITA out of the box, without first analyzing which elements are applicable to their business domain, and filtering out all the others. This is the sole reason why the EDDs and templates were reorganized from the ground up. Problems with nested text insets and incomprehensible variables were removed, and the use of conditional text was enhanced, using all the new options provided by the improved conditional text expression builder.
With the new set of DITA 1.3 EDDs, anyone can now build a constrained EDD for any DITA topic or map type in minutes, where in the previous implementation this job was time-consuming and required a lot of technical knowledge (see Figure 2). The document shell EDDs contain lists of domains and conditions that are included and offer direct visual feedback on the validity of the chosen combination of conditional text snippets. Even if you are only using DITA 1.2, the DITA 1.3 EDDs with their support for constraints will make you much more effective in offering the optimal set of elements to your technical authors. And this requires no knowledge of DTDs or EDDs whatsoever.
Putting the User in Control of the Content
On the publishing side, the main additions to FrameMaker appeared in the previous release, when the publishing engine of RoboHelp was incorporated into the product. One-click publication of up to five different output formats became a true option. What is more, the definition of the CSS that governs the look and feel of your responsive HTML5 design was made as easy as is humanly possible (see Figure 3). A fully visual and totally easy CSS editor was built into the settings dialog. In FrameMaker 2015, there are further enhancements to this feature and the option to publish directly to native mobile apps for iOS and Android was added.
More media and more CSS options are nice, but they are not devastating new features. What is truly new in the interactive output, however, is the inclusion of filtering options—not filtering before publishing but after the materials are delivered to the user. This is another feature that has crossed over from RoboHelp to FrameMaker, and it has been implemented well. Instead of creating multiple outputs, one for each target group, you now have the option to pass the conditions (with which you have marked up your content) into the output and give the users the ability to filter the output as they see fit. You define the labels, set the corresponding conditional text expressions, and the publishing process creates the filter controls in the output. This not only optimizes production of output, as you no longer have to create one set of files for each target group, but you also provide content that will be more useful for each individual user. After all, who are you to decide what each user already knows? How well do your personas match each and every user in your imagined target group? In fact, only the user knows what the user already knows. What the users need from the help system is based on the gaps in their knowledge that they can probably define best for themselves.
This new approach to filtering content in the output brings progressive disclosure within reach without having to spend a lot of work on defining your own transformation scripts or Web application. It is a welcome addition to a publication chain that was already impressive.
JANG F.M. GRAAT (yes, those are the middle initials that my parents chose for me, long before the FrameMaker product was even invented) has studied physics, psychology, and philosophy before embarking on a fast-track career in the international high-tech computer business in 1987. He has worked as technical author, consultant, and trainer and has delivered countless presentations and training courses on a wide variety of computer-related topics around the globe. He has been self-employed for 20 years and recently joined Tom Aldous in The Content Era. He lives in Amsterdam with his princess, two cats, a library of philosophy and psychology books, a bunch of musical instruments and, of course, a handsome collection of cool computers.
