I’ve recently shifted gears from data collection to data analysis in my dissertation research–so of course what better time to navel gaze on the tools I’m using, rather than doing the work itself, right?

Well, not really.

Early in my PhD studies I went through a phase where I spent a significant chunk of time trying different citing and writing tools, before settling on collecting materials with BibDesk and DropBox, writing in Markdown with WriteRoom (sometimes Vim or VSCode), and then publishing with Pandoc. It hasn’t been perfect, but it has let me collect about 2k citations to the research literature, and to be able to easily draw on them in my written work in articles, my dissertation proposal, and here on this blog, which has been super handy.

Markdown kind of sucks for workshopping text with others. There are some tools for collaborating with others on Markdown text, but it can be challenging to get academics to use them when their time is so limited. So I’ve tended to give people Word docs or PDFs (generated with Pandoc), and solicit people’s feedback that way. Then the challenge is integrating those suggestions back into the original source. This means the track changes feature in Word or Google Docs don’t work right, but if people are interested in that level of granularity they can look at the Git repository…yep, using Markdown files means my manuscripts can all happily be versioned in a Git repository. While the collaborative lure of live editing in a Google Doc is a strong pull, I’ve actually come to appreciate the degree of separation that editing Markdown provides. It gives me a protective space in which to think.

Now I’m in the process of converting hundreds of pages of hand written field notes in a couple notebooks into text documents that I can use as a source material for open coding. For my last project I ended up using MAXQDA for qualitative data analysis after experimenting with Dedoose and NVivo. I was happy with it, but it wasn’t cheap, even with the educational license, which expired after a semester.

Close reading field notes and interviews is key to my method, and being able to annotate the text with codes is extremely important for coming to understand, and use, my data. But honestly all the bells and whistles built into the tools were not so important for me. I liked to see my codes, and bring up chunks of text for particular codes. But that was the extent of my analysis. I built themes out of the codes and used the codes as an index into my data. But I didn’t tend to use any of the other statistical tools that were available.

So this time around I’m trying something different. Because I am transcribing my own hand written notes, I’m going to write them as Markdown (basically text files), and then “mark up” regions of texts with codes using HTML, which is perfectly legit to use in Markdown files. I could have done this keying/annotating work in MAXQDA which provides a way to compose documents, but I was kind of surprised to find that NVivo didn’t have this capability–it really likes to be pointed at completed documents, instead of providing an environment for creating them.

Out of habit I use Vim for editing text because I reach for it for coding after being forced off Emacs by a boss 20 years ago. I briefly looked at writing a Vim plugin for marking up text quickly but Vimscript is truly arcane. Truth be told, for editing Node/JavaScript projects I’ve actually been using VSCode more these days (with Vim key bindings), which (for me) has a much saner plugin environment.

So I created a very simple VSCode plugin I’m calling Anselm (named after Anselm Strauss) that makes it easy (with a few keystrokes) to highlight an arbitrary region of text in a Markdown document and mark it up with code, expressed with a <mark> tag.

So for example, assume I have this bit of text in my field notes:

Some heavy machinery, bulldozers mostly were also there.  To the right was a cement structure with multiple large diagonal entrances.  I missed the sign pointed to the right for Yard Waste and ended up on a road that led out of the facility. I thought about turning around but it was a one way road.  There was another person in a truck at the exit who was watching people leave. I felt a bit like my movement through the facility was controlled.

Anselm will let you quickly (faster if you assign a keyboard shortcut) assign simple codes to pieces of the text:

Some <mark class="technology">heavy machinery, bulldozers mostly were also there</mark>.  To the right was a <mark class="architecture">cement structure with multiple large diagonal entrances</mark>. I missed the sign pointed to the right for Yard Waste and ended up on a road that led out of the facility. I thought about turning around but it was a one way road. <mark class="surveillance">There was another person in a truck at the exit who was watching people leave. I felt a bit like my movement through the facility was controlled.</mark>

The plugin is so simple it seems barely worth mentioning. You can see it in operation in the video at the top of this blog post. I am writing about it here really just to give encouragement to you to develop the tools you need in your research. There is significant value in understanding how your research tools operate, and to being able to shape them to do what you need. There is also value in getting the research done, and not focusing on the tools themselves. So it’s a balancing act to be sure.

Also there’s another latent lesson here for me, summed up in the words of Graydon Hoare, as: You can always bet on text.

Text is the oldest and most stable communication technology (assuming we treat speech/signing as natural phenomenon – there are no human societies without it – whereas textual capability has to be transmitted, taught, acquired) and it’s incredibly durable. We can read texts from five thousand years ago, almost the moment they started being produced. It’s (literally) “rock solid” – you can readily inscribe it in granite that will likely outlast the human species.

Just using text for my field notes, means I can analyze it as text and not be limited by what MAXQDA or NVivo lets me do. I’m going to give it a try for a bit. If you want to try it out yourself you can find it in the VSCode plugin app store, just search for “Anselm”.

Finally, research is an opportunity to not only generate new findings (or knowledge) but also to develop new instruments and methods (practice). I certainly haven’t done anything revolutionary in creating this tiny VSCode plugin; but it has granted me the chance to reflect on what is happening when I code text in this way, and opened up other possibilities for its analysis later that would have been foreclosed by the limits of someone else’s tool.

But yeah, on with the analysis! 📙💻📊 I’ll probably be adding little bits and pieces to Anselm as I go. If you have ideas for it drop them into them in here.