As this new edition of Handling Qualitative Data went to press, the field of qualitative computing celebrated a 25 year anniversary. A quarter of a century ago, the first international gathering was held for those interested in using computers in qualitative research. You can read here the contributions to the anniversary conference, and evaluate for yourself how the field has grown and the directions of software development. And reflect, please, on the information that this software is no longer radical, now largely normalised, and should be regarded as old software.
It's now widely assumed that qualitative researchers will use specialised computer software. As you'll find from Chapter 1 of Handling Qualitative Data, the book doesn't require that readers are using any particular software but it does at each stage discuss the challenges and opportunities you are likely to meet with software. Like most researchers, it expects that they will use some computer program. I expect that too.
This is not, I assure you, because I spent two decades developing qualitative software. On the contrary, that experience taught me to be much more wary of the risks to research projects from software use, and much more reflective about the motivations and abilities of commercial companies providing research software, than most observers would be. The sections below are designed to help researchers approaching qualitative projects to decide why they would want to do this, and then choose well the tools they want to use.
Should you use qualitative software?
Well, of course. All researchers will use some software. But should you use one of the specialist packages for qualitative work? (The products referred to as ‘qualitative computer packages’ or as QDAS or CAQDAS packages?)
Before taking that step, seriously reflect on the other ways you use computers, for communicating, reflecting, reporting, searching and exploring. These are the tasks associated with qualitative analysis. Do some thinking about which of these tools please you and help you, which extend your skills, and which impede your life and work. Approach the specialist software in this context. Do you need them? Do these packages offer to improve or impede your knowledge of data and your ability to explore data records and see patterns and meanings? Check out the comments on this site, as the contributors reflect back on their use of software. If you are new to specialist software, or concerned about the effects on your research, talk to others who have used it.
Twenty five years ago, most qualitative researchers were strangers to computers. The qualitative software packages were designed to provide a safe box to contain all your data records and thinking about them. By working with a qualitative software package you work within that box. For most users, data records or summaries of them have to be ‘in’ the program before they can be explored and analysed. This makes the learning process more challenging for many researchers, as they can’t get started until they can manage the software, and often then feel distanced from their project once it is ‘in’ software they are still learning.
There is a sharp contrast with how, these days, all researchers manage their personal and professional data electronically, in a wide range of apps and packages, moving freely between them. So the first advice is: don’t feel constrained to the stable of specialized qualitative computing tools. To explore the range of digital tools that may be familiar and useful, go to Paulus et al (2014).
Most qualitative researchers now use some specialist software, and most probably should. My exception to this assumption is researchers who are incompetent on computers and terrified of them. It's now very hard to be there and still researching. If you don't come into that category, it's highly likely that there is software that would help your research greatly, save you an extraordinary amount of time and allow you to do things with your data that couldn't be done manually. So long as you learn it and use it well.
But there’s the rub. Learning can be a long and infuriating process, especially if you start learning after your data records are building up. And using these software packages well is not the experience of many, even most users. These pages are designed to help you approach the packages informed, and get to use them well.
What's the state of the art?
A stranger to the current stable of qualitative computing programs will be struck first by their similarity. All retain the ‘boxing’ of a project within the software, and all to some extent rely on coding and retrieval of coded passages. This similarity within the stable is a startling contrast to the methods literature; qualitative research has always contained a bewilderingly wide range of methods for making, handling and making sense of qualitative data.
This convergence of qualitative programs on a common approach is of course disappointing, but also easily understood. The early years of debating computer applications and developing them were hugely exciting. But rapidly, once researchers accepted software, this became a highly competitive and somewhat commercialized area. Convergence on the most commonly required techniques – especially coding – was one result. Another was a me-too mode that meant all packages raced to add a feature or new technique once it appeared in one product. Widespread normalisation of software use brought a rapid decline in debate and this in turn increased risk that researchers are limited, even exploited, by commercial entities. Profit-motivated push for site licenses meant many, even the majority of institution-based researchers had no effective choice of program, so missed the step of asking whether the licensed product actually did what they wanted it to do. The vast majority of advice for using software tools is written by their developers or by those who make a living teaching the package – so there is always a marketing purpose in such materials. Researchers whose professional expertise is in analysing meanings of words should use those skills in such situations.
Back in the research world, things could be better. Research tools require constant, collaborative and critical interaction between developers and researchers if innovation is to continue. So software users must be alert to corporate motives and vigilant in reporting directions that don't work. Novice researchers need relevant teaching and writing on methods. But debate about the impact of computing on qualitative research seemed early to get stuck in the mud of methodological territorialism and conservatism, at worst bogged in the boredom of a development process that was more about advertising claims than research challenges. Have you noticed the dates on those still-cited conference papers and books? (Many of which are collected papers of long-ago conferences I attended!) Some programs they discuss don't even exist now, and some complaints they made about software were answered in the first decade. Worse, other complaints have never been addressed!
There have also been few systematic and critical comparisons of the different effects of different products. Available online is an important special issue of the Forum: Qualitative Research (FQS) Vol. 12, No. 1 (2011), from an experiment in 2010 known as the KWALON conference, in which developers reported analysis of a common provided database using their particular software. It’s a useful read, especially if read critically.
There have been even fewer discussions of the impact of using a computer package – any of this stable of packages – on your research. An earlier issue of FQS (Vol. 3 No. 2, 2002) provides one of the best collections of thoughtful articles. There have been some scholarly attempts to critique the efficacy of different packages in particular research settings, e.g., by MacMillan (2005) in FQS (Volume 6, No. 3) on use of software for discourse analysis.
This book, and my previous book with Janice Morse, Readme First, attempts to fill some of these gaps. Throughout both, you are urged to think critically about whether you use software and what package you use, and consider not only the advantages but also the perils of using it. A careful summary under three headings – approaches, advances and alerts – ends each of the central chapters in Readme First: these summaries are provided on the website for Readme First.
Where to go for unbiased (and some biased) information?
In this situation how are you to find impartial, useful and non-marketing advice comparing software products?
The CAQDAS project at the University of Surrey is funded to provide an up to date (and regularly updated) overview of the current programs available, with discussions and links to developer sites. You will find on the CAQDAS site detailed advice, with a review of each package, for choosing a CAQDAS package
The only current authoritative overview book, Using Software in Qualitative Research: A Step-by-Step Guide, was written by the CAQDAS project's experts, Ann Lewins and Christina Silver, in 2007. It is now in a second edition. On the associated website are detailed illustrations and case studies, along with step by step tutorials provided by all but one of the developers. (In an indication of competitive commercial priorities, the current marketer of NVivo, alone, was ‘unable to contribute’).
Once you have explored the range of software available and made a choice, always go to the developer's site. This is as essential as is meeting the owner before you buy a dog. You need to learn not just about the software but about the people and commercial bodies producing, documenting, selling, marketing, supporting and upgrading it.
Several sites provide more extensive lists of currently available products that may be more relevant than those in the CAQDAS stable, with comments and contact details for developers. Text Analysis Info is a very detailed website with definitions and information about text analysis and software supporting it. A comprehensive and updated list of programs for qualitative analysis is provided here.
What are you looking for?
- Read the material on the developer’s website to find what the software is designed for. (Are its tools relevant to your work?) Do a quick qualitative analysis of the text on that website: is this pertinent and sensible information or is it marketing hype? What does the software actually do and what doesn’t it do? (If you can't work this out from the website, worry. Maybe they don't want you to know?)
- Download free software and use it. (No free trial software? Ask, and if it's not available, go elsewhere. This may be exciting software in the future but it's not safe to commit your project to it.)
- Most sites have tutorials available online. This is by far the best way of getting a feel for what it would be like to work in that software. The tutorial should let you actually do something in the software, preferably a lot, following clear instructions, using free downloaded software. (If they don't offer a free detailed tutorial, ask for one. If they are charging money for help you should get free, or if you can't learn enough from the online free resources, beware!)
- If the developers have an online blog or discussion, join it and listen in. Is this a buzz of interesting research discussion or a litany of complaints? Do the developers contribute and does it sound as though they know about qualitative research and actually like to talk with researchers? (If not, they are not likely to be producing software that does what researchers are trying to do.) Does it sound as though people get into trouble with this product, and if they do, do they get helped? Really helped? Still unsure? Ask the contributors to the discussion list.
You and your software: managing this relationship
OK, you have chosen software (or had it chosen for you). Now what?
It's highly unlikely that you will learn everything you need to do with that software package just by clicking around. It has to be learned, and the sooner you learn it the better. But you choose how you learn it. There are many ways to learn software and nobody should tell you what will work best for you. You probably know how you like to learn. Alone or with instruction? At your own pace or paced by a tutor? Playing with it or studiously doing something useful?
You may be helped by the reflections about the learner’s experience, and observations by trainers of their problems, provided on the website for Readme First.
There are – in person or online – courses in most products (many cost serious money). Think before you enrol in one. How big is this course, how relevant will it be to your work, how much individual attention will you get if you're stuck? Check out the tutor and their abilities; do they actually do research? (If not, will they be able to relate to the research goals you have?) For some researchers workshops fast track confidence, for others they sap it. Perhaps you'd do better quietly exploring tasks with a manual or a tutorial beside you. Or it may help to sit beside someone skilled in the software you are going to use and watch how they work.
But do learn it, and get to know this package before you put it to use. The best advice is to set out on some software learning task. You might use pilot or trial data (some developers provide this on their websites) in advance of starting your precious project in software. Or explore by putting your project proposal and literature review into the software. But do some learning before you trial it with your data. If you let learning happen (or not) as you work in your own data, you are likely to damage the data and end up hating (and blaming) the software. You will also learn only the software functions that do what you were doing without software (since these are the only tools you'll know to look for). At the end of the project, it's very frustrating to find that you could have asked quite different questions and made quite different discoveries had you known the software could support different ways of exploring and discovering.
A quick online guide to Stepping into Software
Once you've made a decision about products, and once you have learned what tools are offered by the software and you can use them fairly competently – use it. You'll forget what you've learned if you don't try to use it for your purposes. It is essential to have the software working for you, in your project. The next section of this site offers a quick online guide to ‘Stepping into Software’ – a ten-step guide, loosely following the ten chapters of Handling Qualitative Data. It aims to get you up and running in any of the software products whilst focusing on your own project. For each step, the advice takes you through two sets of questions. What to ask about your project? And what needs to be done now?
It's important to ensure that what you do is directed by your method and goals, not by the software. Any sophisticated software will offer tools to do far more than you – in this or any future project – will ever want to do. If you try to do everything it supports, and invent a reason for doing it in your project, the task will become impossible and (much worse!) the project will lose its purpose.
There will also be some processes for which software doesn't offer a tool – for example, thinking. Don't assume that if something can't be done in software it shouldn't be done.
And finally, a more general warning. It's increasingly common for researchers to learn qualitative software without first learning about qualitative methods. To do so is not wrong or immoral, but it does add massive challenges as they start to use the software tools. Like any powerful tool (think of the chainsaw), qualitative software can be easily used to make dramatic and unintended changes. If the operator is unsure why this matters, serious damage can result. More importantly, like any tool, its power is wasted if the user cannot understand the purposes to which it can be put. The most common result of researchers learning software without method is that they do very little with the software, reaching only for the most obvious processes, like coding, and continuing in them ritualistically. You can code for ever and the software won't stop you. You have to know the purpose of coding, in your project, to design your codes and coding to that purpose. Starting a qualitative project can be daunting, even if you are not also starting with a software package. If you have no training in qualitative research, but confront the need to make sense of your data, please start there, with the skills taught in Handling Qualitative Data, not with a software product. Why are you doing this project, and what outcome are you seeking? Now – can software help?