drive
drive copied to clipboard
fission-codes
Implement a 'Trash' concept
Summary
File managers usually have a 'trash' concept - so should we.
Problem
Drive will happily remove files with no confirmation dialog and then offer no way to recover in the case that this was an accident - we could mitigate this by implementing a "trash" folder in drive which is where all files go that the user wants to get out of their way.
Impact
Users might assume that removing files from Drive has some of the UI safe-guards in place like confirmation prompts and a trash can / recycling bin, and might be surprised to learn that the file they removed really is gone for good.
Solution
We should provide a trash-can / recycling style folder in the root of Drive that is where all files go to when they are removed. We should also use the same terminology eg
- trashcan -> send to trash
- recycling bin -> recycle
- hellmouth -> banish
Super interesting. This would be extremely lightweight, since we have all of the files in history already, so just pointers. We can think of this as "recently removed" (whiiiiich is... a trash, so yeah 😛)
Also worth noting that this is probably a WebNative feature directly, but leaving here for now because it largely powers the Drive UI
Also worth noting that this is probably a WebNative feature directly, but leaving here for now because it largely powers the Drive UI
My strategy has always been - log the bug against the thing I'm looking at as my assumptions about the thing underneath that powers it can be quite misguided.
@therealjeffg Yup, you did the right thing! Agreed on working outside-in; just wanted to flag it for posterity