Recommendation for Limiting No. of Cond. Tags?

[TX_Marie]

Hello,
I'm about to implement conditional tags for my X5 WebHelp project for the first time. I would like to set up numerous tags -- one for each major feature.

Has anyone found that it's best not to use more than a certain number of tags in a project? Does RoboHelp support only a certain number of tags?

Thanks in advance.

[Peter Grainge]

I don't think there is any technical limit, it is more about usability.

It is so unusual for someone to ask about limits on this that it makes me question why you would need so many different builds. Perhaps if you covered that, there might be a better solution.

[TX_Marie]

Hello Peter,
Thanks for the reply. You're right; I'll definitely have to keep usability in mind.

There will probably be 3 builds to start with, but it could increase to 5 or more within 2-3 years.

The product and accompanying documentation is being customized for different states.

I read a suggestion that seemed quite good from an STC online SIG member who described applying build tags to major features rather than applying tags for a particular build when multiple builds are needed. In this way, a feature can be included in 2 or more builds and excluded from others.

It seems a key aspect of using this approach would be apply feature tags at a relatively high level.

[Peter Grainge]

When you said "numerous" it sounded like you were talking very high numbers.

You talk about applying tags to features rather than to a build. Not sure what you mean there. Tags are applied to parts of a topic or the whole topic and in the generate wizard you define a number of build expressions such as Not A and Not B - or Not B and Not C etc.

Then you generate your help you can do one of two things.

Either you select the appropriate expression each time you generate using that layout OR you can create more than one layout and each one will already have the required expression selected.

[RoboColum_n_]

To add the Peter's excellent advice, just bear in mind that whilst there is no limit to the number of build tags you can have, there is a limit to the number of characters you can use in a build tag statement. I believe the limit is 255 characters. Whilst this may sound like a lot, it can easily get clogged up if you have long tag names.

[MergeThis]

Also keep this in mind: topics with no conditional tags are included in every build (this includes content within those topics).

Therefore, you should only assign conditional tags to the material that might be excluded from, or exchanged within, certain builds. So in your case, you would only tag those features that might not make build A, or that might be different in builds B or C, etc. You should really sit down with all your major players (engineering heads, product managers, etc.), and hammer out a plan of action that will allow you to keep that tag statement to the 255 limit, as Colum indicated. That is, which features are likely to be modified, when will they be modified, etc.


Good luck,
Leon

[TX_Marie]

Many thanks for all of the pointers.

[HKabaker]

Another point we need to clarify for a first-time user is, what happens to tagged content and topics that are not specifically excluded?

For example, tag conditions are:
Untagged
A
B
C
D

If the build expression is

NOT A AND NOT B

Will the output include:

Untagged only, or
Untagged plus C and D?

I think I know the answer but am reluctant to state it without consulting colleagues who are more expert than I.

Thanks.

Harvey

[Gravenstein]

quote:

---

Originally posted by: HKabaker
...If the build expression is NOT A AND NOT B ill the output include:
Untagged only, or
Untagged plus C and D?
...

---

The output will include Untagged plus C and D.

Cheers,
G

[HKabaker]

. . . Therefore,

It would make no sense to use a complex include / exclude expression, even though the RH advanced setup seems to accept, for example,

A and not C and not D.
Logically, this should generate output with A topics but not B topics, excluding C and D topics, and omitting any C and D text that may be present in A topics. However, RH actually would include Untagged, A and B topics (excluding any C and D text in those topics), and would exclude C and D topics (regardless of any content tags they may have in them.)

To simplify, this takes us back to the basic rule: Use exclusionary tags, and expect everything to be included in the output except what you specify to be excluded.

If anyone has successfully applied an include / exclude build string, please contribute to this discussion.

Regards,

Harvey