CDML Multiuser Editing

In a previous blog post we gave an overview of our universal conversation design markup language (CDML) and how we use it to simplify and make manageable several of the intrinsically complex problem spaces designers and developers find themselves in when trying to create and maintain engaging conversational experiences.

Stackchat Studio - our own chatbot authoring platform - is, at it's core, a graphical interface that consumes CDML and dynamically generates visual elements and components that users see and interact with on the screen. Each update and revision made to a bot results in some CDML being generated and saved. That new CDML in turn can be shared around to be edited directly or within the Stackchat Studio's bot-builder editing suite.

Making edits to your chatbot and saving them either locally to your computer or pushing them up to our cloud storage platform is a workflow that would meet the needs of most single user accounts. But, for collaborative teams where multiple users can be making edits simultaneously this pattern of save and walk away is going to get us into trouble.

Imagine a scenario where someone that has made several complex revisions to one of their chatbot's conversations has their changes replaced by a colleague that was working on their own changes to the same bot. The last person to make a change to the bot's underlying CDML would have the final say as to what the conversation looks like.

This doesn't cut it, all users capable of editing a chatbot should be working on the exact same version of the chatbot that everyone else is currently working on. We need a real-time solution!

Real-time Editing

Collaborative editing is not a new problem, you might already have come across some mature solutions to this problem in other products such as Google Sheets or if you're a developer, some of Atlassians software management tools like Jira support real-time events to keep users synced up. There are many solutions to this problem with varying degrees of 'smarts' and interfacing niceities baked-in to make the experience appear more seamless and we needed to find the right solution for Stackchat.

Screen Locking

When multiple users are present within the same editing ecosystem, the screen is locked for all new users to a page after the first user has joined. This is obviously an effective method of preventing all syncing issues between clients since only one editor can ever be present, 'late' users are forced to refresh their clients until the screen appears unlocked. There are some improvements that could be made to the basic implementation such as allowing more privleged users to take over the editing session from the original user, however the solution is somewhat of a dead end for collaboration as only one editor can be active at a time. More so it doesn't neccesarily by itself solve the syncing issue as there is no obligation to send through updates as they happen to 'late' users.

Screen Locking is somewhat antequated, generally it was reserved for systems that didn't support real-time connections but instead was just a way of indicating to anyone trying to make changes that other users were present and they too might be attempting to edit the same content. Given the wide availability of real-time standards today, implementing anyone one of them as a service is much more straight forward than it has been in the past and generally screen-locking is seen as being a poor user experience ultimately unneccesary.

Syncing up with sockets

As we mentioned before we need a solution for keeping users in sync with events as they happen. Luckily for us, there have been many real-time standards avaiable for the web for a few years now, and if we weren't already feeling lucky, one of our other software solutions (the Stackchat Web Messenger) make use of these real-time systems so we have been able to carry forward some of that work to Stackchat Studio in order to implement real-time events there as well.

The beauty of CDML, which we talk about here, is that it's a light-weight text file, which makes the work needed to keep clients in sync absolutely minimal. As you and your colleagues make edits to your chatbots in Stackchat Studio, or even if you have multiple tabs open in your browser and make edits in separate tabs, those changes will be sent to all other active instances of Stackchat Studio as they happen.

This feature isn't a cute after-thought - Stackchat Studio, enforces this connectivity at all times! Users can't make edits to a chatbot unless they are connected to our real-time servers. It's our way of guaranteeing that you and your colleagues are on the same page, collaborating and not worrying about stepping on each other's toes.

What's Next?

Adding a real-time service like this one opens the door to many exciting new features in Stackchat Studio. Remember what we mentioned before about screen locking? Well imagine instead of locking a screen we could lock individual elements to prevent users competing with each other. This is possible with sockets, as is many other useful little behaviours.

We aren't confined to how we use our real-time connections either, another example of this is our live chat management portal. The live-chat service relies on the real-time connection to supply it with events across all conversations related to the account as they happen.

Many hands make light work, and we know that collaborative environments foster innovation and growth. We're committed to making our Studio as easy to use for you and your team no matter how close or remote you might be from one another. Give it a try today for free!.