Re: George Hayhoe's Observation

[Mary McWilliams Johnson <mary -at- SUPERCONNECT -dot- COM>]

Tim, I thoroughly agree that modern, super-smart HTML editors can lure folks
into using gimmicky coding that has nothing to do with designing a Web page
to deliver the site contents in the most user-friendly manner possible.

I certainly don't intend to use stylesheets or DHTML until such time as 99%
of all Web surfers have browsers that support them consistently.

I do think some day (a long way off) we will take advantage of stylesheets
to apply font characteristics and object placement instructions to our Web
pages. This could mean a big saving in time and effort in updating a Web
site. We will code once and then apply a new stylesheet when we want the
site to have a new "look."

One thing an editor like Dreamweaver can help with right now  is analyzing
our code to determine how various versions of various browsers will
interpret it. Since it's almost impossible to keep every version on my
computer, it's nice to have a tool that alerts me to coding that isn't
universally acceptable.

Cordially, Mary

======================

At 10:42 PM 4/11/98 -0400, Tim Altom wrote:
>Thanks for the information, Mary.
>
>My concerns were at least partly procedural, rather than technical. I can
>still remember the awful early days of DTP when every DTPMonkey thought that
>he or she was a repressed Gutenberg and just had to impress everybody with
>their command of fonts and rule lines and...well, you know. The documents
>were crammed with useless or ugly elements that did nothing to create a
>coherent whole and were almost impossible to quickly update. Or worse, the
>elements were beautiful and whole was artistic and STILL almost impossible
>to update quickly. Nobody asked the purpose for the document. Its purpose
>was manifestly assumed to be to impress the boss.
>
>I see many websites of the same character. When I see a beautiful or even
>highly creative, bouncy, saucy, glittering website, I have to ask myself who
>in the bloody Heloise has the time to play with such things when the whole
>thing lacks any coherent purpose.
>
>The tools may exist to do such things pretty reliably, but as long as
>browser definitions remain in flux and new HTML standards pop into being
>every few years, there's no way to sleep well at night. I have found that,
>tools notwithstanding, there is a direct correlation between complexity and
>fragility. And between complexity and time/money. And complexity and
>difficulty of updating. The tool may even ensure that every current browser
>will read the tags pretty much the same way, which is a step forward I
>suppose. But that's not nearly enough. I personally think that the rush to
>cascading style sheets and Java applets subverts the essential purpose of
>the Web, which is to transfer information. Like a manual with an
>annual-report cover and a lousy organization, too many websites are created
>by the tools, not by a plan.
>
>Based on my long experience in help file design, the niftier the tools
>become, the more likely it is that lesser practitioners will come to rely
>more and more heavily on the tool to rescue them from their own
>incompetence. It's happened in help files...the most common question I get
>is "What tool do you use?", which betrays an appalling lack of knowledge. I
>used to get funny looks when I said "Microsoft Word 2.0". Even today, you
>can do help files and Web pages right in there, although I wouldn't
>recommend doing either that way today.
>
>Tim Altom
>Simply Written, Inc.
>317.899.5882
>http://www.simplywritten.com
>Creators of the Clustar Method for task-based documentation
>
>
>Happy news. An HTML editor now exists that will tell you exactly which codes
>will work on which browsers. It's Macromedia's Dreamweaver. It costs more
>than other WYSIWYG editors, but it does more, too.
>
>