When a writer sits down to draft an article or story, she must consider her audience. In a similar manner, when a developer sits down to code a Pocket PC application, he needs to consider the environment in which the application will be deployed. While similarities exist, Pocket PC development is not the same as developing for the client/server world or a Web-based environment. Aside from a drastically reduced screen size, the Pocket PC developer must also think about such factors as memory, CPU power, storage space, limited keyboard function, and a mouse-less operating environment. This new environment is a large enough departure from both the client/server and Web-based platforms that you need to start thinking outside the box of your traditional approach. The goal of this article is to expose you to some new strategies for Pocket PC development and encourage you to invent some of your own. What's so hard about designing a little application? Well, let me tell you. I've been building Pocket PC interfaces for the last several months using both Sybase's Pocket PowerBuilder and Microsoft's Visual Studio Smart Device Extensions (SDE). At first glance, it all seemed very simple - I could paint a screen and deploy it easily. Next, I began developing practical and more elaborate demos. It was during this process that I discovered one of the greatest challenges of the Pocket PC environment: data input. During a demo, I entered an incorrect value. My first response was to reach for the backspace key on the keyboard - unfortunately there was no keyboard. The point was driven home: developing for the Pocket PC was not the same as developing for a rich client. Developing the Screen
The best place to look for design ideas for Pocket PC development is already-existing Pocket PC applications. There are a number of successful applications, such as Word and Excel, that have been adapted to this new platform. By examining their interfaces, we can envision some tricks to use in our own Pocket PC applications. The first thing to notice about working on a Pocket PC is how its graphical interface differs from a standard desktop (see Figure 1). The Start screen consists of a list of icons used to navigate straight into a program with a single tap of the stylus, much like a Web-based hyperlink. The Start menu and clock are at the top of the screen and an abbreviated menu bar resides at the bottom. In time, you'll find that many of the applications on the Pocket PC make little use of menus, relying on them primarily to define options and create new records. Adopting the Start screen's graphical approach, we need to develop Pocket PC applications so the user can quickly navigate into applications with simple point-and-tap navigation. One of the first objects we developed at PowerObjects was a window we refer to as the Launch Pad (see Figure 2). It's a graphical start-up screen that allows the user to quickly jump into a business process and to also add additional processes in the future. The user can change the background graphic via the Splash menu and, thereby, customize the application to give it a more personalized feel. Notice also that the menus on the Launch Pad are limited; they serve, primarily, as access to less frequently used processes and options settings. Avoid Menu-Driven Applications
I've worked with several groups developing screens for the Pocket PC and the most common error I've seen is developers trying to force a client/server design on their Pocket PC applications. Don't repeat this mistake by trying to create an MDI frame that launches, tracks, and switches between open processes using a menu. Without a physical keyboard, users won't have access to traditional menu shortcuts, such as Alt-Tab. While menus on existing Pocket PC applications do allow users to point and tap, their content is not what users have come to expect on their desktop applications. Specifically, it's much more limited. Why not use menus in the more traditional sense? In addition to the lack of keyboard functionality already mentioned, menus don't offer the graphical experience associated with Pocket PC applications. They also consume valuable screen space. Instead of relying heavily on menu-driven user options, I recommend using a limited set of icons to assist the user in common tasks, such as Save, Open, and Delete. These icons should be placed to the right of the menus to conserve screen space, and remain intuitive to the user. Currently, neither Sybase's Pocket PowerBuilder nor Microsoft's Visual Studio (SDE) allows the developer to implement this technique, although it's used in most Pocket PC applications like Word, Excel, Internet Explorer, Calendar, Notes, and Inbox (see Figure 3). Fortunately, PowerObjects has developed a light framework that does make this placement possible. With this implementation, users gets visual clues as to what they can do with the application and, once again, it fits the point-and-tap interface design. PowerObjects' Solution
PowerObjects' framework includes a base window that allows icons to be toggled on and off. These icons provide basic functions: Save, Open, New, Delete, and an icon to indicate connection to the database. In addition to these functions, the interface provides a basic menu for less frequently used options. To achieve this intuitive design, PowerObjects had to create a special menu object that enabled the display of both a menu and icons in the same menu space. Again this saves valuable screen real estate and lends itself to the point-and-tap interface. The icons create consistency in the business application by allowing the user to have the same common actions on every screen. In Figure 4 we have Save, which is enabled whenever there is unsaved data, New, Open, Delete, and the icon to indicate an active database connection. Note that in this example the icons appear in color when enabled but are grayed out when disabled. Saving Data
When working on a Pocket PC, a user assumes all changes are saved automatically. For example, open a Word document and make a change. Now close the document or even power down the device. When the document is reopened, the changes have been saved. This design is different from the traditional message box approach, whereby a user is prompted to save changes before closing an application. Automatic saves alleviate the need for extraneous tapping, which is beneficial for two reasons. First, users don't need to open a menu and click Save or respond to a message box. Second, consider a salesperson who's just filled in 13 of 14 fields of customer information but doesn't have the zip code for Moose Jaw, Ontario. If he forgets to manually save the information or taps the wrong icon on his screen, the data will be lost and all the effort he put into keyboarding or transcribing will be for naught. Automatic saves are a good standard to develop against and it's one that Pocket PC users will come to expect as the devices become more prevalent. Developing to the autosave standard challenges developers to think about how and when a program saves data. What do you do when a user closes a window and she hasn't entered a complete and valid database record? At PowerObjects, we deal with these issues by first triggering a save when the application's window is closed and, second, creating a local database with a design that affords the insertion of records that might not be considered valid by the remote database. Keep in mind that synchronization to the remote database can move only complete and valid records. In addition to the autosave functionality, we've also developed a base class that gives users a more traditional, visual prompt for saving data. Specifically, a Save icon, located on the bottom menu bar, is turned from gray to blue when there's unsaved data. While this may seem to run counter to the autosave standard, it allows the developer to code other functionality behind the scenes, such as data validation. Local Database
Pocket PC applications are designed to run in any location - office, car, home, beach, etc. Because of this, a user can never depend on a connection to a remote data source or application server. To solve this issue, Sybase offers an excellent database, Adaptive Server Anywhere, for the Pocket PC. ASA allows easy synchronization with an enterprise database; it's also fast and easy to manage. In the client/server world, developers design an application and database assuming multiple connections to the same database, placing emphasis on table relationships and referential integrity. When developing for the Pocket PC, don't assume the application's database will be a small footprint of the enterprise database. In fact, the local database will likely end up being a subset of the rows and tables from the enterprise database and, in addition, will include other tables to ensure user data is never lost, as well as tables to support saving user preferences, saving a window's state, and saving and managing tasks that need completion. When synchronization of the two databases does occur, not all the data in the local database will need to be synchronized with the back end, so dissimilar table structures will not cause a conflict. Prompting for Input
When working in the client/server arena, you'll see some users that do everything with their keyboard and others who mouse their way through an application. I once worked on a computer for 20 minutes before realizing there was no keyboard. In the client/server desktop environment, data input is very efficient. This is largely due to Microsoft's design approach. Applications are easy to navigate and data input can be done in many ways and with many different devices. Now we need to design applications for the Pocket PC, a world where the stylus rules and "point and tap" is the convention. Pocket PC devices come with SIP (Soft Input Panel) to help the user enter data. SIP offers two methods of data entry: Keyboard and Transcribe (see Figure 4). The design of your Pocket PC application should make user input as quick and easy as possible. For example, generate lists from which users can select an entry. The application allows the user to select attendees from a list of trainees instead of making them manually add names of attendees using the keyboard or transcribe method. This might seem like a simple example, but it illustrates the idea of seeing the application from the user's perspective. They will appreciate data entry that is easy and efficient. Other input-friendly features include pop-up calendars, which are virtually indispensable in gathering date information. The same functionality that drives these calendars can also be used for gathering other types of input. In the applications that PowerObjects has designed, we've created something called "lookup objects" that assist the user in inputting data. When the user taps certain icons or arrows, a context-specific pop-up window appears from which a user makes a selection. For example, numeric columns may trigger a pop-up calculator to appear and allow the user to tap in a number quickly. The filter object allows the user to limit a list of data based on the filter selection. The prior value object enables the developer to design a "pick list" so that when a user needs to input a value, the list will default with common values for that column. The trick to this object is to retrieve a list of possible values for the field and then register the list with the column, then, when the user starts typing, the field autocompletes with potentially correct values. Not only does this save time, it also creates consistent input values. Conclusion
This article is meant to get you thinking "outside the box" when designing applications for the Pocket PC. Hopefully, you've gotten the message that designing for a small screen is not a small task. Developers need to consider many factors, such as screen design, data input, and how data is saved. At PowerObjects, we see the potential that lies in the Pocket PC platform and we're committed to creating applications that incorporate our latest development techniques. If you're interested in learning more about PowerObjects' Pocket PC framework, or would like help with the design and construction of your Pocket PC applications, we'd like to hear from you.