Limited Conditional Control in Flare

[Steve Davies]

Hello

Our company is currently evaluating Flare as a potential replacement for Help & Manual. We are also evaluating Adobe TCS 4.0 in parallel.

We single source documentation for a range of software tools that have extensive commonality. At the moment, H&M allows us to use if, if not and if else conditional tags. For example, we might have a paragraph of text in which there are five or six separate if, if not, if else conditionals applied

However, it appears that in Flare I can only use the equivalent of if tags in the editor, and am only able to exclude when generating a target.

I really have two questions:

1) Am I missing something with Flare's conditionals, or are they really that limited? Adobe TCS 4.0 offers a raft of conditionals that look perfect for our purposes
2) For those of you who single source complex documents like ours, is there a better way of using conditionals that would be supported by Flare? We are open to completely changing our processes, so any ideas would be welcome

Many thanks

Steve

[KJohnsonDBTK]

Isn't the application of your conditions (not the tool) the driving force behind your if, if not, if else conditions?
You can apply combination conditions such as
A
B
C
A+B
A+C
B+C
A+B+C
or create single level conditions
A
B
C
D (was A+B)
E (was A+C)
F (was B+C)
G (was A+B+C)

Flare won't have issues with the number of conditions you use. The hard part is for the writers to keep it straight. (Personally, I would think single level usage would be easier for writers to keep straight and impelement than combation usage.)

Flare has target level conditions and snippet level conditions. I have a project with 10 target level conditions and 17 snippet level conditions. I transitioned several years ago from FrameMaker to Flare and found the snippet level conditions increased my single sourcing capability significantly.

Kathleen

[Steve Davies]

Hello Kathleen

Many thanks for your response.

It is true that our process is driving our selection, but there appears to be no viable alternative way of doing things.

To me, it seems that people use and talk about single sourcing as a means to primarily output the same document (or a small number of very similar documents) across multiple formats. For us, single sourcing means using common text to create 13+ different documents across a number of target formats. We have about 2,000 discrete topics, of which about 75 percent are common to all 13 manuals.

To this end, your proposed method simply won't work for us. There are simply too many different permutations to make A+B+C etc. a realistic option.

Yours is what I would characterise as a 'positive' approach to conditionals, where you mark text that is to be included. That works fine when there are only a small number of distinct documents, or where there is so much commonality between documents that very few conditionals are required. However, given the large number of documents we create and the fact that (in places) they are quite disparate, that would mean a massive amount of conditional text highlighting on-screen: that's going to significantly impact the readability of text on the screen. This will be compounded by the fact that we need to be able to nest our conditionals up to two layers deep.

For example, the two attached screen grabs shows what the following simple paragraph of text, which has conditionals applied for only three products, looks like in Flare and Help & Manual. It is now very difficult to read in the Flare editor, primarily because of the highlighting of the text (and I've used soft pastel colours in an attempt to mitigate this). If this were a 'real' topic that spanned a full page or two, the overall effect would be pretty ugly.

Code: Select all

Example Paragraph: 

[if] This text should appear only in Product 1 [end]. [if] This text should appear in [if] both Product 1[end] [if]and also Product 2[end][end].
[if]This text should appear in [end] Product 2 [if]as well as in [end][if] Product 3 [end].
This text should appear in all products. 

Any other suggestions would be much appreciated - we're really open to changing our workflow, but we're fairly sure that what works for most will not necessarily work for us...

Best wishes

Steve

[crdmerge2]

Steve, I don't think Kathleen's reply was necessarily advocating a "positive" conditionals approach, which you implied from her quite basic example. Best practice, as suggested repeatedly in the RoboHelp and Flare user forums, is a "negative" approach (NOT A, NOT C, but everything else).

Also implied by Kathleen's reply is the underlying issue here: conditionals alone will not usually be the only solution. That is, the infrastructure you'll need will more than likely be a combination of multiple targets, TOCs, variable sets, variables, snippets, concepts, and yes, conditionals.

Out of curiosity, what is causing you to investigate a replacement for H&M? At a previous job (maybe four years ago?), my boss and I had tentatively chosen H&M to replace RoboHelp, but were shot down by upper management (who said the company was "too small"). So we stayed with RH a little longer, then switched to Flare (by this time, many in our group were Flare fan-boys/girls). However, he and I were pretty impressed with H&M at the time (Rev 4, I think).


Good luck,
Leon

[KJohnsonDBTK]

It sounds like the amount of common text versus conditionalized text is your challenge, not a Flare issue. I have many topics where every bit of content is conditionalized - no common content at all. And that's with 27 different conditions currently. I'll be adding another one in the next month and probably another one mid-next year. As our product grows, so does my condition list. So yes, you are right. There is massive amounts of conditionalizing, but it works. (And no, my conditions are not for creating the same document across multiple formats. That is only a small subset of my conditions. Most of mine are for conditions within a single document.)

One suggestion I would have for your application is to conditionalize in larger chunks. Using your second sentence as an example. Instead of conditionalizing parts of the sentence, repeat it and conditionalize at the sentence level.
[Yellow]This text should appear in Product 1.[/Yellow]
[Green]This text should appear in both Product 1 and also Product 2.[/Green]
This has several benefits: Easier application of the conditionals, easier to read your content in the text editor, easier to see your colors in the text editor, and localizable. (Conditionalizing bits and pieces will be a nightmare if you ever want to translate because word order and sentence structure in some other languages is different than English.)

You can still layer with larger conditionalized chunks.
[Yellow,Green]This is more text that needs to come right after the above sentence but is exactly the same for both products but doesn't apply to others.[/Yellow,Green]

As Leon said, conditionals are just one component of single sourcing in Flare. Don't let the rainbow of condition colors blind you!
Kathleen

[Steve Davies]

Leon

Thanks for your response.

We are looking at alternatives to H&M because there are a number of niggling issues that have been reported to them over the years but which they still have not fixed (forgetting bullet styles, for example). So, we want to look at what else is out there and whether the alternatives can help us either do things more efficiently, or do things the say way but to a higher standard.

In trialling Flare and Adobe TCS 4.0, it has become apparent to us that H&M actually stacks up very well against the competition... and that there is never going to be a perfect solution!

The idea that conditionals alone will not suffice is new to me. I have been indoctrinated into doing things a certain way (a way that works in H&M, so there's nothing wrong with that). As such, Kathleen's suggested alternatives are most welcome.

Best wishes

Steve

[Steve Davies]

Kathleen

Thanks for your response, too.

Let me take a look at your suggestions and get back to you.

Steve