No 'basic' or 'advanced' CAQDAS features

By Christina Silver on May 13, 2017 at 09:25 AM in CAQDAS commentary

by Christina Silver, 13th May 2017

This blog post is a response to Steve Wright’s reaction to this comment I made on Twitter on April 27th 2017:

“There are no basic or advanced #CAQDAS features, but straightforward or more sophisticated uses of tools appropriate for different tasks”

There are no basic or advanced CAQDAS tools, but straightforward and sophisticated uses of tools appropriate for different tasks

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 organize data files, to interrogate and visualize data and the way they have been conceptualized through coding, linking, organizing 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 organizing 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 visualization 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 visualized 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 familiarization 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 analyze 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...

May 16, 2017 Arrow1 Down Reply
Steve Wright

Thanks for posting this Christina - my extended response is here https://caqdasblog.wordpress.com/2017/05/16/on-agency-and-technology-relating-to-tactics-strategies-and-tools/ where i try to explore the potential limits of subsuming tools use to pre-defined strategy. Hope you find it interesting!

Looking forward to the books and being able to explore these ideas at greater length and apply them to teaching.

May 16, 2017 Arrow1 Down Reply
Steve Wright

Have also extended my initial thoughts on potential routes for defining simple/basic vs advanced features. It's kind of a preamble to the more substantive questioning about agency of tools and potential.
https://caqdasblog.wordpress.com/2017/05/15/basic-vs-advanced-features/
It doesn't really address the steps of your argument though - whether such definitions are useful or not, however I do think there's something important about complexity and that famous design prinicple from The Little prince that "There’s a famous quote by beloved author Antoine de Saint-Exupéry that says “Perfection is achieved when there is nothing left to take away.” - I think that's something BADLY missing in CAQDAS UX design at the moment and there could be something productive to design simpler interfaces with fewer confusing and complex options. And that would need to be predicated on an understanding of which features are needed when. There's a hint here perhaps of compensating for complex UX design rather than proposing ways to improve it and to me erasing the difference between simple and complex is not necessarily the way to start.







Testimonials

Christina's sessions were excellent and very well received. Feedback demonstrates that the students and staff who attended the sessions really benefited from and appreciated them. Thank you, once again, for preparing and delivering, what was clearly, a very successful package of training.
Rachel Torr, PhD
Head of Researcher Development University of Exeter Doctoral College