I'm trying to plan for the best way to single source or reuse our content. Most of our content is different but we have login instructions for our applications that are the same for all apps. That's the easy part. We can write those instructions in a separate document and use it when we build the books for each app or use a text inset. But we also have applications where a unique transaction ID is selected when logging in. How do we write common instructions for all these apps where only the transaction ID is different? I was thinking we could use a variable in a text inset, but it seems like each name-value pair is unique and I can't define a list of values for the Trans ID. We would need to maintain many separate variables? We could create an inset leaving the transaction ID blank, then convert it to text and change the transaction ID, but we want to single-source our content in case the login steps change--not just reuse it.
Personally, if only the transaction ID is different, I'd write a generic bit of text that would work regardless of which ID you picked and maybe mention the fact that different ones exist (or not - depends on how important the ID is to the login process).
Thanks for answering, Jeff. The trans ID is very important to the login process and is required by our documentation standards. So does your answer mean it's not possible to single source content that has some differences? That the best we could do is use a generic inset as sort of a template, then convert the inset to text and add the trans ID?
Frankly, I don't know - I don't use text insets myself, so I'm not sure if you could use a variable in them and then apply a value to the recipient doc to set the value in there. I think you would need to do some mock ups & proof of concept trials before committing totally to that approach. You're using Unstructured FM, right? Because if you're using Structured FM, it's supposedly much easier to achieve this sort of granularity in content.
Yes, if only a single value changes, you can use a variable. Its value would have different values in the various documents.
Or you could also add a sentence specific for a certain variant in the inset and apply a condition specifc for this variant. In the target document you would have to hide all conditions which do not fit.
Amplifying what Winfried Reng says – when a text insert contains a reference to a variable, the value for the variable is retrieved from the file where you reference the text insert. In a file where the $product variable is set to Acme, a text insert using the $product variable will show Acme. Use the same insert in a file where the $product variable is set to Excelsior, and you'll see Excelsior.
Also, you can import variables across all files in a book – so (depending on your content) you could set up a single .fm file describing the login instructions and using a variable for transactionID. The next two steps would be a) add this .fm file in a book about transactionID 4711; b) copy variable settings from another .fm file in that book where transactionID = 4711
I think you'll find a way that suits you. Good luck!
We are using unstructured. But we aren't actually using FM yet. It's a long process from approval to purchase here. I'm trying to get our standards and best practices in order now so we can get moving as soon as we get the install. I think I did see the Tech Comm Tools FM book that you can use a variable and assign the value in the container document. My problem with that is that, if I understand how variables work, I would have to create a variable for every transaction ID. I hoped that I could create one variable name that contained all the values, like a drop-down list. Maybe it won't be so bad to create and maintain many variables. I'll have to wait and see when I get the install. Thank you.