Existing Features
Automatic update of changed element names – In prior versions, all authors had to agree on the name of a variable, condition, or file tag set before inserting it. If you created a variable called custname, for example, inserted it in 500 topics, and then changed the name to customername, the insertions broke and had to be recreated. That changed in Flare 8, where references to a named element are updated automatically. It’s a small change, but it adds authoring flexibility since a misnamed variable name is no longer carved in stone.
Additional print features – The print output features continue to grow, with Flare 8 adding features like the ability to control where page numbers appear for index entries, to suppress page number display for specific levels in a table of contents, to control how a PDF should display when it opens, a better ability to create tables with captions that repeat if the table spans multiple pages, and more. These features increase Flare’s ability to serve as the primary authoring environment for all outputs. However, these features also raise the potential complexity of a project and make it more important than ever to plan a project before starting it and document that plan for reference during maintenance. “Winging it” is less and less realistic an approach for project management.
New Features
ePub output – With the addition of ebooks in ePub format as an output option, Flare now handles two out of the four primary mobile outputs – ebooks and web apps. (But excluding native apps and hybrid apps, which are not an obvious fit for a tool like Flare - for the moment at least.) This, and the added print features, increases Flare’s utility as a central authoring environment. You will still have to validate the ePub code using an external validator if you want to send the ebook to a store, and that’s a jump in technical complexity, but the addition of ePub output is a strong step forward.
HTML 5 output – This is similar to the familiar WebHelp output but more powerful. This format supports the WHATWG HTML 5 format and CSS 3. It adds features that take advantage of the capabilities of new browsers. There are too many features to cover in a short blog post, but some of the major ones include support for SEO (search engine optimization – more about this below), improved “accessibility”, and server-based functionality like the ability to include non-XHTML (topic) files in a search. This is a strong step forward into the era of modern browsers.
SEO (search engine optimization) support – SEO is fairly new and esoteric for many help authors but it’s a reflection of changing trends in technical communication. How? In the past, access to help was usually limited to people who’d bought the application software for which the help had been created – the help was “inward-facing”, aimed at the buyers. People who hadn’t bought the software couldn’t see the help. Google changed this; buyers and potential buyers often did Google searches to find information about or answer questions about the application software instead of using the official help. As this practice spreads, the value of the official help will decline to the point where traditional help authoring may turn into an endangered niche. The solution is to make the help “outward-facing” – to make sure it can be found via a search and not only found, but listed near or at the top of the search results. One way to do this is to include features that make the help easier to find by webcrawlers. If you’re creating traditional, inward-facing help, SEO isn’t a factor (although it’s worth learning about now.) But if your company is changing its online help strategy to an outward-facing one, SEO support features are going to become important immediately.
More posts in the near future but, overall, a very nice job.
