Ajai Khattri wrote:
On Thu, 20 Aug 2009, Chris Snyder wrote:
Yes, designers should have HTML experience. But the best designers
think visually, and need to have the freedom to do that.
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.
That would be nice, but you rather should choose the tools that suit what you
want to do, not the other way around. Way too much software is dumbed down or
misdesigned just because some framework doesn't do this or that or the
developer is too lazy to make it so. I encounter this plenty of times and like
to call it "developer arrogance".
So if HTML doesn't work, use something else. Use Flash or Silverlight, or
rethink the idea of making this app a browser based app. I am sure there are
several other options. I heard the "VB cannot do that" whine way too often, no
interest in hearing the "HTML cannot do that" whine. I know that HTML is
limiting and that the stateless process is a pain in the rear at times. AJAX
helps here a bit, but I think that heavy use of client side scripting makes
for a bad end user experience.
Good that I mention that, it all comes down to what the user wants. Not what a
designer or developer think what the user needs - or what the sales guy
thought he remembered from the last phone call.
At the company where I work we have one developer who left the team of
developers to focus solely on UI design, mainly for our browser based
applications. He crafts the UI and using his developer knowledge crafts it so
that the "behind the scenes" code is easily attached. But he no longer worries
about how things are calculated, how they are stored in the database, or how
the stored procedures work. He also often provides input for our desktop apps
and it is amazing how much you can get from a really simple solution.
I also worked with designers at my previous job who took the more or less raw
material and the embedded that into a UI. That was the exact opposite approach
and there the designers prettyfied the rough, but working product.
Either way, the designer (meaning UI designer, not product designer) shouldn't
just be a graphics artist or be treated as a sidekick. From product idea over
coding, testing, UI design to sales and support get everyone involved from the
beginning and have everyone fully understand what is supposed to get
accomplished. If the project lead has no clear vision and there is no proper
statement of scope, functional requirements, and tech specs you run into
trouble, usually later than sooner. So when working with a designer clearly
express expectations and document those. Rather spend a few hours more upfront
to really get things nailed down. And there is also nothing wrong with drawing
a picture or prototyping. Many people can't really grasp how something will
look like, they need to see it, even if it is just a cheesy mockup.
David
_______________________________________________
New York PHP User Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/show_participation.php
