NYCPHP Meetup

[David Krings]

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