Skip to main content
barbshoop
Participating Frequently
February 22, 2017
質問

Planning for single sourcing (insets and variables)

  • February 22, 2017
  • 返信数 1.
  • 445 ビュー

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.

このトピックへの返信は締め切られました。

返信数 1

Jeff_Coatsworth
Community Expert
Community Expert
February 22, 2017

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).

barbshoop
barbshoop作成者
Participating Frequently
February 22, 2017

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?  

Jeff_Coatsworth
Community Expert
Community Expert
February 22, 2017

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.