The Final Post: HCI for Low Technology Landscapes
A billboard above a shop along Zaatari’s market area, which references various social media platforms and messaging apps that are popular among Syrians. Michael Pizzi
The current plan for my MRes project is to target refugees and work in the context of refugee camps, specifically the Zaatari camp in Jordan. Currently hosting over 83,000 Syrian refugees [1], this camp was opened in 2012 to host the syrian refugees fleeing the war in Syria to Jordan.
Zaatari camp is a digitally restricted landscape with a myriad of limitations on resources. In terms of infrastructure, the households of the camp have access to electricity 11 hours per day [2]. In terms of internet connectivity, the wi-fi connection is clogged due to its inability to handle the large influx of refugees [3]. Cellular networks are unreliable and offer slow internet connection speeds [4]. While technology is not just electricity grids and internet connections, it gives some indication to the general limitations one might face in the camp. However, going beyond that, even kitchen appliances that we take for granted, such as ovens, are missing from some of the households, if not most of them. These limitation make the camp interesting to explore, but quite challenging to work with.
I’ve been thinking about this challenge a lot lately, how does one approach a technology limited/restricted landscape with a digital solution, and how might one go about designing a solution in such a case?
Digital Civics research always has cause to turn back to HCI for input; and this post will talk about some of the various ideas in HCI that might apply to projects based in a low-tech community, and how they might apply to this case more than usual (or perhaps less, in certain cases).
What I refer to as a low-tech community in this post is a community where access to technology is severely limited or not, in general, available to most members. This creates limitations on the devices and interfaces that can be used, and has a heavy bearing on the priorities and methods of design, which are a more sensitive issue when the community in question is undeveloped or lacking in resources. [5]
A close-up view from a helicopter of the Za’atri camp in Jordan for Syrian refugees as seen on July 18, 2013. [State Department photo/ Public Domain]
Colonial Pitfalls
There is a tendency for organizations working with, or studying poor communities, to fail in
considering things from the viewpoint of community members themselves, or in consulting them at all, as demonstrated by a number of efforts at various levels, from volunteer action to UN-led projects [6], and digital civics researchers are no less prone to this.
The concept of the colonialist mentality may not seem like the intuitive point of entry for such an article at first (or perhaps it does?), but the framing of the problem, that of a digital civics researcher approaching a low-tech community, is such ripe grounds for colonialist thought.
Colonialism, as re-coined by Paul Dourish in Ubicomp’s colonial impulse [7], refers to the central/peripheral structure where the research lab is the center of power, much like a colonial hub, and the rest of the world is peripheral colonies. Colonialism, in this context, has a tendency towards universalization. Working from a major centre, and believing as it does in the development\model centre rhetoric, the colonial empire aims to create universal representations of knowledge that abstract local characteristics and differences into a single model, eventually going for the most universal framework by quantifying knowledge into numbers.
In short, colonialism, is about generalizing away differences in context, or even considering them in the form of extra factors to a central model, themselves subject to models and categories; all to be ironed out and dealt with so that we can return to clean, planned, structured models that work nicely in our lab environment, or in our first world city with fast internet and working location services everywhere.
It is easy to see how this maps to low-tech communities; for they, by their very definition, are situations where the usual assumptions about technology fail. This includes tech availability, the way it’s used, its social role, the directions of its development, and more.
In Residual Mobilities: Infrastructural Displacement and Post-Colonial Computing in Bangladesh [5], Ahmed, Mim, and Jackson report on a field study of forced mobility and technology use among populations displaced by the Hatirjheel waterfront development project in Dhaka, Bangladesh. They find discrepancies between even the most basic and usual assumptions and those they faced in the field, starting from simple ones like assumptions about infrastructure and the availability of power and internet, up to the basic frames of imagination in mobile computing, wherein the individual is an empowered user, with resources to spend, a right to choose, and ability to act on choices, unlike the subjects of their study, whose displacement is not voluntary.
Even political blindness to the effects of introducing technology into a context has an impact; efforts for introducing technology for “developmental” ends foster the relationship of dependence, create more initiatives and tools that don’t engage the conditions and experiences of their targets, and blind researchers to possibilities of making things that are simply different from what exists in the developed world, and are locally better.
In short, the implication here is that the pitfalls of colonialist thought are pervasive, and falling for them is much more likely to have an impact in such a project; for things that work in the lab or even in a modern city are unlikely to work the same in hands of the community, technical problems are everywhere, what the researcher is likely to think are the community priorities is likely going to be false, generalisations based on different communities are likely to fail, and so on and so forth. It’s a spike pit trap.
The spike pit of colonialism.
From Colonialism to Postcolonialism:
Postcolonial computing, then, is not a project of making better design for “other” cultures or places. It is a project of understanding how all design research and practice is culturally located and power laden, even if considered fairly general [8].
Postcolonial computing, as dubbed by Irani et al. [8], is as an answer to the these issues. It can be said that it is about situatedness; design within context, with the community, culture, politics, and environment all being considered in the design experience.
There is much work in HCI and elsewhere about how to achieve the post-colonialist ideal, which brings us to…
Participation \ Participatory Design
Participatory Design now lies at the heart of the modern practice of human research in HCI. It’s not just about asking people to fill surveys or vote on options, but cooperating with them in the design process. This cooperation isn’t limited at the stage of problem solving, but can extend to cover the formation of the problem as well as the evaluation of the solution [9].
Participatory Design, in its basic form, maintains the traditional roles of designer and user. A post-colonial approach to Participatory Design would, as envisaged by Irani et al. [8] not focus on the view of designers trying to formulate requirements, but on the conversation; staging and shaping encounters between parties. This could draw attention to the context of the encounter and those taking part in it, and to the bidirectionality of the exchange; people take away from the encounter just as well as they contribute. The result, in essence, would be a conversation between several parties, not of a recipe whereby they respond in certain fashions to assigned roles. The approach of designing the participation space is likely a good way of having people in these communities discuss their views of technology and their vision to how it can solve this problem, while avoiding many traps.
Participation and Care
In Structuring future social relations: the politics of care in participatory practice [10], Light and Akama propose a certain kind of restructuring of the participation process. To define the role of designers, the paper draws upon the feminist concept of care and the notion that for life to be livable, people have to care for each other. Hence, a designer is a ‘custodian of care’, setting to create the space for people to reflect, interact, and design, which could eventually lead to restructuring the power relations from a ‘top-down’ approach to one that engages the community making it more interdependent.
The proposal here, simply stated, is to cease designing with people’s participation, but to simply create opportunities for people to build relations that somehow solve the problem, or otherwise enable them to find better solutions and hopefully maintain this. This is one example of how the approach to Participatory Design as a staging of encounters between people can lead to different outcomes than a classic, unidirectional, participatory elicitation of requirements.
In the case of a low-tech community, this has the interesting side-effect of creating the opportunity for sustainability, by allowing the community to own the solution, and create relationships that sustain it. The issue here, however, is that such an idea isn’t especially geared for technological solutions, which brings us to the question of how much the process needs to be technical.
But is Technology the Answer?
HCI as a field for research has been defined and approached in so many different ways. One such approach is HCI research as problem-solving [11], in which it is proposed that HCI research is problem and solution centric, clearly stating problems and validating the solutions based on their contribution to the problem-solving capacity.
It is easy to see why the HCI research has the unfortunate reputation of being solutionist [12], believing in a technological solution to every problem; the problem-solving approach argues against that case by using broader definitions of the research problem and solution. However, in it being focused the contributions of solutions to the problem-solving capacity, does that mean our research is failed if we find that technology is not the answer? A low-tech community, likely one with less infrastructure and higher relative costs, is one context where such solutionism or solution-centric approaches can spell failure.
I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.
So what if, after all, we find that technology is not the answer, or that the technology we implemented was the wrong answer? Eric Baumer addresses this issue in “When the Implication is not to Design (Technology)” [13]. In this play on words, when the implication of the research is not to design technology, there are still things to do. For one, we must value this result in itself, for it is just as useful for definition to know when something is not, as it is to know when it is; there are areas where technology may seem useful, but turn out inappropriate, and that’s important to recognize. Another thing to recognize is that negative results aren’t to be simply written off, there are reasons and circumstances for them that we must recognize and understand, and perhaps later present along with successful results, to present a more whole understanding of the problem.
Finally, I don’t mean to conclude that technology is not the answer, it is just that HCI might have it hard with the C part in a low-tech community, but also likely with the I part if the C part isn’t done correctly; for you don’t design here like you design somewhere else, if you’re wary of the spike pit of colonialism. You don’t assume what you made in a lab works here, nor do you generalize your findings from previous work in a different community. You find a more suitable design approach, you try to understand people’s experiences and histories, your design is inspired by their experience instead of it trying to force new experiences, you be prepared for all sorts of problems, and for the possibility of re-phrasing and reviewing your methods and your research goals, and you brace yourself for the possibility of the answer to the question of technology being no.
REFERENCES
[1] United Nations High Commissioner for Refugees (UNHCR). “UNHCR data Portal”. UNHCR Syria Regional Refugee Response. [Accessed: 20 November 2016]
[2] UNHCR, 2015. Zaatari Refugee Camp Factsheet. [online] Available at: https://data.unhcr.org/syrianrefugees/download.php?id=10047 [Accessed: 9 Dec 2016]
[3] The Borgen Project, 2015. Wi-Fi ‘Saves’ Residents in Jordan Refugee Camp [online] Available at: http://borgenproject.org/wi-fi-jordan-refugee-camp/ [Accessed: 11 Dec 2016]
[4] Maitland, C., Tomaszewski, B., Belding, E., Fisher, K., Xu, Y., Iland, D., Schmitt, P., and Majid, A., 2015. Youth Mobile Phone and Internet Use – January 2015 – Za’atari Camp, Mafraq, Jordan.
[5] Ahmed, S.I., Mim, N.J. and Jackson, S.J., 2015, April. Residual mobilities: infrastructural displacement and post-colonial computing in Bangladesh. In Proceedings of the 33rd Annual ACM Conference on Human Factors in Computing Systems (pp. 437-446). ACM.
[6] Gigler, B.S., 2004, September. Including the Excluded-Can ICTs empower poor communities? Towards an alternative evaluation framework based on the capability approach. In 4th International conference on the capability approach (Vol. 5, No. 7).
[7] Dourish, P. and Mainwaring, S.D., 2012, September. Ubicomp’s colonial impulse. In Proceedings of the 2012 ACM Conference on Ubiquitous Computing (pp. 133-142). ACM
[8] Irani, L., Vertesi, J., Dourish, P., Philip, K. and Grinter, R.E., 2010, April. Postcolonial computing: a lens on design and development. In Proceedings of the SIGCHI conference on human factors in computing systems (pp. 1311-1320). ACM.
[9] Schuler, D. and Namioka, A. eds., 1993. Participatory design: Principles and practices. CRC Press.
[10] Light, A. and Akama, Y., 2014, October. Structuring future social relations: the politics of care in participatory practice. In Proceedings of the 13th Participatory Design Conference: Research Papers-Volume 1 (pp. 151-160). ACM.
[11] Oulasvirta, A. and Hornbæk, K., 2016, May. HCI Research as Problem-Solving. In Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems (pp. 4956-4967). ACM.
[12] Morozov, E., 2014. To save everything, click here: The folly of technological solutionism. PublicAffairs.
[13] Baumer, E.P. and Silberman, M., 2011, May. When the implication is not to design (technology). In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (pp. 2271-2274). ACM.
Leave a Reply Cancel reply