Need to exclude content from online output

[ccardimon]

I know that all content is included by default unless specifically excluded.

I have a big, messy project that was previously just PDF output.

I am trying to specific folders as online output, but everything is being included.

Try to exclude what I don't want would be labor intensive, but is doable.

Would it be worthwhile to create a new project with just the folders I want?

Anyone else run into this?

[whunter]

Include won't work the way you want it to -- you have to Exclude the content that you don't want in the output. (It doesn't exclude everything that isn't marked as Include, instead it includes everything that isn't marked as excluded -- how's that for a mouthful of a sentence?)

Alternatively, on the online target, you might try using the "Exclude content not linked directly or indirectly from target" -- this might work if all the topics in your online target are in the online TOC. This option is on the Advanced tab of the target.

[ccardimon]

Thanks I'll try it.

[i-tietz]

Include won't work the way you want it to -- you have to Exclude the content that you don't want in the output. (It doesn't exclude everything that isn't marked as Include, instead it includes everything that isn't marked as excluded -- how's that for a mouthful of a sentence?)

It's even worse :
If a topic or a folder has two (or more) conditions and in the target you specify one of them as "included" and the other as "excluded" the element is INCLUDED, because the include always overrules the exclude. That principle even works if you use conditions on different levels, e.g.: You have a folder with conditions A and B and in that folder you have a topic with the condition B only. Then this topic will be in output A, because it has that condition via the folder.

[Matt O]

I'm still on Flare 6.1. This problem goes way back, it crops up all over this forum, i was just looking at one from 2008. It seems appalling that Madcap have not resolved such an in-elegant piece of functionality.

As far as i can establish, this effectively means that you cannot easily produce, say, PDF output and webhelp output from the same TOC. The PDF will work fine, the webhelp will not work at all unless you concoct a load of workarounds.

This sort of behaviour is what we expect from MS and why we are all so glad to be able to ditch it.

Sorry i have no solution to add and I shall be watching this post closely.

[Msquared]

you cannot easily produce, say, PDF output and webhelp output from the same TOC

I've done this without too many problems for Webhelp and PDF. I also have three product variants, Product A, which contains almost everything, product B which contains a subset of the functionality, and Product C, which has one or two subtle differences from Product B. I was determined that I was only going to maintain one TOC (as maintaining six separate products has been a nightmare) and I've managed it.

I had the (possible) advantage that this was the first project that I converted to Flare, and I was able to spend a bit of time thinking it thorough first, but some things didn't work as I'd first planned and I had to make some changes. This is how I did it - your situation may be far more complex than mine, but you may find some things below helpful. It's late at night, and this is a bit of a brain dump, but here goes . . .

I have Print_Only and Screen_Only conditionals (Print output excludes Screen_only and online output excludes Print_only) to handle print and online outputs. I also have Product_A_Only, Product_B_Only and Product_C only conditionals (Product_A excludes Product_B_Only and Product_C_only etc) for my product-specific content.

I also have Product_A_Print_Only, Product_A_Screen_Only, Product_B_Print_Only etc as the include always overrides the exclude as is said above. I don't have to use these often, but there are one or two places. For example, each product has a different format and content for title page etc. I can do some of that by using different page layouts for the different products, but not all of it. So the title page for Product_A is flagged Product_A_Print_Only, etc. The printed output for Product A includes Product_A_Print_Only and excludes Product_B_Print_Only and Product_C_Print_Only. That's the main conditionals I have.

The next thing is to get the topic structure correct. I've got my topics in subfolders, grouped according to functionality. I also have a Print-only folder for things like Title pages and glossary pages, and an Online-only folder for some additional troubleshooting content that we only provide online.

So, if a whole subfolder's worth of functionality is Product A only, then I flag that folder as Product A only. In fact, I also ended up flagging each individual topic in the folder too (I think that was to avoid warning messages about missing topics when building relationship tables - the relationship tables didn't seem to take sufficient notice of folder level conditions - they are only warnings, but they are a nuisance - or was it the CSH? I can't remember without looking at my notes now) but that actually makes it really easy to see what you have. Here you need to be a bit careful, if any of the Product A-specific topics are Print-only, as there you will need to Product_A_Print_Only flag. Oh I always show the conditional indicators on topics so I can see where I am.

If just one topic in a subfolder is Product A only, then I just flag that topic.

Now for the TOC. Again, I apply the appropriate conditional to the topic, and to the book, if applicable. I may be just fortunate, but my TOC structure matches my topic folder decomposition almost exactly, so that's not difficult to do, or to maintain. The names in the TOC are the names in the corresponding topic headings, which in turn are the names of the actual topic files, so I can see where I am at any time.

There are three places within topics where I sometimes need to print/online conditionals for structural reasons, rather than for content reasons. Now I'm used to them, It's not hard.

The relationship proxy is online only. Once the relationship table is set up (that's another story), it handles all the "See also" references, and you just need to add the relationships proxy to any page. I don't yet have that on my web master page, because it didn't dawn on me that would be the best place for it.Currently, it's online only at the end of each topic, but I will move it from each topic to the master page as soon as I get a moment. That will leave only two places . . .

Where I have dropdown text, I want the drop-down header to be online only (the bit that says "Click here to see more about . . . "). The print version just runs straight into the extra text, although if the print content of the drop down text starts with another heading level, then I usually make that print-only, as the "Click here" bit is usually enough of a separator in the online help. It looks messy if the lower level heading is there as well.

The final place where I may have medium-specific content (sometimes) is for xrefs. Because . . .

My print content has some topics which are just there to give a higher level heading in the print output. For example, I may have a chapter on "Stuff", that has subsections on "Widgets", "Left-Hand Elbows" and "Sticky Stuff". The "Widgets" section would have subsections like "About Widgets", "Creating Widgets", "Deleting Widgets", "Painting Widgets", "Widget Command Reference". The TOC will match this structure, with "Stuff" being a book containing "Widgets", which in turn is a book containing real topics "About Widgets", "Creating Widgets" etc . The "Stuff" topic will just contain a level 1 heading, the "Widgets" topic will just contain a level 2 heading (no real text) and "About Widgets", "Creating Wdigets" etc have a level 3 heading and the real text. S, for print, everything is hunky-dory. Level 1 heading, Level 2 Heading, Level 3 heading, text (and lover level headings if necessary), Level 3 heading, more text etc.

This means that the topics containing just the level 1 and level 2 headings are Print-only as they look silly in the online help (Or Product_A_Print_Only if they are Product A-specific of course). So I have to be very careful not to use them as xref targets in the online help, because they aren't there. And Flare doesn't detect these conditional missing xrefs when it builds . And Flare makes a spectacular mess of the xrefs that it can't locate when it doesn't detect them.

But the fact is, that it print, it often makes more sense to reference these as "For more information about Widgets, see <xref to Widgets level 2 heading>", if you are talking about widgets in general, unless you really do mean a specific subsection. This will be a broken link for the online help. But there, the statement "For more information about Widgets, see <hyperlink to About Widgets level 3 heading>" makes sense, as the About Widgets page will have links to all the other widget-related stuff in the related topics section anyway.

I could compromise, and ensure I always choose a xref target that exists in both mediums, but that sometimes makes the print xref less than optimal, for the reasons above and I've decided not to do that. So many xrefs have a print target and an online target as conditionals. Again, now I'm in the habit of it, I don't find it too much of a problem.

What made this easier? Undoubtedly, the fact that I spent a couple of days ensuring that my Word content was structured into approximately "proper" DITA-style topics before I imported it. Where something was missing, or all mixed up, I just added extra headings to ensure the contents ended up in topics with the right sort of names. So my structure was reasonable at the outset - the "proper" topics enforced that. This made it much easier to see what was needed for what, and to move things around if necessary. Incidentally, this was my first foray into topic-based authoring and I'm hooked!

Perhaps something here may be helpful to someone . . .

[Matt O]

Hi Msquared

Wow, good effort and your first foray into topic based authoring. I sense success ahead! Thanks for all that info.

I think, in a way, your description enforces my point that Madcap sing loud about how flexible the output of Flare content can be but the reaility is a delicate and risk-prone cobbling together of workarounds as you have described. I'd like to think there is a team in La Jolla working on this but the issue has been around for so long that i'm not so sure.

i think part of your success, and continued success judging from your obvious diligence, is that you are starting on a new project.

So, grumbling about La Jolla is not totally fair because undoubtedly part of the problem is where one has a lot of heritage content. Like ccardimon mentions at the start of this thread, I also have thousands of topics which are all in fairly good condition but do nevertheless carry the scars of my learning curve and other signs of malnutrition from wreckless driving en route to tight deadlines.

ho hum. Thanks Msquared, all the best.

Matt

[NorthEast]

I'm still on Flare 6.1. This problem goes way back, it crops up all over this forum, i was just looking at one from 2008. It seems appalling that Madcap have not resolved such an in-elegant piece of functionality.

As far as i can establish, this effectively means that you cannot easily produce, say, PDF output and webhelp output from the same TOC. The PDF will work fine, the webhelp will not work at all unless you concoct a load of workarounds.

If all the topics in your project are in the TOC, then your PDF and WebHelp will be the same.
You'll only have these extra topics in the WebHelp output if you have topics in your project that aren't in the TOC; in which case, you use conditions.

To be fair, MadCap have actually made a quick-fix to this type of issue (to save you adding conditions), as mentioned by whunter above; but this is since v6.1 and 2008.
It only includes 'linked' topics, so it'd have topics in the TOC, and also topics linked from those topics; basically all the files required for a working help without broken links.

Help on this feature:
http://webhelp.madcapsoftware.com/flare8/Default.htm#Targets/More_About_Targets/Excluding_Content_not_Linked_Directly_or_Indirectly_from_Targets.htm

[i-tietz]

I think, in a way, your description enforces my point that Madcap sing loud about how flexible the output of Flare content can be but the reaility is a delicate and risk-prone cobbling together of workarounds as you have described. I'd like to think there is a team in La Jolla working on this but the issue has been around for so long that i'm not so sure.

If somebody told you that "Single Sourcing" means pressing two different buttons and that's it - kick him where it hurts him most, because he promised you the moon.

And this won't help you anymore, but maybe a few other new Flare users:
Spend resources (time, money) at the beginning - then it's cheap in comparison. If you wing it, you'll pay a higher price lateron ...

And I go on by rubbing chili into your wound:
There are systems in which you just press two different buttons - but the "purchasing resistance" for those systems is at least a 6-digit-number ...