Chapter 9: Conclusions 129
A.9 DEAFVIDEOCHAT 166
A.9.5 Reflection 169
DeafVideoChat clearly offered superior video quality with respect to sign language comprehension. Still, Deaf users who actually used a remote video tool rather chose Camfrog. It should be noted that very few of the participants used a video communication tool outside the research sessions. There were only a couple of regular DCCT video users. SLED, on the other hand, adopted Camfrog as a part of their everyday business conduct. There were several explanations why regular users preferred the lower quality tool, and why so few DCCT participants used the tool.
Camfrog was synchronous and was therefore easier to use than the asynchronous interface that required numerous button presses to record, receive and send video.22 Camfrog also had the advantage of being clearly associated with Deaf users on an international basis. Camfrog provided established chat rooms for users from all over the world. Deaf users related to Camfrog as a SASL tool whereas Skype was a text tool even though it also supported video. DeafVideoChat, on the other hand, was a research tool clearly associated with our weekly visits. Camfrog's perceived superior quality may have been linked to these social issues rather than purely technical ones. We cannot say for sure because we could not perform automated objective video quality tests on Camfrog or Skype as we could with DeafVideoChat because the internals of the web tools were not accessible via open source. On a related issue of users adopting a lesser quality tool, Camfrog had many Skype features with respect to media and temporal modalities, but was much less sophisticated in terms of security and privacy. This lack of features, however, did not deter users from adopting Camfrog.
SLED users appropriated tools like Camfrog (for SASL) and Skype (for text) into their daily activities more than DCCT users. This could be explained by the fact that the two SLED offices needed to communicate with each other because of geographic distance. Furthermore, end-users at both SLED offices had very similar RA/RI criteria attributes, e.g. education, PC literacy, PCs with web cams on their desks and broadband connectivity that encouraged the appropriation of a tool like Camfrog. On the other hand, while most DCCT participants had a PC on their desk at offices throughout the Bastion building, face-to-face contact was preferable to and more convenient than virtual contact. More importantly, DCCT-resident
end-users had much more ICT4D access than off-site Deaf and hearing users in their potential connectivity circle, especially with regarding to physical access to ICT. Therefore, the connectivity circle at the Bastion was artificial at best. Even though the Deaf telephony prototypes may have functioned adequately, there was no need or even genuine opportunity for DCCT participants to use the tools, as was the case at SLED. The lack of take up of research prototypes at DCCT and the simultaneous take-up of Skype and Camfrog at SLED demonstrated that the social RA/RI criteria-related considerations were fundamentally more important than the technical attributes of any ICT4D system we could devise. Thus, in order for ICT4D appropriation, RA/RI criteria had to be addressed.
Appendix B Information Sheet – Deaf Telephony
Who are we?We are Computer Science researchers from the University of Cape Town and the University of the Western Cape. The team members are Bill Tucker, Tao Sun, Elroy Julius and Edwin Blake. Meryl Glaser is our advisor.
What do we want to do?
We want to improve communications between Deaf and hearing people. The aim is to provide a Deaf relay service to the telephone system using computers on the Internet. Our system, called SIMBA, allows Deaf and hearing people to communicate with some degree of automation. The Deaf user sits at a computer (PC) at Deaf Community of Cape Town's (DCCT) premises. We will provide the PCs. The Deaf user communicates with text. A Deaf user's text is automatically converted into speech with a Text-to-speech program. Our system, SIMBA, sends that voice to the telephone of a hearing user. When the hearing user speaks, the speech is sent to an operator that translates the speech into text. Then, SIMBA sends the text to the Deaf person's computer. Our research is primarily the development of the communication software. We will work with Deaf and hearing people to design and change the software over time. Our research runs in cycles where we introduce improvements, provide training and talk to the users to make improvements for the next cycle.
Over the past several years, we have made several attempts to build this service. We have learned that there are two main issues concerning the use of such a system: computer literacy of Deaf people and the text-to- speech and speech-to-text translation. We want to deal with these issues, because both issues introduce a lot of delay into the conversation. For example, the hearing user will have to wait for the Deaf person to type a message and also for the translation of that text into speech. Likewise, the Deaf user will have to wait while the operator translates the speech into text. We want to learn how to best deal with these kinds of delay in the conversation.
Why are we doing this?
We have already developed some software in the laboratory, but the reason we are doing this project is because we are interested in how we can use technology to help communication for the Deaf community. We are doing this as part of our research studies. We want to know things like, is the system useful, how can we make it better and how many times you use it. We will write about our experience of doing this work to help others who want to do similar work in South Africa, and even the rest of the world. We also want to show the Department of Communications the kinds of things that can be used to improve communications for the Deaf.
Who funds this project and how will it continue when we are done?
This research is funded by the Centres of Excellence at both UWC and UCT until the end of 2005. Please note that this is not a donation, and is not a commercial product. We are interested in learning how to use technology to help the Deaf communicate with the hearing over long distances. If SIMBA proves useful, we would like to convince the Department of Communications to support the project. We hope that the community will work with us to do this!
If you agree to join this project, I will ask you to sign a consent form, but you can leave the project at any time without any penalty to you at all. Participation is your free choice. You will be asked to use the system and allow yourself to be interviewed about the system at regular intervals when we visit your site.
Appendix C Consent Form – Deaf Telephony
I, ___________________, fully understand the Deaf Telephony project and agree to participate. I understand that all information which I provide will be kept confidential, and that my identity will not be revealed in any publication resulting from the research unless I choose to give permission. Furthermore, all recorded interview media and transcripts will be deleted after the data results have been analyzed. I am also free to withdraw from the project at any time.
I understand that the South African Sign Language interpreter who will provide the voice-sign-voice translation is bound by a code of ethics which does not allow him/her to repeat any information that is given during the discussions. This means that my identify will remain confidential within the group.
For further information, please do not hesitate to contact: William Tucker
Dept of Computer Science University of the Western Cape Private Bag X17 Bellville 7535 Email: [email protected] Cell: 082 494 8884 Name: Signature: Date:
Appendix D Rural Telehealth Action Research Cycles
This appendix chronicles the action research cycles for the rural telehealth field study analysed in Chapter 7. The action research cycles were linked to a series of communication prototypes called MUTI from 2004 to 2008 and can be grouped as shown in Figure D-1. This appendix has a section for each cycle. Each cycle is reported in standard action research stages: diagnosis, plan action, implement action, evaluate action and reflection. Within the groups, the reflection and diagnosis stages of successive cycles are combined. An overview table precedes each cycle, showing the timeframe, location, local champion, intermediary, prototype name, coder(s), supervisor(s), and references to technical details. A schedule of all field trips is shown in Table D-1. These trips are cited throughout the appendix by number.
Figure D-1 Rural telehealth field study prototypes
Prototypes for the rural telehealth field study fit into three groups. Each group was associated with a particular technical orientation, location and Masters student who led the implementation of software prototypes. Marshini Chetty built MUTI v1 at Tsilitwa to explore VoIP. Xolisa Vuza deployed MUTI v2 at Canzibe with video. Andrew Maunder ported MUTI v3 to run on mobile handsets, also at Canzibe.