While it’s very important to look at the content of your digital assistant to make sure it mirrors your brand, contains the correct information and is relevant, it is as important to look at the user interface to that content. This post explores all the options available to you so that you can improve the experience for the user and potentially tailor it to suit their individual needs.
Its not all about the looks
I’m sure when you originally created your assistant your looked at the branding, the layout, the sizes and most of the other things to do with the look and feel of the chat widget you have on the page. This is the first thing the user will see as they interact with your brand and so it’s important this looks right. If you are familiar with the EBM Chat Widget Builder hopefully you will have seen how easy it can be to ensure the widget is replicating the look and feel of your site in terms of icons, colours and fonts. However, what can often be overlooked is the information that can be sent from the widget back to your assistant.
The EBM Chat widget is designed to be as flexible as possible and along with the many widget and theme parameters you can use to affect the appearance, we also have the option of using custom parameters. Due to the wide range of applications for digital assistants these parameters are not specific to any one use case and as such can be configured to provide a richer set of information to the bot. For example, you could use parameters to:
- understand the page the user is currently on, so that you can adjust the content accordingly.
- pass information about the user, so that you can greet them properly
- indicate their authentication status, so that you can have some content for logged in users, and different content for when they are not.
- or to pass information that you might want to collect additional metrics for.
Sending browser information as a parameter
In order to demonstrate this flexibility let’s walk through a simple example. In this situation we want to capture some information about the browser that the user is using to have the conversation. We’ll use the parameters function of the chat widget to set the relevant properties for each chat session, and then demonstrate how through the use of a proxy function this information could be stored in a database.
The first thing we need to do is set the relevant parameters. For our example we are going to make use of the “userAgent” string that is set of each browser. The value for the browser i’m using at the moment looks like this :
Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Mobile Safari/537.36
For simplicity i’m only going to use the first part of that string, and i’m going to set it against the property called “browser”. To do this i would run the following code :
This is a piece of JavaScript that makes use of the Chat Widget Helper Functions. In particular the first line registers a function that will be called when the “filament-chat-widget” event is fired. This is a specific event that is created to determine when the widget has been loaded successfully. By waiting for this event you can ensure that your code isn’t going to run on a page that your chat widget isn’t on. The second line of code then sets the property “parameter-browser” to the first part of the userAgent string. In the example above this would be the value Mozilla/5.0. Now each time a user types a message, or clicks on a button this parameter “browser” will be available.
The image above is then showing how that parameter then translates into the requests that are made to the bot. You can see here the “properties” object has now been populated with the additional "browser" variable that we wanted.
Processing the values that are sent
Now that you have the values being sent from the users browser, the next step is to do something with those variables. What you do with the value will depend a lot on the use case you are developing but here are a couple of options.
The first option is that you want to affect the content that the user sees based on that variable. This is done inside EBM through the use of conditions. Because you could potentially pass any number of different variables, the first job we need to do is tell EBM about the new parameter. This is done via the “Configuration” tab on a domain.
The image above shows that i’ve now told EBM that a “browser” parameter might be sent via the APIs. Please note that this view is only shown if you have the Advanced toggle checked. Now that we’ve added that parameter we can then use it in a condition on a response block, as shown in the image below.
The second option is to store the value in a database or log it somewhere. To do this we’ll need a “proxy” which can act as a middleman between the chat widget, and our bot. The following example shows the creation of a simple cloud function that could perform this proxy function for us. The chat widget will be configured to call this function instead of the bot by altering the bot-api-url parameter. Line 10 of the code then sets the URL that any requests should be forwarded on to. In this example we are using EBM as the target for this fulfilment, but lines 10 to 17 could easily be replaced with any other fulfilment logic if you needed to.
The important lines for our use case are lines 22 and 23. Here you can see we are collecting the browser parameter that the widget has passed in, along with the session ID for the current conversation. The example continues to go on and insert those values into a fictitious database however you could just as easily use those parameters in additional API calls, or in calculations.
Summary
As you can see with a few small changes we are very quickly able to enhance the information that the chat widget is collecting, and passing to any fulfilment – be that EBM, DialogFlow or custom API. By using this approach you can open up a much wider range of use cases and also satisfy a large number of internal KPI requirements.
