When to use chat for UI

I’ve changed the design of Yarn a little bit. Initially it relied on two phone numbers — one for talking to bots, and another for talking to users. This split seemed necessary so that the user could know whether he was talking to a human or a bot, and not confuse bots with speech intended for users, or annoy users with speech intended for bots. But it’s not worth it. Getting texts from 2 phone numbers is always worse than 1.

I’d already been developing Forms to allow bots to request structured or visual information. (These are similar to Facebook’s bot API’s structured messages, or Telegram’s inline keyboards.) I replaced the textual rendering of Forms with web forms. I also always deliver forms from the same phone as the thread.

So, instead of getting this from a different phone number:

@sched: Hi! What days work for you for “deadpool, anyone?” Reply with a list of today, tmrw, thu, fri, sat, sun, mon, or type skip or any.

Yarn now sends a form with a calendar widget from which you can pick days. Users can interact with these without sending unnecessary messages.

(By the way, the @sched bot didn’t need to be updated at all. It was already interacting with Yarn using Forms, and so it didn’t care that the rendering technique changed.)

Improving this behavior for third-party bots also meant changing it for the core Yarn functions like adding users. You can still “/invite bob” if Bob is a contact, or “/invite 800–555–1212” to add a new user. However, if the new user is unknown, you’ll be prompted with an add user form.

Another example is the @reddit bot. This bot lets users chose from the top reddit posts of the day to share with the thread. Since this one is visual, it was had been done with Forms from the start.

I haven’t completely removed the ability to talk to a bot 1:1. You can still do so by starting a message with the bot’s name. For example, “@sched weekday” tells the scheduler bot that you want to find a weekday to meet. Like twitter, messages starting with “@” are shared only with the mentioned bot, not the other users in the thread. (I may also borrow Telegram’s and Slack’s idea of letting bots install “/” commands... I haven’t decided if that’s necessary yet.)

Of course, you can also create a new thread with just you and the bot if you’re into that kind of thing.

Emoji Charades is a little bit different. Since gameplay works by letting many people try to guess a movie title, it makes no sense to require users to type “@emojinary Silence of the Lambs” when it can passively monitor for the title (with fuzzy matching), and announce to everyone when there’s a winner.

So, with these examples in mind, I think I end up these principles:

  • Preserve the boundaries of the space: if you’ve added a bot to a thread, the bot should communicate with people inside that thread only. For my lo-fi sms implementation, this means using 1 phone number for any interaction related to a thread.
  • No 1:1 dialog with social bots. If the bot can hold its own as a participant (eg @emojinary), that’s fine. Other bots should send Forms and get out-of-band responses.

Alistair Croll suggests that a benefits of chat-as-ui is debugging: every conversation can be displayed as a simple text log. However, relying on forms more heavily doesn’t detract much — it’s possible to render the forms in a log much as you would simple text. As for self-segmenting, that’s probably true, but would mostly apply to commercial transactional use cases which I’m less interested in with Yarn, and which would probably be handled as 1:1 with the bot anyway.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.