Testing tools are not all created equal. Here, we break down the WYSIWYG and share a guide to the pros, cons and perfect time to implement them.
Love acronyms? This one is particularly long, but you’ve probably heard it before. WYSIWYG. Pronounced ‘wizzy wig,’ this acronym stands for ‘What You See Is What You Get.’ In the world of testing, WYSIWYGs are often included in testing tools as an option for editing website content and creating tests.
Sound great? They are! And they feature two main benefits.
The Pros of WYSIWYGs
- They provide the ability for you to create a test – even if you have little to no coding experience.
The biggest benefit of a WYSIWYG – and the main reason they exist – is that they are easy to use. They don’t require coding experience, and they’re generally quite intuitive, with options like “edit text,” “resize,” and “hide.” These features make it easy to tweak the look of the page and achieve the visual experience you want without writing code.
- You can immediately see how a change will look on a web page.
When editing within a WYSIWYG, the web page you’re testing on will automatically run, and you can click to make changes right on top of that page. You can drag a button to a different place on the page and immediately see how that placement will look. You can choose a color from a color palette to see how headers look with that new hue. If you decide you don’t like the look of any of your changes, you can easily click an undo button and try again.
The Cons of WYSIWYGs
Unfortunately, WYSIWYGs aren’t perfect. There are two big downsides.
WYSIWYGs ultimately need to translate all the changes you make into code the browser can read. They do this using an algorithm, often creating code that would be much less complicated than if it had been written from scratch by a developer.
The more complex the code is that the WYSWYG generates, the longer it takes to compile. That leads to more flicker for the end user as the code loads up. This might not be an issue if you’re only making a few, small changes with a WYSIWYG for your test. But the more changes you make, the more complex the code will get, and more changes means the load time will grow.
Web technologies are always changing, and it’s important to consider which technologies your website is using. Is it a Single Page Application (SPA) built within a framework like React? If so, SPAs only load once, unlike more traditional sites that reload each time a user visits a new page. This can cause additional complications with getting A/B tests to work well even with custom written code. If your site is a SPA, you’ll definitely want to consult with a developer about the feasibility before attempting to use WYSIWYGs.
When Should You Use A WYSIWYG?
If you’re building a very simple test – such as comparing two different headlines on a web page – and you don’t have access to a developer, using a WYSIWYG is a good option. It will provide you with the functionality you need to create that test in an easy-to-use environment.
If you are looking to run more complicated testing experiences however, we recommend relying on a developer who can write custom code whenever possible. This will guarantee that you’re creating the best possible experiences for your users.
Aly Pilkons, Optimization Engineer