Conclusion

Handheld design, particularly for technicians, is a field with very little room for error. Far more than in a desktop interface, there is a very real danger that users will find the device unusable on the basis of seemingly minor deficiencies. Due to previous failures to effectively replace NASA's existing paper systems, suspicion of handheld solutions will be high among the workforce. The final PROPHET design cannot just be acceptable. It must be a significant step above conventional modern solutions. With our research as a base, we are confident of the future of the PROPHET HCI design effort.

challenge summary

Our design challenge was to address the problem reporting needs of the roles of the three user roles of Technician, Quality, and Engineer, and to automate a fourth, that of Problem Reporting System Expert, through the introduction of a problem reporting system capable of supporting composition & submission of reports directly from the problem context. While this interface would primarily be used by technicians on the work floor, the impact of their problem reporting behavior spreads throughout NASA.

The three critical roles in this system are the following:

The Technician, assigned to focus on the work itself to the exclusion of the broader context. Possessing a range of experience ranging from junior personnel to technical leads, they work with their hands and are sensitive to minute irregularities in the products they maintain. In the event of a discrepancy with what they expect, they are prepared to report it, but junior technicians produce many false alarms.

Quality, charged with assessing reports of discrepancies and elaborating them for later review by engineers. In the event of a superficial anomaly, Quality can elect not to bother the engineers about it, but even then, it is important that the anomaly be somehow logged, in case it was dismissed without basis. Legitimate problems are elaborated upon to the point where engineers can quickly comprehend the discrepancy.

The Engineer, responsible for receiving and reviewing the elaborated problem reports, analyzing them, and recommending corrective action. Engineers are best suited to consider the broad overview of the context of a single discrepancy and locate trends. It is the duty of technicians and Quality personnel to ensure they stay informed.

The breakdowns we identified in problem reporting are repeated all over NASA. We believe many failures at NASA occurred partially because the true needs of technicians were not taken into account, and so the resulting creation did not contribute to the technician's quality of work. A handheld problem reporting interface should only be deployed if it is measurably better than no handheld at all. The PROPHET project is determined to create an interface that rigorously addresses this challenge.

form factor specifications

The development of handheld devices is proceeding at a rapid pace, and we cannot know what form factors will be available when Constellation is fully underway. Therefore, rather than insist on a specific model available on the market today, we formulated a series of specifications intended to support the appropriate choice of a viable platform in the future. For the present, we found a Symbol MC70 to be a minimally adequate prototyping platform, although it failed specifications for bulkiness, color camera, screen resolution, and lack of modal keys.

The form factor specifications are drawn from our user testing are as follows:

★ The device must be durable, and furthermore must appear durable to its users.

★  The device must be hardened against fragmentation and invulnerable to liquids and other substances of the technical environment.

★  The device must not be, and must not appear to be, bulky or heavy.

★  The battery must be capable of surviving at least one full working shift. The ability to switch batteries without turning off the device is highly recommended.

★  A 3.5-inch diagonal screen size is adequate; given a similar screen size, more dots/inch is superior, allowing improved legibility at smaller fonts, and in all ways improving the speed and accuracy of handheld problem reporting.

★  Screen visibility must be acceptable in shadowy viewing conditions and at awkward viewing angles vulnerable to difficult visual contrast effects.

★  The device must have a bar code scanner, or similar identification technology, for speedy identification of items and personnel; the work environment must support its use with visible and ubiquitous labeling.

★  The device must have a low-megapixel camera, located on the opposite side of the device from the screen with a high-accuracy lens and fast shutter speed, flash, and automated scale detection.

★  The device must provide the ability to capture audio and voice recordings.

★  A stylus must be available for novice users, attached with an elastic tether strong enough to support the weight of the entire device.

★  The keypad must have few if any modal keys, and non-modal number keys. A distinction between capital and lowercase letters is not useful.

★  There must be dedicated scrolling buttons along the side of the device adjacent to the screen for speedy navigation.

★  Forward and backward tab buttons must be available for expert users.

★   A hard button keypad is a necessity.

★  The device must experience universal wireless connectivity at all times.

★  The device must be tethered to the user in high places, non-Foreign Object Debris environments, above fragile components, and above other employees.

interface specifications

A distinct Technician interface must support speedy communication of the existence and location of a discrepancy to Quality. This interface must be minimal and communicate only enough for the Quality personnel to locate the problem, allowing the user to return to work. The process of filling out the form must be fast enough that the user sees it as less of an obstacle than fixing the discrepancy without reporting. The user should not be burdened with the routing of the report, which must occur automatically & invisibly.

The resident form factor of this interface must be on the durable device described in the specifications above. The technician should carry this device with him during his work, and keep it with his tools.

Before using the device, the user must be able to log in using a form of personal identification. Once this is completed, all reports he creates are automatically signed with that identity. By tracking the user's location, the system will be able to deliver notifications from engineers directly to the technician in the event that a problem needs further research, regardless of the reassignment of the technician. A second and equally distinct interface is required for Quality personnel. While resident upon an identical device as the Technician interface, the Quality interface will only appear when Quality personnel authenticate themselves on the device, allowing all workers on the technical floor to use the same store of devices, and to share them when necessary.

Quality personnel must have the option to assert a certain level of urgency to problem reports whenever the judge it necessary. While this is by no means a valid form of analysis in the larger PRACA workflow, its value is in its ability to communicate to engineering that a certain problem may be urgent; proper visual design of an engineer's interface, if this specification is fully adopted, can help engineers spot urgent reports quickly and easily among those submitted.

Quality personnel do not normally need to review existing problem reports at the scene of the problem, with one exception. Due to extensive text entry required, it is frequently more efficient for Quality personnel to copy sections from older reports. The interface must supply templates of common problem reports for speedier repetition, without inclusion of any values that need alteration before submission, which the user may forget to change. See below for recommendations on this subject.

The online form required is far too long, as it is, to expect speedy creation of problem reports. Therefore, the development of a Quickmode widget for the speedy entry of technical information into online forms using handheld interfaces is required.

This widget must provide capacity for the accurate auto-completion of field values across a library consisting of a two-dimensional array including both field names and field value, allowing users to skip the steps required for conventional navigation.

We prototyped Quickmode by developing a hypothetical interface capable of running on the personal handhelds of NASA engineers, allowing them to monitor the reports of technicians and Quality personnel at all times, decreasing lag.

future recommendations

With the closure of the PROPHET 2007 project, we intend to specify avenues of further research, so that future teams can best continue where our project ends. Our recommendations for further research and development include the following:

Speed Quality's handheld input through the provision of useful templates. Repeat problem report detection was identified as a means of enabling the appropriate provision of prior report content when necessary, and on a more direct level, allowing Quality personnel to create and save report drafts as templates could potentially speed reporting.

Leverage the Work Authorization Documents for a future handheld.Although entirely out of the scope of PROPHET 2007, the consolidation of all technical paperwork into a single interface could greatly increase the effectiveness and efficiency of technicians across NASA. By reporting directly from a WAD workstep, various data fields could be filled in automatically, speeding reporting. Finally, coupling the PRACA interface with an indispensable WAD handheld would ensure that the handheld would never be left far away from the site of the technical work until it is needed.

Investigate strategies for advanced multimedia collaboration. We originally noted stylus annotation, combined with image, video and audio multimedia and possibly occurring in real-time, as a possible means of allowing direct collaboration between non-colocated engineers and technicians. The PR system is intended to create collaboration between roles on problem reports, and this is a useful route of future investigation.

Develop an accurate system of constraint propagation. The faster input into the PROPHET interface becomes, the more problem reports will be filed through it and the more accurate and complete these reports will become. By creating a complex yet accurate system of constraint propagation, and limiting possibilities for drop-down menu options and auto-completion, fewer choices to sort through can speed data entry.