This blog post is a response to Steve Wright’s reaction to this comment I made on Twitter on April 27th 2017:
Thanks Steve for starting this conversation – it’s really important to debate these issues, and fun too! See Steve's comments here
The sentiment behind the Twitter post underlies the Five-Level QDA® method that Nick Woolf and I have developed. Our forthcoming series of books explain our position, so here I briefly respond to Steve’s comments.
No basic or advanced CAQDAS features
The term “feature” is not a technical term, but a common way of describing generally what a software program can do. CAQDAS packages have hundreds of features - including for example the ability to code qualitative data, to link segments of data to one another, to organise data files, to interrogate and visualise data and the way they have been conceptualised through coding, linking, organising etc.
Distinguishing between ‘basic’ and ‘advanced’ features implies that when learning a CAQDAS package it makes sense to first learn the ‘basic’ features and only later move on to learning the ‘advanced’ features. In developing an instructional design this begs the question of which features are ‘basic’ and which are ‘advanced’, in order to know which features are taught first and which later. We remain to be convinced how this distinction can meaningfully be made. What criteria are used to decide which features are ‘basic’ or ‘advanced’? Is it that some features are easier to use than others? Or that some features are more commonly used than others? Or that some features are used earlier in a project than others? I’m interested to hear what others criteria are in this regard.
We believe that attempting to distinguish between ‘basic’ and ‘advanced’ features is unhelpful. For example, our many years of observing how different people engage with CAQDAS packages has shown how subjective ease of use is because people experience using the same feature differently. In addition, each project is unique and uses different features - any definitive list of features that are more commonly used than others would always be an average that isn’t helpful to any particular researcher or any project.
It’s also not true that certain features are typically used at certain stages of a project – in one project a particular feature may be used at the beginning, whereas in another project the same feature may be used much later on. Some features are used throughout a project, but in different ways at different times. Some projects don’t use certain features.
Teaching ‘basic’ features first, and ‘advanced’ features later gives primacy to the software as an organising scheme for deciding how to use it - whereas we believe it is the needs of individual analytic tasks that should drive the way CAQDAS packages are used.
Straightforward and more sophisticated uses of tools
Our argument is that it is the use of a software tools, not the features themselves, that is straightforward or more sophisticated. Our change in terminology here is intentional.
Rather than framing CAQDAS packages in terms of features (the things the program can do) we frame them in terms of components – things in the program that can be acted upon. Whereas there are hundreds of features in CAQDAS programs, there are far fewer components (typically around 15) and actions (typically around 30 – some which are common to all components, others that are specific to certain components). Five-Level QDA therefore teaches components and actions. This involves various steps, which are explained in the forthcoming books.
We also do not use the term tool as a synonym for feature. In the Five-Level QDA method a tool is defined as the combination of a component and an action. Because components in CAQDAS packages can be acted upon in many different ways, the resulting tools are different – because of the uses for which they are selected or constructed. A selected tool is a straightforward choice of individual software operations and a selected tool is sophisticated use of software by combining software operations or performing them in a custom way. In the books we describe situations that call for selecting or constructing tools, and how to go about doing so – a process we call translation. But the point is that this is done according to the requirements of particular analytic tasks, iteratively as a project progresses.
The needs of individual analytic tasks drive the use of tools
To illustrate the point we’ll use the example of text searching, something that most CAQDAS packages enable. Text searching enables users to search textual material (whether interview or focus-group transcripts, literature files stored as PDFs, social media content, open-ended survey responses, observational field notes…whatever) for words or phrases.
Text searching can be useful for many different purposes, at many different stages of a project. In addition, many CAQDAS packages enable text searching to be undertaken in different ways and for the results to be acted upon in different ways.
For example you can usually search for an individual word, a collection of related words or phrases (either specified by yourself or – in some programs – suggested by the software) or ask for a list or graphic visualisation of frequently occurring words. These searches can usually be run on either an individual data file, a collection of files or across an entire dataset. And the results can usually be visualised in several different ways, and the context around each occurrence accessed, coded or outputted.
Whether and how text searching is undertaken therefore, depends on the needs of each particular project. For example,
they could be used at a very early stage of a project to facilitate data familiarisation or to contribute to the development of a coding scheme. The results may not be acted upon other than to provide an overview of content that informs a subsequent inductive interpretation
they could be used throughout a project to quantify the occurrence of particular terms or expressions and thus form a key basis of an analysis. The results may be acted upon only to count instances of words and phrases or also to code the instances so they can later be quickly accessed to analyse the context in which they are used
they could be used during later stages of a project to contribute to the process of checking that all instances of a concept have been accurately captured in earlier stages of work
These are just a few examples, there are many more ways in which text searching can be usefully employed. But their usefulness depends on the characteristics of the project.
Developers present their programs in terms of features to highlight what their programs can do. And they try to make the features visible on the screen so that it is as obvious as possible how to operate the program. But that is necessarily done according to their assumptions about how the software will be used. They cannot possibly anticipate all the different possible analytic tasks that users have. Focusing on software components and the actions that can be taken on them in order to select or construct software tools is the skill that Five-Level QDA makes explicit. It’s not a new or different way of undertaking qualitative data analysis but unpacks what expert users of CAQDAS packages unconsciously do. What we are doing is making that process explicit so that new users can develop the expertise they need for their unique projects without having to go through many iterations of trial and error, like we did!
Steve rightly raises the issue of the distribution of agency in all of this. We would argue that the analytic tasks that need to be fulfilled in a given project take precedence over the capabilities of the software features. The assumptions software developers use to develop their products are informed by users, via conferences and direct feedback. But users are the ones that use CAQDAS packages and our aim is to better enable them to make appropriate choices at appropriate times, according to the needs of their unique and idiosyncratic projects. The CAQDAS field is at a crossroads right now in many ways, not least in what the future holds regarding the assistance that CAQDAS can provide in analysis, and particularly in whether semi-automated assistance will have a desirable effect on the way researchers undertake analysis.
Look forward to your thoughts Steve - and of course, anyone else's too...