As a programmer, rapid prototyping is a great way to grow and learn, because taking a 'deep dive' into new technologies can help grow your skill set and apply your mind to new problems. In an environment where everything is unfamiliar - from programming languages and tools to documentation - it can also be quite difficult. We found that these problems are often 'magnified' when working in an environment like a hackathon that is pressured, sleep deprived and competitive. This is what we learned from prototyping an isiZulu chatbot in just three days.
We were first introduced to chatbots at a Make day, which is basically a pressure-free day of building with new and unfamiliar tech. This really got our creative juices flowing because the potential to build awesome chatbots that help address some complex issues became immediately apparent.
After this, we went to a hackathon to build something that solved a real world problem, such as access to financial services, specifically for speakers of languages like isiZulu. Non-English speakers struggle to access financial services in their home language, so we decided to build an isiZulu chatbot.
Due to the time constraints and competitive nature of hackathons, we didn't have time to integrate with a dummy bank back-end, so we decided to focus on the functionality:
- Checking bank balances
- Transfering money
- Checking debit orders
Choose the tools you find easiest to use
Initially, we were building our chatbot using Google's Dialogflow, but the API and documentation proved to be decidedly difficult to use. After spending a number of frustrating hours trying to get Dialogflow's API to play nice, we switched to IBM's Watson. Watson's API was far easier to use as the documentation was explicit and straightforward.
This illustrates the point that, given comparable tools or services, you should always choose the one that is more user-friendly. In a pressured environment, such as a hackathon, this will save time and allow you to focus on the key features.
The major pitfall with using services such as Watson is that they may not be economical at scale. In a production system, our chatbot would rely on IBM's continued support of the service. However, for the proof of concept or prototype we didn't have to worry about this, so Watson was ultimately an excellent choice.
Don't let yourself get overwhelmed - plan ahead!
The task of building a chatbot in a language that we didn't speak in three days seemed pretty daunting at the start. The fact that we didn't have a clear plan didn't help either. Our productivity slowed down as we had to spend time figuring out what to do. Initially, we didn't actually execute or make any tangible progress.
Looking back, feeling overwhelmed would have been avoidable if only we had just planned better.
Starting a project is often the hardest part, so getting that ball rolling is crucially important! For us, that meant that we had to start to train our bot. Often our objective, an isiZulu banking chatbot, seemed distant and far removed from what we were working on, but we found it helpful to break the system into the following sub-systems or components:
- Facebook Messenger interface to receive the isiZulu message and then send back the isiZulu response,
- Google Translate to translate the isiZulu inputs into English, so that they could be analysed by Watson,
- The chatbot on Watson to analyse the input received from Google Translate, which helped access the meaning of the original phrase,
- Python, heroku and flask to make API calls and manage the interaction between components
Focussing on one of these components at a time really helped us remember how each would deliver value as a part of our final prototype.
On reflection, it became apparent that having established a more concrete plan earlier on would have helped us iterate quicker, which in turn would probably have led to a better prototype. Tracking our progress and tasks on tools like a sprintboard would also have helped a lot to keep up to date with what had to be worked on urgently.
Stick to an ideal use case for the initial prototype
We soon realised that there were a number of problems that we couldn't solve in three days, such as the accuracy of natural language processing algorithms. We had to focus on building our prototype and accept that it would be just that: A proof of concept that wasn't able to handle all of the real world complexities.
Practically speaking, we were building a chatbot that would deliver a stable perfomance if used as intended but could otherwise be easily broken. Because of the time constraints, we had to ignore all complicated use cases and stick to building a system that could handle the ideal scenario well.
For us, that meant we had to focus on building a system that could take an isiZulu string as an input, perform a function based on this input and then show the users an output, like a bank balance, through the Facebook Messenger interface.
This proved helpful because there were many potential other use cases, such as:
- A user speaking a different language,
- Complicated grammar or nuanced language,
- Security issues, or
- Building a fully robust product
Tackling each of these would have gotten us nowhere during the hackathon.
That's not to say you shouldn't take note of edge cases and other potential issues that don't relate to the core functionality. There is no doubt that these will need to be ironed out in the more advanced stages of development, but they won't enhance an MVP noticeably.
Don't trust services to be foolproof - know their limits
Going into this project, we were acutely aware that we would need to use a translations API, such as Google Translate. But, we were also aware that these services are not perfect.
It is important to know the limits of services that you are relying on, as there could be a catastrophic system failure if they can't handle certain inputs.
One of my favorite examples of this is this video where a singer translated the lyrics from 'Let it Go' into a foreign language and then back into English using Google Translate:
This process of translating and re-translating actually completely changed the meaning of the song.
Being aware of the limits of Google Translate and other tools we were using allowed us to limit their effects on our system. For example, if we need to translate multiple sentences and then extract the meaning using NLP, the system is more likely to extract the incorrect meaning. This is because each new word increases the likelihood of a slight error in translation, so the longer our phrase the more likely it is to have errors. That's why we decided to only translate short sentences and then analyse these to extract the correct meaning.
Of course, in a production environment this may not be sufficient.
Use the internet
With us not having had a ton of experience in programming and working with chatbots, we had to do many Google searches and use resources shared on the internet. These provided a foundation which we could adapt according to our own chatbot requirements. There are some really awesome and useful chatbot resources out there, like Python Programming where they show how to train a bot based on literally all of Reddit's data.
This basically boiled down to knowing when we were a bit out of our depth or didn't really know what we were doing.
Once we knew this, we could leverage the internet to learn from others who do know what they are doing. Being out of your depth happens all the time, so becoming adept at finding helpful content, on sites like Stack Overflow, is super valuable.It helps to save time and offers the opportunity to learn from programmers who have had similar issues.
As always with the internet though, it is important to be careful! Randomly changing code that you don't understand can become counter-productive. It's helpful to always remember what has been changed. If this is not possible, source control is a useful way to revert a code base to an older version.
Mark Jones is currently studying a BCom Information Systems and is interested in all things tech and innovation, particularly ICT4D and the use of technology to address social issues. When not busy with university, Mark enjoys a couple of outdoor pursuits like mountain biking and surfing - as well as beaching on weekdays.
Michael Harrison is currently undertaking research in Knowledge Representation and Reasoning towards a Masters in Computer Science. He is interested in learning new techniques in the Artificial Intelligence space. He enjoys running and hiking and also has a weakness for drum and bass.
