What OS X Could Learn From Windows
Okay.
Hard hat? Check.
Flak jacket? Check.
Flame proof vest? Check.
White flag? Check.
Deep breath? Check.
Windows has some features OS X could do with.
There, I said it. Nice and quick and up front. No beating around the bush. So what now? Duck!!!
Is it safe to come out yet? I’ve been burnt before daring to suggest this. But here I am again, sucker for punishment.
1) Compatible control keys. Switching between Mac and Windows this drives me nuts. I have to consciously think “command-C or control-C?” It shouldn’t have to be that way. And if you’re running RDC or VPC and copying and pasting between OS X and Windows!! Sheesh!
The problem isn’t the labeling, it’s the location of the keys used. I had to use a Windows PC today and I kept pressing Alt-C to copy. This is why it’s a problem. If it was simply a matter of labeling, no worries, mate. Apple - and the zealotry - need to concede that this battle is lost.
Implementing this would rock many people’s boats, so if Apple did make this change it’d have some serious domino affect on other keystrokes and applications that use them, but maybe it could be done with the switch to Intel, just to ease the pain slightly.
2) Save button on toolbars. I don’t think any of the Apple software ever gives you the option to include a Save button. Print button yes, Save button no. A little test - raise your hand if you save your work more often than you print it? Ah, so I’m not alone. Good. You can put your hands down. Thank you.
3) A multi button mouse. And you thought I’d say two. Why stop at two? Especially with things like Exposé, Dashboard and Spotlight. They’re just crying out for single click activation from a mouse. Ok. So this isn’t a Windows feature per sé, but still is needed.
4) Only show relevant file types in open and save dialogs. For those who like seeing every file that’s every existed in their Documents folder, give them a checkbox to show all files. But personally, if I am opening a Pages file, I don’t want to see all my iMovie, Excel, iDVD etc files. And OS X already knows which are which because non-related ones are greyed out.
5) Sort folders to top of directory listings I know that we don’t go folder mining as much since we got Spotlight, so I won’t labor on about this one.
6) More context sensitive help. I notice since I first raised this two years ago, more of it has crept into OS X. So I guess at least I can’t be flamed for this one!
Now why is it that I can list all the features I want Leopard to have and as long as none of them are from Windows, its cool? But dare suggest OS X needs a feature already in Windows and the world comes down on you. We can admit that OS X is not perfect, but not that Windows is better in some ways.
But Apple have admitted it in the past. Here’s just a couple of things I’ve seen Windows do that Apple has added:
- Command-tab switching
- Existing files selectable in Save dialog
Last week I suggested changes to the iPod and more people than not, disagreed. And I reckon this week it’ll be a lot worse. But if I added to this list “Change to Intel CPU’s"… two months ago I would have been burned at the stake. Now it seems we all think that change is logical. So before you get the flame thrower out remember, we know Apple make changes, they borrow from Windows and borrow from their 3rd party developers.
Also, I know I’m going to get flamed for this being a “tired old argument that has been done to death”. Sorry if you feel that way. just pretend I didn’t say these features already existed in Windows and that they are new and revolutionary. If we stop asking, Apple may think we don’t want them anymore. Microsoft copied so much from Mac OS, why can’t Apple do a little copying back?
And if you can take the heat, what would you like to see Apple borrow from Windows?
del.icio.us
Digg
Facebook
Slashdot
StumbleUpon
Comments
It appears that Apple would implement cut and paste in the Finder by putting files in the trash when you cut them.
It appears that Apple is f***ed in the head!
Okay. Let’s go right back. All the wayyyyy back to kindergarten.
Teacher’s given you some scissors, glue, and a magazine and wants you to cut and paste pictures from it.
Let me ask you this, Scott. Did you cut the pictures out of the magazine and throw them in the trash until you’d decided where to paste them?
Of course you didn’t. So why are you so obsessed with OS X doing cut and paste of files that way????????
In applications, when using cut, does it go into the trash? No! It goes - by your own statement - into the clipboard.
Repeat, why are you so obsessed with OS X cut and pasting files via the trash?
Because?
It appears that Apple would implement cut and paste in the Finder by putting files in the trash when you cut them.
So, you are so hooked on “the Apple way”, that you can’t see that in this case it is totally wrong and totally screwed.
How hard would it be for OS X to use the Windows model for cutting and pasting files? And as we know from Windows, you don’t have to touch the file until the point of time when you instruct the computer to move it.
Surely Apple has one programmer with enough talent to code this impossible task.
Of course… it is only impossible until Steve finds a way to say that Apple invented it, and that Windows somehow retrospectively copied it from Apple.
I mean, look how much trouble Apple went to with the two-button mouse so they could still say it’s a one-button mouse.
They’ve probably got whole team of programmers and marketers working 24/7 on this cut and paste Everest.
Yet it appears that Apple has done, as Beeb likes to say, the “seemingly impossible” task of creating a model that would make Cut in the FInder work exactly the same as every other cut and paste out there.
There are two reasons why this comment is bafflingly inexplicable.
1) You’re now arguing that they have accomplished implementing a feature that you have given elaborate reasons for they haven’t and shouldn’t implement.
2) You’re arguing that they have a feature that either they actually don’t have, or that they have but works nothing like “every other cut and paste out there.” From the Finder, I cannot Edit-->Cut a file, I cannot right-click, and I cannot CMD-X.
I am trying desperately not to refer again to your one-dimensional Mac-atronic brain, but WTF?
Beeb wrote: “ But since “cut” implies the intent to move (and which is probably a better word for the operation), it makes less sense to immediately move the files to the Trash, but rather to wait until the move operation is complete.”
It implies no such thing. In a word processor, you can cut text and paste it several times in multiple locations. You can used it to delete content. You’ve limited your definition of cut and paste with files due to Microsoft’s decision to implement a limited model of cut in Explorer.
Mac OS doesn’t support a limited cut model. As such, I haven’t changed my definition of cut since I can’t use Cut at all.
Again, people shouldn’t have to learn a different model of cut for every application. it’s results in limited assumptions just like the one you just made.
Beeb wrote: “It “appears” that Apple wouldn’t implement cut and paste at all. Isn’t that the problem?”
I’m not against having cut and paste in the Finder, as long as it’s constant with cut and paste as defined everywhere else. This means not implementing it as a move. This has been my position since my first post.
I’m simply pointing out that if Apple were to implement cut and paste for files in Leopard, it’s appears it wouldn’t be a move.
Beeb wrote: “doesn’t explain why there are design inconsistencies in existing Apple applications, like the afore-mentioned inconsistencies between DVD Player and Quicktime.”
No operating system is perfect. Dragging a disk to the trash to eject it is a huge inconstancy. However, as a whole, Mac OS is much more consistent than Windows.
I’ve always found this rather odd since Microsoft created Windows AFTER Apple created the Macintosh.
No operating system is perfect.
Oh good lord, it’s like arguing with a Republican.
I think you’re getting hung up on the whole “cut-and-paste” semantics and twisting yourself into a pretzel of apologist excuses in the process.
What Chris and I clearly want to do is to move files from one volume to another via the Edit menu, CMD-X and context menu. You can do this in Windows, Path Finder, and just about every other OS except OS X.
So WHATEVER you want to call it and however much you’d rather spend your time inventing preposterous nonsensical explanations, OS X’s implementation of this feature is non-intuitive at best and far more dangerous and less efficient than the Windows implementation.
It implies no such thing. In a word processor, you can cut text and paste it several times in multiple locations. You can used it to delete content. You’ve limited your definition of cut and paste with files due to Microsoft’s decision to implement a limited model of cut in Explorer.
Actually it DOES imply such a thing. When I want to MOVE text (even to multiple locations), I “cut and paste.” If I didn’t want it moved, I’d simply “copy and paste.”
And I wanted to delete, I’d hit “delete.”
And if MS’s decision is “limited” by allowing you to cut and paste one instance (and it might not be that limited, I honestly don’t remember), then OS X’s decision is CRIPPLING.
Beeb wrote: “I am trying desperately not to refer again to your one-dimensional Mac-atronic brain, but WTF?”
What part of the words “...creating a model that would...” don’t you understand.
A “model” is not a feature. The mere existence of a partially implemented cut that is consistent with the commonly held idea of cut refutes the statement that “cut has to work a little differently.” Clearly it does not. Again this is an artificial limitation.
“Would” implies a possibility in the future, not a fact in present.
Saying that model that has yet to be implemented has no value is like saying that patents have no value since many of them have never been implemented.
Saying that model that has yet to be implemented has no value...
First of all, I didn’t say it has no value. What part of “it would be better than the nothing we have now” don’t YOU understand?
Second, defending and lauding Apple for how consistent it WOULD be if it ever got around to implementing a feature that it does not have and that you don’t even think it SHOULD have takes your empty rhetorical knee-jerk apologies for Apple to depths even I could not have imagined.
Well, now I’ve seen everything. I hope you’re sitting down, Beeb.
This move files that you and I both want Beeb, and that for want of a better name, we call cut & paste, is an action in Automator!! (Man, how many exclamation marks does that deserve?!)
Very easy to set up too, although not quite as smooth to use as cut & paste.
Go into Automator, select Finder, select the “Move Finder items” action. Drag it into the right hand pane, tick “Show Action When Run” and “Show Entire Action”
Then save this as a plug-in for Finder. Call it whatever you like. Call it Move files; Pickup; Cut; Bollocks; or whatever you dang well like, coz it won’t matter! It still does what you want, that is, move files. I know that’s hard to believe because you thought that the name dictated quite specifically what would happen, but not this time!
You can then access it in Finder through the Automator context menu. Just select the files to move, right click, and select your move workflow.
Also, you can save it as an Application, drop it onto your Finder taskbar, which I find slightly quicker than using the Finder context menu. And again, select the files, and click on the icon in the task bar.
Now the ammmaaaaaazing thing about this wonder of the 21st century… no, I can’t tell you, coz you’d never believe me! Oh okay, it doesn’t use the Trash!!!!!! Seriously! I watched the Trash and nothing appeared there. Somehow - it must be magic - it just moves them straight to where you want them!!! Freaky deaky!! I hope Apple’s got a patent on that coz it’ll be worth billions. (I presume it’s the same way drag&move;works, which is also able to achieve this miracle without going via the Trash.)
Well, Beeb, I really need to lie down. I’m just so spun out that we can do this and it’s still only 2007. Maybe this workflow was to be included by default in Leopard, and that was the “top secret feature”.
Steve Ballmer’s going to be chucking more than a few chairs tonight.
I’m just so spun out that we can do this and it’s still only 2007.
I went ahead and created the Automation, although it DID create a rip in the fabric of space-time by actually allowing me to MOVE a file in OS X with the context menu (albeit in less than an ideal manner).
I was led to believe that OS X would NEVER allow such a thing (my god, won’t someone think of the children - and the tech support calls!).
I’m just thankful that OS X is so much simpler and easier to use. As long as I do those things in that order, “it just works!” Just like the ads say! Who needs Windows and their whole “hey, we’ve already made this possible right out of the box” methods? Pfssh.
Scott, the way I see it, the core of the problem is terminology. If we had’ve asked for a move command in the context menu, or via keyboard shortcut, then I’m sure you woulda been happy.
Yes, cut&paste;is probably technically not quite the right term.
Hopefully Leopard will bring keyboard and context menu moving of files in a way that will appease both of us.
If we had’ve asked for a move command in the context menu, or via keyboard shortcut, then I’m sure you woulda been happy.
Actually no, Chris. It was “move” that he specifically railed against and applauded Apple for not including as a feature - even though they do.
He states above that he would be open to cut-and-paste so long as it sent your files to Trash purgatory first because that’s how other apps do it - even though they don’t.
Sorry for the excess sarcasm, Scott.
I’ll fight like a dog does for a bone over the incomplete support for moving files in OS X. Windows does it safely, and OS X already provides two methods of doing it (drag move; and via Automator) that work safely.
So there’s just no valid reason for not adding it via keyboard shortcut and context menu.
If there was, then the same reasonng would apply to the methods already available.
So, Apple has two options.
- Show they do believe it is dangerous and remove the functionality completely;
- Or admit the shortcoming and implement it fully.
OS X is better than Windows, and for many good reasons. OS X, not the hardware, is why I own a Mac and will keep buying Macs.
I accept that OS X is still a work in progress (as the inconsistencies demonstrate). However, that won’t stop me from raising issues.
Leopard is going to come out soon and make Tiger look bad, just as Tiger does to Panther. For example, I hope in twelve months time that I’ll be thinking when having to use a Tiger based Mac, “My God, I can’t believe this didn’t have a tree view in Finder and cut&paste;of files!”
Chris wrote: “In applications, when using cut, does it go into the trash? No! It goes - by your own statement - into the clipboard.
...
So, you are so hooked on “the Apple way”, that you can’t see that in this case it is totally wrong and totally screwed.”
Chris, let me see if I can make my point painfully obvious…
The clipboard is a temporary area to hold content, such as text or images, until you paste it at some point in the future. However, if your computer crashes or you invoke cut / copy multiple times, any previous content you had in the clipboard is lost. Also, the content of the clipboard are stored in RAM. As such, it can’t hold any content that is larger that the total amount of memory in your computer.
Due to these limitations, instead of putting cut or copied files in the clipboard, as it did with Word, Outlook, Notepad, Publisher, Paint, etc., Microsoft made an exception and implemented cut & paste in Windows Explorer as a move. They also made the same exception for Excel, due to limitations I posted earlier. Had it not been for these limitations, it’s quite likely that Microsoft would have put files and cells in the clipboard instead of using a move, just like it did everywhere else.
However, if you stop and think for a moment, what happens when you delete a file in the Finder? It gets put in the Trash. And what is the Trash?
The Trash is a temporary area to store files you want to delete, such as applications and documents, until you empty it at some point in the future. However, if your computer crashes, the files the Trash are NOT lost. NOR are any previous files stored in the Trash lost if you invoke delete multiple times. They simply get added to the contents of the Trash. Also, the Trash can hold VERY LARGE amounts of data.
As you’ve hopefully noticed by now, the Trash works like the clipboard, except it doesn’t have all of the limitations the clipboard does regarding loss of content or holding large amounts of data.
As such, it would be quite possible for Apple to emulate the clipboard using the Trash, instead of using a move, and make the Finder consistent with the commonly defined version of Cut and Paste
When you invoked cut, the files wouldn’t just get grayed out, they would be removed from the source folder and put in the Trash. If you never Pasted them, they would remain in the Trash until you emptied it. Consistent? Yes.
If you invoked Paste, the files that you cut in the Trash would be COPIED to the target, just as pasted content from the clipboard is always copied to the target document. Consistent? Yes.
Since the files would remain in the Trash after the paste, instead of being moved, you could paste them multiple times. You could also instantaneously undo a cut and paste, even on external volumes by having the Finder take the files out of the Trash, restore them to their original location and delete the files on the target. This is in contrast to having to MOVE all the files back from the destination.) Consistent? Yes. Faster than the undo of a move? Hell yes.
In fact, when you put a file in the trash, the Finder really puts it in a hidden folder on the same volume you deleted it from. (it’s a rename not a move) The Trash in the Dock combines the all the files from these hidden folders on each mounted volume in a virtual folder. That’s why, regardless of how big a file is or what volume it’s on, the Finder can “move” it in and out of the Trash instantly.
And when you enable Apple’s hidden “cut” in the Finder, where does it put the files? The Trash. Coincidence? Perhaps. Perhaps not.
Regardless, what I have just described *is* a way that Cut and Paste could be implemented which would be constant with everything else.
To bring this back to the topic of the thread, if Apple were to implement cut in Leopard’s Finder, would you want it to work like Microsoft’s cut, which is really a move. Or like the cut I just described, which doesn’t use a move and is more consistent with cut and paste in other applications?
I’m going to present a scenario where even Beeb probably would NOT use a move-based Cut and Paste in Windows. Even though, by his own definition, it would do exactly what he wanted it to do.
You’ve finished editing a video for a client. Since you need more disk space to work on your next project, you’ve just finished archiving the completed files to DVDs, when the client calls. He needs all of the project files delivered today so he can add footage they shot this morning and air it tomorrow afternoon. No time for FedEx. Luckily, this client is one of your regular customers. Your IT guy has setup a VPN which shows the clients server as an icon on your desktop.
So, here’s what we know…
- The video files need to end up on the clients server
- The video files on your computer need to be removed so you can start another project.
So why not just cut the files from your local drive and paste them to the clients remote drive over the VPN? After all, it does exactly what you want done, and it does it in just two keystrokes. And the flies will be removed from your local computer as soon as they have been transfered. Automaticly. Good right?
Hopefully, you wouldn’t even dream of doing this. Why?
- You’re computer could crash
- You could loose power or internet connectivity
- Your client’s server could crash, loose power or internet connectivity
- The files could get corrupted during the transfer
- If the files are large, a remote move could take much longer than a local move, which would dramatically increase the window of vulnerability for the any of the above problems.
However, if you really think about it, all of these things have absolutely nothing to do with what you really want to do, which is cut and paste the files. They are all implementation details. You wouldn’t think twice about any of these issues when cutting an pasting content in a word-processor or graphics editor, why should you have to when working with files?
- Cut and Paste on Windows Explorer doesn’t use the clipboard. Files are either moved or renamed.
- Cutting and Pasting files to a different volume is not a rename, it’s a move. as such it could take much longer to perform and to undo (and undo may not be possible)
- Copying large files to a external or network volume can take much longer than to a local volume
I know you might find it shocking, but many users don’t really understand the differences between remote or local volumes, or even file sizes. They’re just one of many icons on the same screen.
Sure, they may think one document is “bigger” than another, but only in the way that a five page document is bigger than a two page document or that a one hour video plays longer than a 30 minute video. Since a DV video tape is exactly the same size regardless if it holds two minutes or two hours of video, why should digital video on a computer be any different?
Cutting and pasting 30 seconds or 30 minutes of video both happen instantaneously in a non-linear video editor. Why shouldn’t it happen any differently in the Finder?
Also, both Mac OS X and MS Windows file managers default to icon view. You get a postage size stamp that represents the file and a name. That’s all. A file’s icon is the same size, regardless of how many bytes a it takes up on disk. And, unless you manually switch views or “get info” on a file, it’s size is never visible by default.
These are advanced concepts that are not obvious to everyone. You can’t find them in a manual. Users lacking these concepts are not stupid, nor are they unusual. They don’t really care how things work, unless it’s absolutely necessary to perform a task.
I’ve even seen a highly skilled 3D animator do the exact same thing in a similar scenario, except he was transferring 900 5mb animation frames for a real-time 3D game demo. The results weren’t pretty. This could easily be a corporate user moving documents or a home user moving all of their files from their old computer to a new computer over Wi-FI.
My point is that an operating system or application’s job is to hide all of this complexity from the user. A user’s decision to use or not use a feature should be based on whether it does what it’s supposed to do, not based on non-obvious knowledge of how it’s implementation details change from application to application.
A such, If a feature in a particular application doesn’t act consistent with the majority of other applications, it should be exposed through some other model where it is more constant, not be available at all or both.
Of course, you’re free to disagree with me. But then again, If everyone agreed, we’d all be running the same OS.