If you live in an area with a lot of freight or commuter trains, you may have noticed that trains often have more than one engine powering the cars. Sometimes it is an engine in front and one in back, or in the case of long freight lines, there could be an engine in the middle. This is known as “Distributed power” and is actually a recent engineering strategy. Evenly distributed power allows them to carry more, and carry it more efficiently.1

When it comes to your website, the same engineering can apply. If the Content Management System (CMS) is the only source of power, it may not have enough oomph to load pages quickly and concurrently for many users. Not only that, but a single source of power may slow down innovation and delivery to multiple sources in today’s multi-channel digital ecosystems.

One of the benefits of decoupled platform architecture is that power is distributed more evenly across the endpoints. Decoupled means that the authoring system and the rendering system for site visitors are not the same. Instead of one CMS powering content authoring and page rendering, two systems handle each task discreetly.

Digital properties are ever growing and evolving. While evaluating how to grow your own system, it’s important to know the difference between coupled and decoupled CMS architectures. Selecting the best structure for your organization will ensure you not only get what you want, but what is best for your entire team — editors, developers, designers, and marketers alike.

Bombardier Zefiro vector graphic designed for Vexels

What is a traditional CMS architecture?

In a traditional, or coupled, CMS, the architecture tightly links the back-end content administration experience to the front-end user experience.

Content creation such as basic pages, news, or blog articles are created, managed, and stored along with all media assets through the CMS’s back end administration screens. The back end is also where site developers create and store customized applications and design templates for use by the front-end of the site.

Essentially, the two sides of the CMS are bound within the same system, storing content created by authenticated users and then also being directly responsible for delivering content to the browser and end users (front end).

From a technical standpoint, a traditional CMS platform is comprised of:

  1. A private database-driven CMS in which content editors create and maintain content for the site, generally through some CMS administration interfaces we’re used to (think WordPress or Drupal authoring interfaces)
  2. An application where engineers create and apply design schemas. Extra permissions and features within the CMS give developers more options to extend the application and control the front end output
  3. A public front end that displays published content on HTML pages

What is a decoupled CMS architecture?

Decoupled CMS architecture separates, or decouples, the back-end and front-end management of a website into two different systems — one for content creation and storage, and another for consuming content and presenting it to the user.

In a decoupled CMS, these two systems are housed separately and work independently of the other. Once content is created and edited in the back end, this front-end agnostic approach takes advantage of flexible and fast web services and APIs to deliver the raw content to any front-end system on any device or channel. It is even possible that an authoring system delivers content to more than front-end (i.e. an article is published in the back-end and pushed out to a website as well as a mobile App).

From a technical standpoint, a decoupled CMS platform is comprised of:

  1. A private database-driven CMS in which content editors create and maintain content for the site, generally through the same CMS administration interfaces we’re used to — though it doesn’t have to be2
  2. The CMS provides a way for the front-end application to consume the data. A web-service API — usually in a RESTful manner and in a mashup-friendly format such as JSON — is the most common way
  3. Popular front-end frameworks such as React, VueJS, or GatsbyJS deliver the public visitor experience via a Javascript application rendering the output of the API into HTML

Benefits of decoupled

By moving the responsibility for the user experience completely into the browser, the decoupled model provides a number of benefits:

Push the envelope

Shifting the end-user experience out of the conventions and structures of the back-end allows UX Engineers and front-end masterminds to push the boundaries of the experience. Decoupled development gives front-end specialists full control using their native tools.

This is largely because traditional back-end platforms have been focused on the flexibility of authoring content and less so on the experience of public visitors. Too often the programming experience slows engineers down and makes it more difficult to deliver an experience that “wows” your users.

Need for speed

Traditional CMS structures are bogged down by “out-of-the-box” features that many sites don’t use, causing unnecessary bloat. Decoupled CMS structures allow your web development team to choose only what code they need and remove what they don’t. This leaner codebase can result in faster content delivery times and can allow the authoring site to load more quickly for your editors.

Made to order

Not only can decoupled architecture be faster, but it can allow for richer interactions. The front-end system can be focused on delivering a truly interactive experience in the form of in-browser applications, potentially delivering content without a visitor reloading the page.

The back-end becomes the system of record and “state machine”, but back-and-forth interaction will happen in the browser and in real-time.

Security Guard

Decoupling the back-end from the front-end is more secure. Since the front-end does not expose its connection to the authoring system, it makes the ecosystem less vulnerable to hackers. Further, depending on how the front-end communication is set up, if the back-end goes offline, it may not interrupt the front-end experience.

In it for the long haul

Decoupled architectures integrate easily with new technology and innovations and allow for flexibility with future technologies. More and more, this is the way that digital platform development is moving. Lean back-end only or “flat file” content management systems have entered the market — like Contentful and Cosmic — while server hosting companies are dealing with the needs of decoupled architecture as well.

The best of both worlds

Decoupled architecture allows the best decisions for two very different sets of users. Content editors and authors can continue to use some of the same CMSs they have been familiar with. These CMSs have great power and flexibility for content modelling and authoring workflows, and will continue to be useful and powerful tools. At the same time, front-end developers can get the power and flexibility they need from a completely different system. And your customers can get the amazing user experiences they have come to expect.

The New Age of Content Management Systems

Today’s modern CMS revolution is driving up demand for more flexible, scalable, customizable content management systems that deliver the experience businesses want and customers expect. Separating the front- and back-ends can enable organizations to quicken page load times, iterate new ideas and features faster, and deliver experiences that “wow” your audience.

  1. Great article on the distributed power of trains: Why is there an engine in the middle of that train?
  2. Non-monolithic CMSs have been hitting the market lately, and include products like Contentful, CosmicJS, and Prismic, among others.

We’ve dreamed about having conversations with our computers for a long time. Stanley Kubrick’s 1968 film 2001: A Space Odyssey imagined a sentient computer named Hal. In the past few years, with the rise of Siri, Alexa and more, we live in that reality.

A simpler version of the natural language processing apps like Siri are chatbots. 2016 was the rise of the chatbot, and 2017 will continue that trend, with more and more users having “conversations” via the keyboard to find information and complete tasks instead of clicking around in search engines and on websites. Some of us have not yet interacted with a chatbot before, so, what is it like? And what is it like to design one?

The experience of interacting with a chatbot is very similar to interacting with a smart and eager-to-please dog — the bot understands a lot, but won’t always give you the feedback that you expect; their intentions are good, but they are not always helpful; and you end up training yourself as much as you try to train them.

When it comes to designing one, it is very much like training a dog as well. Since there is no visual interface, the tools of brand are limited to the voice and tone of the snippets of conversation that the bot can have. If you are lucky, there might be an avatar that the bot can use, but beyond that, the “personality” of the bot comes solely from the way it reacts and the words that it uses.

No UI is still a UI

First, a slight tangent, if I may.

There is a saying, coined by Golden Krishna, that goes The best user interface is no user interface, or, The Future of UI is no UI. While on the surface, that is a nice, catchy statement, I don’t think it is true. To get semantic, I’d refine that to say The Future of UI is no GUI.

The absence of a graphical user interface (GUI) is still an interface. If your bot uses Facebook Messenger, or WeChat, or Slack, it still has a GUI. It’s just not one that you designed, and you have to work within the constraints of that system.

Further, I would argue that a Conversational UI is still a UI. How could it not be? To design one, you need to make the same decisions that you would if you were designing anything else — there are just a lot more constraints to work within.

You can’t choose the typeface, you can’t rely on colors, or design details such as borders, drop shadows, and the like. Instead, your UI and all the personality of this little bot comes through in the way it can have a conversation. It would be a very different experience to have the bot use a military tone of voice — gruff, coarse, quick and to the point with very few conversational niceties — than if you used a friendly, happy, and more naturally intoned voice.

A Conversational UI may not be a graphical UI, but it is still a UI. There are decisions to be made, but because there are no visuals to work with, the decisions you make are even more crucial to the expression of your bot’s personality and the brand that you want it to reflect.

Our good little boy, Gitpup

As a way to experiment with Conversational UIs, and as a way to create something useful for our team that might also have usefulness in the larger marketplace, Oomph designed, built, and implemented a chatbot for <a href=”//slack.com”target=”blank” rel=”noopener noreferrer” title=”Opens in a new window”>Slack (a Slackbot) and <a href=”//www.hipchat.com”target=”blank” rel=”noopener noreferrer” title=”Opens in a new window”>Hipchat called <a href=”//www.gitpup.io”target=”_blank” rel=”noopener noreferrer” title=”Opens in a new window”>Gitpup.

The problem that we wanted to solve was “How do you make peer-to-peer code review easier to manage and more fun?” As the name suggests, Gitpup is an assistant that we connect to our Github account. Its job is to announce when a Pull Request is ready for review, assign it to someone, track it, and then close it when the review is approved. Once a review has been completed, the user is given “karma” points that come with bragging rights and have become a currency of sorts amongst our team.

Designing the chatbot

Our “design” and personality came from who we decided that this bot was. We toyed with a bunch of ideas, but once we decided that the bot was a dog, it was easy to start to have some fun with it.

As a dog, Gitpup is everything you would want one to be: helpful, quick to respond, and obedient. But Gitpup has a little sass, too. We wanted it to have some personality, and be somewhat of a jokester. It has random phrases that it throws back at you if you mention it by name, and while the randomness is uncontrollable by nature, it does lead to some fun interactions.

A sample conversation with Gitpup

nate whats unassigned
Gitpup APP No open, unapproved and unassigned Pull Requests
nate Thanks gitpup
Gitpup APP You’re welcome, nate!
nichole hey gitpup
Gitpup APP See if I play fetch with you next time, @nichole
nichole y r u so mean?

It utters plenty of encouragement when a Pull Request is taken or completed by a team member.

Sample workflow with Gitpup

Gitpup APP [Review #3366] marc has been assigned to Bring react ish into main oomph repo!, #233 on oomphinc.com. Go get ’em, Champ!
Gitpup APP [Review #3364] brett closed and merged Add logintoboggan module, #269 on drupal-repo +1 Karma (1,766) Yes. You. Can!
Gitpup APP [Review #3365] brandon approved PR Add style for when there are logos in a grid within content (SASS), #207 on kab. Magnifique!
Gitpup APP [Review #3365] Thanks for participating, brandon +5 Karma (903). Woof!

We also built some randomness into the daily grind. In addition to helping with reviews, assignments, and approvals, Gitpup announces a Raffle for any Karma that might be unassigned once a day at a random time. You can type I’m in or I’ll join to enter the raffle.

Joining Gitpup’s daily Karma raffle

Gitpup APP Attention Today’s community Karma raffle is in effect! Say I’m in! to join the
raffle within the next 5 minutes to join for your chance to win 45 Karma!
nate I’m in
Gitpup APP Thanks for joining, @nate, you’re the first and only participant in this raffle, Purrrrrfect! Chances are looking good!
nichole im in
Gitpup APP Fingers crossed, @nichole! There are now 2 participants in this raffle.
brett ill join
Gitpup APP This could be the one, @brett! There are now 3 participants in this raffle.
stephen I’m in as well
Gitpup APP May the odds be ever in your favor, @stephen! There are now 4 participants in this raffle.
Gitpup APP And the winner of today’s raffle is… @nathandentzau! Congratulations! +45 Karma

After interacting with Gitpup for a few days, it is easy to forget that it is just a bot that we programmed. Personality is an easy thing to create if you start from a place of authenticity. For us, we were not trying to create a person, we simply wanted an amiable cartoon character that would be fun to interact with and make what might be a dreary task into something a little more engaging.

A well-trained Bot will also train the User

This little experiment into Conversational UIs helped show us how any UI will also train the user in ways to get the most out of it. With a visual UI, it might be lots of trial and error — clicking around to get a sense of what things are and where they go. With Gitpup, it was the same sort of trial and error, but the downside is that a command can simply go unnoticed if it is not in the bot’s vocabulary.

For instance, our patterns match phrases with a certain degree of fuzziness — we ignore punctuation and plurals, just so the commands don’t have to be perfectly typed. To ask Gitpup which PRs are not assigned to someone yet, you can type “whats unassigned” and Gitpup will respond. There is a drawback to a Slackbot that is in an open room where other conversations are happening — you don’t want it to respond to everything that anyone says, so, if you try to get Gitpup’s attention but don’t use the right terms, you won’t get any response.

Users can quickly learn the different commands that a simple bot will recognize, and it’s not so bad to use trial and error to figure it out. But with a more complicated bot that you are in a direct conversation with (via a text app), it can be a little more awkward if your bot does not recognize a lot of natural language. Be sure to design some phrases in the bot’s conversational database that can be used when it does not understand something, or it can not complete a particular task. Success messages are easy to create, but it is harder to create a failure message that does not frustrate a user or make them think that the bot is simply useless.

brett gimme 4034
Gitpup APP Ruh roh, I don’t know about Review #4034
nichole give 3466 to @thatguy
Gitpup APP Darn, I don’t know who that is!

When is a Chatbot right for you?

While chatbots are all the rage right now, I don’t think normal point and click websites are going away anytime soon. A chatbot service isn’t right for everyone because the service they offer is very transactional in nature—get me this, research that. They can offer information that a user didn’t know that they wanted, but that is often more complicated, and in the end, the user needs to opt into the service somehow.

The questions you can ask are:

Find a Chatbot and Use it!

If you are a marketer looking for new ways to connect with customers, or a manager looking for tools to keep employees efficient and engaged, you should become familiar with chatbots. We’d recommend these as good starting points:

The barriers between our computers and our normal everyday interactions are coming down. A computer that can hear your voice commands is probably not far away from you at any given time. Conversational UIs are making it easier to get what you need at any moment without finding a particular app, typing on a tiny screen, or doing a lot of clicking around. They become another tool in the belt and another way to be where your customers are.

If you’d like more information about chatbots and whether or not your company can benefit from the power of No GUI, drop us a line. We’d love to chat person to person. 😉

More reading about chatbots: