MadCap Flare Goes Mobile

In a recent post, I discussed how RoboHelp 8 has added support for mobile output. In this post, I’ll look at Flare 6 and its support for mobile output. Again, some background about the mobile space…

Mobile debuted in the early ‘90s with Apple’s Newton. Newton was revolutionary, but its problems turned it into a footnote in computer history. Windows CE Help and Wireless Markup Language followed several years later, but failed in the mass market for, in my opinion, three reasons. One was an unattractive output, shown below in a real screen from a presentation that I gave in 1998:



That problem has been corrected, as evidenced by the examples below – iPhone apps for star charting and birding:

Another problem was that vendors didn’t know what content to offer so they offered anything, much of it “fluffy” novelties whose charm wore off quickly and that lacked staying power for the mass market. Many apps today share that problem, but there are a lot more apps so there’s a better chance of finding something good amid the fluff.

The third problem in ‘98 was a rough authoring environment, often requiring hand coding. Authoring can still be difficult, but there’s a decade’s worth of improvement in the tools.

So, in general, mobile has become easier to create and more attractive to use.

For today’s technical communicators, there’s a new problem however. Do we create apps, or help or doc to be read on mobile devices? App development is new for many technical communicators and can take them into unfamiliarly complex authoring issues. But the help authoring tools, or HATs, offer another approach – letting us put online content into a format that works on mobile devices and either stands on its own, like an online procedure manual for use in the field, or help for a real mobile app. (If you think today’s mobile apps are so simple as to need little or no help, you’re right. But as mobile device power keeps increasing, I expect increasingly powerful apps to appear that will need help.)

Flare offered mobile output as an option in the interface when it released v. 6 in March. In this post, I’ll give an overview of the feature set and results. Another article will appear in a forthcoming issue of the Communicator, the journal of the ISTC (Institute of Scientific and Technical Communications) at www.istc.org.uk.

Flare 6 supports mobile output through its WebHelp Mobile output target. The target is integrated into the Flare interface, so using it mechanically simply involves creating the target, selecting WebHelp Mobile as the output type, setting or selecting various options, and generating the output. Most of the options are familiar ones in Flare, such as skins, TOCs, CSS mediums, and so on.

How well does it work? Here’s my test project, output as standard WebHelp:

And here’s the same project output in mobile form:

What’s striking about this test is that I made no changes to the project except for the skin settings; Flare just gave me the material in a different format. This has strategic effects for development. If you’ve wondered what your online help or doc would look like in mobile form, you no longer have to buy and learn new tools. Instead, just select mobile as the target. And if mobile proves not to be what you need, just delete the mobile target and try something else. In other words, there’s no risk to trying mobile.

More specifically:

• WebHelp Mobile produces a “mobile site” rather than a “mobile app” so it’s not tied to a specific device. It’s simply a web site accessible from any device with a microbrowser.

• The code is “pared-down” XHTML, so it’s open-source.

• WebHelp Mobile automatically adjusts to a microbrowser’s features. For example – no JavaScript support means no search capability or dynamic text features. This automatic adaption to the microbrowser’s capabilities simplifies project planning, design, and management.

• Flare has pre-defined mobile skins, so skin definition is just point-and-click.

• There’s a generic emulator to preview WebHelp Mobile, shown below:



• All standard navigation options are available on the home page, as shown below.



Mechanically, outputting a project to mobile is a snap. The problems arise in design. This isn’t a problem in Flare but rather in the need to fit output designed for large-screens onto a screen the size of a sticky note. My test project has a fairly typical feature set. Here’s a summary of what happened on conversion…

• Text and variables (which are text) converted smoothly because they reflow to fit the screen sizes.

• Objects that are too big converted but added horizontal and/or vertical scrolling. (Scrolling reduces usability but isn’t necessarily evil, but avoid combining both types of scrolling at the same time if you can.) You can expect this problem with tables, graphics, drop-downs and togglers that contain tables or graphics, master pages, wide head styles, and SWFs. Snippets and project import link items can also be troublesome because they may have the same problems but you won’t “see” it as you insert them – basically “out of sight, out of mind.”

• Popup links converted to jumps. Some microbrowsers don’t display popups, so making the popups work as jumps supports the lowest common denominator microbrowser.

• The only other problems I’ve found or heard about so far are due to the limitations of the display devices themselves. For example, WebHelp Mobile should be able to use a regular project’s header and alias files to create context-sensitive help for mobile apps, but the device must support multitasking or else opening the help closes the app.

• Finally, there’s the design problem of deciding what information to omit from the mobile output.

Except for the last point, you can deal with most of the other problems by making fuller use of Flare features. For example, style properties should be relative rather than absolute – % or ems for text size instead of points for example. This isn’t unusual for text, but what may be unusual is the need to do so for tables and images. (You’ll want to create a CSS medium for the mobile output.) For example, here are two versions of the same page, one with the graphic displaying at its default size and the other with the height and width set to 50%. Note how the second one eliminated the horizontal scroll bar.

This isn’t that difficult, but it will require you to look more closely at your styles and properties and maybe try some features of the Stylesheet Editor that you’ve ignored until now. You’ll also make greater use of conditionality, and perhaps variables in order to use full names in the regular output but abbreviations in mobile. You may also have to re-evaluate your content to determine what’s really needed and what’s there because it’s cool and you had the screen space to indulge yourself. And so on…

If you’re a Flare shop and considering mobile output, you’ll find that the mobile target will push you into new areas of information design in general and Flare’s feature set in particular. And it’s fun…