Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Accepted] SDL 0152 - Driver Distraction Improvements: Command List Limitations #441

Closed
theresalech opened this issue Mar 28, 2018 · 8 comments

Comments

@theresalech
Copy link
Contributor

theresalech commented Mar 28, 2018

Hello SDL community,

The review of "Driver Distraction Improvements: Command List Limitations" begins now and runs through April 3, 2018. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0152-driver-distraction-list-limits.md

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

#441

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,
Theresa Lech

Program Manager - Livio
theresa@livio.io

@AndrewRMitchell
Copy link

My primary comment isn't really about this proposal, but as a resulting side effect. I already view the navigation back from sub-menus to be broken as it brings you to the top level menu. Adding additional sub-menus makes this problem even worse. For this proposal to be truly useful I think it needs to address this back behavior since the current workflow is not what the user is expecting. Allow deeper sub-menus only makes things worse.

@joeljfischer
Copy link
Contributor

I think that navigation back from sub-menus is an HMI decision made only by OEMs, not specifically an SDL requirement. I would assume that HMI decision would not be made with deeper submenus.

@Jack-Byrne
Copy link
Contributor

@joeljfischer

the author was unable to find a notification from Core to HMI of driver distraction.

This type of notification is not necessary since the HMI notifies Core when Driver Distraction is enabled or disabled. Also I do not believe that having a system capability is necessary for menu length and sub menu depth. I think it would be simpler to just include these values in the display capabilities since we are going to be relying on the HMI to limit the menu length and submenu depth. However if you believe that the display capabilities response has become too large and "bulky", then I would be ok with the original idea of using SystemCapabilities.

On a different note, I believe that there should be some sort of warning or information passed to the phone on a driver distraction event to notify the application that submenus and add commands have been limited.

i.e.

  <function name="OnDriverDistraction" messagetype="notification">
    <description>Notification must be sent from HMI to SDL when driver distraction state is changed. Driver distraction rules are defined by the platform.</description>
    <param name="state" type="Common.DriverDistractionState" mandatory="true">
      <description>See DriverDistractionState. </description>
    </param>
    <param name="hiddenMenuIDs" type="Integer" array="true" mandatory="false">
      <description>Array of SubMenuIDs hidden due to distracted driving</description>
    </param>
    <param name="hiddenCmdIDs" type="Integer" array="true" mandatory="false">
      <description>Array of AddCommands hidden due to distracted driving</description>
    </param>
  </function>

@joeljfischer
Copy link
Contributor

Also I do not believe that having a system capability is necessary for menu length and sub menu depth. I think it would be simpler to just include these values in the display capabilities since we are going to be relying on the HMI to limit the menu length and submenu depth.

It could be in displayCapabilities, but we've been moving away from that struct and the model of adding data to RAIR to instead go to the model of GetSystemCapabilities.

On a different note, I believe that there should be some sort of warning or information passed to the phone on a driver distraction event to notify the application that submenus and add commands have been limited.

That's possible, though it would be fairly trivial for the app to calculate it and can be easily handled by the proxy manager, assuming it knows the limitations.

@AndrewRMitchell
Copy link

I think that navigation back from sub-menus is an HMI decision made only by OEMs, not specifically an SDL requirement. I would assume that HMI decision would not be made with deeper submenus.

As an App developer I consider this either a bug or a missing piece in the specification. It is my app that is running, and while it may be skinned to look look like the HMI, its a usability issue that I have to deal with, and one that I get negative feedback from customers about. Just because it's not currently defined (and hence left up to the OEM), doesn't mean it shouldn't be defined. If we're opening up the number of sub menus we need to clean up the UI to properly support this.

@joeljfischer
Copy link
Contributor

@AndrewRMitchell I think the closest we can come to defining that would be a recommendation (or, hopefully, requirement?) in the eventual UX guidelines for SDL head unit certification. Since SDL doesn't define a UI and leaves it up to the OEM, we can't really "clean up the UI." Only OEMs can really do that. I totally understand where you're coming from and think it's pretty obvious that a sub-menu needs a back button, but since one of the primary points of SDL is that it gives OEMs a huge amount of control over the UI, there's only so much we can do, and there's no way for us to build it into Core or the mobile libraries. So, I don't think it's something that can be built into my proposal.

@theresalech theresalech changed the title [In Review] SDL 0152 - Driver Distraction Improvements: Command List Limitations [Accepted] SDL 0152 - Driver Distraction Improvements: Command List Limitations Apr 4, 2018
@theresalech
Copy link
Contributor Author

The Steering Committee voted to accept this proposal. It was noted in the discussion that including a back button from sub-menus should be a requirement within the Core Certification Guidelines, and may also be included in the HMI Implementation Guidelines.

@smartdevicelink smartdevicelink locked and limited conversation to collaborators Apr 4, 2018
@theresalech
Copy link
Contributor Author

theresalech commented Apr 8, 2018

Issues Entered:
RPC
iOS
Core
Android
Generic HMI
SDL HMI
JavaScript Suite

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants