1027 words
Recently Matthew Thomas wrote an essay on interface cruft, that is, why user interfaces tend to go bad after a while. He makes a couple of interesting observations in this essay, some of which are beyond doubt while others deserve further discussion, which has already happened. Matthew even collected a few responses of which I agree strongly with that of John Gruber.
There are two main points of disagreement: Firstly, about whether or not having to save files manually is a good thing and secondly, whether or not applications should have a Quit button.
In an ideal world, I guess, you shouldn't need to have either as your applications automatically make sure your data don't get lost now matter how stupid you behave and good file formats along with clever indexing features make sure you'll find that letter you wrote for your auntie a couple of years ago although you don't have the faintest idea about how you filed it. Also, applications load instantaneously and those parts of them which may need to continue running, will....
If all this were true, there wouldn't be a need for Save or Quit buttons, would there? Unfortunately this doesn't sound like today's state of software. Today's software actually likes corrupting your data and file formats and indexing aren't quite up to making you automagically re-find your files. As John Gruber points out, all attempts of doing the clever bits in this fail miserably so far and have a distinct feel of being bossed around to it.
Also, I find it quite annoying that in MacOS X applications open new windows when you click their icon. While this behaviour may be acceptable behaviour for certain applications as web browsers (I still think it sucks, but that's mainly because I'm so used to pressing Command-N after switching...), it stinks for any non-trivial application.
An example for this is TextEdit. I click on TextEdits's icon and it opens a window. Now why does it open a window? Possibly because its programmers thought it'd be a clever thing to do as I'll probably want to type a document. The fact is however, that I hardly ever want to type a document in TextEdit. So why did I click it's icon in the first place? It's not to open an normal TextEdit file of course as double clicking it. It's not for opening a non-TextEdit text file either as dragging it onto the icon would've worked splendidly. So normally it's because I need to Open a file, say, in UTF-8 encoding which isn't recognised automatically. In analogy you could quote the import features of other applications that need a bit of user interaction before knowing what they're supposed to do.
And, most irritatingly, the programmers of TextEdit seem to have realised that when using the open menu item you end up with a spare, empty window. So TextEdit simply replaces that window. Of course this is just annoying and inconsistent behaviour as you don't expect windows to simply vanish. Ugh, sickeningly bad.
Of course the problem I mentioned could easily be solved by having properly working metadata that allows the applications to know what they're doing and doesn't require them to make wrong guesses. Of course for some reason or another there seems to be even less metadata around these days than there used to be. Apple even considers using their low-precision Type/Creator metadata as an optional feature at best (in fact opening and re-saving a file with Type/Creator information in TextEdit will delete that information).
So, I don't disagree with Matthew quite as much as I boldly claimed initially but my conclusion would be slightly different, stating that the reasons for interfaces to go bad are mainly in the underlying architecture which even after decades of so-called progress in software engineering and in term of Moore's law doesn't allow for the software to be un-crufty. (A hint on this may be in this article, which Matthew linked to as well.)
This is particulary evident for Matthew's main examples: Consider Desk Accessories in the late MacOS 9. They did launch quickly and they would quit themselves once you closed their window. Still they had a Quit item in their menu, so they could be quit via the menu as well. I wouldn't call that crufty. You wouldn't even notice the menu item existed. The problem with most other applications seems to be that they don't launch fast enough, particularly on MacOS X [I'll rant about this another time]. Make any application launch instantaneously and you wouldn't need the Quit item in any application. I think it's still needed these days, because you don't want to wait a few seconds to see you e-mail, you want to see it immediately.
The same goes for the saving business. Has anybody (except those BeOS people) seriously tried to get rid of hierarchical folders and so on for finding your files? It doesn't look like it. Actually there have been applications without a Save menu item for a while. They all had in common that either you rarely create new files with them, so they'll ask you for the location to store it when you create new file, or they simply only operate on one set of data. The first I remember was HyperCard but FileMaker comes to mind as well, as do Stickies (which have a Save item> that you don't really need) or any e-mail or usenet application and even our very own GeburtstagsChecker which tries to take care of your data reasonably well - but still has a Save item in its menu.
I don't think you can eliminate these menu items before they're obsolete in all applications. Otherwise the confusion you cause will more than eat up the advantage you get by being cruft-less.
Finally let me remark that I was delighted to see Matthew mentioning the Apple menu as we knew it. It simply was extremely useful and Apple was extremely wrong in replacing it by it's defunct substitute in MacOS X. Doing trivial tasks now requires extensive trips to your application folder where two moves of the mouse sufficed.