Auto-saves are too eager to do their thing

[Clorith]

Describe the bug
The auto-save feature seem to triggers roughly every 5 seconds, regardless of what you are doing. This means it runs if you have focus on the editor, un-focus it, or even if you are in the middle of typing.

The auto-saves them selves are not a big issue, but a few thoughts came to mind.

• Why is the save icon flashing all the time, did it not save properly?
• What was actually saved just now while I was typing?

It also pulls attention with the repeated state changes.

I did notice that this is only the case for either a brand new post before it is manually saved or published, and that after a manual save it will not auto-save again until you've modified the content in some way (at which point the rapid auto-saves return).

Expected behavior
Auto-saves should be less frequent, ideally they should trigger a short time after typing ends, making it save at a natural position for the user while they are writing.

Screenshots

Desktop (please complete the following information):

• OS: Windows 10
• Browser: Google Chrome (66.0.3359.181)

Additional context
Gutenberg 3.0.1

[danielbachhuber]

I think this is related to #7135, as I've noticed that autosaves are much more frequent when there's a metabox within the editor. If you don't have any metaboxes, then the autosave behavior works much better.

[aduth]

Why is the save icon flashing all the time, did it not save properly?

Related: #7124

At least for the case where a full save did occur, this should be resolved by #7130. The Save button is always presented when meta boxes exist, however (see #4184).

[aduth]

It also pulls attention with the repeated state changes.

cc @jasmussen From a UX perspective, should we just hide the fact that autosave is occurring, or minimize its visibility? Is it enough to infer from the presence of a Save button whether the user may have changes they want to save?

[adamsilverstein]

From a UX perspective, should we just hide the fact that autosave is occurring, or minimize its visibility?

I also find the autosave visuals more distracting than helpful and would appreciate something that felt a bit more subtle.

[Clorith]

I like knowing it's there, it gives a sense of having a safety net, but not if it fires too often.

In the classic editor autosaves are only noticable by the publish button text becoming slightly greyed out (disabled state) during the autosave, there's no other indicators.

[adamsilverstein]

In gutenberg, we increased the autosave interval from 60 seconds to 10 seconds (added in #1945).

Currently we are also failing to respect the AUTOSAVE_INTERVAL constant. See https://codex.wordpress.org/Editing_wp-config.php#Modify_AutoSave_Interval.

d795e1d#r188057153

in Gutenberg we use a hard coded value of 10:

gutenberg/lib/client-assets.php

Line 1132 in 5389ada

'autosaveInterval' => 10,

[aduth]

Currently we are also failing to respect the AUTOSAVE_INTERVAL constant. See https://codex.wordpress.org/Editing_wp-config.php#Modify_AutoSave_Interval.

Can we create a separate issue for this? I'm finding this one to be a bit overly broad in scope and therefore not particularly actionable.

[jasmussen]

I'm almost completely sure that it is, as Daniel suggests, related to #7135. Which if the case, is the first issue that should probably be looked at.

It also pulls attention with the repeated state changes.

From a UX perspective, should we just hide the fact that autosave is occurring, or minimize its visibility? Is it enough to infer from the presence of a Save button whether the user may have changes they want to save?

If #7135 can be fixed, this would mitigate nearly everything, and I think it's a very core issue to look at. In my development environment, I currently do not have any metaboxes enabled, and in fact the autosave seems to kick in too rarely — often the Save Draft button just sits there without doing anything. This is possibly another separate issue, but nonetheless, the issue is tangential here.

Perhaps it would be good to step back a bit and reiterate how the current design came to pass, and what the ultimate utopian dream save scenario would be:

There is no save button. Saves happen automatically and you don't have to worry about it, ever. If you're offline, things are saved offline and synced when you go online, perhaps with a state message saying such, but we have spared you from having to click a button in order to not lose your work. This is a modern web-app pattern — things save by themselves.

Autosaves happen after a change is made, otherwise it doesn't do anything.

In absence of a save button, a visual affordance for letting you know the document is indeed saved, is crucially important. It explains why you might see a confirm prompt. It's also something to glance at to verify that yes, things are saved.

When we reach this point, we can reduce the footprint of the save indicator — we can make it a very light gray — since it's not clickable at that point we can potentially reduce the contrast and make it lighter. We can even experiment with removing the text entirely, or the icon entirely, in favor of a simple "Saved" text label. Google Keep uses an icon:

I'm fully aware we can't reach this point yet, and metaboxes make this extra hard. But this is nonetheless the ultimate destination for the save interface, and we should be extremely careful to not make concessions to support a legacy behavior at the expense of a better future. User tests we've done show that the save state indicator is very important, and hiding it to support metaboxes would be one such concession.

Outside of fixing #7135, I'm not sure there's a ton we could do. Ideally we could rid of the interval entirely, so that this could work:

Autosaves happen after a change is made, otherwise it doesn't do anything.

[danielbachhuber]

#7135 is fixed, which I feel reasonably confident addresses this issue too. Feel free to re-open if you find otherwise.