In this article, you’ll learn the following:
NOTE: The Code Block feature highlighted in this article is a new release and is in beta. We will be rolling this out in phases for all Data360 accounts early access.
Overview
While the Visual editor allows you to create variations by directly altering the visual design of the UI elements, the Code editor allows you to write the code changes for your variations and control the execution of the code.
This feature provides flexibility such as hiding webpage elements until variation changes load, setting triggers for changes, and reverting changes in single-page applications.
You can create multiple changes for a variation, bundle them up in individual code blocks within the code editor and configure when to display the changes as the variation is loaded for the visitors.
To directly access the code editor, go to Configuration > Variations, select Code editor from the Edit with dropdown and click on the Edit option corresponding to the variation.
If you’re already in the visual editor, click on the CODE option from the editor options panel at the bottom, and the code editor opens.
Structure of the Code Editor
The code editor features a panel on the left for variations and a panel on the top for basic options.
Variations Panel
The variations panel on the left features the sections to hold the codes for the following:
- Campaign Code - To insert the pre-JS and post-JS codes.
- Variation - To add the code for the variation.
Clicking on each of the sections, you can access the respective code blocks. You can add more variations using the Add Variation button. Based on your requirement, you can rename, clone, preview, or delete a variation.
Options Panel
The options panel on the top right of the code editor houses the generic options that can be applied across the code blocks for all variations, as follows:
| View the saved versions of your code changes | |
|---|---|
|
Features the following options:
|
Code Blocks
Code Blocks are discrete sections for organizing and placing your code changes. You can create multiple blocks, each with its triggers and configurations. Additionally, you can choose to hide elements until code execution is complete and, for single-page applications (SPAs), add code specifically to revert changes if needed.
Just like variations, you can rename, clone, and delete your code blocks.
Visual Editor Block
When you make changes using the visual editor, the corresponding code will be automatically displayed within the Visual editor block of the code editor. No matter if you start with the visual editor or the code block, you can freely switch between them to make changes to your experiment variations. You can make modifications to the code inside the visual editor block. However, the trigger is fixed to Campaign executes, which cannot be changed.
Note: The visual editor block is a default code block generated by Wingify based on the changes you have applied using the visual editor, and you cannot delete it.
Entities of a Code Block
Each code block inside the code editor features the following entities:
Language-specific Code Tab
Each of the code languages (JavaScript, CSS, and HTML) has an individual tab within which you enter your codes for changes. You can code your changes simultaneously for different languages. However, the sequence of execution of the changes will be in this order: HTML, CSS, and then JS. You can simply place the code changes in the respective tab and save them.
Triggers
Each code block has a Trigger dropdown, which lets you select an appropriate trigger option to configure when to execute the code changes when the variation is loaded for the visitors.
Click on the dropdown and select the appropriate trigger option from the following:
| Campaign executes |
This is the default option. It triggers the code when the campaign is executed on the visitors’ browsers. For example, you're trying different promotional offers (via a popup) on the homepage of your e-commerce site. When this trigger is applied, the promotion for the respective variation is displayed to the visitor who lands on your homepage. NOTE: This requires the targeted elements for these changes to be present during the execution of the campaign |
| Element loaded | Triggers the change when a specific element is loaded. When certain elements on your page appear after some time or after a specific action, such as hovering over a menu, then you can use this option to trigger the changes after the specific element is loaded. For example, if your variation is set to display a unique price in a discount modal that appears when a visitor clicks on a specific CTA, then you can use this option to configure the code to be executed after the modal appears. By default, Wingify applies changes on the element only once when this option is selected, i.e., if the “Buy now” CTA is modified to show a different text, “Place order”, the change gets applied only once when the element is loaded during the first purchase. If the same element is loaded during the second purchase, it will retract to “Buy now”. If you need the changes to be reapplied every single time the element is loaded, enable Keep applying changes from Options. |
| DOM ready | Triggers the change when the DOM (all the elements on your website) is loaded in the visitors' browser. For example, if your website has heavy content that consumes more time to load, then you can use this option to trigger the changes after the entire content (DOM) is loaded |
| Run after another code block | Triggers the change when a specific code block has completed executing its change. When you have multiple code blocks, you can use this option to sequence the triggering of the changes |
| Campaign exit | Triggers the change when the visitor navigates to a non-campaign page. For example, imagine you're conducting an A/B test on a travel booking website's search results page. Your variation includes a new filter option that allows visitors to sort results based on price ranges. However, you want to ensure that this filter resets whenever the visitor navigates away from the search results page. You can do this by adding a code to revert these changes with this trigger option |
Option to Hide/Unhide Elements
If you notice a momentary flash of the original content being displayed when the changes get executed, this option comes in handy.
For example, picture yourself as an e-commerce site testing a fresh product page look. Your new design boasts a striking product image and a bold "Add to Cart" button. Yet, as the page loads, users briefly glimpse the old design, complete with a smaller image and less visible button. This flash of outdated content can distract visitors and hinder their checkout process.
You can prevent this by hiding such elements until the code change is executed. Click on the Hide element(s) until code runs option and specify the selector path of the elements. To specify multiple selector paths, use a comma to separate them. Click Done to apply the setting. To make any changes to this setting, click on the Edit option and perform the necessary changes.
Wingify will now analyze the code inside the code block and suggest selectors that may be visually impacted when the code runs in Live or Preview mode. You can review these suggestions and directly add the relevant selectors to the Hide element(s) until code runs block.
Attention: If you've set the Make modified elements visible when option (accessed from Configuration > Audience and Traffic > Target Audience > Settings) to Always (elements are not hidden), the Hide element(s) until code runs option will have no effect.
Option to Revert Changes
For single-page applications (SPA), chances are there that the changes will remain even when the visitor navigates away from the campaign page.
For example, assume you're running an A/B test on your e-commerce website's checkout page. In the test variation, you've added a new feature that displays a progress bar during the checkout process. However, since this is a single-page application (SPA), there's a concern that once the visitor completes the checkout and navigates away, the progress bar might remain visible on subsequent pages, causing confusion.
You can avoid this by configuring the changes to be reverted when the visitor navigates away from the campaign page. To do that, click on the Add code to revert changes link. This creates a code block beneath the current code block, where you can insert the code to revert the changes.
Tip: Alternatively, you can do the revert operation by creating a separate code block and applying the Campaign exit trigger.
Option to Import External JS/CSS Library
If you are trying to load external libraries for JavaScript or CSS, you can click on Options and select Include External JavaScript or Include External Stylesheet. In the popup that appears, you can enter the file path for the library or select one from the QUICK ADD dropdown and click Done.