Wednesday, September 13, 2017

Machine Learning Madness


The hype around machine learning and AI is just off the charts these days. This reminds me of several years back when just about every software product started putting the term "Big Data" in front (or at the end) of all of their product literature and company tagline.

Today startups are claiming to change every industry and the world because they got "machine learning" inside their products.

Listen, I am just as excited as the next geek about the potential of deep learning and the democratization of data science, but please stop putting machine learning in your company's slogan, like it was the secret ingredient that you were looking for. Sorry, this is becoming my new pet peeve.

ML, at the end of the day, is just one more tool in our arsenal to build more efficient and more intuitive solutions and services for our customers and for humanity as a whole.

Please talk about the benefits of using AI/ML/DL, don't just say "because you are using machine learning" you are changing the world or have a better product. There is that little thing called building a product that delivers value to the end user that you still have to get right. And believe it or not, this still requires human creativity and execution. Claiming your infusing your product with ML will not necessarily make it a better product or the world a better place.

I do believe that machine learning related technology will be in every future product, just like we have transistors in every computer today. Machine learning will allow us to build better and more efficient products. How you use the machine learning to build a great product will matter much more than the fact that you are using machine learning. Keep that in mind when you come up with your next startup tagline and company slogan!

End of rant.

Monday, August 28, 2017

AI vs Paradox of Choice


The paradox of choice is a problem we see more and more of in our modern world. It goes beyond what products Amazon should recommend or friends Facebook should suggest. In the business world and in enterprise applications this is also a challenging problem as our applications and processes grow in complexity. The potential for machine learning powered recommender systems to augment human decision making is one of the next frontier for AI in the enterprise . 

Recommender systems can do more than just suggest what articles you should read on Linkedin or what jobs are most suited for you. In the future machine learning (and more likely deep learning) powered recommender systems will guide enterprise decision making by helping business process owners take the most effective actions and decisions in a timely manner and with hyper-personalization. 

Recommender systems will move from solving B2C optimization problems (how they are typically used today in our data saturated and over marketed world) to solving problems in B2B and enterprise applications. Ultimately recommender systems are about prescribing (they are not really about predicting) an optimal decision at the right time and place/context, so they can naturally deal with a variety of B2B scenarios such as optimizing workflow paths, streamlining supply chain actions, to augmenting human decisions for common day to day business operational functions. Enterprise decision makers are in vital need of these AI super powers. Stay tuned they are coming :)

Sunday, August 20, 2017

Messaging-First Applications with Slack or FBM?


Conversational UX design is evolving as more and more apps begin to incorporate conversational UI functionality. While the concept of a messaging-centric UI can seem simple, the melding of a messaging-first user experience is nothing to underestimate. Conversational user interfaces can be simple for humans to interact with (you are just chatting back and forth), however, blending in and balancing rich visualization and complex interactions is not simple to get right. Just like any other UX, it is a balance of minimalism while allowing for rich expressiveness in the UI without overwhelming the user.

Slack is one of the leading platforms for building bots, especially for enterprise applications. However Slack has a number of bot conversational UX features that are still missing relative to other platforms such as FB Messenger and FB Workplace.

To give some perspective, here is my compiled list of features I would like to see in Slack's bot framework to improve its messaging UX and bring it on par with platforms like FB Messenger:

1) Conversational Streams and UI Alignment

Slack bots (especially in direct-messaging one-on-one dialog flows) force the bot and the user to both be left justified in the messaging UI stream. This goes against UI norms found in the majority of messaging application and related best practices for messaging apps. Typically in a streaming messaging flow, your conversational stream (you being the person interacting with the bot) is on the right of the screen and the party you are talking to (in this case the bot) is on the left side of the screen (or it can be visa-versa).

This is something not supported in Slack and makes a number of things awkward and cluttered in a bot-to-human dialog, especially when it is one-on-one (as opposed to Slack group channel). In Slack the entire conversational interaction is left justified, which can make the UI look cluttered when there are visual rich elements involved and and things like "Quick Replies" in the back and forth stream.

I hope that Slack will allow for aligning the bot vs the user on different sides of the messaging stream, something more similar to how FB Messenger works. This will allow for a more natural conversational interaction.

2) Horizontal Scrolling Carousel UI Components

Slack (mobile and desktop/web) does not provide any kind of horizontal card or horizontal scrolling carousel. While some might consider this bad design (to allow for horizontal scrolling of cards), it is often necessary to minimize the vertical area needed to display information in rich messaging interactions. FB Messenger allows for limited horizontal scrolling carousel that I find to be very useful when building bots. Hopefully Slack will incorporate this. Slack already supports rich "attachments", so it would be a natural fit to allow for some limited level or horizontal scrolling.

3) WebView Integration

Slack does not have explicit support for messaging buttons that open a webview UI. Sometimes a webview is needed to show rich web content (again here this kind of feature should not be abused). FB Messenger has this ability and allows for controlling how the webview window is opened and closed. This can be mimicked in Slack by using embedding links in the "field" elements for example, but is a bit of a hack.

4) Quick Reply Buttons

One particularly nice feature I got accustomed to using in Facebook Messenger is the feature referred to as "Quick Reply". This allows the bot to display "Quick Reply" buttons that are shortcuts for the user to enter commands that they would normally have to type.

There is a away to mimic quick replies in Slack, but again it is a bit of hack. Check this open source node/slack project for an example of how this works with Slack. Quick replies are a real necessity in a rich messaging interaction. Again here, I hope that Slack adds this feature natively instead of making bot frameworks jump through hoops to emulate this feature.

Hopefully the Slack product team will address these issues as Slack is by far the best team and enterprise collaboration/messaging platform on the market today.

FB Messenger might have some superior bot-to-human interaction and UX capabilities, but it inherently lacks the team collaboration functionality and the many third-party integrations that Slack has to offer.

I do believe FB Workplace will close the gap over time, and in many ways has advantages over Slack in terms of out of the box social collaboration functionality. Slack is a bit of geeky technical tool when it comes to social collaboration and thus not as intuitive to use.

I expect both FB Workplace and Slack to evolve as head to head competitors and battle for the hearts and minds of developers much like how Netscape battled Microsoft's Internet Explorer for web domination. For enterprise owners and enterprise end user, intelligent AI endowed virtual assistants and bots will usher in a new era of innovation not seen since the dot-com days. The battle has moved from the mobile app store to the AI app store where natural language understanding and deep learning are the killer technologies in the arsenal of AI sophisticated developers.

Thursday, July 13, 2017

Augmented Reality vs Conversational User Interface



Don't believe all the hype about virtual reality and its close cousin augmented reality. How many examples do we need to see before we get it that humans don't like a big gizmo sitting over their faces and eyes or attached to their body. Examples like the failed Google Glass and the failing Facebook Oculus are two examples of such failures, with more on the way if Apple is not careful.

What will win out? It's all about texting and voice stupid (not you). AI is surely coming, but it will be powered by voice-first and messaging-first applications and services. Visual augmentation with AR and VR, is cute, but it will not be what transforms our reality and changes how we interact with technology.

Humans are social animals and voice and texting is what taps into that part of our brain that drives us to connect with others/things and drives us to share ideas. So gear up and start thinking how to turn your applications and services into voice-first and messaging-first user experiences. That is where the future is going.

Monday, June 26, 2017

Conversational Bot UI Features Missing in Slack


Conversational UX design is evolving as more and more apps begin to incorporate conversational UI functionality. While the concept of a messenger-centric UI can seem simple, the melding of a messaging-first user experience is nothing to underestimate. Conversational user interfaces can be simple for humans to interact with (you are just chatting back and forth), however, blending in and balancing rich visualization and complex interactions is not simple to get right. Just like any other UX, it is a balance of minimalism while allowing for rich expressiveness in the UI without overwhelming the user.

Slack is one of the leading platforms for building bots, especially for enterprise applications. However Slack has a number of bot conversational UX features that are still missing relative to other platforms such as FB Messenger, for example. Here is my compiled list of features I would like to see in Slack's bot framework to improve its messaging UX and bring it on par with platforms like FB Messenger:

1) Conversational Streams and UI Alignment
Slack bots (especially in direct-messaging one-on-one dialog flows) force the bot and the user to both be left justified in the messaging UI stream. This goes against UI norms found in the majority of messaging application and related best practices for messaging apps. Typically in a streaming messaging flow, your conversational stream (you being the person interacting with the bot) is on the right of the screen and the party you are talking to (in this case the bot) is on the left side of the screen (or it can be visa-versa).

This is something not supported in Slack and makes a number of things awkward and cluttered in a bot-to-human dialog, especially when it is one-on-one (as opposed to Slack group channel). In Slack the entire conversational interaction is left justified, which can make the UI look cluttered when there are visual rich elements involved and and things like "Quick Replies" in the back and forth stream.

I hope that Slack will allow for aligning the bot vs the user on different sides of the messaging stream, something more similar to how FB Messenger works. This will allow for a more natural conversational interaction.

2) Horizontal Scrolling Carrousel UI Components
Slack (mobile and desktop/web) does not provide any kind of horizontal card or horizontal scrolling carousel. While some might consider this bad design (to allow for horizontal scrolling of cards), it is often necessary to minimize the vertical area needed to display information in rich messaging interactions. FB Messenger allows for limited horizontal scrolling carousel that I find to be very useful when building bots. Hopefully Slack will incorporate this. Slack already supports rich "attachments", so it would be a natural fit to allow for some limited level or horizontal scrolling.

3) WebView Integration
Slack does not have explicit support for messaging buttons that open a webview UI. Sometimes a webview is needed to show rich web content (again here this kind of feature should not be abused). FB Messenger has this ability and allows for controlling how the webview window is opened and closed. This can be mimicked in Slack by using embedding links in the "field" elements for example, but is a bit of a hack.

4) Quick Reply Buttons
One particularly nice feature I got accustomed to using in Facebook Messenger is the feature referred to as "Quick Reply". This allows the bot to display "Quick Reply" buttons that are shortcuts for the user to enter commands that they would normally have to type.

There is a away to mimic quick replies in Slack, but it again, it is a bit of hack. Check this open source node/slack project for an example of how this works with Slack. Quick replies are a real necessity in a rich messaging interaction. Again here, I hope that Slack adds this feature natively instead of making bot frameworks jump through hoops to  emulate this feature.

Hopefully the Slack product team will address these issues as Slack is by far the best team and enterprise collaboration/messaging platform on the market today.

FB Messenger might have some superior bot-to-human interaction and UX functionality, but it inherently lacks the team collaboration functionality and the many third-party integrations that Slack has to offer. Perhaps FB Workspace might have something to offer down the road, but it has a long way to go in order to catch up with Slack.

Tuesday, June 20, 2017

Building Slack Bots with Node.js

There are a number frameworks for building Slack bots such as botkit and beepboop. But sometimes you just want to use the native Slack APIs and build your bot without the added burden of a complex bot application framework. If this sounds like what you are looking for, then you have come to the right place.
This project demonstrates how to apply the essential Slack APIs using the keep it simple principle and a straight forward approach to extending and customizing your bot's conversational dialog and interactive UX (interactive buttons/menus).
Slack has an extensive set of APIs for building user-to-bot conversational UI and interactive messaging applications. This project implements a bare minimal bot application written in node that provides a template for integrating with the various Slack APIs. This is a starting point application for building your bot that can be thought of as a basic modular template and set of coding patterns for building a Slack bot that exercises the essential Slack APIs and bot interaction features.
Support for api.ai is included for demonstration purposes, but other NLP services can be used instead.
The focus of the project is to make it easier to implement NLP intents and conversational bot/user interactions and the associated UI interactions that might come about from the use of Slack attachments (such as Slack interactive message buttons and interactive message menus). Adding new NLP intents and handling the callbacks for interactive UI elements are demonstrated in this basic bot. Examples for using incoming webhooks and slash commands are also provided.
The hope is this project will make it easier to start building a Slack bot by providing a template on which you can extend your bot with new dialog/conversations and interactions. The coding patterns will hopefully make it easy to extend the conversational user interaction when building your bot.
By design, this bot uses the Slack Event API and avoids any use of the Slack RTM API.
Note, that this bot was not designed to work with Slack Enterprise Grid. Some minor modifications would be required to have it work in a cross team enterprise environment.
Slack APIs demonstrated in this bot application:
  • Event API (subscribes to: "message.im" and "reaction_added").
  • Sending Text/Attachment/Interactive Messages via channel reply.
  • Sending Text/Attachment/Interactive Messages via Incoming Webhook.
  • Handling Slash commands.
  • Handling Interactive Message actions.
  • Handling oauth.access to store and use bot access token.
In addition to the core Slack REST APIs, this app demonstrates how to use the following slack wrapper APIs:
  • @slack/client
  • @slack/events-api
  • @slack/interactive-messages
  • @aoberoi/passport-slack
Give the GitHub project a spin. Hopefully you will find it a good starting point for building Node native Slack bots.

Wednesday, June 14, 2017

Python Data Science and Machine Learning Stack

If you ever wondered how the whole Python Data Science and Machine Learning stack all fits and plays together (Numpy, Scipy, Pandas, scikit-learn....)


Friday, March 10, 2017

The Rise of Cloud ACID Databases



Cloud Spanner and AWS Aurora among others are promising traditional RDBMS capabilities with cloud scale-out (does not mean cheaper btw).
Here is interesting article comparing Cloud Spanner with its inspired open source offshoot called CochRoachDB.
Somewhat established niche SQL scale-out contenders like Clustrix, MemSQL VoltDB and NuoDB are getting more competition than they can handle Smile :)

Monday, February 27, 2017

Stop Calling Them Chatbots


I generally agree that the chat and NLP capabilities of a chatbot should not be seen as an end unto itself. Voice and text/messaging skills are just tools for reducing the friction between the end user and the device/application.

GUIs will go the way of the Dinosaur

For the last 30+ years we have seen graphical user interfaces grow in visual richness, but this is an evolutionary dead end. The future of human-to-device interface is Streaming-UI applications. Visually fixed and structurally static GUIs are the past. The future will be dominated by applications that "stream" a conversational conscientiousness and user experience using a fluid mixture of text, voice and point and click widgets/controls.

A Future of Streaming User Interaction

We need to stop calling the new crop of intelligent applications "virtual assistants" and "chatbots" - they are Streaming-UI applications that blend voice/text/point-click with a good dash of AI, NLP and other related technology. They are not rigid or fixed, instead they are streaming across the screen and across conversational time. So stop calling them "chatbots". They are Streaming-UIs and they will need a whole new way of thinking, development/design skills and tools to build them well. The user experience and application building rules have changed.

Sunday, December 25, 2016

The Death of Visual Analytics and the Dawn of Conversational BI


In the last several years we have seen the emergence of a new breed of business intelligence products that have made it possible to build highly interactive and visually expressive and rich dashboards and reporting experiences. Products like Tableau, Domo, and Looker to name a few are replacing established BI heavyweights with a focus on self-service and rich visualizations.

What is driving this trend? Well anyone not living under a rock for the last then years will tell you that the explosion of data on the internet coupled with the advancement in Big Data related technology have made storing and accessing data much easier than ever before. But this alone is not the whole story.

Self Service BI is Good but not Good Enough

Products like Tableau have come onto the seen to lower the barrier for connecting to internet accessible data sources and as well to traditional sources locked up in relational databases and in the billions of excel spreadsheets sitting around the enterprise world. Driven by this, Tableau, for one, has been successful for three primary reasons:
  1. Provides many out of the box data source connectors with an easy to use interface - connect to just about any data source.
  2. Self service analytics without some of the heavy lifting - you don't need an army of data and tech experts to model your data and meta-data.
  3. Highly compelling and visually rich analytics features - the visualization you can create with Tableau are stunning - not always easy to do, but much more achievable than ever before.
So this is all great, but what does this have to do with the death of visual analytics? I seem to be saying richer BI visualization is blossoming and inspired by tools like Tableau. Well, I will argue that item number three listed above is an evolutionary dead end and that are going to see a gradual trend away from visually rich analytics.

There is such a thing as too much of a good thing. More visualization does not mean you are solving business problems more effectively, answer questions faster, finding root cause (answering why questions), or getting better predictions and trends? In fact ,too much visualization might be overwhelming users.

A Stroll Through BI History

Let's take a quick ride back in time before we look forward. Human civilization has been evolving for thousands of years and our way out of the stone age was guided by the development of human language and communication. While it is true that a picture can say a thousand words, the spoken or written word, on the other hand,  can express all of human existence in short phrase, e.g "to be or not to be" or "I love you". Human expression through words is powerful - more powerful than any picture.

My point is that human communication is the most powerful expression and exchange of information. It is a fact that visualization is a powerful tool, but it pales in the presence of the written or spoken word. You can probably guess where I am going now.

Computers and computer to human interfaces have evolved over the past sixty or so years on a twisted evolutionary path. We started with simple command line tools and interfaces (mainframe), where we issued simple grunting commands and got back simple grunted responses from our computers. We then saw this lead to the evolution of rich graphical computer windows, icons and the mouse (point-drag-click). While this helped advance our interface and interaction with the computer and with extracting data from within these artificial devices, this path of human to computer interaction is effectively an evolutionary dead end. It pales in comparison with what is coming next.

Evolving Toward AI Conversations - More Than Pictures

Products like Tableau, Looker and others will need to evolve in the coming years or be left in the dustbin of technology. While we have seen amazing advancement in rich and interactive visualizations of data, I argue this is the wrong path and effectively an evolutionary dead end. How many times have you looked at Tableau dashboards (or other BI visualization) and saw beautiful and rich colors, shapes and graphics only to be overwhelmed by the information? What does this information mean, what does it tell me, what questions and answers are buried in this beautiful and rich visualization?
Tableau: Endangered Safari Animals
What if instead of being bombarded by visualization alone, you can converse with the data - converse with the machine? Having rich visualizations can be fantastic, but I would want to ask the machine to answer questions about the visualization - make predictions or tell me "why" this is occurred - point me a the root cause. We are moving to a new dawn where machine learning and AI will help us make sense of the information around us that that is currently locked up and visualized by computers. And this requires a new way (back to the future) for humans to interact with BI.

While computers started out as simple command line beasts, our current evolution toward more and more visualization is an evolutionary dead end. We will soon be moving toward a voice and messaging first world - where visualizations will augment our experience of information and are a tool for us to engage in conversation with our AI powered BI applications and virtual assistants. Chatbot BI virtual assistants are on the horizon.

More Than Just Looking Pretty - Answering Questions

You can see the beginning of this already. Tableau recently announced they will be releasing, in 2017, a new NLP interface to their platform - competitors will follow - and this is only the beginning. We will one day be able to ask questions of your BI in natural human language. The AI powered analytics revolution is coming. Conversational interfaces are a game changer for BI. Analytics as a conversation will no longer be the stuff of movies and sci-fi.

Driven by the advancement in AI and machine learning and with the massive surge in adoption in virtual assistants, chatbots and messaging/voice applications, the future will be here sooner than we think.

Tuesday, November 1, 2016

Thougtht Experiments are not Agile

 
Agile methodological such as Scrum are the rage these days. They have helped organizations achieve some perceived control over delivering projects on time and managing the overall scope of projects. In most cases when waterfall or agile processes fail it is the failure of the organization in managing expectations and not necessarily in the processes that were used. I think everyone can agree on that.

This blog is not meant to be a bashing or endorsement of scrum, waterfall or any other project  methodology. Personally, the approach I usually prescribe to is that you do what you say you are going to do and that your processes (whatever they are) are repeatable and are well understood by all in the organization. And from one release to the next you work to make your process better. End of story.

Now having said all that, lets get into what I really want to talk about. What kind of methodology inspires and nurtures the best and most innovate design work (software, UX or any other creative design) and ultimately leads to the best products and systems being built? No surprise that the answer has nothing to do with whether you are using agile or waterfall or with how much analysis and design documentation you generate. The answer instead has everything to do with tapping the human imagination.

The best designs and products don't come from a process of painting by numbers. You can break down a user story into as many tasks as you like (in your favorite scrum tool) and you can have "spikes" that lead to other user stories and build POCs until you are blue in the face, but this does not lead to creative or ground breaking results. What does? Well, if we look back at some of the greatest designs from the amazing works of such people as Archimedes, Galileo, Newton, and Einstein, these great minds had something in common. They conceived of many of their brilliant works with thought experiments.

I argue that great design can't be prescribed into design documents or crafted from user stories. The best and most innovative designs come through thought experiments. Then once you have the outline of a concept in your mind you can runoff and start coding and crafting your ideas and attempt to let them take form. There is nothing like immersing yourself in deep thought over a problem. Few of us can claim to be at the level of brilliance of an Archimedes, but thought experiments are the path to brilliant work, whatever discipline you are in. I don't want to diminish the value of hard work and having good team discipline, but innovative designs are best done deep within mind experiments. Only in your mind can you think big while juggling all the variables and constraints, yet aiming small on your target and balancing all the parameters and dependencies that your problem and solution domain demand. No great design document or architectural blueprint will come to shape without this, if it does, throw it away and start over.

So when you are sitting in your next sprint planning meeting, see if you can carve out a few user stories for some thought experiments. You might just deliver on some of your best work :)

Tuesday, October 25, 2016

Goodbye Apps and Hello Bots


The shift in the market is undeniable. Bots are beginning to challenge the established mobile app store ecosystem. There is plenty of evidence that mobile app adoption has plateaued and that the average user has lost their excitement for downloading and experimenting with new apps. There are more than 2 million apps in the Apple app store now! Ask the average mobile developer - it is almost impossible to get your app noticed or discovered in such a crowded space. Apps will always be with us, much like desktop applications and the company website, but there is a sea change.

Disruption and the New Players

It is becoming clear that jumping from one mobile app to the other is not a great experience for most users (especially for enterprise users) and this is giving messaging apps like Slack and Facebook Messenger the opportunity to become the new app/bot marketplace. GUI-less bots are more easy for users to transition from and to, and they make it seamless to switch between bots and more natural to interact with an application service using human like conversation (something people are already doing in droves on messaging apps). These bots are basically mini-apps with conversational interfaces. Slack (for the enterprise) and FB Messenger (for consumers) are both becoming the new application playground; and the promise of an AI enabled world is lurking within them to provide a user experience that traditional GUI apps are not capable of.

Microsoft is chasing Slack (using Skype) to establish itself in the enterprise team messaging market and in this new emerging bot marketplace. For Microsoft, this is obviously an opportunity to disrupt the mobile app market (where they have lost) and establish an early beachhead with bots, AI and enterprise team communication. Microsoft has clearly been leading the charge with products like Cortana, LUIS and their Bot Framework. All the other big players are in the bot and AI game as well, and the race is definitely on for who can deliver the best bot solution for developers. There is a new land grab in the making between the big tech giants, developers and startups.


How Do I Deliver My Bots?

I describe all this because to deliver conversational applications (aka bots) to end users, developers need a platform and a bot marketplace. Messaging apps will be that vehicle to supplant the traditional app store ecosystem, because building your own custom bot infused mobile app will not be the way to go for most developers in the future. Building a custom mobile app for your bot might still be possible in some situations where an app already has an established user base - like a banking app - but for the average bot developer messaging apps, like Slack, will be the delivery platform.

Messaging apps like Slack also offer a lot of out the box backend integration to help deal with single-sign-on, identity management, permissions, roles and executing custom business logic (via webhooks) for backend integration. Apps like Slack provide much of the platform plumbing for this backend integration that your bots will need, and enterprises are already adopting team messaging apps like Slack. This all lowers the barriers for connecting your bot to a companies cloud and back office systems, in order to get access to the necessary the data and enterprise systems.

Messaging & Voice First Applications

I think the future model for developers will be to deliver their bots and AI conversational services through tools like Slack and possibly others popular "platform messaging apps" such as Cisco Spark, HipChat, Fowdock, FB Messenger, Skype, Kik, and others. All these messaging centric platform apps are already spreading fast through the corporate and consumer world. Developers will be leveraging these messaging platforms to deliver their AI services in the form of bots and conversational user interfaces . Mobile app stores will always be with us, but the game is changing. The new AI marketplace is happening now, get your bots ready!

Friday, October 7, 2016

Bots, AI and the Future of Augmented UX Design


We hear a lot these days about technologies such as futuristic looking VR goggles and mobile apps with augment reality that enhance our interactions with the physical world using a computer generated reality that overlays and assists in our interpretation of the world around us. As computer users, have become accustomed to rich visual interfaces as desktop, web and mobile app technologies have matured. However, the next leap forward in human-to-computer interaction will not be more visual effects, but in fact less, and we are seeing the beginnings of this shift in what we refer to today as "bots". This is only the beginning of a seismic shift in how we as end users interact with applications.

GUI Alone is Not Enough

Now, what if we could have the same augmented reality type experience applied to the countless GUI applications we all deal with on a daily basis both at work and at home and from desktop to mobile? What do I mean? Computer applications are already computer generated, so why do they need an augmented reality? Yes that is true computer/mobile applications are already based in the virtual real-estate of the computer (or mobile device), but why do we need any augmented assistance while dealing with the computer application

GUIs are Not Natural

If you reflect carefully on what is happening with bots and AI in type applications in general, we are seeing the creation of a new human to computer mode of interaction that can assist us in how we interact with the virtual world of the computer application. The dumb and boring old computer or mobile application screen is about to get a big dose of intelligence! Having an intelligent conversation with your application (not just mouse clicks and keyboard taps) will become the norm and is not just the thing of science fiction. Note, this bot/AI augmented application does not necessary have to voice converse, have a personality or hold a deep philosophical discussion with us (maybe some day), but it will be able to assist us in our current world of application beyond just the visual windows, buttons and menu options we have today.

We have come accustomed to interacting with our computers using an already mature human-to-computer model of clicking on buttons and visualizing our experience with a computer through drop down lists and dialog boxes among other widgets and interfaces. But what if we could augment our interaction to a consumer application (i.e. banking app) or an enterprise application (i.e. supply chain application) with a  an intelligent chatbot that could aid us in the interaction with said application and the many knobs, controls and actions you can invoke on the application screen? This bot assistant could remember what we have done in the app in the past and guide us through taking actions using a combination of chat/message exchanges sprinkled in with intelligently timed suggested actions. This could in fact lead us to to a situation where we do not needed the full blown array of buttons and menus that bloat the apps we have today. We could have a conversation with the application with the help of an intelligent and conversational chatbot assistant.

The Shift to CUIs is Unstoppable and Inevitable

Well this is where the world will soon be fast moving towards. With the ubiquity in mobile communication and advancements in machine learning, AI and big data, the scene is now set for every application we have come accustomed to using to have a chatbot assistant that can aid us in our interaction with the application itself. No more stupid dark ages style help documents to sift through. Think of it as online docs help on steroids and this just the beginning.

Any enterprise or consumer application team not starting to think how to they can replace their outdated online help docs and bloated UIs with more efficient and engaging intelligent and interactive chatbot assistance will be left in the dustbin of technology history. Don't worry you have a few agile sprints before this happens :)

This transformation is not to be taken lightly although. It will be a significant investment of both engineering/technology and a big leap in thinking in how we design user experiences for end users and how we can expand the visual application metaphors we have grown accustomed to with new intelligent chat assistants that can guide us through the navigation of information and assist us in the potential actions that can be taken within an application.

Evolving your Development Processes for CUI

This technology leap will require a big shift in thinking from product owners, UX designers, information designers and engineers. This will require everyone in the product development ecosystem working together using enhanced business and engineering processes that put this new augmented UX design philosophy in the forefront while on the engineering side leveraging fast maturing technologies in the areas of NLP, AI, and machine learning to enable captivating and predictive conversational engagements between humans, their devices and their applications.


The applications of the future, whether on your desktop or on your mobile device, will in the coming years begin to manifest augmented UX capabilities. Be prepared for this new world whether you are a developer, UX designer or end user of these applications. Conversational interfaces are coming to an application near you to augment and enrich your application user experience!

Sunday, October 2, 2016

What's Next? Conversational Enterprise Applications


There is a lot of chatter these days (excuse the pun) around AI, machine learning, and chat bots and how this technology stack can be used to engage with users, at a human like level, to exchange information and automate tasks. The elusive goal of an all intelligent AI machine that can by indistinguishable from a human to help us with day to day tasks has been with us since the Turing test and has been embedded in our psyche from countless sci-fi movies.

Bots Here and There and Everywhere

Today, that elusive goal is closer with the many advancements in computing and communication technology. We are starting to see the real application of such technology in tools like Slack where chat bots sit in the background ready to engage in channels/rooms to assist and respond to natural language chat communications to help solve/automate DevOps tasks or monitor and manage IoT infrastructure among many other applications. And we also see it with more casual consumer applications like Siri, Cortana and Alexa.

Where this is all headed is exciting both for consumer and enterprise applications. However a lot of the current focus for how and where conversational interfaces can be applied is still stuck in the past. In my opinion there is too much attention given, for example, to a chatbot's personality and if that chat bot is behaving with true human like mannerisms. I think this distracts from the actual transformation that is happening and the opportunities that lie ahead for where and how conversational interfaces can transform business applications. A conversational interface does not necessary need a human personality to be effective - keep that in mind when you go down the path of building this new form of user experience into your applications.

The Smart Command Line Interface

If we look back in time, we started first with "dumb" computer command line interfaces (i.e. the green screen CLI), then through the 80s, 90s, and early apart of this century we went through a steady evolution toward more visually rich human to computer UX (think desktop apps, web X.0 and mobile). Interestingly enough, this has brought us full circle and back to the command line interface (CLI). But this new CLI is now "intelligent" and has the potential to take us to the promised land of conversational human to computer interaction. I wont get into the theory of why the intelligent CLI (aka the conversational interface) has reemerged and why it will prove to be more effective than our current bloated visual UX application world. And remember that the conversational interface can also be voice driven, but voice to text is more or less an added bonus and part of the longer technology maturity in this space.

What does the future hold? I propose that this next generation intelligent CLI should augment every business application in the coming years. Every enterprise should take a hard look at their current UI applications (business and consumer facing applications at every level) and make it a high priority to embed AI chat bot like intelligent CLIs (with or without a personality :) into every user experience and business function they have and for every application persona

Don't Get Left Behind

Whether you are building an ERP application for an HR manager or a sales executive, or an IoT monitoring platform or an analytics dashboard, every one of these applications should have an intelligent conversational interface to augment the visual interface. By 2020 any enterprise not beginning to bring to the market such investments in conversational interfaces within their applications will be left in the dark ages of the visual only UX world.

Friday, September 23, 2016

Analytics + AI = Analytics as a Conversation

The pendulum is swinging in the business intelligence and analytics world. The on going technology evolution driven in part by the adoption of Big Data, machine learning and other advancements in cloud computing have made the storing, modeling and analyzing of huge volumes and velocities of data possible. The tools and IT skills needed to turn this data into rich visual information is now more possible than ever before.

Products like Tableau, Splunk, Qlik, Birst, among others, have brought rich visualization and actionable-minded analytics (actionable analytics still not that common :) to the masses. It is now easier more than ever to build rich visualizations, reports and dashboards. Building BI solutions to tackle all that data percolating around us and across social networks, IoT and within the enterprise is available to the IT masses to build compelling visual user experiences.

Visualization Overload

But there is trouble brewing on the horizon. Is there such a thing as too much data? Too much information? Too much visualization? I have built my share of BI and I have seen many amazing and compelling visualizations and dashboards using powerful solutions like Tableau and many home grown SaaS BI platforms. But I think it is time to step out of the forest and look at how humans effectively interact with information.

While we rely heavily on our visual sense, even the most well intention and minimalistic BI dashboard (and its supporting drill-down reports) might not be the best solution all the time at getting to the information you want or need. Humans have another ability for consuming information, the conversation (question and answer).

There are many technologies now converging and making it possible for us to evolve our BI stack beyond purely visualization based analytics. Analytics-as-a-Conversation (A3C) in my mind is the next frontier for BI. It does not necessary replace today's rich visualization based BI, but augments it.

Living in the Matrix

What is A3C? Well, in movie terms, it is sort of the Matrix. It is about having a conversation with your BI and getting at what you need (the what) through normal human-like conversation (think texting, hashtags, tweets and even emojis). Also, this conversational form of BI is a much more natural way of interacting with complex information and can more naturally lead to asking not just the "what" questions but the "why" questions to your BI Matrix. And this form of information interrogation lends itself to setting a more clear context to the information exchange, as the BI conversation progresses from one question-answer to the next question-answer. For example, perhaps you ask your A3C system the value of a particular KPI or which KPI is the most off its norm this quarter. And then this can naturally lead to such questions as to "why is this KPI higher this quarter?"

Obviously we are not Neo and we are not talking to the Matrix, so the system has to be taught (or programmed to learn) how to converse with a human-like grammar and has to programmed to extract what it needs from the grammar/questions using NLP and then translate that into queries against the target data and metadata system. There would have to be bounds on the grammar and enough knowledge of the system's metadata to compose the proper answers. No small engineering effort, to say the least, but from where we are today with AI, bots, machine learning, NLP and general computing stacks, the technology is there to accomplish this.

All the Right Ingredients Coming Together for AI

Why now? Because the technologies needed to construct the BI Matrix I am describing is largely here and the data volumes are now, in my mind, overwhelming even for the best BI visualizations. With a bit of creativity (and sweat), and with current availability and advancements in Machine Learning, AI and general computing power, it is possible today to begin to build such intelligent conversational analytics systems and user experiences. Don't forget this a about changing how the user "experiences" data.

It is not just about data volumes and technology capabilities, human interaction has itself evolved in the past decade. We have seen with the recent explosion of mobile and social communication that humans are using texting and short messages for communication more than ever and with no sign of ebbing. In fact, texting is quickly becoming the dominant form of communication and the main form of information exchange across the globe and across all demographics.

How is this better than the visualization based BI we have today? Well, I would say it is not necessarily a replacement for the BI we have today, but is instead complementary and can lead to BI answering questions of "what" and "why" that the original BI developer/modeler could not necessarily anticipate out of the box. And as artificial intelligence and machine learning systems continue to evolve and improve the potential is virtually limitless and no longer bounded by what can be rendered on a 2D display or a click of the mouse.

Back to the Future

The revenge of the CLI (the command line interface) is upon us :) But don't underestimate the conversational CLI, it will prove to be orders of magnitude more powerful than any visualization a human can conjure up.

Stay tuned, Analytics-as-a-Conversation is coming and we will all be talking about it (or talking with it).

Tuesday, August 30, 2016

Getting Bitemporal With Your OLTP Database


The concept of a bitemporal database can seem a bit exotic and complex to be considered for a typical RDBMS schema model. While the transaction processing and query structures required to make this happen, with standard RDBMS, are more involved than a normal database model, it is a fairly straight forward design methodology to annotate every table in your RDBMS model with bitemporal semantics.

See the table below for an example for what the table structure might look like. The TT start/end columns are the transaction time dimension and the VT start/end columns are the validity time dimension. These four columns drive the basic schema model structure for a bitemporal database and enable powerful queries that can pivot and scan for data across two time dimensions without the need of a data warehouse or other complex analytics.


The table above looks straight forward, right? And it is. The bit of complexity comes with how to handle the actual data mutations (a change to a row) and insure that every row that is superseded by a a new TT and VT tuple in proper time semantics and that this is handled in a transactional consistent fashion to insure a continuous flow of tuple epochs (an epoch is a row at a particular TT/VT point in time) where the new epoch that supersedes the prior epochs properly terminates the TT and VT epochs with the start of the new TT and VT epochs.

The advantages of a bitemporal schema model are many. They include:
  1. Immutable data structures which means all tuples preserve all changes across time.
  2. Built-in audit trail functionality, since no changes are every overwritten.
  3. The ability to write fairly simple queries to view data any point in time.
  4. Easily compare any two points of time for changes.
  5. The ability to find all changes across a time range.

Injecting bitemporal capabilities into your schema will allow tracking every change that happens within a table across two time dimension: transaction time (when the mutation happened) and validity time (the time range the mutation and current state of the row is valid).

Some databases such as Oracle, DB2 and PostgreSQL have specialized extensions to support bitemporal capabilities, but you don't really need these extensions - they only help with the DDL aspect of the design and not with the DML or query aspect. For the most part, these extensions are just syntacitc sugar that you can implement on your own in a more cross database fashion and even extend to support NoSQL databases as well.

Get started with turning your schema model into a bitemporal powered RDBMS. Contact Grand Logic to learn how we can help you build your next bitemporal database environment.


Thursday, May 26, 2016

Building ML Pipelines


What is involved in building a machine learning pipeline? Here is a common flow:

  • Data pre-processing
  • Feature extraction
  • Model fitting
  • Validation stages
Learn more about ML pipelines (from a Spark perspective).


Wednesday, May 25, 2016

Tuesday, May 24, 2016

Spark Structured Streaming - Crazy Like a Fox

Big Data related computing has matured greatly over the past several years from its early and humble Map-Reduce days. Hadoop introduced developers and enterprises to mainstream distributed computing on commodity hardware and with a software stack (largely Java based) that was accessible to the average developer.

Early versions of Hadoop did not have the most developer friendly APIs, but they made breaking up large computing tasks and iterative processing possible to scale without big iron and SMP hardware. Things evolved and improved with the emergence of memory efficient Big Data engines such as Apache Spark. This has also been helped by the fact that memory prices keep dropping.

A lot of attention has been given to Apache Spark these days as the successor to Hadoop. The big advantage that Spark is touted to have over Hadoop is how its Map-Reduce engine leverages distributed memory to improve performance over classic Hadoop. While this is true, the broader Hadoop ecosystem has been evolving rapidly as well, so this alone is not at the heart of what has given Apache Spark such a big leap forward.

What is often underestimated in the growing popularity of Spark, is its API. If you have ever tried to write a Map-Reduce type job in Java Hadoop 1.x or 2.x you would understand. Spark is API plural with support for Scala, Java, Python and R. The way you build data processing pipelines and construct transformations and aggregations in Spark is well thought out by the authors of Spark.


Sparks is not standing still either. With the development of Spark Streaming, Spark SQL, DataFrames and DataSets in the Spark API, Spark is making the development effort of manipulating data and writing processing logic much more intuitive for developers. The elegance of the Spark API is a key part of the reason why Spark has grown in popularity.

One knock on Spark is that it is now being obsoleted by the next wave of compute fabric engines that are built from the ground up to be realtime streaming centric. Many claim that this streaming first architecture is superior to Spark's batch based architecture for both general purposes processing and especially for streaming operations. Products such as Storm, Fink and Apex, just to mention a few, have garnered a lot of attention. The claim is that by using a streaming first architecture, these engines can do both batch processing and streaming more efficiently than Spark does batch and micro-batch bases streaming.
What is often left out of such as debates is again the API. If you have ever tried to write a Storm processing stream you will know what I mean. So again here, this is where Spark shines with its more intuitive APIs. 

Now this is where we get to Spark's new API coming out in the soon to be release Apache Spark 2.0. Spark will be introducing a new Structured Streaming API that will unify streaming, batch and Spark SQL. The Spark team is raising the productivity bar with how developers use APIs by unifying the building of both batch and streaming applications.

The idea is that a streaming application is really a "continuous application" and that the best way to build a streaming application is not reason about streaming altogether. In other words, Spark 2.0 with Structured Streaming, will make building streaming application no different than building any other Spark application. The streaming aspect is essentially declarative and the Spark engine will do the work of optimizing the stream. The big advantage this has for developers is that we can continue to think of our applications in the same way whether they are doing streaming or batch.

Spark 2.0 with advent of Structured Streaming will leapfrog Spark ahead of the other competing streaming first engines by removing the stream design complexity while at the same time brining Spark's elegance to building APIs to the forefront.

At then end of the day, Spark's well designed APIs will prove to be pivotal for developers. Developer productivity and Spark's fast evolving optimized engine  (Tungsten...etc) will offer a hard to beat combination of developer productivity and raw scalable performance. The idea of having a programming model that does not require a developer to reason  about a stream and instead let them focus on the higher order functions of their application will in the end prove more superior vs the harder to use streaming first engines such as Storm and the like. This unified programming model also frees the Spark engine to evolve the low-level streaming plumbing over time without impacting developers.