ten things I hate about MacOSX
See this article:
http://www.informit.com/articles/art...58172&seqNum=1
Good valid points! I don't mind the last point about nagging popup boxes though, since MacOS is a lot better in this respect compared to Windows constantly telling me "new hardware found", "network cable unplugged", etc.
As for his Finder remarks; the thing should be rewritten from scratch IMHO (but there are enough topics on that one).
I would add point (11): Being able to close windows in the dock by right-clicking and choosing "close". And (12) being able to cut and paste files to move them around just like in Windows Explorer (and Path Finder).
http://www.informit.com/articles/art...58172&seqNum=1
Good valid points! I don't mind the last point about nagging popup boxes though, since MacOS is a lot better in this respect compared to Windows constantly telling me "new hardware found", "network cable unplugged", etc.
As for his Finder remarks; the thing should be rewritten from scratch IMHO (but there are enough topics on that one).
I would add point (11): Being able to close windows in the dock by right-clicking and choosing "close". And (12) being able to cut and paste files to move them around just like in Windows Explorer (and Path Finder).
Comments
(12) Is not in right now. Try to CUT and PASTE...It won't work. Instead you have to click and hold your mouse to drag your stuff to another location, a pain in the behind for fast use.
Your number 11 - Let's see ... if you're closing the program in general, this can be done from the dock or done by hitting Command+Q. If you just want to close an app window, this can be done with Command+W after taking the window off the dock. You'd have to move the mouse anyway to the dock to right click and say "Close", so what's the difference in mousing to the dock, clicking on the window to maximize it and then hitting COmmand+W? The latter is probably just as fast and if it's not, then come on man ... you're griping about literally miliseconds of productivity time either way.
Your Number 12 is incorrect as well. I didn't know that clicking on the mouse and holding it to drop a file or folder or app in a new location was something that was really that hard. If you "cut" something, then you still have to migrate to wherever you want to put it. In OS X, you can migrate with the file by holding it over the folder. You can also highlight the file, hit command+C, go to wherever you want the file and hit Command+V. Poof ... there you go. Come back later and highlight the original file and hit Command+Delete so you only have the one copy. Again, not terribly time consuming ... an extra 5 seconds. Or, assuming that you're not totally concerened with second-by-second productivity 100% of the time, it can be put off until you have the 3-5 seconds to spare.
12 incorrect as well? You seem to like to point out being smarter then me. I am a webdesigner and game designer so I know where I am talking about. It's very handy to being able to cut and paste.
Your method of copying files, going back and then deleting the files is plain silly and VERY time consuming. Not handy when you're moving files all the time.
You are basicly saying that a less perfect option is good enough...if everyone would have the same point of view, there would be no improvements in design.
never mind. Something to discuss with interaction designers.
Originally posted by AgNuke1707
Well first off, I can't access your link to know what you're talking about.
Your number 11 - Let's see ... if you're closing the program in general, this can be done from the dock or done by hitting Command+Q. If you just want to close an app window, this can be done with Command+W after taking the window off the dock. You'd have to move the mouse anyway to the dock to right click and say "Close", so what's the difference in mousing to the dock, clicking on the window to maximize it and then hitting COmmand+W? The latter is probably just as fast and if it's not, then come on man ... you're griping about literally miliseconds of productivity time either way.
Your Number 12 is incorrect as well. I didn't know that clicking on the mouse and holding it to drop a file or folder or app in a new location was something that was really that hard. If you "cut" something, then you still have to migrate to wherever you want to put it. In OS X, you can migrate with the file by holding it over the folder. You can also highlight the file, hit command+C, go to wherever you want the file and hit Command+V. Poof ... there you go. Come back later and highlight the original file and hit Command+Delete so you only have the one copy. Again, not terribly time consuming ... an extra 5 seconds. Or, assuming that you're not totally concerened with second-by-second productivity 100% of the time, it can be put off until you have the 3-5 seconds to spare.
Originally posted by dacloo
12 incorrect as well? You seem to like to point out being smarter then me. I am a webdesigner and game designer so I know where I am talking about. It's very handy to being able to cut and paste.
Your method of copying files, going back and then deleting the files is plain silly and VERY time consuming. Not handy when you're moving files all the time.
You are basicly saying that a less perfect option is good enough...if everyone would have the same point of view, there would be no improvements in design.
never mind. Something to discuss with interaction designers.
I never said I knew more about it than you did, I just pointed out an alternative which you don't seem to like. Any way you go about it, you still have to migrate to where you want the data. Whether you cut and paste to the folder or drag and drop it there it shouldn't matter. One wonders why you're moving files in the first place? Shouldn't you have saved the files to the location you wanted them in to begin with? Maybe you're pulling stuff off an external disk ... highliught your items and drag them to where you want them ... still involves migrating to a point in the system.
The Safari argument you're supplying is silly. If every minimized window in Apple's OS operates the same way (Hit the yellow button to minimize, click to maximize, or click to close) then there's no inconsistency in THEIR design ... just in what you're used to. Again, I pointed out an alternative to the right click -> close window, but you didn't like it. Both of our solutions require one mouse click ... both take the same amount of time. You're just used to a Windows way of doing things that lets you access every possible feature you may ever need from a right click menu. I prefer an Apple way of doing things that makes me maximize the window, make sure I want to close what is in the window, and then actually close it with command+w. If you're really that worried about it, script it for yourself, put it on the web and charge interested parties $5 for the script.
And what the hell does web designing and game designing have to do with a debate about how to move files around in a system or how to close windows. My grandmother can do these things and she hardly touches the computer...
Originally posted by dacloo
never mind. Something to discuss with interaction designers.
(11), cutting-pasting a file, is a disaster to human interface designers. Cut is a destructive action; it's supposed to make whatever you cut disappear. Doing it to a file is dangerous, especially since the Finder/Explorer's clipboard holds all sorts of other data. Mucking together a cut-is-not-really-a-cut action, like MS likes to do in all their apps, only helps a little. There really isn't any consistent, elegant way to implement file cut-paste. You're used to it, which is fine; but Apple's interface designers clearly consider it a potentially dangerous kludge.
Try CocoaTech's Pathfinder, it does has the feature built-in. It works like a charm.
The Safari argument you're supplying is silly. If every minimized window in Apple's OS operates the same way (Hit the yellow button to minimize, click to maximize, or click to close) then there's no inconsistency in THEIR design ... just in what you're used to.
Being able to close windows fromout the dock is no different than closing them by clicking the red button on the window itself, it's just a shortcut when a window is minimized. I can close (stop) applications the same way in the dock, so why not windows belonging to a certain application? I don't see the problem.
- Right Click on file and drag and have options: move, copy, etc
- I like in windows the ability to Cut any file any then paste it anywhere else, which effectively moves it
- Connecting to an FTP site with the Finder *STILL* gives me Kernel Panics
- Easier Personal File sharing (like in Windows: Select folder, share, done)
BeOS (still around in some form, I believe) had an option in context menus for files to either 'Copy to' or 'Move to' with a cascading menu that allowed you to copy or move a file to any location within the file system without resorting to the cut-paste (broken metaphor) kludge. This could be implemented both in context menus and in the main menu bar.
The big difference, though, is that BeOS would show a file listing instantly while drilling through the hierarchy. Blazing speed that seems impossible with the Finder.
By the way, this method also makes spring-loaded folders redundant. I think it would be the biggest interface enhancement out.
While speaking of BeOS, I would also like to see mime-typing for files. In BeOS each type of file (identified by the system by analysing the file and assigning a mime-type) would have a default application, just like in OS X, and you could set a different application for files on an individual basis. The BIG advantage, however, was that it did not depend on haveing a file-type or creator code in the metadata beforehand, or on file extensions. This way, if you received a random file with no extension (or a wrong extension) it would still open in the correct program. No way to hide an executable as a JPG or similar.
Very cool.
Originally posted by adamr
BeOS (still around in some form, I believe) had an option in context menus for files to either 'Copy to' or 'Move to' with a cascading menu that allowed you to copy or move a file to any location within the file system without resorting to the cut-paste (broken metaphor) kludge. This could be implemented both in context menus and in the main menu bar.
KDE does that, at least the v3.3 I use on my Gentoo box. I know Apple can be very principled when it comes to UI issues - why they will never implement cut-paste for files - but I wish they'd relax their bias against contextual menus a bit. Besides "Move to..." and "Copy to...", KDE lets you archive/encrypt, (un)compress and even print from a right-click. Very handy.
Originally posted by adamr
BeOS (still around in some form, I believe) had an option in context menus for files to either 'Copy to' or 'Move to' with a cascading menu that allowed you to copy or move a file to any location within the file system without resorting to the cut-paste (broken metaphor) kludge. This could be implemented both in context menus and in the main menu bar.
That's an even greater kludge, however, as it requires dozens of hierarchy levels in the menus.
Users hate submenus.
Just string together "Get Selected Finder Items" then "Move Finder Items" (Show Action When Run).
Then save as a Finder Plug-In.
Andrew
Originally posted by dacloo
I heared that comment on the human interface design a lot of times before, and it's a nice theory. Read, "theory" :-) Until you actually use it and find out it's VERY handy. I never heared anyone having troubles with the cut and paste metaphor. Never heared about data loss too.
Try CocoaTech's Pathfinder, it does has the feature built-in. It works like a charm.
Being able to close windows fromout the dock is no different than closing them by clicking the red button on the window itself, it's just a shortcut when a window is minimized. I can close (stop) applications the same way in the dock, so why not windows belonging to a certain application? I don't see the problem.
File CCP may work for you, but it is dangerous to some users.
This isn't just theory. A decade ago I worked as support gimp for the university's computer labs. I witnessed plenty of people lose data to this "feature".
It works as intended for some users and disastrously for others. Not that it's a "bad" interaction technique for files. Rather, it should only be wielded by people competent enough to understand that the file isn't actually cut or copied, despite what the command is called. Files are actually marked for later copy or move. Sure, we understand this distinction, but many users don't.
Plenty of users assume that once they've copied a file it will be paste-able no matter what, as long as it was the last thing copied. This isn't so, if trashed or moved to a different computer, the file can no longer be pasted. This is a completely different behavior than true CCP in applications.
Also, you aren't guaranteed to paste what you've previously copied. If changes are made, it is no longer possible to paste what you copied. Once again this is different than in application CCP.
Thus, I'm happy that this feature must be installed separately by a user rather than a part of the default install. It has saved thousands if not millions of users from minor or major data loss. If you've never heard woes of data lost to file CCP, you've likely never supported large groups of users. Seriously, user are far dumber than you realize.
I also agree that the Save/Open dialog box needs some love. The current sizes were fine when on a small screen, but now that I have boatloads of screen real estate lets have the defaults be slightly larger.
Originally posted by Xool
I also agree that the Save/Open dialog box needs some love. The current sizes were fine when on a small screen, but now that I have boatloads of screen real estate lets have the defaults be slightly larger.
Or they could tell the Finder to remember your "settings" (first time you install an OS, you get a Save/Open Dialog and you resize it) so that in the future, it opens the dialog the size of your last (or in this case, first) resized dialog.
So if you resize it to the size of X, next time you open it, it will be in size X because that's the way you wanted it the last time so we'll assume you want it this time as well.
BeOS was FAAAAST! The Apple Finder in comparision is ultra slow and IMHO needs to be rewritten from scratch for performance.
Originally posted by dacloo
BeOS was FAAAAST!
BeOS also didn't have to do 90% of what OS X has to do...which explains why it was fast...
System 1 is FAAAAST too nowadays. Does this surprise you?
Originally posted by kim kap sol
[B]BeOS also didn't have to do 90% of what OS X has to do...which explains why it was fast...
Yeah but, BeOS was fast when OS 8/9 wasn't.
System 1 is FAAAAST too nowadays. Does this surprise you?
You're comparing BeOS to System 1? On what grounds?
Originally posted by Gene Clean
Yeah but, BeOS was fast when OS 8/9 wasn't.
Yes, because it was written from scratch, without code cruft. A luxury OSes can't afford these days, at least not on the desktop market.