We’ve just released another open source project in github, a humble utility we’ve been using to generate and maintain data intensive rest endpoints that have a CRUD behavior on database tables.

It’s implemented in Java, and it generates:

Java Beans for tables.

JDBC based Data Access Objects to retrieve and execute commands on the PostgreSQL database.

Jersey 2.0 endpoint classes for each table.

The goal was to automate the creation of straight forward endpoints, and to separate data structures, and queries affected by changes in the database in base classes meant to be inherited, and updated regularly as the database evolves. So that, every time you make a change in the database, you just run the generation process and it updates all your related code.

All the generation is driven by templates files, with some ugly tokens for dynamically replacing content and at times for required pre processing of conditional logic.

The generation is based on metadata queried from the PostgreSQL database, but it could be extended to support other relational sources.

It generates Java code, but we are thinking about moving to node.js REST endpoint generation, in the near future. Suggestions and contributions in this sense are welcomed.

We’ve made available a docker image of our enterprise chat, task manager (and slack alternative) Kezmo. We used a Raspberry Pi 3 as our infrastructure benchmark for a fresh installation ready to support a small team and it works 🙂

So, what’s Kezmo?

Kezmo is an enterprise chat and team collaboration platform that can be customized and integrated to any system in your organization. It’s based on a small set of core concepts, which are: work spaces, conversations, containers, and container items. A workspace is a pocket of context to collaborate around any given subject. It can be a team, a project, an short term initiative, a client, you name it. Members can be invited to workspaces by it’s creator, where they can exchange conversations, documents, notes, tasks which are stored in workspace containers. The underlying design goal was to provide an intelligent way to store and categorize shared content by type, attempting to overcome chat archeology whenever you need to go back and recall what was the agreement, link, or file shared at any time.

You can try the vanilla version from the cloud, or you can run it on premises. We implement white label versions of Kezmo, with custom content types, forms, and automations to integrate it into domain specific systems, in health, finance, and construction. If this could interest you let us know.

We have recently released our support chatbot in Kezmo (our own @kezmobot), implemented with API.AI, and this blog post details some of the lessons we learned building it.

Kezmo is a task management & messaging platform for organizations that require an agile internal and external communication. The product includes a support space where users can chat with our team. Up until recently support was handled by a subset of the whole dev team. While this has been great as a way to get insight into our product’s usage it’s also true that pareto holds and 80% of the users tend to ask about the same things, hitting 20% of our knowledge base. Also, answering customer questions during weekend nights is not fun after a while.

So we set out to build our own customer support chatbot.

Why API.AI?

If you are about to build a chatbot you’ll learn there are number of alternatives out there provided by the major players in technology, and then some more. Among them: API.AI from Google (recently acquired), Microsoft Bot Framework, IBM Watson.

API.AI was recommended to us by our good friends at the Tryolabs team. When evaluating alternatives such as the Microsoft Bot Framework we realized that API.AI requires less code plumbing, and overall proposes a more simple approach (higher limits on number of intents, no need for handlers on intent callbacks, no multiple cognitive services and endpoints). Plus API.AI is free, right? After exchanging emails with Google’s API.AI sales team, I’ve learned that:

Our platform is free to use as provided but we do restrict requests per minute to 180 on average. Google Cloud will add paid tiers later in 2017 with new features that align with enterprise requirements and allow for increased request rates.

They said the free version isn’t going away. We’ll see about that. So, for now free means you can make up to 180 queries to API.AI per minute, so you get about two per second. For the time being this works for us.

Getting started with API.AI

In API.AI chatbots are defined as agents. In API.AI you define an agent based on intents, which are the conversations interests it can handle. For each intent you define a number of phrases, texts, used to train the model. So that whenever a similar phrase is found that intent is matched. In our experience, in API.AI you should think about loading around 20 sample sentences for each intent for the model to behave reasonably good.

You connect to your agent using any of the supported out-of-the-box channels, such as Facebook Messenger, or Skype, or you can code your own client using any of the supported libraries to connect with API.AI. Since we wanted our bot to run on Kezmo, our own messaging platform, we had to program the integration.

When you create an agent you can base off existing sample data which preloads the agents with typical intents, or you can import prebuilt agents, which also preload intents into the new agent.

We wanted our bot to handle basic small talk, so we imported the small talk pre built agent, which loaded 84 intents. The imported intents do not include preloaded answers. So expect to spend some hours loading content in order to enable casual conversation skills.

Then we moved on to load our FAQ knowledge base as intent responses. In order to do this we combed all our support conversations for the past six months to identify intent patterns, and mine typical phrases used to express intents. This took days. We ended up with more than +500 sentences expressing intents.

Output formatting of the chatbot responses in API.AI

For a first version we loaded the answers directly to API.AI, I know we could have implemented an action, and a fulfillment to retrieve them from some endpoint but not for version one (make it work, make it right, make it scale).

The first issue we faced was supporting line breaks in the response texts loaded in API.AI. For some reason this gets lost in the client call, so we had to include markup (\n) and a basic post processing code for the API.AI calls to replace \n occurrences for actual line breaks in our messaging platform.

Implementing the bot human handoff with API.AI

Kezmobot is a customer support agent meant to act as first level support, so we need it to be able to escalate questions in a number of scenarios, including when the user explicitly requests to talk to a real person. Our support channel is a group chat, which means it’s key that the bot remains quiet once the human agent takes over the conversation, otherwise you get the nightmare scenario where the chatbot answers both the client and the human support agent.

Transferring chat to a human agent is not something API.AI supports out of the box. You need to add some client code in order to implement this sort of behavior.

In our case we relied on a hand off context, that whenever returned as output of an API.AI call the client code would simply sleep the bot for 10 minutes, for the current client conversation (it quickly became clear it needed to be more like 12 hours).

Since we wanted to achieve a natural looking transition we created an intent that would match phrases such as: @kezmobot I’ll take over from here. This intent outputs the QUIET-MODE context notifying the client code to stop passing calls for that conversation, and that’s how kezmobot goes silent.

Handling sentences with multiple intents with API.AI

After combing our support log we realized humans have a tendency to pack multiple intents in one sentence. Interactions like the following are common:

Hello, how are you doing? I wanted to ask about X feature, how does it work? By the way I love your product, thanks!

Here we have at least, 3 intents, like:

Opening Greeting

Feature question

Closing thank you

These type of sentences can lead to a mismatch of intents. The model may match any of the three intents, leaving two unanswered. What we did was implement a very basic pre processing of the text we send API.AI to recognize stop tokens, used to split the sentence in multiple calls. For instance, we would split the sentence on occurrences of substrings such as: . ! ? which would output something like the following:

Hi

You can use feature X in this or that way.

Glad you like our product! (would be great if you could post a good review on the store!)

That’s half of the solution. The other half is adding in our welcome intent wording to let the user know our bot works best with short simple phrases 😉

Measuring your chatbot accuracy

We loaded a CSV file with two columns. On the left column a sample text from our support logs. On the right column the expected intent for each phrase. Then we ran a process that would call API.AI using each line in the CSV file, and check the output against the expected intent. The difference between expected, and actual was used to calculate the % of accuracy.

One caveat is that you have to sleep your calls to API.AI to avoid going beyond the allowed throughput for the free service.

Between executions we tuned the ML Settings for the agent. Basically we played with different numbers for the ML Classification Threshold. We settled (for now) on a 0.5 value, which worked best for us to avoid false positives.

Implementing a chatbot that can handle multiple languages with API.AI

A big part of Kezmo’s user base is from spanish speaking countries, so it was key for us to support multiple languages.

They way to implement this is using multiple agents, one trained for each language.

Currently we have released the bot for spanish, and we are working on tunning the english version of it.

The good thing is that with our approach the client code does not care about the spoken language, or even the intents at play. We rely only on existing contexts, that must be shared among languages. What sets them up is transparent for the client code.

Chatbot analytics on API.AI

For the time being API.AI analytics are pretty basic. It’s rumored that they will open Chatbase to the masses some time. In the meantime log your own stats in your database.

Closing Thoughts

API.AI is adding features on a monthly basis. Business model is still not rock solid. But it’s simple, and gets the job done. It provides a good balance between expressive power and simplicity of the whole developer experience.

Real world usage of our chatbot is not like our human interactions, and now we are working on a second round of tuning after real interactions people are having with our bot.

If you want us to check your support process to see if we can implement a chatbot for it drop us a line, we’d be happy to help you!

Scroll based interfaces are everywhere. It has been the de facto overflow solution since we saw the first modern user interface, and of course it is widely used everyday on our mobile devices today.

But even though scrolls are very common, we have all seen apps spicing the scrolling experience up in different ways, and as mobile developers we want the best experience to delight our users too.

Having this in mind, I decided to create and share a simple UI component that hopefully will help you create better experiences as well.

Introducing the OLSDynamicHeaderViewController

OLSDynamicHeaderViewController is a simple iOS UI component that allows the most common scroll based UIs to have a header that can be easily animated along with user scrolling, as simple as that! So…

How do I get it?

The code is published on GitHub as you expect, with a sample project showing the basic capabilities. You can either use it through CocoaPods or you can also copy the files directly to your project, old school style.

How do I use it?

First, make your UIViewController to inherit either one of the helpers OLSDynamicHeaderTableViewController or OLSDynamicHeaderCollectionViewController.

Now, you need to provide a header view to the component, and for that, you need to implement the headerViewInstance() method and provide an instance of a OLSDynamicHeaderView subclass. This view must conform to OLSDynamicHeaderViewProtocol that consists in the following methods:

maxHeight() returns the maximum height allowed for this view.

minHeight() returns the minimum height allowed for this view.

resize(withProgress:) will be called when the user scrolls and your header needs to animate. `progress` goes from 0 to 1, 0 min height reached, 1 max height reached. This is probably the method you will be working the most to pull out a nice animation 😀

overflow(withPoints:) will be called when the user scrolls further the max height. `points` goes from 0 to N.

Cool! … anything else?

Note you can also inherit from OLSDynamicHeaderViewController directly if you do not want to use a UITableView or UICollectionView. The code of the corresponding helpers are there for you as reference of a base implementation 👍🏼

The sample code has a SampleHeaderView class that you can use (of course), but also have some basic math you may find handy for your header ideas!

Messenger apps are huge already

Granted, we also believe this, that’s why we are investing in building Kezmo, a customizable messaging platform that can be setup on premises, so Enterprises can get the best of both worlds.

Chatbots are going to be huge (yyuuuuge)

We believe that chatbots will play a major role in the future of human computer interactions, and yes we think they are going to act as the trojan horse for the arrival of artificial intelligence. Still, the hype around the subject does not quite match the fundamentals. I don’t on a daily basis use or interact with any chatbot. The people I know don’t. Every chatbot interaction I’ve had has been in the context of toying with a new technology. I have not adopted it in any scenario yet, and I don’t know anyone who has. So, while I’m bullish on bots, and Kezmo will serve as the foundation for the deployments of bots either the technology is not quite there yet, or otherwise

It doesn’t seem that far ago when free apps were able to generate hundreds of downloads per day just by the mere fact that they were free, and the app store was new. This dynamic is dead. If you are publishing anything to the app store, make sure to generate traction for it independently, relying only on the app store for marketing an app is not an option anymore, no matter how much app store search optimization time you put in.

Closing thought: are we comparing apples to oranges?

We can all agree the app store user experience is a mess, and both Apple and Google need to make changes asap to inject some life back in the app ecosystem. On the other hand chatbots seem like a promising investment despite imho the lack of true traction yet. To what extent are these two phenomenons related? Are we comparing apple to oranges?

What to expect from TC Disrupt

I see startup people. People, thousands of them. This 2016 edition had somewhere between 3000 and 4000 attendees. Most of them startupers. Fellow startup founders, desperate to be noticed, which sets the stage for a hard competition for attention. Beyond the numbers it’s important to stress the fact that you see people from all around the globe. TC Disrupt has country pavilions, as part of the Startup Alley which adds to the cosmopolitan vibe. It’s good if you want to get a feel of how your product resonates with different cultural backgrounds.

Venture/Vulture Capital. You will talk to some VCs representatives, and some VCs wannabes. The latter are dangerous as they can be tire kickers and will suck time and focus out of your brains. Be warned.

Tech Journalists. If you exhibit you get a list with a couple of hundred journalists that will be there. You can email/spam them with very low chances of getting a response back. You will get to talk to some of them during the event…but unless you either know somebody who knows somebody and can introduce you to a journalist, or if your startup is somehow related to one of the darling topics of the moment (this year it was all about AI & Virtual Reality) getting coverage will be pretty hard. So low expectations there, and start moving those connections, or talking to those PR agencies.

Students. Hackathon winners, university students, MBA graduates, you name it. They are not the majority but you will come across them. They will listen to your pitch with a lot of attention (maybe too much?) only to let you know later that they have just finished this career/course and are looking for a job. But hey, if you are running a startup outside the US. and are looking to expand your operations in that country it can be an opportunity, right?

Talks. If you follow the startup scene, you will notice that people you admire will be giving some cool talk. Unfortunately you won’t have time to attend to most of them. Unless there’s three of you tending to your booth, and you can just leave. For insance in this edition Neil Stephenson was signing books, and I loved Seveneves, but I really couldn’t make it. It was rush hour at the booth and before I noticed they day had finished.

Business Development Opportunities. Among the army of startups presenting you will come across some interesting companies. Competitors for once, but also startups whose business could be a good complement to yours, and it’s in these cases that you have an opportunity to discuss some kind of arrangement that may server both parties.

Interesting contacts. I came back with +50 business cards, of various degrees of relevance. There are probably 5 of them that could prove to be valuable contacts in the future. From other tradeshow experiences I was expecting to come back with more like 200 hundred cards. Maybe it was just poor hustling on my side, but those are the figures. On the other hand I know I delivered hundreds of my own cards, and was left without any by the second day.

Trends. You don’t have to be go to Disrupt to stay on top of trends, but it never hurts to be there and get a feel for what’s trending in the startup scene.

What NOT to expect from TC Disrupt

End users. Unless your end users are specifically startups, and startup founders, but even in that case, they will be probably too busy to pay meaningful attention to you at least during the event. If you expect people to hear about your product and register that same night you will probably be disappointed.

Enterprise. Large corporations do not have a big presence at Disrupt. With some exceptions that send R&D representatives to spot trends, most large corporations are just not there. So if you plan to connect with these type of companies, or if you are looking to connect with CIOs or CTOs you should start looking somewhere else, maybe the Gartner events?

Secured Coverage. In my opinion TC could do a better job at providing exhibitors better coverage. As an exhibitor you get listed in a lousy dynamically generated page that’s very hard to find & navigate. It does not appear in search engines, and where you are listed along with hundreds of startups within a collapsible accordion (I dare you to find Kezmo). For days I was expecting to have some kind of public url I could use in tweets or blog posts, if only to make a statement with local investors that our presence at Disrupt was real but what they provided arrived late and was pretty poor.

Final thoughts

Our previous experiences in tradeshows and conferences came from the Microsoft world, in SharePoint events, such as SPTechCon. In comparison that type of events are more enterprise oriented, have more CIOs & CTOs attending and offer a more focused audience for the type of products we develop.

In a couple of weeks I will know for sure if the event really paid off. For now it’s a close call.

We are proud to announce that Kezmo is finally available to the public.

Kezmo is an enterprise chat and collaboration tool for managing projects & teams. We believe one of the main problems with most enterprise chat tools is that everything is a message and after a couple of days of having a conversation with your team you forget what were the agreements, actionables and who owns what. Kezmo is a slack alternative that enables enterprise conversations while providing means to easily transition to more actionable structures such as: tasks, issues, notes, etc, that have their own life cycle and tools to interact and manage them independently.

We will be showcasing Kezmo to the world, in the startup alley, in the Uruguay pavillion. Kezmo is an enterprise chat and collaboration platform to help teams get things done. Yes, we too are trying to to kill email, but we will succeed were others have miserably failed. We are experimenting with visual ways to navigate contents which we believe is critical for handling and prioritizing large volumes of interactions.

Kezmo is available in the cloud or you can set it up on premises. It’s localized in several languages, which is not a minor thing when fostering adoption of these type of tools in the enterprise environment.

While Kezmo is still in a closed beta phase, if you stop by our booth we just might hand out an invitation to you 🙂

We are working hard, jumping through hoops and loops to have everything ready for the event. So if you are at the TechCrunch Disrupt please do stop by the Alley to say hi and get some of the gifts and surprises we are given out!

What is a Kanban board?

Kanban boards are a visual and intuitive way of laying out cards in a board, across different columns, in such a way that a team can collaborate in the management of a business process. Cards can be used to represent things that need to get done. This can mean an inventory item in a supply chain, or a task in the context of a project, or an issue that needs fixing in a product, or a client that needs to be visited. Kanban boards appeared in Japan as part of the Kanban system.

Kanban boards have become popular in software development, as part of agile methodologies that promote teams to focus on the work actively in progress as part of a sprint. Kanban boards are a very useful tool to visually represent knowledge about the state of the current activities. For instance cards representing tasks can go from a TODO state, to an In Progress, and then Done providing a very quick way to check on the status of each activity for the current sprint. Very useful in team management, and project management scenarios.

Starting point, basic html lists

So I started with an html like the following:

It looks something like the following image:

I styled the different lists with different backgrounds, and named the cards with different letters to make sure the elements are moving across columns. I also left the Done list empty to make sure the empty list scenario is also covered by the POC.

The question becomes then how to add behavior to this DOM structure so that users can move items from list to list.
After doing some JQuery research into draggable, and droppable interactions, I came across the sortable jQuery interaction, which can be configured to have connected lists. Awesome I thought! This covers points one and two, I just needed to confirm whether I would be able to listen to elements being dropped to be able to react to that event. Checking out the jQuery api documentation I could confirm it’s possible. I implemented a simple background color change on the item dropped event as a proof of concept.

I enabled the jQuery interactions with the following code:

With this I have requirements one and two covered. In order to add the ability to create new cards in the Kanban board I added an input text, and a button, with a corresponding jQuery click handler so that a new li element is added to the TODO list.

Conclusions & final thoughts

I was able to put this example running in very little time with jQuery. It seems to perform well in Chrome, and Safari while in Firefox the animation every now and then becomes a bit laggy as the number of cards in each column increases. HTML5 provides native support for drag and drop so there might be space to make a more efficient implementation doing without the jQuery layer, and assuming a bit more from the browser.

Email collaboration is broken, still to this date a lot of companies base their online digital collaborations on email. Typically for external collaborations, but sometimes even for internal ones. Even if it’s not THE technology sponsored for that end it coexists with a number of email alternatives in the organization, and it usually works as the fallback enterprise collaboration technology.

The good things about email

While a lot of people have been prophesying it’s death the truth is that email has some very good points going for it. It definitely has some advantages, such as:

It’s simple and widely adopted. It’s a very basic paradigm based on the notion of sending, replying and forwarding messages. Additionally it’s among the most widely adopted technologies of the internet. Everyone has an email address. So there are network effects at work here, an example of a technology whose value increases with it’s rate of adoption, and in this case almost every internet user has adopted so go figure it’s value.

It’s reliable and relatively inexpensive. Email messages arrive regardless of the distance involved, and setting up a mail server is a very documented procedure. There are several open source, and off the shelf alternatives, both on premises, and on the cloud.

It’s an open garden. Provided you have someone’s email address you can message with him, you don´t have to provide further personal information, there are no registrations involved, no setups, no hassles. While there´s a dark side to this, for beginners and spreading adoption is great.

It enables work/life balanced time management. In terms of managing expectations for turn around times common network etiquette allows you to wait a few hours, or even days before replying an email. It’s not real time. Plus you can turn auto respond for vacations. Point being that from a work/life balance and time management perspective it allows for a much needed wiggle room to put work stuff on hold.

What’s broken about email collaboration?

Among email shortcomings when it comes to enterprise collaboration are:

SPAM. The same open garden quality mentioned above enables strangers to contact you for whatever reason, such as trying to sell you something. It’s like a cognitive tax you have to pay to sort through all the messages you get to filter and categorize. It’s such an issue that a whole industry of spam filters was born to attempt to fix this problem, but at it’s core is still present. Anyone can pass along your email address to another stranger allowing them to contact you without your consent.

Email is really a bad fit for conversation type of interactions. Particularly among several people. Before you know it you have tens of unread emails, some of them which are one liners, with “Me too” responses and it can take really a long time before you figure out where’s the substance, or agreements that were reached as part of the exchange. It’s just not a good medium for conversations, and that sucks because team collaboration is to a good extent a ongoing conversation.

You don’t have confirmation of delivery and read from the other part. Unless the recipient is kind enough to reply with some form of acknowledgment message, the sender does not know whether the message has been read or if has fallen through the cracks of spam. Sometimes in corporate scenarios it’s not just a nice to have feature, but an audit level required by the business process.

It really is horrible for team collaborations and document collaborations. For instance if several people have to collaborate on document, it’s normal for everyone to send their version of the modified document, sometimes including previous work from someone else, but sometimes not. Leading to a number of email threads all with attached versions of the document in question. It can quickly become an nightmare to determine what’s the latest version, or what are the differences between these versions to consolidate everyone’s work.

Turn around time is awful for remote teams. It’s not real time, or close to. In some contexts, specifically for remote teams that are not in a call conference that requires constant interactions, but they are working on the same thing. It’s good to be able to exchange perspectives, and shoot quick questions and get a yes or no answer within minutes, in “close to real time’ time frames.

No support for complex types. Everything is a message. Why typing content is important you may ask. Well, different types of content involve different presentations, and enable different behaviors, and actions. Different types enable different life cycles. For events you need a reminder and will probably want to see it in a calendar. For tasks you will want to see who it is assigned to, it’s due date, and will probably need to be able to mark them as completed. For purchase orders you will want to approve them or reject them, etc. A lot of vendors have implemented applications attempting to attach, or meta morph an email message into something else, and had to cope with the fact that at it’s core that remains an email message which you can reply and forward.

The inbox as a sink for everything. The email inbox as the sink where all content flows no matter it’s nature can be a problem. Even if you try to have different email accounts for different purposes, you can only separate things so far. In most companies you will only get one email account, which will act as an inbox of all work related communications. Jokes from your workmates, with me too one liners, with important client exchanges are all in the same place. If the amount of emails arriving is high, it is a matter of time before you miss an important message. Because the platform does not make it easy to separate the wheat from the chaff, to separate the signal from the noise.

What’s next for enterprise collaboration? There has to be a better way

Well collaboration in the workplace is changing. A number of new consumer technologies have appeared over the past years which have generated different use patterns. While email is not dead yet, young generations are less ready to write page long emails and more prone to have spontaneous chat interactions. It’s the facebook, whatsapp & snapchat generation.

There’s a new wave of business applications that attempt to address this challenge by leveraging a conversation centric paradigm for collaborations in the workplace. Among them applications such as HipChat, and Slack.

We are building an email alternative of our own design. It’s called Kezmo, and it’s designed to achieve the best of both worlds. Conversation based (near real time) interactions while enabling good expectation management of turn around times. For instance providing feedback on whether or not a message has been delivered and read. Allowing users to structure content with different types, enabling different displays and behaviors for them.