It’s already been two weeks, and Jason is now ready to fly on his project design!

Jason has worked out a design with his mentors at Inquirium, so I am not going to focus on that. Besides, it’s good to make a few mistakes when you build your first real interactive; this is what will build programming character. I’ll step in when it’s time for feedback.

Additionally, since Jason is a video enthusiast, we will do a little discount usability testing as described in Steve Krug’s book, Don’t Make Me Think. There’s nothing quite so deflating as actual user confusion when faced with your design! I am sure it will be quite instructive for the both of us.

Anyway, let’s recap what we’ve done so far.

• Week 1: AS 1.0 and MovieClip Concepts, Implement some basic components from scratch, then hook them together.
• Week 2: AS 2.0 and OOP Concepts. Convert Week 1 to AS 2.0. Add some screen management.
• Week 3: Code Review. How to Quiz a Client. Pre-production methodologies. Build the skeleton app for this Friday.

In case this sounds incredibly aggressive, it’s boot camp! And Colin Moock would’ve been way tougher! Besides, Jason has actually taken a couple of C++ courses, so he is already familiar with the basic ideas behind procedural and object-oriented programming. Maybe not rock solid on it yet, but he will attain mastery through doing and my benevolent goading.

One decision I made was not to critique his interactive design before implementing it. I think he needs to code something at least twice, and we don’t have a lot of time to waste dilly-dallying on the design details. Plus, it is also a lot easier to make points by using his own implementation than a piece of paper that is easily rationalized away (“Oh, that is part of the design. I just forgot to write it down.”)

So instead of doing a critique, I pretended Jason was my client. We sat down in our comfy chairs, and I proceeded to read through and make notes. I thought aloud for his benefit, expressed confusion when appropriate and genuine, and ran him through my client “what are we doing” interview procedure. I base it around three key words: Intention, Expectation, and Motivation. I’ll have to write up that article sometime, but the basic idea is that many clients ask for a thing but don’t tell you why they’re making that specific thing, right now and what they expect will happen as a result of making that thing. I thought that this might be interesting for Jason to experience by example; next time, he’ll do it himself.

Next step: the production breakdown. For me this means figuring out the general architecture / technical strategy, and generating at minimum a screen list / functional diagram / storyboard / wireframe (so many names for the same thing) and an asset list complete with asset numbers assigned. I had Jason create his own rather than doing it for him; he found it very clarifying.

Jason has enough information to get going, so I’m setting him free. Some of his immediate challenges are to structure an object-oriented application architecture for the more complex design he has, but the past two weeks have given him most of the code for what he needs to do. We may have to discuss more advanced data structures at some point, and also missing is the strategy for implementing a visual simulation in Flash. We did talk a bit about Model-View-Controller patterns, but not the specifics of frame-rate independent, parametric time-based simulation. I told him to take a first pass at it and see what happens; I have the feeling that he will get more out of it if he comes across the difficulties first-hand rather than me just telling him what to do. We’ll see how that goes. So far, he’s doing pretty well.