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.

Advertisements

5 thoughts on “Designing your QDA project for ConnectedText

  1. Pingback: Importing your data into ConnectedText | Dr Andus's toolbox

  2. Pingback: Preparing for coding in ConnectedText | Dr Andus's toolbox

  3. Pingback: Coding process flow in ConnectedText | Dr Andus's toolbox

  4. Pingback: Summary and example of coding in ConnectedText | Dr Andus's toolbox

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

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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