singlepage

The singlepage tag is similar to the single-page application (SPA) concept. It allows the original page of a survey to persist while dynamically replacing some of the content. A page refresh actually never occurs, thus letting the respondent complete the survey on a single browser page. This creates a faster respondent experience and prevents respondents' survey browser back button from affecting survey navigation. 

Syntax

'app config' settings

The singlepage tag can include both 'y' (yes) and 'n' (no) inputs (defaulting to 'n'), or Survey Programmers (SPs) can instead specify to 'show', 'fade', or 'scroll'. Applying singlepage: y creates a 0 millisecond (msec) transition time between questions. Both 'fade' and 'scroll' can be used with or without a specified duration (in msec). 

# Using as part of 'app config' with default settings (defaults to "show" with 0 msec transition time)
app config
singlepage: y

# Using as part of 'app config' with no delay between questions
app config
singlepage: show

# Using as part of 'app config' with fading between questions lasting 200 msec (.2 sec)
app config
singlepage: fade 200  

# Using as part of 'app config' with scrolling between questions lasting 400 msec (.4 sec)
app config
singlepage: scroll 400

Defaults and behaviors

The inputs for singlepage exhibit the following behaviors and default settings. For fastest transitions, singlepage: y is recommended.

Amending survey links

The '_sp' parameter can be added to a survey URL during testing to experiment with how the various settings will affect the survey experience. Examples of this are listed below.

# Using _sp parameter with survey address, set to default (0 msec transition)
/dev/mysurvey?_sp=1

# Using _sp parameter with survey address, showing questions without delay (same as _sp=1)
/dev/mysurvey?_sp=show  

# Using _sp parameter with survey address, fading to next question in 500msec (.5 sec)
/dev/mysurvey?_sp=fade500

# Using _sp parameter with survey address, scrolling to next question in 1000msec (1 sec)
/dev/mysurvey?_sp=scroll1000

Using 'singlepage'

To force a survey to be displayed on a single page, SPs can apply the singlepage tag to the app config widget (shown below). SPs can also simulate the application of singlepage during testing by adding the '_sp' parameter to a survey URL.

As with any URL parameter, if '_sp=1' is the first parameter, it needs '?' before it (e.g., '?_sp=1'). If it is following any other parameters, they are delimited with '&' (e.g., '&_sp=1'). When you open a new browser tab, paste in any of the test links, and then add '?_sp=1' to the end.

Note, the back button will be visible because you are going from your browser's home page to the survey page. Normally this will not be the case for respondents, as they will likely access the survey by opening it from an email link or from within an app. The new tab generated will never have the back button in that survey instance because it will be the only page ever loaded there.

We can also replicate this behavior using the Run | Test button's User ID field. Put the '_sp' parameter desired in the field as shown below. Then, any tests we run will be in "singlepage" mode. These links open in new tabs. So, there should not be any active browser back buttons.

Advantages of using 'singlepage'

• It is perceptibly faster for respondents. The browser does not need to reload or re-render some content, which may save several tens of milliseconds per page. This may not seem like a large amount of time, but over the course of a longer survey, this does add up and factors into the respondent's survey-taking experience.
• The browser back button is truly disabled. We sometimes see orphan data (or other strange behavior) when respondents hit their browser back buttons and change responses. With singlepage, this is no longer possible; thus, data will be cleaner as a result.
• Custom transitions. SPs can choose between the default (near instant) transition, or fading and scrolling, where they can dictate how long the transition should last. 

What to be aware of

• Test JavaScript-heavy pages thoroughly. The way that it handles scripts is a little different. So, there could be corner cases where singlepage mode is not ideal.
• Note that adding a transition other than the default settings can counteract the efficiency that singlepage provides. If other transition settings are desired, SPs are encouraged to test out the responsiveness and avoid transitions greater than 500 msec. 

Examples

For the examples below, the same survey questions will be used, but with different transition settings applied to them. Please scroll through each example's source code to see the full content.

Default

When set to 'y', the singlepage tag will default to using a 0 msec transition time between questions. This is the equivalent of using singlepage: show.

See demo See code Restart demo

Fade to next question

To apply a fade interval besides the default of 100 msec, simply add the number of msec after 'fade'; e.g., singlepage: fade 200. 

See demo See code Restart demo

Scroll to next question

When singlepage: scroll is applied, the questions will swipe away to the left as each answer (or set of answers) is submitted, with the next question sliding onto the screen from the right. When no duration is specified, the default duration is 500 msec. Like 'fade', 'scroll' will also accept a specified number of msec for the transition duration.

See demo See code Restart demo