The New Yorker Poetry Bot
The nice folks at The New Yorker contacted/reached out to us about doing not one but two bots to celebrate their 92nd anniversary! We are decidedly pro-bot here at Feel Train, especially since these involved poetry, which is (in our opinion) very well-suited to social media’s often terse writing style. The bot lives on Twitter and on Facebook Messenger.
The Twitter bot portion of the project was a pretty normal implementation for us, but this was our first time making a Facebook Messenger bot! We used Botkit to handle the all the API plumbing, which was easy enough. However, Facebook has a much more restrictive and confusing set of rules for developing Messenger bots. For one thing, it will only accept messaging webhooks from an https instance, which meant we needed to get SSL set up on our dev server. Normally this would be pretty fast but we were dealing with another company’s IT infrastructure so we had to wait around for the ticket to get fulfilled.
The next difficult part was figuring out the different interactions that a Messenger bot allows. We knew we wanted a kind of multiple-choice interface for picking the time of day for poem delivery. Messenger offers at least two choices: quick replies and buttons. Quick replies are a shortcut that act as a text callback; that is, the user clicks one of several canned replies but it’s as though their keyboard autotyped a word of your choosing bound to the reply element. Buttons are more versatile but more complex; they send back any payload of the developer’s choosing. We wound up using quick replies because Botkit is more naturally suited to listening to chat events rather than arbitrary payloads.
And of course there was every programmer’s favorite problem: time zones! We needed to make sure that clicking "morning" means a user gets their poems at 9am no matter what time zone they’re in. That wasn’t so hard: Messenger gives you a user’s time as an integer offset relative to UTC, which makes time zone math incredibly easy. But we also happened to launch right around the daylight savings time change. The problem here is that we were originally storing the user’s timezone offset when they signed up, but we never updated it. And that changes on daylight savings. It also changes when someone physically moves timezones! There’s no way we could find to query for this information directly, but we get it on the server response whenever we send a message to someone, so we ended up simply storing the user’s timezone offset after every poem we send them. Not elegant but timezone code never is.
We loved working with The New Yorker team; nobody will copyedit your bot like they do. However, a huge hurdle in this project was discovering that we didn’t have a continuous deployment system available. Once we realized that, we should have renegotiated the project scope (even though the final products are really beautiful!). Also, a workflow we want to try in the future is that if a client doesn’t have a chat application they can invite us into, we’re inviting them into our company Slack at the start of the project. Trying to wrangle folks into real-time communication when a problem appears is less than ideal.