CONTRIBUTION 129

The contribution of this thesis is the Softbridge framework. The framework provides a useful checklist and guide to ICT4D fieldwork for both newcomers and experienced hands. The framework consists of three components: Softbridge stack, QoC and the SASE method. We chose to address two difficult communication scenarios characteristic of digital divides in South Africa. South Africa is peculiar in that developing regions frequently co-exist with developed regions because of the relics of apartheid. Crafting communication prototypes for the two field studies revealed recurring themes that informed the development of the Softbridge stack, a socially aware design abstraction for the construction of ICT4D communication systems. The Softbridge abstraction incorporates a people layer and the Real Access/Real Impact, or RA/RI, criteria to enable the alignment of technological and social issues. A consequence of the Softbridge design stack was the need for a correspondingly

socially aware approach to the evaluation of ICT4D systems. QoC plays the same role for the Softbridge stack as QoS plays for the OSI stack. QoC posits that social factors help explain why end-users might tolerate macro delays and poor quality in communication systems and conversely, why perfectly functioning communication systems might be shunned and unused. We iteratively developed a series of prototypes based on the Softbridge stack and evaluated them with QoC guided by a socially aware software engineering method, or SASE.

A result of the SASE method was that we also iteratively refined the two novel abstractions based on cyclical reflection. The SASE method had the additional benefit of recursively refining itself via reflection. Together, Softbridge stack, QoC and SASE form the Softbridge framework. Section 9.1.1 recaps the Softbridge stack. Section 9.1.2 explains QoC, and Section 9.1.3 comments on the SASE method.

9.1.1 Softbridge stack

The Softbridge abstraction combines technical and social issues in a reference model for the design of ICT4D communication bridges (see Section 8.1 and Figure 8-1 in particular). Softbridge stack layers include power, network, device, media, temporality, interface and people. Four of the layers are the same as Brewer et al.'s (2005) 'Big 4' (see Figure 3-1). People issues affect all layers and are factored into the model with RA/RI criteria. The Softbridge stack is meant to be complementary to the OSI and TCP/IP stacks (see Figure 8-2). The technical Softbridge layers are conceptually organised similarly to OSI layers except that Softbridge layers are fundamentally interrelated and centred on people factors (see Figure 8-3). The people layer requires software engineers to consider social factors during the design process.

RA/RI criteria were utilised at all layers in the Softbridge stack in order to comprehensively include social issues that arose during both field studies. RA/RI criteria were simple and easy to apply. The NGO was co-located with us in Cape Town. We were able to establish a good rapport with them, and contracted their services to help the research team apply RA/RI criteria to our endeavours. However, any reasonable ICT4D M&E tool, e.g. Universal Access Wheel (see Figure 3-2) could be utilised to inform consideration of the people layer in the Softbridge stack to complement the technical design issues. It follows, then, that socially aware evaluation is required to evaluate ICT4D systems built on the Softbridge stack.

9.1.2 Quality of Communication

The Quality of Communication abstraction, or QoC, focuses on RA/RI criteria to assess how well bridges operate at various layers in the Softbridge stack (see Section 8.2 and Figure 8-4 in particular). The original idea for QoC was that social factors rather than bandwidth could help overcome disadvantages of QoS-challenged networks, e.g. large latency and poor quality. That view implies that QoS is often not applicable to ICT4D scenarios because those environments oblige participants to accept low QoS, thereby negating the need to design specifically for QoS. For example, QoC helps to explain why store and forward systems like SIMBA (Section 6.5.2) and MUTI (Section 7.5.2) could be beneficial. A traditional QoS view infers that users would reject asynchronous communication based on technical performance delay. However, the quality of QoS-poor store and forward communication is as much social as technological. The poor adoption of SIMBA and MUTI prototypes had more to do with social than technical factors. Comparing QoC with QoS in this manner is still in terms of network performance and an individual's perception of the communication service. Over the course of the field studies, QoC became more aligned with the idea that quality is situational. This view is compatible with "quality is in the eye of the beholder" (Bouch et al., 2000), albeit on a social rather than an individual sense. We use RA/RI criteria within the Softbridge stack to reflect on the social aspects of QoC. This is very different from traditional QoS measurement techniques. An implication of QoC is that imperfect systems can be tolerated as long as they address social factors effectively. A further implication is that one could explicitly design imperfect systems. Designing to achieve QoC does not mean minimising delays, as QoS mandates, but rather to maximise social cohesion with ICT. Achieving QoC, or the lack thereof, is a factor of how well ICT4D system addresses RA/RI issues, and was a significant determinant of communication system take-up in both field studies.

Section 7.5.2 described how various QoC aspects inhibited take-up of research prototypes at DCCT. Participants did not use SIMBA no matter how much they needed to communicate with hearing people because SIMBA was text-based. Deaf users eventually told us they wanted to communicate in SASL, a language that defined their culture. Deaf participants did briefly use the real-time text chat despite their awareness of poor grammar and slow typing, but that was because they were communicating with fellow Deaf participants in the Bastion. DCCT participants could not embrace Internet tools like Skype or AIM

because they had temporary privileged access to ICT while at the Bastion that most of their friends and family did not have. Deaf users were also slow to adopt Internet-based video conferencing despite the possibility of SASL communication for that same reason. Camfrog appeared to satisfy technical requirements for real-time SASL language communication, but a lack of a calling circle inhibited usage. However, despite the lack of adoption of research prototypes, many DCCT members continue to take advantage of the Internet connectivity associated with the research infrastructure. The DCCT NGO saw how ICT access was increased by the connectivity and budgeted to sustain its use.

Social factors regarding prototype adoption were also prevalent in the rural telehealth field study, e.g. as described in Section 6.5.2. Clinic nurses would have much preferred to communicate with other nurses at the hospital and their managers, like the discontinued CB radio system had done. Unfortunately, the hospital laptop was put in a doctor's office and it was not readily available to hospital nurses. The doctors took to the technology because it bridged them to colleagues and information, and to friends and family on the Internet. The nurses, like the Deaf users, did not have such a connectivity circle. Regarding MUTI specifically, poor QoC rather than poor QoS was the main inhibiting factor to take-up. Despite the entire range of media and temporal modalities at Lwandile clinic offered by MUTI on both PC and cell phone, the nurses simply chose not to establish social connectivity with the doctors. Of course, the stolen solar panels eventually prevented them from using MUTI, but they had ample time in which to use the tool and they chose not to do so.

Social issues that arose during the Deaf telephony project described in Chapter 6 and the rural telehealth field study described in Chapter 7 motivate placing people at the top and centre of the Softbridge stack (see Section 8.1) and consequently being central to QoC (see Section 8.2). If people do not use ICT to bridge their own social gaps, then no technological bridge can ever span such gaps. Therefore, research methods were necessarily qualitative in nature. One could design for social factors and could become aware of them through a socially aware iterative process of software design.

9.1.3 Socially aware software engineering

Section 5.2 describes how action research espouses the dual imperatives of community and academic goals. In our case, the community goals are empowerment of respective communities via Deaf telephony and rural telehealth. The academic goals are to learn how to

design and evaluate ICT4D systems, as articulated by the research question in Section 4.2. To address both imperatives, we constructed a series of communication prototypes for both field studies as reference implementations for the evolving Softbridge stack and QoC abstractions. By infusing people factors into the design and evaluation processes, the socially aware software engineering, or SASE, method (see Section 8.3) helped us align community and academic goals. Based on our experience in the field, NGOs as intermediaries can form an essential part of that process.