I’ve been designing some advanced help systems lately, without significant CSS3 and HTML5 usage. The great thing about this is that it keeps me learning, which I love, and it keeps my clients happy.

The problem: the CSS and HTML often can’t be properly rendered in the XML editor. This happens for a couple of reasons:

• Flare doesn’t render CSS3 quite yet. I’m hoping that a future release will resolve this issue.
• DIV tags and other structural HTML tags don’t always render well (see example below).

While the final product may look fine, working in the XML Editor when things are funky looking can be a challenge AND inefficient. I’m going to show you an easy way to work effectively and efficiently in the XML Editor while maintaining complex layout via DIV tags.

Here’s what the page looked like when I was done (click the thumbnail to embiggen):

I think it looks great…and so does the client (and that’s the goal here!). But getting to this point with a LOT of DIV tags in the HTML was frustrating when in the XML Editor. Here’s why (click on thumbnail to embiggen):

I know what you’re thinking: What the heck am I looking at? THAT is a view of part of the XML Editor for the page I showed above. Nothing much to see, is there? I mean, how do you work with this and why is it happening?

Would you be surprised to learn that it’s the result of a checked box? Really. I had the Enable Object Positioning option checked.

Where is that?? I had no idea…until a few weeks ago:

 That is the Show Tags pull-down list on the XML Editor menu bar.  The Enable Object Positioning option.You see how it’s checked? Uncheck it and see what happens:

Wow, what a difference! The page is now workable! All because of a checkbox. So remember, if your XML Editor is looking funky, see if the Enable Object Positioning option is checked.

Wow, it’s been too long since I’ve posted. I’m sorry for that. I’m back now…tan, rested, and ready.

When Flare v7.1 came out recently, I noticed a new checkbox in the Advanced tab of the Webhelp target (We won’t discuss how pathetic I am that I noticed a new checkbox):

I’ll admit, I was excited about it. This would allow me to exclude all the topics that I decided not to use in output: old versions, bad topics that were discarded but never deleted, etc.

Why was I excited? Because before that checkbox, if I left those topics as is, meaning in the project but not in a TOC, they would still be included in a build. This was BAD because every time I left unused topics in my project, the test team would inevitably find them through testing the Search feature in my help project. Grrrrrr….

So, I learned to use conditional tags with abandon. For webhelp project, the Print Only tag became a close friend. Setting those unused topics to Print Only was a quick solution to a nagging problem.

Now, if you’re building print output as well – DON’T DO THIS. Create a new condition tag (maybe called ‘not being used’) and use it liberally.

With Flare v7.1, I thought I was free from what was somewhat annoying: applying a conditional tag to all unused topics. So, I checked the box! I was soooo excited! I built my project, published it to the test server, and waited for the brilliance of the help system to shine through during testing.

Except it didn’t turn out that way at all. The test team logged a Critical bug against my help! What?! The majority of my Context-Sensitive Help tags were broken. Huh? How could that be? They worked yesterday?!

Well, the culprit, it turns out, was that blasted checkbox! I had many CSH tags that were topics independent of the others and not used in the TOC. In other words, they were topics that simply defined a field and weren’t really appropriate for the TOC. So, clicking that checkbox resulted in all of those topics being tossed out of the build, thereby breaking my CSH tags.

It almost goes without saying: I quickly unchecked that checkbox.

The lesson here: be careful what you wish for and BEWARE the Power of a Checkbox.