-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publishing flow: establish a clear transition throughout the process of publishing #16327
Comments
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:
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. |
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. |
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? |
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: 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? |
Thanks @sarahmonster for your further explorations! A few things 🙂 1
We can't remove (or hide) the Publish button because that will trigger a focus loss for all keyboard users. 2 3 4 |
@afercia Thanks for the feedback!
|
1 2
Sorry, I meant v4. Not sure, I'd like to discuss the multiple modal option with the a11y team first. 3 4 (I know notices have changed, this is just what Gutenberg currently does) |
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. |
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: |
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)
Hm, maybe the second one could be "Publish date"? That's what it is. |
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:
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:
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. |
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. |
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. |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: