Nice work, this is certainly a huge improvement over the current workflow!

If an author leaves the page and returns to the entry later, the provisional draft will be loaded automatically (merged with any recent changes to the Current revision)

Considering that the current revision's content will be inaccessible to the author as long as the provisional draft exists, I feel like the Discard changes button could be more visible/easily accessible. Maybe it could sit next to the revision dropdown, instead of inside it?

@mmikkel We tried both ways and felt it was better to be directly linked to the “Edited” label, along with that “Showing your unsaved changes” message. (Maybe we chose wrong, but we’ll wait and see how well it’s received by normal authors during the beta before making the final call.)

Cool. I enjoy how consistent the new workflow is and I think always loading the provisional draft (if one exists) is the right call. But, I also suspect that in a lot situations any unsaved changes will be intentionally unsaved, in which case it might be frustrating to some that discarding those unsaved changes isn't easier/more streamlined. In the situation where the author leaves the page and returns at a later time (possibly, days later) I'm also not convinced that the "Edited" label and the blue status indicators are clear enough signals to the author that they're looking at unsaved changes and not the saved current. A more visible "Discard changes" button (perhaps, even together with the entire "Showing your unsaved changes" message, being rendered outside of the revision dropdown) would probably help with that, too.

It's definitely going to be interesting to hear how real authors respond though.

Yes I agree

Oh no. I can't believe this is changing again after we've just spent hours and hours explaining it all to our clients.

@sunscreem think of all the hours you will save in the future, not explaining it to future clients!

@brandonkelly Testing 3.7 and noticed that the updated "Unpublished drafts" workflow can be confusing when intentionally making a new post with the intent of working on it in the Draft state before publishing it.

In this instance, "Save" is a confusing option, as it takes the auto-created draft and publishes it. Not having a clear option to save a draft will lead many users to simply publish their work.

It might be preferred if there were multiple options here.

• Save Draft (or similar) so the user has a clear way of knowing that their work is saved
• Publish (or similar) so the user has a clear way of knowing that clicking this will publish their content

In this instance, "Save" is a confusing option, as it takes the auto-created draft and publishes it.

I don't agree. The UI/workflow in Craft 3.7 acknowledges that most authors don't consider their "new entries" to be "drafts", but rather entries that are not-quite-real-yet, or ephemeral, i.e. "unsaved". And the word "Save" works, because it implies that this ephemeral thing that the author is working on will be persisted, which is not necessarily the same thing as "publishing" it (a word that implies that the entry will go live on the site, which may or may not be the case).

Not having a clear option to save a draft will lead many users to simply publish their work.

Agreed; in addition to the primary "Save" button it'd be nice to have a "Save as draft" (or "Create draft") option, which would convert the provisional draft to a "real" draft – either as a secondary action (i.e. gray button to the left of the red "Save" button) or inside the primary action dropdown, below "Save and add another".

@mmikkel Let me explain why I think Save is confusing.

Here's a user's steps:

1. Create new entry
2. Begin writing content
3. Decides to stop and come back to it later
4. Attempts to save current work by clicking "Save" (even though it's already auto-saved as an unpublished draft)
5. Returns to entries list to realize that they just published their draft (or may not even notice and have incomplete content showing on the website)

I think there just needs to be a clear way for the user to do one of two things. Save their current progress or publish their content, and it should be crystal clear what's happening.

I think there just needs to be a clear way for the user to do one of two things. Save their current progress or publish their content, and it should be crystal clear what's happening.

@jsunsawyer I don't disagree, and I think adding a secondary "Save as draft" or "Create draft" action to provisional drafts would be the perfect solution to the scenario you describe.

Part of the reason why 3.6 as so confusing to a lot of people, was that most authors don't consider their "new entry" as anything like a "draft". It's an unsaved entry; saving it will make it a saved entry, and if it's saved in an enabled state, that will effectively make it a "published" entry. This is how Craft worked for years, and I can't remember anyone being confused.

Testing 3.7 and noticed that the updated "Unpublished drafts" workflow can be confusing when intentionally making a new post with the intent of working on it in the Draft state before publishing it.

This is exactly the use case we were trying to improve with 3.6 (see #5661).

The challenge is, when you click “New entry”, you are already editing an (unpublished) draft. That’s exposed in two ways:

• The entry status in the metadata pane shows “Draft”.
• If you were to leave the page and go back to the Entries index page, it will be listed there with a draft icon.

So it’s not really clear what the expected behavior would be for a button labeled “Save as draft” or “Create a draft”, when you’re already editing a draft.

We “solved” this in 3.6 by making unpublished drafts’ action buttons more consistent with normal entry drafts – so the primary action was to save the draft, and publishing the draft was relegated to a secondary action. That turned out to be confusing as hell for most people though, as the primary action no longer matched the likely intent, which is to fully save the new entry they’re creating.

Maybe instead of “Save as draft” or “Create a draft”, we could add a button labeled “Done” or that just takes the author back to the Entries index page, which might feel safer than navigating away from the page. But I’m worried that would still add some level of confusion, where currently it’s very clear what the next step should be once you’re finished editing.

Plus, the author can always set the entry to disabled before pressing “Save”, which would avoid it being published on the front end.

Well, we can just wait to see how it's used (or misused) then. People will probably get used to the new behavior, but I think that it will lead to some confusion.

Something about the act of simply leaving an entry that you're working on to leave it in its auto-saved draft state just feels unintuitive to me, and I think that some users might appreciate a clear action for peace of mind. Opening up a Craft 2 project, I see that new entries present a single "Save" option, then a few dropdown options that include "Save as a draft", which gives the user a clear action to ensure that their work is saved, but not ready to publish.

Something about the act of simply leaving an entry that you're working on to leave it in its auto-saved draft state just feels unintuitive to me, and I think that some users might appreciate a clear action for peace of mind.

The UI is driving them toward saving the entry. I don’t expect many authors to know or care that they could technically leave the page as-is and let it continue to exist as an unpublished draft. If they aren’t ready to publish an entry, they can set its status to disabled before pressing Save.

Opening up a Craft 2 project, I see that new entries present a single "Save" option, then a few dropdown options that include "Save as a draft", which gives the user a clear action to ensure that their work is saved, but not ready to publish.

Right, because entries didn’t start out as unpublished drafts until 3.2.

The UI is driving them toward saving the entry. I don’t expect many authors to know or care that they could technically leave the page as-is and let it continue to exist as an unpublished draft.

This. I think the concept of drafts is close to a power user feature, and that the big win in 3.7 is bringing back "Save (entry)" as the primary action (which in my experience is what makes the most sense for most authors and use cases) whilst retaining and improving how provisional drafts work. The UI is kept clean and intuitive, and for authors who do need to work with drafts in a deliberate way, explaining how these provisional drafts function should be manageable.

That said, although the provisional draft technically covers the use case, I do think a potential "Save (as) draft" button could have merit – mostly as a reassuring feature, enabling authors to deliberately convert provisional drafts to what would basically amount to "real" drafts without a current version attached. I guess these drafts – without a current entry – could basically use the 3.6 UI (i.e. with a primary "Save draft" action and a secondary action to move the draft to a current entry - «publish» it, as it were), with the crucial difference being that the author deliberately created these drafts from a provisional state.

@mmikkel Couple clarifications:

• Entries start out as unpublished drafts – which is how we refer to drafts that aren’t attached to a real entry yet.
• When you have unsaved changes to an entry, those are stored in a provisional draft.

The old (pre-3.2) “Save as a draft” button would save your work as a real entry (set to disabled), and also create a draft for that entry, and take you to the draft. I don’t see how adding that complexity back into 3.7+ would add any value, when the thing you’re asking for (a “‘real’ draft without a current version attached”) is already exactly what an unpublished draft is. (Also keep in mind that unpublished drafts are no longer ephemeral as of 3.6, so there’s no harm in keeping them around indefinitely.)

I just made a couple changes that I think will help:

• The “Save” button is now relabelled to “Create entry” for unpublished drafts.
• The “Create entry” context menu now includes a “Save draft” action, which saves the work in progress to the draft and returns you to the Entries index page.

See #8094 for more details on those changes.

Aha, thanks for clearing that up Brandon.

3.7.0-beta.3 is out with those changes ✨

@brandonkelly I'm giving the most recent beta another go and am in agreement with @mmikkel's concerns about the provisional drafts.

Imagine a scenario where a user is simply testing out some content, but doesn't save the entry, and doesn't really intend to ever use these test changes.

Exiting the entry now leaves the entry in a provisional draft state for this user. There is no warning when they leave the page, and it may not be clear to the user that their test edits will persist upon their next edit.

Revisiting the entry that is in a provisional draft state doesn't feel much different than viewing an unedited entry.
@mmikkel outlines some related issues in this comment.

Improve exiting from provisional draft

It may be nice if, when leaving an edited entry, the user was given the option to:

• save as draft
• discard changes

This would prevent users from coming back to a partially edited entry at a much later date, then unintentionally updating content (from their initial test) that had not been intended to be part of their new edits.

Improve revisiting a provisional draft

Provisional drafts may still exist, as the user may have never been presented an option to save as draft.

Users should be presented with a clear notice that they're working from previous, auto-saved edits.

This could be as simple as alerting the user when they revisit the entry that they're working from previous auto-saved changes – potentially with a timestamp of the last auto-save.

Perhaps this would be most beneficial if Craft were to first check for more recent changes than the latest auto-save, then give a clear warning that their auto-saved changes may conflict with a more recent version, presenting the user with options on how to proceed (create draft from current auto-save or discard changes to edit the current version). If there aren't any recent changes, then it'd be as if the user left off editing the latest version (though I still think it should be more clear that they may be working with previous, unpublished edits).

Summary

I fear that left as is, users will over-use provisional drafts as their primary way of working on edits for an entry, and they'll run into issues where they make unintended changes, either overriding more recent content, or having more recent content get pulled in and not make sense in the context of their updates. Pushing users toward real drafts for content authoring and making provisional draft states more clear to the user seems like it'd prevent a lot of potential issues.

There are probably other things I'm not considering, and my initial suggestions for improvements aren't too thought out, but hopefully we can work toward some improvements here.

and it may not be clear to the user that their test edits will persist upon their next edit

In our testing and from the real world feedback we’ve received, the consensus is that it is in fact clear that you’re looking at your latest changes, thanks to the blue bars alongside the edited fields.

It may be nice if, when leaving an edited entry, the user was given the option to:

• save as draft
• discard changes

That’s not possible, unfortunately. When a user is leaving the page (either because they’re navigating away from it or closing the window), browsers only give JavaScript the opportunity to display a confirmation prompt (yes or no). The result will either do nothing or abort the action. That’s it. We can’t show a custom modal, or fire off an Ajax request if they choose to discard changes, etc.

Just to provide some feedback: Our clients are also having trouble with the automatically created 'provisional' drafts. In particular, the following scenario is now a common occurance:

1. One editor changes something in an entry, realizes they don't want to save those changes right now and leave the page. A provisional draft has been created, even if they haven't noticed that.
2. Other editors edit the entry, creating new revisions.
3. Days or weeks later, the first editor returns to the entry and doesn't understand why they're seeing massively outdated versions, even though the website shows the current versions. It's not clear to them that they have to 'discard changes' in order to see the latest version.

This problem is exacerbated if the majority of the content modeling is done with a matrix field, in which case the provisional draft and the current version can be wildly different. It also doesn't help that sometimes, provisional drafts are created even if you haven't changed anything at all (see this post with a screenrecording demonstrating this issue).

Of course, this behaviour is understandable from a technical perspective and can be explained to clients. But I still see why it's confusing if you don't know how provisional drafts work.

I would suggest the following fixes:

1. Fix the bug where provisional drafts are created if you haven't changed anything (see the link above).
2. Display a more noticable warning when editing an entry where the provisional draft is based on a previous revision that is older than the current version of the entry.

Seconding this. I'm working on a site right now which is going to have multiple authors in multiple regions (multi-site) and it's critical that this isn't confusing or broken before the editors start working on it. I'm already finding during the build that when I'm the only author, I go to edit an entry, and my edit page is filled with blue and yellow lines with no descriptions. I work with Craft every day, and I find it confusing what's going to happen if I save or discard.

Issue 1: Looking at the screenshot below, I have no idea what's current, or what will happen if I "discard changes". If I hover over the blue or yellow lines, the cursor becomes a question mark, but there's no text anywhere to describe what those lines mean. Clicking when the cursor is a question mark does nothing. Perhaps this is broken? Normally the question mark cursor is meant to indicate help text.

Issue 2: It's not clear enough when you land on the page that you're not looking at the "current" version of an entry. I've had several clients already ask why, when they go to edit a page, that the edit screen doesn't reflex what's on the website. They expect to click Edit, and change what they can see on the site right now, not what Craft saved (without telling them) 2 weeks ago.

Clicking when the cursor is a question mark does nothing. Perhaps this is broken? Normally the question mark cursor is meant to indicate help text.

There is title text that will show up if you keep your cursor there for a second.

It's not clear enough when you land on the page that you're not looking at the "current" version of an entry.

Yeah we’ve heard similar feedback – that the “Edited” label isn’t obvious enough.