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).