search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.56k stars 4.22k forks source link

Enhance the Publishing flow #7602

Closed karmatosed closed 4 years ago

karmatosed commented 6 years ago

Update 28 June 2019 (exactly one year after originally opening!) by @sarahmonster:

This issue is a long discussion about the overall experience of publishing a post and is now being used as a tracking issue to. To contribute ideas, feedback, or just follow along with the conversation, please use the following issues:

Original issue text from 28 June 2018 by @karmatosed:

Right now on publishing the experience comes to an abrupt end. For example:

2018-06-28 at 11 42

Whilst the content of the post may not mean we want to celebrate with balloons and ribbons the publishing, having something that doesn't just stop at this empty end is needed.

Preview looks like this....

2018-06-28 at 11 55

A few ideas could be to have an animation such as here: https://www.wired.com/2013/12/a-sandbox-for-experimenting-with-animated-typography-built-by-a-google-designer/.

This has been talked about in other issues and it's worth creating one here to just focus on this and explore. Along with adding some flourish to this page of engagement also looking at the format. This is pretty flat as an end to the experience. Beyond any animation this screen showed above could do with some iterations itself.

Could perhaps bringing in a better previewing to this all also be wrapped in? Thinking about this in stages may be the best, what can we get in for phase one. Then maybe having a preview modal or something on preview could be brought in later phases. I think it's worth in designs exploring freely then distilling back.

Worth noting that exploring things like having this across all devices is important. What could be created that adapts well?

sarahmonster commented 6 years ago

Since there's a rather a lot at play here, it might make sense to split these into two different issues. This is how I currently see these two improvements breaking down (and I have questions!):

  1. The post-preview-button loading screen ("please wait, generating preview") that appears when you click on the "Preview" button whilst working on a post. Since this screen will appear for a varying length of time for different users, we may want to consider what we can do to make it interesting or exciting. A fleurishy animation could be one approach, or we could try an empty-state animation to help with perceived loading time.
  1. The post-publish-panel component that appears after you've published a post. Right now, a sidebar pulls out and says the post is now live, with a "what's next" section offering two options: 1. Visit the post and 2. Copy the link. This is pretty anticlimactic, so we'd like to give it more character and sense of purpose, whilst avoiding being too congratulatory or cutesy.

I'm having a comb through issues to surface history and prior conversations around these two experiences as well, but if there are particular discussions that it'd be helpful to read, I'd appreciate a link or two as well. 😸

karmatosed commented 6 years ago

Thanks for tackling this one @sarahmonster. I am totally into splitting into issues and leave that up to you if want to. I do think it's perhaps the same flow but totally could be.

Is the primary intent here to improve the perceived loading time, or to add interest to the experience?

Both! Mostly improving perceived loading time but also engaging is good here.

How much time (range) do we expect this screen to be visible for?

This can vary but usually isn't long at all, it just 'could' be. Also having anything is better than even a flash of white blank screen.

Do we also need to design for a potential failure? I've seen a few cases (my local install is currently doing this) where the preview screen appears and the post preview never goes away.

This used to be a bug, it shouldn't be anymore... if it still is lets get it fixed over designing around a flaw.

Will this sidebar panel be extensible by plugins?

Yes.

Why have we opted for a sidebar here, rather than a modal, notification, or full screen?

So it can be extended and it's a better experience than a modal, there also doesn't need to be a full screen take over. Right now let's stick with sidebar.

Do we have any research on what action users want to take once they've published a post? (I am guessing that some users will want to ignore any prompts and get on with something else, whilst other users would like to proofread their post in-situ and probably share it to social networks, send it out via email, tweak it for SEO purposes, etc, but this is purely speculation.)

Most seem to want to see post or just carry on. It feels like a 50/50 split from observations.

sarahmonster commented 6 years ago

I'm splitting the preview loading experience into #7922 and will leave some ideas there, so as to keep this thread focussed.

Benchmarking other publishing flows

Before making recommended changes, I looked at what other services are doing, to get a sense of how it's handled elsewhere, what works well, and what's not so great. It turns out there's a wide variety of experiences offered by different services.

WordPress.com

2018-07-10 13 28 28

Two presses to publish, then redirects to post itself, with a "Post published on [site]!" dismissible notification and a top header bar that allows for previewing the post at different breakpoints, going back to edit the post, and copying the link. Updating a post just prompts a notification whilst remaining on the same screen. Very similar to the current Gutenberg experience, but a bit more polished.

Wix

2018-07-10 14 07 24

One button with a dropdown. Pressing publish opens a (dismissible into the future) modal that offers to share to social media (email, Facebook, Twitter, LinkedIn).

Medium

2018-07-10 14 15 01

Publish button pulls up a pre-publish panel with some tips (add tags, add an image, share on social media) and a second publish button (below!). Pressing the second button redirects to the new post. (Post = "story")

Ghost

2018-07-10 14 42 25

V similar to Medium, with a publish (indicated by a dropdown, not a button) then pulling up a post-publish panel that gives the option of "ready to publish your post?" + a post now/schedule for later option, and a second publish button at the bottom. Nice animation and use of icons on the button from publish > publishing > published. Also shows a "Published! View post" modal at the bottom left hand side of the screen, although it's super easy to miss. (Blog = "publication", post ="story")

Hubpages

2018-07-10 15 09 56

This is a pretty terrible experience overall, and required a text message confirmation before it would publish. Once you finally get all that sorted though, you get a "Congratulations! You've posted your first article!" notification that also includes some info about their QA process, suggests to write another article ("Your new article is lonely: Create another article!"), and a copyable link to the article itself. (Two, actually.)

Contentful

Required a German version and a specific format for the title before it'd allow me to actually post anything. Uses a single "publish" button with a drop-down for more (change status.) Never actually got through the publishing flow, so who knows what happens at the end!

Tumblr

2018-07-10 15 28 08

There's a button with some drop-down options (post later, etc). One click to publish ("post", in this case.) Clicking through redirects you to the main homepage/feed, with no indication the post published. (Where did my post go?)

Blogger

2018-07-10 15 30 57

Uses a simple "publish" button. Redirects back to a post list. Gives me a whole slew of notifications, but nothing related to the actual post I published.

Svbtle

2018-07-10 15 36 27

First you need to use the "save idea" button, then an additional menu area appears with settings, preview, publish button, and save button. Hovering changes the text to "publish now". Clicking through causes a modal ("You sure you want to publish now?) Clicking through makes the whole screen pulse green, then a bright blue "published" notification appears, + a link to view post.

Livejournal

2018-07-10 15 51 44

Uses a drop-down "Tune in and publish" button (drop up?) that opens more options, similar to Ghost/Medium but with some button styling, rather than just the dropdown styling. Pressing opens the dropdown/up with additional settings (post to different journals, publish date, plus RSS, x-post, sticky, etc options), with a second "publish" button at the bottom. Clicking that then redirects to the new post.

Pen.io

2018-07-10 16 02 44

Suuuuuuuper simple. Hit a publish button, your post (page) is published. No bells and/or whistles.

sarahmonster commented 6 years ago

Suggested improvements to our flow

For comparison, here's Gutenberg's current publishing flow in action:

2018-07-12 09 30 10

Here's my current thinking for how we can improve this flow:

Pre-publish

Post-publish

On "hurray!"

The first time you publish a post is very different from the hundredth time you publish a post. How do we account for these varied experiences?

Should WordPress commemorate this in some way? We could consider congratulatory milestones: published first post, published six posts this month, written x words, etc. Nothing too confetti-laden, but perhaps a simple message in the post-publish screen: "Great work on your first post!"

This would be a nice way of putting a bit more emotion in the interface, but we don't want to annoy or disrupt users. Can we note important milestones without potentially seeming tone-deaf if someone's writing a blog for therapeutic purposes, or about a traumatic subject?

Research

I've tried to approach this with the intention of being as helpful as possible. How do we help users get the most from their new post? What do they want to do immediately after publishing a post? I looked for research into this but couldn't find anything specific to "what do users want to do after publishing a post?" Thus, my recommendations here are mostly based on guesswork, assumptions, and/or looking to what others are doing in this space.

I think it could be super beneficial to do some user testing here, both of the before flow and the after flow. My thinking is that it would be ideal to test it with the following types of users:

Do we have a pool of users anywhere to test with, or have usability testers typically been recruited on a per-test basis?

Next steps

I'll work on some mockups for this suggested flow next, but I'd welcome any ideas or thoughts on the suggested approach here!

karmatosed commented 6 years ago

This is all really great @sarahmonster as an exploration, thanks. Let me dig into some responses.

Now onto your improvements to respond. Firstly some super interesting ones here, thank you for your suggestions already there.

The pre-publish panel should be dismissible (either a pre-checked "Show this every time I publish" box or a "Don't show this again" checkbox) for power users who don't want to be forced to click twice to publish a post. I could see this being frustrating for people who publishing multiple times a day and just want to get on with it.

This is interesting. How do you get it back if want to change mind?

Giving a prompt to add tags is nice, but it could also be moved to post-publish, since it's not critical to the pre-publishing experience, which should be geared toward making users feel confident that they're ready to go for it and post.

How would you suggest this?

We could improve the animation states of the publish button to show what's going on. (Ghost's is super nice, with the changing colours and icons.)

Yep :)

I think a better pattern here could be to have a visual indication that the publish button doesn't trigger an action, but rather pulls down a sidebar with additional actions. (So, a little drop-down icon.) Converting the sidebar here into an actual drop-down may help distinguish it from the settings sidebar, as well as connecting it more closely to the button from which it originates.

I'd love to see your explorations there considering the extensibility complexity.

There should also be a secondary "Publish" button at the bottom of the the pre-publish panel, so you check all your settings, looks good, and then the final step is to press the publish button. At the very least, the interim Publish button should change state more noticably, so that it's clear a second click is required (see WordPress.com example).

I am torn about this, I don't think double buttons work in this sense. Maybe explore other things first? I'm not ruling it out as much as want to see the other impacts then loop back.

I'd love to see you explore all your post-publish points. Same goes for your 'hurray' points, love to see what you come up with from those.

Thank you for taking such a considered approach, look forward to see where this goes.

johnmaeda commented 6 years ago

Can we note important milestones without potentially seeming tone-deaf if someone's writing a blog for therapeutic purposes, or about a traumatic subject? +1 to this @sarahmonster -- the idea of "Yay!" etc is well-meaning but ill-fitting in all cases.

sarahmonster commented 6 years ago

I've mocked up two different solutions to this problem, exploring different approaches to various different parts of the problem. I understand that this may, in a few cases, be re-introducing patterns that have been decided against in a previous iteration, but given that a great deal has changed since, I figured it would be good to approach it with fresh eyes.

I've designed this from a mobile perspective first in order to ensure that we prioritise for the simplest possible display first. I've just started with two different explorations, in order to get some ideas out there, but I expect we'll combine some of the component elements as we iterate on this flow.

Animations and UI elements are obviously pretty mockuppy at this stage! 😜

Variant 1

2018-07-17 03 54 15

mock1

Prototype: https://automattic.invisionapp.com/share/USMZOBPWMHZ#/

Here, I've split the "publish" button to allow for two different actions here, depending on how trigger-shy the user is. Clicking the main part of the button publishes the post immediately, and clicking on the drop-down icons pulls down the pre-publish panel, now as a popover container instead of a sidebar element, so it feels more consistent with other patterns. (See conversation in #7878, and my understanding is that this may also help with some accessibility concerns.) I've also dimmed the background to reduce noise and improve focus.

This one makes use of a secondary publish button in the popover, but either button would work to publish the post. My thinking here is that if you're opting to go through a pre-publish check by clicking on the down-arrow portion of the button, you want to actually read through those checks in a (relatively) linear, down-headed sort of fashion. Putting a button below all that would be a logical place for people to expect it, and we don't need to design in this case for the impatient user who just wants to click through and get it over with, since they can avoid the double-click on the button altogether.

The focus here is on the post-publish panel, which appears to give tips and next steps. I expect that plugins would make heavy use of this and would likely be responsible for adding a lot of the functionality that people would want post-publish (fine-tuning SEO settings, sharing on social media, etc). I've tried to focus on what we can do with the out-of-the-box experience to make it feel like an accomplishment, without trying to be too celebratory or cutesy, as well as to guide the user in getting the most from their post.

Variant 2

2018-07-17 10 41 07

mock2

Prototype: https://automattic.invisionapp.com/share/7FMZOEYZST6#/

This variant uses an alternate iteration on the "publish" button, more aligned to the WordPress.com solution. It does mean it's a bit harder to decide on-the-fly if you want a pre-publish checkup, but the panel will be more discoverable for more users. It also means we'd need to store a setting somewhere to allow users to opt out of the double-click publishing experience, which I think we'd need to store under "Settings" in the ellipses bar menu.

In this, your post is highlighted more immediately after publishing, but it feels less like something important's happened. It is, however, a lot easier to review your post for any issues, then work on any post-publishing follow-up actions, like adding tags or sharing on social media.

karmatosed commented 6 years ago

Thanks for all this work @sarahmonster, so much in good way to process.

First, I am very pleased to see a focus on mobile first. I do wonder as an over-arching point how does this work if someone extends the sidebar? Maybe could you also explore a full sidebar just as a comparison? Someone could have a few plugin that check things like SEO, tags, spelling and even have more options on publish like sending to social media. What would those look like as a stress case?

First version:

Second version:

mtias commented 6 years ago

Closing in favor of #7922.

sarahmonster commented 6 years ago

I'm going to break this flow down into its constituent components here so that we can evaluate the different options for different parts of the flow separately, then I'll bring them all back together to test out a full prototype again. Again, I think testing on users could be really helpful here, so I'm going to see about a good way of going about doing that.

Publish button

Having thought on it more, I'm thinking the split button solution is a better option for users, as long as we can ensure they understand how it works. I'm heartened here by the fact that we have prior art in the form of the New Post button... except of course that'll only be familiar to users who've already installed or played around with Gutenberg.

That said, it's a bit more flexible than the "don't show this again" checkbox in allowing users to decide, on the fly, if they'd like to publish immediately, or if they'd prefer to double-check everything first.

One way to introduce this to users would be via a tip, or by showing the pre-publish panel the first time a user goes to publish a post, regardless of which option they choose.

If they choose the "publish" button, they're directly taken to see their post: pre-publish skip

If they choose the "dropdown", they're shown the pre-publish panel: pre-publish panel

Note that the last screen in each of these flows is just a temporary screen whilst we redirect more-or-less-immediately to the new post (more on that below).

The alternate to this solution (as illustrated in the original flow 2) is that we have a single "Publish" button that opens up the pre-publish panel and offers the user the option to hide the pre-publish panel in the future. This has its advantages (namely, a simpler button), but doesn't allow for as much flexibility in how people publish, and it also requires that we add an extra setting (for "do/don't show me the pre-flight check). Allowing users to dynamically choose which way to publish their post gives them the most flexibility, as well as being kinder to established users, who may be annoyed by a sudden jump to a two-click publishing process.

Since we're going to go with the assumption that users are going to want to double-check their settings prior to publishing (ie, actually read the stuff in the popover), it'd make sense to put a secondary "publish" button at the bottom, as shown above. In this setup, the original "Publish" button at the top of the page would still work—if you pressed it while the pre-flight popover was open, you'd immediately start the publish process. 💥

Pre-publish panel

Here I've opted for a popover in order to ensure focus is retained for those users who want to be able to double-check their settings prior to publishing the post. This also allows us to use a visually distinct element from the settings sidebar, rather than a sidebar that looks similar-but-not-quite-the-same, and provides a more consistent behaviour across different screen sizes (because the width will remain the same throughout). It also seems to be a more commonly used pattern for those services that make use of a pre-publish panel (Medium, Ghost, Livejournal, Wix) where only WordPress.com uses a sidebar pattern.

In terms of plugin extensibility, it's more or less the same as the sidebar option. I haven't been able to find examples of plugins that add any modules here, but let's see what it would look like with the usual suspects here:

pre-publish panel extensibility

This demonstrates how it might look with a whole bunch of plugins adding extra checks, and some extra pre-flight checks disabling the publish button as in the case of #7020. The worst thing we'd need to deal with is a little bit of scroll, which we'd need to do anyway with a sidebar scenario. Breaking everything into individual panels (ideally collapsed by default) keeps things clean and visually parseable.

Post-publish redirection

In my review of other services, redirecting post-publish to the post itself was overwhelmingly the most common behaviour, and I suspect it will work for the majority of users who, after publishing their post, just want to go look at it. I don't think we have any data or research on user behaviour and wants post-publish, so this is largely an assumption, but anecdotal data (see: asking people casually) indicates that the most common responses to "what do you want to do after publishing a post?" is "look at it". (Closely followed by "write another post" and "do something else altogether". Leaving them at the edit post page isn't the right solution for any of these desires, so I think it makes sense to optimise for the people who want to go look at their post and see if it's all okay. (Which I suspect is the vast majority of people.)

There's an opportunity to do some sort of brief animation in here as well, but I think we'd want to go super simple.

Post-publish panel

Here's what I'm thinking would be optimal here, and it sort of combines elements of the two flows above.

The first time you publish a post, you're redirected to your new post, with a full takeover (dismissable) modal like this:

post with modal

It has a "Don't show this again" checkbox option, so users who just want to get on with it don't need to see it again. Still debating if we should check this by default or not.

When you dismiss the modal, it collapses into a little notification bar:

post with notification

(Note: I'm not opposed to the x button closing the modal and the notification entirely, but I thought it could be useful to retain access to the modal, so it doesn't just totally disappear if you want to look at your post.)

From the notification bar, you can re-open the full modal (so useful if you want to look at your post, then come back to the modal to share to an email newsletter or edit the post or whatnot) or close it entirely.

The next time you publish a post, you're immediately redirected to your new post, with either the full modal or the notification bar, depending on if you opted for "don't show me this" at some point. Failing that, if we want to avoid adding a setting, we could just opt for defaulting to the notification bar only for subsequent posts.

The bar is then dismissable if you just want to get on with it already, or you can pull up the full post-publish panel by clicking through. This whole mico-flow ends up looking something like this:

post-publish

I see the post-publish screen potentially being more useful for plugin extensibility than the pre-publish screen, because lots of things (additional sharing, checking SEO stuff, adding tags) makes sense to do (or at least as much sense to do) after you've published the post.

This part is likely the roughest part of both the original/current flow right now, and this updated flow as well. It'll need some iteration to get a good balance of options and extensibility in place, as well as some fine-tuning of the visuals themselves. For now, I'm trying to focus on getting the broad strokes worked out, and then we can work on more of the finer details. 😅

sarahmonster commented 6 years ago

Also: I'm reopening this since #7922 refers to the animation/load state on pressing the "preview" button, not the publish-button experience itself. And also this is where all the work is. 😜

afercia commented 6 years ago

Adding the Accessibility label, as the Publish flow is pretty critical for inclusive design.

There should also be a secondary "Publish" button at the bottom of the the pre-publish panel

From an accessibility perspective, yes please 🙂for keyboard and assistive technology users, navigation is a linearized experience so having the Publish button at the end of the logical flow is super beneficial (this was noted several times in several issues)

Since 50% of users want to see their post in situ, let's try taking them there directly, and saving them the click.

Not fully convinced that always redirecting to the post itself after publishing would be ideal, as it seems a too brad assumption on the users intent.

afercia commented 6 years ago

P.S. just to note that any visual indication (icons, animations, etc.) used to communicate important information about the flow needs also a semantic equivalent and an audible message.

karmatosed commented 6 years ago

Thanks for exploring this @sarahmonster. I think it's important we get a balance between accessibility here also but I feel that's an easy goal to reach as this is worked with mindfully.

I am wondering on seeing the dropdown if this pattern isn't a little limited. Could you explore a sliding? I do think it could provide a lot more flexibility and not add a new pattern. What do you think? Something similar to https://material.io/design/components/sheets-side.html.

I also really like exploring the 'publish' being at the bottom. I also would like to maybe throw in an exploration of having the sliding page use a wider space. This would take it also away from being like the sidebar.

sarahmonster commented 6 years ago

@afercia thanks for the notes—I think the icons/animations used here all do have corresponding text elements (when the icon changes, the text associated with it also changes) but please do let me know if there are any concerns with the patterns and flows suggested here. It's definitely helpful to keep these things in mind in the design phase, to be sure we catch things before they've developed. Hopefully we can improve the overall accessibility of this flow.

@karmatosed we could use a side sheet instead of a dropdown, but I'm not certain it's a better pattern here—it means we can't use the split button, which means that we either force users to always double-click through to publish their post, or we have to introduce an additional setting.

I couldn't find anything using an existing side-sheet pattern in Gutenberg, but do let me know if I've missed one somewhere. It seems like the Material pattern would be very suited to the sidebar itself. Here, using a side-sheet pattern breaks with convention of other services' publishing flows, which tend to use popovers for a pre-publish panel. That's not necessarily a bad thing if we're improving on the pattern, but I'm not sure we are. This pattern does have the benefit of obscuring more of the screen below, which certainly helps improve focus.

Here's what that portion of the flow would look like with a side sheet.

pre-publish slider

We'll want to introduce a setting to allow users to avoid the "double click" publishing flow, since there isn't a good way to use a split button with this approach. It's definitely closer to the sidebar in look & feel, but that's largely unavoidable. We shouldn't be trying to make it much wider here, since it won't accomodate smaller devices, but we don't really need more space with the current setup—even with the "kitchen sink" plugin example above, it's busy, but it's not the restricted width that causes the busyness.

For apples-to-apples, here it is using the popover: pre-publish popover

The popover is an established pattern in Gutenberg, although I can't find cases where it's used quite as heavily as it is here. This option does allow us to use a split button pattern, which gives users the option to on-the-fly decide if they want to use the pre-publish panel. That said, that may be an option we don't want to give to users. It's also following a pattern that's been pre-established by other services, which means it could be familiar to some users.

That said, I think either of these approaches is a good improvement on the existing pre-publish panel, so I'm happy to go with the prevailing opinion here. 😺

karmatosed commented 6 years ago

@sarahmonster I think we are on the right track with the thinking here. I would very much like to explore the side sheet if possible. I really think on desktop this could even be a lot wider than we have now - although then we have an issue with looking at making too big an area for people to fill up. We have a modal but not an existing pattern. I think we could explore one at least in prototype. I also wouldn't be against testing both in prototype if we had time to rough test. I feel testing side sheet is a good start.

That said, I think either of these approaches is a good improvement on the existing pre-publish panel, so I'm happy to go with the prevailing opinion here.

I very much believe the work you are doing here is far better than we have now. Thank you for doing it.

sarahmonster commented 6 years ago

I've created a new prototype that uses the side-sheet approach, as well as introducing a tiny bit more whitespace and typographic hierarchy—we'd probably want to dial that back unless the spacing were introduced across the board, which is obviously a much bigger change, but this is mostly to test out how it might work with a bit more breathing room:

Clickable here: https://automattic.invisionapp.com/share/DGNHVJ5ZKBC#/

There's a lot of finer detail (animation, transitions, etc) that isn't possible to properly prototype in Invision, so if this feels like a good direction, I think it'd be good to try to get it into a code prototype to test.

I'd like to A/B test this as much as possible to determine its effectiveness, but I haven't found much information (I may be looking in the wrong place!) about user research efforts attached to the project. Do we have a pool of people from whom we can recruit testers, or have efforts typically been on a one-off basis? Has there been any testing done prior to this on this particular flow? Where are test results and data shared?

shaunandrews commented 6 years ago

publishing sheet

Took some inspiration from this to explore a sheet for the publishing flow with Gutenberg on WordPress.com.

sarahmonster commented 6 years ago

❤️ the publishing progress bar. Is it tied to anything meaningful in the backend, or is it purely decorative?

shaunandrews commented 6 years ago

is it purely decorative?

I wanted to indicate progress, but didn't want to use an endless spinner. The bar hopefully gives a sense that something is happening, but in reality there's prolly no way to really indicate progress without faking it. :)

karmatosed commented 6 years ago

I really like the publishing progress bar.

There's a lot of finer detail (animation, transitions, etc) that isn't possible to properly prototype in Invision, so if this feels like a good direction, I think it'd be good to try to get it into a code prototype to test.

I think we're ready to start moving into code also. Thanks for working on this. It would be great to move into code and get those nuances in.

Do we have a pool of people from whom we can recruit testers, or have efforts typically been on a one-off basis?

We don't have a pool, it's usually per section if focused research. I would say lets get the prototype, get it to a point of where we feel it is solid and we can then consider who to test on.

0aveRyan commented 6 years ago

A few outside thoughts on this:

sarahmonster commented 6 years ago

I've put together an initial PR for this a little while ago here: #9398. It's currently in need of some JavaScripty help which @nosolosw has kindly offered to help out with when time permits. 🎉

jarahsames commented 6 years ago

I know I am a bit late to this conversation; however, I do have a few items I’d like to add to the discussion.

First and foremost, this all is looking great and I’m a big fan of the overall direction. It was fun to read through this entire ticket and see all the iterations. Kudos to all the hard work and ideas that went into it. 👏 👏 👏

Here are some ideas and feedback in a long winded comment.

When reviewing the designs and the iterations I found myself going back to the core user tasks for this experience; namely, to write and publish posts/pages. In regards to publishing, I can’t help but notice that we are removing the core publishing metabox and instead adding a simple “publish” button.

Why do I bring this up?

People are comfortable with the current experience (and usually resist change). Right now we are prominently displaying a large publish button in the editor bar but deemphasizing the publishing options (yes, they are by default displayed in the settings sidebar, but this area could be ignored by users).

What are thoughts to further exploring more transparency with the publishing options (in the editor bar)?

I wonder if we need to not only expose the publishing options more readily, but also ensure we are being clear about the actions a particular button has — if I click publish I might not know there will be more options available to me. For example, authors that have custom post/page states, such as “ready for review,” should have transparency into where that lives and not have to guess it would appear after clicking publish. Should we show different states here like that in the editor bar or have a separate button (i.e. “quick publish” vs. “ready to publish” < poor choice of language, but trying to get intention across here).

As a separate thought, I’m also curious to get user feedback on if they overall publishing area in the editor bar has too much content. The cog to collapse/expand the settings sidebar is a new pattern (meaning we have taught a user to “Collapse Menu” in the core navigation area and to “Hide Controls” in the customizer, why are we changing it here?) for a user to learn and I wonder if it would be better served moved more directly into the sidebar settings area?

This would also be true for the more options menu — it seems to be better served with the other settings sidebar items.

I bring this up because I feel like the extra items increase cognitive load in the publishing area where we should be focusing more on that core user task.

My last thought is in regards to the interaction model of the container. Can we also integrate this into the settings sidebar experience? I feel like we are making these two items more disjointed now and feel like we can tighten up the overall interaction model to ensure they are consistent. A vague comment that I am happy to elaborate on if anybody wishes to hear more. 😄

I would love to hear opinions about these ideas and look forward to more collaboration!

karmatosed commented 6 years ago

One point that comes to mind with the 'don't show me again' and plugins using the publishing panel for checklists or output. This is more a case of maybe checking if anything is hooked there and making sure no broken flows occur. If it's not going to break a flow we're all good.

shaunandrews commented 6 years ago

One point that comes to mind with the 'don't show me again' and plugins using the publishing panel for checklists or output.

Perhaps we need to set the expectation to plugin developers that the publishing sheet is a user-defined option. What I'd want to avoid is a user who decides they don't want/need the publishing sheet, turn it off, and then wonder why it came back (due to a plugin requiring it.)

oandregal commented 6 years ago

I've started work on making the PublishSidebar an optional step at https://github.com/WordPress/gutenberg/pull/9760

sarahmonster commented 6 years ago

Perhaps we need to set the expectation to plugin developers that the publishing sheet is a user-defined option. What I'd want to avoid is a user who decides they don't want/need the publishing sheet, turn it off, and then wonder why it came back (due to a plugin requiring it.)

💯

One of the things we're already doing here with the pre-publish panel is only surfacing options and settings that already exist somewhere else. Since the pre-publish panel only appears at the very end of the writing flow, it makes sense to set the expectation that any settings that appear here should also exist elsewhere in the interface, so that users can access them at any stage. I suspect that people would struggle if they needed to press the "publish" button in order to access settings controls for their post.

The intention here is to provide a last-minute double-check to help prevent accidental publishing of posts and to ensure confidence in the process for users. I'm not sure it would make sense to put anything that's critical to the post settings here and here alone.

It's worth including this in plugin guidelines, so that plugin authors don't rely too heavily on this panel.

karmatosed commented 6 years ago

@jarahsames thanks for the in-depth insights.

What are thoughts to further exploring more transparency with the publishing options (in the editor bar)?

Do you have any ideas of how this could be mocked up?

I don't have firm answers for a lot of your questions as I think we're still exploring here, they are great to add to thinking though.

I bring this up because I feel like the extra items increase cognitive load in the publishing area where we should be focusing more on that core user task.

This is a valid concern. We don't want to increase the cognitive load and if we do find that happens we should revisit.

A vague comment that I am happy to elaborate on if anybody wishes to hear more.

I'd love to hear more.

tofumatt commented 6 years ago

I'm removing accessibility as a label right now. It's not because I don't agree with @afercia that accessibility is an important aspect of these changes, but this issue is quite long and a bit difficult to follow. I think of it as a discussion/tracking issue at this point; any actionable changes as a result of discussion here need to be split out into their own issues–and tagged with the "Accessibility" label as needed–to be addressed with any context.

There's a lot here to take in, so I think it's best to split out discrete issues from this task.

sarahmonster commented 6 years ago

@mtias @karmatosed Probably makes sense to remove this from the 5.0 milestone unless it's changed in priority. I haven't been able to move my PR forward without development help so I can't get these designs fully implemented.

tofumatt commented 6 years ago

Actually this can keep the accessibility label but it would be helpful if we had a sort of "tracking" label to denote this is an issue that serves as more of a discussion than an item a developer can tackle.

I removed the label so developers who I sent to the WP 5.0 milestone + Accessibility label didn't try to tackle this issue and get overwhelmed, but I'll add it back with the caveat that it's more a tracking issue for now.

sarahmonster commented 5 years ago

Revisiting this after some time, I think we can rethink some of this design with the primary aim of increasing confidence in the publishing process. How can we help users be as certain as possible they’re publishing what they want when they want?

Let's start with the publish button

The “publish...” button still makes me feel uncertain. Will this really publish my post, or can I check on things first?

So let’s try a change in verbiage. I know there’s been concern about this taking too much space, but I think we can work around that. There's no reason we couldn't shorten the text on mobile devices, but use a longer version on larger screens.

Let’s try “Ready to publish?” and see how that feels. It feels like a clear call to action without indicating that your post will immediately publish itself.

Ready to publish

There's still kind of a lot going on up here, with the save draft and the preview button. (And I know one of the usability test results from the audit indicated a user found the flashing "Save" indicator rather distracting.) There may be cause for simplifying this area in the future, especially if we had some data around how users make use of these buttons, but let's leave that for a future iteration.

Focus attention

Next, let’s switch the publish sidebar to a modal. According to our design guidelines:

Modals give users information and choices related to a task they’re trying to accomplish. They can contain critical information, require decisions, or involve multiple tasks.

That sounds like it’s the right tool for the job here, and it will help to focus users’ attention as well. Let’s try it!

Pre-publish as a modal

This has the advantage of being a fully distinct pattern from the sidebar, rather than something that looks a whole lot like the sidebar, but doesn't behave the same way. It's also going to be a more consistent experience across mobile devices and larger screens.

The scrim being white doesn't quite work effectively—it lacks contrast with both the white underneath and the white on top. A darker scrim is much better for focussing user attention:

Pre-publish dark scrim

That said, I wouldn't want to subvert the existing patterns just for one iteration, so if we were to change it, it'd make sense for it to change universally, and we may have a reason for it being white in the first place.

Clarify publish settings

This seems to be an ongoing source of confusion and/or accidental breaking of embargoes, so let’s use this as an opportunity to make the publish date SUPER obvious. Maybe we can underline here whether it’s in the future or the past as well, to help with #12256 and #13230 and a whole number of other number-confusions.

I haven’t illustrated editing these controls yet (may hinge on results in #470), but we’ll want a way to edit the visibility and post date here as well.

Publish dates

Publish visibilty

The wording on these will probably need some tweaking, as will the hierarchy, but providing additional checks and information here may help users make more informed decisions and avoid accidental publishing snafus.

I'd also recommend changing the wording on the publish button itself, depending on when the post is scheduled for:

Again, labels could use some thinking through, but I'm trying to get the broad strokes down first, then narrow down a bit.

Provide helpful suggestions

Finally, I added a post preview to show what your post might look like when shared. I'm not sure how accurate this would be, but it would be a good way of checking things like an excerpt and featured images.

Screenshot 2019-05-31 at 19 26 57

I've also added the tag suggestions in (needs some Figma components being built, I think!):

Screenshot 2019-05-31 at 19 27 02

Questions

  1. Does anyone have any data or usability test results to share about the existing publishing flow that could help inform the direction here?
  2. Does switching from a sidebar slideout to a modal seem sensible?
  3. Are there accessibility concerns with this approach, or things we need to take into consideration?
  4. Are tag suggestions here helpful, or do they belong instead in the post-publish panel?
  5. Is "Schedule for later" helpful here as an alternate option? This would probably just shift focus back and allow users to select a date to publish their post, or open a datepicker in place.
  6. Is there anything else we can do to help users feel more confident about publishing their posts?
afercia commented 5 years ago

Next, let’s switch the publish sidebar to a modal.

Noting there's now a new issue specifically focused on using a modal, see #15847.

It's also going to be a more consistent experience across mobile devices and larger screens.

I'd totally second this. Also, it's not a case that designing for mobile first often helps a lot accessibility because requires to design the UI and content in a linearized way.

The scrim being white doesn't quite work effectively—it lacks contrast with both the white underneath and the white on top. A darker scrim is much better for focussing user attention

Not sure what a scrim is. If you mean the dialog overlay, totally agree and I'd like to note I personally asked more than one time to make the one used in Gutenberg darker. The Gutenberg light grey one deviates from the one used in core and doesn't really convey the right feedback for a "modal" interaction. Also, I don't see any good reason to not make them consistent. Sadly, my request was constantly dismissed by the team feedback.

sarahmonster commented 5 years ago

The design team discussed this during a triage session in Slack yesterday (Note: You may need a Slack account to log in.)

Since this has turned into something of a ahem long-winded (my fault!) issue, let's treat it as a tracking issue, and try to split all the different improvements into a series of smaller tickets. I'd still appreciate design feedback on the overall approach suggested here, but we can also forge ahead with

Here's how I think we can break this one down:

I'm working to file issues for each of these issues individually so we can make progress on this issue.

mapk commented 5 years ago

Thanks for wrangling this, Sarah!

Let’s try “Ready to publish?”

It feels awkward to have a question as the label for a button. If I'm clicking a button, I'm performing the action it should be suggesting, right? I noticed Amazon has a "Proceed to checkout" label on their button. I wonder if that's kind of what we're doing here? Maybe, "Proceed to publish" or "Prepare for publish".

Next, let’s switch the publish sidebar to a modal. According to our design guidelines:

I'm on board with this! Good call. "It's also going to be a more consistent experience across mobile devices and larger screens." is a great point!

A darker scrim is much better for focussing user attention:

Yep! 💯

I'd also recommend changing the wording on the publish button itself, depending on when the post is scheduled for:

Future: Schedule post
Past: Publish retroactively

Good thinking. This little fix help reinforce the changes made too!

Are tag suggestions here helpful, or do they belong instead in the post-publish panel?

I think we can drop the tag suggestions. Let's try to keep the user's focus on the immediate things they need to check before commiting.

let's treat it as a tracking issue, and try to split all the different improvements into a series of smaller tickets.

I like that idea. Let's keep this issue updated with links to all the smaller ones.

sarahmonster commented 5 years ago

Thanks for the feedback @mapk! I've moved your idea over to # 16342 for further discussion.

I've now refined the original concept here based primarily on findings from usability studies and intuition:

2019-06-28 01 05 54

(Figma prototype and source)

I've split these recommendations into component issues and have updated the original issue text here, so it's easier to find these linked tickets. We'll use this issue as a tracking issue, and discuss individual changes recommended on these tickets:

karmatosed commented 5 years ago

@sarahmonster does this issue need keeping open if those others are being worked on? Just checking if we can tidy up this one?

sarahmonster commented 5 years ago

Let's keep this open as a tracking issue—it's helpful to be able to find all the related issues in one place. Once those related issues are dealt with, we can close the tracking issue.

sarahmonster commented 5 years ago

Circling back here, I've combined some of the conversations from #15847, #16127, #16342, #16308, #16311, #16310, #16327, #16341, and other publishing-related issues into a single, combined prototype. Some of the finer details are missing here (datepicker behaviours and improvements, error handling, editing dates and visibility directly from the pre-publish panel, surfacing visibility and publishing options in the document settings, the title block, etc), but it should be enough to get the broad strokes of the proposed changes here:

2019-08-02 01 57 23

Figma prototype

Note that the transition between pre- and post- publish panels is still subject to change—more solutions illustrated in #16327. I'm not sure anymore if I'm leaning toward the dialog-snackbar-dialog pattern shown here, or the dialog-dialog-dialog pattern. That decision may be contingent upon accessibility and usability feedback.

karmatosed commented 5 years ago

First, thanks for taking the time to create this mock walkthrough @sarahmonser. I do have a few points this brings to mind, some of them because of the recent explorations in full screen modal.

It does feel a little disjointed as it goes between screens, the changes in height and spacing is a little jarring to the flow. I think it takes me out of the flow of publishing. I know I've been vocally against a modal here and I still feel in current version this leads to a weird ending to the writing journey.

Looping back to the idea of a journey when you write, this is the end in some ways. I feel the modal takes me out of that and doesn't lead me to the celebratory high point. Just a thought to add to this. Personally, I wonder how this could change 'if' the full-screen modal @youknowriad proposes gets in. A few things I wonder about the modal:

afercia commented 5 years ago

I share the feeling that the size change of the modal through the steps is a bit confusing. That could be solved in many ways, including but not limited to the full-screen modal dialog proposal.

jasmussen commented 5 years ago

As the efforts here continue, and as the archive is getting increasingly buried and hard to browse, I thought I'd resurrect some of the thoughts we formed while designing the first iteration of the pre-publish flow. I present these only as historical context, not as a value judgement in favor of one design or another.

The pre-publish experience is super important:

We did learn as we went about the designs, that we wanted to be somber and neutral in this pre-publish dialog, as the words a user might publish are not always appropriate to celebrate. This is why we opted to not include too much colorful language or illustrations. This bit is a delicate balance.

karmatosed commented 5 years ago

+1 to everything you wrote @jasmussen. I think with phrases like 'Great job' we have to consider what if someone is writing about a loved one that is no longer around, something personally traumatic.

The pace and journey are essential to consider here.

sarahmonster commented 5 years ago

Thanks for the feedback, everyone! It sounds as though I may not have yet landed on a solution that solves the problem at hand.

Since there's been some lengthy back-and-forth in this issue (and others!) without landing on a good solution, it may help to take a few steps back and clarifying:

  1. What's the problem we're trying to solve?
  2. How will we know when we've landed on a solution that solves the problem?
  3. Are the suggested changes an improvement on the original/current solution, or a step backward?
  4. Are there any parts of the current publishing flow experience that aren't working for users? (Maybe everything is great?)
  5. Do we have any relevant data (qualitative, quantitative) that we can use to identify problems with the current publishing flow, or support our hypotheses here?

Once we have answers to those questions, we can look to revisiting and/or closing out this issue and its component sub-issues.

mapk commented 5 years ago

The prototype really helps convey this flow! Thanks for doing this.

The three-modal version shared here https://github.com/WordPress/gutenberg/issues/16327#issuecomment-517512760 feels visually like the better way to go between the two choices. The user is in the modal flow, and stays in until done.

As for the modal jumping around, I think it can be refined by fixing the top position of the modal and only changing the height? Or maybe animating through the modals would provide a better transition, similar to: https://github.com/WordPress/gutenberg/issues/16327#issuecomment-510273073

brentswisher commented 5 years ago

I have updated my Draft PR #16715 to be based on @sarahmonster's latest prototype if anyone wants to take it for a spin, I did make some changes detailed in the comments. It needs some overall design clean up, but it should allow you to experience what using a publishing modal "feels" like. I hope to create a branch that combines this and @youknowriad's full-screen modal early next week to give an idea of what that would feel like as well.

karmatosed commented 4 years ago

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.