Closed Bug 1901629 Opened 5 months ago Closed 3 months ago

[Spike] Investigate onboarding "Set Up" checklist actions for use in new Feature Callout template

Categories

(Firefox :: Messaging System, task, P1)

task
Points:
2

Tracking

()

RESOLVED FIXED
130 Branch
Iteration:
130.2 - Jul 22 - Aug 2

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

Actions for Initial Experiment

  • Import data action complete targeting:
    • All of the migration prefs are false: !(hasMigratedBookmarks || hasMigratedCSVPasswords || hasMigratedHistory || hasMigratedPasswords)
  • 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).
  • 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 from AWToolbarUtils 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)
  • Currently, only one feature callout can show at a time.
  • Some targeting attributes, like doesAppNeedPin and isDefaultBrowser 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.
Iteration: --- → 129.1 - Jun 10 - Jun 21
Points: --- → 2
Priority: -- → P1

Looking back at our planning board and this is actually slated for 130. I'll update priority at the start of next cycle.

Iteration: 129.1 - Jun 10 - Jun 21 → 130.1 - Jul 8 - Jul 19
Priority: P1 → P2
Iteration: 130.1 - Jul 8 - Jul 19 → ---
Target Milestone: --- → 130 Branch
Iteration: --- → 130.1 - Jul 8 - Jul 19
Priority: P2 → P1

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: nobody → mviar

Updated description with notes from initial investigation, a proposed approach, and open questions

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.

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.

Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED

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.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #9413502 - Attachment description: WIP: Bug 1901629 - Attribute Level Targeting Prototype → Bug 1901629 - Attribute Level Targeting Prototype
Iteration: 130.1 - Jul 8 - Jul 19 → 130.2 - Jul 22 - Aug 2

Marking fixed, feature work will begin in Fx131 Nightly.

Status: REOPENED → RESOLVED
Closed: 4 months ago3 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: