Submitting and publishing survey content with the Edit applet

Creating new survey content and editing content comes in waves, and without a doubt, multiple revisions. Before reading this article, we highly recommend new Survey Programmers (SPs) review the full capabilities of the Edit applet by reading Getting started with the Edit applet (Survey Editor) as well as learn the basics of editing with the article Creating and editing survey content with the Edit applet. Next, you are ready to submit and publish the code.

Submitting survey code

When you are ready to submit source code and merge it to the Dev (Development) version of the survey, click the Next: Review Changes button found at the bottom-left of your Survey Editor pane.

This presents a version comparison between the last compiled (built) version and the proposed edits. Changes that removed content will be in red, and changes that added content will be in green. It is best practice to review your changes and scroll from top to bottom. If the changes are correct, you are ready to parse (process) and update the survey. Click Commit Changes, or press Alt+S (PC) or option+S (Mac).

Cancelling the build

There is a brief opportunity to cancel this process should you need to. To stop it, click the Cancel Build button in the menu bar. If the Cancel Build button is clicked before the survey finishes parsing, users will see a notification message that the build was cancelled. If no message appears, this indicates that the SP did not press the Cancel Build button quickly enough and the build was completed. The Details section will then contain a note that "The process was not canceled because it was too late."

Successful survey compilation

If the new code compiles without any errors, users will be taken to the next screen and see "Survey updated" next to a green checkmark on the bottom-left of the screen. This is the point when a "Dev" (Development) version is created. If the previous version of the survey has been published at least once, you will see the yellow construction worker icon. If the survey has never been published, the icon will be a gray circle with a line through the center. The survey will increment to the next version number and will clearly note how many versions have been compiled since the survey was last published.

From here, there are a few options on screen. You can check compiling notes in the Details section by clicking on the expand arrow. You can test the survey with various links, such as test levels 1, 1.1, and 2, or with a "live" link which simulates what the changes would look like to a live respondent. You can also add comments about the round of changes you submitted in the Update Comment section which can be referenced later in the Versions Management applet.

If you wish to continue editing, simply click on the Restart button or click on the Editor Mode button and select Survey Source. Publishing the survey is discussed further below.

Survey Mechanics

The Survey Mechanics table provides a comparison of the previous version of the survey with the most recently compiled/current version of the survey.

The following columns are included in the table:

• Version - This column will always list the Previous and Current versions of the survey, with the version number shown in parentheses to the right. 
• Data Columns - The total number of fields in a survey (or the number of columns that would appear if all fields were exported in an Excel file). If the number of fields exceeds 15,000, the column header will turn red and an info icon will appear. Hovering over the icon will show a message, letting the SP know that "The maximum number of columns in Excel is 16,384." 
• Time to Parse - The time in minutes and seconds it took the platform to parse the survey. 
• Survey Forms - The total number of pages in a survey. This includes both pages that are visible to the respondent and hidden.
• Visible Questions - The number of questions that are respondent facing.
• Quota Questions - The number of quota variables included in the survey.

Development links

The Development Links section provides users with various Testmode links in order to test the newly parsed code. Remember that each time a survey is compiled, that version automatically becomes the latest Dev version of the survey. If the survey is not published after compiling the code, a message will be listed at the bottom of this section letting the user know how many versions back the last Pub version of the survey is from the current/most recent Dev version.

Comments

When the survey is done building, a box appears under the progress bars, noting what changes were made to the source. There are three types of automatically generated comments: Added, Removed, and Changed. The widgets that fall under each category are listed by their ID. Up to five widgets are listed for each category. If more than five exist, a count of additional widgets in that category is included, e.g., "Added Q54. Removed T5A, T5B, T5BR1, T5BR2., T5BR3, and 6 more."

To add greater detail, the text in the box can be edited. After making any changes to the text, click Update Comment. These comments appear in the Version Management applet in the Comments column adjacent to their respective versions to provide details on the changes that were made.

Unsuccessful survey compilation - Resolving parse errors

In contrast to the section above, if any issues are found while attempting to compile the source code, the parser displays them in a list on the next screen. With a few exceptions, most issues discovered do not stop the parser from building the survey, and the survey version will still be saved. 

Parse issues can be divided into four categories, from least serious to most: CAUTION, WARN, ERROR, or a ("STOP") ERROR.

• CAUTION - Indicated by a yellow rectangle, these are the least serious of parse issues, and can be more of an informational note. A new survey version is saved, and the survey can be published. Examples of "cautions" include possible Perl code errors and "valid triggers" not found in conditional statements.
• WARN - Indicated by the orange rectangle, these are moderately serious parse issues. The survey will compile/build with warnings, and a new survey version is saved, but the survey may not render correctly. The survey cannot be published until all warnings are corrected. Examples of warnings include unrecognized lines of code and empty type tags.
• ERROR - Indicated by the red rectangle, these are more serious parse issues. The survey will compile/build with errors, and a new survey version is saved. The survey can be partially rendered, but it will eventually stop. The survey cannot be published until all errors are corrected. Examples of errors include missing a mandatory tag for a widget or having an invalid question type. 
• ("STOP") ERROR - These errors were called "FATAL" in earlier versions of the software. "Stop-errors" are indicated by a red circle with an exclamation point icon and are caused by server issues or critical errors in the code that stop the parser instantly. In comparison to a general ERROR, here the survey version cannot be saved, and the errors must be addressed immediately to parse the survey. Stop-errors fall into two groups:
  
  • • Expected/Known - The specific error is known and listed next to the red circle icon. An example of a known error is duplicate question or option IDs.
    • Unexpected/Unknown - These errors are unknown and, therefore, have little information provided. The error message usually says "Unexpected error during build." An example of an unexpected error includes when there are an excessive number of survey errors. 

CAUTION, WARN, and ERROR examples:

Known STOP-ERROR example:

Unknown STOP-ERROR example:

If a survey contains parse issues that are categorized as WARN or ERROR and an SP tries to publish the survey, a modal will appear with the following message.

To fix errors, click Back or press Alt+A to return to the Survey Editor. Lines containing known issues will be highlighted in red. Continue editing as needed to resolve the parse issues.

Publishing a survey

SPs may commit source code changes as many times as needed without publishing the survey. Remember, however, external users testing with the "live" link will not see any changes until the latest survey version has been published. When the survey is approved and ready to "go live," the survey must be published.

When a survey is ready to be published, it can be done from the following locations:

• From the Publish button in the Development Links section after successfully compiling the source code.

• From the Publish button in the menu bar of the Survey Dashboard.

• From the construction worker icon found in the menu bar of any applet (see image above).

After any of the publishing options are pressed, a confirmation modal will appear. Click Yes to continue with the publishing process. Click No to cancel.

Once the survey is published, the yellow construction worker icon will change to the green circle with checkmark icon, and other publishing options will be removed or deactivated.

Next steps

At this point, we recommend you test your survey changes thoroughly. If this is your first draft of the survey, it is highly likely you will need to make revisions and repeat the editing process. Here are a few other articles that you might find helpful for common next steps:

• Run your surveys in Testmode.
• Add panels to your survey.
• Create quotas and set quotas in the Quota Manager applet.
• Add your colleagues and team as users to the survey.
• Begin and manage translations for your survey.