Mobile Phones and Paper Documents: Evaluating A New Approach for Capturing Micro? nance Data in Rural India Tapan Parikh, Paul Javid Sasikumar K. Department of CSE ekgaon technologies Univ. of Washington Madurai, India tapan,[email protected]
washington. edu [email protected] com Kaushik Ghosh Human Factors India Mumbai, India [email protected] com ABSTRACT CAM is a user interface toolkit that allows a cameraequipped mobile phone to interact with paper documents. It is designed to automate inef? cient, paper-intensive information processes in the developing world.In this paper we present a usability evaluation of an application built using CAM for collecting data from micro? nance groups in rural India. This application serves an important and immediate need in the micro? nance industry. Our quantitative results show that the user interface is ef? cient, accurate and can quickly be learned by rural users.
The results were competitive with an equivalent PC-based UI. Qualitatively, the interface was found easy to use by almost all users. This shows that, with a properly designed user interface, mobile phones can be a preferred platform for many rural computing applications.Voice feedback and numeric data entry were particularly well-received by users. We are conducting a pilot of this application with 400 micro? nance groups in India. Author Keywords Mobile phones have been cited as the most likely modern digital tool to support economic development in underdeveloped regions . As shown in the example of Grameen Phone , if a phone is shared by a group of people, it can be afforded by even the poorest communities.
For rural computing applications, a mobile phone has inherent advantages over a PC in terms of cost, portability and familiarity to users. Previously, we conducted a design experiment with micro? ance groups in rural India . We observed that paper plays an important role in group record-keeping. We demonstrated that a user interface based on graphical icons, voice feedback in the local language, and numeric data entry was well-suited for rural users that were new to computing and who may be functionally illiterate. We have implemented these guidelines in CAM, a mobile phone user interface toolkit designed to automate inef? cient, paperintensive information processes in India and elsewhere in the rural developing world .
In this paper we present an instantiation and usability evaluation of CAM for a speci? application — collecting data from rural micro? nance groups in India. Mobile user interfaces are frequently cited as less usable than PC interfaces due to their limited screen size and input capabilities . Our quantitative results show that a CAM-based user interface is ef? cient, accurate, can quickly be learned by rural users, and is competitive with an equivalent web-based UI on a PC. Qualitatively, CAM was described as easy to use by almost all users.
This justi? es our design and shows that, with a properly designed user interface, mobile phones can be a viable platform for many rural computing applications.Based on this successful evaluation, we are planning a pilot implementation of CAM with 400 micro? nance groups near Madurai, Tamil Nadu, India. THE CAM INTERFACE paper user interface, visual codes, document processing, mobile phone, micro? nance, rural development, ICT ACM Classi? cation Keywords H5. 2. Information interfaces and presentation (e.
g. , HCI): User Interfaces. INTRODUCTION Micro? nance is the provision of ? nancial services to poor, disadvantaged and under-served communities. Including services such as loans, savings and insurance, micro? nance is an effective tool for enabling sustainable local socioeconomic development.One of the biggest challenges facing micro? nance service providers, particularly in rural areas of the developing world, is implementing a Management Information System (MIS) that can interface with a large number of clients across a region with unreliable physical infrastructure (communication, power, transport, etc. ) .
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for pro? t or commercial advantage and that copies bear this notice and the full citation on the ? rst page.To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior speci? c permission and/or a fee. CHI 2006, April 22-27, 2006, Montr? al, Qu? bec, Canada. e e Copyright 2006 ACM 1-59593-178-3/06/0004.
.. $5. 00. CAM is a user interface toolkit that allows a cameraequipped mobile phone to interact with paper documents containing visual codes — two-dimensional data glyphs that can be recognized and decoded from a camera image . Visual codes serve as references to interactive multimedia functions — allowing the user to enter data, review values and communicate with a remote database.CAM is designed to link inef? cient, paper-intensive processes to online information systems.
associated code, which brings up a dialog window. When a set of input codes is clicked together, their respective dialogs are displayed in sequence. • Buttons — Once the user has transcribed all of the form ? elds, the user can submit the data to the server. To do this the user clicks on the Submit button, seen at the bottom of Figure 2. The second button is for refreshing the displayed data from the server, and the third is for deleting the database record corresponding to this form instance. CamShell Figure 1. The CamBrowser application.
The current value for the ? eld is displayed beside the visual code. CamBrowser The CAM client application is called the CamBrowser, and has been implemented for phones based on Nokia’s Series 60 platform. CamBrowser acts like a virtual window and one-button mouse for paper documents. A phone’s physical interface is limited to a small screen, a 12-button numeric keypad and some soft-keys. By recognizing visual codes using the phone’s camera, this interface can be extended to a nearly in? nite number of widgets situated in the real world.
For code recognition we are using the software developed by Rohs and Gfeller .We have re-packaged the recognition functionality and compiled it as a stand-alone library. Other researchers have presented a rich set of interactions made possible by tilting, rotating and translating the camera relative to an individual visual code . However, it also has been observed that most of these interactions were not accessible to novice users . In CAM, we have simpli? ed the interaction to two primitives.
The user scans codes by moving the view? nder over visual codes in real time, or clicks codes by taking a high-resolution image using the joystick button.Our aim was to design a simple and intuitive interaction model with well-de? ned affordances between actions. CamForms CamShell is the API used to specify interaction with visual codes. Each visual code invokes a distinct callback function when it is clicked or scanned. These functions are programmed in a XML-based scripting language that includes support for function calls, control ? ow, arithmetic and basic datatypes . Each callback contains a number of sequential actions, some of which may be executed conditionally. This can be used for data validation.For a scan callback, the value returned by the function is displayed on the screen.
This is used to display the value entered for a ? eld, the result of some calculation or the name of the form or button. An example callback function is shown below: seq = input_int(“Please input Form ID”); if (! seq) return false; uri = “http://abc. com/reload. php? ” . “seq=”. seq; return http_get(uri); CamShell provides an API for accessing the mobile phone’s features. Example API functions include launching a user dialog, recording an audio clip, saving an image, making an HTTP request or sending an SMS message.
Every action can be accompanied by voice and graphical prompts. By using audio, images and numeric data entry, CAM applications can be localized even if the phone’s operating system does not support the target language. APPLICATION BACKGROUND CamForms are paper documents containing visual codes. An example CamForm is shown in Figure 2. CamForms are organized in the following canonical sections: • Header — The user begins interacting with a form by clicking on the header (located at the top of Figure 2). The header visual codes identify the form type and instance to the CamBrowser.
Depending on the form, the browser may then automatically display a sequence of dialogs for transcribing the hand-written values using the keypad (as in the shortcut code discussed later in this paper). • Input Codes — Input codes are like HTML input tags. They are co-located with form ? elds (located in the middle of the form in Figure 2). When the user scans an input code, the current value is shown on the screen. This can either be what the user had entered, or the result of some calculation.
To edit the ? eld, the user clicks on the In this section we introduce the target application — collecting data from Self-help Groups (SHGs).SHGs are a kind of autonomous micro? nance group prevalent in India. There are estimated to be more than 1 million SHGs in India, with a total membership of more than 15 million (90% of whom are women). This constitutes one of the largest and fastest growing micro? nance activities in the world. SHGs are supported by Self-Help Group Promoting Institutions (SHPIs).
While most SHPIs are non-pro? t NonGovernmental Organizations (NGOs), some are government agencies, commercial banks, farmers cooperatives, or even private individuals. SHPIs employ ? eld staff to form and train groups.Field staff are recruited from villages and rural areas near the districts where they will work. They usually have at least a partial high school education and are paid a small salary or commission per group.
in Tamil Nadu. Field staff will be equipped with a mobile phone to record member-level transactions. CamForms will be printed in bulk and physically distributed to ? eld staff and groups. Transactions will be entered on the phone using the CamBrowser application, at the time of the meeting, or afterward from the paper records. This data will be posted to an on-line server via an SMS message.
The resulting reports and ? ancial statements will be printed from a secure access point, or faxed from the NGO head of? ce to the ? eld of? ce, from where they will be picked up by the group or delivered by the staff. These reports will be used by the group for monitoring their portfolio and applying for loans and other services. Less common documentation requiring textual data entry (such as registering a new group or submitting a group loan application) will be faxed to the head of? ce, where the data will be entered by a trained local language data entry operator. If the image resolution is suf? cient, we can use the mobile phone camera to transfer these documents.USABILITY TESTING Figure 2. An example CamForm, showing the three sections the user interacts with. An SHG consists of between 10-20 members.
While the education level and af? uence of members varies by group, most are very poor and minimally educated or literate (if at all). SHGs accumulate pools of money through their own savings. Eventually they can also access loans from banks and other commercial institutions. This money is redistributed within the group as loans, to be repaid with interest at regularly scheduled group meetings. Mature SHGs are expected to document their own meetings and manage their internal accounts and lending.If none of the members is capable, a local educated person or schoolgoing child is enlisted as the SHG accountant. However, most SHGs are still not able to produce ? nancial statements and lending reports. They have inadequate accounting controls and systems for monitoring risk in the loan portfolio.
Embezzlement, loan delinquency and mis-management are common. Therefore banks and other lenders ? nd it dif? cult to assess SHGs’ stability and ? nancial history when considering loan applications. Even for ? eld staff with a basic education, the current accounting and documentation processes are onerous.
For the past two years we have been working with a NGO based in Tamil Nadu, India to make the SHGs’ paper-based accounting processes simpler and easier to learn. Even using this simpli? ed system, it has taken over six months to train ? eld staff to produce basic reports and statements. These are still inconsistently prepared, and errors are frequent. If we handle accounting and report preparation automatically, it would dramatically reduce the workload of ? eld staff, and improve the ef? ciency and transparency of SHGs. Currently, very few SHPIs have succeeded in computerizing at the SHG level.
We have developed an application using CAM for collecting data from SHGs. We are planning a pilot of this application in partnership with the same NGO In this section we present a usability evaluation of CAM as a mobile user interface for capturing SHG records. The results will help us determine whether CAM meets the performance, accuracy and accessibility requirements for this application. We also compare the CAM interface to web-based data entry on a PC. While we do not expect CAM to be more ef? cient, we can determine if it is a viable alternative given the phone’s other advantages in cost, portability and familiarity.The quantitative experiment consisted of a set of timed user trials measuring the speed and accuracy of data entry using CAM. Ease of learning and recall were assessed by repeating the experiment over a period of four days, followed by another test ? ve to twelve days later. Qualitative data was collected on the basis of self-report questionnaires, spot polls, informal feedback, and direct observation.
User Group The subjects in our user study were the staff from two NGO ? eld of? ces that are participating in the pilot. All of the subjects were educated rural women from the Indian state of Tamil Nadu.In the Pulvoikarai ? eld of? ce, the education ranged from 8th to 12th grade completion, with an average of 9. 7 years of education. In the Natham ? eld of? ce, the women averaged 11. 9 years of education. A group of Computer Science graduate students were tested in Seattle, WA as a benchmark for experienced technology users.
Group Pulvoikarai Natham Seattle Users 6 8 9 Avg Age 27. 8 22. 4 26. 6 Avg Educ. 9. 7 11. 9 18+ M 0 0 5 F 6 8 4 Table 1.
Basic demographics for each of the user groups. While all of the Tamil Nadu users were literate and could perform arithmetic, they had very little technology exposure.Some had participated in our earlier experiments . In Natham, a few had been using drawing applications on a Avg Exec Time Per Receipt (secs) recently purchased of? ce computer. This had conferred the important skill of using the mouse.
In Pulvoikarai only one of the women had previous PC experience. All had used phones before, either mobile or landline. All of the staff used calculators for their current accounting tasks.
120 110 100 90 80 70 60 50 40 30 20 10 1 2 Day Number 3 4 CAM-Pulvoikarai WEB-Pulvoikarai CAM-Natham WEB-Natham CAM-Seattle WEB-SeattleTask Description The task we evaluated was recording the payments made by one group member during a meeting. Following accounting convention, this transaction was recorded as a group receipt. The design of the receipt is shown in Figure 2 (translated to English from Tamil). The receipt includes input codes for the Date, Member ID, Savings, Interest and Principal Repayment amounts.
The Total is auto-calculated and displayed upon scanning. Buttons are included for submitting or reloading the data from the database or for voiding the transaction.We measured the execution time and error rate for entering and submitting four receipts in sequence. We used a Nokia model 6600 phone running the CamBrowser application. The paper receipts were pre-populated with written values for each ? eld. The user had to capture an image of the header plus each of the input codes — either together or in sequence. Each input code brought up a prompt to enter the value of the ? eld. The prompts were displayed in Tamil (as a bitmap since the phone did not have a Tamil font installed), accompanied by Tamil audio indicating the name of the ? ld.
The data entry was all numeric (member identity was recorded as a numeric ID). After entering all the values, the user captured the ‘Submit’ code to post the transaction to the web server. For the purpose of this experiment, the web server was running on a laptop connected to the phone via a bluetooth connection. The use of the application was explained and demonstrated to each of the users on the ? rst day, after which they were given up to ten minutes to practice. On subsequent days the practice period was limited to 2-3 practice trials.
After the task, the data on the server was reviewed to determine if there had been any errors. Each database value different from what was written on the paper form was considered one error. Execution time was measured by an observer with a stopwatch, from when the user focused the phone camera on the form until when the data for the fourth receipt had been received by the server.
To compare these results to PC-based data entry, each user performed the same task using a similarly designed web form. This test was conducted using a Sony Vaio laptop with an attached USB mouse.The same receipts and written values were used. The user had to enter one more three-digit value — the sequence number of the particular receipt instance (embedded within the visual code in the header for the CAM version).
When the user submitted the form, the data was posted to a server running on the same laptop. The order of the two variations was counter-balanced and randomized. The test was repeated each day for four days (three for the Seattle users). Figure 3. Graph showing average execution time (per receipt) on each day for the basic variations. CAM performance is comparable to the WEB for Tamil Nadu users.
The standard deviation was high on the ? rst day, especially in Pulvoikarai (73 sec. for CAM, 72 for WEB), but then stabilized (7-11 sec. by the last day for all conditions). Ef? ciency and Learnability Figure 3 shows that CAM was learned effectively by all user groups within a three day period.
In Pulvoikarai, CAM performed equally well to the Web alternative. In Natham, CAM performed only slightly worse (averaging 10% to 12% slower). In neither case was the last-day difference statistically signi? cant. In contrast, the Seattle users performed the task much faster with the Web variation (p