Lessons learned - OneGC Alexa Proof-of-Concept

From wiki
(Redirected from Lessons learned - Alexa PoC)
Jump to navigation Jump to search

General

  • The basics of developing an Alexa Skill are fairly simple and easy to learn.
  • AWS services have a steep learning curve and the documentation isn't always great.
  • Calls to and from AWS services are asynchronous; developing for asynchronous functions is very different than for synchronous ones and takes some getting used to.
  • It's much easier to develop locally and use the Alexa Skill Kit Command Line Interface to deploy your Skill than it is to do everything via the Web interfaces provided by Amazon.
  • Setting up an AWS account correctly is a lot of work
    • Permissions are very granular, which means a lot of overhead setting up minimum-required permissions for every user, group, and role
    • The looser the permissions, the more likely you are to have billing surprises
    • There are significant benefits to setting up multiple accounts under an organisation to manage permissions and billing.
    • Billing alerts and reports are 24 hours in arrears, so by the time an alert is triggered it's already 24 hours too late.
  • You can share the dev Skill (without publishing) by adding beta testers

Structuring data

  • Works better with well-formed, well-described data
  • The data set should not contain HTML tags or any other artifacts
  • The data set should consistently label data used for set purposes (e.g. description field should hold a description)
  • Fields with similar names need to be renamed (e.g. type1, type2, type3 => adultRate, childRate, seniorRate)
  • RSS feeds used in Flash Breifings need to comply with Alexa's minimum requirements
  • Descriptive data sets such as food and car recalls need to be summariezed in plain English with simple words.
  • Descriptive data sets such as food and car recalls need to follow the 1 breath design guidance. If it takes more than 1 breath to read the sentence, it means that the sentence need to be further broken down.
  • A natural conversation flow need to happen between Alexa and the user. One need to design the dialog in a way that lets the user drive the conversation by letting him/her know that they can say "tell me more" or followup with a question such as "what are the side-effects?".
  • The Alexa service share only 1 information about the user with the developed Alexa Skills. And that is the User ID, a unique identifier. It is up to the developer/designer of the Alexa Skill to ask the user the right question at the right time such as "What is your name?", "What food allergies do you have?", "What is your car make, model and year?" and to store this information in DynamoDB for future use such as "Hello John!", "There are 5 food products that have been recalled.", "There is a new recall concerning your vehicle."
  • Alexa Skills can store information anywhere. Most sample codes use DynamoDB to store and retrieve user data. But data can be stored in a relational database, S3 storage or sent to any other web service. DynamoDB was recommended by AWS and Alexa presenters for its superfast read speed, data redundancy, low cost and simplicity (1 line of code to read or write data).

Hello, world Skill

  • What went well
    • A hello, world Skill is provided by the Alexa Skill Kit; all that's needed is to install it.
    • Installing a Skill is very easy using the Alexa Skill Kit Command Line Interface.
    • Modifying the Skill to add the ability to specify who to say hello to was straightforward when using the AMAZON.FirstName slot type.
  • What could have gone better
    • The initial deployment of the Skill failed as I created the Lambda function in the Canada region, which is not supported buy the Alexa service.
    • Using an AMAZON.SearchQuery slot did not work and it was not possible to identify the cause of the failure as there was no error message provided.
  • What to do next time
  • What needs to be fixed to make it better
    • Improve the Amazon documentation to make it clear which regions are supported by Alexa.

Parks fees Skill

  • What went well
    • After having built a hello, world skill and having learned the basics of building an Alexa Skill and using AWS Lambda, those parts of the development of the Parks fees Skill were easy.
  • What could have gone better
    • Transforming the data into a state in which it could be imported into DynamoDB was a lot of effort due to the dataset being designed for a relational database system and the poor documentation of DynamoDB.
    • Querying data from DynamoDB is case-sensitive, but Alexa lower-cases everything. We had to duplicate the 'park name' attribute to have properly-cased and lower-case instances so that we could both search it and display it.
    • The Alexa service can't handle park names containing non-English names or words.
  • What to do next time
    • Using a relational database system would have been easier than using DynamoDB.
  • What needs to be fixed to make it better
    • Improve Alexa service to recognize non-English words and names.

Health Canada Recalls and Safety Alerts

  • What went well
    • Integrating with the existing RSA API over HTTPS was seamless and worked as expected.
    • After looking at examples from other collaborators and the web, creating the skill itself was relatively easy.
  • What could have gone better
    • The ability to index the RSA data with a search engine without a high associated cost would have been ideal.
    • Having properly structured data would have freed up more time to further develop the skill, rather than massaging the data to work with Alexa during the development process.
  • What to do next time
    • Come prepared with restructured data that is more suited to generic use cases.
    • Index data with search engine to provide more helpful results
  • What needs to be fixed to make it better
    • RSA Data needs to be restructured and reformatted so it can be more easily consumed by different use cases.
      • It is tied too tightly to the UI is was originally designed for. HTML content should be removed and added dynamically by the applications that consume it instead of existing that way in the database.
      • This has been an ongoing issue that has been further highlighted through this proof-of-concept.
    • Having the ability to create dynamic slot types would be ideal since new data is constantly published.
    • Amazon (AWS+Alexa) documentation is not the greatest and many tutorials are outdated and/or provided misleading information.

Transport Canada Vehicle Recalls

  • What went well
    • The proof of concept session provided immense amount of support to the developers participating. From actual assistance from internal tech personal to outside experts from Amazon.
    • The creation of the proof of concept wiki and continual documentation provided easy reference to various materials covered during the sessions.
    • Daily lessons provided before we code.
    • Friendly atmosphere.
    • Zero barrier between developers and management.
    • Awesome location, easy access by public transportation, new building, and WIFI.
    • Provided laptop with required software.
    • Flexible work schedule.
    • Proof of concept open to various developers’ skill level and backgrounds.
    • Proof of concept fostered a learning environment.
    • Good ratio of support staff to developers.
  • What could have gone better
    • Firm start and end date.
    • Leverage subject matter experts more throughout the design and testing phases.
  • What to do next time
    • Have a longer proof of concept (4 weeks).
    • Bring in a NoSQL (non-relational database) expert to spend time analyzing data structure after the developers have attempted to design their primary keys, the expert can give recommendations.
  • What needs to be fixed to make it better
    • Have longer proof of concept sessions, could have the following benefits.
      • Create a stronger question and answer period with the Amazon tech staff. The basics can be found via google and surrounding peers, with a better understanding developers can shift their focus from getting something to “just work” compared to what’s considered “best practice”.
      • Provide more time to shift data from relational database to a non-relational database. Transport Canada Vehicle data set requires analysis to get the most out of DynamoDB.
      • Allows developers to continue with forward momentum and develop a more complete Alexa skill as opposed to just being able to scratch the surface with what could be done.

Flash briefing

Retrieved from "https://wiki.gccollab.ca/index.php?title=Lessons_learned_-_OneGC_Alexa_Proof-of-Concept&oldid=4710"