MadCap Software Forums

Hi
I've just noticed that Flare is showing condition information in the output of a build! For example, our HTML5 build includes things like this:

<p class="BlockHeading" MadCap:conditions="Globalconditions.PrintOnly,Globalconditions.PrintOnly"><a name="Participants"></a>Participants in a conversation</p>

Why?
Surely this information is only relevant to the flare build itself? ie Do I include content or exclude content?

Is there something I'm missing here?

Cheers
Mark

I can't answer why, but I can confirm that Flare includes conditions as properties in HTML5 outputs. So what you see is normal.
But I'm not aware of any way to stop it doing this.

Hi,
Thanks for confirming.
What I really want to know is what it the thinking behind this because to me it seems completely unnecessary.
Maybe I fundamentally don't understand conditions, but my take on them is they are used to define what it actually included in the output - I didn't expect to see them in the output as well. Maybe a someone from Flare can comment?

We're going through an exercise of rationalising the condition sets and names throughout our company documentation. This involved creating a much smaller set of conditions and renaming or removing lots of existing conditions across probably ~100 flare projects, each with thousands of topics.

In order to identify if our changes are causing problems, we are:
1) building the pre-change set of documentation
2) making the condition changes (via scripts)
3) rebuilding the new set of documentation
4) comparing the outputs of both.

Having the conditions in the output of both set of builds is causing a lot of false positive change reports as they simple echo the changes we already know we've made.
Cheers
Mark

It can be useful including the tags in the output. For example, in the past I've used it to highlight text for review

Or I believe some people have implemented a custom filtering system. They tag the content (e.g. Admin, Reception, Call Centre, or version numbers, whatever they want to use). Then use custom javascript and a dropdown list to allow users to filter the content based on those tags.

Hi
I'd imagine the people who are taking advantage of Flare leaving this condition tagging in the output are very much in the minority.
But I can see how your and other usage of this is advantageous to you.

I'll consider making create a Flare enhancement to at least make the behavior optional - maybe a few years down the line we'll see a change.
Cheers
Mark

I should also note that if your target has a condition expression to exclude the tag, then the tag (and content) obviously won't be in the output. It only remains in if you tag the content, but don't exclude the tag in the condition expression.

Probably also worth noting that as the labels for your included conditions are visible, you may want to avoid using any sensitive/internal terminology.

Here's a scenario where I'm thinking to use it. I have a working prototype if you'd like it.

STORY
I produce internal and external versions of our help, and my internal audience wants a quick way to see the differences between the two versions. They don't want to open another PDF or another browser window, and they don't want a split view (and I really hate CORS, so I'm not opening the box of loading a topic from our other subdomain).

SOLUTION
My Setup
1. I created two conditions - one for internal content and one for external.
2. I have two Targets - one for internal publishing and one for external.
3. I created a button and placed it on my MasterPage (TemplatePage).

For the internal Target
1. I Include both external-only and internal-only conditions.
2. At runtime, the script hides every thing that has or and a special case of (I don't know if it's special - that's just what I call it).

With some styling, I think it's a homerun from an internal audience's perspective... especially the technical support group. However, I haven't let any of them see it just yet. (I'm trying to cover my bases with this one.)
NOTES AND CAVEATS
- I'd like to use Flare's Name and Toggle functionality to do this, but I haven't tried it yet. This could be confusing because when you click a search results link, it will open a drop-down or toggle so that it can highlight the search query text. If the content isn't showing.... seems like a bad idea to me, so I made the component functionality myself. This way, the search won't be confused nor my audience... and me!
- I haven't tested how this affects Menu Proxy items when the TOC entry has been conditioned as External.
- I've only tested this in a Skinless project template, so I don't know if it works in TopNav and SideNav templates.
- I don't know what this might do to accordion-style TOC menus with a SideNav project. Same for TopNav.
- For content in a topic, it works great so far.

So, for my particular scenario, I like the conditioned content being included... just don't take away my ability to hide it.

Hope this helps a little with your quest for the "why" part of your question.

Jim

For Menu proxies and accordion-style navigation, I can probably answer before I test: I bet it won't work. Flare dynamically creates the menu items at runtime and I think the same with Side and TopNav. The CSS would probably work to hide it, but I doubt the script could tell Flare to show a specific entry... I don't know yet.