Now that you are aware of the manufacturers of touch screens, the technologies behind the screens, and the questions you need to answer to decide on which one to use, what are the things you should keep in mind when developing a Flash application for a touch screen?
Stay away from rollovers. Most touch screens only register either on or off pressure and not distinct levels of pressure. Thus, a rollover button would not function correctly. This is similar to the functionality of a Pocket PC and the authoring guidelines for that platform. Use press, press/release, or a combination of these to trigger your actions.
If you previously used the rollover to draw attention to the areas a user might interact with, you should rethink the flow and direction of your application and use other hints to guide the user through your navigation. Clear and concise navigation is key to making an effective Flash based touch-screen application. Limiting the choices available at any one time, if possible, will help guide the user through your application in a logical fashion.
Turn off the cursor. Because you can jump directly to any point on the screen simply by touching, turn off the cursor with the mouse.hide() function. The cursor will only get in the way and detract from the interface. On a Pocket PC the cursor is not visible regardless of a setting, but because your touch-screen kiosk may be based around the standard version of the Flash Player or plug-in, you will need to do this in the Flash document.
Determine your container. If you are using a browser-based environment to contain and display your Flash content, keep in mind invisible frame borders or other OS-specific items that may limit the amount of screen real estate you have to play with. A good trick on the PC side is to modify a shortcut to Internet Explorer that will prompt it to go into kiosk mode and take over the whole screen. You can simulate this manually by pressing F11 and disabling the menu bar, address bar, and so on. To hardcode a shortcut to do this automatically on the launch of Internet Explorer 4 and up, navigate on your computer to where Internet Explorer is installed (typically c:\Program Files\Internet Explorer\) and make a shortcut to Internet Explorer. Then modify the properties for that shortcut to add a K so that it looks like the screen shown in Figure F.1.
Figure F.1. Setting the properties for a custom Internet Explorer kiosk shortcut.
Now when you launch Internet Explorer with this shortcut, you are placed automatically in kiosk mode. Menu bars, address bars, status bars, and so on, are not available, and the only way to quit is Alt+F4. You can, however, still switch between applications with Alt+Tab. So if your application is browser-based, you might have to investigate third-party applications to help further lock down the environment, unless you do away with the keyboard completely and only allow touch-screen input.
If you are using the standalone player or a projector-based application, use the FScommand or new Stage object to control the scaling or full-screen mode of your application.
Use a virtual keyboard. If you do decide to remove the keyboard from the equation, yet your application requires keyboard input, consider including a virtual keyboard in your Flash application. Plan your application to allow room in your design to have an onscreen virtual keyboard. An example of this is the ATM interface in Figure F.2 and is similar to the virtual keyboard included with the Authoring Guidelines released by Macromedia for the initial developer version of the Flash 4 Player for Pocket PC platform.
Figure F.2. A virtual keyboard being used for text input in a touch-screen ATM interface.
Allow for variations on the "pointer factor." Keep in mind the size and shape of your stylus and constantly test to be sure the layout of the Flash buttons or interactions are not so close together that they cause the user to have to attempt his input more than once. Having as many people as you can test this with actual fingers is helpful as well. Don't assume that your finger or the way you point at the screen will be the same as every other person. If you have the room, make your buttons larger and spaced further apart than you normally would.
Consider invisible frames. If you have to talk to many different ActiveX objects to allow your Flash application to interact with hardware, consider using an invisible 1-pixel-high frame in your layout to which you can direct getURLs . Using the onload method in the body tag, you can have "trigger" HTML files that are designed to talk to and load individual ActiveX objects, instead of using the FScommand to invoke or call particular subroutine of one large ActiveX object. You could also build an ActiveX container to hold the Flash OCX and talk to it directly with ActiveX methods.
For more information on this last technique, see:
www.macromedia.com/support/flash/ts/documents/activex_script.htm.
JavaScript is also another method to communicate with the Flash plug-in, but there are limitations when using this method from browser to browser and from platform to platform.
See Appendix C, "Flash Device Resources," for links to resources on using Flash with JavaScript.
Combining technologies. You can combine JavaScript, ActiveX, and VBScript. For example, JavaScript can retrieve information from a VBScript and pass it back into a Flash movie.
Consider LocalConnection. A brand-new feature of Flash MX and the Flash 6 Player is the capability for two or more open and active Flash content areas or applications running on the same machine to talk and pass information back and forth to each other. This is done without the need for JavaScript or ActiveX and is done totally in Flash using the new LocalConnection object.
 | See the example on the web site (www.flashenabled.com) covering the LocalConnection Object. |
Consider your content and purpose when deciding on the actual touch-screen size. A 20" touch screen might be good for a medical application where a doctor is reviewing images and making choices, and might not be good for a touch-screen application where someone is entering credit card information. A clever idea for PIN entry is to have the keys appear on screen in a different order each time the screen is presented. This can be an effective method to prevent shoulder surfing of PINs in a touch screen environment. For example, a virtual keypad will have digits 0 9. Make an array object containing the values 0 9. Then using the following example code, build an array shuffle method:
Array.prototype.shuffle = function() { var len = this.length; var i = len; while (i ) { var p = random(len); var t = this[i]; this[i] = this[p]; this[p] = t; } }; pins = new Array(); for (x=0; x<=9; x++) { pins[x] = x; } function doit() { pins.shuffle(); trace(pins[0]+" "+pins[1]+" "+pins[2]+" "+pins[3]+" "+pins[4]+" Â"+pins[5]+" "+pins[6]+" "+pins[7]+" "+pins[8]+" "+pins[9]+" "); } setInterval(doit, 1000); Shuffle the array and use the shuffled results to order the way the PIN input items are placed on the screen. Thus, every time the PIN entry screen is presented, it is in a different order, preventing the casual onlooker from knowing which buttons the user is pressing. Of course, be sure that the users know that the numbers will be shuffled for security reasons; otherwise they may get confused and press the wrong numbers.
Constant testing and retesting. The most important part of the process is to constantly test how the interface works on your touch screen as you develop. If at all possible, use the same make or model of touch screen during development as the one that will be used in the deployment.
If you don't have access to the touch screen while developing the application, you can still test for the live area on a demo. The live area is the area of the screen that will be viewable and that accepts users' input. Get access to the targeted device for an hour or so and test for the live area on the touch screen. A good rule of thumb is to allow a 1/4- to 1/2-inch margin on all edges of your application where no button activity will be placed. This prevents users from having difficulty selecting items with their fingers near the border of the screen, and prevents problems if the screen becomes misaligned.
Finally, if using the Flash Player 6, you can also use the System.capabilities object in conjunction with the new Stage object to automatically determine or configure the size of your Flash-based application, depending on the screen resolution. See the example file touch_stage.fla on the web site that accompanies this book. Launch the published .swf from this document in a standalone Flash Player on your target machine with the targeted screen connected. Change the document to full-screen mode. This Flash document uses the stage object to show you how a full-screen Flash document will scale and fill the screen. Use the up-, down-, left-, and right-arrow keys to cycle between the various scaling modes. Wherever a press from a stylus or finger is registered in this document, a virtual fingerprint is left with the x and y coordinates of the location where the press was registered. This can be helpful in determining your layout. Drop a mockup of your layout into a background layer of this movie to see how well your planned button spacing might work. This file also iterates through the System.capabilities object, displaying the value of each.
Use high-contrast interfaces if possible. This is especially important if you are using resistive- or capacitive-based touch screens, as their technology requires several layers of material in the touch screen to work and these layers can sometimes degrade the saturation or intensity of the screen. SAW screens are better suited for applications that demand color fidelity and intensity of your Flash application.
Also consider the visually impaired. Some users may be color blind and unable to distinguish between certain colors. This renders your interface difficult or impossible to use. You should also be aware of federally mandated guidelines for meeting the Americans with Disabilities Act and how they might apply to your project. There is a new accessibility feature of Flash MX and the Flash 6 Player that works in concert with screen reader technology, allowing the user to hear the interface and prompts. For more information about the official ADA Standards For Accessible Design covering topics ranging from wheelchair entrance ramps all the way to ATM interface design and specifications, see the following government web site: www.usdoj.gov/crt/ada/stdspdf.htm.
Macromedia additionally has an excellent resource section on its site devoted specifically toward accessible design methodologies for its products including Flash. It is available at: www.macromedia.com/macromedia/accessibility/.
Use sounds to complement visual clues. If the environment allows for it, add narrative sound to help instruct a user, either as feedback to input or as a guide to navigation. Also be aware that, by default, some touch-screen drivers, such as Elo TouchSystems, automatically provide sound-based feedback to screen touches. Typically they can be disabled in the control panel or settings for the particular driver you are using so they don't conflict with sound in your Flash application. Visiting the accessibility resource on Macromedia's site you will also find information about sound as well.
Utilize the new Flash MX video features. The Flash 6 Player is now a perfect delivery vehicle for streaming video. Don't forget this when bidding on a job. Now your touch screen interface can deliver video, as well as Flash based content. You may require other tools during production, but having one main technology to deliver it on your touch-screen interface will simplify deployment. An excellent idea for a Flash-based touch-screen kiosk would be a glorified instant snapshot kiosk. Hook up a web cam to a standalone projector on a web-enabled touch-screen kiosk and within minutes you could build a kiosk that allows users to take a snapshot and have it delivered to a friend via email. A perfect vacation spot kiosk to replace the standard postcard.
