CDML Multiuser Editing

In one of our previous blog posts we gave an overview of our universal conversation design 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.

The Stackchat Web-Studio which is 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 CDML and saving them either locally to your computer or pushing them up to our cloud storage platform is a work-flow 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 bot'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 cdml should be working the exact copy of the bot that everyone else is currently working on, or at least a version that can work on independently withouth compromising the work-flow or edits that their peers/colleagues have been working on.

We need a realtime solution!

Realtime 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 are work within the software delivery industry some of Atlassians software management tools support realtime events to keep users workflows 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.

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 realtime 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 realtime 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 realtime standards avaiable for the web for a few years now, and if we weren't already feeling lucky, one of our other software solutions (stackchat-messenger clients) make use of these realtime systems so we have been able to carry forward some of that work to the Studio to implement realtime events there as well.

The beauty of CDML which we talk about here, makes the work needed to keep clients in sync absolutely minimal on our behalf. As you and your colleagues make edits to your bots in the 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 the Stackchat Studio as they happen.

This isn't a cute little after-thought either! The Stackchat Studio, enforces this always! Users can't make edits to a bot unless they are connected to our realtime servers. It's our way of garunteeing that you and your colleagues are on the same page, collaborating and not worrying about loosing work due to random chance.

What's Next?

Adding a realtime service like this one opens the door to many exciting new features on the stackchat platform. 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 are committed to providing users with world-class tooling for maintaing their bots and you can expect to see many more improvements to our collaborative editing experience as the platform evolves and matures.

We aren't confined to how we use our realtime connections either, another example of this is our live chat management portal. The live-chat service relies on the realtime 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!