PLANNING YOUR PROJECT

One of the most important things you need to do before, during, and after a project is to be organized. Being organized might seem time consuming, but in the overall picture, it helps you keep focused on what you need to do and keeps you on track. Organization is a good skill to have, and it will help you in other situations.

At this point, you should have an idea of the types of devices you're considering, cost and time estimates for completion, and how you plan to utilize the capabilities of Flash for your project.

Five Things to Ask First

Here is a quick checklist of questions that you should ask in the initial meetings with a client:

• What's the purpose?

• Are there any specific requirements?

• Who will be the end users?

• What's the scope?

• What's your budget?

Remember: This checklist can be used in all types of projects, not just Pocket PC Flash projects.

Understanding Your Limitations

Every project will have its own unique set of limitations only in an ideal world will we have all the time, resources, functionality, and flexibility to create projects just the way we want them. Here are some limitations I've found that might affect your Flash project:

• Available time for development

• Available resources (which means "cheap is good")

• Ambiguity from the client

• Ignorance about the software

• Hardware (platform?) limitations

• Limited training available

• Lack of IT support

• Internal politics and personality clashes

• Other concurrent projects you might have

In the event guide example that we're following in this chapter, we need to consider many major limitations: the event guide content, the Pocket PC Flash Player, and the Pocket PC devices. For example, consider these issues:

• Amount of content. Event guides usually include a lot of information. How do you choose what you need for your Pocket PC application? What's fluff and what's important? You will most likely determine the specifics with your client, but the sifting will have to be done.

• Information that is hard to reproduce. Event guides often have large maps that show you city information and where to find booths you're interested in visiting (see Figure 5.2). A large map or a complex table can be hard to display well on the Pocket PC.

  Figure 5.2. Map of the city of Santa Monica, California.

  

• Flash Player for the Pocket PC. You've already read in Chapter 2, "Creating Content for the Pocket PC Using Flash," about the Flash Player for the Pocket PC, and you should be aware of the limitations of displaying Flash content on Pocket PCs. Please refer to that chapter for more detailed information.

• Screen size. Pocket PC devices have a relatively small screen size that you must take into account when planning your design.

• Color depth. Keep in mind color depth limitation when planning your design for display on Pocket PCs.

• Available RAM. Another limitation you need to plan for might be the storage space or built-in RAM. Currently, devices have anywhere from 32 64MB, with the latter being plenty for most projects.

When creating your project, you should keep in mind that in most cases, devices have limited storage space or bandwidth; therefore, file size should be a consideration.

Planning the Workflow

Most people are visual learners; they remember things more easily if they're able to see a picture or diagram of a concept as opposed to just reading about it. This is where a project workflow comes into play. It doesn't have to be complex or confusing, but something simple to which you and the client can refer throughout the project. Here is an example of a project workflow for a medium-sized Pocket PC Flash project:

1. Initial meeting with client in which you get your questions answered. [Time estimate: 2 hours]

2. Spec, research, and prepare proposal, with prototype if needed. [Time estimate: 8 16 hours]

3. Confirmation meeting with client presentation of project plan. [Time estimate: 1 2 hours.] This could be done online to save time.

4. Begin development. Determine the number of developers, make task assignments, and set deadlines, with checkpoints midway through. [Time estimate: 1 4 weeks (depends on complexity)]

5. Walkthrough meeting with client, which can be scheduled once or several times during development. [Time estimate: 2 4 hours]

6. Testing and modification cycle. [Time estimate: 2 8 hours (depends on number of modifications)]

7. Rollout/deployment. [Time estimate: 2 8 hours]

Defining Your Project

This might be the most critical part of your project, so it's important to spend the time to get it right the first time. At this point, you should have already met with the client, asked your questions, and have a good understanding of the purpose of the project, the requirements, the scope, and so forth. Now you need to define what the project will be, what needs to be accomplished, and how your project might be used beyond its intended scope.

Here are a few things to consider as you begin to define the goals and expectations of your project:

• Remember the purpose of the project.

• Research and determine the best solutions.

• Have a device on which to test your project.

• Create realistic goals and deadlines.

• Manage your hours to stay within budget.

• Be prepared for things to go wrong.

Thinking and planning beyond the scope of your project toward how it can grow is a great selling point to a client for follow-up work. Not only will the client get enhanced capabilities, but the development time and costs will also be minimized because you're adding to an existing project. When defining your project, it's best not to think of it as only one project, but instead as the start of several projects. A great way I've found to accomplish this is to present your project in "phases" to the client. Each phase of the project can be built on the other, developed and deployed at different times. This "phased" approach might not be applicable to all projects, but always try to develop projects this way.

Introducing the Event Guide

First, let me define an event guide. For the purposes of this chapter, I'll define an event guide as organized content for an event, conference, or summit that allows attendees to find relevant information. In general terms, the purpose of an event guide is to give the attendee a portable overview of information for the event.

Why Flash and the Pocket PC Are a Good Fit

Creating a printed event guide involves numerous steps, and it limits you to when you can add or remove information. It would seem to make more sense to only have an electronic version of the event guide (see Figure 5.3), or depending on the event, to have both versions available.

Figure 5.3. Here you can see several screen shots of the Pocket PC Summit 2001 event guide.

There are several advantages of creating an electronic event guide with Flash versus a traditional printed guide. These advantages with the Flash guide include the following:

• Can be changed and updated at any time

• Is quicker to develop and has faster turnaround

• Can be shared with anyone

• Can create mini-communities

• Can be customizable

• Is printable

These are some of the benefits, but the most important one that I'm going to focus on is the interactivity of the application. By using Flash to create the event guide, you can utilize some of the capabilities of the devices, including connectivity. Some of these capabilities include realtime feedback of the current event, conference-specific chat rooms, user forums, and much more. Also, by allowing the application to be dynamic, you're able to push conference updates to users via wireless connectivity (Bluetooth, 802.11b). Now you have a living document that is interactive and can be shared. Pretty cool, huh?

Choosing Your Platform

Now you're thinking, "Okay, with all the different devices that are available to me, how do I choose the best one for my project and for the client?" If you're thinking about developing your project using Flash, then you're limited to devices that have a Flash Player available.

See the book's web site (www.flashenabled.com) for a list of the latest Flash-enabled devices.

Another feature to consider is which device will give the best user experience. Screen size will be an issue, so you're probably not going to consider a cell phone sized screen. You want to be sure your project is easily accessible and usable at any time, so a PDA solution is probably your best bet. Currently, there are two main PDA market segments: Pocket PC and Palm OS.

Finally, you need to think about the ubiquity of the device. You want to be sure that enough people have the target device to make development for it worthwhile.

Planning the User Experience

It can be easy to get carried away when designing a user interface (UI) for an application, so it's important to recognize the determining factors for creating the best user experience. You need to remember that the end user will be someone with a Pocket PC device. These devices have a small screen (320 height x 240 width in pixels), so it's not going to be the same as when designing applications for desktop PCs (usually 800x600 or higher). This means that you need to be creative and efficient when designing your application.

In most cases, the users will be using their stylus to access the information on the Pocket PC device, so the navigation needs to be easy to read and simple to understand. Some users might use "snap-on" or "fold-up" keyboards to access and enter information on their Pocket PCs. If you're designing an application that requires a lot of text entry, you might want to consider a "keyboard" solution to work with your application. Using contrasting colors and fonts that are specially designed for small screens is important to remember.

See Chapter 4, " Typography in Flash for Devices," for more information on using fonts with Flash on devices.

Eventually, the user experience will come down to a combination of different factors. These include the following:

• Amount of information

• Type of navigation

• Creativity

• Any special requirements

• Ease of use

Amount of Information

Depending on your project content, you need to determine what stays and what goes. If possible, try not to use information that is irrelevant because it might confuse the user. Organize information in a way that doesn't overwhelm the user. Make information usable.

Type of Navigation

Remember that you're working with a small interface, so you don't want your navigation to hog the screen. Menus that slide out, pull out, or expand and collapse are good solutions. Although these are only a few of the possibilities, it's up to you and your client to decide what the best navigation should be. Don't forget that the majority of your screen should be used to display the content of your application, not the navigation.

Creativity

Some people say you're born with it, and others say you achieve it through everyday experiences. Whichever the case, having some creativity in your application is necessary for several reasons. Creativity helps to separate your work from everyone else's. A client wants to have that standout, unique app that everyone is talking about.

Any Special Requirements

Being aware of and addressing any of your client's special requirements is vital; after all, they chose you because they believed in you and thought you could help them. Your project might require that the application connect to a database and update information nightly, or it may require Bluetooth connectivity between multiple users of your application each one on a different device. You need to be able to understand what the special requirements are and determine the best solution.

Ease of Use

Try to make your application as enjoyable as possible for the user while maintaining usability. Your goal is to create an inviting GUI that masks the fact that the user is interfacing with an application. Remember: You want your users to spend their time using the application and not learning how to use it.