Posted: July 30th, 2010 | Author: Tabitha Hart | Filed under: articles & books, research tools, transcribing | 1 Comment »
Anyone in the business of analyzing talk knows that with every interview, focus group, or interaction comes the laborious task of transcribing it. When I’m really speedy I can transcribe 15 minutes of talk in about one hour, but that’s only a rough cut that doesn’t include Jeffersonian notations. When I’m adding those in, it nearly doubles the transcription time.
(Note: The Jeffersonian Notation system, developed by the late Gail Jefferson, who was an acclaimed Conversation Analyst, is a set of notations/markers that can be used to preserve phatic and other paralinguistic qualities of speech. See this Glossary of Transcript Symbols by Gail Jefferson herself.)
Is there anything to make transcription easier, short of paying someone else to do it for you? This week in the NY Times, David Pogue wrote an enthusiastic review of Dragon NaturallySpeaking for Windows.
Dragon NaturallySpeaking is a newly revamped and (according to Pogue) much improved voice recognition software package. I don’t have a copy of it myself, but it sounds like it might be a great tool for generating good (not perfect) rough cuts of recorded talk. Even better, the professional, premium, and home packages all have multiple language capabilities, including English, Dutch, French, German, Italian and Spanish. The downside is that Dragon NaturallySpeaking is only available for PC. However, Nuance, the company behind Dragon NaturallySpeaking, does offer a software package called MacSpeech Dicate for us Mackies.
If I paid the $100-200 for the home or premium versions and had my transcription time greatly reduced, I’d think it well worth the price.
Any insight on this?
Posted: July 15th, 2010 | Author: Tabitha Hart | Filed under: research tools | Comments Off on Ethnography app for iPhone
Has anyone tried the ethnography-themed “EverydayLives” app for the iPhone? It purports to help researchers with in-the-field data collection of still and movie images. It seems to have tagging, note-taking, and archiving functionalities. I believe you can also easily share the data with other team-members. There’s a short video demo of it on YouTube. So far it’s difficult to find any substantive reviews of it. It’s USD 12.00, so not a huge investment, but it would be nice to hear what other users have to say.
Posted: July 2nd, 2010 | Author: Tabitha Hart | Filed under: research tools, TAMS | 11 Comments »
Getting started with TAMS Analyzer
I’m updating my notes on TAMS as I get better at it. This should help you get started with the first-level coding of your data. As I learn more I’ll continue to share steps and tips.
- Currently TAMS only works with data in rtf format, although I understand that the upcoming version will also accommodate pdf. In the meantime, you’ll need to convert your data to rtf before you import it. (See user manual page 8.)
- I recommend creating a basic init file right away. (See user manual pages 35 & 95.) This file will save you a lot of time as you code your data as it tells the program how to treat certain variables and/or contextual data that you mark up in your texts. Note that you have to TELL the program which file to treat as the init file. Once you’ve created it (call it “init file”), go to the file list in the workbench. Highlight the init file in the list of files, and then click the “init file” button. Now in the bottom left corner of the workbench you’ll see “Init file: name of the file you selected.” This confirms that which file the system “sees” as the init file. These are the codes I put in my init file:
- {!universal datatype=””}
- {!context role}
- {!context speaker}
- {!button speaker}
- {!button “{!end}”}
- You can also do “if” coding, like {!if speaker=”Jane”=>role=”trainer”}
- Now, consistent with the init file, you’ll include some basic codes in each and every file you work with. Think of these as basic, structural codes that you’ve already decided on, which are linked to the init file. These are the particular ones that I’m using:
{!universal datatype=”Interview”} (or fieldnotes, or forum posts, etc.)
{role}{/role} (I code the role of the person in question, so it looks like this: {role}student{/role})
{speaker}{/speaker} (I code the name of the speaker, so it looks like this: {speaker}John{/speaker})
The benefit of steps one and two above is that in my search results I now have columns for contextual information like the type of text (interview, fieldnotes, forum posts, etc.), the speaker in question (Jane, Bob, James, etc.) and their role (student, teacher, staff member, etc.)
- Other notes on the information above:
- The code {!button speaker} in my init file creates a short cut “button” on each of my files for the {speaker}{/speaker} code. Clicking the “speaker” button is a nice shortcut for me when I code the data, since I use this particular code a lot.
- The code {!button “{!end}”} in my init file creates a short cut “button” on each of my files for the {!end} code, which is a context code. Without the short cut button I’d need to either type this in by hand or use the menu option Metatags>Structure>{!end}. This way, I can insert the {!end} tag with just one click. More about {!end} below.
- In my project, I’m using the context code {speaker}{/speaker} because it’s important to me to be able to link statements with a source (i.e. the person who said it). Given my large interview sample, having the capability to easily link statements/data to people is great. When I’m coding, I use the {speaker}{/speaker} code each time somebody takes a turn. The corollary to this is that I need to tell TAMS when that person’s turn of speech ends. To do this, I use the metatag {!end}. A passage of coded data would therefore look like this: {speaker}Barry{/speaker} When are you going to turn in that assignment? {!end} {speaker}Ralph{/speaker} I’m not sure. Probably next week. {!end}
- TIP (1) be careful to mark all the speakers, or you will think the wrong people are saying the things you are finding.
- TIP (2) put in {!end} whenever the value of speaker changes, or you will be misled as to who is speaking.
- Now we get to the regular data codes. As indicated above, TAMS uses squiggly brackets { } to denote coded data. The codes go on either side of the passage. The end code contains a slash: {code}piece of text here{/code}.
Code names can have numbers and underscore characters. No spaces permitted.
Passages of text can have multiple codes; codes can be nested and can overlap
Create a new code by entering its name into the field, then press “new”
As you create codes you’ll use the “definition” button to define them.
That sums up where I am right now in my first-level coding. I’ll report back with more information as I progress.