Fenix: Let users know they can open a site in a native app

[vesta0]

User Story

• As a user, I want to know if my browser allows me to open a supported site in a native app.

Often users are unaware that this is an option we provide in settings, and think that Fenix doesn't support handling such intents or is broken.

Acceptance Criteria

• I learn that my browser can open a supported site in a native app

See UX recommendation here: https://docs.google.com/presentation/d/1bH89EfNvDj_u2VeD7gB3swtg82inBUic5x6sEIThGfA/edit#slide=id.p

[abodea]

Hello, @vesta0 I added this https://github.com/mozilla-mobile/fenix/issues/8380 a while ago as a followup from https://github.com/mozilla-mobile/fenix/issues/5905.

[Poopooracoocoo]

Could do something like Fennec and have a button in the toolbar. I would expect the menu item to be hidden when the button is visible in the toolbar.

[vesta0]

For UX: once you pick this up please also see comments in #8380

[brampitoyo]

@vesta0 @Poopooracoocoo Clarifying question: won’t sites that want to open their link in external apps actively try to do so?

If that’s the case, then the solution I’d propose is to set our “Open link in apps” policy to be ON by default. This way, users won’t think that our intent-handling is broken.

If users are on Private Browsing, then we’ll warn them before opening those external apps – they can still do so, but they have to confirm every time. On normal mode, we’ll just open the external app by default, without confirmation, unless the Setting menu item is toggled OFF manually.

Thoughts?

[Poopooracoocoo]

Clarifying question: won’t sites that want to open their link in external apps actively try to do so?

yup. *glares at Spotify*

If that’s the case, then the solution I’d propose is to set our “Open link in apps” policy to be ON by default. This way, users won’t think that our intent-handling is broken.

I think it should be on by default too.

If users are on Private Browsing, then we’ll warn them before opening those external apps – they can still do so, but they have to confirm every time. On normal mode, we’ll just open the external app by default, without confirmation, unless the Setting menu item is toggled OFF manually.

Sounds good! That's what Chrome does too.
I don't know if I'd expect the confirmation to appear when I've turned off "Open link in apps". I prefer Fennec's button to open a link in an app. It could even sit in the menu instead of in the url bar if that's too prominent.

[vesta0]

The "open in app" option already exists in the browser menu but many users tend to miss it and think the browser is broken.

In Fennec, "Open links in apps" is disabled by default and we have signals from Firefox users indicating that they prefer it this way but this is worth looking into and re-validating.

Worth noting that there are 2 scenarios here:

-User taps on a link in an external app such as Gmail, and expect the link to open directly in youtube, Google Play, etc. We should always allow that (and I think it's actually an OS setting).

-User taps on a link in side Fenix expecting to either be directly taken to the external app, or to open that link inside Fenix. Our default currently is to open the link inside Fenix but surface an "open in app" option in browser menu for the users.

[Poopooracoocoo]

User taps on a link in side Fenix expecting to either be directly taken to the external app, or to open that link inside Fenix. Our default currently is to open the link inside Fenix but surface an "open in app" option in browser menu for the users.

like fennec, it could show up in the urlbar or toolbar. or even appear temporarily in the toolbar and "fade into" the menu or something like that

the spotify case is very annoying and they try all they can to direct me to either the play store or the spotify app. i hope that can be handled

-User taps on a link in an external app such as Gmail, and expect the link to open directly in youtube, Google Play, etc. We should always allow that (and I think it's actually an OS setting).

yeah, that's an OS setting and not something for fenix to handle but the open in app options in FF Focus have been so nice

[brampitoyo]

@vesta0 @Poopooracoocoo Yes. We have to think of modifying these default behaviours carefully.

The most conservative solution is the one we have today:

• Set default policy: “Open in app” = OFF
• When “Open in app” is available, show it inside main menu
• Cons: many users tend to miss it and think Fenix is broken

---

A slightly tweaked solution from original (proposed by @Poopooracoocoo) might look like this:

• Set default policy: “Open in app” = OFF
• When “Open in app” is available, show it in a more prominent place (appear temporarily in toolbar, etc.)
• Cons: still easy to miss, if you don’t know where to look

---

What I proposed is a solution that’s a little more involved, but I think lines up with user expectation.

Let’s look at “Open in app” links from some of the most popular sites:

(Twitter was opened from iOS, as the Android version didn’t offer a deeplink).

What can we observe from this very short survey?

• Many links that open apps don’t break expectation
  
  
  
  • They’re not blue text links that you thought will open in the browser, but will sneakily redirect you somewhere you don’t expect
  
  
  • Instead, they’re often shaped like buttons and have clear labels. They imply that, whatever destination you’re about to go to, it will “Open somewhere else”, not “Open in the same tab”
  
  
• It’s impossible for a website to automatically redirect you to another app, without you manually tapping on the link first

Therefore, my proposal was to set the default policy of “Open in app” to ON.

Why? Because it’s nearly impossible to get your expectation wrong. Most “Open in app” links are clearly labelled, so when you tap it, we can safely assume that you do it with the full knowledge that you indeed want to open another app.

But this rests on the assumptions that apps always label their links clearly. And @Poopooracoocoo, it sounds like Spotify really likes to be sneaky? Can you provide examples of this happening? Better yet, do you know of any other sites that like to be sneaky?

My point is, the more sites try to be sneaky, the more we should try to protect users by preventing unintended redirection to apps. But if most sites clearly label their links, then we can set “Open in App” to ON without much problem.

[Matth7878]

For what is worth if I use the browser it is not to open link in other apps. If it was I would directly use the native apps.

What's actually happen is that I'm looking for something or reading an article which contain a link to a video, a reddit thread or whatever and I want to check it or save it for later in another tab because right now what I am doing is not an activity related to one of these native apps. (And I hate all the spam they use to force you to use the native app)

Eventually I will open it in native app because it might be more convenient or my activity is about to change. Or I don't care to lose time watching an ad (which would have been blocked thanks to extension)
It's why having previously an icon in the URL bar was really convenient. But I understand we do not have much space.

Yet I think it's better to have open in native apps as a default for people who don't care and never take a look at preferences.
Users could still disable this to not open in native apps and a red dot could be shown on the three dots so there would be no space lost in the URL bar. It would point out that it is possible to open in native app via the menu. (Similar to the blue dot to indicate that something is new which is quite visible)

[Poopooracoocoo]

a red dot could be shown on the three dots so there would be no space lost in the URL bar. It would point out that it is possible to open in native app via the menu. (Similar to the blue dot to indicate that something is new which is quite visible)

it reminds me of this:

8474, #7408, #7659 and #8800

Some users assume blue dot is highlighting reader mode being either a new feature or notifying that we made changes to reader node. They expect the blue dot to go away after they interact with reader mode once, and they find it confusing when it doesn't.

something like #6639 would be nice imo

[Matth7878]

It's not really the same as the blue dot.
The blue dot IS annoying because it's not clear what it means. It appears to indicate new features and when reader mode is/was available. (Apparently no longer true in nightly)
It is annoying because it's extremely visible and it feels like they want to force you to use a feature you may not care about. (I don't understand how they could not found it annoying, sometimes it really feels developpers are not users... 😕)

In what I propose the red dot would appear only if you disabled open link in native app.
But maybe user don't want it. If so the issue should be "add a specific preference so user could have an indication they can open a site in native app".

All in all I don't know what you can do. It's either adding an icon in URL bar, next to the URL bar, on the three dot or nothing. Like you I would prefer it like it was in fennec but it feels they don't want to use URL bar space. :-/

[Poopooracoocoo]

@Matth7878 simple solution would be to merge the page info and tracking protection buttons 😄 Firefox 70 split them on desktop and it's rather annoying as the tracking protection icon is coloured too.

[AmyYLee]

@brampitoyo for follow-up (not sure if this is needed since moved to backlog)

[brampitoyo]

TL;DR I recommend setting our default “Open in App” policy to ON.

@Matth7878 wrote a really important point:

… it's better to have open in native apps as a default for people who don't care and never take a look at preferences.

Most of our users want their browsers to “do exactly as it says on the tin”. Meaning: when websites display links that says “See in Reddit app”, “Open in the Twitter app”, “Switch to our app”, etc., most of our users would expect those links to switch to the native app.

Recall the original problem that was posted on comment 0:

As a user, I want to know if my browser allows me to open a supported site in a native app.

By setting our default “Open in App” policy to ON, we would solve the original discovery problem that this issue posed.

Some of us would prefer to open in native app only by choice. We prefer links to not “do exactly as it says on the tin”. We can go into Settings and manually set “Open in App” to OFF.

Since the only way to turn “Open in App” OFF is manual, every user who turn it off will know that it’s not Fenix’s default behaviour. Since it’s not default, then there has to be a way to override it temporarily, to open in app on a one-off basis.

When you view a website, Fenix doesn’t have too many tap targets:

• Shield icon
• Lock icon
• Web address
• Three-dot icon

If you were to guess, you’d probably look inside the three-dot icon. Other Android apps behave this way and put “the rest of the features” inside a three-dot or three-line icon. Your guess is correct. Tap the three-dot icon, and you’ll find a dedicated item to “Open in App”.

I know that we talked about using or not using the blue dot. I also know that @apbitner is looking into a better means for feature discovery. At the same time, I also want to emphasise the power of simply setting our default “Open in App” policy to ON, letting some users manually switch it OFF, and keeping the one-off override menu item inside the main menu where most people would guess correctly and be able to locate.

[vesta0]

@apbitner @brampitoyo @betsymi so is the UX final recommendation is to set our default “Open in App” policy to ON?

Please confirm and also create a ticket to track the discoverability aspect of this setting. We should have a way of letting users (especially migrated ones) know that they can change this setting.

[liuche]

Not enough time / information to do this before release, so removing this from "release" column.

[apbitner]

We will work on a solution to allow users to choose their preference post-launch

[liuche]

hey @betsymi 2-way sync isn't working, so please comment here in github !

[betsymi]

hey @betsymi 2-way sync isn't working, so please comment here in github !

• Keep default setting of Open in App OFF
• Keep global setting under Advanced
• When user visits site where they have the native app installed, surface CFR that informs them about their option to turn the global setting on
• CTA button on CFR deep links to settings where user can turn on the setting
• Cadence: One time only, first time user visits native site
• Blue dot: Appears on second visit to a site where user has native site installed.
• PWA: Switch cadence to 3x user visits site. Current cadence is first time.

[Mugurell]

Thank you @betsymi for the comment above!

I think we still need specs and strings for:

When user visits site where they have the native app installed, surface CFR that informs them about their option to turn the global setting on
CTA button on CFR deep links to settings where user can turn on the setting

Have not seen the above CFR in the abstract for this.

[betsymi]

Lots of confusion around this one due to syncing issues between JIRA and here. Ultimately the path forward is to use the banner component from #11582 with the following strings.

You can set Firefox to automatically open links in apps.
DISMISS GO TO SETTINGS

Implementation details:

• Keep default setting of Open in App OFF
• Keep global setting under Advanced
• When user visits site where they have the native app installed, surface banner that informs them about their option to turn the global setting on
• GO TO SETTINGS link on banner deep links to settings where user can turn on the setting

[Poopooracoocoo]

Isn't a banner pretty intrusive and annoying?

[betsymi]

Isn't a banner pretty intrusive and annoying?

We have decided on this solution because a banner is less intrusive than the previously proposed purple bubble CFR, which blocks a portion of the screen and the content behind it. Banners also allows the user to either ignore them or interact with them at any time.

[Poopooracoocoo]

what about a button like fennec's with an educational tooltip (or whatever)?

[mcarare]

This seems it is not ready for eng. Is there any abstract for this yet? TY!

[liuche]

@betsymi @lime124 so if we are reusing the banner from #11582 (which looks like https://app.abstract.com/share/4341a8c8-02f7-48a0-8952-98be0aef4c80?mode=design&sha=a3633820b169e4bc6ac37fe927c31d169dcd45d0 ) is this banner in the tabs tray too, or is it somewhere else?

We'd like to get these mocks earlier rather than later, since this was supposed to be in the current sprint, but the UX changed after we assigned it to a team. Currently it's in Hershey, but the tabs tray banner component is in skittle.

[liuche]

Victoria will be helping us out with the UX here, but since this feature likely won't make this sprint, @mcarare could you pre-land the strings so that if we need to, we could uplift the feature.

[violasong]

Hi all! Here are some answers based on Material with browser-specific adjustments. (Thanks to Bram, Adam, and Betsy for the advice :).) Let me know here if there are any concerns.

Is it pinned to the toolbar and overlaps web content? Should work similarly for both top and bottom toolbar?

• For top toolbar: The banner should be pinned right under the toolbar. If the toolbar scrolls out of view, the banner follows it and then pins to top.
• For bottom toolbar: The banner should be pinned to the top.

Wireframe below. Tentatively documented in UI Components deck. This behavior does cover up content; however, it seemed important to pin the banner to differentiate it from 3rd party content.

What if the toolbar is hidden, does it still show?

Yes.

Is the only way to dismiss the banner by clicking “Dismiss” or does it dismiss if the user interacts with the page?

Correct, it requires clicking "Dismiss" to dismiss.

Are there other cases where it dismisses? (like if the user navigates away from the page)

The banner should remain if the user navigates to another page under the same domain, but dismiss if the user goes to a different domain.

[Poopooracoocoo]

would that banner disappear forever once the user interacts with the banner?

[mcarare]

@liuche @betsymi Given the fact that the UI for the CFR has changed from the info in comment 0, I am not sure the same string will apply:

"You can set Firefox to automatically open links in apps. Tap to go to your settings."

Given that, we would need confirmation for strings for the message and for the action button. I have submitted a PR : https://github.com/mozilla-mobile/fenix/pull/14211, please provide feedback on that. TY!

[mcarare]

would that banner disappear forever once the user interacts with the banner?

In the current specs, like other info messages already in the app, it will show up just once.

[betsymi]

@liuche @betsymi Given the fact that the UI for the CFR has changed from the info in comment 0, I am not sure the same string will apply:

"You can set Firefox to automatically open links in apps. Tap to go to your settings."

Given that, we would need confirmation for strings for the message and for the action button. I have submitted a PR : #14211, please provide feedback on that. TY!

The string is in a later comment.

You can set Firefox to automatically open links in apps.
DISMISS GO TO SETTINGS

[mcarare]

@violasong , just FIY, there is currently no Android API implementation for the Banners from Material design. This will require a custom solution to be implemented in Fenix/ AC. Also, another concern that may arise is the lack of consistency for in app-messages that improve feature discoverability.

[violasong]

Hi @mcarare, I understand the concern. My rationale for having a banner in addition to the purple bubble CFR:

• Compared to the purple bubble CFR, the banner is visually streamlined and less interrupting. The user can still interact with other parts of the UI before dismissing it.
• The banner is also more neutral in tone, which fits the case of recommending a setting. I expect this will be useful for more cases in the future. IIUC the purple CFR is more of a fun highlight for new features.

[liuche]

We'll be using the same banner item in #4118 - can we reuse the styling from that bug? unfortunately that banner is in the tabs tray, so it's not a component that can just be re-used, but needs to be re-implemented for web content.

[mcarare]

I began work for this, but I'm not sure the design specs are final, for example, the message text color is something we use in the app just for text_scale_example_text_color. Also, should the button match style of other buttons in the app?

[violasong]

I believe the text and button styles should match the alert UI (@topotropic can confirm)

[yoasif]

I haven't seen a bug filed to optionally bring back the older Fennec functionality as an option, which users are asking for in Google Play reviews and on social media. I personally liked this feature and definitely believe that it is more convenient and discoverable than being buried in the main menu.

Please see https://github.com/mozilla-mobile/fenix/issues/14705.

[rbtcollins]

Just like to note that I'm amongst the crowd that got confused, and stopped using firefox for android on my new phone, where I'd given it another go after the recent release - precisely because of this. Not because I love 'open in app', but because my travel agent uses 'open in app' as a workflow to hand off to their app that breaks and is not replicatable via the website (this is flight centres app in NZ ; its a terribly broken UX flow, but there it is).

[softvision-miralobontiu]

Hi all!
I've tested on the latest Nightly build from 9/10 with HTC 10 (android 8), the following:

• the default setting of "Open links in apps" is set by default to OFF,
• the global setting is under the Advanced section in Settings,
• the banner that informs the users about their option to turn the global setting on is displayed only once, when the user visits the site where they have the native app installed,
• the CFR is "You can set Firefox to automatically open links in apps.
  DISMISS GO TO SETTINGS",
• tapping on the "GO TO SETTINGS" button on banner deep links to settings where the user can turn on the setting.

Note:

• Having the "Open links in apps" option enabled/disabled in Settings, triggers the CFR when the user visits the site (where they have the native app installed) for the first time.

[violasong]

Hi all! Thanks for your work on this. I just saw the Open in App banner come up in Nightly; however, I already had Open in App turned on in my Settings. It seems that the banner shouldn't appear in this case. Could someone else confirm that this is happening?

Also, in dark mode as seen below, I realized it needs a bottom border (same border styling as the URL bar's top border).

Should I file new bugs for these? CC: @vesta0

[vesta0]

@betsymi ^^

[betsymi]

Confirming that the banner should NOT appear if you already have open in app turned on in your settings.

[vesta0]

@softvision-miralobontiu @mcarare ^^

[mcarare]

IMO additional requests that were not in the original design and specs should be opened in a new issue, for a better tracking of changes, sizing and sprint planning. Opened https://github.com/mozilla-mobile/fenix/issues/15150 for the follow-up issue, closing this as per comment: https://github.com/mozilla-mobile/fenix/issues/9506#issuecomment-690109585. Thank you all for your feedback!