CAQDAS model for ConnectedText

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

((topic_name==Heading_title))

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.

P.S. If you’re wondering, I used SmartDraw 2012 (which is on my list of favourite software) to create the above chart.

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.

Coding process flow in ConnectedText

In this post I will describe the process flow of how ConnectedText can be used as a CAQDAS for coding qualitative data (see my caveats and qualifications in the previous post). Unfortunately I can’t use my own CT project as an example because the information in it is confidential and it would just take too long for me to anonymise it. Instead, I will use the silly little example I came up with in a previous post.

Imagine you are conducting a research study into how people use technology. As part of your research, you have decided to interview me about my unorthodox use of CT as a CAQDAS tool. You have recorded and transcribed the interview. You have followed the procedure recommended in an earlier post to import the document into CT and use the suggested naming convention to entitle the topic containing the interview as “DRA1 Why CT.”

The “Why CT” bit is a reference to the main interview question: “Why do you use ConnectedText for qualitative data analysis?” This was the first interview in a series of interviews with Dr Andus, and it was “filed under” the Dr Andus case study, which in your CT is represented by a topic called “DRA case study.” We thus have a case study topic (the parent topic) and several interview topics linked from that topic as child-topics.

Using this example, I will now describe the overall coding work flow and the structure of the CT project before and after the coding, so you can have an overview before we delve into the details. The whole thing might not immediately make sense because you may also need to see how this was actually implemented in CT (which I will show you partly below, and partly in my next post). I strongly recommend that you try to replicate this in your CT test project, so you can experience how these various commands and markups work.

Here is a visual representation (created in VUE) of the coding process flow and the resulting structure of topic relationships. Please note that this follows the same overall CT project design I had suggested and described in this post. This chart just adds our concrete example of the DRA case study to the previous general model (this time only focusing on the “empirical data” and “findings” topic branches). It is a hierarchical structure with horizontal levels, where the Home page is level 1, “Empirical data” etc. is level 2, “DRA case study” etc. is level 3, “DRA1 Why CT” is level 4, and DRA1.1 etc. is level 5 (and it could go on as far down as you need it to):

The other thing to note about this chart is that it shows the end result of the coding process. Initially when you first import your document to code, there would only be level 1, 2, 3, and 4 topics. Level 5 topics (DRA1.1 etc.) grew out of the coding process. While you could set up the “DRA case study findings” topic in advance (I usually do), initially it would be empty (except for some “include” markup which sits there patiently until the topics they point to get gradually filled up with content) [more about the “include” markup below].

Let me now explain what we are seeing in this chart in full detail. As I said, it is a mixture of a process flow chart (follow the arrows) and an organisational structure chart (top-down hierarchy), which shows the elements of the CT project structure. All the boxes represent individual CT topics. Black arrows represent the parent-child relationships between the topics (links emanate from the parent topic to the child topic).

Red arrows represent the direction and operation of the “include part of other topics” markup, which is a critical command for this whole system to work. The “include” operation generally flows upwards from child topic to parent topic (remember my analogy of meaning emerging like “bubbles or cream rising to the top“?), except in the case of  the relationship between “DRA case study” and “DRA case study findings”, in which case they are “siblings”, sitting at the same level of the hierarchy.

Let me explain how the “include” markup works because it is such an important part of this system. When you add the following markup to the body of a topic in CT, it includes (pulls) the contents of the target topic in the current topic:

((target_topic_name))

More importantly (and this is the killer feature for this project design and process flow), you can also specify to only include text that has been entered under a specific heading, by adding the title of that heading to the “include” markup like this:

((target_topic_name==heading_title))

To use a concrete example from our chart above, we will need to add the following markup to the bottom of the text in the topic “DRA1 Why CT”, if we want it to collect the conclusions that have been derived from and gathered at the bottom of topics “DRA1.1”,  etc.:

((DRA1.1==Conclusions))
((DRA1.2==Conclusions))
((DRA1.3==Conclusions))

As if by magic, the text contained under the heading “Conclusions” in these sub-topics will instantly appear in “DRA1 Why CT”. Moreover, should you make any changes to that content in DRA1.1 for instance, the changes will be immediately updated in the “collector” topic as well. If you now take another look at the chart above, you will see that the red arrows effectively describe a daisy chain structure by which elements of some topics are included in the next level of topics until we reach the top level. Here is the whole hierarchy of “include” commands for the structure in the chart, cross-referenced with the topics they would need to be added to:

((DRA case study findings==Final findings)) - to be included in "Findings"
((DRA case study==Findings)) - to be included in "DRA case study findings"
((DRA1 Why CT==Final conclusions)) - to be included in "DRA case study"
((DRA1.1==Conclusions)) - to be included in "DRA1 Why CT"

You should also consider that this is not simply a mechanical operation but also a conceptual one. Each new inclusion at the level above includes content that has been extracted and abstracted from the topics at the level below. Meaning is becoming purified as it rises to the top, while retaining physical linkages (references) that allow you to trace your findings and conclusions all the way back to the ground level of the empirical material. You have to agree that that’s a brilliant functionality!

Let’s now turn to the other two features mentioned in the chart: the “headings” markup and the “Cut to new topic” command. The “headings” markup is also very important for this system because it is actually the notation by which the qualitative coding can be carried out the most easily.

[There are some other, more sophisticated ways of annotating a few words and aggregating them in another topic (such as “properties” and “attributes” – you can read up on those in the Help file or see them in action in this post by Steve Zeoli) but not of larger chunks of text (although this is likely to change, as CT’s developer is actively considering introducing a special command for marking up and collecting larger passages which would work very much like a standard CAQDAS feature).]

The “headings” markup is our best option now for coding, partly because it’s very quick and the results can be seen in real time in the Table of Contents pane, but also because the text under a given heading can be included in other topics, as I have explained above. Here is what you need to type to define a headings hierarchy (there are max. 5 levels) (or select them from the context menu by right-clicking on the selected text in edit mode):

=Heading 1=
==Heading 2== 
===Heading 3===
====Heading 4====
=====Heading 5=====

When I talk of “coding”, what I mean is adding your “codes” (annotations) as headings above the sections of the text that you are analysing. E.g. =Heading 1= could be your interview question. Then underneath you could add sub-headings, in effect annotating the interviewee’s responses. The 5-deep hierarchy allows you to structure the interview text in a meaningful way, by bringing out its implicit logical outline, which gets gathered and displayed in the Table of Contents pane.

=Why do you use ConnectedText for qualitative data analysis?=
==Because he didn't like the hierarchical nature of NVivo==
===NVivo separated the codes out of its original context===

Now, if you are doing this kind of coding on a 20,000-word document, sooner or later the Table of Contents might fill up the entire page in its pane. While it can be collapsed, the better option in fact might be to remove the coded content from the workspace altogether, partly to make it less cluttered but also in order to organise the content into thematic groups.

This is where the very handy “Cut to new topic (CTRL+ALT+N)” command comes in. Just highlight the section you have already coded that constitutes a coherent thematic group (e.g. the answers given to question 1, 2, 3 etc., if you have numbered your interview questions), right-click, choose “Cut to new topic” and voilà! – CT packs away the selected topic into a new topic, leaving a link to it in the original topic. This is where the Navigator window comes in handy, as you can monitor it visually how the sub-topics that you have coded and cut away gradually grow and appear at a sub-topic level.

When you are finished coding (marking up your topic with headings and sub-headings) and you have cut all of them away, all you should end up with in the body of your original document (“DRA1 Why CT” in our case) is a bunch of links to all the sub-topics (the double-square brackets signify that these are internal wiki links) (and you can of course give the topics more descriptive names after the initial code, such as “DRA1.2 about NVivo”):

[[DRA1.1]]
[[DRA1.2]]
[[DRA.1.3]]
etc.

Let’s say you started with a 20,000-word document (a 2-hour interview transcript). After coding, you might have ended up with 15 sub-topics on average with 1300-words each. Now you can go into each of those sub-topics (DRA1.1 etc.) and complete your evaluation of the codes and the content there.

The simplest way of doing this is to copy the contents of the “Table of Contents” (not in the TOC pane but in the view mode of the topic itself) in this sub-topic and then either paste it into the Notes pane for some further evaluation, organisation or pruning, or you can directly paste it at the bottom of the topic after a heading called =Conclusions=. Here you can carry out additional operations, such as turn this into a numbered or bulleted list or use highlighting to mark out especially important information. (You can also add a “Category” to the sub-topic itself, to have yet another way of classifying the content. See the Help file.)

Remember that only content that is under the =Conclusions= heading in the DRA1.1 sub-topic will be pulled into the parent topic, “DRA1 Why CT.” For this to work, in this parent topic you will need to include the markup ((DRA1.1==Conclusions)). It is best to collect these =Conclusions= from the sub-topics under a heading such as =Summary of conclusions=. Once all your coding is finished, all the conclusions from the sub-topics will be listed in the body of the parent-topic, “DRA1 Why CT.”

This is where the “reverse cascading” of the abstraction process begins, as now you will be ready to evaluate these collected conclusions from level 5, record your conclusions from these conclusions, e.g. by initally writing them in the Notes pane, and then pasting them under a new heading at the bottom of the “DRA1 Why CT” topic, called =Final conclusions=. These “final conclusions” then get pulled into the “DRA case study” topic, where you can repeat the whole process, draw conclusions from the conclusions of the conclusions and call them “findings” this time, under a heading called =Findings=. This in turn will be included in the “DRA case study findings” topic, the =Final findings= of which will eventually be included in the “Findings” topic itself. And that’s it. The meaning (bubble or cream) has reached the surface. Hurray!

I realise it might be a bit heavy to follow all this without seeing what the actual topics look like in CT. However, this post is getting quite long already, so I will summarise all the steps involved in this process in a final post, illustrated with screenshots.

Importing your data into ConnectedText

As part of this tutorial series on how to use ConnectedText for qualitative data analysis, in the previous post I have suggested that it might be a good idea to design and set up your research project and work flow in CT before importing the data that you want to analyse. Now we are ready to discuss how to import your qualitative research data into CT.

Please note that I won’t go into all the possible ins and outs of importing stuff into CT. You can read all about that in CT’s Welcome project (Help file), which is available here [2.9MB]. The topics of interest are “Importing text,” “Images,” “Movies,” “Embed Youtube video in a topic,” “Files,” “URL,” and “Application button.” Instead, here I want to focus on the organising of the import process, with some import tips that may not be found in CT’s Welcome project.

As I suggested in the previous post, I prefer to conduct the import process as part of the analytical filtering process of sorting out what’s important and what’s not. Importing stuff into CT is an opportunity to execute one operation of reduction on the long road of reduction and abstraction that leads to the producing of your research report or dissertation.

After all the entire qualitative research process is about reducing things meaningfully. You start out with collecting possibly millions of words (and hundreds or thousands of media and other types of files). Then the challenge is to reduce these millions of words (captured in your interviews, participant observations, collected materials etc.) into an 80,000-word dissertation, and beyond that, into 10,000-word journal articles.

For this reason I recommend importing material incrementally, as and when needed for the analytical process. Import stuff for one of your case studies or import one type of data (such as all the interview transcripts) and then organise and possibly even analyse (code) them before importing the next batch. During the analysis of the first batch you will get new ideas about how to organise the entire project, so that the next batch can be imported into a more organised space.

As you are importing stuff, you can use the Navigator to see which topic to link the newly imported material to. Effectively you are building a meaningful hierarchy, so that it can be easily navigated by just simply following logical links from the Home (dashboard) page to where you need to go.

The Topic list pane can also be used for introducing some order. For example, when you import a series of interviews belonging to the same case study, you may want to name the topics according to a convention using the same starting letters and/or numbers, so that they appear in a particular (alphanumerical) order in the Topic list.

E.g. let’s say you are conducting an interview series with me about my use of CT. After you had transcribed your recorded interviews in MS Word, you could start importing the Word files and naming the resulting topics as “DRA1 Why CT,” “DRA2 Getting started” etc. (DRA being the code for the “Dr Andus” case study and the number signifying the chronological order of the interviews).

Then when you are analysing “DRA1 Why CT” and you want to break it up into smaller chunks (new topics) using the very helpful “Cut to new topic (CTRL+ALT+N)” context menu command in CT (which will leave a link to the newly “cut away” topic in the parent topic), you can name the new topics “DRA1.1”, “DRA1.2” etc. This will keep all the topics belonging to the same case study next to each other in the Topic list, making it easier to find them (especially after you end up with thousands of topics a few months or years down the road).

Now, back to some of the mechanics of importing data into CT. “Importing” may not in fact be the right term, if by ‘importing’ you would expect files and their contents to be all included in CT’s project file, like it happens in NVivo for instance. As CT is a wiki (and works as a website), mostly it is only text, markups (e.g. from HTML imports) and scripts that actually get imported into a CT topic (which are all some form of text anyway). Beyond that what I mean by “importing” simply includes creating links in a CT topic to external files, such as image files, PDF, PowerPoint, Excel and even programme files. Even though the image will be displayed inside your topic, it is effectively linked in from outside of CT’s topic and overall project file.

Remember, CT is called “ConnectedText,” and there must be a reason for this: it mostly works by connecting textual information (although numerical information is also a form of text for CT’s purposes, as long as we’re talking about the contents of a topic). Why is this important? So you understand that when you “import” a file that is other than text, such as an image file or a PDF, those files continue to sit in a folder deep inside your PC and not inside CT. If you move them or delete them, it might break the file association and they won’t display or launch from your CT topic. One way to avoid this problem is to copy these files into CT’s dedicated folder in its own folder structure.

But I find that too much hassle and I don’t want to duplicate hundreds or thousands of files. Instead, I consider the importing/linking of an external file as a part of the analysis process. Once I have decided to review a folder on my PC and decided what to import from there into CT, I am done with that folder for ever. While I will leave it where it is for archival purposes and in order not to break the link path to the CT topic, I never intend to go back there and duplicate my effort. The whole point of importing stuff into CT is to continue the rest of the analysis and processing of that information inside CT, as the main tool.

As I said earlier, for me importing is part of the analytical/filtering process. Before I decide to link to a file, I open it, read it, analyse it and extract only the most important information to be copied and pasted into the body of a CT topic (see how I use NoteTab to clean formatted text and to repair broken lines in text copied from a PDF here). I do include a link to the given file at the bottom of the topic but not because I ever want to return to it to analyse it again but only as a reference, so I know where that information comes from.

This process can work particularly well when you are reading for a literature review. You only want to import the summary and some quotes from a 20-page PDF article and not all of its 10,000 words. And also, you probably wouldn’t want to have to do that process all over again a year later, when you want to remind yourself of that article. You won’t have to because the summary and the key quotes are now in your CT topic, with a link to the original file just in case.

Let’s turn now to the specific mechanics of importing some important file types. Importing text files is easy, and copying and pasting might be the quickest way of doing that. However, most people would probably keep their interview transcripts and participant observation notes in some kind of a word-processor file such as Word. If it’s unformatted text, a simple copy and paste will do. However, if you already have rich text formatting applied, such as headings and font formatting (bold, italics), and some images embedded, you will need to use an import procedure.

Although CT’s import tool (Project > Import…) includes Rich Text Format (.RTF) as one of the options, I wouldn’t recommended it as it haven’t produced good results for me. Instead (and this was a tip from a CT forum user), save your MS Word document as “Web Page, Filtered” and import it as HTML using CT’s import tool. This is what you need to do in Word and then in CT:

1. Open your Word document.
2. Go to File > Save As.
3. In the “Save as type” pull-down menu (right under “File name”) select “Web Page, Filtered.”
4. Change the name of the file to the intended topic name according to the naming convention I suggested above.
5. Click “Save.”

1. Open your CT project.
2. Go to Project > Import…
3. In the import wizard select HTML for “Files to be considered.”
4. Under “Source file” navigate to the folder where you had saved the converted Word file (now it’s an HTM file) and select it.
5. Under the option “If topic exists” choose “Create a new one”, to make sure you don’t accidentally overwrite a topic that you may have already imported and edited before.
6. Click “OK.”
7. If you hadn’t done so in Word yet (which might be preferable), then after the import you can rename the imported topic according to the naming convention I suggested above.

As for “importing” (i.e. linking) content that’s other then text, it’s a simple “drag and drop” of the file from Windows Explorer (or your favourite file browser such as Directory Opus) straight into a CT topic that is open in edit mode. CT will recognise the type of file and will insert the necessary markup automatically. If you drag an image file, it will add an image markup so that the image can be displayed inside the topic in view mode. If you drag some other file type (PDF, Excel, PowerPoint etc.), then CT will create a file link, and clicking on that link will open the file in its respective application.

If you drag a URL straight from a web browser window, CT will convert it into a URL markup and create an external link that can be launched either in CT’s browser or an external browser like Firefox. Finally, if you drag a .exe file, CT will create a button in view mode, on the clicking of which the associated programme will launch. Neat or what? There are some other possibilities as well, but for those you will need to read CT’s Welcome project (Help file).

The main thing to note here is that CT can become the main depository of all the information related to your research project because you can either import it in text form or create a link to it. CT will become the brain and the central nervous system of your research project. But it also has some other internal organs to help you distil the essence of your project, which can emulate the CAQDAS process knows as “coding your material.” But more about that in my next post.

Designing your QDA project for ConnectedText

If you have completed the steps suggested in the previous posts (here and here) for this tutorial on how to use ConnectedText for qualitative data analysis (QDA) (or if you are already a CT pro), then you are ready to move on to the next stage of the CT QDA process, which has to do with designing your QDA project for CT. I am suggesting that before you import and dump all your qualitative data and other notes in CT, it might be a good idea to come up with an overall shape for your project and work flow. It is certainly possible to ignore this advice and dump all your data in CT first and worry about organising them later. However, I found that being methodical and designing the project first and then importing data (strategically and incrementally) has helped me keep my head above the water – the data ocean, so to speak.

Let me first present you with my concept map (created in VUE) for the design of my PhD research project in CT, and I will explain how it works below.
Essentially what you are seeing here is a mixture between a top-down hierarchical model for organising topics in ConnectedText and a flow chart indicating a process flow (roughly from left to right) for the qualitative analysis of data and the production of the eventual report, in this case a PhD dissertation. At the very top sits the “project dashboard,” which is the tip of the data iceberg, if represented in this hierarchical model, or the central node of a flat network, if you try to visualise it as the home page of your personal Intranet system.

At the second (horizontal) level of the hierarchy (which are the topics that are linked to from the project dashboard/home page) you will find the main elements of the project. Let’s tackle these one by one.

“Meta project considerations” is the topic that contains or links to information that pertains to the overall organisation of the CT project, the work flow, the project plan and related tasks. This is the place to collect those thoughts and materials that are looking at the project from the outside or from above and are concerned with the overall design and operation of the system as a whole. (For example me reflecting on the design of my PhD project right now is an instance of such a meta-consideration. I will be including the above concept map under this main topic in my own CT project.)

The second main topic, “empirical data (case studies),” is the heart of the project and will contain the bulk of the material. It contains all the empirical data that I have collected as part of my research. It is organised into individual case studies, which contain such material as interview transcripts, participant observation notes and collected files (such as emails, PDFs, MS Office files or even URLs). The red arrows indicate the flow the qualitative data analysis process that I will be focusing on in future posts, showing how CT can be used as a CAQDAS. The main objective of the analysis is to extract findings from each case study, which will be eventually aggregated and evaluated in the fourth major topic, “findings.”

I have skipped over the third topic, “theory notes.” These include notes of all such reflections or interpretations that I have produced myself but which are not strictly speaking part of the empirical materials. It is debatable whether these observations should be included in the empirical data, if they were triggered by – or during – the data collection process. But I prefer to separate out material that was more part of the interpretation of the data than the data itself. Nevertheless, note the dashed lines which indicate that these “theory notes” are closely related to “empirical data” and feed into the “findings.”

While you are analysing your empirical data and evaluating your findings, simultaneously you will start having some ideas about the significance of these findings and how they should be presented later on. You might even want to select quotes to be included and discussed in the final draft itself. So the next two topic areas, “outlines” and “draft” are very closely related to the analytical process (from empirical data to findings) and start developing simultaneously with it. Hence the dashed lines coming out of “case study 1 findings”, which start to inform the outlining and drafting (writing) processes.

You might be in the middle of analysing an interview and have a sudden insight into how this material might fit into the overall or individual chapter outline, and you might even want to engage in some ad hoc writing and type up some paragraphs in the corresponding draft chapter topic. Nevertheless, outlining and drafting/writing will emerge as important processes in their own right, once the coding and analysis of the empirical material had concluded.

The final topic is an “inbox” for uncategorised and unprocessed material that had been imported into CT but has not been allocated to any of the aforementioned topics. I would generally advise against importing too much of such material, as it will just sit in CT and clutter the workspace. Regarding importing material, I found it helpful to work on one case study at a time and only import materials that relate to that case study. Also, I have treated the importing of material as a filtering process and a quality control process. After all, what’s the point of importing stuff that turns out to be utterly useless? It would just end up sitting in CT as dead weight.

Now, “inbox” needs to be understood metaphorically here, as CT is a wiki and therefore there are no folders or boxes into which you can drop stuff. Nevertheless, you can emulate an inbox in two ways: 1) either by creating a category label called “inbox” or “uncategorised” and append it to all new topics that need to be put into this virtual inbox, or 2) use a topic as an inbox and drop text, links to files and URLs into that topic. The same is true for all the other topic “areas”: they are not so much areas or folders as local networks of interlinked topics, for which the top level topic acts as the central node.

As for the overall project, it is essentially a process of trying to find an answer to a question. You can include the research question in your project dashboard, interrogate your empirical data with your chosen conceptual tools (theories), develop your findings, develop outlines to organise your argument, and write the eventual draft, which should hopefully provide an answer to your original research question. The great thing about CT is that it has tools for conducting this entire process in one place, within one software.

There are a few glaring omissions in my model above: a literature review topic, a conceptual framework (theoretical lens) topic, and a methodology topic. You could certainly include them here. I had worked on those phases of my PhD before discovering CT, so I haven’t had a need to include them in my CT project yet. However, as I will be moving onto writing up my dissertation, it is very likely that I will add in those topics and import the related material into CT as well. For the purposes of this blog and this CT tutorial I have decided to focus the above model on the qualitative data analysis process. However, it is easy for you to include those elements. All you need to do is type [[literature review]], [[conceptual framework]], and [[methodology]] into the body of the dashboard topic, and these topics will be automatically created for you and linked to the dashboard.

I have found writing this blog post a very useful exercise. This reflection allowed me to improve my model, as up until this morning it looked a lot less organised in fact. I didn’t have my meta considerations included in an organised way, neither did I have an inbox for uncategorised data.This type of meta-reflection on the design of your project and your work flow can be an important quality process in the ongoing development and improvement of your overall system.

Finally, let me include a couple of screenshots of the above model as implemented in CT. First, the edit mode (I have used a vertical tree view in the Navigator instead of the horizontal tree view of my concept map, so that it could fit into the left-hand-side pane. However, there is also a horizontal tree option in the Navigator, if you prefer that):

And then in view mode:

Please note that in the “PhD project dashboard” (or Home) topic only the words in blue are active links (e.g. “meta considerations“). The bullet-pointed text in black underneath (“CT project design” etc.) is only there to remind me what is inside that top-level topic (or link). Links to “CT project design” etc. are inside the “meta considerations” topic, which is currently not visible in the view window (as we are editing/viewing the “Home” topic), however the relationship can be seen in the Navigator pane on the left. Had I made those links live in the “Home” (PhD project dashboard) topic as well, it would have resulted in a messier Navigator picture, as they would have also showed up as part of level 2 hierarchy.

The Topic List pane on the right simply displays all topics in alphabetical order.

Setting up ConnectedText

In an earlier post I have discussed how to set up your desktop layout in ConnectedText, as part of getting started with CT. In this post I will offer a few more tips on setting up CT for general use but also for our intended purpose here as a CAQDAS tool.

One of the things that puts people off from using wikis in general and CT in particular is the need to use (and having to learn) markups. Especially if you have never learnt or used a markup before, it may seem too technical and daunting and even unnecessary in this day and age of icons and touch screens.

The good news is that CT makes it relatively easy to use markups. First, it uses a simplified markup language, so there is no need to learn a huge amount of markups. I only use maybe 4 or 5 markups on a regular basis. CT also reduces the need to type markups in a number of ways.

First, it offers a number of buttons in the header and commands in the right-click context menu that obviate the need to type the markup yourself.

Second, you can just drag and drop certain items, such as URLs from your browser and file links from your Windows Explorer, rather than having to type the associated markup. Some markup also gets inserted automatically for you if you are starting a list, such as a bulleted or numbered list or a list of comments. Finally, there is also something called “completion proposal,” which means that if you start typing a certain markup, it brings up a pull-down menu of options, and you just click on the markup you need to insert it automatically.

One complaint about having to use markups is that they disrupt the flow of writing or reading in edit mode. As far as the speed of writing is concerned, I think this might be more of an issue of perception stemming from the habit of clicking buttons and selecting menu items in the headers of standard office applications. While it may seem that it is easier or quicker to highlight a piece of text, go to the menu, select a command, and click on it, in reality that also disrupts your flow of writing because you need to take your hand off the keyboard, grab the mouse, move it, click on things, and then move your hand back to the keyboard. If you know the markup, it’s much quicker to just type the markup and achieve the same result, without your hand having to leave the keyboard.

But it is true that the presence of markup in the text itself may disrupt the comprehension of the text you are writing, after all you might be inserting some notation that looks like gibberish  (at least until you get used to it, which is another way of dealing with this problem: use it long enough for it to become second nature).

Fortunately CT has a feature that can somewhat alleviate this effect of disruption. If you select custom colours for specific mark-ups, they become more easily recognisable in the text, and your eyes will learn to skip over them and ignore them when you want to concentrate on the content of your writing in edit mode (and of course you can always just switch to view mode, if you don’t want to see any markup at all).

Here is how to select the custom colours for your markup: go to Tools > Options (or hit CTRL+O) > Editor, and you will see a box called “Colors,” as well as a corresponding preview box at the bottom that will show you the colours you have chosen. You can change both the foreground colour (the font colour) and the background colour (which works as highlighting) for your given markup or feature. You will also need to tick the box “Use syntax highlighter” for this to show in the edit mode.

You can see that I have selected orange for my comments, dark blue for internal links, light blue highlighting for headings, green for commands (which also includes external links), and red for “includes.” (By the way, the “include” command is a powerful feature. It allows you to include sections of other topics in the body of your current topic. More about that later.)

And this is what these markups look like in CT’s edit mode (note that internal links to other topics are dark blue, while external links – which are recognised as a type of command – are green).

And this is what this topic looks like in view mode (the orange comments are not visible because they are only meant for the edit environment, a kind of a “note to self” feature):

Getting started with ConnectedText

Following on from my previous post on “getting ConnectedText,” here are my suggestions on how to get started with CT if you are brand new to it.

1. Download and install the software. (If you have special needs for installing things in a particular folder or if you need to sync files with other computers, read the relevant sections (“Changing user data location” and “Project synchronization tips”) of the Help file first, which is available here [2.9MB], as you may need to do some things differently then. But these are fairly advanced issues. If you are not sure what these are about, just go with the standard installation process.)
2. Read (or rather, work through – see point 5) the “First steps” section in the Welcome project (which is CT’s Help file). A ‘project’ is CT’s term for a database, within which ‘topics’ (documents) reside. Keep the Welcome project always open in a tab for easy access. You may even want to load it onto your smartphone or tablet (using a CHM reader app, so you can read it when you are out and about). The Welcome project has over 300 topics, so probably few users read it from “cover to cover,” but it’s there for you to search when you need specific help.
3. Sign up to the CT Forum. Search it for issues for which CT’s Welcome project may not have an answer to. If you can’t find an answer, post your question, and you are likely to get a quick reply.
4. Note that CT’s main window has two modes: an edit mode for creating content in a topic, and a view mode for viewing the content. Learn how to toggle between them (e.g. type ALT+E or click the Edit button).
5. Create a new project (database) file, call it “Test”, and try out the various features as you are learning about them. Make sure to select “Auto Backup” for any new project you create in the Project wizard, otherwise you won’t be able to recover deleted topics. You can download a cheat sheet with the basic mark-up commands here [PDF]. Use the Welcome project to practice on how to navigate an existing fair-sized project.
6. Go through all the menu items in the pull-down menus, to learn the main commands. Similarly, check out all the buttons in the toolbar, to become familiar with them. Also check the commands in the right-click context menu, e.g. when you select some text in the topic editor window.
7. Read some of the existing tutorials online: Steve Zeoli on some of the basic features of CT and Prof. Manfred Kuehn on the basic mark-ups he uses in CT.
8. Develop your preferred desktop configuration for the various panes. Go to “View” pull-down menu and try out the various options. The most important panes for me are the “Table of Contents,” “Topics,” “Categories,” “Outline,” “Notes,” and “Navigator.” As the Navigator allows you to view a map of your topic relationships, it’s best to use it undocked as a standalone window in a separate monitor (using Windows’ Extended Desktop feature). Make sure to save your favourite desktop configuration by going to View > Desktop > Save Desktop. You can save a variety of desktop configurations for different scenarios (such as reading, writing, annotating, outlining etc.).
9. Practice docking the panes because it can get tricky and it can happen that you end up in a mess (with panes stuck where they shouldn’t be and there not being an obvious way to return to the previous state). That’s the time to go to your saved desktop and load it.
10. If you have already messed up your desktop and need a fresh start (just like I did early on), download this desktop template [ZIP file] from the Forum, courtesy of one of the users. Here are his or her instructions: “Put it into your user settings folder, where you keep CT’s icon folder, dictionary folder etc. The First_Aid.lay should go on the same level where CT stores your bookmarks.xml, fulltext.xml, filters.xml etc. After you put the file there, call it up via View > Desktop > First_Aid.” Below is what the First_Aid desktop layout looks like, once called up. It’s the swiss army knife of CT desktop layouts. You can just close the panes that are not needed.
11. My preferred desktop configuration (for the qualitative data analysis that I will discuss in future posts) is the following: view/edit window in the middle, Table of Contents and Outline docked on the left (as tabs in the same pane), and Topic List, Categories, and Notes docked on the right (as tabs in the same pane), with Navigator undocked in a separate monitor. If you don’t have a separate monitor, you can still have it undocked, but you will need to call it up by F7 or clicking on the Navigate button and then close it, otherwise it will cover your main CT window. Alternatively you can dock the Navigator on either the left pane (like in this YouTube video) or the right pane.
12. Once you become comfortable with CT’s main features, make sure to install Python on your computer, so you can use some Python plugins that will help your work. Instructions for how to install Python are in the Welcome project. I use three Python scripts (all downloaded from the Forum) on a regular basis: one for doing word count in a topic, and the other two for creating bullet-point and numbered lists. There are also a lot of AutoHotKey scripts on the forum but I don’t use any at the moment. [Update (11/3/13): I do now…]

In my next post I will discuss my work flow regarding qualitative data analysis in CT.

Getting ConnectedText

In an earlier post I have outlined my reasons for switching to ConnectedText (CT) from NVivo 8 as my main CAQDAS tool. However, before I get into discussing how I use CT for qualitative data analysis, I need to tackle the delicate issue of “getting” or “not getting” ConnectedText. It is a common complaint by new or prospective users that there is a learning curve associated with CT or that they simply “do not get CT.”

I empathise with these comments because I was also one of these people. I had first encountered CT back in 2007 perhaps, and I ‘trialled’ it  several times over the years. I say ‘trialled’ because most of the time I couldn’t get passed the first screen and I gave up on it very quickly. In retrospect I realise that there were a number of reasons why I didn’t get CT back then and why I get it now (at least for my purposes).

Some of the reasons have to do with the profile and the expectations of the prospective user. If you have never used a wiki or mark-up before, if you are not a programmer or blessed with an engineer’s mind, if you have been raised on the common fare of Microsoft Office type applications, if your background is in the humanities or social sciences, then encountering an idiosyncratic tool like CT may prove initially a challenge.

But some of the difficulties arise out of the characteristics of CT and the way it is initially presented to this non-programmer, non-techie type of user. CT’s main strengths are also its main weaknesses when it comes to selling these strengths to the uninitiated. At its heart it is a desktop wiki that is enhanced by a wide array of sophisticated tools that can turn that wiki into any number of specialist solutions (such as CAQDAS in my case).

The problem with ‘just’ being a wiki at its heart is that it makes CT into a highly generalist application, in the sense that a wiki can be whatever you make of it. A desktop wiki after all is your own mini internet or intranet, and as such it can be organised in a myriad different ways, as far as the content and the structure of the output are concerned. Therefore  it might be more difficult to “get CT” if you come to it without a specific need to solve a particular information management problem. Just like with the case study method or practice-based learning, it helps to have a real-life problem at hand to which you can apply CT as the solution.

At the same time CT is also packed with some very sophisticated features, such as special ways of connecting the “web pages” (called ‘topics’ in CT), analysing them, visualising them, organising them, enhancing them with various add-ons and scripts etc., etc., which probably can also scare the novice away. At the moment the way information is presented on the website, in the software when it is first launched, and in the Welcome project (which is the Help file, 2.9MB), CT probably appeals to the sophisticated programmer-type audience more, than let’s say the humanities-type person with no experience in using mark-up. When I recommended CT to another PhD colleague of mine with a social science background, he said, “Wow, and I thought learning Scrivener was a challenge!”

For this reason I would like to recommend some strategies for this latter type of prospective users on how to increase the chances of “getting CT” because I think it is well worth the effort (in my experience). I will provide a particular way into CT in my next post. However, in the meantime let me emphasise that if you want to give CT a chance as your main database for your PhD (or any other type of) project and as a qualitative analysis tool, then you will need to become a member of CT’s forum because it is a live extension of CT’s Help file. There are not only some very helpful human beings on there but it is also a depository of existing knowledge, user case studies and Python and AutoHotkey scripts (more about those later).

Why use ConnectedText for qualitative data analysis?

This is my first post in what hopefully will become a series of posts on how I use ConnectedText (CT) for qualitative data analysis, as part of my Ph.D. project. You may ask: “Why bother using CT, a personal wiki, for qualitative data analysis when there are such long-standing dedicated CAQDAS tools on the market such as Atlas.ti and NVivo?” That is a legitimate question. Some people may indeed find that Atlas.ti or NVivo works better for them. However, based on my personal experience as a PhD student, I found that neither Atlas.ti or NVivo was quite right for me. Finding CT was a revelation, as it allowed me to overcome some problems (more about those later) that I couldn’t solve with NVivo, my CAQDAS of choice prior to CT.

How to select a CAQDAS for your study? Try several if you can. Test them on a pilot project. Take workshops on them. Although here I will be recommending CT as CAQDAS for particular qualitative analysis jobs, I still suggest you use either Atlas.ti or NVivo extensively for a prolonged period of time to learn about how mainstream CAQDAS work.

What was my experience with CAQDAS? I took a couple of workshops in Atlas.ti, got a copy and trialled it repeatedly over the years. As far as I know, Atlas.ti was originally developed to implement grounded theory, and as I wasn’t completely convinced by its implicit research philosophy (which still seemed a bit positivist to me, although otherwise I’m all in favour of grounded theory’s bottom-up approach), I found some of the lingo, the design and the interface off-putting. I discovered that I was a visual learner and found that Atlas.ti wasn’t accommodating my type of learner. I found it difficult to visualise the conceptual linkages between Atlas.ti’s various commands and floating windows.

NVivo 8, on the other hand, immediately appealed to me the first time I laid my eyes on it. I could see how its different tools related to each other. At its heart there was a hierarchical folder structure that worked like many other Windows-based software. It also seemed more neutral from a research philosophy perspective. In the end I spent 6 months analysing my qualitative data in NVivo. I used it to code about half of my data (interviews, participant observations, and a variety of collected documents in a range of media and file formats). I enjoyed doing the coding with it. [The screenshots below are of the example database that comes with NVivo.]

Why did I abandon NVivo? The main reason had to do with the limitations of NVivo’s interface, or rather the way its tools are organised and the way this organisation forces you to follow a particular analytical logic. The underlying issue is the hierarchical organisation of folders and tools, which, ironically, was the reason I chose NVivo over Atlas.ti in the first place. The problem was that different elements of the work get separated into different folders, which can’t be viewed at the same time, thus breaking up the workflow and the analytical reasoning.

After all my coding I ended up with a hierarchical forest of codes (a lot more complex one than the example in the above image) and it was difficult to see how to bring them all together again in order to synthesise them into findings and a coherent answer to my research question. I was stuck and confused, as I also lost my overview of all the data that I had reviewed and stored in there. (In fact, in my desperation I took screenshots of my NVivo codes and pasted them into PowerPoint, and continued the rest of the work outside of NVivo. It helped to cut a Gordian knot but I still ended up needing another CAQDAS solution for the rest of my data).

I also realised that NVivo is a wiki forced into a hierarchical straight-jacket. You are essentially creating links between different documents and then these links are presented to you in a hierarchical organisation. This rekindled my interest in personal wikis again. Since the early days of my PhD I wished that there was a way to create a dashboard for my dissertation project, from which all my files (both data and my analysis and writings) would be linked in the manner of an intranet. I have experimented with Planz, WhizFolders and a range of desktop wikis but none of them were quite right. In fact I also checked out ConnectedText a few times over the years but I never managed to make sense of it. However, my problems with NVivo’s hierarchical structure convinced me to have another go with the wiki format. Fortuitously, there were a series of helpful posts on Outliner Software and on his blog by Steve Zeoli, which finally led me to an epiphany with CT. But more about that in my next post.

There were some other reasons too why I was happy to say good-bye to NVivo (and the same is true for Atlas.ti). One was the enormous price tag and their licensing regime. Although I got a very cheap, subsidised license from my university, it needs to be renewed annually, and after I graduate I may need to shell out some serious money if I want to have continued access to the data in the form it’s organised in NVivo. To me it seems that NVivo and Atlas.ti to some extent cornered the market and are taking advantage of the fact that PhD students are a captive audience, strongly influenced by the preferences of their supervisors, peers and academic tribes. This business attitude I find very unappealing.

Finally, there are the resource requirements of running a software like NVivo. When I installed my first NVivo copy onto my previous computer, a laptop, I wasn’t even able to launch it. It just simply wouldn’t budge and froze my entire machine. I was forced to buy a top-of-the-range PC in order to be able to run it, and even on the new machine it was sluggish. Waiting for files and windows to open for several seconds eventually adds up. Also, as far as I know, all the work in NVivo is saved into a single proprietary file. It is just asking for a lot of faith to put several years worth of data and effort into a single massive file and hope that it will work for 100% of the time forever, that it will never get corrupted etc., etc. I’m not a techie but it seems to me there are some risks associated with that approach.

Still, I’m glad that I had a proper go with NVivo. It was only by spending many months toiling with it that I had learned how CAQDAS work and what the features are that I like and the ones that I would like to have. I was only able to adopt CT as my new CAQDAS tool because I was able to model the processes that I learnt about – or wasn’t allowed to do – in NVivo.

In my next two posts I will introduce the key qualitative data analysis features of CT and I will also provide some tips on how to get started with it, especially if you had never worked with a wiki before.