FEDERAL
SECTOR REPORT
January 1998
(c) P2C2 Group,
Inc.
IN THIS ISSUE
Proposals & HTML
Code
PROPOSALS
& HTML CODE. Over the past year or two there has been talk at
the Association of Proposal Management Professionals about putting
proposals on-line at a WWW site maintained by the bidder. There are a
number of advantages: Government proposal reviewers can use hyperlinks
to jump quickly to the specific information they want to review. Web
search tools can help reviewers find specific information they
seek-possibly increasing the offeror's chance of scoring extra
evaluation points. The web-based proposal might even include various
enhancements, such as color graphics, audio, and animation that are
difficult to replicate on paper. Of course, many funding sources will
not consider "web proposals" at this time, but this could be an
important trend for future proposals, especially for large and complex
procurements where paper documents are horrendously complex and
voluminous.
WHAT'S
THE SWEAT? You already have the proposal in MS Word or Corel Word
Perfect, right? The current versions automatically convert to hypertext
(HTML), right? So putting the proposal on the web should be a snap!
Well, maybe.
HERE'S
THE HITCH. True, the word processor will put the text in HTML, and
you can view it on the Internet. But there are some problems:
The image area of
a sheet of paper
(8-1/2 x 11) is quite different
from a computer screen. Generally, it takes two or three screens to
equal
a paper page. This presents challenges for graphics, text, and the flow
of
ideas. It's the opposite problem of taking panoramic cinema views of Lawrence
of
Arabia and squeezing them onto a TV screen.
The automatic HTML
generators of word
processors produce HTML code
that is difficult to maintain.
HTML
CODE REFORMATTING. I write much of my HTML code "by hand" because I
like greater control over layout than permitted by most code
generators. One of my pet peeves about the latest word processors (Word
8, Corel Wordperfect 8) is that they change HTML source code.
I
prefer to write code like other computer code (such as C), were the
structure of the code is visually evident through blank lines and
indentations. However, the word processors (which can generate HTML
code) tend to clump all of the codes together ... so that it looks like
the spaghetti code of 1979, when programmers where attempting to cram a
BASIC program into 4K or 8K of RAM on early microcomputers. This
rearrangement makes the code nearly impossible to read or maintain ...
unless you capitulate and use the word processor on its own terms ...
as a generic code generator that is never touched by human hands.
BATTLE
OF THE TITANS. A fact widely known to web site developers is that
various browsers interpret HTML code somewhat differently (quite apart
from the Netscape- and Microsoft-specific code extensions). In revising
my web site, I ran the code through three different browsers and had to
tweak some of the code to attain reasonable conformity in different
browsers.
One
of the cute idiosyncrasies was the MS Word generated code that could be
read easily read by Internet Explorer 4, but the code tripped up
Netscape Navigator 2.1 and 3.x. Some of the problems were illogical
placement of HTML codes. Programmers know to "nest" their code, but the
word processor would sometimes place codes out of order. For example,
bold <B> and italic <I> were sometimes placed outside of
new paragraph <P> definitions ... and were not recognized by
Netscape. One anomaly is that MS Word cannot read all of one page that it
generated, even though Explorer and Netscape can indeed read
it.
I'm
not really complaining. The headaches keep unemployment low and
technical interest high.
