-
Notifications
You must be signed in to change notification settings - Fork 122
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
Comments
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. |
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.
|
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.
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. |
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: |
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:
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
The text was updated successfully, but these errors were encountered: