For the past 6 years I
have supported qualitative data analysis through the provision of
training and
consultancy in QSR software.
Contact me at t.barrington@onupalong.net
for:
 Project
Consultancy
Software
Training
Helpful Information
The following may be helpful to those who are
considering the use of QSR software for handling data.
About QSR software
Do you need software? If you have
a dozen or so interviews of one or two pages each, chances are
you don't need a QDA (qualitative data analysis) package. The
use of a word-processor (and its ability to Find text) and a
spreadsheet for handling tabular data may be all you need.
Twenty or more one hour interviews may require a tool that does
a bit more - read on.
About QSR software
These are software tools for qualitative
data analysis, the analysis of unstructured or semi-structured text.
Examples include interviews, open-ended survey responses and other bodies of
descriptive text. Leichhardt scale style questions can be integrated
with open-ended text so that all information can be stored centrally.
The software provides tools to examine the relationships
between concepts or themes in your data and to record your thoughts and insights along the
way. Furthermore, they support exporting (via tab-delimited format) to
spreadsheet or SPSS.
For an up-to-date overview of current software, please see the QSR website at www.qsrinternational.com.
From 1999 to the start of 2005,
QSR had two product lines: the original software NUD*IST
continued alongside the newer NVivo to support large datasets
and scripted automation (N5
and N6 were roughly contemporary with NVivo 1 and NVivo 2).
Tools were also developed so that two databases could be merged.
In 2005, NVivo 7 superseded both N6 and NVivo 2 but
imports databases from both. NVivo 8 has since been
released along with a second version of XSight (designed for
market research applications).
Learning software
Learning qualitative data analysis
software such as QSR
NUD*IST (N6) and QSR NVivo is
an investment, and the amount of time and effort required varies from person to
person. A two or three hour session is sufficient, at least in the first
instance.
It's important to make a distinction
between knowing "how to drive" the software (make it perform
various functions) and knowing how to structure and manage your data to
maximize the software's effectiveness. Often, it is useful to get some advice
that is specifically directed at the needs of your project.
Do you need training?
The NVivo software is accompanied by
online guides and tutorials to familiarize yourself with the software's functions. Doing a
tutorial is one way to determine for yourself whether further training
is required. Try a trial version of the software (see www.qsrinternational.com).
After completing a tutorial you may still feel
that you would like further training. However, don't begrudge the time spent doing the
tutorial - most (if not all) people will get more out of training having
first encountered the software in a hands-on tutorial.
Outside Victoria, Australia,
there are a range of trainers across many countries (see the
listing on the QSR website above).
They may offer workshops, one on one training, project
consultancy and research advice.
Project design
Consider the following when
setting up a project in NVivo (or NUD*IST for that matter):
Structure and arrangement of data: designing and formatting files
to import into the software as data documents.
Inefficient
design can restrict you later on. Thinking about how the text is
laid out ensures that it is easy to identify the origin of each
segment of text (who's speaking, which question prompted that
answer), to retrieve answers within an appropriate amount of
context (whether they said that in the same paragraph, what else
they said there). NVivo uses section headings (define using
paragraph styles e.g. Heading 1) to automate clerical processes
e.g. automatically coding the equivalent sections from each
document.
Integration of demographic information.
Import what you know about the source of
your data e.g. demographics such as age and gender, or factual
information such as the interviewer, interview date and data type.
In NVivo, incorporating such information allows you to ask questions about
specific subsets of your data. This information can be
imported in a table (saved as tab-delimited text) with the sources
or cases as rows, the variables as columns (referred to as
Attributes in NVivo) and the appropriate values make up the cells.
Developing coding structures that work.
A good look at how to arrange thematic
categories in a hierarchical tree as a 'node system'. A well
organized catalogue of your coding categories allows you to find
and use them easily, and to ask the questions you wish to
ask. Try to group things under parent nodes using a types and
tokens approach - a simple example: if you are coding for 'happy',
'sad', 'angry' etc. perhaps these could be children of a parent
node 'emotional responses'?
Also, one of the consequences of NVivo's
design is that if you want to ask a question about a topic you
need a single node for it, and that node must code all the text
relating to the topic. Therefore, don't create more than one node
for the same thing.
DON'T
DO
The above diagram shows how this can make
it hard to ask a general question about outcomes that didn't work,
regardless of the 'coping strategy' to which they related. In the
DON'T scenario, the 'Didn't work' outcomes are split across three
nodes and these would need to be combined in order to ask the
general question. On the other hand, grouping the outcomes that
'Worked' and 'Didn't work' under a type 'Outcomes' allows
questions to be asked about all outcomes that worked.
If you want to identify when chocolate
worked, then a simple intersection (AND) query will return the
text common to 'Chocolate' and 'Worked'. Indeed with the nodes
organized as they are, you can even generate a matrix intersection
to get a distribution (in NVivo, the actual text can be accessed
via the cells):
Querying the data: searching and inspecting the data to provide
answers to specific questions. Exporting data.
The above concentrates on getting
information into a project - but have a good look at how you will
extract information e.g. to compare the
coding of two or more categories against each other, or against
descriptive/demographic information produces results that can be
exported as text or tables. NVivo's search/query tools
basically report which items have text in common and return
whatever passages you ask for. Knowing how the search/query tools
operate will greatly inform the project design.
Coding the data: how much to code?
While this is not typically thought of
as project design, the decision of how much text to select for
coding at a particular category/node can have a significant
impact on the effectiveness of the project. Consider the
following two sentences:
Chocolate is readily available and
doesn't take long to eat, and most of us would use it to get
us through the day. I find that when I eat it it really does
make me feel a lot better.
The first sentence identifies chocolate
as a coping strategy so it would be coded at 'chocolate'. The
second sentence states that it worked as a coping strategy for
this person, and so that text would be coded at 'Worked'. But if
I want all the instances where chocolate worked, and so looked
for the overlapping text for those two topics, I won't find this
passage. However, if I included a bit more context by coding
both sentences at 'Chocolate' (and the second sentence at
'Worked') then I would have an overlap between the two
topics.
How much text you code will determine
whether there's an overlap but also the extent of the overlap.
If you code more of a passage, you'll ensure an overlap but
there may be too much text in your result - the answer you're
looking for may be buried.
If you code less of a passage, you may
not get an overlap and that is a concern. If you think there's
more there than a result shows, you can use a proximity (NEAR)
search to look for them (this will return coded passages that
are within the same paragraph or section in the document
text).
Conversion of
tabular databases (e.g. Access/Excel/SQL) into NVivo/NUD*IST
projects.
Data in tabular form can be converted
into source files for a NVivo project relatively easily. Textual
responses can be saved as a text or Word file and imported before
a table of descriptive responses (e.g. demographics) is imported
to assign attributes in NVivo.
While you'll need an idea of NVivo's
input files, the actual work is done in Excel, Access or
other database program. So you will need a good knowledge of these
to be able to export the data in the required format. Try it on a
test case first!
E.g. in Excel: For textual responses, you
may wish to transpose (Edit > Paste Special) the table so that
each case's responses are in a column. Each column can then be
copied/pasted into a text file and saved. Note that it doesn't
matter whether the descriptive data is also included. To create
the descriptive data table, delete the textual responses from a
table which has cases as rows and variables as columns (the cells
then contain the values) and save as a tab-delimited file.
All the best,
Ted Barrington, November 2008.
|
