Re: Re HTML vs Acrobat

[Arlen -dot- P -dot- Walker -at- JCI -dot- COM]

   o The version of HTML to convert documents to is the version of HTML
     people are mostly likely to use in their browser to reach your page.

     [Arlen, do you agree that this is either HTML 2.0 or N-HTML 1.1?]

Actually, no. I think it's entirely audience-dependent.

First question is controlled or uncontrolled audience. In other words, are
you in a position either to control which browser is used or know in
advance which browser will be used? The "controlled" audience is possible,
ISTM, only in the case of an internal doc set (as I mentioned, I totally
skipped the origin of this thread so I don't know what kind of docs we're
talking about). If, for example, your clients will only be internal and you
use only MS IE for your browser, then write for that browser.

Assuming uncontrolled audience, then examine the browsers they use. You can
do this either via open survey or via covert checking (covert checking
something via coding on the web page is generally Not Nice, but if all
you're looking for and maintaining is a count of browser type, then it's
more likely to be Not Nice But Tolerated).

This yields a soft number, meaning it could change in the future. Right now
it's heavily weighted towards Netscape, but my gut feeling is that Netscape
and IE will gradually settle toward a parity with each other in the market
over the near future. In the long run it could be different.

Take a look at the browser numbers and decide who you want to alienate. If
the answer is "no one" you're in for a tough call, as anything you do will
alienate someone. You're probably best off going with HTML 2.0 for now.
HTML 3.0 is coming, but when it does all of its features may not be
supported by all of the browsers, so you'll want to avoid those features
which cause trouble for your audience. And be sure you use ALT clauses in
all your graphics to accomodate the Lynx users out there.

Test your pages in all the browsers your audience uses that you can. It's
tedious, but for right now it's the only way to be sure you're treating
your readers right. (Don't rely on them to tell you; most likely they'll
just stop visiting if the page looks horrible to them.)

     - I maintain it's inherently easier to create pages on the fly from
       a database with ASCII (HTML) then binary (PDF).  See also Web page
       creation from a file server.

Since databases don't care what's stored in them (binary or ASCII) any more
than file systems care what's stored in them (binary or ASCII) I don't
agree that ease is inherent. ISTM all that is needed on an elementary level
is an HTML wrapper for the PDF document(s) stored in the database. Now, if
you're heading towards rewriting the text on the page based on the query,
you're headed for a more difficult time. Still, I don't think most of us
have our text currently stored in a form which would make that easy, so it
doesn't help us to have that feature now. If we begin towards that goal,
I'd expect to see some PDF tools appear to support the trip. Early adopters
of that approach would probably have to use HTML, as the PDF tools wouldn't
be there, yet.

There's pressure on a small portion of tech writers to go in that direction
now (a larger, but still small, portion of marketing writers). If you fit
that, then HTML is your best hope, and I wish you luck.

   o I maintain that there would be no motivation for Netscape to move from
     Netscape 1.1 Helpers to Netscape 2.0 Plug-ins unless RAM was a
   significant
     difference.

Yes, here we continue to disagree. I see another reason to move their
market toward plug-ins and away from helpers. If I have helper apps, I can
use *any* browser and get the same benefit. If I have Netscape plug-ins,
then I can only use Netscape or Netscape-compatible browsers. Therefore
Netscape has locked me into a market which has their name on it. Sound
familiar? It should. It's the same strategy MS used in the desktop wars.

     [Technical Detail: Acrobat invokes a separate application for many
      plug-ins - each of which uses up more RAM - while Netscape plug-ins
      are built into Netscape  - using up no additional RAM.]

The extra RAM only becomes an issue when you're loading lots of helpers.
Personally, I'm not. I don't know about anyone else, but the helper app
which I loaded most frequently is Stuffit Expander (which de-Binhexes file
transfers). And that was a helper app even under Netscape, as there's no
Stuffit plug-in.

When we look at a document to see what's likely to be in it I can see text,
pictures, perhaps a movie or sound file for added explanation. Both text
and pictures require no plug-ins for either client to see, and both movies
and sound are handled by existing plug-ins in both clients (Netscape and
Acrobat). So I don't see this part of the discussion as anything other than
a red herring. Sorry.

And, as I noted, I'm doing more CyberDoggin' than Netscapin' lately and in
that case the extras are Open Doc Part Editors, which are basically the
same as plug-ins except they work for the entire OS, not just for Netscape.
In other words, the OD part that lets me view movies will let me view a
movie from my OS as well as within Netscape, with the same performance and
the same interface. (BTW, Netscape will become an Open Doc Container soon,
and there will also be a framework under which Netscape plug-ins will
become Open Doc accessible, so the distinction here may be blurring. When
Acrobat becomes one as well, I can have the best of both worlds.)

Special note to those watching the MS/Netscape vs HTML wars. I ran across a
great addition to a page recently. The creator had taken the "Enhanced for
Internet Explorer" logo that's been appearing around the net and removed
the "Internet Explorer" text and replaced it with "Lynx"! ;{>} Kudos to the
webmaster, and because of the possible MS lawsuit depriving us of the
continued presence of his wonderful sense of humor, I'll not name the page
(not even privately -- if you're that curious, find it yourself; if you
know me, it shouldn't be that hard to find, and if you don't know me,
there's no way I'd tell you anyway).


Have fun,
Arlen
Chief Managing Director In Charge, Department of Redundancy Department
DNRC 124

Arlen -dot- P -dot- Walker -at- JCI -dot- Com
----------------------------------------------
In God we trust; all others must provide data.
----------------------------------------------
Opinions expressed are mine and mine alone.
If JCI had an opinion on this, they'd hire someone else to deliver it.

                  TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send administrative commands
         ALL other questions or problems concerning the list
       should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-