1214332 - Consider merging tab queue & tab received (via Sync) notifications

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect)

Description

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Anthony, in bug 1208268 comment 10 Nick brought up the idea of making the tab queue code similar to sync and I wondered if we shouldn't just merge the tab queue notifications with sync – what do you think?

If we don't merge the notifications, we can still merge the code. bug 1208268 adds a TabReceivedBroadcastReceiver that we can repurpose for the task (and Tab Queue may have something similar).

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

Would the copy (text) be the same? Probably not. Let's not push the UI's together, even if the receiver code is shared.

Comment 2

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

There is inconsistency in how the notifications are handled too: sync will send out a generic VIEW Intent and thus prompt the user to choose a browser to open with, whereas tab queue will open directly in Firefox. However, if you open Firefox, both notifications will be fulfilled. Funky.

Leaving NI on for antlam to share his thoughts.

Comment 3

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Attachment: IMG_20151015_163608.jpg

I've drawn out the matrix of possibilities out and it seems like merging would be a good idea.

Currently, Fennec's two main notifications are for "# tabs waiting" (tab queues) and "# tabs received" (send to other device). Next to push notifications, that would give us 3 separate notifications. This might be a bit much to our users.

Our current notifications lead to two parts of our UI when pressed (the 'outgoing' lines in my beautiful drawing) 

1) A new tab or an existing tab 
 - for when there's 1 tab received, 1 tab waiting, or 1 web notification from a given website.
2) The Tabs tray 
 - for when there's multiple tabs received, multiple tabs waiting, or multiple web notifications from 1 or more website

Not merging these but having them lead to the same parts of the UI seems confusing. 

E.g. If you've queued a couple tabs and received another two from another device, clicking on either notification will open the tabs tray. At this point, you should see all your tabs. Which might mean we should clear the notifications also.

So, if we merge our tabs received and queued notifications, that would bring us down to 2 notifications. 1 for websites, and 1 for user triggered Fennec features like Open in background/ Tab queues and "Send tab to device".

Then, we just have to figure out the copy for this new merged notification. Something like:

+---------------------------------+
|                                 |
|  ****   4 tabs                  |
|  ****   Firefox                 |
|                                 |
+---------------------------------+

Where **** is the Fennec build icon. 

Tapping on this will open the Tabs tray (cause there's more than 1 tab in question). We might see a couple "spinning" tabs from this. This might be reason to address bug 755395 in the same breath? 

Thoughts?

Comment 4

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

That all makes sense to me.

Worth noting that until bug 1183659 lands, the tabs received notifications appear one for each tab received and prompt the user to open any appropriate app (e.g. Chrome, Google Maps for maps links) when clicking the notification.

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Anthony Lam (:antlam) from comment #3)

> Currently, Fennec's two main notifications are for "# tabs waiting" (tab
> queues) and "# tabs received" (send to other device). Next to push
> notifications, that would give us 3 separate notifications. This might be a
> bit much to our users.

Only if they're all shown at the same time.

> Our current notifications lead to two parts of our UI when pressed (the
> 'outgoing' lines in my beautiful drawing) 
> 
> 1) A new tab or an existing tab 
>  - for when there's 1 tab received, 1 tab waiting, or 1 web notification
> from a given website.
> 2) The Tabs tray 
>  - for when there's multiple tabs received, multiple tabs waiting, or
> multiple web notifications from 1 or more website

This is not exactly true for "# tab received" notifications. Those could be opened by Chrome or Maps or whatever. "# tab waiting" and "web notification" are always destined for Firefox.

> +---------------------------------+
> |                                 |
> |  ****   4 tabs                  |
> |  ****   Firefox                 |
> |                                 |
> +---------------------------------+
> 
> Where **** is the Fennec build icon. 

I don't like that I have lost context. Which were the tabs I was queuing from other apps? Which were the ones sent from Laptop?

Honestly, this seems premature to me. We've had Tab Queues and Sent Tabs together for a while, and I have not seen reports of issues.

Web Notifications will be tricky on their own. Merging all Web Notifications together and opening the Tabs Tray doesn't seen right to me. Each Web Notification has a specific message on it from the specific domain. We should keep these somewhat separate so people can see those specific details.

Comment 6

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to Mark Finkle (:mfinkle) from comment #5)
> This is not exactly true for "# tab received" notifications. Those could be
> opened by Chrome or Maps or whatever. "# tab waiting" and "web notification"
> are always destined for Firefox.

Note: standardized intents can only have one URI so if we change to aggregating the tab received notifications (i.e. "# tab received"), in order to maintain this behavior, we'd have a build a custom chooser that will select an activity to open all of the uris. We can't show for each because it's unclear how multiple started activities can be shown. It's unclear that we can pass X intents for X uris to the same Activity and have it handle them correctly.

As such, in bug 1183659, where the work to aggregate notifications is taking place, we decided to directly open Firefox when a "tab received" notification is pressed (additionally because it's confusing that "tab received" opens another app and "tab waiting" does not).

What do you think of this approach?

(another explanation of this is in bug 1183659 comment 20)

Comment 7

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Mark Finkle (:mfinkle) from comment #5)
> (In reply to Anthony Lam (:antlam) from comment #3)
> 
> > Currently, Fennec's two main notifications are for "# tabs waiting" (tab
> > queues) and "# tabs received" (send to other device). Next to push
> > notifications, that would give us 3 separate notifications. This might be a
> > bit much to our users.
> 
> Only if they're all shown at the same time.

Right, so nothing should change if they aren't all shown at the same time. I.e. we don't merge. 

So there'll be no difference for our current users.

> I don't like that I have lost context. Which were the tabs I was queuing
> from other apps? Which were the ones sent from Laptop?

Yeah, and I think that's a fair point. This was something I was struggling with too. But since our users only have 1 tray each, it would be harder to have this tray contextually change based on how you opened it and from where.

I also looked a lot at the Android guidelines [1]. Beyond aligning ourselves with system guidelines, it made me very cognizant of "notifications fatigue". I wanted to "approach with caution" here because Android makes it very easy to disable notifications for any given app and we'd find it hard to get that ability back if we give them a reason to do so. 

[1] http://developer.android.com/design/patterns/notifications.html
 
> Honestly, this seems premature to me. We've had Tab Queues and Sent Tabs
> together for a while, and I have not seen reports of issues.

It might be a bit premature, but I wanted to at least file this bug early and define a baseline UX here first. I'd like to simplify our logic now and reduce UX issues in the short term. Then expand on that granularity (in terms of control) in the future. 

My worry here is that there are too many "things to keep track of" in our users head and we're over complicating the features with nuances that will probably get lost for new users. My goal is to ease them in and flatten the learning curve here as much as possible.

> Web Notifications will be tricky on their own. Merging all Web Notifications
> together and opening the Tabs Tray doesn't seen right to me. Each Web
> Notification has a specific message on it from the specific domain. We
> should keep these somewhat separate so people can see those specific details.

This is definitely tricky. But not merging them seems to be dangerous since we have no idea how these might be used. 

We might be able to just merge them based on the source (website) for the time being. My original thinking here was to simplify the matrix of options and scenarios but on second thought, perhaps the prompt in bug 1212606 is enough of a filter and control for our users.

I'm open to just merging Web notifications based on source. That would also empower these websites which is nice. :) 

NI-ing chenxia for context since we just talked about this for bug 1212611.

Comment 8

[Chenxia Liu [:liuche]]

We should stay aware of how "annoying" Firefox is in the Android system tray, and try to minimize that. The biggest reason I've heard people don't use Nightly/Aurora is that the Firefox notification is always in the tray. This bug makes sense to me for addressing that problem, but yeah, there is definitely loss of information. But, contrary to our Firefox-centric world, I'd guess that most users would be happy with a single notification that they have tabs that they have "opened in the background", and if things are going to the same place (tabs tray), this makes sense to me.

Also, I think merging tabs queue/sent tabs makes sense with respect to simplicity, because otherwise we need to track if users have "seen" their tab queue (tabs tray) vs their sent tab (single tab) vs the multiple sent tabs (in the tabs tray).

Anyways, those are my thoughts. I'd rather go for simplicity, and maintain less state, even if we're losing information (that may or may not be interesting to the user).

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

The Nightly/Aurora "update" is an example of a notification that appears everyday and does not prove it's value (why should I update right now?).

Send tabs and Queued tabs are higher value (IMO) since the user initiated the action. I don't put them in the same category as the update notifications.

I'd really love to see a mockup of how this would really look and how it would really work, because I am very worried that we are losing a lot of useful context by jamming these notifications into a single notification.

Also, how often would this situation even be hit? Are we trying to simplify a situation that rarely even happens? Is this the highest value project to work on right now?

Comment 10

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

I think there's some good points here and I'm happy to let this simmer here for a bit. After cleaning up the copy in bug 1183659, we should be in pretty good shape for a while even though we aren't fully abiding by the design guidelines I think our value (for example, things like opening received tabs in another app) justifies the divergence.

Comment 11

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.