Chris Snyder wrote:
The only problem is when a designer comes up with a design that can't be
expressed in HTML or doesn't work easily with your coding framework of
choice. That's what I mean when I say the HTML knowledge should inform the
design process too.
Exactly. When a designer takes on web work they have to learn the
limitations of the medium: web fonts for body text, no custom form
controls, no flowed text. I'm happy to educate anyone I'm working with
about what is a bad idea, what is really expensive, and what is
impossible.
I think you should rather educate everyone including yourself about what the
end-user wants. It is well possible that the end-user doesn't need fancy stuff
and eye candy, but unless you _are_ the end-user I'd be a bit careful about
ironing over all this with the "we don't need this stuff" approach.
Clearly define what is asked for and required. That is why a business analyst
should have no clue about coding, but know everything about the end-user /
customer. And that for the same reason why developers make really bad software
testers. First figure out what needs to be done and what needs to be
accomplished, which is the point where everyone involved has a chance for
input, but without loosing sight about, yes, you guessed it right, the
end-user (which is often enough the paying customer). If after that there is
still a need for custom form controls or flowed text (or whatever else) then
so be it and it becomes irrelevant what the programmer thinks about it.
The vast majority of software created is not used by those who make the
software, so who are they to say it has to be this or that way?
David
_______________________________________________
New York PHP User Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/show_participation.php
