AB Tasty web page editor, the difficulty of creating a simple tool

Kévin José
Oct 22 · 5 min read

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

ABTasty Editor V1
ABTasty Editor V1
ABTasty Visual Editor V1

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

ABTasty Visual Editor V2
ABTasty Visual Editor V2
ABTasty Visual Editor V2

In 2015, we launched a new editor directly embedded on our clients’ website. In this new version, the entire content of the editor (HTML, CSS and Javascript functions) was injected through a JS script, loaded and executed on the client website.

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”.

However, new technical issues arose. First, the editor was experiencing display conflicts between the original CSS and javascript of the website, and the items of the editor. Jquery libraries and javascript variables between the editor and the clients’ websites were also experiencing conflicts. Last but not least, with this new approach, our editor lost its responsiveness, preventing our clients from redimensioning their website.

We had to find a solution…

2018: V3 — A responsive tool on our clients’ website

ABTasty Visual Editor V3
ABTasty Visual Editor V3
ABTasty Visual Editor V3

Both V1 and V2 had pros and cons, so we decided to create a third version mixing the best of its predecessors. We went back to an iframe tag to embed the client’s website, in order to solve conflicts and restore the editor’s responsiveness. But this time, the iframe stayed on the client’s website to prevent cross-domain conflicts. This new solution resolved all CSS and most javascript conflicts.

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.

Thirdly, we added a javascript anti-conflict system function. Some scripts or libraries used to overwrite native javascript functions and crash the editor. With this anti-conflict system, we can now use native javascript functions with our editor instead of the functions of the client website.


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.

To adapt to evolutions of the web and the millions of cases and websites encountered, our web page editor is constantly evolving on a technical level. However, expectations sometimes exceed the technical limitations of the tool and of web javascript.

The AB Tasty Tech & Product Blog

Learn about AB Tasty’s world class engineering efforts, company culture, product developments and more. We are facing specific challenges and we share it with you. GCP (Google Cloud Platform), AWS (Amazon Web Services), Dedicated Servers, CDN

Kévin José

Written by

Team Leader chez AB Tasty. @abtasty

The AB Tasty Tech & Product Blog

Learn about AB Tasty’s world class engineering efforts, company culture, product developments and more. We are facing specific challenges and we share it with you. GCP (Google Cloud Platform), AWS (Amazon Web Services), Dedicated Servers, CDN

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade