I think that Flash and other dynamic tools could explain to developers
the need for certain designs, but there is a limitation there in that
you have to think somewhat 'logically and rationally' just to make the
exact bit of interface you need to explain. It's an uphill battle for
most designers to understand script in the slightest. Requiring
scripting on a design team is going to limit who you can hire,
I think we are better to try to explain the assets of code to
designers. What a system is composed of, how elements come together and
what is called what.
I'd say most coders are willing to listen as long as you have the right
names for things. It's a new set of taxonomy, and it's pretty logic
driven, but it is how they talk and knowing the basics of their
language might give us a bit of leeway in terms of working with them.
On 10 Mar 2004, at 11:58, Jason Moore wrote:
> I think the key strategy is not to sound like you want to be the guy > who doesn't code but has lots of great ideas. (I think most > programmers' nemesis are all those business/marketing people with > great ideas who can't code. see dilbert.) The requirement to be a > "coder" is really a requirement to "thinking logically and rationally" > and being able to get things done. e.g. If you can make amazing flash > demos that demonstrate how a widget or feature will work, I think an > interaction designer could easily join and contribute to any open > source project.