🤖 A Peek Inside Camber Bot: Our Marketing “Website”

Jonah Katz
Camber Creative
Published in
7 min readFeb 14, 2017

--

We just launched our, shall we say, long overdue redesign of our marketing website. We wanted to do something more fun and experimental than the traditional marketing site, and because we are a bunch who loves creating beautiful and interactive apps we decided we should do something epic; so we invented CMBR Bot.

Meet CMBR BOT — The user-guided, ReactJS-powered, conversational bot, built by and for the app design and development team, Camber Creative. 🤖

How fun! Turns out, however, that even though the design is quite simple (Brice likes to call it “undesigned”), the implementation is not. Like, at all.

There’s the content, the dynamic but natural feeling flow of conversation, the animations (and timing of said animations), the communication between the different team members — the list goes on. We were determined to make this thing perfect, which meant we were in for a challenging few months.

Here are some particularly interesting challenges and how we solved them.

1. Writing the Conversation

We had several goals with the conversation script. The end result is a balancing act of all of these objectives.

Goal #1: Address the user’s intent in very few clicks.

The script is based on the history of “getting to know each other” conversations we’ve had with our new contacts over the years. The user input options and responses closely mimic the flow and content of these real human conversations.

More frequently discussed topics are presented earlier in the workflow. Less frequently discussed topics start to appear later.

Goal #2: Provide a variety of “choose your own adventure” style experiences so that users could navigate through the site somewhat on their own terms.

At any point during the conversation the user can decide to take a different “path.” Using either a suggested next path that we provide, or by using a “jump menu” to access all possible paths, the user never has to feel stuck in the current conversation path (unlike some of our real world conversations, looking at you Steve 😜).

Goal #3: Allow some conversations to branch off into consolidated experiences, while seamlessly transitioning back to the main storyline at the end of the branch.

Some of the available responses result in the conversation branching off into a “sub-conversation” (kind of like going from small talk to medium talk). While in this isolated experienced, the bot is smart enough to only provide options relevant to that conversation. For instance, if the user says they’re interested in making an app, we’ll gear the conversation towards answering questions they might have about making one (Our approach, past work, a price estimate, etc.) and at any point they could branch out and return back to the main storyline.

Goal #4: Allow users the flexibility to override our options and still have a great, natural-feeling experience.

The most important part of the script and experience is that the user is in full control. They can easily indicate what they want and when they want it. We made sure that the app can handle that requirement without it ever feeling broken or without that conversational tone thats so important to this project. We can even direct link right to a specific question: Our Team.

Coming up with the series of responses and replies was easy, relatively. Clearly communicating the flow in a way that could be implemented was not. Google Docs was the obvious starting point:

We quickly realized how confusing and convoluted this would become. 😷

Turns out, Sketch is our friend:

Even though this file got quite large (quite, quite large), it made visualizing the entire flow a breeze. And, it was a snap to then import into an InVision prototype, so that nobody had to suffer this bizarre screen map for very long.

2. Coding the Conversation

We went ReactJS + Redux due to the ever-so-frequently changing state of this app (and because React is awesome!). Implementing the conversation was tricky. We had 2 main goals:

  1. It must be dynamic. Meaning, it needs to be updatable on the fly by someone who does not code.
  2. We need to be able to enter sub-conversations and present response options that make sense. (For instance, if a guest asks for an app estimate, we present questions about their app, and only supply sensible responses).

We opted to put all the data in one big JSON file. The responses, the rules, the different sections of conversations — all of it — is in this one conversation file. It makes it very easy to update on the fly and even gives us the option to eventually move the conversation to a separate server, which in turn will allow us to rapidly expand the conversation( ….did someone say NLP?).

All the active messages and available responses are maintained in the Redux state. But I won’t get into that — you can just use DevTools. 😉

3. Adding Some Pzaz

We knew from the start this was going to have animations. Coming up with the right animations was a challenge; especially in communicating between the design team and dev team. In the end, the translation happened using Keynote (who knew?):

4. Implementing Some Pzaz

Boy, thinking about this stuff still sends shiver down mine spine. Not because animating React elements is tricky (it is), or because the timings of the animations have to be totally dynamic based on the rules inferred from above (they do), or because our CSS delays and durations have to perfectly match the numbers in Javascript (they do) but I guess its because all of that put together . 😁

A few things made this a very manageable process:

  1. Thanks to a clever npm package by Updater, we are able to import JSON files and treat the keys/values as SCSS variables! And of course, using the same variables on the Javascript side:

2. animate.css — boom, done. (seriously, best lib out there)

3. The awesome ReactCSSTransitionGroup component to add and remove animation classes.

5. Saving The Data

The front end of this project was so much work that we really didn’t want to spend additional time coding a backend to save the data (the flows guests take for analytical purposes, contact information for guests who request an appointment, etc.). So, we decided to use Firebase because a few team members have had experience with it and also because, well, its awesome (and hopefully it doesn’t get shut down next January 😉).

It really doesn’t get much easier than Firebase.

6. Using The Data

Ok, we lied. We couldn’t avoid a backend all together. Though Firebase is great, it does not function well as a standalone CRM. So, to make the data manageable, we set up a simple Node.js powered server that listens to Firebase data updates and forwards the data to Pipedrive, which does function well as a standalone CRM. 💜

8. Making It Work On All the Browsers

This was probably the most time consuming “feature” of the site, and in truth is not done and never will be. The number of edge cases we ran into is appalling. The animations, the transitions, the spacing etc simply do not like to be consistent accross all devices, browsers and OS’s, but its in a pretty good place now. One particularly problematic viewport was the Twitter/FB/IG in app browsers. If someone can make an easy to test and debug version of those browsers they’ve got a million dollar idea. (Because using ngrok can only get one so far).

IT LIVES

And now CMBR bot is alive! 😅 Go say hello. And please email us with feedback, we’d absolutely love it: hello@cmbr.co.

And if you’re curious, the entire front end is open on Github. Feel free to check it out! (Admittedly, we’re seriously lacking some documentation and testing. It was an oversight during the excitement of development — and its high on the list of things to get to).

If you want us to build your app (Mobile, Web, Wearable, IoT, etc.), go here: https://www.cmbr.co/?action=looking_to_make_app

If you’d like to work for us (its remote, its challenging, its fun, its awesome), go here: https://www.cmbr.co/?action=work_for_cmbr

Thanks for reading!

Camber Creative is a digital product design and development company, headquartered in Orlando, Florida. We’re an all-expert, fully-distributed team specializing in digital products for mobile, web, and the internet of things. We work with clients ranging from multibillion dollar enterprises to bootstrapping entrepreneurs. Come say hi on Twitter, LinkedIn, Instagram, or Facebook, or tell us about your new project.

--

--