Samfya

From Bjoern Hassler's website
Jump to: navigation, search

Samfya is a city and a region in the north east of Zambia. In December 2008 Aptivate participated in a Camfed summer school. Aptivate's role at the summer school was to provide ict training to 150 young Zambian women. (Aptivate news bulletin December 2008: "We currently have a team on the ground in Samfya, rural Zambia, delivering training in computer usage, email and web browsing to girls of school leaving age, as part of a Camfed-run programme to empower women. Camfed are also providing local women with long term access to IT resources, and supporting girls' education in local schools. Aptivate has been working closely with Camfed over recent months to support various aspects of their work.")

I should add that the present reflections are my own, rather than an official statement from one of the NGOs involved in the programme. Bjoern 15:18, 27 December 2008 (UTC)

1 Location, environment, health[edit]

The summer school itself took place at Lubwe High School. This google map shows Lubwe, as well as Lubwe High School. This map shows a closer view of Lubwe, while this map shows a closer view of the school. There is no article on Lubwe or Lubwe High School on wikipedia, but there is an article on Samfya and an article on Lake Bangweulu.

Transport to Lubwe from international destinations is via plane to Lusaka, and then either by car from Lusaka to Lubwe (10-12 hours drive) or by small plane from Lusaka to Mansa airport and then by car towards Samfya (about 45 mins on tarred road to get to the junction near Samfya) and then another hour from Samfya to Lubwe (on mud road). The mud road from Samfya to Lubwe is being worked on, and where the sections have made progress, transport is quite quick. In the future, this stretch of road should continue to improve. Lubwe High School is about 5-10 minutes by car from Lubwe. Leaving from Lubwe, the mud road is good initially, but deteriorates after the turn-off to the school. Transfer gear came in handy a number of times, particularly on wet roads.

At the moment (December), it's rainy season. Roughly speaking, there was a one-hour shower every few days, and it also rained through some nights. The landscape was very nice and green.

In terms of electricity, one of the pylons between Samfya and Lubwe were damaged fairly soon after we arrived, which resulted in no electricity for a good few days. But even after the pylon had been fixed, electricity was quite intermittent, so that we had to rely on our generator at the school to power the ICT equipment. Interestingly, the electricity falls off across Lubwe, with highest voltages at the southern edge of Lubwe (where the electricity comes in), falling off northwards (towards the centre of Lubwe).

Cannister with tap and soap for hand washing

Lubwe was said to have had running water in 70s, but much of the pipes were repurposed elsewhere at a later date. Today, water mostly comes from bore holes, and seems to be mostly pumped manually. It also seems that some water is pumped from the lake. Nevertheless, in some places there is running water: Some of the accommodation had water taps in sinks and showers, as well as drains, and some toilets were flushed with running water too. However, this was contingent on electricity: If electricity failed for too long, water tanks would deplete, and thus there would be no running water. In places without running water (or when the electricity was off for a while), water supply would be by the bucket both for showering ("bucket showers") and for flushing toilets. Usually there would be a large open water drum somewhere (say 100-200 liters), with a bucket next to it, so that you could take some of the water for flushing. For showers, water would be heated in a large metal drum over a fire. For hand washing (particularly before meals), there would usually be jugs of water (though not always with soap). Sometimes there would be a canister of water with a tap fixed to the bottom, which is useful for hand washing. For drinking water we exclusively used bottled water ("Manzi Valley").

In terms of mosquitos we took the usual precautions: malaria prophylaxis, treated mosquito nets, long sleeve/leg clothes, as well as liberally applying DEET at dawn. Overall there didn't seem to be a lot of mosquitos, and with the above precautions we hardly got bitten. We also used antibacterial hand foam where hand washing facilities weren't available. We did travel with first aid kits (including sharps kits and vent-aid), although reportedly Lubwe hospital has got hygienic sharps available. Some links with medical travel advice: FCO Zambia, NaTHNaC Zambia, Fit for travel Zambia, FCO HIV and Aids.

In terms of animal life: By all accounts, the lake does have plenty of crocodiles (though we didn't see any). There have been attacks in the past, and you definitely shouldn't swim in the lake near Lubwe. There were some reports of snakes, and while it's not common to find snakes in the centre of Lubwe, there are some about, including black mambas. Otherwise there are plenty of creepy crawlies: lizards, cockroaches, frogs, mice, bats, and all sorts of flying/crawling/hopping insects. Of course there are also domesticated animals, such as chicken, pigs, cows, and dogs.

2 Mobile phones[edit]

Mobile phone connectivity (via Zain) was really quite good: There was a mast right in Lubwe, and reception was pretty good throughout. (There was one day where the mast seems to have failed, but this only lasted for a day.) It seems to be quite easy to buy additional phone credit almost anywhere.

Interestingly, it was easy to set up a mobile data plan on a Zambian Zain SIM, and data rates (certainly when comparing email with sending text messages) were quite cheap. A text message costs about 300-500 Kwacha, while a short email (send via Google mail for mobile) costs about 30 Kwacha, making email a factor of 10 cheaper. (1 USD is about 5000 Kwatcha, ZMK). (For related comments, see mobile). In many ways, using google mail on mobile, or using Opera mini were the fasted ways of sending email or browsing the web. Although texts need to be entered via the keypad on my W810i, this was still faster than accessing the internet in non-optimised way via a dongle. (By the time you'd logged into web mail, got to the compose page, the message on the phone was already written and sent. Of course for longer messages the querty keyboard gives you an advantage, but shorter emails were faster on the phone.)

We also had a Zain dongle (Huawei E220), which worked flawlessly with windows and an Asus Eee pc. Out of the box we couldn't get the dongle to work with Ubuntu or Mac OS X, but we got some way with this, and might have managed to get this working if we'd spent more time on it. Apparently there is 3G connectivity in Lusaka, but in Lubwe we only got GPRS datarates at about 20kbps, which is slow for accessing non-optimised web-sites. In many ways it was much faster to access the internet via a mobile phone (and the associated specialised applications, see mobile). However, for general browsing and doing some email, the dongle worked fine.

Update: Lubwe now has Edge, and there is 3G in Lusaka.

For more about mobile phones, see below!

3 The ICT programme[edit]

We spent three weeks at Lubwe / Lubwe High School, as part of the larger summer school. During this period, we worked on three different activities:

  1. Work with four local co-faciltators to establish a skills basis for using the equipment.
  2. Together with the local co-faciltators run a 'long course', consisting of eight 90 minute sessions for 30 students chosen from the 150, covering email and internet.
  3. Together with the local co-faciltators run five 'short courses', consisting of three 90 minute sessions for 30 students per course, covering email. Because the course was run five times, all students participated in this.

The idea with this graded programme was to provide basic skills to all students, somewhat more skills to a smaller group of 30 (that would internet with the larger group of 150), as well as more in-depth skills to just four local trainers, who would then be able to run the resource centre (see below), and would be able to continue training the 150 students (as well as others).

The materials used for the email part of the course are available here: http://oer.aptivate.org/wiki/Email

3.1 The equipment[edit]

The equipment that Aptivate sourced for the project consisted of Aleutia E2 computers (plus screens), as well as two servers (and networking equipment). The Aleutia computers don't have any moving parts (solid state disk only, no fan), and are certified to work in more extreme environments. All sensitive equipment (such as computers and screens) were shipped from the UK in Peli cases, and it all arrived in good working order. Some of the less sensitive equipment was shipped in normal plastic crates.

The lab was set up with 15 Aleutia terminals, consisting off the Aleutia, mounted to the back of an LCD screen (similar to the arrangement shown here http://www.aleutia.com/images/profile-back.jpg), with full size keyboard and mouse. Because of the normal sized screen, it was possible to work at the terminal in pairs. The Aleutia were set up to do a PXE boot into LTSP off Ubuntu 8.04 LTS. However, the Aleutia could also work stand-alone as a fall back solution (again, booting into Ubuntu).

The equipment was selected specifically for robustness and low power consumption. For instance, the power consumption of the Aleutia E2 is around 8W. The total power consumption of the lab (15 Aleutia/screens, two servers + screens, projector + Aleutia/screen) was around 1.3 kW. We used six UPS units to be able to keep the equipment operating during transitions from mains power and generator, as well as to condition main power. This was absolutely essential. Main power usually wasn't at 240V, and was quite likely to fail randomly.

Overall, there wasn't much main power at all, so that we had to rely on a diesel generator. Given the current power situation in Samfya and Lubwe (and the cost of diesel, not to mention environmental concern), one should consider powering a permanently installed lab through solar power. Of course the details depend on how often power fails, what the local cost of diesel and mains electricty is, but a rough calculation suggests that a solar installation would become cost effective quit quickly, and could provide a good long term solution for permanent installation.

3.2 Open Source and Creative Commons[edit]

In principle, the Aleutia computers used are capable of running various operating systems. Why did we choose an open source operating system, such as Ubuntu?

Firstly, as described below, very few of the students had any ICT experience whatsoever, including no experience of commercial operating systems (such as Microsoft Windows). Also, from a users point of view, the most used applications will be web browsing, email, and document editing, perhaps instant messaging, say using Firefox, web mail / Google Mail, Open Office, and Skype. For those applications, it makes almost no difference to the end user as to whether the underlying operating system is say Ubuntu, or Microsoft Windows.

However, there is a significant, perhaps unexpected, advantage to using an open source system. Often barriers to knowledge sharing are invoked: Because knowledge is power, knowledge is closely guarded, and not shared. Of course in the content of the summer school (but also in the community more widely), this perception needs to be broken. The only way the community can make significant progress in ICT is if the existing knowledge is shared.

So for the ICT training, all software used was open source, and the training materials were available under a creative commons license, and we did draw attention to this. ("You can take the email booklet, CC-By, and do what you like with it, as long as you acknowledge. You can translate, you can run your own courses.") I would argue that this open philosophy helped to build a culture of knowledge sharing, and one could argue that for that reason alone it would be justifiable to choose an "open" technology approach.

You might also like to consider that all these activities are funded through aid programs. So to what extent is the "gift" a true "gift", or to what extent does it come with attachments and licensing conditions? By using "open" technologies, the gift is freer than it would otherwise be: It allows the recipients of the gift to maximise the impact, to reuse, replicate, and scale.

3.3 Connectivity for the summer school[edit]

For training, internet connectivity was via a BGAN, kindly provided by http://www.africonnect.com/. While this gives ubiquitous access to phone and internet, it's also expensive at about USD 7 per MB. There is a local youth skills centre with VSAT, but unfortunately their WIFI (normally supplied to Lubwe High School) was out of order, and was awaiting repair (more below).

The email training was all done with a local email server, so didn't require true internet connectivity. This worked very well for the training. (The email server was set up with url capture, so that the students would type exactly the same url, and would have exactly the same experience, as being online. Of course they could only email eachother and the trainers, but that turned out to be sufficient for the training.)

3.4 ICT background of the students[edit]

The majority of the students hadn't done any prior work on computers, nor had they used a type writer to type. However, most students did seem to have mobile phones, and some had browsed the internet on their mobile phone.

3.5 Methodology: Training vs. facilitation[edit]

A few notes about the methodology that was employed for "training" our four "co-facilitators". Consider a three-week ICT intervention in rural Zambia, where students have very little exposure to ICT. Essentially it's not possible to teach anywhere near enough 'content' to be able to deal with most ICT situations. So even if that was desirable, it wouldn't be possible. But even if it was possible: once you've trained the students, you have a bunch of trained students, rather than a bunch of trainers, and so the model doesn't scale.

One solution to this is to not teach. In other words, to employ a participatory approach, that doesn't aim to "teach students", but to "foster co-facilitators". So rather than covering as much ground as quickly as possible in terms of 'content', we decided to cover as much ground as we could in terms of participation, and letting co-facilitators discover things for themselves.

In terms of 'content' this made for slow progress. For instance, it took a comparatively long time for everybody to work out how to switch the computers on, how to wire the UPS, that you cannot loop ethernet, etc. However, by the co-facilitators exploring this on their own, they became capable of replicating the set-up, which, after all, is what's needed.

Initially our co-facilitators were somewhat frustrated with 'not just being told the answers' (especially when they perceived us to "have ICT knowledge" and perceived themselves as "not having ICT knowledge"), but this very soon flipped over into happy hands-on engagement with ICT, and a fantastic learning curve. This also very quickly led to an appreciation of a participatory approach.

3.6 Teaching the students[edit]

The same approach applied to training the larger groups of students. Rather than 'us' (from the North), teaching 'them' (i.e. the students from the South), with the co-facilitators just observing, we entered into dialogue with the co-facilitators about how we should be teaching, trying out different approaches with the students, and working out (with as little prejudice as possible) what works best. This meant that the co-facilitators (having only learnt the skills themselves) started teaching the students right from the start. Of course some support was required: The teaching load was such that we needed to rotate and support each other anyway, so it made it easy to come into dialogue about teaching style and content. The most important thing in the teaching was to not be dogmatic in terms of how to teach, but to be flexible and adapt to the particular needs.

What was remarkable is that the swapping and regrouping between facilitators (UK/Zambia) worked so well and seamlessly. This also included discussions that often involved a mix of English and the local language (Bemba). Again, this worked quite well.

Generally we taught classes of 30 students in an essentially 15 seat lab. This meant teaching students in pairs. Firstly, this reduces the need for hardware, but it also works well as a pedagogical tool. It means that students are encouraged to help eachother, and further foster a sharing of skills. Of course sometimes on person within the pair would take over (just because, say, they were able to type a bit faster). However, this provided an excellent opportunity to discuss the need to swap around, to give everybody a fair chance, and to let them explore, rather than just tell them what to do, or to operate the keyboard/mouse for them. With those discussions, and encouraging the pairs to swap round, the teaching in pairs aspect worked very well.

3.7 Stories and role play[edit]

With regard to teaching the larger groups of students, another interesting element was story telling and role play. Consider for instance the 'short course', consisting of three 90 minute sessions for 30 students per course, covering email. Within this course, we decided that we would need to teach some element of privacy, as well as cover spam.

Most of the students had never used email. So how do you go from "this is a computer/keyboard/mouse, this is a web browser, this is how you log in" to "emails can be intercepted and read at each server the email passes through, so you need to be aware of privacy" in the course of three sessions? When we introduced privacy issues the first time we ran the short course, it fell completely flat. We then settled on a more interactive and role play based approach, with some success.

The first example is to do with not sharing your password. We'd tell the students that only they need to know their email account password, and that they shouldn't share it with anybody. One of the facilitators would then team up with another facilitator, and they'd do a little performance, in which the first facilitator would make up reasons why the other facilitator should tell them their password, and they'd just keep refusing. We'd then ask one of the students to tell us their password. This is of course also a question of perceived authority: As the 'trainer', we have authority over the 'student', and so often they might just reach for their paper slip where the password was written down. Or if they initially refused, we'd say that this was different, and we'd really need to know it. Once we'd done this with a few students, they started to refuse to give out their password no matter what. This was a good way of making the point that you should not share your password with anybody.

The second example is to do with privacy, which is a more complicated concept. The analogy is that email is like a postcard, not like a letter. However, just talking about this wasn't helpful. So we'd have two of the facilitators writing postcards to each other, while another facilitator was the postman. The sender would write a postcard without critical information (at one table), the postman would pick this up, walk a few steps away from the table, read the postcard, find it unremarkable, and deliver it (to the recipient sitting at another table). The recipient would then write down bank details on another postcard, and again, the postman would pick up, this time also reading the postcard, finding the bank details. Then, rather than just delivering the postcard, the postman would stop to discuss this with a friend, to see how the information could be exploited. (Which also leads nicely into issues around spam.)

This may seem over the top, but to find out about computers and learn email from scratch in three 90 minute sessions is a lot to ask, and we felt that such role-play-based ways of introducing ideas worked quite well, certainly much better, and much more memorable, than just talking about it.

4 Lubwe Youth Skills Centre[edit]

There is a Youth Skills Centre in Lubwe, which also has an internet cafe, where courses are run. Internet connectivity is provided via VSAT. This employs an interesting model: The VSAT connection is shared with Lubwe Hospital, Lubwe High School, and a number of others, via directional WIFI. I don't know whether the cost is shared between those partners, but in principle this would be a good way of sharing the cost of the VSAT connection. An issue for the Skills Centre is power: Currently, there is very little power, and so the Skills Centre has to rely on a generator, which is expensive to run, and only runs for two hours per day. Thus there is only internet for two hours every day.

Nevertheless, the Skills Centre provides a good blueprint how an expensive connection can be shared. Imagine a VSAT installation (costing about $500 per month, say for a 400kb/s connection). Suppose you make an up-front investment (say via a donor) to power the VSAT and a directional WIFI installation via solar power. You then use the directional WIFI to share that connection with a number of people to reduce the cost. As long as the cost is affordable for everybody, you'd have ongoing internet with bearable costs.

VSATWifi.png

As mentioned above, cost of fuel is an issue, and if there was solar power, those issues could be alleviated (notwithstanding the need to replace deep cycle batteries ever so often). For completeness, the above image has a reference to solar panels. With the solar panels, the installation becomes independent of regional energy and connectivity issues: The only costs are "local costs", such as meeting the cost of the VSAT connection and the cost of maintaining the ICT equipment and solar panels. There is no dependence on regional conditions, and a lab like this could be set up anywhere (given sufficient funding, and basic conditions such as reasonable peace).

5 Samfya Resource Centre[edit]

At the end of the summer school, we went to the newly established Samfya Resource Centre, located at Samfya Basic School in Samfya. A subset of the equipment was set up by the four local trainers, to be available for summer school participants and cama members on an ongoing basis. The resource centre has got a VSAT connection for internet.

6 Further work in 2009/10 and 2010/11[edit]

The program consists of pairs of summer schools, run in December and April. Aptivate teams went out in December 2008 (as described above), and to the 2nd summer school in that year in April 2009. We then went again in December 2009, and April 2010 (for the 2nd cohort of students).

In December 2009 we introduced a trial for mobile-phone based email, further notes on which are available here http://oer.aptivate.org/wiki/Src/phones .

In December 2010 (3rd cohort) we introduced a FrontlineSMS-based system for collecting business data from the business groups. The phones introduced in the previous cohort (Nokia 2330) were very suitable for this. Business groups can thus submit their data as well as continue to communicate (and receive business mentoring) via gmail. We wrote a number of perl scripts to send credit to phones, which has the advantage of being able to send credit responsively depending on the amount of data received from a particular phone. Other scripts collate and reformat data, for easier evaluation by business mentors. The last session of the programme was in April 2011, which concluded the programme for Aptivate! The non-residential phase of the programme continued until the end of 2011.

7 Links[edit]