[1304] Define navigation flow involving history and the overlay

[pocmo]

In #1063 I was trying to test and simplify the navigation. We are going through some cycles to remove sessions, add new sessions, load URLs and replace the BrowserFragment - This seemed very complex.

From reading the code I wasn't really sure at what point we want a new session to start and at what point we just want to load a URL - maybe there's no need to replace the Fragment at all!?

Anyhow, I met with @aminalhazwani to talk about how the navigation is supposed to work. During the meeting I sketched the navigation while we talked about certain states. This was the state at the end of the meeting:

One of the questions we didn't solve yet was: If we are in the state "Overlay on top of Website B" and we click on a tile then will this start a new session (-> Remote Back will go to the start state) or will this just load a new URL (-> Remote back will navigate back in history)?

@aminalhazwani wants to think more about this and look at metrics. I filed this as a separate issue because this seems to be independent from the engine refactoring now and a foundational question that we need to solve.

Design

Source file of the flowchart below is available here https://whimsical.co/L8SDfeuM7FXzMBHXEw1Exi

[aminalhazwani]

So, I've been thinking about this for a while and we're possibly closer to a solution. Before diving into the proposal some important info:

• UPPERCASE (R) indicates actions executed with the remote
• Lowercase (T) indicates actions executed with the toolbar

This proposals takes also into account the fact that we want to use the MENU (R) for contextual features (see #1167).

The following image highlights the possible flows and paths. Arrows are color-coded in order to give a point in time in the flow.

Written description of the picture above:

1. Open the app, homescreen visible
2. SELECT (R)/type a website from the homescreen
3. Go to website A
4. Open homescreen via MENU (R)
5. Go to website A via BACK (R)
6. Go to website B from website A
7. Open homescreen via MENU (R)
8. Go to website A via Back (T) or go to website B via BACK (R)
9. Go to website C go from website B
10. Go to website B with BACK (R)
11. Open homescreen via MENU (R)
12. Go to website C via Forward (T)

You can exit the app via the BACK (R) from the first website in the history stack (we will display a confirmation modal for this case) or via a new Exit (T) button in the toolbar.

As we already doing on Connect the homescreen is not included in the history stack. How does it look to you @pocmo?

[mcomella]

@aminalhazwani Thanks for spec'ing this out: this makes sense to me for users with a Fire TV remote but we've been seeing users who may not have a menu or home button on their device - #1308 - is there anything we can do for them? (I wonder if these alternative remotes have other ways of creating a menu command...)

[aminalhazwani]

@mcomella I checked the documentation and it seems that both the Toshiba TV and Element 4K TV provide a Fire TV remote.

I tried to to use the Fire TV with a Panasonic Remote and yes, you have to trial and error to find out how to go back to the homescreen and it's not the most intuitive experience. If it's worth pursuing we could investigate if it's possible to first detect and then set custom remote buttons through the new system settings (#689).

[athomasmoz]

Hi Amin! Thanks for putting this together. I think overall it's very intuitive, I would echo Mike's point about confirming remotes.

The only workflow that confuses me a little is "You can exit the app via the BACK (R) from the first website in the history stack." If you're at website A and click back, I would expect to go to the Firefox homescreen, and maybe a 2nd back press exits the app. Can you tell me a little more about that workflow?

[aminalhazwani]

The only workflow that confuses me a little is "You can exit the app via the BACK (R) from the first website in the history stack." If you're at website A and click back, I would expect to go to the Firefox homescreen, and maybe a 2nd back press exits the app. Can you tell me a little more about that workflow?

Absolutely! First, the only way to open (go back to) the homescreen is via the MENU button and the proposal is to keep this as much consistent as possible. Second, many Fire TV apps allow users to exit the app right after launch via the BACK button (and some prompt a confirmation dialog), therefore the proposal -- let users exit the app from the first website they visit (similarly to Silk) with a confirmation prompt.

[athomasmoz]

Ok awesome, thank for the extra details! I like really like that you're keeping behaviour consistent with how other Fire TV apps work.

Let me know when you're comfortable moving this to the implementation stage. It's in our current sprint.

[aminalhazwani]

Yes, we can start to implement this and test it. Also cc @pocmo since he gave also a deeper take at this.

[pocmo]

What I didn't get from the diagram yet is will selecting a website from the homescreen during a session start a new session or load the site in the current session.

If my path is:

Website A -> Website B -> Menu

And now I select "Website C" from the Homescreen. In which of those states will I be:

Website C      // New session, back stack is empty
               // Disadvantage: Cannot get back to previous session

Website A -> Website B -> Website C    // Just a new page loaded in the same session
                                       // Disadvantage: I can't really start fresh

[aminalhazwani]

Thanks @pocmo, that's a good question. I wouldn't reset the history stack after every time users open the homescreen. We could keep the session (and the history stack) available as long as the app is open. Once the app is close we could keep only the tab that is left open and reset the rest of the history stack. There are pros and cons -- I don't have a strong opinion about it. I would loop in also @athomasmoz and the rest of team for a greater feedback.

[aminalhazwani]

I brought up this problem with @topotropic and she gave us some great inputs.

So here a proposal: what we could do is to reset the history stack after a user closes the app for more than XX minutes (5? 10? I am thinking about app switching -- back and forth). And after this elapsed amount of time we could reset the history stack, so on next launch the app will open the homescreen.

Nevertheless we could include a new channel (aka row) with the recently visited website (5? 10? 15?), right under the Pocket channel. What do you all think?

[liuche]

During Sprint Planning, we discussed that for users who are continuing to use their tv remote, which lacks a menu button, this flow would make it impossible to get to the "homescreen" without a menu button (whereas before, you could get to the homescreen using the "back" button, unless you were on Youtube #773 ). (but keep in mind that we still don't know how many users this would be, but this could be quite high depending on how many people buy "smart tvs")

[mcomella]

So here a proposal: what we could do is to reset the history stack after a user closes the app for more than XX minutes (5? 10? I am thinking about app switching -- back and forth). And after this elapsed amount of time we could reset the history stack, so on next launch the app will open the homescreen.

In general, I don't mind this behavior and I think it could be standard on some "household devices" like this and Echo Show. However, it's hard to get the number just right and likely needs some kind of session restore (e.g. user uses Firefox, leaves it on but device goes to sleep, comes back in a few hours and they lost their place).

What do other apps do on this device?

[athomasmoz]

@aminalhazwani I'd like to add this to next sprint. However, I'm worried about the back button behaviour. We're getting more & more feedback about people needing the back button to return to the homescreen & ultimately exit the app. What are your thoughts on having the back button from Website A take you to the homescreen. And the back button from the homescreen exit the app?

[aminalhazwani]

What are your thoughts on having the back button from Website A take you to the homescreen. And the back button from the homescreen exit the app?

@athomasmoz I thought we where opting for this approach 🙂

many Fire TV apps allow users to exit the app right after launch via the BACK button (and some prompt a confirmation dialog), therefore the proposal -- let users exit the app from the first website they visit (similarly to Silk) with a confirmation prompt.

See #1071 (comment) up here.

[athomasmoz]

Oh may be a misunderstanding of your previous message. In your diagram, BACK goes right out of the app. But if someone only has a back button, then how do they reach the overlay? So my question is, can the back button from site A first go to the homescreen/overlay. And then a 2nd back press exit the app

[aminalhazwani]

So my question is, can the back button from site A first go to the homescreen/overlay. And then a 2nd back press exit the app

Ok, let's try to see if this might work.

1. Launch Firefox
2. Open Website A
3. Press BACK on remote
4. Show Homescreen (instead of exit app as Silk)
5. Press BACK
6. Exit app (instead of dismissing homescreen and going back to website A)

If we use the BACK button to exit the app instead of dismissing the homescreen there is no direct way to return to Website A from the homescreen. So while we would simplify the back flow (and users who don't use the Fire TV remote) we would then remove the possibility to close/dismiss the homescreen coming from the first visited website.

[athomasmoz]

Ah I see. Any ideas on how to deal with remotes that only have back buttons? I'm awaiting survey results to see how widespread the issue is, but they won't come back before you go. So if this is common, then I guess we'd somehow have to figure out how to:

• Open the overlay
• Close the overlay & return to site
• Exit the app

Any suggestions?