We are using NVivo to not only code our transcript data but to act as a data repository of source materials. NVivo not built to handle this second functionality in a collaborative environment, and as a result leads to the proliferation of source materials – both within NVivo and across multiple versions of files. The collaborative functionality allows for the proper integration of coding — but not of sources, which are just duplicated, and will be duplicated each time a site tried to merge their local master into the project master. This is okay to deal with on the small scale, but really breaks down at larger scales. Anticipating a couple of hundred interviews, we fear the consequences.
Assuming we can get a functional set of NVivo techniques and complementary social practices, we still face intellectual challenges of how to do this sort of large-scale collaborative coding. For instance, we have a constant tension between wanting to do “entrepreneurial” coding for a specific group’s interest or upcoming paper, and yet preserving a common set of codes that will allow us to compare between projects. Although difficult, this intercomparison is one of the distinguishing features of our research and giving it up would be (in some ways) giving up the game.
Since NVivo minimally supports the processes we need to perform, we have had to focus our efforts on social design. We have elaborate diagrams and descriptions of work flows for receiving and disseminating our coded data. Hopefully as we talk to the NVivo team we will be able to inform them of ways that they could move this burden from the social back into their technical design.
