Within NVivo, and likely other QDAS packages as well, it is possible to use the structure of interview transcripts for auto-coding. Basically, what auto-coding does is go through the transcript and using criteria specified by the user assigns text to chosen nodes (further explanation of auto-coding and how to do it in NVivo is available on the NVivo help website). This can be useful to separate out the different speakers within a transcript whereby everything they say is coded to a node with their participant code number. Even in one-to-one interviews this can be worth doing so that any word frequency queries, word clouds, etc can be limited to only include sections from the transcripts where a participant is speaking. However, any mistakes in the structure of the interview transcripts can result in them being incorrectly auto-coded. Depending on the extent and nature of the errors this can be a headache to manually fix. This post briefly covers what type of errors can arise and provides a set by step guide to creating a Visual Basic macro within Microsoft Word that can automate the process of fixing the paragraph styles in transcripts so they can be auto-coded without error.
The challenges of data management and analysis on a large longitudinal qualitative research project
Computer aided qualitative data analysis has the potential to revolutionise both the scale of research and possible analysis techniques. Yet, the software itself still imposes limits that hinder and prevent this full potential from being realised. This post looks at the large and complex dataset created as part of the Welfare Conditionality research project, the analytical approach adopted, and the challenges QDAS faces.
The Welfare Conditionality project has two broad research questions in setting out to consider the issues surrounding sanctions, support, and behaviour change. Firstly, is conditionality ‘effective’ – and if so for whom, under what conditions, and by what definition of effective. And, secondly, whether welfare conditionality is ‘ethical’ – how do people justify or criticise its use and for what reasons. To answer these questions, we have undertaken the ambitious task of collecting a trove of qualitative data on conditional forms of welfare. Our work across nine policy areas, each of which has a dedicated ‘policy team’ that is responsible for the research. The policy areas are: unemployed people, Universal Credit claimants, lone parents, disabled people, social tenants, homeless people, individuals/families subject to antisocial behaviour orders or family intervention projects, (ex-)offenders, and migrants. Research has consisted of 45 interviews with policy stakeholders (MPs, civil servants, heads of charities), 27 focus groups with service providers, and three waves of repeat qualitative interviews with 481 welfare service users across 10 interview locations in England and Scotland.
This post is an introduction and placeholder for a planned series of posts on useful apps, services, and software. Once there are a few posts in the series I will eventually promote this post to a page with an index of all the posts from the series.
I decided to make a series for this because although using computers has become a key part of academic work, too many academics remain uncomfortable using them. Often I come across people using Word for anything that involves text. Not due to it being the best tool for the job but that they are unaware of the alternatives. Even when someone knows it is not an ideal solution, it is not always easy to find a good entry point to start learning how to use new software. At a training event I attended last year I was sat next to a professor. From the introductions he obviously had years of experience using an advance software package for tasks similar to the software the training was on. Yet, it became clear from the start that he was uneasy and disorientated when facing a new application with an unfamiliar interface. After accidentally launching another application and then opening the wrong file, that resulted in a garbled mess of symbols appearing on the screen, he got up and left only ten minutes into the session. While it is rare for someone to feel so at a loss that they leave, I have heard multiple times from PhD students that despite feeling like walking out they have persisted through a training session and still come away not feeling any more confident in knowing how to use the software. Such experiences end up reinforcing self perceptions of not being ‘a computer person’.
Tasker is one of the top reasons I regularly give when asked why I prefer Android to iOS. The app was designed to provide a means to run tasks based on contexts as defined by the user. For example, turning the notification volume on the phone to silent at night or reading out text messages received while driving. Through the wide range of triggers, actions, and third-party plug-ins it is effectively a visual programming language for Android devices that can be used for more complex applications. The above video shows an example of using Tasker to automate signing in and out as part of a lone worker procedure. The video shows version 1.0. After initial field-testing a small revision was made to add another screen that displays the details to be used for confirmation before sending the sign in text.
Version 1.1, therefore, includes the initial task that launches a scene through which a contact to sign in with can be selected. Then the sign in task grabs a list of any events from the calendar over a twenty minute window before and after the current time. From the calendar events each of the following are added to a set of arrays: event title (who the interview is with), location (the participant’s home address where the interview is taking place), and details (the participant’s contact number). A regex is then used to find the position in the event title array of any event who’s title begins with ‘Interview’ . The full event details are then taken from the other arrays and alongside an expected sign out time are sent in a text message to the chosen contact.
Having signed in, a permanent notification is created through which it is possible to sign out or to raise an alarm if the researcher is in danger. Both require a confirmation button to be pressed to avoid accidental selection. The sign out task sends a text to notify the chosen contact that the interview is over, removes the permanent notification, and clears all the variables used in the tasks. Red Alert sends a text raising the alarm, and offers a notification option to call the contact as well. Finally, if the sign out task has not run by the expected sign out time, the phone vibrates and requests an estimate in minutes of how much longer the interview is expected to take. The entered value is then added into a text message in the format: “Sorry, running over, should be another X minutes roughly”.
As well as a general post on Tasker I am working on as part of a planned series of posts on ‘useful apps & services for academics’, I am also aiming in the next few weeks to have a short guide written for how to create within Tasker the lone worker sign in automation shown in the video.
The core component of the fieldwork for the Welfare Conditionality research project is an on-going three waves of qualitative interviews with 481 welfare service users sampled across nine different policy area. In order to assist with descriptive statistics and finding subgroups amongst our sample, we have a set of key attributes such as the participant’s age, household, benefits received, etc. Furthermore, we have additional attributes specific to each policy area. Due to this, we have around fifty attributes in total that need values entered for them after each interview. By default NVivo offers three main ways to add attribute values, none of which are ideal for working with this amount of data entry.
The primary means of adding attribute data in NVivo is through the Attribute Values tab of the Node Properties dialogue window. This presents a list of drop-down menus for each of the attributes and can be laborious to work through. Similar to this is opening the Classification sheet and working along the row for the participant. In addition to having the same problem of developing RSI as the first method, this method has become nearly impossible to use as our project file has grown larger. Any change to an attribute value with the Welfare Service User classification sheet open now results in a 1-2 minute wait for NVivo to process the change. The third option is to save attribute data to an excel sheet and import it into NVivo. This introduces its own problems with ensuring values are typed correctly or setting up the excel sheet with acceptable values defined for each column, and still does not make any real time savings with the data entry process.
The above video is an example of using a script I wrote in AutoHotKey in order to provide another alternative. The script translates the keypresses on the numpad into a series of keypresses that select the desired attribute value and then moves focus to the next attribute. For example, if the second value for the selected attribute is ‘Unemployed’, pressing ‘2’ on the numpad would set the value to ‘Unemployed’ and move the focus to the next attribute so the user can press another numpad key to input the next attribute value. Alongside using post-interview checklists that have the number written next to each value, it greatly reduces the amount of time required for data entry. Further details about the script and how to use it are include below. The script file and an executable version of it are available from a Github repository.