The Interview Object Model (IOM) defines the components of an interview script, the characteristics of those components, and the way that those components relate to one another. It is related to the Routing section of the interview script and to the mrScriptBasic language in which the Routing section is written.

You may find it useful to have a copy of the Interview Object Model diagram on hand as you read this section so that you can refer to it as you go. The text that follows contains links to topics in the IOM documentation which you can follow. These links are provided simply as a means for you to learn how the IOM components fit together, and there is no requirement for you to read the topics. Note, however, that the Object Model documentation is targeted at programmers and assumes some knowledge of object oriented programming concepts.

Objects are the components of the interview script so, for example, questions are known as Question objects, and categorical responses are known as Category objects.

Objects are made up of different items and sometimes the same type of item will be present in more than one object. For example, a question consists of a question name, a question text, a question type (categorical or text, for example), and an appropriate response definition. A categorical response consists of a response name and a response text. Even though question and response texts will differ in the interview, they are the same type of item so they become an object in their own right in IOM. IOM calls text items Label objects. It defines what a Label object is, and gives each Question and Category object its own Label object.

IOM defines many objects, the most important of which are:

Take a moment to look at the Interview Object Model diagram and you'll see a "map" of the Object Model that has these objects as the top-level objects. You'll also see how the Label and Style objects are used within most of the other objects because most of the other objects have texts and visible display characteristics. This hierarchy is important when it comes to writing code in the Routing section and we'll come back to it later.

Something else you'll notice in the Object Model diagram is that some boxes are shaded whereas others are not, and often the text of an unshaded box is the same as that of its related shaded box, except that the text in the unshaded box is plural. For example, the IOM object contains a Navigations item that contains a Navigation object.

In these cases, the unshaded box represents a collection of the corresponding shaded items; in the example, Navigations is a collection item that contains one or more Navigation objects. If we relate this to an interview, it means that an interview can use one or more navigation buttons. Similarly, the Question object contains a Categories collection item that consists of Category objects. In interviewing terms, this means that if the question allows a categorical response, the question will contain a collection of Category objects each defining one categorical response.

All objects have properties. Each property defines a specific characteristic of the object. Sometimes a property is actually another object or a collection item containing objects, but it can also be a simple entity that defines one particular thing. For example, the Style object has a Color property that defines the color of the object to which it belongs.

If the Style object is attached to a Label object within a Question object, then the Color property defines the color of the question text; if the Style object is attached to a Label object within a Category object, then the Color property defines the color of that categorical response text. To see other examples of simple properties, click any Style object in the Object Model diagram and then click on any of the Read/Write Property links on the IStyle page.

Typical properties for collection items are Count, which returns the number of objects in the collection, and Item, which returns the item in a given position in the collection (for example, the first item).

Properties can be read-only or they may be readable and writable. You can query the values of read-only properties in the routing script. You can set the values of read-write properties to control the way an item looks or behaves in an interview. We'll look at how to do this later in this section, and you'll find numerous examples in the rest of the Interview Scripting documentation.

Type Definitions define constants (variables with fixed values) that you can use when you need to assign a specific value to a property. For example, if you want to display a categorical response text in italics, you can set the value of the font effect property for that category's label to be the name of the italic font effect Type Definition.

The values that a particular property can have are grouped within a single Type Definition, so all the values related to font effects (italics, bold, underlined, and so on) are grouped under the FontEffects Type Definition. Each value within a group has a unique name and value. You do not need to worry about the values, all you need are the names. All names in a group start with the same two-character code which is related in some way to the name of the Type Definition. Using this standard, all font effect names start with the letters fe: fe.Italic, fe.Bold, fe.Underline, and so on.

You can perform actions on objects. In object oriented programming, actions are referred to as operations or methods. One action that you will always use is the Ask action for the Question object because this is how you ask questions. Another action that you might use is the Terminate action belonging to the IOM object: this terminates the interview immediately. There are other operations belonging to these and other objects but you are unlikely to use them in Routing scripts (they exist for use in other applications written in mrScriptBasic).