[Accepted with Revisions] SDL 0119 - SDL Passenger Mode

[theresalech]

Hello SDL community,

The review of the revised "SDL 0119 - SDL Passenger Mode" proposal begins now and runs through April 10, 2018. The original review of "SDL Passenger Mode" took place December 6 - December 12, 2017, was returned for revisions, and was withdrawn by the author on February 21, 2018. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0119-SDL-passenger-mode.md

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

#359

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

[joeljfischer]

I would like to note that both Carplay and Android Auto do allow use of the app without a lock screen while in the vehicle. iOS 11's Do Not Disturb pops up an "I'm Not Driving" confirmation button when the home button is pressed. I believe this proposal should be accepted, and an "I'm Not Driving" button added to the default lock screen.

[robinmk]

We need more time to provide our final feedback as we are following up with our legal team to understand if there are any legal implications.

[theresalech]

The Steering Committee voted to return this proposal for revisions. The committee agreed that the proposal should be revised to make SDL Passenger Mode a capability of the module, which can be enabled or disabled by an OEM. This will help to allow legal compliance with different OEMs, as they will be able to accept or reject an app based on the availability of Passenger Mode.

[theresalech]

The author has requested to withdraw this proposal. If another SDLC member would like to continue the efforts of this proposal, they can become the author.

[theresalech]

The author has submitted a revised version of this proposal, which will now be in review until April 10, 2018.

[joeljfischer]

Another option for implementation is to use the driver distraction system capability. This would seem to conceptually fit better there, assuming that all of the remaining functionality is the same. It would be good for OEMs to be able to update all of their driver distraction related capabilities including those in the linked proposal as well.

[joeygrover]

<param name="lockScreenDismissalEnabled" type="Boolean" mandatory="true">

The param should not be mandatory. As we've observed while trying to alter the RPC spec adding the mandatory flag usually introduces more problems then they solve. They are only necessary if the struct itself doesn't make sense without that param. In this instance, in can easily be inferred that if the para is not included the default value would be false.

... the proposed solution is to have a button in the default lock screen that certifies that the user is not driving.

I would propose something like a press and hold functionality here. A button press could easily be pressed accidently. As I believe Android already uses a swipe motions we shouldn't try to replicate that, but a specific gesture based acknowledgement would still be ideal.

This will disable the lock screen, and for the remainder of that app's session...

If another OnDriverDistraction notification was sent with the lockScreenDismissalEnabled the lockscreen should be re-enabled. In my opinion, even a timeout of inactivity should denote a return to the lockscreen.

As another addition, it might be a good idea to add a policy entry for custom language from the OEM to be displayed when a user tries to dismiss the lockscreen. The additional text would need to be sent in the appropriate RPCs and new params.

[BrettyWhite]

The param should not be mandatory. As we've observed while trying to alter the RPC spec adding the mandatory flag usually introduces more problems then they solve.

That makes sense.

I would propose something like a press and hold functionality here. A button press could easily be pressed accidentally.

I wholeheartedly disagree. Adding more complex gestures will further isolate SDL from commonly used UX patterns that will confuse users. A button or the Android Auto-like swipe should be sufficient.

In my opinion, even a timeout of inactivity should denote a return to the lockscreen.

If there are no laws on this, it is just adding to user headache while using the intended app and in my opinion, should not be done.

Another option for implementation is to use the driver distraction system capability.

The goal was to allow OEMs to update this (enable / disable / misc) on the fly with an update to their policy server. As far as I'm aware, your solution does not easily allow this. Please correct me if i'm wrong.

[joeygrover]

I wholeheartedly disagree. Adding more complex gestures will further isolate SDL from commonly used UX patterns that will confuse users. A button or the Android Auto-like swipe should be sufficient.

A press and hold is a pretty common gestures (eg long press or otherwise referred to as press instead of tap) and would prevent accidental button pressrd on a sensitive issue. This can literally be a gesture recognized on the button, but I don't believe the simple onClick gesture should be used when a simple change can prevent unintended behavior. The swipe features is already used in Android Auto as stated, so replicating it opens SDL up to an area that I think we should avoid.

If there are no laws on this, it is just adding to user headache while using the intended app and in my opinion, should not be done.

It's not so much about laws, it's about use cases. So let's say the driver's phone is connected, but the passenger wants to be able to access more functionality so they dismiss the lockscreen. They set the phone back down, now the driver can use the phone without the lockscreen. With a mechanism to revert back to the lockscreen we prevent unintended behavior. I realize it's not a perfect solution as it would be possible to simply pass the phone and the driver continue using it, but I think it covers a pretty common use case where driver's aren't intent on performing adverse behavior. I don't believe this to be a reason for the proposal to not be accepted, but I believe adding functionality like this should have use cases exhaustively thought out as this is a very sensitive area.

[joeljfischer]

I would propose something like a press and hold functionality here. A button press could easily be pressed accidentally.

I wholeheartedly disagree. Adding more complex gestures will further isolate SDL from commonly used UX patterns that will confuse users. A button or the Android Auto-like swipe should be sufficient.

iOS requires two button presses for the "I'm not driving" prompt, one for the CarPlay lock screen, just for reference. I think a press and hold could work, but would require some good UI work to make it clear what we're asking for and how to do it. I think a two prompt-flow like iOS could also work well.

If another OnDriverDistraction notification was sent with the lockScreenDismissalEnabled the lockscreen should be re-enabled. In my opinion, even a timeout of inactivity should denote a return to the lockscreen.

If there are no laws on this, it is just adding to user headache while using the intended app and in my opinion, should not be done.

I disagree about the new OnDriverDistraction, unless now the lockscreen dismissal was disabled in that notification. It would definitely be confusing to the passenger if the lock screen suddenly came back after the driver stopped at a stop light and began moving again. A timeout of inactivity could work, but would require developer work to reset a timer on every activity, which may be too large a burden.

Edit Perhaps if the app goes into the background and comes back the lock screen could resume? I'm not sure that we need to bring it back without a new connection, however.

[BrettyWhite]

I realize that these evolution proposals are more about the technical aspect of a change to the SDL platform, but I want to make known that i truly believe that we need some deep thought about our end users as well, not just from an engineering perspective. Think about what you are saying and ask if your grandparents could use it, or someone not used to a smartphone. While gestures and re-locking on a timer or notification might make sense to you, it will be distracting, dangerous, and maddening to them. Keep in mind, developers will want to write for the platform that has a great user base.

That is why I have re-written this proposal from my original one a few months ago. I realize that OEMs need to have their control and that in different countries, different laws require them to have the flexibility to make changes to this. Therefore, that control has been added to the design. But as a platform, I feel a step back and look into what the end user might perceive is needed. I believe simplicity and common UX patterns should be used here, whether borrowed from iOS or Android, and that is what was in mind while writing the proposal.

[theresalech]

The Steering Committee voted to accept this proposal with the following revisions:

• lockScreenDismissalEnabled param should not be mandatory
• Swipe method to dismiss the lock screen
• Be able to re-engage the lock screen if a notification is received, instead of allowing a lock screen to be disabled for the remainder of an app's session

[theresalech]

@BrettyWhite please advise when a new PR has been entered to update the proposal to reflect the agreed upon revisions. I'll then merge the PR so the proposal is up to date, and enter issues in the respective repositories for implementation. Thanks!

[theresalech]

PR with revisions has been merged and issues have been entered:
RPC
Core
iOS
Android