Graphics Reference
In-Depth Information
questions. There are a couple of advantages to taking this approach
with your designs. First, the Flash developer can actually sit there
trying different animations from directly within the Flash authoring
environment. Once he or she finds the one that suits best, you can
both decide together if it
s the right animation for the project. The
other advantage to this is pride of ownership. Turning over this
control to the Flash developer will make the Flash developer feel
more inspired to do a better job on the project due to the fact that
he will feel more like the project is his instead of feeling like he
'
'
s
just another part of an assembly line.
Know the Strengths and Limitations
Because the design of each round of banners will differ, they will each
have different strengths and limitations when it comes time to ani-
mate or program, and you
ll need to be able to recognize them ahead
of time in the design process. For example, moving objects over a
large area at a very slow rate of speed can end up looking choppy if
it
'
ll talk about in
Chapter 5, is the format chosen for images used within a banner.
Sometimes moving an object across the stage will require it to have a
transparent area. This can be both a strength and a limitation at the
same time: a strength because of the ability to support the transparent
area of the image, but a limitation because of the extra amount of file
size that can be taken by that image (as opposed to an image without
transparency). Knowing the strengths and limitations of Flash is
something that comes with time. After some experimenting, some
trial and error, and needing to rework a few projects, more and more
of these strengths and limitations will become apparent.
Just as it
'
s not done correctly. Another example, which I
'
s important for designers to know the strengths and
limitations of the developers and their tools, it
'
salsoimportantfor
the developers to know the same about the designers and their
tools. With that being the case, I would like to make a suggestion
that the two disciplines meet on a regular basis to discuss those
things. You can call it whatever you like, but I call it a capabilities
meeting and I believe it
'
s good to hold them at least once a month
if not every 2 weeks. Developers can use this time to showcase
new features of Flash or new
'
ve learned since the last
meeting. Another thing that may take place in these meetings
might be for the designers to show other inspirational Flash sites
that contain certain elements the designer particularly likes or has
questions about. For example, a designer might show a site and
ask if the developers on the team have the skill set to do something
similar to feature X. Each time the designers and developers walk
out of these meetings, both disciplines have a better understanding
of the capabilities of each other
“
tricks
”
they
'
…
which is why I like to call them
capabilities meetings.
