LaunchPad Checklists - Create the initial checklist module.

[Addison-Stavlo]

For the LaunchPad we will need a checklist module that:

• Surfaces the assigned checklist corresponding to the sites goals. For starters we could assume we are given a string like newsletter or links-in-bio, but in the end will need to set this up to read the checklist variable being coordinated in this P2 - pdDR7T-bx-p2 . Related for defining checklists - https://github.com/Automattic/wp-calypso/issues/66125
• Renders the checklist into the vertical list of individual step/tasks in components as seen in designs paYE8P-1Ot-p2#comment-1651
• Can be reused across full-screen launchpad, My Home, and possibly other interfaces.

Perhaps we are able to re-use or re-purpose parts of existing MyHome checklists in some way.

[jeyip]

It'll be worthwhile to look at the existing implementation of the my home site setup checklist https://github.com/Automattic/wp-calypso/blob/trunk/client/my-sites/customer-home/cards/tasks/site-setup-list/index.jsx

[edanzer]

Notes on Reusing Home Setup Checklist for Launchpad

... NOTE THIS IS A DRAFT IN PROGRESS. JUST MAKING NOTES/DISTINCTIONS AS I GO.

Comparing Appearance

Home Setup Checklist

Launchpad Checklist

Relevant Files and Components

This folder contains most components and logic for the Home Setup Checklist. https://github.com/Automattic/wp-calypso/tree/trunk/client/my-sites/customer-home/cards/tasks/site-setup-list

• Component for checklist wrapper. Checklist is rendered starting on line 268. Seems like the checklist itself could be pulled out of this file and put in separate component. https://github.com/Automattic/wp-calypso/blob/trunk/client/my-sites/customer-home/cards/tasks/site-setup-list/index.jsx

• Component for checklist items. This component is quite simple compared to the one above. https://github.com/Automattic/wp-calypso/blob/trunk/client/my-sites/customer-home/cards/tasks/site-setup-list/nav-item.jsx

The Home Setup Checklist also draws on logic from elsewhere in terms of how checklists items are defined and stored.

• Currently available checklist steps appear to be defined here: https://github.com/Automattic/wp-calypso/blob/trunk/client/state/data-layer/wpcom/checklist/index.js
• Checklist tasks are also stored in state, retrieved via: https://github.com/Automattic/wp-calypso/blob/trunk/client/state/selectors/get-site-checklist.js

Home vs Launchpad: What's the Same?

• Checklist with checklist items.
• Markup, appearance, styling, are generally similar.
• Each item can have incomplete/complete status.
• Accommodates methods and sophisticated logic to check status of each item.
• We may be able to re-use some of the methods for checking status where tasks are the same.
• Incomplete/Complete icons are nearly identical (green check, empty circle).
• Font/size/spacing of items is similar.

Home vs Launchpad: What's Different?

• Actual home checklist items (ie, email verfication, try the wordpress app) are generally different from what we need.
• Home checklist items are accordion tabs. When clicked, they load a card with content to the left. So what happens on click is different. There is a prop for accordion view. Not sure what happens when that is disabled yet.
• Home checklist items don't seem to support pill buttons for intermediate status (ie, "Draft").
• Final item in Launchpad checklist (ie, "Write Your First Blog Post") is a button, not another checklist item.
• Some small markup differences: Launchpad items have no borders, have arrow icon at end, are marked through when complete, go from bold to lighter when completed, etc.

Home vs Launchpad: Other Considerations

• All In or Not. I think using the Home Site Setup means going all in. The checklist wrapper logic, the individual checklist component, the way in which potential checklist items are defined / stored / retrieved, all seems to be tightly integrated. So I think we either go all in, or we don't.
• Same Purposes. A potential argument in favor of using this is that the Home checklist serves intends to serve a very similar purpose. Namely, it outlines, tracks status, and link to to-do items needed to launch. Our flows like newsletter/link-in-bio are arguably just specific iterations for particular use cases.
• Complexity / Overkill? The Checklist wrapper module is very long and complex. Perhaps we'd end up with the same level of complexity even if we started from scratch. But in general, I'd prefer something simpler and wonder if there's overkill here in terms of logic/complexity.
• Refactor Suggestion. If we use it, I might propose refactoring to break this component up a bit in to smaller chunks.
• Refactor Suggestion. Is there a reason this module (and other components in our codebase) use connect() with functional components? I'd propose refactoring to use hooks.

Updates

• CHECKLIST_KNOWN_TASKS. Additional note on using the Home site setup checklist: These components assume/rely/depend on the existence of CHECKLIST_KNOWN_TASKS. This contains common site setup checklist items that are interacted with at various points in the code base. So we'd either need to leverage that to contain/mange our task lists, or refactor components to be able to not rely on that.
• Checklist Not Currently Own Component. I noted above that the actual checklist is output from within the site-setup-list/index.jsx starting around line 268. The checklist is embedded in other markup, and is not separated out as its own component. So we'd need to refactor that first before we could use it. At present, you can't just insert that checklist as it's own component in some other location.

[edanzer]

Notes on Reusing Current Stepper First Step List

The current stepper-based onboarding flow for new WP.com websites ends with a screen that has a kind-of similar feel to Launchpad. Like Launchpad, this is a task list that shows on the last page of an onboarding stepper flow. I thought it may also be a good jumping off point for Launchpad.

It looks like this:

Verdict

I don't think the checkist / checklist items components used here are a good starting point. The list above is generated by very basic markup. The checklist lacks any logic or methods for checking status of items, doesn't handle any conditional rendering for complete/incomplete/intermediate states, etc. There just isn't much advantage gained by using this as a starting point.

[edanzer]

Proposal

1) Launchpad + Site Setup Checklist. Ultimately, I think we should try to coordinate our work with the Site Setup Checklist. They serve the same purpose in providing a trackable checklist of site set setup tasks with status. And they need similar UI elements and logic. And Automattic has already done a lot of work to refine a system for this. We'd end up reinventing a lot of the same logic if we start entirely from scratch.

2) Stage Things for Faster Immediate Progress. There's some urgency for Launchpad. We can accommodate this by taking some initial shortcuts to get Launchpad UI and checklist logic in place, and then moving toward integrating with Home Checklist afterward. In particular:

• For UI, we can create simple Checklist / ChecklistItem components for Launchpad. Indeed, this is easy and we already have a good start. Once up and moving, we can refactor LaunchPad and Home Checklist to use the same components.
• For the Checklists and logic themselves, we can get start by hard coding checklist for, say, newsletters. As we develop, we'll find we need similar APIs / state management / methods to Site Setup Checklist - As we do, we just adopt the relevant portions of logic.

[Addison-Stavlo]

For tracking purposes Im going to close this initial issue for creating the initial checklist, and we have the follow up for further functionality - https://github.com/Automattic/wp-calypso/issues/66125