Questions from Captivate Course in Orlando

Chris and Anthony,

To delete misspelled terms that you accidentally add to the dictionary - This is mentioned in the help. Terms that you add to the dictionary during a spell-check go into your personal dictionary, userdic.tlx, which you should find at \\Documents and Settings\\Local Settings\Application Data\Adobe\Adobe Captivate\Spelling.

To delete the Adobe logo from the movie playbar - You'll have to use a different skin. To do so, select Project > Skin Editor and select any other skin listed in the Skin field in the upper left corner of the dialog box.

Enjoy...

Workshop – Creating Mobile Device Output Using Flare

Need to create output to run on mobile devices from a Flare project but not sure how? You could create an app, but the process may be unfamiliar to your developers and call for new tools. Or you could use Flare itself to create the mobile output, in the form of a "site" that should run on most mobile devices that have a microbrowser.

Generating mobile output from a Flare project is simple mechanically. Where things can get tricky is in the design and control of the content – deciding what content to show or not show in mobile form and controlling that, controlling formatting by making full use of possibly unfamiliar CSS features like mediums and relative sizes, and more.

This half-day, hands-on, web-based class is aimed at Flare 6 users who need to quickly get up to speed on converting existing projects to Flare WebHelp Mobile output. Prior experience on at least one Flare project is necessary.

- Date - Monday, July 12, 9 AM to 12:30 PM ET.

- Cost - US$150 per person, includes workbook and working files.

- Location - Remote, via GoToMeeting.

- Outline – see www.hyperword.com/FlareMobile.htm.

Contact Neil Perlin at nperlin@nperlin.cnc.net to register or for information about payment.

Creating Mobile Output with Flare

New half-day, hands-on workshop on how to convert online help or doc projects created using Flare to mobile format. Covers the conceptual background, conditions, CSS mediums and relative size settings, the mobile skin, and testing.

See http://www.hyperword.com/FlareMobile.htm

First of a series of workshops on mobile and tech comm.

Adobe RoboHelp’s Mobile Output

Continuing my look at help authoring tool-based mobile output, we turn to RoboHelp 8.

RoboHelp mobile output uses the International Digital Publishing Forum (www.idpf.org) ePub standard. This means the output can run on any device that supports ePub, like the Barnes & Noble Nook, Android devices with ePub readers, Kindles (with some extra work that doesn’t involve RoboHelp – see http://kindleworld.blogspot.com/2009/08/ million-free-google-books-in-epub-for.html) and others.

RoboHelp creates mobile output using a script that you import into RoboHelp itself. (This is similar to how Adobe added AIR support to RoboHelp – using a plug-in in v.7 before adding it to the interface in v.8. If the mobile market takes off, I’d expect to see Adobe follow the same path and build the script into the interface in v.9.)

What follows is an overview of what’s involved mechanically and design-wise in converting a fairly standard project to mobile format. The project is a proof-of-concept I created for a Boston-based maritime historical to which I belonged from 1990 to 2003. Members of the group built museum-class ship models, and my idea was to create an online “book” about the models and have it sold in the museum store as a fund raiser for the group.

Here’s the main screen and default topic:

And here’s a fairly typical topic screen.



The project had a TOC, index, header and footer in one topic, breadcrumb trail, table and graphics, internal links, an external link, popups, and an audio file. My question was how well the project would convert to mobile with no effort on my part.

The first step is to download the ePub generator script and a file archiver, both free. (See Ankur Jain’s blog at http://blogs.adobe.com/techcomm for instructions.) A few caveats – you’ll have to change the name of the script file to ePubGenerator.jsx and modify the script – a minor step into code – to specify where you put the file archiver on your PC. You can then import the script into RoboHelp using the Script Explorer. Finally, you have to change the XML handler using RoboHelp’s XML support feature.

You can then open the project to be converted to mobile format and run the script. After you specify the output folder, RoboHelp will create the ePub output. Here’s the result in Adobe’s ePub viewer – Digital Editions. First the main screen and default topic:



And the topic.



The result? Mechanically, pretty good. Without making any changes to the initial project, here’s what I got…

• Text converted correctly, as expected since ePub offers “reflow” of text. The text also resized correctly when I used the resizing options on the viewer.

• The TOC came across fine.

• Internal jump links worked fine. External jumps worked too, but opened the target pages in a new browser window. This is okay if your users will read the book in a full browser, like Firefox with the ePub reader add-on, but not if users will read it in a “true” reader. Popups did not work, which I assume is because ePub doesn’t support them.

• Graphics seemed to come across fine.

The problems I found seemed to have more to do with apparent incompatibilities between help project features and the ePub standard, and design.

• The index didn’t convert. I’m not sure if this is because ePub doesn’t offer one or because of something that simply hasn’t made it into the conversion script yet.

• The search tab didn’t convert. It was replaced by the ePub viewer’s search tool, as can be seen, with some difficulty in the images above, at the end of the toolbar.

• One oddity – the project apparently converted to one text file when viewed in the Digital Editions viewer but individual topics when viewed in Firefox. I assume there’s a reason for this that I simply haven’t found yet.

• Projects meant to be single sourced to ePub, in addition to any other outputs, need greater and more rigorous use of CSS. Basically, avoid local formatting – good advice under any circumstances.

• Adobe recommends setting sizes as % rather than the usual points. You’ll have to do this for everything, not just text. Also, don’t use hard returns for paragraph or table row separators because these double when rendered in ePub. (Compare the paragraph spacing in the pre- and post-conversion versions of the default topic, and the spacing of the table rows in the pre-and post-conversion versions of the ship topic.) Instead, specify the spacing as part of the style for the items in question.

• There are also some formatting requirements described in Ankur’s April 23 post.

Finally, as you’d expect when converting content from big-screen to little screens, you’ll have to decide what content is “need to know” versus “nice to know,” such as graphics, and be prepared to conditionalize out the latter. You can fit many graphics in the mobile output by making their sizes relative, with the % unit of size, but a graphic may become small enough to be illegible. Think of this as single sourcing taken to an extreme level.

The biggest benefit of this support for mobile output is the fact that it makes it easy to try mobile without buying and learning new software. And, if you don’t like the result or it’s not what you needed, just delete the output, delete the script (or just ignore it), and go back to your regular output.

And, again, it’s challenging and fun to figure out how to output to mobile…