Redesign Back, swipe-to-the-left and hardware device Back buttons to align the behavior

[asemiankevich]

Problem

We have a lot of discrepancies between the following actions across all the application:

1. tapping Back button which is build-in the app
2. tapping Back button with is device hardware button
3. doing left-to-right swipe

What we need to achieve:

• define [Back] and [Cancel] behavior (like when tapping Back is actually a cancel of action or tapping back should lead to previous screen)
• define where this swipe from left-to-right gesture is implemented and define what it should do (sending user to previous screen or something else)

This will resolve the following existing issues and prevent new ones:

• Swipe back from "Sign in to status" (accounts list) leads to empty login form and at attempt to login - "Unknown status-go error" #8462
• "Block user" and back button in "Contacts" and "Blocked users" always leads to "Home" instead of appropriate screen #7437
• Back button is not active on Recover a key stored on keycard screen #8851
• a lot of issues with Keycard when i tap Back randomly and the app becomes completely broken

@andmironov @hesterbruikman @errorists i need your input here since it is a design question anyway.

@rachelhamlin

[errorists]

whew, ok here goes nothing :)

1. tapping <- back button, takes you to the previous screen in the current navigation stack. It is joined by the screen edge swipe, they are mutual and if the <- is present, you should be able to swipe. Unlike modal views (presented with an X instead of <-) where swipe back is not possible.
   You should not be able to swipe when there is no back arrow meaning you can't go back to the previous screen in the navigation stack.
   If it doesn't work as you expect it to it means someone botched up the navigation stack. A navigation stack is the linear sequence of screens you follow. it's like a powerpoint slide deck.

It's not a cancel action, but then again it would depend I guess on what you mean by cancel. It's like hitting the back button in your internet browser, if you loose data you had in that page then you might think of it as a cancel.

Now the Android back button, I have no clue really as I don't use an Android phone 😁 By Google's definition it does the same thing as the in-app Back <-/X so it's a duplicate. On newer devices it's replaced with a edge swipe gesture just like iOS. There are areas like the browser where we could point the software button to go backward to the previous page rather than exiting the webview.

In any case, it should act as similar as humanly possible to any natively written app. All of the issues you point to sound like implementation errors when dealing with React Navigation i.e. wrongly linked screens.

[errorists]

I'd like to ask, because I might've missed some thread, what's the expectation of us, should we create documentation for what happens when you press back/swipe/hit device back button on each and every screen?

[andmironov]

Two things I'd like to add to what Maciej just said:

1. At some places of the app in IOS there's a bug now, edge-swipe does not do the same as hitting the back button. So at least both of those actions should lead to the same result.
   Currently, this happens when you go to "Join public chat" -> Choose a chat to join -> Go back. From here tapping "<" brings you to the "Chat" screen and edge-swiping brings you back to "Join public chat" screen.

2. I think sometimes it's okay to break the sequence, especially if the "previous" screen is a part of a finished action. The above is a good example of that, I believe after the user has joined a public chat, both tapping "<" and edge-swiping should bring them back to "Chats" and skip the "Join public chat" screen. But this is a) arguable b) very context-dependant. So like I said above, both actions should at least do the same

[andmironov]

So I think what can be done now is:

1. Making sure that everywhene in the app tap on "<" and edge-swiping does the same;
2. Everywhere where there's a "Cancel" button make sure that there's a specification of what happens after the user hits "Cancel" (most likely an "are you sure" alert -> redirect to some screen)

All exceptions, like the one I've mentioned above (skipping the "Join public chat" screen), are unique and context-specific and require discussion and testing.

[flexsurfer]

the first step of navigation improvement, for v1 we want to avoid broken app states, so i added a list of views there it's possible to navigate back safely, we can remove v1 label and continue improvements after v1

[errorists]

@flexsurfer I'll go ahead and ask you here, would it be possible for the navigation to work like below, so currently if you navigate back from a Chat, it would take you to the previous screen, the New chat. Instead what it should do is take you to the root view, the Chats List, skipping the sequence of any screens in between?

[flexsurfer]

@errorists yes it's possible

[errorists]

@flexsurfer you're awesome, thanks for the quick reply