Prototyping

[ LiB ]

After you define the objectives for a project and specify the features, it's best to first create a prototype before you build the real thing. A prototype will really clarify exactly what your application will be like. It helps team members reach a consensus and exposes flaws in your idea, which, up to that point, has been nothing but an idea in your head. A prototype appears in the final form of your application (say, a Flash movie). People can touch it and really feel how things flow. After you build a prototype, you can quickly identify issues that must be resolved.

Hopefully, you agree that prototypes have a real value. In any event, the following section covers specific techniques worth using when building prototypes .

Being Sloppy

If ever there were a place where being sloppy is okay, it is while prototyping. The goal of prototyping is to get something up and running quickly. Therefore, a prototype doesn't have to look pretty. Not only are blocky "holder" graphics perfectly suitable, they're quicker to produce. In addition, the risk of presenting a halfway decent-looking prototype to a graphic designer is that the designer may mistake your visual elements for having some purpose. Ideally, the graphics won't be influenced by anything visual in your prototype. It's not like you have to be intentionally messy, but realize that prototyping goals include getting a feel for your application, identifying all the interactions necessary, and getting sign-off from all interested parties.

I could list quite a few general tips for prototyping, but most are either common sense or specific to the way I work. One universal suggestion I can make is to always think modularly. That is, even though you may not need a lot of the code you're developing, you may need some of it. If it's all wrapped up into a few huge functions, it'll be harder to extract. If you break things apart (as you're building), however, it will be easier to grab select routines. It's like I'm saying "follow good code practices while you're being messy." Obviously, that's a contradiction. I'm just saying time saving sometimes has a higher value than pretty code.

Using Components

I used to advise using user interface components only while prototyping. However, they're so darn useful I'll admit using at least the Buttons and List components in real projects. In any event, they're still quite useful for prototyping. I guess my main point here is that it's worth the investment to learn how to populate components and to tie them in so that they trigger your code.

In the case of Flash MX 2004, there's a new set of version 2 components that require a slightly different procedure. Chapter 12, "Using Components," provides more details on these. For now, just realize that they can save a lot of time while prototyping, too.

[ LiB ]