Data-level Work in ATLAS.ti: The Fluid Articulation of Segmentation, Writing, Coding and Diagramming

March 13, 2016

Download article in PDF

Author: Ricardo B. Contreras

Introduction

This article closes, for now at least, a series of articles touching directly or indirectly on data-level work with ATLAS.ti; in the 2014/4 issue I discussed the versatility of quotations in ATLAS.ti; in the 2015/3 issue I discussed hyperlinking and how it expands the boundaries of data exploration; in issue 2016/6, I gave recommendations on how to make the best use of the data segmentation and coding procedures that the software provides; and in issue 2015/8, I discussed diagramming and its role in supporting data-level work. And, finally, in this issue of Inside ATLAS.ti, I propose a model representing data-level work as the articulation of four sub-processes: data segmentation, writing, coding and diagramming.

The Model

Data-level work in ATLAS.ti involves two counter-acting forces.  In the one hand, fragmentation that derives from segmenting and coding the data, and in the other hand a process of integration that derives from writing and diagramming linkages and relationships. The figure below depicts this balancing act:

Figure 1. Balancing integration and fragmentation in data-level work with ATLAS.ti.

By approaching our work with ATLAS.ti by articulating segmentation, writing, coding and diagramming, we are avoiding the risk of reducing data-level work to a mere process of coding.  There can be a temptation to take a coding-reductionist approach and I can think of three reasons for that. First, because software in general, and ATLAS.ti in particular, has made it very easy to attach labels to segments of the data: it is, more or less, a simple matter of dragging and dropping. Secondly, because through coding we are achieving the highly satisfying outcome of reducing into a word or short phrase (following Saldaña 2009:53) the complexity of what a person is saying in a given segment by assigning meanings to the data; and, after all, qualitative data analysis has to do with interpretation and meanings.  And thirdly, I believe that there is a temptation to reduce data-level work to a process of coding particularly among those experienced with other software for qualitative data analysis because in most software, coding is the only option available to relate to the data.

I argue that by articulating segmentation, writing, coding and diagramming, we can expand rather than only reduce and integrate rather than only fragment. In this way, we can easily advance toward building a holistic understanding.  Also, by approaching data-level work in this way, you will avoid a typical mistake that I have seen in a few occasions, represented in the following archetypical questions: <And now, what do I do with all of these codes?>  <How do I make sense of all of this?>

Given that qualitative data analysis is by definition an iterative rather than lineal endeavor, the order in which you engage in these four sub-processes is not as important as the necessity to do so in an articulated way. In other words, it is important to engage in a dialogue with the data by engaging these sub-processes in dialogue.

The following figure represents the model:

Figure 2. Data-level work as articulation of segmentation, writing, coding and diagramming.

Figure 2. Data-level work as articulation of segmentation, writing, coding and diagramming.

I will now elaborate upon the components of the model.

Data segmentation

This involves reading and selecting segments from the source of information that call your attention.  These segments become quotations in ATLAS.ti. Each quotation becomes part of a ‘database’, in which they are identified by a unique identifier.  Quotations are independent objects, in the sense that they exist on their own: you may or may not code them, or at least you do not have to code them right away.

Writing

As you create quotations, you make an effort to say something about them in their Comment spaces.  Is there any reflection that comes to your mind as you read the segment?  Is there any insight that emerges from it?  Do you feel the need to further describe what the person is saying in that segment?  If you feel the need to write, you do it right away.  You can create an output of quotations with their comments.  This can become a rich source of information to build your understanding of the data.

Writing also occurs in the form of memos.  However, I like to say that memos are functionally different from comments: rather than being spaces where you write about what the person is saying in a given segment (you would do this in the quotation comment space), in memos you develop a narrative in which you elaborate upon your understanding of the whole or aspects of the whole.  Although memos allow for integration, I like to think of them more as an analytical tool rather than a data-level tool/descriptive tool.

Coding

In ATLAS.ti you have the option to code immediately as you segment the data, as well as the option of postponing the process for a little while.  As I like to say, you are not forced to commit to a given label (i.e., code) if you feel you are not ready to do so. If you decide to postpone coding a little and instead make good use of the option of writing comments on the quotations, those comments have the potential to illuminate your coding decisions. Further, you will arrive to coding by already having an understanding of the data, albeit preliminary.   And if you decide to code as you create quotations, you should still use the quotation comment space to write your reflections on the segment.

Writing is also associated to coding in the form of the code comments.  You should write code comments soon after you create them. Inserting the date and the time each time you write can be useful as a way of keeping track of your evolving understanding of the code operational definitions.  In ATLAS.ti 7 Windows this is facilitated by pressing Control-D, which inserts the date and time.

Diagramming

As explained in a previous blog article (click here), diagramming in ATLAS.ti is a rather rich process.  You can represent graphically the linkages between the different objects of the project that are created as you go through the regular process of working with your documents.  These linkages are known as ‘second-order links’.  But you can also represent graphically your understanding of the data, by linking semantically quotations to quotations and codes to codes.  These linkages have known in ATLAS.ti as ‘first-order links’.

Although the graphical representation of relationships is an intrinsic component of the analysis process, I make the argument that it is also a crucial component of data-level work.  As we segment the data, write, and code, we need to frequently visualize how elements are coming together, how they are connecting with each other and thus configuring the whole.  These visualizations illuminate and enrich data-level work by providing a necessary integrated and systemic view of the data.

Conclusion

To finalize, let me emphasize the importance of establishing a strong dialogue with the data.  Although apparently more labor-intensive than approaching data-level work through coding only, articulating segmentation, writing, coding and diagramming can pay off by allowing you to ground analysis on rich description.  As you do that, chances are that you will be able to achieve a good level of understanding of the phenomenon under study.  Of course, the decision about how to approach your work in ATLAS.ti is always yours: it is shaped by your research design, methodology, and even pragmatic considerations such as how much time you have available for the analysis.

Reference cited

Saldaña, J. (2009). The Coding Manual for Qualitative Researchers. Los Angeles: SAGE Publications, Inc.

About the author

Ricardo B. Contreras is an applied anthropologist with research interests in migration, community health, and qualitative methodology.  He is a consultant in ethnography and qualitative methodology and director of the training division of ATLAS.ti Scientific Software Development GmbH. He lives in the city of Corvallis, Oregon, in the United States. Ricardo can be reached by email by clicking here.

Share this Article