Re: GUI vs Hand ...

Subject: Re: GUI vs Hand ...
From: "R A Downey" <rdowney -at- matrox -dot- com>
To: "\"TECHWR-L\"" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Tue, 30 May 2000 15:58:30 -0400

Background: I work with systems that primarily use HTML as their source of
online help. Not HTMLHelp, but raw version 3.2 of HTML. I'm hoping to
upgrade to version 4.0 with the upcoming project.

>In light of the capabilities of some GUI web-authoring programs, it is no
longer fiscally responsible
>to code web pages by hand anymore."

I agree with this statement 100%. However, it is far too easy to assume that
any old GUI will do. Anyone designing web pages, or converting information
into HTML still has a few things to consider. The ideal solution is still a
good GUI of the user's choice with either notepad or some other HTML editor
to allow for minor changes to be made (tweaking).

1) They may produce bloated code.
If your Target audience is middle-America, where average modem connection
times are slower than the east and west costs - then bloated code is a
problem. You'll be forced to keep your pages short and thin.

If your target machine (I.E.: for built-in help in a hardware device) has
limited memory and limited paging functionality (assuming it does not have a
fake-file system) again bloat may not be acceptable.
As an example of this I present the Matrox iSwitch 8 (8 Ethernet Port, 4
Serial Ports, switching device to share internet connections). It had a 40KB
maximum for HTML file sizes primarily because of memory constraints. The
HTML help files were literally compiled and compressed into the code and ran
off a 4meg flash.

I was using FrontPage at the time and it took me up to a day to remove the
additional tags that FrontPage insisted in replacing each time. The device
couldn't understand FrontPage code and could never use FrontPage code and I
could neither turn it off nor permanently get rid of it.

Also with wireless web coming in, bloat just got even uglier. While fast
connection speeds are assumed for the coasts of North America; such
assumptions are questionable for the EC and downright dangerous for the rest
of the webbified world. To code HTML *assuming* your customers have a nice
big color monitor and T1 (or better) connection is never a good idea. Web
browsing clients seem to have little or no patience. If it takes a minute
(or more) to load they often assume the page is broken and go elsewhere.

So the master GUI *cannot* produce bloated code. If it does, it will not
solve all the problems, and coders will still have to crack open Notepad to
fix the problem.

2) Would they notice?
When sites and developers stop relying on reviews to promote their products,
I would say - then it would be safe to have sloppy code. Conditional, of
course, that sloppy code did not mean broken or misleading links - for those
would always be noticed and could actually drive customers away.

Consider the first few pages of your web site to be a display window. If the
display window is badly designed, few people will enter the shop. Not only
do you need good content (which, imho, is the most important aspect of them
all) - it has to be well organized and designed so people can find the
information for which they are looking. The design has to survive many
changes for, as you say in #3, information has a very short lifespan.

Would they notice bizarre formatting of the html code, funky graphics names
that show no logic, and stranger directory structures? No.

But they would notice:
* Missing graphics (due to moved files or misspelled directories/links)
* Bad formatting (dark background stripes overwriting body text is the most
common of these I've seen, but also frames, tables and layers that overflow
the display area of the browser, with no way to scroll or resize.)
* Bad forms and scripts (things that give you error messages in your
browser).
* Bad or missing content (badly written, or just bad links).

So there's sloppy (i.e. the code that Dreamweaver 3 produces doesn't look
that pretty as code), and then there's bad (i.e. code that has noticeable
errors). The former I don't think users would notice, but reviewers
(especially if they can find nothing better on which to comment) would; the
latter everyone would notice.

3) Data dies early ...
With the need to keep web pages continuously updated perhaps HTML should be
replaced entirely by ASP or some other form of database-oriented, script
updateable site. Still, while the content must be as fresh as possible (our
corporate site receives a couple of new pieces on a monthly basis, and that
is considered "slow"), if it doesn't look right or read well you might as
well not have any content at all.

Op-Ed pieces written by the multitude at large may be quickly produced, but
they are rarely read. Check out slash-dot (www.slashdot.com). There's tons
of content there, but they also provide a way to rate their own posts so
people don't have to muddle-through the vast number of posts available.
Without this feature, slash-dot, IMHO would not be near as popular as they
are currently. Their site is updated twice daily with new information, and
posts are carefully backlogged so people who bookmark odd pages (like
myself) don't have to worry about dead-links as often as one would expect.


---
Rebecca Downey
Matrox Networks
Technical Writer
e-mail: rdowney -at- matrox -dot- com
web: http://www.matrox.com/networks






Previous by Author: An interesting editorial: Learning from abuse
Next by Author: Re: working with other writers
Previous by Thread: Found it online:On em dashes and other lingua interrupti
Next by Thread: Re: GUI vs Hand ...


What this post helpful? Share it with friends and colleagues:


Sponsored Ads