Mixing autosave and drafted updated in webapp

Question

I developed an LMS web application for which I decided to go with an autosave-based user experience: there are several different editable resources in the application (quizzes, lessons, exams, announcements, and so on) and the general feeling the application gives is a save-button-less flow where:

• when you create a resource, the resource is immediately created on the server in draft mode
• any change you make to the resource is automatically saved to the server
• most resources have nested resources that are also automatically created and saved during editing of the parent (think of a multiple choice question that allows creating its choices inside of an editor; an example of this is Google Forms)
• you still have a "Publish" button, which essentially just modifies the state of the resource

I'm trying to figure out whether it's bad UX design to have changes made to such resources when editing them auto-saved just like when first creating them.

I have some resources that are modified in a full-page editor, and the whole task you're doing is just editing that item. For these, I believe the "always auto-save" might work well: think Google Docs, which always saved changes, not just when creating them.

However, I also have some resources that are edited in a smaller, dialog-contained editor. For these, I am not too sure about always committing changes automatically. Think of Google Classroom's "classwork" editor:

Here, changes aren't committed until you hit save. I believe this could be safer for the user, who would feel more empowered to experiment, knowing it's as easy as just discarding the most recent changes if they wish.

For example, let's take this lesson editor from my app. When you first create a lesson, autosave is enabled, and the editor looks like this:

However, if you subsequently edit the lesson, the autosave will be turned off and you'll have to manually click a Save button.

For now, one solution I'm adopting is that nested items (for example the attachment in the second screenshot) are created and stored even if you discard the most recent changes. So "saving" only applies changes to the top-level resource.

Do you think it could be disconcerting to the user to have two different experiences when creating vs updating a resource? Also, how would you handle nested resources created, updated, or deleted during such a phase of not-autosaved editing?

I understand the latter is more of an implementation issue, but what I'm finding to be the hardest aspect to deal with is dealing with nested entities when the changes to their parent aren't saved yet: it's much easier to assume the parent exists and is up to date, so any advice as to this aspect is also very welcome.

Answer 1

Rather than decide when the users can autosave, let them decide for themselves—adding an "Autosave" toggle control:

I contend the Autosave toggle option ought to initially be set to the OFF position—let the user turn the feature on.

The initial draft button might be:

[Publish Draft]

And when editing the button might be:

[Publish Edits]