Provide in-app communications to users about new or existing features

[bbinto]

Why/User Benefit/User Problem

• Help users explore new features that might be useful for them

What / Requirements

• Build a control (outside of app releases)
• Show hint inside app (e.g. home screen)
• Setting to turn of hints
• Should it be built as an Android component?
• Define locale (we might want to run it for US/CA only)

Acceptance Criteria (how do I know when I’m done?)

• Allow slicing users based on specific events
• Probes and system to perform analysis of results

[Sdaswani]

@pocmo @csadilek do you think building this as an android component makes sense? We would want to use them in Fenix, at least.

[pocmo]

@pocmo @csadilek do you think building this as an android component makes sense? We would want to use them in Fenix, at least.

Yes, absolutely! That's what I wrote on Slack today too :D

We will need to define what exactly the component can/should do. But apart from that I 100% agree: We wanted to have contextual hints in all our apps (even way back in Fennec) but we never got to it because it requires a good amount of work. It would be great if our components could provide enough tools so that this will be easy to add to all our apps going forward.

I'll wait what @brampitoyo comes up with so that we can start to make a plan. @aminalhazwani may be interested in this too. Let's see if we can come up with a shared vision for contextual hints in our apps.

[Sdaswani]

Thanks @pocmo ! I think the UX side of things is still up for creation by Bram and Amin, but one thing we definitely need is a local event and trigger system to fire the UX side of things. Can we get started on that?

Some ideas / questions:

• Should the telemetry library start caching 'local' and 'remote' events, the latter of which get sent up to UT?
• Would Remote Settings be able to send down 'hint configurations', i.e., a json of event trails that should fire contextual hints?
• Can Remote Settings also send down hint copy (potentially localized) so we don't have to ship new app versions to provide new hints?

[pocmo]

Thanks @Sdaswani! I filed https://github.com/mozilla-mobile/android-components/issues/351 and copied some things over.

[brampitoyo]

From the UX side of things, I know that our team has come up with a Firefox In Product Communications strategy. As far as I know, it’s only been applied to desktop, but a mobile strategy is most certainly in the works. We want to make sure that we stay consistent to that strategy.

Here are my thoughts for the moment:

• There are, I think, two ways to surface features in the product.
  • Passively. These hints are general purpose. For example: tips or snippets on the home screen.
  • Actively. Hints specifically geared towards your current activity. For example: contextual feature/add-on recommender
• The more active a hint is, the more potential we have to interrupt the user’s current activity. Therefore, the easier it should be to dismiss, and the less it should repeat (maybe it should only be shown once, and not repeat again).
• The more active a hint is, the more we have to worry about false positives. That is: showing hints to people who have used the feature before. For example, we should avoid showing a hint about multi-tasking if that user has opened links in a new tab before.
• So far, there are at least three features that we’d like to showcase. Here they are, along with the set of user actions that will trigger them. Are there others that you can think of?
  • Open in new tab. Trigger:
  • Type a search term, tap Go
  • Tap a search result
  • Tap back button (either through system, or through menu)
  • Show hint
  • Add to home screen. Trigger:
  • Type a URL, tap Go
  • Navigate elsewhere
  • Tap URL bar
  • Retype the same URL as step 1, tap Go
  • Show hint
  • Turn tracking protection off. Trigger:
  • Type a URL, tap Go
  • Firefox Focus detects that the website is missing a lot of elements
  • Show hint

[Sdaswani]

Thanks for your analysis @brampitoyo ! Any way we can highlight the search engine customization? How about adding autocomplete URLs? Most importantly, how about asking the user to set their default browser?

[brampitoyo]

@Sdaswani Those three features (search engine customisation, autocomplete URL, default browser) will help me think of more trigger for active hints. Thanks very much for the ideas!

[brampitoyo]

Search engine customisation. Trigger:

• User has set search engine value as x
• Type URL of a search engine which is not x, tap Go
• Show hint

Autocomplete URL. Trigger:

• Type a URL which is ≥12 characters long, tap Go
  • “…the average .com domain name is 12 characters long” according to VeriSign and DataGenetics
  • Website loaded successfully
  • Show hint

Default browser. Trigger:

• When using any other app, the user chose to open a link in Firefox Focus
  • Practically, this means tapping the Share button, then selecting Firefox Focus from the list
• Switch app to Firefox Focus
• Show hint

[brampitoyo]

Some more thinking-out-loud around this topic:

• We need to make sure that hints are reasonably good at predicting user intent, and work in harmony with each other
• Reasonably good means that hints only appear when enough actions have been triggered.
  • For example: the hint for Open in a new tab may require more than a single tap + back to show up. At that point, we’re still not sure whether multi-tasking is desired or whether the search result was simply wrong. But if they tap links and tap back a few times, then we can reasonably guess that the user may benefit from multi-tasking
• Working in harmony means that each hint is spaced out sufficiently (although I’m not sure what this means yet. One hint per app session? One hint every couple of days?)
  • Example 1:
  • The hint for Open in a new tab appears and is interacted with. However, the user never proceeds to use “Open in a new tab” feature.
  • Then the user proceeds to type a long URL.
  • Normally, this will activate the hint for Autocomplete URL, but because a different hint was just showed, this hint will wait.
  • Example 2:
  • The hint for Open in a new tab appears and is interacted with. Furthermore, the user actually uses “Open in a new tab” after the hint shows up.
  • Then the user proceeds to type a long URL.
  • Because the user has taken two actions (view the hint + acted on the hint), then the hint for Autocomplete URL will wait for a longer time than in example 1.
  • Example 3:
  • The hint for Open in a new tab appears, but is never interacted with.
  • Then the user proceeds to type a long URL.
  • Because the previous hint was never accessed, this should activate the hint for Autocomplete URL. It’s now waiting for the user to access it.

[brampitoyo]

Our in-product communication strategies are already clear (there’s a slide deck I can share – but not sure if a video of it exist), but here are a few low-level, tactical principles that we can use to implement hints. I’m summarising everything that was written up above:

• There are two kinds of hints: passive (e.g. tool tips) and active (e.g. contextual feature recommender). This issue is about designing active hints.
• A hint should only be shown to users who have never accessed the feature showcased in that hint.
• Active hints can hinder user flow, so it should be easy to dismiss and not repeat over and over again.
• Hints should only appear when enough actions have been repeated enough times to reasonably guess user intent.
• Hints should be spaced out sufficiently, and should definitely not appear one right after the other.

[bbinto]

Thanks for all the input on this big topic.

I'd love to brainstorm a bit more on the features we want to highlight in the future.

• I had started this doc last year (!) when we talked about it.
• I'd love us to work with @mmccorks to identify more features that retain users well and how to run the ideas for contextual hints through A/B tests, cheap and dirty!

As of now, to keep things rolling, I'm in favour of starting with some of the ones @Sdaswani mentioned, maybe except the search engine customization as I don't think that's as intuitive right now.

To get started, I'd suggest to only focus on the following:

• Set default browser (one of our KRs)
• Add to homescreen (we know users who understand this feature, retain better) (- Autocomplete URL via tap)

[brampitoyo]

We can show in-app communications that are more private, more direct, and more respectful of our mission by utilising two principles:

1. Just-in-time information. Instead of showing hints after users do certain actions (our prediction may be inaccurate), show information next to features and menu items themselves, and show them permanently (no tracking required).

We have just-in-time information for:

1. Tracking Protection. Place: main menu.
2. Add to Homescreen. Place: main menu.
3. Set as Default Browser. Place: Settings page.

---

2. One-tap actions. Instead of telling users how to access features, give them the ability to execute that feature in just one tap, and allow them to do it all the time (no tracking required).

We have one-tap actions for:

1. Add custom URL (add to autocomplete). Place: when user tap on the URL bar and the URL hasn’t been added to the list yet.
2. Open link in new tab. Place: when user taps on any link for the first time.
3. Set as Default browser. Place: Settings page. Instead of redirecting users to the system Settings app, we trigger the default browser selection UI, and ask users to choose “Always” on Firefox Focus.

---

Should we file individual issue for each information/action? An issue has already been filed for Set as Default Browser and Add to Homescreen, so I will post my mockups there.

[Sdaswani]

@brampitoyo said:

Just-in-time information. Instead of showing hints after users do certain actions (our prediction may be inaccurate), show information next to features and menu items themselves, and show them permanently (no tracking required).

@brampitoyo and @bbinto - do we know that users are accessing these features or menus often enough for these tips to be seen very often? For example, if a menu is accessed by 1% of users on a daily basis, an associated tip is not going to influence them very often (if at all).

[brampitoyo]

@Sdaswani wrote:

For example, if a menu is accessed by 1% of users on a daily basis, an associated tip is not going to influence them very often (if at all).

Looking at the data, out of 400 million foregrounds, settings has only be accessed some 2 millions times. Not very many people will ever see this tip.

Out of 400 million app foregrounds, the menu has only been clicked some 9 million times - that's about a 2% chance users will ever see this tip.

This problem occupied me all night, and it turned out that we have an obvious solution that’s been overlooked: start screen tips.

Start screen is an incredibly precious piece of real estate, because every Focus user is guaranteed to see it at some point. That’s 100% of users.

There’s an opportunity in this screen: users who have used Focus for a while already know our value proposition well. So can we replace our default “Browse. Erase. Repeat.” messaging with useful tips?

These tips refresh after each time you press Erase.

They may start at a random place (so every user gets to see a different one), but they shouldn’t be annoying (ie. you shouldn’t see the same tip twice in a row, every other time, etc.). And they should circle back to “Browse. Erase. Repeat.” eventually.

Lastly, these tips don’t interrupt your activity (you can still type on the URL bar straight away).

I think that these tips should work in conjunction with the other just-in-time information and one-tap actions. In other words, we should do all of them together. What do you think?

[Sdaswani]

I ❤️ the start screen tips, and I would want to prioritize them for 7.0. I would also want to use fretboard to be able to send new tips down without app updates, but we can leave that for another revision.

As you say @brampitoyo they will be seen by 100% of users.

Can we 'deep link' to some actions (like setting default browser) instead of giving links?

cc @oliviabrown9 this may be something nice to do for iOS too.

[brampitoyo]

@Sdaswani The action that makes sense to deep link – in a sense that the action can be useful without needing any website to be loaded first – is indeed “Set as default browser”!

We can easily turn the hint text into a link – and in fact make the entire hint area tappable (even though only the hint text is underlined).

And when tapped, we will show an instructional modal dialogue that says “On the next screen, select Firefox Focus and then tap ‘Always’”. This is the most direct way to make Firefox Focus your default browser without needing to go into Settings and correctly select a specific menu item.

---

And yes, these start screen hints are readily adaptable to iOS! Some interesting things to highlight there will be our security features (like Touch/FaceID) and shortcut features (like Siri shortcuts).

[pocmo]

I think this screen flow is technically not possible unfortunately :(

Our default browser setting does two different things:

• (1) On modern Android systems it links to the Android settings for setting up a default browser (That's something the user has to do manually)
• (2) On older versions of Android it links to a SUMO article explaining how to change the default app handling links on those versions

There's no way for us to trigger the selection screen above.

[brampitoyo]

I haven’t got a phone running older versions of Android to test this, but on my test phone running 8.1, somehow Opera Mini was able to invoke the system’s browser selection dialogue.

Example: https://www.youtube.com/watch?v=MTUd9JKGw78

I wonder what they’re doing here, and how they’re able to do it?

[Sdaswani]

We should 100% do this - @pocmo @colintheshots any ideas how we can do this?

[aminalhazwani]

And when tapped, we will show an instructional modal dialogue that says “On the next screen, select Firefox Focus and then tap ‘Always’”. This is the most direct way to make Firefox Focus your default browser without needing to go into Settings and correctly select a specific menu item.

@brampitoyo possible technical constrains aside what if we merge the two last screens. The folks at Citymapper do something very smart. After users tap on the action the native dialog shows up with an overlay and - even if behind the overlay - they change the content of the background to guide users, this is a screenshot (on device the caret jumps up and down).

[pocmo]

I haven’t got a phone running older versions of Android to test this, but on my test phone running 8.1, somehow Opera Mini was able to invoke the system’s browser selection dialogue.

Interesting.

This menu item seems to do different things based on the Android system and if you have a default already. On my phone it tells me to first clear the current default and then sends me to the "App Info" page of Klar. After that it shows me the same flow like you showed to select the app from a list.

This seems more complicated than our solution (on systems that have a default browser setting). On other systems it's nice because they have a kind of interactive version of what we describe in the SUMO article.

[Sdaswani]

We can iteratively improve this to something more complex that covers more cases but can we start defining something MVP for 7.0 (that still links directly to the setting change)?

[Sdaswani]

@brampitoyo is this Eng Ready? Or do we still need UX and/or copy? I know for default browser there was some discussion about making that actionable without leaving the app, but leaving that implementation aside, can Eng get started on this?

[brampitoyo]

[…] is this Eng Ready? Or do we still need UX and/or copy? I know for default browser there was some discussion about making that actionable without leaving the app, but leaving that implementation aside, can Eng get started on this?

@Sdaswani Yes. Other than default browser, this issue is Engineering ready.

In essence, the Start Screen Tips are text-based messages that replace our current “Browse. Erase. Repeat.” messaging at certain conditions, as explained above in https://github.com/mozilla-mobile/focus-android/issues/2816#issuecomment-407596977.

And if we cannot invoke the “Open with” system dialogue reliably, we can just send user to the correct page under the system Settings.app, which is what we already do if you go to Firefox Focus Settings and select “Set as default browser”.

[Sdaswani]

@brampitoyo do we need @BrianNJones to finalize the copy for the tips?

Of course we need @bbinto's thoughts on this.

[brampitoyo]

@aminalhazwani

The folks at Citymapper do something very smart. After users tap on the action the native dialog shows up with an overlay and - even if behind the overlay - they change the content of the background to guide users, this is a screenshot (on device the caret jumps up and down).

I like this idea a lot, and think that we can do something similar for default browser. Of course, it depends on whether we can invoke the “Default app” system dialogue reliably!

But ideally, it might look a little like this:

And the arrow animation would look like this: https://cl.ly/1M3H1h1h1R2Z

[brampitoyo]

[…] do we need @BrianNJones to finalize the copy for the tips?

Yes. Absolutely.

Brian, here’s a summary of all the in-app communication that we want to do in Focus.

(To everybody else: if you feel like the discussion above are fragmented and incomplete – such is the nature of any bug/issue thread – then read below for a summary)

---

Context: why we need in-app communication

We think that educating our users about some of our less known features will make them more likely to use Firefox Focus more.

We have thought of things such as showing hints after users have performed certain sets of actions. However, showing something more passive (ie. doesn’t need any user tracking or activity detection) and direct (ie. allows users to perform the action directly, instead of telling them about a feature), will allow us to educate users while staying true to our mission.

We’re planning to have three kinds of in-app communication:

1. Just-in-time information
2. One-tap actions
3. Start screen tips

---

1. Just-in-time information

Instead of showing hints after users do certain actions (our prediction may be inaccurate), show information next to features and menu items themselves, and show them permanently (no tracking required).

We have just-in-time information for:

1. Tracking Protection.
   • Place: main menu
   • String: Turn off to fix some sites
2. Add to Homescreen
   • Place: main menu
   • String: Go to sites faster using a shortcut
3. Set as Default Browser
   • Place: Settings page
   • String: Open links in Firefox Focus by default

---

2. One-tap actions

Instead of telling users how to access features, give them the ability to execute that feature in just one tap, and allow them to do it all the time (no tracking required).

We have one-tap actions for:

1. Add Custom URL (add to autocomplete)
   • Place: when user tap on the URL bar and the URL hasn’t been added to the list yet
   • String: Autocomplete: [http://www.example.com]
2. Open Link in New Tab
   • Caveat: it may not be such a good idea to show this one-tap action, because it will involve replacing the user’s standard tap with a modal dialogue – it may be interruptive and hacky
   • Place: when user taps on any link for the first time
   • String: Long press any link to access this feature
3. Set as Default Browser
   • Place: Settings page
   • How it works: we trigger the default browser selection UI, then ask users to choose “Always” on Firefox Focus.
   • String: Tap “Always”

---

3. Start screen tips

Those who have used Focus for a while already know our value proposition well. So can we replace our default “Browse. Erase. Repeat.” messaging with useful tips?

These tips refresh after each time you press Erase, and don’t interrupt your activity (you can still type on the URL bar straight away).

Best of all, these tips can also be adapted to show up in Focus for iOS.

We have start screen tips for:

1. Tracking Protection
   • String: Sites not working as intended? Fix it: Menu → Turn off Tracking Protection
2. Add to homescreen
   • String: Open your favourite site in one tap: Menu → Add to homescreen
3. Set as default browser
   • String: Open links in Firefox Focus by default: Menu → Settings → Set as default browser
4. Add to autocomplete
   • String: Autocomplete your favourite web addresses: Go to site → Address bar → Autocomplete
5. Open Link in New Tab
   • String: Make links open in a new tab: Long-press a link → Open in new tab

---

Now you know all the in-app communication that we’d like to do in Focus for Android, and all the strings that we’ll need your help writing.

[bbinto]

Of course we need @bbinto's thoughts on this.

@Sdaswani what exactly should I think of? If we want users to be sent to the settings page?

[Sdaswani]

@bbinto I need your green light for us to build all these things for 7.0 (most importantly the start screen tips, which I would want to do first as they are the most high impact).

On Mon, Jul 30, 2018 at 3:16 AM, Barbara Bermes notifications@github.com wrote:

Of course we need @bbinto https://github.com/bbinto's thoughts on this.

@Sdaswani https://github.com/Sdaswani what exactly should I think of? If we want users to be sent to the settings page?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mozilla-mobile/focus-android/issues/2816#issuecomment-408816094, or mute the thread https://github.com/notifications/unsubscribe-auth/AEp2Uu4eyycUKzRU8tYs_nDW-6keBBsnks5uLt0FgaJpZM4U6LQy .

-- Susheel Daswani Senior Mobile Engineering Manager phone / text: (415) 218-7259

[bbinto]

@Sdaswani & @brampitoyo, I also <3 the start screen tips and don't feel we need to get everything in for 7.0, so starting with start screen tips and starting to break them into eng issues would be great, including probes.

I feel the start screen tips are the easiest to implement and to add strings/tips as we go (especially the ones that don't deep link).

[Sdaswani]

great @bbinto - @sblatz is going to breakdown the work for the simple implementation (where an app update is required for new tips) while @BrianNJones gets the strings ready

[BrianNJones]

@brampitoyo @Sdaswani @bbinto, wrapping my head around everything here. Think there's more to understand before we implement the start screen tips.

• What cue(s) are we giving users to help understand that start screen content is semi-dynamic? The hedline (Firefox Focus) is static; it's unlikely users will understand the text beneath is changing.
• Tying string refresh to "Erase" makes engineering sense, but we're assuming users will understand the relationship/cadence.
• Will user who has already turned off TP see the TP-related tip, etc?
• 5 strings + "Browse. Erase. Repeat" = 6 strings. For this to be meaningful/compelling, strongly think we need more. Thanks! -

[Sdaswani]

@colintheshots @ekager @sblatz for screen tips, I see that @brampitoyo has included the workflow to get to the setting, but can't we just deep link if the user clicks on the tip?

[Sdaswani]

My comments, but happy to hear from @brampitoyo :

• Can we do something like fade the tip in, or some visual effect, so the user sees the tip as dynamic?
• We could easily tie it to a new app launch, if we feel that relationship is clearer. But given plenty of people erase, I think it's a fair to rotate the tip upon Erase and/or new app launch: https://sql.telemetry.mozilla.org/queries/4293#8578
• We can be smart about tips and not show ones that users have enabled / disabled.
• It's not a huge amount now but I think we can add them in future releases, and later we will be able to add them without app updates. I vote we ship now and improve by iterating.

[brampitoyo]

@BrianNJones Thanks for bringing up all your concerns! They’re very important to address, and I’ll try my best to answer them below:

What cue(s) are we giving users to help understand that start screen content is semi-dynamic? The hedline (Firefox Focus) is static; it's unlikely users will understand the text beneath is changing.

Tying string refresh to "Erase" makes engineering sense, but we're assuming users will understand the relationship/cadence.

I had a few ideas around how the tip should initially display and refresh, but your point has helped clarify my thinking.

1. Every time the user cold boot the app, the initial state should always start out on “Browse. Erase. Repeat.” with no other hint fading in or displayed. This ensures that our initial state remains unsurprising to anybody who has used Focus before. Hint will only be displayed after the first tap of the Erase button.

2. How do we help users understand that the start screen content can change? How do we help them understand that tapping Erase will change hints? I like @Sdaswani’s idea: each time after the user taps Erase, the initial state should always start out on “Browse. Erase. Repeat.” – however, after a few seconds, the hint would replace this text permanently, until the next time the user taps Erase.

3. Once a hint is displayed, it won’t easily change (they won’t change on app switching or warm boot). The only way to change a hint is to tap the Erase button. And if the app is quit, the hint returns to its initial state: “Browse. Erase. Repeat.” – so as to minimise surprise and randomness.

Will user who has already turned off TP see the TP-related tip, etc?

I was thinking that the tip would only show up when the user has never used the feature before:

1. Tracking Protection would only show up if
   • The user has never toggled the TP menu item
2. Add to home screen would only show up if
   • The user has never tapped on the home screen menu item
3. Set as default browser would only show up if
   • The user has never tapped on the Settings page menu item
   • Even if the user’s default browser is currently not Focus, if the user has ever switched it to Focus before, we assume that they’re not interested
4. Add to autocomplete would only show up if
   • The user has never added an entry on the Custom URL list
   • The user has never tapped on the “Add to autocomplete” action on the URL bar
5. Open Link in New Tab would only show up if
   • The user has never long-press a link and tapped “Open link in new tab”

This means that many of our pro users won’t see any hint at all. That’s perfectly fine. We can still display “Browse. Erase. Repeat.” Our aim is simply to get users who haven’t tried specific features, to try them at least once.

5 strings + "Browse. Erase. Repeat" = 6 strings. For this to be meaningful/compelling, strongly think we need more.

I strongly agree that we need more than just 5 hint strings.

For a hint to be actionable, it needs to be tied to a certain feature – otherwise, it’s just crowding up the start screen.

I would recommend hinting at features that allow users to get to where they want to go faster, or give them more privacy:

1. Change search engine
2. Find in page
3. Open link in another browser (if our users want to keep a link open permanently)
4. Biometrics or Stealth

Thoughts?

[BrianNJones]

@brampitoyo, thank you X 1,000,000 for your response.

Tip display beneath Firefox Focus: I'm still skeptical that users will see the tips, but it can't hurt to try. (Aside: it would be interesting to do a quick eye-tracking test, eh?)

Display rules: makes total sense, Bram...great!

Number of hint strings: would you have time in the next couple days to talk this through?

Thanks again!

[Sdaswani]

@brampitoyo some comments:

• I do want to emphasize that these are called 'start screen tips', so only showing the tips after an 'Erase' takes us away from these tips showing up on the 'start screen'. 'Erase' is clicked a lot, but only showing tips after an Erase does reduce the eyeballs on these tips significantly.
• I agree that if a user displays knowledge of a tip, we have to disqualify that tip from being shown again. You should make that part of your acceptance criteria in #3039 @sblatz .
• please do meet with @BrianNJones soon to settle on the strings - @sblatz is going to use some placeholder strings in #3039 for now.

[brampitoyo]

@Sdaswani I’ll meet with @BrianNJones and have a chat about the strings. Thanks!

[bbinto]

@brampitoyo any updates on this? moving this to sprint 4

[brampitoyo]

@bbinto I think that @sblatz has implemented the initial UI for home screen tips at #3039 and PR #3097.

With that in mind, should we close this issue? We can continue working on the details of the tips implementation (e.g. #3101, #3126) in other issues.

I’ve posted some more thoughts about tips on https://github.com/mozilla-mobile/focus-android/issues/3039#issuecomment-412384274, but generally, we’re good to go.