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.
