Sam Tregar writes:
>On Thu, 17 Jan 2002, William R Ward wrote:
>
>> Well, my experience differs.  In my experience, the UI designer makes
>> a mockup which includes dummy form elements but has the look that they
>> want.  I would then go through and convert the mockup into a template
>> for them (mainly because <tmpl_loop> gives HTML people headaches).
>> Then they can carry forward making changes to the template.
>
>Ah, I see why we're on opposite sides of the fence - I generally do just
>the reverse.  After the functional spec is done, including mockups from
>the interface designer, I produce a working version of the application.
>This means I do some bare-bones template work to make the thing do its
>job.  The end result is ugly but functional and testable.  Then I pass it
>off to the designers who make the thing pretty by editing the templates.

That is making the designers do their job twice, once for the mockup
and once for the real app.  I don't think that's very efficient...

>I prefer this process for two main reasons:
>
>  - It requires me to look at as little HTML as possible.  If you're the
>    one that takes the designer's HTML from mockup to working forms then
>    you have to deal with a steaming shit-load more HTML than a bare-bones
>    version.  I hate HTML and if I have to deal with it then I want to do
>    as little as possible.
>
>  - The designers are in control of finishing the work - when the clients
>    come back with endless tweaks to the look-and-feel I don't even have
>    to hear about it.  If you let the designers "finish" before you even
>    start then you often end up holding the ball when Frenchy decides
>    orange is out this season and mauve is in.

Well, in the case I was working on (the only time I've had to work
with a real-life HTML designer), the business process wasn't up to
me.  But it worked out pretty well.  I have no great objection to
HTML, I just don't like seeing it mixed in with my Perl code.

>> Just about every HTML::Template app I've worked on has been a rat's
>> nest of loops and conditionals, but that's pretty much unavoidable I
>> think.
>
>I disagree, but maybe we work on different types of applications.

I suppose so.

>> For example, look at this page: http://airtel.cellmania.com/
>
>Lord, that is nasty.  My condolances.

HTML::Template serves just fine, but there are at least three layers
of nested <tmpl_loop>'s there.

>> One customer might want a drop-down list, while another might want a
>> list of radio buttons.
>
>Heh.  I've got a word for that kind of request - "no".  I really hate HTML
>radio-buttons.  Maybe it's because I spend so much time using Linux
>Netscape 4.  I really wish they'd finish Mozilla so I could use it for web
>development...

I try to avoid saying "no" to customers; it's bad for business.  If
they say "jump", I ask "how high?"

Oddly enough, for precisely the same reasons (use of Netscape on
Linux), I vastly prefer radio-buttons and checkboxes over pop-up lists
(though scrolling boxes are OK).  Netscape (pre-6.0) on Unix/Linux
does not handle pop-up lists well if there are more than a few
entries.

--Bill.

-- 
William R Ward            [EMAIL PROTECTED]          http://www.wards.net/~bill/
-----------------------------------------------------------------------------
     If you're not part of the solution, you're part of the precipitate.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to