However, where data to be collected by fieldworkers are primarily quantitative in nature, here are my top 10 reasons (in no particular order) to use a good mobile data collection service (I’d like to include Mobile Researcher in that category but will let others decide that):

1. Capture once: With Mobile Researcher, you only capture the data once – in the field during survey conduction – it is then available for export as an Excel file (for example) once it has uploaded from the handset.
2. Validate in the field: Mobile Researcher allows you to design logic and validation rules which prevent many common erroneous entries (the clichéd “pregnant male”, accidentally skipped questions, etc) in the field. As there’s no separate data capture involved, there are also fewer points of failure.
3. Reduce latency: Data collected via Mobile Researcher is available for analysis as soon as it is uploaded – typically within a few minutes. This allows for faster analysis, near real-time data cleaning (automated or manual) and the opportunity to pick up anomalies while the study is in progress rather than weeks or months afterwards.
4. Conserve the environment: Obviously not using paper saves money and trees. We’ve had thousands of survey responses, each equivalent to 50 printed pages or more, captured using Mobile Researcher.
5. Reduce cost: In many cases, using Mobile Researcher is actually cheaper than paper (apart from the other benefits).  This is due to the removal of the exhausting print, distribute, collect and capture processes.
6. Increase flexibility: Surveys can be modified very easily – even with fieldworkers in the field. Survey design errors can be corrected, missed questions added, confusing questions rephrased, etc.  That’s very expensive and logistically taxing with paper.
7. Monitor activity: Using Mobile Researcher you can see what time surveys were started and completed. If the handset is GPS-enabled, we will also stamp the location of where the survey took place.
8. Improve data integrity: Once data has been captured using Mobile Researcher a full audit trail is maintained recording who modified data (if they even have permission to do so), when it was modified and what it was modified from and to.  Ensuring data is able to be cleaned without being incorrectly altered is more challenging on paper.
9. Preserve confidentiality: Once data has been captured on Mobile Researcher, it is securely transmitted to our servers.  Only authorised personnel you grant access to can view the data (there are other very granular permissions as well).  Our systems utilise the same level of encryption used by online banks.
10. Simplify survey conduction: Fieldworkers don’t need to understand branching or skip logic – this is built into the design of the survey.  Based on their response to each question, they are automatically directed to the next appropriate question.  This simplifies training substantially – particularly where prerequisites are complex.

I’ve covered some of the challenges involved in paper-based data collection in several previous posts but here I wanted to summarise the key factors I feel are important.

Perhaps there are other factors which are more important to you? Or are their areas where you disagree? Feel free to post your thoughts.

Having heard horror stories about eye-watering phone bills from friends and colleagues who had opted to take their South African SIM cards overseas, I decided to leave mine at home, thinking it would be a cinch to buy a SIM card on arrival and be up-and-running with fast, low cost internet via my mobile in a few minutes. On a recent trip to the Mobile Research Conference in the UK, that strategy worked out well for me. Unfortunately, Italy was a completely different story.

My initial surprise was how difficult it was to procure a SIM card in the first place. Walking through the streets of Rome, I must have enquired at 4 or 5 cellular stores – each out of stock with new supplies only expected the following week. I was quite keen on buying a Vodafone IT SIM since I use Vodacom here in South Africa which is partially owned by Vodafone. When I finally found a store which had SIMs in stock, they were for the TIM network – not one which I had heard of before arriving in Italy – but certainly a big player based on the number of adverts I saw on Italian television.

The TIM SIM card set me back €10 (about R110 at the time of this post) and included €5 of airtime. The €5 for the actual SIM is more than 50 times more expensive than in SA (you can buy a SIM for under R1 here). Of course the exchange rate plays a part here but certainly doesn’t account for such a large discrepancy.

Another interesting difference was that, whilst in SA buying a pre-paid SIM is literally a matter of pulling one off the shelf and proceeding to the cashier, in Italy I had to provide a copy of my passport and sign a document to buy one. As my Italian is limited to a few basic words and being able to count to 10, I have no idea what I actually signed. The anonymity with which SIM cards can be purchased in South Africa may well change with the introduction of new legislation here so we’ll have to see whether that remains the case. While I can understand the motivation behind such administrative procedures in an attempt to curb terrorism (I would imagine), it is certainly annoying and debateable as to whether this actually has any real effect.

In any event, upon securing my new SIM card, I hurriedly inserted it, hoping to send some loved ones messages as to my safe arrival as well as get in touch with the office. To my disgust, I was unable to do any of these things. Only after contacting the TIM call centre (which would have been impossible without the help of a friend with functional command of the language), did I discover that it takes 24 hours for the SIM to be enabled. Again, in contrast to the local situation, one would be up-and-running within minutes of cracking open the SIM. This delay may well be a result of the administrative procedures but it’s anyone’s guess really.

Once the mandatory 24 hour waiting period had passed, I was about to send and receive text messages. Unfortunately internet access would be a far tougher nut to crack. After a few days of travelling, I found a TIM store where I was given a few internet bundle options. I chose a 100MB / 100 hour package which apparently gave me access to 100MB of data or 100 hours of surfing, whichever came first. Although I’m not used to the concept of time-based internet browsing (all our mobile internet access here is based on data transfer), I paid the €25 for the package (more expensive per megabyte than even our highest out of bundle rate here in SA but still a fraction of the cost of international data roaming). The next stumbling block was getting the necessary Access Point settings for the TIM network. This shouldn’t be a complicated exercise but the confusion which arose between my mentioning that it was a South African phone, and the sales agent’s incompetence was somewhat comical. Eventually the necessary AP was configured and the connection with my twitter account and email was restored. And I holidayed happily ever after.

Well not quite. After spending what couldn’t have been more than half an hour that evening checking email, remoting in to a few systems, and some other bits and pieces, my connection died. Checking my airtime balance (not a simple task) revealed that instead of the bundle which should have been loaded, my surfing had eaten all my airtime which is why (I presumed) my session had been terminated. A colleague suggested that I wait a day and buy some more airtime by which stage the bundle should have kicked in. I did this, buying €10 and loading it a day or two later. Again, I was met with frustration. After following the instructions on the card to the letter, and receiving an SMS that my request had been received, a few hours later I was sent a message advising me that precisely 0 Euros had been recharged to my account. Retrying to load the card produced a message that it had already been used – the airtime lost somewhere in cellular cyberspace.

It was at this point that I conceded my failure to become an Italian mobile user and hauled my laptop to the nearest internet cafe. I got what I needed to do urgently done in about an hour and a half for €5 including a coke.

I’m not sure whether I was unlucky in my experience, picked a bad network, am an idiot or some combination but I was definitely left surprised, annoyed and unsatisfied with my Italian mobile internet experience. I was also left with a renewed admiration for our mobile infrastructure in South Africa – and indeed in Africa. We haven’t got much of what the developed world has in numerous other areas but in terms of mobile technology, I’d say we’re streaks ahead – and that’s something to be proud of. Of course we shouldn’t get complacent – there’s a lot still to be done and pricing needs to be reduced drastically but, in the context of mobile internet connectivity and the upcoming 2010 world cup, I think foreign tourists will be pleasantly surprised.

On several occasions, I’ve had the experience where, after a survey has been sent for translation (and we were assured no further changes would be made), the inevitable “last” few modifications have followed soon thereafter.  Such changes could be as a result of mistakes made in the design of the original survey or based on feedback received from survey pilots.  In other cases, stakeholders who hadn’t been involved early on in the process suddenly want to add their feedback.

Short of sending surveys for complete re-translation every time a change is made, maintaining synchronisation between translations is difficult and frustrating – not to mention costly. This complexity increases exponentially with the number of additional languages.

Our approach

To overcome the logistical nightmares which often accompany multi-lingual surveys, we focused on three key areas.

Firstly, we built the survey designer to give users the freedom to design in any language and easily switch from one to another. The key point is that the structure remains intact, regardless of the language you’re working with. Logic, question order and constraints remain unaffected by the language. Only the text shown to the fieldworker changes.

Secondly, we decided to take a very practical view on the actual translation process. While it’s true that at some point in the future (watch this space) we may provide “fancier” and more collaborative mechanisms for translation, for now we settled on the concept of translation tables.

A translation table is simply an Excel export of the text used in the survey. There is a source language (e.g. English) and a destination language (e.g. isiZulu). The spreadsheet produced by the system, contains the source language for the translator as well as a cell for the translated equivalent. This file is sent to a translator who opens it and simply fills in the blanks. Upon returning the file to you, all that remains is to upload the file and the translated text will be imported and stored for the specified language.

Should a question change, the translation table is simply regenerated and sent to the translator. All their previous translations will be provided with highlighted cells indicating where their input is needed. Once their changes have been made, uploading the file overwrites the previous translation text.

The final step we took was to allow the generation of translations for any source and destination combination. Assume you have a survey which, for example, needs to be available in 3 languages: English, Afrikaans and German. You may have a translator who can speak English and Afrikaans and another who can speak Afrikaans and German. The translation functionality in Mobile Researcher allows you to export a translation table for English-to-Afrikaans and, once the Afrikaans translation has been performed, a table for Afrikaans-to-English.

Translation is an area we are planning to give a lot more attention to in the future. I think we have some really neat ideas which I’ll share with you in future posts. Hopefully as things stand currently, you’ll find the existing functionality a huge help.

In the first stage of the field research process, the metrics are usually determined – the question “What data must be collected?” is answered.  Once this has been decided on, the surveys (aka questionnaires or forms – depending on function) are designed.  The goals which survey designers should be cognisant of during this process are:

• Surveys are structured in an unambiguous manner which does not make their responses subject to fieldworker bias or (mis)interpretation.  Factors such as localised terminology, advanced logic and respondent fatigue come into play.
• The collected data is easy (or at the very least possible) to analyse.  Tables are a common favourite amongst designers who are used to deploying surveys on paper because they use very little space – but they can create tremendous challenges when trying to unravel them at a later stage.

In the majority of cases, the design process involves multiple stakeholders (such as principal investigators, consultants, ethics committees, etc) and the design tools used are often run-of-the-mill word processors (such as Microsoft Word or OpenOffice).  Countless versions (and I use the term version rather loosely here) are emailed from one stakeholder to the next with limited regard for change control. 

Without a dedicated survey design tool, asking questions in a consistent fashion and the way in which the logic is described to the fieldworker can vary significantly – even within the same survey.  That’s bad news for data integrity.

If a change has to be made to a survey (and that occurs rather frequently) such as the addition of a new question, or removal of an unwanted one, it often necessitates a thorough check of the entire survey to ensure that skip logic references and numbering still make sense.

Our approach

When developing the survey designer component of Mobile Researcher, we decided to keep the existing conceptual model of a designing a survey on paper.  Designers lay out their surveys section by section and can select from a variety of question types.  We felt that it was a better idea to pass the complexity of survey logic on to the designer rather than leave it to fieldworkers to follow instructions.

Instead of writing out instructions which fieldworkers need to interpret or follow, the survey workflow (logic) is built into the design of the survey itself. This logic is not actually shown to the fieldworker but is evaluated and executed by the mobile application on their phone.  The fieldworker is only ever presented with one question at a time.

Using a consistent approach to survey design improves efficiency and reduces the likelihood of errors being introduced by confused fieldworkers.  A caveat to the approach is that survey designers need to think clearly about how they’d like the survey to flow.  Although the designer is intended to be intuitive to use, there is no substitute for logical thought.

Somewhat obviously, the challenges differ somewhat depending on the nature of the data collection exercise but, in general, there is a great deal of commonality.  In a series of discussions on the challenges of paper-based field research, I’ll use the scenario whereby a fieldworker interviews a respondent to collect the necessary information (interviewer administered survey).

In a typical field research exercise, there are several key processes which occur in a reasonably sequential fashion.  An obvious observation is that each process has outputs or deliverables which feed into and impact on subsequent processes and thus the final outcome.

Some of the processes and activities which I will cover in separate posts include:

• Survey design
• Translation
• Deployment
• Conduction
• Collection
• Capture
• Cleaning and processing
• Analysis
• Archive
• Quality control
• Privacy and confidentiality
• Management of distributed resources

Each process can pose significant obstacles and expense when making use of paper-based techniques.  By replacing paper with a suitable technology alternative, we can go a long way to improving the efficiency and quality of field research and data collection.

Innovative while at the same time providing stable software that allows us to have confidence in the data we collect.

This perspective is courtesy of a PhD candidate at the Human Sciences Research Council.

Mobile Researcher cut my research cost and time by nearly half.

 This perspective is courtesy of a PhD candidate at the University of KwaZulu-Natal.

Mobile Researcher has made my life as a researcher infinitely easier – it is one of the best discoveries I have made in the last decade.

 This perspective is courtesy of a Professor at the Univesity of Stellenbosch.