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.
Trying to figure out how to get started? There are a few good ways:
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.
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:
DEBUG=*
or DEBUG=flowScriptCompiler
before running a Voice App.