Research: Possible backend implementations of auto-save, drafts, and publishing

Adding @hchonov (maintainer of https://www.drupal.org/project/autosave_form) to this issue per #3462360-20: [PP-1] Partial preview updates: update preview of modified component only, not entire component tree.

We are currently under the assumption that we can require Content Moderation for this functionality. It should work "out of the box" but Experience Builder may want to create a specific UI for saving and viewing revisions.

Content moderation has severe limitations - for example if media, taxonomy terms (via tags autocomplete) or other similar entities are created within experience builder while editing a node, it is not able to track their publishing state along with the node, so the media entity or taxonomy term will 'leak' into the live site.

These problems are fully solved by workspaces, so I'd strongly recommend looking at that first especially since it's stable in core now. Workspaces also supports full-site preview, so once a draft revision of an entity is saved, it can be properly viewed in context in the rest of the site - including in views listings and any other contexts it might appear.

The disadvantage of workspaces at the moment is that the 'workspace' concept is always exposed, but #3095414: Add the concept of workspace providers is already open to address this, and would eventually allow for a lite/transparent interface for workspaces that could fully replace content moderation.

The initial idea for auto-save is to use the shared temp-store. It was determined that doing a full entity save for auto-save would not be a good solution because

Another reason that auto-saving can't do a full entity save is validation. For example when first creating a node in a form, the entity is not a valid node (no title for example), so entity validation would fail. Saving without validating would create invalid revisions which if they were ever published could break custom logic, lead to information disclosure, or might not even be allowed with the database schema. Even once an entity is valid, it could be temporarily invalid again in the form state - e.g. if I delete the current content of the title field to replace it, the title field will be empty but required and autosave would be blocked (or risky) until there's something in there again.

Is there friction as far as site building, contrib compatibility, or custom code?

Disclaimer that I haven't actually used the Drupal 10 version of workspaces in production, but it's completely transparent - the only case where it wouldn't be is hard-coded entity-like or entity-related storage that does not use the entity revisions/views/entity query system properly. The only friction is that you have the workspaces concept exposed, vs. 'only' workflow in content moderation. Recipes could probably smooth out any initial set up now.

My understanding from the reason Workspaces was originally developed was or organizations that had pretty strict requirements for this type of entity "leaking" into a live.

It's only partly about the 'leaking', but as much about being able to publish sets of changes at the same time (which IMO is potentially useful for any site bigger than a single-person-blog), and having whole-site-preview so that changes can be reviewed together and in context (relevant for read-only collaborative preview if not quite collaborative editing as such).

The initial idea for auto-save is to use the shared temp-store. It was determined that doing a full entity save for auto-save would not be a good solution

It seems like you are only listing the drawbacks of the alternative solution. Have you considered what are the limitations and drawbacks of the current solution? For example, are we able to show these auto-save states in the content listing for when the content was last updated?

If Content Moderation cannot be a requirement for this functionality then another implementation would need to be part of this research spike.

At minimum, we could have a soft dependencies like this. If we can provide better experience by having a hard dependency, we could consider that too.

These problems are fully solved by workspaces, so I'd strongly recommend looking at that first especially since it's stable in core now.

I agree with @catch that Workspaces from UX perspective would likely to be closer to the ideal experience (in the long run). With Workspaces, it is possible to edit multiple things and preview them together. For example, when I make changes to a design token as well as components, it's likely that those changes would be better reviewed together. Same as when we make code changes; if we were limited to making changes just in a single file per MR, it would be really hard to actually review changes. I think we should at least consider this as an option since we believe it could provide the best experience.

TBD: What information would we need to save in the shared tempstore?

FYI, there's an existing implementation of this in the Blokkli module which may be worth reviewing: https://git.drupalcode.org/project/paragraphs_blokkli/-/blob/1.0.x/src/E....

I haven't caught up on the comments in this issue, so this is just a drive-by idea, but I wanted to post it here in case it leads to any good discussion or helps spark other ideas.

The key problems with an auto-save saving an entity "for real" (whether as a draft revision or in a non-live workspace) as opposed to "just" in the temp store are:

1. It might be unexpected. Unlike with Google docs, Drupal content editors might not expect their stream-of-consciousness writing automatically becoming real draft revisions or real changes in the workspace that they're in.
2. The in-progress work being auto-saved might not be in a valid entity state (e.g., required fields might not be filled in yet).
3. A real entity save (even a draft revision or a save to a non-live workspace) can be slow. Especially if the site has contrib or custom code with hook implementations that call out to 3rd party web services.

So here's a possible idea for mitigating the above by combining Workspaces and Temp store:

• Every auto-save submission from the client we save to the temp store.
• We introduce an "Allow auto-saves" setting to Workspaces. This mitigates #1 above.
• If while in XB, the editor is also in a workspace that allows auto-saves, then when we get an auto-save submission from the client, in addition to saving to the temp store, we also save the entity for real, if:
  • It passes validation (mitigates #2 above).
  • We're not already in the process of saving it in a different request (i.e., we add a lock around a real entity save) (mitigates #3 above).

This would mean that even without the Workspaces module enabled, we still get auto-saving to the temp store. But with Workspaces enabled, and when in a workspace configured to allow auto-saves, we also get real entity saves happening for valid states and protected from stampedes without having to slow down the rate that we're able to save to the temp store.

Content moderation has severe limitations - for example if media, taxonomy terms (via tags autocomplete) or other similar entities are created within experience builder while editing a node, it is not able to track their publishing state along with the node, so the media entity or taxonomy term will 'leak' into the live site.

I’ve rarely seen this as an actual problem on the websites I’ve worked on. Neither on different CMS that have same limitation, like Contentful.

1. Per @catch in #12, I think we may need to update the issue summary to replace every mention of Content Moderation with Workspaces? Although, is this only a problem on more complex sites, not on simpler ones, like @johnwebdev seems to imply in #20?
2. RE: validation + auto-saving by @catch in #12: I think we could do partial validation of an entity, like Form API's #limit_validation_errors or Field API's \Drupal\Core\Entity\EntityConstraintViolationList::filterByFields(). Although you're right that some field/entity DB schemas may simply not allow certain invalid values. But doesn't that mean that Content Moderation and Workspaces automatically have to be discarded as possible implementation methods? 🤔 Because autosaving should work from the very start, not only once the entity is in a valid state…
3. @lauriii in #15: RE: content listing → can you elaborate? Do you mean /admin/content? This could be solved using a new computed field on all entity types, or even just an additional computed property on an existing field type.
4. @effulgentsia in #17: very interesting … but how does that get around DB schema-level constraints that may not be met by an invalid entity?

I'm going to try to process all the details here and update the issue summary.

But doesn't that mean that Content Moderation and Workspaces automatically have to be discarded as possible implementation methods? 🤔 Because autosaving should work from the very start, not only once the entity is in a valid state…

Yes, this is why I brought up autosave_form in #3462360-20: [PP-1] Partial preview updates: update preview of modified component only, not entire component tree after going through much of the same thought processes that are happening in this issue in June - you just cannot do autosave as-such with entity revisions. There are other things you can do with entity revisions (like full site preview) but it is not the same thing, and the two can work together (i.e. autosave can preserve your edits, before you then save a new draft revision).

Okay, I've fleshed out the requirements for the Auto-save feature, and this is on track to become the longest issue summary in history. 😬 (I blame d.o's CSS for the odd markup choices I made to make it more readable.) I plan to do the same for each of the other two features and then distill the discussion in the comments. Also, it's past 1:00am my time and too late for proofreading. Here's hoping for the best. 😛

@longwave, @lauriii, @catch and @hchonov discussed this issue at Drupalcon Barcelona. We agreed that we need a combination of solutions for the product requirements for autosave functionality - but the good news is that much of what we need to implement this already exists.

We should be able to use Autosave Form to handle automatically saving XB data into tempstore. It provides an endpoint that XB should be able to talk to with little or no modification. It does not yet support displaying details of the autosaved state elsewhere in the CMS but this should not be difficult to add. It also currently uses per-user tempstore but converting it to (optionally) use shared tempstore should not be a problem.

This will allow us to save valid or invalid entities. We may want to extend it to attempt to validate the entity on autosave in order to indicate to the content creator whether the entity is capable of being saved or if there is an error that would prevent publishing.

We may be able to use Content Lock to handle the non-concurrent editing problem when two users are using the XB interface for the same content item.

As XB may involve editing multiple entities (content or config) at once, we can use Workspaces from core to handle reviewing sets of changes across multiple entities before publishing them. We may want to implement #3095414: Add the concept of workspace providers to move Workspaces entirely behind the scenes so the content creator does not need any knowledge of workspaces - but advanced users will still be able to use full workspaces to e.g stage multiple sets of changes or go through longer review workflows.

We have ruled out Content Moderation as there is a longer term desire in core to phase out CM as it currently exists and replace it with a simple implementation based on Workspaces.

Updating the issue summary to reflect the elimination of Content Moderation as an option per #28.

...and again to updated the proposed resolution. I'll leave it assigned to me to continue fleshing out the distinct user stories for drafts and publishing.

@lauriii gave a very quick idea of how he envisaged XB editing to look like, and it looked very, very similar to how workspaces works already, which was both encouraging and surprising.

I had been assuming we'd want to hide the workspaces concept almost entirely for a default UX (which is the main missing piece from what it can already do compared to content moderation), but @lauriii said things like 'but what if I want to edit both the site menu and tweak a node from one page in XB and then publish both changes at once'. XB can't do that yet, but workspaces can already do this including config entity changes (in the wse_extras contrib module), so it is just a case of getting those things to meet.

The main UX difference was that the list of affected entities was shown right on the XB edit form, and it was possible to publish the changes directly from there without needing to go to the workspaces UI as such. We still might still want to hide the 'workspace' as a thing separate to the current set of edits itself (so still need #3095414: Add the concept of workspace providers), but not the concept of reviewing/pubishing/staged changes and the fact that multiple entities are affected - just localise it to the XB form when you don't have a separate review workflow. This all seems like less work/changes than I was thinking it would be - not that much of a jump at all.

This is bit of gamble, relying a recently stable module that has not been used by a lot of production sites

Workspaces is slightly different to a lot of experimental modules in core. It's been used in production on at least a handful of large production sites including at least one fortune 500 company for at least a couple of years or more. The last handful of patches that were required to get it to stable were also run on production for several years. The reason it took so long to get to stable was because the company that originally pushed towards getting it into core withdrew support for it more or less at the last minute, and then other companies started using it after that, but the core momentum was lost for some time in between. There were also issues with the initiative that extended the timeline, which I'm still bitter about, but too late to fix those now. Me and Fabianx were also running workspace's predecessor on production on Drupal 7 as early as 2015 (while the name is different, CPS, the architecture is almost identical).

All of this to say the data model and functionality is very stable, it just took a long time to be able to flip the core flag.

However this very long timeline has definitely affected wider adoption and I'm pretty sure there will be usability issues that will have to be fixed both for Drupal CMS and XB. But... both Drupal CMS and XB picking it early means there is time to identify and solve those issues starting from now, rather than in a year's time having run out of options with content_moderation and having to start later, so it should result in a much quicker timeline overall.

Another concern I want to raise about relying on Workspaces is that if want to also be able to edit and stage Config changes as @catch mentioned in #31 we need to rely on Workspaces Extras.

This is true, but the config staging is holistic (as is trash module support), so while there will be work involved to get config workspace support into core and stable at some point, it should be a lot less work than trying to implement config staging within XB without the 10+ years of work that has already gone into it. Trying to implement config moderation with content_moderation would be a complete non-starter.

If we do decide to depend on Workspaces I think it would great make it a dependency as soon as possible to make sure it the direction is as clear as possible. If we only make it dependency after we have spent months to make integration really nice that could shorten that time people to raise concerns before XB becomes stable.
[...]
It would great if we could be practical with this part of module like we have with other parts, like the Canvas UI demo that doesn't allow saving, to get working with Workspaces in even rough way first.

100% agreed with this. I think the easiest way to approach things would be to just make workspaces a requirement, and then add some basic configuration so that people installing XB don't need to set up any workflows etc. and live with exposing the workspaces concept for a while. Then hopefully some of the workspaces UX work can happen in parallel, and not necessarily directly in XB (although the final touches might need to be if it's in react).

edit: to put the above differently. The risk here is from the requirement of draft, workflow, autosave, potentially multi-user editing as first-class functionality in experience builder. I agree these are good problems to tackle, but if they are going to be tackled,then the lowest risk way to do this is to use workspaces (and probably autosave or at least the same conceptual distinction between form and revision data that it has). Any other approach risks repeating all the moderation and workflow mistakes and complexity of the past 15 years all over again - the problems of which CPS/workspaces was created to solve.

Okay, my updates to the issue summary are complete. I think I've captured more-or-less everything. Assigning to @lauriii for input on the unconfirmed requirement details.

@lauriii, we've documented our current understanding of the requirements in the issue summary. We would like your confirmation so we can confidently finalize our architectural decisions. Every detail we've identified is marked with a colored circle indicating its status (confirmed or otherwise). (See the legend.) Basically, anything that isn't green needs confirmation--mostly from you.

Incidentally, the issue summary is now rather massive, and I could see it being extracted to its own issue for reference and discussion, if desired. I'll happily do that if asked.

The workspaces DrupalCon session is now online and even for me who helped build the initial workspaces implementation and reviewed much of the core work, I had no idea what was implemented in workspaces extras so it was useful to see it all pulled together into a demo https://www.youtube.com/watch?v=bgJ-oubGjbc

Couple of comments/questions on the issue summary:

And I am working on an entity in Experience Builder

The wording of these user stories assumes that the entity has already been explciitly saved (i.e. exists as an entity). autosave_form also handles the case where nothing has been explicitly saved - in this case when you go back to the node/add/* form it will tell you there's an unsaved draft to resume. I don't know if that is an XB requirement but it would be good to explicitly rule it in or out, currently it's not mentioned.

Then I am warned the entities I created will be deleted, and I am prompted to continue (Am I given the option to selectively delete them, or is it an all-or-none proposition?)

This could potentially be done with trash module which doesn't depend on workspaces but does integrate with it. It does add another layer of things but it implements soft delete + restore + purge. It can also be tackled by moving entities selectively into a different workspace so some can be deleted and some can be preserved.

A lot of the semi-collaborative editing section can be achieved in workspaces (e.g. you can send a link with a token to an anonymous user and they can see what you're working on in the workspace, or an auth user with permissions can browse workspaces)... but this does not include being able to see the editing UI live, which I think is what it's point at (?) - and I agree with the questions about discoverability - would they just be able to browser to the node/n/edit form, but then it would need to be a read-only version of that form.

Feature: Saving a draft

I think this is now just workspaces - except there's a question whether XB (or Drupal CMS) provides default workflows for that - i.e. a separate review stage doesn't make sense for a single-user site, even though they might want to save in-progress drafts and preview them sometimes.

Did we give any thought to CRDTs here?

CRDTs = Conflict-free replicated data types. Some interesting discussion on Drupal Slack.

Same Page Preview reuses NodePreviewController's method of using TempStore to persist the FormState of an unsaved node.

What's being discussed here appears to be a decision to use workspaces and revisions instead of tempstore when building something with Experience Builder. I presume the "something" here will be stored as an entity somehow, but maybe that something isn't a node.

My question is, when we consider nodes, are we talking about modifying the underlying mechanism for storing unsaved nodes, so that they are previewed?

Also, when previewing nodes, is there the possibility of reusing Experience Builder's preview capabilities? In the XB future, does thinking about content as nodes even matter anymore?

What's being discussed here appears to be a decision to use workspaces and revisions instead of tempstore when building something with Experience Builder.

No not quite..

At the moment, the current state of discussions leads to something like:

When an item is explicitly saved -> new revision.

When an item is autosaved -> autosave_form (similar but not identical to temp store).

This is because an item that is autosaved may not be a valid entity - it could have required fields missing, so it can't be an entity revision in a useful way. Similarly on the node/add form, there is no entity yet to save a revision for at all.

Ah yes, incomplete data.

When we think about auto save, data that is incomplete and would fail validation, are solutions that persist data on the frontend able to be a candidate solution?

I'm not familiar with yjs or other solutions of that class. But even something as simple as JavaScript's local storage might provide a means to store complex data temporarily

Storage API
Indexed DB
And React is in the mix so, I guess Redux

All provide various advantages / use cases.

Do we have to auto save to the backend? Is there no way we could solve this on the frontend?

@cosmicdreams if we never autosave to the backend, then there is no ability to start something on desktop and resume it on phones. I use that feature on slack/gmail at least and even if there might be less of a use case for a website than an email draft, people will know it exists and potentially miss it if it's not there. Similarly if your laptop runs out of battery or browser updates etc. Collaborative editing will also have to save to some kind of backend even if it's different/evolves from the autosave one too.

@cosmicdreams there is a product requirement:

As a creator, I want to work collaboratively in real-time with other creators. This means being able to work on the same page simultaneously with other creators, and seeing changes made by them.

While full collaborative editing is some way off, autosaving changes on the server side means that other creators could still see a preview of something that a creator is working on without them having to explicitly publish it, in near-realtime.

I built an initial proof of concept using tempstore that allows saving and reloading of the current layout: #3478299: Implement basic auto-save

I think CRDTs will probably become useful and perhaps a requirement in order to build full collaborative editing, but to start with I think we can introduce single-user editing and locking which would still allow collaborative preview.

The wording of these user stories assumes that the entity has already been explicitly saved (i.e. exists as an entity). autosave_form also handles the case where nothing has been explicitly saved ... I don't know if that is an XB requirement but it would be good to explicitly rule it in or out, currently it's not mentioned.

Good thinking, @catch. I assume it is not a requirement since, as far as I know, there's no way to use Experience Builder except on a piece of content that already exists.

I've updated the issue summary to include this assumption.

#46 Maybe laurii can confirm? Personally I think starting in XB when creating a new page would be better UX than first having to create and save a node before getting started.

A lot of the details in this issue (that assumption included) are pending confirmation from @lauriii. See the legend for interpreting the status markers.

Granting our assumptions, it seems like we're more or less in agreement on the proposed resolution at this point. (Tell me if I'm wrong.) I'll see if I can get @lauriii's eyes on the issue, and in the meantime, I'll find a good place in the codebase to document our architectural direction. Since the scope of this issue is research, that should resolve it, and we can create follow-ups to start on implementation.

Looked at this with @bostonjillian and @Renee Lund and got through the auto-save section.

🔵 When a given amount of time transpires (How much? Or should it be event-based?)

We want users to not have to think about this action, which means that it needs to be close to immediate (~few seconds). I guess based on that, it should probably be based on when changes are being made?

🟢 Scenario 5.1: Deleting created entities when abandoning progress

There should be a way to delete the draft by using a delete action but once the user has entered the content form and inserted any content there, we should retain the saved draft.

🔵 Scenario 6.1: Deleting created entities when abandoning progress

From UX perspective, there might be different expectation between the two examples given in the user story. Media library is often something that is considered to be separate from the content (i.e. page) that is being created. This is highlighted by the fact that it opens up in a modal dialog and has explicit steps for uploading and saving. This is different from the use case of Taxonomy Term because in that case you're just adding a tag inline using an autocomplete.

🟡 Auto-save only applies to saved entities. It doesn't make sense in any other context, e.g., an un-submitted node/add/* form, since (it is also assumed) Experience Builder can't even be opened except on an existing entity.

I don't think this is the right assumption. Content types that are using Experience Builder should open in XB even when creating content.

🟡 If a user wants to revert back to a specific point in history, that will be handled with revisions.

It should be possible to revert back to previous revisions and auto-save states. It would be okay if auto-save states get truncated into a single revision once content gets published.

🟡 Workspaces can be a dependency of Experience Builder. (Can it be a hard dependency for all behavior, or only a soft dependency for "enhanced" functionality? See Open questions.)

I think we need to work with the assumption that we depend on Workspaces for now. It doesn't seem that the UX of going with content moderation would meet the needs. I don't think we need to implement support for using XB without Workspaces now, but it would be great if we could build this in a way that we could reconsider this decision closer to the release. This way we could add a way to use XB without Workspaces later if needed.

🟡 What happens if the same user has the same node open in Experience Builder at the same time on two different computers? For example, what if a user goes back and forth between home and the office? Does one computer get locked out of editing and become "read only"? How do we avoid the two computers repeatedly overwriting each other's auto-saves?

We could do something similar to: https://www.youtube.com/watch?v=CsRBypaT_hM&t=27s. We could apply this both for the scenarios where the user is the same and where it's different.

🟡 What happens to one user's auto-save states if a node or revision is changed by another user?

Is this relevant if we do above ^?

It should be possible to revert back to previous revisions and auto-save states. It would be okay if auto-save states get truncated into a single revision once content gets published.

One extra question here - is this only when the content is actually published, or is it also when it gets sent for a workflow step like review? I think autosave_form would currently truncate drafts whenever the entity is explicitly saved. In the Barcelona meeting, we briefly discussed saving a new forward revision as part of the autosave when the entity is valid (or every so often when it's valid), this would provide a partial interim-history of autosaves which could more easily be preserved for longer (but still with some metadata noting they're implicit rather than explicit revision saves).

fwiw I think that aspect is something that could be experimented on once the initial implementation is up and running, feels like there are a couple of options and it will need to be built on a working foundation with some trial and error both in terms of UX and implementation. But also good to think ahead to it.

Re: #29

🟢 Scenario 5.1: Deleting created entities when abandoning progress

There should be a way to delete the draft by using a delete action but once the user has entered the content form and inserted any content there, we should retain the saved draft.

I don't understand. I assume "saved draft" means an auto-save state. Is that right? What do you mean by "content form"?

🔵 Scenario 6.1: Deleting created entities when abandoning progress

There might be different expectation between [Media entities and taxonomy terms]. [In] the use case of Taxonomy Term because… you're just adding a tag inline using an autocomplete.

But you can also configure Taxonomy term fields to "create referenced entities if they don't already exist". The point is that it’s possible to create separate entities from a node edit screen. Does the rest of the scenario look right?

🟡 Auto-save only applies to saved entities. It doesn't make sense in any other context, e.g., an un-submitted node/add/* form, since (it is also assumed) Experience Builder can't even be opened except on an existing entity.

I don't think this is the right assumption. Content types that are using Experience Builder should open in XB even when creating content.

Okay, so when you create an XB-enabled node, for example, there is no standard node/add form at all? You go straight to Experience Builder and that's the only way to interact with the entity? If so, that should be added to the assumptions. And we probably need a new scenario for editing the overall entity information--such as title, URL alias, and menu settings--from within Entity Builder. Would you agree?

🟡 If a user wants to revert back to a specific point in history, that will be handled with revisions.

It should be possible to revert back to previous revisions and auto-save states. It would be okay if auto-save states get truncated into a single revision once content gets published.

Wouldn't that mean that the "truncated" (meaning, squashed or merged, I assume) auto-save states are always identical to the list of revisions--making them effectively useless? Wouldn't that mean that every revision would have an identical auto-save state?

🟡 What happens if the same user has the same node open in Experience Builder at the same time on two different computers? For example, what if a user goes back and forth between home and the office? Does one computer get locked out of editing and become "read only"? How do we avoid the two computers repeatedly overwriting each other's auto-saves?

We could do something similar to: https://www.youtube.com/watch?v=CsRBypaT_hM&t=27s. We could apply this both for the scenarios where the user is the same and where it's different.

Given the workflow depicted in the video, I suppose that would mean a user on computer two would have to request control from computer one. And ignoring the logical challenges with that, it would mean that our auto-save states would no longer be associated with a user but rather with a browser session, right? Otherwise the concept of locking doesn't make any sense and we haven't solved the problem in question at all.

🟡 What happens to one user's auto-save states if a node or revision is changed by another user?

Now that I understand that only one user can be working on a single entity at a time, problem can't actually materialize, then as long as starting an editing session in Experience Builder locks the whole entity, this is irrelevant.

We're making great progress here!

Note: I'm updating the issue summary to capture what we've learned. I may have made some small mistakes, but it's the end of the day and I don't have time to give it a thorough proofread. I'll keep updating it as the conversation proceeds.

Wouldn't that mean that the "truncated" (meaning, squashed or merged, I assume) auto-save states are always identical to the list of revisions--making them effectively useless? Wouldn't that mean that every revision would have an identical auto-save state?

If autosaves are always newer than the latest revision, it's much easier to think about because you have revision 1, 2, 3, 4, 5 then autosave 1, 2, 3, 4, 5, not revision 1, autosave 1, revision 2, autosaves 2 etc..

Then to have interim checkpoints between explicit saves to potentially revert back to, the idea discussed of implicitly saving a revision in the background when the entity is valid comes into play (with metadata so we know that's what happened) - while this adds complexity, it would still result in two linear histories of the entity/form.

If all the above happens, then autosaves can be garbage collected every time an entity revision is saved (whether this is explicit from a button or implicit when the autosave state is a valid entity).

I don't understand. I assume "saved draft" means an auto-save state. Is that right? What do you mean by "content form"?

While the end user might not need to know the difference between an auto-save state and a forward revision, I think it would be very good to use the terms exclusively in this discussion and not mix and match 'draft' to mean both things.

While the end user might not need to know the difference between an auto-save state and a forward revision, I think it would be very good to use the terms exclusively in this discussion and not mix and match 'draft' to mean both things.

I agree with this sentiment, but I think picking the right words is tricky. I think we need to have terminology for three states. Taking an implementation-perspective, we can call these states:

• an auto-saved state
• a non-live (is "non-live" the more accurate term than "forward"?) revision
• a live (is "live" the more accurate term than "published"?) revision

However, as the UX for this hasn't been fully designed yet, and the product requirements not even fully flushed out yet (though this issue is making good progress towards that), I wonder if it would help the requirements/design process to also have product/UX-oriented terminology for these states rather than jumping straight to the implementation-oriented terminology.

Perhaps something like:

• In-progress stuff (or some other term than "stuff", such as "work", "content", "edits", "changes", etc.)
• Reviewable stuff
• Published stuff

?

a non-live (is "non-live" the more accurate term than "forward"?) revision

To me it's not more accurate, because a 'non-live revision' includes past, previously-default, revisions too, and technically 'published' revision also includes non-live, previously default revisions, so we can't just use non-live and published. So we probably need to explicitly talk about four states/things :/

That would mean:

• old, previously default, revisions
• auto-saved states
• forward revisions (for review by ones-self or others)
• default revision

In-progress stuff (or some other term than "stuff", such as "work", "content", "edits", "changes", etc.)
Reviewable stuff
Published stuff

If we add 'old stuff' or 'published history' here too that probably covers it.

How about this?

It should be possible to revert back to previous revisions and auto-save states.

I strongly request that we descope "revert back to previous auto-save states" from the initial implementation of Save functionality and from the 0.2.0 milestone. I opened #3481006: Implement time travel (undo/redo/revert) of auto-saved states across devices and users to discuss and work on just that feature in its own issue.

Did we give any thought to CRDTs here?

The issue in #58 proposes to use a CRDT library for implementing that issue, both to eventually support collaborative editing, and also because those are the libraries/algorithms that also implement the most mature, robust, and efficient storage of large histories.

I opened #3481986: Lazily create draft revisions from valid auto-saved states on demand rather than on save or only on schedule as a child issue, with an idea for how we can make valid auto-saved states essentially equivalent (from a UX standpoint) to real draft revisions, but without the performance cost of doing a full entity save for every auto-save.

Chiming in as an early-ish adopter of content moderation. When we upgraded to Drupal 8, workspaces wasn't really a thing. We now have years of muscle memory built up around content moderation, having explained in depth to our users why it works the way it works as opposed to something like, say, the Oasis Workflow plugin for wordpress (which has been lauded above the Drupal tooling btw...).

In my experience, teaching the technical mechanics of a solution has been secondary to the "why doesn't this work like other workflow solutions that I am used to" barrier.

For us, it would be a very hard sell a switch to something completely different again with different justifications involved. If a motion to strong-arm use of a specific workflow tool is inevitable, I would urge looking at the most popular (by number of installs globally) workflow tools and to derive the end-user facing terminology from those tools versus Drupal implementation detail nomenclature.

Not sure if this is helpful at this stage of the game or not, but I wanted to get this point of view out there.

Re #63, it's very likely that for XB we'll build an XB-specific UI for listing, previewing, approving, and publishing draft content, even if we use Workspaces as the storage model. Your comment is great input for the design work being done on that. If the designs implemented for XB are well received, they can potentially make their way upstream to the core Workspaces UI eventually.

By using Workspaces as the storage model, if people don't like XB's listing/previewing/approving/publishing UI, they could potentially replace it with core's Workspaces UI, or any other UI built on top of Workspaces, such as even Content Moderation if/when that UI is rebuilt on top of Workspaces (see #28).

For XB, Workspaces is only viable if it can also handle config entities. I opened #3493461: Identify roadblocks to staging config in Workspaces (e.g., via wse_config), so if anyone has knowledge to share there about wse_config, that knowledge would help us enormously in planning out our roadmap.

I think we defined the path for 1.0.0 mostly at this point. I would appreciate if we could complete #3512616: Document the reasons for not using Workspaces for saving in XB 1.0.0 which documents the current direction. That said, I don't think we need more research on this topic until later when we actually implement Workspaces support.