Technical solutions to support a SHOULD for back navigation during the booking flow are missing

[riclage]

Concerning the tech spec proposal #4 to implement a "booking" flow for passengers, we consider the "back" UX navigation pattern as optional. As per the RFC 2119, carpool operators MAY implement this pattern so that passengers can go back to the MaaS app.

Currently this is optional due to technical limitations that exist in many cases today. For example:

• Passengers that don't have the app installed, may be redirected first to the app store to install it. Then they may have to go through the operator's onboarding before starting the booking flow
• Operators may choose to open a third-party url first before redirecting to the app
• Operator or MaaS apps may have their own navigation systems in place, with custom screens that override the operating system default behavior

In all the above cases it is not trivial to implement a solution where the user can use the operating system "back" UX pattern to return from the operator to the MaaS app.

Until those technical difficulties are addressed, we cannot propose that operators SHOULD provide a back navigation.

[adelcasse]

@osarrat proposed an interesting way to pass some arguments during search, before the booking flow occurs to take them into accounts in deeplinks and after during the booking by deeplink process, in PR https://github.com/fabmob/standard-covoiturage/pull/6 ...

We could maybe take inspiration on that by adding something like a callbackUrl which would be the "Return to the MaaS" URL for the "back" functionality ?

This wouldn't be so complex for the operator and we could use a SHOULD instead of MAY ?

[adelcasse]

Following todays meeting discussion, I made a new proposal for a converged (API + deeplink) booking in PR https://github.com/fabmob/standard-covoiturage/pull/18

In this case, passengerOperatorUrl (if the MaaS provides a passenger) could be used as callback URL to solve this and send back to the MaaS ?