Our system has been thoroughly tested and, as it stands, we don’t have any bugs that affect the performance or stability of the application. We also have complete error handling and logging so, if anything unexpected were to happen, the user would get a visual notification that something went wrong with the option of emailing us (
firstname.lastname@example.org) the error log.
Relying on Twilio
When it comes to one of our main dependencies, Twilio, we are using the most recent stable version of the Twilio API. All these releases have been made to be backwards compatible, and previous versions of the API are still maintained by Twilio, so possible issues are limited on that front.
What about Voiceflow diagrams?
Voiceflow diagrams were initially made in a way that didn’t allow users to export and were potentially designed not to be used outside of Voiceflow. This means that there is a chance in the future that Voiceflow may adapt or change this format.
This is why we made our own
Unified Bot Format to combat this. The idea is to take any diagram and convert it into this one format that can be interpreted and read by our
ubf-to-twilio package. If Voiceflow decides to change the format of their diagrams, you only need to convert this new updated format to
UBF and you are ready to go.
We also put in a lot of research reverse engineering Voiceflow, so if Voiceflow were to remove the ability to export the
.vf files, we have an alternative way of accessing the diagrams.
We have many isolated components that come together to make our system. Our application is currently a frontend that connects to a backend (Twilio), so it is incredibly efficient in resource usage since the main computation done consists of converting a Voiceflow diagram into something the backend can understand.
We went through many stages of iterating the UI to get it to a state where a user can efficiently navigate through it. The primary way we achieved this was by getting feedback through multiple channels.
This included getting input from our TA, client, and users who don’t have a technical background such as associates or, more importantly, doctors. Going to many different channels for feedback helped us to not make a system that was developer biased.