[edited from support email exchange]
On many of the items, a set of answer options are provided for
selection. For the lowest frequency and for the highest frequency
options the respondent is asked to specify the frequency, as follows..
1- Less than once a week <specify>
2- Once a week
3- Twice a week
4- Three times a week
5- Four or more times a week <specify>
In our test of the items, I noticed the data in the .csv and .sav files
is documented so that the <specify> data is written over the keyed
response rather than in as a separate variable. In this way if someone
indicated "Less than once a week" the data would not appear as "1" but
as whatever text was specified. I don't see this data as a separate
variable in the .txt files. I don't see any syntax that addresses it as
a separate variable.
I didn't find anything in the manual that addresses this issue.
Is it possible that I am overlooking something in the available data
files that documents the keyed response separately from the <specify>
response? Is there any way to retrieve the original keyed response? Is
this problem unremediable in the written data but fixable in programming
for future data collection?
You are correct. This is the first time anyone has brought this to our
attention. I had never anticipated people offering two or more specify
options within the same question. I will add this to our to-deal-with
list. In the mean time, are you finding examples where the data become
confusing or is it mainly a hassle to have to deal with the coding? I
ask because it would have implications for how we fix it. As a short
term fix, I could suggest creating a single skipto value for these items
rather than using the specify option. If they choose one of these
"other" type options then they get a subsequent item which would be a
fill in the blank in which they would specify. Would that provide a fix
while we figure out how best to deal with this in the future?
Thank you for getting back to me so quickly. I'm sorry that there isn't an existing fix. However, I know that this is exactly the process through which versions of software evolve. For the most part, examples are just a hassle to recode. Fortunately our data set is relatively small. However, in some cased the data is truly confused. Using the example in my original email below.... You will notice that "Less than once a week" might be specified as "twice during the four weeks" which wouldn't be a problem to interpret, or "2" which might be confused with option 2 "Once a week" which would be calculated as 4 times during the 4 weeks. A similar problem might occur with a "3", which could mean "less than once a week" specified as 3 times in four weeks, or option 3 "twice a week"
calculating out to 8 times in 4 weeks. At the high end of the scale we could get a "4" which could mean option 4 "three times a week" (for a total of 12 times in 4 weeks) or option 5 "4 or more times a week" specified as 4 times a week (for a total of 16 times in 4 weeks). In the construction of our study, open-ended follow up items allow us to untangle the problems indicated above. So that what we have is really just a lot of hassle. And a fix for the future would be wonderful.
It seems like part of the problem could be addressed by allowing the buttons to be alpha rather than numeric if the data requires it. It would also be helpful to have the <specify> data fall into a separate variable automatically somehow. Your suggestion using an "other" type option associated with a subsequent item would offer a solution, but possibly extend the time or difficulty of the task for those whose responses fall into these categories. This would likely only become a problem in a longer questionnaire with time constraints. If I can provide you with more information on my situation to assist the development of solutions, please don't hesitate to ask.