Upfront planning and design considerations can be intimidating to some. It is very difficult to design visuals when you don’t have content, and tough to set the mood for a story that might not exist yet.

The process of planning ahead for design and functionality changes down the road can be intimidating. First you’ll have to come to the realization that there is no way to predict the future. Who could have guessed that by 2010, all computer monitors would be set to 10,000 x 6,000 resolution, and that project you created in 2004 at 640 x 480 is now the size of a postage stamp? Some things just can’t be predicted. Your best bet would be to look one or two years ahead and take a guess, especially with projects you know will be used year after year.

Issues that arise from changes in storyboards, content or anything affecting your project can be infinite. What if in the middle of your 6 month long project you came to realize you needed audio controls, such as play, stop and volume. What would save you time and get the addition completed would be a sloppy hack job. This might take you less than a day to get up and running. You’d be doing this however, with the knowledge that any future projects based on this backend system you’re building will crumble the second any programmer but yourself touches the source files.

An alternative approach is to work within structured guidelines using reasonable timeline goals. This audio fix might now take 2 weeks to do it right as opposed to half a day. What a bummer! The truth is, when you do something wrong or sloppy, the problems you create may take a whole month to fix later on, as other aspects of the code become dependant on your sloppy code. It’s the house of cards effect, where you pull out one part of the structure that all other parts rely on, and the whole thing may come crashing down.

Seeing there’s no right way to plan far in advance, what you have to do is create some sort of constant update timeline. Checkpoints in development where you really focus on debugging code, making everything work together flawlessly, so that in the end you don’t have a hulking mess of jumbled up templates, actionscript files and graphics.

It always happens at the worst possible moment, doesn’t it? You’re booked solid, working 10 hour days, borderline zombie, and the program you use the most starts acting funny for no reason, and apparently no one else in the world has ever shared the same problems (or so Google tells me).

I’ve recently come across a host of Flash audio problems and feel I’ve come up with some fairly straight forward solutions. One side note just FYI is that all audio used was professionally recorded, so none of the issues from what I can tell were caused by the quality of the initial recording.

Problem #1: My audio file sounds slow and drawn out, like a dying record

While adding in .wav audio into a project, it took me a while to realize it, but the VO (Voice Over) actors all sounded a lot deeper voiced that I’d assumed was natural. A few hours into the project I needed to edit a clip of audio and opened it into my favorite editing tool, Adobe Audition (earlier known as Cool Edit Pro before being bought out). Lo and behold the VO actor’s voice sounded clear and natural, the way it should. So what was Flash doing to my file?

Solution #1: Batch process or save your files at a different sampling rate

Now this may be a no brainer for all you audio editing geniuses out there, but for a Flash developer like me who only dabbles in the complexities of professional audio recording, it took a while and some digging to figure this out.
To correct this problem, re-sample your files down to 44100 HZ or a lower quality 22050 HZ. Flash likes these two sampling rates the best which is the important part. You can do 44100 HZ, 16 bit Mono, or 44100 HZ, 32 bit Stereo, it’s the sample rate that matters and will fix the problem.

Problem #2: My audio file appears to randomly skip the first .75 to 1 second of audio in my file

(Oh there is more…)

I had an interesting discussion with a client yesterday about project direction and process, and there was some open debate on how to develop an interaction to not only meet a tight budget, but fulfill some broad goals. Is there a best method, or does every project deserve to flex and adjust into multiple styles of interaction and teaching methods? Also discussed were the pros and cons of linear vs. nonlinear activities, and we went over the possibilities of having a little of both mixed in.

Getting to the point, I’ve written up a fairly detailed overview on Living Children’s initial project process. It covers our first four steps when brainstorming a new project, and covers each topic up to actual production (a page on production process will come another day).

The overall process includes:

• 1. Defining The Goal(s)
• 2. Rough Project Outline
• 3. Refining Goals and Listing Objectives
• 4. Creation of Flow Diagrams

Click here for the full page on project process, including samples of each step. This page will become a permanent addition under “About” in due time.

The most exciting prospect of eLearning is the ability to produce nearly any dangerous, or complex situation and provide access to anyone who has the skill to click a mouse. There really was nothing like the time I had a fashion major friend of my wife user test the Virtual Knee Surgery simulation before launch.

Here was a person, who pretty much knew how to check email, and after 10 minutes of slicing and dicing, felt completely capable of performing major surgery in her own home. To hear her response and excitement over having just done surgery was inspiring, as I’d given someone who would have never in their life cut someone open, the ability to take on the roll of a med student with $400,000 in school loans, all in a 10 minute simulation.

(Oh there is more…)