Re: PDF vs HTML

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 10:52 AM 3/22/00 +0100, Cas Tuyn wrote:
>----------------Snip--------------------
>My EUR 0.02 regarding Dan's mail (clipped slightly):
>
>> What Utter Nonsense!
>> 1. Experimental results have established that .....
>> 2. Experimental results show that .....
>> 3. ..... people understand more when the
>> screen looks like a well-designed printed book.
>> 4. Real-world experience ..... Most people who browse through 
>> long HTML documents adopt the print-before-reading habit
>
>IF 
>   you see online publishing as onscreen viewing of information
>   layed out such that it requires an A4 monitor with a 600 dpi 
>   resolution, 
>AND 
>   you do not have that monitor,
>THEN
>   everything Dan said makes perfect sense.
====================================================================
Exactly what is it that I stated in my original post that would make you
conclude that I suggested there was a preference for any particular page size?
In other words, my statement that comprehension and retention improves
radically when the on-screen information "looks like a printed book" doesn't
mean that the on-screen page has the same dimensions as its printed
counterpart. It's the typography and layout that counts, not the page size.
PDF is the easiest and most effective way of replicating the typography and
layout developed in a high-end DTP such as FrameMaker. 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>OTOH, when you take the limitations of your reader and his/her
>screen and environment into consideration when you design the 
>new layout, HTML may approach the readability of the paper 
>publication. 
============================================================
Prove it.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>In industry/business environments with 800x600 screen laptops 
>and paperless environments the typical multicolumn, side-headed 
>A4 PDF (with print resolution graphics) is a scrolling exercise, 
>and a memory/diskspace hog too. Furthermore, when you change a 
>few words in a PDF file, the whole file needs to be replaced, 
>while HTML is normally split in many small files, so you only 
>have to ship a small file.
===========================================================
Now, tell me why PDF files can't be split into many small files.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Some realworld experience: since 1994 I used FrameViewer to 
>publish our 3000 FM files and 5000 illustrations, arranged in 
>small files per Frame's documentation recommendations (see 
>Chapter 18, Planning online systems).
============================================================
So, when you switched to HTML, you lost all the robustness of FrameMaker
(popup links, matrix links, message links, better typography and layout, etc.).
Do you still think you made the right decision? Please explain why you
didn't stick with FrameViewer.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
>Last year I had the choice between PDF and HTML. I chose to
>create the navigation in PERL, which accesses a plaintext 
>database with all files, and when you click on a link, you 
>get a WWP prepared HTML file.
===========================================================
Old-fashioned. The same thing could be done much better using XML.
XML provides attributes and the Reference Description Framework (RDF) that
allow the user to query an XML database for the particular information
he/she needs, and then have the "hits" delivered, fully formatted, on-the-fly.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>To avoid an output format battle, BOTH formats may produce 
>acceptable results, when designed with the end user in mind.
>I thought HTML was a bit underexposed in this particular thread,
>but I use it as well in addition to HTML, when people want to
>print the documentation remotely.
================================================================
The fact remains that all of us have had extensive experience with reading
complex information on-line, and every single one of us knows there is an
enormous drop-off in comprehension and retention compared to reading the
same information in printed form. It shouldn't be a surprise to anyone that
this drop-off has been confirmed by many scientific studies. 

Like airplanes, space shuttles, and computers, on-line documentation must be
designed to survive in a worst-case environment. For on-line documents, this
is the worst-case combination of screen size, resolution, display quality,
and font availability on user platforms. So, we're talking a laptop with 800
x 600 resolution. 

Given this worst-case environment, the "paperless environment" you mention
above is a pipedream, at least for now. The worst thing that's happened with
the advent of on-line documentation is that the bean counters jumped in and
said: "The paperless office is here! If we deliver our documentation
on-line, we no longer have to deliver those expensive and hard-to-maintain
printed books."

Those in the documentation business who let this happen now have to live
with the knowledge that they didn't stand up to the bean counters when it
counted, thus they don't like to hear anyone remind them of their
dereliction by bringing up the dirty little secret that printed books are
vastly superior.  
     ====================
     | Nullius in Verba |
     ====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com
10044 Adams Ave. #208, Huntington Beach, CA 92646
---Subscribe to the "Free Framers" list by sending a message to
   majordomo@omsys.com with "subscribe framers" (no quotes) in the body.


** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **