Wan Yuee Low No Comments

Bot Making Tools – Syn Bot OSCOVA

This is part of a series of “Bot Making Tools Assessment” findings from my Choosing The Right Tools For Bot Making article.

Checkout the rest of the series by following these links:

My Findings

OSCOVA is part of Syn Bot Development Framework developed by Synthetic Intelligence Network.  This development company has been around for a while and their core business is built around providing intelligent automation of selected workflow using pure Artificial Intelligence.

My experience with OSCOVA was initially through a use case where the bot is used for Data Visualization based on excel sheet data (completely offline).  Check out the sample project here .

What I find interesting about the framework was it is .NET compatible and uses a markup language to build the bot intelligence (SIML).  Since I have spent quite a bit of time with Microsoft Bot Framework and LUIS earlier, it easy to understand how everything ties in when crafting the bot’s intelligence model.

If you have read the other three approaches of bot building (Chatbot Building Platforms, Facebook Messenger Platform API & Microsoft Bot Framework), you may notice that most of the “Artificial Intelligence” (AI) magic is done via cloud hosted services, and they have made available trained models to cater for common use cases.  It is also noted that English remains the dominant language for AI at the moment, with other languages gradually being added overtime by these platforms.

From my point of view, OSCOVA addresses the question – “What about uncommon use cases?”:

  • Bot brain that is based on certain language / domain terminology / specialized glossary?
  • Running experimental modals based on special rules / scenarios.
  • Devices with no / limited internet connectivity (e.g. on-premise security devices, mobile phones).
  • Learning how bot intelligence models can be crafted, for educational & research purposes.
  • Separately test the bot’s intelligence without worrying which channel the bot be hosted in.
  • When ownership of the bot intelligence modal is a top priority in the project or business.
  • Applying clear separation of concerns on the bot intelligence model.

The Syn Bot Development Framework comes with the “Syn Bot Studio” desktop application that developers can use to build these custom models and perform unit tests on the bot’s intelligence side of things.  The application is also packed with useful utilities such as a Regular Expression Tester and Javascript console.  The developer forums are also available for additional resources and like-minded developers in the AI domain.

Note that the developer still needs to spend time developing the actual interface for the end user to key in requests.  This could be a mobile or web application, or even Internet Of Things or speech recognition devices.  Connecting to a messaging channel would require additional technical knowledge of the connecting APIs and managing token issuance & API maintenance as well.

Use cases:

  • If you already have a .NET application and want to add some “intelligence” without the “strings” (online connectivity to cloud services), OSCOVA is a viable option because it has a relatively straight-forward API and decoupling of bot logic and business logic.
  • If you are feeling adventurous and want to learn something more advanced, and having ultimate control over how your bot should be thinking, then yes, OSCOVA provides implementation flexibility on the AI level.

A few caveats:

  • Looking up relevant resources via Google search may lead you to samples written for SIML 1.0.  Do note that OSCOVA uses SIML 2.0 (also known as SIML Modern) which is a different specification and elements.
  • SimlBot and OSCOVABot are two different libraries, with OSCOVA being the newer component with architectural difference (hence working with the newer SIML specification) & improved performance.  The developer may choose to actually use both to bridge any gaps in terms of features, but do take special care of memory utilization of your application especially on devices with limited memory.
  • Community Edition is Free (has core engine features and for personal projects). It’s a great option to go for to try stuff out.
  • Developer & Enterprise Licensing is available for full developer support via Email. You may want to consider this option for large scale projects.


Wan Yuee Low No Comments

Bot Making Tools – Microsoft Bot Framework

This is part of a series of “Bot Making Tools Assessment” findings from my Choosing The Right Tools For Bot Making article.

Checkout the rest of the series by following these links:

My Findings

Before continuing with this section, it would be useful to do a quick recap of the difference between a library and a framework .

Basically, Microsoft provides a set of libraries, tools and a portal to help the developer develop the bot.  They also have a pretty good set of design guidelines, technical documentation and sample projects .  So, for developers who prefer “cold steel programming tools” and need this kind of granularity, this is a good option, especially when they are already familiar with the Microsoft development platform and tools.  And guess what, since Microsoft being all Open Source friendly nowadays, NodeJS is also a very much supported preferred development language too.

An added bonus to developing on this framework is the ability to add Artificial Intelligence features by using the LUIS (part of Microsoft’s Cognitive Services).  Plus, if the developer choose to host the bot on Microsoft Azure, everything (including the AI services) are setup in 1 place with central monitoring of API consumption and resource usage.  It also the developer has less worry on service provisioning / API key tracking & hosting performance all round.

Bear in mind that Microsoft’s Cognitive Services actually consists of other nifty tools (Image Recognition, Text Analysis… just to name a few) that the developer can further explore to enhance their bot.  Click here to read more about Cognitive Services and what it has to offer.

Note that the developer will need some knowledge of:

  • Cloud Hosting services to deploy the bot, and setting up Artificial Intelligence services such as LUIS and/or other Cognitive Services.
  • Using the portal to register & publish the bot – the developer must have a basic knowledge on getting the necessary keys and tokens from each of the channels to deploy the bot to.  There are guided instructions on the portal so it is not difficult to follow through.

A few caveats:

  • Since it supports multiple channels, the developer should not expect the bot UI to be the same across different channels “pixel by pixel”.  The framework comes with a bot emulator that can help allows the developer to test “generic” versions of bot components, and that’s it.  It will not render the UI exactly how an end user would see it in the channel.  Check out the differences using the Channel Inspector .
  • This is similar to the problem for mobile developers when developing native applications on iOS and Android (e.g. the application bar is in different places – top or bottom).  Whilst it is still not too bad for mobile developers to “just standardize across the board with standard custom UI design”, for bot developers (unfortunately) this is not possible.  There is no “styling” layer as bot interactions are very tightly coupled with their host channels.
  • Another problem is also the fact that not every channel has the same set of bot components, although it is still possible to workaround this using the ChannelData property .  The developer would need to know the format of the payload of that channel’s component, which means digging through the relevant documentations from the channel’s documentations.

Suggested Use Cases:

  • e-Commerce (e.g. complex data flow and calculations)
  • Bots that have complex logic or flows that require session context / database backend
  • If you want to utilize LUIS or Cognitive Services from Microsoft, integration work is easier on C# .NET Platform.



Wan Yuee Low No Comments

Bot Making Tools – Facebook Messenger Platform API

This is part of a series of “Bot Making Tools Assessment” findings from my Choosing The Right Tools For Bot Making article.

Checkout the rest of the series by following these links:

My Findings

The official Facebook Messenger Platform API was launched on 25 March 2015 at F8 conference, and since then there has been a slew of online services catering to Facebook Messenger Bot Building.  All these online services connect to Facebook via the developer APIs (using REST protocol) and the development language of their developer’s choosing.  The documentation have improved a lot since version 1.0 .  At time of writing, Messenger Platform API is version 2.1.

The approach Facebook is taking with bots is a lot more aggressive and driven as they have a much wider and diversified use case & user base compared to Skype at time of writing (no surprise here, technically they are also Social Media Platform, and “not just a messaging channel”).  Judging from the way Facebook is marketing their Messenger Platform and recent acquisitions in Artificial Intelligence related companies (they acquired Wit.ai and has integrated NLP features within the platform), this is a very interesting space to lookout for as they will also likely be the ones to introduce something new and developers can sign up for beta provided certain conditions are met.

If you live on the bleeding edge and love to play catch with the “latest and greatest” from Facebook, this is the way to go.

Be warned, these developer APIs are very granular and in no way “a complete solution” to bot building.  The developer will need to plan and develop for “everything else” (API monitoring, Database connectivity).  The benefit of knowing the developer APIs well does pay off in the long run, especially when the platform is in the lead in the bot space.

A few caveats:

  • Bear in mind that the developer may need to figure out additional plumbing especially when it comes to session context / database backends, as they don’t really have a “do it all code library” like Microsoft Bot Framework.
  • Also, specifically for developers that are outside the U.S, there are certain features that are not available to the rest of the world unless “your business address is in the U.S. or your Page Admin is based in the U.S”.
  • The developer has to remember to request for specific permissions to use specific Messenger API platform features when the app is open for public use.
  • They have strict (and lengthy) policy and branding guidelines the web application must adhere to, otherwise any requested permissions will not get approved as quickly as it should. Especially for Messenger APIs, it is not just making sure it works and performant technically, the developer also needs to put some effort in the copywriting and user experience as well.
  • The developer will have added requirements for maintainability of code as Facebook may cease support for old API versions over time.
  • Compared to Chatbot Building Platforms, the developer has full control over the data and where the bot is hosted, and do not have to deal with external service imposed limits except for Facebook API.  It is clearly stated in their documentation that any usage of their Facebook API can be rate limited, and if the Facebook Page & App is found to have abused the API by not adhering to their policy (the big red marker here is broadcasting), they reserve the right to block the API request.

Suggested Use Cases:

  • Lead Generation, customer service & e-Commerce (simple followups).
  • Advanced / experienced developers has the flexibility to implement complex complex logic or flows that require session context / database back end given enough time and resources.  If time is not a luxury, then do consider utilizing Microsoft Bot Framework instead (click here to read my assessment) .


Wan Yuee Low No Comments

Bot Making Tools – Chatbot Building Platforms

This is part of a series of “Bot Making Tools Assessment” findings from my Choosing The Right Tools For Bot Making article.

Checkout the rest of the series by following these links:

My Findings

Currently there are many online tools that allows the developer to build chatbots very quickly (some claims that “you will be able to do it within 5 minutes”).  For example, just for the Facebook Messenger alone, there are 69 (and growing) Messenger Platform Development Providers .

Do note that the main aim of Chatbot Building Platforms are to abstract away the technical parts of building a bot, much like how CMS (Content Management Systems) like WordPress & Kentico does to abstract away the technical bits of HTML and CSS.

I picked ManyChat & Chatfuel (and tried it in that specific order as well) and it certainly was the best way to learn some of the basics of bot development, in terms of understanding the type of bot components available.  Chatbot Building Platforms usually play to the strength of certain parts of bot building / feature set.

  • ManyChat is more focused on broadcasting, so their analytics and tracking features are pretty good.  Building conversational flows is a little bit difficult because their builder UI is more geared towards broadcasting messages.
  • Chatfuel is a pretty good middle ground that caters for the possibility of integrations and have a much better bot building interface, however it still takes a few days to get acquainted to “how everything works” by going through samples and videos or checkout this Udemy course.

Casual users will appreciate that they have “pre-built” templates get started quickly.  When moving on to something a little more advanced, Chatfuel has “extensible” components / functionalities for integrations with third party systems.  For example, to send data to another system, the developer must have some knowledge of using JSON APIs of that other system.  This will be quite a common scenario as many small businesses use a multitude of online services (e.g. online storage, email marketing, information APIs) instead of having everything “under one roof”.

As for Artificial Intelligence, it is usually an option to be “turned on” explicitly.  In other platforms, it could be part of the features in the bot itself with no further setups from the end user.  Taking Chatfuel as an example, they have both their own AI and supports integration with third party AI – DialogFlow (formerly known as API.ai).

Another good thing about these platforms is that they have quite an active community base.  Both casual users and developers can easily find solutions on how to configure the bot for certain scenarios and get inspired by other creative ways to build bots.

Note that these platforms are hosted services.  They do provide both “Free” and “Paid” tiers, removing certain limits such as watermarking & number of bots the user can build & host.  It is also entirely up to the platform provider to ensure the quality of service and support.  Data is not as easily accessible, especially in cases for businesses in certain countries / domain that have issues with data being hosted “on a remote server that they do not own” or security reasons of “data not being in isolated data store”.

Suggested Use Cases:

  • Simple marketing and customer facing interactions such as lead generation, customer service & e-Commerce (simple followups), news broadcasting.



Wan Yuee Low No Comments

Choosing The Right Tools For Bot Making

An Assessment Of Bot Making Options

In this article, we will explore what exactly do we need to build a Chatbot from a slightly technical perspective.
Warning: There may be sprinkling of technical jargons in this article. As always, Google is always your best friend for further details and illustrated examples.

Introduction & Objective

First, a bit about myself. I am a software engineer who started off my career as a web developer.  Over the course of my career I built up skills in ASP.NET, CSS, HTML and JavaScript.  I do both types of development : front-end and server-side integration.  Therefore, my working knowledge with various tools and frameworks could be considered fair.  In the last 10 years or so, I have also experienced shifting development methodologies and trends.  Seen the rise and fall of various development frameworks due to rapid innovation.  Experiencing all that helps me to provide a unique assessment of the tools I have used before.

Good software developers understand that there is never a tool / framework that is a “one-size fits all”.  This is especially true when considering the use case and the projects that we build the solution for.  There are some unique problems that require careful consideration of what to use, and how to use it.  Otherwise, we might end up in a very difficult situation of not being “flexible enough” to scale or grow.  If you are in a leader position, there are also other things to think of, such as available team skill sets, how easy to learn / run with the technology, and where to find resources or get help when things get tough.

We are now stepping into the age of Artificial Intelligence and Machine Learning.  5 out of 10 articles on the techno-sphere are specifically talking about bots.  Or some variation of the word bot – “intelligent virtual assistants”, “automating ABC”, “smart XYZ” and how it is revolutionizing industries around the world.

So, what exactly is involved in building bots?

How is it different from the normal “code my business logic” way of software development?

Bot Building 101 (Technical Edition)

A bot is hosted on a channel (e.g. Facebook Messenger, Skype, Telegram, Slack).  User types a request to the bot, the bot responds with the right information based on understanding of the request.  Usually the channel forwards the request to a handler which will process what to do next.  Up to this stage, it sounds like a regular Webhook or Web API connection.

How the bot presents the information back to the user is using bot components.  Bot components are very much like the UI aspect of a conversation: text, images, audio, buttons.  Note that each channel provides a different set of components and options through their platform APIs.  From a web development perspective, it sounds just like a server request / response.  However, it is the expectations of what bots are supposed to be able to do that catch many software developers off guard.  (Hint:  It is more than “just presenting information” back to the user)

In fact, the tricky part here is that often the user’s request is expressed in human language.  The developer has to learn to deal with this apart from standard server formats (e.g JSON / any schema based request).  And here is the other part of the bot equation: Artificial Intelligence (e.g “how it understands the request”, or Natural Language Processing – NLP).  The “brain” of the bot does not just contain business logic, but also a (few) model(s) of “intelligence” of the bot.  Basic terminologies used in NLP – Intents, Entities, Session & Context is necessary to get things going if you intend to use one.

(Off-Topic : If you intend to invest a lot more time on the topic of AI, I would suggest to read  what is the difference between Artificial Intelligence, Machine Learning & Deep Learning first)

Soft Skills You Might Need

  • Understanding how to communicate concisely with words.
  • It would also help if you have a good command of English as most tools available today are English based.
  • It would also help to understand a bit of communicative UX and user behaviors to craft your bot’s intelligence model.
  • A clear understanding of the business context of what the bot is used for.

The Technical Bits

Some of my personal experience of building bots were using the following approaches:

Some might argue that ManyChat & Chatfuel are not exactly “cold steel programming tools” but I believe that as software developers, we should not discriminate on whether the tool is “hardcore matrix code” or “GUI based tools”.  The more tools we try, the more we understand how the concept works.  Once our mental model is in place, it will make more sense of what each tool offers in terms of functionality.  From then on, you can easily determine the fit for your use case and niche of users.  After all we are all in the business of building solutions to solve a problem.

Feel free to click on the links above to read my findings with each approach.


Below is a summary for your reading pleasure.

  • Chatbot Building Platforms (e.g ManyChat, Chatfuel)

    • Pro:
      • Great for simple use cases.
      • Great documentation and pre-built bot templates.
      • Uses JSON API for integration to external systems.
      • No need to worry about hosting or deployment.
    • Cons:
      • Developers do not have absolute control over the data and performance of the server.
      • If there is a need to do integration to systems that do not have a JSON API, the developer has to build the API themselves to connect.
      • Usually targeted to specific messenger channels.
  • Facebook Messenger Platform API using standard REST calls

    • Pro:
      • Access to the latest features direct from Facebook.  (Even when the feature is still in beta!)
      • Documentation and code samples are available.
    • Cons:
      • Developer may need to put in place REST calls monitoring within their application just in case.
      • Requesting the appropriate App Permissions requires a little more effort from the developer.
      • Strict Policy Guidelines on branding and usage of their API.
      • Not all features are supported worldwide (e.g. Payments).
  • Microsoft Bot Framework

    • Pro:
      • Supports multiple messaging platforms.
      • Integrates with complementary services such as LUIS and Cognitive Framework easily (setup, hosting, monitoring centralized on MS Azure)
      • NodeJS friendly
    • Cons:
      • Bot components are generic versions.  To use channel specific bot components, the Developer needs to know the specific channel’s API payloads.
      • Developer will still need to know how to generate access tokens from the channels to publish and deploy the bot.
      • The framework is currently in PREVIEW, so we don’t actually know how much it will actually cost to host yet when it comes out in GA (General Availability).
  • Standalone Framework – Syn Bot OSCOVA

    • Pro:
      • Markup based Artificial Intelligence modelling tool.
      • Support for offline devices since less dependency on Cloud APIs & Services.
      • Paid License for premium support.
    • Cons:
      • Developer has to implement the bot UI / channel / third party integrations.
      • Other online resources (apart from official website) might feature samples referring to SIML 1.0 instead of SIML 2.0 which OSCOVA uses.


So which should you choose for your first / next Bot project?  The answer is: IT DEPENDS.

Another consideration is the fact that each channel has a specific user base that your bot might want to target.  Hence, deciding on the final approach may not just be a pure “technical decision” after all…


To end this article,

“If you get stuck, draw with a different pen.  Change your tools; it may free your thinking.”

– Paul Arden

“I’m not saying being a comedian is brain surgery, but it is definitely – it’s like being a carpenter. You learn how to make tables and chairs. You have to have the right tools, and you have to know how to put the thing together, right?”

– Denis Leary


Kindly leave your comments if you like to read more articles like these.

Wan Yuee Low No Comments

Why Startups Need Software Engineers

Process of Engineering Your Software Product

This article will present you a likely startup scenario that happens from time to time, and this is something Software Engineers Malaysia should be aware of.  A bit of a disclaimer here, the author is not saying that this happens all the time and also any monetary and contractual bits are removed from the scenario so that we can focus on the product development itself.

A Typical Startup Story

In many tech startups nowadays, the story usually starts with a two-man team: a Domain Knowledge Expert, and a Software Engineer.  Both wants to build a Software and offer it as a Service on the internet.  In technical terms, we call this kind of endeavour a SaaS model.  There are many Software Engineers in Malaysia too, and most of them will know this story very well.

While this may be the easiest way to start and being human we all understand how easy it is to “get into the moment” and start building stuff.

So, the Software Engineer goes off, starts up his trusty machine and start hammering codes while being in the zone.  “Have to put these ideas into something that works”, “Have to put this icon here”, “Have to make sure the button works”, “Have to remember to feed the cat” etc…

Houston We Have A Problem

The problem starts when physical and mental limitations hit someone / everyone in the team, due to a multitude of reasons such as life prioritisation that results in someone pulling out of the team.  This can be especially very painful when it is a two-man startup because when either one pulls out, it really means a huge gap left unfilled, and your software becomes stillborn.

  • In the case where the Software Engineer who pulled out: maybe the option would be to get the source code from the developer.  Then find another Software Engineer to continue the work. However, sometimes it is it is equally difficult to carry on with another engineer’s work because of difference in thought process, technology stack and architecting idea. Ultimately what happens most of the time is that it gets rewritten from scratch, in a technology of their choosing, based on their understanding.  Cost: TIME.
  • In the case where Domain Knowledge Expert who pulled out: the value might still be there (from discussions), but it is equally difficult for the Software Engineer to carry on. Some prototypes may have useful bits of code that solves a problem, but no further value can be derived since no one knows the domain well enough to sculpt it in such a way that it becomes useful to the intended users. Cost: OPPORTUNITY.

In other words, the quality of your software product becomes questionable, although it is not apparent at the start.  This may also happen after the team gets additional funding, and you are ready to hire your second generation of developers to continue enhancing the software product.

Was Anything Documented?

A Software Engineer can come in many flavours.  Some are meticulous in making sure at least the code is functioning properly.  But it is quite subjective as to whether they use source control and making sure there are available code documentations logged for every source code change?

A Domain Knowledge Expert may know the story from the top level, and know generally the use cases & screens that require which specific functionality.  That knowledge is only a hint towards the technical implementations of the Software, and may not be indicative enough on whether a code update will impact any parts of the Software.

Lack of transparency in the development process puts your business at risk.  A couple of questions to ponder:

  • How will they train the second generation of developers on how to ensure the software does not lose the level of quality promised to the prospects / investors?
  • How will they train support staff to manage customer service?

The conclusion is: Software Quality is often not just the “what you can see” part, but rather “whether it is maintainable” parts as well, if a startup is serious for the long haul, it’d better be ready for the ride ahead.

The team should be able to understand the inner workings of the software product well, and able to improve the software product over time.  And being human, there is only a limited number of things a person can keep on their minds at any one time.

Ever wondered how to be able to recall the details when it matters?

The Right Way to Start

Every software project has to start with source control, PERIOD.  This establishes a comfortable area of transparency where both team members (and subsequently when your team gets larger) will get a bird’s eye view on what is happening to the software product.

Fundamentally, we recommend these basic steps to get started, click on each link to find out how using Visual Studio Team Services (this service is FREE) can help you streamline your startup software development easily.

  1. Write down what the software actually does and what problems it aims to solve.
  2. Get your developer / software architect to break down all functionalities.
  3. Estimate what to build and when to build it.
  4. Get users or customers to test your product.
  5. Marketing your product.

I hope this article gives you some insights as to what almost every software product based startup should go through before turning a profit.


To end this article,

“You’ll never get it perfect the first time, but starting somewhere will force you into an iterative cycle of improvement.”

– Luisa Santos, Founder of Lulu’s Ice Cream


Kindly leave your comments if you like to read more articles like these.