The first thing I have noticed in building a bot is you need to think a lot about state management, even for a basic bot.
The original app we built had 5 or 6 entry fields on a form and you did not need to think about state at all. With the chat bot I now need to think about the state of the interaction between bot and user as it moves from step 1 to step 2 to step 3.
At this point I am going to allow the user to skip ahead with some smart text analysis, and I've accounted for that in my state document. But I am not yet allowing the user to move backward or change an answer.
For our basic bot we have developed a simple flow chart on a white board that describes the 5 steps and where we allow skipping, and what are the criteria for the skip.
For anything more complicated you would need to write something up and spend time thinking those requirements through. As it is for our bot, we are going to release an MVP and get some user feedback from power users, then we will look at possible expansion and feature addition. And I will likely need a real flow chart for that.
We are starting to build a couple of conversational UI programs at work using Slack. Slack is a great program and I wrote an earlier post about some challenges I had writing a basic integration.
So now we're tackling something a bit more sophisticated and building some bots. The first will be to handle a couple of basic data entry tasks that we have that we think will be better or easier if people can do them directly from Slack.
Of course we'll need to get user feedback on whether they actually make life easier, but I think by investing a little time in the bot it will improve things. We plan to do this in two ways:
Our bot will parse some answers and use extracted information to pre-fill some other data.
Allow multiple entry/splits on some items by indicating that you want to do so. Where this would require a grid in the web, and might be unnatural given the flow of existing pages, we think it will work quite naturally in the bot.
I recently attended a great, one-day seminar by Edward Tufte. It was full of highly valuable strategies for presenting visual information and very inspirational. He definitely isn't afraid to challenge conventional notions in interesting ways. If you are interested in data, communication, and data visualization you should take the opportunity and see him.
All this got me thinking about my own work differently, and how I can work with my company's data to improve our work on projects. I work for a consulting company and we have lots of data on project execution - hours used, features completed, velocity, and client satisfaction especially.
I immediately started to dig into our project data burn data on project with lots of preconceived notions about what I would see in terms of the shape and composition of projects. Some of these preconceived notions were valid, and some of them were way off.
I am in the process of trying to come up with some base visualizations I can use (easily) across all projects and also re-evaluating my preconceived notions in the process.
A good opportunity to take a deep breath and listen, instead of trying to force my preconceived notions onto data that is clearly contradicting them.
I've been an avid reader of Seth's Blog for years. It is great. You should read it.
You probably won't agree with everything he writes but that does not stop it from being smart and worthwhile, pretty much every day.
One thing that he talks a lot about is the sharing economy. The sharing economy is all around us, and by most accounts it is a successful and powerful idea. For many people, I suspect, the reasons for this are a foregone conclusion and do not need a 'why'. Or maybe the why was covered a long time ago by someone else and everyone (else) already knows the answer.
But not for me. For me, there are inconsistencies that have to be ironed out for it to be consistent with capitalism, which of course has been pretty successful too, in the long term.
It doesn't reconcile incompatibilities between the sharing economy and capitalism in my opinion, but it does give a sense of how sharing has impacted us in the (very) long term. And can help you understand the power of the sharing economy and how it interacts with other forces.
I will probably use some Angular on the front end, when I get there, but I am not there yet. I technically "know" Angular, since I learned that last summer.
It is very time consuming to learn all these things. But I chose it because I run this site with Ghost and this is what they use, or at least, something close to that. I have no idea if they use Webstorm, I just picked that.
Why did that (the blog) make me want to learn all this tech? Well, I think it was partly that editing a few Handlebars templates to make my theme work in Ghost made me overconfident, and partly that since I plan to host it similarly to this blog I wanted to use something similar.
I forget sometimes how much work it is to learn new technologies. It's hard, especially when you are learning several at once. You always spend a lot more time learning and Googling than you plan to, even when you've used analogous tools before.
And CSS slows me down too. That's another technology that technically I "know", but of course those quotes are there for a reason.
All this got me thinking about proliferation of tools and productivity and so forth. It would be nice to have a hammer we all could learn to use. But of course, sooner or later, you have some type of central planning committee and none of us want that. Over time the marketplace will answer some of these questions and some it won't.
But we do need to ask ourselves, at this point: Is JavaScript becoming a hammer? Has it already happened?
Jonathan Fries on .