SPECIAL CONSIDERATIONS FOR DEVICES

Interface design for devices is very much a world unto its own. You'll probably glean at least a couple of important rules from both this chapter and from your own common sense; keep it small (but not too small!), and keep it simple.

Although keeping your applications small and simple are valuable core ideas, implementing these rules can be far from easy. Different devices bring different challenges. For example, if you've ever worked on, say, a kiosk, you are well aware of the first big challenge our design group ran into: rollovers, or lack thereof.

Making Buttons Stand Out

Because devices rarely deal with mouse-based input, no actual cursor exists. In fact, the position of the user's "pointing device" isn't known until he actually taps on the screen. This obviously disallows the use of any kind of rollover or rollout effect. Given how simple such effects are to create in Flash, it might take you some time to get used to being without them. Just remember to keep that OVER state of your buttons the same as your UP state.

Besides the obvious cosmetic pleasantries that rollovers provide, they also serve the important role of letting the user know what he can click on. This means that you need to be sure that the user can tell what is "clickable" on devices. Beveled edges and other 3D effects might be tempting, but remember that you only have a limited amount of real estate. Why use those valuable pixels on the interface when you don't have to? Take a cue from the device's OS makers: Some of the best interfaces for devices Palm OS and Windows CE are flat in nature. They use shapes, small icons, and certain consistent rules to cue the user to what is a button and what's not.

Surrounding text with a simple border or making it bold works well for denoting something as a button. By making something stand out, you are cueing the user into the fact that it's not just something to read.

Icons work similarly well, as long as they are good icons. Good icons denote an idea or action clearly and with little to no room for confusion. An envelope icon for email and a Clipboard for tasks are both examples of good icons. Good icons don't need text labels, so if you find that you really need some kind of textual label, consider revising your icon.

One of the most important but overlooked ways to denote something as a button is to be consistent in your buttons. Show all buttons in your application the same way, and if possible, show them in the same area of the screen. This way, after the user understands the basic rules for what is a button, he can make intelligent guesses in later parts of your application.

Limited Device Functionality

Besides buttons, another problem when designing interfaces for devices is working with the fact that the user's input has been mostly stripped down to two functions: tapping and dragging.

Tapping by nature isn't extremely precise. With a mouse, you can "aim" with the cursor before clicking. With a stylus-based interface, you either get it right, or you don't. Therefore, you should be sure that all your interface components are large enough for the user to make small mistakes but still hit the target using either the stylus or his fingers. What if the user still manages to miss? If your interface is designed in an intelligent manner, this shouldn't be a problem. Your buttons and other components should be spaced far enough apart that it would be difficult for a user to both miss his target and hit something else.

Zombie Buttons

The fact that you don't have an actual cursor on devices causes one particular bug that you might run into: zombie buttons. That is, if you press on a button and then drag the stylus and lift off the screen while not on the button, it will stay stuck in its DOWN state. However, the button will properly fire any on(releaseOutside) statements that are attached to it.

The easiest way to deal with this issue is to make all your buttons invisible and then have movie clips represent the actual graphics of the button. These movie clips can have two frames: one for the UP and one for the DOWN state. The invisible button can simply tell the movie clip which frame to show.

Dragging can also be a problem for users. Problems mainly arise when you don't let users know they are dragging something. The simple remedy for this is to be sure that all your buttons have a DOWN state. Also, if the range of the dragging is limited, you should visually show the user what that range is. These "gutters" help the user get a sense of proportion, which is quite important when manipulating slider-type controls.

Although not specific to devices, an additional rule you should stick to is keeping the poison away from the milk. That is, keep components that perform destructive actions as far away as possible from your other components. If you design your interface with this in mind, then a user who manages to miss his target and hit something else won't do damage. A good example of poor design in this manner is the Windows icon strip at the top of all applications Minimize, Restore, and Close. It is easy for a beginning user to accidentally click the Close icon when he just meant to minimize the window.

The Challenge of Typing

Unless a device comes with a keyboard of some sort, typing is far from easy for users. If at all possible, it's best to avoid having users type. If you can't avoid the need for typing, however, you have two options:

• Let the OS handle it. Pocket PC devices have built-in software keyboards, but they always appear at the bottom of your screen; therefore, these keyboards could easily block the text field in which the user is typing. If you plan to use the built-in keyboard, be sure that you keep your text fields at the top of the screen and be sure that the keyboard won't block anything the user needs while he types.

• Make a keyboard in Flash. If you provide the only method for input in a text field, you can do all sorts of things, such as limiting the user to certain characters or making the keyboard dragable. This option is more flexible than using the OS keyboard, but at the cost of development time and file size. If you do decide to use a custom keyboard, it's often a good idea to "pop up" the keyboard automatically for users. You can do this by attaching the following code to a movie clip in your movie. The code determines (when the mouse is released) what, if any, text field has been selected and then runs the code of your choice.

 onClipEvent(mouseUp){     var selected = Selection.getFocus();     if ((selected != null)){         // insert code to display keyboard here     }  } 

Small Display Area

A major issue that every person who is developing for devices runs into is the extremely small screen real estate. There is only so much you can pack onto a screen at once. In fact, it's best to try to keep as little as possible on the screen at one time. Don't try to pack information onto the screen like you would in a desktop application. Instead, base your system around screens of information. For a good example of this type of design, look at the Windows Media Player for the Pocket PC. Most of what you need to do with it is on the main screen play, pause, fastforward, and so on. All the additional functionality, such as playlists and track info, has its own separate screen. This keeps the information accessible, yet the interface remains uncluttered and readable.

With such little space in which to work, it's tempting to scale down fonts to tiny when developing for devices. This can be a real problem with Flash though, due to its built-in anti-aliasing. If you look at text in Flash, it's often fuzzy, which makes small text nearly impossible to read. There are numerous ways around this problem though, from making your movie run in LOW mode to using pixel fonts, such as those available from http://miniml.com/.

For more information about using text with Flash on devices, make sure to check out Chapter 4, " Typography in Flash for Devices."