backdrop-issues
backdrop-issues copied to clipboard
backdrop
[D8][UX] Save Draft (module) in core
Describe your issue or idea
@laryn ported this great module: https://github.com/backdrop-contrib/save_draft
This issue aims to update the button text on the node form. The text should match the selected Publishing option - so it's clear exactly what pushing the button will do.
Is this a duplicate of https://github.com/backdrop/backdrop-issues/issues/1383?
@herbdool The issue title sounds like a duplicate but the other issue is mainly about the drop buttons which had been introduced in Drupal 8 (and then recently have been removed again). That's why we discussed yesterday to open this new issue.
I have now renamed #1383, but still leaving it closed until the scope of this issue here is defined. If we address the button labels in this one, then that other issue can remain closed.
PS: Credits for the title of the other issue go to @herbdool 😄
Of course we should get this in sooner if we can make it @jenlampton ...that's why the exception for UX improvements/bugs was put into place ...ahem, by you and me I believe 😄
Funny, that renamed other issue still sounds like what save_draft does, which is, in fact, "situationally aware".
The other issue was about the failed drop-button idea. Can we name it that instead?
Yep, this issue here is about moving the "Publish now" and "Draft" options out of the "Publishing options" vertical tab, and converting them to form submit buttons instead. I personally have bigger plans for that other issue, but will need to wait and see the scope of this one here first.
moving the "Publish now" and "Draft" options out of the "Publishing options" vertical tab
I don't think there's a plan to do anything at all the options or vertical tab.
I think the only thing this issue aims to do is to update the button text on the single submit button. The text should match the selected Publishing option - so it's clear exactly what pushing the button will do. edit: I just updated the issue summary to match, but maybe @laryn can fill us in on everything that module does if we're missing something here :)
I think the only thing this issue aims to do is to update the button text on the single submit button.
So then this issue should not be called "Save Draft in core", because:
Save Draft replaces the default "Save" button on the content creation page and removes the "Published" checkbox under "Publishing options". Instead it presents a "Publish" button and a "Save Draft" button for the same functionality with improved usability. "Publish" will save in published form and "Save as Draft" will save in unpublished form with a single click.
...so if we are to just update the label of the button, but still have users need to select the "Publish now"/"Draft" radios, then that is (or should be?) #1383
Here's what Save Draft currently does when creating new content:
...which I think is really good UX. I don't see the point of keeping the radios if the respective submit buttons are there. Why keep requiring 2 clicks instead of changing this into a single one.
...and here are screenshots for existing content (already published vs unpublished/draft):
...missed the case where existing unpublished content is set to be scheduled:
It can get confusing when trying to figure out what to write as an action (or transition) and a state. I noticed that in the radio buttons (without any changes here) the first one will subtly change between transition and state. When first creating a node it says "Publish Now" and once it's published it says "Published". But if I edit and save it as draft and then edit again, it no longer will say "Publish Now" even though it would be an action. It still says "Published" but isn't selected.
Anyway, might need to catalog the transitions and states. I can image Save Draft functionality only works so long as there aren't too many workflow states.
I can image Save Draft functionality only works so long as there aren't too many workflow states.
That might be true, but these will be specific with core, so we can tweak the number of buttons and their labels to make this work. I can imagine that contrib that want to take over the workflow (Workflow module and the likes of it) will eventually come into play, but when that happens, these modules will need to override the default published/draft/scheduled states that come our of the box anyway.
BTW, I was recently working on a project that is using the Acquia Lightning distro (D8), and they have implemented their custom version of Workflow. v1 had this UI:
...which they have now changed to this in v2:
...these mockups/screenshots imply the ability to schedule content to be published, as well as to be unpublished at a date/time in the future (the later of which we chose not to implement).
I think the only thing this issue aims to do is to update the button text on the single submit button. The text should match the selected Publishing option - so it's clear exactly what pushing the button will do.
I don't see the point of keeping the radios if the respective submit buttons are there. Why keep requiring 2 clicks instead of changing this into a single one.
At first sight, it seems needless to keep the radio buttons in the vertical "Publishing options" tab. And yes, it is redundant but that might be a good thing because the radios tell you the Published state directly and in a clear way.
The submit buttons in contrast don't tell you the state of the content, or only in an implicit way. Take existing unpublished content as an example: You see the submit buttons Update, Unpublish and Delete which may cause a reaction like: "Okay, there is something to update, and it can be unpublished, I guess this thing is already published."
In my opinion, an editor shouldn't have to deviate the published state but he or she should be able to see it directly, that's why I tend to keep the radio buttons, at least for the moment. (Maybe we can then organize a usability testing to decide if to get rid of them.)
that might be a good thing because the radios tell you the Published state directly and in a clear way.
I'm agree with this.
The submit buttons...
I'm also not sure I like the idea of adding additional buttons.
What about the one save button we do now, but we change the text so that it tell you what will happen when you push it -- based on the selected workflow state? Views does this when you change the display you are editing and I find it super helpful.
😄 ...and that is why #1383 should not have been closed in favour of this issue here, ...nor renamed to remove the "Merge Save Draft" bit off of its title 😄
I am not in full agreement with this, as I find that my workflow is much clearer and more straight-forward/intuitive after installing Save Draft rather than a vanilla Backdrop installation (module installation bugs notwithstanding). If Save Draft could be added into core as an experimental/endorsed module (#1713), and if also we had #285 in place, then I am sure (™ 😛) we'd see most users having that enabled.
Having said that, if #1383 takes longer to get consensus on, then making the label of the current single submit button "dynamic" so to have it more accurately reflect status, is in fact a UX improvement. So definitely 👍 ...I'm just saying I expect more from core, and we can do better by using Save Draft.
I think I'm in agreement with @klonos on this one. Simply changing the label of the submit button based on the publish status radios is better than current, but Save Draft's additional functionality is better than that.
It veers a little off topic, but for context -- most of the time it is not necessary to adjust things in the vertical tabs, and I think it is a UX win to avoid extra clicks and scrolls, so the option to Publish/Save Draft with one click (Save Draft combined with sticky actions buttons and a reconfigured content creation page) seems like the best direction to me.
(And @klonos the module install issue should be solved at this point. :smile:)
Okay, it looks like everyone prefers exactly what save draft does now. Let's go with that (and close the other issue - for clarity).
Thanks @jenlampton 👍
...I couldn't sleep (typical me :sweat_smile:), so started working on this and made some good progress, but I am hitting some oddities with setting primary/secondary buttons on the fly. Now my js skills are laughable 😅😞, but I feel that this could become easier. So I have filed a couple of feature requests that could improve the DX in general when working in similar tasks: #3440 #3441
@klonos I saw your issue on primary / secondary buttons, but we already have those in Backdrop, so I closed it :) I added a note there about how we implement that (which is simpler than D8)
There's no PR here yet, and code freeze for 1.13 is in less than a week. We should get crackin' if we want this in the next release.
It's release day and there's no PR. removing milestone, adding candidate tag.
I often use the Save Draft module, and think it would be a great addition to core. I'll advocate for this issue, and see if I can start working on a PR soon.
