Progress Report

The extent of my progress on this project has been both broad and focused. The development of a device of this caliber requires attention to the most minute details while also maintaining an ability to evaluate the contribution of the details to the whole. In this respect my research has been quite time consuming.

The initial consideration of “device design” was daunting as I began to realize the vast amount of components that had to be specified. First was the conceptual designation of the device type. Handheld devices are categorized in three different categories (see Illustration 2.1): phone, pager, and personal digital assistant (PDA). In light of these specifications, I found that my original paper title “Design of Handheld Device for User Applications” lacked the specifiicity needed to be effective. In response I changed the title of the paper by adding “Handheld PDA” instead of “Handheld Device”.

The second change to the title was to state the intent of the project. By adding “Single User Application”, the project took on yet another designation in an attempt to narrow the scope of the design. The device's purpose was to augment a shopper's efficiency, not to provide a comprehensive tool for multiple applications. The design needed to reflect the restricted nature of the project; therefore the final title reflects the nature of what will be accomplished through the course of the project.

From this point the design spiderwebs into multiple areas of specification including: input device specification, memory modeling, and menu layout. Thankfully I found several resources that helped immensely with lying out the criteria for the design. I found that reading though collections of papers presented at conferences for ubiquitous computing were most helpful in the following process.

The nature of the PDA requires that everything from the buttons and stylus to the very shape of the device be considered as hardware user interface elements. From this point forward, any hardware consideration must be made with the whole design in mind. For example, if it is decided that the device will be primarily driven by stylus inputs, then the screen of the device needs to be larger than it would if driven by button input. Most devices that are on the market have implemented both button and stylus inputs with various proportions. In some cases devices have both offered full QWERTY keypads and stylus handwriting recognition. The QWERTY keypad (see Illustration 2.2a) is named for the left-to-right arrangement of keys on an English keyboard. The keypad is characterized by tiny buttons and ease of use, whereas the stylus handwriting recognition (see Illustration 2.2b) is characterized by difficult often non-intuitive keystrokes and slow device response. In an attempt to reckon with the shortcomings with the handwriting recognition, on-screen keyboards have been offered, but the method requiring the user to tap each character with the stylus makes for a slow and deliberate input mechanism.

By far the QWERTY keypad is considered to be the preferred extended input mechanism, but what if the device needs input for navigation more often than it needs data entry? In this case it is beneficial to look at cell phones. Cell phones have effectively integrated data input while also accommodating navigation. To accomplish this balance several button types and configurations have been utilized. Directional keypads (see Illustration 2.16) provide directional arrow buttons to move the highlight and/or scroll content. Roller wheels allow menu traversing by “wheeling” through options and frequently can be pushed to active a selection button. Rocker controls are directional controls that are usually place at the upper left-hand side of the device.

As stated these input methods are inexorably linked to the overall device specification, and therefore any further consideration could not be made without exploring the device's form factor. The form factor of a device refers to the size-shape relationship. A handheld device is fundamentally easily held and manipulated. This is referred to as the mobility of the device. Mobility is described by the following factors:

*combined weight of all the necessary components, such as CPU, display, keyboard, and mouse
*number of required components and how they are configured
*cables needed for operation, such as power, networking, and component configuration
*size of the fully configured system in height, width, and depth

Having completed a cursory look at the physical interface, next the data modeling of the user application in question must be done. In modeling the data and the user interaction with the data several problems must be addressed. Information accessed by the application must both be readily accessed and maintained without spurious anomalies. To model the data to verify its integrity a Extended Entity Relationship (EER) was developed (see Illustration 2.3). Because of the intrinsic nature of the relationships in this application, it is impossible to model the data with straightforward modeling techniques. As Illustration 2.3 shows there is no way for a single relationship to represent the full semantics of the relationship between Consumer, Grocery Store, and Item, but by using the EER diagram a weak entity type “Stock” serves as the common factor to maintain the semantics of the data.