Implement Offline actions - posting/scheduling/deleting while offline

[diegoreymendez]

When you create a post and you hit “publish now” a toast “Device is offline, changes saved locally” is shown

Decision

Android

• Improve labels according to the design Improve labels on post list items when a post is pending upload #10207
• Add support for the Cancel action Add cancel publish/schedule/submit button to post list items #10206
• Add support for trashing/restoring posts in offline Add support for trashing/restoring post in offline #10205
• Automatically upload all local changes not just local drafts Automatically upload posts with local changes #10174

[shiki]

This contradicts with #9565. That issue is saying that we don't see anything but this issue saying that we do. 🤔

[malinajirka]

This contradicts with #9565. That issue is saying that we don't see anything but this issue saying that we do. 🤔

It seems the description of #9565 has been updated.

We are currently considering following this principle App initiated actions should not override published content. If we decide the principle makes sense and we want to stick to it, I think we can close this ticket. The toast will be replaced with Snackbar and a better message in #9565.

[shiki]

We still have to discuss whether we should schedule posting in the background or never publish if the user is offline.

@maxme @diegoreymendez

[diegoreymendez]

If there's no urgency in closing this one, maybe we can freeze it for the time being?

I currently don't have the bandwidth to peek into this, but feel like I'd like to understand a bit more before reaching my own conclusions.

PS: it's ok for me if we set it's priority to low, or assign it to a "Frozen" column in the project.

[shiki]

I think we can just leave the priority as is and work on the high priority issues for now. We can continue discussions later.

This is how things currently work right now:

• Android: Publishing while offline and retrying will lead to the post being uploaded and published
• iOS: Publishing while offline and retrying will lead to the post being uploaded as a draft

I'm not sure which one is right but Android's behavior is scary for me as a user.

[shiki]

Subscribing @wordpress-mobile/ravenclaw

[yaelirub]

Labeled at "13" as it needs discussion

[malinajirka]

This is one of the long-going discussions which is a bit difficult to close as all the solutions seem to have some downsides.

When I click on Publish/Update I kind of expect the post will be published as soon as possible.

Possible downsides

a) The device can become online after a week - imho it doesn't really matter and it sounds like an edge case scenario.

b) The user wants to cancel the upload - they can still open the post in the app and change its status from "publish" to "draft" in the Post Settings. However, I agree this option is quite hidden. We might want to consider adding it to the Post List.

c) The user updates the post in Calypso before it gets published from the app. This can be a real issue as the app could override the remote (the most up to date) version. - for me this is the biggest deal and I think it won't be an edge case scenario. I think we could modify the api and start sending "remoteModifiedDate" in the "PushPost" request and if the post has been modified in the remote, the api could just return an error and we'd require a user interaction.

Wdyt?

[osullivanchris]

I had an idea on 11420 which I believe is related

Could we prompt the user with a toast or other message when they come online. Saying 'your post is now ready to publish do you want to go ahead'. We could also send a push notification to the device, as we can't assume the user is in our app, and they might not come back in the time they expected to publish.

Then we get the benefit of showing the user we've followed up when connectivity returned. But without the fear of something happening unexpectedly.

[yaelirub]

@osullivanchris, I like the idea of prompting the user before publishing when going back online or/and update the status to "ready to publish" though I think the latter should be split up from this especially since we're in talks of refactoring post activity.

Imo, the bigger downside from @malinajirka's list is C (The user updates the post in Calypso before it gets published from the app) and I believe the prompt will solve this.

@malinajirka , @diegoreymendez can you think of any foreseeable issues with taking this approach on both platforms and moving forward with its implementation?

[diegoreymendez]

@yaelirub - I'd just be interested to see the actual UI/UX flow for this (I think it'd probably need some new screen?), but definitely no objections on my end.

[malinajirka]

Could we prompt the user with a toast or other message when they come online. Saying 'your post is now ready to publish do you want to go ahead'. We could also send a push notification to the device, as we can't assume the user is in our app, and they might not come back in the time they expected to publish.
can you think of any foreseeable issues with taking this approach on both platforms and moving forward with its implementation?

I have been thinking about this and I can see two potential issues

1. Imagine the user clicks on "Publish" but their connectivity drops for 5s -> we'd show "your post is now ready to publish do you want to go ahead" after 6 second since the user clicked on Publish.
   (We can solve this and make sure we show the prompt only when the post is older than x minutes/hours).

2. This approach works great when there is only a single post in the queue. However, we can't show more than one SnackBar message. We could show more system notifications, but the UX might be a bit clanky.

Both the issues above are solvable, but I just wanted to point out there will be some bumps on the road we'll need to fix.

For me the ultimate question is whether it's worth the effort. Honestly, I'm not even sure it'll be an improvement for the users. The scenario that the user doesn't want to publish a post they wrote and tried to publish seems like an edge case to me - in which they can simply go back to the app and move the post back to draft.

So if it were up to me, I'd make sure we publish only posts for which the user confirmed publishing + I'd fix the "bug" on the API which allows you to override changes in the remote with an older post. However, if you think showing the prompt is an improvement worth the effort, let's do it:).

I think this is one of the cases where having a deadline makes sense. So if there are no objection against the approach Chris proposed till Wednesday (3rd of July 11:59pm), I'd move forward with the design proposal + implementation.

[osullivanchris]

Thanks for the feedback folks! I worked through the flow as @diegoreymendez suggested and it turned up some issues, also discussed with @malinajirka . Lets take a quick look

Issues:

• If we want to have a rule about only confirming with the user after X time, e.g. 1 hour...we make a lot of assumptions. In 5 minutes a user could open their laptop and make a change. On the other hand, if the user really intended to post they might still expect that 2 days later. So we can't make assumptions about time, and I'm going to remove that dimension from proposed solutions
• When the user returns online we have to show some kind of alert / toast / push notification. Whichever one we choose, the user might ignore / accidentally tap outside, etc. Or it could appear at a moment that doesn't suit the user, they might not be engaged with our app etc.
• If we are asking the user to confirm publish again, its not far from just not publishing it. Its almost the same as just keeping it a local draft. Either way they have to act to publish again. Ok with a prompt, but not much is gained.

PROPOSAL
Here's a second iteration which is bolder and simpler.

When the user chooses to publish and we don't get an internet connection, a toast appears saying (placeholder) "Offline. Publishing when connection returns" with the action "Cancel".

• This assumes the user wanted to do what they said they wanted to do!
• Keep in mind we also showed a confirmation dialogue so the user intent is high
• If the user is unhappy with the outcome, the toast message provides a "Cancel" action (alt title: revert to draft)

On the post card, there is a label saying "Publishing when connection returns" and it stays in drafts for now (as it is not published)

When the user returns online

• The post is published
• The post is moved to the 'publish' tab
• The label is removed
• The timestamp is updated to the time that the post was published
• A toast appears "Post published" with the action "View"
• Of course if the user doesn't want it published anymore they could go into it and change it back to a draft

Outstanding issues

• Copy review. Tagging below. If someone is looking at it from editorial could you look in combination with 9949 (this one is posting while offline, the other ticket is scheduling a post while offline)
• @malinajirka @diegoreymendez @yaelirub what do you think the middle action should be on the post while it is in the ready to publish state in the middle image in the flow? In the sketch I had 'Cancel'

[osullivanchris]

Attaching mocks which should clarify the final design and copy for this issue, #9949 , #9558

[shiki]

That's awesome, @osullivanchris.

On the last image, bottom right, I believe you wanted to say:

- SnackBar "Sending to trash cancelled"

Or something along those lines.

[diegoreymendez]

For "Post Published" and "Post Scheduled" it looks to me like the "View" button offers you a way to identify the relevant post, but when offline-deleting I wonder how that notice with the "Undo" button would give you context. I can see myself wondering what post the notice is referring to (as these notices can come up while you're in other sections of the App as well).

Also, any thoughts on adding a timeout for these scheduled operations? If we're publishing a post that was last modified a month ago, that's probably a red flag and it's something we should be able to check rather easily.

[malinajirka]

I've created three new sub-issues and added them to the decision section above.
#10207
#10206
#10205

At least #10207 and #10177 should be released in one version of the app so the UX is consistent and predictable.

[yaelirub]

Thank you so much, @malinajirka ! I've updated the title to reflect the subtasks and the decision.
@malinajirka , @maxme , @shiki , can you please estimate these?

Also, any thoughts on adding a timeout for these scheduled operations? If we're publishing a post that was last modified a month ago, that's probably a red flag and it's something we should be able to check rather easily.

??

[osullivanchris]

@yaelirub @diegoreymendez I think per the discussion on paCBwp-bF-p2 it makes sense to put a time limit on it. I will try capture what that would look like today.

It might need to be a separate / sub-task. Something like 'timeout for offline actions'. We can start with a sensible assumption: cancel the task after 48 hours. I just want to take a look at what it looks like when the user comes back online after 49 hours. Just to make it clear to them what has happened/what state the thing is in.

48 hours might not be "perfect" but its sensible and once we put it in place we can get some feedback and learn if a different time period is more optimal.

[malinajirka]

@osullivanchris As we discussed the design proposal doesn't cover all the statuses. Here is a list of all the statuses with some proposals.

---

In the design proposal

Publish draft in offline | Edit published post in offline
SnackBar: “Post will be published next time your device is online”
Label: “Post will be published next time your device is online”

Schedule post in offline | Edit scheduled post in offline
SnackBar: “Post will be scheduled next time your device is online”
Label: “Post will be scheduled next time your device is online”

Post trashed in offline (trashed post can't be edited)
SnackBar: "Post will be sent to trash next time your device is online"
Label: "Post will be sent to trash next time your device is online"

---

Not in design proposal

Save draft in offline | Edit draft in offline
SnackBar: “Device is offline. Post saved locally.”
Label: “Local changes”

Submit post for review in offline | Edit post submitted for review in offline
SnackBar: "Post will be submitted for review next time your device is online"
Label: "Post will be submitted for review next time your device is online"

Publish private post in offline | Edit published private post in offline
SnackBar: "Private post will be published next time your device is online"
Label: "Private post will be published next time your device is online"

Restore in offline
SnackBar: "Post will be moved to drafts next time your device is online"
Label: "Post will be moved to drafts next time your device is online"

Note: AFAIK we currently don't store the original (remote) status of the post. Therefore we can't differentiate between "first time publish vs edit of an already published post". However, we are probably going to start storing the original status in some other PR and as soon as it's merged we can start showing different messages if we want to 🤷‍♂.

SideNote:
Btw I also realized we created a ticket for "Add support for trashing posts in offline" and not for restoring. So I just modified the existing ticket as "offline restore" will be pretty straightforward as soon as "offline trash" is implemented.

[diegoreymendez]

It might need to be a separate / sub-task

100% agree @osullivanchris

I'm a big fan of separating work into atomic tasks when possible.

[yaelirub]

@malinajirka ,

Btw I also realized we created a ticket for "Add support for trashing posts in offline" and not for restoring. So I just modified the existing ticket as "offline restore" will be pretty straightforward as soon as "offline trash" is implemented.

Brilliant!

Not in design proposal

Do these need copy review?

@osullivanchris , @diegoreymendez , opened and issue for offline actions timeout
#10214

[malinajirka]

Do these need copy review?

Yes, but I wanted @osullivanchris to see them first.

[osullivanchris]

@malinajirka this is really great stuff. Thank you for capturing all those cases. I think the ones I worked through are ones which would create the most anxiety for users, so if its working for those cases, I'm confident we can carry the solution through to these.

Do you think we need mocks? It seems like we've landed on the same UI for all cases, so capturing the content seems like all that we need to me.

@yaelirub this copy approach originally came from the editorial team per this comment
#9949 (comment)

We've expanded the approach from just "Post will be scheduled next time your device is online" to "Post will be [outcome] next time you're offline". I like the consistency of the approach. If we're agreed on everything else but feel we need one more copy review for confidence please let me know or tag away!

[malinajirka]

I think the ones I worked through are ones which would create the most anxiety for users

That's what I assumed, but I felt like that when we are touching this part of the code it makes sense to improve all the cases. Thanks for clarification.

Do you think we need mocks?

I don't think we need mocks for these cases. Thank you for asking though!

"Post will be [outcome] next time you're offline". I like the consistency of the approach.

Private post will be published next time your device is online this sentence starts with Private but it should be fine, right?

[diegoreymendez]

Part of the problem I see with how we're moving forward with our discussions, is that we're sometimes not opening new issues when it would help make things clearer.

In the case of this specific discussion, editing the initial ticket in place means:

• Some comments are now outdated and are hard to follow.
• We're missing an opportunity to remove a lot of noise from the discussion history.

I'm closing this issue now. I opened the final decision issue here: #10224

Any new conversation pertaining that issue should happen there.