Back to Top

Research

Home → Research

Project Research

PRIDAR

Before considering the chatbot, we first had to understand the PRIDAR requirements, and why they were causing so much trouble.

Our first point of help with this topic was our client, Dr Connor, who graciously provided us with a list of the topics covered by the PRIDAR standard.[1]

From there, we researched each topic individually, ensuring we had enough of an understanding of them to create helpful content on, and understand what about them was difficult for software projects to meet.

Chatbot

Before embarking on our project, we set out to understand the kind of platform we were tasked with making; an informative chatbot.

This involved collating our experiences with similar systems to analyse how they generally work, along with their common downfalls and how we may circumvent them.[2]

We mostly had interacted with customer service bots, designed to answer FAQs when a question matched a key topic, or provide guidance through a rigid dialogue path algorithm.

With these in mind, we came up with possible solutions or areas to pay attention to throughout our project, and to evaluate our bot against:

PAIN POINTS

  • Conversations felt too rigid
  • Outcomes of the experience unclear
  • Expectations of time commitment unclear
  • Users not guaranteed help with their queries

PRIDAR CHATBOT CURES

  • Conversations should feel natural, and accept different types of speech (not expecting a specific answer or keyword)
  • Users should always be given options when navigating the help available
  • Time commitments should be estimated before beginning any process
  • Users should know what to expect before entering any process
  • Bot should be able to help users regardless of the topic or content of their question

Technical Research

Solution

Traditional chatbots are based on simple decision algorithms[4], and continue down a path in a tree with many branches of conversation. They can be tweaked to interpret different inputs from users but never actually interpret their speech, or can be programmed to provide different phrasings of an output but never really form an original response.

Especially when implemented badly, this can become painfully noticeable to users and make the experience feel rigid, inflexible, and by extension sometimes unhelpful.

NLP(Natural Language Processing)[3] technologies can to some degree solve this, however due to our inexperience with the field of AI, and limited time, we decided upon a traditional chatbot solution for the PRIDAR chatbot.

Our hope is that its features can prove useful enough, and provide enough options for flexibility to the user, that the experience doesn’t feel as rigid or unhelpful as traditional chatbots tend to be all too often.

Development

For the development of our chatbot, we initially considered programming it in Python, with the use of libraries to handle API requests and stitch together the front end app interface with the backend model and database. This was because we were all familiar with the language, and it has great support, with extensive frameworks such as Django for web app development.

Early on into the project however, our partner Dr Connor suggested a platform called Voiceflow.

Voiceflow, is a purpose built development environment for chatbots, using premade blocks to allow for logic or custom JavaScript code, and support for accepting voice input, APIs, and deployment to multiple channels, including their own front end web app.

After this suggestion, we searched and compared our initial plan for Python development with both Voiceflow, and its most compelling competitor DialogFlow.

Python & Libraries

PROS

  • Entirely customizable
  • Complete control over data
  • Efficient custom algorithms

CONS

  • Time Consuming
  • Cost involved hosting app


The main points which nudged us towards Voiceflow over something more powerful like DialogFlow or MS Bot Framework was that it was far more intuitive to develop with, clearly showing the logic and flow of conversations visually. This was ultimately very important to us, as a requirement of the project was to be easily comprehensible to non-technical clinicians, allowing them to expand, tweak, or maintain the bot themselves after the end of this project.

Another big reason for choosing Voiceflow was its accessibility to users. Being hosted for free (for our project’s purposes) on the Voiceflow servers and distributable by a web link, or alternatively deploying to more conventional means such as Telegram or MS Teams through the use of their API. This peace of mind and flexibility would allow us to focus on ensuring the bot met all the key functional requirements without running out of time.

Finally, alternatives to Voiceflow’s relatively code-free environment such as Botpress exist, but ultimately proved not as appealing due to a combination of price barriers, collaborative barriers and the fact that of these platforms, Dr Connor expressed how clinicians are most familiar with Voiceflow.

Databases

As for our backend database, we intended this to be all the clinicians needed to use for updating the bot’s content and interacting with users. As such, we needed a platform which was flexible in it’s use and familiar to clinicians.

Once again, Dr Connor suggested a platform, Airtable, to us. Upon comparison with its counterparts such as Monday.com and Jotform, Airtable was the most suitable for our needs of a simple to understand database with a robust free offering. In addition to this, Airtable’s API proved to be by far the most capable, both in terms of data rate limits (allowing 5 requests per second, as opposed to the competitions 5 per 20 seconds) and unlimited usage for free users (other platforms imposed restrictions).

However, halfway through our development of the bot, Dr Connor came to us suggesting a change to Jotform due to EU GDPR concerns, as well as a shift in clinicians’ preferences of platforms. This was for the most part doable, however user credentials are still stored on Airtable, due to Jotform’s terms of use prohibiting this on their platform.

Integrations

For our chatbot’s login system, we required an emailing system to verify user emails and recover their passwords. We landed on Twillio SendGrid for this, as it was a reliable provider, with no limits on usage, as was the case with competitors such as MailGun.[6]

The other integration we required was a way to create visualisations of our data. For this, we went with QuickChart, due to it’s ease of use and exceptional privacy policy. QuickChart doesn’t store any of our user’s data on their servers, only rendering graphs upon a url request. QuickChart is also far easier to work with than alternatives. Google Charts lacked support for our desired radar graphs, and Chart.js and Plotly didn’t work inside of Voiceflow.

Deployment

For the deployment of our bot from Voiceflow we had numerous options to choose from. The most native deployments of Voiceflow included: it’s own front end web app, Amazon Alexa, and Google Assistant. The front end web app was extremely convenient, as it handled translating elements such as buttons into the UI well, and was easily distributable to users. In addition, it required no extra work communicating to a front end, which could introduce extra latency or errors.

While deployment to Amazon Alexa and Google Assistant were equally as convenient, we decided it was best for our project to remain text based, due to accessibility concerns and issues with voice recognition.

We considered other modes of deployment such as to Discord, MS Teams, and Telegram. These were all a really good fit for our text-based approach, and could be implemented using Voiceflow’s API. Due to the requirement for a 365 developer account however, MS Teams deployment was unachievable. Time constraints meant that we chose to focus on Telegram deployment only for the time being, as it is the most familiar and accessible platform to clinicians and potential users alike.

Summary

Overall, our technical decisions were influenced heavily by three main factors:

  • The decision to make a decision based chatbot, rather than integrating NLPs.
  • The requirement for the chatbot to be easy to understand and work on for non-technical clinicians.
  • The requirement for the chatbot to be lightweight and accessible to users.

We ultimately came to develop the PRIDAR chatbot on platforms which are reliable, distributable to users and accessible to non-technical clinicians.

Technical Decisions


After researching APIs and development tools, we decided to use the following to develop our PRIDAR chatbot.

TECH DECISION
Deployment of chatbot Voiceflow
Login/Register Sendgrid
Store User Details Airtable
Post User Queries Jotform
Visualise Data Quickchart

References

[1] “CarefulAI Motives and Models,”CarefulAI. https://www.carefulai.com/motives-and-models.html (accessed Dec, 2021).

[2]C. Verstegen, “The Pros and Cons of Chatbots,” www.chatdesk.com. https://www.chatdesk.com/blog/pros-and-cons-of-chatbots#:~:text=Chatbots%20have%20limited%20responses%2C%20so (accessed Nov. 30, 2021).

[3]K. Krayewski, “How NLP Text-Based Chatbots Work,” ultimate.ai. https://blog.ultimate.ai/blog/ai-automation/how-nlp-text-based-chatbots-work (accessed Nov. 10, 2021).

[4]I. Team, “What is a decision tree and why should my chatbot use it?,” Inbenta, Oct. 23, 2017. https://www.inbenta.com/en/blog/decision-tree-chatbot/ (accessed Dec. 05, 2021).

[5] Karen, “Chatbot Conversation Flows: Static Versus Dynamic Decision Trees,” www.solvemate.com, Mar. 29, 2021. https://www.solvemate.com/blog/chatbot-conversation-flow-dynamic-static (accessed Dec. 07, 2021).

[6]“SendGrid vs Mailgun | HubSpot,” www.hubspot.com. https://www.hubspot.com/comparisons/sendgrid-vs-mailgun (accessed Feb. 05, 2022).