Summary and example of coding in ConnectedText

In this post I would like to summarise how I use ConnectedText as a CAQDAS for coding qualitative research material, and illustrate it with examples and screenshots. This current post should be read in tandem with the previous post that had laid out the coding process flow and discussed the main markups and commands involved. I will continue using the same example called “DRA case study.” If you would like to reproduce the following steps in your own copy of CT, I recommend you read my post on “Preparing for coding in ConnectedText” first.

To remind ourselves, here is a visual representation of the coding process using the DRA case study example:

Steps of the coding process in CT:

  1. Import your document into CT. Give it an appropriate name. (I will call mine “DRA1 Why CT”). Link it to the appropriate topic to place it in the hierarchy in the system. (I will put it under the “DRA case study”, which in turn belongs to the “empirical data” topic. All these relationships are created by simply typing the name of the topic in double square brackets. Entering [[DRA1 Why CT]] inside the “DRA case study” topic will create a link to the “DRA1 Why CT” topic and establish a parent-child relationship (if viewed in the Navigator pane).
  2. Open the topic you want to code (I will open “DRA1 Why CT”) in edit mode. Have the Table of Contents pane open on the left, and the Notes pane open on the right.
  3. Start annotating the content by using the headings markups (e.g. =Headings 1=) to record your codes (or observations). Note how the headings appear simultaneously in the Table of Contents.
  4. When a large enough section of the document has been coded and a clear enough thematic group has emerged (under a top-level heading), use the “cut to new topic” command to relegate that chunk of text from the current topic into a topic of its own. Use an alphanumerical system to name the sub-topic in such a way that it will show up under the parent-topic in the Topic list window. (I will name my sub-topics DRA1.1, DRA1.2 and DRA1.3 in my example.) In the Navigator you can see how the newly created topic is linked to its parent topic. By the end of the coding all the content in the parent topic (DRA1 Why CT) should be cut away, so that only links to the child-topics remain.
  5. Add an “include part of other topics” markup at the bottom of the parent topic (DRA1 Why CT) under a =Summary of conclusions= heading like this:
  6. Go to each of the child topics (DRA1.1 etc.), switch to view mode, copy the contents of the Table of Contents box in the topic pane (not in the Table of Contents pane), and paste it at the bottom of the topic under the heading =Conclusions=. You can also highlight the most important finding(s) in colour (e.g. yellow). You may want to apply bullet points or numbering to your list. You can also edit and reduce your list to the most important findings. Now if you go back to the parent topic (DRA1 Why CT) and switch to view mode, you will see that the “include” markup ((DRA1.1==Conclusions)) has now pulled in the text from DRA1.1 =Conclusions=.
  7. Repeat this process for each of the child topics, until all the text has been evaluated and all the conclusions have been included in the parent topic (DRA1 Why CT).
  8. Open “DRA1 Why CT” in view mode and review the included conclusions from its child-topics. Record your comments in the Notes pane on the right. Then copy them, switch to edit mode, and paste them under a new heading called =Final conclusions= at the bottom of the topic. Use colour highlighting to mark out the most important finding(s).
  9. Go to “DRA case study” (one level up in the hierarchy) and add “include” markups to collect all the =Final conclusions= from the documents the level below (DRA1 Why CT). Add a =Findings= heading below them, then review and draw conclusions as described in the previous point.
  10. Continue with this daisy-chaining process of aggregating and abstracting findings until you rise through all the levels of your hierarchy and arrive at your “Findings” topic, which should contain all the top level abstracted findings from your entire research study. The “include” markup leaves an “Edit” button in the topic in which it had been included, which means that by clicking on it you will be able to trace back where a particular finding came from, if necessary all the way back to the bottom of the hierarchy, the actual empirical evidence. And this is it. You have completed the coding of your material and have arrived at your findings, which hopefully will answer your research question.
  11. When you have finished coding a document and ended up with a number of sub-topics, you may want to take the opportunity to add “categories” to each topic, which is another way of classifying them and finding them in the future. “Attributes” and “properties” are additional advanced features for classifying and finding topics. Learn about them in CT’s Welcome project [2.9MB].

If you have any questions about this or suggestions to improve this process, feel free to comment below or email me using the Contact page.


4 thoughts on “Summary and example of coding in ConnectedText

  1. Pingback: CAQDAS model for ConnectedText | Dr Andus's toolbox

  2. Hi, Dr. I had some troubles with step 6. When I paste the content of TOC to some topic in edit mode I loose the structure, i.e., I get only the content not strutuctured as I see in the TOC. Did I miss something? Thank’s!

  3. Unfortunately that’s a limitation of CT (or my process). For me the eventual TOC in the cut-away topic was usually relatively small, so I just quickly reapplied some bullet points to reconstruct the original hierarchy. For adding bullet points to a list in one go I use the following Python script from the CT forum:,2475.0.html. BTW, I also asked on the forum to solve the above problem:,2493.0.html. And here was another related request:,2488.0.html.

    It might be worthwhile for you to consider that the forthcoming v. 6 of CT (which apparently should be out fairly soon) has a new feature called “named blocks,” which turns CT into a more direct CAQDAS tool, as “named blocks” (i.e. coded blocks of text) can be gathered by a query in another topic, automating much of the process that I was doing manually in the above post. But I’m no longer dealing with qualitative coding at the moment, so I haven’t spent a lot of time trialling the “named blocks” in v. 6 beta, though I tried it enough to be able to say that it does work and that it is a great feature.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s