Implement Offline actions - posting/scheduling/deleting while offline

diegoreymendez commented 5 years ago

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

Decision

Offline Actions

Android

[x] Improve labels according to the design https://github.com/wordpress-mobile/WordPress-Android/issues/10207
[x] Add support for the Cancel action https://github.com/wordpress-mobile/WordPress-Android/issues/10206
[ ] Add support for trashing/restoring posts in offline https://github.com/wordpress-mobile/WordPress-Android/issues/10205
[x] Automatically upload all local changes not just local drafts https://github.com/wordpress-mobile/WordPress-Android/issues/10174

shiki commented 5 years ago

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

malinajirka commented 5 years ago

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 commented 5 years ago

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

@maxme @diegoreymendez

diegoreymendez commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

Subscribing @wordpress-mobile/ravenclaw

yaelirub commented 4 years ago

Labeled at "13" as it needs discussion

malinajirka commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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

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).
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 commented 4 years ago

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 iteration1 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. iteration2-proposal

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'

michelleweber commented 4 years ago

This copy seems pretty straighforward; let's just make sure we keep the language consistent across this and the other issue, specifically on/offline vs. connected/disconnected and the simple "offline" vs. "device is offline."

malinajirka commented 4 years ago

I love this proposal! It's way simpler and the user is always aware of what is going to happen. Moreover, it requires less taps/interaction which imo is almost always a plus.

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'

I like the idea of having a "cancel" button. Regarding the copy itself, I think that as long as the button has the same color as the text ("publishing when ..."), the user will connect the dots what they are canceling... Another option would be to use "Move to draft" action which we use in "Trashed" tab - however, since its copy is long, I think we'd need to put it into the "more" section and we "couldn't" use the color.

osullivanchris commented 4 years ago

@malinajirka ok cool, let's stick with cancel and use the same colour as the warning, as that seems to be the pattern that we use right now.

Happy to call this ready from design side. There's no new UI but do ping me if you need to see a mock, or have any other clarifications.

diegoreymendez commented 4 years ago

@osullivanchris - This is some fine work! I really love this proposal!

@malinajirka - Can I ask you to update the initial issue description to match the work we're going to do (or create new issues / close existing ones according to this outcome)?

It'd also be a good idea to chat with @yaelirub to see if this needs to be split and if we can propose an estimate.

shiki commented 4 years ago

I added subtasks on the description based on the discussion. Please feel free to change them if I missed anything.

osullivanchris commented 4 years ago

They sound right to me @shiki !

yaelirub commented 4 years ago

Thanks for pushing this forward @osullivanchris and for the proposal. Let's split this into 2 issues, one for updating the messaging and the other for adding the cancel button.

@osullivanchris, I know this passed editorial review but I think the message "Offline. Publishing when connection returns" is a bit confusing and doesn't seem quite right to me. First, I'm not sure we should say offline. I haven't seen other apps use that word and think it might not be clear for everyone, especially in localization (In Hebrew for example the direct translation wouldn't make sense) Second, i think "publishing" is confusing. Who's publishing?

Are you attached to this copy? Can we make some adjustments?

osullivanchris commented 4 years ago

@yaelirub thanks for the feedback. I think its fair. I had a look across publishing, scheduling and deleting while offline. I think the proposal in scheduling is really good and can work across all three. I would use the same messaging in both the toast message and the 'state' message on the card.

Lets go with

Publishing Post will be published next time your device is online

Scheduling Post will be scheduled next time your device is online

Deleting Post will be sent to trash next time your device is online

osullivanchris commented 4 years ago

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

Offline Actions

shiki commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

I've created three new sub-issues and added them to the decision section above. https://github.com/wordpress-mobile/WordPress-Android/issues/10207 https://github.com/wordpress-mobile/WordPress-Android/issues/10206 https://github.com/wordpress-mobile/WordPress-Android/issues/10205

At least #10207 and https://github.com/wordpress-mobile/WordPress-Android/pull/10177 should be released in one version of the app so the UX is consistent and predictable.

yaelirub commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@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 https://github.com/wordpress-mobile/WordPress-Android/issues/10214

malinajirka commented 4 years ago

Do these need copy review?

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

osullivanchris commented 4 years ago

@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 https://github.com/wordpress-mobile/WordPress-Android/issues/9949#issuecomment-507233927

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 commented 4 years ago

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 commented 4 years ago

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: https://github.com/wordpress-mobile/WordPress-Android/issues/10224

Any new conversation pertaining that issue should happen there.

wordpress-mobile / WordPress-Android

Implement Offline actions - posting/scheduling/deleting while offline #9555

Decision