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

Subject: Re: GUI vs Hand, Was: estimating the cost of building a web site
From: "J. Wynia" <jwynia -at- earthlink -dot- net>
To: techwr-l
Date: Wed, 31 May 2000 12:01:39 -0500


>> 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."
>
>That's a different statement...not a variation on the one I
>proposed.

I wrote my statement based on the fact that your statement fiscally excluded
a method of coding web pages. As a result, my statement addresses the
exclusion. It also allows for the WYSIWYG editor to be the development
environment of choice IF it is more efficient in the specific situation.
However, it doesn't make sense to exclude hand-coding as an archaic,
outdated mode of development when it CAN and in quite a few instances IS
more efficient.


>But how long does it take to customize your setup for a new
>environment? Can you walk up to a new machine, in a new company,
>with a new structure, and with your macros, bindings, and
>customizations, produce a new style of web site that you haven't
>seen before, based on the client's styles and formats?
>Productivity is the whole process, end to end...not 2 days to do
>a site but 3 days to setup the tools.

Actually, with my current editor, 1st Page 2000 from evrsoft.com, it only
takes a few minutes to do setup. All of my bindings, etc. are in a portable
INI file that I take with me. Most of those bindings have more to do with
using HTML efficiently than anything that is specific to a site. For
instance, it doesn't matter what type of site I'm working on, I need to be
able to insert table rows, etc quickly. My bindings allow me to do that.
Actually, many TW's installations of Word are no different except that
they're not as portable. 1st Page is licensed freely and therefore doesn't
require me to get a new license in order to begin working. You could end up
with more than 3 days to set up the tool in a WYSIWYG environment as well.
After all, if you are using a client/employer PC and your development
environment is Dreamweaver, you can't legally get working until you get a
license and get someone to pay for it. As for the new style of web site that
I haven't seen before, that problem exists no matter what type of editor you
use. If the client has bizarre styles and formats in existing HTML, both
types of editors are going to have much the same problem. If their format is
only a design, i.e. on paper, either approach will again have the same types
of problems. Ever try to get complete control over a table layout through
the WYSIWYG dialog? If you can code the table in raw HTML right the first
time, there is no tweaking to be done. Adding a link in my editor? I type it
or paste the URL itself. Adding a link in most WYSIWYG editors? Select the
link text, go to Insert, Link, type the URL or open a browser to find it and
essentially paste the URL into the dialog, and click OK. If you're using two
CSS classes of A tags? Forget it in most WYSIWYG editors. In a text editor?
<a class="classname" href="URL">Link</a>.


>I haven't found that. What I have found is if you are
>comfortable with making your way through a particular code
>structure, it is harder to work your way through another code
>structure until you become familiar with it. I'm sure that I can
>find a point in the code faster in code that I'm accustomed to
>than I can in yours, and vice versa. it'a all that you are
>familiar with.

But some code structures are inherently hard to read. For example, MS Word's
output litters the whole works with <font> tags around every snippet of
text, even if you really didn't care what font the document was in. All of
those tags have to be waded through to find the text you need to update. Of
course you'll be able to find something in a page you're familiar with
faster than something in something you're not. The same could be said of a
really poorly written manual that you've used for years. That doesn't make
the manual any better than one with clear navigation and coherent structure.
It just makes your practice useful. What you say is true, but doesn't make a
case against text editing web pages. It just indicates you should use
whatever is familiar.


>Much of what you pay for with a high-priced writer is the
>assurance that no matter what, it will get done on deadline.
>Clean or sloppy, a less experienced writer will miss the
>deadline more times than not because they cannot see the end
>while at the beginning, and therefore, don't know all the
>obstacles that will jump out and bite them on the butt. Missed
>deadlines...that the client CAN recognize.

Right. However, your original statement indicated that a web developer using
the text editor by hand is usually going to fail to meet the deadline. The
deadline is only an issue if the tools/methods are going to cause the missed
deadline. After all, you said that it is no longer fiscally responsible to
hand-code. That indicates that it will cost more(take more time) to code it
by hand. My whole point is that it can be just as if not more efficient, in
the right hands, to hand code. Not always, but that's my point. Don't
exclude any potentially efficient process/tool.


J.
(Enjoying a bit of intellectual quarreling.)






Previous by Author: Re: GUI vs Hand, Was: estimating the cost of building a web site
Next by Author: Re: GUI vs Hand, Was: estimating the cost of building a web site
Previous by Thread: Re: GUI vs Hand, Was: estimating the cost of building a web site
Next by Thread: Using Text Insets (was Comparing three documents)


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


Sponsored Ads