[Sigia-l] Designers and Developers

[Russ Unger]

> First of all, it's important to realize that HTML is not "code." It's
> declarative markup language, not meant to be executable code. It's far
> easier to pick up than a programming language, for obvious 
> reasons. I'll say
> it again, today, it would be quite difficult to get a job as 
> a web designer
> without knowing HTML, at a minimum.

I disagree, again.  Trying explaining to someone who's never worked in
markup or code what the difference is between the two.

If HTML was all it took to create a web page or anything that's of any
relevance in a web-based application these days...  Well, it's not.  You
can frame it however you would like to in order to suit your needs for
your own definitions and purposes--that happens a lot where ever a
person goes, so I'd hate for you to think of that as a personal attack.
Of course, I hate that I have to add that extra snippet to ensure that
this doesn't turn into a flamewar, but again, such as is the nature of a
lot of things these days.

> > To say that a designer would never have to write code would 
> be, to me,
> > fairly ridiculous.
> 
> There's absolutely no reason whatsoever for Designers to 
> write deployment
> *code* (not markup) when Developers are available to do it.

Maybe not--but if we break this down to job markets, I can point you to
more job listings than you'll know what to with that state the contrary.
I've certainly worked in several companies where your logic doesn't
stick.  Maybe what we're dealing with is a perfect, frictionless ideal
versus the cold, harsh reality.

Sorry, but it happens, no reason whatsoever or not, and that's a very
simple fact that has been experienced by many, many people, and because
it does, indeed, happen, it's most likely going to continue to happen
and I simply can't agree with your thinking.

> >  A designer absolutely NEEDS to know enough about the
> > tools that their designs are being deployed with to be dangerous.
> 
> I don't quite understand what you are saying here. I'm the 
> one who's been
> advocating that Designers fully understand the technical 
> ramifications of
> their design choices. There's a difference between knowing 
> how something
> works and actually doing it for *deployment*.

Perhaps a part of the misunderstanding at play here is that you've been
advocating this for years and I've been chiming in for all of one thread
now.  Exactly what I'm saying is that a designer needs to know enough
about the tools that their designs are being deployed with to be
dangerous, that is, much like I originally stated, it's imperative to
understand how things work, and it's somewhat flawed to assume that
someone can figure that out without getting down to the nitty gritty,
even if that's simply understanding "Hello World".  As for whether or
not their code goes to deployment, that's an entirely separate issue.

I've set-up processes that have been entirely successful having a
variety of roles that require cross-functional skills because of the
size of the teams that were in play.  Again, it DOES happen, it IS a
reality.

> This is beginning to sound like a Bob&Ray routine. This is 
> what I've been
> advocating here for years, as you can check in the archives.

And, unfortunately, it's sounding presumptuous and it's beginning to
have the nature of an attacking format, which is something I've tried to
work hard to stay away from in my commentary.  Chalk it up to whatever
you will, but I'll finish my piece on this thread and move to an
environment that doesn't feel quite as aggressive, which is also
unfortunate.
 
> > A developer shouldn't be forced to pick colors out of the air,
> 
> He "shouldn't be forced to pick colors," period.

No, he certainly should not.  But, it does happen.  All the time.

> > but they should understand what the colors are in use in an 
> application
> 
> Or they can just observe the prototype.

The prototype that might not have the rules in place for color schemes
or definitions as to why's and why not's for specific colors being
selected.  Very important pieces, especially if you're, say, working on
a medical application and someone decides that red is a great color for
something...

> > and what underlying meaning those may have
> 
> Why should a developer even be dealing with "underlying 
> meaning" of colors
> in an app? 

They shouldn't.  But they do, and that's why we provide documentation to
support our choices that are made.  Regardless, I'm not going to
continually justify things that actually do happen, all the time, from
Fortune 100 to unknown privately held companies, all the time.  Why
would you ever believe that they wouldn't?

> > --something that should be provided to them by a designer, 
> but should also be
> > somewhat "understood" that you don't just arbitrarily 
> create new colors.
> 
> Why? Why should a developer in Bangalore "understand" or care 
> if #000033 is
> velvet blue or plain blue, or popular in Southern California? 
> Why is he
> being asked to "create new colors"?

See above.  Still very true.  Very true right now with companies in
Bangalore with employees who, if they don't have / can't find / aren't
aware of what some of the rules are that are in place, will arbitrarily
pick whatever works for them at the moment.  Blame it on whatever flaws
in whatever processes and systems in place, or blame it on accelerated
timelines and decreased resources, or what have you--the world doesn't
stop just because [one resource] falls off a project; often times,
someone with comparable skills, lesser skills or someone who can 'ramp
up' quickly are thrown into projects and are forced to make decisions or
even randomly decide against reviewing documentation.  Why would they
ever do that?  I don't know, but it does happen all the time.

> > From the developer to designer side, I'll admit it's a bit 
> of a weaker
> > argument, 
> 
> There's no argument at all for developers dealing with these 
> issues *when*
> there are designers to take care of them.

See above.  It's far from a perfect development world.  Every single
project has its share of speedbumps and rough patches along the way.
So, what happens *when* there are no designers to take care of these
issues because they've been moved to another project and something new
has been found out?  Don't answer this, please.

> > but to think that each group is going to placed in silos would
> > seem to me to only create a greater gap in communications and
> > understanding.  
> 
> There's no justifiable reason to communicate design-oriented stuff to
> developers, as your examples reveal. Competent designers with 
> a prototype is
> by far the best antidote mitigating ambiguity and risk.

This is your opinion.  I still find it to be entirely false and I've
witnessed first-hand, in several instances where design-oriented stuff
being communicated to developers have resulted in more open-minded, more
user-thinking developers that result in better efficiencies and better
end project results.  To silo people off from one another is to again
assume that the parts individually are worth more than when you add them
all together.

Simply put, there are very rarely two types of people
(designers/developers) on many projects.  

> > If nothing else, I would say that my technical knowledge 
> and abilities have
> > helped me gain notice during the interview &/or sales process.
> 
> As it should, providing further evidence that what I'm 
> advocating works.

How?  You're advocating 2 roles with no middle ground.  I disagree.

> > The reality of the situation is that there are very, very 
> few positions
> > in the technology sector that are very focused these days.  
> There's a
> > desire to have well-rounded, much like those gen ed courses 
> in college
> > were supposed to make us, developers, designers, etc.
> 
> I guess "1.  Designers have to know much more about the technical
> ramifications of their design choices" in my original post  
> hasn't made
> much of an impression on you.

I do not appreciate the nature of the comment.  Unfortunately, it
appears that someone is unable to disagree and have their opinions
without having an attack.  That's unfortunate; this is a public list and
the new persons that sign-up should feel that this community is geared
more toward dicussions that are healthy and not those that appear to be
of an attacking nature.

> > Because when work is done in a silo, communications 
> channels break down,
> > knowledge becomes proprietary and the end result is a dissatisfied
> > client and potentially a fired vendor.  Certainly, not in every
> > situation.
> 
> I'm still waiting for someone to explain why developers need 
> to know a whole
> range of design issues, from usability to color selection, 
> *when* there are
> competent designers to take care of them.

Unfortunately, I'm still waiting for the acceptance of the fact that
these things do happen.  If you would like to frame your argument as
such that it is existing in a perfect, frictionless world, then you
might get some agreement.  No one needs to explain it--it happens, and
the why's are easy:  resource constraints, time constraints, budget
constraints and resources that already have experience in a variety of
roles because they've either a) done them before or b) learned skills on
their own.

Russ