copyrighted material

copyrighted material

31136c01.qxd 5/22/07 8:26 PM Page 1


Project Archaeology

Starting a new Flash video project, especially with a new client, is much like arriving on an archaeological site. There’s important information under the surface that you need to uncover. What is the overall focus of the application? What are the audience bandwidth targets and file size restraints?

What type of video navigation and interaction is needed? As the developer, it’s your job to drill down to the main objectives and functionality of a project, and create a realistic map to get there.

This chapter will walk you through the steps of mapping out a successful Flash video project.


Chapter Contents

Scout the Site: Define Client Needs

Piece Together the Artifacts: Determine the

Appropriate Solution


31136c01.qxd 5/22/07 8:26 PM Page 2


Scout the Site: Define Client Needs

As any good archaeologist would tell you, you don’t start digging without first scouting the site. Before you get started on any project, especially one involving video, you have to clearly define its scope. All too often we developers jump eagerly into the technical aspects of a project, delivering exactly what the client asked for, only to end up with a disappointed client. It can be frustrating to deliver exactly what they said they wanted, only to have them tell you it doesn’t achieve their goals. “I want DVD quality!” is a common request, but when a video of that quality is not properly deployed on the

Web, disaster ensues. The video stutters and stops as it squeezes through on its limited bandwidth. The client isn’t happy, the viewer isn’t happy, and neither are you.

As an expert (if you aren’t one now, this book will help you get there), you play a critical role in helping to define these realistic project specifications with your client.

You need to truly see this as a partnership. Doing so always works to your advantage and will set you apart from the less-involved developer. This approach will lead to a better overall relationship with your client, and you will gain their trust as the expert.

They may not be able to articulate it, but you need to trust that your clients

know what they need. It is important that you spend time listening and asking the right questions to develop a full understanding of their goals. Excavating the real job scope from this exchange is your challenge.


Listen more than you talk.You can’t hear what your client is communicating to you if you’re too busy telling them what you know!

Read Between the Lines (or, Is the Customer Really Always Right?)

“I want the video to play automatically when someone comes to the site—and it needs to play


Wow, this guy really wants attention. He wants every visitor to see that video, in their face, in high quality. But as anyone involved in the execution of Flash video on the Web knows, many of those visitors won’t see that video in high quality at full-screen size—it’ll be a jerky, jittery slideshow—if they don’t get so annoyed at the full-screen pop-up that they leave the site altogether, that is.

So, reading between the lines here, what does this client really want?

He wants to entice the visitor to watch the video, and he wants them to see the best quality possible.

There are many ways to prompt the visitor to view video content. Playing an animation or a very

31136c01.qxd 5/22/07 8:26 PM Page 3 short clip of the video to draw attention on the page is one option. Except in special applications, it’s almost always best to let visitors choose to play a video and not make that choice for them.

The Flash Player does now have a full-screen video option built in, but keeping in mind bandwidth issues, as well as user preference, it’s best to let users specifically choose that option too. Either let them choose low- or high-bandwidth options or, if you are streaming, dynamically serve the optimized video for their connection automatically.

Explain your proposed solution to your client in a way that is positive and makes them feel that you respect them and their ideas, and your slap of reality will sting a bit less. Even though these are mostly usability considerations, they almost always have a technical counterpart, as in extra work. Clients are usually hesitant to spend extra money in usability, but presenting it as an investment in their corporate image is known to yield results.

Getting the Lay of the Land: The Site Survey

So, how do you partner with your client in this “dig?” You begin by asking lots of questions. Their answers will help you define the overall goal and offer solutions.

What are the key components and features? Will there be user-generated content? Who is the audience? What are their limitations? Browser? Platform? Connection speed? What version of Flash will be required?

One of the best ways to extract that information from your client is to prepare a survey document with pertinent questions for the client to fill out prior to the initial meeting. It is meant to provide an overview, covering questions in such categories as general information, project information, content, marketing goals, and technical considerations. We have found this to be a great way to get started because it allows the client to complete it at their convenience and get input from others who may not be available for a phone call or meeting. Also, the sheer act of putting thoughts in writing will offer clarity. In short, it efficiently gets your project under way.

Flash Video Survey Sample Questions

Here are some of the questions we’ve found helpful to include in the survey for a new Flash video project:

What are your primary objectives? Secondary?

Who will be the primary contact person for this project? Who makes the final decisions?

When is the expected launch date of the project?



31136c01.qxd 5/22/07 8:26 PM Page 4


Flash Video Survey Sample Questions (Continued)

Do you have a specific budget range? Can the project be divided into phases to accommodate budget and timing constraints?

Describe the user interface look and feel of the application/website. Are designs/screen layouts being provided?

Will this site use existing content from the current site? If not, who will be providing the content, and when?

How do most people find out about your website or application?

How many people (as far as you can tell) access your site on a daily, weekly, or monthly basis?

How do you measure usage?

Will the content need to be dynamic (changing often or automatically)? Will a content management system be required to allow you to update the content?

Will you be providing source video? If so, what are the specs (dimensions, frame rate, file format)? Can you provide a sample file now?

If utilizing long-form video, will “seek” functionality be required? In other words, do you want a “scrubber” bar that viewers can use to scan through the video?

If predetermined, in what format(s) will the project be executed (i.e., Flash, a Flash-HTML hybrid, or other technology)?

What deliverables will be required?

Do you have a target file size for the final application?

Will the project be deployed on a new server or on an existing server? What level of access will be provided (i.e., FTP, SFTP, Root access)? Who will be the IT point of contact?

We’ve provided a complete sample survey for you to download at http://www.flashconnections



Excavation: The Interview

In archaeology, the excavation process involves the exposure, processing, and recording of data. In our scenario, you “excavate” the information you need by conducting an interview with your client. The interview is an opportunity for you to understand what the client’s real needs are. You are an active participant here, and need to take charge of the process. You’ll be taking the valuable survey information and digging deeper for more meaningful answers.

31136c01.qxd 5/22/07 8:26 PM Page 5

You’ll want to walk through the completed survey with your client, in person if at all possible. This will allow you to ask questions and clarify details. This is your chance to ask things like:

Will your visitors want to view the site on mobile devices?

What are the most important features?

What are your plans for the future? Does this application need to be scalable?

How solid is the deadline date? Is there a tradeshow or other event that you need to accommodate?

What happens when a deadline isn’t met? How will delays on the client’s side affect the expected delivery date and final price?

Any other questions that your client may not have considered.


Break down “geek speak” into plain English. Keep the tone informative, never condescending.

Having a strong understanding of your client’s goals will also help you maximize the project’s value. Giving them verbatim what they say they need may lead to a proposal so cumbersome that you’ll never get the job, or never get the job done. Understanding their needs and defining your own solution will likely result in a much leaner project. We’ll talk about the importance of providing multiple pricing options later in this chapter.

Piece Together the Artifacts: Determine the Appropriate Solution

Now you have nailed down what this application needs to do. The next step is to figure out how to get it done. Video projects are complex and demanding in nature, and mistakes are expensive. We have listed some common example projects that can help point you in the right direction. They reference chapters in this book that would be useful in these common scenarios.

Video Playlist with Variable Bandwidth Options

Design a smooth user experience (Chapter 3: “Creating a Video Delivery


Detect user bandwidth and display appropriate clip (Chapter 6: “Getting It

Out There: Test, Optimize and Deploy”)

Determine the source of clip names (Chapter 7: “Dynamic Playlists”)

Player with Chapter Links

Add bookmarks using Cue Points (Chapter 8: “Demystifying Metadata and

Cue Points”)


31136c01.qxd 5/22/07 8:26 PM Page 6


Live Webcam Conference with Text and Sound

Use Flash Media Server (Chapter 11: “Live Video and Webcams”)

Choose deployment solution (Chapter 3: “Creating a Video Delivery Roadmap”)


The costs for hosting video content can vary significantly and often are not considered by the client ahead of time. Many delivery options are available, ranging from hosting your own streaming Flash Media

Server 2 to using a content delivery network; we’ll cover those topics in detail in Chapter 3.You will want to make your client aware of the options and pricing structures from the beginning of the project.

Anticipate the Pitfalls

Managing Flash video projects is often like navigating an obstacle course. This section will give you an overview of the major obstacles so you can avoid them, or at least plan ahead.

When dealing with video in Flash specifically, you’ll consistently run into certain problems. We’ve outlined some (including some of our own hard lessons) in the “What

You Don’t Know Can Hurt You” sidebar, and also included a few general projectrelated problems that we found cropping up often. You’ll find the survey document very helpful in ferreting out these potential issues early on.

Overall, the best approach is to keep the project as simple as possible. It is difficult to make something cutting edge that is 100 percent fail-proof. When you start adding various connection options, compatibility requirements, and all the bells and whistles, the potential problems will grow exponentially. Even the simplest of applications can have some serious complexity behind the scenes. This is why this first “project archeology” step is so crucial.

Many of the pitfall examples may seem like common sense, but it’s easy to gloss over them when planning and pricing a project. You want to be as thorough as possible in these preliminary stages so that you encounter fewer surprises along the way. Having an experienced associate play “devil’s advocate” and point out potential flaws in your project plan is always a good idea. “What happens if the video file specified in the XML does not exist?” “What happens if the visitor loses their Internet connection while broadcasting?” “What if the video goes viral and traffic spikes?” We’ve seen this happen, and it’s not fun. Developers should plan for “unplanned” traffic increments; this means making sure the hardware will not break down with the overhead, and that there’s enough bandwidth allowance in the case of shared hosting. It’s difficult to anticipate every possible scenario, but with experience and the information in this book you will be able to spot potential pitfalls early and avoid them.

31136c01.qxd 5/22/07 8:26 PM Page 7

What You Don’t Know Can Hurt You

We’ve learned the hard way, so you don’t have to! Here are our top eight gaffes (that we’re willing to admit to); some were more expensive than others:


Trying to make do with existing subpar hardware; we lost sleep and missed deadlines in the process.


Implementing ActionScript 3 (AS3) in the middle of a project; learning a new language as you go is never a good idea.


Caving in to client demands to deliver their website before testing was complete.The site still didn’t launch on time.


Not having a written contract. Enough said.


Realizing we needed a DV camera without including it in the budget. Doh!


Traveling offsite with no remote access to files. Figures—our biggest client called us for changes on an old project shortly after our plane landed.


Expecting that the client knew how to encode good-quality Flash video files (FLVs) because they said they did.


Not having a plan B. A colleague of ours had a photoshoot where the client washed and prepped a fleet of limousines — and his camera broke on-site.Thankfully, there was an electronic store nearby that had his exact camera in-stock (whew).Without a replacement camera, his specialty 360-degree lens would have been useless. Rescheduling the shoot would have been a nightmare as the limos get booked for events.

Some other common pitfalls to avoid:

Getting incompatible assets from the client after the application is already built.

Not planning for NTSC/PAL conversion issues (e.g., audio and video out of sync, video flicker, etc.).

Video encoded using square versus nonsquare pixels (there are reasons for both; we’ll cover that in Chapter 2).

Failure to use a high-quality microphone to record audio.

No limit or goal set for final file size.

Not getting crucial content from client prior to starting the project (most clients don’t understand that DVDs do not make the best source video).The earlier you get involved, the better.

If you can monitor the shoot, please do. Often producers are not knowledgeable about the video formats required for Flash video.We will arm you with the information you need to know in Chapter 2.



31136c01.qxd 5/22/07 8:26 PM Page 8


What You Don’t Know Can Hurt You (Continued)

Not accommodating low-bandwidth situations.

Not planning for interrupted connections in streaming applications.

Not anticipating traffic spikes (load balancing).

Not getting input from the real decision makers early in the process.

Not leaving enough time for torture testing.

Poor communication with IT staff responsible for final project deployment.

Attempting to incorporate new technology on a tight deadline.

Not planning for future uses (scalability of application).

Trying to get by using inefficient software or hardware (not using the right tools for the job).

This last one’s pretty important. Never try to dig with a teaspoon when the job calls for a shovel!

Construct the Project Map: The Proposal

Using the data you’ve unearthed from the survey and interview (while steering clear of the pitfalls), you are now ready to construct a map of the project—in other words, a formal proposal. This document will define the actual project scope. Its purpose is to have the project specifications clearly defined in writing for both client and developer.

It also provides a benchmark to ensure that the project is on time and on budget, and is built to specification. If the client decides in the middle of the project that they want to add on-the-fly alpha channel video, you can whip out the proposal document and remind them that, though you’d be thrilled to add it, it’s not in the spec so you’ll issue a change order. (Yes, those need to be in writing, too!) When it appears you’re off course, you can always use the map as a reference to get back on track.

The most useful maps are detailed. Be as specific as possible, and include:

Overall objective, stated in one sentence


File formats


Who will be providing assets, when, and in what format

Functionality of application/navigation

Browser and bandwidth targets

Additional programming languages required

See Figure 1.1 for a real world example of a typical Proposal. This file is also available for download at


31136c01.qxd 5/22/07 8:26 PM Page 9


Figure 1.1 Sample proposal

31136c01.qxd 5/22/07 8:26 PM Page 10


Figure 1.1 Sample proposal (contiued)

31136c01.qxd 5/22/07 8:26 PM Page 11

The proposal ultimately serves the important function of “managing your client.”

Managing your client really means managing their expectations. A good proposal is the clearest way to set these expectations. It plays a critical role in your client interaction, partnership, and therefore project success. We can’t stress enough how important this step is. If you don’t have a map of where you are going, chances are you will never get there!


The devil is in the details. Play out all the nightmare scenarios you can think of from the beginning so you aren’t living them later.

Price It Right

Developers and creative professionals use several time-based ways to determine their rates, including hourly fees, day rates, and project fees. Often it’s not up to you. It is common for clients to have a system in place that you will have to follow, such as

“project not to exceed” clauses, a predetermined purchase order amount, or an approved hourly rate. It’s just important that you set a project scope that is reasonable within any time or budget limits.

The more experience you have in pricing, the more accurate you will be in estimating realistic labor hours. The most common problems with calculating pricing involve misjudged rates or projected hours, and not the formulas themselves. To help estimate project fees, or if you are new to pricing, it’s a good idea to keep a project time log. This is something you can refer to for future projects to achieve more accurate estimates.


Notice if a potential client is in need of “hand-holding.” Expect them to be more hands-on, thus requiring more in-person meetings and phone calls.This is not necessarily a reason to run away—just build extra hours into your estimate for management time.

Here are some common formulas for determining fees:

Hourly Fee (Monthly Overhead Costs / 160) + Hourly Labor Costs + Profit Margin

Take your total monthly overhead costs and divide by the number of working hours in a month (based on five 8-hour days per week). Then add your real hourly labor cost and a profit margin (usually 15–30% of the total).

Day Rate (Standard Hourly Rate

× 8) × 90%

This approach applies a 10% volume discount to the standard hourly rate.


31136c01.qxd 5/22/07 8:26 PM Page 12


Project Fee (Standard Hourly Rate


Number of Hours Estimated)

× 2

This multiplier covers the estimated costs of management time, overhead, etc.

Although most clients have a budget in mind in advance, these guesstimates are often made to the best of their ability without having a benchmark for such a project.

It’s common to state how much a project should cost without having any experience in the industry to know a realistic amount. In our experience, the budget they have in mind is not definitive and they usually have some flexibility depending on the priority the project has in their overall budget for the year.

Once the fee is determined, you will want to update your client about hours spent, either weekly or when you reach a milestone. Even if it is not required of you, it’s a good practice to have a procedure to keep them informed along the way in order to avoid a shocking invoice at the end.

Working for Equity: A Word on Startups

With all your fresh, in-demand Flash video skills, you may find yourself being approached by entrepreneurs who would like you to help them bring their startup ventures to life—in exchange for a share in the company’s profits.

There are a few things you should consider carefully. First, working for equity is risky, paying off only when (and if) the company is actually profitable.Then there’s the expense of having a lawyer draft or review the formal equity agreement. Add to that the significant time investment (and as we know, time is money). Remember that often your services are among the venture’s most critical needs. Consider this fact when negotiating an agreement. Evaluate the opportunity carefully; the chances of buying in to the next YouTube or Revver are quite slim (though we have to admit, it’s tempting!).

Offer Alternate Routes

When estimating complex projects, we almost always break the proposal down into “a la carte” options. Beginning with the core functionality of the application, we then add either project phases or feature add-ons that the client has requested. These are listed as separate menu items with their own price estimates. Often, we add features here that we think would improve the application (or would just be “cool”). This allows us to get creative and introduce ideas to the client that they can assign value to.

Breaking down the project this way also gives the client perspective of the work involved in each phase, and gives them the freedom to choose options rather than a

“take it or leave it” bottom-line number. However, be careful not to create so many

31136c01.qxd 5/22/07 8:26 PM Page 13 options or phases that clients are overwhelmed, or worse, confused. Keep in mind that you are the expert here, and the client is looking to you to best group these options together to streamline the project.

Even if your numbers are perfectly reasonable, allowing the client to see these options itemized will tell them what they are paying for and give them confidence in their investment.


Note that a proposal is different from a contract because it does not contain all the legal verbiage of an agreement. Although we do not cover contracts in this book, we strongly recommend having one drafted by a lawyer, based on the proposal, for both parties to sign.The contract, unlike the proposal, addresses legal issues such as copyright, payment, and liability.This is especially important when creating Flash video applications, as they tend to be complex and large in scale.


In this chapter you’ve learned how to:

• Develop a partnership with your client.

Grasp an understanding of the project at large and clearly define your role.

Conduct the survey and interview.

Create a detailed written proposal.

So you’ve surveyed, excavated, and created a detailed map. You’ve got everything you need to prepare for a successful Flash video project. It’s time to gather your assets and start digging!


31136c01.qxd 5/22/07 8:26 PM Page 14

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF