Not long ago, I wrote an article about using data and the Bot Framework to manage a conversation.  The driving idea behind that article was about using a graphical editor to make changes to a conversation without requiring any additional coding.  The more I thought about that idea, I wondered if it could be extended to start down the path of conversations as a service.  Could we build a platform that a user could create an account, build a bot completely via an editor, and then embed that conversation in a website (or possibly some other medium)?

If something like that could be done, I think it’s unlikely that it would ever become sophisticated enough to meet some of the bot and conversation goals.  However, to bring conversations to the masses it might be a great starting point.  Consider an example such as a local sandwich shop, which is one of the classic Bot Framework examples.  Joe the sandwich maker likely isn’t also a programmer.  He probably doesn’t have the skills or the desire to learn how to code a bot.  He wants to make sandwiches, and ultimately, make money.  However, if Joe could add some kind of conversation to his website, perhaps something that takes an order from a user and then e-mails that order to the sandwich maker, would that give him an edge over other sandwich shops?  Maybe so.  Personally, I will always choose the online option before I call to order, if for no other reason than there’s a higher probability that my order will be accurate.  This article covers my proof of concept for the idea.

Admin Portal

The first important component of this idea is the administrative portal.  From here, the user could login, create new conversations, edit old conversations, and gather the necessary information to embed those conversations into his or her own solution.  My rendition of the landing page of the portal (after login) looks like this:

Once the user creates an account and/or logs in, they can either create a new template or manage an existing template.  If they click the Edit button, the screen from my previous DataDrivenBot concept is displayed:

Once the user makes any necessary changes, they can click the Save button and return the main screen.  Now that the template has been updated, the user can click the Embed button from the home screen.  This will popup a window that gives the user some HTML that they can copy and paste into their existing website.

User’s Website

Now that the bot itself has been built out and the user has the HTML to embed an iframe into their website, it’s as simple as them copying and pasting that HTML into their website.  I built a little demo site to show the resulting bot.  The site looks like this without the bot addition (by the way, if you need a web designer, feel free to give me a call #NotADesigner):

Adding the HTML is simple, just copy and paste:

Reloading the page and interacting with the bot a bit looks like this:

Bot

The actual Bot is built based on the Bot Framework DirectLine connector and the user interaction is created with HTML and JavaScript/AJAX.  When the embedded app loads in the frame, it first makes a call out to the DirectLine connector to initiate a conversation.  Next, it makes an initial message call into DirectLine passing in a userId and conversationTemplateId.  This call is invisible to the user, but when interacting with the bot via the web chat control, looks like this:

By using a unique identifier (a pair of unique identifiers, in fact), the bot can look up any conversation template from the database and follow that flow.  From there, the bot utilizes exactly the same process that was described in the data driven bot article to push and receive messages.

Additionally, the embedded view can support multiple layouts.  For example, by choosing to display a Web Chat instead of the chat window overlay, the Embed window updates the HTML like so:

Pasting that HTML into a page within the site looks something like this:

The different styling is achieved just by overriding the CSS when the bot UI is delivered.  Certainly the Admin Portal could be extended to allow the user to make their own CSS/styling changes to fit the color scheme of their site or adjust the sizing of the bot.

Source Code

The source code is available on GitHub, here:  https://github.com/JonathanHuss/JonHuss-CaaS.  Feel free to use it however you like, but please note that it’s not production ready code.  Not even close.  It’s a proof of concept, which means that there are lots of places that would need a fair bit of updating before it would be ready for prime time.  However, if you turn your head just right and stick out your tongue, it will probably run for you.

Thoughts

Is this approach likely to solve all of the world’s bot/AI challenges?  Absolutely not.  But that’s not really the point here, at least for me.  As someone who works in the field with enterprise customers every day, I’m painfully familiar with the obstacles that these customers face.  One of the major initial obstacles is simply barrier to entry.  How do they get started?  How much time is going to take to learn the platform?  The next is almost always how much time can they devote to the development effort itself versus whatever else is in the pipeline.  After all, time is money and in the competitive marketplace, that matters a lot.

By making a service type approach available to those customers, the cost bar is lowered significantly.  Lowered so far, in fact, that almost anyone, technical or not, could add this type of feature/functionality to their own platforms.  For the larger customers, it provides an opportunity for them to test drive the concept without tremendous investment in learning to write the code directly.  If they find at some point that it’s something their customers like but more flexibility is needed, they might then have some ammunition to justify the time to learn and build a custom bot that might be much more in depth.  For the smaller, less technical customers, it’s an easy way to add new functionality to their websites (or potentially other platforms) to better reach their own customers.

What else?  How could this idea be better or more useful to our customers?  Or, is the idea completely off the mark?  Maybe customer’s aren’t really interested in this approach and would rather just build their bots entirely from scratch?  I’d love to hear your thoughts and feedback around the concept.