Setting up Conditional Text in Global Project Linking

[writer9]

Hi,
I'm trying out Global Project Linking for the first time.

Scenario I'm dealing with:
Product1 has three variations (minor variations--product name change + very few content changes)
Product2 has three flavors (three types of modules where set up for each module is very different; could add more modules in future)
Product3 (currently one entity; could morph into more later)

All three products at the basic level have about 15 features/tasks that are common to all products (products1,2 and 3), but the variations are at the product level. For eg. xyz feature of Product1 has 10 ports vs. xyz feature of Product2 has 5 ports vs. xyz feature of Product3 has 2 ports (with corresponding images to represent each).

I have all of this content that is common to all three products in the "Global" Project folder organized by topics (more or less one topic per feature/task).

I read through this article on how to use conditional text:
http://www.madcapsoftware.com/blog/2012 ... cap-flare/

Here, Tips&Tricks #2 (page 4) indicates NOT to use product names as condition tag names. I would like to use feature names for condition tagging; however, the variant within the topic for each feature is product-specific. And so it is with the images.

What is the best way to set condition tags for this global project?

Thanks, in advance, for your help!

Rekha.

[techwriter31]

Not sure if this helps your scenario, but I'm using GPL for a similar situation. We have a variety of hardware products with similarities between them in some cases, and drastically different features in other cases. I store all the common content in the Global project and import to the child projects.

The method I used is to:
- Store the conditional tag set within the Global project.
- Name each conditional tag based on the product name and the output. For example xyz_Manual, xyz_QSG, etc. I also added conditional tags for "Print_Only", "Mobile_Only" and "Web_Only".
- I applied very few conditional tags to files within the Global project, except to "Front Matter" type topics that we use exclusively in print outputs.
- Within the child project import file, I chose to include condition tag sets in the files imported from Global (but currently don't import based on conditions).
- Any time we add a new target/output to a child project, I go back to the Global project and add the new conditional tag there and then import the new tag to the child project and apply it to the appropriate files.
- Within the child project, each topic file is tagged based on the output(s) it needs to be included in.
- Within the target, select the appropriate conditions to include/exclude.

We did end up with a rather large list of conditions, but having it set up this way will also allow us to use GPL to import from one child project to another if we need to. Overall, I haven't encountered any problems with this setup.

Worst case - if the product name changes and you are using Flare 8 or higher, you can rename the condition in your Global project. The only downfall is that you'd want to manually rename this condition in your child projects too (so that all of the topics are updated) THEN reimport, and it should work fine. If not using Flare 8 or higher, you'd get around it by doing a find/replace within source code.

[LTinker68]

Worst case - if the product name changes and you are using Flare 8 or higher, you can rename the condition in your Global project. The only downfall is that you'd want to manually rename this condition in your child projects too (so that all of the topics are updated) THEN reimport, and it should work fine. If not using Flare 8 or higher, you'd get around it by doing a find/replace within source code.

To get around that worst case scenario, you could set up a separate mapping list in an Excel spreadsheet or even just in a topic in your global project. So you'd have the internal name which is what you'd name the conditional tag, and then you'd have next to it the marketing name. That list would just be for reference for your authors (although if it's an Excel spreadsheet stored elsewhere, then support, QA, marketing, etc., can also reference the list).

The example that comes to mind is how Mac OS's have a cat name in the development stage (tiger, leopard) that corresponds to a version number (10.4, 10.5, respectively). I think Android does it now, too (isn't Android v4 also called "ice cream" or something like that?). So your internal name could be the major rev number (10.x) and the marketing name could be whatever name the end user knows it by. That way if marketing or whomever decides they want to rename the product, all you have to change is the variable name for the product in the child project so the end user documentation uses the correct name in text, but you keep the same conditional tag name the same so you don't have to replace it, which can cause major problems if you don't do the find-and-replace correctly (or forget to do it altogether).

That's a suggestion anyway.

[writer9]

Thank you, Kellie. Great suggestions! And thanks for taking the time to list out the steps--that definitely helps! But I do have some questions on that....

First, about the setup I have--our QSGs and UGs are independent of each other with no overlapping content. So, the content is mainly for different flavors of QSGs for different products and some products have different modules within them. I ended up talking to Flare Tech Support yesterday (because we have a maintenance plan that covers limited number of calls) and they suggested that I use variables for product names and use product names for conditional text (Default.Prod1; Defaul.Prod2 etc.) and that works for me.

Your list items #1,2 and 3 make total sense. I have my Global project all set up now and am just about trying importing to child projects and maybe that's why, I lost you at #4 (-within the child project import....[you are including the tag sets, but not importing based on them? Does that mean that you are essentially "copying" the tag sets but not using them yet? I just copied the tag set using Explorer]) and the rest of the items again make total sense.

I made an error* while tagging a topic in the global project and then imported it. Now I am having trouble with undoing the import of that file.
[* I don't think the details of the error are relevant, but here it is if you need them: Instead of applying conditions to the content, I inadvertently applied conditions to the topic (selected content, right-clicked and selected properties and applied conditions to the topic thinking I was applying to content) and had also applied different conditions to some of the content.]

I fixed the error in the global project and in the child project if I just select the file in the Project Import Editor and do reimport, that file does not even show up in the list. I will have to look into this more, but if you think I'm missing something obvious, I'd appreciate if you could let me know.

Lisa,
Thanks for your reply. That's a good suggestion, but I think what Kellie is alluding to is if you use product name in conditional text. If the product name is set to a variable, yes, that's simple to just change it there. Or, am I missing something?

Rekha.

[LTinker68]

Lisa,
Thanks for your reply. That's a good suggestion, but I think what Kellie is alluding to is if you use product name in conditional text. If the product name is set to a variable, yes, that's simple to just change it there. Or, am I missing something?

I read it as using a product name in the condition name, but I might have missed something. Regardless, using a variable for items that traditionally change on marketing's whim (product name) or business needs (company name change due to acquisition) is always a good idea.

[techwriter31]

Sorry, I knew I didn't get that one quite right. Within the import file in the child project, I am including the conditional tag set as a file type (*.flts) in the "Include Files" field, so that when I import content from the Global project, the condition tag set is imported to the child project and stored in the Conditional Text folder of the child project.

includefiles.png

But within the import file, I don't include any conditions in the "Import Conditions" field.

importconditions.png

Once the conditional tag set has been imported into the project, I then apply the conditions to the topics or content in the child project as needed. And anytime I need to add a new condition tag to the condition tag set, I go back to the global project, add it there, then go to the child project and reimport the condition tag set.

I read it as using a product name in the condition name, but I might have missed something. Regardless, using a variable for items that traditionally change on marketing's whim (product name) or business needs (company name change due to acquisition) is always a good idea.

Yep! I was referring to naming the condition tag itself using the product name. So, in my condition tagset editor, I have a variety of condition tags using "productname_outputtype". For example, "xyz_InstallManual".

Vairables can be very useful (especially the ability to overwrite them in the target file!), but we found that it made translations more difficult and our vendor requested that we use them as little as possible.

[writer9]

HI Kellie,

Thanks again for your post! You're awesome---just solving all issues I have with importing . Item #4 makes complete sense now.

I did my first import and I have a basic question (I actually think I know the answer, but would like to confirm that with the experts):

Scenario A: I have all files (topics) for all products in the global folder and if a file (topic) is specific only to Prod1, then I apply Prod1Condition at the topic level and if it's specific only to Prod2, then I apply Prod2Condition at the topic level. This way, I edit all files in one folder and import them when I'm ready to build the book.

Scenario B: I only have topics with common content in the global folder all marked up with the various conditions and I have all product-specific topics in its own folder. I have to go to two places to edit a book.

After reading previous posts, I know that Scenario B is typically used. But I actually prefer Scenario A because I have one "go to" place to edit the files and I typically have to edit more than one file which could include product-specific or one that's common to all topics.

What is the advantage of using Scenario B over Scenario A?

Thanks, in advance, for your help.

Rekha.

[Nita Beck]

What is the advantage of using Scenario B over Scenario A?

One big advantage is that the author can condition an entire folder of product-specific topics rather than having to condition all those topics individually.

Another is that having all the imported common stuff segregated in its own folder reinforces for the author not to edit those topics there but back in their original project.

[writer9]

Thanks, Nita. That helps in planning my project and keeping it clean!

[rob hollinger]

Testing a post to a subscribed thread.
Thank you.