Violet v1.0: A Voice-First Framework

Violet has always had a single focus - to become a developer framework which eases building great Voice User Experiences. Just like with the Web and Mobile, we believe in the importance of Voice User Interfaces. Two years ago when we started building Voice Apps, we found that drag-and-drop tools are limited when needing to build sophisticated use-cases, and that other voice development frameworks make refining UX hard.

We have been incredibly grateful for the useful feedback that we have gotten ever since the first release of Violet. Violet is inspired by and built on the lessons of numerous Voice Apps and UI Development Frameworks. These improvements getting into Violet, combined with the apps built on it going live, as well as some minor breaking changes have resulted in this v1.0 release.

Getting Started

Trying to figure out how to get started? There are a few good ways:

Breaking Changes

Upgrading old Voice Apps to the latest version of Violet should not be very difficult. There are two big changes that are worth keeping in mind:

  • Improved Intent Naming CFL id’s have always been used as the platform specific intent id’s. When CFL tags do not have id’s provided, these id’s have been auto-generated. The way these id’s are generated has changed, so that they are more stable in the future - generated id’s now use parent id’s as a prefix. Previously, adding a choice tag near the beginning of a conversation script would have resulted in most of the auto-generated id’s changing, this is no longer the case. Given this change, updating to the latest version of Violet means that platform specific metadata will change and you will need to update the interaction models.

  • Conversation’s closed by default Violet tries to make conversation management in Voice Apps easy. As part of doing this it assumed that once triggered a conversation was running by default. However, this can result in Voice Apps unintentionally leaving the apps ‘listening’ to the end-user, and therefore most voice platforms best practices are to keep conversation closed by default. Given this, Violet has changed it conversation state default to being closed. Conversations are still kept open when a decision/ask is triggered, and in addition the say tag now has a keepConversationRunning tag to make it easier to keep a conversation open (conversation builders can also use a endConversation with the say tag). This change should not result in most voice apps behaving differently, but you will likely need to do an extra round of testing with the conversation state in mind.

Other Updates

Beyond the above breaking changes, this release adds support to Violet for:

  • Dev Tooling now runs standalone The Violet Dev Tooling has been incredibly helpful in finding early bugs while testing your app. This tooling - violetToolSrvr.js can now be run as a standalone app against a remote Voice App. By default the remote Voice App is assumed to be running at http://localhost:3000 but can also be running at a different url by passing the url as a parameter in when launching the tool.

  • Easier Serverless Deployments While Violet could always be used to be deployed in a Serverless Environment we have added a few helpful methods to make it easier to do so. To see an example against the Serverless Framework see the meal-planner example and in particular the serverless.yml configuration file and the violetSLS.js handler code.

  • Extensible Expecting In Voice Apps it is important to give numerous examples of what a user can say to trigger an intent/choice. We have found that adding a large list of expecting tags in a conversation script detracts from the flow. We therefore have moved towards a best-practice of having 1-2 prototypical expecting tags in a CFL script and adding a separate file of expectings examples and loading them by calling violet.loadExpectings.

  • CFL id’s for platform-specific events as well as help, fallback, and launch Different Voice platforms provide predefined intents names for specific use-cases. For example, using the intent name AMAZON.AddAction<object@Event> allows event (calendaring) related request. Now such intents can be provided from within CFL scripts as well. Additionally, CFL scripts allow for special id’s help, fallback, and launch that map to platform specific requests (when available).

Beyond the above changes, this release also has a few minor improvements:

  • Debugging messages have been cleaned - these can be enabled by adding DEBUG=* or DEBUG=flowScriptCompiler before running a Voice App.
  • Violet’s Google platform plugin can now handle custom types.
  • There is better handling of duplicate intents (even when they have a parameters and differ in only the parameter names).