Comparative performance  Designing for the Smartphone

Appendix D: Designing Applications for Windows CE Platforms

Designing for the Pocket PC

Efficient design

In applications for the Pocket PC, you should reduce redundancy and promote a single way of doing things. This means avoiding the use of options by presenting only the most efficient selection or procedure to use. The main view of an application should include the most important information, and other information should be just a single step away. Presentation and procedures should be as consistent as possible, allowing application users to “learn once, do everywhere.”

Tab pages, notifications, and information flow

On the Pocket PC, you can use a tab page approach to application design as a substitute for MDI windows, which are not supported on Windows CE platforms.

For persistent notifications, you can use the NotificationBubble object. Unlike a standard modal message box, the notification bubble does not stop processing.

On a Pocket PC, information should flow from the top down, and on English-language Pocket PCs, from left to right. You should place frequently needed controls close to the top of an application window. Audio should be used as a UI cue rather than as a novelty item. The default font for Pocket PCs is typically 8-point Tahoma.

Application titles, SIP display, and Pocket PC menus

You should display application titles in the navigation bar of a Pocket PC. On Pocket PC 2003, you should use the system support for automatic sizing of windows to fill the screen. (This is automatic with PocketBuilder applications.) Do not override these settings by entering custom size values. The Soft Input Panel (SIP) should display continuously for user text entry, and it should be hidden only where no user input is possible.

Menus on the Pocket PC are typically oriented from left to right, whereas buttons are typically aligned closer to the rightmost edge of the application screen. Typical Pocket PC applications can do without a File menu. A typical application might use the following menu bar items and display them in the order shown: Edit, View, Insert, Format, and Tools. Common command buttons display in the order: New, Open, Save, and Print.

Accelerator key combinations in menus and dialog boxes are not supported in Windows CE environments, and menu shortcuts should be avoided.

External files and icons

Pocket PC applications that use external file input or output must support long file names and the common system dialog boxes for opening and saving files. You can use 16x16 or 32x32 icons to represent a PocketBuilder application in the Pocket PC Switcher Bar. You should avoid user-exposed methods for closing applications. Applications should shut down without displaying dialog boxes or other controls for user input.

Using system functionality

Applications must not duplicate system functionality such as the Pocket Outlook Object Manager (POOM) object model, the notification system, or the MAPI, TAPI, and phone API functionality.

Providing online help

Online help for PocketBuilder applications should be integrated with the system TOC. You write help for an application as an HTML file and place the HTML file, or a shortcut to it, in the \Windows\Help directory. You can then call the PowerScript Run function to start the Pocket PC Help application and include the name of the Help file you want to open. The following example in a Help menu item script opens the Help file called myHelpTest:

Run ("peghelp.exe file:myHelpTest.htm#Main_Contents")

Wait cursors and size adjustments

Applications must respect user settings and display a standard wait cursor for unresponsive events.

Applications should adjust window and control sizes in SIPUp and SIPDown PowerScript events. The SIP must not overlay partial screen dialog boxes. Docked SIP panels have a maximum height of 80 pixels.

Saving application state

One instance only of an application should be running at a time. The application state is saved and restored on reactivation.

For a Pocket PC or Smartphone emulator, you must explicitly save the emulator state before shutting down the emulator, or the application is removed.





Copyright © 2004. Sybase Inc. All rights reserved. Designing for the Smartphone

View this book as PDF