Change "create new revision" check box

Is this patch failing tests because of a bug in the patch, or because the tests are expecting this checkbox to work differently from how it does?

I'm more designer than programmer, but I had our web developer take a look at the patch and he thought it was pretty simple and straight forward. I'm changing the status back to "needs review" so we can hopefully get some more eyes on this.

Given the minor nature of this patch, the fact that it is only failing testing because the test itself must be updated to account for the patch, and the fact this is a usability update, do you think we can get this in during the current "code slush" period? Is anone willing to take this on? While the major feature updates I was hoping for may not make it in, this will at least help set the stage for some contrib modules to improve things.

I have no problem with the default state of the checkbox being checked, which means you still need to "opt in". Personally I don't think that's ideal, but if it will make the change more acceptable to the broader community then I'm all for it. And the wording of the checkbox is also negotiable. If anyone has a better way to phrase it, please make a suggestion. Right now I'm more concerned about the overall concept being implemented than I am about specific wording.

I think this is absolutely a critical update, despite #282122: D7UX: "Save draft" and "Publish" buttons on node forms not making it in. This will still remove a critical usability roadblock and permit further development of these features in contrib.

The "save as draft" issue provides a good example of the importance of this change. Many publication workflows require the ability to save new revisions in a draft state, without changing the currently published revision. Adding a [Save as Draft] button to the node edit form is a logical feature to implement for these use cases. The expected behavior of such a button is to create a new revision in the draft state. The problem is that there is this checkbox to "Create New Revision." If the button creates a new revision when the checkbox isn't checked we have a serious UI conflict, but requiring the user to check the box before pushing the button is a user experience disaster. If the button doesn't automatically create a new revision it will be performing counter to user expectations.

To solve this we change the wording of the checkbox to something like "Overwrite Current Revision." Checking this box is the equivalent to leaving the "Create New Revision" checkbox unchecked, and vise-versa, so there is no real change in functionality. However, it significantly improves the user experience. Now a feature like the [Save as Draft] button can work as expected. It will automatically create a new revision, unless the user takes the extra step of forcing Drupal to overwrite the current revision.

On the other hand, checking the box in the default settings for a content type will make Drupal act as it does now and prevent it from creating new revisions at all. And if the default setting for new content types was to check "Overwrite Current Revision," then Drupal would behave exactly as it does now out of the box. But at least it would make things a little better for those of us who need to implement more advanced workflows which make use of the revision system.

As you can see, this change has a good potential upside with no real downside. No one looses any functionality, but some users will gain an important improvement to the user experience. And while workflow functionality did not make it into D7 Core, this change will remove one of the roadblocks to its further development in Contrib. Dries and many others have given this approach their blessing, and the patch itself is already written. All that remains is to fix the automated tests so they expect this new behavior, allowing the patch to pass said tests.

@alexanderpas:

"Create new Revision" = something new get's created! and if I don't check this box, no new revision get's created but i edit the existing revision!
"Overwrite Current Revision." = which current revision? what happens when i don't enable it?

I don't think "Create new Revision" makes any more sense than "Overwrite Current Revision" to people who aren't familiar with the revision system. Nor does it do any better at indicating what will happen if I don't check the box. If I'm not overwriting the revision I'm editing, then I must be creating a new revision. It's the only logical option. Just as overwriting the current revision is the only logical conclusion if I don't check "Create new Revision" now.

The big difference here is that "Create new Revision" does nothing to express the danger inherent in not checking that box. To me, this alone is reason enough to make this change. Editing a node without using revisions is a seriously destructive process and whatever we say should communicate that to the users. Once you hit save there's no turning back. As for what happens if you don't check "Overwrite Current Revision", that is less important, in my opinion. Letting people save new revisions is the safe choice. Look at Google Docs. They don't warn you that you are saving new revisions when you press save.

@soxofaan: I agree. The checkbox should say what it is going to do, rather than what it is not going to do.

How about "Overwrite Existing Content"?

I hope the wording issue is not preventing anyone from moving forward on the rest of this patch. Changing a simple string can always happen later, but this patch needs to be committed by Oct. 15 or we'll still be talking about it a year from now.

@RoboPhred

"Override" is not really accurate in this context.

While I personally don't have a problem with "Overwrite", I am also happy with "Replace".

How about "Replace Existing Revision"?

Does anyone know how to fix the tests so we can get this baby committed? The clock is running!

bump

According to Dries' development schedule for D7, patches that address usability, string changes and UI changes will still be accepted until November 15. This patch seems to fit into that category, so I thought I'd plea once more for help fixing the tests and getting it committed. We're so close!

@joachim

Personally I would find those three buttons confusing, and they seem generally inconsistent with Drupal's UI. But I digress. The actual implementation of a "Save as Draft" button is being discussed elsewhere. I only brought it up here as an illustrative use-case demonstrating the need for this patch.

We're not proposing any changes to the revision system, or removal of the check-boxes. The patch being proposed here is basically a simple text change. It is intended to improve the user experience and allow for the further development of publication workflow capabilities in Drupal. I'll say it again, and I can't stress this enough, this patch doesn't in any way change the functionality of Drupal, or its revision system. It is purely a usability and user experience enhancement. Furthermore, implementing this change does not mean that revisions will be "on" by default. If the box is checked by default, which is fine by me, then Drupal will continue with its current default behavior of overwriting the old revision when a node is saved.

I see no reason why a string change can't be critical. Ultimately though, I don't much care what we label this patch, as long as it gets implemented! :-)

In truth, these workflow issues are absolutely critical to me (and many others, I expect). My colleagues and I are spending countless hours trying to workaround Drupal's shortcomings in this area. Anything that might help make that easier would be a major boon. This is one of those things.

@jackie
The wording is the issue, not the default state. It's fine if the default state is to have "Replace Existing Revision" checked, thus keeping things the way they are now. But changing the wording like this helps avoid user experience inconsistencies when more advanced workflows are implemented. See my comment #15 above for one example.

@EvanDonovan
I realize this change is only needed to support advanced workflows. However, since it has zero negative impact on simple workflows, why wouldn't we want to implement it? This change is all upside and no downside! Even if the upside is only for one segment of Drupal users, it is an important segment.

True, "save as draft" didn't make it in this time, but that's no reason not to go ahead and implement this patch.

1. Implementing this will help with contrib development of content moderation modules, in the absence of a Core solution.
2. We already have a patch (thank you BarisW) and are only waiting on an update to the automatic tests so they can recognize the changes made in the patch.
3. There will be no negative impact resulting from this change.
4. This is basically a simple text change that improves usability, and who doesn't want to improve usability.

For all of these reasons, I am bumping this back to D7 one more time and crossing my fingers that someone is willing to take up the task. It looks like content moderation is going to be a longer road than I had hoped, but why not take the first step!

I would be fine with that, but: a) there will be a revolt from the army of users who don't want to use revisions for most of their content (see #12 above), and b) that is a separate issue than what is being discussed here.

The basic thinking behind this issue is as follows:

1. It would be good if support for content moderation and advanced publication workflows was improved in Drupal.
2. Implementing some workflow features (like a save as draft button) creates interface inconsistencies.
3. By changing the phrasing of this interface element from "only create a new revision if I tell you to," to "create a new revision unless I tell you not to," we can avoid such inconsistencies and thus improve usability.
4. Because this is a change in perspective and not a change in features, it can be implemented without altering Drupal's default behavior.
5. Even if the workflow features are still in contrib, implementing this can help improve the quality and usability of that area of contrib development and may pave the way for future core upgrades.

In my mind, the default setting of this check box is far less important than the phrasing of its label. There's been a fair amount of discussion in this thread about how the label should be worded, but I am happy to entertain more discussion on that matter. Here are a few options:

• Replace existing revision
• Replace existing revision with changes
• Overwrite existing revision
• Overwrite existing revision with changes
• Save changes over existing revision
• Replace current revision
• Replace current revision with changes
• Overwrite current revision
• Overwrite current revision with changes
• Save changes over current revision
• Replace revision with changes
• Overwrite revision with changes
• Replace this revision
• Overwrite this revision
• Replace existing content
• Overwrite existing content
• Replace existing content with changes
• Overwrite existing content with changes
• Replace the existing revision
• Overwrite the existing revision
• Replace saved revision with these changes
• Overwrite saved revision with these changes

Some of these had already been ruled out by others, but that doesn't mean they shouldn't be reexamined. If you have any other suggestions then please post them. Today my favorite is "Save changes over existing revision." I find it to be descriptive and at least as intuitive as "Create new revision."

For what it's worth, I just polled my wife, who is not a developer, a designer, or a Drupal user. I asked, if she were using a content management system to edit a web page in an online form, and at the bottom of the form there was a check box labeled "Save changes over existing revision," what did she think would happen if she checked the box before pressing the save button. She said she thought it would overwrite what was already on the site with her changes. Then I asked her what she thought would happen if she didn't check the box. She said she thought the changes would save to some other holding place, like a draft.

For the sake of comparison, I asked her the same question again, but labeled the check box "Create new revision." This time she said she thought there must be a series of revisions and this would add another one. But then when I asked her what would happen if she didn't check the box, she thought it would keep the old content and her changes would be lost.

I realize this is just one data point, but it's interesting non the less.

I've been thinking about this issue quite a bit and I think I'm ready to relent. Given the current system in place in D7, EvanDonovan's suggestion that we replace the checkbox with two radio buttons could definitely help usability. It makes the two choices available to users explicitly clear. That being said, I don't think it solves the problems presented by advanced workflows, which I was trying to tackle. However, I'm the first to admit that workflow is a complex beast. Perhaps we just need to expect that anyone building a workflow module will need to use hook_form_alter() to fix the problem for their specific workflow implementation. I know that for my own use, given the custom workflow we're setting up, there's no way I would ever let my users see this checkbox anyway.

For now I'd like to call attention to #218755: Support revisions in different states. That provides far more fundamental support for workflows and content moderation in Core. Once it is implemented, just about everything else, including "save as draft" buttons and this issue here, could likely be taken care of in contrib.

This issue is now superseded by #1776796: Provide a better UX for creating, editing & managing draft revisions., so I am marking at a duplicate. I would have no problem re-opening this as a D7 issue again, but I expect getting this sort of UI change into D7 would be an uphill battle at this point.