Posted by s.aragon on 16 October 2018 - 9:34am Image courtesy of Andy South

By Andy South, Software Sustainability Institute Fellow.

Training people to use software is not straightforward. I imagine most of us can remember courses that have gone well and not so well. I’m going to make a couple of suggestions for things to consider when developing software training based upon our recent experience.

With the Liverpool School of Tropical Medicine and the Center for Humanitarian Emergencies at Emory University in the US, we (Sophie Dunkley, Michelle Stanton and myself) developed and delivered a series of week long training courses on dealing with spatial data for mosquito control staff in Latin America and the Caribbean. The GIVeS (Geographic Information for Vector Surveillance) courses improve the capacity of operational staff to deal with geographic information in their day to day work using freely available tools, such as QGIS. Rather than targeting a single narrow problem with a specific tool, the courses aim to develop flexible skills that can be used to tackle a range of problems. Between April 2017-2018 we delivered seven weeks of training to a total of 141 participants from 31 countries. The course materials are openly available, currently in English and Spanish, under a Creative Commons Attribution (CC-BY) licence.

These courses have a slightly different focus to Software Carpentry training workshops (and my recent experience) in that a) they focus on software with user interfaces rather than command-line or code, and b) they are (mostly) for operational public health staff rather than researchers. Nevertheless there are issues in common with software training for researchers.

We got very positive feedback from participants and in the formal course evaluation performed by our collaborators from Emory University. We think this was due to a range of factors including that we made the training very practical and hands-on, focused on freely available software, taught in the local languages (Spanish, English or French), made initial examples very simple, and provided a hard-copy manual and USB containing all the training materials. It also really helped that we had an excellent, dedicated course organiser, so as instructors we didn’t have to worry about admin such as room bookings and travel. Learner motivation was really helped by having local senior staff supportive of course objectives and present at the start and end.

I’m going to explore two specific issues here that may be useful to others. The first was a success that we developed based on initial experience and the second tripped us up a couple of times.

1. Allowing supported time for learners to work with their own data

Our courses lasted for five days, and we scheduled most of the final day for learners to work on their own data. In the preceding days we started with very simple example data to avoid distraction from the early concepts we wanted to focus on. Midweek we had some exercises in collecting data but the final day was reserved for confronting data that learners had brought from their day jobs.

 We challenged all learners to show a few slides to the group by the end of the day. We set them off with pointers and encouragement to seek help from the internet, colleagues in the room and the two instructors. We used a simplified version of the sticky-note system that will be familiar to anyone who has attended or taught on a Carpentries course. Learners who had a question put a coloured sticky-note on their computer screen. The two instructors dealt with questions when they could. The sticky-note allowed learners to keep working without needing to have their hand up or standing in a queue to get the instructors attention. Sticky-notes also allowed the instructors to gauge how many people in the room were waiting for input.

We found this day created an atmosphere of purpose. Learners were keen to use what they had learnt to produce an output they could show to the group. It allowed learners to apply what they had been taught in a semi-supported environment, providing a bridge to continuing on their own after.

A lot of our work on the final day as instructors was trouble shooting. Spotting that a file wouldn’t import because it wasn’t in the right format, or that two fields wouldn’t join because of a typo, a capital letter or an accent. These are issues that may take an instructor a few seconds to spot but could be an insurmountable barrier to a new learner when they have returned to work. It is also an opportunity to teach self-reliance. What do we do when something doesn’t work? We look at an error message, google it, or submit a question to Stack Overflow. When working with learners, we showed that we didn’t know the answers to all their questions and demonstrated how we used internet tools to try to solve them.

The final day worked well in terms of the motivational dynamics of the week too. Learners all produced something, presented it to the group and bowed to the applause. Local senior staff attended the presentations then we concluded with awarding certificates. Learners left with a sense of achievement and knowing that they could use what they had learnt. For our five day course devoting a day to this worked well, if you are teaching a one day course devoting an hour and a half at the end could work similarly.

2. Being aware that software can behave differently in different countries

A second, smaller, thing we learnt was associated with the humble CSV file and internationalisation. The data-hackers low-fi data file format of choice, the comma separated values (CSV) file, is unfortunately not actually separated by commas in countries where the comma is used to indicate a decimal point. Whilst I was vaguely aware of this before the course, it still caused us problems when learners were running our exercises on local computers.

We had an exercise where we got learners to edit a text file in Microsoft Excel, save it as a CSV then add it to QGIS as a map layer. We had tried out this exercise numerous times and got others to go through it for us. When we got to it in class in Colombia, a sea of sticky-notes appeared on screens as the learners found that what they were seeing wasn’t as we had described in the manual. The CSV file that we had saved on our English speaking pcs was delimited by commas. The file our learners had saved from their Spanish versions of Excel was delimited by semicolons. It is not difficult to accept CSV files delimited with semicolons in QGIS but we hadn’t prepared learners for it. You need to tick a box on an import screen and allow for personalised delimiters and tick another to specify that the decimal separator is a comma. I quickly learnt what the Spanish word for semicolon is (‘punto y coma’ in case you ever need it).

Because we wanted to be clever and show that we learn from our mistakes we modified the manual before our next course in Guatemala a month later, indicating that learners needed to select the tick boxes mentioned above. Again we got to that point in the exercise and the sea of sticky-notes appeared. What could be happening ? This time we were in a computer room and most users were using the lab computers. Checking them we found that they all had English versions of Microsoft Office Excel installed, so the output file had gone back to being delimited by commas again. Doh! In the next version of the manual we tried to cover both of these possibilities, while at the same time not overwhelming learners with too many technical details.

This is simply a recommendation that you be aware that even very simple things can be different on computers speaking different languages. It can be a learning opportunity to demonstrate this (rather than the panic of trying to work out why your carefully tested exercise suddenly isn’t doing what you expect for 20 learners in a class).

What next ? Towards sustainability through modularity ?

This was a successful series of training courses targeted at a narrow user-group to a set timescale and developed by a small team. The materials have been made available under a Creative Commons Attribution (CC-BY)cc-by licence, but we are aware they could be made more discoverable and useful. We are keen to develop the materials further, and are awaiting one funding decision and on the lookout for further funding opportunities (suggestions welcome).

I’m impressed by the scale and reach of The Carpentries – we are much smaller and so far have focused on one contract. We are now looking at how we can use what we have already to pursue opportunities to do more. I really like the recent ten simple rules for collaborative lesson development paper. We feel we’ve done well on rules 1 and 7: identifying our learners and evaluating the training. Now we are looking at how we can make our resources more modular (rule 2) so that they can be more useful for ourselves and others in the future. If you are interested, or have any questions, do get in touch.