Safe Cut

EDITED TO ADD: I have been told Windows already does this. Oops. This is one of the few places Windows has a better UI then a Mac. For shame, Apple.

Finder lets you copy and paste files, but it does not let you cut them. Presumably, this is to make it hard to accidentally delete files. This means there’s no way to move a file using only the keyboard. It’s reasonable to trade a little speed-of-manipulation for safety. But, we can have both.

It’s easy to lose sight of what’s really going on when we use the cut/copy/paste metaphor from wordprocessing for file manipulation. Files are not blocks of text on a page. copying and pasting a file is really copying the file. (Unless you paste it where you copied it, in which case you are duplicating it, but there is already a command — ingeniously titled “Duplicate” and crafty placed under the “File” menu — that does this). Copy and Paste let you copy a file using only the keyboard.

Cut and paste (should) let you move a file using only the keyboard. A move operation is never destructive to the source-file being moved. You can destroy an identically named file in the destination location, by over-writing it with the source-file. But no move operation can destroy the source-file. But the first thing a cut operation does in word-processing is destroy it’s source-operand.

Here’s a solution: rather then immediately deleting the source-file, instead mark it (grey it out, and/or make it semi-transparent, and/or put an X over it) to clearly indicate that it is about to be deleted, and then finish the deletion once it has been pasted somewhere. If the user never pastes the file, and puts something else onto the clipboard, then the file should be un-marked. If the user moves the marked file around, or otherwise modifies it, then it should be un-marked. The source-file’s path should be kept in the clipboard until it is replaced by something else. This makes the modified cut-command’s behavior familiar to a user already used to the wordprocessing metaphor.

What about using this safe-deletion behavior in wordprocessing? My intuition is that it would be a bad idea, but only testing can give a definitive answer. In wordprocessing, visual layout is very important. Deleting a block of text changes the whole layout of a page, as text ‘falls-up’ to fill the gap. If an author issues a cut command, they immediately see how the deletion changes the layout of the page. Their decision of where (or if) to paste the text is affected by the page’s new layout. More importantly, safe-deletion is more complex, and the added safety is not necessary since wordprocessing programs all have powerful undo capabilities.

Explore posts in the same categories: Design, MacOSX, Usability

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

%d bloggers like this: