Closed aerych closed 5 years ago
It's a different situation now there is a pseudo-auto-save. Draft will be sent to the server in most cases so reverting local changes won't be possible.
That's right. Reverting local changes would be possible only for non-drafts (published, scheduled) posts.
Although the situation has changed, I do think we need a way for users to discard changes they have made to a post.
Now we auto-save but users don't have a way to avoid auto-saving if they change their mind about the edits they made to a draft locally. Since we don't support revisions in the app, they can't undo that auto-save in the app — they have to go to a browser, find the revision, and reinstate the older revision.
I think the cleanest way to solve this would be to support revisions in the app. Are the missing APIs the reason it hasn't been implemented yet?
I wonder if we could use the undo functionality here. Like, bootstrap the undo history with one or two revisions back.
This would be unexpected and inconsistent. Agree w/ @0nko best bet is revision history.
This came up recently in support, where a user could not find a way to revert local edits in order to sync with remote edits on a post.
Internal ref: 183745-h
Another user brought this up after looking for a way to revert local edits from within the editor.
Internal ref: 184078-h
This came up in an app review with respect to the autosave functionality and the desire to revert or cancel changes made locally in the app editor:
This app has some glitches where it does not always connect to the latest posts on the website. So if you find and go to edit a post you might be editing a rough draft or old update . Then when you realize you exit out and then IT SAVES with out me telling to CAUSING me to lose lots of WORK. Please update so nothing gets saved unless you submit and tell the app to save.
Another user has requested a way to revert local edits.
Internal ref: #190420-h
Hey @sarahblackstock , in the meantime until we make this better, the "Revert" option becomes available after tapping the "Preview" button of a post with local changes. The post is then opened in view-only mode and the "Revert" appears at the bottom in a Snackbar. Hope this can help some users. Thanks!
Another user in support had trouble finding the option to revert local changes:
I'm on Android. I don't think this option exists to only purge local drafts yet then I think...
We can continue to instruct users how to do this, but it's not very discoverable as it is now.
(Internal ref: 196595-h)
What if we added a Revert menu button directly to the editor activity?
A user reported that they cannot revert local changes on pages, and I confirmed (in version alpha-65) that there isn't a way to get to the page preview when a page has local changes, so those changes can be reverted. Instead, when you view a page with local changes you get a live preview of the published page and no prompt to revert the local changes.
Steps to repro:
Result: You get a live preview of the published page, and no option to revert local changes. Tapping on the page itself open the page in the editor (again, no option to revert).
(Internal ref: 205434-h)
Thanks for the report @rachelmcr . That's a dead-end situation you describe above and yes, we should address it one way or another.
Request in support:
Add option to discard all local changes
internal ref: #230122-h
Having a revert function seems both a) simple and b) essential. This is genuinely making the app unusable for me.
This came up again in 272305-h. The user seemed happy after I guided them to the option to revert on preview, but it would be nice for the option to be more discoverable.
Another request for a way to revert local changes in 272701-h.
Recent app review:
I dare not open the app. Somehow dropping unwanted local changes to pages and posts is too hard for them, so if you do anything wrong you must go back to your browser to revert it. And it is equally hard to query the server whether a new version is there, so it will go ahead overwriting the server version if you just open your post in app, no warning of course, even if you make no change at all in the app! Allow for user mistakes, please. Phones and tablets are not platforms tailored for creating contents. It's a shame, the app should be so much more useful.
Another app review:
This app looks like it is incomplete... In particular, if a page or a post have local updates they cannot be discarded, and might overwrite recent updates made from the site.
App review:
And there is a minor issue concerning the updates of the archives which always causes my phone not to synchronise properly when I finished an article on the computer, saying "local draft" instead. 5* if you get that fixed. Thanks.
Two star review:
I'm writing a blog with my gf and this app has reeatedly caused us problems because you cannot discard changes! Also, sometimes (most of the time), the posts are not properly updated with their versions in the server, so one may open a stale version, and because the changes are always uploaded to the server, the latest changes are overwritten by the version cached in the app. Add to that that, sometimes, the latest version disappears from the history and that means you cannot recover it! Very annoying and makea you kose work!
We received more feedback around this in 284077-h. The user is editing pages, not blog posts, and doesn't have the option to revert local changes.
I also have this problem. I just wanted to look at a page using the app, and now it says that I have local changes. How do I get rid of the local changes?
We're scoping to tackle this issue in the near future.
I spent some time last week thinking about this issue, and think there's two parts to this:
A stop-gap solution: a way to discard changes/restore to the previous draft/version in the editor once you've edited a post/page
Full revision history, a much-requested feature: a new UI similar to Calypso's "History" that would allow users to manage their entire revision history
Considering mobile Gutenberg will bring some larger changes to writing flow and some time limitations, I decided to tackle the stop-gap fix first.
(Note: Full Revision History will be coming soon! I've already got designs for a v1 in the works)
The idea here is to allow users to quickly revert changes inside the editor, without disrupting the overall writing/saving/auto-saving flow that seems to work well for most cases. They always have access to the undo/redo options, but this is a shortcut to bounce back quickly.
It would look something like this:
The flow is as such:
•••
will show a menu. User can access undo
/redo
and discard changes
from this menu.Discard Changes
will present a confirmation dialogDiscard
will essentially revert the post/page back to the previous remote-saved (not auto-save) version, and close the editor, then show a snackbar to acknowledge the action was taken.I'm also open to keeping the user inside the editor after revert, but it might be more obvious what's happening if the editor were to close.
Any thoughts, @aerych, @SiobhyB, @hypest ?
I'd vote for a quick stop gap in the short term and let revisions be the end goal.
I think the reason we're setting this issue reported so much has to do with how easy it is to make a local change in the editor. Try this:
Note that you are not prompted about unsaved changes before returning to the post list like you are in the iOS app. Now that you're back on the post list you can see the post has local changes, but there is no way to know what those changes are except to remember what you did, and no way to dismiss them. They are retained when the list is refreshed. I think we can address this particular scenario and see these reports quickly drop off.
I'd missed this comment from @hypest (thanks for the nudge sir!). So its not true that there is "no way" to revert the changes for posts, but the ability does seem a bit hidden to me.
Any thoughts?
I'd opt for the stop-gap solution too @iamthomasbishop , thanks for considering the options there.
One clarification question about the flow design, will the "discard changes" option become available when user opens up a post that already has local changes? Like, changes performed in a previous editing session but haven't be synced/uploaded yet to the server.
Yes, this comment from @hypest works for posts but unfortunately does not work for pages. Does anyone have a stop-gap solution for pages?
One clarification question about the flow design, will the "discard changes" option become available when user opens up a post that already has local changes? Like, changes performed in a previous editing session but haven't be synced/uploaded yet to the server.
TBD I think.
Does anyone have a stop-gap solution for pages?
Not currently.
I think we need to align the language we use here. I like "Discard Changes" as @iamthomasbishop has in his designs which feels like something that would be more widely understood than "Revert".
I also propose using a yellow colour to match the styling of the "Local Changes" label on the post list level and including the option to discard as the last item in the ellipsis menu with the reasoning that it shouldn't mess with the order of the other permanent items.
Also +1 for either a confirmation or the 'Undo' action. But I'm not sure we need both.
Can you explain why this is closed? It doesn't appear to be fixed in 10.4. Might be fixed in Beta, I don't know, because beta program is full.
The issue was closed since the associated pull request (i.e. https://github.com/wordpress-mobile/WordPress-Android/pull/8005) was merged into the develop
branch. That pull request has the 10.5
milestone, which means the changes will be included in the 10.5
release.
Thanks for clarifying. I've found and installed the apk for 10.5, and I now have the option "Discard Local Changes".
@theck13 confirm that even after discarding local changes, the flag/yellow label of existing local changes in post list don't go away ?
The yellow "Local changes" label will be removed only from the post for which the local changes have been discarded.
Here's an example. I have a list of three posts. The first two have local changes. I tap the second in the list to go into the editor, discard the local changes in the editor, and return to the post list. The first post in the list will still have the yellow "Local changes" label while the second will not. See the screenshots below for illustration.
Mobile request originally reported by @rachelmcr
Follow ups by: @catehstn
@0nko