Some general look and feel questions

[jbean]

The body text (p) in my output looks a lot thinner that that in the WYSIWG. The font settings for the mediums are all the same (Verdana 12). Captures below. Any thoughts ?

While on the subject, can everyone chime in on what font/size they use for Help and Print ? I have read some of the basic philosophy on serif/sans serif and on-line v print font size, but not really sure what is a good way to go. Right now I use Verdana 12 for all regular text, and varying sizes of Verdana for headings. Seems to look good in all outputs to me.

Finally, does anyone use a subtle color as a background for their Help topics ? Seems to me that would make it easier on the eyes, but don't want to break any "rules".

Thanks for your help and have a great weekend wherever you are.

acapelad

help-source.png

[RamonS]

Which browser do you use to display the output? Flare uses the currently installed IE rendering engine for the preview, so I'd assume that would look the same when viewing output in IE on the local machine. Since W3C standards don't explicitly specify how the rendering output has to look like you will find differences between browsers no matter what. So I'd rather go for "looks different, but OK in all browsers" rather than trying to make it look identical.

In regards to fonts, a lot of usability testing has been done and based on that fonts for print as well as different fonts for on-screen display were developed. Rough rule based on what I remember is sans-serif for screen, serif for print. I'd check with the style guide / publication guidelines of the company and adapt whatever is specified there.

For the background, I like the primitive black font on white background approach. Maximum contrast, but may be hard on the eyes after a while, which shouldn't be a problem given that on-line help is not meant and typically not used for extended reading. But here as well, check with the style guide / publication guidelines of the company. Maybe a watermark is required, which I find to be OK if it is static, means it does not scroll with the content. And of course it needs to be as pale as possible to still see it, but not disturb in any way. I am sure you can find online several resources that provide some guidance on what works better for backgrounds.

Uh, and if there is no style guide or publication guidelines, then now is likely to be a good time to create those.

Not wanting to be mean, but I hope "HOBOware Pro" is just a working title. Definitely not a good name for the US market.

[jbean]

well HOBOware Pro has been a very successful product for years and the company is continuing steady growth, even in the current conditions ....

[tekwrtr71]

I use a very light gray background. In fact, it's about the same color as the background used on this forum. It's almost white, but not so bright that it's hard on the eyes.

I've also used a very pale yellow in the past.

[LTinker68]

How items appear in the XML Editor is also determined by the GDI settings in the View menu (I think that's where they are -- I don't have Flare open at the moment).

You can be a bit more flexible in PDF output as to what fonts you use because they'll be embedded in the PDF output, unless you're using a standard computer font, like Arial. Embedding the fonts does increase the file size slightly. But if you have a corporate look and feel for print, then you can more easily match that look and feel in PDF output than you can in online output. For instance, our corporate font is Humanist 777 for print, but for web output we use Verdana. You should also specify a font-family for online output, instead of just one font.

You should also determine if you need to be 508-compliant for online output. For some industries/customers it's required. You might also want to use a relative font sizing for online output (ems or percents) so that customers can increase the file size through their browser, if they want/need to.

[jbean]

well it does indeed look better on IE and Safari, but I checked with a couple of co-workers and it looks fine for them even in Firefox, so I must have something funky in my Firefox settings.

Anyway, I changed the body background color in my style sheet (per Flare Help) but it is not showing up as background in my topics .... am I missing something ?

[LTinker68]

Are you using a masterpage, and if so, does it have a background color specified?

Also, delete the output folder before building. Some changes to the project may not be picked up because the browser caching certain information. Deleting the output folder before building forces the browsers (namely IE) to reload all elements.

[jbean]

found a body style though another door that did not have background set. did that and it works.

thanks

[forfear]

Hi jbean,
you already have a nice look and feel in the sample output, IMHO.

since you asked, here goes, in no particular order of priority.
here are some suggestions. These are in no way industry best practices, just some good advice from observed common patterns, tips and practices to put you on the road to your own high quality printed/online deliverables.
- for body text, use a slightly -off black colour, or very dark gray. it helps to make your make black text headings 'pop' out of the page- increasing readability. it also creates the subtle illusion of softer text.
- for body text for online, use a sans-serif font. as per mr RamonS
- for body text for print, a serif font is not a bad idea.
there's a very subtle psychological and statistically backed reasoning for a different choice of serif vs sans-serif fonts in print vs online output.
some popular font-sets/font-families combinations used by larger corporates
Microsoft online docs (Verdana, Arial, sans-serif) sans-serif
Microsoft post-WinVista (MS Segoe) sans-serif
Madcap online docs (Tahoma) - sans-serif
Madcap online KB (Verdana) - sans-serif
Madcap printed docs (Georgia) serif
Microsoft printed docs (Arial, Times New Roman) sans-serif
Adobe online (Verdana) sans-serif
Apple online (Arial) sans-serif
Apple print ( Myriad) sans-serif

* be watchful of white space. how much (padding) spacing you have between paragraphs, headings-paragraphs, paragraphs - list items, stem sentences - list items.
- the right amount of spacing between charactes, paragraph elements, heading elements, establishes context and sections in a document without any use of colour. its a very very low cost solution to achieve best results. for printed output designs, assume your document will never see the light of day in colour. the world is black and white or gray regardless of what the inkjet manufacturers want you to believe.
White space is for Chunking, to separate your content from each other, chunking, makes pages infinitely more readable, pleasing to the eye, easier to understand.

[forfear]

Instead of using larger fonts, font-weights, colours, or different font families to denote differences, explore the quiet visual power contained in controlling
- wider character spacing in a paragraph.
- character CASE in a paragraph.

cheers!

[jbean]

thanks so much for the input.

i was trained in Information Mapping, so am a big believer in white space and chunking.

cheers