flash project process slides

8/14/2019 Flash Project Process Slides

1/41

FLASH PROJECT PROCESSDesigners and Developers

Prepared by Kris Schultz and Jeff FischerMay 23, 2007

Insert .jpg ofclient logo here


2/41

PURPOSE

Lear to manage to medium bymaking Flash project success

reproducible across all teams andacross all projects.


3/41

SUCCESSFUL FLASHPROJECTS

: Make us proud

: Make our clients happy

: Are reasonably predictable: Adhere to budget goals

: Adhere to time goals

: Are not overly stressful

: Avoid crisis


4/41

COMMON PROBLEMS

: Unexpected after hours work near end of project

: Over budget

: Missed deadlines: Doing code rewrites

: Long ramp-up time when adding new people toproject

: Producing work with serious flaws

: Creating sites that are time consuming andexpensive to maintain


5/41

CAUSES

: Improper team composition

: Lack of clearly defined roles and responsibilities

: Inadequate level of effort estimation: Inadequate timeline / milestone planning

: Ad hoc workflow between designers and developers

: Little standardization in how functionality is built


6/41

2007 PRIORITIES:MANAGE TO MEDIUM

: Stages of organizational growth for mediumcompanies:

:Jobs become more specialized

: Leadership become more removed from the day-to-day

: Work environment becomes more standardized

: Procedures are documented

: Leaders emerge and are trained

: Client satisfaction measures are needed

: Com etitive focus for marketin and business


7/41

KEYS TO SUCCESS

:Team composition

: Roles & responsibilities

: Workflow: Standardization


8/41

TEAMCOMPOSITION(MANDAR WEARS PARACHUTEPANTS)


9/41

TEAM COMPOSITION

: Every Flash project must have:

: A Flash designer

: A Flash developer


10/41

IF NO DEVELOPER IS INCLUDED

CONSEQUENCE

Impact of creative

decisions is notevaluated

overtime

over budgetmissed deadlines

Brute force is usedto

achieve functionality

confusing codebrittle code

extra effort

Logic flaws in codego unnoticed

site failuresliability problemsclient confidence


11/41

ADDITIONAL BENEFITS

: Developers know the right questions to ask

: Developers know OO architecture theory andtechniques

: Reduces construction time

: Code is more robust/less brittle

: Project is easier to test

: Can code for change


12/41

OO THEORY JARGON

: Loose coupling

: High cohesion

: Favor composition overinheritance

: Design patterns (Observer,Singleton, Composite, Strategy,

Factory Method)


13/41

ROLES &RESPONSIBILITIES(DENNIS WISHES HE COULDLIVE OFF THE GRID)


14/41

THE RULE

Designers dont write code.

Developers dont design.


15/41

DESIGNER RESPONSIBILITIES

: Ideation / static design comps

: Motion / interaction design prototypes (includingcode)

: Flash graphic production

: Slicing PSDs

: Initial Flash file layout

: Basic MovieClip construction

: Creating button states

: Code writing tasks assigned by a developer


16/41

DEVELOPER RESPONSIBILITIES

: All planning activities

: Component / module identification

: Development estimate: Development plan

: Requirements documentation

: All coding activities

:Technical design

: Code writing for components, modules, and

integration


17/41

PROJECTWORKFLOW(MATT IS THE BEST JAZZBAGPIPE PLAYER IN FRANKLIN

COUNTY)


18/41

ESSENTIAL PROJECTWORKFLOW


19/41

RASCI MODELOF ROLES

: Responsible

: Accountable to

: Supporting: Consult

: Informed


20/41

WORKFLOW RASCIASSIGNMENTS

DESIGNER DEVELOPER

IDEATION R I

STATIC COMPS R I

MOTION / INTERACTION PROTOTYPES R C

GRAPHIC PRODUCTION R C

SKINNING / TWEAKS R C


21/41

WORKFLOW RASCIASSIGNMENTS

DEVELOPER DESIGNER

FUNCTIONAL REQUIREMENTS R C

DEV ESTIMATE R --

DEV PLAN R --

TECHNICAL DESIGN R --

COMPONENT / MODULE DEVELOPMENT R C, S (optional)

INTEGRATION R --

TESTING R --

FIXES R S


22/41

CREATIVE COMP

: [description]


23/41

FUNCTIONAL REQUIREMENTS

: A textual description of theexpected functionality from endusers perspective

: Acceptable formats...

: Software RequirementsSpecification (SRS)document

: Annotated graphic comps

: Wireframes


24/41

DEVELOPMENT ESTIMATE

: Should include breakdown of alldevelopment related tasks

:Task granularity should be no

larger than 40 hours

: All estimates should use theRIA Estimate template


25/41

DEVELOPMENT TIMELINE

: Should account for all tasksidentified in the estimate

: Should identify and

accommodate dependenciesbetween tasks

: Should identify key handoffpoints between designer and

developer


26/41

MOTION / INTERACTIONPROTOTYPE

: Gives developers a guide to themotion and interactivityexpected

: Forces you to think through allinteraction steps

: Have comp as close to final aspossible


27/41

COMPONENT / MODULEDEVELOPMENT

: [description]

: [show Rbk Music footwearcomponent & mod]


28/41

SKINNING / TWEAKS

: [example footware module]

: [Kris todo: create fakeunskinned module]


29/41

STANDARDIZATION(TROY OWNS MONGRAMMEDBOWLING SHOES)


30/41

2007 PRIORITIES:MANAGE TO MEDIUM

: Stages of organizational growth for mediumcompanies:

:Jobs become more specialized

: Leadership become more removed from the day-to-day

: Work environment becomes more standardized

: Procedures are documented

: Leaders emerge and are trained

: Client satisfaction measures are needed

: Com etitive focus for marketin and business


31/41

BENEFITS OFSTANDARDIZATION

: Enables collaboration by making team membersmore interchangeable

: Reduces communication time

: Helps avoid misunderstandings

: Promotes best practices for common projectrequirements

: Reduces ramp-up time for new team members


32/41

GOALS OF OURRIA STANDARDS

: Promote consistent, reusable solutions to commonfunctional and design requirements

: Maximize the understandability of code

: Accommodate the things that are likely to changeduring a projects life cycle

: Align with the code standards of our other

technology disciplines


33/41

NON-CODERS

: Flash Designer Patterns and Practices

: Catalog of Resource endorsed recipes foraddressing common design tasks

: Example topics...

: Button construction

: Progressbar construction (aka preloaders)

: Placeholder clip construction


34/41

CODERS

: Flash Developer Patterns and Practices

: Catalog of Resource endorsed recipes forimplementing common functional requirements

: Example topics...

: Load management of external assets

: Communication between SWFs

: Open / close animations


35/41

CODERS (CONTINUED)

: Resource ActionScript Code Library and ResourceComponent Library

: AS class files and Flash UI components created

for reuse

: API - [enter location]

: AS classes - [enter location]

: Component FLAs - [enter location]


36/41

CODERS (CONTINUED)

: ActionScript Code Standards

: Provides code style, code construction, and FLAfile construction guidelines

: Required for production code; Optional for motion/ interaction prototypes

: Four Essential Flash Testing Practices

: Details four tests that must be applied to allFlash projects.


37/41

THINGS TOREMEMBER(MIKE PRACTICES BILL GATESIMPRESSIONS IN FRONT OF A

MIRROR)


38/41

REMEMBER...

: Every Flash project requires a Flash designer andFlash developer

: Designers dont write code. Developers dont

design.

: All steps of the Flash project workflow are requiredfor any Flash project

: Developers need to review all creative before itsshown to the client.

: Designers need to review all functionality before itgets tested.


39/41

Q & A


40/41

Q & A

:Team composition

: Roles & responsibilities

: Workflow: Standardization


41/41

THANKYOU

flash project process slides

Documents