Slashdot Mirror
When Good Interfaces Go Crufty
An anonymous reader writes "A good article over at mpt on why good interfaces go crufty." A nice read before or after a visit to the Interface Hall of Shame.
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
But I have karma to burn...
I just wanted to know, WHY on earth MS would use the directory name 'Program Files' when so often installers and path names, etc. can only work with the 8.3 format and end up calling it 'PROGRA~1'. Plus, the space in the file path screws up some apps... just WTF were they thinking? Why not call it 'Applications'? At least that abbreviates to 'APPLIC~1' which sounds slightly less silly
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
Well, I'll tell you why. In the article, the author compares a wordprocessor to a pen and a paper, where everything you write gets "stuck" on the paper, while in the computer world you have to manually "Save" the work before anything really gets written. This, he deducts, is an arbitrary obstacle, and not intuitive at all.
On the contrary, my dear Watson. What if I change something in my Word document, but later on decides it was no good and wish to discard it? Nope, sorry. My old document is already rewritten with no turning back. Or is he suggesting that everyone should always make a copy of a document before editing it, just in case? Wouldn't THAT seem terrible unintuitive?
The "Save" function is one thing that separates the wordprocessor from a real pen and paper, and it certainly has it's uses.
Slagborr
One thing I hate is the "skinning" of everything, particularly media players. It was popular for mainstream kids software, and it worked okay there; but for everything else, the standard GUI (preferrably written with something nice like WxWindows) should be the only thing that is used. If I see something with colorful, bubbly bitmaps on the gui, I probably won't use it.
What is intuitive to us is what is standard -- adding new buttons with new pictures, new dials, and other things in a single instance interface only confuses everyone. Even if some of the properties are inefficient, regular GUI standards are the way to go.
Good user interface is hard and even though the author claims that "we have the technology now", some of the ideas just reflect his personal preference and are not really the obviously better design. Many times the interface which users would find "working as expected" requires nothing short of magic (or artificial intelligence, whichever arrives first). "Industrial design" has one major advantage over user oriented design: It's learnable. Learning a system which itself adapts its behaviour to the user can be really frustrating and time consuming because it follows more complicated hidden rules. That's why "power users" turn off as many automagic functions as possible.
The real user interface crimes are when well researched principles of perception are ignored: Making every icon round by dropping the actual icon into a marble of colored glass may be pleasing to the eye, but it's working against the way we recognize patterns. Adding bevelled lines around and between everything, even when there is no logical or functional separation, makes user interfaces distracting. And those are just the worst offenders in the graphical representation area.
1. The alphabet you are typing corresponds to a shortcut in the window, and the window happily closes itself, having done god-knows-what-damage-it-did.
2. It slows down your pace, disturbs your thinking process, and by the time you close the window and move to the position you were in before, one more word gets added to your swearing vocabulary.
"Do something man. Right now."
...nice in that you could see exactly where you were saving it, but not nice in that if you clicked "save" and type in a name only to realise the window you want to save it in isn't visible.
In the good old Acorn vs. Amiga wars of yore the Amiga's file requesters were a deadly weapon.
Phil, just me
"Cattle Prods solve most of life's little problems."
``In the 1970s and early â(TM)80s, transferring documents from a computerâ(TM)s memory to permanent storage (such as a floppy disk) was slow. It took many seconds, and you had to wait for the transfer to finish before you could continue your work.''
Wait...are they suggesting there weren't multi-tasking operating systems in the 1970s? What about Unix? Wasn't next to every system multi-user, multi-tasking in those days (timesharing)?
Please correct me if I got my facts wrong.
So we should get rid of ways to close programs? I dread to think how much you'd have running if the computer is on for more than an hour or two.
Phil, just me
"Cattle Prods solve most of life's little problems."
Some people are posting that they can't undo past a save, or don't like the slowdown of multiple apps, etc. By the time we can lose the cruft the author is talking about, you won't have that problem. The system will intelligently swap out applications and you'll be able to undo past save.
If you're fighting for reasons we need the crappy methods we have today, the very methods the author was talking about, then you haven't thought it through. It's obvious there's a better way than we have now. It will take some intelligent design and programming to make it happen. That's all. We're smart enough to figure out how to make this happen, and shouldn't screw it up making excuses for why we have to keep old methods around.
Oddly enough, most of his complaints about the handling of files are being addressed in the next Microsoft file system, that's reportedly being based on ODBC (effectively turning the entire file system into a massive database -- the BeOS guys tried and failed at doing something similar).
Perhaps the Windows right-click-drags he vilifies should be an "advanced feature" that has to be turned on manually, and maybe it isn't magically intuitive, but damn, I'd sure like to see him come up with an alternative that allows a user to quickly and easily take files and copy, move, or alias them with a single gesture this easily.
// I will show you fear in a handful of jellybeans.
He is of course right that you don't have to save your work when using a pencil. But, on the other hand, the eraser on the other end of the pencil won't wipe out 100 pages of work in half a second by accident either. Personally, I am very happy to take responsibility for losing my data, and eternally grateful that emacs has a 'revert buffer' option!
More generally, why does not exactly like a real desktop equal bad? It's an analogy, right? Does he want files to start curling up at the edges after a couple of years too?
Virtually serving coffee
Slightly OT:
Did you notice the different feel of menus in
common GUIs? Without tricks, it would be hard
to select submenus. You have to keep the mouse
pointer in a narrow 'tunnel'.
MacOS Classic works around that problem by using
a V shaped buffer zone. If you move your mouse
to the right within a certain angle, the submenu
doesn't change.
MS used an inferior workaround. Submenus open with
a delay, and you have to select them slowly or they
won't open at all.
KDE submenus work like the Windows ones. Gnome
behaves like the old MacOS. Sadly enough, menus
in MacOS X now work like the ones in Windows.
The worst implementation is used by Swing.
Submenus open with delay, but close without one.
You have to wait for a submenu to open, and when
your pointer leaves the tunnel, it vanishes instantly!
Getting rid of Quit
What does he mean with getting rid of Quit and Exit options? Should it (bad idea for obvious reasons) auto-close when I change the application or should they just never close (whoa - look my memory run out).
The alternatives to not exiting apps manually seem horrible to me, so I have to be missing something...?
Windows' shortcut menus
"In short, Windows native shortcut menus are so horrible to use that application developers would be best advised to implement their own shortcut menus which can be used with a single click, and avoid the native shortcut menus completely"
Ctrl+Click = Copy
Shift+Click = Move
Alt+Click = Shortcut
No modifier equals the most likely operation according to Windows. I.e. Shortcut if dragging to start menu, Copy if dragging between local/network drives, Move if dragging between folders on same drive.
The operation Windows will perform is always shown with an icon next to the mouse pointer.
I'm not sure how I'd design a quick move/copy/link operation better myself.
Beware: In C++, your friends can see your privates!
I suspect the only reason it caught on was because the competition is has even more retarded behaviour (yes vi I'm looking at you).
The article is calling the fact that you have to do a manual save at least once per document a bad thing.
Fortunately, technology has improved since the 1970s. We have the power, in today's computers, to pick a sensible name for a document, and to save it to a person's desktop as soon as she begins typing, just like a piece of paper in real life. We also have the ability to save changes to that document every couple of minutes (or, perhaps, every paragraph) without any user intervention.
We have the technology. So why do we still make people save each of their documents, at least once, manually? Cruft.
I don't wan't to name the document until I decide to save it. Does anyone else here want this feature? I create many documents every day, to re-format, print, view differently cut / paste from web for printing, for email, etc... I don't want my hard drive cluttered with this crap. That's why I don't save it. Yet, this Matthew Thomas guy thinks this would be good. I think his first example of "cruft" is a bad one.
-- -- Warning. Do not stare directly at the sun.
Personally, I don't like cruft, but the way he wants to "correct" some of the things he doesn't like, well... the cure is worse than the disease.
My idea of hell is an editor that auto-saves code that I'm in the process of hacking up in an editor to let me think about the problem over top of code that already works.
My idea of hell is a platform where every document I've ever opened has no way to close it and no way to exit the application that's got it up in a window, because there;s no 'Quit' or 'Exit' option.
My idea of hell is not being able to drag something in a GUI from one folder to another, because they have an obscure "parent of my parent" relationship, which makes me have to cut and paste the document, instead of just dragging it, because I on;'y have one file manager, which is running all the time, instead of a "file picker".
My idea of hell is symbolic links that get changed when I rename a file out from under them because the OS thinks it knows what I want better than I do, so it's impossible to replace a file with another, while keeping, and the old one, unless you copy it, rename the original, rename the copy, and then edit the original (instead of replacing it).
-- Terry
Well, you wrote my comment for me, but I'll add that the author tries to deflect this sentiment at the end by implying that anyone who disagrees with his preferences has obviously just bought into the dominant paradigm. ("But I *like* QWERTY..."). I suppose the proper reponse to him is, "If you're under 25 years old you obviously haven't had enough time to really think about this problem." And some specific criticisms: - Lots of modern software does, in fact, automatically save your documents. But by doing at least one manual save you get to pick a name and a location so you can find it again without needing Autonomy built into your computer. And while I like that the computer saves its own copy for safety, I specifically do NOT want it overriding the master copy without permission. - On Mac OS X the file picker does in fact look exactly like the file manager, with a few extra buttons around it. - I read his criticism of the "Quit" function several times and still don't understand his gripe. Yes, our computers can multi-thread so we can run multiple applications, but they have limited memory so we can't run EVERYTHING at once. And I for one would rather control which ones are running rather than wondering what my computer chose to quit. Also, Windows doesn't behave as he describes...close the last window and the application quits. Finally, there aren't any "mystery" menu commands unless you don't actually look at the menu bar when you use hot keys. I will admit that the "invisible application" phenomenon can be confusing to new Mac users, but I disagree with MPT's prescribed solutions. The current state is less "cruft" than it is the lack of a perfect alternative. Overall grade for mpt's "cruft" essay: C+.
Actually, I was trying to be Insightful, not Funny.
I don't think the author is really up to speed with technology. A couple of examples:
"We have the power, in today's computers, to use filesystems which store a unique identifier for every file, separate from the pathname -- such as the file ID in the HFS and HFS+ filesystems, or the inode in most filesystems used with Linux and Unix. In these filesystems, shortcuts and other references to particular files can keep track of these unchanging identifiers, rather than the pathname, so none of those errors will ever happen."
What about network shares in Windows or remote mounts in *nix? These are filesystem-independent, so unique identifiers like inodes aren't available.
"So why do we still punish people by including "Quit" or "Exit" menu items in programs? Cruft."
Not cruft - the GUI desktop is like a workbench: you pull up the tool you want to use, and you work on your creation with the tool until you're done. Then you put the tool away to make room for using the next tool. You can use several tools at once (multitasking), and you might put one tool down nearby (iconise it) if you know you'll come back to it soon, but it still makes sense to put the tool away for good (exit) when you're done with it.
Chuck Norris: Socialism == a thousand years of darkness.
1) Why is there a "quit" or "exit" menu item when a modern computer can run more than one program? Because sometimes I really do want the program to STOP RUNNING. Does the author suggest that we replace quit/exit with "stop"?
/home to a partition mounted at /usr and the file gets a new inode.
2) Inodes are only unique in the filesystem in which they reside. Move a file from a partition mounted at
Maybe Matthew should trade in one of his degrees for a degree in computing instead of relying on ZDnet for knowledge.
But Mac OS X, and OPENSTEP/NEXTSTEP before it, manage to keep the Mac metaphor while still hiding the implementation details, and it does it much better. Each application is actually a fairly complex directory structure, and all support files can be hidden within the application itself. This can include movies, help files, whatever--you name it, it's there. Now, to the user, you still have just the application, but the application can suddenly be dragged around at will without disturbing anything. For the application, you now can also guarantee a very rigid directory structure that the user can't even mess with. Next time you're on an OS X system, control-click a program and choose "Show Package Contents," or, if you prefer, cd right into the app. You'll see what I mean.
That's the right way to solve the problem, and that's why he's slamming Windows' metaphor and lauding ROX/OS X app wrappers/packages/bundles.
Why the heck do I have to move the mouse to one of the most obscure position, the lower left corner, just to start a program, which is easily the most used desktop operation of all?
Because the corners/edges of the screen are the easiest pixels to click on, with the exception of the pixel currently under the mouse. See Fitt's Law.
It's easier to click on the desktop if the mouse is already over the desktop. However, a lot of people work with apps using the full screen, so it's easier to use a start button.
Of course, this requires that your Start button actually extend to the corner of the screen. MS fumbled the ball on this originally, IIRC, by giving it a border (as they did with taskbar buttons), but they later fixed this (the border is still there visually, but now you can click on it). However, if you make the taskbar double height (as I normally do) then the Windows Start button inexplicably gets aligned with the top of the taskbar rather than the bottom, so slamming the the mouse to the bottom left and clicking has no effect.
I expect this positioning was considered to be more aesthetically pleasing. Sometimes Microsoft are very good at, as Sir Humphrey once said, "Snatching defeat from the jaws of victory".
Tim
"We have the technology. So why do we still make people save each of their documents, at least once, manually? Cruft." Please that's the stupidest thing I've heard in a long time. Do I want word or open office or abiword randomly saving documents all over my drive and trust it "to pick a sensible name for a document." NO, that's stupid, if we wanted to use Mac's that held our hand through every click then we would. Just because you can't use a computer when you're too stupid doesn't mean the interface is crufty, it means you're too stupid.
It's called "auto-save". The feature already exists in most word-processors.
We have the technology. So why do we still make people save each of their documents, at least once, manually? Cruft.
Well, maybe we want to allow people the choice of whether or not the the work gets saved. So to make it less crufty for the user, should we auto-save a different document every time, and fill up the user's hard drive? Then the user doesn't have cruft anymore, but does have to look through dozens of similar documents in order to revert changes.
Interesting article. I like it, but the author doesn't appear to have a good concept of what cruft really should be.
The human mind is pliable and adaptable enough to overcome these simple challenges in abstract thought. Humanity was able to eventually understand complex language then reading and writing. The UI of ancient times must have baffling to many and I'm sure a few of them balked it and called it cruft. Aren't computers and their UI just the next step in information and communication evolution? Should we keep "backwards compatibility" in these new interfaces? I don't think so. Move on. If you can't adapt, you'll be left behind and the gene pool will be better off. Darwinism at it's best.
Find somebody who knows how to use AutoCAD and be educated on how GUI & command-line are not mutually exclusive concepts. AutoCAD has the GUI for all gui bits, but still has a command line for when it's easier and saner (think typing in desired dimensions instead of trying to fake it with a mouse) to type things in. As most people can type faster than they can take their eyes off what their working on, move the mouse to the top of the screen and guess at which icon is which it also seems to be great for switching tools & modes quickly. :)
More programs really should allow that sort of functionallity. Now I have to see if anybody is working on it for The Gimp.
- RustyTaco
There is no excuse for this. I suspect it boils down to a hardcore RTFM attitude in the Emacs community, determined to not make things easy for anyone, especially people who just want to edit a file. The 'Customize Emacs' option is a sick joke. Even XEmacs makes an effort, for example referring to 'syntax highlighting' rather than 'font locking' and other efforts to put some sense into the configuration system. WTF did someone get the name 'font locking' from??? Talk about obtuse.
Most modern editors have the good grace to stick the commonly used settings into a nicely grouped point and click dialog box. Emacs has a graphical mode so it should do likewise.
The issue is not so much that that extra features have been added, but that the intent is not correctly communicated, or is inappropriate
For example, the WPS applied to the OS/2 desktop is a wonderous thing, one that people desire in other systems. When this file-viewing device is applied to files in general [eg DRIVES], the result is a nightmare. Drives is *not* one of os/2's better features.
Windows copied this feature into their shell, along with a network browser. Unlike the OS/2 one, these ones *can not be hidden*, especially without corrupting the operating system. [deleting Network Neighbourhood removes UNC support].
It's not that the "start menu" is totally bad either. It relies on an established practice of menus. So does the send-to [as a configurable context menu that allows drag-and-drop to otherwise hidden targets]. Folders = submenus. So you can have submenus in the send-to as well.
It's not that one can't make the windows shell liveable. Create a directory called grotto, and move these folders from Windows: sendto, start menu, desktop, shellnew, recent. You can create other folders there as well.
Create an icon with the command /e,/root=c:\grotto,start menu
explorer.exe
This gives you a super-program manager that you can fix your start menu, send-to, etc, as well as drag out recently edited docs for shortcuts to the desk.
The other issue of what happens whens when one closes dialogs (as to whether it's an OK or Cancel), frustrates users to no end.
The issue is not so much as Cruft, but the lack of consistancy. Were cars like this, they would be hazardous.
OS/2 - because choice is a terrible thing to waste.
Everbody should use VAX/VMS!
These commands are, IMO, actually examples of good interface design. The (unwritten) rule these commands are implementing is,
Let's say the "Save" command was automatic. Where are the files saved ? Under what name ? How often ? What if I made a mistake, and want to restore the old file -- is it possible ? How far back can I go ? Infinitely back ? What if I don't have infinite disk space ? Etc. etc. Instead of making a program that would try to solve these questions for all people and all applications at once, I can simply tell the user, "look, when you want to permanently persist your document, hit Save". This is a lot better in the long run than a program that would overwrite your files every so often because it feels like it.Similarly, the "Quit" command is useful. Without it, applications would just pile up on the screen and in RAM. When I am done with writing my letter, and want to play some Warcraft 3, I want to close MS Word and open WC3. It's very natural; just as when I am done working and want to go to the beach, I take off my suit and put on swimming trunks. If I could not quit any programs, they would pile up like layers upon layers of dirty clothes -- media players, web browsers, p2p programs, text editors, word processors, compilers, virtual machines, graphics editors... and that's just what I use before breakfast ! Yes, it would be nice if we had infinite CPU, RAM, disk space and screen space, but we don't, so the "Quit" command is the next best thing.
Note that, ironically, on single-threaded OSs, such as PalmOS, the Quit command is actually not neccessary. There, it makes a lot more sense to just save the state of the current program when you want to run something else, then restore the state when you reactivate the program. This only works because you can run one program at a time, and that's it, so there's no room for confusion.
Contrast the ease of use of the "Save" and "Quit" commands to other commands which have been implemented as automatic agents, just as the article suggests. MS Word's "auto-correct" (more like auto-confuse), Visual Studio's auto-complete (it knows best what function you want to call) and that damn paperclip all come to mind. My computer is not psychic (yet); it cannot sense what I want to do. If it tries to predict what I want to do ahead of time, it will fail and mess up.
>|<*:=
The complaint is not that the filepicker and filesaver don't look alike, it's that they don't *act* alike.
Windows has gotten better at this over the years. Its file save dialog appears to be an embedded instance of Explorer, albeit with some restrictions. Generally you can do all the file manipulation commands in the save dialog as you can in a full-blow Explorer window. You can't launch an app, you can't get the double-pane look, and the toolbar looks different, but the majority of the functionality is the same.
This is much better than older versions of Windows. Win 3.1 definitely didn't do this. I don't recall whether 95 did.
But if you ever wanted inconsisent filepicker dialogs, take a look at Amiga. In the early days, every programmer had to write their own filepicker from scratch. That led to some very innovative filepickers, and made the Amiga platform very difficult to use. I think they finally added a standard filepicker in a later OS release (2.1? 3.0?) but all the old apps still used their home-built ones.
It's fine to try to improve on things, but Thomas makes a fundamental error in dismissing things like 'Save' and 'Quit' commands as outdated. Even though hardware speeds have increased, so have document sizes and many people work with huge files where continuous saving would bring their work to a screeching halt.
I notice quite often that people who try to analyze the shortcomings of current UI's often make this kind of error because they are not aware of the diversity of needs that must be served.
For people who like to develop new, improved and consistent UI models, I would suggest that they also spend some time in describing the particular context and subset of computer users for which this model would apply.
Building a better ribosome since 1997
I strongly disagree with the author's comment about saving documents, but not for the reason that most people think.
The problem with eliminating save and only having one version (the version that is currently open, which is reflected in the file on the disk) is that you eliminate a primitive sort of "versioning" where the saved document on disk represents an older version of the document. The "save" command becomes a sort of "push current version out" and "revert" becomes a sort of "roll back changes to last version."
Now I would happily eliminate the "save" menu from my programs, but only if we could replace it with a "mark version" and "rollback version" command which would allow me to maintain several versions of the same document. That is, I wouldn't mind if we created a word processor which saved the current version of the document to disk as it was typed, but only if I have the power to mark different document versions and either roll back to an older version or mark the contents as the current version in that file.
I strongly believe this is the reason why eliminating the "save" command was not accepted by MacOS usability testing when they were working on OpenDoc. OpenDoc eliminated file saving entirely, and users hated it--because users were using the "save" command and "revert" command as a sort of "commit changes/rollback changes" command--that is, as a primitive way of version control. And OpenDoc, by eliminating the save command, took that away from users.
Don't take away file version control; give me a more powerful version of it!
I worked on a very valuble system as a code archiologist. The legacy system was in a million dollar a piece semiconductor furnace. Doing the work involved grepping through old C code that was written by a brillient assmebly language programmer.
;)
If code is working and shipping you don't throw it away. What I did was decouple the various patterns that I found and made something that was more modern. I did all of this work in C. It involved a lot of grepping and creating interfaces.
Just because code is old an kludgey doesn't mean that it is not valuble. Elegance is getting paid a million dollars for a device that only costs a fraction of that to manufacture.
Bottom line: if you don't have the cash you can't stay in business.
There is a difference between bad code and old idiom code. Archaic code that is shipping and works is much more valuble than pie-in-the-sky new code that no one wants.
It doesn't even have a line number indicator on the status bar.
...the position that appends to the end of the line is not available.
...cruft is eliminated only when something new comes along that's ten times better. Only ten times. And vi still exists. Amazing.
vi is configurable. Try ":set all" to see what you can play around with.
Use 'a' instead of 'i'. There is an append mode in vi.
It's bad enough having two modes.
For a pure console environment (no GUI, no mouse), vi's modes really aren't a bad thing. Command mode allows cut'n'paste, navigation, global search and replace, etc. You only enter new data in insert mode. Another thing about vi: its power isn't unleashed until you've read the 'ed' man page.
This is true. There has not been a programming environment invented that is ten times better than vi (or Emacs, to be fair). I have used Java IDEs, used Visual C++, etc., and all of them added only complexity to the development process. Complexity is a large project's worst enemy. And I'm talking about true complexity, here, not the apparent simplicity of an enormous GUI application like Visual C++. For example, when Visual C++ breaks...how do you know what went wrong? What if the binary build system goes awry? What if the VC plugin doesn't work right? What is the best way to keep binary project files under good change management? And so forth. Why add things to worry about, when vi, make, sccs, etc., do everything in a predictable managable way?
Healthcare article at Kuro5hin
You are right that is a huge undertaking to fix this since this would require reengineering a lot of applications and operating systems. That was the whole point of mpt's article. Existing programs are a cumulation of decades of fundamental design errors. Many severe usability issues can be traced to these design errors from the seventies and eighties. Many programmers are unaware of this and have actually duplicated the errors in efforts to improve usability. Their workarounds are symptoms of rather than solutions for the problems.
I don't think some of his proposed ideas are really solutions so much as alternate means of implementations. Take his thoughts on file saving, for example. As someone who spends time on and off working on larger files, I fully appreciate the flexibility I have now to save a file on MY terms- when I want, how often, and whether or not it will be saved as a new, incremental version of the original. Saving a large file in Painter or Photoshop takes time. I can't see any way in hell that an automated save will not become a huge source of annoyance. I sometimes start work on an image, and decide that I don't want to keep the changes that I've made. That should be my decision.
Personally, I think time would be much better spent on providing systems with transparent backup (give the electronic data a form of persistence closer to that of hard copy) so that recovering from a hard disk failure isn't such a traumatic experience - or even something that people need to worry about.
I mean, the premise is fine, but both of the two main reasons he talks about AREN'T TRUE! Just looking at the people who while about their favorite piece of cruft going away in Mac OS X should prove this. Take your pick: Trash on the desktop instead of in the dock, quick launch aliases in a highly hidden location (the Apple menu), applications strewn everywhere, etc, etc.
Also, the very idea of Microsoft inventing a good user interaction model is laughable. I don't know for certain which web browser first introduced tabbed browsing, for instance, but I know it wasn't made by either Microsoft or Apple. Ditto any number of interface features.
Let's move on to his examples, then.
He argues against having to save once. Well, I hate to break it to him, but I like to organize my documents. Further, I want to name it something very specific. Sure, applications can suggest a name, but when it comes right down to it for intuitive tasks computers are stupid. Even if we could get the intuition rate up to 95% I still wouldn't want one anticipating me in ways I can't see and correct. 5% error is unaccptable.
He argues a Quit commannd is unecessary and confusing. I have to disagree on this point, too. Perhaps it's not named the ideal thing, but let me use a simple analogy. When I want to put a nail into a wall, I go get my hammer. I line up the nail, smack it with the hammer more times than I'd care to admit, then... I put the hammer away. Computer applications are tools and need to be used the same way. As long as it is obvious the tool has not been put away and the way to put it away is obvious, it is an entirely intuitive operation. On these grounds, Mac OS Classic fails but Mac OS X passes. Apple got rid of the cruft. Microsoft also fails, because they try to make the ilusion of a tooless world but only succeed part of the time. Instead of having to find the tool, using it, then putting it away you need to find it, use it, find it, use it, find it, use it... and finding it is generally the hard part.
Yes, why DO you use file pickers for opening files? I almost never do! But when I do use one, I can't help but notice it looks exactly the same as the file manager. Further, Windows has an even better solution: Right clicking where you want to create the file.
I'm not going to bother with the fourth example. He scores a couple partial hits, but his average is way too low to bring the document back to respectability.
Just my two bits for what it's worth...