Only require a single click to update a post

[maddisondesigns]

Are we really going to have multiple Update buttons?? This is a ridiculous UI and really poor usability!

Issue Overview

Poor UI with multiple Update buttons.

Expected Behavior

I shouldn't have to click Update multiple times just to update my content. Regardless of whether the content auto-saves, people are still going to want to click the Update button. That's just natural behaviour. Forcing them to do this twice now, is ridiculous.

Current Behavior

I have to click update multiple times

Possible Solution

Revert back to original design where there was only one Update button, similar to how the existing UI is.

Firefox 56.0.2 (64-bit)
macOS Sierra 10.12.1
Gutenberg 1.6.0

[youknowriad]

This design is not polished yet, this is just the first iteration but that's not a reason to use words like "ridiculous", "poor".

Allow us to disagree with you, I think this design needs improvements but is good, it achieves two goals:

• Prevent accidental publish/update
• Distraction free experience, you can leave the sidebar closed

Note that several other modern editors like medium/ghost use a similar design.

[jasmussen]

I think the verbiage could use a little work, I agree, visual changes can be made also. For example we could change the button to simply spell out "Publish..." or "Update..." to imply that it's the first step of a two-step set of actions.

The 2nd button inside could then be "Confirm Update" or "Confirm Publish", or perhaps "Apply Change" and "Confirm Publish".

This is also a spot that we mean to make pluggable. It would be a great place to show an "SEO score", or other last-minute checkup actions.

[maddisondesigns]

I was discussing this months ago on another issue, before this was even introduced. As I mentioned back then, the reason that people have raised an issue about accidentally publishing their content, is because this is an issue that has been introduced by Gutenberg. The current WordPress workflow doesn't suffer from accidental publishing (or at least, very rarely) because users have a Save Draft button which is clearly visible. Since Gutenberg decided to removed the Save Draft button people are just going to naturally click the first (and only) button they see, without reading it properly (thereby causing their page to be published). You're trying to solve a problem that Gutenberg introduced, and by doing so, decreasing usability by forcing people to make multiple clicks and navigate multiple panels, just to publish their content.

From Usability Experts, Nielsen Norman Group, in their post Don’t Prioritize Efficiency Over Expectations, they state;

Users Crave Control. Similar to backseat drivers, users want to feel in control. Taking away the Save button reduces users’ control over the interface. Suddenly, the website is an autonomous entity that decides on its own how and when to do things.

And, in reference to an example of a form without a Save button, they say;

What is missing from this otherwise fairly standard form? There is no Save button! How do we apply our changes so they are saved in the system? Computer-savvy readers may realize that the form is likely saving any changes whilst they are made, thus gaining efficiency by not requiring an extra save button press. However, most users are not this savvy, and even the savviest amongst us are more used to the pattern of having a Save or Submit button at the end of a form. This is an excellent example of how even the smallest deviation from a standard can cause confusion and increase cognitive load.

And yes, as I mentioned above, I realise that Gutenberg auto-saves. I'm not suggesting that it shouldn't. I'm suggesting that providing users with a Save Draft button, as they're currently used to, is going make it less likely that they're going to publish their content accidentally.

On a side note, the ability to close the sidebar does not provide a "Distraction free experience". It hardly changes a thing with the page layout. The main WordPress menus still show, as does the toolbar at the top of the page. I would argue that literally no-one is going to ever care that you can close that panel. It'll be used by the same number of people who use the existing "Distraction free" button, which is basically no-one as well.

[iandunn]

While I agree that the original post could have been worded more tactfully, I think this is valuable feedback. The extra step feels really annoying to me too.

Prevent accidental publish/update

I think that's a worthwhile goal, but I personally would prefer something closer to the approach that Calypso took. The interstitial shows up the first time, but it has a checkbox that allows power users to prevent it from showing up in the future.

Distraction free experience, you can leave the sidebar closed

I also don't see how this is connected, could you clarify?

[anyssa]

If I may give my two cents:

Update or publish is simply the main action you can take on the editing page. Every email interface, social network or form highlights the Send / Publish button because of that. So, although accidental publish/update can be an issue (was this really an issue on classic editor?), preventing it can't be done in a way that makes the main action harder.

There are other (better) ways to do that. Some suggestions:

• Allow the user to undo actions, or display a cancel button for a few seconds, like Android/ Google products does.
• Separate things: for example, visibility settings really needs to be placed so close to the publish button or is that just a legacy of the classic editor?
• I agree with @maddisondesigns about the Save draft button preventing accidents.

Also, the publish button in not a distraction, is the goal.

[kevinwhoffman]

The idea of preventing accidental publishing is being taken too far and having adverse effects on users' expectations. It is unexpected when first clicking "Publish" to have to click "Publish" again, but it feels even more awkward when updating a post to have to click "Update" multiple times.

In its defense, the possibility of a pluggable dropdown could be very helpful to certain users, especially those in news organizations who may require posts to be approved or tagged before publishing. I like that the possibility for that exists, however it should not be the default behavior.

Gmail's Undo Functionality

In Gmail, pressing "Send" immediately sends the email. That's the affordance that the button provides, and it delivers on that expectation.

However, you can choose to set a time limit for which you can undo sending. Of course you can't really undo a sent email, so behind the scenes it is just delaying the action. Here's how it works:

• After pressing "Send" a notice appears at the top of the window that allows you to undo (cancel) sending.
• If you click undo in that time period, you return to the editing process without sending.
• If the time expires, the email sends as expected.
• If you close the window before the timer counts down, the email sends automatically.

Something similar in WordPress?

• After clicking "Publish" an admin notice could appear that allows you to undo publishing for a set amount of time.
• If you click undo in that time period, you return to the editing process without publishing.
• If the time expires, the post publishes as expected. A success notice appears and the "Publish" button changes to "Update".
• Unlike Gmail, if you leave before the timer counts down, I don't think the post should publish on its own. I think it should warn you that the published post is pending, and ask you to confirm publishing before navigating away.

Again this behavior should be optional, and the default behavior should be to publish or update in one click.

[StaggerLeee]

I like solution as it is now. But it is subjective, most because I install extended Save button plugin on almost all websites.

This one with select option "Save and return to Posts list", "Save and return to edit screen", "Save and add new Post", or something like this. Do not remember by heart now exact wordings.

For me very familiar, and so long no User has complained or mentioned this.

[maddisondesigns]

@StaggerLeee I'm curious to know, is this the plugin that you're referring to (or something similar)?

I think it's important to note, that plugin doesn't extend the default Update/Publish button, it actually adds an entirely new button to the Publish panel that performs the Publish/Update function along with an extra action (e.g. Save and New, Save and List etc.).

Whilst it might be handy functionality, the issue that I'm referring to is that Gutenberg currently has two buttons just to perform one single action (along with a complete change of the existing publish workflow by removing the Save Draft button). Even with that plugin installed, people still have the option to just click the standard WP Publish button to publish their content straight away.

[karmatosed]

Firstly, what a lot of passion about this subject. That's good because passion leads us to solutions.

If you distill back a checking interaction makes a lot of sense, that's what this is when it's simmered down. This checking gives the user a chance to change their mind - we've all seen people accidentally click so many things. This accidental publishing isn't just from Gutenberg it's been there since WordPress has had publishing.

Building on from a second chance checking of an action, you could add in extra checks to the flow easier as it's isolated. What about a SEO check right there? What about spelling? If you think of all the plugin checks before publishing and imagined them there - things open up a bit.

Now I've dipped a bit into the background of the why. Let's turn to the how it is right now. Is it perfect? No. This is a work in progress and we need to remember what we're trying to do and iterate. Language is a powerful thing and changing something like that could be super helpful here.

Here are some suggestions to throw into the mix whilst we think about this.

[folletto]

Building on from a second chance checking of an action, you could add in extra checks to the flow easier as it's isolated. What about a SEO check right there? What about spelling? If you think of all the plugin checks before publishing and imagined them there - things open up a bit.

Agreed. Editing is a process that involves multiple mental model and stages, and we are trying to not just make sure there aren't accidental clicks, but also provide space for the editor and plugins to allow for the mental model of publishing to have a proper UI. I won't repeat the list of reasons for having this intermediate step as we already had this discussion in the threads leading us to this.

I however agree the current UI should be improved: labels, spacing, duplication of content are the first things that come to my mind.

I want to analyze briefly Medium, as their UI has been refined over time, and they have done it successfully for a long while now. Their model is simpler than WordPress, as they have far less features, but it's a good reference point as it's already shipped for millions of users:

1. "Publish" is the main action, showing a dropdown.
2. "Publish" is repeated as the main action within the dropdown.
3. It provides the following modules: tags, featured image, sharing, scheduling, visibility, license.
4. The content in the dropdown isn't replicated anywhere else in the UI before the dropdown.
5. Interestingly enough, when editing an existing post, it still says "Publish" / "Publish".

Starting from here, I feel there are already good pointers at things we can review and change in the first iteration we had.

We should however also play on WordPress strengths: Medium is a simpler tool, and not extensible. WordPress is extensible, as such I believe we should think of dedicating more space instead of a dropdown — plenty of tools could add their features there (from content check plugins, to SEO plugins, to sharing plugins, to workflow plugins, etc) without cluttering the editing experience.

Editing and publishing are two steps of the process, let's embrace their different mental model. :)

[themightyant]

While I agree the tone of the original post was off the point behind it is valid. I realise this is a work in progress so here are my thoughts and constructive criticism on the update button and related issues.

• I understand the potential use of having the drop down the FIRST time (to publish) I quite like that solution.

• However the terminology needs work. Clicking "Publish" twice seems redundant. Don't call the first initial button "Publish" if that is not what it is actually doing. I understand this may confuse long time WP users looking for the button but lets be honest Gutenberg is going to do that anyway! Don't make the decision for this reason. How about "Publishing" and "Publish" (as per example above)

• On update this is just extra work, it should never have to be clicked twice after initial publishing. How often after publishing would you change the post date or visibility? These options are still easily available IF you need them but shouldn't detract from the number 1 task of updating the content.
  @anyssa nailed it when she said

"Also, the publish button in not a distraction, is the goal."

• Never posted by accident on the old editor. Is there data to back this up? Is it a problem of Gutenberg's own making?

Finally a lot has been said of the 'distraction free experience', personally I don't use it and there seems to be some data to back up the fact that few clients/endusers seem to use this 'feature'. e.g. https://wptavern.com/wordpress-editor-experience-survey-shows-75-of-respondents-dont-use-distraction-free-writing-mode

It seems like a lot of problems are being created by the need to have a 'distraction free experience' and it feels like key decisions are being made based on the apparent need for a clean minimalist aesthetic rather than good usability.

[folletto]

Aside: being distraction free is just a side effect, it's not the reason for this UI to exist.

[Ipstenu]

There are a handful of ‘are you sure?’ plugins to put a pause between publish and REALLY publish. They’re very popular with news companies. As WordPress is more and more used by larger corporations, this becomes a larger issue.

Plugin usage numbers around 5k and I’m pretty sure Matt uses it too 😁

[themightyant]

@Ipstenu For first PUBLISH I can understand it and like it, though I think the terminology should change. "Publish" twice makes no logical sense, it's a misnomer, the first press you are not publishing anything. Even if others (e.g. Medium) do the same doesn't make it correct.

However for UPDATE I think it should be pressed once. As someone who has done plenty of the data entry and updating on the way up this will quickly become irritating behaviour for most CMS end users. It sounds like a small thing but clicking update (reposition mouse) click update again multiplied by 100 times a day soon tires. There are plenty of use cases that utilise WordPress and custom fields for product/service data where 100+ daily updates is entirely the norm. Not least when initially populating a site with content.

I do understand there are also discussing tying this two-step method into other uses e.g spellcheck, SEO

[folletto]

"Publish" twice makes no logical sense, it's a misnomer, the first press you are not publishing anything.

Think about existing interfaces in many common apps.

• "Print..." for example will lead to a new screen with more details about printing, and a "Print" button.
• "Save..." similarly if the file isn't saved will show a new screen with path and settings, and a "Save" button.

With these examples I don't mean to argue for "we should repeat". I would just argue that we should make the best labelling for that screen, and if a repetition we can test it's the clearest, we shouldn't avoid repetition just for the sake of avoiding repetition.

However for UPDATE I think it should be pressed once.

We can probably test this one, but I feel that it would be unexpected to get sometimes the dropdown and sometimes no dropdown (wouldn't be even more dangerous?).

This is especially more true if there are extensions and settings inside the user might want to change.

It sounds like a small thing but clicking update (reposition mouse) click update again multiplied by 100 times a day soon tires.

This is a solid point. We can probably do something to optimize this, like adding a Cmd+Click kind of action (similar to Cmd+Enter in some form field that immediately submit), or maybe in the case of update updates instantly, then allows for more changes within the dropdown – or maybe some other solution.

I'd also expect that in special cases we could have plugins that add the "Instant" functionality, like today there are plugins that add the "Interim" confirmation.

I do understand there are also discussing tying this two-step method into other uses e.g spellcheck, SEO

Yep! I would highlight this, as it's something that would open up a lot of possibilities! :)

[themightyant]

@folletto

Think about existing interfaces in many common apps. "Print..."

Good point, well made.

However for UPDATE I think it should be pressed once.

I can see the benefit of both having it and not having it in different situations. In most of my clients use cases it would be an additional annoyance. Though I am excited by the possibilities.

We can probably do something to optimize this, like adding a Cmd+Click kind of action

This would be highly useful for a huge number of use cases.

On a sidenote I was looking for the initial discussion on the two-step button, does someone have a link or issue number? I'm would love to have the full picture and failing with Search :-(

[kevinwhoffman]

Part of what makes the Gutenberg publish flow feel repetitive is that the same button control style is used to initialize the process as is used to confirm the action. I think that really contributes to feeling like you're doing the same thing twice.

While Medium follows a similar flow, the simple change in visual weight from the text link dropdown to the button makes it feel like two different actions and elevates the importance of the final Publish button.

[anyssa]

I don't think labeling, is the main problem here. Taking an extra click just to reach the publish button is the issue, as I see it.

Again, there are better ways to help the user prevent taking unwanted actions. Although a dropdown may give the user some time to think, even so there's a possibility that they will click it accidentally. How about ask for a real confirmation, instead of using tricks?

• A little modal confirming publication, after the user clicks the button the first time the post is being published. It can have other publishing settings too.
• Feedback about all the actions taken, letting the user know exactly what's happening.

Mailchimp has a nice way to confirm the sending of a campaign.

The difference is that this happens after we click the send button, that is not hidden, is highlighted (side note: is super fun too).

Also, as @themightyant asked, is there any data about the accidental clicks on the publishing button to backup this? It would be a great contribution to the discussion.

[StaggerLeee]

Hi @maddisondesigns. Yes it is this plugin.
I know it replaces whole button, hides old.

Just saying like it this way as it is now in Gutenberg. So they do not think about switching back to one button design. This way plugins/code can extend button/select list.

[iandunn]

@karmatosed: This accidental publishing isn't just from Gutenberg, it's been there since WordPress has had publishing.

Do we have any stats (or at least a lot of anecdotes) to show that? I can only remember 1 time that I've ever accidentally published a post, out of thousands. A simple 30 second undo timer would have been enough for me in that 1 situation.

@karmatosed: Language is a powerful thing and changing something like that could be super helpful here.

The problem for me is that the extra step requires extra work, but it doesn't offer anything that I find useful, in order to justify that extra work. I think that'll still be the fundamental problem, regardless of the language on the button.

Another idea would be to have two buttons: one that's Publish... (which brings up the dropdown), and another that's Publish Immediately (which skips the dropdown).

@folletto: The content in the dropdown isn't replicated anywhere else in the UI before the dropdown.

Now, if that's the case, then I can see an argument for it. Because, it's no longer an extra unnecessary step, it's just that the work of setting tags, etc has moved from being done in the sidebar to being done in a dropdown. That doesn't feel like a compelling change to me right now, but I'm willing to give it time to grow on me.

@Ipstenu: There are a handful of ‘are you sure?’ plugins to put a pause between publish and REALLY publish. [...] Plugin usage numbers around 5k [...]

I agree it's a valid use case for those organizations, but if the numbers are only 5k, then that doesn't seem like it comes anywhere close to satisfying the 80% rule. Maybe Gutenberg should provide hooks to allow interstitial steps from plugins, but not have any in Core?

[maddisondesigns]

@folletto I haven't used Medium myself. I'd be interested to know, in that example you gave, it shows a Publish dropdown menu. Do users have to actually click the Publish menu option or is it a typical dropdown menu when you simply hover over it and then the dropdown panel appears?

One of the issues that I have is the introduction of extra clicks, just to publish your content. Using that Medium example from above, if that Publish panels appears by simply hovering over the Publish dropdown menu, even that is better solution, as you're not forcing an extra click/step.

As others have asked, I would be keen to see if there are any stats to back up the claim that accidental publishing is an issue with the current workflow. I have never heard any client or Meetup/WordCamp attendee complain that they have issues with accidentally publishing content all the time. Gutenberg should be making publishing easier, not making it more complicated and certainly not introducing "solutions" to problems that don't currently exist.

[mtias]

along with a complete change of the existing publish workflow by removing the Save Draft button

@maddisondesigns I am confused, Gutenberg has a "save draft" button:

[themightyant]

@mtias Everything is in flux and being tested and iterated. This wasn't there before.

[mtias]

@themightyant the save draft action has been present since several months ago.

[maddisondesigns]

@mtias As of the current version of Gutenberg, that Save Draft link constantly disappears (after auto-saving), leaving people with just a Publish button. I mention in my comments above why no visible Save Draft button is a bad idea and poor usability, regardless of the auto-saving.

[youknowriad]

@maddisondesigns It disappears if you don't have anything to save. It's already saved. I won't call this a poor usability.

[maddisondesigns]

@youknowriad Yes it is, and I've explained why, above. The lack of a (constant) Save Draft button is why people are complaining that it's too easy to accidentally publish content, which in turn is why you've created this double update button solution. Again, as I said above, you're trying to create a solution to a problem that you introduced

[folletto]

Note: the issue existed before Gutenberg: it's not a byproduct of auto-save. Where does the idea that auto-save is creating a problem come from?

Also, as explained above as well as in the original ticket, I'll remind that the solution exists for multiple reasons. Please let's be mindful of all of them in the refinement process. If there are other alternative ideas, on top of the ones already suggested above, let's propose them here for consideration so we can iterate. Let's keep the discussion constructive.

Thanks @anyssa for the Mailchimp example, that's excellent. While we need something more structured because we aren't doing this just to avoid accidental publication, their approach is effective in that specific regard, and I agree it adds a good fun factor without being too whimsical. I'm not a fan of the dropdown solution myself (as you can read in #2887), so I feel there's space for exploration here. :)

[folletto]

Trying to summarize, here's my take on the suggestions tha appeared so far in the thread above:

1. Labels — I personally don't have problems with the same labels as it's a common pattern, I can agree as hinted by others above that having both visible at the same time introduces some cognitive dissonance. This could be done by changing the label once the button is clicked or...
2. Style — ...changing the button styling / selection / visual. Especially when clicked.
3. Container — Consider different options that aren't dropdowns (modals, sidebars, full page transition, other?), or a different dropdown, or a different style altogether.
4. Hover — Consider hover instead of clicking.
5. Shortcut — Consider a shortcut for expert users, like introducing cmd+click for instant action.

Sorry if I missed any, I just wanted to have a reference list for the iterations.

[aurooba]

What if we just made a slight alteration to the design (and also functionality of course). Here's a screenshot from my Quickbooks app, it's a button and it has an arrow, but they are actually two separate buttons.

You can hit the actual button to save and close or you can open up the menu for more options. This way, if you want to just hit publish/update, you can do that, but there is this little menu there that you can open if needed, and have the rest of the stuff in there just as it is now.

Here's what it looks like collapsed.

[maddisondesigns]

Note: the issue existed before Gutenberg:

@folletto I would like to see some stats or proof that this (accidental publishing) issue existed before Gutenbuerg. I find that very hard to believe, and I have not heard, seen or read where people have complained that it was too easy to accidentally publish content.

it's not a byproduct of auto-save. Where does the idea that auto-save is creating a problem come from?

I literally said in one of my comments above that auto-save is NOT the issue!

I was fully aware that people would bring up the fact that it Auto-Saves, so I said...

And yes, as I mentioned above, I realise that Gutenberg auto-saves. I'm not suggesting that it shouldn't. I'm suggesting that providing users with a Save Draft button, as they're currently used to, is going make it less likely that they're going to publish their content accidentally.

You also seemed to have missed my question from earlier in relation to Medium...

I'd be interested to know, in that example you gave, it shows a Publish dropdown menu. Do users have to actually click the Publish menu option or is it a typical dropdown menu when you simply hover over it and then the dropdown panel appears?

Does that button example you showed from Medium, need to be clicked or just hovered over? If that Publish panels appears by simply hovering over the Publish dropdown menu, even that is better solution, as you're not forcing an extra click/step.

[MounirHamani]

@youknowriad It might be better to leave the "Save Draft" button and make it grayish when there is nothing new to save.

Also, as suggested, it might be better to adopt a hover interaction with the main "Update/Publish" button instead of a click.

[folletto]

I literally said in one of my comments above that auto-save is NOT the issue!

Yes I recall, which is why I asked explicitly as I was confused by what you meant with the latest comment.

Thanks for your clarification. :)

You also seemed to have missed my question from earlier in relation to Medium

It's on click. Which is important as hovering is not available on mobile, and even more hovering is difficult in terms of accessibility for two reasons:

1. People with motor disabilities will have a harder time to open the dropdown
2. Once open it's too easy to accidentally close it by moving outside the area, making it harder to use to everyone

That said, I'd suggest to just signup on Medium and give it a try.
It's always better to try things first hand, and Medium it's fairly easy to access. :)

[folletto]

I tried to check some data. For us this wasn't a recent news so I had to do some digging in past discussions and threads. I can share a few bits here, one qualitative and one quantitative, one of which is updated to November 2 so it's incredibly recent which is helpful in avoiding showing up "old data".

Quantitative: disable actions metric

The quantitative part is related to an UI we launched on .com that covers the same goal of the dropdown discussed here. We wanted to make sure it was something effective, so to track it we added a flag that allowed users to disable this feature.

Here's the result (Sep 4 - Nov 2):

It's also notable how most of the actions were done in the first four days after the launch, and now it's trending down as fewer and fewer people are disabling it.

Qualitative: forum feedback

The qualitative one is easily visible to you all by browsing our support forums. This is tricky as for most people "I accidentally published" is really asked as "How do I revert from published to draft", because (in my experience) people tend to blame themselves. During the research we had found people complaining since 2012.

To see by yourself you can do some searches. I'd suggest to use Google as it's easier to pinpoint the wording. Do a search like this one.

We have yet to see if the issue surfaces again since we introduced the new interface. We'll keep tracking it.

Some examples of the feedback you can find in this way:

Several times now, and twice in the past month, I’ve accidentally clicked Publish before my post was done. I love how fast and efficient WordPress is — but surely wish that it was a little less fast and efficient on publish, as it immediately e-mailed the unfinished post to all my subscribers and published to RSS where feedreaders picked it up.

Please, please, please relocate the PUBLISH button away from the SAVE DRAFT button in the edit window. I know they are clearly labeled, but I constantly, inadvertently, in the euphoria of writing and saving drafts of my post, hit the PUBLISH button before I’m ready, on accident.

When tired or working too intensely, it is easy to make the mistake. It is impossible to retreive send e-mails that contain a draft version, which causes significant damage to the publishing.

I accidentally published a blogpost I wanted to delete, because it contained confidential information that I am not allowed to publish. It now has gone to the people who subscribed to my blog. I want this message to be recalled, because in this e-mail they can still read what I did not want to publish, even though I now deleted the post from my blog. Is there a possibility to recall the notification emails to subscribers?

Almost happens to me from time to time. But it was because I wanted to click ‘save’, not ‘preview’. I rarely use ‘preview’.

I’m not the only one who occasionally clicks “Publish” by accident, instead of “Preview” or something else. I can immediately take the post down, but email notifications will have already been sent to subscribers and the post will have already gone to Facebook and Twitter.

And so on. You can read these yourself.

Other

It's also something that can be found on sites that cater to all audiences as tutorials on how to avoid the issue. For example "How to Avoid Accidental Publishing in WordPress" is a recent article on the subject and it suggests using a plugin to fix it.

---

I hope this helps.

[karmatosed]

Thank you so much for digging into the data @folletto! It's so great to get these insights.

[maddisondesigns]

@folletto Thanks for those details. It's an interesting read. I do think that data from WordPress.com is mostly irrelevant though as the interface for .com is completely different from the .org software, and in fact, it's closer to the current Gutenberg design.

Gutenberg is the replacement for the edit screen on the .org software. Sure, it will know doubt get implemented in .com as well, but for the most part, when people are testing Gutenberg, any comments or issues they make or find, are in relation to their experience with the .org software.

Like Gutenberg, .com doesn't have a clear Save Draft button. It has a tiny Save link, on the complete opposite side of the screen, from the rest of the page tools, so of course people aren't going to notice it. Again, like Gutenberg, it disappears after the auto-save. The fact that the existing .com interface is quite close to the existing Gutenberg interface, and people are complaining about accidentally publishing, only goes to prove my whole point.

Do your exact same Google search for site:wordpress.org/support and you don't even get two full pages of results returned.

As I've stated previously, people using the WordPress.org software, very rarely complain about accidentally publishing their content because there are clear Save Draft and Publish buttons, and they aren't sitting right next to each other, which also helps avoids accidental clicking.

[folletto]

Please don't forget that the data is from as back as 2012, .com's new editor is far far more recent.

Even if we consider that not being a problem, the data is showing people are overwhelmingly ok with the new interface.

That said, I'd still try to tweak it along the lines described in the thread. It's still good feedback, especially around creating an optimized behaviour for experts — and shouldn't be ignored.

[folletto]

Updating the list of suggestions from above, incorporating the feedback, so it's an easier reference:

1. Labels — We should review the labels and evaluate if there are better pairings.
2. Style — Review the button styling / selection / visual. Especially when clicked.
3. Container — Consider different options that aren't dropdowns (modals, sidebars, full page transition, other?), or a different dropdown, or a different style altogether.
4. Hover — Consider hover instead of clicking.
5. Shortcut — Consider a shortcut for expert users, like introducing cmd+click for instant action.
6. Explicit Choice — Consider introducing a way to switch behaviour if someone doesn't care at all about the content in the dropdown, while keeping the option available if they want to go back.

Thanks everyone for the ideas so far! :)

[nylen]

I agree that requiring multiple clicks to update a post is counter-intuitive.

On WP.com we've introduced a multiple-click feature for publishing posts (as noted above). However, there is a big difference between current behavior on WP.com and on Gutenberg. The confirmation step before making your post public makes sense to me, but updating a post after it becomes public is a frequent operation that should be frictionless.

[pyronaur]

I agree. Multiple clicks to do what I used to do with a single click is annoying.

When working on content, I tend to update 79 times before the content is truly finished (switching back & forth from the front end to the back end). That's still going to be the case when WordPress goes 5.0

Here is a simple, band-aid solution:

@folletto As for the analytics where only 1.5% disabled the confirmation - what would happen if you tested the inverse of that? Add an optional "enable confirmation" and see how many out of 1.5m users willingly enable that feature. Would that be more than 1.5%?

[jasmussen]

Would the mockups shown in this thread address the concerns?

#3496 (comment)

And to clarify, aside from you being able to opt out of that flow for publishing, we wouldn't show it for updating.

[folletto]

As for the analytics where only 1.5% disabled the confirmation - what would happen if you tested the inverse of that?

Note that the default is precisely what we are testing. The test was geared to see if that UI, when placed as default, would cause major issues. Which means that testing the opposite would be testing a different thing, so even if we got higher numbers there, it wouldn't be a useful result to assess its UI as being default.

[pyronaur]

What I meant was that by testing the opposite you would establish a baseline of how many people notice that there is an option to change the default at all.

If 2% of people notice that the default can be changed at all, and 1.5% opt-out, then you have effectively a 75% drop-out rate.

And I don't think 2-clicks are always bad. Like the "I accidentally published" examples you mentioned @folletto - Publishing is a major event, going from not-existing to visible to the whole world. However, updating - that's where I want things to be quick. When I find a typo - I want to change the typo, click update, and be done with it.

@jasmussen I think the 3496 (comment) is good for publishing. I'm not even sure whether publishing needs that checkbox there - especially if there are settings to fill ( like SEO or the like). But updating has to be faster.

[maddisondesigns]

@jasmussen From what I can tell looking at those last few mockups on #3496 is that you still need to click the publish button twice to publish and update your content. And in fact, you don't even get a different button now, you have to click the same button twice. Am I interpreting that correctly? If so, then no, it hasn't addressed any of the issues mentioned here. That makes things even more confusing!

[pyronaur]

I agree about having to click the same button twice - that would be confusing.

[jasmussen]

From what I can tell looking at those last few mockups on #3496 is that you still need to click the publish button twice to publish and update your content. And in fact, you don't even get a different button now, you have to click the same button twice. Am I interpreting that correctly? If so, then no, it hasn't addressed any of the issues mentioned here. That makes things even more confusing!

The original intent of this ticket may have gone a little bit by the wayside — that clicking update opened the popup. What we're mocking up in #3496 (and I would direct to #3496 (comment) as those are the latest mockups), we are both adding an opt-out of the whole publish confirm experience, as well as making it so it's only for the publish action, not for the update action. All other criticisms aside (which I'll get to), wouldn't that "fix" this particular ticket?

The 2nd point, that the confirm publish button sits in the same place as the pre publish button, I partially agree with, and Davide brought up that point too. A Plan B for that has already been mocked up in a previous version, and this is definitely something we'll want to tweak in implementation.

[pyronaur]

Just to clear things up - that mockup of the publish flow would be exactly what updating would look like too? If that's the case I think we can move this entire conversation over there.

[jasmussen]

Just to clear things up - that mockup of the publish flow would be exactly what updating would look like too? If that's the case I think we can move this entire conversation over there.

No, I imagine only Publish needs a publish flow like that.

[maddisondesigns]

@jasmussen I like the idea of the 'Show this every time ' checkbox, but the implementation is poor. If I uncheck that checkbox, then obviously, that panel doesn't display. If that panel doesn't display, I no longer have access to the Publish or Visibility controls. What happens when I have a page that I decide that I want to unpublish or I want to schedule the publishing of? I can't, because I no longer have access to those options. Have you thought about how I get those options back again, if I change my mind and decide that I would like to see the 2-step panel? You're going to need to have the same option somewhere on one the Settings pages, so that I can reset it. Does that checkbox stop this panel from displaying when publishing a page or only when updating an already published page? Or Both? It's not clear which workflow it affects. What happens when a plugin (e.g. yoast) adds some functionality into that sidebar section, and I've already unchecked that checkbox. I'd never see it.

There are so many issues with this implementation. And again, it's all to solve an issue that was introduced by Gutenberg in the first place.

[jasmussen]

If that panel doesn't display, I no longer have access to the Publish or Visibility controls

Those are still in the Settings sidebar. This is a "last minute checkup".

Have you thought about how I get those options back again, if I change my mind and decide that I would like to see the 2-step panel?

I was thinking something like this:

Does that checkbox stop this panel from displaying when publishing a page or only when updating an already published page? Or Both?

In the flow detailed in #3496, the publish confirm popover does not show, ever, for when you update a page. Probably doesn't show for scheduling one either. It only shows when the button is labelled "Publish...".

And if you check the opt-out box in the publish confirm flow popover, you won't see it until you manually enable it in the ellipsis menu again.

What happens when a plugin (e.g. yoast) adds some functionality into that sidebar section, and I've already unchecked that checkbox. I'd never see it.

That's right, if a plugin adds content to the publish confirm screen, and you opt out of that, you won't see it. Same as if you hide a plugin metabox using Screen Options.