Below is a generalised conceptual model and process flow for organising qualitative data analysis in ConnectedText. It is intended to illustrate further – but in more general terms – the qualitative data analysis process I have described in my tutorials on how to use CT as a CAQDAS. An implementation of this model with a concrete example can be found here.
Here is how to read this chart. Each white box represents a ConnectedText topic (a single text document). “Research project dashboard” is the home page of the wiki, sitting at the top of the parent-child hierarchy and at the centre of the network of topics it links together (click here for a complete illustration of such a hierarchy). There are five levels of hierarchy represented in this image, with “Research project dashboard” being level 1 and “Case study 1 interview 1.1” being level 5.
The qualitative analysis (coding) process begins with Step 1 in the “Case study 1 interview 1” topic. In the first instance this is the topic that contains your interview transcript (or any other type of empirical material that you want to analyse). Using the coding process I described here and here, use the headings markup (=Heading 1= etc.) to annotate and code the material. In Step 2, use the “cut to new topic” command to move completed sections of the text into their own sub-topics, which will leave a link to them in the parent-topic.
In Step 3, review the codes for your coded material and aggregate and organise them under the heading =Conclusions= at the bottom of the topic. This is also a conceptual process of analysis, evaluation, and abstraction. It is up to you to whether you just collect your codes here or subject them to further processing and abstraction.
Step 4 utilises ConnectedText’s “include part of other topics” markup, which uses the notation
to include a section of text under a particular heading in one topic in the body of another topic. This operation also creates a type of a link between the two topics, by leaving an “Edit” button in the latter topic to lead you back to the source topic. This type of link will allow you to trace your steps back through the hierarchy and the “daisy chain” of “includes” and abstraction all the way from the home page at level 1 to the bottom at level 5.
Step 5 and any consecutive steps repeat the sequence of Steps 3-4-3 , by drawing conclusions and findings from previous conclusions and findings, which then get “included” in the next level up in the hierarchy, all the way until you reach the top. I like to compare this process of abstraction rising through the levels to bubbles rising to the surface of water or cream rising to the top of milk. The idea is that good stuff (meaning) finds its way to the top, which in our case is represented by the project dashboard. The project dashboard contain the research question. Ideally at the end of this process the answer to your research question should rise to the top and meet with it there, thus completing the search.
I’ve tried to use colours consistently to represent the various steps and commands described above. The “cut to new topic” command is represented by the blue arrows and the blue links left behind in the original topic (“Case study1 interview 1”). Red arrows represent the process of inclusion and connect the source topics with target topics. The “include” markups are also in red in the target topics. The green arrow represents the process of abstraction that takes place within a topic, by either drawing conclusions and formulating findings from the coded empirical material (at level 5) or drawing conclusions and findings from “included” conclusions and findings (at all the other levels).
“Included” content is marked in the same background colour (of its box) in the target topic as in the source topic, to indicate that the actual text content is identical and to also make it easier to follow the relationships between the inclusions.
I hope this clarifies further the concrete case study I worked through in my previous post.