An idea for a better trash

Well, as I have received no answer yet to the article on the interrupt handling model, I’ll leave it there for another week before starting work on implementation, just in case.

In meantime, I wanted to tell you about an interesting idea about file management which I’ve been toying with for some time.

In most GUIs, there are two mechanisms for deleting files. The first one is the trash, accessed via the contextual “Delete”/”Move to Trash” command or via the “Delete” key. Based on the real-world desktops, like many things in current GUIs, it implements a metaphorical trash which holds your deleted files so that you can reverse their deletion if it was a mistake, and must be emptied from time to time.

At the other extreme, we have a permanent deletion mechanism, akin to the UNIX “rm” command, and accessed via the Shift+Delete keyboard shortcut. This mechanism displays a confirmation dialog, and after that permanently removes the file from the hard drive.

Like real-world trashes, the computer trash system is boring. We can essentially separate two kind of extreme trash users, with few users inbetween: those who always forget about emptying it, resulting in the trash being filled with gigabytes of garbage unless another user of the computer does something, and those who empty it right after having deleted the file, effectively replicating the confirmation dialog of permanent deletion in a less convenient way. This has led many experienced computer users, like me, to avoid this burden altogether and disable or never use the trash mechanism, preferring permanent deletion instead.

Permanent deletion has however this big disadvantage that it is not very forgiving, like nothing should be in a properly designed user interface. For those of us backup enthusiasts who always have two copies of our mundane files and three for the very important ones, it does not matter much: if the file was not so important, we forget about it with a sigh, and if it was we go have a look at our backups in order to get it back. But although I plan to put as much emphasis on the importance of backup in this OS as is possible without making it annoying, I know that many people still won’t backup their data or will do it only infrequently because they have not experienced yet a big data loss and underestimate their importance. So it’s good to have some “damage control” mechanism like the trash around, to reduce the impact of failures.

So, what do we do ?

In my opinion, the big problem of the current trash system is that it is built around existing real-world trashes, which themselves are based on some constraints of the real world which do not exist anymore in computer software.

If we abstract ourselves from the constraints of this world, how should trashes work ? This way, in my opinion:

  1. You put a file in them to tell the computer that unless an unlikely event occurs, you won’t need it anymore.
  2. After some time (say, one month), you’ve forgotten about the file in the trash and it’s unlikely that you’ll ever need it again.
  3. To save space and make searches more efficient, the file should thus be permanently deleted at this point.

What are the key benefits of this approach ?

  • Users don’t have to care about emptying the trash and can think about more cheerful things instead.
  • Yet file deletions can still be undone, even after some time has elapsed.
  • Unlike traditional emptying, this process does not delete files regardless of their age, and thus cannot remove very recent documents which could be needed again based on arbitrary criteria.

In my opinion, the transition path from the traditional trash should be as follows:

  • Permanent deletion remains. If people are experienced enough to know about it, they are smart enough to find out about this innovation and reconsider their use of Shift+Del for everything.
  • This process is enabled by default and based on “Suppr”, like the traditional trash mechanism. This way, people who never empty their trashes and don’t care about settings will migrate to the new mechanism effortlessly.
  • The people who have to learn about this mechanism in order to take advantage of it are those used to the “Empty Trash” command.Thus, we should leave a similar command in the trash’s contextual menu. When clicked, it displays a polite and concise message telling the user about the new mechanism, and offering two options: cancelling the emptying of the trash or continuing to empty the trash. In the last case, the message will never be displayed again, as people who can’t give up on their old habits for something superior generally don’t like to be bothered.

19 thoughts on “An idea for a better trash

  1. whatever March 26, 2011 / 12:12 pm

    I’m not sure autodeletion based on time is such a good idea. Let’s use the example of personnal accounting. You may use your ledger file only once every month, so you won’t notice that it was accidentally deleted before it’s too late. Why not have different policies depending on the file size and/or MIME type? It is the big data files staying in the trash that are problematic. Autodelete time could be proportional to the file size. Like, if the user delete a 2gig video and doesn’t undelete it during the day, it’s very likely it can be disposed of safely. A 30kB spreadsheet? better keep it around, it won’t waste much disk space and can actually be needed much later.

  2. nnutter March 26, 2011 / 5:56 pm

    I don’t know what method Windows uses to maintain this capacity limit but it does allow you to set one. If it just deletes the oldest thing to make room for the newest then it would be similar to what you are suggesting. I suspect though that it just complains when it gets full. I like your idea, it is just like tmpwatch but for ~/.Trash.

    Change the storage capacity of the Recycle Bin

  3. dacresni March 26, 2011 / 7:44 pm

    didn’t this get slashdotted? would you put some of your thoughts on the replies?

  4. mappy March 26, 2011 / 10:26 pm

    How would you deal with a sensitive file that must be deleted, without emptying the entire trash history?

  5. Amenel March 27, 2011 / 1:19 pm

    Just a thought about data deletion and recovery, which is a non-trivial issue: the user’s life would be so much easier if the OS handled backup the way Time Machine does on Mac OS X or Oops!Backup does on Windows OSes. After all, managing resources is an OS responsibility, right? It shouldn’t be different for resources created by the user.
    In this scheme you proposed, I guess the “one month” period would be customizable and smart enough to adapt to the deletion patterns it encounters?

  6. zou March 27, 2011 / 6:48 pm

    that’s how it already works on Windows., give or take a few details.

  7. Leaflord March 27, 2011 / 6:59 pm

    I was thinking of a similar tenuring trash mechanism; although I think it’s kinda presumptuous to say “old habits for something superior” — occassionally I find myself in the need for a lot of space — for instance, if i wanna download large files. On the other hand, the way OSX shuts down is a useful way of catering to both type of users

  8. Hadrien March 27, 2011 / 10:41 pm

    Your example does indeed prove that a month would sometimes not be enough, however, I can’t imagine a situation someone could accidentally delete such a file except while using it… Well, whatever, let’s admit that it is possible. Computer users manage to do surprising tricks sometimes.

    I think that having MIME type-based policies is a bad idea, because there’s no perfectly established standard file format for many things, which means that there are tons of different file types which we can’t possibly all manage. Size could be a more interesting criteria, on the other hand, but if you put a very long deletion delay for small files it means that if you delete lots of them you’ll get a trash loaded with a gigantic heap of garbage, which is pretty hard to browse when looking for a specific file. Plus, size can also be a bit of an arbitrary criteria: let’s imagine a professional photograph who incidentally deletes a 2 GB RAW file which he is working on. If he does so on Friday, he may not notice it before the next time he turns the work computer on, next Monday. With a one-day deletion delay, that would be too late… Big files are not necessarily disposable media files.

  9. Leaflord March 27, 2011 / 11:30 pm

    I’d simply say that, any form of efficient mechanism has a bottleneck. Best would be rule-based bin with smart defaults.

  10. Hadrien March 27, 2011 / 11:40 pm

    I think I remember seeing “Trash is full” dialogs on Win98, so considering Microsoft’s love for compatibility that’s probably still the way it works :)
    Besides, the problem with such a size-based FIFO mechanism is that it has in some way the same shortcomings as real-world trashes: if you throw a shoebox (or something similarly big) in your trash, you have to empty it very soon, so you’ll lose many small documents lying on the bottom which could be recent and important.

  11. Hadrien March 27, 2011 / 11:43 pm

    No slashdot in the few thousands of hits I’ve got thanks to OSnews and reddit :)

  12. Hadrien March 27, 2011 / 11:46 pm

    There would still be some way to do permanent deletes when needed. I’d keep shift+delete for compatibility reasons, and we could also think about deleting a file within the trash to permanently delete it.

  13. Hadrien March 27, 2011 / 11:49 pm

    Yup, I think those backup, deletion, and recovery issues are important, hence this article :)

    In this scheme you proposed, I guess the “one month” period would be customizable and smart enough to adapt to the deletion patterns it encounters?

    Customizable yes, obviously, and one month is just an example, real-world defaults would probably be decided through user testing. On the other hand, I don’t understand the “smart enough” part, can you elaborate?

  14. Hadrien March 27, 2011 / 11:51 pm

    Yeah, it’s admittedly quite presumptuous. However, one has to admit that many users have quite a hard time ditching their old habits for something arguably superior – me included, in some areas.

    What’s special about the way OS X shuts down, by the way?

  15. Hadrien March 27, 2011 / 11:58 pm

    Indeed, it’s possible to introduce simple and predictable defaults (like “delete if 2 months old”), but allow for more complex deletion rules for power users and future releases of the OS, kind of like e-mail filtering in modern clients…

  16. Leaflord April 4, 2011 / 10:13 am

    My bad for the delay. Just that, it times the shutdown in case they made a mistake.
    Similarly, pressing “Empty Trash” can show a popup which says that the trash is being tenured with a button to purge all trash at that very moment..

  17. Hadrien April 5, 2011 / 11:42 am

    Oh, that…

    Myself, I’m not fond of it. I turn my computer on and off several times a day, and having to confirm something as mundane feels a bit wrong. Confirmations should be exceptional events, otherwise they lose their strength.

    I see two reasons why a GUI designer would want to do that:
    1/Make sure that users who hit the “Shutdown” by accident don’t suffer from the consequences
    2/Give users who still had unsaved files or something like this when they started to turn off the machine a chance to notice their mistake.

    In the first case, I’d say that one should better make sure that the user doesn’t activate shutdown by accident, e.g. by putting the power button away from the rest, as is the case with the physical power button of all desktops and most laptops.

    On OSX, what are the odds that someone will open the apple menu for anything but shutting down the computer or tweaking some settings, both options being put far away from each other in the menu ? On most macs, considering where the power button is located and how hard it is, what are the odds that someone will press it by mistake ?

    As for unsaved files, a shutdown confirmation is not an efficient way to manage them, because as soon as the user has spent a few weeks using a mac he just confirms shutdown all the time without thinking twice. Better allow unsaved files notifications to temporarily halt the shutdown procedure, ask the user what to do, and if he doesn’t answer during a specified delay, save the relevant applications’ state or hibernate in order to keep the data around.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s