. "Understanding the Documentation Problem for Complex Census Bureau Computer Assisted Questionnaires." Survey Automation: Report and Workshop Proceedings. Washington, DC: The National Academies Press, 2003.
The following HTML text is provided to enhance online
readability. Many aspects of typography translate only awkwardly to HTML.
Please use the page image
as the authoritative form to ensure accuracy.
And another situation is that documentation really depends on the proprietary tools you happen to be using. Now, many times when you’re testing and documenting computer systems and tools … [that is, in general computer systems testing,] you don’t have to use, necessarily, documentation tools that are dependent on a C++ processor, for instance, or something like that. But [in the survey community], because a lot of our CAPI instruments are so tailored to proprietary systems, our documentation is also dependent on that.
And that’s one reason I was talking about a possible future—this is an idea that’s been floating around for a while—where the documentation language could work off of some common representation of the questionnaire so that you would at least have enough market for developing documentation tools. See, right now, these are all stovepipe-type operations, and it’s very difficult for anyone to do documentation without getting to the innards of all this. Now, as we’ll see in the TADEQ presentation, they’ve approached this a little bit in terms of having an XML representation of the Blaise instrument. So they’re thinking along these lines also, to some extent. From a computer design perspective, if you’re thinking along the lines of, “this is a good model,” I just want to make sure you understand we’re already thinking about that. It’s a possibility, but I would say it’s—it hasn’t gone anywhere. And I would say that, occasionally, it gets, I would say, “polite yawns.” [laughter]
On that cheery note … We’re not going to document a pie-in-the-sky model. We have to document the instruments we actually have, the way they run right now. And so let me talk about documenting CASES instruments. I’m going to show you first what some aspects of what an instrument document (IDOC) looks like, and then I’m going to say briefly how one is created, and then maybe a few closing comments before we turn to the next discussion, which will be on documenting Blaise instruments.
If you’re going to start with an instrument document, one thing that’s useful to do—perhaps you have done—there is an online file that is always available with an instrument document that gives some information on, you know, what it looks like, what indexes are available, it talks about it. And even, down here—it’s kind of cute—it even gives you a color-coding that you’ll find in there. So, if all of these things aren’t immediately intelligible, some of these things you can obtain just by looking at that help file.
Now let’s switch to the opening page for our old friend, the SIPP instrument. When you look at the instrument document for the SIPP instrument, this is what it comes up. Here it says the title and so forth, and so forth, and it says, “start over there on the left.” And you can get the help file I told you about, which is the way to start. But what I