I am writing help content for software that is highly customizable. Users can change field labels and other labels very easily. However, if any of these labels are changed, users will no longer be able to identify the field descriptions in the help content.
I am trying to find a systematic way of updating these field names in the help content when the field label in the software is changed.
Ah yes. Developers love giving people the ability to customise their product. Of ourse that can have massive implications for information developers and end users alike. There is no easy way around this as there is no way you or anyone else will know what the user is changing these field names to.
RoboHelp has variables that you could use, but you'd have to know the value (field name) before you create your output. There could also be a lot of them. Another way, and a way I did many years ago when I had this problem, is to either use the default field names or keep the descriptions generic. Either way you'd have to have some topics on the customisation aspects that you could like to or highlight in some way.
If you knew 100% what customisation was to be applied, maybe you could tackle this programmatically. The issue here would be the sheer number of variables that you may have to use in your RH project. Personally I'd not go there.
I’ve got some of the same issues in one of our modules – clients can change the “factory” terminology to suit their situation. I ended up using the “factory” defaults throughout my documentation with an explanatory note about the customization aspect. As Rick says, you probably don’t want to try going down the road of variables.
Oops – this is what happens when I try to read too many forum posts at once ;>)
I’m sure that come St. Patrick’s Day, Rick turns into O’Stone or O’Captv8r – don’t we all get our Irish on that day?
Europe, Middle East and Africa