Re: GUI vs Hand, Was: estimating the cost of building a web site

["J. Wynia" <jwynia -at- earthlink -dot- net>]

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

My Statement:
"In light of widely varying capabilities in web-related tools, it is not
fiscally responsible to exclude any method of coding web pages which is
efficient given the results."

>NOTE: I'm talk refering to those of us that use a GUI program to
>create the complete page then go to code level to touch-up a
>link or two. I'm refering to those who's main web application is
>a text editor.

I think another poster hit on this, but "text editor" covers a whole lot of
applications with a wide range of functionality. Consider that "word
processor" is a term that does the same thing. Microsoft Works is a word
processor and some would argue that Frame is one as well (I wouldn't, but
some would). Similarly, Notepad is a text editor and so are emacs and
products like 1st Page 2000.

Given a powerful text editor with extensive macros, keystroke bindings,
syntax highlighting and an expandable snippet library (my current setup for
web work), I can "hand-code" my way to exact results just as or more quickly
than many users of GUI web-authoring tools. I started out hand-coding HTML
when there weren't really any WYSIWYG editors (circa 1994). I continue to
use this method (with timesaving macros added) because it gives me precise
control at pretty much the same pace as default control in a WYSIWYG
program. I use the same setup for PHP/MySQL web programming. Most of the
good web-programmers I know (including those who use Interdev) use text
editors or the text mode of their IDE's.

>
>1) They may produce bloated code.
>However, in light of higher speed access and cheaper storage,
>does 1k or so matter anymore.

To me it's not the download speed or storage that's a problem, but
maintainability and readibility. If you need to go into the HTML itself to
fix something, clearly coded, well-indented HTML beats Frontpage, MS Word,
and most other non-text editor output hands down to find and fix problems in
layout as well as for updating.


>
>2) At $100 per hour or more for a developer, would a customer or
>employer rather have 1 or 2 pages in an hour of sloppy code or 1
>page in several hours (or days) of tight clean code?  Would a
>customer know what clean code was if it hit them between the
>eyes?

The same arguement could be made for cheap tech-writers that crank out
sloppy manuals and help systems. However, TW's on this list typically
lambast those writers as a drain on the industry. After all at $50 per hour
for a tech writer, would a customer or employer rather have 1 or 2 help
topics per hour of sloppy writing or 1 or 2 topics per day of clean,
understandable text? Would a great many of the customers know good clear
writing either? Some do, but others don't notice the benefit until there is
a reduction in support cost.

>3) More and more information has a short half-life, when after
>that limit, the value of the information is reduced or lost. Is
>it more important to save several minutes or several bytes.

That applies to writing as well. Is it more important to save several
minutes or eliminate several redundant statements

J.
(Not being argumentative, despite what it may sound like.)