Best approach for Webhelp and PDF from a single source

[iand]

Calling all Flare Single Source Gurus! If you are creating two sets of output from a single source: Webhelp and PDF (not sure if this is the strict definition of single source), should you:

a) Create one format and perfect that before moving on to perfect the other output format via conditional text, etc.

or

b) Create and perfect sections of both as you go along.

If a) what factors determine which format you create first? Should you create what you feel will be the "most used" format first, which approach gives better quality overall?

I have tried PDF first followed by Help and Help followed by PDF, the advantage with PDF first was that cross references were not messed up in the other format, however I had a job splitting the topics into small enough chunks to make the Help files. Overall I think creating Help first is easier but I have only done two fairly small projects.

[SteveS]

There is no hard and fast rule here - and most projects are dynamic, styles change as the organisation changes.

My suggestion is to make the online target the default. No real reason - it just appeals to my sense of rightness that the html and css is for the web default, and other outputs use the modified style sheet.

As to how you develop your project stylesheet - I try to get the online styles set up, before refining the print styles. You have to be careful that you are modifying the correct media, so it makes sense to do a whole lot in each media in one go, rather than bouncing backwards and forwards.

HTH

[iand]

As to how you develop your project stylesheet - I try to get the online styles set up, before refining the print styles. You have to be careful that you are modifying the correct media, so it makes sense to do a whole lot in each media in one go, rather than bouncing backwards and forwards.

HTH

Very good point. I found this out the hard way

[royj]

To me, the biggest issue isn't one of how your CSS is set up, but how your source content is structured.

You mentioned having to break things up into the right sized chunks for online display. In my experience, the first thing to do, before doing anything in Flare, is to analyze your content, clarifying your macro- and micro-level structure (parts, chapters, topics, etc.), as well as the meta-structure (that is, deciding what kinds of topics you have: procedures, concepts, overviews, definitions, etc.), and what the elements of those topics are (Main heading, intro paragraphs, procedure steps, field labels and descriptions, tables, illustrations, etc.). Then figure out what's going to end up in which target; what goes online, and what goes in the PDF.

THEN you can start figuring out how to make things look the way you want them to in each target.

[Jeannie Marzonie]

I agree with royj's approach: analyze your content first. Then, look at what will be online content (if that is your largest need) and then printed content. The source files we started with came from online Help in RoboHelp. Then, over time, moving from RoboHelp to Flare, we created our printed content from the online Help source. It has definitely been a trial and error process. Lots of tweaking text and breaking up content. We use conditions and variables extensively. Currently, for our latest product release, I produced 4 versions of WebHelp and 5 versions of printed materials from one set of source files.

[Andrew]

I agree royj's approach is the best. If you don't have the time to do that, typically I'd focus on whichever output will be the "primary" output and make sure that works pretty well before worrying too much about the other format. For example, our new features docs are primarily PDFs, and we throw them up in a WebHelp for searchability, whereas our online help is, well, online.

[mattbnh]

I don't disagree with what has been said, but I think it is easier to string help topics together to create a book than it is to break up book content to create coherent help.

I think if you take a topic-based approach, write good topics, and make a Help TOC that works, you can then use Flare's TOC Editor to make a separate TOC for the PDF, and use the PDF target setting's to establish chapter breaks.

One of the main differences is that the hierarchy in help and books tend to be different. For example, when we used to do totally separate help and PDFs, every topic in help was set up to start with an H1, regardless of it's level in the Help TOC. In the book, the same content might begin with an H2, H3, or H4. What we now tend to do is start all help topics with an H1 or H2, keep H3 and H4 within a help topic file. Then the book hierarchy is easier to put together.

The thing that we do is add print-only chapter start topics in the PDF TOC that give the chapter number and name and a mini-TOC, then the next file in the TOC is the first topic in the chapter, then the next, in a logical order.

We tend to have topics that are truly H1s and topics that formatted as H1 in the Help medium, but in the print medium they act as H2, and are formatted to look like an H2 in that medium.

[iand]

Thanks for all the replies to this post everyone, it's certainly given me a lot of food for thought. Very useful to get some hints and tips from those of you with more experience.

Ian