Sdl_evolution: [Deferred] SDL 0167 - App Services - Voice Assistant

[jordynmackool]

Hello SDL community,

The review of the Voice Assistant type of the larger proposal “SDL 0167 - App Services” begins now and runs through September 25, 2018. The original review of “SDL 0167 - App Services” occurred May 2 - May 8, 2018 with the vote of acceptance pending each service type review on the feature happening July 10, 2018. The app service type of the proposal in review, Voice Assistant, is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0167-app-services.md#voice-assistant

The original review can be found here:

https://github.com/smartdevicelink/sdl_evolution/issues/485

Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:

https://github.com/smartdevicelink/sdl_evolution/issues/599

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:

• Is the problem being addressed significant enough to warrant a change to SDL?
• Does this proposal fit well with the feel and direction of SDL?
• If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
  Please state explicitly whether you believe that the proposal should be accepted into SDL.

More information about the SDL evolution process is available at

https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md

Thank you,
Jordyn Mackool

Program Manager - Livio
[email protected]

[joeljfischer]

1. Do synonyms need ids? The strings should be unique, no?

<struct name="VRSynonym">
    <param name="synonym" type="String" mandatory="true"/>
    <param name="id" type="Integer" mandatory="true"/>
</struct>

I think we'll need input from app companies who are developing voice assistants on what information they would see as useful to expose to the system and other apps.

[jordynmackool]

The Steering Committee voted on 2018-09-25 to defer this proposal, keeping it in review until our next meeting on 2018-10-02. This will allow the author to respond to this comment and allow additional time for review. It was requested for SDLC members with voice assistant expertise to weigh in and provide information on what they view as useful to expose to the system and other apps.

[jordynmackool]

The Steering Committee voted to defer this proposal, keeping it in review until our next meeting on 2018-10-09. This will allow members with voice assistant expertise additional time to review and comment.

[jordynmackool]

The Steering Committee voted on 2018-10-09 to defer this proposal to allow members with voice assistant expertise additional time to review and comment. It was requested by the author that SDLC members with voice assistant experience review and provide insight, as they are not comfortable approving the proposal at its current state. If we are unable to receive feedback on this service by 2018-10-16, it will be recommended that this service be removed from the App Services proposal. It was agreed that members should reach out to partners with voice assistant expertise so their voices are heard.

[MazdaMKok]

Does anybody have any information to share about this? It would be much appreciated.

[AndrewRMitchell]

My first issue is around the voice assistant trigger. Specifically, is it a short or long press. It also completely removes one of the primary use cases of voice in a car (as it is a noisy environment), hold to talk. So I suppose you could add a parameter with length, or break up the enum with something like tap, press, hold (or short press, long press, hold). But having a single value seems like we're just going to collide with the IVI over button presses.

My second issue is around lack of details. It specifically says this section needs to be flushed out. If you would like me to take a crack at flushing it out, I will, but I really think the section needs to be flushed out for a vote, not flushed out in comments for a vote. I think the root cause of the lack of comments or discussion is the lack of detail in the proposal.

Andrew

[joeygrover]

@AndrewRMitchell thanks for your feedback! As the author my intention here was for the experts to lend a hand into the feature rather than a novice in the area (like myself) define how it should work. So yes, please take a crack at it! We have been able to move forward with all the other services besides this one coming to an agreement (Nav to be returned however) so I believe the base idea is there for an app service, but each service type requires the participation of their respective experts.

Also, I do not recommend accepting the proposal as it stands today as I've voiced on the steering committee calls. I would much rather reject for now, and move forward with the larger feature in hopes that a member with more knowledge in the area could help. If it's possible to get a commitment that you can get something back to to the steering committee than I would suggest leaving it deferred another week.

[jordynmackool]

The Steering Committee voted on 2018-10-16 to defer this proposal to allow time for Amazon to add specific details about voice assistants that are called out in this comment. Once updates have been made to this proposal, the SDLC will review.

[theresalech]

@AndrewRMitchell please advise if you will be able to take action on this proposal within the next two weeks. If not, we will plan to close as inactive on 2019-05-08. Thank you!

[theresalech]

Closing as inactive. The issue will remain in a deferred status and unlocked so the author can notify the Project Maintainer when it is ready to be revisited.

@joeygrover to adjust voice assistant section of larger App Services proposal to reflect this proposal being closed.

[Kazuki-Sugimoto]

@theresalech -san
I took over #893 from @Shohei-Kawano.
I have an idea for @joeygrover's suggestion, so please reopen.
Continued below.

[Kazuki-Sugimoto]

Thinking as an ideal Voice Assistant UX, it's about saying what users want to do and giving them the best feedback without having to be aware of what services each Voice Assistant has.
Actually, it is difficult to fulfill all the wishes of the user with only one Voice Assistant, since there is no service that bundles multiple Voice Assistants at this point. Thus, users need to differentiate the use Voice Assistant for what they want to do.

Apple CarPlay and Google Android Auto are examples where NatviceVR and Voice Assistant are mixed up.
There are two specific ways to use them properly:

• When Apple CarPlay or Google Android Auto is connected, pressing Talk button launches Apple CarPlay or Google Android Auto Voice Assistant, other launches NativeVR.
• Short press talk button to launch NativeVR, long press to launch Apple CarPlay or Google Android Auto Voice Assistant.

For home use, there are Amazon Echo and Google nest as devices equipped with Voice Assistant, but it is unlikely that other Voice Assistant will be mixed up since they use dedicated Voice Assistant.

From the above, we have considered that the identification by long press / short press of the PTT button and the identification by WakeUpWord are realistic.
In this section, we describes the recommended cases for each in-vehicle device system using PTT and WakeUpWord.

1. When NativeVR exists (No registration of WakeUpWord from SDL) or NativeVR does not exist, user uses PTT button with long press / short press.
   
   
   
   • Advantages: HMI implementation and processing are simple.
   
   
   • Disadvantages: Requires active service configuration by the user.
   
   
2. When NativeVR exists and not always detecting, user speaks SDL WakeUpWord after pressing PTT button.
   
   
   
   • Advantages: Users can clearly select the service they want to use.
   
   
   • Disadvantages: There are two actions, therefore, the user may feel inconvenience.
   
   
3. When NativeVR exists and always detecting (NativeVR WakeUpWord only), user speaks SDL WakeUpWord after speaking NativeVR WakeUpWord.
   
   
   
   • Advantages: Users can launch without button operation.
   
   
   • Disadvantages: User needs to speak two kinds of WakeUpWords(; NativeVR and SDL)
   
   
4. When NativeVR exists and always detecting (NativeVR and SDL WakeUpWord is available), user speaks SDL WakeUpWord. (equivalent to NativeVR WakeUpWord)
   
   
   
   • Advantages: Users can launch by just speaking one kind of WakeUpWord.
   
   
   • Disadvantages: HMI needs to support SDL WakeUpWord with NativeVR.
   
   

Considering the scale of development, it is desirable to expand in stages.
First, assuming the proper use of launch by PTT, we will implement the basic part as VoiceAssistant of AppService.

Thank you and best regards.

[theresalech]

Hi @Kazuki-Sugimoto - thanks for your input! In order to allow the Steering Committee to review your proposed revisions to this proposal, please submit a new PR to revise the original SDL 0167. Instructions for how to do so can be found here.