Flare CSS design strategies?

[Phlawm53]

I'm a reasonably competent user of Flares 6,7, and now 8. I currently have a Flare CSS that works pretty well for both PDF / Word (print) and HTMLHelp (default) mediums. That is to say that I've done reasonably well at designing and organizing my Flare CSS.

Having said that, I'm wondering if anyone can share any acquired insights about Flare CSS design strategy.

For example:

- To what extent have you found it necessary or desirable to create separate Print / Non-print / Default selectors and classes?

- What CSS design "tricks" have you learned that have improved your Flare workflow, or helped you better deal with new output types?

Any other comments or ideas are welcome.

Cheers & thanks in advance for any ideas,
Riley
SFO

[wbrisett]

My "strategy" is fairly simple and probably the one most people follow.

I try to use default as much as possible. For print/PDF, I know I need figure numbers, table numbers, and section numbers, along with a defined type, so that all goes in the print section. For web/online, I don't need the numbering, but I do make sure my type is not set to our corporate type. If there is a major conflict with online vs. pdf output, pdf wins. That's because we always publish in PDF and only sometimes on the web.

There is a push towards seeing if we can start doing some ePub, but our current layout simply won't allow us to do that, so we will have to totally redesign both content and css.

Wayne

[Phlawm53]

Thanks Wayne.

One of the things that I've learned since posting my question is that Flare CSS Mediums may be useful vis-a-vis mobile.

That is (and I'm NO expert, believe me), just as one can partition Print-only CSS, one evidently can also create a Mobile Medium.

I'm still researching the issues. My goal in so doing is of course to benefit from the accumulated wisdom of other Flare users. If nothing else, I'm hoping that wisdom will help me avoid making silly design choices…

Cheers & thanks 'gain,
Riley
SFO

[chunkee]

I have tried to get a repository started here for participants examples and using them to view. To learn, share and teach, but I am not certain as to why this forum does not have one. Seriously, why not a set of skins, CSS, scripts etc. that are stored for people to learn from?

This is a design and development tool, there should be an end user repository for tricks, examples and best practices.

[Phlawm53]

chunkee:

there should be an end user repository for tricks, examples and best practices.

I'm going to be attending the Flare 8 Roadshow soon. I'll bring this up there and see what both the Madcap reps and the other attendees think.

Maybe there's a basis for a group of Flare users to set something up on their own…

Cheers & thanks,
Riley
SFO

[wclass]

Here is my long-winded essay on CSS strategies. Basically, I think it is important to have different settings for the different output targets, but you can choose to use mediums or separate style sheets. Here is how we have set up our styles.

We have ended up with a more complex set-up, but it seems to work for us (a team of 4 with 30+ projects).

All our main styles are set up in a general style sheet, let’s call it “basicStyles.css”. That includes settings for body, headings, lists, etc., as well as our table styles, with corporate colour settings and so on. This style sheet is used by all team members for all our projects.

We then have a smaller style sheet, let’s call it “projectStyles.css” that is created for each project. It imports the basic set and then includes any styles specific to the current project. This is the style sheet that is linked to the topics and becomes unique to the project. The extra styles usually include Madcap specific ones like togglers or glossary terms that get used within the project that we hadn’t thought to set up earlier.

While I know this sounds a bit convoluted, there is a reason – it means an author can experiment with styles and formatting and keep it local to a project without messing up the shared style sheet. As we discover useful new styles we add them back into the original basicStyles file. It would certainly be possible to just have the basicStyles sheet and make changes as needed.

For our different outputs, mainly webhelp, CHM and Word files, we also use “mediums”. The webhelp and CHM files use the default medium, and we have created separate mediums for msWord, and PDF. We assume the “print” medium is used when printing webhelp pages and so we actually created separate ones for Word and PDF. The main changes are for fonts and sizing, plus we choose to set web-specific styles, like for navigation, to “display:none;” and so use the medium to exclude formatting rather than condition tags (condition tags are then used strictly for content not formatting). Using the existing Print and Non-Print styles is too restrictive when there is a range of different print output formats.

We have some groups who have their own colour schemes – this is handled by creating another medium for the group and setting up the styles accordingly.
We keep the medium settings in separate .CSS files and use the CSS import function to include them in the project style sheet. When building output, we don’t need to change stylesheets linked to any topics, all we have to do is select the right medium on the target and it all works. The “medium” info could all be kept in the basicStyles file if necessary, but it is easier to maintain if they are all separate.

I have done some testing for mobile outputs and more recently, eReader output, and have used the same methods – we created a new medium for each of these outputs. However, we came across a bug. When generating ePub format, the compiler does not seem to recognise the @import function and so does not include our basicStyles.

We set this methodology up back in the early days of using Flare (from v1.0). Nowadays, because you can set up a default style sheet, and assign a Master sheet to a target, it is really easy to change from one stylesheet to another. So while our system works for us, if I was starting over I would look more seriously at maintaining sets of stylesheets and linking the right sheet to a target.

[Phlawm53]

Thanks wclass for that truly informative contribution! Your comments on the mobile Medium was very useful as I try to gracefully move towards delivering to mobile outputs…

Cheers & thanks 'gain,
Riley
SFO

[techwriter31]

We only have a handful of outputs right now - 8x11 PDF manuals, 4.75x4.75 PDF quick start guides, and online outputs (CHM and webhelp). We've got one stylesheet with 3 mediums defined. The stylesheets are stored in our global project, and imported into our local projects, using global project linking.

One thing that I've implemented and found really useful if you're translating content, is to create stylesheets for each language. The translated stylesheets use the import feature, and then only contain the differences between the English and the translated stylesheet (mainly for autotext used in figures, table titles, notes, and cross-references). This saves us from retranslating the autotext and also allows us to control formatting for specific languages. For example, in our Japanese translations, we never want to use italics. Our translation vendor still always delivered the content with italics, so I modified the stylesheet to remove italic formatting for this language, and the problem was solved. Another example, is specifying specific fonts for certain languages. Now we can control the fonts used, and the translation vendor doesn't have to use separate fonts for English content within the translated document (proper names, etc., that would not be translated) and eliminates the need for local formatting in the translated topics. We just request that the translation vendor specify the translated stylesheet in the target when generating the output and it works great.

[Phlawm53]

Thanks techwriter31 for this one:

One thing that I've implemented and found really useful if you're translating content, is to create stylesheets for each language. The translated stylesheets use the import feature, and then only contain the differences between the English and the translated stylesheet (mainly for autotext used in figures, table titles, notes, and cross-references).

That's a Heck of nifty idea!

Cheers & thanks 'gain,
Riley
SFO

[techwriter31]

You're welcome! It has definitely helped reduce translation headaches and costs.

[SolenaLeMoigne]

We have one Flare project per target language and using different CSS makes perfect sense, so thank you for the wealth of information I've just received browsing through this topic.
I was wondering if there was a way to tell Flare "this project is in Swedish" and have, say, the hyphenation follow the rules of the specified target language? Or do I have to specify theses rules style per style in the CSS?

[jasonsmith]

Hi Solena
you can set a project to most any language you want by setting Project > Project Properties > Language. At least this activates the correct spell-checker, I don't know whether hyphenation rules are defined as well.

[SolenaLeMoigne]

I have checked the help back and forth, and it seems the hyphenation settings are not language-dependent. For the time being I have resorted to turning hyphenation off in all used text styles, and it has made the translators a bit happier, though the ragged edges are really too ragged to my taste, but I can live with that.
More info once the tech support has given me an answer that works.