thanks John - I just reiterate my own recommendation to others starting out
with QDA - that this paper which John has generously made available to all,
is a really good introduction to a way of working with qualitative data -
whether you are, or are not working with any software to assist - see the
web site below:
>The important thing is that you are grounded in analytic
>strategies rather than having your strategies driven by the software.
>Flexibility and experimentation are the most important things. Strategies
>will be altered by the software. As I note in Appendix E, the strategies
>and practices I describe are not exactly what Agar advocates, but then each
>of us has to find our own way. And things that bother some of us, don't
>bother others.
>
>I have put Appendix E on the Website. Interested people can download a
>copy in Adobe PDF format from www.qualisresearch.com Click on QDA Paper.
>
>
>
>[log in to unmask]
>P.O. Box 3356
>Salt Lake City, UT 84110
>Ph: 801-532-3090
>Fax:
-----Original Message-----
From: John Seidel <[log in to unmask]>
To: Ann Lewins <[log in to unmask]>
Date: 09 June 1999 19:19
Subject: Re: CHAT ABOUT The ETHNOGRAPH 5
>Ann,
>
>You are keeping me busy Today.
>
>At 09:05 AM 6/9/1999 +0100, you wrote:
>>John -
>>>
>>>In regard to code mapping, I'm not sure what you mean. If it is that
your
>>>coding is displayed on the screen embedded in the text, so that you can
see
>>>the work that you have already done, then I don't think this works
against
>>>intensive coding. Yes, If you have a lot of short segments, and a lot of
>>>code words per segment, things can get a little crowded. But when you do
a
>>>search, you can see the output segments with or without the coding.
>>>Further you can expand the context of the search output with or without
the
>>>embedded coding.
>>
>
>>Ann
>>well - first I did not mean to suggest that the coding process was
>>difficult -far from it - but what i meant to say was - that if you rely on
a
>>VISUAL display of how a file is coded as a whole and many people like to
>>work like this - (i.e. not coded retrieval) - code mapping is nice - but
if
>>there is too much coding embedded in a file - the code headers identifying
>>the start points of each segment break up the data - making the file
rather
>>long and broken up - (if, for instance printing out)
>
>Well, you always have the option of printing out the text without the
>codes, so you can go both ways. If your point is that, while coding, you
>have all the codes embedded in the text, and that this can be a problem for
>some people, I understand. But I also feel that it is important to be able
>to see what you have already done. And other programs, at least in their
>recent versions, seem to agree. But their ways of displaying the same
>information can also get very messy (albeit in a different way) I guess it
>comes down to which form of representation and display of your coding
>scheme you prefer.
>
>>In fact in your Appendix E, which I found extremely useful, you say "the
>>trick is to avoid intensive coding early in the process" - referring to
>>Agars (1991) analytic alternatives. Of course you were not referring to
the
>>code mapping tool at the time - but rather to the process of "preliminary
>>sorting and sifting to generate candidates for the intensive analsyis
>>described by Agar".
>
>>I suppose I picked up on that because you go on to describe a nice mix and
>>match of approaches - where some members of the research team are reading
a
>>few -(presumably) broadly coded segments - generated by outputting them
from
>>the software and then intensively analysing those segments by mulling them
>>over -scribbling and and annotating them by hand. I think I interpolated
>>that to mean (and I felt it myself while experimenting with the software)
>>one has a better sense of those broad segments when looking at the file as
a
>>whole - if there are not too many segments broken up by very detailed,
>>intensive coding.
>>
>>that reference:
>>Agar, Michael (1991, 1994) The Right Brain Strikes Back, in Using
Computers
>>in Qualitative Research, N. Fielding and R. Lee, eds.
>>Sage.
>
>I think what you have said is fair and reasonable. I would also suggest
>that it is only one among many things you can do while working with data.
>I personally found it productive, and intensive coding did not get in the
>way for me. For me there is no "right" way to proceed. But I, as have
>many others, have developed sets of analytic practices which in turn have
>been "begged, borrowed, and stolen" from others. And I have described some
>of my practices in Appendix E. I later discovered that I was doing
>something very similar to Agar. It was not exactly the same, but there
>were clear overlaps and I have incorporated some of Agar in my own
>perspectives. I advocate this, but it is only one amongst many strategies,
>and generally I utilize several. In my mind software does not preclude any
>strategies. You can do these types of things with most of the other types
>of software. The important thing is that you are grounded in analytic
>strategies rather than having your strategies driven by the software.
>Flexibility and experimentation are the most important things. Strategies
>will be altered by the software. As I note in Appendix E, the strategies
>and practices I describe are not exactly what Agar advocates, but then each
>of us has to find our own way. And things that bother some of us, don't
>bother others.
>
>I have put Appendix E on the Website. Interested people can download a
>copy in Adobe PDF format from www.qualisresearch.com Click on QDA Paper.
>
>
>
>[log in to unmask]
>P.O. Box 3356
>Salt Lake City, UT 84110
>Ph: 801-532-3090
>Fax:
>
>
>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|