Improve saving

[swissspidy]

It's been a while since I looked at Gutenberg so I just installed the current plugin version (0.10.0) and gave it ago.

After a few minutes of typing and rearranging blocks, I was not sure if the post was already saved automatically and tried to manually save it. I couldn't find the "Save Draft" button so I first clicked on "Revisions" because I thought maybe there's a new revision. However, that unexpectedly took me to the actual revisions screen.

After going back, it took me a few seconds until I found the "Save" link in the upper left of the screen. Usually in the WordPress admin, there's only a page title in the upper left. I guess that's why I didn't think of looking at that area of the screen.

I think I'm not the only one who encountered this. Perhaps it's something that should be included in a few more user tests.

A few ideas to improve this:

• Move "Save" link somewhere else, e.g. to the right side of the screen or perhaps even combine it with the "Publish" button
• Improve visual indication when a post is saved, e.g. by making the message green.
• Add autosave functionality, again with a clear visual indication that the post was saved (periodically). In the current editor, such a thing exists below the textarea (inside <td class="autosave-info">).

[afercia]

See also #467 (toolbar controls order and grouping )

[jasmussen]

Good thoughts here. I'd like to defend the placement of the action, though. In the past there hasn't been a clear affordance for showing you when a post is auto saved. There's only been the explicity page reload and giant prompt at the top.

In modern web-apps, "Save" isn't something you do. Everything is always auto-saved. Look at Google Docs and many others — everything you do should always save. Not only that, but there should be a message that let's you know this, so you don't feel the need to save all the time. This feels like a pattern to emulate, long term, for WordPress: embracing the web nature of this. Long term we should remove the "Save" button, which is essentially the same button as it was in version 1.2, "Save and continue editing".

We're not there yet. There are actions that only fire when you explicitly click the save button, like saving metadata. We can't remove the save button. But we can give you an affordance for letting you know when auto-save is doing its thing. That's the area on the left: it is for information on the document save state, and it's there on the left to emulate existing editor patterns that also show this information there. The save button therefore sits there in context of the notice.

I understand why you'd want to move this to the right, but to me this feels like optimizing for the old way of doing things.

[swissspidy]

In modern web-apps, "Save" isn't something you do. Everything is always auto-saved.
We can't remove the save button. But we can give you an affordance for letting you know when auto-save is doing its thing.

Agreed. Even Google Docs shows "Saving…" for that. We need something similar, hence my suggestion.

Personally I'm happy to keep the button on the left side or remove it in the future if possible, as long as there's an indication about the autosave.

[jasmussen]

Personally I'm happy to keep the button on the left side or remove it in the future if possible, as long as there's an indication about the autosave.

There should be — are you not seeing this?

Edit: yes, there seems to have been a regression here. Finding a ticket to reopen.

[aduth]

Fix pending at #1301

[JJJ]

I, too, think the "Save" link is out-of-place on the left side.

This is crazy, but the "Publish" button could also be moved to the very bottom right. That would parlay well into the top-down completeness of actually publishing something.

Not that Quickbooks is the pinnacle of UX, but they've kept their "click here when you're done" buttons in the bottom right, and it's felt pretty natural to me.

We could also consider a combo-button approach for the "Publish" button, and hide "Save" completely under a drop-down menu attached to the side of it. That would reconcile the desire to abolish it with the desire to keep similar actions relatively close together on-screen.

[swissspidy]

See also #708 for the publish button.

[swissspidy]

I just installed version 0.2.0 and my content is still not being autosaved 😔 I hope it's being considered as it seems like this is the only issue really mentioning it.

[youknowriad]

@swissspidy yes, we will have auto-saving at some point. We're just focused on other issues right now. Feel free to PR :)

[slaFFik]

No autosave + I don't see Save button/link at all now, after upgrade to v0.2. Not sure if this is a bug or a feature, that's why writing it here.

[karmatosed]

I just fell into thinking it was saved (spoiler it wasn't) and being faced with a very old version. It struck me that I expected it to just save, whizz bang magic UX has spoiled me! I would therefore add a +1 to adding any magic we can, such as auto-saving. The sad feels I got on having to reconstruct my post was heart wrenching.

[swissspidy]

Worth noting that wenn you click on "Preview" in the current WordPress post edit screen, WP will save the post first so you can preview the latest version. This is another thing that should be considered. Preview = preview current state.

[swissspidy]

This is another thing that should be considered. Preview = preview current state.

See #1673

[karmatosed]

Worth adding some feedback from @helen via Twitter on saving/publishing:

@helen reported this via Twitter:

I don't think the preview button is triggering an autosave - it showed me a preview with stuff I had already changed.

The "Publish" button changed to "Update" right away even as it was working, seems like it should have said "Publishing" first.

[helen]

A couple technical things I noticed that are related to previewing are how taxonomy (including post format) and featured image changes are previewed - because we don't store that data for revisions (right now, anyway), it has to be handled a different way on published posts. It's not clear to me whether autosave runs for published posts - it seems like it doesn't right now, which means you can't preview changes to them, but also at least means that things like the featured image aren't being accidentally changed live. If there's a separate issue for handling published posts I didn't see, happy to move this over there.

[aduth]

Some related discussion to published post autosave at #1773 (comment)

[danielbachhuber]

@swissspidy Is there anything actionable remaining of your original report?

[swissspidy]

Whoa, didn't realize this was still open 🙂

Saving is much more intuitive now. Still have to get used to the publish workflow, but saving is fine.

It would be great if #2863 could be integrated though.

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.

[afercia]

For reference and history: the saving/publishing flow (even the new one) is still very hard to use with a keyboard only. I'd encourage everyone to test using only the keyboard. See #4187

[danielbachhuber]

Thanks @swissspidy @afercia. I've created #4644 for the micro delay suggestion. Closing in favor of linked issues.

[tecnogaming]

The auto-saving is a DISGRACE. On my website we are 9 writers/editors and it is absolutely impossible to work with with so much auto-saving going on. There are times that when we try to edit our articles we get locked out and have to wait up to a minute to edit/write our content because some other editor is writing. The auto-saving kills performance.

Gutenberg desperately needs an option on the configuration to remove autosaving or limit the amount it does, it's ludicrous. Frankly I'm shocked nobody says anything about this. They all must be using Gutenberg on tiny blogs.

My magazine has about 15 articles posted each day and has no less than 2500 unique visites a day and working with gutenberg has been a pain, all my writers and editors are complaining of really slow gutenberg performance and in my troubleshooting, autosaving is the single most important item that is slowing down the whole web.

Can you please add an option for remove auto-saving or limit the amount it does or should I need to start tweaking gutenberg code on my own to remove this?

[jwold]

@tecnogaming thanks for sharing your experience! It's really helpful to hear a use case from a larger content team!

For your team I want to clarify something and make sure I'm understanding correctly.

1. It sounds like you're having a lot of instances where a team member needs to hop into an article that another team member is currently working on. In that case they have to let the other team member know and wait until they're out? I'm not sure if post locking has been implemented in Gutenberg, so curious whether you mean actual lock out functionality.

2. Is autosaving causing performance issues because multiple team members end up working on a post at the same time and you get issues with conflicting revisions?

If you don't mind could you share a user journey example? That'd provide some great insight! For example, this fake example:

• John (our writer) starts writing an article in Gutenberg, and adds the title and a quick outline
• Jane (our photographer) wants to jump in and add a photo, so she has to message John to jump out
• John needs to get back in to write the first draft
• Jill (our editor) needs to then jump in to review the draft

[afercia]

For reference: post locking has not been implemented yet but it's being worked on, see #4217

[tecnogaming]

1. You can't seriously suggest that big team members all agree on how to work because of a limitation in Gutenberg. The system needs to work and not stall the website normal behavior. We don't edit 2 articles at the same time but WE DO edit several different articles at the same time. I'm not talking specifically about lock but decreased performance when multiple editors are working at the same time on different articles, it slows down saving a lot, this is NOT HAPPENING on the classic editor. I know this happens because they all started complaining of slow updates, slow posting, slow saving and the only thing that changed on our magazine is Gutenberg.

2. Multiple team members work on different articles at the same time. When this happens, the "saving" box could stay there for as long as 15 seconds. Saving is fast when I'm the only one around, which is about 4am in the morning.

Magazine is: https://www.tecnogaming.com

Work schedule for us:

6 writers work on regular news posting. Each post a new "news article" with pictures and galleries, each article is later repost to social networks. 2 editors working at the same time editing reviews of products (longer versions of news articles) with several images and image galleries.

This is happening from 10am to 6pm usually and the load decreases after that. Gutenberg appears to work fast when I'm the only one there.

Tags and categories are also a pain in the a** to work with. They don't show up, when load is high (all of us working) the tags shows empty and after exactly 35 seconds they show up. Categories are even WORSE as they can take up to 50 seconds to show up !!.

Writers and Editors are tired and in a really bad mood because of this. They decided to edit the tags and categories on the QUICK EDITOR, which works perfectly. I don't understand how Gutenberg can fail so miserably on something that was working perfectly fine previously.

Galleries are broken too. I have writers uploading galleries than when later I need to edit (as I work as editor) they show up as BROKEN and gutenberg ask me to convert it to HTML (which fails) or blocks (which fails also, turning the galleries into nothing). Each time a writer uploads a gallery, I need to re-do each gallery when I'm editing the article because they appear as broken.

As it is, I will just need to suggest the team to go back to the classic editor as Gutenberg is seriously hurting our performance.

[mcsf]

@tecnogaming, I suggest subscribing to #4217, possibly testing it early or at least in the next Gutenberg release candidate once that PR lands, and see how/if it improves your situation.

Another useful piece of information would be a log of the network requests associated with saving — as that would give a more accurate performance measurement of the requests themselves, compared to gauging from the response of the editor UI (the saving button).

Galleries are broken too.

This would be useful in a separate, documented issue in order for other contributors to have a look.

[tecnogaming]

#10169

#10167