News & Resources — Articles
Planning Your Mobile Flash Projects
By Nader Nejat
This article originally appeared in the Macromedia Mobile and Devices Developer Center.Reprinted with permission.
Developing for a new medium, including mobile devices, can be a challenging, yet rewarding, experience. Due to various constraints and development factors, designing a project for a mobile platform typically takes two to three times as long as designing the same project for desktop delivery. It's good to keep this in mind when you are planning your project. Often it's tempting to start development right away. I did on one of my early mobile projects and was able to learn from some of my mistakes.
Last year, I rekindled one of my pet projects--you know, the kind that has been almost done for as long as you can remember. I decided to convert it to a mobile edition. Every time I work on a personal project, I try to focus on a couple specific areas that I can learn from. With this particular project, code named Wine Pal, I decided to focus on execution time as well as data visualization. I jumped in and started creating graphics and writing code. I also put off testing for a bit. I ended up having to throw out a lot of my UI work and rewrote a lot of code. Although frustrating, I was lucky not to have a looming deadline over my head.
In this article, I take you back to the basics, focusing on best practices that can save you a lot of time. Carefully planning your mobile project has many benefits. You will shorten your development cycle and end up with a much more polished project. This article will present best practices on planning your mobile project. We'll look at topics such as prototyping, using templates, reusing code, and testing.
Prototyping
Prototyping is a crucial first step in developing a project. A prototype helps generate additional project ideas, work out eventualities, spot design or logic flaws, and ensure a consistent and sustainable look and feel. Good prototyping can really speed up your development phase.Plan the architecture in pseudo code and sketch your graphical elements, including the UI, as thumbnails or in story boards. Make these sketches on sticky notes and order them as a user would likely encounter the screens or interfaces. Here are some rough sketches of Wine Pal and a screen shot of an alpha version:
At this point, borrow friends or other developers and run a small usability test session to improve the user workflow and architecture based on the "what if" user activity scenarios; do this before you move onto developing more complex areas of your application. Show the sticky notes or transparencies to your testers or film the interaction process and show the movie to the test group. You can put a flexible gooseneck camera, like a FlexCam above the device; it is an effective way to record scenarios. It's also a great way to demonstrate your project concept to your clients. Cameras like these are often inexpensive, so this is a viable option for many developers. You can prototype the early stages of a project rapidly in this fashion.
Using Templates
The templates that come with Macromedia Flash MX 2004 are extremely helpful tools for mobile developers. These templates preset the correct preferences for your target platform, and each template contains a bitmap graphic of the target device provided as a guide layer. As you create your Flash content, this visual guideline layer lets you lay out the content as it will appear on the device.Here's a bit of advice: Get yourself in the habit of thinking about creating for multiple devices by exploring multiple templates as you plan your projects. You will start thinking of creating content for multiple target devices, which will be a valuable perspective as you develop for increasing numbers of platforms. For more information on creating content for a specific device, get an appropriate content development kit (CDK) in the Macromedia Mobile and Devices Developer Center.
Creating Device Cutouts
Now that you've been playing around with the templates, you're probably wondering you can make all the different variations in work with your project. How can you keep the form factors of all the different devices in mind? One trick that works pretty well is to print out bitmaps of the devices, which Macromedia conveniently placed on the guide layers in the mobile templates. Glue the printout to a thin piece of cardboard and cut a hole where the device screen is. You now have a device cutout, which is very handy during the conceptual stage. Place your cutouts against different sketches or roughs to see how your content will display within the device. The cutouts are also useful for figuring out how to fit content in a small space; I often keep the cutouts handy when I'm reading a newspaper or a magazine. When I see a layout that looks like it may work well in a small space, I place my cutout against it and check.Separating Interface from Functionality
People will interact with your movies in different ways on different devices. They may be using a PDA, like a Pocket PC or a CLIE or they may be using a mobile phone. Your users may interface with your movie by using either a stylus or their fingers to press buttons.Do not make your functionality device-dependent. While you may be deploying to only one device today, you should leave your options open to publish your project on additional devices in the future. By separating your functionality from the events that trigger it, you leave your options open to offer a version for a different device in the future, like a mobile phone. If you are triggering functions in your movie, try to create triggers that work on many devices, rather than on just one.
Providing Multiple Ways of Interaction
Many devices let users perform tasks or interact with their interfaces in more than one way. Pocket PC Phone provides a good example of where a user needs several options for interfacing with your program. Let's say a user has already stowed away his stylus, but still needs to enter a phone number. Or the user may have to simultaneously address an incoming call while interacting with some Flash-based content. Offer users a choice of using the numbers on their touch pad or using their stylus so that they can easily use your program.Providing Multiple Levels of Reinforcement
Sound is often considered the illegitimate child of the multimedia industry. You'll often hear people telling you not to use sound at all. The general gripe is that sound is annoying, and no one cares about what it is communicating. Contrary to the naysayers' beliefs, many of us enjoy sound and find it useful.Many people predominantly interact with the world in an auditory manner. Sound can alert a user to open an application, much like a ringing phone prompts you to answer it. It is easy to imagine that in the near future, mobile devices will host critical applications, possibly even ones that people's lives may depend upon. Picture a Flash Communication Server-based application assisting medical personnel as they're dealing with a health epidemic during an earthquake or natural disaster. Their primary means of interaction to pass critical information could be through a mobile device. Rescue workers or medical staff could access real-time medical data and information, and sound would provide a much-needed function to alert and inform the mobile users.
Even in the ordinary day-to-day use of a mobile device, you get more out of applications that use sound. When a user goes outside and the sunlight is very bright, she may not be able to see your application. If you provide audio to reinforce the displayed data, the user can get a good idea of what's going on.
When a user needs to make a critical decision in seconds, make that easy for them. Use as much visual and audio reinforcement as you can. In the future we may have haptic, or tactile reinforcement, and you may be able to control levels and duration of vibration or provide pulsing in your mobile applications.
Reusing Code and Extended and Rewriting Objects
Want to save a lot of development time? You can probably repurpose a lot of code you've already written for previous projects, as well as set up a lot of code for reuse in future projects. For example, you'll probably write a lot of code that processes digit input and you'll frequently use a lot of code that responds to keyboard triggers. Structure your code so that once you write your first few mobile projects you'll be able to reuse your routines. You'll then have a code library to draw from, which makes it much easier to start and to demonstrate proof-of-concept prototypes rapidly. This can help you win a project bid.When I first started getting into mobile development, I wanted to do a fun, tiny project to experiment with various mobile-specific issues that arise when handling a lot of text and graphics. My idea was to play around with text and see how much information I could fit into a small space. I ended up deciding to create a mobile version of a bingo game based on corporate buzzwords.
Every time a user started a new bingo game, the application randomized the tiles. I used an array to store all the words, then I'd shuffle the array and generate the tiles based on the data. When I first deployed the game on a device, it was horribly slow--it would take two to three seconds just to randomize the tiles. Clearly, that was unacceptable--a user would think the game wasn't working and wouldn't play it. I found an array shuffling method on Prototype, a website by Layer51 containing a great collection of object rewrites and extensions. This code randomizes the tiles in about half a second. If something is slow from a code standpoint, Layer51 can be a great place to look for a better way to structure a portion of code.
Find object extensions and rewrites on Layer 51 Prototype:
http://proto.layer51.com/
Download or play Pocket Bingo here:
http://www.omegamedia.com/products/pocketbingo_orig.html
Focusing on Usability
When the CD-ROM industry was publishing lots of CDs in the early to mid-90s, everyone was trying to stuff an encyclopedia's worth of information on a CD-ROM. Now we're starting to see everyone trying to stuff a desktop onto a mobile device. You need to stay in control of your application design to provide usable mobile projects.First of all, a mobile device is not a tiny desktop. There is a new medium at play that merits a new development approach, with a higher focus on usability. If you build it they may come. If it's confusing, they will leave. Spend more time at the start of your project testing for usability. It's much easier and cheaper to make changes when your project only exists on paper.
Start researching the available information on mobile usability. Keep in mind that the research is written by people who view the world mainly in terms of textual information, not graphics or experiences. When you're reading books and articles on mobile usability, bear in mind that there are people out there who desire more than a text-based experience. Let that positively impact your design.
For more information on usability, be sure to checkout the Macromedia Usability Developer Center.
Testing Your Content with Users
Mobile testing is more immediate, easier to administer, and more effective than traditional methods of user testing. While it is difficult to have people come to your workstation or laptop to test content, with mobile, you can bring the testing environment to your test subject. One traditional method of testing applications remotely is to let users interact with a program over the web. This method is limited as you will miss visual cues that you could have gathered by observing users in person. You can learn a lot by how your user reacts, including expressions of amusement, excitement, or, through a look of confusion.Try to get people to test the content on the target device as it also approximates a more typical usage scenario. When you hand someone content on a device, he's usually very willing to look at it. It is hard to refuse a device that you already have in your hand. This is good news for mobile developers--we are uniquely able to test applications in this fashion, while other developers are confined to the desktop or web-based testing.
When observing a user test your application, focus on her eyes and how they move when she uses your program. If the person keeps moving the device back and forth while squinting, it's probably a sign that your text is too small. Designers and developers are used to looking at large amounts of information on high-resolution monitors, so our eyes tend to be much better at grasping information than those of the typical user.
Although it's tempting to help people by telling them what to do when they get stuck, donut. Let them struggle with your application. Ask them to speak their thoughts aloud. When they get stuck, ask them what they expect they should be able to do. Ask them how they'd do it. Then take this valuable information and reengineer aspects of your application as needed.
Anticipating Other Platforms
Multimedia and the devices that play it will continue to grow and evolve. For instance, truly interactive TV is waiting in the wings. Mobile developers are already dealing with a number of different form factors now, and many more coming in the future. The Pocket PC has a screen resolution of 240 x 320 pixels. Some CLIE models offer a 320 x 480 screen size. Soon we'll have really tiny phones, and who knows what Flash will be able to play on within a few years--free giveaway cereal toys maybe?Set up your files so that they can scale up or down to meet the different display needs now and in the future. Think about structuring your entire project so that you can resize it. And it's not just a matter of rescaling the project itself. If you're using bitmapped fonts, you can't rescale them since they work at particular point sizes. If scaled incorrectly, all the text becomes illegible.
Conclusion
If you have a personal pet project that's been sitting on your computer for months (or years) on end and it's been 80% complete, maybe now is the time to dust it off and create a mobile version. Redoing a pet project, or starting up a new one for a mobile device is a great way to get hands-on experience with mobile development issues. Don't forget to focus on a few issues that are critical to mobile devices, such as speed, limited screen real estate, and text presentation.In summary, I've taken you through various methods to plan your mobile projects. Since mobile projects take more time, a bit of careful planning can go a long way. Good luck with your project. If you create a mobile project, I'd love to hear about it:
You can e-mail me at mobiledev at omegamedia dot com.
Stay tuned for more mobile best practice articles in the Developer Center.
