Issue No. 02 - April-June (2006 vol. 5)
DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/MPRV.2006.41
Kaushik Ghosh , Human Factors International
Tapan S. Parikh , University of Washington
Researchers have thoroughly explored computer-supported cooperative work (CSCW) over the past two decades. However, most of this research has focused on supporting users in the developed world who are voluntarily collaborating on a computing task. In India and elsewhere in the developing world, for all except the richest (and most westernized) individuals, cooperation is a requirement rather than an option for most computing interactions. Human-computer interaction in the developing world is a complex relationship between technology, multiple users, indirect stakeholders, observers, and bystanders.
Multiuser interaction scenarios are common in India for many reasons. According to Geert Hofstede's cultural indices, India is a collectivist society, inherently prone to group orientations toward tasks (see www.geert-hofstede.com/hofstede_india.shtml). Different social norms of privacy mean that interaction in public (or even private) places is often subject to external observation and intervention. Access to technology is limited because of its expense in comparison with people's incomes. Without the luxury of a personal computer at home, users must access information resources in public places such as cybercafes, schools, or community information centers. For users with limited education or literacy, direct access to a user interface might not even be feasible.
Many users in India, especially those from disadvantaged classes, have only partial or no physical access to computing devices. We refer to these users as secondary users to distinguish them from the primary users that the interface design process traditionally considers. Secondary users must interact with information resources via a proxy primary user who has the required access rights and skills. The proxy's filtering and funneling decisions limit the secondary users' information-seeking behavior; the secondary user might also have an unequal power relationship with the proxy. Therefore, secondary users might never know the full scope of actions and knowledge available to them. If we are to realize the egalitarian potential of computing, we must consider secondary users in the design process. We must develop technologies that recognize the needs and aspirations of all classes of users, including those without direct access to the user interface. In fact, by designing user interfaces explicitly supporting intermediated tasks, both primary and secondary users can benefit.
The Indian context
Several cultural and economic factors contribute to the prevalence of multiuser and intermediated information tasks in India. (For more information on multiuser computing in general, see the sidebar.)
India's collectivist cultural norms are reflected in its low individualism index, according to Hofstede's cultural rankings. Countries with high individualism, such as the United States, attribute great importance to individuality and individual achievement. In contrast, interpersonal relationships and collective approaches to work and life mark countries with low individuality indices. This is reflected in the close-knit structure of rural Indian villages and the importance of the joint family system throughout India, where many people from an extended family share the same small (by Western standards) living space. Family businesses are also common, with extended family members even having intimate knowledge of one another's personal finances. 1
An individual's sense of privacy can be limited or even nonexistent in these close living and working circumstances. Ponnurangam Kumaraguru and Lorrie Cranor observed "an overall lack of awareness of privacy issues" among Indian IT professionals compared to those in the United States. 1 Given the general lack of personal or private spaces, it's not surprising that most interaction with technology in India, whether via radio, television, mobile phone, or computer, is a shared user experience.
Another Indian cultural trait Hofstede notes is a high power-distance index. This indicates a "high level of inequality of power and wealth within the society." This gap can exist between social groups, between the rich and the poor, between genders, and within the same social group or family. People in such societies sometimes also display a diminished tendency to question or contradict those they perceive to be in control. As a result, when dealing with technology in a group setting, those in lower power positions are unlikely to intervene on their own behalf, exacerbating access inequalities.
The hesitation to question those in power might also indicate a general resistance to change within the society. For this reason, technology adoption in India often happens alongside existing processes. We talked to one bank branch manager who had been encouraging his clients to visit a nearby ATM in an effort to improve the branch's efficiency. Still, many clients continued to come to the branch, even though it took significant additional time. According to the manager, clients were comfortable in their existing banking patterns and enjoyed the opportunity to meet the teller in person. In India, labor is cheap and abundant, and human interaction is an expected part of many services.
According to the CIA World Factbook ( www.cia.gov/cia/publications/factbook/geos/in.html), India has a population of over 1 billion people, 25 percent of whom are living below the poverty line. Under these conditions, it's neither advisable nor possible for every person to have a personal computing device. Except for the rich and the upper-middle class, people must share technology within a social group, such as a village or a family. Public access is also common, such as at the many community information centers that governmental and nongovernmental agencies have established in rural areas, or at private cybercafes in cities.
According to the CIA, over 40 percent of the Indian population is illiterate. Disparities between the rich and the poor and between urban and rural areas, compounded by the limitations of public education and the necessity of child labor, have concentrated illiteracy in disadvantaged communities. For uneducated or illiterate users, intermediation is a requirement for many information and technology-related tasks.
A taxonomy of intermediated information tasks
We created a taxonomy of intermediated information tasks from observed usage scenarios in India. We categorized our taxonomy according to the intermediation level—the degree to which a secondary user has direct access to the computing device.
Cooperative interaction occurs when numerous users gather around a single device with equal (or near equal) access to the interface. The interface might not originally have been designed to support such copresent collaboration. In such cases, users must share input in an ad hoc manner, either by taking turns or by delegating responsibilities.
This scenario is common in schools and with children, where users cluster around an available device and negotiate usage rights. For example, we observed this scenario during a field trip to the Hole-in-the-Wall project ( www.hole-in-the-wall.com), where unmanned PC kiosks are placed in slums and school playgrounds for the local children to use (see figure 1a). We noticed how students playing educational games delegated operation of the keyboard, trackball input device, and buttons to different users. By explicitly providing interface features supporting delegation to multiple users, we can reinforce this positive cooperative experience at an early age.
In a cooperative scenario, one or several users can sometimes dominate the others. This can be because of an existing power relationship between the users, or because some users aren't confident or adept at using the interface.
Dominated interaction occurs in many public places, such as cybercafes or railway information kiosks, where one user voluntarily defers to another in achieving some mutual task (see figure 1b). However, being dominated involuntarily can result in a diminished user experience. Joyojeet Pal studied the seating positions of students sharing a computer at Indian primary schools. He documented a statistically significant correlation between each student's seating position relative to the front of the computer and their performance and family affluence. 2
In intermediated interaction, the secondary user must conduct a task without direct access to the device (see figure 1c). Although the task is often relevant to both the secondary user and the proxy, only the proxy directly touches the device. This could be because the technology belongs to the proxy (or the proxy's employer) or because the secondary user isn't capable of using the system independently. The secondary user can, however, observe the proxy's interaction with the device.
This is a common model for community kiosks—PCs installed in a village or town for community use. A kiosk operator manages and operates the kiosk. Villagers come to the kiosk and pay the operator a fee for accessing information, such as the weather, farm prices, information about government schemes, and communications from friends and relatives. The operator interacts with the computer to find the information. The results might be visible to both, but the operator can still verbally convey the information if the secondary user is illiterate. The operator also prints a copy of the result that the user can confirm later (with help if needed). However, secondary users have limited flexibility in information seeking and a limited appreciation of the total scope of information available. Moreover, they must trust the proxy to enter the right query, convey the full results, and safeguard their privacy.
Indirect interaction is similar to the intermediated scenario, except that the secondary user can't observe the primary user's input or the system's output (see figure 1d). The interface is oriented to give access and feedback only to the primary user. A physical barrier might even separate the secondary user from the locus of interaction.
Reserving a railway ticket in India is a perfect example of indirect use. The computerized schedule and seating data are only accessible to the enquiry agent who is trying to find an available train berth. Automated information kiosks are becoming available in larger cities, but inexperienced technology users (such as the poor and uneducated) aren't comfortable using them. These customers must find an available train through verbal queries mediated by the enquiry agent. Making multiple queries is difficult given the encroachment of others in the line. After finding a suitable train, customers must fill out a paper seat-request form and wait in line for an available booking agent. The entire process might take more than an hour (see figure 2).
Conducting transactions at a bank branch follows a similar model. The bank teller communicates with customers while accessing their account information using a computer. Customers must pass requests to the teller using paper transaction slips reinforced by verbal instructions. They might not know what other information is available, nor what data the teller is entering. The teller passes feedback to the customer in the form of paper receipts, statements, and other documents the system produces. In fact, in both of these scenarios, paper is a key interface mechanism between primary and secondary users.
We've conducted some early experiments investigating a sample intermediated information task. By taking into consideration intermediation's effects on this example application, we hope to improve the user experience for both primary and secondary users.
The task we evaluated consisted of capturing transactions from microfinance group meetings. Many microfinance groups in India are organized as self-help groups. SHGs have regular weekly or monthly meetings where members conduct different kinds of transactions, such as savings deposits, withdrawals, loans, and loan repayments. We're in the process of designing a mobile phone-based system for capturing data from SHGs. 3 Nongovernmental organizations (NGOs) use the transaction data to monitor the groups' performance, and banks use it to judge the groups' suitability for receiving additional loans. In our system, each transaction is recorded as a receipt or a voucher. The member keeps one copy, and the group keeps the other. During the meeting or within a few days, an NGO staff member will come to collect this data for the institution's records.
In our mobile phone-based system, the user takes a picture of a sequence of barcodes on the receipt or voucher with a camera-equipped mobile phone. This launches a set of voice-accompanied prompts for entering data from the document. The user enters the group and member identification numbers and the transaction amount. The system sends this data to the institution's server. This is an example of an intermediated information task, with the field staff as the primary user and the group members as secondary users. Group members must be vigilant to ensure that the primary user enters the correct data. They're also unaware of other information that might be available to them through the device.
Design for the primary user
In the first experiment, we were interested in intermediation's effect on a novice primary user's performance. We initially observed that in a group context, observers continually provided guidance, encouragement, and even physical assistance to the individual using the system. We wanted to assess the effect of this external participation on the primary user's performance.
We included 14 participants in the evaluation (all women—all SHG members and most staff in this institution are female). All of the participants were field staff working for our partner NGO in rural Tamil Nadu, India. The participants' educational backgrounds ranged from 5th to 10th grade. They had limited experience in using technological devices—only four of them had used a mobile phone, and none had ever used a computer. All of them regularly used landline telephones and calculators.
We conducted this experiment in the NGO field office. We asked each user to record numerous transactions using the mobile phone while the rest of the participants (and some random passersby) watched. In the group condition, observers were free to encourage the subject as best they could (we discouraged direct intervention). In the individual condition, the user interacted with the system independently without observer guidance. This situation would be rare in practice, but it was important for us to evaluate it as a baseline.
Each trial consisted of capturing a fixed number of transactions. We recorded the total execution time with a stopwatch and counted the number of errors (inaccurate data entry or erroneous input). Efficiency and accuracy are both important performance factors for this application, as each field staff member must visit numerous groups daily to record meeting transactions. Moreover, because we explicitly asked each user to complete the task as fast as possible, we can take their performance as a general indicator of their distraction level during the experiment. Table 1 shows the results.
The users in the individual condition performed the task significantly faster (p < 0.1) and with significantly fewer errors (p < 0.1) than those in the group condition. Although these are preliminary results, it appears that, at least for these users, the presence of observers proved detrimental or distracting. Given Indian society's collective nature and the lack of personal or private spaces, this has important ramifications for novice rural knowledge workers' productivity. Finding ways to improve primary user concentration in the presence of external distractions could improve the situation. However, any changes to the interface would have to consider the social context and the perspective of secondary users.
Design for the secondary user
We accompanied NGO staff to five microfinance group meetings in local villages. Initially, the groups conducted the meetings normally. The field staff member recorded their transactions manually in their individual passbooks, in the group ledger, and in either a receipt or a voucher. The passbook is an individual paper record of transactions, while the ledger is an aggregated group record. These two artifacts represent the main personal and communal (respectively) trusted records documenting each meeting's events. After the meeting, we told the groups that a staff member would use a mobile phone to capture the records, send them to the NGO head office, and later deliver a printed report that would substitute for the ledger.
The staff member captured all the receipts and vouchers generated during the meeting. As the staff member entered data, voice prompts indicated the field the system was processing. These prompts were audible to both the primary and secondary users. After the form was completed, the staff member uploaded the data to a server application running on a colocated laptop. We videotaped the entire session to capture the members' reactions and comments. The video was later transcribed and translated to English from the native Tamil.
At various points in the process, we asked the group members questions to gauge their understanding. First, we asked whether they trusted that their data was being captured accurately. Almost all of the members said that they trusted the system. However, when we questioned them further, several responded:
"The person recording the data should be competent.""If she enters the right amount, it will be right and we have no problems.""It is a matter of the integrity of the person entering the data. We have nothing to say in it, we are illiterate, we can only sign [the documents]."
These quotes make it clear that their trust was vested with the staff person and not the system: The groups all had long relationships with the staff, who regularly helped them obtain loans from banks, mediated disputes, and managed the group's financial records. This trust was necessary, because few elements of the user interface provided direct feedback to the secondary users. It was obvious that most of them couldn't see the screen or what the staff member was typing. This was in contrast to the previous practice; using the paper ledgers, almost everyone could see (if not read) what the staff member was writing.
One element that did improve their awareness was the audible prompting. Initially, the group members had no idea what the staff person was doing, especially with a still rare and expensive technology. By hearing the names of fields as the staff person entered them, the group members felt comfortable that at least the correct process was being executed. Most group members mentioned the voice prompts as their only way of understanding what the primary user was doing. However, because we hadn't implemented a text-to-speech engine, the system didn't audibly repeat each field's value. Several group members pointed this out as a deficiency in the system. As one member said, "(In our group) there are some literates, some illiterates … (for the illiterates) it is good if they can hear the mobile phone speak the numbers."
This reflects the group's collectivist nature in safeguarding all members' interests. When we asked them whether that might compromise their transactions' privacy, they laughed. They replied that the SHG's structure implied that all members know the values of other members' transactions.
Almost all group members wanted to immediately introduce the new system. However, when we asked if that meant that we could eliminate the manually aggregated records (the ledger and the passbook), the members were more hesitant. They weren't willing to replace important paper artifacts until they confirmed that the new system achieved the same purpose.
Q: So are all of you willing to use the new system, or do you want to use the old system?
A: The new system is good. We trust the system. The only thing is that we should keep the passbook and the receipt should be issued.
Q: Will you use the new system?
A: We will use the ledger until we understand the system.
Q: So are you willing to use the mobile phone and get rid of the ledgers?
A: Until and unless we completely understand this system, we want to continue using the ledgers.
In two of the villages, we carried a printer to the village to print a report that listed all the group transactions. After we showed this report to the members, they agreed to discontinue using the ledger. They were happy to be spared the effort of manually preparing the ledger accounts and financial statements. This report would serve as a communally trusted and accessible paper record. They trusted that the staff person would bring this report regularly. However, because we hadn't shown a replacement for the member passbook, they insisted on retaining it. Until the system could generate a locally kept paper analog to replace every record, the group members were unwilling to trust their personal records only to electronic data capture and storage. Even within the communal SHG, individual members had to safeguard their interests.
We must consider several issues when designing for intermediated interaction scenarios in India and elsewhere in the developing world.
Cooperative vs. dominated interaction
If cooperative interaction is the goal, we must observe points where domination is occurring (or could occur) and provide mechanisms supporting more equitable access. We can do this by including turn-taking and other delegation techniques explicitly in the application. If domination is unavoidable because of device limitations or user inexperience, including an explicit intermediated element in the application can often help support secondary user requirements. For example, in an educational game where many children will clamor for the mouse, include a section where one student must navigate through the story while explaining it and getting feedback from the others.
Intermediated and indirect interaction
In intermediated or indirect scenarios, we must explicitly consider the secondary user's perspective. Providing process feedback to secondary users (either via audio or some other means) increases their awareness of and trust in the process. The interface between the primary and secondary user—that is, the methods by which they exchange information and specify actions to be performed—must also be clearly demarcated. If it's not, the secondary users' existing relationships with the primary user can define their access. This increases the potential for bias and corruption. Also, attending to secondary user queries can unnecessarily distract the primary user, adversely affecting performance.
As we observed in the railway, bank, and microfinance examples, paper provides a time-tested interface mechanism between primary and secondary users. By designing forms for queries, we can clearly define the functions available to the secondary user. This limits the potential for preferential treatment by the primary user. The secondary user prepares the query (with help if needed) and delivers it to the primary user, who then should be free to execute it without interference or distraction. A printed copy of the result provides a permanent, verifiable record. Using paper for input and output formalizes the interface for secondary users and can increase their flexibility and confidence in the overall process.
Expanding access to computing to India and elsewhere in the developing world requires effectively supporting intermediated interaction. As we've documented, the experience of a user interface is very different for primary and secondary users in intermediated tasks. Improving secondary users' awareness of the primary user's actions can help them understand the process, gain confidence in the system, and know the functions available to them. A secondary user's trust in a system will be based on the entire workflow, rather than a narrow conception of the technology and the user interface. Still, their primary confidence will reside with the information resources that they own and retain.
Using paper as an interface addresses many of these design requirements. Since the days of punch cards, paper has served as an effective way of sharing limited computing resources. In the future, we plan to build on our work linking paper to modern computing systems to further empower and reassure secondary users involved in intermediated information tasks.
Thanks to Paul Javid for recording video and participating in early discussions and to James Landay for pointing out the importance of considering self-help-group members in the design process. ekgaon technologies and the Covenant Centre for Development in Madurai, India, helped coordinate the field studies. Thanks to the women of the Mahakalasm SHG Federations for their participation.
Tapan S. Parikh is a PhD candidate in computer science at the University of Washington. His research focuses on developing practical and accessible technologies serving the needs of rural communities. He's working on the CAM project, a scalable, accessible mobile information services framework for serving disconnected rural communities around the world. His earlier research projects have included the Hisaab project, investigating user interface design for semiliterate rural users, and the Knownet-Grin project, a grassroots information network linking rural innovators and entrepreneurs. He received his MS in computer science from the University of Washington. Contact him at the Univ. of Washington, Dept. of Computer Science, Box 352350, Seattle, WA 98195-2350; email@example.com.
Kaushik Ghosh is a communication design professional. His research interests include development informatics, empathic user research, sustainable innovation, public technology policy, and technology diffusion. He has worked for and in collaboration with Human Factors International, Media Lab Asia, HP Labs Asia, and Intel Research. He received his bachelor's degree in user-centered design and research from the National Institute of Design in Ahmedabad, India. He's a member of the West India chapter of ACM SIGCHI and has been program head for the Indo-European Systems Usability Partnership. Contact him at 4th Floor, Chemtex House, Main St., Hiranandani Gardens, Powai, Mumbai 400 076, India; firstname.lastname@example.org.