Table of contents

COMPLETE CATI DOCUMENTATION ON A SINGLE PAGE QUICK START GENERAL INTRODUCTION
SUPERVISION Introduction Define active projects Describe interviewers Set up the script Populate the data set Control data collection Manage telephone numbers Attribution of telephone numbers Analyse productivity	INTERVIEWING Introduction Log-in procedure Selecting a project, strata and types of calls Selecting cases according to a third criterion Automatic number, particular number or terminate Managing a call Time keeping
APPENDIX A CATI Project initiation checklist APPENDIX B Recent changes and additions APPENDIX C Time data in CallWeb APPENDIX D Audio-visual supervision APPENDIX E Playing sound files during an interview APPENDIX F Batch dialer installation

Quick start

This page provides brief instructions on how to set up your first CallWeb CATI project. It is assumed that you have access to a Web server equipped with CallWeb and to an FTP program to transfer files to the server.

1. edit the BASEprojets project to document your new project;
2. edit the BASEpasse project to make sure interviewers can log in;
3. add the following questions to the script: PRESTRATE, CALCTESTQUOTAS, TESTQUOTAS;
4. add call result codes to the project;
5. populate the data base with the telephone numbers to call and the stratum to which each number belongs;
6. add telephone numbers to the call queue;
7. unleash interviewers.

General introduction

CallWeb CATI comprises a series of computer programs which add structured control and access to CallWeb questionnaires in the context of telephone interviewing.

CallWeb CATI includes a set of supervision modules to define active projects and their behaviour, to describe active interviewers and manage their time, to feed telephone numbers to the call queue and to control the state of the data collection.

CallWeb CATI also includes a set of interviewing modules which control the attribution of telephone numbers to interviewers, dial the numbers on behalf of interviewers and manage the collection of information on call results.

This documentation is organized accordingly.

Supervision — Introduction

CallWeb CATI includes a set of supervision modules for the following functions:

• to define active projects and their behaviour
• to describe active interviewers and manage their time
• to set up the CallWeb script for CATI use
• to populate the data set
• to feed telephone numbers to the active number set and
• to control the state of the data collection.

Defining active projects

All CallWeb CATI projects must be defined and activated in the BASEprojets CallWeb project. Projects that are not declared or activated in the BASEprojets CallWeb project are not available to supervisors and interviewers — this way Web-only projects can be managed along with CATI projects, without interference.

Defining a project simply requires

• stating a name,
• possibly a title, and
• a telephone suffix code (for billing purposes).

Also, projects

• can be made to use the auto-dialer and the predictive/batch dialer,
• can allow interviewers to change telephone numbers of individual cases,
• can be temporarily switched on or off without deleting the entry from the list and
• can be associated with a "do not call before" time and a "do not call after" time which are expressed in local respondent time.

The BASEprojets CallWeb project is most easily viewed and edited from the cwnav.cgi utility which is accessible from the integrated module.

Describing interviewers

Before they are admitted into the CallWeb CATI system, interviewers must be granted permission. This is done in the BASEpasse CallWeb project.

Describing an interviewer simply requires

• stating a name and
• providing a password

The BASEpasse CallWeb project is most easily viewed and edited from the cwnav.cgi utility which is accessible from the integrated module.

If the auto-dialer is used, each connected work station must be defined in the BASEposte CallWeb project — which is most easily edited in the cwnav.cgi utility.

Finally, the CallWeb CATI project automatically cumulates interviewer time spent on each project. The time data are stored in the BASEtemps CallWeb project. If an interviewer does not properly exit the system, an error is displayed next time they attempt to re-enter the system and a supervisor has to locate the time slip in the BASEtemps CallWeb project using cwnav.cgi and edit the transaction to correct it.

Setting up the script

There are some CallWeb script requirements that are specific to the CATI environment. They are explained below.

1. add a PRESTRATE question
2. add a CALCTESTQUOTAS question
3. add a TESTQUOTAS question
4. document possible call results

PRESTRATE question

Very early in the questionnaire there must be a question named PRESTRATE which stores the stratum membership of every case in the data base; every case must be assigned a value for this question via prepopulation. If the project does not use strata, PRESTRATE must still be present and contain a single category.

The text of the PRESTRATE question must document the maximum number of cases which will be allowed to be used in each stratum. The syntax is as follows:

1 = 100, 2 = 50, 3 = 90

This limits stratum 1 to 100 cases drawn from the entire data base into the list of active telephone numbers, 50 for stratum 2 and 90 for stratum 3. Using this mechanism, one can prepopulate the data base with a large number of telephone numbers and "open the tap" as required without having to perform additional prepopulation.

Strata are defined using response categories; there shall be as many response categories as there are strata.

The PRESTRATE question should be given the NEVERUPDATE characteristic so that it is never displayed to the interviewers and that it cannot be modified once prepopulated. A typical PRESTRATE definition would look as follows:

PRESTRATE NEVERUPDATE
% text
    1 = 100, 2 = 50, 3 = 90
% note
% categories
    Montreal
    Toronto
    Vancouver
% skips
% display condition
% open end
! end ==============================

CALCTESTQUOTAS question

CallWeb CATI demands that quotas be defined. The basis for quota definition can simply be membership to the original strata defined in PRESTRATE but quotas can also be based on any other criterion or combination of criteria. CallWeb supports quotas for groups that are defined on-the-fly during the interview and based on responses to the questionnaire as well as prepopulated or calculated data. Refer to the CallWeb base documentation for a description of quota management.

The simplest CALCTESTQUOTAS question simply transfers PRESTRATE stratum membership over to the TESTQUOTAS as follows:

CALCTESTQUOTAS CALCUL
% text
    TESTQUOTAS = $PRESTRATE
% note
% categories
% skips
% display condition
% open end
! end ==============================

TESTQUOTAS question

As early as possible into the questionnaire, a question named TESTQUOTAS (of type QUOTA) must be inserted to test whether required completions have been reached for the stratum to which the current case belongs. Refer to the CallWeb base documentation for a description of quota management.

Actual quota groups must be defined as categories of this question.

In the following typical example, the project manager is striving for 40 completions in stratum 1, 25 in stratum 2 and 60 in stratum 3. Once a stratum has reached its quota, based on the presence of data in a sufficient number of cases in question QCOMPLETE, interviews are routed to question QUOTAFILLED and terminated.

TESTQUOTAS QUOTA
% text
    complete = QCOMPLETE, skip = QUOTAFILLED, 1 = 40, 2 = 25, 3 = 60
% note
% categories
    Montreal
    Toronto
    Vancouver
% skips
% display condition
% open end
! end ==============================

Call results

Call results that will be offered to interviewers are defined using the cwcodescati.cgi utility which is accessible from the integrated module. Call results can also be copied from one project to the next by copy the file named project1.ccw to project2.ccw (make sure to give write access permissions to the world si that cwcodescati.cgi can modify this file).

There can be any number of result codes; each is defined, in cwcodescati.cgi, on the basis of the following characteristics:

• a code name which is displayed to interviewers and in field reports;
• whether or not the result code corresponds to a completed interview; only one result code can bear that characteristic;
• whether a callback date is required for the code
• whether a callback time is required for the code; if a time is required, a date is automatically mandatory. Result codes requiring a date but not a time correspond to general day-based appointments or "not available until" such a date situations;
• whether or not the result code corresponds to a refusal situation;
• whether or not the result code is allowed to replace a previous refusal code; for example, this gives the project manager the ability to allow refusals to be transformed into completions, but not into busy signals;
• whether or not the result code is usable only once; using this characteristic, the project manager can control that a code, say Refusal, cannot be entered a second time; in this example, a second refusal would have to be coded as Second Refusal;
• whether or not the result code is invisible to interviewers; it is sometimes useful to deactivate a result code (say, after a pretest) but it must be maintained in the result code list if a single case uses that code in the data base;
• the number of times a result code can be used before a case is retired from the project; for example, a single use of a "Definite refusal, don't ever call again" code could retire a case; a value of 0 indicates that the code may be used without incidence on case retirement;
• whether an interviewer comment is allowed or is mandatory if the result code is selected;
• whether the result code represents a human contact (e.g., the interviewer talked to someone); this information is used by cwoutcomes.cgi to calculate the adjusted response rate;
• the response rate analysis group to which the result code belongs; response rate categories are defined below the list of result codes; they are used by cwoutcomes.cgi to calculate the adjusted response rate.

Populate the data set

Before telephone interviewing can take place, the project data set must be prepopulated with at least the following information for each case:

• a unique ID must be used as _telkey;
• a telephone number (including area code) must be used as _telephone; if the telephone number field is empty, the _telkey field is used instead;
• a stratum must be imported into the question PRESTRATE for each case.

During prepopulation, the offset between the time zone of each number (based on area code) and GMT is calculated and stored in the data file. Therefore, the GMT offset of each area code used in a project must be defined in the CallWeb installation file.

Additional fields may be required on a project by project basis, such as a contact name or a substitute telephone number. Such additional information would be prepopulated into separate questions which would be given the INFOCATI characteristic so that they are displayed to the interviewer in the case management interface.

Data prepopulation is documented in the main CallWeb documentation.

Control data collection

The cwsuper.cgi interface gives access to field management actions for each project that is defined as "active" in BASEprojets. The following paragraphs describe each column of cwsuper.cgi interface.

Define or stop updates
This column may contain an open folder icon or a skull icon. The open folder icon indicates that there is no update planned for the project; clicking on this icon brings up the update planning interface (cwsuperpro.cgi). The skull icon indicates that there is an update planned for the project; clicking on this icon stops the automatic update and brings up the update planning interface.

Most recent update
This column indicates when then most recent project update has taken place — as long as a call queue exists for the project.

Next update
This column documents in how many minutes the next project update will take place.

Additions with the most recent update
This column informs about the number of telephone numbers which were added to the call queue at the last project update (e.g., new numbers, appointments, numbers brought back after a pause).

Numbers available to interviewers
This column contains the number of telephone numbers currently available for interviewers to use (the call queue). Note that numbers in time zones which are currently closed (because of the project start and end times) are included in this total.

Number of interviewers
This column reports on the number of open BASEtemps slips for each project. A value followed by a question mark refers to time slips opened before the current day. The numbers are hyperlinked to a cwnav.cgi list of the corresponding time slips.

Completes according to cwstats
This column reports the numbers of completed questionnaires according to the cwstats data base which is updated every hour.

Condition of the fieldwork
this icon produces a large table describing the state of the fieldwork based on the last call result; the table comprises three parts:

• the first provides a picture of the distribution of last call result code by prepopulated stratum (PRESTRATE);
• the second reports the average number of calls made according to last call result code and according to the combination of prepopulated stratum abnd result code;
• the third describes call results within calculated strata (TESTQUOTAS); only cases that have been accessed are reported since TESTQUOTAS requires a calculation that is performed upon opening a case.

State of the call queue
This icon displays a table describing the state of call queue: it offers a breakdown of numbers by strata and last call result. The page also reports the parameters of every update performed since the last reinitialization of the call queue. A red (rather than yellow) icon indicates that the most recent update encountered some constraints (e.g., closed strata, strate where the maximum number of allowed numbers is reached).

Case groups
This icons brings up a listing of existing groups of cases that were predefined for use by the interviewers in selecting the cases they will be provided from the call queue.

Cases by results
This icon calls cwfreq.cgi and automatically builds a table according to call results and strata; each combination of a call result and a stratum is hyperlinked to the underlying list in the cwnav.cgi program.

Productivity
The Gantt chart icon opens cwprod.cgi with a selection for the current project. Productivity stats are available from there.

Entry in BASEprojets
This icon opens the BASEprojets entry for a given project.

Utilities
This icon brings up a cw.cgi menu with the project already selected.

Automatic quota closure

If the required conditions are fulfilled, CallWeb automatically closes PRESTRATE-based quotas as soon as the first interviewer reaches the quota-filled situation. Thereafter, no more cases from this newly-closed quota is dispatched or added to the call queue. The conditions that are necessary for this automation are as follows:

• PRESTRATE and the first active QUOTA question have the same list of categories;
• the project is defined as a "# CATI = yes" project in the project pound instructions or in the system installation file;
• the project does not contain a "# Close full quota = no" instruction; adding this instruction to the system configuration file would deactivate the automatic quota closure system altogether;
• the BASEprojets project exists and it contains the QUOTASPLEINS field;
• the project has been compile while all of these conditions were met.

To re-open a quota that was closed after being reached, perform the following actions:

• edit the questionnaire to increase the quota target for the quota in question in the definition of the quota variable;
• recompile the questionnaire;
• request a recalculation of the call queue or wait for the call queue to recalculate itself.

Manage telephone numbers

In a CATI context, managing telephone numbers means identifying which telephone numbers must be made available to interviewers, and repeating this identification so as to make the most efficient use of the sample. In CallWeb CATI, this is accomplished in supervision modules which are entered via the cwsuper.cgi program. Any number of projects may by managed from one supervision workstation.

Principles

The principles of telephone number management implemented in CallWeb are as follows:

• only numbers that have been selected explicitly to be accessed by interviewers are available to them (in the call queue);
• numbers are added to the call queue only via the cwsuper.cgi update process;
• updates may be done manually upon request or automatically at regular intervals; automatic updates probably shouldn't be done more often than every 10 minutes; a 20-minute interval has proven effective;
• each manual update may include different sets of criteria and, hence, draw different types of numbers for interviewer usage;
• appointments are automatically brought into the cann queue if the automatic update is selected;
• automatic updates use the update parameters last entered; while previous updates may have left their selected numbers in the call queue, only numbers corresponding to the criteria last entered by the supervisor (and appointments, automatically) are added during automatic updates;
• once a telephone number has been selected by an interviewer, it is reserved for their use for a period that is selected by the supervisor;

Supervision interface

From the cwsuper.cgi module, the supervisor selects one project to manage. Then, a menu such as the following is displayed.

This main supervision and field management menu is comprised of three areas:

• the top part reports the number of telephone numbers in the current project call queue;
• the right end-side lists existing call result codes; the supervisor selects the types of calls that they want added to the call queue and the delay between the last call and a new attempt; this section also allows for the inclusion of additional new cases (that have never been called);
• the left end-side describes the specifics of the update request:
• enter the last-call dates for the numbers you want brought into the call queue; this is normally left to default to a very large period of time to avoid losing cases;
• determine the number of previous calls above which a number will not be brought into the call queue;
• identify from which stratum or strata numbers should be drawn; it is probably best to select them all (as long as work is required in all of them) since CallWeb CATI manages time zone requirements by itself based on the calling times defined in BASEprojets;
• select an automatic update frequency or Never for manual updates;
• select a type of appointment management (relevant only in automatic updates) or None for no appointment management:
• Massive appointment management: appointment calls are made by the interviewer available next in the project without regard for the identity of the interviewer who took the appointment.
• Passive personalized appointment management: appointment calls are by the interviewer who took the appointment; if this interviewer is not available in the project, the appointment is missed.
• Active personalized appointment management: in principle, appointment calls are by the interviewer who took the appointment; if this interviewer is not available in the project, 5 minutes after the appointment time, the number is attributed to the interviewer available next in the project.
• determine how long the interviewer reserves a case when it is automatically brought to their attention;
• click Submit to initiate the update; every minute, the server verifies whether it must perform an update, therefore it can take that long before the update is initiated;
• the Reinitialize button empties the call queue; this is done without further warning.

Attribution of telephone numbers

There are two ways to attribute telephone numbers to interviewers: manually via the Search function or automatically. In the manual Search, the interviewer is provided with a list of numbers to call and they use them to query the data base. This is an adequate approach to focus specifically on certain cases (say, in-bound calls) but it is not an efficient way to manage the call queue or interviewer time. For this, use the automated attribution of cases.

When numbers are attributed automatically (by the interviewer simply requesting a New number), CallWeb scans the call queue and identifies the next priority number. The following logic is applied:

• only numbers corresponding to the interviewer and time constraints are considered. The following cases are discarded:
• cases already attributed to another interviewer and that have not passed their reservation period;
• cases where the respondent time is outside the active hours of the project (except appointments);
• cases outside the strata, call disposition and third criterion selected by the interviewer;
• within the pool of available numbers, cases are dispatched with the following priorites:
• appointments have the highest priority but their priority diminishes as one moves away from the appointment time (e.g., if appointments were due at 10:00, 10:05 and 10:10, the interviewer requesting the next case at 10:11 is given the 10:10 appointment); appointments are defined as disposition codes requiring a callback date; if an appointment is missed by more than 30 minutes, it is dispatched only if the respondent's time is within the project working hour — otherwise, appointments are respected, even outside project working hours;
• cases with fewest calls come next so as to equalize the number of times cases are attempted;
• call disposition codes with shorter return-to-the-queue times have a higher priority of selection than cases with longer return times (e.g., busy results with a return time of 30 minutes have a higher priority than no-answer results with a return time of 4 hours);
• untouched cases have the lowest priority;
• if refusals are brought back into the call queue, a refusal which was followed by another call result is controlled by the latter disposition code.

Analyse productivity

cwprod.cgi, the productivity reporting module, works hand in hand with cwappels.pl to create and to exploit a data base of time spent on projects and results obtained.

Sources of information

cwappels.pl draws information from two sources to create the BASEprod data base (a CallWeb-format data base):

• daily, during the night, cwappels.pl creates the BASEappels data base which documents each call found in live projects. In the process, it tags each call as a completed interview or a refusal based on the call results and their behaviour. The module also converts GMT-based times stored in the call history to the local server time;
• time spent on projects is obtained from the BASEtemps data base — but only from time transactions which
• have not yet been processed, to avoid double counting;
• which are CATI-related according to a flag placed by the interviewer interface when it created the time transaction; and,
• which are closed.

cwappels.cgi matches time transactions to call results at the interviewer + project + time level and stores the resulting data in BASEprod; it is normally called once a day, at night. Once a time transaction from BASEtemps has been processed, it is not re-analyzed. Therefore, modifications to time transactions after cwappels.cgi has processed them are disallowed.

Producing reports

The cwprod.cgi module queries the BASEprod data base according to projects or interviewers or dates or shifts and returns a number of self-explanatory indicators of performance (e.g., the number of completed questionnaires per hour).

One final composite index requires some explanation. Labelled "index", it accounts simultaneously for completes and refusals while recognizing that there are circumstances when completes and refusals have differing values. Specifically, the default index equation is as follows:

( c₁ + 2c₂ + 5c₃ - 3r₁ ) / hours

where
• c₁ = number of questionnaires completed on the first call
• c₂ = number of questionnaires completed on subsequent calls
• c₃ = number of questionnaires completed after a refusal
• r₁ = number of first refusals (note that refusals after an initial refusal are not penalized)
• hours = number of hours logged in BASEtemps

This default index can be redefined by entering a new calculation in the productivity_index installation option, which affects all projects, or by adding a new calculation as part of a # Productivity index pound instruction, on a project by project basis.

Interviewing — Introduction

Interviewers are responsible for the selection of the types of calls they will make during their shift. CallWeb CATI then feeds them one number after the other, as soon as they have provided a call result code for the number they were provided. Much of the interviewer work is done from a single screenful of information.

Log-in procedure

Interviewers must log into the CallWeb CATI system every time they start their shift and every time they need to change project or change the nature of the telephone numbers they want to handle within a project.

Interviewers enter the CallWeb CATI system using the int1acces.cgi script. They enter their user name and password as they were supplied in BASEpasse by the supervisor. They also specify in which language they want the interface to appear to them — the system default language is pre-selected.

Validation of the log-in is done immediately.

If they select the demonstration mode, interviewers are taken through exactly the same steps as they would in real mode (project selection, case selection, etc.) except none of their selections are saved, either in the call history or in the questionnaire itself.

Selecting a project, strata and types of calls

Once logged-in, the interviewer is shown the list of all active projects. He/she clicks on the button corresponding to the project he/she was attributed for the shift.

The interviewer then needs to identify the cases he/she was told to work on. The case selection is always based on the stratum membership and on call dispositions, at a minimum. It is possible to add a third selection criterion, as is displayed below and as is explained on the next page.

If call groups are defined for the project, the interviewer case selection windows includes a radio group (as in the exemple above) which includes each of the groups defined as well as the capacity to make an ad hoc selection. Interviewers are expected to make the selection which corresponds to the instructions they were given.

The system asks for confirmation and validates these entries before proceeding with the interviewing process.

The selection made by the interviewer on this menu is stored in the BASEtemps data base for eventual audit.

Selecting cases according to a third criterion

The previous page explained how interviewers are called upon to select a project to work on, and cases to access according to the project strata and the most recent call disposition.

Interviewers can also be offered a third criterion (beyond the strata and call dispositions) to select cases within a project. Interviewers could then select cases on the basis of, say, the respondent language or gender or any other (known or yet unknown) characteristic.

In order to activate this feature, the following steps must be taken:

• the questionnaire must include a "# CATI selection 3" instruction which indicates which question in the questionnaire acts as the third selection criterion. The instruction syntax is as follows: # CATI selection 3 = question_name, YES|NO
• the "question_name" must correspond to a question which exists in the questionnaire; its categories correspond to the relevant groupings of cases (e.g., a language question would contain all of the relevant language codes);
• the YES|NO selection is called the "action field": if set to YES, it allows interviewers to modify the value of the datum from their call management window (e.g., it could allow them to enter a language code based on an answering machine message, where no language was known in advance).
• the question indentified in the "# CATI selection 3" instruction must exist in the questionnaire; it should probably be of the STOCK type so that it is not displayed during the interview but this is not a requirement; if the action field is set to NO in the pound instruction, the question could be given an INFOCATI type so that the existing value is shown to interviewers.

Once this feature is activated, the following happens:

• a third selection criterion box is displayed to interviewers in the login process; this box includes the categories of the target question in the questionnaire as well as an additional category representing the absence of data (e.g., no language information was available for the case);
• interviewers select one or more of the third selection categories to draw cases from the call queue;
• if the action field is set to YES, interviewers are shown a radio group (or a dropdown list if the SELECTION3 question bears the DROPDOWN type) of categories in their call management interface and they have the ability to change the existing data for the case they are managing.

Automatic number, particular number or terminate

The interviewer now faces a decision as to the next task:

• asking for a new telephone number to be supplied automatically by CallWeb CATI according to the scheduling priorities (New Number button);
• entering a complete telephone number (with its 5-digit random suffix) to access a particular case (in the box, before clicking the Search button);
• closing the work period and the time slip, getting ready to resume in another project, stratum or call status, or to have a cup of tea (button Close the work period).

Managing a call

Whether the interviewer has requested an automatic number or a specific case, a menu resembling the one below is displayed.

This menu is made up of four areas:

• The top area relates to the telephone number selected. The number is displayed on a yellow button, ready to dial. This button is used to start the questionnaire in a new browser window in case the contact is successful. If the project parameters allow that interviewers modify the telephone number, two text boxes are offered in case a different telephone number needs to be recorded; this new number is saved with the "Save this number" button.
• The middle left part of the menu supplies information on the case: the comment recorded as part of the last contact; the stratum to which the case belongs; any other data that was given the INFOCATI type; and, information on the last call. This is also where the appointment buttons are located (see last bullet).
• The bottom left part of the menu gives the interviewer the choice of the operation that will follow the present case: either the system will supply another automatic number or it will display the three-way decision menu which allows to search for a particular number or to terminate a work session.
• The right side of the menu lists possible result codes (remember that these result codes are not fixed but rather entirely customizable on a project by project basis). Once the interviewer has determined how the call ended (completion, refusal, etc.), he/she clicks on the appropriate button; this result is appended to the call history and the interviewer is supplied with the window selected in the bottom left portion of the current menu. The interview completion button is always first in the list. Appointment-related call results are listed to the left of the other call results. Call result buttons are colour-coded according to whether they allow (yellow), require (green) or disallow (red) the use of a comment (event if a comment is disallowed, it is possible to carry over a comment from a previous call using the radio group in the middle left portion of the menu).

A contact script (text) may be supplied in HTML format in file consigne.html in the CallWeb project directory. If such a file exists, it is hyperlinked to a button displayed in the middle left portion of the menu.

A better solution for contact scripts, though, is to use a CONTACT-type question. Such a question is not displayed as part of the normal questionnaire operation. If present in the questionnaire script, a button is added to the interviewer case management interface (labelled "contact script"). Clicking it pops a new window with the CONTACT question text. This text may contain recalled values (e.g., the name of the person to interview or any other information available in the data record).

If a # Historique = oui or # Historique = yes pound instruction exists in the questionnaire, the entire call history is hyperlinked to a button displayed in the middle left portion of the menu. Since this is an interviewer productivity killer, it is customarily not used. It is possible to display the call history without identification of the interviewers who logged the previous calls using this variation on this pound instructions: # Historique = oui, sans interviewer or # Historique = oui, without interviewer.

Time keeping

Interviewers enter the CallWeb CATI time reporting module using the int4temps.cgi script. They enter a start date and an end date for the report to be produced as well a their user name and password as they were supplied in BASEpasse by the supervisor.

CallWeb CATI then produces a daily report of hours logged for the requested period.

Appendix A

CATI Project initiation checklist

The following checklist is offered as a guide to control that all steps of the project installation process have been completed.

Appendix B

Recent changes and additions

Appendix C

Time data in CallWeb

There are two types of time data in CallWeb:

• timestamps related to the questionnaires (questionnaire initiation time and prepopulation time); these are stored in server time, that is, the time returned by the server, within its time zone;
• timestamps related to interviews (call time and appointment time); these are stored in GMT time so that the current time for the respondent can be calculated easily, but they are displayed in server time, and so that multiple CallWeb servers located in different time zones can collaborate on a single project.

Appendix D

Audio-visual supervision

Technical requirements. Audio supervision is accomplished via the telephone system. Using the Asterisk PBX system, CallWeb offers a way to easily connect with an on-going call. Video supervision is implemented using a VNC server installed on each interviewer station and a VNC client running on the supervisor station. TightVNC is a free implementation of the VNC protocol which has performed well in various installations. Refer to the TightVNC documentation for installation instructions relative to that software. The following assume the pre-installation of the Asterisk PBX and of TightVNC.

Operations. cwphone.cgi lists the phones lines in use and matches them with interviewer station IP addresses, interviewer name and project. The duration of the on-going call is also indicated. Once the supervisor station phone extension is supplied to cwphone.cgi, magnifying glass links are added to the page; clicking on one of them connects the supervisor phone to the on-going interview and pops a window showing the current state of the interviewer display.

Accessing recordings. If interview recording is activated in BASEprojets, corresponding .wav and .mp3 files are accessible from cwnav.cgi. Usual cwnav.cgi case selection tools can be used to focus on the cases of interest (e.g. completed interviews or cases handled by a certain interviewer). Selecting the "Display .wav/.mp3 files" checkbox adds a .wav/.mp3 column in the case-by-case output. Sound files are hyperlinked such that left-clicking opens the file with the sound application available on the local computer; it is also possible to save a local copy of the sound file by selecting the "Save target as" (or equivalent) command in the right-click context menu.

To the extent possible, sound file names give some indication about the content of the file. The name displayed starts with the date and time of the call, followed by the call sequence number (1 for the first call in a case), the language of the call (if available) and an indication of whether the call was a completed interview (CO) or not (UN). For example, in the image to the right, the last case contains a call made on October 14, 2009 at 8:22PM; it was the first call to the case and it led to a completed interview in French.

The real name of the file is longer than that displayed in cwnav.cgi. The underlying complete file name is prefixed with the project name and the case _telkey.

Installation. Assuming Asterisk and TightVNC are up and running, the rest of the installation required is as follows.

• add the following context in /etc/asterisk/extension.conf and reload the Asterisk contexts:
  [ext-ecoute]
  exten => 8888,1,Answer
  exten => 8888,n,NoOp(cwphone.pl: ecoute=${ecoute})
  exten => 8888,n,ChanSpy(SIP/${ecoute}|q)
  exten => 8888,n,Hangup
  
• on the Asterisk server, ensure that the supervisor station has access to the PBX software in /etc/asterisk/manager.conf
• on the supervisor station:
• ensure that "vncviewer" is installed
• ensure that Perl is installed (which it is by default on a Linux station)
• install the Net::Telnet Perl module
• perl -MCPAN -e shell
• install Net::Telnet
• exit
• copy the cwphone.pl script on the supervisor station and note down its location
• install Firefox (version 1.5 or more)
• in Firefox, install the StartALocalProgram extension (may require issuing the following command at the system prompt: "firefox startalocalprogram.xpi"; restart Firefox after installation)
• in Firefox, enter the URL about:config and edit the following keys:
  • put the full path to Perl (usually /usr/bin/perl) in the following keys: extensions.startalocalprogram.launcherLocation and extensions.startalocalprogram.launcherLocation.linux (or mac or windows)
  • put the full path to cwphone.pl in the following keys: extensions.startalocalprogram.programToLaunch and extensions.startalocalprogram.programToLaunch.linux (or mac or windows)

Appendix E

Playing sound files during an interview

Technical requirements. Playing sound files during an interview is accomplished via the telephone system. Using the Asterisk PBX system, CallWeb offers a way to easily start and stop playing such sound files. Sound files must be saved on .gsm format. Under Linux, several sound file editors can save files in this format. Under Windows, WavPad does it too.

Operations. Start playing a sound file by inserting a CALCUL question in the questionnaire and performing the following calculation: PLAY = start_wav("sound_file") where "sound_file" is the name of the file on the Asterisk server, typically custom/some_name without extension (since Asterisk will select the most relevant file format). The sound file will stop playing at the end of the file; it can be stopped using another CALCUL: STOP = stop_wav().

Installation. Assuming Asterisk is up and running, the rest of the installation required is as follows.

• create one Asterisk meetme room for each interviewer station; name them 6 preappended to the last two portions of the station IP address (e.g., the meetme room for station 192.168.10.128 is 610128).
• add the following context in /etc/asterisk/extension_custom.conf and reload the Asterisk contexts:
  [cw-to-meetme]
  exten => _.,1,Answer
  exten => _.,n,MeetMe(${EXTEN}|q)
  exten => _.,n,Hangup()
  [cw-play-wav]
  exten => s,1,Answer
  exten => s,2,MeetMe(${myconf}|q)
  exten => s,3,Hangup
  exten => endmsg,1,Answer
  exten => endmsg,2,Playback(${mysoundfile})
  exten => endmsg,3,Hangup
  
• create the gsm sound files and place them on the Asterisk server in the following directory: /var/lib/asterisk/sounds

Appendix F

Batch dialer installation

Technical requirements. The batch dialer requires an Asterisk 1.6 server. The CallWeb server needs to be able to connect to the MySQL server on the Asterisk machine.

Operations. Batch dialing is requested in BASEprojets by specifying the number of telephone numbers to dial in a batch (setting the batch size to 1 deactivates the batch dialer). When the interviewer requests the next case, that many calls are issued. Non-human contacts are identified and stored in the call historically automatically. Human calls are passed on to the interiewer. If more than one human contact are identified in a batch, the excessive ones are dropped and entered an "extra" result is stored in the call history.

Installation

• On the Asterisk server:
  1. create the "cw" MySQL data base;
     CREATE DATABASE IF NOT EXISTS cw;
  2. create the "cwdial" table in the cw data base on the Asterisk server
     CREATE TABLE IF NOT EXISTS cw.cwdial
         (
         insert_date char(14) NOT NULL,
         insert_epoch char(14) NOT NULL,
         client char(64) NOT NULL,
         projet char(64) NOT NULL,
         lot char(64) NOT NULL,
         _telkey char(64) NOT NULL,
         _telephone char(32) NOT NULL,
         interviewer char(64) NOT NULL,
         n_dans_lot int(10) unsigned NOT NULL,
         resultat char(32) NOT NULL,
         KEY client (client),
         KEY lot (lot),
         KEY _telkey (_telkey)
         );
  3. place a new copy of cwAST.pl in /usr/bin
  4. place the cadenceur.conf Asterisk context file in /etc/asterisk
  5. integrate this context file in the dial plan, in extensions_custom.conf
     #include "cadenceur.conf"
  6. restart Asterisk
     asterisk -rx "dialplan reload"
• On the CallWeb server:
1. update CallWeb to the most recent version using cwupdate.cgi
2. compile the version of BASEprojets which contains an open-end portion to question SIGNALEUR (Does the project use the auto-dialler? (# calls))
3. place cwdial.pl in the utilities directory of the CallWeb instance
4. add a cron entry to start cwdial.pl every minute (it will die immediately if it is already running); the CLIENT is found in the usager.conf file
   cd /var/www/instance && perl cwdial.pl CLIENT