Wp-calypso: Gutenboarding: inject "Launch" button to Gutenberg header

[simison]

For un-launched sites, we'll want to have "launch" button all the time visible that starts the "pre-launch flow" (plan selection, checkout, etc).

Design:

The live header looks like this when editing pages/posts (also for un-launched sites):

(you can ignore the pink color and imagine it's blue)

It will likely look different when editing _sites_, but even then there will likely be "Save/Update" buttons to save edited site layout/global styles whatnot.

Curious to hear from designers how launch button should integrate with other buttons in the header?

Meanwhile, we can inject this button already to get into building a functional prelaunch flow for Gutenboarding. It should stay hidden behind a flag.

cc @mtias @olesyabrk @joanrho @dwolfe for thoughts.

[simison]

I believe the actual injecting has to happen from somewhere in apps/wpcom-block-editor. We modify UI there in some other ways, too (e.g. add back-button).

cc @Automattic/cylon for any technical guidance.

[simison]

Should we start with a header that looks like this?

[rickybanister]

In a world with full site editing I think Preview becomes slightly less valuable since you're already 'previewing' the entire site in the editor window. And prior to 'launch' all of your pages can be saved, but not published. So the Launch button can replace both preview and publish/update until the launch flag is flipped. The Jetpack or other plugin buttons aren't particularly useful prior to launch either (I may be missing something).

[simison]

The Jetpack or other plugin buttons aren't particularly useful prior to launch either (I may be missing something).

Yep, mostly just interested about interaction and wording between _Save draft_, _Preview_, _Save/Publish_, and the new "Launch" button.

Jetpack/gear/global-styles etc buttons will be there anyway unless we specifically want to hide some of them before launching.

Any wording that should be modified, primary/secondary states switched around, or any buttons should be hidden?

I think what confuses me is "Save Draft" — specifically because saving posts (even for an un-launced site) is different from "saving drafts". It sounds like you'd want the "Save draft" button function like "publish" button otherwise would for a regular WP site?

Should we just have "save" instead of "save draft"?

[rickybanister]

"Save" feels very appropriate at the site level.

[olesyabrk]

Ditto to what Rick said about deprecating Preview and Publish/Update.

I think it's important to keep Draft in Save Draft as it provides a secondary indicator that this is not a live site.

[noahtallen]

@simison this will become a lot easier with a custom editor instance! Yay :)

I think sticking it in that package is a fine idea, but there may be some tradeoffs between loading the editor from wp-admin and otherwise.

You can see prior art with the editor back button. Even without custom UI, we have to do quite a bit of work to perform navigation in the Calypso client instead of on the backend. (The moment you do a full reload, you have to re-boot calypso which takes some time.) The FSE editor also has custom UI, which lives in the FSE plugin so that it still works on wp-admin views, since the iframe bridge server only affects the iframed block editor (i.e. it does not run if you access it via wp-admin)

The flow looks like this:

1. We get a back button URL in the Calypso app and send a message through the iFrame.
   
2. In the iframe bridge server, we listen for the back button URL. We both save it to some global state and fire a wp.hook action with the data.
3. If it's the FSE editor, we actually listen for that wp.hook action and use that URL/label to render a different back button that makes more sense in that context.
4. In all back button flows, including FSE, we wait for the user to click on the back button then hijack the event to port a message back up through the iFrame to the calypso client.
5. In the calypso client, we receive the close editor action and then perform client-side navigation to wherever the close URL points.

In hindsight, it would be better to use a wp data store to assist with this. I'd actually like to switch to that for a lot of our global state at some point. It just hasn't been complex enough yet to warrant it.

[simison]

In hindsight, it would be better to use a wp data store to assist with this.

Sub-optimal solution seems fine for now, given that we'll try building custom editor at which point we don't indeed need none of this. :-)

Thanks for the pointers, very very helpful!

[mtias]

Why is there both a "save draft" and "save page" action? "Launch" is meant to replace "Publish", so there should be no extra buttons compared to a regular view.

[rickybanister]

@mtias we discussed this briefly this morning, and while I'd been operating under that same assumption (that Launch would act as a publish-all button), there might be edge cases where that is undesirable.

How would we handle a situation where someone wanted to leave a couple of pages as drafts, but launch all the pages they feel are ready? We'd need to separate out their status somehow. @olesyabrk suggested relying on page visibility settings, which could be a good solution, but requires extra thought beyond leaving things as a draft.

We should optimize for the most common case, which I believe is launching all pages at once, but be mindful in some way of how this deviates from the standard behavior.

[sirreal]

I've assigned @Addison-Stavlo and @jeraldjuice - they and their teammates have previous expertise relevant for this type of task.

Edit:

🚀 Looks like @Addison-Stavlo got started https://github.com/Automattic/wp-calypso/pull/39048 (remember to refresh your long-open tabs, folks 😉)