Allow restoring a deleted page about collectives HOT 8 CLOSED

In GitLab by @azul on Aug 6, 2020, 09:17

https://goodui.org/#8 recommends offering undo over asking for confirmation:

Imagine that you just pressed an action button or link. Undos respect the initial human intent by allowing the action to happen smoothly first and foremost. Prompts on the other hand suggest to the user that he or she does not know what they are doing by questioning their intent at all times. I would assume that most of the time human actions are intended and only in small situations are they accidental.

Deleting the page currently moves it to the files app trash. So there kind of is an undo mechanism already. We just do not expose it in the ui.

I can imagine different ways of offering undo:

• adding an undo button to the "Page was deleted" success message
• greying out the entry and adding an restore button to it
• adding a trash to the list of pages

They would last for different timespans. The undo button in the dialoge is gone once you click away the dialogue. The greyed out entry would disappear once you reload the page. The trash could be shown as long as there are pages in the trash.

Implementing the trash seems more complex then the first two options.

from collectives.

Thanks for your feedback @marinkaltani, much appreciated! We're currently working on a collective-wide trashbin for deleted pages.

from collectives.

In GitLab by @azul on Aug 6, 2020, 09:19

@mejo- I changed this from a confirmation dialog to an undo / restore option. Would that work for you?

from collectives.

Mh, very interesting. Thanks a lot for double-checking UI changes for best practices before implementing them. 😊

I agree that an undo dialog would be even nicer.

After a first quick look into the (filesystem backend) mountpoint topic it might be that a whole lot of file app features (trash, version history, further sharing, ...) will not work out of the box anymore and need custom implementations. So I'd suggest to postpone a decision here until we got a better picture of the implications of planned backend changes.

from collectives.

In GitLab by @azul on Aug 6, 2020, 16:34

So I'd suggest to postpone a decision here until we got a better picture of the implications of planned backend changes.

Sounds good.

from collectives.

In GitLab by @azul on Aug 11, 2020, 21:43

marked this issue as related to #52

from collectives.

From design review call:

• Expandable page trash ("Deleted pages") at the bottom of the page list.
• Allow to open deleted pages read-only (but not edit/change them).
• Allow to drag&drop to/from deleted pages.
• Restore action in three-dot menu (will move page/subpages back to its original place)

from collectives.

Yesterday a colleague deleted the whole contents of a collective (leaving only the root Collective existing, but empty), because of a misteke in using his webdav Files client.
I was luckily able to spot it by checking the web server logs, where I found the recursive DELETEs. Otherwise I would have said it "misteriously disappeared".
As you know Collectives are available via Webdav for client side editing too (no Collectives UI is protecting them).

For this reason in my humble opinion a trashbin is an expected feature. Mistakes in deletion can happen without the user even being aware of it.
Alternatively, an option to decide wether or not Collectives may show up in Files should do.... not sure how many people really use them in Files or via webdav client. Even the page in Files is suggesting the user not to use it.

Hope this helps in your decisions.
Thanks and Regards

from collectives.