draganescu
commented
4 years ago I second this as the "getting rid" of the autosave is very annoying in the current way.
Open afercia opened 5 years ago
draganescu
commented
4 years ago I second this as the "getting rid" of the autosave is very annoying in the current way.
paaljoachim
commented
4 years ago This is a bit more complex. We had a discussion about it during the Gutenberg Design Triage: https://wordpress.slack.com/archives/C02S78ZAL/p1595953914473900
I am also bringing this issue up during the Open floor for tomorrows Core Editor chat.
enriquesanchez
commented
4 years ago I spent some time going over this flow and this is what I found.
As reported in this issue, when there is an autosave on a published post, users are presented with a notice and given the option to view the autosave.
At this moment, updating the post is disabled.
Clicking on View the autosave takes the user to the Compare revisions screen. From this screen, users can only Restore the autosave or Return to the editor.
Clicking on Restore the autosave takes the user back to the Editor and automatically Updates the document.
There was no indication or warning that the post was updated. I would've expected to be able to preview the autosaved version in the editor context before being given the choice to update.
That said, If instead, the user selects Return to the editor, the autosave notice appears again. The only way to dismiss it is to click on the Close (X) button. However, this does not dismiss the notice permanently. If/when the user returns to the document, they will be presented with this notice again, until the end of times, or until new edits are made.
When there is an autosave on a published post, users are presented with a notice and given the option to view the autosave.
Although Updating the post is available, it won’t update to the autosaved version (at least not in my testing).
Clicking on View the autosave takes the user to the Compare revisions screen. From this screen, users can only Restore the autosave or Return to the editor.
Clicking on Restore the autosave takes the user back to the Editor and automatically Updates the document (again, I found this unexpected).
But here at least you get a notice of what just happened.
If instead, the user selects Return to the editor, the autosave notice appears again. The only way to dismiss it is to click on the X (close) button. However, this does not dismiss the notice permanently. If/when the user returns to the document, they will be presented with this notice again, until the end of times, or until new edits are made.
I think there are clear areas of opportunity in this flow, for both editors. I'll expand more in a following comment to avoid this one from getting too long.
enriquesanchez
commented
4 years ago I think this flow could be made more obvious and useful if we give users the ability to take a few actions.
When there is an autosave on a published post, users are presented with a notice and given the following options:
Preview autosave (only in Gutenberg) The autosaved version is previewed in the context of the editor and users should be able to choose between the autosave or the previous version.
Compare versions Users can compare versions in the revisions screen. From there, one should be able to restore to the autosave version (as it currently works), but also have the additional option to dismiss/delete the autosave version. If they choose to delete it, they return to the previous version they had in the editor and the notice is gone forever.
Dismiss/delete the autosave Both the notice and the autosave are gone.
Close button (X) Maintains current behavior. Next time the post is opened in the editor, the user is prompted again until they select an option from the above.
Thoughts?
MDWolinski
commented
4 years ago @enriquesanchez agree with your analysis of this issue.
The only other potential addition would be if the user should also have the ability to remove the newer version from the notice bar so a user wouldn't need to go into the comparison and then delete the autosave.
estelaris
commented
4 years ago I would add another clarification to the workflow when comparing revisions. In both of @enriquesanchez 's examples above, in the columns, the different content is identified with red and green. That to users may say what is wrong/right but it doesn't differ the autosave from the "other" version. I am not very technical and I am having issues to figure out which revision should I keep.
enriquesanchez
commented
4 years ago Here's a new proposed flow to handle the autosaves.
When there's an autosave, users will be presented with a notice, similar to how it currently works. This notice will now provide a couple of options: View autosave and Compare versions.
View autosave will let users see the autosaved version in the context of the editor. Once there, they can Restore or Delete the autosave.
Notice the 'Update' button being disabled until the user makes a choice.
The other option, Compare versions, takes the user to the 'Revisions' screen in wp-admin (the current flow). In that screen, the user now has the option to both Restore and Delete the autosave.
Clicking on the Close (X) button will maintain the current flow, where the notice is only dismissed but the autosave flag remains, so next time they open the post, they will see the notice again until they make a choice.
annezazu
commented
4 years ago I'm not a designer but thought I'd give some feedback in case it's helpful :)
How does this flow feel in general?
This feels a ton better than the current version. Less technical and more robust. I wonder if the word "recover" might be better than "restore"? I don't feel strongly but just a thought as I think of restoring as being a more intense action (like restoring from a backup). I worry that might confuse people.
Do you feel that you know what's happening on every step?
Yes! Although I found myself wanting a "Compare Versions" option in the "View and restore" GIF as I felt nervous about deleting. Delete is such a strong word and I feel like it might benefit from having the "Compare Versions" option there as well or some way to get back to the original. Not a dealbreaker but just a reaction I had. In general, I found having the delete option there made my mind go to waiting to have the option to keep it too 🙃. The human brain is an odd thing.
The other flows look great to me and make sense!
enriquesanchez
commented
4 years ago Thanks @annezazu, this is great feedback!
I wonder if the word "recover" might be better than "restore"?
I love "recover", yes I think it's better choice.
Delete is such a strong word
How about "Discard" instead?
Although I found myself wanting a "Compare Versions" option in the "View and restore" GIF as I felt nervous about deleting.
We wanted to avoid having too many options presented to the user at once, that's why we kept them to only two per step. That said, maybe a way to go back to the first step give users more peace of mind?
annezazu
commented
4 years ago Discard sounds great. I don't know how it would hold up when it comes to internationalization but it feels better and less severe.
We wanted to avoid having too many options presented to the user at once, that's why we kept them to only two per step. That said, maybe a way to go back to the first step give users more peace of mind?
Makes sense! Ideally, this would be an option but I understand the current flow doesn't have that either so it would be asking for a pretty big change.
All in all, super excited to see this coming together particularly as I just ran into the current flow earlier today 😆
enriquesanchez
commented
4 years ago Here's a revised prototype of the same flow described above. I've update the visuals and took @annezazu's feedback into consideration (thank you!).
I decided to try a different, but similar UI for this flow. I feel that it was putting to much weight on the notices UI, which was not designed and is not intended for this use case. This new UI is quite similar but allows us to break away from any constraints the notices UI may come with.
Only showing one part of the flow. Let me know what y'all think 🙌
draganescu
commented
4 years ago @enriquesanchez to make sure:
enriquesanchez
commented
4 years ago to get back to the previous state I should click the (X) and dismiss the autosave notice?
@draganescu Thanks for the feedback!
@annezazu had the same great observation. I initially didn't consider it but will definitively revise the flow so there's a way to take a step back.
I don't want to add another option to the main actions, but perhaps the "back button" can be part of the component's UI:
paaljoachim
commented
4 years ago Taking a step back....
Autosaving can be confusing as it crosses into revision/history states. Of a layout one might have forgotten about.
The existing approach as is seen in WP 5.5 and Gutenberg 8.7.1.
There is the View the autosave text link and the x icon. One can disregard the notice and keep working and click update button to save, but the notice is still there until the user chooses an action. If the user continues to work on the current layout then the notice should automatically be removed.
From the above visual example from @enriquesanchez Left arrow - Recover this autosave - Discard this autosave - X. It seems the Discard this autosave would have the same result as clicking the X. It looks a bit too complicated.
Bottom line. Autosave shows up. User just ignores it and continues to work on the layout. Adjusting and clicking Update button to save the content. Then the Autosave notice should automatically go away.
Autosave can very easily cross over into revision/history. The user can use the revision option if they need to go back, or use the undo button.
enriquesanchez
commented
4 years ago Here's another round of iteration, this time I'm exploring a flow where the user will "enter" into an autosave step by removing the top toolbar UI and instead we retain the user focus on the task at hand.
Worth noting:
mapk
commented
4 years ago This is looking amazing! I've always had problems with this notification, and your new design feels like a great balance between notifying and providing visual context to the decision.
To address your questions:
MichaelArestad
commented
4 years ago @enriquesanchez this is getting interesting as it's getting into visual diffs. When you enter the "compare" mode, it's no longer clear to me which side the Recover/Discard buttons are referring to.
I almost wonder if the entire top toolbar should "split" and have the author/label and the action above each side. Something like this perhaps (needs refinement for sure):
joanrho
commented
4 years ago @enriquesanchez Really nice explorations! Just sharing some thoughts here:
SNaushadS
commented
4 years ago in context of the autosave, i have some confusion. Probably its only me… Here it is In the comparison, we are showing Current | Autosave The latest one being towards the right makes sense that it should be the latest version…. however… i got confused with only the wordings… Is Autosave, more current than the Current ?
if others too feel this can be improved here is a suggestion: Having a timestamp with the Current (DD-MM-YY, HH-MM-SS) | and Autosave (DD-MM-YY, HH-MM-SS)
paaljoachim
commented
4 years ago I really like your latest version @enriquesanchez ! It is wonderful to have both versions side by side. The wording "Use this version" and "Recover" could be more like @SNaushadS mentioned. Kinda like: use version made 2 hours ago and timestamp or use current version.
As it gives a timestamp to when the older version was made in comparison with the version that is used in the editor.
Btw I do feel this method of changing/removing the top bar to place focus on choosing the autosave or the current version is a method that can also be used for other features (which features I am not sure off at this moment). As it is an interesting way to guide the user into taking a decision. Perhaps this is a method to be used somewhere in Full Site Editing....
enriquesanchez
commented
4 years ago Thanks for the great feedback everyone!
I worked a little more on the flow and here's the result:
in context of the autosave, i have some confusion.
@SNaushadS @paaljoachim Is it now clearer which version is which?
Can we bring back the code view here too so users can just toggle between visual/code views while in this autosave isolation mode?
@joanrho I had a little trouble figuring out a good place for this option, but I agree some users are used to it and even rely on it for certain flows. Where would you expect to find this option?
I think we should make the CTA buttons "Recover"/"Discard" clearer
How do you feel about the new button labels?
A few things I'm still uncertain about:
paaljoachim
commented
4 years ago Yes. It is a lot more clear now as the timestamp has been added.
Use case: I see the autosave notification show up but choose to disregard it and continue working on the current version. After having clicked update/save then the autosave notification should automatically go away. As I am in a way saying that I choose to use the current version and have made adjustments and even saved it. That I choose not to relate to an autosave version. The autosave version goes into the revision/history which if needed I can get back by clicking revisions.
Mobile. I am wondering if a toggle between current/autosave is needed. So the user can choose to jump between the two. I am also wondering if comparing current and autosave should be more similar to comparing revisions.
Comparing current <-> autosave is this actually revisions? Should clicking autosave bring up the revisions screen? Where we see the code. One side in pink and the other side in green. Or having a way to go between the split screen and the revisions screen? Or perhaps the revisions screen should be adjusted to look like the new split screen? Today the user is moved outside the Gutenberg screen when clicking revisions. Reworking the split screen to include revisions could be interesting way of handling autosaves/revisions. We could then have split screen (+ revisions features) for autosave and revisions. Creating a better consistency between how to handle older versions of content.
Btw This issue is somewhat associated: https://github.com/WordPress/gutenberg/issues/20957 "No visible timestamp for autosave."
SNaushadS
commented
4 years ago @enriquesanchez Thanks for the iteration. This appears much cleaner and short. The visual weight is also low now, as you've removed the avatar and used secondary buttons.
MDWolinski
commented
4 years ago So we're understanding of the flow of where this issue might come up, from my understanding, the user was editing a blog post that's saved in the local browser cache, but closes the browser before an autosave occurs. When the user returns to edit their post, the local version is different from the last autosave version, thus prompting this issue.
Right?
Does this prompt then stop an autosave from occurring until I either dismiss the alert? Or if I let my browser sit long enough will an autosave occur and make this issue...er...go away anyway?
Essentially, clicking the X is equivalent to choosing to use the local copy, which when chosen, should probably then initiate an autosave so the local copy/autosave are in sync.
This is separate from revisions, in my mind because the autosave is not necessarily a revision. If the user has activated revisions (and can we talk about the inability of a user to activate revisions without modifying their wp-config or theme file, just seems like there'd be an easier way for avg users to manage this or not, off soapbox) then a revision is created when the user clicks Update/Post button.
So in this workflow, there is a Saved post, the user is actively editing the document and Local Cache / Autosave is the interim state until the post is saved via Update / Post, thus creating a new revision.
As we talked about in Slack, I think this interface could be used to easily navigate between revisions, my team built a similar interface for one of our corporate sites to do that within the custom editor we use, I'll attach a screenshot below as a sample of this, but overall, this is probably an additional issue that references this work.
Mobile Version, my thoughts And since Enrique did a great implementation of my idea of using the divider line to highlight the differences (but I wonder if the line should be different from grey to just be clearer), I'll throw out a more radial idea for handling this on mobile.
What if, on mobile (small screens), the two versions are overlaid on each other with a slider to transitions from one to the other using transparency? Could even technically be done on large screens if people wanted, I guess. So with this interface, I could see the Local version at 30% transparency over the Autosave version and scroll through it to see the differences (the indicator of difference could be on the left or right margin depending on text flow).
Our Custom Revision Navigator
So at one of our corporate sites, this is the revision navigator we built...
It does function a little similar to the WP revision viewer, but because we work in a multi-user workflow, the navigator shows who created the revision and the date it was said. The star shows the current version, the blue shows the selected revision. If the revision is the same as the current version, then it indicates that there isn't a difference between the two selected versions.
Not saying this is perfect, etc, but as mentioned above, I can certainly see this issue being added on to include revision navigation as well.
paaljoachim
commented
4 years ago I have not read through everything again and might have missed something that I could have addressed....
There is an issue for "Offer to restore any available local post backup (instead of only the most recent one)" https://github.com/WordPress/gutenberg/issues/23955
Here are my thoughts regarding the general Auto save feature.
Autosave is just that the post or page automatically saves.
Gutenberg has an Autosave which fires every x seconds/minutes. One can see it says Autosaving. As it does here:
Today when we click the update button one sees this:
Since Autosaving is already a part of WordPress I do think it is better to just incorporate it as part of the saving procedure. Be it manual or automatic.
The main difference would be: With a manual update one gets the View page/post snackbar notification in the bottom. With an autosave no snackbar notification is seen. One will need to click the top black admin bar - view post/page to view the update.
Leaving a page/post and having clicked Save Draft or Update or there is an automatic save should not make a difference. Upon entering the page/post again it should just show the newest version independent of how it was saved.
I think we should just remove the "View the autosave" notification.
Much of what is being discussed above here really belongs to the revisions panel, and not a part of the auto save procedure. If a user does not agree on the point of where the post/page was manually or automatically saved then there are two options:
Undo/redo to arrive at a point they are satisfied with. Then clicking update/save.
Or use the revisions panel to compare the code of one version with another.
The Revisions Panel is something that really needs an update. Using the above comments I plan on creating a new issue to focus on how we can update revisions so they show up within the Gutenberg area and not exiting the page. There are a lot of good comments in this issue that I can use for rethinking the flow of the Revisions Panel.
paaljoachim
commented
3 years ago I am closing the "Rethinking the design of the Revisions Panel" issue I made: https://github.com/WordPress/gutenberg/issues/25270 So that we can keep the discussion going here.
paaljoachim
commented
3 years ago I am consolidating another issue: No visible timestamp for autosave. https://github.com/WordPress/gutenberg/issues/20957
From support forum: https://wordpress.org/support/topic/autosave-visual-feedback/ My Question is: How (or where) can I see (while writing) when the last Autosave has been executed. In the Classic Editor, there is a Indicator in the Status Bar “Last saved at nn:nn:nn”.
Describe the solution you'd like A simple way to see when the last autosave was made.
Autosave timestamps can be added into the revisions panel.
In the Classic Editor, when a published post has an autosave, there are various actions users can take including update the post and get rid of the autosave:
Instead, in Gutenberg the "Update" button stays disabled:
At this point, to get rid of the notice and of the autosave:
Instead, in the Classic Editor if users are OK with the post current state, they can just click "Update".
I'd like to suggest to introduce a way to do the same also in Gutenberg.