If you want to give respondents an idea of their progress through the interview you can include an <mrProgressBar> tag in your template. The default progress bar is a single, thin blue line that appears when the second and subsequent pages are displayed:

This is not particularly satisfactory because there is no indication of where the bar will end, so the respondent cannot calculate their relative position in the bar (in fact, it extends the full width of the browser window). Additionally, the respondent may not realize straight away that this is a progress bar.

You can resolve these issues to some degree by placing <mrProgressBar> inside a <div> tag and then adding standard HTML code to alter the appearance of the progress bar. For example:

You can improve things further by using some of the attributes that <mrProgressBar> supports:

where:

The template for this example contains:

which displays a red progress bar followed by the percentage of questions answered so far. For information about how counts are calculated and how you can change this behavior, see How to calculate progress:

The template for this example defines a customized image for the progress bar and displays it vertically on the left of the screen. It uses a table to ensure that the progress bar is always a fixed distance from the question.

When you use images such as the arrow shown here, you will notice that the image is either squashed or stretched to fill the required amount of space. You can avoid the image distortion that sometimes happens with this by using a solid block instead.

The calculations for counts and percentages are very simple and are based on the total number of pages defined in the metadata section. (If each page displays a single question this is the same as saying that the counts and percentages are based on the number of questions in the script.) AsValues reports the position of the current page in the question list and the total number of pages in the form answered/total; AsPercentage reports the same information as a percentage. So, if there are ten questions in the metadata section with each one displayed on a separate page, and the respondent has answered the first five questions, progress is always 5/10 or 50% respectively.

If you want to report progress more accurately by ignoring pages that do not apply to the current respondent, you will need to calculate progress manually in the routing section of the script. There are various ways of doing this, but there are some interview properties you need to know about first. These are:

If the script contains routing so that respondents do not answer all questions (pages) in the script, you may be able to estimate the maximum number of pages that respondents or groups of respondents will answer. If you set this value into IOM.Info.EstimatedPages, the progress calculations will be made using this value rather than the total number of pages in the script. For example:

The example uses two templates, one without a progress bar, which is used before we know how many questions the respondent is likely to answer, and the other with a progress bar, which is used for the rest of the script. The answer to Q1 determines which questions are asked, so it is at this point that we set the estimated number of pages that the progress calculations will use. The page that a respondent answering Q6 will see is as follows:

If it is not practical to specify the number of pages respondents will answer, you can specify the number of pages that have been answered after each question (you may have to estimate this if not everyone answers all questions). When you specify values for IOM.Info.EstimatedProgress, progress is calculated by comparing this value against the total number of pages in the script. It does not matter how many pages a respondent actually answers to reach a given question, progress at that point will be identical for all respondents because it is based on two fixed values. Here is a routing script that illustrates this:

There are five questions in the script, each displayed on a separate page, so when progress is reported at Q4 it will always be 3/5 or 60% even if some respondents have only answered Q1 so far.

In long scripts it will be tedious to set progress in this way, but you can cut down on the amount of work involved by using the OnAfterQuestionAsk event.

Events are named points in the timeline of an interview, which allow you to specify things that are to happen at those points (see Events for more details). The OnAfterQuestionAsk event defines what is to happen after a question has been asked. If you insert a generic statement in this event that increments the value of the EstimatedProgress property, you avoid having to write a separate statement after each page. The only time you will need to specify the value of this property manually is when a respondent is routed around a page that is not applicable. Here is a simple routing script that illustrates the general procedure:

If we follow two respondents through this script until Q4 is displayed we can see how progress is calculated for each one. There are five questions in the script. The first respondent chooses Response1 at Q1. When the respondent clicks Next, the OnAfterQuestionAsk event runs and increments EstimatedProgress by 1. The respondent chooses Response1 at Q2 and then again at Q3, and each time the OnAfterQuestionask event increments EstimatedProgress so that, when Q4 is displayed, progress is shown as 3/5 or 60%.

The second respondent chooses Response2 at Q1, and then something other than Response1 at Q2. When the respondent clicks Next on both these questions the OnAfterQuestionAsk event runs and increments EstimatedProgress by 1. This respondent is not eligible to answer Q3 but still needs to have EstimatedProgress set correctly by the time Q4 is reached. This is achieved by manually incrementing the property by 1 for each question that is skipped; this happens in the Else clause of the section that tests the answer to Q2. The property has been incremented automatically or manually for each question answered or skipped, so progress for respondent 2 is shown as 3/5 or 60% at Q4, the same as for respondent 1 who answered all questions.