In retrospect, 2014 may appear a pivotal year for technological change. It was the year that “wearable” technologies began shifting from geek gadget to mass-market consumer good (including the announcement of the Apple Watch and the rising popularity of fitness trackers), that smartphone and tablet usage outstripped that of desktop PCs for accessing the Internet, along with concurrent interest in home automation and increasingly viable models for pervasive computing (such as Google’s purchase of smart thermostat Nest), and that computer algorithms, machine learning, and recommendation engines came increasingly to the fore of public awareness and debate (from Apple buying streaming service Beats to the effects of Facebook’s algorithms). Many of these shifts have been playing out world-wide, or at least, in diverse contexts, such as Chinese online retailer Alibaba going public and Xiaomi smartphone maker speedily surpassing most rivals. It also proved to be an exciting year on The CASTAC Blog, where our team of Associate Editors and contributors brought our attention to this rapidly shifting technological landscape, and to pressing questions and debates driving anthropological inquiry into science and technology.
In today’s post, I continue my predecessor Patricia Lange’s tradition of reviewing themes and highlights on the blog from the past year. Some of these are topical, and included energy, the environment, and infrastructure, crowdsourcing and the “sharing” economy, wearables, algorithms and the “Internet of Things,” science communication, science’s publics, and citizen science, while others were more conceptual or even experimental—reflections on longterm ethnographic engagement with technology, broader issues of scientific (and ethnographic) authority, technological infrastructures as social infrastructures and tacit knowledges (such as Jenny Cool’s co-chair report), and broadly, how to make anthropological research into science and technology relevant within and beyond academic circles.
I would like to respond to Patricia’s questions about tools and techniques by reflecting on my journey regarding qualitative data organisation and analysis, from a hierarchical tree-based approach to a wiki-based network approach. Like probably many other qualitative researchers using Windows, I started out with standard software packages from household names that had come pre-installed on my home and university PCs. But as the amount of my collected data grew, and as I started to get a better sense of what I wanted to do with my data, the limitations of my initial “system” (or rather, lack of it) started to become apparent.
One problem had to do with storing information in hierarchical folder structures, whether in the My Documents folders or in other two-pane outliners and personal information managers (PIM). The inherent limitation of most two- or three-pane viewers of data (such as Windows Explorer) is that in the hierarchical tree you can usually only see the contents of one note or folder at a time. Once you have hundreds and thousands of files and notes, you reach a point after which it becomes increasingly difficult to browse the archive, find things, remember where they are, and retain a general sense of the shape and contents of the data. Having to decide about the place of a note or a piece of data in the tree too soon in the analysis can also reduce the chances for alternative interpretations and subsequent conceptual discoveries.
I thought my problems would be solved once I had imported and reorganised everything in NVivo 8 (and later 9), the computer assisted qualitative data analysis software (CAQDAS) I had selected out of the two that were recommended and subsidised by my university (the other one being Atlas.ti). I threw myself into the coding process with great gusto, only to realise after having coded half of my data that I still ended up being locked into yet another hierarchical system, where despite the ample availability of tools to cross-reference and connect my documents I started to lose a sense of where everything was and what I were to do with the hierarchical tree of codes that emerged out of the analysis.
I needed help and I found it in the Outliner Software forum, a wonderful community of information management software users, many of whom confess to suffering from CRIMP, “a make-believe malady called compulsive-reactive information management purchasing.” Following their recommendations I have assembled an arsenal of helpful software tools over the years. It was also through them that I have discovered that there was a cure to my condition of being “hierarchically challenged,” and it was called a desktop wiki.
A desktop wiki (also called a personal wiki) solves the problem of “not seeing the data forest from your hierarchical trees” by enabling you to create a flat, network-based representation of data. Essentially you end up creating your own mini-Internet – or more precisely, intranet – on your desktop computer, by connecting up all your data in the manner of interlinked webpages.
There are a number of immediate benefits to a flat, network-based wiki organisation over the hierarchical structure that I described above. First, a wiki requires you to set up a homepage, which is very helpful, as it can be used as the research project dashboard, the alpha and the omega from which and to which everything else can be connected in one way or another. Should you feel overwhelmed by your data or lost in the bowels of your project, all you need to do is hit the Home button, and you can get your bearings again.
The second benefit of using a wiki is that the hierarchical folder structure is absent (at least from view). When you can create a new document you don’t need to make a decision about where it needs to fit in within a hierarchy upfront. A few links or categories inserted here and there will keep it anchored in the network, and the implicit hierarchy of the linked documents gets rearranged dynamically every time links between documents are altered.
This is not to say that hierarchies are inherently bad and that seeing them cannot be helpful at times. The desktop wiki solution that I have adopted – ConnectedText (CT) – has visualisation tools like the Navigator, which enable you to construct very purposeful hierarchies. What sets CT apart from the standard hierarchical folder system is that you can switch this visualisation off at will and immerse yourself in the flat network structure of your interlinked pages whenever you feel like it. Besides the Navigator, CT has a number of other ways to find what you are looking for within the database, including a powerful search tool. You have both your own Internet and your own search engine.
As Manfred Kuehn suggests, a wiki can be described as an electronic version of the traditional “index cards in a slip-box” system that qualitative researchers have long used for taking, keeping and coding notes. Each wiki page represents an index card with notes on it. The advantage of an electronic (wiki) version is that the “index cards” can be freely associated with each other via hyperlinks, without the need for a separate catalogue to keep track of how your index cards are related conceptually.
As I gradually delved into ConnectedText, I realised that not only can it serve as the main project dashboard and database for most of my data (reading notes, participant observation notes, collected files, including PDFs and images etc.), but that it also has tools that allow me to code my data, making NVivo redundant. I ended up using CT to develop my own system for coding that suited my specific needs and which was more consistent with the methodological approach I wanted to pursue.
My key requirements were 1) the ability to store, retrieve and rearrange data without a hierarchical tree emerging and obstructing my view too early on in the process; 2) the ability to carry out analysis, abstraction and synthesis; and 3) the ability to maintain a complete and easily navigable audit trail from the raw data to my final conclusions and back.
It is true (and may seem paradoxical) that by using a wiki to avoid a hierarchical structure I still ended up with a hierarchical organisation of my data and findings. However, this eventual hierarchy emerged through a deliberate process of induction, in line with my chosen research philosophy, rather than being the result of unintentional deduction imposed upfront by the technical constraint of hierarchical folder organisation.