Exploration: should we prevent user to leave the editor without publishing changes?

[maxme]

In Calypso, when a user edits a published post (classic or block editor), if the user click on "Close", they'll get a dialog asking

When the device is online, should we show a similar dialog and ask the user if they want to update their post?

Note: when the user does this on an unpublished post, Calypso won't prevent the exit, it will save changes as a draft (or update)

[shiki]

My gut feeling is we shouldn't and perform an auto-save instead. However, for self-hosted sites, they don't have auto-save right? So we have to show it. I think it will be confusing if have different behaviors so my recommendation is to show the dialog. 😄

It looks like this is what we do on iOS too.

[shiki]

Subscribing @wordpress-mobile/ravenclaw

[maxme]

My gut feeling is we shouldn't and perform an auto-save instead.

I think we should define what's the expected behavior in the most common cases and direct the user to that behavior. To me, the expected behavior is to publish your changes [1], so if the user hit back we should give them the option to publish.

Also having a dialog is not a huge flow breaker and it's a good reminder that the back/close button won't publish your changes.

[1] only in certain cases you don't want to, like if you are in a middle of an edit and want to check another post or browse the reader, but I think this is not the most common behavior.

However, for self-hosted sites, they don't have auto-save right? So we have to show it. I think it will be confusing if have different behaviors

I agree, this is confusing.

[shiki]

To me, the expected behavior is to publish your changes [1], so if the user hit back we should give them the option to publish.

Based on the funnels you created in paCBwp-84-p2, it looks like users generally Discard the changes. For my personal experience with other editors, whenever I press Close, I'm always in a hurry. If there is a Publish button in the confirmation dialog, I might accidentally press it. I usually don't read confirmation dialogs when closing something. 😄

What do you think, @megsfulton?

[megsfulton]

@iamthomasbishop this overlaps with online editing behaviors so would like to get your thoughts on it.

For high impact actions (like publishing) and destructive actions (like discarding changes), I like to err on the side of giving the user control over what happens rather than deciding for them.

In this case, where the user has made changes to a published post, the options they have are:

• save the changes locally
• discard the changes
• publish the changes

If they want to publish the changes they've made - tapping the "Update" button is the most straightforward path to that.

When they tap the close button, I think the choice is between saving the changes as a local revision or discarding the changes.

[malinajirka]

For my personal experience with other editors, whenever I press Close, I'm always in a hurry. If there is a Publish button in the confirmation dialog, I might accidentally press it. I usually don't read confirmation dialogs when closing something. 😄

Yep, I totally agree!

For high impact actions (like publishing) and destructive actions (like discarding changes), I like to err on the side of giving the user control over what happens rather than deciding for them.

💯

When they tap the close button, I think the choice is between saving the changes as a local revision or discarding the changes.

When we save the changes as a local revision/locally, we can also remote-auto-save them, right? What might ruin the UX a bit is that the remote-auto-save stores just title, content and excerpt so if the user decides to finish the post in a browser, they might not notice the other settings (feature image, tags etc) were not synced.

[diegoreymendez]

For my personal experience with other editors, whenever I press Close, I'm always in a hurry

I totally agree with this!

I LOVE our current approach in Android in that it doesn't require any action from you to actually close the editor.

Currently:

• When editing a new post: pressing back saves the post as a draft and exits the editor.
• When editing an existing draft: pressing back saves the changes to the draft.
• When editing a published post: pressing back saves the changes locally.
• When editing a scheduled post: pressing back saves the changes locally.

We could improve this further by incorporating autosaves (when supported) for published and scheduled posts. But I digress.

[iamthomasbishop]

Sorry for the delay in my response! I've got a lot of thoughts on this, but I'll try to condense to the most relevant to this discussion 😄

My opinion (short version):

In the context of Aztec/single "mode" editing, @megsfulton proposal makes sense. With that said, I'm hesitant to recommend any structural changes that might be discarded (😉) with mobile Gutenberg, so fair warning.

My opinion (the long version):

As a preface: There will most likely be some big changes to the writing/viewing flow coming up in Mobile Gutenberg, my gut is to be cautious about structural changes here. Also, my preference differs between the current Aztec flow (single "mode") and Gutenberg (which will be a split-mode editing flow).

To the issue at hand: do we alert the user that they might have unsaved changes to a published post? If we're talking about the current structure (Aztec, or a single editing "mode"), I think Megs' proposal makes the most sense. As much as I find it convenient that Android doesn't bother you while exiting – it might be useful to confirm with the user what they'd like to do. I also agree that we probably don't need to add the Publish action to this confirmation.

Moving forward with GB, once we move to a split flow (Edit vs. View), the responsibilities shift slightly, particularly for the Discard Changes action. Theoretically, we won't ever have to alert the user that there are unsaved changes when they're closing the editor because they will already have tapped the √ button (to save changes) or the option in the ••• menu (to discard changes). In other words, that decision will already have been made. I hope this helps to visualize:

[malinajirka]

I know it's a minor thing, but just for the record.

Theoretically, we won't ever have to alert the user that there are unsaved changes when they're closing the editor because they will already have tapped the √ button (to save changes) or the option in the ••• menu (to discard changes).

They can still hit the "back" (hw/sw) button on the device, right?

[iamthomasbishop]

They can still hit the "back" (hw/sw) button on the device, right?

They can but it's a bit more complex. A couple of scenarios in edit mode:

If typing:

• Hitting "back" action via the system navigation bar (OR performing new LTR-swipe-back gesture on Android Q) hides the keyboard and stays in edit mode.

Else:

• "Back action" brings you back to view mode – essentially same thing as the √ action.

See Google Docs on Android for reference.

[osullivanchris]

This has been on my list to get through and I've finally found time to think it through. As I pick it up though, I'm not 100% sure why its an offline issue. Seems like a both offline and online issue. Anyway my two cents on this

Draft Posts Out of the options we could give the user when they leave the editor

• Publish: is now very prominent in the action bar. If the intent is to publish, it seems like tapping back/up is unlikely. Further, we even offer a confirmation dialogue when publishing. This implies that we view publishing as a very deliberate action.
• Updating the draft: feels like the natural happy path. You write something but aren't ready to publish it yet.
• Discard changes: a sad path of sorts. Can be achieved by other means (revision history, undo)

Proposal: The approach I've taken with some similar issues is going with a smart default.

• In this case, the smart default would be close to the current Android flow, where we assume you want to keep the changes you made.
• The tweak would be to add the alternative path. This could be done with the toast message. The toast message could say 'Revert' rather than 'Publish'. We can dig into the numbers but we have strong locations for publish already which seem more appropriate than the toast.
• If the user hits 'Revert' we push them back a version. So the changes they just 'discarded' are still there too :)
• I've even added a further confirmation toast telling the user they have reverted, with the option to see all revisions if they really wanna get in the weeds on the matter.

The most important thing in this proposal is that I believe the flow is frictionless in the happy path. Whereas today there is friction in both paths on iOS (have to make a decision every time). Updating a draft is a reasonably non-destructive non-committal action so I feel its not gonna cause too much pain as a default.

Published Posts Following the same logic, I would save locally as a default. Its the non-committing non-destructive action. Again, if the user wants to publish the action is there prominently on the card and on the toolbar. We don't want to confuse them with too many ways to do it. We want clarity and confidence for publishing.

And if the user doesn't like the changes they made to their published post, and didn't get to the toast in time, they still have two means of retribution:

• revision history
• simply not publishing it, and leaving it there as a draft, with the published version still live.

Offline Things would work roughly the same. They'd just be local drafts rather than online drafts. But that shouldn't impact the user too much. It only matters when they go to publish, which we're working on separately.

Side Note On iOS and Android we have a different icon with slightly different implications

• Back icon on Android feels in tune with what I've proposed
• The 'x' icon on iOS is a bit more ambiguous. Sometimes 'x' can mean close, but it can also be a destructive icon in other cases. To be true to the current iOS paradigm I think a down chevron would actually more accurately represent what is happening (closing an overlay without destroying work)

[iamthomasbishop]

@osullivanchris This is a great approach and it lines up well with the approach I was imagining on Gutenberg – well done! I especially like the flow you described attached to your sketch. A couple of very minor thoughts:

• Regarding X (iOS) vs <- (Android): On Android, the current back arrow makes sense. I agree we should change this on iOS, but I would consider a text label ("Done" or "Close") as an alternative that is more common on iOS for this type of scenario (see Apple Notes, Dropbox Paper, etc). Another alternative would be the "default" < Posts (or < Pages when editing pages). The caveat is this brings internationalization into play.

• The "see revisions" label on the snackbar might be a bit long, perhaps "see all" would work considering the message says "Reverted to a previous version".

[osullivanchris]

@iamthomasbishop Thanks really glad to hear it lines up with what you're thinking!

Those two are totally fair bits of feedback. Will take into account when I work on this further, will just wait for any other feedback from the team before I iterate. The iOS icon for example, might not be necessary as part of this task. But I think it would be an improvement. The copy I'll get reviewed before we build in any case.

[shiki]

Thank you, @osullivanchris. The proposal is looking good.

I'm concerned about this. I consider "Revert" to be a destructive action. I would guess that users would probably not use this a lot. As a user, I would also worry about not tapping on that and might pause for a bit to let the snackbar disappear.

Self-hosted sites do not have revisions history. Were you thinking that they would rely on manual changes instead? Just curious about your thoughts on that. 🙂

[osullivanchris]

I consider "Revert" to be a destructive action

I tested out the revision history. If I have a v1 and a v2, and I revert to v1; v2 is still there also. It might feel destructive, and so we could somehow make that more usable/obvious. But I didn't intend that reverting would delete the work, it would just roll back a version.

Self-hosted sites do not have revisions history. Were you thinking that they would rely on manual changes instead?

I didn't think that through. I didn't realise that Self-hosted sites don't have revision history. I'll have to think that through - but if you have any ideas I'd be happy to hear!

[dangermattic]

Thanks for reporting! 👍