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

┆Issue is synchronized with this Jira Task

[abodea]

Hello, @vesta0 I added this #8380 a while ago as a followup from #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.

[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).

[lobontiumira]

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 #15150 for the follow-up issue, closing this as per comment: #9506 (comment). Thank you all for your feedback!