“Translation” is the key concept in our Five-Level QDA method, so it’s important to know what it means.
The word just showed up in the title of Susanne Friese’s blog post on the ATLAS.ti website – “Translating the process of open/initial coding in Grounded Theory” – and Susanne ended by inviting readers “to read more about this process of translation” in our textbooks on the Five-Level QDA method coming from Routledge in September. But as Susanne uses the word “translation” in a very different way from us we want to clear it up right away.
Susanne describes how the various kinds of coding described by Grounded Theory writers could be implemented in different ways in ATLAS.ti. She calls the various kinds of coding “methodological tasks”, which I think is a good term. She then suggests alternative ways for using ATLAS.ti’s features to accomplish those different methodological tasks. We would suggest that the word “implement” captures what she is describing. Our problem is calling it “translation”, because we introduced that term with a specific and very different meaning. It’s our responsibility to clarify this in the transitional period between telling people informally about the method and the publication of our textbook which spells out in detail what the terms refers to.
Translation refers to a different level of the research process from the methodological tasks Susanne describes. All research projects start with a methodology – could be Grounded Theory or something else. In the Five-Level QDA method we start with an analytic plan to answer the research question using the methodology. This is the strategies level of the project, and it leads to a series of “analytic tasks” to be accomplished by using the software.
The concept of an “analytic task” is highly specific in this method, it is not a general term for “something to be done in the analysis”. What is specific about it is its context and its level of detail. An analytic task as we use the term is unique and specific to its context, in other words, to the research question. So for us “open coding” is not an “analytic task”. “Analytic tasks” are also at a specific level of detail – not too general and not too specific – so that they can be best accomplished in the software with an eye to what may be coming next. Our textbook provides guidelines and lots of examples for how to write analytic tasks in this way.
What is important here is that it is a specific “analytic task” in its context – not a generic “methodological task” – that is translated to a software operation. It is accomplished by specifically matching the units of an analytic task to what we call a “component” – a “thing” in the software - rather than to one of the higher-level features of the software. This process ensures that the software is used creatively and is harnessed in a powerful way in each unique project.
By the way – this is what long-time expert users of these programs already do unconsciously. We are just making the process explicit and conscious. When the textbook is published it will become more clear what we mean by “translation” and how it is accomplished in practice.