Difference between revisions of "Lessons learned - OneGC Alexa Proof-of-Concept"

From wiki
Jump to navigation Jump to search
(spacing)
Line 60: Line 60:
  
 
* What went well
 
* 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
 
* 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
 
* 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
 
* 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 ==
 
== Flash briefing ==
 
* Easy to start
 
* Easy to start

Revision as of 11:09, 30 July 2018

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.

Set up

  • What went well
  • What could have gone better
  • What to do next time
  • What needs to be fixed to make it better

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

  • 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

  • Easy to start
  • Flash briefing template does not support ATOM feeds
  • Flash briefing template only supports HTTPS
  • Alexa voice flash briefings are better if source material is voice (e.g. podcast)

To do

Micro-Mission Experience at TBS

What went well

  • This was my first micro-mission ever (4-week assignment) and it was a great learning experience.
  • The TBS team was very welcoming, friendly and had good communication
  • TBS location made it ideal for me to try a different restaurant every day while working downtown Ottawa
  • I was able to learn about TBS, Alexa Skills, and other departments needs
  • I was able to share my knowledge and Alexa Skills experience with other participants and provide them technical support
  • I was glad to have had two weeks to ramp up on Alexa prior to hosting the 4 departments
  • I was happy to meet very motivated developers from 3 out of 4 departments on the 3rd week
  • GitHub was a nice platform to share code and host a wiki for developers and designers
  • The OpenGov WiFi was instrumental for the development and testing of Alexa Skills on the Amazon Echo device that was assigned to me (no proxy settings nor firewall issues)
  • It was the first time that I worked in the open (publicly-faced GitHub repositories). This was a great way to share our experience of Alexa Skills with everyone in the world.
  • I really like the fact that TBS sent out Tweets to tell the world about our event.
  • The meeting rooms used when hosting the event are well suited for a collaborative effort with the big TV screens and open WiFi.

What could have gone better

  • It would have been great to have a developer from the 4th department on the 3rd week
  • It would have been great to start our 2-week collaboration with all 4 departments in mid-July. But since it started later, I will probably miss the ending.
    • The original plan was to start on the 2nd week of July. It got postponed to the 4th week.
    • The good news is that we got to meet the developers on the 3rd week
      • Got to see their dataset, think about their use cases and provide a day-long Alexa Skills training
  • Alexa Skills has a lot of training material, code samples and tutorials scattered all over the web. I would have liked to see a well defined and structured course to cover all the key concepts for developing a voice assistant skill. There's an AWS Certification. But, there doesn't seem to be an Alexa Skills Certification from Amazon.
  • The furniture in the open space area is definitely not adequate for long periods of software development. The table and chair height were not adjustable and it caused shoulder and forearm pain.
  • For a good live debugging experience, 3rd party developer tools are needed for a good end-to-end software development experience. It would be great for Amazon to list these tools in their documentation and provide guidance for end-to-end software development and testing.
  • I would have like to download an Alexa desktop application directly from Amazon instead of relying on a 3rd party application.

What to do next time

  • Consider inviting local businesses, companies, provincial governments (e.g. Ontario), crown corporations (e.g. CBC) or departments to share their Alexa Skills experience with the participants.
  • Consider inviting or hiring consultants or companies to provide a structured training to participants.
  • Consider getting firm commitments from the supplier (e.g. Amazon) several weeks in advance.
  • Consider getting the developers from the different departments on a 4-week micro-mission with the goal of releasing an official Alexa Skills for their respective department.

What needs to be fixed to make it better

  • Book meeting rooms well ahead of the event
  • Have ergonomic furniture in open spaces
  • Consider inviting or hiring companies that can provide training.
  • Consider inviting or hiring companies that can help departments continue the development of their Alexa Skills well after the 2-week hackathon.
  • It would be awesome to have at least one developed Alexa Skills go through the submission process and become available for all Canadians using Amazon Echo devices or the Alexa app on their smartphone.

Structuring data

Template

  • What went well
  • What could have gone better
  • What to do next time
  • What needs to be fixed to make it better