Since the very beginning, AB Tasty’s main value proposition has been to empower marketers to easily run A/B tests on their own, without coding. That’s what our web page editor is all about. But creating an easy-to-use web page editor is trickier than it looks. Our editor went through three main evolutions and is still evolving to be more accessible, stable, and intuitive every time.
What is the web page editor ?
Our web page editor is a tool that lets anyone make modifications on his/her website without having to modify the code. Marketers usually use it to create an A/B test or personalize a web page without calling upon their developers. Our editor allows them to change the color of the buttons, alter text, modify the order of items, add or hide parts of the page, etc. It also lets them add widgets or components, such as an ad pop in, a retention pop in, a countdown, … In some specific cases, our team of technical experts can also develop custom pieces of code at the client’s request.
In order for it to be easy to use and intuitive, we opted for “WYSIWYG” features (What You See Is What You Get) so that the user can edit the elements on the page of the web site, and directly see the result displayed on his/her screen.
2012: V1 — An editor integrated to our AB Tasty platform
In our first version, the web page editor was located on our platform. The website of our clients was loaded into our platform thanks to an iframe tag. Their entire code was then uploaded to our servers through a proxy.
This first version was responsive and allowed our clients to resize their website. However, it suffered from cross-domain problems. Scripts and images didn’t load properly as the source of the iframe was located on a different website to the domain that contained it. In addition, the editor was encountering issues to access our clients server. As a result, the website display was not quite accurate compared to the original.
2015: V2 — Our editor on the website of our clients
The main benefits of this solution were that the display was more true to the original, and the resources were loading more easily as they stayed “at their source”.
We had to find a solution…
2018: V3 — A responsive tool on our clients’ website
Nevertheless, no solution is perfect. Despite numerous tests, we discovered after launching V3 that some websites contain scripts or libraries that don’t load when embedded in an iframe. Even worse, the editor doesn’t open at all sometimes because of that. Luckily, our editor also includes an option configurator that can clear up these issues.
The work must go on
We continued working on improving for this third version. First, as I said two lines above, we added an option configurator to our editor, in order to mitigate specific cases that might occur. This configurator enables the user to:
- Choose between iframe and “iframeless” modes, in order to solve possible loading conflicts inside the iframe
- Choose how the website code is embedded in our editor: by its URL or by proxy
- Deactivate the analytics in our platform
- Use the HTML node or the body node instead of the code itself
Secondly, we revamped our Edition/navigation mode switching functionality inside our editor. This functionality has existed since the very first version, enabling the client to switch between both modes. In edition mode, all the elements of the page are fixed, and the edition menu appears when clicking on an item. In the navigation mode, the website is “moving”: slideshows, image carousels, and other dynamic elements can be activated. It allows the user to access items or pages that are hidden in edition mode (for instance, a pop in that appears when clicking on a button). This actually gave us a hard time in terms of refactoring: we had to entirely revamp the functionality without breaking anything or changing its visual aspect for the users.
In our current version, the problems that the editor is facing are more and more delicate and specific, due to the variety of websites. Emerging libraries are not always compatible with our editor. Page behavior on some client websites can show surprises. For instance, Polymer.js displays the shadow DOM on Chrome and the classical DOM on Firefox, creating a different HTML code generated on both browsers — needless to say, AB Tasty doesn’t work well with Polymer.js. Likewise, more and more websites use the SPA (single page application) technology for their purchase funnel. In that case, the navigation mode is necessary to be able to directly access a specific page.
As you can see, if the editor is now stable and most bugs fixed, spending time to understand the specificities of websites will always be necessary when a conflict arises with the editor.