![]() |
|||||
| Tips & Tricks | |||||
|
|
| Tips
& Tricks
The following are some ideas regarding software based on my (and a few others) experience with teaching the use of various software packages. Over the past years, I had the opportunity to co-teach workshops with a few of my colleagues and also to meet some of the developers. This allowed me to benefit and learn from their experience, and hopefully gave them something in return too. Thus, the information offered below is a conglomeration of tips and tricks that I´ve gathered over time. My goal is to write about tips & tricks that can be applied across all of the various programs, even though I sometimes point out where and how a feature might be used (or misused) in a particular program.
Tips for transcribing data when using a particular Program Strategies for building a hierarchical coding scheme Some things that are important to remember when being immersed in a qualitative research project What else can I use memos for? Which is the best software to buy?
Tips for transcribing data when using a particular Program Generally it is a good idea to decide on a particular program before starting to transcribe the data. This is likely to prevent lots of extra work later on, although some programs like Atlas.ti and winMAX only only require that you save your data "as is" in an ASCII or ANSI text format with line breaks; the data is then ready to be read by the program. Still, you might miss out on making the best use of the functions provided by a program, if you don't take a look at the program first. Let's consider the following example: One of your respondents is Peter. While you are transcribing the data you might not consider just how this name may be used later during the analysis process. So sometimes you indicate a section of Peter's speech by using the full name, "Peter:", while other times you just type "P:" or "P.:" or you add an empty space, "P :", etc. If it occurs to you later in the analysis process that you want to code all turns of Peter's speech, you could have used a text search, spread the finds to the entire paragraph and let the program automatically code all of Peter's statements. This would be a point in your analysis process when you wish you had known from the beginning that……. Speaking of paragraphs, if you know that there is an option to spread the finds of a text search to a paragraph, it may not be a good idea to break Peter's turn of speaking into multiple paragraphs - since then even a consistent usage of "Peter:" throughout the entire transcription would not allow you to fully use the automatic coding function. The Ethnograph offers an entirely different way of letting the program know where speaker turns are. In order to make use of that function you have to follow some transcription rules. If all your data are already transcribed, it can be a pain to get all the documents into the right format. Another option The Ethnograph offers is the use of contextual comments. These have to be inserted when transcribing your data. If they´re not, you´ll miss out on a very helpful function. In Nud*ist you have to make an up-front decision about text units - here it would also be a good idea to know where you want to put your hard returns before you start transcribing. In addition, you can make use of paragraphs and sections. The length of a section can be determined by the user and can include numerous paragraphs. Again, when you know about this function from the start, you can prepare your data accordingly. Experimenting with one or two transcribed documents before you transcribe all of them, can also be very helpful. Even though not every program limits you to a certain number of characters per line, it is advisable NOT to use the entire screen for displaying your text, especially if you have a small screen with a low resolution. While you are working, a number of windows will be open simultaneously and often you want to see both your text and whatever else is displayed in another window (e.g. the code word list, the search results, etc.). By using only about half of the screen, you have the other half for displaying other elements of your project. If you intend to use a program where the smallest codeable piece of text is one line, this has the nice side effect of allowing you to code smaller chunks of text. Under the next heading are some tips about how text searches can be facilitated. The little "aids" that can be used for it, however, also need to be added when transcribing your data.
Facilitating text searches The following trick may be especially useful when a) a program does not specifically support the use of variables, or b) when you only want to use a few variables and it might not be worthwhile to prepare a table, or c) when you simply hate working with tables, or d) well, there might be some other reasons too. In any case, it might be good to know about it. If you already know that you are interested in some variables like gender, age, marital status etc. it might be a good idea to include some information about this at the beginning of a document (or above the speech of a speaker in case of a multi-person/focus-group type interview), such as: Marie female 20s single This information however, cannot be effectively be used in a text search since the words female, 20s and single might also occur in the speech. A better way of clearly marking this information as demographic information is: %Marie %female %20s %single This way you are sure that all strings of %female that you find are pieces of demographic information, since this string of text is not likely to occur anywhere else in your document. You can then spread the find to the entire document (or section if there are multiple cases per document) and use the auto coding function for coding your documents. It needs to be noted that this does not work for all programs and other programs offer different ways of dealing with such information. But this emphasizes again just how important it is to think carefully before transcribing the data - and if you don't transcribe the data yourself, how important it is to give the transcriber precise instructions.
Strategies for building a hierarchical coding scheme When hierarchical coding schemes are mentioned, one might immediately think of Nud*ist - but this does not have to be the case. In winMAX you can organize your coding in a sideways tree, and in the new version of The Ethnograph you can do that as well, as well as in Atlas.ti - yes, you can do it too, if you want to structure your data that way. The easiest rule to remember is that you should immediately stop working on your hierarchical coding scheme, sit back, and re-consider, whenever you beginto notice that you are duplicating things. For example, you have data about 3 different events, E1, E2 and E3. Your interviewees talk about the excitement they felt at the various events. You might be tempted to code for excitement/E1, excitement/E2, and excitement/E3. This is not necessary since you can leave this work to the program's search engine. Just code for excitement and for the various events. You can later do a search using an intersect operator and let the program find all of the instances where people talk about excitement in conjunction with event 1, in conjunction with event 2, and in conjunction with event 3. If the program offers you the capability to save these results as a code or node, you can still make them a part of your tree or coding scheme. But, instead of having done all of the coding work yourself, the computer has done it for you. Thus, a good rule of thumb is to think in separate categories when you are building up a hierarchical coding scheme; don't mix apples and oranges and build relationships between codes (not yet, anyway). Leave that until the stage when you start searching through your coding scheme or index system.
What good is auto coding when I believe that the meaning I am interested in is between the lines and not within the text itself?
Some things that are important to remember while being immersed in a qualitative research project
Remember the saying that sometimes you can't see the forest for the trees? Code words are sometimes like trees; and you may not be able to see how the pieces that compose the big picture fit together because the code words, the possible links between them, the ways you might combine them in a search, etc. are all whirling through your head and creating chaos instead of fusing into an intelligible whole. Maybe then it is a good time to let your computer rest for a little bit.
What else can I use memos for? It is probably not exactly news to you when I say that memos are good for writing down ideas that occur to the researcher while analyzing qualitative data. You may also know that you can specify particular memo types, regardless of whether the program offers you an explicit function to do this or whether you add a meaningful code word to the memo that fulfills the same function. Memo types help you to organize your thinking and can make it easier later on to write the research report. You might have memos that contain unfinished ideas where you make a note to yourself that you still have questions x, y, z you need to answer. Other memos contain analytical thoughts that can later be directly used in the report. The date and time stamp that is or can be inserted by most program allows you to trace the various steps of your analytic thinking and help you to make the analysis process more understandable and visible to others. You might also want to use a memo, for instance, if you are in the middle of something and suddenly it´s noon and your colleague is standing in the door, waiting to pick you up for lunch. When you write a quick note to yourself at this point, it might be much easier to get back into work when you come back after lunch. Memos can also be used to write a note to a co-worker if you are working together with other people on a project. You might tell your co-worker about something that is directly related to the analytic process, something that you have done or that you want him or her to do. You might also use the memo to remind your co-worker to bring the book s/he has borrowed from you to the next meeting, or to bring you a sandwich for lunch, or to wish him or her a happy birthday…. this assumes that you have a system in place where memos that contain a particular type of information are placed in a pre-designated point in your project, for example attached to a particular node in the tree or attached to a particular object. Giving the memos/nodes/objects an appropriate name is also essential in order for the system to work. As can be seen from the examples, memos do not only have to be used for "serious" stuff J .
Which is the best software to buy? Well - this question needs some re-phrasing. A better question to ask is: Which is the best program for my needs, taste, preferences and financial situation? Every project has different demands and one has to compare those demands with the functions that the various programs offer. Can the program do what I want it to do? If two or three programs can do it, which one seems the most suitable for my kind of working style? What if one program has a number of features I like, but it is not obvious how tasks x and y can be accomplished? In most cases, tasks x and y can be also be accomplished by using a work-around. The question then becomes how willing I am to live with these work-arounds and how important are the other functions. Of course if you want a graphical interface and the program does not offer that, then you won't be able to find a work-around within the program itself. Being able to use a graphical interface may, however, only be of secondary importance, with either financial considerations have a higher priority or system requirements posing a limit. Hence you might decide to buy a less expensive or less memory intensive program and instead draw pretty pictures of your coding scheme and of the relationships between codes, etc. on a piece of paper. Getting a feel for a program is also important. A Mr. or Ms. Miller might find certain ways of doing things annoying and cumbersome and advise you to stay away from a particular product - but you love the way it works. Different people have different tastes and preferences so it is advisable to download the demos of those programs that one might consider using. It is a bit like buying a car. Most people will first test drive those car brands that they might consider buying. Based on that experience - the feel of the interior, the way it takes one places, the way it accelerates, etc. - it becomes much easier to make a decision. When applying this metaphor to particular programs, one can ask the following questions: Does the method of coding appeal to me? Is the search engine powerful enough? Do I like the way the results are presented? Am I fascinated by the many options I have or do they confuse me? Is the program too simple or too complex for me? Does it have all the extras I want? The best way to find the answers to these questions is the (slightly changed) slogan: Just try it out! Regarding the platform: For some users, making the choice is quite simple. If you work on a Macintosh computer and are looking for a package with coding functions, you have a choice between HyperResearch and Nud*ist. (There may be a few others, but they are not as visible.) There is of course the option of using conversion software like Soft Windows to run a PC program on a Mac - now it becomes more complicated again…. Another excluding criteria could be the system requirements. Newer versions often require you to have Windows 95 or NT installed on your machine. It is also no fun to run one of the more complex programs on a slow computer, you may have to wait ages before a search is completed…. Financial constraints, learning time and computer skills might also be issues that influence a decision in one way or another. Computer novices might have a hard time with programs that are sophisticated and that offer lots of functions. They may prefer a simpler program to begin with. Sometimes it could be a good idea to look around which programs are used by people that work in close proximity to you. It could be be that this is not the best program for your project requirements - as mentioned above, most programs can be appropriated somehow - but you might like to have people around who can give some support if you get stuck. Thus, there is no straight answer to the question of which is the best software. The best advice is: Get some information on program features, match them up with your project needs, play a bit with the demo versions, consider system requirements and computer skills, ask others and then simply trust your intuition or your reason. Some additional information that may help you in deciding which of the programs is the best one for you can be found on the page "Introduction to Software". Look at the following three questions: What are the important functions and features one should look for? A few more questions that are important to answer before one decides to buy a particular program. What kind of features should a good program offer?
DISCLAIMER: The descriptions reflect my personal experiences with the programs and should not be (mis)understood as an objective report |
|
|
|
QUARC
- Qualitative Research & Consulting, Dr. Susanne Friese, Dr. Susanne Friese, Fallingbosteler Strasse 1, D-30900 Bissendorf, Germany |
||