Saving

The first and foremost thing to say about saving in overall is this: by all means avoid losing users’ work. The work user has done in the product, a flow of steps that she made, a state of the UI, an input of the text in a field — all of this is user data, and user data is infinitely precious.

To avoid having people lose their work if their connection goes down or the computer battery ran out of charge, or simply if the user closed the browser tab by mistake, it may be good to have the server keep an up-to-date copy of the state being edited, but the previously "saved" state should generally only be updated if someone affirmatively requests that.

The second thing here is this: be consistent. 

If we use the Save button in most of the forms in Valamis, there should be a Save button in all of them. Users would expect to locate the button in a familiar place, but if they couldn’t, they would be confused.

Over years of experience with technology, most users have learned that they need to explicitly tell a system to save their work or they risk losing everything since the last save. In the case of forms, most users assume nothing is really changed until a Save or Apply button is pressed, and also they assume hitting Cancel will revert all of the changes. 

Navigating away from a form, if there were changes made to the form, should always prompt users whether they want to apply those changes or discard.

But the main point here is that when we use the form model we only have the form UI and lose the context itself. So we don’t see the real thing which we are creating or editing using this form. This means that somebody else might interact with the entity at the same time you are editing it using a form.

What you change in the form should not take effect on the system immediately. However all of the data that the user has filled in should be kept. It just should not be applied yet. 

Autosaving

There’s another interaction model where in turn auto-saving is king — it’s the so-called document-model. Like Google docs or Figma, or the better example would be Valamis Lesson Studio. Document model means that there’s no underlying system somewhere else which you influence by changing the settings or something.

It means that the user sees clearly all of the changes immediately apply on the canvas, which makes perfect sense from the feedback pov. Basically there’s no need for extra feedback as long as the changes themselves give enough feedback. The only feedback that is necessary is the notion of saving. Users must be absolutely sure that everything is always up-to-date and saved.

However, there’s always a however. Even in this case auto-saving would be a downside unless the model provides versioning or at least a simple undo/redo functionality.

If all of the changes apply immediately, there should be a way for users to revert back to a state that they had somewhere in the past if they realize, that there’s no more undo, or if they messed up the whole thing.

Keeping user's data

Keeping user data doesn't mean auto-saving. It means that the system needs to be able to restore users work, data inputs and state of the UI even if the system crashed due to different reasons. Users need to be sure that none of the work is lost due to inactivity or any other issues (excluding third-party intentional misbehavior) at any given point in the experience.

Publishing

Regardless of the interaction model or the way of saving, Saving is not Publishing. Saving means keeping the work saved. Publishing is another user's intent, which means making the previously made work available to other users in the system.

Users don’t wan’t changes made to a learning entity automatically appear on the other user’s end. A content creator might be experimenting with a Lesson or Learning path, and wants to make it available to other users only after she finished her work.

Publishing is a necessary step in the content management and distribution process. Good systems provide easy, familiar and intuitive ways to save and publish content. 

Summary

We need to use save buttons in the forms, because users expect them there. It doesn’t wipe away the need for comprehensive feedback, and of course the UI should keep all the user input in the form even if the system crashed due to electric shortage for instance → the UI should be restored in a state that user were at the moment of crash and all the data should be there. It just should not be applied to the underlying system without users intent.

That being said, it’s also very true that often people forget about saving (and autosave is a great feature that prevents many hours of grief and duplicated work). However, autosave does not need to replace save: they can both coexist.

When it comes to publishing, everything should be already saved on the publishers end. When it comes to saving it should be only made by users intent in the out-of-context interaction model, and good to be automatically saved in a document-based interaction model. We should always keep users data, and only clear it when user hits Cancel or interrupts her flow of work with an intention to start from the beginning or revert to the previous state discarding the changes.

We should always have comprehensive feedback so the users would feel more control over the system. We should have undo/redo functionality to support different user intentions, especially within document-based interaction model, and also provide version history for the experiences that use this model.