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.”
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 an IDE cue rather than as a novelty item. The default font for Pocket PCs is typically 8-point Tahoma.
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.
Microsoft Windows Mobile 5 is designed to facilitate one-handed operation of devices using this platform. To support this design constraint, Microsoft recommends using a maximum of two top-level menu items in all applications you deploy to devices or emulators running on the WM 5 or later. Although this design constraint is not yet a requirement for Pocket PC devices, it has been and continues to be a requirement for Smartphone devices.
At runtime, the PocketBuilder VM determines whether the operating system platform is WM 5 or later. If it is, and the application that you deploy opens a window with a menu containing one or two top-level menu items, PocketBuilder changes the menu design to the style used by menus on Smartphone devices—that is, the top-level menu displays as two adjoining buttons, with labels corresponding to the menu item names.
For information on designing for Smartphone applications, see “Designing for the Smartphone”.
If, however, you open a window on a Pocket PC with the WM 5 or later operating system, and the window uses a menu with more than two top-level menu items, the menu style remains the same as the menu style on Pocket PC devices that use an older operating system. After a menu with a legacy style displays, all menus in the same application display with the legacy style, even if they have only one or two top-level menu items.
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.
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.
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")
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.
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.
