[Spike] Investigate onboarding "Set Up" checklist actions for use in new Feature Callout template
Categories
(Firefox :: Messaging System, task, P1)
Tracking
()
People
(Reporter: mviar, Assigned: mviar)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
Investigate triggering and marking completion of actions to be used in a new onboarding "Set Up" checklist template for Feature Callout. This will support experimentation slotted for Fx131.
Experiment spec with description of checklist actions
Initial findings / proposed approach (updated 7.18.24)
Add a New Action List Component
- We have a MultiAction component in about:welcome which is useful for reference, but too different to be repurposed for this use case
- First use case is in the FeatureCallout surface
- Includes a progress bar the reflects percentage of action items completed
- Updates when an item is checked due to user click
- Component should display a list of items, each of which is a button that:
- can trigger a special message action
- shows a visual “checked” indicator if the action is complete
- is disabled if checked (no action arrow)
- can be configured to initially show as checked (complete) or unchecked based on a targeting string (see prototype patch)
- can be configured to be marked complete by:
- user clicking the item
- can trigger a special message action
Actions for Initial Experiment
- Import data action complete targeting:
- All of the migration prefs are false:
!(hasMigratedBookmarks || hasMigratedCSVPasswords || hasMigratedHistory || hasMigratedPasswords)
- All of the migration prefs are false:
- Pin to taskbar action complete targeting:
doesAppNeedPin
- Set to default action complete targeting:
'browser.shell.checkDefaultBrowser'|preferenceValue && !isDefaultBrowser
- Install extension & Add a theme (explore pages) action complete targeting:
- Store whether the user has visited each of these pages as messaging system prefs and use this pref value to check for completeness
- Sync mobile action complete targeting:
!isFxASignedIn || sync.mobileDevices == 0
Additonal Notes / Supplemental Work Required
- Callout will automatically be removed if its anchor, the "Finish Setting Up" button, is removed
- Clicking the "Finish Setting Up" button should toggle showing the callout
- If this button will no longer link to about:welcome, we’ll need to update the AWToolbarButton code to trigger the callout message on click using
sendTriggerMessage
- We can use a
page_event_listener
in the Feature Callout message configuration to close the message when the user clicks the "Finish Setting Up" button (see example here).
- If this button will no longer link to about:welcome, we’ll need to update the AWToolbarButton code to trigger the callout message on click using
- Callout should show on new tab after user finishes with about:welcome flow
- We could potentially have two version of the callout message:
- One triggered when DID_SEE_FINAL_SCREEN_PREF for about:welcome changes to true (meaning onboarding has ended)
- One triggered by a
featureCalloutCheck
called fromAWToolbarUtils
when the "Finish Setting Up" button is clicked- This could have special "first time" copy with something like "Click this button to view again"
- Alternatively, we could explore adding a special message action that sends a trigger message with a configurable trigger id (see bug 1907952)
- We could potentially have two version of the callout message:
- Currently, only one feature callout can show at a time.
- Some targeting attributes, like
doesAppNeedPin
andisDefaultBrowser
are cached (see here, so we may need to exposure uncached versions of these noting any negative impacts on perceived performance (see attached patch). - We would like to capture when items are marked as "complete" in telemetry, but we'll no longer be listening for pref changes in real-time. So, we can explore other options for reporting the complete state of items.
Assignee | ||
Updated•5 months ago
|
Updated•5 months ago
|
Assignee | ||
Comment 1•5 months ago
|
||
Looking back at our planning board and this is actually slated for 130. I'll update priority at the start of next cycle.
Assignee | ||
Updated•4 months ago
|
Assignee | ||
Updated•4 months ago
|
Assignee | ||
Comment 2•4 months ago
|
||
I confirmed with Vasant that we'll continue with this initiative. I've updated the priority to reflect that we'll investigate this during 130 Nightly as planned.
Assignee | ||
Updated•4 months ago
|
Assignee | ||
Comment 3•4 months ago
|
||
Updated description with notes from initial investigation, a proposed approach, and open questions
Assignee | ||
Updated•4 months ago
|
Assignee | ||
Comment 4•4 months ago
•
|
||
Some updates from our sync today (also reflected in the updated bug summary):
- We'll likely want all actions to show as complete on click to avoid the button seeming "broken" to users, completeness can be reassessed when the message is shown again. This likely removes the need for observing preferences completely.
- For the initial experiment, we should aim to avoid overlap with any other feature callout messages.
- The first time the message is shown after about:welcome, we'll likely include copy along the lines of "Click this button to see again" to let users know they can return to the checklist.
- We'll stick with simply recording whether a user has visited the theme and add-ons pages, rather than checking to see if they've actually downloaded one.
- We would like to capture when items are marked as "complete" in telemetry, but we'll no longer be listening for pref changes in real-time. So, we can explore other options for reporting the complete state of items.
Assignee | ||
Comment 5•4 months ago
|
||
Marking this initial spike as complete after discussion with product. Work can begin with the goal of landing all on-train patches by the end of Fx131.
Assignee | ||
Comment 6•4 months ago
•
|
||
Reopening this patch to add a prototype for attribute-level targeting and investigating potential issues there.
:pdahyia noted that the pin and set default targeting is cached (such as here). We'd likely need to expose uncached versions for this use case.
I'll also do additional exploration into performance differences between using pref getters and pref value targeting to determine if it would be worthwhile supporting both.
Assignee | ||
Comment 7•4 months ago
|
||
Updated•4 months ago
|
Assignee | ||
Updated•4 months ago
|
Assignee | ||
Comment 8•3 months ago
|
||
Marking fixed, feature work will begin in Fx131 Nightly.
Description
•