I am going to cross-post this on the Atlas listserv as well.
----- Original Message -----
From: <[log in to unmask]>
To: <[log in to unmask]>
Sent: Friday, July 14, 2000 10:11 AM
Subject: RE: Research teams in QDA software (Was: Re: 2 person coding on N
vivo)
> with 2 of us so closely involved in the coding we are going to have to be
> fairly firm initally about what codes we are using - and that we will need
> very regular periods where we stop and re-evaluate our codings together!
So
> having 2 people will not mean that we get it done twice as fast, but maybe
> the final product will be of higher quality!
I hate to be rainer of parade, but this is precisely what software
developers need to help us avoid. Being "initially firm" about what codes to
use is a good way to produce something of lower quality rather than higher
quality. The whole idea of GT and most other QR protocols is for concepts
(i.e. codes) to be developed inductively. Being firm about these concepts at
the outset can lead you on a long path in which you develop a conceptual
apparatus that you find increasingly at odds with your growing experience of
the data. This can result in some euphoric revolutionary moments when you
throw out those concepts because something else works much better. But I
think it tends to be an inefficient way of going about it and has the
unfortunate effect of producing bogus conceptualizations early on--not good
if you need to produce early-stage reports or publications to satisfy
funding agencies. Much less emotionally taxing and more time-efficient is
starting inductively from the beggining and going through a series of
"mini-revolutions" in which higher level concepts emerge and re-organize
lower level concepts. This also has the effect that preliminary reports and
publications can be presented as "first takes" at the data and usually are
consistent with more deeply conceptualized work produced later. This is much
preferable than producing intial, deductively conceptualized work that later
ends up looking reckless, irresponsable, misleading and generally
regretable--even when it was the result of earnest, honest efforts.
Atlas.ti does this well at an individual level. It facilitates merging for
group projects so theoretically can do the same thing. But this merge
capacity needs some work to smooth out the process. As it is now the
dialogue box for doing the merge has some broad criteria for constructing
the merge. But it needs to be much more fine-grained to make merges
efficient. As it is, any changes in data that amount to creating an object
are fine, but any time an object is "disappeared" (by deleting, or renaming,
for example) it reappears with the merge, from the files of the others who
did not make the change. This is a problem for an inductive enterprise that
should include continual name changes and modifications of the coding
scheme. Overcoming this requires a meticulous system of keeping track of all
objects "disappeared". A more detailed merge-editor specifying particular
objects to be merged rather than "types" of object would help. Another
problem is the fact that objects can only be related in one way. I find this
to be a problem in my personal work since I would frequently like to play
around with networks trying to construct different conceptualizations to see
which works best with the data--for example does code "religious emotion"
determine code "economic viability" or vice versa? This is a much bigger
problem in a group project since it is most likely that participants will
have different coneptualizations and it would be nice to be able to try them
out and discuss their effectiveness. One other change that would help would
be name-stamping for all objects--especially quotations--so that afterwards
one call always tell who created what.
I think the first and the last problem will probably be corrected with the
next release of Atlas. The second problem implies some more complex
philosophical issues and may or may not be different in the next release.
But if these problems were resolved, I think Atlas would be an excellent
tool for group projects. I should say "more" excellent since I think it
already is very good. We periodically do (time-consuming) merges and
redistribute the new project file and it is absolutely wonderful to have all
three of our's work together and available for all.It in effect, extends our
meeting time into our own individual work time since I can go to my
collegues codings and see how they used a code, reconstruct when they
created it, etc. in my attempts to understand their mindset in working with
the data.
Best, DS.
************************************************
David Smilde
University of Chicago
Universidad Central de Venezuela
Apdo. 60712, Chacao 1060, Caracas, Venezuela
(h)58-2/237-2457; (cel)58-14/902-8551; (o)58-2/753-6977; (f)58-2/753-5750
[log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|