I love the fact that one of the usability issues identified 25 years ago in windows is still the case today.
* If you "cut" a bit of text, it disappears from your document, and unless you later paste that text, it's gone forever.
* If you "cut" a file, but never paste it, the file stays in its original location, contrary to the users expectations.
This kind of thing is really the implementation details showing through into the UI (the clipboard is not a place on disk, and cannot have files and directories moved into it)
This is likely why in macOS, you can’t cut files but instead have to copy them and then move them with Command-Shift-V (holding down Shift changes the title of the Paste menu item) — the intention to move the file is indicated on the pasting half of the operation, dodging the Cut issue entirely.
Also, cut never really made metaphorical sense for files… you don’t break out the scissors to transfer documents from one folder to another.
I get the menu item to change name with option, not shift.
Incidentally I've been using a Mac for decades, but I never remember to check what modifiers do. I'd always just copy and then go back and delete.
I think the right way to deal with this is to have a fancy clipboard manager / shelf, frankly. Cut things, they're put on the shelf, paste pastes in the top thing in the shelf. I suppose lots of people might just end up with cluttered shelves and lose track of stuff. But the shelf concept is a good GUI power user thing.
What happens if you "cut" an important file, and then forget to paste it before copying something else? You could easily loose many hours of work!
That can happen with text too, of course, but because text takes up more screen real-estate, selecting lots of text "feels" dangerous, so you're less likely to accidentally screw yourself.
--
When you "cut" a file in early Windows, did it disappear from the original location, or did the icon fade out as on modern platforms? IMO, the fade makes it clear what is happening, and is a great example of how minor visual tweaks can be imbued with lots of meaning.
Windows 95 behaved like Windows does today: "cutting" a file faded out the icon until it was pasted someplace else.
Prior versions of Windows did not have an equivalent to the "cut" operation; for example, Windows 3.1's File Manager moved files via a "File > Move..." menu option, which opened a dialog with two text fields to specify the source and destination. (Copying behaved similarly; the document-editing-inspired Ctrl-C, Ctrl-V, and Ctrl-X bindings used today were all introduced for file management in the Windows world in Windows 95.)
Cutting a file sets its hidden attribute. If you have turned on display of hidden files then they do indeed appear faded, but you have to be a fairly advanced user for that – for most people they will just seem to disappear.
If you cut or copy another file the the first file will be unhidden, and I suppose also on a clean shutdown. Overall it's still confusing for a normal user who doesn't see hidden files, especially if they intentionally used cut without paste to delete a sensitive file.
I've always thought it'd make a lot of sense, for any modern OS, if every time you cut something, you'd be creating a .scrap on the desktop; and then, if you later pasted it, the .scrap would go away. Desktop-as-spool-directory. Same as the way macOS tried to use the desktop as a spool for screenshots until recently (where now the screenshot spool has become a mysterious locationless storage displayed in an ephemeral modal window.)
This doesn't work well with multiple drives. If you cut an object from a usb stick, should it get transferred entirely to your desktop (maybe taking many hours for big files), for you to then paste it somewhere else on the usb stick? (When a direct move would be near instant).
If instead you want a .scrap directory on every volume, you have a new inconsistency - if something is cut, and the device removed before the paste happens, the paste will fail.
Ah, I wasn’t really suggesting that the (contents of the) clipboard be immediately serialized to disk, but rather that an OS built-in clipboard manager be created that exposes its contents as shell objects living on the shell Desktop (rather than the filesystem Desktop.) So every cut would put a shell object onto the shell desktop, but this would just be a handle to a memory object living in the clipboard manager. Pasting would move that object from the shell Desktop, to the shell Trash, such that emptying the Trash would get rid of it; but it wouldn’t really be “in” the filesystem Trash either.
If you select and copied the shell object on the shell Desktop, you’d just be making the “selected” clipboard handle the one referenced by the shell object.
If you moved the shell object, you’d be instantiating a physical filesystem .scrap object at the destination.
And, of course, since all this is simulating something persistent, you’d expect the clipboard manager to make each clipboard object refcounted, and not get rid of objects as long as something (e.g. a shell object) holds a reference to them; even meaning that the clipboard objects with nonzero reference-counts would need to be persisted to an OS “clipboard database” on shutdown, such that the shell objects referencing them would still be valid on next startup.
I'm honestly impressed that they thought so in depth about these things. That said, I'm of the opinion that a clipboard manager should be a standard part of an OS and would arguably solve this problem.
This wouldn't have been considered a problem in the 90s, but my concern with clipboard managers is that they would end up containing a lot of sensitive information, particularly passwords from my password manager.
(Not that this isn't a concern otherwise, but there's a difference between a pasteboard that holds one piece of information at a time and immediately purges old information, and one that logs history for an extended period.)
Clipboard managers, such as the one that ships with Windows 10, allow applications such as password managers to mark something to not be stored in the clipboard history. KeePass supports this functionality as an example.
Yeah, my concern is that the user won't necessarily be copying from a proper password manager. Passwords are not the only information that people copy and paste: there are credit card numbers, SSN's, drivers license info, etc etc.
You could argue the security trade-off is worthwhile, and I might even agree if the clipboard manager isn't enabled by default. A clipboard manager requires you to treat your clipboard in a certain way that I don't think users do in practice.
It isn't enabled by default (currently) but there isn't really anything you can do to protect someone who copies important out of a text document and/or leaves open access to their desktop anyways without annoying them so much they work around it in an even worse way. Same thing with browser autofill and password managers.
* If you "cut" a bit of text, it disappears from your document, and unless you later paste that text, it's gone forever.
* If you "cut" a file, but never paste it, the file stays in its original location, contrary to the users expectations.
This kind of thing is really the implementation details showing through into the UI (the clipboard is not a place on disk, and cannot have files and directories moved into it)