Feature requests?

Hi guys loving the Google Support. So that great. … here what I can think of would be help to really create more complete prototypes.

  • Browsing carousel cards for Phone.
  • Table card for Smartdisplays.
    *Format text as needed. (Bold/Italics) Size?
    *different card types.
1 Like

This is what I need too. Any news?

I strongly support the re-addition of editing the live version of a Skill / Action (or pushing the development version onto the live end-point). I can see a multitude of situations where a hot-fix may be needed:

  • Sudden change in API from 3rd parties.
  • CDN or domain name issues / outages.
  • Voiceflow introduced-bug.
  • Developer introduced-bug.
  • Minor marketing changes to text.
  • Minor bug fixes.

For example, a developer’s CDN provider has major issues and they don’t have any fallback. They would potentially need to wait days for certification now to update the URLs.

Google Sheets integration falls over, and a developer wants to at least put a ‘Sorry we are down’ message at the start rather than just a hard-error. They will be unable to do it now.

If a developer hosted with AWS or using Firebase they can make these changes fast. Voiceflow should be the same - easier to use but just as flexible as other solutions.

I would like to make another suggestion. The shareable links and ‘download’ links seem like they should be opt-in on a per Project basis. Right now they are generated by default, and I may be wrong but seems to me that anyone with the link can import another project or run the related skill in the browser.

The test link is just a 15-digit number. The download link seems security encoded - but even so, some developers will want the option to keep it 100% secure, no links, I’m sure.

As explained on Facebook, the current solution was no longer the right one. We fully agree that offering a fast update solution is necessary, some of our users are already developing this in their skills created with Voiceflow. Again, we are already working to find a viable, simple and effective solution that does not violate Amazon’s policies but also, we must do everything to help our users develop projects more effectively.
To use your examples, of the six situations, four can already be managed today in Voiceflow, that’s why we continue to teach our users how to better support them in their development.

I remember once the Google Sheets integration went down for some days. At the time we chose to quickly disable the integration, and instead hard-code some values using code as a work-around. The outage on Google Sheets went on for many days if I recall.

So if the work-arounds are based on (editable) 3rd party API and the API link dies, like it has happened before, then multi-day outages will happen while users resubmit for certification and wait. If It happens now a lot of users will suddenly discover the ‘live’ editing missing and support will be swamped.

Also, the documentation, which says updated a week ago, still refers to the ability to edit the live version:

Yes, you’re absolutely right about the 3rd party API problem. These are very practical solutions for many of our users, so much so that most of them rely entirely on these solutions. But indeed, even Google can have problems, we have seen it again recently when the Google servers went down. Google sheet is great but should not be used in production. Prototyping with it is fine, using it in production is not the best idea. It’s exactly the same with Live Update, even if we thought it was a great idea, many of our users relied on this feature to manage errors and bugs that appeared after certification rather than integrating error management into their skill and doing BETA tests before launch. But it is also part of our work, to help and guide our users who do not have the knowledge of developers to find better solutions. Live update was definitely not the best solution.
And good catch on the article, I’ve removed it :+1:

What is the recommended production solution? Something like Firebase?

Probably the biggest area that needs to be fixed on Voiceflow is the ability to have multi-language support in one skill / project. Right now the Publish details only have one field per item for all languages, so if you want to have different invocation names - you can’t. Which I imagine 99% of multi-language skills need due to translations.

The solutions I have found is to create different skills per language or try to edit in ADC the language parts. But if you edit in ADC the language parts and re-publish from Voiceflow, the English will overwrite everything. Not great.

Trying to migrate over a project now with 2 languages, and 2 different invocation names (word has been translated) and you get ‘Cannot change invocation name’. Not sure if there is a solution to this or we have to just use Lambda for now. Would be great to solve this somehow.

One other area that needs more robust testing is ISP. Changing the name, re-uploading, using backup all have the potential to create new Product IDs.

So not sure what happens in the following scenarios:

  1. Live skill with ISP. Users reverts to Backup project. Publish.
  2. Live skill with ISP. User changes ISP name. Publish.
  3. Live skill with ISP. User changes price point. Publish.
  4. Live skill with ISP. User deletes, adds back ISP. Publish.
  5. Live skill with ISP. User deletes ISP from ADC Build menu. Publish.
  6. Live skill with ISP. Adds another product.

Right now all the above scenarios could create a new ISP product, and in the process potentially orphan existing ISP users. Needs some thorough testing.