_Thanks for posting this feedback. Each issue should only be focused on a single request/bug, so I have edited your post to focus on the auto draft creation._

_Regarding “Save and continue editing”, consider teaching your authors how to use the Command/Ctrl + S keyboard shortcut for that._

_Regarding entry freezing, see #824. Also check out the Snitch plugin._

In order for Live Preview to function, the changes must be saved to a draft. Perhaps the draft could be created in an ephemeral state, though, as opposed to a normal draft that was explicitly created via the “Save as a draft” button. Ephemeral drafts would then still have the same Save button & behavior that you get when editing the current entry, and you would still be able to convert it to a normal draft by clicking “Save as a draft” if you want to.

You may also be interested in the discussion happening over at #5661.

brandonkelly on 21 Aug 2020

👍1

Brandon,

Agree on 1&2.
For 3, I was even thinking NOT allowing users to directly edit the "Current" version. (the Live version)
When users click "+ New Entry", the entry is "Created" and the user is set to "Draft 1". (no more "Create" Button)
To update "Current" version, user must select a "Draft" and click Publish.

That will allow

Show something like "8 changes that differs from Live version"
User won't accidentally make changes on live website
"Save" is no longer needed. All edits are auto saving (because they are drafts)
Easier workflow to understand for editors
No need to change anything on "Live Preview"
Entries listing pages doesn't need to separate "[enabled, pending, expired, disabled] & [draft, trashed]
(p.s. I don't understand the reason that when filtering "All Entries", it does not include "Draft". To the editors, they are just entries that are NOT yet published. I have received multiple questions that they thought their drafts are gone but actually not.)

chanwhab on 22 Aug 2020

@chanwhab Please post that as a new issue, so this issue can stay focused on your draft request.

brandonkelly on 23 Aug 2020

In order for Live Preview to function, the changes must be saved to a draft. Perhaps the draft could be created in an ephemeral state, though, as opposed to a normal draft that was explicitly created via the “Save as a draft” button. Ephemeral drafts would then still have the same Save button & behavior that you get when editing the current entry, and you would still be able to convert it to a normal draft by clicking “Save as a draft” if you want to.

You may also be interested in the discussion happening over at #5661.

I agree with Brandon's idea on this. Ephemeral drafts auto-created by preview would provide a more predictable experience (at least in my opinion).

thupsi on 5 Feb 2021

I thought I would add my two cents following discussion at #7517 and the issue of having auto drafts creating to many versions to display on the entries list.

So I checked at one of my largest client (the french postal office) if they had drafts created that they didn't consciously authored. I had many different answers but none of them understood what was actually happening, that entering live preview created a new draft. For many, they stopped using drafts as a whole and reverted to editing on the live version. They thought drafts were created as a bug (but didn't think it was that much of an issue).

After a quick check, one third of the entries had drafts that authors had never thought of authoring. That's more than 400 entries, with some of those having up to ten drafts. (that's when I almost felt off my chair). It looks like authors are sometimes using live preview just to see the content in situ, without actually thinking about authoring the entry at any point.

I do understand that draft needs to be created when entering live preview for it to work the way it works. But it should be transparent to the author. I mean fully transparent. There shouldn't be ANY difference between blindly changing the value of a field and doing it in live preview. I go one step further: ephemeral draft as we could call it should not be exclusive to live preview, it should happen as soon as we are editing a field, so that it applies to the view button without having to save the entry beforehand.

Let me sum up this last issue because it really is related:

we should be able to edit a live version without saving as a draft first
- we shouldn't be mandated to create a draft to change a typo
- that means live preview should be available on the edit screen of a published entry as it is today
view and live preview should work in the exact same way
- let me explain this one
- authors are loving live preview because it allows them to edit alongside the live result
- but I witnessed many authors using view just to see the result in the actual large breakpoint, which is not possible in live preview as it takes some precious horizontal space, often getting the page to render at a smaller breakpoint
- and very often they get trapped in the "oops why am I not seeing my changes?" "oh I get it I forgot to save my changes"
- this actually happens to me all the time when training at my clients, I always prefer to show result via view
that means from the moment we edit a field, we should enter a special state that auto saves our changes, so that they are visible in live preview as well as in view
- that's where our views could diverge in how to handle this
- that state should be transparent for the user except for the green check box that shows entry is live saved
- it shouldn't create a draft unless the user at one point asks to save as draft
- if the user decides to save as draft, the published entry should be reverted to before editing
- if the user does not save as draft and leaves the edit screen, edits are lost (forever)
- if the user does not save as draft and saves the entry, well the published entry is saved with the edits
so it is not so much an ephemeral draft as it is a special state (working copy) that gets applied to a published entry and reset as soon as we save as draft, cancel (leave) or save changes.

For new entries, nothing changes, a draft is created as soon as a new entry is created.

Edit: I realize there is a weakness in this... how to deal with cancelling or leaving the entry consciously (and discarding the auto draft) as opposed to leaving your station open for lunch and getting disconnected unconsciously, loosing your work... auto draft allows for dealing with that situation. But I maintain that 1/ this auto saving/draft thing should apply as soon as editing starts (not only entering live preview) and 2/ it shouldn't be treated as a draft but as something else.

Edit 2: Regarding my previous edit, I say it doesn't matter. It's not any different than today when we are NOT in live preview. Except we are auto saving, just not keeping it as a draft. So forget my previous edit, I think the approach described above still makes sense.

JeanLucEsser on 9 Feb 2021

👍3

It looks like authors are sometimes using live preview just to see the content in situ, without actually thinking about authoring the entry at any point.

This – it happens a lot. Although the draft isn't actually created until the author starts editing the content (at least not since.. 3.5-something?). Problem is, authors often use Preview to simply test stuff out, play around, show off a new feature to colleagues, etc. – with no intention of actually saving or publishing anything. And even if they did, Craft shouldn't change the context; if they're previewing the current entry, any edits should (at least transparently appear to) apply to the current entry, not a draft that the author didn't ask Craft to create, and that will – to a lot of people, inexplicably – change the context of the entry/form that they were in, before they opened that preview.

mmikkel on 9 Feb 2021

that means from the moment we edit a field, we should enter a special state that auto saves our changes, so that they are visible in live preview as well as in view

This is actually how it worked when 3.2 first launched with the new draft system, and it wasn’t well-received (e.g. #4549).

that means from the moment we edit a field, we should enter a special state that auto saves our changes, so that they are visible in live preview as well as in view

That “special state” needs to be a draft; it’s what the draft system was built for.

We could tweak it a bit to make it _feel_ less like a draft, but it would still be a draft under the hood. That’s sortof what I previously suggested that we do, but the more I’ve thought about it the more I don’t care for that idea. Good design is clear about what it is and what it’s doing; the more insight an author has into what’s happening, the more effective they’ll be at using the tool.

On that note, I think the biggest issue we have right now is not the behavior, but the communication. So as of the next release, Craft will start notifying authors that they’re now editing a draft, after they close Live Preview, and give them the option to quickly delete it if they don’t want it:

An HUD that informs the author that they’re editing a draft, with the options to keep it and to delete it

brandonkelly on 10 Feb 2021

I would also prefer if Craft would only show versions intentionally saved as drafts in the Drafts dropdown. Because of the automatically saved drafts, drafts are practically unusable or very confusing on some of my client sites. Live Preview is very often used to quickly try something out. My clients don't understand that a visible draft is created every time. (In fact, it is rather annoying most of the time.)

This is what the drafts dropdown looks like for practically every entry (Craft CMS 3.5.17.1):
Screen Shot 2021-02-10 at 13 52 04

Versions intentionally saved as drafts are often moved far down the list and are indistinguishable from the automatically created drafts. My clients don't understand what's going on at all.

I (and my customers) would prefer that only entry versions (drafts or published) are preserved that are explicitly saved by user action. We don't really care how the whole thing works under the hood. 😄

dennisfrank on 10 Feb 2021

👍2

@dennisfrank The next release will start listing all drafts, including drafts of published entries, when you select the “Drafts” status on the Entries index page (see https://github.com/craftcms/cms/issues/7517#issuecomment-776363856), which means it will be easier to bulk-delete the drafts you don’t care about. And going forward authors will be able to quickly discard drafts they don’t want via that “Delete it” button, which should help avoid getting back into that situation.

brandonkelly on 10 Feb 2021

Agree that it is about communication, so want to add that we had some good experience with giving some feedback when a draft
was created in live preview, something like

if (window.draftEditor) {
    window.draftEditor.on('createDraft', function() {
        if (window.draftEditor.isPreviewActive()) {
            var draftName = window.draftEditor.settings.draftName;
            Craft.cp.displayNotice('A new draft ' + draftName + ' was created for your preview edits');
            $('.lp-editor-container header').append('<div style="margin-top:6px;"><b>New draft for preview edits: ' + draftName + '</b></div>');
        }
    });

}

wsydney76 on 10 Feb 2021

@wsydney76 Good to know. That’s similar to what I’ve done. I’m also accounting for the possibility that the draft was created as a prerequisite of opening Live Preview (if changes had already been made beforehand), and I’m holding off on notifying them until LP is closed, but the general effect should be the same.

brandonkelly on 10 Feb 2021

Craft 3.6.5 is out now with that change ✨

brandonkelly on 10 Feb 2021

👍1

Thank you for that change. But I have some comments:

On that note, I think the biggest issue we have right now is not the behavior, but the communication.

I have to disagree with this.
Communicating on something that doesn't make sense functionally but is needed technically is not the answer. And Live Preview creating a draft is that kind of issue. It is just NOT what the author asked for. Simple as that.

Don't add to the author's work by asking him if he wants to keep a draft he didn't ask for initially.
This overhead add up real quick.

As @mmikkel said it best:

Craft shouldn't change the context; if they're previewing the current entry, any edits should (at least transparently appear to) apply to the current entry, not a draft that the author didn't ask Craft to create

Which brings me back to the fact that if auto-saving is required for live preview to work, it should be transparent to the author. Add a flag to that kind of draft and never show it to the author. And purge them as soon as they are not needed anymore.

This is actually how it worked when 3.2 first launched with the new draft system, and it wasn’t well-received (e.g. #4549)

This is not (in my view) what was wrong with 3.2.
The issue says it best, what was wrong in 3.2 was what is now still wrong with live preview. That auto save meant auto draft. You decided to remove the auto save feature then (removing auto drafts at the same time) to answer the issue, but kept it for live preview because it was technically required.

This caused 1/ this issue and 2/ a dichotomy in how live preview works compared to just view (where we need to save explicitly before viewing).

What I say is this:

auto-save was fine, and should be re implemented when editing a current entry (even when not in live preview)
auto-drafts (that are technically required by auto-save) should be hidden from the user and purged immediately
even the green checkmark should be hidden on auto-save as it could confuse the author as to what happens ; we should have something more appropriate like a "you have unsaved changes" alert - maybe even adding actions like "discard/save as draft/save entry"
auto-save should only be the technical requirement that allows live preview and view to work seamlessly (and in the same way) ; the changes in the current version still would need to either be discarded (default) / saved as draft (explicitly) / or saved. We shouldn't jump context to a draft that again nobody asked for. Nor should we ask the author if he wants to keep a draft he never asked for.

I'm really sorry @brandonkelly if I give you the impression to be insistant on this issue, it is just that I feel this is important, it is part of the process an author goes through, and it should be very clear.

As you best said it:

Good design is clear about what it is and what it’s doing

This is not solely about communication.
This is about what makes sense and what is predictable for the author without having to explain it or asking more actions from him (like clearing out unused drafts that shouldn't have been created in the first place).

As it stands (3.6.5):

What I suggest:

JeanLucEsser on 11 Feb 2021

👍5

Communicating on something that doesn't make sense functionally but is needed technically is not the answer. And Live Preview creating a draft is that kind of issue. It is just NOT what the author asked for. Simple as that.

They asked to see what their content changes look like on the front-end. Which requires saving those changes to a draft first.

Don't add to the author's work by asking him if he wants to keep a draft he didn't ask for initially.

We are simply asking if they want to keep their changes or discard them. I wouldn’t consider that “work” any more than being forced to answer the confirmation dialog when you are leaving/closing an Edit Entry page with unsaved changes.

auto-save was fine, and should be re implemented when editing a current entry (even when not in live preview)

We can’t auto-save against the Current revision without overwriting the live entry content. Hence, drafts.

auto-drafts (that are technically required by auto-save) should be hidden from the user and purged immediately

If they are discarded immediately, then what’s the point of auto-saving them in the first place?

What I suggest:

“Current w auto-saved changes” is just a draft by a different name.

I’m sorry but I fundamentally disagree that we should pretend a draft doesn’t exist when it does.

One of the main reasons is because it eliminates a stress case: what happens if the browser crashes? If the author happened to be editing a draft, they don’t have to worry—they know the changes were saved.

brandonkelly on 16 Feb 2021

Thank you for getting back and pursuing this conversation.
I know you have tons of others issues to work on, so sincerely, thank you.

They asked to see what their content changes look like on the front-end. Which requires saving those changes to a draft first.

Yes. But they didn't ask for a draft. This is my issue. They did not. The draft is technically required for the functionality to work. But the author didn't ask for it. It is forced upon him.

We are simply asking if they want to keep their changes or discard them.

No, you are not asking if they want to keep their changes. You are asking if they want to keep a draft, which is a concept and a context they didn't think they entered in the first place. That makes them ask "what happened ?". It is not added work per se, but it is adding confusion.

We wouldn't have this conversation if the dialog said "Discard changes or Save as draft". Even if it wouldn't make much sense for other reasons, at least it wouldn't introduce the fact that context has changed without the author expecting it to.

We can’t auto-save against the Current revision without overwriting the live entry content. Hence, drafts.

Yes I get that, that's precisely the reason I'm not suggesting you auto-save against the current revision, but that you accept that auto-saving is another concept all together. It may be similar to drafts in every aspect, except for the fact that the author shouldn't see it. It serves a different purpose, functionally.

“Current w auto-saved changes” is just a draft by a different name.

Another concept, technically similar to drafts I would say. But serving a different and specific purpose, which is NOT part of the author's conscious publishing process. You approach it at the technical level. I'm talking about the use case.

I’m sorry but I fundamentally disagree that we should pretend a draft doesn’t exist when it does.

That is why I'm NOT going to call it a draft but something else, let's give it a name, working copy? There are two very different concepts here at play, even if they are technically identical (or at least similar):

a DRAFT, which is a conscious decision on the author to create, which is a full part of the publishing process
an auto-saved version, the WORKING COPY, which is here to allow for live previewing, which is a technical requirement, which should be hidden from the author (unless you want to use it to protect the system by allowing auto recovery after a crash), and which should be regularly purged from the system (say after every successful save action)

(Of course when editing a draft, we don't need a working copy of it.)

I'd love to have @mmikkel (and others) input on these two concepts.

I'm not giving up (yet!) ;)

JeanLucEsser on 16 Feb 2021

You are asking if they want to keep a draft, which is a concept and a context they didn't think they entered in the first place.

Which is why the dialog says “You are now editing a draft.” The purpose of that message is to notify them that something happened (understanding that they may not have expected it), and to reorient them around that.

We wouldn't have this conversation if the dialog said "Discard changes or Save as draft". Even if it wouldn't make much sense for other reasons, at least it wouldn't introduce the fact that context has changed without the author expecting it to.

That would be far worse IMO, considering that the draft has in fact already been created. If that’s not clear, and we simply ask if they wish to “Discard changes” or “Save as a draft”, it would lead to confusion as to _why_ Craft is forcing them to make this choice between two undesired choices. _“I just wanted to close Live Preview…why do I now have to choose to discard all of my work, or create a draft? Can’t I just keep editing my content??”_ feels much more annoying to me than being told that a draft has _already_ been created for me, and giving me the option to continue editing it or discard it.

That is why I'm NOT going to call it a draft but something else, let's give it a name, working copy? There are two very different concepts here at play, even if they are technically identical (or at least similar):

If we were to do this, they would in fact be technically identical to drafts, and stored as drafts, perhaps with a boolean column to keep track of the fact that they were implicitly created. So again, they would just be drafts by a different name. Which, again, I’m not a fan of.

brandonkelly on 16 Feb 2021

Which is why the dialog says “You are now editing a draft.” The purpose of that message is to notify them that something happened

Which doesn’t change the fact they didn’t ask for this. They asked to live preview content. They don’t care if a draft needed to be created in the background for that to work.

That would be far worse IMO

I was talking conceptually, not in the context of this issue. In general if you want to ask a user if he wants to keep changes, you ask a question around that (discard / save) and eventually add an option to change context (save as ...). You don’t ask a question around a concept they didn’t expect, and you don’t add a dialog to explain said concept to ease with the fact that you didn’t actually design around it.

If we were to do this, they would in fact be technically identical to drafts

Yes they would.

You say:
- technically they are drafts, so let’s treat them as such, like any other drafts
I say:
- conceptually they are VERY different, because the intention of the author behind their existence IS different

Looks like we won’t agree on this. Hope you’ll share the idea with the team or other members / clients.
My previous schemas tell the story. Keep them somewhere eventually.

Thank you for listening ;)

JeanLucEsser on 16 Feb 2021

👍2

@brandonkelly

I am joining this conversation after a brief exchange in the chat today.

I would like to sidestep the deep dive on the mental model of edits and drafts and request an improvement in UI/UX based on the current draft structure.

As of today / craft 3.6.6:

Editing on the edit screen waits for an explicit Save / Publish action to apply edits
Switching to Live Preview screen autogenerates a draft (in order to display the preview).
Exiting the Live Preview displays a modal forcing the editor to keep the new draft or discard it.
If the editor switches between Live Preview and Edit mode after a draft has been created in this editing session, no further drafts get autogenerated - the current one gets updated until the session is over, the draft is published, or deleted.

I understand that 3 was created in response to the accumulation of autogenerated drafts (I imagine a scenario where editors make changes in Preview mode and don't publish them?)

The modal

Informs the editor that a draft was created
Forces the editor to make an explicit choice to keep it or discard it, thus presenting every single edit made in preview mode with the choice to throw away their edits.

Discarding one's edits is a costly high-risk action if made by mistake and that the risk and confusion do not equal the convenience of avoiding the accumulation of drafts.

Interrupting a flow to confirm a costly or risky action like making a payment or deleting something important is common and accepted UX. Interrupting a flow to present a risky action is I think unusual and increases risk as it normalizes the risky choice.

Is the scenario of discarding all edits made in preview mode so frequent that it calls for forcing the choice after every single edit made in preview mode? Is it so necessary as to present the costly option to mistakenly throw one's work away as a 1-click option?

This is extraordinary behavior and not the norm in any workflow I've participated in or witnessed. It is stressful for me to know this is suddenly presented to all my editors, some of who barely navigate the system and don't really know what draft is.

My clients know to click preview -> make their edits -> go back -> publish. This converts the autogenerated draft into a current version. Now they get presented with the option to throw away their work as if it is a very common and useful choice - and some will choose it, losing work.

Is there a way to indicate the autogenerated draft the first time Preview gets closed without forcing a choice? A "softer" notification?

Maybe something as simple as defaulting to an open tooltip for the draft mark with

"Your changes were saved in a new draft"

Screen Shot 2021-02-18 at 1 19 23 PM

Proximity to the dropdown menu with the word "Draft" in it prompts where the possible actions are.

Screen Shot 2021-02-18 at 1 19 23 PM

Another possibility helping with unwanted drafts. Given that a new draft is created by switching to Preview, even without making edits... Would auto-deleting such a draft without edits on "exit preview" prevent the accumulation of unwanted drafts?

andreimoment on 18 Feb 2021

👍2

I'm with @JeanLucEsser on this one.

MattWilcox on 18 Feb 2021

I also would like to present my thoughts here. I will just copy what I just posted on Discord in response to Brandon's questions about the proposed "preview-draft":

First of all let's start like this:
The author makes edits in Live Preview. The auto-draft gets saved in the background (let's call it preview-draft). The author remains in the entry editing mode, and the "header" should be something like the attached image:

What if they leave the edit page after the preview-draft is created:
If you can intercept the exit navigation you display a modal 'You will loose unsaved changes: "Exit anyway", "Remain on this page". If the choose "exit anyway", then delete immediately. If they leave and you can't intercept it, delete via garbage collection at a later time.

If they accidentally left and return
They will either see the same screen (unsaved changes), or they will lose the changes if garbage collection has occurred. (In my experience if someone spends a lot of time making changes, they will either save the entry, or create draft, not just leave, especially if we have those warnings and notifications).

What happens if there’s more than one, because on more than one occasion they’ve gone back to Current and clicked Preview?
Well, just see the previous point. So, there can not be more than one. (Note: The "preview draft" will be tied to only one author and not be visible to others)

What if the source entry is updated after the auto-save is created?
Not possible by the same author, according to previous answers. If another author makes changes, yes, show what has been changed by the other author.

What if they want to save the changes as a draft? It's already one, technically. How is that option presented?
See attached picture

What if they just want to delete it, discarding their changes?
See attached picture.

Bonus question: What if they go from the index directly to a draft and from there choose to go to the "current" version via the dropdown?
Show the "unsaved changes" view. (Which anyway should be a rare occasion. The entry will either have been saved, the "preview-draft" converted to a regular draft, or the changes discarded.)

Note: In the attached design, notice that the "versions" dropdown is disabled and only shows the "unsaved changes" label. Also, maybe in this screen the "view" button, when clicked, should open a HUD with the options "view live version", "view with unsaved changes".

thupsi on 19 Feb 2021

@andreimoment

I'm with you on the fact that as it is, the modal is the wrong way of handling our issue.
But I don't think we can "sidestep the deep dive on the mental model of edits and drafts".

We have to answer a very simple question first:
Should drafts created by the system for technical reasons should be considered the same as drafts consciously created by the author, whatever the communication we put in place to inform the author of what happened ? Again, I say no.

Changing context should be a conscious and/or PREDICTABLE action.
Live preview drafts are neither.

@brandonkelly

@andreimoment said:

This is extraordinary behavior and not the norm in any workflow I've participated in or witnessed. It is stressful for me to know this is suddenly presented to all my editors, some of who barely navigate the system and don't really know what draft is.

This is what I meant by added work on the author, which I then presented as added confusion. @andreimoment puts it in better words here. It is indeed stressfull.

@thupsi

I like your approach (a lot), it is very close to what I draw in my schema in one of my previous answers, and I was about to post a picture for the new header that kind of ressembles yours. Are you actually living in my head? ;)

What IS actually different in my approach:
I don't link what you call preview-draft to entering the live preview state.

First, vocabulary (for the sake of this comment):

draft: consciously created by the author (via save as draft)
unsaved-draft: created by the system

I go for simplicity. From the moment you start editing an entry (current), you generate an unsaved-draft. This is transparent to the author, from his POV he's still editing the current version. There can be only one unsaved-draft (per author) as it serves for all unsaved edits.

From the moment an unsaved-draft has been generated, we could disable the versions dropdown and show unsaved changes as a label. I wouldn't do that though. I think we could still be able to navigate all versions. When selecting current again, it shows current with the unsaved-draft applied. (I think your design is essentially space conscious - for adding the label - more than really wanting to disable the dropdown ; make that header two lines, the entry title is already too short in the current design)

The rule is simple: unless we left the entry's edit page, the browser crashed, or we discarded the changes, current always shows unsaved-draft if it exists. If concurrent edits from multiple authors (there is actually one unsaved-draft per author), well last to save its changes wins...

Communicating to the author is still of vital importance, so a label saying "unsaved changes are pending" along with the 3 options that make sense (discard / save as draft / save) should be put in place. Discard only exists because of unsaved-draft, if we didn't make edits, the option shouldn't be enabled.

Leaving the edit page without saving or discarding should be intercepted and the 3 actions should be presented (discard and leave / save as draft / save). Or alternatively (discard and leave / keep working) with a text that says "You have unsaved changes pending. You can save them, save them as a draft to get back to them later or discard them".

Quitting the page unexpectedly (crashing, closing the browser) would be the only scenario where an unsaved-draft still exists for a current entry and an author. We can garbage collect it (24 or 48 hours?). And put a mechanism in place so that if it wasn't garbage collected yet, we offer the option to recover unsaved changes when next editing the entry.

Also, maybe in this screen the "view" button, when clicked, should open a HUD with the options "view live version", "view with unsaved changes".

Preview and view are part of the same button group. We should expect to see the same content from them which is not the case actually. A HUD for view could make sense, yes. But I bet the author making edits wants to see its edits, not the live version. The live version could still be easily accessed via a globe icon next to the slug.

If current, view shows the current/live version.
If current with unsaved-draft, view shows the unsaved-draft.
If draft, view shows the draft.
If revision, view shows the revision.
And at anytime you can see the live version via a globe icon in the slug (same as in the list view).
BTW, it would then be more like Live/New window than Preview/View. Maybe make it a single Preview button (with the View button being just an open in new window icon). When multiple live previews are available, use that new window icon for each option available.

JeanLucEsser on 19 Feb 2021

There is actually one more instance in which an unsaved-draft is discarded: if a draft (or revision or trashed) has been promoted to current (published or restored), either from this author or from another one, all unsaved-drafts (for all authors) are discarded. This is a freshly published current entry, should be virgin of all pending changes.

JeanLucEsser on 19 Feb 2021

@JeanLucEsser I haven't had time to digest your latest comments, but it seems indeed that your proposal is close to mine.

The only thing that I'm not sure about is keeping the versions dropdown enabled. Maybe that would lead to complications. For example: What happens when the author, having created an auto-draft, goes to a revision and creates another auto-draft? Does it overwrite the first one? Sure, we could warn him when he opens the versions dropdown that he might lose his changes, but I think that would not be so elegant. Anyway, just thinking out loud here :)

thupsi on 19 Feb 2021

@thupsi

The only thing that I'm not sure about is keeping the versions dropdown enabled.

The versions dropdown shows:

currents (for each site) - each current is independent and has its own unsaved-draft per author
drafts - by definition, drafts do not need unsaved-drafts
revisions - which cannot be edited, only restored so no need for unsaved-drafts

There is also the trashed entries, which as for revisions can only be restored

As I commented just before your last reply, promoting a draft, revision or trashed entry to current (in other words publishing or restoring) would purge all pending changes (unsaved-drafts) on the "previous" current for all authors. We are explicitly saying in those cases "this is the new, fresh current version I want". Publish / Restore is a strong action.

Anyway, this is just cherry on the cake. I wouldn't mind if we disable the dropdown. I just think it would force the author to either discard or save just to see another version. Which could be avoided.

We still agree on the bigger picture.

JeanLucEsser on 19 Feb 2021

@JeanLucEsser
You are right, I didn’t realize that revisions can not be edited. Which, of course, would not make sense, now that I think about it.

So, yes, the versions drop down should not be disabled.

We agree completely ;)

thupsi on 19 Feb 2021

I'm also a fan of the suggestions from @JeanLucEsser FWIW.

Should drafts created by the system for technical reasons should be considered the same as drafts consciously created by the author, whatever the communication we put in place to inform the author of what happened ? Again, I say no.

I think herein lies the real solution. For the sake of this discussion at least, I think it'd be fruitful to refer to this with a separate name, as things gets conflated when everything is called "Draft". @JeanLucEsser suggested "Working copy", and I think that is the best one yet. Let it technically be a "Draft" behind the scenes if that makes it easier for the P&T team, but let's give the _concept_ a separate name.

I might be dumbing everything down now, but.. If live preview and the edit entry form/screen only ever showed your current "Working copy" (and why wouldn't they, that already work with drafts), I don't really see that there's a need for all these changes to the UI.

In my mind, there's something wrong with the way autosaving works today in terms of the behaviour of unpublished drafts and published drafts (ie, entries). It doesn't make sense that a draft always autosaves, and an entry doesn't. I should be able to work on a draft the same way I do with entries, and if I want to hack around in my draft and then discard my changes, I should be able to do that, I'm not. So for a second, let's pretend that recovering autosaved content (this is what most of the questions in @thupsi reply to @brandonkelly touches on) is not a priority, and get back to that later.

So, in my naivety, this is how I envision a system with the concept of "Working copy" would work:

1) I click "New entry" in a section. With the changes in 3.6 I always start with an unpublished draft, which I think is totally fine. But based on some of the feedback from Discord, maybe I can configure on the section settings whether or not the default should be published (ie, an "Entry") or unpublished. Currently, the only thing that has been created in the database, is a "Working copy".

2) You add some content, which is autosaved to the "Working copy". You switch to live preview. What's shown in the live preview is now the "Working copy" which for all intents and purposes works like a draft does today. You make some changes, they are saved to the same "Working copy". The preview looks nice.

3) You switch back to the entry edit screen, what is shown in the fields is the contents of your "Working copy". You edit some more. The only thing that is still saved in the database is your single "Working copy".

4) You now decide to save your content. Since I'm in a section that is set to have unpublished drafts as default, the main action is "Save draft". This saves my "Working copy" as a new draft in the database. If it was a section that was set to publish by default, the main action would be "Save entry", and the same thing would happen, but now with a published entry being saved.

5) I continue editing. These are saved to my "Working copy". There is still only one "Working copy" in the database. I can now choose "Save draft" again to update the draft I created in step 4, or for instance choose "Save as new draft", which creates a new draft.

6) When I'm done editing and want to make my content available publicly, I select "Publish draft", which creates a new "Published draft"/"Entry"/"Current" (i like "Current", will use that from now on). All is good.

7) I come back to the entry at a later point, wanting to make some simple edits. When I enter the entry edit screen, a new "Working copy" is created, based on "Current". I make some edits, they are automatically saved to my "Working copy". I switch to live preview, it shows a preview of my working copy. I switch back and hit cmd-s, which is "Save entry" now since I'm on a published draft, and "Current" is now updated with my "Working copy" and a revision of my old "Current" is saved.

8) Some time later I want to do some major changes to my entry. I enter the entry edit screen, and a new "Working copy" is created for me. I make changes, add content, live preview, etc. All within my autosaved "Working copy". By a mistake I click somewhere in the main menu, and Craft prompts me with "You have unsaved changes, are you sure...". I click "Nope, that was a mistake". I'm still at the entry edit screen, working on my saved "Working copy". I decide to take a break and come back later, so I choose "Save as new draft" from the actions. A new draft is created, based on my "Working copy". All is good, I'm off.

9) The next day I decide to continue working on my draft. I click to edit my entry. My "Working copy" is now "Current". I select yesterdays draft from the draft dropdown, and "Working copy" is now updated with the contents of the draft. If I'd made changes to my "Working copy" when I still was working with "Current", I'll get the same prompt as in step 8. I can choose either to abort and continue working on "Current", or discard my "Working copy" and continue to work on my draft.

This is what would make sense for me as an end-user. At every step, Craft responds clearly to my intent, and there is no need for any new status messages or dialogues.

Now, in terms of recovering content that was autosaved, ie it has been saved to your working copy but the computer crashed, you clicked the wrong button in the dialogue, or something. @JeanLucEsser suggested that there was only ever one "Working copy" per author, but I'm thinking there're more factors that make up one unique "Working copy". Maybe it's tied to draft/entry _and_ author. In which case Craft could check if a "Working copy" exists for a given entry/draft when opening it, and prompt the author if he want's to continue work on it, discard it, or save it as a new draft. This could be a dialogue box very similar to the one you get if you try to upload an asset and a file with that name already exists.

So, what scenarios did I miss? I'm sure there are some.

aelvan on 19 Feb 2021

❤3

@aelvan

Ok, this is something else actually as you consider the concept of working copy to always be the one which is "edited", be it the current entry or the draft. My first thought is that it adds confusion. Think "I'm working on my draft" or "I'm working on current" versus "I'm working on a working copy which has been updated by the draft I just selected". Ok maybe I'm over reacting but still.

Plus I'm not sure we should add to the confusion by having sections that do not behave the same way as far as "starting new as a draft" is concerned. Maybe we could add an action that says "Publish and close" as for simple entries this is today a two step action (Publish, then Save).

Maybe I need to take the time to think twice about your proposition. It is interesting for sure.

My proposition does not try to change the publishing process:

Start as Draft
Publish as Current
Edit Current (auto saved working copy)
Save Current
Edit Current (auto saved working copy)
Discard changes
Edit Current (auto saved working copy)
Click else where
Intercept and ask to Discard / Save as Draft / Save
Save as Draft
Keep Editing Draft (no notion of working copy, it is already a draft)
Quit
Come back
Select Draft to keep Working on it (no notion of working copy, it is already a draft)
Publish as Current
Edit Current (auto saved working copy)
Crash browser
Come back to the entry (Would you like to try and recover your last edits?)
Yes - Keep editing
Save
...

Working copy was just a name in my proposition. Later I called it unsaved-draft which can be found to be more appropriate because it is kind of a temporary draft with unsaved changes, which life depends on wether those changes will be saved, discarded or saved as an actual draft.

JeanLucEsser on 19 Feb 2021

@JeanLucEsser

Think "I'm working on my draft" or "I'm working on current" versus "I'm working on a working copy which has been updated by the draft I just selected". Ok maybe I'm over reacting but still.

Well, in my mind, the concept of the "Working copy" should be transparent to the end-user, so I think the user would still think in terms of: "I'm working on content that has not yet been saved", "I'm working on a draft" and "I'm working on a published draft/live content/current".

I think the first status is highly underrated. Even though there are services where you don't need to save content, it just always updates and is there, I don't think that's the expectation of the average user. And, that it's a feature to actually being able to discard things you don't want to save.

Plus I'm not sure we should add to the confusion by having sections that do not behave the same way as far as "starting new as a draft" is concerned.

This was just a response to several people on discord last night wanting to remove the draft system all-together because the couldn't see the point of having it, because the type of content they created should always be published. As I said, I actually like this aspect of the new 3.6 functionality, so I'm all for having that. But I also think that, conceptually, starting off with a "Working copy" with a state that indicates whether or not it will be a published or an unpublished draft when it's saved with the default action, is a very minor cognitive disruption. It would be identical to whether or not you clicked on a draft or a published draft/entry in the entry index. When you open up the edit screen, you're either working with published content, or not.

Working copy was just a name in my proposition. Later I called it unsaved-draft which can be found to be more appropriate because it is kind of a temporary draft with unsaved changes, which life depends on wether those changes will be saved, discarded or saved as an actual draft.

I find "unsaved-draft" more confusing because it is... saved? :D But, doesn't matter what we call it.

I guess the only thing I'm proposing that changes the current workflow is that changes are no longer saved automatically to an actual draft when you're working on one. I see this as a good thing. In terms of loosing content, I think there's a bigger chance that users will loose content the way it works now, when there's no way to discard your changes if you're working on a draft. So if you're editing a draft, changing content, testing stuff, and then change your mind and want to go back to the draft as it were before starting to edit, you can't. But for published drafts/entries it's the other way around. I find this extremely confusing.

aelvan on 19 Feb 2021

@aelvan

Well, in my mind, the concept of the "Working copy" should be transparent to the end-user

So that's not different than what I say. I feel you approach the issue from a technical perspective by saying the concept is transparent to the user but behind the scene we are working on an object from the db which is a working copy.

And, that it's a feature to actually being able to discard things you don't want to save.

That's what the action Discard is for. Unless I misunderstand what you mean. We are working on current, it has auto saved but unsaved changes, we can discard those changes (rollback) or save them. And this auto saved version allows for not loosing content, and even recovering it in case of a crash. I'm not sure I see what's different in your approach.

But I also think that, conceptually, starting off with a "Working copy" with a state that indicates whether or not it will be a published or an unpublished draft when it's saved with the default action, is a very minor cognitive disruption.

I think this could be argued and dealt with in a separate issue.

when there's no way to discard your changes if you're working on a draft.

I don't get it. If you're working on a draft there is no reason to discard your changes. It is still a draft. Having the concept of working copy on drafts would be equivalent to having draft's drafts. Or I missed something.

So if you're editing a draft, changing content, testing stuff, and then change your mind and want to go back to the draft as it were before starting to edit, you can't.

Yes that's what I thought. You want to be able to rollback changes on drafts. For me the point of a draft is to be linear, you don't "go back". It would be too much confusion.

But for published drafts/entries it's the other way around

There is no such thing as a published draft. If it is published, it is not a draft anymore. And discarding small experimental changes on a published entry makes sense in a way that doing the same on a draft does not. A draft is, well, a draft. If you really want to have an history of the changes for your drafts, then the best way of doing it would be to introduce revisions for drafts. It is a known concept. Explicitly Saving a Draft would create a new Draft revision. It would be even way more powerful than just discarding changes on a draft. But that should be for another issue.

I am not confused at all to have a "unsaved changes" label with a Discard action on current and not having it on drafts. But I may be wrong.

JeanLucEsser on 19 Feb 2021

I think there's a bigger chance that users will loose content the way it works now, when there's no way to discard your changes if you're working on a draft.

Drafts are auto saved. How could we loose content? And how having a way of discarding your changes on drafts would help not loose content?

[Edit] Oh, you mean loosing content as in loosing the previous version of the draft you're working on? Well, that's drafts. Maybe we could allow for a "Save as new draft" action alongside the "Publish draft" one? So that if you want to work on another version of your draft you can. And then switch between two drafts. Why not (not convinced though, would prefer revisions). -> new issue.

JeanLucEsser on 19 Feb 2021

So this is starting to feel like a (very) long issue.

In short:

The latest implemented changes in 3.6.5 didn't address the issue from my POV so I expressed my concerns here:
https://github.com/craftcms/cms/issues/6681#issuecomment-777480599

@brandonkelly and I argued a little and we didn't agree.

Then @thupsi weighed in with something very similar to what I proposed and illustrated it with a header here:
https://github.com/craftcms/cms/issues/6681#issuecomment-781915194
That I commented here:
https://github.com/craftcms/cms/issues/6681#issuecomment-781974025

We argued a little and finally agreed completely on a solution ;)

Then @aelvan came in and proposed something similar but promoting the concept of working copy to encapsulate current and drafts, so that changes could be discarded on drafts as well:
https://github.com/craftcms/cms/issues/6681#issuecomment-782055479

We argued a little and we still do (spoiler alert, I'm not convinced - yet!) ;)

But we all seem to agree that the issue is not "closed".
That should make it simpler for newcomers to follow along.

JeanLucEsser on 19 Feb 2021

_UPDATE: Edited based on feedback._

Been thinking this over and there might be some middle ground.

Here’s what I think I’ll do (borrowing from ideas suggested by @JeanLucEsser, @thupsi, and @aelvan):

Immediately after you begin editing the Current revision—whether from the normal edit page, or within Live Preview—an _Autosaved Draft_ will be created with those changes. It replaces “Current” in the revision menu, labeled as “Autosaved changes”, and styled a bit differently to indicate that it’s a bit of a special state.
In most ways, this Autosaved Draft acts just like any other draft:
- It will continue to be updated as additional edits are made.
- It is persistent, not ephemeral.
- If the Current revision is updated after it was created (either from another author, or because the current author published one of their drafts), any fields/attributes that are out of date in the Autosaved Draft will say so, and give the author a chance to merge those changes in.
There are a couple important ways that it’s different from other drafts, though:
- Only one Autosaved Draft can exist per entry/author.
- Authors will only be able to view their own Autosaved Draft.
- The primary action button will be “Publish changes”.
- Secondary action buttons will include “Discard changes” (red) and “Save as a draft”.
The Current revision will be inaccessible to the author so long as the Autosaved Draft exists. If the author leaves the Edit Entry page and then returns to it later, the Autosaved Draft will be loaded in place of the Current revision.

brandonkelly on 19 Feb 2021

👍4

I like your thinking here @brandonkelly. It makes a lot of sense.

But there is so much to digest from this issue that I feel this could have a (short) beta period, maybe in a 3.x. Or a 3.6.x with one (or two) betas? What do you think?

JeanLucEsser on 19 Feb 2021

Yeah I’m thinking 3.7.

brandonkelly on 19 Feb 2021

👍2

I also like your proposal @brandonkelly. Actually this is why I put the 'unsaved changes' label inside the dropdown, it was meant to replace 'current'. I didn't communicate this because I got sidetracked with the disabled state of the dropdown.

I pretty much agree on most of the things you describe, at least the important stuff. Also agree about the beta period. Great!

thupsi on 19 Feb 2021

It is kind of weird though that an 'autosaved draft' can be 'saved as a draft'. Ok ok, I'll shut up now, haha 😂

thupsi on 19 Feb 2021

👀1

Eh true. Maybe it’s just labeled “Autosaved changes”. 😔

brandonkelly on 19 Feb 2021

Or "Pending draft/changes"? Yeah right, a French guy that tries to label English stuff... haha! Sorry

JeanLucEsser on 19 Feb 2021

@brandonkelly

If I understand it correctly, what you're proposing is keeping the behaviour of drafts as it currently is, with its current autosave capabilities and everything? This new "Autosaved draft" is something that only exists on top of a "Current revision"?

I'm totally ok with letting "Working copy" go, I didn't even realise it's a git concept. :) I think it's a good idea to go with something like "Unsaved changes", "Pending changes", "Autosaved changes", etc. More than anything, this is a _state_. I wrote earlier:

so I think the user would still think in terms of: "I'm working on content that has not yet been saved", "I'm working on a draft" and "I'm working on a published draft/live content/current".

I want to revise that. What we have is two binary options:

1) "I'm working on a draft" / "I'm working on published content"
2) "My changes has been saved" / "I have unsaved changes"

The first are different features of Craft that the user is working with. The second are two different states the user can be in when working with these features.

If you propose to keep the drafts system as-is, it means that there is in reality no state for drafts, "My changes has been saved" will always be true. Whereas for published content, there can still be these two states, and the "Autosaved draft" represents the "I have unsaved changes" state. So calling it "Unsaved changes", "Pending changes" or something makes more sense.

This is a lot better than the current system. It's _more_ consistent, and you're not thrown out of one feature and into another just because you decide to open live preview. I still think there's a cognitive disconnect in the fact that the behaviour is different depending on the fact that you're working on a draft or a current revision. But, it's a lot closer than before.

One question though, why do you want this to be something that's persistent and visible to the user? What are the benefits?

Also, if the draft autosave thing is going to work like before, I would personally prefer to just opt out of the whole draft system, and go back to using status to keep things "unpublished" until I'm done working on my content. It's a much more straight forward publish workflow, as echoed by several people on the discord yesterday. Do you feel like there's an opportunity to have this as a setting per section with the changes you've now proposed?

I guess what I'm suggesting is just that when you click "New entry" and start working (on a draft), the default action should be the same as "Publish draft" is today. Although it would make more sense if it just says "Publish changes" straight away, so that it's the same as the next time you save. This way we could imitate the way our clients have always used Craft by bypassing the different workflow that drafts represent.

aelvan on 19 Feb 2021

One question though, why do you want this to be something that's persistent and visible to the user? What are the benefits?

Two reasons:

It’s comforting to know that your work is already saved in some state, and it’ll survive a browser crash, etc.
It’s important to be honest with the author about what’s going on. As I mentioned earlier, “good design is clear about what it is and what it’s doing; the more insight an author has into what’s happening, the more effective they’ll be at using the tool.”

Also, if the draft autosave thing is going to work like before, I would personally prefer to just opt out of the whole draft system, and go back to using status to keep things "unpublished" until I'm done working on my content. It's a much more straight forward publish workflow, as echoed by several people on the discord yesterday. Do you feel like there's an opportunity to have this as a setting per section with the changes you've now proposed?

I guess what I'm suggesting is just that when you click "New entry" and start working (on a draft), the default action should be the same as "Publish draft" is today. Although it would make more sense if it just says "Publish changes" straight away, so that it's the same as the next time you save. This way we could imitate the way our clients have always used Craft by bypassing the different workflow that drafts represent.

We should probably re-identify unpublished drafts (what you get when you first click “New entry”) as Autosaved Drafts (however they end up getting labeled), rather than normal drafts. At which point it would make sense for their buttons to mimic Autosaved Draft buttons, so the primary action would be “Publish” rather than “Save draft”.

At that point, we’re basically back to a pre-Craft 3.2 entry publishing workflow:

Click “New entry” → taken directly to an Autosaved Draft, with primary “Publish” button
Click “Publish” → now the entry is published (regardless of whether it’s enabled).
Go back to the entry from the Entries index → taken to its Current revision
Start editing the entry (either in normal view or within Live Preview) → “Current” replaced with “Autosaved draft”, but primary button is still “Publish changes”.
Click “Publish changes” → Current revision is updated with published changes.

…with the added benefit that your changes are always autosaved somewhere.

I don’t think we would go further and let you disable the entire (manual) draft system, as it would already be 100% opt-in at that point. If an author doesn’t want to take advantage of working in drafts, they just won’t click the “Create a draft” button.

brandonkelly on 19 Feb 2021

Even if "autosaved draft" accurately describes how the feature is implemented under the hood, I'm fairly certain that the concept of "unsaved changes" would be _a lot_ more intuitive to authors. In fact, I think that in not labelling these things "drafts", both concepts (i.e. real/saved drafts vs. autodrafts) would probably become much clearer.

mmikkel on 20 Feb 2021

👍5

@mmikkel Yeah you may be right about that.

brandonkelly on 20 Feb 2021

👍2

@brandonkelly With the new "Discard Changes" concept, I can see users potentially being confused about what all will be discarded. Assuming that a user jumps back in to edit a post that already has one of _their_ auto-saves, they might think that discarding changes will only be things they changed since they started making edits again. This should be clear to avoid loss of content. Just a lot of different concepts here for our editors to understand, each with slightly different behavior and implications.

jsunsawyer on 22 Feb 2021

@jsunsawyer When you revisit an existing autosave, it will show you exactly which fields have been modified (as drafts already do), so I suspect that will help.

brandonkelly on 22 Feb 2021

@brandonkelly @mmikkel

Even if "autosaved draft" accurately describes how the feature is implemented under the hood, I'm fairly certain that the concept of "unsaved changes" would be a lot more intuitive to authors. In fact, I think that in not labelling these things "drafts", both concepts (i.e. real/saved drafts vs. autodrafts) would probably become much clearer.

Wouldn't these be "Unpublished changes"? - they do get autosaved and I can see them if I leave and come back. Or, "Work in progress"? The most appropriate language may emerge from conversations with editors.

Related to the thread, beyond the quote above:

It is my sense that we are basically moving away from implicit draft creation. The system will now prevent me from losing work by saving my work in progress, but if I want to save a "Draft" that would be an explicit action. A step toward a simpler mental model!
But now, I can't see other editors' work in progress, unless they explicitly save it as a draft. This may actually be a plus. Having an explicit training with editorial staff in when and why they'd create a draft is a good thing.
I can't see the Current version unless I dispose of my work in progress - not sure about the benefit of this? I may want to access the current version to reference existing content in order to revert it in my work in progress copy.

I see there's a lot of work being done here and definitely progress.

Would it be useful to do a few user interviews with the new functionality? I can volunteer doing 2-3 15-20 min interviews and sharing them with pixelandtonic privately, while this is in beta or alpha.

andreimoment on 22 Feb 2021

Wouldn't these be "Unpublished changes"? - they _do_ get autosaved and I can see them if I leave and come back. Another option - "Work in progress". The most appropriate language may emerge from conversations with editors.

I’m open to playing around with the wording during the beta. We’ll see what works best.

3. I can't see the Current version unless I dispose of my work in progress - not sure about the benefit of this? I may want to access the current version to reference existing content in order to revert it in my work in progress copy.

Originally I was thinking it would be good to go back to the Current revision without discarding the in-progress changes, but it presents a bit of a challenge: what happens if they then start making changes to the Current revision? That would discard whatever changes they’d already made. So we’d need to either make the Current revision non-editable, or show a dialog as soon as they start editing, warning that these changes are going to overwrite the autosaved changes. Neither of those seem like good UX to me, so for now I think it’s better to just not make the Current revision accessible.

We could solve it better in the long run by adding a comparison view(#898), which could let authors see the Current revision and their in-progress changes (or a draft, or another language, etc.) site-by-side.

In the meantime, if an author wants to compare their in-progress changes with the Current revision, they’d have to save their work as a draft, which would bring the Current revision back into view.

Would it be useful to do a few user interviews with the new functionality? I can volunteer doing 2-3 15-20 min interviews and sharing them with pixelandtonic privately, while this is in beta or alpha.

We are certainly hoping the 3.7 Beta will get a fair amount of real world testing, once it ships.

brandonkelly on 22 Feb 2021

@brandonkelly That might help, but I'm assuming that most users won't reference that.

There will be instances where users are working from a previous auto-saved entry (because they aren't utilizing drafts). They might go in and start making sweeping changes to the entry via live-preview to test a concept. At this point, they'll want to discard their changes. They might attempt to do so by exiting the entry, which will result in their changes being unintentionally overridden. If they instead click "Discard Changes", all their previous updates will be lost – resulting in a confused/frustrated editor.

I know this may sound like an edge case, but this is just the type of thing I see day-to-day in our sites, so I just want to be sure that there's some thought put into this.

jsunsawyer on 22 Feb 2021

👍2

On the Current version becoming inaccessible - how would this work with multiple editors?

A: Starts edits from Current and leaves them as Work in Progress

B: Starts edits from Current and publishes them (because A is unavailable and changes need to go live)

A: Opens the entry and can see their own Work in Progress, but cannot access the Current version?

This could lead to A unknowingly overwriting B's work by arriving at an older Work in Progress save , so A would need a notification that Current has been updated since they created their Work in Progress.

It would make sense then for A to discard their WIP and start a new edit from the Current version.

andreimoment on 23 Feb 2021

@andreimoment Same way it works with drafts already:

A: Starts edits from Current and leaves them as Work in Progress

Autosaved Draft is created for author A. The draft keeps track of which fields/attributes have been edited.

B: Starts edits from Current and publishes them (because A is unavailable and changes need to go live)

The entry will remember which fields/attributes were edited in this process as well.

A: Opens the entry and can see their own Work in Progress, but cannot access the Current version?

The Edit Entry page will show which fields/attributes have been modified in the Autosaved Draft (1), as well as which fields/attributes are now out-of-date compared to the Current revision (2) and which fields/attributes were updated in both (3), with a button to merge in the latest changes (4).
Even if the author doesn’t click the button to merge in the changes, Craft will only actually replace the fields/attributes that were directly updated within the Autosaved Draft, when the “Publish changes” button is clicked.

An Edit Entry page loaded to an autosaved draft, showing how the fields reveal their current state as compared to the Current revision of the entry

brandonkelly on 23 Feb 2021

The concept of 'private auto drafts' may need some extra thoughts.

Don't let authors be unaware of other people working on an enty. Show a warning 'This entry is currently edited by xyz'.
Admins (permission?) should see and work with all private drafts.
A functionality may be needed to shift a private draft to an other editor (illness/vacation. let B finish my work, take it over from the very untalented intern, next step in a review workflow...). Or does all this require to create a 'public draft'?
Can a private auto draft be shared via 'View...' ?
Can a public draft be reverted back to a private auto draft?
Can a new 'unsaved draft' be the target of an other entries relationship field? (would be useful for simulating batches #6987)
Wording: Make it translatable, so it can be adjusted to the clients specific needs https://github.com/craftcms/cms/issues/5661#issuecomment-588980870
Would solve #6921.
Make my pending auto drafts easily accessible, i like the way it is done here with a drow down at the top toolbar:

(except for 'unsaved changes', which is simply not true. Not so easy to distinguish two drafts concepts as it may first appear)

wsydney76 on 23 Feb 2021

I think @jsunsawyer, @andreimoment and @wsydney76 raises some important issues, which in my mind comes back to _how persistent_ "Autosaved drafts/changes" is perceived by the authors. If it ends up being treated as the primary way to save work that's not yet done, something's wrong. Not sure if that'll be the case when it's all implemented, but I think this is the pressure point when it comes to the naming and UI changes.

_Edit:_
And, not to flog a dead horse, but the completely opposite end of the spectrum in terms of UI, would be to keep the unsaved changes completely transparent from the author. Use it for live preview and the technical aspects for which it's needed, and the only point in the publish-workflow where the author has to interact with the fact that they exist, is if they return to an entry that have unsaved changes (which would only happen if they exit the edit screen without responding to the "You have unsaved changes, are you sure..."-dialogue). Upon which they're prompted if they want to recover their unsaved changes - one simple, atomic choice.

aelvan on 23 Feb 2021

👍4

Ok so I've been following along from a distance the last couple of days.
I think this is going a little too far in terms of functionality, hence the important issues that arise.

All that we seemed to agree on at first was to recognize that "drafts" needed for technical reasons were not the same as the ones consciously created by an author. So editing current would create a "temporary draft" so that it could be auto saved and previewed (and then published or discarded). Simple.

What @brandonkelly suggested was that "temporary draft" would be shown to the author in the version dropdown (as a version on top of current, with current being inaccessible forcing changes to be discarded or published). What I suggested was to plainly hide the whole concept from the author and only show him being on current. I see why Brandon tries to be honest with the author here and it doesn't bother me at all as in any case this "temporary draft" replaces current (you cannot go back and forth between them).

This was simple and effective, this "temporary draft" would be exclusive to one author and if it existed for multiple authors, well, last to save its changes would win the race. But Brandon wanted to go one step further and add in the functionality of drafts via merging, so that authors would be aware of others authors working directly on current. I thought why not. But thinking twice, this is from my POV almost going one step too far, as I see the draft functionality existing precisely for that reason. And from there, it only goes even further, with more questions and issues, as some try to mimic the draft functionality without being in drafts.

Working directly on current is only suited for small edits. It shouldn't be viewed as an alternative to working with drafts. So it should be kept very simple. Want more power? Embrace drafts. Want to correct a typo? Edit your current.

By limiting the power of editing current, you show a clear distinction to your authors as to why drafts exist. If you are functionally blurring the lines, you're confusing your author. I say make a strong statement: editing current should not be the preferred way. You actually made that statement by sending them into an (auto)draft. Adjust it. It can be done, but only for small edits, and there are limitations (overwritten risk, no merging). Save as draft for more.

I get the sense this is turning into a debate about using the draft system or not using it but still having the same capabilities... sort of a pre/post 3.2 war.

JeanLucEsser on 23 Feb 2021

👍3

As to the implicit/explicit draft creation when creating a new entry?

Well, I'm torn. I really am. I see why you would reconsider unpublished draft as the default. But I see some logic as starting an entry as a draft. It just makes sense. It mimics life (measure twice cut once). And it shows the author why drafts exist, it pulls them in, it shows what the system considers as being _the_ publishing process (I like it when a platform is opinionated - it is a good sign). See, in writing this, I don't even see it being any other way.

The only thing that bothered me was the primary action of Save draft. Or is it the secondary action of Publish that keeps me in the edit screen and forces me to Save again to go back to my list?

Maybe what we need, as drafts are auto saved, is to have Publish as the primary action. Every time we are editing a draft. Or if it is too risky, no primary action at all. Just two secondary actions, Save draft / Publish draft. Both of which are getting us back to the entry list.

I think the post 3.2 world is a good one to be in. It just needs to be adjusted to remove auto-drafts.

JeanLucEsser on 23 Feb 2021

One more thing ^^

I'm going one step further as to the system fully embracing drafts.

I think that restoring a revision, or restoring a trashed entry should restore them as a draft. And keep its publishing status as it was (live, pending or whatever). It's a two step process (restore > publish) that would allow for further checking and editing before publishing.

And it would be consistent with starting new as a draft. When you are starting, or restoring, it's a draft. That's the publishing process the system is built upon. And it's easy to train our editors to that logic. Confusion makes training harder.

But that's for another issue. So is the option of unpublishing an entry. There are cases where it makes sense. Do not conflate an unpublished draft and a disabled published entry. Educate the author to their differences.

JeanLucEsser on 23 Feb 2021

The confusion

So two coffees later and I think I know where the confusion comes from in the latest posts.

What needs to be understood about this auto-draft/auto-saved/on-top-of-current-version is that it is ephemeral. We do not (never) come back to it. Leaving the edit screen allows us _only_ 3 choices: Discard changes / Save as draft / Publish changes. The _only_ time when it is persisted when we come back to the entry is if the browser crashed or the tab was closed (and even then it should be garbage collected after a configurable? period of time). That's it.

It is very limited in functionality. It exists for small edits and for previewing.

And for that reason, I think new entries should still be created as unpublished drafts. Because we plan on coming back to them and keep working on them. That's what drafts are for. To work, quit, come back, work some more.

I never wanted to go back to pre 3.2, using a disabled publishing status to handle my work in progress. A disabled published entry is ready. Work on it is done. If it is disabled, it is an editorial choice. It is not because it's a work in progress.

JeanLucEsser on 23 Feb 2021

The implementation

I said it should be temporary, ephemeral.

@aelvan said:

If it ends up being treated as the primary way to save work that's not yet done, something's wrong.

So how do we insure this?

First leaving the page could be intercepted. A dialog would ask "You made changes to this entry that are not published. Do you want to leave and discard them or keep working to either publish or save them as a draft?" Discard | Keep working.

If we can't/don't want to intercept leaving the page, or the browser crashes, then we are left with a temporary draft on top of current. What do we do when getting back to this entry?

Well I say we open the edit page with a dialog that says something to the tune of "You left unpublished changes when you last visited this entry. You can discard them to see the current entry or review them (you will still be able to discard them at any time)." Discard | Review.

And this is where @brandonkelly is finally right in putting some draft magic in this (the step I was afraid was going too far) so that we know which field are impacted helping us in reviewing those unpublished changes.

I still think we should have an option to garbage collect those changes after a configurable period of time (48h by default?).

And last but not least, those unpublished changes or temporary draft are private to the author for a given site. No other author should see them. Again, this should be kept narrow as functionality goes. It is equivalent to editing an entry now (there is no auto save, if you crash you loose everything, and no other author knows what you're doing unless you hit save). Well this is the same except we auto save so that we can preview without creating drafts and so we don't loose anything if we crash.

Ok I'm done for today, back to you ;)

JeanLucEsser on 23 Feb 2021

👍2

Think of Autosaved Drafts as similar to how GitHub will store your WIP comments in the browser’s local storage, so it persists across page reloads. It’s a safeguard for your WIP content.

Maybe that framing will help put other things in perspective…

Admins (permission?) should see and work with all private drafts.

No.

A functionality may be needed to shift a private draft to an other editor (illness/vacation. let B finish my work, take it over from the very untalented intern, next step in a review workflow...). Or does all this require to create a 'public draft'?

No; they can save it as a real draft if they wish to let someone else take over.

Can a private auto draft be shared via 'View...' ?

Yes. (View and Preview both use the same underlying infrastructure; just a different frame.)

Can a public draft be reverted back to a private auto draft?

No.

Can a new 'unsaved draft' be the target of an other entries relationship field? (would be useful for simulating batches #6987)

No. (Nor can real drafts.)

I think @jsunsawyer, @andreimoment and @wsydney76 raises some important issues, which in my mind comes back to _how persistent_ "Autosaved drafts/changes" is perceived by the authors. If it ends up being treated as the primary way to save work that's not yet done, something's wrong.

I don’t think it’s wrong, just as it’s not wrong to close a GitHub tab with a half-written comment, and come back to the issue later to finish it. Sometimes you need to take a break when you’re in the middle of some edits, and don’t want to commit to the changes just yet. So close the tab and come back later – your WIP edits will still be there waiting for you.

And, not to flog a dead horse, but the completely opposite end of the spectrum in terms of UI, would be to keep the unsaved changes completely transparent from the author. Use it for live preview and the technical aspects for which it's needed, and the only point in the publish-workflow where the author has to interact with the fact that they exist, is if they return to an entry that have unsaved changes (which would only happen if they exit the edit screen without responding to the "You have unsaved changes, are you sure..."-dialogue). Upon which they're prompted if they want to recover their unsaved changes - one simple, atomic choice.

If we went this route (which we won’t), I agree it would be good if Craft made accidentally-discarded changes recoverable. However by doing that, we’d be giving the author a false sense of security that their content will always be recoverable, which wouldn’t always be the case, depending on when garbage collection gets run. (A version of this has happened before – see #7216.)

brandonkelly on 27 Feb 2021

👍1

I have just received the following email from a client (DE→EN translation by me):

can you explain to me how the draft stage works now? I'm really annoyed at the moment because once again my entry and the press releases I'm about to publish have disappeared - I've just received another window like this and I don't know what to do so that everything isn't gone again. I don't understand the logic behind all this...

Attached was a screenshot of the “You’re now editing a draft. Keep it / Delete it” dialog.

My clients do not understand the automatically generated draft versions and the more complicated workflows (compared to former Craft versions). And I'm sorry to say that I also find it difficult to explain the current functionality in a way that my non-technical clients understand.

It would be great if there were further improvements in Craft in the very near future.

dennisfrank on 10 Mar 2021

👍1

Further improvements are coming in 3.7 and there will be a beta cycle so your comments will be welcomed.

But let me try to tell you how I intend on explaining the draft concept to my clients (should it be implemented the way I hope it will):

New entry

Everything in Craft starts life as a draft.
Even restored revisions or trashed entries re-start life as a draft.

From there, the main action is Publish Draft (best of both worlds, it's a draft, but the client is pushed towards publishing).
This should be your preferred action if you are done working on your entry and it is ready for publication.

The secondary action is Save Draft.
This should be your preferred action if you need to keep working on this entry at a later time.

If you leave the page without choosing any of these two actions, you are left as if you chose Save Draft (because of the auto saving mechanism).

Drafts that have never been published are found in the main entry list, with a specific icon, among all other published entries. This is so you don't have the impression that you "lost" your entry which was an issue pre 3.6.

Published entry

Once a draft from a new entry has been published, you have a published entry.

A published entry is meant to be done and ready to be shown to the public, even if its status is disabled. I have many clients that use the disabled status to list entries that are ready but that the chief editor is not yet ok with enabling for reasons such as timing, advertisement, processes and such. (For those reasons a new entry cannot go back as starting life as a published entry - but the main action should be changed to Publish draft as previously explained).

From a published entry, you can go back to a draft process at any time by choosing Save as Draft.

But you can also edit the published entry directly (for small changes like a typo). Should you choose to do so, your edits will be autosaved to a temporary state, and your entry won't be impacted until you choose Publish changes. You can change your mind at anytime and Discard changes. And you can even Save as Draft if you feel those changes should enter a full draft process and not be published just yet.

When returning to an entry, you will always be shown this autosaved temporary state should it exists for this author and this entry.

#

I have a very good relation with my clients in general and have been exposing this concept to a couple of them. It "clicked" and made sense almost immediately. So I'm pretty confident this is a good approach. Clear, constant, predictable. I'd love to have the sentiment of @dennisfrank 's client.

JeanLucEsser on 10 Mar 2021

❤3

Cms: Don’t autocreate a draft in Live Preview

Description

Most helpful comment

All 59 comments

New entry

Published entry

#

Related issues