The Challenges of Pocket PC Development [May 2002 Pocket PC Summit]
With it's power, features and flexibility the Pocket PC platform is a very compelling mobile development platform. As a development platform it has also endured numerous immature tool suites and in the past has often failed to live up to the marketing hype as the universal panacea for extending the Microsoft paradigm onto mobile devices. The relatively short development life span of the Pocket PC specification (the last 18 months) [Editor's note: circa May 2002] coupled with disappointing wireless bandwidth advances have left many corporate architects and mobile developers uncertain of the future direction of Pocket PC development. My presentation is intended as a high altitude pass of the challenges inherent in Pocket PC development and the approach that enterprise developers can adopt to minimize the technology churn. Up for discussion are the maturing development platforms and methodologies embracing XML-based data exchange, database replication, the advent of the .NET Compact Framework and Smart Device Extensions as well as other development solutions. Both enterprise IT leadership and developer attendees will come away with a pragmatic approach to maximizing the return on investment in the Pocket PC development arena.
OPERATING SYSTEMS, PLATFORMS AND SDKS
Since we will be referring to these terms fairly frequently it’s important to understand how they all fit together. What exactly is the difference between the Windows CE operating system, the Pocket PC platform or specification and Software Development Kits (SDKs)? I’m sure there are more erudite ways of explaining the differences between the Pocket PC platform and Windows CE, but this is simplest and easiest to way of explaining this without getting too technical. Windows CE 3.0 (which is to be succeeded by Windows CE.NET) is the operating system that enables Pocket PC devices. As the operating system Windows CE is responsible for providing the device kernel that controls all the hardware of the device. Although it controls the hardware functionality of the device the operating system does not have a visible interface – that’s where the Pocket PC platform comes into play. The Pocket PC platform consists of a device with certain minimum device requirements; for example memory, color screen, infrared port; coupled with a shell; which is the actual interface we use to interact with these device features. The Pocket PC 2000 and 2002 are not operating systems – rather they are platforms that adhere to a particular specification defined by Microsoft. That specification says these devices will have these features and run the Windows CE 3.0 operating system. Currently we have the Pocket PC 2002 platform (originally codenamed Merlin) which is the successor to the original Pocket PC specification (originally codenamed Rapier). The next generation of the Windows CE operating system is called Windows CE.NET. This white paper deals primarily with the current Pocket PC platform – Pocket PC 2002.
To develop robust applications for the Pocket PC developers need to be familiar with the constraints of the Pocket PC device. This is fundamental to providing a robust and usable solution and is not as self-evident as it seems; especially when the developer has a limited test bed of target devices. The following characteristics of the Pocket PC make development a special challenge:
Not all Pocket PC’s have the same processor type. Earlier Pocket PC 2000 devices sported MIPS, SH3 and ARM processors whilst the latter Pocket PC 2002 devices have standardized on the ARM processor chipset, most of which happen to be of the StrongARM variety. These have processor speeds ranging from 120 to 206 MHz.
16MB to 64MB on board excluding storage cards.
The screen color depth varies between 12 (4096 colors) and 16 bit color (65535 colors) utilizing a 240 x 320 resolution.
The devices all include some form of expansion option to increase the memory via Secure Digital (SD), Compact Flash (CF) or PC Card slots/sleeves. These slots also offer connectivity accessories; you can add wired connectivity in the form of a dial up modem or 10/100 ethernet card; or wireless connectivity in the form of a 802.11 card, CDPD modem or Bluetooth GPRS connectivity.
This differs tremendously depending on the usage factors and power drain of connected accessories; for example Bluetooth modems.
Every one of these characteristics presents a challenge to the Pocket PC developer. Most of these characteristics have been deprecated in the desktop model since they can be addressed relatively easily. On the Pocket PC platform you can take certain steps to address these constraints but you have to be careful that you are not impacting the original design niche or purpose of the device. For example you can add additional memory and 802.11 connectivity at the same time using a dual PC card sleeve, and extend battery life using electric fuel or a PC card sleeve in the case of the iPAQ; however at this stage the device looks and feels like a brick.
THE MOBILE GUI EXPERIENCE
The user interface experience of the mobile user is so vastly different to that of the desktop that developers need to spend time using their own Pocket PC applications on the device in a real world setting rather than programming and testing them from the comfort of their desktop world. As obvious as it may seem it is an insidious problem that is imperative even for seasoned developers to observe. A good example, I have been developing applications for close to 15 years, the last 5 of which have mainly been web based. My first design of a Pocket Internet Explorer application positioned the menu system on the left hand side of the screen utilizing the same convention as we would in desktop world. Well as it was later explained to me by one of my fellow developers in crime, Carl Davis, that design is not optimal for the Pocket PC unless you are left handed. If you are right handed, as you navigate the menu system with the stylus your hand will restrict your view of the screen. This mistake is obvious when you stop to consider the ergonomics of your design but I bet many first-time Pocket PC developers have fallen prey to the subtle idiosyncrasies of the handheld interface. In addition if you had been testing this on the desktop emulator with your mouse, in other words not using stylus input – this wouldn’t occur to you at all. As simple a decision as screen colors can have a profound impact on the usability of a mobile application. Get out in the field, hold the device in your hand and try squinting at that yellow text in the sunlight.
Input methods are another area underestimated and perhaps misunderstood when designing Pocket PC applications. You can enter data using the embedded keyboard, the block or letter recognizer and transcriber. Each of these methods have their strengths and weaknesses. The environment that the device will be used in will also impact the appropriate use of certain input methods. For example using a Pocket PC with gloves on is not easy and in this instance the utility of a well designed numeric control to enter test data would be infinitely preferable than using the embedded keyboard.
INPUT NUMERIC CONTROL
In short remember to think carefully about the architecture of your design and how users will use it in the field. As Einstein said, “Everything should be made as simple as possible, but not simpler.”