Widget Development and Testing

Explore examples of widget development and testing for Modern Chat

Khoros provides two instances to each of its customers in order to give them the ability to execute a wide range of development and testing strategies. In this section, we'll look at a few common examples of how brands are developing, testing, and deploying Modern Chat.

Example 1: One Care Instance, One Widget

In this example, we are using one Khoros Care instance and one Modern Chat widget. Within that widget, we have created two rules. Each of these rules points to an instance of the website (dev and prod).

Each rule generates its own Source Tags. Source tags attach to a conversation and serve as a visible reference to why or how the conversation started. From a routing standpoint, source tags act as hooks that enable you to assign specific teams of agents to them.

This means that you could set it up so a group of agents receives messages from your production environment, and an entirely different group receives messages from your development environment to help with testing and other necessary tasks.

Then, when you want to apply the rule to production, all you need to do is rename it and change its conditions and the new rule can be routed to your production agents.

Example 2: One Care Instance, Two Widgets

In this example, we are still using just one Khoros Care instance, but we have created two widgets to serve our two environments (dev and prod). As before, we have two groups of agents assigned to Source Tags generated by rules that apply to their respective environments.

The advantage here is that you have an additional separation between the environments where you can define and test widget settings without affecting your production environment.

For example, you could test sets of rules with one widget without having them affect the widget assigned to your production site at all.

📘

While the widgets and rules are independent of one-another, they still share the same instance. As with the first example, the rules you create are also reflected in Source Tags and this will add clutter to the instance's Source Tag lists. It's important to maintain good digital hygiene and keep track of your testing resources so they don't create confusion when it comes to making changes that affect production.

Example 3: Two Care Instances

Finally, we have perhaps the most distinctly separate method for testing development and production environments. By utilizing your provided development Care instance, you can set the widgets, rules, and agent trees independent of the instance used for production.

This does create a bit more work when you want to bring those settings to production as you will need to recreate the widgets, rules, and agent assignments again on production.

Testing Method: IP Restrictions

Another option is to add an IP condition to your rules that only allows the widget to appear when the visitor's IP matches. This is a great choice for companies that route employee traffic through a VPN with a predictable IP address. Once you're ready for the rule to apply to a general audience, you just need to change or remove the condition.

Testing Method: Create a Reset Button

When you're developing and testing your widget, and you don't want to go through the hassle of clearing your application cache on your browser each time you want to reset your Modern Chat experience, you can use the solution below.

<script>
     function clearStorage() {
         Brandmessenger.reset();
     }         
</script>    

...

<button onclick="clearStorage()">Clear Storage</button>

This creates a button that effectively clears the widget and resets the conversation state for quicker and easier testing and development. This should not be used in any production environment.


Did this page help you?