The statment that he made is absolutely correct and utterly immaterial to
his current business situation. Every day that Netscape futzes around with
HTML it renders itself more vulnerable to companies who innovate at higher
application levels.
I used to make a little extra money as a graduate student in 1980 adding
IBM's script code to other student papers and theses. You would add
commands into the body of the text that all began with a period in column
one--which I think was state of the art for then, DEC had a similar language
and laser printers cost more than 100K. Now I convert RTF/MIF/ASCII into
HTML and it's not clear that I have come all that far 15 years later
(actually we do most of our work as CGI, but that would spoil this argument
and I believe that the basic paradigm is still high craft, not high tech).
HTML represents a slight improvement over putting a period in column
one--except that it's online viewing and you have hyperlinks and images and
sound and...OK, OK I give--but the view of the creation process is the same.
And I think that it's this view on the part of many webmasters--that emacs
or vi or the Notepad editor is the HTML creation tool of choice--that drives
the perception of "he who has the better tags has the better product" is the
way to measure innovation. From 1980 onward the directions that desktop
publishing took had little to do with better script tags. And a lot to do
with applications built upon layers of standards (and cheaper laster printers).
o You don't want a slighly better postscript every six months if it breaks
your DTP applications
o You don't want a slightly faster etherenet connection each year, if each
new set of signalling characteristics breaks your link to the printer
o You don't want a slightly better cpu if none of your applications
can run on it.
o You don't want a slightly better HTML if you have to build it,
update it, and "publish it" by hand.
Standards protect users existing investments because they focus innovation
on higher levels of application abstraction. Netscape would be much better
served to come with up client and server applications that leverage the
existing HTML spec to the hilt. And they will soon have to or someone else
will come out with applications that obsolete the current WWW publishing
paradigms:
- The way to build HTML is to hand craft it.
- A webmaster is required to mediate access to new document publishing,
unlike, for example an Apple file server where anyone can put useful
data that can be shared with anyone else.
- Conversion from (pick your favorite DTP package) is troublesome and
the original document really doesn't contain intelligent link info.
I believe that none of these statements will be true in two years, at the
most. Certainly once you break the "HTML is built by hand" paradigm, and
the implication that learning new tags represent higher levels of personal
mastery, new tags become simply opportunities for software incompatibility
and should be resolved as such. Knowing how to type in HTML will be as
useful as knowing RTF, or MIF, or even Script.
And this is how a little company will get ahead of Netscape, by addressing a
higher level problem than expanding the encoding set for HTML. Moreover, at
least in Clark's case, he is not at all worried about a little company
getting ahead, because Netscape has the financial wherewithall to buy them.
He is worried about Microsoft.
He is worried that Microsoft will change the rules on him by forcing their
customer to build "invalid" HTML. And his fears have come true. But the
answer is not more HTML innovation (at least to a first order) the answer is
more powerful HTML/HTTP/MIME-based applications. Netscape is solving
the wrong problems, and encouraging its customers to do likewise.
I believe the most pressing enterprise marketing challenge for online docs
is to be able to publish your message in each distinct format needed, from a
common representation, and subject to common controls. The second is to be
able to take feedback from prospects, customers, partners, "in-band" from
the external WWW site and wire it into the internal, fire-walled Web.
I don't think that rushing to implement <UL PLAIN> in your literature is as
important as having all of the formats (e.g print, slide, CD-ROM, E-mail,
WWW) that you need easily built and updated from a common set of source
materials.
I don't think developing the ability to generate junk e-mail is as important
as the need to manage incoming e-mail (e.g. filter/route it, store it in a
context-searchable fashion, publish it on the WWW, and reap it when it's
obsolete) in a common context with WWW and newsgroup information as a key
part of many business relationships.
______________________________________________________________________________
Sean Murphy, President, Leader-Murphy, Inc. (skmurphy@netcom.com 408 252-9676)
WWW-Enabled Applications and Methodology Consulting: "Knowledge, Refined from
Information Derived from Data, is the Fundamental Asset of the Enterprise"
URL: <a href="<a href="http://www.l-m.com/l-m.html">http://www.l-m.com/l-m.html</a>">http://www.l-m.com/l-m.html</a> &amp; http://www.e2w3.com/
______________________________________________________________________________
----
This week's sponsor:
Marketing to Women Online Conference &lt;<a href="<a href="http://kelseygroup.com/kelsey">http://kelseygroup.com/kelsey</a>">http://kelseygroup.com/kelsey</a>&gt;
Talk with Mary Morris on Tuesday, Oct. 10, at 4 pm Pacific/7 pm Eastern
over the Internet using GlobalStage/GlobalChat software. See
&lt;<a href="<a href="http://www.popco.com/hyper/internet-marketing/chat.html">http://www.popco.com/hyper/internet-marketing/chat.html</a>">http://www.popco.com/hyper/internet-marketing/chat.html</a>&gt; for details
Post a message to this group by filling in the form below.