-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auto-Save #221
Comments
@pbakaus is the autosave interval 30 seconds? or is it configurable somewhere? |
I don't think we should make it configurable for now, unless it's configurable in Gutenberg. /cc @samitron7 |
WordPress' default autosave interval is 60s I believe, and can be changed using the |
ok great. Let's use the constant, and therefore 60s. |
Gutenberg allows users to trigger a save ( as draft ). As we are not saving on keypress like google docs, we will need to do something similar. Thoughts @pbakaus |
Related: #85 |
@pbakaus @samitron7 In WordPress, when there is an auto-save of a Published story that is newer than the saved post (e.g. the browser crashes or is closed without saving first, however, there's an auto-save created), this notification is displayed: Should we have something similar to notify the user there is a newer, auto-saved story available? |
@miina so, WP expects you to effectively press "save" button manually from time to time to explicitely save the state? otherwise shows this? If that's like it works, I'm torn - I kinda like the simplicity of conflating auto-save and regular save. Thoughts, @samitron7 and @o-fernandez? |
https://wordpress.org/support/article/revisions/#autosaves Seems that this is, in essence, done to never overwrite the last thing the user saved. So WP has a revisions which are when the user explicitly saves, but there is only one autosave which is there in case the user navigates away, goes offline, etc. before they have a chance to save. So, the principle WP follows is that:
That behavior makes sense to me if we are creating and storing revisions each time the users saves, and exposing the revision history to manage it. Otherwise, I think we can go with a simpler autosave implementation for now. |
@pbakaus Yes, auto-save is a separate auto-save post kept in a database. Independent of the revisions -- in case of a published post, the auto-save saves into the "backup" auto-save post, never the post itself -- otherwise, the published post would be automatically overwritten which definitely should not happen without the user explicitly prompting it. This means that in case of published posts, the user needs to click "Update" to actually update the published post. The auto-save is still kept as a back-up though -- for displaying previews for example (already implemented), also, it would become useful if the user has worked on an unsaved (published) post for quite some time and then the browser crashes or the connection fails, etc. In this case, the notice mentioning there is a newer auto-save could be helpful to let the user know that the changes did not get fully lost meanwhile. Thoughts? |
@o-fernandez That should work, I'm mainly missing the UX part here though -- probably reusing the WP default notice wouldn't be the best option. WDYT? |
Let me tag this for UX consideration @samitron7 This can happen because autosaved versions in WP do not overwrite the saved revision, they are just a backup/fallback in case the browser crashes, etc. But users are expected to explicitly save work before leaving the browser (they are reminded to...) So the question is, how do we show this in the UI for story editor? |
@o-fernandez it'd be great if you could take this on and make sure the product definition/needs for both 1.0 and beyond is clear. You might use my prev spec on the topic as foundation. Does that work for you? |
I'm fine with that. Yes.
In the future we will do the UX work to support revisions properly and, once we do that, we can also consider the proper 2-file approach to autosave in which user can "restore/recover" from autosaved file in case of a crash, but otherwise autosave won't impact the revisions/saved drafts. @miina let me know if this is what you also understand the approach we'll take to be. Happy to iterate on this if there is a better alternative. |
@o-fernandez @miina I think before making a final decision on this we should take a look where the two-file approach is now. It seems to me that it must be pretty functional since we are using it for preview. And if so, it might be easier for us to use it right away then doing auto-save disabling/etc. E.g. we might be at a place where we can relatively easily enable auto-save into the second (draft) file and offer a user a chance to re-publish it. |
@dvoytenko IIRC the main constrain at the moment is UX bandwidth, figuring out the right way to show users the second file and restoring from it, which is why I think we discussed going down the proposed path in my last comment. If it would be much easier to do the 2-file approach, let's discuss with @samitron7 and @pbakaus and properly do overall prioritization and think through the timeline. |
@o-fernandez It might be a significant UX effort, but I'm not yet convinced that it will be. And depending where things are technology wise, you may be able to make the necessary UX calls yourself and we can refine them with UX later. For instance, we might end up in the following situation: Currently we do:
It's possible that we may just need to change this like this:
This is too many buttons in the last one. We could instead remove "Unpublish" and stick it somewhere on the side panel or into a "...". I'm not sure how commonly people would want it. We can definitely punt on this, but for posterity, I'd definitely want to understand:
|
@dvoytenko Here is the current PR for auto-saving which is addressing this issue: #1361 With this PR.
Current state for Published post:
Things that need doing for enabling restoring an auto-saved post in case a browser crash:
If we decide to not implement auto-saving for a published post right now, the PR mentioned above should already be ready (other than adding some tests). We could easily add auto-saving for a published post separately once we have UX. Note: all this is independent of revisions, these should be investigated and looked into in a separate issue. |
@o-fernandez @miina IIUC, this sounds like covers all our needs for the flow I described above. The only thing that's missing here is one more action to |
For a published post, I think the key options that we need to give the user are:
The one thing I don't know how to add there is to have a way to "revert to published version" button. In essence, once you publish and then you make edits, the edits you make are autosaved to the 2nd file but not published. You need the option to either Publish them or Revert to the published version. Does this make sense? May be worth to chat live about this and iron it out, if we want to go down this route. Otherwise, I think just not autosaving once someone has published, only option being to republish before they navigate away, it's an OK approach for now. |
@o-fernandez It makes sense. But if we count, auto-save as an action, we have the following actions total for a published post:
Some of these actions do not need to be displayed maybe. Some only need to be displayed when new changes have been saved. Some could be hidden inside a "...". Etc. I think we just need:
|
We could make an API request to pull in the data from the latest auto-save, prepare it, and then use |
Perhaps it would make sense to create a new issue for all the actions described above, it looks like the original issue (auto-saving for a draft) is clear for now and will be closed with #1361. Thoughts? |
@miina I agree. @o-fernandez lets open the followup issue on the two-file approach. |
Ok, I agree. Let's then keep this ticket to what it is (per the description) and we can have another ticket if things change. |
Blocked by #1247
As an author I want my progress auto saved so I don't lose my work.
Feature Brief - Epic: Document Workflow
Note: Save is in #521 and this ticket is for adding Auto-Save
Acceptance Criteria
Note: Save/update does not save the undo/redo stack. Undo/redo is tied to the current client state.
The text was updated successfully, but these errors were encountered: