Use a modal for the publish box

[hedgefield]

Is your feature request related to a problem? Please describe.
Publishing currently happens via the sidebar. A panel slides in that gives you some pre-publish checks, then you have to press the same publish button again to confirm. For usability and focus this is not super great.

Describe the solution you'd like
A modal would improve the focus you put on the 'mindful' task of publishing your content, and remove the feeling of having to confirm twice. Accessibility expert @afercia agrees with this approach:

This sounds like a step in the right direction. When modal dialogs are done well, they help to focus on a specific task. Seems to me the Publish flow is something that fits well with the dialog paradigm.

[sarahmonster]

@hedgefield, have you been reading my mind? 😜 See my long-winded comment down at the bottom of #7602.

[hedgefield]

Ooh lovely! It does offer more room for things like that preview too, a nice example.

[anevins12]

Excuse me, I thought that preview was for the website. It's twitter, got it.

[afercia]

We've discussed this proposal during today's accessibility team meeting on Slack (requires registration).

The general consensus is that a modal would be an improvement over what Gutenberg is using now (the sidebar). We second this proposal and encourage exploring further, thank you!

Worth reminding one of the main accessibility issues in Gutenberg is about the sidebar paradigm: sidebars are difficult to navigate to and back for users with accessibility needs, as outlined in the Accessibility team report published on October 2018 and also reported by the WPCampus accessibility report.

Population affected by the sidebar issue:

• Blind
• Low-Vision
• Motor Impaired
• Cognitively Impaired

In the accessibility team we see anything that moves Gutenberg away from the idea of sidebars as a welcomed step in the right direction.

Concerns were expressed on the actual implementation details of the modal dialog. Modal dialogs help keeping focus on specific tasks when well implemented. The amount of information within the modal dialog is a concern: that should be simplified as much as possible, as well as the amount of decisions to be made before publishing.

Additional concerns were expressed on the real need for the "pre-publish" checks.

These are all things related to the actual implementation that we're guessing can be discussed more in-depth at a later stage.

Pinging @bemdesign-er and @NatAtGeni to be sure I didn't miss anything from the discussion on Slack.

[brentswisher]

I've started on this, as part of the larger issue here: #7602. I'm still figuring out how to break that up into manageable iterations as just moving the current panel into a modal isn't a great UI experience, but wanted to leave a note that it's in the works.

[sarahmonster]

@brentswisher yay! Do you want to push what you have so far as a draft PR, and I can have a look? I have some thoughts about how to break that giant issue into smaller, iteratable pieces but it may help to see what it looks like with the first step implemented first since I imagine there's probably a little bit of cleanup we'll need to do with this first-step change.

[karmatosed]

I have a little suggestion regarding this. What about considering an elevated panel that could be partial across the page? The benefit here would be it could have a lot of space for extending. I am just showing some rough sketches here as an idea to bring into the mix.

One little note is that the links (blue), on hover are designed to have underlines so they aren't only using color as an indication.

My thinking against the modal is that it causes a break in flow and by using this sheet view, we could open up a bit more potential. In suggesting this, I wanted to both keep the feedback about focus, not being a sidebar and trying to open up a future for extending.

I would welcome feedback and love to see if anyone wants to explore as to what content goes in these sheets. For now, I have put some rough suggestions there but it would be something to iterate.

[tofumatt]

My thinking against the modal is that it causes a break in flow and by using this sheet view, we could open up a bit more potential.

The publishing of an article is a definitive break in flow though; it's the end of writing and tweaking a post/page and deciding: "okay, this is finished; I want to publish it to the world now". For sighted users, that abrupt break in UI is a good visual cue, to my mind.

[kjellr]

My thinking against the modal is that it causes a break in flow and by using this sheet view, we could open up a bit more potential.

It's totally true that a modal introduces a break in flow, but to @tofumatt's point above, that may be a welcome break in flow.

UI component-wise, one of the things I really like about the standard modal approach is that it's borrowing an already-established UI component. This off-to-the-side version seems a bit similar to our current publish flow in that it feels a bit non-standard. It's its own thing — new UI for the user to adjust to. If we can think of other places we'd use a sheet like this, then it's totally worth considering, but I'm not totally clear on the benefit it has over a standard modal.

Regarding the modal use in general (this is applicable to both versions), one thing that we definitely lose is the ability for people to view the post content and give it one last look over. The current sidebar-ish approach still keeps that area visible, which is nice for those of us who're a little nervous to publish.

[brentswisher]

@sarahmonster - I had hoped to get a draft PR up before the holiday but it didn't happen, I'll have family in town for the next week or so, so probably not much time to update. You can check out https://github.com/WordPress/gutenberg/tree/try/publish-via-modal if you want to see what's there so far, but it is very (very) early. One UI problem I noticed that I would like to try and fix first is the clicking "private" published immediately confusion/a11y issue. I have some ideas that I think could work, but unfortunately, they will have to only exist in my head until next week sometime :)
And thanks to everyone else for the thoughts/feedback!

[jasmussen]

Forgive me if I'm missing context here, but I'd like to step back here and ask some questions around the problem of the publish sidebar overlay that a dialog means to solve, but before I jump in, I'll just reiterate a few terms for clarity. Please correct anything I'm getting wrong here:

• "Modal" describes a behavior, not a design. When an interface that is modal is opened, focus is moved there and trapped inside the modal until you act upon it with, for example, escape.
• "Dialog" means a "window" of sorts, usually centered on the screen and with a scrim behind it. Dialogs are nearly always also modal.

To the extent the above terms are true, the publishing sidebar is already modal. Focus is moved there, and is constrained inside the panel until it's acted upon. So in that vein: what problem does the dialog interface solve? If the answer is to help you focus, would a scrim over the content, (as Tammie suggested but maybe not that big) be a sufficient improvement to aid the cognitive focus?

The benefit the sidebar interface has over a dialog is that it doesn't cover any content — you can actually look at it, as you add tags and go over last minute changes. Whereas a dialog will cover content quite a bit.

[sarahmonster]

@brentswisher enjoy your holiday! Feel free to ping me when you're back and ready to look at things, and in the meantime we'll continue hashing out the finer details. 😉

Thanks for the clarification re: terminology, @joen! Some of the confusion likely derives from the fact that the component we refer to here is named a Modal—and that confusion may continue unless we can determine a strategy for renaming it. (#14195)

For reference, the current design we've been working for (using a dialog) looks like this:

There are a number of different issues discussing what actually goes inside these panels, but #16327 is probably the best one to follow along with if anyone's interested in discussing those details or seeing how the pieces are proposed to fit together as part of a larger flow.

In terms of "do we use a dialog or a side sheet", let's look to the pros and cons of both approaches suggested here:

Dialog (Modal)

[+] Uses existing Modal component used elsewhere in the UI.
[+] Focuses user attention on most important task at hand (making sure the publish settings are correct).
[+] More consistent behaviour across small and large screens.
[+] Encourages developers to keep plugin interactions at a minimum, maintaining a less cluttered UI
[+-] Completely covers post content. ([+] For users who want more focus, [-] For users who want to double-check their post prior to publishing.)

Side sheet

[+] Allows for side-by-side reviewing of content for those on larger screens (albeit blocked a bit by the scrim.)
[+] More natural scrolling for longer content (This is a guess—may require testing or technical prototypes!)
[+-] Introduces a new component not used elsewhere in the UI ([+] if we have use for it elsewhere, [-] if we don't.)
[-] Visually may look a bit empty/awkward on a large screen if it isn't extended by plugins.

Some questions:

1. Are there considerations I'm missing here?
2. Which of these options is best from an accessibility perspective?
3. Do we have any data to influence our decision here?
4. How do we want to come to a consensus about the best approach?

[jasmussen]

Thanks for the thorough response to my brief interruption!

Some of the confusion likely derives from the fact that the component we refer to here is named a Modal—and that confusion may continue unless we can determine a strategy for renaming it. (#14195)

Absolutely, +1+1+1 that ticket.

The design looks good, and although I would argue there's greater value in being able to see the content in context of publishing, ultimately both designs could probably work.

But a benefit to the obvious solution of just adding a scrim below the publish dialog (and possible letting you click that also to close it), is that it's arguably the smallest possible iteration that can let us fix the issue at hand. Given how many big changes we've made to the editor over the year, the smaller changes we can make that accomplish the same is arguably a benefit.

To provide a counterpoint to myself, if the proposed solution is fundamentally better for users, then obviously the best solution should win. But even then, it might make sense to go with the tiny pull-request solution to fix the problem now. We can keep this ticket open if need be.

[afercia]

I'd like to clarify an important point, from an accessibility perspective.

To the extent the above terms are true, the publishing sidebar is already modal.

No, it isn't 🙂

Focus is moved there, and is constrained inside the panel until it's acted upon. So in that vein: what problem does the dialog interface solve?

Looks like you're considering only keyboard accessibility. When it comes to assistive technologies things works differently though.

Screen readers, for example, provide a huge amount of ways to navigate content. Tabbing with the keyboard is not the main one. Regardless of whether tabbing is constrained within the publishing sidebar, screen reader users can exit the sidebar in several ways, at any time. Thus, the sidebar is not "modal" at all. It is only for keyboard users. There are other assistive devices and technologies for which "constraining tabbing" won't work as well. Speech recognition software, for example, is one of them.

The only "modal" UI pattern that is fully supported by browsers and assistive technologies is a modal dialog, as described in the ARIA specification.

Screenshot to illustrate just one of the ways screen reader users can exit the Publish sidebar:

Although keyboard focus is within the sidebar, I can jump to any other form control in the page. Same applies for headings, links, etc.

Only an ARIA modal dialog effectively "hides" the rest of the content from assistive technologies.

[brentswisher]

Thanks @sarahmonster - I should be able to get back into this in the upcoming week, just reading up now and here are my thoughts:

From a developer side, there is already a "Modal" component (which is styled as a dialog) that I believe we should try to use here if at all possible because it is already coded/vetted for accessibility. Regardless of whether the visual design is a sidebar or dialog, it should be seen and interacted with as a modal following WCAG guidelines.

I'm thinking it might make sense to explore a way to extend/style it so that it looks similar to the current publishing panel while being an actual Modal component behind the scenes. This could accomplish a win for better accessibility and move the larger issue of updating the publishing flow forward, while still being a smaller "fix it now" change as @jasmussen suggested.

The obvious alternative I see is making a wholesale replacement of the current flow with a new dialog based modal, based on @sarahmonster's mockup. While personally, I like this proposed flow much better, I recognize it is a large change to one of the most frequently used sections of Gutenberg, and the probability of it getting bogged down seems fairly high.

Would love to hear thoughts on the best process for moving this forward. In the meantime, I will continue the initial work of just getting it into a modal component and verifying that fixes some of the accessibility issues, then looking into technical options for styling it to look like the panel that exists now.

[afercia]

Not sure going for a smaller "fix it now" is worth it 🙂This issue is about exploring a modal dialog, not about repurposing existing UI that proved to be not so great.

Also, what I'm seeing emerging from the various user testing sessions, for example test three and four in the first part of the WCEU testing sessions, is that some users expect to be able to just click and publish.

I'd like to suggest to explore to invert the current option: by default, no pre-publish checks. This way, users that don't need them can just click and publish. When enabled as option, that means users opted to focus on pre-publish check and a modal dialog makes perfectly sense.

[afercia]

/Cc @mapk @hedgefield I'd like to hear your thoughts 🙂

[mapk]

I really like the latest mockup from @sarahmonster here for these reasons.

1. It feels like the right amount of information (dropping the tags and no post share preview). To @joen's note about the Dialog covering content, it feels safer to restrict the number of things this publish Dialog can do since the content is hidden in the background.

2. It appears a Dialog solves some a11y issues that are made more apparent with slide outs. It helps focus the user on the one thing they clicked the button to do in the first place – publish.

My only suggestion is that if I wanted to update one of those settings, I'd like a way to click it to drop me out of the Dialog and into the right settings panel to do so. Should we also include a "Cancel" link for this particular Dialog?

[sarahmonster]

I'd like to suggest to explore to invert the current option: by default, no pre-publish checks.

I'm not opposed to this idea in principle, and it certainly simplifies things, but I do wonder how we'd reveal this option to the users who might want or need them. Right now, we can reveal the option to turn them off contextually (ie, inside the checks themselves), but having an option to enable them couldn't be shown contextually in the same way, which means that users who might find them helpful may never know that they exist at all.

There's also the option to use a split button to allow users to choose, at the time of publishing, whether they need additional checks or not. We explored this option as part of this process but discarded it, which I think was the right call. I'm not sure it's an established enough pattern to avoid introducing confusion for users, rather than providing them with more options. I'm not certain if this would be more or less confusing that our current setup.

The most compelling use case for these pre-publish checks, that I can tell, is in reinforcing date and other publishing settings, to avoid stress cases where users have accidentally broken news embargoes due to unclear settings. (See #13230 and #12256) I'm not sure about the full history behind their introduction, and I don't have any user data about whether people find them helpful or annoying. It'd be really helpful here to have some data about the frequency with which users disable the pre-publish checks.

Should we also include a "Cancel" link for this particular Dialog?

See mockups in #16327 (comment)

Note that the "show pre-publish checks" is also missing here, as is a close "x" in the corner of the Modal—the former being my forgetful soul, and the latter being a missing piece in the Figma component.

[afercia]

I do wonder how we'd reveal this option to the users who might want or need them

Yep I get the point and considered it. One option could be making the post-publishing "dead-end" a bit more useful 🙂and include the information there, e.g.

"Would you like to have more options before publishing? Enable the Pre-publish Checks."

This would allow to "clean" the publish flow a lot for users who just want to publish right away. Far from pretending the WCEU usability test session is fully representative of the WordPress user base but worth noting that only in the first part of the results 2 users out of 5 were surprised for the 2-step publish flow:

• test three: "did not like pre-publish check"
• test four: "Clicked the publish button but post was not published, needed to then click publish again. Was expecting to publish on first click."

[brentswisher]

While I know that switching to a modal is a big change, I think we might be reaching a point where we are trying to cram too much into this issue. Changing the default value of the "always show pre-publish checks" can be handled separately from this change, as one is mostly a UI change and one is more behavioral. I would say if you want to have that conversation it should be its own issue where that discussion can take place.

Edited: Updated to clarify my reasoning

[paaljoachim]

Is this issue still valid?