Issue
Article
Vol.30 No.2, April 1998
Article
Issue
Issue |
Article |
Vol.30 No.2, April 1998 |
Article |
Issue |
To broaden the reach of effective computing support into new environments requires different technologies from those we are accustomed to designing and using. One of the key aspects of the India Healthcare Project is to confront unfamiliar conditions and contexts in order to prototype effective hand-held computing support for rural Indian healthcare workers. The project involves introducing a technology relatively new to us (Newton), with unfamiliar characteristics (size, display, pen-input), to a community of users with which we were initially totally unfamiliar, doing a job about which we knew virtually nothing. Additionally, we needed to localize Newton software and the MessagePad hardware for Indian languages and physical conditions. In this paper, we lay out the challenges associated with such an undertaking, the strategies we have adopted, the current chronology of the project, some aspects of our current design, and our preliminary findings from field testing.
Introduction
The charter of research organizations includes both investigation of new technologies and designing and testing of new technologies in new situations. Both of these have been central to the India Healthcare Project in Apple's Advanced Technology Group (ATG). Its potential users are Indian rural healthcare workers, currently providing primary healthcare and collecting population and other health-related data. They are unfamiliar with computer and related technologies and in fact rely on a technological and social infrastructure very different from what is familiar to us, as designers and users ourselves. The project we have undertaken is to investigate whether and how a Newton-based data collection and performance support tool could aid these workers in their jobs and increase the effectiveness of the healthcare system as a consequence.
The scope of this article covers the background of the project, its research goals, and its overall chronology, emphasizing how we have approached and tried to resolve challenges relating to the varieties of unfamiliar conditions and contexts running throughout the project. We will discuss some of those conditions and contexts in a section on the project's challenges.
This article will lay out the basics of the project, its challenges, and its goals. Some very important aspects are excluded. Those include the importance of ATG's partnership in the project with the research and development branch of CMC, Ltd. in India, specific features of the prototype interface, and the methods and lessons learned from field testing.
The Government of India (GOI) administers a vast rural healthcare system, with a deep, hierarchical administration. The system provides healthcare for the country's rural population of about 630 million people, by 1991 census figures [Bulletin, 1995], spread among 32 states. This system is distinguished from a private, primarily urban system.
At the top of the hierarchy is the government's Health Minister, and at the bottom are village-based workers known as Auxiliary Nurse Midwives (ANMs). Each ANM is, by design, charged with administering to a population of 5,000, spread over several villages and hamlets.
Figure 1: The Government of India's Rural Healthcare Reporting Structure
The government had initially expressed interest in providing portable, laptop computers to the rural healthcare workers. However, in meeting with Apple representatives, the Health Ministry became intrigued with the capabilities of the Newton MessagePad. Relevant advantages of the Newton included lower cost, relatively long-term battery power, pen-input, and mobility. In order to provide a true solution for the healthcare system, though, investigation, prototyping, and testing were critical. Additionally, Newton would have to be localized for Indian languages and physical environments.
Given how vast, intricate and dynamic the healthcare system is, we needed an entry point into the system, a point from which we could begin to build an adequate understanding of specific, supportable activities. In accordance with the government's initial interest in supporting the healthcare workers in the field, we adopted a grassroots strategy, to begin by observing and working with the bottom rung of the system, the ANMs. The ANM's job requires that she (ANMs are exclusively women) visit the houses falling within her responsibilities once per month. She operates out of a Subcenter, usually in or near one of the villages she serves. Often other villages and hamlets she covers lie a number of miles away. She collects demographic data and administers immunization, family welfare, and mother-child health programs.
The Government of India recommended a field site in the state of Rajasthan in mid-northern India, centered on the city of Ajmer. Their thinking was that this site was representative of a large number of sites throughout India, where the problems regarding literacy and technological infrastructure were neither so great as to guarantee failure nor so little as to guarantee success. They wanted to test the project in a place from which we could learn about requirements and chances for success in other parts of the country as well.
Figure 2: The State of Rajasthan, India
We decided that the project must be undertaken with partners within India. During the initial study period we would need to call on help regarding familiarity and access to healthcare personnel, facilities, and the villages themselves. Also, over the long run, we felt that a solution for the healthcare workers was outside the scope of what we could provide. Our charter as members of a research lab does not include providing such large-scale commercial solutions, and, moreover, to provide such a solution in this case would require long term, continuous presence study, maintenance, and localization. We decided that the model we should follow was one in which we carried the project through an investigation, prototyping, and testing stage, while at the same time developing a partnership with an Indian research and development company who could at some point take over the project and deliver a solution.
The two partners we chose are the Center for Diffusion of Information Technology (CDIT) and CMC, Ltd. CDIT, headquartered in Delhi, could provide coordination and communication with the government, familiarity with the healthcare reporting structure, and introductions to local healthcare personnel in Rajasthan. CMC has done extensive work in development of computer technology for public systems in India, including an innovative railway ticketing project. They could provide engineers to learn Newton and Macintosh technology, an existing field maintenance organization, and an established research and development center in Hyderabad.
Additionally, as the project has unfolded, we have worked with the National Institute of Design (NID) in Ahmedabad. A student from NID has served as an intern on the project, providing a more continuous field presence than we could provide ourselves.
Within ATG, we decided that, given our lack of familiarity with the healthcare system and the region itself, an extensive study period would be necessary in order to determine the social and technological context in which we would be working and to determine basic facts about the healthcare system and the job of the ANM. Before designing anything, we needed to know what the existing system is, how it works, what its perceived problems are, and to get a feel for the rural culture into which it all must fit. We would address these needs with a series of visits and field investigations, beginning in the fall of 1994. In the meantime, we could begin to investigate some known technical challenges, such as familiarizing ourselves with the Newton platform and learning how non-Roman languages might be supported on it.
The India Healthcare Project began in the fall and winter of 1994 with some preliminary visits and investigations of the healthcare system in Rajasthan. Principals from the Advanced Technology Group included Rao Machiraju, the project's originator from Apple's side, Sally Grisedale, interface design and field studies, and Mike Tschudy, field studies. Soon afterward, Mike Graves joined the team as engineering lead and eventual project manager, along with Alexander Grünsteidl, interface design, and Chris Burmester, software engineer. Also from Apple's side, Apple Pacific provided needed help for getting the project off the ground.
The goals of the project extend through several scopes and perspectives.
For the healthcare system:
For Apple:
Many of the challenges for the project team revolved naturally around cultural and language differences. We are working with unfamiliar factors and contexts on all sides -- culture, geography, multiple languages and the public healthcare system itself. What is more, at the outset of the project, we were not familiar with the capabilities and limitations of the Newton platform. In fact, the starkness and scope of all that was unfamiliar may have given us some advantage. We knew that whatever assumptions we approached the design issues with were most likely false.
To get a perspective on all of these challenges, we'll divide them up into culture/language challenges, technological ones, and broader social challenges.
India's people speak a wide variety of languages. This includes not only fifteen distinct official languages, but a much greater variance from locality to locality based on dialects. According to one source, there are 325 dialects of various languages spoken in India [Silveira, 1995]. In the village of Narwar, within our study site, the dialect of Hindi spoken and written varies markedly from the Hindi spoken and written in the city of Delhi. Our initial confidence in translators to provide proper interface equivalents in Hindi for our English terms was based on ignorance of this variation in dialect. Our Newton-based prototypes needed to support the Hindi spoken by healthcare workers in the District of Ajmer, including the village of Narwar and others, but in principle also the other languages spoken by other ANMs in other districts, as well as English, a kind of common denominator for the healthcare system. At the higher levels of the healthcare hierarchy, the current paper-based system is English-based. At the village level, it is in the language spoken by the villagers and ANMs, although not in their own local dialect. We have found that, in the current system, local language differences sometimes account for ANMs' not collecting data needed by the government -- they simply don't understand some of the forms given them to work with.
The written forms of these languages require ten different scripts. Hindi is written in Devanagari script, but other languages, such as Telugu, require other scripts. And, of course, none of the scripts is made up of Roman characters, like English.
Working in a foreign culture of course carries its own challenges. We needed help in such basic activities as transportation and finding places to eat and sleep. All of our interviews and other communications with ANMs took place through interpreters. We were unaware of sensitivities, customs, and expectations on the part of the ANMs and the villagers they served. We could not count on ourselves to be able to notice, for instance, when an ANM might be voicing an opinion politely, but conveying a strong message nevertheless. And since none of us had any direct experience with the rural healthcare program itself, we could only accept, in the beginning, official descriptions of how it functions.
Much of our lack of cultural familiarity extends even to the Indian members of our team and the engineers and staff of CMC in India. Most do not come from rural areas, and none come from the rural area where the study was located. In addition, differences of education and economic status produce between what is familiar and the rural culture a gulf that is wide, albeit not quite so wide as that between native westerners and the village populations. This is a critical point for any work in such settings that have not been reached by the computer industry. Even `native' developers, ones from the country or even the region within the country in which we are working, are likely to be unfamiliar with the culture of the populations for which they are asked to develop technology.
Finally, we should note that, in addition to standard work-at-a-distance challenges (time differences, unreliable or limited communications infrastructures, etc.), we met differences between the outlook, practices, and goals of Indian technology companies and engineers, working in a different economy and a different technological market, and those of us at Apple, with our own individual and collective interests and practices. To expand adequately on that issue would require a dedicated paper or article.
We've noted above the challenges set by multiple Indian languages, dialects and scripts. The Newton operating system does not itself provide support for any of those languages other than English. And we did not attempt to develop handwriting recognition for Hindi. Thus, one formidable challenge was providing support for display and input of Hindi text, while laying the groundwork for extending support to other Indian languages and scripts. Additionally, we needed to develop a system that could be customized to accommodate local differences in dialect and vocabulary without requiring high-level engineering skills.
Apart from any differences of culture or language, the project involves fitting an effective technological support system into an existing person and paper-based healthcare system. We had to provide something truly useful to the ANM and the government structure she is part of. This meant understanding her job, both in its formal report and data driven aspects and in its more subtle aspects involving social interactions with villagers, gaining their trust, and providing the right kind of service and information at the right time.
While it is tempting to say that the ANMs lack a technological infrastructure or technological literacy, they do have their own technological environment. Many do not come from the villages they serve, but rather live in cities, where stereos, televisions, and fax machines are common. In the Subcenter where they work, though, they do not typically have telephone or electricity. They possess enviable knowledge of how to use public transportation systems, bicycles, mopeds, etc. to travel the distances they need to travel, and they have great facility with the accustomed procedures and tools of their trade -- their registers, diaries, ante-natal care practices, immunization materials, and so on. Our prototypes need to fit into the composition of their technological world. The Newton-based device will perhaps sit alongside the ANM's hand-written diary and immunization cards, with information passing from one to the other. Much of this fit, as we confirmed, could not be designed in advance but must be worked out through an evolutionary process. This involves not only passing from a paper-based reporting system to an electronic one, but also combining computer-based practices with the more accustomed current practices of the ANMs. Their skills and current effectiveness should be magnified rather than simply supplanted by the new support technology.
Figure 3: ANM entering data into one of her official register
Figure 4: Rural landscape in Rajasthan
Lastly, we needed to fit the Newton-based device into the physical environment of rural India. The study site is located in a desert region, with temperatures reaching above 120 degrees Fahrenheit, above the Newton MessagePad's recommended limits. Dust is everywhere and could find its way into the edges of the MessagePad's screen and into its exposed ports. Seasonal monsoon rains make some sort of waterproofing necessary. And as mentioned above, there are few electrical outlets in which an ANM might charge the MessagePad's batteries.Broad Social and Practical Challenges
Technological innovations often change the practices of the people who use them in unpredictable ways [Tenner, 1996]. And they can also change the roles and relationships of people working together [Rosenberg, 1992]. We have identified several areas for special attention.
One potential success of the project would be providing a way for information to flow much more easily in both directions within the healthcare hierarchy than is now possible. ANMs' monthly reports can be generated automatically (a process now done by hand and sometimes requiring up to two days). Those reports can be uploaded to desktop or server machines and compiled automatically with reports of other ANMs (a job now also done by hand, by the ANMs' Supervisors). And those compiled reports can likewise be uploaded and compiled into larger data sets automatically. All of that potentially relieves ANMs, Supervisors, and especially the person known as a `Computor' at the Primary Health Centre of much currently hand-done paperwork. What will be the effects? Will the structure change? Will roles change? Once in electronic form, data can be analyzed and visualized quickly in standard and perhaps ad hoc ways. What new services could be based on those capabilities?
The ANM's status in the community could be affected by her use of the new technology. A Newton device is much more expensive than other equipment now used by the ANM. It is certainly foreign to her current interactions with the villagers. If she takes it with her on her tour of the village's houses, it could increase her status and it could potentially harm her relationship and social interactions with the villagers.
Figure 5: ANM interacting with villagers during her house-to-house tour
Part of our proposed support system includes the ability to provide to the ANM on-demand information relevant to current conditions in her villages via the Newton device. This information could be limited to healthcare data, but the ANM often performs a broader function within the village, as a general source of information and as a point of contact with the government as a whole. How would her increased access to information affect this broad role within the village community?
A relatively large amount of the project has been investigative. In fact, to divide the project into developmental stages is misleading, since a theme of investigation and progressive understanding of the environment, potential users, and the technological basis has been constant throughout the project. Thus, the divisions following are more thematic than strictly chronological. Various categories of investigation, design, development, and testing overlap throughout.
We are passing over what could be judged the most critical aspect of the project, building the project team and the partnerships needed to see the project through from conception to eventual delivery of a solution to the healthcare system. Of particular note, however, throughout the project has been our building, together with CMC, a partnership for development. Engineers from CMC have spent time (two months or more each) in Cupertino, working with Apple engineers learning the Newton and Macintosh software platforms and development environments, meeting with designers, and contributing to the design and implementation of our early prototypes. Throughout the engineering phases of the project, the team was composed of components of both CMC and Apple.
The project team purposely held back from concrete design sketches, usage scenarios, or interface concepts during the initial months of the project. The team felt that any narrowing of potential designs when so much was unknown would be extremely premature. Before beginning to think of valuable designs or even of what tasks and roles we were designing to support, we needed to learn a number of basics. These included:
The first team members active in the project concentrated their efforts on visiting the field site and gathering information, impressions, and building relationships to pursue those goals. A great deal of this initial work consisted in reconstructing the paper report structure and the formal practices and roles associated with it. Team members modeled the reporting structure and checked its accuracy with the local Chief Medical Officer, Dr. Ashok Singh, in Ajmer.
The purpose of the first two visits to the site in November and December of 1994 was to gain a first-hand impression of the physical environment, the players involved, and the scope of what the team needed to learn. Also, this was our first chance to see the needs and practices of the ANMs from ground level rather than from the government's descriptions of their roles and duties. The team for this first visit was oriented almost exclusively toward field studies and was guided by Kawaljit Singh, working on the project through CDIT. He acted as guide to the region, to the healthcare principals, and to the healthcare structure as a whole.
The third site visit in March of 1995 focused much more specifically on the job of the ANM. Members of the team followed one ANM on her daily tour of her village, documenting her routines and her interactions with villagers on film [Grisedale, 1995], later edited into a short video-tape that proved invaluable in orienting new project members and interested parties to the basic facts and, as far as is possible on video, the feel of the job and environment for which we were designing. This process also allowed the team to make first-hand observations (and later, reflective observations, based on reviewing the film) about the ANM's practices and to raise questions about the potential fit of electronic support into them.
The two critical concrete results of this phase of the project were a formal reconstruction of the reporting system and the dataflow between nodes of the healthcare system and a less formal reconstruction of the ANM's tasks, practices, and roles within the village. In addition, though, the team gained a less tangible orientation to the culture and region that formed the background for our later designs.
As a result, by April of 1995, we were ready to begin asking some large design questions. Should we concentrate specifically on the ANM? If so, what aspect of her many roles should we try to support? Ultimately, we decided among several directions, each of which could have been valuable and justified. Our decision was to focus on the ANM's data collection responsibilities and on her ability to bring health-related educational information to bear on the current circumstances of her village (population growth rate, outbreaks of disease, drought, water contamination, etc.). Our decision was based on the strengths of the Newton software and hardware platform and on the expressed needs of the Indian government and the village-level healthcare workers.
The first engineering-related phases of the project concerned transferring the existing paper data structure, represented by the ANM's registers and monthly reports to her supervisor, to an electronic model. We did this without regard to interface design, using an emerging data backbone as a central feature.
Figure 6: Backbone for healthcare data
Sally Grisedale, and later, Alexander Grünsteidl, constructed paper models of the flow of data through the healthcare reporting structure. Kawaljit Singh, who had the most thorough knowledge of the healthcare system and the organization of data at the ANM's level, built a Hypercard mock-up around this data backbone, and then, later, Mike Graves built a very simple model of the data backbone to display on the Newton MessagePad. Sally and Mike also constructed alternative paper mock-ups as prods for the teams' thinking.
Figure 7: Screenshot from an early Hypercard prototype for data collection and viewing
These reconstructions and electronic mock-ups allowed the team to begin to discuss more concretely the limitations and capabilities of an electronic device within the context of the ANMs' roles and practices as we were now discovering them. The goal here was to incrementally learn how the existing system and the potential of the new technology could be brought together.
At the same time that we were learning the basics of the ANMs' job and the rural villages, we were learning about the potential of the Newton platform and the MessagePad hardware. In addition to learning our way around the Newton development environment, we began to specifically address some of the challenges we mentioned above.
Language support was perhaps the most daunting of those challenges. We needed to learn basic facts about the written Hindi language and how, technically, to provide for its display and input on the Newton MessagePad. This included also devising methods for uploading and downloading Hindi text between the MessagePad and the Macintosh.
The details of language support fall outside the scope of this paper. However, by way of illustration, we show below some of our initial efforts at porting Macintosh Devanagari fonts (Devanagari is the script for written Hindi) to the Newton system and for constructing a keyboard based on it, and then also some representatives of our later prototypes.
Figures 8 & 9: Early (top) and later (bottom) interfaces for Hindi keyboard prototypes
The design of the font itself required tailoring its characteristics to the non-backlit display of the Newton MessagePad 120 and development of specialized fonts and styles for various Newton interface elements (buttons, field labels, etc.). The keyboard itself is based on ISCII (Indian Script Code for Information, similar to ASCII) [ISCII, 1991]) standards, with modifications to allow the normally invisible, shifted keyset to remain visible in the background of the unshifted keyset. Hindi does not include capital and lower case characters, but it does require a character set spanning both sets of keys on a standard Roman-script keyboard.
Other notable challenges concerned adapting the MessagePad hardware to the physical and technological environment. Since the ANMs' Subcenters typically lack electricity, we considered various alternative power sources, eventually testing a prototype carry-bag incorporating a solar panel for continuously charging the MessagePad resting inside it. We adapted, with the help of Keep It Simple Systems, a solar bag they had already manufactured for the general Newton market to the needs of the ANMs, providing a shoulder strap and pockets within the bag for the ANM's equipment. We based the design on our observations of the bags already used by the ANMs we had seen in our field studies.
We also tried, with less success, to find solutions for protecting the MessagePad from dust and from the physical wear and tear we expect from the rural Indian setting. While ruggedized Newton cases are readily available on the market, their cost and weight were prohibitive. Less expensive solutions, such as a prototype stretch-to-fit rubber boot, did not provide adequate protection.
Designing an interface for the Newton-based prototype required bringing together everything we had learned about the data structures, language issues, and the reconstructions of the ANM's functions and practices. Alexander Grünsteidl headed the team's interface design efforts. Again, full treatment of the design strategies and implementations fall outside the scope of this paper, but we will lay out some essential points of the strategy and illustrate them with screenshots from prototypes.
We chose to keep text entry to a minimum and push the possibilities of a pen interface to its maximum. Doing so avoided inherent difficulties associated with Hindi text entry on Newton and also, we felt, provided the best strategy for introducing screen-based interaction to people who had previously been exposed only to primarily paper, radio, and television based one way media.
Figure 10: Screenshot of prototype Hindi interface, showing graphical display of members of a household in the village of Narwar. The Hindi characters next to the couples and at the top of the screen read `Laal,' the surname of the couples in this household
We chose to create a patient-centered organization of data, with individual patients embedded in a hierarchy up through their families, households, and villages. Each person is then identified through his or her name, family membership, membership of the family within a household, and location of the household within a village. These relationships are represented in graphical layouts.
Figures 11, 12, and 13 below shows the hierarchy from the household level to the individual record for one person. The `Moss' household is located within the village of Narwar in the first shot. In the second, we see the members of the `Moss' household in their relationships to one another. The couple who heads the household is the `Moss' couple, with their four children, and then the `Smith' family with two children live in the same house. Finally, the individual record of `James Moss' is shown open in the third screenshot.
Figures 11, 12, 13: Screenshots of prototype showing navigation path through a fictional household, showing single pen-tap navigation from a list of households within a village to a display of members of a household and then to the individual record of one of those members
Figure 12: Families within a household
Figure 13: An Individual Record
This organization was chosen not only to mirror the hierarchy of the ANMs' current paper records, but also to try to match her practices in her daily tours of her villages, organized around regular visits to sets of households in the village.
We developed a method for navigating through the interface based on modal iconic representations. The icons serve both as labels and as navigation elements. Thus tapping the pen on the individual's icon takes the user to the record for that individual.
Icons also provide qualitative feedback on the status of the population. Noteworthy conditions, such as disease, immunization status, or pregnancy, and personal data, such as gender and age, are visible in individuals' icons.
This method includes an overview to limit constant deep navigation into the hierarchical levels of the data to review records of individual patients. Essential information is propagated from the lowest levels to the village overview level for the ANM's quick reference and recognition.
The prototype's interface is evolving from our earliest designs both to meet the demands of the ANMs' practices as we learn more about them and also to match the actual reporting system more and more accurately. The reporting system has changed since we began prototyping our support system, and it will continue to do so. Some data elements that were initially critical have been altered or even eliminated from the system. On the side of the ANMs, as we spend more time working with them and getting to know them, we discover more and more about how they actually work and what tasks are considered crucial by them, as distinguished from the official account of the healthcare system.
Figure 14: Iconic representations of individuals, showing age and gender distinctions
We first took our prototype into the field and showed it to ANMs in December 1995. This first `test' was not really a test, but rather an exposure for initial reaction and impressions. We found out how the ANMs handled the device, whether they hesitated to use it, how they handled the pen, how carefully they treated it, how they reacted to the on-screen keyboard and the Hindi-language and graphical displays, etc. Each of six ANMs spent a maximum of one and one half hours each with the prototype, getting an initial, verbal orientation to it (through a Hindi-speaking interpreter who has joined the field team in India), exploring the interface first-hand, and performing some elementary tasks on it.
Feedback from this first exposure was impressionistic, but, on the whole, very positive. ANMs did not hesitate to take the MessagePad in hand, to tap on the interface with the pen, and some even reported that using the keyboard to enter names of villagers was `fun.' The navigation method through the interface seemed to be intuitive to them. On the whole, they felt that the device would be valuable to them, after an initial period of learning, perhaps with one-on-one training.
At the same time, we found that some particular graphical elements were not understood, some data elements were not accurate (with respect to their actual practices or responsibilities), and the device's display was too dim or too reflective in the sun's glare. This initial feedback gave us a great deal to go back to work on.
Also, during this field study, we broadened our understanding of the ANMs' duties and practices. We considered it especially important, now that we had begun design work, to gain a sharper understanding of how the ANMs go about their daily tour, what their order of business is, how they collect and consult data, and what is of greatest importance to them. Michael Tschudy led this field effort, using a card-based method for eliciting information from the ANMs [Tschudy et al., 1996].
Currently, we are engaged in our second round of field testing, with a more complete prototype, backlit Newton MessagePad 130s, and with a more formal testing plan.
The India Healthcare Project will continue through the oncoming year. At this stage, the role of the Apple project team is evolving from principal designers to advisors and more basic technology providers, with the team at CMC, Ltd. in Hyderabad taking over continued prototype development, field testing, and development of the project in partnership with Apple Computer and with the Government of India. Much more needs to be learned in response to our basic research questions, and we are counting on our continued partnership with CMC to provide help in doing so.
Returning to the research goals we laid out at the beginning of this paper, we can offer our reflections at this stage of the project to summarize its current status.
For the healthcare system:
The prototype system promises to reduce ANMs' paperwork. We await field testing results to confirm that achievement, but the Newton-based system does eliminate redundant data entry and laborious hand-done compilations under the existing paper-based system. Even greater streamlining should become evident higher up the reporting structure. Currently, data from a region's Supervisors are delivered to a `Computor,' a man whose job is to compile all of the data he receives and generate a variety of summaries. He must do this by hand, on paper. Any analysis of the data to spot trends or track cycles is laborious.
Our hope has been that reducing ANMs' and their Supervisors' time spent on paperwork will allow them more time for monitoring conditions in the villages, planning responses to those conditions, and generally providing greater coverage and depth of healthcare. Introduction of our prototype system will not accomplish that goal by itself, though. The duties and practices of the ANMs and Supervisors will need time to evolve, under the guidance of the government, to meet such a goal. And, of course, other factors, including changes in the healthcare programs reflecting national and local priorities, will intervene.
An overriding factor is the success of the project on a large scale. So far, we have been working with a relatively small number of Subcenters and ANMs in one part of India. We are counting on Apple's partnership with CMC to push on to the next step, to larger pilot studies and other regions within India. It is not our expectation to see the kind of system we have been prototyping in all regions of India, as political, educational, and other issues have a great bearing on local adoption, but it is our goal to see benefits derived from widespread use throughout the country.
For Apple:
We expect many more specific findings from our current field study. While that study is not yet complete, we can speculate about a few high level findings.
Pen interfaces seemed to provide a significant advantage for us. Our potential users are not computer-literate, are not experienced typists, and do not write a language with Roman characters. The Newton pen interface, along with the unintimidating size of the MessagePad, allowed them to take the device in hand and begin to use it immediately. Even though we do not have localized handwriting recognition, ink text and software keyboards provide a great deal of flexibility for designing comfortable input methods.
Physical conditions have a great bearing on the success of the prototype. Poor lighting conditions and uncorrected eyesight are much more common in rural India than we are accustomed to in our more traditional environments. Glare resistance and backlighting are essential. Additionally, high resolution displays and/or space for large fonts are critical, given the intricate nature of many Hindi (and other Indian language) characters. Dust, heat, and rain need inexpensive solutions -- to a large extent we have not yet successfully addressed those problems. Alternative energy sources, such as the solar powered carrying bags we have introduced, are also needed, as electrical power and batteries are in short supply.
Another interesting area in which further observation is needed is in assessing the impact of introducing computers into a job in a country where computers are uncommon and where facility with computers may be seen as a very significant advantage economically and in social status. Will this make the ANM's job more satisfying and more promising in terms of longer term career goals? Will it increase the distance between ANMs and the villagers she serves? We need much more time to begin to see answers to those questions.
For future prototype development and field studies, our group will serve as consultants to the research and development group at CMC in India. Already, we have seen that their ability to maintain much more consistent contact with the field has made it possible for them to tailor the prototype system much more closely to the ANMs' and their Supervisors' practices and needs. Clearly, we are seeing, in the first weeks of this new phase of the project, great advantages in seeking Indian direction toward solutions for Indian users.
[Bulletin, 1995] Bulletin on Rural Health Statistics in India for the Quarter Ending June 1995, Rural Health Division, Ministry of Health and Family Welfare, Government of India, Nirman Bhawan: New Delhi, 1995.
[Grisedale, 1995] Grisedale, Sally (writer and producer), Padma's Story: A day in the life of a Healthcare Worker in Rajasthan, India (video), Apple Computer, 1995.
[ISCII, 1991] Indian Script Code for Information Exchange -- ISCII, Bureau of Indian Standards: New Delhi, 1991.
[Rosenberg, 1992] Rosenberg, Richard S., The Social Impact of Computers, Academic Press, 1992.
[Silveira, 1995] Silveira, D. M., DM Silveira's India Book 1994-95, Classic Publishers Pvt. Ltd.: Goa, India, 1995.
[Tenner, 1996] Edward Tenner, Why Things Bite Back: Technology and the Revenge of Unintended Consequences, Alfred A. Knopf: New York, 1996.
[Tschudy et al., 1996] Tschudy, M.W., Dykstra-Erickson, E. A., Holloway, M.S., `PictureCARD: A Storytelling Tool for Task Analysis' (In Press) Participatory Design Conference '96 Proceedings.
Mike Graves is the manager of the Contextual Learning group at Apple's Learning Technology Group. He has a Ph.D. in Philosophy from the University of California at Berkeley. Before coming to Apple in 1989 to work on collaborative systems, he did research and design work on workflow and communications software systems.
Sally Grisedale is currently Director of Interaction Design at Studio Archetype in San Francisco. She managed the Interaction Design team, for the Apple Technology Group at Apple Computer, Inc. She trained as a graphic information designer in London, then spent two years studying for a master's degree in Computer Related Design at the Royal College of Art. She is also a Fellow of the Royal Society of Arts. Before joining Apple in 1993, she worked as a graphic designer for several companies in England and Germany including the Royal National Theater and the British Broadcasting Corporation.
Alexander Grünsteidl, born 1965, grew up between the Netherlands and Austria. He studied industrial design at the Akademie voor Industriële Vormgeving, Eindhoven, the Netherlands. During his bachelor degree he collaborated with the Philips corporate industrial design group. He attended a course in computer related design at the Royal College of Art in London, UK. He was invited to work on the India Health Care Project at Apple Computer, after which he participated in the Interaction Design Group of the Knowledge Systems Lab of the Apple Advanced Technology Group. His focus is still on information architectures, but his fingers and body are itching to incorporate more physical interactions with computing and communication devices than point and click.
Mike Graves
email: mgraves@apple.com
Sally Grisedale
email: grisedale@earthlink.net
Alexander Grünsteidl
email: agrunsteidl@earthlink.net
Issue |
Article |
Vol.30 No.2, April 1998 |
Article |
Issue |