Advocacy
Dojo (HowTo)
Reference
Markets
Museum
News
Other
Myths
Press
General
Hack
Hardware
Interface
Software
Standards
People
Forensics
Web
CodeNames
Easter Eggs
History
Innovation
Sightings
Opinion
Martial Arts
ITIL
Thought
|
I can't ever write something about the flaws of interface in NT, or subtle interface advantages of the Mac, without learning that I'm being much too nice to Windows. My Copying Files Article was just one example. I mentioned a few examples of how the Mac is better and why -- of course, I got dozens of helpful emails from Mac and NT users helping remind me of what I missed. Killing me with kindness and excellent points that I'd omitted. So this little addendum should fill in some of the blanks and add more of people's favorite interface differences.
Interface
On the Mac when you copy files it pops up a nice little progress window. Copy operations can take some time, and odds are you don't want the copy progress window where they put it (center screen). So move it -- say to the lower right of the screen (or to another monitor in a multi-monitor operation). Of course the Mac remember where that window is. When you start another copy, the Mac puts the next status window right next to where you left the last one, or if you do another copy later, it remembers where you placed the last copy. In other words, the Mac makes an effort to remember what you did and how you work. Windows does not -- it places status where it wants. You can move it -- but the next time you do a copy operation it places the status window right where it wants (the old "wrong" position). To Windows users this isn't even surprising (they are used to working around the interface), but being Mac literate I'm often frustrated by Windows forgetting where I placed my windows last, or not remembering what view I left them in.
Clarity
The story of which one's dialogs are more clear does just stop with not throwing in complex buttons and behaviors (and clearer text). The Mac also does very clear behaviors, and pays attention to context. On WindowsNT when you do the file copy, it tells you the file already exists and asks you if you want to replace it.
On the Mac, it tells you that the file exists, and which version of the file is newer. Look at the following:
The Mac is once again clearer about what is going to happen -- which reduces the likelihood of a mistake. All these confusing Windows options (buttons) -- and most importantly, Windows doesn't tell you whether you are replacing something newer or older. This kind of thing (clarity and productivity lost because of it) won't show up in a benchmark, and the average user doesn't even know there is a difference -- but the first time you delete a critical file because a dialog wasn't clear about which was newer, it can cost the user a lot of lost time -- far more than gained by any performance differences (or measured in benchmarks). True performance is productivity and avoiding costly errors not just speed of an operation.
Now some users sent me pictures where sometimes Windows behaved similar to the Mac, and would state the file existed, and listed both file names and their dates (and left it to you to decide what to do and which was newer).
This snapshot is actually from Win98, and it was less clear than the Mac -- but I was also able to get it to work, sometimes, with NT. I couldn't figure out why sometimes it worked and sometimes not. Finally, I figured it out -- when copying a Folder from a source to a destination, you get the non-descriptive behavior -- but when copying files (contents of a folder) to another folder, you get the more descriptive behavior. Why one works and the other doesn't is beyond me -- and I didn't want to even try to figure out what a mix of files and folders would do. I'm usually copying folders, so the Windows behavior usually doesn't works correctly (for me).
Consistency
Windows is not an Operating System with one interface, it is many. Windows95, Windows98, WindowsNT all can work substantially differently -- and that is just the start. There is Windows95 OSR1, OSR2, OSR2.5, and so on. Then there are various NT versions with service pack updates. Oh, and the computer can behave substantially different on whether you have Explorer installed or not, or if Active Desktop is installed or not. And just wait until Windows 1900 (2000). I'm not even going to get into WinCE. You can not assume that any behavior in Windows is static (or staying the same). Every time I say that "Windows works like this" -- I get responses from someone saying, "On my version it behaves different" -- which I think is a point on its own.
I realize all interface must evolve and change over time, but the many flavors of Microsoft change more, because things are so much less thought out to begin with. This may not cost Microsoft much money -- but it certainly causes users in time and likelihood of errors. Almost everything I've ever documented about Windows has some exception in one version or another. The Mac changes too -- but often in very subtle ways. This is because Apple spent the time to design things right the first time -- and some people mistake this consistency with a lack of progress.
Source and Destination locking
When you copy a directory under MacOS you cannot add or remove items to the source directory or move the folder until the copy operation is complete.
This is very useful, and keeps you from making mistakes like moving something before a copy is done, or by adding files to the source directory (thus not getting them copied), or deleting things before they are copied somewhere else and so on. Now on the Mac you can still work the folder in nondestructive ways -- like you can look through the folder and copy it (or parts of it) to other destinations at the same time.
Of course nothing is this simple in Windows. In Windows you can have the same folder open multiple times -- once at the "desktop" (traditional interface) and once using File Explorer. They both do different things, and don't know about what the other one is doing. And locking is never clear. If you start a copy from one interface, you can't access the entire source drive from that interface! This is complete excessive, since only destructive behaviors on a source folder are a problem.
Windows doesn't offer any feedback either (there is no clue as to what is going on when this happens), your clicks and actions are just ignored for that window or drive (if there is a copy from there). Sometimes it also locks destination folders (downloads sometimes seem to do this) -- I haven't figured out all the rules for when this will and won't happen, but sometimes the machine sort of locks up (partly) and doesn't tell me why. Many times it allows me to do things that it shouldn't -- and so later gives me some "sharing violations". If you use WindowsNT and do a lot of file copying/moving operations, get used to this dialog:
I thought I was losing my sanity until I realized that it was just that the Windows programmers never had any. People talk about multitasking, but you can't even do many copies at the same time using windows, assuming that they are coming from the same source (or sometimes to the same destination). Oh, and by the way, the Mac (unlike Windows) can copy files that are in-use just fine (locally -- it just gets blocks you if you try to pull out someone else's files that are in use across a network (since the state of the file is unknown).
The Macintosh keeps file state information bound to the file, so multiple interfaces can be aware of what is going on -- Windows does not (it is just a memory resident state). So of course in Windows each of the file interfaces (Desktop or File Explorer) doesn't know anything about the other -- so if you start a copy in the desktop view, then you have complete access (including adding, moving or removing files) from the File Explorer view -- if you do anything destructive it can of course confuse the first interface (and user) and usually leads to a copy failure or at least some operator error. Trying to document this I somehow really confused things (a few times), and got the whole filing system screwed up -- great, thanks Microsoft. And there are dozens of variants of ugly in these behaviors, and I couldn't even hope to document them all -- but the point is that there are lots of ways to confuse Windows and yourself using Windows.
Copy and Paste
On the Mac if you want to make a copy of a file or folder (in place), you just select the file/folder and use a single step command -- Duplicate. The MacOS makes a copy of the file, and appends or prepends "Copy" to the file. Easy, single step operation. There are shortcuts as well (like using the option key when dragging files to make a copy).
Windows doesn't have a copy in place command -- but you can do the same thing with a two step command. (Windows does have more confusing modifier keys, but they do different things depending on what type of item you selected, and they can even delete your source items if you select the wrong key, so I stay away from them and recommend that others do the same). On Windows you can select a file and do a copy, and then select the destination folder (the same one) and do a paste. Well, first I should say that sometimes you can do this -- almost everything in Windows is qualified with "sometimes this works". It works fine using the "desktop" interface -- it will prepend "Copy" to the copied item and work basically how you expect. Try the same operation in the File Explorer (NT Explorer) and you get a dialog that says:
Even the dialog is incorrect -- the operation I chose was paste (not copy). It can't "paste" the folder Dell, because it can't figure out how to rename the file.
Now overall, Copy and Pasting files is an interesting behavior -- and something that Windows does and the Mac does not. (Actually, the Mac does it -- you just need to get a freeware/shareware extension). Of course like most features that Apple "omits" there is a reason. It is easy to select a folder or a drive and say copy, then forget about it. There is absolutely no feedback that you have done something and on Windows there is no way to know the state the clipboard is in (unlike the Mac there is no easy way to see what is on the clipboard) -- so you can't ever verify what is there and what the paste operation will do. So if you come back to a machine and say paste, or you forget which copy was the last copy, then you will get unexpected results. It is also easy to mess up on scope -- which window is the foreground window again? It is very easy with paste to send a copy to the wrong place. I'm often making these subtle mistakes using Windows -- and the whole point of a good user interface is to anticipate user errors and make sure they are minimized and nondestructive.
The complexity of the clipboard filing behavior is only beginning. You can not only copy and paste, you can cut and paste. So imagine you "cut" a folder -- if you paste it somewhere else -- what you are actually doing is a move (copy something to the new place and then delete the original). That is scary -- especially with Windows move behavior (documented later). Any destructive behavior like that needs verification because it can lead to lost work. Yes, it is a powerful function and can save you a second or two every now and then -- but is it worth the potential of lost days or weeks of work?
Windows file cut/copy/paste isn't even consistent or predictable. If you try to paste a cut item back to the same place (where it came from) the cut fails -- it throws up an error which says it already exists. Normally, if I cut and then paste to the same place it is just like an undo. Copy sometimes works as expected (adds the file) -- so why does copy work and cut fail? Cutting a file and pasting it to the trash deletes the original -- which is what you'd expect. But if you cut a folder it isn't really gone yet. If you cut one folder, then cut or copy another folder you also don't get a delete. Proper cut and paste logic should delete the original when you do the cut (not defer the cut until later) -- but that file behavior is too destructive even for Microsoft, so instead they just ignore the proper (consistent) behavior. A file cut is different from any other "cut" in the system, since when you do a file "cut" it actually just makes the folder lighter (implying that the operation is half complete, or deferred until later) -- only when you do a paste operation does the OS actually do the cut operation first. If you are confused now, just try to build up a truth table of all the possible ways in which cut/copy/paste work, or don't work, using File Explorer and the desktop. Apple seems to have been very wise to avoid those confusing, unclear and potentially destructive behaviors.
Verification
On the Mac when you copy files to a from drives (and floppies) it verifies that they made it to the destination. On Windows, the OS assumes they made it there in tact. Imagine you move a file -- which is really a copy and a delete -- but the copy never worked -- I bet just deleting your original was not your intended behavior!
Now you can do verification in Windows -- if you use the DOS prompt -- you use the ever intuitive "/v" switch to do a copy with a verification. So in other words, the Mac behaves correctly (safely) by default, and Windows will if you know the secret workaround and commands -- talk about a metaphor for the entire difference between the systems.
Moving Files
There are two kind of file moves. One is moving files in the same drive -- and the other is moving files across drives (from one storage device to another).
Moving files on the same drive is a simple operation -- you just move the files. You don't have to copy the files from one place to the other and delete them -- you just tell the folder/file that it is now in the new place (or tell the new place that it owns that folder and file). This works simply and easily on the Mac -- it usually works on Windows. I haven't figured out all the rules -- but the Recycle Bin on Windows doesn't quite work like other moves. It is really a special partition or behaves half like a separate drive -- so a move to the trash is really behaves like a move across drives (copy and delete). Sometimes I get the flying folders and all the other things related to a copy (not a move).
Moving Files across drives (or partitions) is dangerous. What it is really saying is copy the files, then delete the original. Good interface is that you always verify a destructive behavior before you do it -- the user may have made a mistake. In moving files across drives there is no good solution for asking the user. You don't want to ask before you delete each file (that would be tedious). You don't want to do all the copies, and then ask for deletes later, because this can be many minutes later and the user is very confused about "what are you deleting", or may think "I didn't delete, I just moved". If you ask for verification before you start, then what happens when the file move fails half way through? There is no way to reverse time and explain that an operation that they started minutes ago, failed.
Windows solves the ugly parts of moving by just not verifying a destructive behavior -- it just does it. It also does it in the worst possible way. Instead of doing all the copies and waiting for the operation to complete, and then deleting (once the copies have succeeded) -- Windows copies and deletes files as it goes. If Windows fails to complete the move for some reason (like there wasn't enough space, some file was in use, or something else -- remember it doesn't preflight) you get two half-completed file-trees (source half deleted, destination half copies). Some files are in one place, some in the other -- and the user is left to fix it. Bleck! Do you know how much time this wastes trying to fix things? What order were the files copied in? Not any logical order that you can easily follow (like alphabetic), it is the "no sort" order, which means when the files were placed on the drive. In a nested hierarchy, this can be some sub-folders and part of their contents in no logical order. Good luck fixing things -- I've wasted hours (on huge copies).
Apple recognized that there should be no "move" among drives -- users should copy first, and delete when they are done. This makes a little more work for the user -- but saves on all sorts of potential loss of data, wasted time, half completed moves, and reduces operator confusion. Even if the Mac were to screw things up (which it can't, you have to it manually) I can fix things. The "File Synchronization" control panel (utility) allows consolidation of two partial hierarchies. Microsoft just added a "power feature" that greatly increases the likelihood of serious data errors -- then they made special keyboard shortcuts to make it even easier to screw things up.
Conclusion
Good interface isn't just for idiots or newbies -- this is about the fundamental way which you interact with your computer. One Wndows power-user friend of mine was doing something that I've done dozens of times in my life -- move files (almost an entire drive) from one drive to another -- in order to rearrange things and gain more space. When copying (dragging the folders) he held the "move" shortcut key to save himself a few seconds and avoid having to do a delete later -- but when he released on the destination drive the mouse was accidentally over the recycle bin (in that drive). In Windows the same key that meant "move" also had a second meaning - it meant to immediately delete all files (without verification dialog) if you dragged them to the trash (no matter what drive's recycle bin you pointed to). I heard a yelp, a cry, and him frantically trying to stop what was happening -- too late of course. Microsoft had designed a descructive behavior to save literally a second or two here and there -- and it cost many days of work.
Again, each of these things sounds simple or like minor nits here and there. They are -- but they add up. Things that allow accidental destruction of your data isn't just a nit (to me). Now two whole articles and dozens of errors and potential pitfalls in the way Windows does things really adds up. The likelihood of being bit by any one issue at any particular time, is pretty low. The likelihood that while using Windows you will run into one (or more) of the issues at some time is very high. The relative cost in time savings are very important -- some Windows shortcuts save seconds but can cost you days or weeks of work. Some naively call that "power", but is that worth it? Is that kind of power really a good idea or good interface? To me it is like putting an eject button next to the turn signal on a car -- so that if you are about to get into an accident you can easily bail out and save yourself (a power user function) -- of course the real results will be that people will actually kill themselves and each other, all over the place. Bad interface. The normal reaction for a failure is for users is to blame themselves -- "Oops, I should have done that". More need to wisen up and learn that it isn't usually their fault -- good interface is about anticipating users behaviors (accidental or not), and making it easier to work well, and harder to make mistakes. Saving a second here or there isn't always enhanced productivity -- avoiding lost days of effort usually is. Microsoft puts in a few simple behaviors, or the primitive parts of a user interface -- but misses this key aspect to proper interface and computing. Microsoft makes it easier to make mistakes -- and easier to make costly mistakes. That isn't the users fault.
|
