[meta] Onboarding Redesign (Cards)
Categories
(Firefox for Android :: Onboarding, enhancement, P2)
Tracking
()
People
(Reporter: jmahon, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Keywords: meta, Whiteboard: [fxdroid] [roadmap] [juno] [uxfundamentals])
Feature Outline
The current Onboarding Flow is an embedded listview that includes a variety of educational cards to help a user learn about core functionality. However, these cards are easy to miss for new users.
We want to create a new design for the first-run Onboarding Flow using the same fullscreen cards leveraged in MR 2022, allowing users to swipe between these items.
Behavior Spec
- Onboarding is shown to new users. (not during app updates)
- Show three cards, in this order:
- Set to default (+ privacy policy)
- Sign in to sync
- Notification permissions
- There should be no "x" button on the card, and onboarding should be undismissable. The back button should close the app, rather than dismissing the onboarding interstitial.
- If user leaves onboarding without finishing it, it should re-appear the next time they enter the app. (no need to keep track of where they were in the onboarding - if the app has been killed in the background, they can just start from the beginning again).
- We don't need to deal with "smart" behavior around cards showing or hiding based on system state (e.g., if they somehow already have notification permissions enabled, the card should still appear in the flow. They can just continue past it). This might be an opportunity for a future UX optimization.
- Users should be able to swipe backwards. If it's straightforward to do, swiping forward should be prohibited. (See note in "topics for product" for more info)
- The 'notification permissions' card should not appear for devices below Android 13. (note in "topics for product" section)
Topics for product:
- Swiping behaviors:
- Swiping forward: If possible, we'll restrict users from swiping forward (to ensure they click one of the two buttons); but if it adds technical complexity, we'll defer that to a future version.
- Swiping backward: should be enabled, in case a user leaves the sign in, set to default, or notification permission flow accidentally, and wants to do it again.
- Warning about potential telemetry confusion: Android 12 and below doesn't require notification permissions, so we won't show them the permission prompt card - users on these devices will only see 2 cards, not 3. We need to account for this in any evaluations we run, because it would be easy to misunderstand that a lack of positive action on these devices might imply user drop-off or negative action.
Experiment setup:
This release of the new onboarding feature should be able to be enabled or disabled by Nimbus:
- The control branch should be the current onboarding experience (listview + notification permission prompt)
- The treatment branch should be the updated onboarding experience (card-based redesign)
The next version of this feature will enable customizing the contents of the onboarding flow through Nimbus.
Update, March 20: below section is no longer relevant. We're just aiming to land for v113 & allowing localization to happen normally.
Update, March 10: we aren't ready for today's string freeze, but we've been brainstorming some ideas about whether it's possible to release this sooner than v113 by localizing & enabling the redesign for a small subset of locales. I currently have no idea if this is even possible.
If we do some limited localization, can we use Nimbus to target them? Need to coordinate this between Delphine, Flod, & Daniela.
Specific locales expected to be supported: marketing focused locales:
en-*fr-*dees-*itSo, for engineering: we'd need to land this, then request localization for those limited locales (from Delphine and/or Flod), and we'd need to make sure the experiment is set up to only target those locales (Daniela can help there, particularly to coordinate with Shell). But as of 3/10, not sure if this idea is viable.
Updated•3 years ago
|
| Reporter | ||
Updated•3 years ago
|
| Reporter | ||
Updated•3 years ago
|
| Reporter | ||
Updated•3 years ago
|
| Reporter | ||
Updated•3 years ago
|
Updated•3 years ago
|
| Reporter | ||
Comment 1•3 years ago
|
||
:rahul: I updated the spec above to match current expectations as far as I'm aware of them; hopefully it's close to being 'locked in'.
:daniela, can you review the bullets in "Topics for Product" and let me or Rahul know if those sound OK to you? Particularly the telemetry one - I'm not sure who to publicize that to; if you have any ideas of who should know about that, please feel free to forward the info (perhaps Joy Ma?)
Comment 2•3 years ago
|
||
Yes they look good to me. I will make sure to call out the telemetry point in the experiment brief.
A comment on the experiment - we want to run 2 branches comparing with X on the cards and without X.
| Reporter | ||
Comment 3•3 years ago
|
||
:rsainani I realized there’s another detail we might need to hash out regarding the “observation” logic we discussed yesterday: it’s a massive edge case, but if a user installs the app and sets it to default browser before opening it for the first time - they wouldn't see the 'set to default' card, right? (and, more importantly: they wouldn't see the privacy policy link)?
If that's the case - can you circle with Product to get a decision whether that's an acceptable edge case to tolerate? (Warning: we might wind up needing to check with legal, since showing the privacy policy on the first card was purportedly a legal necessity)
We didn't talk about this precise situation, but I think this scenario would be similar to what was discussed in this Slack thread, in case you feel like you're missing some deeper context on this.
Comment 4•3 years ago
|
||
:jmahon Yes that's a good point. Thanks for raising this! As it's important to show the "Set to default" card for the privacy policy link, we can make sure we only remove it once the user has seen it and the browser is set to default, instead of the condition that the browser is set to default.
Comment 5•3 years ago
|
||
A few notes:
There's a bit of scope update, after discussing with :aarjav, essentially optimizing point 5 in the ticket.
– The sign in card is removed after a user successfully signs in on the second card, and moves to the next card if present.
– The default browser card is removed if the user sets the browser to default and has already seen the card, and moves to the next card if present.
An edge case has come up. When the user clicks the privacy policy link, that opens the custom tab. The user could select the menu option to "move" the privacy policy web page to the actual tab, taking the user away from the onboarding flow.
Another case, as :jmahon highlighted above, is that if the user sets the browser as default on the first card, exits the app, clicks a link in an external app, the Onboarding flow is skipped and user goes into the browsing experience. This is a edge case but something we should be aware of.
Comment 6•3 years ago
|
||
(In reply to Rahul Sainani [:rsainani] from comment #5)
An edge case has come up. When the user clicks the privacy policy link, that opens the custom tab. The user could select the menu option to "move" the privacy policy web page to the actual tab, taking the user away from the onboarding flow.
Hi, :rsainani, :jmahon, just wanted to bring to your attention another similar edge case we stumbled upon: using the search widget while the new onboarding was not yet dismissed.
At the moment, using the latest Nightly 114.0a1 and Beta 113.0b7, there are two scenarios:
-
While the new onboarding is displayed, send in the background > tap on the search widget > observe that the search bar and the keyboard are invoked over the new onboarding > perform a search > tap the back button > observe that the new onboarding is still displayed.
-
While the new onboarding is displayed, close the app > tap on the search widget > observe that the search bar and the keyboard are invoked over the initial long onboarding tour > > perform a search > tap the back button > observe that the homepage is displayed.
Note that scenario 1 is applicable for the initial long onboarding tour (for new user), where the search bar can be accessed from the onboarding tour anyway. However, on the MR22 onboarding from upgrading users, when the search widget is used, the search bar and the keyboard are not invoked in Nightly.
Another behavior worth mentioning is related to the two scenarios above: While the new onboarding is displayed, either send in the background or close the app > tap on the search widget > perform a search > tap the home button > observe that the homepage is displayed, and not the onboarding.
Please let us know if your feedback on these scenarios so that we can update our teste cases with the expected behavior in terms of using the search widget while the new onboarding is still displayed, and if we should file a ticket for any of the mentioned behaviors.
| Reporter | ||
Comment 7•3 years ago
|
||
Thanks for the thorough report, Delia! I'm going to defer my needinfo to Rahul, though; at this point, I think he has the most comprehensive perspective on edge cases and potential use cases.
Rahul, you may want to consult with Daniela and/or Aarjav to get consensus on whether we want to do anything about the cases Delia described (or if we want to - for now - enshrine them in 'expected and acceptable behavior'). IMO, anything related to the long scroll onboarding is probably relatively low priority at this point.
Comment 8•3 years ago
|
||
Hi Delia, thanks for the report! This is a good catch, although I think it is not likely that people will download the app and use the widget before opening the app in the usual way by clicking the app icon. It's not trivial to block access on the search widget. So my suggestion would be to make a note of this edge case and update the test scenario. Please let me know what you think.
Also, the long scroll onboarding should now not be shown when on the treatment branch, even with this edge case as Bug 1830304 has landed.
Updated•2 years ago
|
Comment 9•1 year ago
|
||
Closing this bug. We are tracking Onboarding changes/experiments through other tickets.
Description
•