Enterprise Project
About Enhydra Enterprise
Project Mail Lists
Working Groups
FAQs

Software
Downloads
Documentation
CVS Repositories
Roadmap
License

About Enhydra.org
Who We Are
News, Articles & Events
Getting Involved
Contact Us

Community
Demos
Contributions
Resources
Case Studies
On The Edge! -NEW-
Commercial Vendors

>> :) I guess we're just real lucky here at Lutris to have user interface
>> engineers who, through long years of dealing with HTML and JavaScript,
have
>> become adept at both the design and scripting aspects of their jobs.

Certainly there are exceptions to the norm. If you are one of those
exceptions, I applaud your ability/talent and wish there were more people
like you that could wear several hats in the development team. Unfortunately
the fact remains that there are more people who conform to the rule than
don't (that's why your so special - stand tall and proud).

I have seen the separation of Flash animator and Flash graphics developer in
several development teams with mixed success. If it works for you then
please by all means continue, but I have yet to be satisfied with the
results of the separation. The ability to create an attractive Flash UI is a
skill separate from graphic design or animation (that is to say that I know
people who are good graphics guys, but not so good animators, and visa
versa - finding a good graphics guy that can animate is a real catch). I
feel that a high level integration model that hides the complexities of the
code would greatly benefit the "non-Flash or actionScript unaware animator",
because it would allow them to continue to living in there skill bubble
without the need to learn anything new (as backward as that might seem - it
seems some people just don't want to learn new things). The benefits would
be similar to those of custom tags in JSP (which have been hugely successful
despite there relative immaturity). As for how this would reduce development
time, it may not. What it will do is provide a more definitive separation of
team roles, as well as open up a whole new level of interactivity within a
Flash interface. Currently most people construct Flash a linear interface
with very orderly "stages". For example, take a shopping cart check out
interaction:

Stages:
1) Fill out form - move to process or to empty field scene.
2) Process results - Add up all items and display in scene.
3) Send information to server - Send information to server move to waiting
for response scene.
4) Receive response from server - Display confirmation scene or denial
screen.

Currently all of the scenes and scene transition logic have to be hardcoded
into flash. If the business process is ever modified you have to go back and
reedit the Flash movie. If we had a higher level of standard communication
that could pass commands and receive responses with no fixed format, then we
would be free to develop Flash applications in a more object oriented sense.
What I mean is that we could design individual Flash movies that represented
individual "states". The movement between and the processing of information
within each individual "state" movie could be handled on the server. This is
similar to the session and entity bean model used in EJB's. Flash interfaces
would no longer have to be one big sequence of scenes all hard coded and
incapable of handling anomalous events/requests. The interfaces could be
designed and assembled in a similar fashion to the underlying logic, where
the state is determined by the interaction and not visa versa. This sort of
modular interface design would make flash interfaces much more easy to
extend when new features are added to applications. The whole Flash sequence
wouldn't have to be rewritten, you would simply have to add new "state"
movies capable of handling the new features interactions. The movement
amongst the new components would all reside in the app server and be
communicated to the state movies via the communications standard.

Just thinking out loud.

Jordan Duggan
Chief Creative Director
Indicium Design
Phone: 919.829.0650
Cell: 919.696.7936
Fax: 801.912.1503




-----Original Message-----
From: owner-Designers@enhydra.org [mailto:owner-Designers@enhydra.org]On
Behalf Of Russ Duckworth
Sent: Monday, March 05, 2001 5:39 PM
To: Designers@enhydra.org
Subject: Re: Designers: Hello


on 3/5/01 3:01 PM, Jordan Duggan at jordan@indicium.com wrote:

> Designers don't want to be (or can't be)
> programmers and programmers don't want to be (or can't be) designers.

:) I guess we're just real lucky here at Lutris to have user interface
engineers who, through long years of dealing with HTML and JavaScript, have
become adept at both the design and scripting aspects of their jobs.

In case of Airsent, we actually worked with a non-Flash designer who simply
delivered us a vector image file, with which we built the interface - rather
quickly I might add.

So, for now, enter the "presentation layer scripter." This person should
have the skills necessary to interact with and decide on the data transfer
rules with back-end developers.

While a high level standard integration model wouldn't directly benefit the
non-Flash or ActionScript unaware animator, I'm interested in hearing
examples of how this standardization would reduce development time for the
presentation layer, and back-end programmers.


--
Russ Duckworth
design.lutris.com
831.460.7379
831.239.4204

----------------------------------------------------------------------------
-
To unsubscribe from this mailing list, send email to majordomo@enhydra.org
with the text "unsubscribe designers" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at owner-designers@enhydra.org.

-----------------------------------------------------------------------------
To unsubscribe from this mailing list, send email to majordomo@enhydra.org
with the text "unsubscribe designers" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at owner-designers@enhydra.org.