Clear up confusion between “Save & Publish” button and publishing posts #207
Comments
|
Snapshots UI makes a lot more sense! |
|
@valendesigns if we changed “Publish” (go live) to “Save”, when what do you think would be a good alternative for the current snapshot Save/Update button? I keep going back to Git terminology, like using “Commit” for publish and “Stage” or “Stash” for save/update snapshot. These aren't helpful for non-technical users. |
|
We could change "Save" to "Snapshot", but I'm not convinced that's any better or that there really is going to be anything that makes it more clear other than adding a tooltip to "Save" that explains what you're doing. |
|
Question About Solution Hi @westonruter, It seems like it might make sense for the button to display “Save & Publish” for all other Customizer panels. Because it’ll actually publish the changes. Of course, it’s different on Customize Snapshots. |
|
I think we should potentially eliminate “publish” entirely from this customizer button that makes changes live, regardless of whether you are in a post section or not. I'm not totally sure on the right words to use, but I'm sure it should be consistent across all customizer sections. |
As Weston suggested in #35547, overwrite api.l10n.save. While the Customizer initially loads, the value (text) of the button is 'Save & Publish'. In about.5 seconds. it replaces this with 'Saved.'
|
Request For Review Of Pull Request Hi @westonruter, As you suggested in #35547, this overwrites |
|
What about moving the Status dropdown selection into the Save/Publish buttons and have some sort of hover or long press/click on the Save button show additional statuses to select?
We'd probably still want to show the Status field, but maybe just as a read only label below/next to these buttons? |
|
@jeffpaul yes, I think this may be on the right track. Ideally the Save & Publish buttons would be re-combined actually, but with a dropdown like you've depicted here to Publish. So maybe there could be a “multi-select button” that has the options:
For the “Publish” button this still doesn't eliminate the confusion in Customize Posts between publishing customizer changes and publishing a post, however. But since the option wouldn't be a separate button like users are accustomed to on the edit post screen, maybe it would help. Or also, in this dropdown it could be “Publish changes”. |
Absolutely right, I can think of only two options here. 1- Change the name dynamically from "Publish" to "Save" for when the expanded post has a status other than Publish, and then change it back to "Publish" to other sections which has status set to Publish. Thoughts? |
|
@sayedwp thanks for your thoughts. I'm really uncertain of the best way to go, though the 2nd option seems like it would be the path of least resistance. Maybe a control notification could be shown when the status is set to anything other than “Publish”, reminding them that publishing the overall changes will not cause the post to also be published unless its status is set accordingly. I'm not sure of the best way to word that:
|
|
@westonruter @sayedwp note that I'm iterating on potential UX flow for the status/buttons with @jwold. We'll get you details once we've both had a chance to review each other's work and hope to help resolve this issue (from a UX perspective). Please hang tight while we work on this "offline"... thanks! |
|
@westonruter and @sayedtaqui Jeff and I have been working on the UX flow and would love some feedback. Jeff isn't 100% sold on the copy yet (and I agree with him). We looked at other content publishers and pulled some styles and ideas from them to combine the Save + Publish into one dropdown box. Please me know your thoughts! https://xd.adobe.com/view/151961ff-ee74-45bc-8499-a99b6bdeb231/ cc @jeffpaul and @valendesigns |
|
@jwold So is this the intention to combine the UI for managing a post's status with the UI for manipulating the status of the changeset as a whole? Would it replace the current post status and date controls? It's not clear to me whether some of the UI there is talking about the post or the changeset. In the case of a changeset, then if you have created 3 posts in the customizer, clicking Publish would send all three of them public? |
|
@jwold For managing the changeset status, I like how your mock integrates the selection of the status with the fields that relate to that status, specifically for when selecting to schedule a changeset. For draft and pending statuses, however, should there really be the second confirmation screen? It seems I should be able to just do a single click to save draft without needing to give an explicit OK. |
|
@westonruter...
I think they've been conflated, albeit unintentionally, so I'm thinking through any implications of doing so. It's a bit confusing that a Post could be set to Review but technically wouldn't be there until its Changeset is Published. I don't think @jwold and I worked through that sufficiently, so we'll take another spin through and see if there's better Copy and UX to account for this. I do know that people using the Customizer are confused by the separate status and buttons, but it looks like there's still some issues to consider between individual Posts within a Changeset and the Changeset itself. |
|
@jeffpaul thanks! Yeah, it is confusing, since there are statuses for multiple things in play here. And maybe a post's status should by default inherit from the changeset's status, though this clearly wouldn't work in the case of assigning a post to a private status. It is a challenging problem! |
|
@westonruter any concerns with keeping the focus of the flow of these buttons specifically to the use in Customize Posts here and having a separate issue for Customize Snapshots to consider concerns specific to that plugin (where things get inherently more complex)? There are definite scenarios where people will ONLY have Customize Posts installed and I believe "solving" this Issue for just this plugin is feasible (and essentially done via work from @jwold). If you're ok with that, then we'll tidy up the wireframe and share here for review as well as spawn a similar Issue in the Customize Snapshots to triage there how best to handle the additional complexities within that plugin. |
|
@jeffpaul I'm not sure how the behavior for the buttons in Customize Posts can be separated from Customize Snapshots, given that they are both centered around the same button(s). The main issue seems to be that the top header toolbar of the customizer is specifically about saving the entire customizer state, nor just whatever post section that might currently be expanded. I don't think we can override its behavior from being customizer-global to being specific to whatever post section is currently expanded. In 4.8 we should be introducing the ability to save a draft using the exact same UI as was first developed in snapshots. See https://core.trac.wordpress.org/ticket/39896 To me it seems that the Customize Posts problem specifically should focus on the Status control itself, and making sure that it is presented in a way that makes its relationship to the Save & Publish button clear. |
|
@westonruter bah, you're (not surprisingly) right. I somehow (again) forgot that you could have more than one post/page being customized within Customize Posts. I'll regroup with @jwold today and try and clean up the work for review. |
|
@westonruter and @jeffpaul based on conversations above and Jeff's feedback, I've created another version of the prototype for feedback: https://xd.adobe.com/view/8c55c16b-15aa-46f0-b07d-e3b08eee24f2/. Also, as mentioned, it definitely makes sense to move the "warning" about individual posts not being published. See attached.
|
|
@jwold that prototype feels good! The changeset title (“commit message”) seems like it could also naturally fit in that initial dropdown instead of being behind the secondary ✏️ dropdown, yes? From current Customize Snapshots plugin:
/cc @melchoyce |
|
@westonruter awesome! What do you think about putting the changeset title, along with the link to the snapshot beyond a settings icon (gear)? https://xd.adobe.com/view/d30cd561-14db-41ba-b8ad-c6b116969e6e/ |
|
@jwold yes, that works well. Another option would be to replace the gear icon in that mock with the pop-out link and then place the title input right there in that initial dropdown. The trash icon could also be shown there next to the pop-out icon. So then the initial dropdown could have the status options, followed by the title input, and then below that have a pop-out icon, a trash icon, and then the Publish Now button. I guess this also depends in part on how often the title and trash features would be used. If they would be used commonly, then this would avoid having to navigate to another screen. If not used commonly, then it would just add visual clutter. Thoughts? |
|
@westonruter I'm torn on whether we should keep it all behind another screen or show it in the initial dropdown. It's good to show as much as you can without hiding things behind a menu, but I'm not sure how often people would want to change the title. Here's a mockup of what you've described using the trash icon or the words "move to trash:"
cc @jeffpaul for thoughts |
Agreed. One thing for sure is that if the title is the same as the UUID, we should show the title as being blank. Or we should have a better default title, like a list of the setting IDs that are in the changeset: “Changes to blogname and blogdescription”. |
|
@westonruter yes the title is the same as the UUID. How much work would be involved in changing the default title to settings in the changeset? I'm certain this would be appreciated by clients. cc @jeffpaul |
|
@jwold preventing the default title from being the UUID would not be very involved. |
|
@westonruter I've made changes to the prototype based on the feedback above: https://xd.adobe.com/view/d30cd561-14db-41ba-b8ad-c6b116969e6e/. |
|
@jwold thanks. When I've selected to schedule the changeset, I'm seeing a “Save Changes” button that doesn't appear when the other statuses are selected. When scheduled:
Versus when a draft:
To me the “Save Changes” button seems somewhat as an outlier? What purposes does it have? If anything I'd suggest that the Force Publish button could be the only button there. Or maybe even this button also should be removed in favor of a user just switching to select the Publish status instead? |
|
@westonruter you're right, it is an outlier. The use case is this:
Is this use case a real one? |
|
@jwold What about when I have a Draft and I make some additional changes? Aren't those changes auto-saved? Or does the user need to click the Draft button again? |
|
@westonruter good point. I wasn't thinking you'd have to press Draft button again. Should we just assume if I've scheduled a changeset and make additional changes that those changes will be part of that scheduled changeset? Or... not? Unsure about this one. |
|
Yes, I think if you've scheduled a changeset, and then you make additional changes, then it would make sense for the additional changes to be added to the scheduled changeset. I guess we should consider the Edit Post screen. If you edit a post, and then schedule it, what happens if you make more changes? You have to actually hit the “Update” button for those additional changes to be saved into the scheduled post. In the same way, if you save a Draft post and you make additional changes, then those additional changes are only saved into the Draft if the user hits Update. Otherwise, the changes are saved in an |
|
Great thoughts! Here's a video response: https://v.usetapes.com/pwL2dm3S41 |
|
@jwold thanks for the video. That's helpful and it clarifies something about the mockup. In your mockup clicking anywhere on the button causes the dropdown to appear. In fact, the button does nothing other than to show the dropdown. I was assuming that the left side of the combo button had a save action, whereas the right side (with the arrow) was just to show the dropdown to be able to reveal alternate statuses to save as. If that is the case, then there wouldn't need to be a secondary save button inside the dropdown because it would already be shown above. Likewise, something else the mock I think needs to show is what the button looks like in a dirty state. Let's say when you first load the customizer and it has a clean state, the button says “Published” and it is disabled. But then when you make a change, the button becomes enabled and the text changes to “Publish”? Then you could open the dropdown to select a different status in this dirty state, and when doing so it would update the button text to be (perhaps):
If you had scheduled the changeset, then you make another change, the disabled “Scheduled” button could then become enabled again with the text changing to “Schedule”. The working state could introduce a spinner like we have today or as some style on the button like on WordPress/gutenberg#708 (comment) or perhaps even the text could change to “Scheduling”, which I think maybe I also noticed on Gutenberg discussions. |
What it be easier if I created a clickable prototype to show all that, or just wrote it out as a description? |
|
@jwold humm. A clickable prototype would probably be best because it is so confusing with so many different states to account for. I feel like every time a bit of time passes, I have to completely re-familiarize myself with all of the intricacies and scenarios 😦 |
|
Just posted some options based on a conversation last week (on the save and publish button discussion) on https://core.trac.wordpress.org/ticket/39896#comment:18 |
If you edit a post and set its status to “draft” it is very confusing that the “Save & Publish” button mentions “Publish”. Users would assume this would switch the Draft status into Publish when you click it, but it doesn't. Via @ahmadawais:
In the Customize Snapshots plugin, this one button is broken up into two:
As the Customizer state can be saved separately from making the changes live. The confusion is still present here for posts, however.
The terminology for “making changes live” needs to be improved. Instead of “Publish” it could instead be “Commit”. It could also be just “Save”, but then we'd need to change the label for snapshots to be something else.
The text was updated successfully, but these errors were encountered: