My Google Assistant App was approved within about 24 hours. That's pretty fast and beat the expectations they set at 'a couple of business days'.
It's published under 'Games & Fun' which pretty accurately describes the content - it doesn't contain anything useful, but is intented to be humorous.
The app brings to life a character I created with my kids named Chuckles the Dirt Chip Muffin - The Worst Muffin in the World. It has a bunch of quotes and silly commands.
Anyway, they approved it. It was fun to make and educational. Here is the link in the Google Assistant App Directory: Chuckles the Dirt Chip Muffin.
You can also reach him by saying 'OK Google Talk to Chuckles Chat' in Google Home or in the Google Assistant App.
I wrote some blog posts way back in the good old days of 2016 about a bot we developed for an intenral work tool. It ran inside of Slack. When we did the development we were basically writing code to handle all the states of the conversation. It was clunky and had some real limitiations.
Fast forward to more recent times - we bought a Google Home at the end of last year. Because I usually want to make something and not just consume information, I started to play around with Google Assistant and how to create an Assistant App for Google Home with tools on Google Cloud.
So right away I found myself working in the Dialogflow ecosystem. This was a big improvement over how we built our Slackbot in 2016 where we were hand-coding our state and writing a million if/else statements to handle the user interaction.
The Dialogflow designer interface is intuitive for creating your conversation. My biggest sticking points were working through the integration between it (Dialogflow) and my existing webservices. The answers were there in the documentation but it took some time to work through my SSL issues (doesn't allow self-signed certificates) and formatting of request. This was a little frustrating at times, but nothing out of the ordinary for using a tool that you haven't worked with before.
I also came across Let's Encrypt for solving my SSL issues. Let's encrypt allows you to get a real-ish certificate for development and test purposes. It is fast and automates several parts of the SSL cert process I've never seen automated before - very handy!
My Google Assistant App is submitted now and waiting for approval. I believe I adhere to all their guidelines, so hopefully they will approve me! Fingers crossed!
Our internal bot has been running for a while and getting some use.
We've gotten it so that it runs for 7 - 10 days without issue, but after that length of time it seems to quietly lose the connection and we previously weren't checking for that. I'm not sure if that is a feature of Slack itself or the library we're using. In any case, 7 - 10 days seems pretty good and we should probably add some code to recover if something happens.
To get to 7 - 10 days with a Slack bot, the key was to use the Ping/Pong functionality you can see here. It's part way down the page, just look for 'pong'.
We're currently pinging every 10 minutes. This is a lot less than I've seen recommended, but I believe those recommendations were based on building chat clients with the RTM API, not long-running bots with lots of downtime. I don't want to get in trouble with Slack for sending a million ping messages for no reason.
Instead of upping the number of pings we send (which may have helped) we've added some functionality to check as part of our ping/pong functionality to check for the health of the connection. This seems to be the more responsible way to run the health check and reconnect if the connection is offline.
We've tested our reconnect, which works well. Now we just need to wait 7-10 days to see the production failure occur and see if it recovers.
A user can't really tell what state a conversation is in from looking at the text on the screen.
Does a user understand that this conversation had a specific state and it needs to be revived in that exact place? That isn't really how a conversation works with a human being.
You leave off. You might meet at the coffee pot. Their might be three separate emails.
What you return to doesn't have to be addressed as though it were some procedural checklist. The bot needs to be smart enough to remind the user, to help them pick up where they left off, or just move on if that is what needs to happen.
One of the great things about Slack is that it serves as a direct IM tool, a more general discussion tool, and allows for private groups and channels.
When you're building a bot for this type of tool you need to think about where you want your bot listening and how you want it to behave when you are messaging directly vs. in a public channel.
For our first bot we decided that the main focus would be on the direct messaging and we would keep the bot chatter out of the channels (public discussions) and groups (private discussions). But in the event that it appeared that contextually someone should use the bot, we would make a suggestion asking if they wanted to direct message the bot.
We can then invite the bot to channels where we think this would be appropriate, and not invite the bot where we think it would be annoying.
Slack is quite powerful and well thought out in this regard and this type of cross-linking between messages, channels, and users is easy to do.
If you are just getting started with this, it is very helpful to read the Message Formatting Spec for Slack.
Jonathan Fries on .