Publishing flow: establish a clear transition throughout the process of publishing

[sarahmonster]

Right now, when a post is being published, there's very little to indicate something is happening:

Note: this process happens really quickly here—I think because it's on my local machine—but I'm sure I've seen it be slower. If it's this fast on all setups though, we may not need or have time for a transition here.

Instead, I'd like to propose showing a small transition whilst the publishing process is happening, to indicate that it's working on it, followed by a change the publish button throughout the transition. See #7602 for more context around the overall flow here.

This mockup uses a progress bar to give a better visual indication of forward progress and momentum. That said, I'm wary of a meaningless progress bar that isn't actually tied to any action—we might need to consider something more infinite in nature (so, a spinner) if we can't tie the progress indication to any meaningful measure of the action taking place in the background.

[afercia]

I'd tend to agree the progress bar is a bit too much, and also tricky to implement because it's not possible to calculate how much time the publishing action will take.

Regarding changing "on the fly" the Publish button to "Publishing..." and then "Published", this is a very different case compared to #16308 and I wouldn't recommend it because:

• buttons are meant for actions, not to convey a state
• thus, the two state indications should be separated from the button
• when publishing, the "Publish" button is the element that currently has keyboard focus: changing it to state indicator (likely plain text) would produce a focus loss

Also, looking at the animated GIF above, I see the whole content of the modal dialog updates on the fly: while some parts of the content can be updated, I'd strongly recommend to not update the whole content as it would be confusing for users with accessibility needs (screen reader users, users with cognitive impairments, low vision, etc.) and it wouldn't allow to keep keyboard focus within the content (keyboard users).

I'd like to suggest to explore a different option: for example, updating only the bottom part of the modal. Reduce all the animations. Use a state indicator separated from the buttons.

Implementation detail: each step should use a spoken message to give proper feedback to screen reader users.

[karmatosed]

Have you considered top progress bar visuals like in the case of Figma? I think there's a more visually subtle balance that could be brought in here.

[afercia]

Technically, it's not possible to calculate how much time the publishing action will take so on what exactly the progress of the progress bar should be based?

[sarahmonster]

Let's avoid using a progress bar if we can't tie it to any meaningful metrics, since it wouldn't actually communicate any helpful information to users.

It sounds as though we need to scale things back and try a few different alternatives here:

v2:

v3:

v4:

The current publishing process changes the "Publish" button to a "Publishing..." button (see #16303), but I've eschewed this pattern and instead have removed the button entirely when it isn't actionable (basically the moment it is pressed). An alternative solution could be to leave the button in place, but disable it, but this sounds like it would be needless visual noise.

The final "your post has been published" panel may need a bit of fleshing out (what is useful for users at this stage in the process?) but I'll look at that in a bit more detail in #16341.

Which of these solutions feels like the most promising direction in terms of usability and clear indications of progress for both visual users and screen reader users?

[afercia]

Thanks @sarahmonster for your further explorations! A few things 🙂

1

and instead have removed the button entirely when it isn't actionable (basically the moment it is pressed). An alternative solution could be to leave the button in place, but disable it, but this sounds like it would be needless visual noise.

We can't remove (or hide) the Publish button because that will trigger a focus loss for all keyboard users.

2
I'd suggest to not update the modal title (see v3 v4) because it gives the modal dialog its accessible name. It's best for the name to not change.

3
The modal needs a close button: this should be standard for all the modal dialogs. At the very least: the "X" close button at the top right corner.

4
I'd suggest to start thinking at a design for notices/warnings to be displayed when publishing fails for some reason.

[sarahmonster]

@afercia Thanks for the feedback!

1. If we can't remove the Publish button, can we disable it? How do we skirt this issue in the current flow, where the Publish button changes to "Publishing..." and then disappears?

2. Does this mean that, of the above solutions, v3 and v2 would work the best, or is there a better way that we can approach this? Would a better solution here be to just close the modal after clicking the "Publish" button, and then using a Notice or a secondary Modal to advise users of the success/failure of the process?

3. Agreed x 10000. Ideally there should be three escape methods: the escape key, an X in the top right corner, and the "Cancel" link shown in the above mockups. I'm not sure if these are built into the Modal component (they aren't in the Figma component), but either way, we should test + add as needed.

4. Great idea! In what circumstances might publishing fail? It would be good to have some specific examples to work from so we can figure out how best to display helpful error messages to users.

[afercia]

1
The pattern Gutenberg already uses to avoid focus losses is to just "noop" the button and style it as it was disabled, with an aria-disabled="true" attribute to communicate its state. This is implemented in several places, e.g. the block mover buttons, etc. The alternative is to manage focus programmatically ie: move focus to a logical place, but in this case there's none (so far).

2

I'd suggest to not update the modal title (see v3)

Sorry, I meant v4. Not sure, I'd like to discuss the multiple modal option with the a11y team first.

3
Yeo, the modal already supports clicking outside, Escape, and the X button to close. An additional "close" control can be added within the content, e.g. the "Cancel" button.

4
Publishing may fail for whatever reason 🙂 network failure, power down, hosting hiccups... For example, setting the browser offline via the dev tools I get this in the WP 5.2 Gutenberg:

(I know notices have changed, this is just what Gutenberg currently does)

[sarahmonster]

Lovely, thanks for the additional information! I'll let this issue sit (along with #16341, and probably #15847 as well, since these tickets are very tightly coupled) until the accessibility team has had an opportunity to discuss, and then we'll loop back to see what solutions may help best clarify and explain this process for users of different devices.

[mapk]

I want to make a poster out of this comment thread with big words that say "CROSS TEAM COLLABORATION." Thanks for working through this!

From a design perspective, the dialog works well when it's filled with content, but after clicking "publish now" it's rather empty. Can this be explored a bit more? I don't want to just fill it with needless info, but can the dialog resize without a complete refresh after click? Will this meet a11y standards?

Really bad example:

[mapk]

Also noticed this little oddity. The "Publish" word in two different sizes caused me a doubletake. Do you think it's important enough to keep as is, or can the copy be revised?

[afercia]

From an a11y perspective, updating the modal dialog content should be evaluated carefully, as it's not the expected behavior. A dialog is supposed to present choices and actions. Not a "flow" with multiple steps. As mentioned in other issues, the part to update should be as small as possible.

Alternatively, I'd like to suggest to explore the idea of using multiple modals as mentioned in #16341 (comment)

Off the top of my head, I can only think at managing this flow using multiple modals, like in the W3C example in the ARIA Authoring Practices. See https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html

• click "Add Delivery Address"
• then in the first modal, click "Verify address"
• then in the second modal, click "accepting an alternative form"

The "Publish" word in two different sizes caused me a doubletake.

Hm, maybe the second one could be "Publish date"? That's what it is.

[sarahmonster]

I'm curious about whether the multiple-modals approach could work here—it seems like it would make sense to close the pre-publish dialog after the user has pressed the "publish" button, but what would happen next? Would we want to open a second dialog to show the publishing process?

Basically, we have three states here: pre-publish, publishing, and post-publish. We need a reliable way to communicate with users that something is happening, but we also need to be sure we aren't getting in their way, and we don't want to leave them with three dialogs to close after the publishing process has finished!

I wonder if something like the following might work:

• User presses "Publish..."
• Open pre-publish dialog
• User presses "Publish"
• Pre-publish dialog closes
• Small notification appears to indicate that publishing is in process (this could be a Dialog, Notice, or Snackbar, depending on the usage)
• Publishing completes (or fails) → in-progress notification self-closes
• New post-publish notification appears (requires user dismissal)

It's the last bit here that concerns me—which notifications do we use here to follow our own rules? Are there issues with a notification that self-closes like this? How do we remove a notification that no longer has any relevance for the user in an accessible way?

Would a compromise solution work... something along these lines:

• User presses "Publish..."
• Open pre-publish dialog
• User presses "Publish"
• Pre-publish dialog closes
• New dialog opens to indicate publishing is in progress (maybe just with a heading "Publishing..."
• Publishing completes (or fails) → dialog adds new text to indicate completion of process ("Publishing... done!")
• Dialog could also contain post-publish checks if needed, and would require user dismissal.

I can illustrate these options if it helps clarify things, but it sounds like it may help to think through the process in words, rather than visuals, at this stage, to ensure we get the semantics of the process right.

As far as the labels for the controls here, let's keep that conversation going in #16127. I'd like to prioritise for clarity of communication here, since we've had a number of issues with users getting confused about publish dates.

[afercia]

Yep, whether it's a single or multiple modal dialogs, it should be very well designed. Of the two options above, the second one looks simpler to me.

There's one more thing to consider though. What happens if users accidentally close the modal dialog while publishing is in progress? For example with an unintended click on the dialog overlay. How do I reopen the modal dialog at that point?

Usually, the publishing progress is fast, but it could be slower or very slow for long posts or for any reason (hosting overloaded, network hiccups, etc.) When it's slow, the "publishing" transition takes a while and at that point users might close the modal dialog. Worth noting this can happen also now with the side panel. When closed, there's no way to reopen it.

In the animated GIF below, I'm throttling the network via dev tools to better illustrate:

when the panel gets closed, I couldn't find a way to reopen it. At least, the publish button still says "Publishing..." but clicking it doesn't do anything.

[sarahmonster]

What happens if users accidentally close the modal dialog while publishing is in progress?

Does a user need to be able to re-open the dialog, if it's just a temporary to inform the user that a process is taking place? A third dialog will appear to let them know when/if it's completed successfully, but perhaps it would help to add some kind of indication in the underlying interface that a process is taking place. Our best patterns for doing that right now are Notices and Snackbars, but we could also consider introducing something new that blocks or covers the underlying content. (I have extremely mixed feelings about this though. What if I want to edit or read my post whilst the publishing process is happening?)

Let's look at how the options suggested here might break down visually:

Opting for one of the notifications options helps most with the "what if I accidentally close the dialog while publishing is in progress?" issue, but may feel a bit jerkier and less immersive overall.

Here's a comparison of how that might feel, albeit with no animations to smooth the transitions:

I think the three-modals option works best visually, but I'd like to figure out which approach is best from an accessibility perspective and move forward from there.

[enriquesanchez]

I also think the three-modals option feels the best. It think that it clearly articulates and communicates status of the three steps on the publishing flow, without the need to rely on additional notices or snackbars.

And going by @afercia's comment and example above regarding the idea of using multiple modals, this looks like the way to move forward.

[karmatosed]

This was brought up in design triage and for now, closing to review later in iterations. There is a lot going on with the flows right now which means letting that settle then look at everything holistically is a great plan. If someone still wants to explore they can as issues can always be reopened later.