Add micro delay to "Save Draft" button

[danielbachhuber]

To improve the perceived UX of the "Save Draft" button, it would be helpful to add a micro delay to the transition:

Also, the "Save Draft" button switches really fast from "Saving" to "Saved". As a user, I might not notice that at all ("did I really just save?") or it can feel buggy ("this was way too fast"). Adding a little delay might help here.

From #1295 (comment)

[karmatosed]

If we are adding a delay just to inform the user wouldn't working on messages help? I would suggest that from a design perspective for a critical feature like saving adding in delays could be not the best approach, or at least something to do after we look at the flow and how we can improve.

[danielbachhuber]

I would suggest that from a design perspective for a critical feature like saving adding in delays could be not the best approach

There's some existing prior art for this in WordPress core but I can't remember the component.

at least something to do after we look at the flow and how we can improve.

Yes, worth revisiting the entire flow.

[karmatosed]

There's some existing prior art for this in WordPress core but I can't remember the component.

Would be great to dig into that a bit and add context.

[karmatosed]

@danielbachhuber did you find the prior art on this?

[danielbachhuber]

I've looked twice now but can't find what I'm thinking of.

@azaozz Do you recall what I'm referring to, or do I have a false memory?

I would suggest that from a design perspective for a critical feature like saving adding in delays could be not the best approach

There's some existing prior art for this in WordPress core but I can't remember the component.

[azaozz]

Do you recall what I'm referring to

Perhaps you mean the delay/disabling of the Save Draft button after clicking it to prevent double clicks and doing two identical requests? That's a standard UI feature that is needed everywhere :)

With the addition of autosaves end point in the REST API, thinking the UI for saving drafts will need to change a bit. What I mean is the user should be able to save a draft at any point, but the editor will do autosaving on an interval (when there are changes).

The difference is when the user saves a draft "manually", they also create a revision, autosaves don't create revisions, just update the post directly or may update the autosave revision if the post author is different than the current user.

Also the client (i.e. Gutenberg) should probably do a "full save" for drafts from time to time instead of an autosave. This is a "weakness" in the classic editor/Edit Post screen; it would replace the whole post on autosaves and never create a draft, no matter what. However if the user did something by mistake, it will save that mistake with no way to recover from it.

[danielbachhuber]

Closing as maybelater. There's ongoing work to the save / autosave UX right now. I don't think this particular approach needs to be adopted as long as the UX improves generally.