TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Online & Offline Doc Help From:Peter Neilson <neilson -at- windstream -dot- net> To:Joe Sokohl <jsokohl -at- mac -dot- com> Date:Mon, 26 Jan 2009 20:30:07 -0500
Joe Sokohl wrote:
>
> find data that focuses on readability? Ex. Sans serif vs. serif, multi
> column vs. single column, color choices, etc. I have spent some time
All I can offer is my private opinion, but I always feel as if I'm in
the wrong universe when I'm trying to read a document that was
especially prepared for on-line viewing, but that has multiple columns.
It'll usually be too wide for my screen, as well, and not designed to
resize properly, so I find I have to go up, down, left and right over
and over again just to page through the text. The standard way to
prepare these monstrosities is to build them as PDFs, but I'm sure that
it's possible to make them in HTML as well.
This is your opportunity to do what you were asked to do and to make
readers happier as well, all in one action. I'm sure you will find
opposition from those who trot out the idea that narrow columns are
easier to read. They are almost right, and I'll bet it's possible to
produce HTML that runs a narrower-than-usual column that's still within
a resizable page.
Occasionally I'll find something that's done so poorly that the type
size is constrained to be too small to read. That's usually correctable
by expandifying the view of a PDF by zooming in, but I shouldn't have to
do that.
The worst offenders in bad PDF design seem to be government entities,
because they never have to listen to feedback from their users. I've
noticed they often lack any facility for receiving meaningful feedback.
The organization of government webpages is a wonder to behold. For
instance, you might have to plod through a long set of steps (divisions
-> departments -> facilities -> facility management -> parks&recreation
-> parks -> schedules -> Jason W. Jason Memorial Park) just to find out
when the Jason W. Jason Memorial Park is open, only to find out that it
won't display on your installed software.
For bad color choices, think of "light on light" or "dark on dark". When
testing colors, you must rely on users of several different kinds of
hardware and software, as well as people who are color blind. That a set
of "corporate" colors works well in print does not guaranteee it'll be
readable or beautiful when rendered on a screen.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals. http://www.doctohelp.com
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
