Hacker News Reader

Comment by throwaddzuzxd | Hacker News Reader

> I don't think you've ever actually used a Mac.

For the last 2 years I've used a Mac professionally and personally. I switched from Windows because lots of things are better. Finder is not one of them. And your answers should give you a hint why it sucks.

An empty file is a file that is empty, with the name and extension I chose on the moment I need it.

>And yes you can cut. Cmd-C, Cmd-Opt-V.

With the wrong keyboard shortcut, the correct one universally being Cmd-X.

>And yes, there's a way to go the parent folder. SEVERAL: > >- Go -> Enclosing Folder > >- Cmd-Up > >- Right click on the window title and choose any enclosing folder from the tree > >- Show the Path Bar and double click any enclosing folder from the tree

Several ways, none being the correct one. Nice. I know Apple likes hard to discover shortcuts but this is ridiculous.

View on HN

Generally speaking, macOS uses option or shift to modify existing commands. Hence cmd-c / cmd-(opt)-v. The paradigm is Copy -> Move or Duplicate.

In Windows, it's Copy or Cut -> Paste. I don't mind this change from Windows. Actually, I slightly prefer the Mac version, because I can change my mind on what operation I want to do. Windows front loads the choice, and I have to do it again if I decide I don't want to copy or cut anymore.

As for folder nav/manipulation, I find Finder to make much greater sense, whereas Explorer was just, this makes sense because it's always been this way (don't get me wrong, Finder has its shortcomings in other areas, although File Preview [space bar] is pretty awesome).

Finder: Generally speaking, arrows do everything.

* Movement within folder: up/down arrow keys

* Move out or into a directory / into a file or app AKA open it: cmd up/down

* Expand/contract a folder: left/right arrow keys

* Rename a file/folder: Enter

Explorer:

* Movement within a folder: up/down arrow keys

* Move into a directory / open a file: Enter

* Move out of a directory: alt up

* Expand/contract a folder: left/right

* Rename a file / folder: F2

> In Windows, it's Copy or Cut -> Paste. I don't mind this change from Windows. Actually, I slightly prefer the Mac version, because I can change my mind on what operation I want to do. Windows front loads the choice, and I have to do it again if I decide I don't want to copy or cut anymore.

That's not just Windows, it is the way the copy/paste model works absolutely everywhere outside Mac's Finder. And there is a clear reason why it makes sense, and why the Finder way is just bad UX: the decision about what happens in location X should always be done when you are in location X.

So, if you navigate into a folder and select a file that you want somewhere else, you are currently in the best position to decide whether you want the file to stay here as well (copy) or no (cut). Then, you can go somewhere else and just add the file in that location (paste). Furthermore, on Windows you can paste the file to several places, with predictable semantics: the file will be copied to each of those places (though performance of this operation may be suprising).

I can't even begin to imagine on Mac if you copy a file the Cmd+opt+v it to multiple places. Does it move it around, deleting it from the previous place where you pressed cmd-opt-v???

Edit: I was entirely wrong about the part about copying to multiple places, which does undermine my point considerably.

> That's not just Windows, it is the way the copy/paste model works absolutely everywhere outside Mac's Finder. And there is a clear reason why it makes sense, and why the Finder way is just bad UX: the decision about what happens in location X should always be done when you are in location X.

Hmm, the first part isn't convincing. To me that sounds like "everyone else is doing it" and not much different than arguing between left side vs right side driving, when there could be a third way, like teleportation. Not saying Finder is quite that much of a shift, but Finder's method does have semantical differences, and not just "hey we're cmd+n/m for cut/copy".

As for the second part, I think that's an intriguing argument, but "bad UX" seems like a stretch. If it were truly always decided in location X, would you have to return to location X to cancel your copy/cut? No, because that would be far too strict. It also depends on what your mental model is of what has been decided at location X.

On macOS: I have decided I want to manipulate the data in this file at location X. I can decide to copy or move it later at location Y.

On Windows: I have decided I want to cut XOR copy this file at location X. I can decide location Y later.

I personally like the ability to chain my decisions after. Based on your edit, I guess you've already discovered, but yes on macOS, you can issue a copy command once, then duplicate it and/or move it as many times as you want, to multiple places, even if you choose a move command first. Only location X's copy is altered if doing a move.

I'm not even sure if that would be possible on Windows without going back and forth between location X and Y to switch between copy and cut (my wintel machine is down at the moment).

> * Move out or into a directory / into a file or app AKA open it: cmd up/down

3 years of using a Mac now, I would never have figured this out on my own.

IMHO stupid to put the most common operation on a file behind a meta key.

The ratio of how often I rename a file (rarely) vs use a file (often) doesn't come out in favor of this choice.

That said I realize the decision was probably made long long ago and now Apple is just stuck with it.

Still though.

Maybe after another few years I'll figure out the hot key to change between the side pane and the main file list.

(yes I could just look it up, but I do most of my work in terminal and I try to avoid Finder as much as I can, I really dislike using it)

> With the wrong keyboard shortcut, the correct one universally being Cmd-X.

I think there's no right or wrongs in keyboard shortcuts, but there are traditions. Both Windows and macOS has their distinct histories and traditions with inspirations from each other. I think it's equally wrong to point a finger to a Windows machine and shout "Why you don't have a command key, you inferior OS-Wannabe?"

Some machines work different from each other. Sun and other Unixen had super, hyper and meta layers on their keyboards with hundreds or more shortcuts. They weren't wrong either, just different, and IMHO cool.

> Several ways, none being the correct one...

Again, if we're going to throw stones, I can name a lot of shortcomings in Windows from file names to other small/backward stuff, but it'd be equally wrong. They are just different systems and have different choices.

> I know Apple likes hard to discover shortcuts but this is ridiculous.

Just open the help menu of an app and write to command you want to find. It'll show it on the menu. Pressing enter will directly run that action.

>I think it's equally wrong to point a finger to a Windows machine and shout "Why you don't have a command key"

Well actually I think the control/option/command paradigm makes more sense than ctrl/alt/super, so yeah, I'd love this being copied by Microsoft. It's harder than just supporting Cmd-X in the Finder though. Adding Cmd-X to Finder is just a net gain, it doesn't even require deprecating or breaking anything. It just brings a standard to an app that should support it.

> With the wrong keyboard shortcut, the correct one universally being Cmd-X.

I think no matter what you do here, you have a problem. When you press ctrl-x on a file in Windows explorer; you're not really cutting it; nothing happens til you paste! (Unlike using cut anywhere else).

Both Windows and MacOS end up with a bit of a strained metaphor here; I don't think it's at all obvious which way is _correct_.

>I don't think it's at all obvious which way is _correct_.

From a UX perspective the answer is pretty clear. Copy/Cut/Paste is the winning paradigm, which empirically makes it the correct way.

But, again, this isn't really cut and paste at all. It's more like "note position, and _then_ atomically cut and paste". Cutting and pasting files in Windows doesn't work at all like cutting and pasting anything else.

Someone who had never used Windows might reasonably expect, on finding 'cutting' a file did something, that if they never pasted the file would just be deleted, because that's how cut and past normally works.

In fact, I have used Windows since 3.11, and until reading your comment I thought that cutting without pasting would delete the file!

That's not true at all! The moment you cut a file on windows it is marked as hidden, which makes it disappear with default settings. It's treu that unless you paste it it will remain there in practice, but the UX gets it right.

Furthermore, you can cut once and paste to several places, with predictable semantics identical to every other implementation of cut+paste (though performance of the first paste will be different from subsequent ones).

Edit: I was entirely wrong about the second part, which does undermine my point considerably.

You were wrong about the 1st part too. Cut files don't change attributes and don't disappear.

At least Explorer marks them as hidden when you cut them, I didn't check the file attributes.

Cmd-X would be inconsistent with every other move/copy action on the Mac. Option is the modifier that switches between them.

And what is the "correct" way to go up a folder? What would be easier or more discoverable than Go -> Enclosing Folder?

A button? Even Unix considers that accessing the parent dir is a fundamental operation that deserves a dedicated file in the API (..) .

File in the API?

Well, .. is not exactly a file, but it's not exactly an API either, right?

Reply on news.ycombinator.com