Wordpress-android: Restore trashed posts as drafts before editing / previewing them

[develric]

Draft issue to start tracking things, it will be updated as things/investigation progress further

This is related to the work in PR #10085.

We need to define how to manage trashed posts in respect to remote preview.

_We could change the current behavior and guide users to restore their trashed posts before editing and previewing_

Hi @maxme the above concept is an idea you suggested in a short chat on slack, please check if I misunderstood; thanks in advance for confirmation or integration 🙇‍.

I made a fast check in the iOS app (version 12.4.1 installed in my iPAD) and the behavior seems aligned with the above, so I suppose that could be the way to go, and I'm sure it was not a case that you pointed me in that direction right? 😊

NOTE: when this will be implemented, consider to remove the if in here a05aba815ad943d5430d38074ef54ae1baace40c . See this thread https://github.com/wordpress-mobile/WordPress-Android/pull/10085#discussion_r298629988 for more background.

[maxme]

We could change the current behavior and guide users to restore their trashed posts before editing and previewing

Yes, to me, it seems like the best solution UX wise.

We should probably look at the problem at a higher level and copy Calypso behavior and prevent all actions from the post list before trashed posts are restored as drafts.

Ping @osullivanchris this might be a small re-design project. Also ping @malinajirka since you worked on the post list update, I wonder if this was already considered.

[malinajirka]

I don't remember a discussion about actions in the drafts tab. However, the proposals makes sense and sounds good.

Perhaps @SylvesterWilmott, might have more background info.

[osullivanchris]

Although I'm not familiar with all the details, I agree with the premise that we should get the user to restore a post before editing it. Editing something in the trash feels a bit weird and will open lots of other questions, like what to do when they exit etc.

One case I would bring up - is if I trash a published post. If I go to the trash to work on a trashed published post, I would expect it to restore to drafts rather than published. Just wanted to mention that case so we don't miss it.

[maxme]

To illustrate this, here is the post list/actions for trashed posts in Calypso:

Note: on this page, clicking on post titles do nothing.

If we copy this behavior in the apps, that would mean:

• remove the edit/view actions from the Post list and only have "move to draft" (rename to "restore to draft"?) and "delete" (rename to "delete permanently"?).
• disable the tap action (currently open the editor) on the list item.

[osullivanchris]

This definitely makes more sense to me. Editing and viewing something that has been deleted ends up in some weird knots.

Sketch of how the proposal could look if we use Calypso pattern

Idea: It might also be a good idea to 'grey out' the image and text, to indicate the post itself is not interactive while in this trashed state, only the actions below.

Question for @maxme : if restoring a published post, today does it get restored to published or draft?

Need some feedback here from the design team as I don't know all our patterns yet cc @iamthomasbishop @SylvesterWilmott @mattmiklic Could someone give a quick look?
(a) is it ok to change these actions under some of the tabs? We already change the actions for certain error states so I think there's precedence
(b) do we grey out things that aren't interactive anywhere or have a pattern for that?

Thanks!

[iamthomasbishop]

I think this totally makes sense to hide the Preview action on a Trashed post. I'm not entirely sure how harmful it is to have it there, but I think the rationale for removing it makes sense and it simplifies the UI a bit.

[maxme]

Question for @maxme : if restoring a published post, today does it get restored to published or draft?

Any trashed post gets restored to draft.

Note: we actually lose the original status once a post is trashed. So we can't make a difference between a trashed draft or a trashed published post, it's just a trashed post.

[maxme]

I think this totally makes sense to hide the Preview action on a Trashed post. I'm not entirely sure how harmful it is to have it there

The "view" action is not harmful, but the edit action is (and it leads to a preview action, that shows the trashed post with current modifications from the editing session).

[osullivanchris]

Any trashed post gets restored to draft. Note: we actually lose the original status once a post is trashed. So we can't make a difference between a trashed draft or a trashed published post, it's just a trashed post.

Thanks for clarifying. That behaviour is what I would want.

The "view" action is not harmful, but the edit action is (and it leads to a preview action, that shows the trashed post with current modifications from the editing session).

It sounds like my proposal solves a lot of issues then. Implementation wise, is it ok for you? Just wondering whether we have a fixed 3 button layout or anything else which will cause trouble for you. Do you feel like you need a mockup or ok to work from the sketch?

[maxme]

It sounds like my proposal solves a lot of issues then.

Yes.

Implementation wise, is it ok for you? Just wondering whether we have a fixed 3 button layout or anything else which will cause trouble for you.

Probably not a problem.

Do you feel like you need a mockup or ok to work from the sketch?

The sketch is fine. I guess the dev who will implement that will ping you in the PR to confirm the final UI.

[osullivanchris]

@maxme Sounds good, lets do it!

@develric please let me know if you need any more input from my side, and get me to review whenever you have something to show! :)

[develric]

Hi @osullivanchris , AFAIU there has been enough clarification to go for a first round and follow up...currently this issue is not in scope with #10085 PR and will be addressed later, but I would really love to be the dev to work on it eventually! 😊 🤞

[SylvesterWilmott]

@osullivanchris Just thought I'd chime in on one thing. We will want to be explicit about where the post goes when it's restored - ie. either showing a message in a snack bar or something else or keeping the "move to drafts" button label.

[osullivanchris]

@SylvesterWilmott thanks for the tip! That's totally fair. Actually 'Restore' does exactly what 'Move to drafts' does. I didn't spot it in the more menu before. So we should just keep the existing one.

@develric @maxme Don't think we've built anything yet here. When we pick it up:

• rather than 'Restore' per my sketch, can we show the 'Move to drafts' action which already exists.
• Then we can also keep the toast messages that appear when the user selects that option.

Should make things simpler

[thehenrybyrd]

@osullivanchris I was doing some Trashed Post testing today as I worked on this iOS issue: https://github.com/wordpress-mobile/WordPress-iOS/issues/12121

Since you're working on Trashed Posts in Android, I thought I'd point out a few things I connected here.

First, iOS is considering allowing previewing from Trash: https://github.com/wordpress-mobile/WordPress-iOS/issues/6037
This would be very handy when trying to remember what that post was called which you want to restore. Being able to see the content would be really nice, and currently that's possible on Android.
I completely agree that being able to Edit from the Trashed Posts list is weird and doesn't make much sense, but it could be nice to keep part of that functionality as a preview.

I also noticed that Trashing a Draft changes the publish date to today, but Trashing a Published Post doesn't. When the Published Post is Trashed, it keeps its publish date, even when it is Moved to Draft. Only when it gets Published again does the publish date change to today.
Ideally, Published Posts would maintain their publish date after being restored as drafts and re-published.

[yaelirub]

Hey @maxme , what's the status on this issue? Do we need more people to review the PR?

[maxme]

This one was fixed via https://github.com/wordpress-mobile/WordPress-Android/pull/10185 but not merged in develop yet (still in a feature branch), that's why it's still open.