[meta] Multitasking V2

[antlam]

UX meta to track related issues. No milestone attachment necessary.

• [x] #1248 Revisit Multitasking via tabs
• [x] #1245 Polish sheet expand/collapse animation
• [x] #1249 Animate web page switching interaction
• [x] #1231 New tab shows more than first subdomain
• [x] #1257 Opening shortcuts/links always opens a new tab - even if there is a tab with identical URL open
• [x] #1363 New tab button
• [x] #1362 Close tab button
• [x] #1388 Open tab in background
• [x] #1334 Back button behavior
• [x] #1365
• [x] #1805 - "Singletasking"

[pocmo]

Does this new issue mean that all those things have been moved to a new/later milestone?

[antlam]

@pocmo I'd love if we could do #1245 before but generally speaking, yes.

As a quick note, we won't be assigning these [meta] issues to a milestone, it's mostly for UX to keep track of related issues.

[bbinto]

"Please add a proper tabs system maybe by changing the action flow button from delete history to tabs? Opening tabs by holding links to open in new tab is difficult."

[vext01]

Tab management is the last remaining nit that stops me using FFF for all tasks.

Why not just have a button to open a new tab someplace? That's all you'd need.

[dimqua]

#1231 and #1365 are closed.

[Sdaswani]

@vesta0 @brampitoyo i think @colintheshots has done some great work on changing our multitasking flow, can we plan to incorporate some of it in 8.0? This issue may be dated so we can close this one and add a new one for @brampitoyo to post his thoughts / mocks in?

[vesta0]

@Sdaswani I have a meeting with @brampitoyo later today to talk about this. @colintheshots and I also talked about it briefly last week. Once we have a mockup I'd like the team to break it down to smaller independent pieces that can be prioritized and I'd love to incorporate some in 8.0

[brampitoyo]

@Sdaswani After talking with @vesta0, we have decided on a few features that we like to consider for multitasking v2:

1. Open fresh new tabs quickly

Opening a new tab that contains a link of your choosing (not just link contained within the page you already have open) should be faster and simpler compared to other browsers.

In this mockup, “Open in new tab” is a new action that we add to our URL bar and keyboard.

Why it’s faster and simpler

Other browsers

1. Tap multitasking button.
2. Tap (+) button to open a new tab.
3. New tab page opens. Tap on the URL bar.
4. Type URL or search keyword.
5. Type “Return” or “Go” on the keyboard.

Firefox Focus

1. Tap URL bar.
2. Type URL or search keyword.
3. Tap “Open in new tab” button
   • Alternatively, tap-and hold the “Return” or “Go” key on the keyboard, to pop open an “Open in new tab” button.

2. Get to an open tab quickly

Finding a tab that’s already open should be faster and simpler compared to other browsers.

In this mockup, you’d be able to search your open tabs by simply typing its name on the URL bar.

Why it’s faster and simpler

Other browsers

1. Tap multitasking button.
2. Tap “Find tab” (most browsers don’t have this; if they do, you need to hunt for the find box).
3. Type tab name.
4. Go to tab.

Firefox Focus

1. Tap URL bar.
2. Type tab name. Tab thumbnail appears on the side.
3. Go to tab.

3. View all open tabs

This is a tricky one to justify. Having a tab list view doesn’t differentiate us from other browsers. And if we do build one, it’s very hard to make it quicker, faster and simpler to access.

However, since we don’t show anything when you tap on the URL bar, why not give this UI some superpowers?

1. Tap URL bar in order to:
   • Highlight current URL
   • Show list of tabs underneath current URL:
     • Current tab is highlighted (no need for tab name, because you already see its URL above)
     • Every other tab is shown
2. Start typing on the keyboard in order to:
   • Go to a URL (manually or autocomplete, open in current tab or open in new tab)
   • Search for keywords (verbatim or using suggestions)
   • Find open tab in the tab list view.

This tab view isn’t really faster or simpler to access than other browsers, but it fits in with other components that we’ve designed as part of multitasking v2.

4. Close individual tabs

This is an easy one to design for. We can simply add some close “x” buttons to the side of each tab (whether it’s a tab name or a thumbnail).

---

Remember that our goal is to help privacy-concerned users get to their destinations quicker. If we can make things quicker, faster and simpler to access compared to other browsers, it’s probably a good starting reason to build it.

[brampitoyo]

In addition to this, it will help to user test multitasking UIs in other browsers and find out where they’re lacking. Although you can argue that our multitasking use case is quite different (because people frequently wipe all their tabs clean!)

[Sdaswani]

Looks very interesting @brampitoyo ! @colintheshots your thoughts on this fits in with your refactoring work, i.e., hopefully you can use that MVP as a base for this work?

[Sdaswani]

Also @brampitoyo should we replace this experience as the multitasking experience, or A/B test it with the old one? What about user education of the new experience (e.g., can these be explained in tool tips)?

[vext01]

Hi,

A firefox focus user here.

I'm really glad that this is being tackled. Since "request desktop site" and "find in page" have been implemented, I feel that tab management is the only lacking feature in firefox focus.

The proposed interface sounds efficient, but I wonder if it's obvious enough? And by that I mean, if I had not read this thread, would I know to:

• tap the location bar to see a list of open tabs?
• tap in the location bar to open a new tab?

I suspect the answer would be no, so why not add these actions into the vertical dots menu next to the location bar too?

Have you though about whether to keep the circle in the bottom right, with the number of open tabs? Under the new proposal it seems redundant, and covers part of the web page.

Cheers!

[Sdaswani]

Thanks for the feedback @vext01. User education / feature obviousness is a huge concern!

[vesta0]

@Sdaswani the idea is to build a new approach to tabs and replace the existing multitasking experience so yes we definitely want to A/B test it first. And if we decide to go ahead then we need to explore user education components such as contextual onboarding, interactive tutorials, home screen tips, etc.

[brampitoyo]

@vext01 This is a very important point to address:

[…] sounds efficient, but I wonder if it's obvious enough? […] would I know to:

• tap the location bar to see a list of open tabs?
• tap in the location bar to open a new tab?

Since the location bar is a starting point to go anywhere on the web (whether it’s browsing or searching), we think that all users will tap on the location bar at one point or another, and see what’s inside it.

Currently, we don’t show anything inside until they start typing a new keyword or URL – then search suggestions would show up.

There is a subset of users (I believe not in the majority) who will never see what’s inside the location bar. They always type new URL by erasing their history first and returning to the start screen. For them, multi-tabs is clearly not on their mind. They’re fine with “single-tasking”.

Ok. We’ve now established that:

1. Almost every user will tap on the location bar
2. The area underneath the location bar is currently empty

Our job is twofold:

1. Convey the fact that the new, visual tab manager has now moved from inside the FAB, to underneath the location bar
2. Teach users to reverse their habits (which is really tough)

Every other browser does this:

1. Open a blank new tab first
2. Then type URL

Our proposal was to do this:

1. Type a URL first
2. Then open it in a new tab

---

My first concept is to have a button on the bottom of the screen that visually says “tap here for the URL bar” when you have no tab open, and “tab here for the tab list” when you have more than one tabs open?

Unfortunately, to have a bottom bar, we’ll need to move the Erase Floating Action Button somewhere close by. I’m afraid that this will disorient some users.

Something like this:

---

My second concept is to avoid having users reverse their habits, and have an “Open new tab” button available directly underneath the URL bar.

In terms of being obvious, this concept is much more self-explanatory.

But there are two negative aspects to it:

1. By adding an “Open new tab” functionality underneath the URL bar, the UI now tries to do too much. Tapping on the URL bar should allow users to edit their URL (and opening the URL they’ve edited in a new tab, if they choose). But now, it can also open a new tab – this is a feature that has nothing to do with URL editing.
2. For users who are “single-taskers” (I argue that there’s a sizeable percentage – our stats say that most of our users erase while only running one tab), Focus loses its simple and pure browsing experience. The “Open new tab” button is so obvious, prominent, and unavoidable.

The benefit of my first approach (posted 2 days ago) is that, just like our current multitasking, it’s totally optional. We believe that people uses Focus differently than they use any other browser, so multi-tasking isn’t required.

But you can also argue that making multitasking optional means that it’s not as accessible as it should be. And a less accessible multi-tasking means that our users aren’t using Focus as much as they can.

---

To solve that specific problem, there’s also something to be said for giving users the option of staying on a single-tasking mode, when they first tap on the new URL bar:

That’s it from me this week. I hope these mocks can generate some good discussions, and I’ll approach it again with a fresh mind next week.

[brampitoyo]

Coming back again to some multitasking explorations.

Recall our design goals:

1. Open new tabs quicker than other browsers
2. Getting to the right tabs quicker than other browsers

We bumped into some problems:

1. In every other browser, users open a blank new tab, then type a URL. Typing the URL before opening a new tab feels upside down.
2. In every other browser, the URL bar is used for searching, not for tab navigation.

So we need to accomplish both of these things simultaneously:

1. Tasks should be achieved more quickly and feel simpler, minimal and more lightweight
2. But we can’t break expectations of how multitasking are supposed to work

---

In this iteration:

1. Like other browsers, the URL and tab views are separate.
2. To see all your tabs, flick up on the handle or drag it halfway up. Our data tells us that Firefox Focus users don’t open so many tabs. This “tab shelf” gives you just enough space to see 4–6 tabs at once. Scroll down the shelf to see more.
3. Ultimately, opening new tabs should be faster and feel more lightweight compared to other browsers. We have many ways to do it:
   • When the tab shelf is minimised, drag the handle all the way up. This means that you can open a new tab using one gesture!
   • When the tab shelf is open:
     • Flick up one more time
     • Drag the handle the rest of the way up
     • Tap the “New Tab” icon
4. What happens to the existing multitasking button? It remains consistent as an “Erase” button all the time. @vesta0 noted that some of our users wanted the Erase button to not be mixed up with the Multitasking button. This design keeps them separate.
5. Phone screens get bigger with every generation. It’s reasonable for our users to expect the address bar to be located up top. This is how every other browsers do it. But maybe we can try something ergonomic and reposition our URL bar down the bottom of the screen, so it’s more accessible by thumb?
   • Either way, tab shelf and opening new tabs can still be accessed easily:
     • If the URL bar is on the bottom, flick/drag up
     • If the URL bar is on top, flick/drag down

Demo video

[Sdaswani]

@brampitoyo should we expect new mocks?

[brampitoyo]

@Sdaswani Yes. I’ve just posted new mocks up above, and will keep iterating on this design until I find something that ties all the loose ends together.

It looks like we’re starting to solve some of the problems already:

1. Would users know to tap the URL to see a list of open tabs? Previously, the URL is doing double duty as a tab viewer. Now, the tab shelf is a separate UI that’s located nearby the URL, but accessed by flicking/dragging.
2. Would users know to tap in the location bar to open a new tab? Previously, you need to look for the “Open new tab” icon and tap it. Now, “Open new tab” is located inside the tab shelf, not the URL bar. And you can open a new tab with one gesture (drag all the way to the top), so it’s actually quicker than other browsers.
3. The only hitch: the new proposal seems efficient, but does it seem obvious that you can drag up to access the tab shelf and open a new tab? Maybe we need to change the handle icon into an upwards arrow. I’m not sure. But I was betting on the fact that having the handle alone is enough of a visual indicator that the user can swipe up (it works on Android 9.0 Pie and iPhone X, so it should work for us, right?)

[dimqua]

Our data tells us that Firefox Focus users don’t open so many tabs.

I don't know about other users, but I do not usually open more than few tabs in Focus, since I can't close them after reading if I want to, see #1362.

reposition our URL bar down the bottom of the screen

Great idea, FYI the similar approach for multitasking is using by the FOSS-Browser.

[Sdaswani]

Wow the URL bar at the bottom - does it auto-hide on scroll like it currently does at the top? I wonder if this could work if we kept the URL bar at the top still?

I'm not opposed to this change but it's a big change so we may want to user test it. Up to @vesta0 though.

[vext01]

Wow the URL bar at the bottom

Maybe I'm missing the point, but the UI doesn't need a total overhaul, you just need to add a "new tab" button somewhere. Then Focus is feature complete for me :)

[vext01]

Then Focus is feature complete for me :)

Well, perhaps reading mode, but that's another story.

Thanks!

[Sdaswani]

Fair point @vext01 - we also have to work on tab management, but I promise we'll keep it simple and direct. :)

[vesta0]

@brampitoyo I really like your innovative approach! It would be great to do some user testing to see what approach is more intuitive for an Android user while providing quick and simple tab navigation. Also mapping out the user journey (1-2 use cases) will help us understand which design aligns better with other features within the browser.

[brampitoyo]

@vext01 @dimqua Thanks for your feedback!

While repositioning the URL bar down to the bottom of the screen is a great idea (one-handed navigation), I also agree with @Sdaswani and @vesta0 that it will need a lot of testing, and has little to do with multitasking.

Besides, the idea can still work even if we keep the URL bar up top.

So I’m updating my proposal to address that.

Now the URL bar sticks on top of the screen. The tab shelf sticks on the bottom of the screen. The Erase button stays where it is currently, with no change in functionality.

To open a fresh new tab, you can either:

1. Access the tab shelf by tapping on it, or flick it up. Then, flick up one more time.
2. Or, swipe up from the minimised tab shelf, most of the way towards the top of the screen.

Method 1 is shown in this demo video

Method 2 is shown below:

---

Let’s map out our user flow, and see whether our design really makes things faster.

There are three main use cases for multitasking, ordered by most to least common:

1. Opening URLs contained within the current page in a new tab
2. Opening unrelated URLs in a fresh new tab
3. Finding/revisiting URLs already opened in a tab

In all mobile browsers, opening URLs contained within the current page in a new tab is a very common action. In fact, we already have this feature today. You can do it using the long-press context menu:

Opening unrelated URLs in a fresh new tab is less common, but is still very important. This multitasking v2 issue mainly deals with this problem:

Finally, finding/revisiting URLs already opened in a tab is even less common, but it doesn’t hurt to have it if we can shorten the steps:

You can see that, generally, our design shorten the steps that it takes to accomplish the tasks above.

[Sdaswani]

Wow @brampitoyo I love what you have done here - I think Method 1 is a winner!

[brampitoyo]

@Sdaswani Best of all, we can do both!

In the beginning, almost everybody will perform method 1: open/tap on tab shelf, read instruction, then swipe up again to open new tab.

Pretty soon, some users will learn that method 2 is available. It’s what would happen if you perform method 1, then instead of stopping in the middle, you continue to hold and swipe up.

In the end, some would prefer method 1 (flick twice), and some would prefer method 2 (swipe most of the way up). That’s fine. As long as opening new tabs feel light and fast, our goal is achieved.

[Sdaswani]

Understood @brampitoyo Method 1 shows JiT info and then users learn and we go to Method 2, just like our home screen tips disappear when folks demonstrate they have learned. Awesome!

[dimqua]

I'm concerned about wasting of space at the bottom which is used just for showing a number of tabs.

[Sdaswani]

Hmm that is a fair point @dimqua .