The latest best features in FrameMaker 2015

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. 18 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 short review, we are convering a couple of the new features that we feel to be important, even if that importance is not the same for all users.

Embracing diversity: bi-directional language support

Most of us are so used to reading and writing in English, that we 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 an easy thing, as simply reversing the direction on everything will not do. 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 what the text direction of the paragraph is in which they appear. Also, product manuals or webpages might contain text in multiple languages on the same page. This implies that having 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 is even more aspects to consider. It is not just language that may have to be rendered in one or the other direction. What about the sidehead, alignment of content, 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 is 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 a piece of cake, 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 doing magic.

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 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 to not 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. Simply because those buttons and commands were removed from the interface in this author view.

In FrameMaker 2015, this 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. Enabling this simplified XML editor is done via a preference setting. Once this is chosen, a form-like authoring screen is shown from which all structure is removed. Inserting elements can be done 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 a winner 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. Possibly the quality of the markup depends on the amount of work that is 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 us, it was not a big surprise that FrameMaker 2015 features support for the latest version of the standard, as we were involved in the creation of the DITA 1.3 EDDs and templates ourselves. This does give us 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 (very) 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. Even though these new domains and attributes make it possible to apply DITA to new business areas and media, we are not going to cover them in more detail here. Check the draft for public review if you want to find out all the details.

But even 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 just 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. We will try to explain 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 removed elements from the available catalogs. This became a necessity as the number of elements in DITA was steadily growing with every business domain for which the basic elements were being 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 was the sole reason why the EDDs and templates were reorganized from the ground up. Problems with nested text insets snd 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 build a constrained EDD for any DITA topic or map type in minutes, where this job could take days and required a lot of technical knowledge in the previous implementation. The co-called 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 have appeared in the previous release, when the publishing engine of RoboHelp was incorporated into the product. One-click publication of up to 5 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. 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 to a mobile IOS and Android  app was added.

More media and more CSS options are nice, but not a devastating new feature. 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 and 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 good does your persona 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. A welcome addition to a publication chain that was already impressive.