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.

Database Diagram

Timeline

October 30
Research Handheld Device Design
November 10
Analyze Software for Device Specifications
November 20
Perform Interviews
November 21
Compile List of Design Specifications
December 1
Research Available Handheld Device Technologies
December 5
Progress Report
March 5
Implement Design Specifications into Hardware Design
March 20
Analyze Hardware Design
April 1
Complete Handheld Device Design
April 12
Publish Abstract
April 18
Symposium Report
April 20
Complete Thesis

Description

Within the scope of the project, I will be designing a handheld PDA that will efficiently deliver user interaction with software designed to maintain a grocery list. The software performs the task of compiling a list of items needed from the grocery store into a concise and easily managed interface. The handheld device would act as the user's portable interface and would supplement the user's personal computer interface by importing and exporting information.

The design will take into account the economic implications of each feature and seek to minimize the cost of the device and maximize the ease of use. To this end, market research will be done to recognize the needs of the consumer, and technological research will be done to utilize the most cost effective implementation within the hardware.

Such a device will provide the consumer with the resources to shop with efficiency, cost-effectiveness, and ease. The ability to travel with an unobtrusive device that enables the user to not only remember what he or she needs but also to know in real time what they are spending increases efficiency. A device that has been optimized to the application's specifications permits for a design that is unburdened by unnecessary cost and therefore cost-effective. As a result of a design maximized for ease of use, the user will find that this device is a must have item.
The culmination of the design will prove to be both academically stimulating and economically rewarding. Within the breadth of the design process I will obtain a working understanding of the technology needed for the implementation of various applications and also a practical method of engineering with a user in mind. Naturally this will lead to the device's economic feasibility and subsequently economic reward.

Thesis

The increasing need for mobile applications has provided a large market for handheld devices, but due to the initial cost of these units it is impractical for users to justify the cost when a single application is intended for use. Described here is the development process of a handheld device which has balanced the user cost with product value to implement a single application used to maintain an interactive shopping list. The focus of the design will be on the functional utility of a device in a real-world environment.