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

Enhance the Publishing flow #7602

Open
karmatosed opened this Issue Jun 28, 2018 · 32 comments

Comments

@karmatosed
Member

karmatosed commented Jun 28, 2018

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?

@karmatosed karmatosed added this to the Merge Proposal: Editor milestone Jun 28, 2018

@mtias mtias changed the title from Enhance the publishing flow to Enhance the Preview and Publishing flow Jun 28, 2018

@sarahmonster

This comment has been minimized.

Contributor

sarahmonster commented Jul 9, 2018

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.
  • Is the primary intent here to improve the perceived loading time, or to add interest to the experience?
  • How much time (range) do we expect this screen to be visible for?
  • 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.
  • On a technical level, do we have access from this component to the post content or post meta?
  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.
  • Will this sidebar panel be extensible by plugins?
  • Why have we opted for a sidebar here, rather than a modal, notification, or full screen?
  • 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.)

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

This comment has been minimized.

Member

karmatosed commented Jul 9, 2018

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 sarahmonster changed the title from Enhance the Preview and Publishing flow to Enhance the Publishing flow Jul 12, 2018

@sarahmonster

This comment has been minimized.

Contributor

sarahmonster commented Jul 12, 2018

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

This comment has been minimized.

Contributor

sarahmonster commented Jul 12, 2018

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

  • I've already submitted a number of small changes and bugfixes here, mostly attached to #7426
  • We could shorten the header text to read "Ready to publish?" instead
  • 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.
  • 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.
  • 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.)
  • Double-clicking the button is a bit unintuitive. It looks as though there was originally a drop-down in the button here, so I may be missing some historical reasoning for the decisions here, but coming at this from a relatively green perspective, 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. (See also #7879.) Livejournal, Medium, and Ghost all follow this pattern and it feels the most elegant.
  • 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).

Post-publish

  • It seems as though, for most users, their next steps after publishing would be either to look at the post, or to go back to their post list and write another post. In either case, there's no value in abandoning the user on their edit post page—they're finished with this screen, at this stage. Since 50% of users want to see their post in situ, let's try taking them there directly, and saving them the click. In my benchmark testing, the flows that redirected to the post itself after publishing were the ones that felt the most inherently satisfying—it felt like I'd really done something, and I could see immediate evidence of that.
  • We could potentially use animation to highlight the shift from the edit screen to viewing the actual post. See Svbtle's flashing green border—I think this is a bit intense, but having a transition between pressing publish and being shown your new post could be really nice. We could show a short message "Great work! Let's take a look at your new post...." and have a brief
  • We could also use the post-publish area to help users get the most out of WordPress. I did a skim through articles with titles like "what do I do after publishing a blog post" to get a quick sense of what users want to do after publishing, and it seems like the biggest concern here is with getting that post out to others: optimising for SEO, sharing on social media, sending via email, checking stats, reading comments, etc. Since these functionalities are provided by plugins rather than core, we can't directly link to them here, but we can help nudge users toward them.
  • We could provide a checklist for "What's next?" to offer people some suggested steps to promote their post. (And a link to write a new post, as well!)
  • We could also feature a series of (potentially rotating, always dismissible) tips or ideas for promotion here. ie, "Did you know? The best time to send out an email is 4pm. [Read more]"

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:

  • someone who posts many times a day
  • someone who is new to WordPress
  • someone who works for a news organisation

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!

@sarahmonster sarahmonster referenced this issue Jul 12, 2018

Merged

Improve pre-publish panel styling #7879

4 of 4 tasks complete
@karmatosed

This comment has been minimized.

Member

karmatosed commented Jul 12, 2018

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

  • The animated button on wordpress.com feels super effective.
  • There is something 'yay' about the Wix modal.
  • I don't dislike Medium's drop down but my concern as mentioned in another issue is what happens to extending this with plugins? This totally may be an issue we decide is ok though. I'm down with exploring.
  • Hubpages is intense....
  • Tumblr makes me scared I lost something....
  • Svtble feels super disjointed.

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

This comment has been minimized.

Contributor

johnmaeda commented Jul 16, 2018

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

This comment has been minimized.

Contributor

sarahmonster commented Jul 17, 2018

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

This comment has been minimized.

Member

karmatosed commented Jul 18, 2018

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:

  • I am not sure about full modal take-overs on desktop, this needs to be something to explore.
  • Thanks for showing flows and video, that's really helpful.
  • It feels somehow like there are a lot of steps in the first version. I think this is because it's split and not sure that's a bad thing but it's worth noting.
  • I wonder if the green publish is resulting in relying on color too much? I'm unsure but worth checking as that check icon seems a little lost.
  • I do like 'great work' as a phrase and think it's a balance over overly celebrating.

Second version:

  • What would that flip animation be on desktop?
  • This does feel like it has some concerns for the publishing extensibility.
  • I kind of like idea it gets to the showing of your post, but I keep musing if this is always the action someone wants. It may be, I just am unsure.
  • I like the 'next steps' and think that type of nudge is a welcome push for interaction.
@mtias

This comment has been minimized.

Contributor

mtias commented Jul 19, 2018

Closing in favor of #7922.

@mtias mtias closed this Jul 19, 2018

@sarahmonster

This comment has been minimized.

Contributor

sarahmonster commented Jul 20, 2018

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

This comment has been minimized.

Contributor

sarahmonster commented Jul 20, 2018

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

This comment has been minimized.

Contributor

afercia commented Jul 26, 2018

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

This comment has been minimized.

Contributor

afercia commented Jul 26, 2018

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

This comment has been minimized.

Member

karmatosed commented Jul 29, 2018

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

This comment has been minimized.

Contributor

sarahmonster commented Jul 31, 2018

@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

This comment has been minimized.

Member

karmatosed commented Aug 8, 2018

@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

This comment has been minimized.

Contributor

sarahmonster commented Aug 13, 2018

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

This comment has been minimized.

shaunandrews commented Aug 16, 2018

publishing sheet

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

@sarahmonster

This comment has been minimized.

Contributor

sarahmonster commented Aug 17, 2018

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

@shaunandrews

This comment has been minimized.

shaunandrews commented Aug 17, 2018

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

This comment has been minimized.

Member

karmatosed commented Aug 23, 2018

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

This comment has been minimized.

Member

0aveRyan commented Aug 24, 2018

A few outside thoughts on this:

  • The Don't show this again should have a filter/action to disable -- some will want to enforce two-step publishing regardless of user preference.
  • The Publish... and Schedule... text currently isn't filterable, except for being translatable strings. These also seem like good candidates for applyFilters().
  • When this goes to code all the language about "post" and "page" should reflect the labels used for the current post type (i.e. Great work! You've just published your first Movie Review)

@sarahmonster sarahmonster referenced this issue Aug 28, 2018

Open

WIP: Try new publishing flow #9398

2 of 7 tasks complete
@sarahmonster

This comment has been minimized.

Contributor

sarahmonster commented Sep 4, 2018

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

This comment has been minimized.

jarahsames commented Sep 5, 2018

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

This comment has been minimized.

Member

karmatosed commented Sep 7, 2018

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

This comment has been minimized.

shaunandrews commented Sep 7, 2018

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.)

@nosolosw

This comment has been minimized.

Member

nosolosw commented Sep 10, 2018

I've started work on making the PublishSidebar an optional step at #9760

@sarahmonster

This comment has been minimized.

Contributor

sarahmonster commented Sep 12, 2018

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

This comment has been minimized.

Member

karmatosed commented Sep 22, 2018

@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 tofumatt removed the Accessibility label Oct 10, 2018

@tofumatt

This comment has been minimized.

Member

tofumatt commented Oct 10, 2018

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.

@mtias mtias modified the milestones: Merge: Editor, WordPress 5.0 Oct 12, 2018

@sarahmonster

This comment has been minimized.

Contributor

sarahmonster commented Oct 16, 2018

@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

This comment has been minimized.

Member

tofumatt commented Nov 8, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment