Closed theresalech closed 6 years ago
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.
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.
@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>
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.
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.
@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.
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.
Issues Entered: RPC iOS Core Android Generic HMI SDL HMI JavaScript Suite
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:
https://github.com/smartdevicelink/sdl_evolution/issues/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:
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