Improve Publishing Flow

[mtias]

For various reasons, publishing can take some time to finish. Right now this is the state we show:

The UI can seem frozen during that time, which is disconcerting. One thing we did in the Calypso editor was having a "busy button" state, so that the publish button, instead of changing to a disabled "update", better communicates that something is happening.

Might be interesting to also explore something in the publish flow popover instead of dismissing it.

cc @jasmussen @karmatosed @folletto

[folletto]

I feel both strategies you mention could work together: a "working" state for the button, but also something in the Publishing panel. 💯

[rileybrook]

A "working" or "busy" state for the button, was explored/mocked up earlier in the project wasn't it? It could possibly be designed in a more communicative way though.

[karmatosed]

My concern with just a loader is 'obviousness' and accessibility. How can we do this in a more conversational approach? Is relying on a visual state enough?

Looking at the journey (super simplified) we have:

At each point we need some feedback, at the end point we need celebration.

[jasmussen]

Tammie's journey curve is an excellent jumping off point for looking at this flow in the context of the publish dropdown. As such, I've taken that as a starting point for some new mockups around this.

1. It starts with a gray button labelled "Publish...":

2. When you click it, you get this popover. This step combines the feedback stage with the confirm stage:

2B. If at this point you uncheck the "Show this every time I publish" checkbox at the bottom, the next time you publish it's a single-click affair, with a blue button labelled "Publish":

3. If, however, you click the Publish button inside the popover, you get a candy-colored active working state as discussed in this ticket:

4. Once the publishing process finishes, you get various post-publish options, including ones that plugins can add:

In exploring this post-publish experience, I also tinkered with a somewhat wilder exploration. Essentially right after step 3, when the publishing process finishes, the popover slides all the way to the left, covering the entire editor, giving you option to preview the post. In a future where the post editor itself doubles as a preview this is perhaps less necessary. Nonetheless, here it is:

---

Note these mockups use a "popover sidebar", which is a new pattern. Some concerns have been noted with this pattern compared to showing a more normal sidebar, or even a dropdown. Please share your thoughts on this, and what you see as an optimal flow, and I can provide new/updated mockups.

The color change of the Publish... button I'd also like your thoughts on.

Once we reach a concensus on what we think is a good approach to explore, I will update this ticket description with the "winning" mockups. Thank you, @karmatosed @mtias @folletto

[karmatosed]

First, it's great to see this arc visualised. I raise my hand as one of those concerned with the popover sidebar. To me, it's using an existing pattern of the sidebar in a way that confuses, it's just too similar.

As far as changing the color of the publish, I think that's good to do, but we should make sure color doesn't just denote the state.

I really like the 'what's next' steps and think that's a great way of levelling up users and encouraging next progress on their journey.

[jasmussen]

Given the feedback yesterday, here are a couple more iterations that center around the "sidebar" pattern.

As a note on all of these:

• You can turn off this experience and get a one-click publish experience by unchecking the checkbox.
• This experience is for the publish action only, and shouldn't be used for Update or Schedule (unless of course Schedule is invoked from the popout)

As usual, keep in mind these are explorations. Even if it looks "final", it's subject to implementation changes and feedback.

---

Popout/dropdown version

This builds on the dropdown that's currently in master. Everything starts with clicking the "Publish..." button:

This gets you the dropdown, which now features a green "go" colored publish button:

Pressing that green publish button closes the dropdown and changes the publish button into a "Working" state, with a new label (seee #3682):

Once publishing is complete, you get a popover with a post-publish experience:

---

Publish Sidebar

When clicking the Publish button, instead of getting a popover or dropdown, the Publish button enters a "pressed" state, and a standard sidebar opens:

Clicking the Publish button inside starts the publishing process:

Once that's done, you get the post-publish experience:

---

Combined popover/standard sidebar

This version looks mostly like the standard sidebar, and it also resizes the content area to not cover it. But like the Popover version, it covers the Publish button, making the next steps more clear. It also doesn't have to untoggle any Settings sidebar, since like the popover it covers it if there:

Click the Publish button to start the process:

Once that's done you get the post-publish experience:

---

Summary and pros/cons

The primary problem with using the normal sidebar pattern, as opposed to a dropdown or an alternate sidebar, is that it untoggles the Settings sidebar (if you have that enabled), which means that once the publishing process is done, the Settings sidebar remains untoggled even if it was on before.

Another downside to using the "standard sidebar" pattern is: what happens if you close the sidebar during publishing? Maybe nothing happens, but it becomes a source of insecurity.

[karmatosed]

You can turn off this experience and get a one-click publish experience by unchecking the checkbox.

I like the idea of a 'chose your own experience' here. We should consider how we can build on that in other areas.

I'll skip through feedback based on both version, thanks for iterating and suggesting a few things:

Popout/dropdown version

• I don't hate the dropdown. It feels a more natural pattern. I really seem to have issues with that long popover though.
• It seems odd seeing a blue and green publish. Now, that may be a matter of adding an 'open' uncoloured state to the blue, but it does seem weird and questioning.
• Will the diagonals animate? I feel they need to.
• There feels a disconnect with the 'publishing' state.. would I notice it as my eye is in the other section?
• The final state feels like should be the same as the first.

Publish Sidebar

• This again feels a little too similar to the sidebar. I would go with the dropdown over this.
• Visually I felt the first flow was strong and more guiding.
• I do like the animation of publishing being 'there' where the action is happening.

Combined popover/standard sidebar

• Not any more comments on this, again I think I prefer the dropdown.

Total aside, what if we move the publish to the left and have a publishing area appear below that? I feel that's been explored before, but we maybe could revisit.

Another downside to using the "standard sidebar" pattern is: what happens if you close the sidebar during publishing? Maybe nothing happens, but it becomes a source of insecurity.

Yes this worries me a bit. I think that's another reason I wouldn't want the standard sidebar pattern :) I like the idea of a focused publishing flow that guides.

[folletto]

keep in mind these are explorations.

Roger!

From a high level view, I think either of the above is good. The reason is that I think that once we are able to cover the three different states:

• Pre-Publishing
• Publishing in progress
• Published

we provide an excellent visual support.

As such, I think my comments here tend to be less strong preferences than usual. :)

1. I know I disagree with a few people, but I prefer the sidebar: it gives more the sense of a structural piece than a temporary one, and since it's going to be extensible and might grow long (with scrollbars) I feel a popup scales worse. That said, if there's a strong preference for the popup, let be it. :)
2. In terms of sidebar formats, I think they all have pros and cons, so seems a neutral choice to me depending which one we give more weight.
3. I'd be in favor of consistency here: either all popups or all sidebars. It feels a bit of a mix having a bit of each, but maybe there's a way to mitigate that?
4. Having an expanded "end" state that plugins can extend is imho very powerful. Sharing is probably the first thing that comes to my mind, but there are plenty of actions that can be done after the publication.

which means that once the publishing process is done, the Settings sidebar remains untoggled even if it was on before.

This seems something easily solvable tho: we just restore it. No?

—

Sidenote on something already discussed: I'm not too keen in having the checkbox to disable the dropdown, as I think it should be a structural piece of the interface plugin authors and developers should be able to build upon without fearing a user to miss important information because they disabled it. That said, I'm also very aware of previous conversations, and I think this is one of the best approaches. I'd also nudge probably to allow plugin authors to be able to force the setting.

[folletto]

Doing a separate comment as this is an extra idea, and unless it's simpler than I imagine, I feel it won't be part of a MVP.

Smart In-Progress State

One of the most annoying things, especially on slow websites and sites with lots of plugins, is being stuck with an indeterminate loader and no information of what's going on for sometimes as long as half a minute (try plenty of publishing related plugins that do operations on external APIs...).

If we have a popup or a sidebar (or else!) that have the space, would be amazing if we could show at which stage the post publication is. For example, it could be that the user in order gets these messages:

• Publishing post...
• Contacting pingbacks...
• Creating 1/3 P2 cross-posts...
• Creating 2/3 P2 cross-posts...
• Creating 3/3 P2 cross-posts...
• Sharing on Facebook as "Lorem Ipsum"...
• Sharing on Twitter as "@lorem"...
• Done!

(This is of course just an example, and assumes some plugins installed).

This would probably require some API changes, but would make the entire process less of a black box.

If would also have more benefits:

1. It would make long waits more communicative, thus giving a better experience.
2. It would make debug easier, as the user would then see clearly if any of the item went wrong.
3. It would make certain "invisible" plugins visible, thus allowing them to be perceived as more valuable.
4. It would allow to resume if any of the steps failed (probably more in the future, currently would be just a second attempt to publish).

Would it make sense as idea? If yes, should I open a separate issue for this?

[jasmussen]

Love your feedback as usual, Davide. 🥇

I'd be in favor of consistency here: either all popups or all sidebars. It feels a bit of a mix having a bit of each, but maybe there's a way to mitigate that?

Having an expanded "end" state that plugins can extend is imho very powerful. Sharing is probably the first thing that comes to my mind, but there are plenty of actions that can be done after the publication.

These two feel related to me, and they are why I personally have a preference for a sidebar, either the popover version or the combined popover/standard sidebar (because they both cover the publish button, fixing some headaches). Especially the end state, the post-publish experience, is where I think we and plugins especially, can provide huge value (your second comment highlights this). If we were to have this happen inside the publish dropdown, it would have to change the contents, which would be super weird. As such, I don't think we can have a post-publish experience, and only use the dropdown version, we'd have to invoke a sidebar or a modal when publish finishes, whereas with all-sidebars, at least we'd only use one pattern for it, even if that pattern was new.

which means that once the publishing process is done, the Settings sidebar remains untoggled even if it was on before.

This seems something easily solvable tho: we just restore it. No?

Well, yes, with smarts. I.e. we'd have to account for situations where the user has dismissed the sidebar, so we don't restore it, and also situations where a plugin has registered a sidebar, so we restore the right one.

Even if we built those smarts, when I walk through the flow in my head, it makes the sidebar feel fragile. Like, we have this lovely toolbar "anchor" to indicate the sidebar, but if it toggles on and off on its own, feels like it could introduce an insecurity around it. Whereas if we had one of the sidebars that simply covered the sidebar, it wouldn't matter which sidebar was there before, or even whether it was toggled off or on.

[jasmussen]

So to resurrect this thread, I chatted a bit with @karmatosed today, and decided it was worth trying to move forward with a slightly simpler version of the Combined popover/standard sidebar.

The way it would work is, it's a popover in that it covers the publishing button, but it's also a sidebar in that it pushes text in.

It animates in from the right, very very quickly, and animates back out when dismissed. It has smarts in that:

• if you do not have a sidebar showing before starting the publishing process, it won't show when you're done either
• if you do have a sidebar showing when opening the publish sidebar, that same sidebar is showing when you're done publishing

Implementation note: whether this publish sidebar untoggles any active sidebar and toggles it back on when publishing is complete, or whether it just covers any existing sidebars, that doesn't matter so long as the smarts mentioned above work.

There are 3 steps:

1. Publish confirm — this is the sidebar popover opening up
2. Publishing step, this is likely to be very brief, has a spinner, but can hold an error message if something went wrong (like Internet dropped out)
3. Publish complete, with post-publish sharing options and the like

Steps 1 and 3 can hold plugin options.

Step 1 holds an "opt out" of this publishing experience, just uncheck it at the bottom.

If you opt out of this, there's an option to bring it back in the ellipsis menu (same as there's an option to fix the toolbar to the block).

Mockups

1: Click the Publish... to get this

2: Clicking Publish! gets you this:

3: Once publishing is done, you get this:

[karmatosed]

I really like this @jasmussen and feel it's a solid place to iterate on. This meets all the feedback and finds a great balance. Looking forward to seeing this coded up!

[folletto]

YES. Agreed. This feels solid, and I feel covers well all the bases. :)

Just one tiny minor note: I understand why the "Publish" button is where it is... but it feels a bit hanging? Not sure how to solve it: I'd consider maybe aligning it left even if it loses some immediacy for a "click-then-click" behaviour? Or maybe adding something to the left so it doesn't feel it's hanging? I'm not sure. Regardless, not a blocker, and it's fairly minor. We can prototype the above.

[jasmussen]

Just one tiny minor note: I understand why the "Publish" button is where it is... but it feels a bit hanging?

I agree with this, and I'm flip-flopping. I feel like either it should be "in place" as is, or it should be moved down as it was in earlier mockups.

I also feel like this is one thing we can try in implementation: sort of take it from there, see what feels right.

[themightyant]

@jasmussen Nice work. I think this is a good incremental improvement and answers many of the criticisms from other issues like #3279 and others i.e.

• Having to move the mouse between clicks for two clicks to update (many update pages/posts often to get it right. Others compose carefully once, different methodologies)
• Having a way to opt out of double clicks
• More space for plugins, permalink etc.

Possible criticisms

• Will clicking the same button twice be obvious (I am a fan of not having to move the mouse but trying to be impartial)
• I understand why the button needs to change colour to highlight the change (above issue) but is the initial publish colour obvious enough? Does it break from established colour for admin themes etc.
• Is the Checkbox a little lost at the bottom?

[jasmussen]

Will clicking the same button twice be obvious (I am a fan of not having to move the mouse but trying to be impartial)

Possibly not, and Davide above raised the same question. I think this is something that will make itself fairly obvious fairly quickly as soon as we try it in practice, and there are good plan B's in case we decide it's unobvious. Such as moving the 2nd confirm publish button, and/or changing colors in between.

I understand why the button needs to change colour to highlight the change (above issue) but is the initial publish colour obvious enough? Does it break from established colour for admin themes etc.

Were you looking at the latest mockups in this comment? The color is the same there, and it takes from the wp-admin.

Is the Checkbox a little lost at the bottom?

Possibly, definitely something we'll observe in tests, and definitely open to tweaks in implementation.

We want to find a balance between making it easy for people to opt out if that's what they prefer, and not making it a permanent nuisance for people to do not opt out.

[maddisondesigns]

Having to click the same Publish button twice, is even worse than the original implementation of two Publish buttons.

If I uncheck that 'Show this every time ' checkbox, then presumably, that panel no longer displays. If that panel doesn't display, I no longer have access to the Publish or Visibility controls.

What happens when I have a page that I decide that I want to unpublish or I want to schedule the publishing of? I can't, because I no longer have access to those options.

How do I get the Panel back if I change my mind or if someone clicked it accidentally? Is there a option somewhere on one the Settings pages, so that I can reset it?

Does that checkbox stop this panel from displaying when publishing a page or only when updating an already published page? Or Both? It's not clear which workflow it affects.

What happens when a plugin (e.g. yoast) decides to add some functionality into that sidebar section, and I've already unchecked that checkbox. I'd never see it.

There are so many issues with this implementation.

[jasmussen]

I will copy my response from here, for folks following both threads.

If that panel doesn't display, I no longer have access to the Publish or Visibility controls

Those are still in the Settings sidebar. This is a "last minute checkup".

Have you thought about how I get those options back again, if I change my mind and decide that I would like to see the 2-step panel?

I was thinking something like this:

Does that checkbox stop this panel from displaying when publishing a page or only when updating an already published page? Or Both?

In the flow detailed in #3496, the publish confirm popover does not show, ever, for when you update a page. Probably doesn't show for scheduling one either. It only shows when the button is labelled "Publish...".

And if you check the opt-out box in the publish confirm flow popover, you won't see it until you manually enable it in the ellipsis menu again.

What happens when a plugin (e.g. yoast) adds some functionality into that sidebar section, and I've already unchecked that checkbox. I'd never see it.

That's right, if a plugin adds content to the publish confirm screen, and you opt out of that, you won't see it. Same as if you hide a plugin metabox using Screen Options.

[maddisondesigns]

Thanks for clarifying those points.

[jasmussen]

Here's a quick stab at a mobile flow for this. It's not super in-depth or perfect, as some of these are dependant on improvements in #4081 and #4082 landing first, so they are more to illustrate the gist of how it should work.

You'd start in the editor:

The publish flow would be a modal:

[afercia]

Just to remind all of this should be easily operable with a keyboard 🙂 Will open a specific issue.

[karmatosed]

Worth adding into this would be removing duplicate behaviour like visibility and post format selection. We shouldn't have those showing in the document settings and the publishing flow.

[jasmussen]

Worth adding into this would be removing duplicate behaviour like visibility and post format selection. We shouldn't have those showing in the document settings and the publishing flow.

I think this was incredibly true when we had the _popup_version, where you could end up in situations with the sidebar open showing visibility and post format, and the popup open covering that, also showing visibility and post format.

However given the new flow that has a sidebar that covers the content of the Settings sidebar entirely, we go back to the original "publish confirm" ideal where we use this area to show last minute checkup information before final publish. Given that this sidebar covers the underlying sidebar, whether there or not, I feel, addresses that duplicate information issue. Furthermore, by keeping the information both in the Settings sidebar, and in the publish confirm dialog, we embrace both those who prefer to configure these settings before starting the publishing flow, those that do it intentionally while publishing, as well as those who simply forgot to do it until the publishing flow.

[folletto]

I agree. As well as since there's a flag to turn it off, duplication is a necessity.

[hedgefield]

This is a stellar improvement over the dropdown, nice work!

In terms of how plugins can integrate, and ways to solve the double-clicks on buttons and such, I have some ideas, but I'll sketch out those iterations once this is merged and tested. :)