Publish flow: redirect to post after publishing

[sarahmonster]

Through usability testing and watching people use Gutenberg, I've come to the conclusion that, for many users at least, the first thing they want to do after publishing a post is go and look at that post. (Note: this is based on rather anecdotal evidence and serves to validate my assumption of a year ago, so it's definitely possible I'm wrong here. I'd appreciate input, observations, or data from anyone who may have some in this department!)

It may be worth running that assumption and seeing how users respond to changes that optimise for that behaviour. If we assume that most users want to click to visit their post immediately after publishing it, let's do them a solid and take them there automatically, or as automatically as possible:

(Figma prototype and source)

I'd ❤️ some feedback here!

1. Are there other things we could show to be helpful to users in the post-publish panel? What are people looking for here? (I've also moved tag suggestions here as per Publish flow: Remove tag and post format suggestions from pre-publish panel #16310, but they may or may not be helpful.)
2. I used a Snackbar here because it feels a bit less interruptive and the message isn't critical, but when it disappears, the link to open the post-publish panel disappears too. Do we need a more persistent notification instead? Do we have a pattern that would be better suited here?
3. Does this present an accessibility or technical concern?
4. Will this change help users feel more confident in the publishing process? Could it help people accomplish their goals without getting in their way?

[afercia]

I'm not fully convinced automatically redirecting users to the published post is a good flow. As you pointed out, it could be the desired behavior for some users but it's definitely not the expected behavior for all users.

There are many, different, editorial flows. From small, personal, blogs to big websites with editorial teams with many editors, etc.: the flow greatly varies and the automatic redirect seems to me a bit too much broad assumption 🙂

Also, users with accessibility needs could be potentially very confused.

Regarding the snackbar: the accessibility team still needs to provide feedback on them. That will likely happen during today's weekly accessibility meeting on Slack.

Snackbars have some inherent accessibility problems that will need to be addressed. For now, I'd like to point out that seems to me the specific usage proposed in this case appears to to against their design recommendations. Specifically, the "Next steps" control. Reading the Snackbars readme:

A Snackbar displays a succinct message that is cleared out after a small delay. It can also offer the user options, like viewing a published post but these options should also be available elsewhere in the UI.

[karmatosed]

What about having options to set publishing flows? I know I'm taking us a little off course here but I can see a potential preference here that could be expressed in settings. For example, having the default as it is now but people being able to through the options modal set to 'go straight to post', 'go to something else'... there are a number of potential options here.

[chrisvanpatten]

I agree with @afercia that an automatic redirect is a big assumption to make. I like the idea of making the "Go to your published post" action as prominent as possible, but I really feel that it should be an explicit action that a user must execute.

[chrisvanpatten]

(That said as @karmatosed points out perhaps there could be some sort of setting to change this for folks who might want to view a newly published post immediately! Settings would let people create the experience that works best for them.)

[sarahmonster]

Thanks for the feedback here! Let's scale back from an automatic redirect and see how we could otherwise approach this.

Here's what I'm thinking might work:

(See also #16327 for that transition, since these two issues are pretty tightly coupled here.)

We could also go a bit more complex, and introduce an alternative next step (writing a new post, which I am guessing is the second most-common use case, although I don't have any data to back that up) and a checkbox for redirecting to the post in the future, but I think it might make sense to make this decision for the user, rather than introducing too many choices here:

I've dropped the tags and post format suggestions here as well, since we'll be dropping them from the pre-publish panel, but I'm not sure they add sufficient user value at any stage in the publishing process to warrant the added complexity. (See discussion on #16310.)

[karmatosed]

If we are reducing, I prefer the first version. I do understand why we are using a modal but maybe as an iteration exploring beyond a modal could be a potential? I wonder if a modal is really the best option, but I want to park that for a separate discussion.

[afercia]

Worth noting that, as pointed out in #16327 (comment), updating the whole content of the modal dialog isn't the expected behavior for the dialog content. That would be confusing for many users.

From an accessibility perspective, the main reason why we (as accessibility team) see a modal as an improvement, it's because it would remove the current publish "sliding panels", which are greatly confusing for users with accessibility needs.

What I see in the mockups above basically repurposes the sliding panels but this time within the modal dialog. Whether they actually "slide" in/out or not, the whole content updates. I'd like to discuss this pattern with the accessibility team in the next meeting and see what the best approach could be from an accessibility perspective.

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"

[mapk]

Based on today's Design Team slack triage, we've opted to close this issue for now. Our focus has shifted and we don't think we'll be revisiting this anytime soon.