We want you to flex your creativity with Dexter bots in any way possible. Today we’re launching a new tool to expand your horizons even further: the Dexter Interactive library. You can now bring your conversations out of their corner and into the whole of your website

One of the major limitations of bots is that they live in a safe little bubble that doesn’t have much to do with everything else around them. What if you could let a user browse your site from your bot? Or highlight something on the screen as you explain how it works? Maybe make that Space Quest reboot you’ve always wanted? Dexter Interactive is here to help.

The library is open source and well documented. Getting started is as easy as replacing your existing bot snippet with:

<script type="text/javascript" src="https://cdn.jsdelivr.net/npm/@rundexter/dexter-interactive/dist/dexter-interactive.min.js"></script><script>
dexterInteractive.createInteractiveConfig({
  handlers: []
  , dexterSettings: {
      botId: '' // Example: AABBCC123123
      , botTitle: '' // Example: My Best Botty
      , baseURL: 'https://bots.rundexter.com'
      , url: 'https://rundexter.com/webwidget-beta'
  }
})</script>

Fill in your bot ID and title, hook up a few ways you want to handle messages, and you’re done! You can react to either the actual text of a message or take advantage of the new ^metadata() tag to pass along specific cues:

+ hi
- ^metadata({"action": "hello"}) Hi there!

You’d react to the above like so:

handler: [
  {
    metaPath: '0.action', meta: 'hello'
    , onMatch: () => console.log('User said hi')
  }
]

There’s some great examples for you to check out, with more to come. We can’t wait to see what you make!

There are times, of course, when a machine can’t fully substitute for the adaptability and breadth of a conversation between two real human brains. If the people behind your account have the staff and patience to lend your bot an occasional human counterpart, Dexter has always been ready to help you step up and provide that service.

We have 2 tools to help a human step into your conversation. For serious usage, many bot writers choose to take advantage of the Relay tool that comes with our Platform and Enterprise plans. Others engineer a special “Human mode” section of the bot where their users can choose to wait for an agent to step in for a chat.

For human mode bots, there’s a sneaky little UI issue that can creep in when a human doesn’t immediately step into a conversation. Let’s say your bot is Sally’s Pizza, and a user Frank comes to start a detailed discussion on how you should treat the tomatoes in your famous fresh tomato pie. You, however, are busy slinging hundreds of your coal-fired beauties and miss Frank’s question. Frank, understanding that you’re probably busy, closes his browser and promptly forgets he asked the question. The next day, Frank hops back on his chat with your bot to check your hours….but uh oh, your bot doesn’t respond. Radio button silence. Dead macbook air. What happened?

Well, most of the time Human Mode involves a topic that looks like this:

+ *
- <noreply>

That means that, since Frank placed himself in Human mode, he can no longer interact with your bot! Most bot writers understand this possibility and give their users an obvious way out:

+ human-start
- OK, we'll try to get a human to you ASAP.  If you want to stop waiting, just say "exit" and we'll take you back to the main menu.+ (exit|stop|menu)
- Sorry we couldn't get to you!  I'll take you back to the main menu now. <send> {topic=default} {@ menu}

This isn’t as useful as it could be for Frank, however. Since he came back to the bot later, he probably doesn’t remember exactly what he was doing last time he was there. Then, either through not paying attention to the instructions or having them somehow disappear from his immediate view, he doesn’t know about the “exit” instruction, and is stuck with an unresponsive agent. This is not, as you might imagine, a great experience.

One fairly simple way around this problem is to remind the user of the instructions occasionally. Our recommended strategy is to keep track of how long the user has been in Human Mode and, after a certain amount of time has passed, use the catch-all to respond with a fresh reminder of the exit instructions. So as to not hold you in suspense, here’s the whole topic that implements this idea:

// Use this to start the human takeover process
// Called from anywhere via {topic=human} {@ human_start}
+ human_start
- OK, I'll step aside so a human can come in and chat with you. <send> If you get tired of waiting, just say "Back to Bot" and I'll take you back to the main menu. <call>setHumanStart</call> ^buttons('Back to Bot')// Tell the user to call this to get back to the regular bot
+ back to [the] bot
- Welcome back! <set human_start> {topic=default} {@ menu}// This is what kills the bot's response while a human is talking
// to the user. It mostly means the bot won't respond at all, but 
// after a certain amount of time it'll remind the user that
// they're still waiting for a human.
+ *
* <call>isStuckInHumanTopic</call> == true => Hi there!  You're still waiting for a human to get back to you.  If you get tired of waiting, just say "Back to Bot"! <call>setHumanStart</call> ^buttons('Back to Bot')
- ^bypass()// Set up a time when the user last heard from the bot.
// We'll use this to see if we need to remind them how to exit. 
> object setHumanStart javascript
rs.setUservar(rs.currentUser(), 'human_start', Date.now())
< object// Check and see if the user is stuck in the topic based on
// how long it's been since the bot last chatted with them.
> object isStuckInHumanTopic javascript
// Get when we started waiting for a human
var started = rs.getUservar(rs.currentUser(), 'human_start', Date.now())
  // Let the caller give a specific age they want to use and default to 5 minutes otherwise.  Change this to change the wait time.
  , waitFor = args[0] || 1000 * 60 * 5
;
// We're only "stuck" in the human topic if we haven't been waiting long
return (Date.now() - waitFor) > started;
< object

That’s it! If you want a breakdown of what’s going on, let’s take it chunk-by-chunk:

+ human_start
- OK, I'll step aside so a human can come in and chat with you. <send> If you get tired of waiting, just say "Back to Bot" and I'll take you back to the main menu. <call>setHumanStart</call> ^buttons('Back to Bot')

This is the standard Human Mode intro, explaining to the user what’s going on and what they should do. There are 2 important features here:

• <call>setHumanStart</call> We call a macro that remembers when we started waiting for a human
• ^buttons(‘Back to Bot’) We give the user a clickable way to exit the bot if they want.

+ back to [the] bot
- Welcome back! <set human_start> {topic=default} {@ menu}

Here’s the standard exit, but note that we clear the human_start flag to make sure any future human conversation requests start from a clean slate.

+ *
* <call>isStuckInHumanTopic</call> == true => Hi there!  You're still waiting for a human to get back to you.  If you get tired of waiting, just say "Back to Bot"! <call>setHumanStart</call> ^buttons('Back to Bot')
- ^bypass()

This is the big change — we’ve tweaked our usual catch-all-and-kill block so that it constantly checks to see how long the user’s been stuck in this topic. If our macro decides we’ve been waiting too long, it’ll respond with the instructions, then reset the clock so that it’ll again wait before the next reminder.

> object setHumanStart javascript
rs.setUservar(rs.currentUser(), 'human_start', Date.now())
< object

A quick-and-dirty macro to capture the current time for later comparison.

> object isStuckInHumanTopic javascript
var started = rs.getUservar(rs.currentUser(), 'human_start', Date.now())
  , waitFor = args[0] || 1000 * 60 * 5
;
return (Date.now() - waitFor) > started;
< object

A less quick-and-dirty macro that decides if the user’s ready to see a reminder. We grab the time of our last reminder (started), figure out how long we want to wait before nagging (waitFor), and return true if we’ve been waiting long enough.

Other games explored different conversation systems. In the heart of the Ultima series, you could chat with any in-game character that wasn’t trying to kill you. Friendly characters might say hi and prompt you to respond, but otherwise, you were left to your own guesswork on how to continue. You quickly learn to ask everyone about their “Job”, and that they will not stop talking to you unless you politely say “Bye”. Each character could respond to a certain subset of topics, some of which would present themselves clearly in conversation, while others must be inferred from your growing knowledge of the world.

The true masters of the conversational game lived at Sierra On-Line. Creators of the famous King’s Quest, Space Quest, and Leisure Suit Larry series, Sierra games were conversational from the very beginning. Walk your character up to a locker and “Look at the locker” — why, the locker is closed! “Ok, open the locker” A bottle of shampoo drops to the floor. “Take the shampoo” You’re half ready for your shower!

Every time you popped a new Sierra game into your high-end, double density floppy drive, you immediately began to test the edges of its language skills. Weird requests, curse words, innuendo…it was fun to explore what a computer could and could not understand. No strangers to humor, the authors at Sierra anticipated a great deal of this behavior, resulting in a bevy of appropriate easter egg responses. “Take leak” was always good for a giggle, even when no onions were around.

Sierra managed to build conversational engines in 1980 that not only spawned a decade’s worth of hit games, but also predicted much of the technology we currently leverage for creating bots. Let’s take a look at how they implemented some modern concepts in AGI (the Adventure Game Interpreter) 36 years ago, and see how it stacks up against SuperScript, a modern bot development platform.

Topics

When building chatbots, related parts of a conversation get organized into topics. There’s no jumping from subject to subject without a specific transition, just like there shouldn’t be in a sane and sober human conversation.

In SuperScript, topics are separate scripts that contain a collection of related “gambits” — conversational pairs of user requests and bot responses. To change the scope of the conversation, a gambit must redirect the user to a separate topic. Talking about Robot Wars? Say “I’m tired of robots. Can we talk about Full House instead?” and a smart script will take you a new — and less interesting — topic.

> topic:keep old_games (games, non-millenials)//Provide a clue if we don't understand the request
+ *
- I hear you like old games - have you tried Leisure Suit Larry?//Give a simple response if they're fans
+ * (like|love) Leisure Suit Larry*
- Careful, he might love you back!//If they profess a love for a lesser game, respond with some snark,
//then send them to a topic that might be more appropriate for them
+ * (like|love) Pokemon*
- Uhm...yeah, sure, that's an old game.  (cough).  
^topicRedirect(millenials)
< topic

In AGI, scope is defined by a more “physical” boundary: the room that your character currently occupies. Each room carries its own set of definitions, gambits, and other scripts. If you try to “light the stove” in the bathroom, AGI won’t know what you’re talking about, but in the kitchen you’ll see little red pixels of fire spring up. Global scripts and gambits can be #included in any room, giving authors the flexibility to share data and conversations between rooms.

To change scope, simply walk your character into a different room.

//woods.txt
if(said('take', 'mushroom')) {
    print('You pluck a mushroom from the rotten log');
}//basement.txt
if(said('take', 'mushroom')) {
    print('You brace the window to prevent the purple elephant from flying into your cerebellum and stealing your Cheetos');
}

Triggers

Every time a user sends a request, it gets checked against a series of triggers. When the request matches a trigger, the response associated with that trigger is returned. These pairs are called gambits. They’re the guts of a good chat system.

In SuperScript, triggers are complex, powerful things. They can range from simple exact matches:

+ Hi there!
- Hello!

to wildcard matches:

+ What do you think of *?
- I love <cap>!

to full-blown, natural-language-tool-fueled, english-degree-justifying structures:

+ Why is my ENTY:animal <verb> a <noun> at me?
- Maybe if you remembered to feed it from time to time this wouldn't be a problem....

Even more, you can make rough conceptual matches using the built in WordNet english language lexicon:

+ Is a ~canine a doge? #(matches dog, canine, dalmation, etc.)
- <cap> is SO doge!  Wow!

This is where modern technology has left AGI well behind. Just including the WordNet database would have caused the original King’s Quest to take up at least 35 floppy disks, and you would have had to load and empty your system’s memory 88 times in order to read it all. We won’t even discuss the impossibility of the increased processing power required.

However, AGI did have a limited, yet clever, strategy for performing simplistic NLP. Games were distributed with a WORDS.TOK file that acted like a manually generated WordNet conceptual matcher. For each word you wanted to use in your trigger (“counter”), you could add a group of matching words (“countertop”, “cabinet”, “shelf”, “island”).

In an actual “gambit”, the string() function was used to find word matches inside the input. string(“get”, “knife”, “counter”) would then match “Get the cleaver off the island”, “Take the blade from the shelf”, and maybe even “Grab the stabbystabber from the boxtopthing.”

// WORDS.TOK
bae | smh | yolo | fleek => millennial
// grade_school.txt
if(string('say', 'millennial')) {
    print("I didn't understand a word you just said...");
}

What’s more, AGI was a full-fledged scripting language, so it could even do things that would be difficult or impossible in SuperScript:

//political_convention.txt
#define has_head_trauma f100if(say('listen', 'debate')) {
   if(has_head_trauma) {
       print('This all makes total sense!');
   } else {
       print('Their lips are moving, but all that comes out ');
       print('is darkness and disappointment');
    }
}
if(say('bang', 'head', 'wall')) {
   set(has_head_trauma);
}

Responses

Language generation is an area that doesn’t seem to have progressed very well in 35 years. Replies in both SuperScript and AGI are simple systems that combine plain text with the occasional piece of captured data. SuperScript adds the ability to make replies bounce the user between topics, while AGI can take advantage of its full scripting capabilities to tweak responses.

//SuperScript
+ Hello
- Hi
- Don't you have anything better to do?
- I SAID HI! ^topic_redirect(grumpy_bot)//AGI
#define response 1
if(say('hello')) {
    if(equaln(response, 1)) {
        print('Hi');
    } else if(equaln(response, 2)) {
        print("Don't you have anything better to do?");
    } else {
        print("I give up.");
    }
    increment(response);
}

Where are we now?

After 1990, Sierra moved from text to simpler icon-based actions in order to make their games feel more approachable.

Sadly, the entire industry followed suit, and modern games gradually moved away from conversational interfaces. Open-ended inputs were traded for choose-your-own-adventure style canned text, and now have been further simplified with radial-style clickers.

Text-based games did live on past the heyday of AGI in some places, such as online Multi-User Dungeons (MUDs), although they, too, are a dying breed:

Even the prolific indie game community seems to shy away from conversational interfaces. There was one heroic effort to build a conversationally driven game in 2005 called Facade which was hailed as the “Future of video games”. That future never arrived.

However, thanks to the current Bot craze, momentum has returned to conversational interface design. As we gain understanding in how best to use and design such interfaces, and as we design better and more efficient tools, maybe an ambitions game developer will figure out how to realize a powerful, modern, chat-based game.

Or maybe I’ll just rebuild Colossal Cave Adventure in Dexter.

Just because you can’t have too many justifications for newfound distractions, I also realized that the game teaches a very valuable lesson for startup types, programmers in particular. For those not familiar with mahjongg, the goal is to remove exposed tiles in matched pairs from a specially shaped stack. There are four of each type of tile, so throughout the game you’ll have several options of which of the four to remove as pairs. The real trick is that every time you remove the first two of four tiles, you’re critically limiting your furture pair matching ability for that set, since now you -must- pair the remaining two.

A player in this kind of environment learns several important things. First, you cannot play safe - there’s no way to win the game by leaving all your options open, and crafty stacks obscure difficult challenges you may face in the future. Therefore you must play smart, and you play smart by only making moves that make a future move possible. Each pair removed should expose one or more tiles you -know- you’ll need for a move in the future…removing pairs just for the sake of their removal often causes you to lose the game.

This is also a sound strategy for a startup. You start your company early with a whole world of options in front of you, but resources to only pursue a few. Pursuit of one option often removes several others, and so each step you take should set up one or more future moves. Randomly exploring possibilities will, more often than not, ultimatley prevent you from reaching your goal.

For startup programmers, this lesson is all the more poingiant. There are always libraries, routines, and architecture that require our attention, and we lack the resources to merely peruse our to-do list until all items are finished. Instead, we must choose what architecture to make robust for worry-free scalability and which we can hack into place. If you over-optimize the wrong code, those you neglect will haunt you during your first traffic spike. We must think three steps ahead to see which routines might benefit from being rolled into a library for better portability and which will survive with judicious copy/paste solutions. Choose wrong and a future tweak to your logical, not fully realized, will irrecoverably corrupt your data.

I live on the web.  I work on it, I play on it, I socialize on it.  I am, therefore, subject to great temptation to misuse the web, particularly during work.  Random browsing and long chains of link-following are very detrimental to productivity, and controlling the impulse that begins such acts is very, very difficult.

Today I finally found a tool that somehow has managed to escape my notice for years: LeechBlock.  This tool lets you add your distracting sites to named buckets, each of which you can give a certain number of access rules.  For instance, I have two buckets – Time Wasters and Semi-Time Wasters:

Time Wasters

I identified these as the sites I’d start browse to just by habit, almost out of sheer motor memory.  An instant distraction is all it would take for my mouse to automatically open a browser and start typing one of these addresses:

• http://reddit.com
• http://arstechnica.com
• http://newegg.com (why is assembling and configuring systems you’re not going to buy fun??)

I set these up so that I can only get them for five minutes an hour during normal business hours, 7 days a week

Semi-Time Wasters

These are sites that I visit somewhat less regularly, or are useful enough in a business sense that I don’t want to completely remove my ability to read them:

• http://news.ycombinator.com
• http://nytimes.com

I allow myself 10 minutes per hour on these.

My previous approach to this problem had been to de-route my obsessive sites in windows/system32/drivers/etc/hosts (by pointing them at localhost).  This kept them completely out of my reach, but I was loathe to move the less distracting sites into the scheme as I do get quite a bit of good, marketable information from them.  That meant it was just pure willpower that kept me from reading pages and pages of good content while I should be crushing small, elusive, annoying bugs.  Needless to say, it didn’t always work out well.

The impressive result to he self-denial process is how quickly the motor memory fades.  A few disrupted attempts at redditing is all it takes to make the urge go away.  It’s like the invisible gremlin in my head that was keeping me from working gave up and went home.

The big problem with Prism right now is that it's in beta and isn't technically Firefox (even though it's the same exact browser engine).  That means software that sniffs the user agent string specifically for certain browsers has no clue what Prism is, and therefore might not let you do everything you could were you in Firefox itself.  Most people come across this issue with YAHOO Mail.  YAHOO's newest mail client is super-sexy, but in order for it to do all the fancy interactivity that it does, it relies on having a very modern, snappy javascript implementation in the browser.  To make sure the user's experience is top notch, it therefore only lets browsers it knows are good enough into the new client, and forces older or unidentifiable browsers into the old, flat client.  Unfortunatley, it does not yet recognize Prism, and therefore your nice YAHOO Mail sandboxes in Prism won't have access to the newer mail client.

In theory, there's a plugin/template linked to at mozilla's prism wiki that is supposed to fix this problem, but it doesn't seem to work as of Prism 1.0 beta 1.  A user named rotassator on the Mozilla Lab's forums outlined an excellent alternative solution that I'd like to repeat here for searchers' sake.  Here's how to do it:

1. Create your Yahoo Mail sandbox by running Prism and filling in the form, creating a shortcut in your start menu or on your desktop
2. Right-click on the shortcut and go to 'properties', then copy the entire contents of the 'target' field to your clipboard.
3. Goto Start / Run (in XP) and paste this information into the window, then at the end add the text -uri about:config
4. Agree that you're OK voiding your warranty (and don't panic, this isn't a big deal)
5. Right-click somewhere in the window and goto New / String
6. Call your new string general.useragent.override
7. Set it to Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 - this will make it look like you're using Firefox 3 on Windows Vista
8. Close the window and then run the program from your shortcut normally.  You should now be dumped into the new mail client!

I hope this helps someone!

This sounds all too much like the arguments made against changing standards support in IE6. The IE6 argument started when a Microsoft product was found to handle things in a nonstandard manner that the larger community of developers found troublesome. That argument resulted in the ascension of Firefox and Safari, as well as Microsoft's decision to support better standards in IE7 and 8 later one.

We're now on the second phase of deja vu now, where the Microsoft holds that their method and strategy is fine and proper, even if it breaks their fundamental compatibility with the rest of the community. Now we'll move on to the last phase, where enough of an outcry is generated that a secondary application like Thunderbird or GMail begins to get better PR and market share. Well after this happens, Microsoft will begin to implement better compatibility in order to appease the community and retain their user base.

It's sad that this has to play out again so soon after the IE6 debacle. One would hope that losing 20% of a monopolistic market would be enough of a jolt to change the corporate culture at Microsoft to recognize the importance of standards on the internet, but their recent declarations indicate otherwise.

Outlook is a digital communications tool, and digital communications rely on standards to operate properly. Despite Microsoft's claim to the contrary, there is a standard for email rendering: HTML 4 and CSS 2. YAHOO, GMail, OSX Mail, Thunderbird, and Hotmail all render consistently using this standard, leaving Outlook as the IE6-like outlier. If they wish to use Word to make the editing portion of their user experience better, that's fantastic, and I encourage them to do so. Simply make the results obey standard HTML/CSS rules, and use a real HTML/CSS renderer to display emails from others.