Citation
PalmQues: A Palm OS Questionnaire System with Database Connectivity

Material Information

Title:
PalmQues: A Palm OS Questionnaire System with Database Connectivity
Copyright Date:
2008

Subjects

Subjects / Keywords:
Data models ( jstor )
Data storage ( jstor )
Databases ( jstor )
Electronic paper ( jstor )
Electronics ( jstor )
Legacies ( jstor )
Questionnaires ( jstor )
Screening question ( jstor )
Synchronizers ( jstor )
Waiting rooms ( jstor )

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright the author. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Embargo Date:
11/4/2002
Resource Identifier:
70786470 ( OCLC )

Downloads

This item is only available as the following downloads:


Full Text

PAGE 1

PALMQUES: A PALM OS QUESTIONNAIRE SYSTEM WITH DATABASE CONNECTIVITY By RYAN M. DONAHUE A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLOR IDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2002

PAGE 2

Copyright 2002 by RYAN M. DONAHUE

PAGE 3

ACKNOWLEDGMENTS I would like to thank Dr. Dankel, my advisor, for the help, input, and direction he has given throughout. I would also like to thank him and Dr. Benn for providing a forum where I and other students could discuss our ideas and receive feedback. It was very helpful, and I hope that he continues to conduct the forum for future students. Finally, I thank those in my personal life for tolerating me throughout my thesis work. I know it was not easy. iii

PAGE 4

TABLE OF CONTENTS page ACKNOWLEDGMENTS ................................................................................................. iii LIST OF TABLES............................................................................................................. vi LIST OF FIGURES .......................................................................................................... vii ABSTRACT....................................................................................................................... ix CHAPTERS 1 INTRODUCTION ............................................................................................................1 2 SURVEY OF EXISTING QUESTIONNAIRE SYSTEMS.............................................4 Descriptions and Short Comings of Existing Questionnaire Systems............................ 4 SurveyMate .............................................................................................................. 5 Professional Quest.................................................................................................... 6 eSurvey Solutions .................................................................................................... 7 ScreenSurvey ........................................................................................................... 8 The Survey System .................................................................................................. 9 Surveyor................................................................................................................. 10 Entryware............................................................................................................... 11 Inquisite.................................................................................................................. 11 Questionnaires & Analysis (QA) ........................................................................... 12 Chapter Summary ......................................................................................................... 13 3 PALMQUES: THE SOLUTION SYSTEM ...................................................................14 The Paper Questionnaire Process.................................................................................. 14 PalmQues System Description............................................................................... 16 PalmQues Users ..................................................................................................... 17 Data Flow............................................................................................................... 17 Questionnaire Definition........................................................................................ 19 Questionnaire Definition Format (QDF)................................................................ 25 Design Issues ................................................................................................................ 28 Avoiding the Pitfalls of Other Systems.................................................................. 29 Ease of Implementation ......................................................................................... 29 Platform.................................................................................................................. 30 Connecting to Data Sources................................................................................... 31 iv

PAGE 5

Specifying Data Storage Locations........................................................................ 32 Question Types ...................................................................................................... 33 Conditional Questions............................................................................................ 33 Chapter Summary ......................................................................................................... 34 4 THE PALMQUES EDITOR ..........................................................................................35 Components of the Graphical User Interface................................................................ 35 The Questionnaire Tree.......................................................................................... 35 The Menu Bar ........................................................................................................ 36 The Tool Bar .......................................................................................................... 38 The General Properties Frame ............................................................................... 39 The Question Frame............................................................................................... 41 The Answer Frame................................................................................................. 42 The InsertField Builder .......................................................................................... 43 The Update Builder................................................................................................ 44 Graphical User Interface Style...................................................................................... 46 Chapter Summary ......................................................................................................... 47 5 THE PALMQUES SYNCHRONIZER ..........................................................................48 HotSync Manager Conduits.......................................................................................... 49 The PalmQues Synchronizer as a HotSync Manager Conduit ..................................... 50 The GetConduitInfo Entry Point............................................................................ 50 The GetConduitName Entry Point......................................................................... 51 The GetConduitVersion Entry Point...................................................................... 52 The OpenConduit Entry Point................................................................................ 53 The QuestionnaireSync Class ....................................................................................... 54 Interpreting QDF Files........................................................................................... 54 Uploading a Questionnaire Definition ................................................................... 55 Storing Results ....................................................................................................... 55 Chapter Summary ......................................................................................................... 56 6 PALMQUES MOBILE PRESENTER ...........................................................................57 Palm Applications......................................................................................................... 58 Palm Memory Management................................................................................... 59 Palm Application Launch and Exit ........................................................................ 60 Questionnaire Definition Storage ................................................................................. 61 Result Storage............................................................................................................... 61 Chapter Summary ......................................................................................................... 62 7 CONLUSIONS AND FUTURE RESEARCH...............................................................63 LIST OF REFERENCES...................................................................................................67 BIOGRAPHICAL SKETCH .............................................................................................69 v

PAGE 6

LIST OF TABLES Table page 3.1 The Questionnaire Definition Data Structure .................................................................20 3.3 Mapping from Data Structure to XML Element.............................................................27 3.5 ODBC Compatible Database Products...........................................................................32 5.1 HotSync Manager Conduit Entry Points.........................................................................50 vi

PAGE 7

LIST OF FIGURES Figure page 2.1 Questionnaire System Evaluation Form ...........................................................................5 3.1 Paper Questionnaire Data Flow ......................................................................................16 3.2 PalmQues Data Flow ......................................................................................................18 3.3 PalmQues Component Data Flow...................................................................................19 3.5 Insert Example ................................................................................................................22 3.6 Update Example..............................................................................................................24 3.7 QDF.dtd ..........................................................................................................................26 3.8 patient_history.qdf ..........................................................................................................28 4.1 The Questionnaire Tree...................................................................................................36 4.2 The Menu Bar .................................................................................................................38 4.3 The Tool Bar...................................................................................................................39 4.4 The General Properties Frame ........................................................................................41 4.5 The Question Frame........................................................................................................42 4.6 The Answer Frame..........................................................................................................43 4.7 The InsertField Builder Window ....................................................................................44 4.8 The Update Builder Window..........................................................................................45 4.9 The Wizard Component of the Update Builder Window ...............................................46 5.1 The Function Signature of GetConduitInfo....................................................................51 5.2 The Function Signature of GetConduitName .................................................................52 5.3 The Function Signature of GetConduitVersion..............................................................53 vii

PAGE 8

5.4 The Format of the GetConduitVersion Return Value.....................................................53 5.5 The Function Signature of OpenConduit........................................................................53 viii

PAGE 9

Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science PALMQUES: A PALM OS QUESTIONNAIRE SYSTEM WITH DATABASE CONNECTIVITY By Ryan M. Donahue May 2002 Chair: Douglas Dankel Major Department: Computer and Information Science and Engineering Traditional paper questionnaires are still used in many situations, despite the continuous advancements in electronic data collection. In particular, medical waiting rooms utilize paper questionnaires to collect patient data. These data are manually entered into electronic storage systems so that healthcare professional, software tools, and other parties can access and process the data to assess patient risks, diagnose ailments, expedite the billing process, etc. Manual transfer of results from questionnaires to electronic storage systems is slow, tedious, and error-prone. An electronic questionnaire system could eliminate manual data entry by automating the process. Such systems already exist but none were created specifically for use in medical waiting rooms. Therefore, the existing questionnaires lack the features necessary to replace paper questionnaires in these facilities. Current questionnaires cannot store results in the legacy data storage system of a medical office because of connectivity and ix

PAGE 10

formatting issues. In addition, a desktop computer is required to display the questionnaires created by most existing systems, which makes deploying multiple questionnaires simultaneously in a waiting room unreasonably expensive. Fortunately, it is possible to implement the features that satisfy medical waiting room needs, which inspired the development of a new system called PalmQues. PalmQues is an electronic questionnaire system with database connectivity and adjustable result format enabling the storage of results in legacy data storage systems. Also, the system’s questionnaires are displayed on Palm OS devices for reasonable deployment in waiting rooms. This thesis documents the capabilities and development of the PalmQues system to illustrate the possibility of an electronic questionnaire system that possesses the necessary features for replacing the paper questionnaire in medical waiting rooms. x

PAGE 11

CHAPTER 1 INTRODUCTION Today, there are many reasons for collecting data. The task of data collection can be a daunting and extremely tedious task. This is especially true when attempting to collect data using the traditional paper questionnaire, because someone has to manually record the results from each completed questionnaire. However, the paper questionnaire is still widely used despite its deficiencies and the availability of electronic questionnaire systems. In particular, paper questionnaires are still used in medical waiting rooms. Patients arrive at a waiting room and are handed questionnaires, which the patients complete and return. Then waiting room or office personnel manually enter the results of each completed questionnaire into an electronic data storage system. Manual entry of results is slow, repetitive, and error-prone. An electronic questionnaire system could eliminate this task, by automating storage of questionnaire results. Electronic questionnaire systems do exist but medical waiting rooms have needs that the current questionnaire systems cannot fulfill. Medical waiting rooms need an electronic questionnaire system that replaces the problematic portions of the paper questionnaire process. Specifically it needs to improve questionnaire creation, questionnaire deployment, and result storage by automating these tasks. Such systems exist, but were not initially designed for medical waiting rooms use. Therefore, the existing systems lack the features necessary to replace the paper questionnaire. 1

PAGE 12

2 The existing questionnaire systems all fail to perform at least one of the following: collect respondent-specific data, store results in a legacy data storage system, and deploy questionnaires in medical waiting rooms in a cost-efficient manner. Medical waiting room questionnaires retrieve data about individual patients such as allergies, ailments, past surgeries, and family illnesses to construct medical histories about each patient. Healthcare professionals, software tools, and other parties use the medical histories to assess patient risks, make diagnoses, expedite the billing process, etc. For the data to be useful in these roles, it must be linked to the patient. Therefore, a questionnaire system used in a medical waiting room should collect-respondent specific. The system also should store the data in the existing storage system and formats. Otherwise, personnel have to learn the new the storage system and formats, and software tools must be changed to work with the new storage system and formats. Finally, most electronic questionnaire systems deploy questionnaires to the Web requiring that the transformation of the medical waiting room into a computer lab (an expensive endeavor). It is true that a Web questionnaire enables patients with Internet access to complete questionnaires before arriving at the waiting room. However, it is not reasonable to require all patients to have Internet access, so an alternative to Web deployment is necessary. In the need to improve upon the paper questionnaire and the lack of an appropriate electronic replacement, PalmQues was developed to show that it is possible to create an electronic questionnaire system improves upon the paper questionnaire process and fulfills medical waiting room needs. PalmQues is an electronic questionnaire system that improves the problems of the paper questionnaire process by automating its slow, costly,

PAGE 13

3 resource-consuming tasks. This solution system also eliminates the problems with using the existing electronic questionnaire systems in medical waiting rooms. The next chapter, Chapter 2, surveys the existing electronic questionnaire systems and reveals the problems in each one. Chapter 3 provides an overall description of the PalmQues system, its components, its fulfillment of medical waiting room needs. Chapter 4, Chapter 5, and Chapter 6 each discuss one of the three PalmQues components (the PalmQues Editor, the PalmQues Synchronizer, and the PalmQues Mobile, respectively). Chapter 7 finishes by providing a conclusion and suggestions for improving PalmQues.

PAGE 14

CHAPTER 2 SURVEY OF EXISTING QUESTIONNAIRE SYSTEMS Many systems exist with the purpose of assisting people in collecting data. The editing method, the distribution method, and the results storage technique categorize these questionnaire systems. The editing methods provided by questionnaire systems include web-based visual editors, PC resident visual editing programs, text file interpreters, and off-site services that simply take written or verbal questionnaire descriptions. The distribution method ranges from the traditional paper questionnaire to web questionnaires and deployment on PDAs.1 Saving results to files of various formats, displaying the results in reports, or writing the results to a database are the techniques for storing questionnaire results. Existing systems employ one or several techniques from each category to provide data collection assistance. Descriptions and Shortcomings of Existing Questionnaire Systems Chapter 1 claims that the existing electronic questionnaire systems fail to do at least one of the following: collect respondent-specific data, store data in pre-existing storage systems, or deploy questionnaires to waiting rooms in a cost-efficient manner. This section surveys the existing questionnaire systems and shows how each fails to perform at least one of those tasks, thus providing support for the claim in Chapter 1. Using the form in Figure 2.1, existing questionnaire systems were evaluated by their features and 1 The term PDA will is used throughout the document to include Palm OS devices, Palm PCs, and any other handheld device. 4

PAGE 15

5 how well these features meet the medical waiting room requirements. Each of the next sub-sections describes one of these systems and illustrates its shortcomings. Figure 2.1 Questionnaire System Evaluation Form SurveyMate The maker of SurveyMate describes it as an electronic questionnaire/quiz system [THI01]. The SurveyMate software resides entirely on a Palm OS device, thus the presentation medium is the device. Creating and editing questionnaires is completely text based. The user creates a text file using any word processor and adds the file to the Palm Desktop Memopad application. The file is next downloaded to the Palm OS device the next time HotSync is run. Then, from SurveyMate on the Palm OS device, the user imports the Memopad questionnaire text into SurveyMate. Of course the Memopad text

PAGE 16

6 must follow a specific format, but it is fairly simple and easy to learn. The results are collected as answer counts or answer percentages. This means that a count for each answer is incremented for each participant that selects the answer. Using a PDA such as a Palm OS device to administer questionnaires is a viable deployment method for medical waiting rooms. PDAs are relatively in expensive compared to desktop computers. Therefore, this system can deploy questionnaires to medical waiting rooms in a cost-efficient manner. However, since the results are grouped together as counts or percentages for each question, SurveyMate cannot collect respondent-specific data. Also, the system provides no method for storing results in a legacy data storage system. SurveyMate fails to perform two of the three required tasks. Professional Quest Dipolar markets Professional Quest as a tool for anyone who needs to efficiently deploy surveys and needs detailed analysis of the results [DIP02]. The demo version of Professional Quest does reveal an efficient and easy to use interface for creating and editing questionnaires. In addition, the system’s reporting tools are capable of providing excellent views of the statistical analysis of results. Another appealing aspect of the system is the many mediums available for deploying the questionnaires including paper, PC application, email, and the Web. Professional Quest is also able to collect respondent-specific data if the questionnaire includes a question asking for the respondent’s name or identification. This system provides a list of features that affectively assist in collecting and analyzing statistical data. Professional Quest, however, does not provide a solution for storing results in a legacy data storage system or for cost-efficiently displaying questionnaires in medical waiting rooms. The results can be exported to file as ASCII text, but no way of directly saving

PAGE 17

7 results to an existing storage system exists. This means that either, someone manually transfers the results or a programmer is hired to create a program that can interpret the ASCII file. Also, email questionnaires or PC applications for displaying questionnaires fare no better than a Web questionnaire in the waiting room. Email questionnaires and PC applications that can be sent to the respondent, if answered outside the waiting room, require that patients have access to a PC. If answered inside the waiting room, these deploying methods consist of equipping the waiting room with PCs, which is not cost efficient. Professional Quest fails to store data directly to a legacy data storage system and to display questionnaires on a medium that is cost efficient in medical waiting rooms. eSurvey Solutions eSurvey Solutions is an organization that provides Palm OS, phone, or Web questionnaires and result analysis to its customers [ESU01]. The steps proceed as follows for each of the available questionnaire types. In all three cases, the customer submits a survey definition to eSurvey through a Web-based service called the Survey Builder Application. The questionnaire is created from this survey definition. If the questionnaire is intended for the Palm platform, the customer then downloads a Palm application. Internet or phone questionnaires are conducted not by the customer but by eSurvey. After respondents are finished with the questionnaire the results are stored at the “Survey Reporter” database maintained by eSurvey. This happens automatically for phone and web questionnaires. For Palm questionnaires, the results are stored on the Palm OS device and are available for minimal viewing until the next time the device is synchronized. The device is synchronized with the Survey Reporter database using a Palm Pilot Internet connection. The customer then has the options to view the reports of the results and/or download a file containing the results. Possible reports include

PAGE 18

8 summaries with or without graphs, individual question reports that detail answer tendencies, and cross-tabulated reports consisting of tables showing each respondent and his or her results. The file formats available for download are SPSS, Crystal Reports, and Excel formats. eSurvey Solutions succeeds in fulfilling two of the requirements. If at least one question asks for the respondent identification, then it becomes possible to view and query the results per respondent. In addition, the option of deploying a questionnaire on a Palm OS device provides a feasible solution to administering questionnaires in a waiting room. The shortcoming of this system is that the data retrieved by questionnaires and surveys resides off site at eSurvey. It is true that the customer can download the results in file form, but as described before, to store the results in legacy data storage, a programmer must develop a program to translate and transfer the results. After review of the eSurvey Solutions services at their Web Site [ESU01], it is apparent that another system is needed. ScreenSurvey The National Research Council of Canada developed ScreenSurvey to eradicate the inefficiencies of mailing a paper questionnaire to respondents and waiting for them to respond at their own leisure [TIL95]. Their goal was to make a system for creating questionnaires that automatically administer themselves on respondents’s computer screen at predetermined times. The software system consists of five Windows programs. The FormBuilder application is a visual editing tool for easy questionnaire creation and editing. TimeSpec is an interface for specifying the time that questions are to be presented on the respondent’s computer. Questions can pop up in front of the respondent at any desired time or order, and they can be asked more than once. This way,

PAGE 19

9 researchers that are conducting studies about topics like computer use tendencies can have questions asked and answered at the appropriate times. Using the OnDemand application, one can preview the questionnaire and the question timing. The Administrator application creates small questionnaire programs that can be installed on respondents’ computers. Finally, DataSort processes the questionnaire results by organizing them for “spreadsheet or statistical analysis packages” [TIL95]. Again, here is a system that achieves its goals. It ensures that questions are answered at appropriate times. One of its secondary goals is that it eases the burden of data collection, which it does by automating the data storage and analysis. Nevertheless, does it fulfill the requirements of the patient data and waiting room scenarios? Due to limitations of the demo version of ScreenSurvey, it is unclear if the results can be viewed or queried according to respondent. It is also uncertain how the results are stored. What is certain, though, is that the system is not sufficient for deploying questionnaires in a waiting room. The only deployment method is small installable questionnaires that run on a Windows machine. As explained before, questionnaires running on PCs are not practical. Therefore, ScreenSurvey does not succeed in providing the necessary solutions needed in medical waiting rooms. The Survey System Create Research Systems describes The Survey System as “the most complete software package available for working with survey questionnaires” [CRE02]. They say it is straightforward enough for inexperience users while providing advanced features for professional researchers. One main goal behind this system is to “do the work only once” [CRE02]. The system accomplishes this by giving users the ability to reuse questionnaire instructions, questions and corresponding answers, and custom table and chart formats.

PAGE 20

10 Another main goal of the system is to provide analysis and reporting specific in nature to surveys. This goal is achieved by a reporting tool that displays results with many options for table or chart types, graph types, fonts, graphics and logos, single question tables or summary tables, and rating scales and question rankings. Optional add-on modules such as the Enhanced Tables Module, The Verbatim Module, The Voice Capture Module, and The Statistics Module satisfy many secondary goals. Each of these modules enhances the core software package to make the system useable in almost any scenario. The system is useable in almost any scenario, but not every scenario. The Survey System does not satisfy two needs. Exported text files can be translated and transferred to an existing database, but this is yet another system that neglects the need for a direct method. In addition, Web and email questionnaires are the only two deployment methods, excluding itself from use in a waiting room. Surveyor Surveyor was designed to make using it as simple as possible. This is evident in the fact that is a completely Web based service. Therefore, there is no installation or setup. Questionnaire aesthetics are completely configurable via a visual editing interface. The questionnaire is immediately available for publishing to the Web, and questionnaire results are available for viewing on the Web as soon as a respondent has finished. Additionally, the system’s database architecture is “open” [OBJ02], making it possible to integrate it with a user’s legacy data storage system. This is one of only two system evaluated with ability to directly integrate with an legacy data storage system, and its results can be queried and analyzed by respondent identification. Yet, a Web questionnaire, the Surveyor system’s only method of deployment, does not work in the waiting room. This system would work for a doctor’s

PAGE 21

11 office whose patients all have his or her own access to a computer. Since this is an obviously unreasonable expectation, Surveyor leaves something to be desired. Entryware Techneos provides three applications that comprise their Entryware questionnaire system. Survey Workbench is the core element of the system and resides on a Windows PC. It is the tool used for designing questionnaires, deploying the questionnaires to PDAs, and storing the results. The Survey Dataport application provides a smaller version of the Workbench and is used for fieldwork most likely harbored on a laptop. This application deploys questionnaires to PDAs and temporarily stores data, but does include the questionnaire design tools. Mobile Interviewer is a Palm OS application that displays the questionnaires. After a respondent has completed a questionnaire, the Mobile Interviewer is synchronized with either Survey Workbench or with Survey Dataport. Survey Workbench is also able to export the results to ASCII or SPSS2 formatted files. Clearly, Entryware can be displayed in the waiting room, since the questionnaires are displayed on Palm OS devices. Also, respondent-specific views of the results are available. Still, Entryware does not provide a direct method for storing the results in a legacy data storage system. This shortcoming means that the system does not fully satisfy every medical waiting room need. [TEC02] Inquisite Features of the Inquisite questionnaire system include centralized system administration, online survey administration, online reporting, configurable survey views, and ability to export reports to PDF [INQ02]. The questionnaire design tool is a PC2 SPSS is a statistical analysis software tool.

PAGE 22

12 based visual editor, and the questionnaires can be deployed to paper, the Web, or email. The result storage choices are either to store to file in Excel or Word format or to reports. Inquisite fails to satisfy medical the waiting room needs expressed in Chapter 1: it does not provide a direct method for storing results on an legacy data system, and its questionnaires cannot be displayed in a waiting room. Questionnaires & Analysis (QA) QA focuses on creating questionnaires that concurrently support multiple languages and statistical analysis of questionnaire results. Questionnaires are created using a Web-based visual editor called QA Design that provides a visual representation of the questionnaire structure in one frame and shows the actual published view of the questionnaire in another frame all on one page. A Web application termed QA Page Builder assists in designing the flow of the questionnaire. It allows the user to make conditional questions and answers, in which their display relies on the results of previous questions. QA Analyzer is an application for complicated analysis such as “predefined cross-tabulations and graphs for repeated surveys, and trend reports” [VIS01]. QA Data Manager is equipped with a scripting tool for transferring data to and/or from QA. It provides other functions such as verifying data validity and sorting data. This is the second of the two systems that are able to directly integrate with a legacy data storage system. The scripting tool of QA Data Manager facilitates this capability. As most of the other systems evaluated, respondent-specific data is available from the results. Also like the other systems, QA fails to fulfill medical waiting room needs because it does not provide an effective method for deploying its questionnaires in a waiting room.

PAGE 23

13 Chapter Summary This chapter described the existing questionnaire systems and demonstrated their shortcomings. Every system that was evaluated failed to perform at least one of the necessary tasks (i.e., collect respondent-specific data, store results in a legacy data storage system, and cost-efficiently deploy questionnaires to medical waiting rooms). The next four chapters describe PalmQues, which is an electronic questionnaire developed with the intent of replacing the paper questionnaire and succeeding where existing systems fall short.

PAGE 24

CHAPTER 3 PALMQUES: THE SOLUTION SYSTEM Chapter 2 demonstrates that no existing questionnaire system can replace the paper questionnaire in medical waiting rooms, because they cannot collect respondent-specific data, store results in legacy data storage systems, or appropriately present questionnaires in a waiting room environment. The development of PalmQues is an attempt to prove that it is possible to create a questionnaire system that can replace the paper questionnaire process. The Paper Questionnaire Process To develop PalmQues it was first necessary to pinpoint how a medical waiting room questionnaire system should work. The initial questions to answer are what is the process for using paper questionnaires and what are the problems with this process. The participants in the paper questionnaire process are the questionnaire designer, the questionnaire administrator, data entry clerk, and the respondents. The questionnaire designer is the person who creates and edits the questionnaires. This can be a doctor or database administrator, but must be someone knowledgeable about the data needed and where these data should be stored. The questionnaire administrator is the person who supervises the deployment of the questionnaire. Most likely this is the waiting room receptionist. The data entry clerk is responsible for entering questionnaire results into the appropriate storage location. The person who fills the questionnaire designer role or questionnaire administrator role often is also the data entry clerk. The respondents are 14

PAGE 25

15 the persons who answer the questionnaires. In a medical waiting room, the respondents are patients. Currently, the questionnaire designer decides what data about a patient the doctor or hospital needs. Once it is decided which data to collect, the questionnaire designer creates a questionnaire containing questions to obtain this data from the patient. The questionnaire is then printed and made available to the questionnaire administrator for distribution to respondents. When respondents enter the waiting room, the questionnaire administrator provides them a questionnaire, which they complete. Once finished, the respondents return the questionnaires to the questionnaire administrator. At some point, the data entry clerk manually enters the results collected from the completed questionnaires. Figure 3.1 shows how data flows through this process. The problems with using a paper questionnaire lie in changing a questionnaire and storing results. If the collection of certain data are no longer necessary, new data are needed, or it is determined that a question or answer choice is not appropriate for whatever reason, the questionnaire must be changed. The questionnaire is then reprinted and redistributed to the questionnaire administrator. This takes time and has an associated printing cost. Additionally, storing the results manually is a slow, tedious, and error-prone task. An electronic questionnaire system should provide solutions for these problems. Namely, it can eliminate the costs associated with reprinting questionnaires and decrease data entry time. In addition to solving these problems, it should adhere as closely as possible to the current process, fixing only what is not desirable.

PAGE 26

16 Manual Result Entry into Database Receptionist Patient Waiting Room Receptionist Printing Manual Questionnaire Creation/Editing Q uestionnaire Q uestionnaire Forms Q uestionnaire Forms Questionnaire Form and Results Stack of Questionnaire Forms and Results Figure 3.1 Paper Questionnaire Data Flow PalmQues System Description PalmQues is an electronic questionnaire system designed to replace the paper questionnaire in medical waiting rooms. Its data flow remains similar to that of the paper questionnaire process, but it lacks the bottlenecks and problems that occur when using a paper questionnaire. Specifically, reprinting and manual entering results have been replaced with file transfers and automatic result storage. PalmQues also overcomes some of the waiting room problems of other electronic questionnaire systems (discussed later in this chapter in Avoiding Pitfalls of Other Systems). The following sections give a complete discussion these issues.

PAGE 27

17 PalmQues Users PalmQues users consist of three of the four participants in the paper questionnaire. The participants are the questionnaire designer, the questionnaire administrator, and the respondent. The data entry clerk is no longer needed since PalmQues automates data entry. Data Flow Figure 3.2 illustrates the data flow through the PalmQues system, which is similar to that of the paper questionnaire process. PalmQues assists the questionnaire designer in creating or editing a questionnaire definition. The questionnaire definition is saved to the receptionist’s desktop. When a patient arrives, the receptionist enters the patient’s identification, connects a Palm OS device to the desktop and informs PalmQues to synchronize with the device. At this point, PalmQues checks the device for results from a previous session. If none are there, it sends the questionnaire definition along with the patient identification to the Palm OS device. Once this is complete, the receptionists hands the device to the patient. The questionnaire definition on the Palm OS device is used to display questions to the patient. The patient selects answers for each question and, once the questionnaire is completed, returns the Palm OS device to the receptionists. The receptionist again connects the Palm OS device and the desktop and informs PalmQues to synchronize. This time PalmQues finds results on the device and downloads them to desktop, where they are automatically stored in the appropriate data source.

PAGE 28

18 Questionnaire Administrator’s Deskto p Data Source Palm OS Device Questionnaire Administrator’s Desktop Assisted Questionnaire Creation/Editing Q uestionnaire Definition Q uestionnaire Definition Q uestionnaire Results Questionnaire Results Figure 3.2 PalmQues Data Flow To achieve this data flow, PalmQues is separated into three components: the PalmQues Editor, the PalmQues Synchronizer, and the PalmQues Mobile Presenter. The PalmQues Editor is responsible for assisting users in creating and editing questionnaire definitions, and does so visually. The PalmQues Synchronizer uploads questionnaires to Palm OS devices and downloads results from them. The PalmQues Mobile Presenter displays questionnaires to respondents and collects results. The data flow between components is shown in Figure 3.3. Chapter 4, Chapter 5, and Chapter 6 discuss each component (the PalmQues Editor, the PalmQues Synchronizer, and the Palm Presenter respectively) and their design issues individually.

PAGE 29

19 PalmQues Conduit Data Source PalmQues Mobile Presenter PalmQues Synchronizer PalmQues Editor Questionnaire Definition Format File Q uestionnaire Definition Q uestionnaire Results Questionnaire Results Figure 3.3 PalmQues Component Data Flow Questionnaire Definition The data flow diagrams show that the PalmQues components pass questionnaire definitions to and from each other. A questionnaire definition is a data structure that specifies how to display a questionnaire and where to store its results. Table 3.1 lists the data attributes of the questionnaire definition data structure and its subordinate data structures. Starting from the top-level, the QuestionnaireName is displayed at the beginning of the questionnaire. The SynchronizationMethod informs PalmQues to store results directly to a data source or to save them to file. The Table attribute specifies in which table to store results.

PAGE 30

20 Table 3.1 – The Questionnaire Definition Data Structure Data Structure Attributes Questionnaire Definition QuestionnaireName SynchronizationMethod Table* Question* Collection Table Name DataSourceName Column Collection Column Name Type DefaultValue Question ID ActiveStatus Type DisplayText InsertField* Collection Update* Collection Answer* Collection InsertField RowNumber ColumnName Value Update ColumnName UpdateValue WhereClause* Collection WhereClause ColumnName MatchValue Answer ID InsertField* Collection Update* Collection ActivationList * Denotes that a data attribute is itself a subordinate data structure. The Table data structure is vital to automatic data storage because it specifies the location for placing results. Its DataSourceName attribute lets PalmQues know the data source in which to find the table specified by the Name attribute. The columns in the Column Collection provide the table schema. Each column specifies the name, data type, and default value for one attribute of the table. The default value is used in constructing inserts and updates, which is discussed later. The Question data structure contains a question ID, a flag denoting whether or not the question is active at the start of the questionnaire, the question type, and the text that

PAGE 31

21 should be displayed on the Palm OS device. Questions are active or inactive when the questionnaire starts. All active questions are displayed to the user and inactive questions can be activated by events that occur during the completion of the questionnaire. The Type attribute tells PalmQues Mobile Presenter how to display the questions answers and how the respondent is allowed to select them. Type options are either “Check One” or “Check Any." The Question data structure also contains collections of InsertField, Update, and Answer data structures (these data structures are discussed in more detail later in this section). When a question is asked, the InsertField and Update collections are used for constructing results. These are important to automatic data storage because they specify what results to save and where in the table to place the results. The Answer data structure contains an ID, an InsertField collection, an Update collection, and an activation list. Similar to questions, when the answer is selected, the InsertField and Update collections are used for constructing results. The ActivationList attribute is a list of Question IDs denoting which questions to activate if the answer is selected. The InsertField data structure is used for constructing inserts that are performed when storing results to the data source. The PalmQues Mobile Presenter keeps a collection of insert rows that is empty when the questionnaire begins. When a question is asked or an answer is selected, the InsertField’s row number and the column name are used to specify a field in one of the insert rows. If the insert row with that row number does not yet exist, it is created and the value in the InsertField’s Value attribute is placed in the column specified by the ColumnName attribute with the rest of the columns filled with their default values. If the insert row does exist, the InsertField’s value is simply placed in the

PAGE 32

22 correct column of the row. When the questionnaire session is completed and the Palm OS and Desktop are synchronized, the PalmQues Synchronizer retrieves the rows from the PalmQues Mobile Presenter and inserts them into the table. (e) Insert Rows If Answer 3 of Question 4 is selected: Row Number patientID date session questionID result 1 ” “y” 2 ” “n” 3 ” “a” 4 < p atient ID> ” ” (d) Insert Rows If Question 4 Is Asked: Row Number patientID date session questionID result 1 ” “y” 2 ” “n” 3 ” “a” 4 ” NULL (c) Insert Rows Before Question 4: Row Number patientID date session questionID result 1 ” “y” 2 ” “n” 3 ” “a” (a) TABLE SCHEMA Table Name: MedicalHistory Data Source: PatientData Column Name Type Default Value patientID String date String Session Numeric questionID String NULL result String NULL (b) InsertField 1 (from Question 4) RowNumber = 4 ColumnName = questionID Value = ” InsertField 2 (from Answer 3 of Question 4) RowNumber = 4 ColumnName = result Value = “Unknown” Figure 3.5 – Insert Example Figure 3.5 is an example using a sample questionnaire to illustrate how insert rows work for a sample questionnaire. Figure 3.5(a) is the schema for the table specified by

PAGE 33

23 the sample questionnaire definition. Figure 3.5(b) shows the data of two InsertField objects. InsertField 1 is the InsertField of Question 4 of the example questionnaire, and InsertField 2 is the InsertField of the third answer of Question 4. InsertField 1 specifies that the questionID column of insert row 4 should contain the value ." InsertField 2 specifies that the result column of insert row 4 should contain the value “Unknown." Figure 3.5(c) shows the insert rows before Question 4 is asked. In other words, if the questionnaire were to end at this point, these rows would be inserted into the MedicalHistory table. If Question 4 is asked, the InsertField 1 is used to change or add to the insert rows in Figure 3.5(c). Since insert row 4 does not yet exist, it is created. The columns of the row are filled with their default values, except the questionID column. It is filled with the value ." Figure 3.5(d) shows the insert rows if Question 4 is asked. Furthermore, if the respondent selects answer 3 of Question 4, InsertField 2 is used to change or add to the insert rows of Figure 3.5(d). Since insert row 4 already exists, it does not need to be created this time. The value in the result column of insert row 4 is simply change to “Unknown” (this is the value specified by InsertField 2). Figure 3.5(c) shows the insert rows if answer 3 of Question 4 is selected. When the questionnaire is completed, the rows are inserted into the MedicalHistory table (without the row numbers). The Update data structure is used to construct updates on the table. The PalmQues Mobile Presenter keeps a list of these updates. The ColumnName and UpdateValue attributes specify a column and a value with which to update the column. The WhereClause collection is used to determine which rows in the table should be updated. Each WhereClause specifies a column and a value with which to match. The

PAGE 34

24 WhereClauses are ANDed together, so that a row is updated if each column in the WhereClauses contains the appropriate value. If a question is asked or an answer is selected the update is added to the PalmQues Mobile Presenter’s update list. Figure 3.6 – Update Example (c) Partial Snapshot of Table before Synchronization: patientID date questionID result Other patient Allergic y Past Surgery n Other patient Allergic a Other patient Past Surgery y Allergic y (b) Partial Snapshot of Table before Synchronization: patientID date questionID result Other patient Allergic y Past Surgery n Other patient Allergic a Other patient Past Surgery y Allergic y (a) UPDATE 1 (from Answer 1 of Question 5) ColumnName = date UpdateValue = WhereClauses patientID = questionID = Allergic Figure 3.6 is an example using a sample questionnaire to show how updates work. This example uses the table from Figure 3.5(a). Figure 3.6(a) shows an instance of the Update data structure. This Update instance belongs to the first answer of Question 5. It specifies that the date column should be set to the current date for every row where the patientID column contains the current respondent’s identification and the questionID column contains the value “Allergic." If the respondent selects the first answer of Question 5, then this update is applied to the MedicalHistory table when the

PAGE 35

25 questionnaire is completed. Figure 3.6(b) shows the table before the update, and Figure3.7(c) shows the table after the update. Questionnaire Definition Format (QDF) The Questionnaire Definition Format is a file format for encoding questionnaire definitions in files. The PalmQues Editor transfers questionnaire definitions to the PalmQues Synchronizer via QDF files. The Extensible Markup Language (XML) is used to define the encoding. A QDF file consists of the following XML elements: questionnaire, dbTable, columns, column, questions, question, answers, answer, results, field, update, where, text, activate, and qID. Figure 3.7 shows the Document Type Definition (DTD) for QDF documents. A DTD defines the valid elements of an XML document. A tag1 beginning with !ELEMENT denotes a valid XML element. In such a tag, the element name and a list of sub elements allowed in this element are given. A tag beginning with !ATTLIST defines the list of valid attributes for an XML element defined earlier in the DTD. An !ATTLIST tag specifies the name, data type for each attribute, and possibly a default value. It also defines whether or not the attributes are required and, optionally, limits the possible values. Table 3.3 shows the mapping between the question definitions and the equivalent XML elements defined in QDF.dtd. 1 A tag is the characters starting from and including a “<” and ending with and including a “>."

PAGE 36

26 Figure 3.7 QDF.dtd Table 3.3 does not include every XML element defined in QDF.dtd, because in some cases the XML element maps to an attribute of one of the questionnaire definition data structures. For instance, the text element maps to Text attribute of either the Question or Answer data structures. Also, the columns, questions, results, answers, and activate XML elements are used simply as containers of other elements and server no other purpose. The activate element contains qID elements which store question IDs used for activate questions.

PAGE 37

27 Table 3.3 – Mapping from Data Structure to XML Element Data Structure XML Element Questionnaire Definition questionnaire Table dbTable Column column Question question InsertField field Update update WhereClause where Answer answer To illustrate how it all comes together in a QDF file, Figure 3.8 shows the beginning portion of patient_history.qdf. The first line marks the file as an XML document. The second line specifies the DTD that is used to validate the file. The third line begins the representation of a questionnaire definition with the questionnaire XML element. This questionnaire definition defines a questionnaire named Patient History. The subordinate XML elements of the questionnaire XML element are a dbTable XML element and a questions XML element. The dbTable XML element contains the properties of the table used by the questionnaire, and the questions XML element groups together the questions of the Patient History questionnaire. The first question is an inquiry to the respondent’s gender. It is active and is a “Check One” type question, which means only one of its answers can be selected. It has an insert field and two answers. When the question is asked, the insert field is used to create insert row 1 with default values in the patientID and result columns and gender in the questionID column. The first answer has the text “Male” and an insert field. If this answer is selected the insert field is used to determine that the value in the result column of insert row 1 should be “m." The second answer has the text “Female” and an insert field. If this answer is selected the insert field is used to determine that the value in the result column of insert row 1 should be “f." When the

PAGE 38

28 questionnaire is completed, insert row 1 is inserted into the PatientInfo table of the ODBC data source named DentalDatabase. Figure 3.8 patient_history.qdf Design Issues Several design issues have system wide significance and are relevant across two or more modules. The next sections discuss these issues.

PAGE 39

29 Avoiding the Pitfalls of Other Systems Chapter 2 shows that each of the existing electronic questionnaire systems is inappropriate for medical waiting rooms because it fails to do at least one of the following: collect respondent-specific data; store results in legacy data storage systems; or appropriately present questionnaires in a waiting room environment. The ability to collect respondent-specific data is supported by requiring the respondent ID at the start of a questionnaire. A variable is available for placing result definitions; the variable is substituted with the respondent ID during automatic result storage. To store results in legacy data sources, the user can specify the data source name, table name, and table schema. Finally, to deploy questionnaires in a waiting room in a cost-efficient manner, PalmQues displays questionnaires on Palm OS devices. Ease of Implementation Maximizing ease of implementation is an import goal when developing software. It promotes the cleanest, simplest designs, which are easier for the developers to understand. The better a developer understands the design, the less likely he/she is to make mistakes. Obviously, minimizing the number of features maximizes ease of implementation, however there is a tradeoff between minimizing features and increasing usability. Therefore, there is also a tradeoff between implementation ease and usability. PalmQues is a proof of concept and not a production-level system. The intent in developing PalmQues was to prove that an electronic questionnaire system could replace the paper questionnaire in medical waiting rooms. A user must see, when using PalmQues, that it is better than the paper questionnaire process. When deciding what features to include and exclude, the following question was asked for each: “Is this feature necessary to illustrate that using PalmQues is better than using a paper

PAGE 40

30 questionnaire?” If the answer was yes, the feature was including in the system; otherwise it was not. In this way, ease of implementation was maximized without interfering with the system’s worth as a proof of concept. Platform The PalmQues Editor and the PalmQues Synchronizer were designed to run on the Microsoft Windows operating systems (NT, 2000, 98, and ME). Doing so increased the ease of implementation and increases usability of both components. Targeting the PalmQues Synchronizer for Windows was advantageous because it made the Palm Conduit Development Kit (CDK) available for use during development of the component, thus increasing implementation ease. Palm provides Windows and Mac version of the CDK for creating “plug-ins” called conduits for the HotSync Manager. The HotSync Manager is an application that orchestrates communication between applications on a Windows or Mac machine and applications on a Palm OS device. A conduit exists for each Palm application that needs to communicate with the desktop machine. The Windows version of the CDK works with Microsoft Visual C++ to provide an API of high-level communication routines, wizards, and documentation for developing conduits. The API relieves the developer of using low-level networking routines for implementing communication between desktop applications and Palm applications and the wizards generate some of the conduit code. Therefore, using the CDK to implement the PalmQues Synchronizer as a HotSync Manager conduit increases the ease of implementing the component. Targeting the PalmQues Editor for Windows increased ease of implementation by making Visual Basic available as a development tool for creating the component. The PalmQues Editor is responsible for assisting the questionnaire designer with creating and

PAGE 41

31 editing questionnaire definitions. It does so with a graphical interface to make it easier for displaying questionnaire information to the questionnaire designer. Visual Basic is a 4th generation language2 (4GL) that eases the development of graphical user interfaces (GUI) targeted for Microsoft Windows by automatically generating much of the code. Like any other 4GL, Visual Basic is appropriate “for proving an idea” (BAK00), because it eases development by requiring less from the developer. The developer, as a result, can focus more on important concepts and features. Connecting to Data Sources PalmQues can connect to any database product that is compatible with Open Database Connectivity (ODBC). Microsoft’s ODBC is an API providing a standard method for accessing databases independent of which database products are being targeted. This means that a program using ODBC does not need a separate access method for each database product that it supports. Table 3.5 provides a partial listing of the database products that are ODBC compatible. 2 Definition of 4GL: “High-level computer languages accessible to people without formal programming skills, with features such as icons, objects, help facilities, pull down menus and templates which present authors with options for every activity which they are likely to require. The software itself generates the program code required to translate these instructions into the commands which the operating system and device drivers require” [MAN02]. Microsoft Visual Basic conforms to this definition, but also allows for more traditional program development by professional programmers.

PAGE 42

32 Table 3.5 ODBC Compatible Database Products [NOR02] Adabas C ALLBASE Btrieve C-ISAM/D-ISAM CorVision DB2 Enscribe Flat files IDMS IMAGE IMS/DB Informix Ingres/Ingres II Jasmine jBASE MUMPS ObjectStore Oracle QueryObject Rdb Red Brick RMS SQL Server Sybase VSAM Apparent from Table 3.1 is the fact that supporting ODBC makes PalmQues compatible with a large number of database products. This includes the MUMPS database management system that is often used in medical facilities. Java Database Connectivity (JDBC) is another technology providing cross-DBMS connectivity and most database products that are compatible with ODBC are also compatible with JDBC. However, ODBC was chosen over JDBC to maximize ease of implementation. JDBC is advantageous when using the Java programming language, because its routines are native to Java. However, Microsoft programming languages have built-in capabilities for using Microsoft’s ODBC, but none for JDBC. Since the PalmQues Editor and the PalmQues Synchronizer were developed using Visual C++ and Visual Basic, using ODBC was simply easier than using JDBC. Specifying Data Storage Locations Conceivably, someone might want results from one questionnaire stored in multiple tables on multiple databases. However, this capability is not critical in demonstrating that PalmQues is worthy of replacing a paper questionnaire in medical waiting rooms. It is only necessary that the questionnaire designer can specify an existing table and data

PAGE 43

33 source for storing results. Therefore, PalmQues allows the user to specify one table per questionnaire. Question Types If the questionnaires are to be deployed in medical office waiting rooms on Palm OS devices, they must be as easy to use for a patient as the paper questionnaires currently administered in most waiting rooms. Inputting text into a Palm OS device is done in one of two ways. Either the user enters text by using Graffiti3 or selects characters from an on screen keyboard. Neither of these activities is trivial for people who are not familiar with Palm OS devices, and therefore a patient cannot be expected to enter text when answering questions. Questionnaire question types include check-one, check-any, open-ended text, open-ended numeric, scale, and many others. The open-ended questions, ones that require text input, are not appropriate for the waiting room because they require text input. The system does support check-one and check-any question types, which require the user to select answers from a list by tapping the appropriate answers on screen. Other question types like scale questions are appropriate for waiting room use, but are not available in the solution system since they are not necessary for proof of viability. Conditional Questions Conditional questions exist in paper questionnaires but are quite awkward and cumbersome. Usually, the text of a conditional question reads “If you answered a) in question 2” or there is a statement similar to “If you answered b) skip to question 10.” 3 Palm Graffiti associates stylus strokes with characters. When a user performs a stroke with the stylus on the appropriate area of Palm OS device’s screen, the Palm Graffiti Engine matches the stroke with the appropriate character.

PAGE 44

34 This requires unn ecessary reading by the respondent. It also means that the space used by the question is wasted if the respondent did not choose relevant answers to earlier questions. In electronic questionnaires, if the user does not answer with the appropriate response they never see the conditional question. PalmQues provides conditional questions by defining a question as active or inactive at the beginning of a questionnaire. As PalmQues Mobile Presenter traverses the list of questions, if a question is active it is displayed. When an answer is selected that activates a question later in the list, the question is marked active, and is displayed once it is reached. Chapter Summary This chapter explained how PalmQues questionnaires, user-defined result formats, and user-specified result destinations are represented, stored, and communicated between the PalmQues components. The chapter also discussed and resolved system-level design issues. Many other design and implementation issues arose during development of PalmQues, most of which were specific to one of the three components. The next three chapters discuss the execution of and design issues of the PalmQues Editor, the PalmQues Synchronizer, and the PalmQues Mobile Presenter.

PAGE 45

CHAPTER 4 THE PALMQUES EDITOR The PalmQues Editor is the component responsible for assisting the questionnaire designer in creating and editing questionnaire definitions, saving the definitions to file, and setting the active definition (refer to Questionnaire Definitions of Chapter 3). It is a Microsoft Windows application employing a graphical user interface (GUI) to assist the questionnaire designer in creating and editing a questionnaire definition. The GUI is separated into a menu bar, tool bar, questionnaire tree, general information frame, question frame, answer frame, insert field builder, and update builder. Components of the Graphical User Interface The following sections describe the major components of the PalmQues Editor GUI. The Questionnaire Tree The questionnaire tree (shown in Figure 4.1) displays each node of the current questionnaire definition, where a node either represents a question, an answer, or the top-level questionnaire properties. When a node is selected, the node’s properties are displayed to the right of the questionnaire tree in the appropriate frame for node’s type. Once a node is displayed, the questionnaire designer can edit its data. For instance, if the top-level questionnaire node is selected, the general properties frame is shown to the right of the questionnaire tree. This frame’s entries are filled with the node’s properties for the questionnaire designer to view and edit. The question frame is shown in place of the general properties frame if a question node is selected, and the answer frame is shown if an answer node is selected. 35

PAGE 46

36 Figure 4.1 – The Questionnaire Tree The Menu Bar The menu bar (shown in Figure 4.1) gives the questionnaire designer access to commands for manipulating the current questionnaire definition. The commands are “New,” “Open,” ”Save,” ”Save As,” ”Set Active Questionnaire,” ”Exit,” ”New Question,” ”New Answer,” and “Delete." The “New” command adds a questionnaire definition in the questionnaire tree. If a questionnaire definition already exists, the PalmQues Editor checks if it has been changed since it was last saved to a file. If it has, the questionnaire designer is given the option to save it, disregard the changes or cancel the “New” command. The requested action is performed and then the existing questionnaire definition is removed from the questionnaire tree so the new one can be added. Upon completion of the “New” command, the new questionnaire tree consists

PAGE 47

37 only of an empty top-level node. The “Open” command loads an existing questionnaire definition from a Questionnaire Definition Format1 (QDF) file into the questionnaire tree. It handles replacement of the current questionnaire in the same manner as the “New” command. The “Exit” command terminates the PalmQues Editor. It also handles an unsaved current questionnaire definition in the same manner as the “New” command. The “Save As” command is used for saving a questionnaire definition to a QDF file. Once invoked, the PalmQues Editor prompts the questionnaire designer for a file path denoting the file in which to save the current questionnaire definition. When the questionnaire designer is finished entering the file path, the current questionnaire is saved to the file in QDF. The “Save” command saves the current questionnaire definition to the file from which it was loaded or in which it was most recently saved. If the current questionnaire definition has never been saved before, then “Save” has the same functionality as “Save As.” The “Set Active Questionnaire” command tells the PalmQues Synchronizer (discussed in Chapter 5) which questionnaire definition to use. The PalmQues Editor does this by writing the name of the questionnaire definition’s QDF file to a configuration file. The PalmQues Synchronizer reads the configuration file to find the QDF file name and loads The PalmQues Mobile Presenter (discussed in Chapter 6) with the questionnaire definition stored in that QDF file. The “New Question” and “New Answer” commands are used to add nodes to the questionnaire tree. The “New Question” command adds an empty question node as a child of the top-level questionnaire node. If the top-level node is currently selected, the 1 Refer to the Questionnaire Definition Format section of Chapter 3.

PAGE 48

38 new question node is placed below all the other questions. If a question or one of the question’s answers is currently selected, the new question is placed directly above the selected question. The “New Answer” command adds an empty answer node as a child of the selected question node. To invoke this command, a question or answer must be selected. If a question is selected, the new answer is placed below the other answers of that question. If an answer is selected, the new answer is placed directly above the selected answer. The “Delete” command is used for deleting the currently selected node from the questionnaire tree. If a question node is selected, the question node and its answer nodes are removed from the questionnaire tree. The following question nodes are moved up. If an answer node is selected, the answer node is removed and the following answer nodes are moved up. The command is not allowed for the top-level questionnaire node. (a) The File Menu (b) The Edit Menu Figure 4.2 – The Menu Bar The Tool Bar The tool bar (shown in Figure 4.3) contains buttons for invoking a subset of the menu commands. The buttons on the toolbar invoke the “New,” “Open,” “Save,” “New Question,” “New Answer,” and “Delete” commands. On the buttons are pictures

PAGE 49

39 representing the command that each button invokes. The pictures displayed on the buttons are the standard pictures used by most Windows applications for representing these commands. Figure 4.3 – The Tool Bar The General Properties Frame The space to the right of the questionnaire tree is reserved for frames that display node information. The general properties frame (shown Figure 4.4) is displayed when the top-level questionnaire node is selected and is used for displaying and editing the top-level questionnaire properties. On this frame are entries for the questionnaire name, the synchronization method (to file or to data source), and a group of components for specifying the questionnaire’s table. The table component group consists of a “Table Name” entry, a “Database Name” entry, an “Import Table” button, a column list, and a sub-group of components for adding a column to the column list. The “Import Table” button is used to import the properties of an existing table. When the button is invoked, a list of available ODBC data sources is presented to the questionnaire designer. The questionnaire designer selects a data source and is then

PAGE 50

40 presented with a list of tables in that data source. The questionnaire designer selects a table, and the table’s properties are imported into the questionnaire definition. These properties include the table name, data source name, and a column list. Once the properties are imported they are displayed in the appropriate places on the general properties frame. If the ODBC data source containing the target table is not available at the time of creating the questionnaire definition,2 the questionnaire designer can manually define the table. When manually defining a table, the questionnaire designer must be careful to enter the names of a data source and a table exactly as they are and to enter the column information correctly to ensure that PalmQues Synchronizer is able to store the results. The column list displays the name, type, and default value of each column. Below the column list is the sub-group of components for manually adding columns to the column list. The sub-group consists of entries for the column name and default value, a list of possible column types, and a button for adding the new entry to the list. Next to the column list is a button for removing a selected column from the list. 2 Reasons for the unavailability of an ODBC data source include network problems, scheduled down time of the data source for munificence, or unscheduled down time due to error, etc.

PAGE 51

41 Figure 4.4 – The General Properties Frame The Question Frame The question frame (shown in Figure 4.5) is displayed when a question node of the questionnaire tree is selected. The frame is used for displaying and editing the properties of the correlating question. The frame has entries for the question ID, initial active status, type, and question text. It also has an entry for the text of each answer that the question has. The question text entry and the answer text entries are arranged inside a box that resembles the screen of a Palm OS device. They are arranged in the positions that the PalmQues Mobile Presenter would display them. This gives the questionnaire designer a visual preview of what the question will look like to the respondent. The question frame also contains two buttons: the “Inserts” button invokes the InsertField builder window, and the “Updates” button invokes the Updates builder window (refer to the Questionnaire Definition section of Chapter 3 for an explanation of the terms “InsertField” and “Update”). These windows are used for constructing InsertFields and Updates that the

PAGE 52

42 PalmQues Synchronizer will perform if the selected question is asked during a PalmQues Mobile Presenter questionnaire session. Figure 4.5 – The Question Frame The Answer Frame The answer frame (shown in Figure 4.6) is displayed when an answer node of the questionnaire tree is selected and is used for displaying and editing the properties of the correlating answer. The frame has an entry for the answer’s text, buttons for invoking the InsertField builder window and Update builder window, a list of all the currently inactive questions of the questionnaire, and a list of questions that will be activated if this answer is selected. There are also two buttons for adding an inactive question to the activation list and for removing a question from this list.

PAGE 53

43 Figure 4.6 – The Answer Frame The InsertField Builder The InsertField builder window (shown in Figure 4.7) is used for displaying and editing the InsertFields of a question or an answer. The InsertField builder is a modal window, which means that when invoked it takes focus from the main window of PalmQues Editor and does not relinquish focus until it is closed. The window contains an InsertField list, a button for removing InsertFields from the list, and a group of components for adding new InsertFields to the list. An InsertField list displays the insert row number, column name, and insert value of each InsertField of the selected question or selected answer. The component group for adding InsertFields consists of entries for the insert row number and the insert value, a list of available column names, and a button for adding the new InsertField.

PAGE 54

44 Figure 4.7 – The InsertField Builder Window The Update Builder The Update builder (shown is Figure 4.8) is used for displaying and editing the Updates of the selected question or answer. The Update builder is also a modal window that takes focus from the main window of the PalmQues Editor. The top half of the window contains a list of the current Updates. The Updates are displayed as text in the following format: Set ( equal to < value>) where ( = ) [and ( = )]*. In this format, is replaced by the name of a column from the table, is replaced by a value that is appropriate for the column’s type, and []* means that the text inside the [] can be repeated zero or more times. Next to the update list is a button for removing the selected Update.

PAGE 55

45 Figure 4.8 – The Update Builder Window The bottom half of the Update builder window is devoted to a wizard3 for adding updates to the list. The wizard begins with an “Add” button that when selected displays the first page, and “Back” and “Next” buttons that are displayed at the bottom of every wizard page. The “Back” button returns to the previous page, and the “Next” button displays the next page of the wizard. The first page of the wizard (shown in Figure 4.9a) has a list of column names, a “value” entry. The questionnaire designer selects a column name from the list. Then the designer enters a value to which the column should be updated. The second (shown in Figure 4.9b) has a list of where clauses, a button for removing where clauses from the list, and a group of components for adding where clauses to the list. The list displays the where clauses in the following format: = . The group of components for adding where clauses consist 3 Webopedia defines a wizard as “a utility within an application that helps you use the application to perform a particular task. For example, a ‘letter wizard’ within a word processing application would lead you through the steps of producing different types of correspondence” [WEB02].

PAGE 56

46 of a list of column names, a “value” entry, and an “Add” button. To add where clauses, the questionnaire designer selects a column name from the list, enters into the “value” entry a value that the column should match, and then invokes the “Add” button. (a) Page One of the Update Wizard (b) Page Two of the Update Wizard Figure 4.9 The Wizard Component of the Update Builder Window Graphical User Interface Style GUI styles vary in color schemes, button size and placement, button pictures, menu size and placement, and menu choices and actions. Generally, an application has higher usability if it adheres to the standards and styles of its operating environment [NIE93]. For this reason, the PalmQues Editor’s GUI was designed to follow Windows standards and styles. Developing the GUI in Visual Basic (VB) made this an easy task, since VB components’ properties defaults to Windows styles. When adding a menu to a VB application, the menu bar is initialized with the standard menus and menu options for Windows applications. The menus and menu options are

PAGE 57

47 also initialized with the standard shortcut keys for invoking them. The developer needs only to make minimal changes to the menu bar to add or remove functionality. When adding the main tool bar to a VB application, it is initialized with the standard main tool bar buttons for Windows applications. Again, the developer only needs to add or remove a few buttons to achieve the correct functionality. The color scheme of a VB application defaults to the color scheme of the “Desktop Coloring Scheme” that the Windows user selects to apply to all applications. When developing the PalmQues Editor, the VB defaults were used as often as possible to ensure that the application adheres as closely as possible to Windows standards and styles. This way, the questionnaire designer could begin using the PalmQues Editor already possessing much of the knowledge needed to find and invoke common commands. Chapter Summary This chapter explained how the PalmQues Editor works, and how the questionnaire designer uses it to create and edit questionnaire definitions. It also brought to light implementation details of the PalmQues Editor. The next chapter discusses the PalmQues Synchronizer component of the PalmQues system.

PAGE 58

CHAPTER 5 THE PALMQUES SYNCHRONIZER Students The PalmQues Synchronizer has two functions: to transfer questionnaire definitions from the PalmQues Editor to the PalmQues Mobile Presenter and to transfer questionnaire results from the PalmQues Mobile Presenter to a data source. It is implemented as a conduit for the Windows version of the HotSync Manager, which is a desktop application that coordinates synchronization between Palm applications and desktop applications. A conduit is a “plug-in” to the HotSync Manager that provides it with the tools for synchronizing a particular Palm application. The PalmQues Synchronizer is the conduit that provides the HotSync Manager with the tools for synchronizing the PalmQues Mobile Presenter (a Palm application). The PalmQues Synchronizer enables the HotSync Manager to synchronize PalmQues Mobile Presenter with the PalmQues Editor and with data sources. The PalmQues synchronizing process begins by connecting the Palm OS device running the PalmQues Mobile Presenter to a desktop machine running the PalmQues Synchronizer. The HotSync Manager is then invoked and it iterates through each Palm application that needs synchronization. When the HotSync Manager reaches the PalmQues Mobile Presenter application, it checks if there is an unsynchronized questionnaire session. If so, the HotSync Manager downloads the results from the questionnaire session and storing them in the appropriate data source. After this is done, or if no pending questionnaire session is present, the HotSync Manager uploads the active questionnaire definition along 48

PAGE 59

49 with a respondent ID, rendering the PalmQues Mobile Presenter ready for respondent use. In this context, a questionnaire session starts and ends with invoking the PalmQues Synchronizer to synchronize a Palm OS device installed with the PalmQues Mobile Pre perform. The session starts when the PalmQues Synchronizer uploads the PalmQues Mobile Presenter with a questionnaire definition. At this point, the Palm OS device is given to the respondent. The session ends when the respondent returns the device, and the PalmQues Synchronizer downloads the questionnaire results. It is often the case that the respondent will return the device before the questionnaire is completed. For example, a patient in a medical waiting room will return the device if they are called back before they have finished the questionnaire. The PalmQues Synchronizer must handle this scenario when it is invoked to synchronize the PalmQues Mobile Presenter. It does so by determining if the Palm OS device contains a pending questionnaire session. At synchronization time, a session is pending if there are any results on the Palm OS device, regardless of whether or not the current questionnaire is completed. If the PalmQues Synchronizer determines that the Palm OS device contains a pending session, it ends the session by downloading the results. Otherwise, no action is necessary to end the current session, so the new questionnaire definition is uploaded starting a new session. HotSync Manager Conduits On Windows computers, a HotSync Manager conduit is implemented as a dynamic link library (DLL). A DLL provides one or more particular functions and a program accesses these functions by creating a link to the DLL [WEB02]. For each Palm application that needs synchronization, a conduit is registered with the HotSync Manager as the conduit that provides functions or “entry points” for handling the synchronization

PAGE 60

50 of that particular Palm Application. When it is time for synchronizing the Palm application, the HotSync Manager calls the conduit’s functions. Table 5.1 shows the entry points provided by a conduit to the HotSync Manager. Some entry points are required, while others have default functionality if not defined by the conduit. Table 5.1 – HotSync Manager Conduit Entry Points [GOS00a] Required Optional File Linking (also optional) GetConduitInfo GetConduitName GetConduitVersion OpenConduit CfgConduit ConfigureConduit ConfigureSubscription ImportData SubscriptionSupported UpdateTables The PalmQues Synchronizer as a HotSync Manager Conduit The PalmQues Synchronizer provides the HotSync Manager with the required entry points, where an entry point is a function that the HotSync Manager knows about and can call. The PalmQues Synchronizer was developed using the Palm Conduit Development Kit (CDK) using Visual C++. The following sections describe the designs and Visual C++ implementations of the GetConduitInfo, GetConduitName, GetConduitVersion, and OpenConduit entry points. The GetConduitInfo Entry Point The GetConduitInfo function must be able to provide the display name of the conduit, whether the Microsoft Foundation Classes1 (MFC) were used to build the conduit, the version of MFC used, and the conduit’s default action [GOS00a]. The PalmQues Synchronizer’s GetConduitInfo function conforms to the function prototype in Figure 5.1. If the infoType parameter specifies that the conduit’s name is sought, then GetConduitInfo copies the name to the buffer pointed to by pOut, and writes 1 MFC is a hierarchy of C++ classes useful for developing Windows applications.

PAGE 61

51 the name’s size to the buffer pointed to by pdwOutSize. If the infoType parameter specifies that the MFC version is sought, then GetConduitInfo writes to the pOut buffer a value identifying that MFC is not used. If the infoType parameter specifies that the default action is sought, then GetConduitInfo writes a value to the pOut buffer identifying the conduits default action is a slow synchronization. A slow synchronization is one where every record is read from the device. Figure 5.1 – The Function Signature of GetConduitInfo [GOS00b] The GetConduitName Entry Point The PalmQues Synchronizer’s GetConduitName function is required to provide its caller with its conduit name [GOS00a]. Figure 5.2 shows the function’s prototype and describes the parameters and return values. GetConduitName provides the conduit name

PAGE 62

52 by filling the character buffer pointed to by the name parameter with a character string representing the PalmQues Synchronizer’s conduit name. Prototype: longchar* name, GetConduitName( WORD nLen); Parameters: name A pointer to a character buffer. nLen The maximum number of bytes that can be stored in the name character buffer. Result: Upon Success Returns zero. Upon Failure Returns a non-zero error code. Figure 5.2 – The Function Signature of GetConduitName [GOS00b] The GetConduitVersion Entry Point The PalmQues Synchronizer’s GetConduitVersion function is required to provide its caller with the PalmQues Synchronizer version number. Figure 5.3 shows the GetConduitVersion’s function prototype and its return value. The return value is the version number, which is formatted as follows. The conduit version number consists of a major version number and a minor version number. The major version number is incremented when major functionality or features are added. The minor version number is incremented when a small feature is added or when a bug is fixed. The data type of the return value is DWORD. Conceptually, this is a double word, where a word is two bytes. The major version number is packed into the high byte of the low word, and the minor version is packed into the low byte of the low word [GOS00a]. The Visual C++ compiler follows “little-endian” byte ordering and so the most significant (or highest byte) is to the right. Figure 5.4 shows how the version numbers are packed.

PAGE 63

53 Prototype: DWORD GetConduitVersion(); Parameters: None Result: The conduit version number Figure 5.3 – The Function Signature of GetConduitVersion [GOS00b] Return Value: Minor Major Empty Empty Byte1 Byte2 Byte3 Byte4 Figure 5.4 – The Format of the GetConduitVersion Return Value The OpenConduit Entry Point The OpenConduit entry point is the function that starts the synchronization process. Its signature is shown in Figure 5.5. Its implementation consists of four steps: (1) create an instance of the synchronizer class that performs the synchronization work, (2) call the engaging function (the function of the synchronizer instance that starts synchronization), (3) delete the instance, and (4) return a value indicating whether synchronization was successful or not. The synchronizer class is called QuestionnaireSync. Prototype: long OpenConduit(PROGRESSFN pFn, CsyncProperties& syncPrefs); Parameters: pFn A pointer to a function that reports progress. syncPrefs Specifies the current synchronization properties. Result: Upon Success Returns zero. Upon Failure Returns a non-zero error code. Figure 5.5 – The Function Signature of OpenConduit [GOS00b]

PAGE 64

54 The QuestionnaireSync Class The QuestionnaireSync C++ class uploads the questionnaire definitions and downloads results to and from the PalmQues Mobile Presenter. Its constructor has no parameters, and its engaging function (the function that begins the synchronization process) is called perform with the prototype long perform(). The perform function first determines if there is a pending questionnaire session on the Palm OS device. If not, it reads a configuration file to determine the active QDF file and the new respondent’s identification. It then interprets the QDF file and uploads the questionnaire definition and respondent’s identification to the PalmQues Mobile Presenter. If there is a pending questionnaire session, the perform function downloads the results and deletes them from the Palm OS device. Information specifying a table and its data source is in the results. Once the results are downloaded, the perform function stores results in the specified table. Interpreting QDF Files Recall that QDF files are XML documents, and that Microsoft programming languages provide tools for easily parsing XML documents. In particular, the Visual Basic XML parser is straightforward to use, and therefore, the QuestionnaireSync class uses it for extracting questionnaire definitions from the QDF files. The Visual C++ QuestionnaireSync class employs the Component Object Model2 (COM) to incorporate the Visual Basic XML parser into the conduit built with Visual C++. A Visual Basic class called Questionnaire was created and built into a DLL. Upon instance creation, the Questionnaire class constructor uses the Visual Basic XML parser 2 “The Component Object Model (COM) enables programmers to develop objects that can be accessed by any COM-compliant application” [WEB02].

PAGE 65

55 to extract a questionnaire definition from a specified QDF file. The PalmQues Synchronizer imports the Questionnaire class from the DLL so that the QuestionnaireSync class can use it. The Visual C++ QuestionnaireSync class uses COM to create an instance of the Visual Basic Questionnaire class and uses the instance’s COM interface to access the stored questionnaire definition. Uploading a Questionnaire Definition Memory on a Palm OS device is managed in “databases." A Palm OS database is simply a list of records where a record is data stored in any format. The applications must know how a record is formatted and how to interpret that format. The PalmQues Mobile Presenter uses one database to store the current questionnaire definition in a plain text format. The QuestionnaireSync class knows this format and writes a questionnaire definition to the questionnaire definition database on the Palm OS using this format. The Conduit Development Kit (CDK) provides functions for communicating with a Palm OS device. This includes functions for opening, closing and writing records to a Palm OS database. The QuestionnaireSync class uses these functions to write the questionnaire definition to the questionnaire definition Palm OS database. Storing Results In addition to the questionnaire definition database, the PalmQues Mobile Presenter stores questionnaire results in another database. The QuestionnaireSync knows the record format in which results are stored and uses this format to decipher results as it downloads them from the Palm OS device. To download the results, it uses the open, close, and read records functions provided by the CDK. Among the results are the data source name and table name for storing the results. The QuestionnaireSync uses ODBC functions for storing results in the table. First using

PAGE 66

56 the data source name, it opens a connection with the ODBC data source. Then, it constructs SQL statements from the results. It submits the SQL statements to the specified table in the data source and closes the connection. Chapter Summary This chapter described the responsibilities and activities of the PalmQues Synchronizer component of the PalmQues system. It gave details about the component’s implementation as a HotSync Manager conduit. The next chapter gives a discussion about the PalmQues Mobile Presenter component of the PalmQues system.

PAGE 67

CHAPTER 6 PALMQUES MOBILE PRESENTER This PalmQues Mobile Presenter is the PalmQues component that displays questionnaires to respondents and tracks respondent’s answers. Use of this component begins when the questionnaire administrator hands a Palm OS device to the respondent (refer to Figure 3.2 for an illustration of each component’s role in the data flow of the PalmQues system). The Palm OS device is loaded with the PalmQues Mobile Presenter, the respondent’s identification, and a questionnaire definition (the term “questionnaire definition” is explained in the Questionnaire Definition section of Chapter 3). The PalmQues Mobile Presenter starts with a welcoming message and a “Begin” button. When the respondent taps the “Begin” button, the questionnaire session begins and the first question is displayed. The question’s text can be multiple lines and is displayed in the top half of the question screen. An answer’s text is limited to a single line, and the text of up to five answers is displayed vertically in the bottom half of the screen. To the left of each answer’s text is a check box. An answer’s selection state is displayed by a check in the check box if it is selected and no check if it is not selected. Selecting an answer is slightly different depending on the type of question. If the question is a check-one type of question, only one answer can be selected at a time. When the user taps an answer’s check box, the answer is selected regardless of its current state and all other answers are deselected. If the question is a check-any type of question, the selection state of the answer is toggled. (i.e., if the answer 57

PAGE 68

58 is currently selected then it is deselected, and if the answer is currently not selected, then it is selected.) The selection states of the other answers are not changed. Two buttons lie in the top right corner of the question screen, and are labeled “Help” and “Next." Tapping the “Help” button cause the PalmQues Mobile Presenter to replace the current question screen with a help screen. This help screen, explains to the respondent how to select answers. On the help screen is a button labeled “OK” that when tapped returns the respondent to the current question screen. The “Next” button on the current question screen prompts the PalmQues Mobile Presenter to display the next question. Before displaying the next question, the PalmQues Mobile presenter stores the current question’s results in a Palm OS database. The results consist of InsertFields and Updates of the question and of any selected answer (the terms “InsertField” and “Update” are defined and explained in the Questionnaire Definition section of Chapter 3). Once the results are stored, the next question is displayed. Result storage is discussed later in the chapter. When the respondent taps the “Next” button of the last question, the PalmQues Mobile Presenter displays a finished screen. This screen thanks the respondent for their time and instructs them to return the Palm OS device to the receptionist. The finished screen cannot be exited until the PalmQues Synchronizer downloads the results (Chapter 5 gives an in-depth discussion of the PalmQues Synchronizer). Palm Applications Some Palm application characteristics need clarification before discussing the design and implementation details of the PalmQues Mobile Presenter: namely, the Palm memory management and application launch and exit need to be explained.

PAGE 69

59 Palm Memory Management The basic building blocks of memory on a Palm OS device are the card, heap, chunk, database, and record [BEY01b]. A card refers to a physical memory module. Currently the maximum number of cards that a Palm OS device can have is two (the internal card and one in an expansion slot that many new devices now offer). Heaps are contiguous areas of memory used to maintain smaller chunks of memory. The memory manager reserves space for one dynamic or volatile heap with the rest of the memory divided among nonvolatile heaps (note: versions 3.0 and higher of the Palm OS are implemented to contain only one large nonvolatile heap). The dynamic heap is used for global variables, system dynamic allocations, application stacks, temporary memory allocations, and application dynamic allocations. This heap is reinitialized upon soft resets. The nonvolatile heaps are used for storing data that must persist through soft reset cycles. This part of the memory is analogous to a computer’s file system. Chunks are pieces of memory residing in the heaps. A chunk can be either movable or immovable. If a chunk is a movable, the memory manager can move it elsewhere to minimize memory fragmentation. If a chunk is immovable, then the memory manager is unable to move it. Generally, the memory manager allocates movable chunks at the front of a heap and immovable chunks at the end of heap. When allocating an immovable chunk, the application is given a pointer to the chunk. The application can use this pointer to read from and write to the chunk. This, however, is not possible for movable chunks, because a chunk pointer would become invalid when the memory manager moved the chunk. The memory manager copes with this problem by keeping a movable chunk table at the beginning of each heap. The table contains the current pointer for each chunk, which is updated whenever a chunk

PAGE 70

60 is moved. When an application allocates a movable chunk, it is given the index to the movable chunk table entry that containing a pointer to the newly created chunk. This table index is known as a chunk handle. When the application is ready to work with the chunk, it uses the chunk handle to retrieve the chunk pointer. The chunk is then locked so that the memory manager does not move it. The application reads from or writes to the chunk. When finished, the application unlocks the chunk so the memory manager can move it. The database concept is used to simplify the use of the nonvolatile heaps. A database is a collection of records, where a record is a movable memory chunk. Records can be dispersed throughout the available memory. To track each record, a database maintains a table of record entries. Each record entry stores the local ID, attributes, and a unique ID for that record. The local ID is the offset from the movable chunk table, and is used for locating the record. When allocating, reading, writing, or de-allocating dynamic memory, an application normally uses functions provided by the memory manager. When working with a database, an application usually uses functions provided by the data manager or resource manager. The manager functions protect an application from the details of memory management. This is useful for keeping an application compatible with many versions of the Palm OS. As long as this functional interface remains the same, an application will work on a newer Palm OS version that implements memory management differently than a previous version. Palm Application Launch and Exit Palm applications do not launch and exit the way like computer applications. A Palm application is launched with several launch codes describing the context in which it was

PAGE 71

61 launched. An application is only exited when another application is started. A convention in Palm applications is that each application is restarted in the same state that it was in when it was last exited. This requires applications to save state information just before they exit. Questionnaire Definition Storage When the PalmQues Synchronizer uploads a questionnaire definition to the Palm OS device, it places the questionnaire definition in a Palm database called QuestDB. General questionnaire information and the table information are stored in the header of the QuestDB database. Each question is stored in a record of the Palm database. The PalmQues Mobile Presenter accesses the questionnaire definition through the QuestDB database. For each new question, the PalmQues Mobile Presenter reads the question’s record to determine the type and text of the question and the text of each answer. This information is then used to display the question on screen and to control answer selection (which depends on the question type). Result Storage When downloading questionnaire results from the Palm OS device to the computer, the PalmQues Synchronizer reads these results from a Palm database called ResultsDB. The PalmQues Mobile Presenter writes the results in this Palm database as the questionnaire is completed. At the beginning of a questionnaire session, the destination table information is copied from the QuestDB header to the ResultsDB header. The PalmQues Synchronizer (on the main computer) uses this table information to determine which data source to transfer results into from the ResultsDB Palm database. Individual results are written to the ResultsDB Palm database each time the respondent taps the “Next” button on a question screen. From the question’s QuestDB record, the PalmQues

PAGE 72

62 Mobile Presenter extracts the InsertFields and Updates of the question and of any selected answer. Once extracted, the InsertFields and Updates are stored as records in the ResultsDB database. The first byte in each record marks the record as an InsertField or as an Update. The PalmQues Synchronizer uses these records of InsertFields and Updates to modify the table specified in the Results DB header. Chapter Summary This chapter explained how the PalmQues Mobile Presenter displays questionnaires. It also clarified how it tracks respondents’ answers and made them available to the PalmQues Synchronizer for download to the main computer. The next chapter makes some final conclusions and gives suggestions for improving the PalmQues electronic questionnaire system stating them as extensions to this project.

PAGE 73

CHAPTER 7 CONLUSIONS AND FUTURE RESEARCH The goal behind developing PalmQues was to show that it is possible to create an electronic questionnaire system that could replace the traditional paper questionnaire process currently existing in medical waiting rooms. This goal came about because of the deficiencies of the paper questionnaire and the lack of an existing electronic questionnaire system that adequately improved upon the paper questionnaire. The problem with the paper questionnaire surfaces when storing respondents’ answers. Often the answers are stored electronically for used by computer applications. Currently, someone must manually enter the answers into the electronic data storage, which can be a time consuming, repetitive, and error-prone task. An electronic questionnaire system could automate answer storage, therefore improving the process of collecting data from respondents. After surveying the existing electronic questionnaire systems, it became apparent that none were suitable for medical waiting rooms. In particular, every system neglected at least one of the following areas: collecting respondent-specific data, storing questionnaire results in legacy data storage systems, or appropriately presenting the questionnaire in a waiting room environment. In a medical office, a patients questionnaire results must be linked to the patient to be useful. Therefore, a system that cannot collect respondent-specific data is of no use in a medical waiting room. A system that cannot store questionnaire results in a pre-exiting data storage system cannot automate the data storage task (the reason for replacing the paper questionnaire). Finally, the system must 63

PAGE 74

64 be able to present a questionnaire to a patient in the waiting room in a cost-efficient manner. The use of many of the existing questionnaire systems would require the conversion of a waiting room into a computer lab filled with terminals displaying a questionnaire. PalmQues fulfills its goal by linking a respondent’s identification with their results, providing connectivity to ODBC data sources, using the connectivity to automate data storage, deploying questionnaires on Palm OS devices, and otherwise adhering closely to the elements of the currently functioning paper questionnaire process. While completion of the development of PalmQues satisfies its initial goal, it does not prove that the system’s targeted users will accept it (the targeted users are the current participants in the paper questionnaire process described in Chapter 3). This point illustrates the necessity for future research and work. First, additional research is needed to study the use of PalmQues in a real world scenario. The goal of the study would be to determine users’ acceptance of the PalmQues. Specifically, questionnaire designers should be surveyed about the PalmQues editor, the questionnaire administrators should be surveyed about the PalmQues Synchronizer, and respondents should be surveyed about the PalmQues Mobile Presenter. Each component survey should determine the user’s thoughts about the component’s usability, functionality, total value, and needed improvements. Other areas for future research consist of additions to PalmQues that would improve its functionality. The most intriguing and difficult of these additions is incorporating questionnaire design knowledge into the PalmQues Editor to assist the questionnaire designer choose question types, question order, and question text. This project involves

PAGE 75

65 collaborating with a questionnaire design expert, collecting knowledge from the expert, and incorporating the knowledge into the PalmQues Editor. Another possible addition to the PalmQues Editor is visual editing of each question screen. In other words, the questionnaire designer would have the ability to drag components (question text, answer text, etc) onto the screen and place them in their desired position. This would improve the current inflexibility of the question building process. More additions to the PalmQues Editor include a help system, the ability to move questions or answers in the questionnaire tree, the ability to copy questions or answers, and additional question types. Improvements to the PalmQues Synchronizer include making use of the file linking and logging utilities available to the HotSync Manager conduits and adding the ability to select whether to download results or upload a questionnaire. The HotSync Manager file linking utilities provide conduits with methods for manipulating files on the desktop. Currently, the PalmQues Synchronizer does not use these utilities for reading QDF files, which it should do to simplify its execution. The PalmQues Synchronizer also does not take advantage of the HotSync Manager’s built-in logging utilities, but instead writes messages to its own log file. If it used the logging utilities it could write messages to the HotSync Manager log, which is shown to the user when synchronization is complete. Currently, the questionnaire administrator is not able to choose to download results or upload a questionnaire. If there are pending results on the Palm OS device, the PalmQues Synchronizer automatically downloads them. If there are no results, the currently active questionnaire definition is uploaded to the Palm OS device. These restrictions are in place because the PalmQues Mobile Presenter can only sustain one questionnaire definition and store the results for one questionnaire session. Therefore,

PAGE 76

66 providing the questionnaire administrator with ability to choose the synchronization action, means improvements must first be made to the PalmQues Mobile Presenter. Specifically, these improvements include maintaining results from multiple sessions, sustaining multiple questionnaire definitions, and allowing the questionnaire definition to be selected at the start of a session. Finally, the addition of a component called the PalmQues Web Presenter would allow patients to respond to questionnaires remotely. The PalmQues Web Presenter would generate a Web questionnaire from a questionnaire definition stored in a QDF file. This way, if patients have Internet access, they can choose to answer questionnaires before they arrive at the waiting room. In light of these suggestions for further research, it is apparent that much needs to be done to improve the functionality of PalmQues, and to prove that the targeted users will accept PalmQues as a useable and viable replacement of the paper questionnaire process in medical waiting rooms. However, PalmQues accomplishes its goal in that it proves that an electronic questionnaire system intended to replace the paper questionnaire process can be created.

PAGE 77

LIST OF REFERENCES [BEY01a] Bey, C., Freeman, E., Hillerson, G., Ostrem, J., Rodriguez, R., Wilson, G., Dugger, M., “Palm OS Programmer’s Companion,” Document Number 3004-005. Palm, Inc., Santa Clara, CA, July 2001. [BEY01b] Bey, C., Freeman, E., Hillerson, G., Ostrem, J., Rodriguez, R., Wilson, G., “Palm OS Programmer’s API Reference,” Document Number 3003-004. Palm, Inc., Santa Clara, CA, July 2001. [CRE02] Creative Research Systems, “The Survey System,” April 24, 2002, http://www.surveysystem.com/bro.htm . [DIP02] Dipolar, “Professional Quest Release 2.2,” April 24, 2002, http://www.dipolar.com.au/ . [ESU01] eSurvey Solutions, Inc., “eSurvey Solutions,” April 24, 2002, http://www.esurveysolutions.com/ . [GAL93] Galitz, W. O., User-Interface Screen Design. QED Publishing Group, Boston, 1993. [GOS00a] Gossett, B., “Conduit Programmer’s Companion for Windows,” Document Number 3013-001. Palm Computing, Inc., Santa Clara, CA, January 2000. [GOS00b] Gossett, B., “Conduit Programmer’s Reference for Windows,” Document Number 3012-001. Palm Computing, Inc., Santa Clara, CA, January 2000. [GRE85] Green, P. E., Electronic Questionnaire Design and Analysis with CAPPA. Scientific Press, Palo Alto, 1985 [HOW96] Howlett, V., Visual Interface Design for Windows: Effective User Interfaces for Windows 95, Windows NT, and Windows 3.1. Wiley, New York, 1996. [INQ02] Inquisite, “Product Overview,” April 24, 2002, http://www.inquisite.com/Products/ProductOverview/default.asp . 67

PAGE 78

68 [JOH89] Johnson, G., Ravden, S., Evaluating Usability of Human Computer Interfaces. Ellis Horwood Limited, Chichester, West Sussex, UK, 1989. [LAU90] Laurel, B., The Art of Human-Computer Interface Design. Addison-Wesley Publishing Co, Reading, MA, 1990. [MAN02] Mante, “Mante: Manchester Telematics Explained," April 24, 2002, http://www.poptel.org.uk/mante/index.html . [MYK00] Mykland, R., Palm OS Programming from the Ground Up. Osborne/McGraw-Hill, Berkeley, 2000. [NIE93] Nielson, J., Usability Engineering. Academic Press, San Diego, 1993. [NOR02] North, K., “ODBC Drivers, Servers, and Vendors, “ January 2002, http://ourworld.compuserve.com/homepages/Ken_North/odbcvend.htm . [OBJ02] ObjectPlanet, Inc., “Surveyor Online Survey Software," 2002, http://www.objectplanet.com/Surveyor . [RUB88] Rubin, T., User Interface Design for Computer Systems. Halsted Press, New York, 1988. [TEC02] Techneos, “Techneos Systems: Entryware Products,” April 24, 2002, http://www.techneos.com/prodindex.html [TIL95] Tiller, D., “Computer Based Questionnaire Software,” April 24, 2002, http://mat.gsia.cmu.edu/GROUP95B/0082.html . [THI01] thinkingBytes, “SurveyMate,” April 24, 2002 , http://www.thinkingbytes.com/products/surveymate.asp . [UNI83] United States Federal Committee on Statistical Methodology Subcommittee on Questionnaire Design, Approaches to Developing Questionnaires. Statistical Policy Office, Office of Information and Regulator Affairs, Office of Management and Budget, Washington, DC, 1983. [VIS01] VisualSoftware, “QA – Survey Software,” April 24, 2002, http://www.visualsoftware.fi/uk/ . [WEB02] Webopedia, “Online Dictionary for Computer and Internet Terms,” http://www.pcwebopedia.com/ , April 24, 2002. [ZIM98] Zimmerman, M. W., Microsoft Visual Basic 6.0 Programmer’s Guide. Microsoft Press, Redmond, WA, 1998.

PAGE 79

BIOGRAPHICAL SKETCH Ryan M. Donahue was born on September 27, 1977, in Des Moines, IA. In May of 1999 he earned a Bachelor of Science degree from Widener University, where he majored in computer science and minored in mathematics. He enrolled at the University of Florida in August 1999 to pursue a Master of Science degree in computer engineering and will complete the degree in May 2002. In May 2000, he joined Velara Software and continues employment there as the lead test engineer and tool developer. 69