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)
Is the interface a command line? If not, it's crufty ;-)
GEOS on the commodore 64 had a good interface for it's time.
yes kids, that's right! the c64 had a GUI.
Be you Admins? nay, we are but lusers!
In Vernor Vinges sci-fi novel A fire upon the deep, he presents the idea of software archeology. Vinges future has software engineers spending large amounts of time digging through layers of decades-old code in a computer system like layers of dirt and rubbish in real-world archeology to find out how, or why, something works.
So far, in 2002, this problem isnt so bad. We call such electronic garbage cruft, and promise to get rid of it someday. But its not really important right now, we tell ourselves, because computers keep getting faster, and we havent quite got to the point where single programs are too large for highly coordinated teams to understand.
But what if cruft makes its way into the human-computer interface? Then you have problems, because human brains arent getting noticably faster. (At least, not in the time period were concerned with here.) So the more cruft there is in an interface, the more difficult it will be to use.
Unfortunately, over the past 20 years, Ive noticed that cruft has been appearing in computer interfaces. And few people are trying to fix it. I see two main reasons for this.
Microsoft and Apple dont want to make their users go through any retraining, at all, for fear of losing market share. So rather than make their interfaces less crufty, they concentrate on making everything look pretty.
Here are a few examples of interface cruft.
In the 1970s and early 80s, transferring documents from a computers 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. So, to avoid disrupting typists, software designers made this transfer a manual task. Every few minutes, you would save your work to permanent storage by entering a particular command.
Trouble is, since the earliest days of personal computers, people have been forgetting to do this, because its not natural. They dont have to save when using a pencil, or a pen, or a paintbrush, or a typewriter, so they forget to save when theyre using a computer. So, when something bad happens, theyve often gone too long without saving, and they lose their work.
Fortunately, technology has improved since the 1970s. We have the power, in todays computers, to pick a sensible name for a document, and to save it to a persons 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.
The original Macintosh, which introduced graphical interfaces to the general public, could only run one program at a time. If you wanted to use a second program, or even return to the file manager, the first program needed to be unloaded first. To make things worse, launching programs was slow, often taking tens of seconds.
This presented a problem. What if you had one document open in a program, and you closed that document before opening another one? If the program unloaded itself as soon as the first document was closed, the program would need to be loaded again to open the second document, and that would take too long. But if the program didnt unload itself, you couldnt launch any other program.
So, the Macs designers made unloading a program a manual operation. If you wanted to load a second program, or go back to the file manager, you first chose a menu item called Quit to unload the first program. And if you closed all the windows in a program, it didnt unload by itself it stayed running, usually displaying nothing more than a menu bar, just in case you wanted to open another document in the same program.
Trouble is, the Quit command has always been annoying and confusing people, because its exposing an implementation detail the lack of multitasking in the operating system. It annoys people, because occasionally they choose Quit by accident, losing their careful arrangement of windows, documents, toolboxes, and the like with an instantaneity which is totally disproportionate to how difficult it was to open and arrange them all in the first place. And it confuses people, because a program can be running without any windows being open, so while all open windows may belong to the file manager, which is now always running in the background menus and keyboard shortcuts get sent to the invisible program instead, producing unexpected behavior.
Fortunately, technology has improved since 1984. We have the power, in todays computers, to run more than one program at once, and to load programs in less than five seconds.
We have the technology. So why do we still punish people by including Quit or Exit menu items in programs? Cruft.
As I said, the original Macintosh could only run one program at a time. If you wanted to use a second program, or even return to the file manager, the first program needed to be unloaded first.
This presented a problem when opening or saving files. The obvious way to open a document is to launch it (or drag it) from the file manager. And the obvious way to save a document in a particular folder is to drag it to that folder in the file manager. But on the Mac, if another program was already running, you couldnt get to the file manager. What to do? What to do?
So, the Macs designers invented something called a file selection dialog, or filepicker a lobotomized file manager, for opening and saving documents when the main file manager wasnt running. If you wanted to open a document, you chose an Open menu item, and navigated your way through the filepicker to the document you wanted. Similarly, if you wanted to save a document, you chose a Save menu item, entered a name for the document, and navigated your way through the filepicker to the folder you wanted.
Trouble is, this interface has always been awkward to use, because its not consistent with the file manager. If youre in the file manager and you want to make a new folder, you do it one way; if youre in a filepicker and you want to make a new folder, you do it another way. In the file manager, opening two folders in separate windows is easy; in a filepicker, it cant be done.
Fortunately, technology has improved since 1984. We have the power, in todays computers, to run more than one program at once, and to run the file manager all the time. We can open documents from the file manager without quitting all other programs first, and we can save copies of documents (if necessary) by dragging them into folders in the file manager.
We have the technology. So why do we still make people use filepickers at all? Cruft.
This last example is particularly nasty, because it shows how interface cruft can be piled up, layer upon layer.
In Microsofts MS-DOS operating system, the canonical way of identifying a file was by its pathname: the concatenation of the drive name, the hierarchy of directories, and the filename, something like C:\WINDOWS\SYSTEM\CTL3DV2.DLL. If a program wanted to keep track of a file in a menu of recently-opened documents, for example it used the files pathname. For backward compatibility with MS-DOS, all Microsofts later operating systems, right up to Windows XP, do the same thing.
Trouble is, this system causes a plethora of usability problems in Windows, because filenames are used by humans.
What if a human renames a document in the file manager, and later on tries to open it from that menu of recently-opened documents? He gets an error message complaining that the file could not be found.
What if he makes a shortcut to a file, moves the original file, and then tries to open the shortcut? He gets an error message, as Windows scurries to find a file which looks vaguely similar to the one the shortcut was supposed to be pointing at.
What happens if he opens a file in a word processor, then renames it to a more sensible name in the file manager, and then saves it (automatically or otherwise) in the word processor? He gets another copy of the file with the old name, which he didnt want.
What happens if a program installs itself in the wrong place, and our fearless human moves it to the right place? If hes lucky, the program will still work but hell get a steady trickle of error messages, the next time he launches each of the shortcuts to that program, and the next time he opens any document associated with the program.
Fortunately, technology has improved since 1981. We have the power, in todays 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.
We have the technology. So why does Windows still suffer from all these problems? Cruft.
Lest it seem like Im picking on Microsoft, Windows is not the worst offender here. GNU/Linux applications are arguably worse, because they could be avoiding all these problems (by using inodes), but their programmers so far have been too lazy. At least Windows programmers have an excuse.
To see how the next bit of cruft follows from the previous one, we need to look at the mechanics of dragging and dropping. On the Macintosh, when you drag a file from one folder to another, what happens is fairly predictable.
Windows has a similar scheme, for most kinds of files. But as Ive just explained, if you move a program in Windows, every shortcut to that program (and perhaps the program itself) will stop working. So as a workaround for that problem, when you drag a program from one place to another in Windows, Windows makes a shortcut to it instead of moving it and lands in the Interface Hall of Shame as a result.
Naturally, this inconsistency makes people rather confused about exactly what will happen when they drag an item from one place to another. So, rather than fixing the root problem which led to the workaround, Microsoft invented a workaround to the workaround. If you drag an item with the right mouse button, when you drop it youll get a menu of possible actions: move, copy, make a shortcut, or cancel. That way, by spending a couple of extra seconds choosing a menu item, you can be sure of what is going to happen. Unfortunately this earns Microsoft another citation in the Interface Hall of Shame for inventing the right-click-drag, perhaps the least intuitive operation ever conceived in interface design. Say it with me: Cruft.
So, Windows designers made a slight tweak to the way shortcut menus work. Instead of making them open when the right mouse button goes down, they made them open when the right mouse button comes up. That way, they can tell the difference between a right-click-drag (where the mouse moves) and a right-click-I-want-a-shortcut-menu (where it doesnt).
Trouble is, that makes the behavior of shortcut menus so much worse that they end up being pretty useless as an alternative to the main menus.
They take nearly twice as long to use, since you need to release the mouse button before you can see the menu, and click and release a second time to select an item.
Theyre inconsistent with every other kind of menu in Windows, which opens as soon as you push down on the mouse button.
Once youve pushed the right mouse button down on something which has a menu, there is no way you can get rid of the menu without releasing, clicking the other mouse button, and releasing again. This breaks the basic GUI rule that you can cancel out of something youve pushed down on by dragging away from it, and it slows you down still further.
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. Once more, with feeling: Cruft.
Meanwhile, we still have the problem that programs on Windows cant be moved around after installation, otherwise things are likely to break. Trouble is, this makes it rather difficult for people to find the programs they want. In theory you can find programs by drilling down into the Program Files folder, but theyre arranged rather uselessly (by vendor, rather than by subject) and if you try to rearrange them for quick access, stuff will break.
So, Windows designers invented something called the Start menu, which contained a Programs submenu for providing access to programs. Instead of containing a few frequently-used programs (like Mac OSs Apple menu did, before OS X), this Programs submenu has the weighty responsibility of providing access to all the useful programs present on the computer.
Naturally, the only practical way of doing this is by using multiple levels of submenus thereby breaking Microsofts own guidelines about how deep submenus should be.
And naturally, rearranging items in this menu is a little bit less obvious than moving around the programs themselves. So, in Windows 98 and later, Microsoft lets you drag and drop items in the menu itself thereby again breaking the general guideline about being able to cancel a click action by dragging away from it.
This Programs menu is the ultimate in cruft. It is an entire system for categorizing programs, on top of a Windows filesystem hierarchy which theoretically exists for exactly the same purpose. Gnome and KDE, on top of a Unix filesystem hierarchy which is even more obtuse than that of Windows, naturally copy this cruft with with great enthusiasm.
Following those examples, its necessary to make two disclaimers.
Firstly, if youve used computers for more than six months, and become dulled to the pain, you may well be objecting to one or another of the examples. Hey!, youre saying. Thats not cruft, its useful! And, no doubt, for you that is true. In human-computer interfaces, as in real life, horrible things often have minor benefits to some people. These people manage to avoid, work around, or blame on user stupidity, the large inconvenience which the cruft imposes on the majority of people.
Secondly, there are some software designers who have waged war against cruft. Word Places Yeah Write word processor abolished the need for saving documents. Microsofts Internet Explorer for Windows, while having many interface flaws, sensibly abolished the Exit menu item. The Acorns RISC OS abolished filepickers. The Mac OS uses file IDs to refer to files, avoiding all the problems I described with moving or renaming. And the ROX Desktop eschews the idea of a Start menu, in favor of using the filesystem itself to categorize programs.
However, for the most part, this effort has been piecemeal and on the fringe. So far, there has not been a mainstream computing platform which has seriously attacked the cruft that graphical interfaces have been dragging around since the early 1980s.
So far.
Discuss
See http://info.astrian.net/jargon/terms/c/crufty.html
Hey! That's my sig you're smoking there!
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.
Though the author points out crufts only in software, these are prevalent in other places too, including interfaces to portable devices. I have a similar document on portable device interfaces here.
It comes out of designing without taking into account user actions and reactions. This subject is un-fashionably called "Industrial Design", but is becoming fashionable again....
"Do something man. Right now."
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
"software archeology"
I work day in day out on a ten year old system. I do not use the term archeology, however I frequently find what I call 'fossils'. Parts of code that are still there, but are never executed. Fields of the database that should have been deleted but are still there, and are still updated, though no program ever uses them. A system has to be sufficiently large however, to experience this. But actually funny to read about this.
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.
Yes we do, but for starters a computer is a tool. You tell the computer what to do, the computer does not tell you. Sure we have autosave, but any sensible application auto-saves to a different filename so that if you decide to abandon your changes, you can just quit, not save and revert back to your original format. If you quit a document, you'd still have to agree. What happens when you do want to commit those changes to your file but you don't want to quit? You have to "save".
Fortunately, technology has improved since 1984. We have the power, in today's computers, to run more than one program at once, and to load programs in less than five seconds.
Here the author obviously hasn't used a PocketPC. With the PPC its very very easy not to close applications. What happens? The system slows down to a crawl as it tried to run 5 or 6 different applications. Again, this is the user being in control of the computer. I want the ability to close applications when I'm not using them. That is my decision, not the computers. It's the desktop analogy. Once i've finished with a book, I put it away because otherwise my desk gets cluttered. I don't leave it out because otherwise my desk gets full and working becomes a problem. Sure, we could get around this by having the PC unload or suspend applications that aren't used in a while - but how does it decide? Just because I've not typed something into Word for the past 30 minutes doesn't mean that I'm not using it. You'd get to the point where the cleverness of the OS/Application was causing me more hassle as it tried to be helpful and suspend stuff for me.
Fortunately, technology has improved since 1984. We have the power, in today's computers, to run more than one program at once, and to run the file manager all the time. We can open documents from the file manager without quitting all other programs first, and we can save copies of documents (if necessary) by dragging them into folders in the file manager.
What about if the application is taking over the whole of the desktop? I'll have to minimise and then drag. Having said that though RISCOS (I think, the one on the Archimedes) used to allow that. You hit Save and the icon appeared for you to drag somewhere. Best thing was that you could drag from one application into another to have it load in there. Neat. But very wierd.
As for inode stuff, sounds neat. But I know so little about that type of thing, I wouldn't even know it's feasible.
So in short, some good ideas, but some of them just aren't practical or possible and would end up being a bigger annoyance than it currently is.
Avantslash - View Slashdot cleanly on your mobile phone.
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.
(getting the fscking html tags correct this time) Lest it seem like I'm picking on Microsoft, Windows is not the worst offender here. GNU/Linux applications are arguably worse, because they could be avoiding all these problems (by using inodes), but their programmers so far have been too lazy. At least Windows programmers have an excuse.
No, the hackers aren't lazy - they're just too busy trying to ape the MS windowes look and feel....
The interfaces of today represent how a computer actually work. For example, the need to save a document. This is not a bad thing if done properly, in fact, it helps (forces) the users to understand how the actual machine works (it writes periodically to the disk, and not one character at a time).
When saying this I'm not saying that there are flaws in the interfaces of today, and I do agree on that the open source movement lack much of the initiative to make things better. However, making all computer tasks behave as things in 'the real world' will not work. I'm not even sure if all metaphors used today are good. It's better to reflect the actual tool, than try to make it look like something that it is not, this will only result in disapointed and surprised users.
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."
In a) he talks about the use of inode numbers as an internal reference used by the system. Regrettably, inodes and other equivalent internal reference numbers used by other file systems under other alternative operating systems can move around. Generally opening by inode is only recommended after first opening by name.
Having more than one pathway to a file as mentioned in d) in windows is most definitely a feature. For engineering reasons a manufacturer may want to keep a set of files from related applications together, however to the user they may be presented somewhat differently. If anything this is an improvement of interface because of the separation between external and internal representations.
As for the problems of moving applications around, that is also an issue with meta information held in INI files or the registery. It is quite possible to make a program easier to move (i.e., by including code to update the file locations), but this isn't often done.
The file/folder metaphor may have probems for newbies but the only real problem is that file (particularly with Unix style file systems) may have more than one name. This is a feature not a bug.
``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!
While I really like GAIM for its all-in-one approach to messenging protocols, the authors deserve a kick in the balls for having windows that constantly raise to the front, every time someone sends you a message. The result is, you are typing an e-mail or programming and, all of a sudden, what you typed ends up in the wrong window, simply because GAIM is receiving an incoming message for you. Bad, Bad, Bad GAIM..
People coding window managers should also wake up to the fact that not everyone wants the latest application someone started to pop in their face, while they are returning to another window during the application startup. e.g. If I start OpenOffice and I know for fact that this piece of bloatware needs 5 minutes before the main window comes to screen, so I go back to typing e-mails until the application has loaded, I do not want frigging OpenOffice popping up and assuming thta what I was in the middle of typing was meant for its Untitled 1 document. As such, Xlib and other OSes' GUI libs should completely remove the ability for an application to request that one of its windows be raised and brought to the foreground since, anyhow, window mangement is the responsibility of... window managers.
Software is not supposed to be about how to work around a useability issue. - Ken Barber
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).
Anyone from the UK may have noted that Crufts is the name of the annual dog show of the Kennel Club in the uk.
While I really like GAIM for its all-in-one approach to messenging protocols, the authors deserve a kick in the balls for having windows that constantly raise to the front, every time someone sends you a message. The result is, you are typing an e-mail or programming and, all of a sudden, what you typed ends up in the wrong window, simply because GAIM is receiving an incoming message for you. Bad, Bad, Bad GAIM..
Got an extra 10 seconds? Take a peek in the preferences dialog, and turn that behavior off.
You use the "Undo" button to undo. Or you use version control. Using "Save" in order to manage versions and undoing is error prone and unintuitive.
Some years ago, I ordered from Acorn the "RiscOS developper reference manuals".
It is not only an exhaustive reference but also comes with a style guide.
I guess this style guide would be invaluable for non-RiscOS developper, especially after browsing through the interface all of shame...
So, why don't these development suites (visual studio, etc) come with such a book ?
Trolling using another account since 2005.
The article clearly moans on and on about how Windows doesn't do this and doesn't do that. While XP f.e. DOES do a hell of a lot the author claims it doesn't. (moving a file where shortcuts point to f.e.)
Also, be glad the OS has a gui. Having to learn every darn flag of every darn commandline tool out there (plus where they are located) and having to know every layout/syntaxis of every config file out there is way way way more painful than clicking on some buttons.
Sure, 10 programs with 10 buttons each is also complex, but the programs regularly come with documentations, explaining the usage. And what should developers do? A lot of people claim they can't even operate a VCR for crying out loud.
Never underestimate the relief of true separation of Religion and State.
Especially since mpt acted as the UI module owner for Mozilla.
A good example of open source design gone bad; where every voice is counted, regardless of whether that voice has any merit to it or not. Like a mirage, lack of ownership makes any ownership look a solution to the problem. Enthusiasm and verbosity belie the lack of expertise.
The ROX Desktop has gone someway to implementing this on X - rather than blindly re-implementing the Windows Way like so many other projects.
there are more differences, just try to reformat a pen written text or to erase some text in the middle of the document.
see the difference?
my point is, a computer is a machine, quite powerful and complex. and it should be used like such a machine, not imitate something. different tools are used differently. not intended to be a flamebate but if people are too stupid/ignorant to realize this then they should stay by pen and paper.
"It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
I agree to many points. Modern GUIs use a lot of crutches to make them self workable. Some problems and wishses:
:)
:)
My favortie is the Save/Open Dialog box, a relic from the single tasking days, why do people use crippled version of the file browser? Risc OS did it correctly, drag an icon from the app to the browser, or even other application!
Just get rid of the File menu all together.
Finding files is still a chore, I do miss BFS instant and always up to date live queries. Can we please have that, Apple/Microsoft/Others?
Installation of applicatons, what is up with that? Why can't I just copy a file from the CD/Net and be done with it?
File ID's are good idea, I could move apps/files around on BeOS and my shortcuts still worked!
Why can't we implement version control transparently in the filesystems? Hardly due to lack of space? Each save creates a new version. Word processors could even use intelligent versioning, like making a new version for each paragraph or chapter. Does Photoshop save undo in its files?
Right now I am using very Explorer-like client for CVS, and it doesn't matter if I am browsing my hard drive or some remote server in Elbonia, it all looks the same, wonderful!
I have been using XP for a while now, and it is making me quite frustrating. Why can't I use all that NTFS has to offer? (AFAIK, NTFS is pretty close to BFS in features, not sure about Live Queries, though)
What else... yes... Use open standards when data leaves the application!!!!. I can't <em> this enough. BeOS sort of did this with it's Translator service. Your image viewer/editor didn't even have to know how to load/save JPEG or PNG files!
Well, enough of this rant.
J.
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.
He goes on in point 2 to complain about the quit or exit commands in the problems, explaining that they are there because in the beginning, Operating systems didn't multitask.
He says "We have the technology. So why do we still punish people by including "Quit" or "Exit" menu items in programs? Cruft."
What is he trying to say? That once a program is running, it should run forever? Why shouldn't I be able to close Netscape when I'm done? How is this Cruft?
-- -- 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
True story: Somebody I knew was one of the many people with Window-phobia. Using the (File-)explorer was nearly a insurmountable taks. But she (I'm not trying to uphold a steriotype here, I know men who are even worse) was the chairman (or chairwoman) of a social club and needed to keep track of all the names and adresses of all the members.
She only needed one list so I made a programme that was specific for that task. Once you opened the programme the database was automatically opened. It was saved as you exited (or if you printed, just in case windows crashed on printing). It had no menu bar or status bar, just a row of buttons with home-made images on the right like:
- Add member (pic: Arrow to document)
- Change member; but you could also doubleclick (pic: Arrow from and to document)
- Delete menber (pic: Arrow from document to cross)
- Print (pic: printer), which didn't popup a print setting dialog!
- Exit (pic: point to door), because she didn't undestand what the three buttons were for at the top-right of the window.
It had keyboard shortcuts, but she never used those.
From the day she first used it she loved it. It supplied just the things you need and nothing more.
Summerisingly, I think that there is an even worse Cluft than the article mentioned: unnecessary options. I see it all the time: people are so easily distracted by all the options they never use. It quickly causes another phobia: option-phobia. They are so afraid they accidentally start one of those stupid options, not knowing how to shut it up again.
It works like this (for a new user):
See this screenshot (near the bottom of the page).
in the 70's (or was it the 80's?) had this feature. It would save things automatically to an internal buffer (on disk), from which things could be restored in the event of a power outage. That feature saved me more than once.
It's a useful thing. No operator intervention required.
Vernor Vinge's A Fire upon the Deep is one of my favorite books, and I was quite happy to see it mentioned in the beginning of the article.
A rather memorable quote:
"Half-assed programming was a time-filler that, like knitting, must date to the beginning of the human experience."
We can neither love nor pity nor forgive. If you make a slip in handling us you die!
For ultimate Cruft, what about dragging something over the taskbar icon for the app. I've never understood why this doesn't do exactly the same as dragging the item over the application window, but the damned thing doesn't work. And I can start dragging something and then press Alt-Tab to bring up a menu of currently-running apps. But I can't drop the item onto that menu of apps. Why the hell not???
Now, if the hardware were to change such that we weren't tethered to mice and keyboards, then I can see some interesting possibilities. But things being what they are, I'm quite content with my shell and VI.
RiscOS has some really neat GUI features, although the OS has failed to evolve and is currently light years behind contemporary preemptive multithreading, networked, journalling blah-di-blah OSs.
Indeed one of the things Acorn got right long before Apple, Microsoft, and most others, is that primarily the OS should integrate applications; you shouldn't expect to integrate with each other. This most clear with Microsoft Office, which over the years has consistently integrated perfectly with itsself, while keeping possible competitors or "plug-in" suppliers away from their honeypot.
Ah well. I guess RiscOS might have been pretty much alive if only Acorn would have taken their loss and GPLed all their sources after one of their bankrubsies...
For the most part, we have only ourselves to blame for this cruft problem. Alternatives have already been brought to market and died. Maybe we were short-sighted consumers?
Example 1: Single-level store
Actually this one survived in the market - sort of. It was part of the old IBM Future Systems effort, and made it out the door as the System/38, with followons in the AS/400 and iSeries. Single level store says you get rid of that silly distinction between RAM and disk - everything is memory. What we quaintly call main-memory is merely another level of caching to the disk, which is the real memory. Then you make the big thing a database instead of just a filesystem, and it can readily solve pretty much all of his numbered problems in one fell swoop. Was this perhaps something like Longhorn, only about 20 years ago?
The System/38 and descendents has met with success, largely as the closest thing to 'just plug it in and run' that has made it to market. At another level it hasn't been that successful, largely because of its unconventional and rather opaque system model.
As an interesting aside, IBM's first entry into the workstation arena, the Romp microprocessor, also had single-level store capability. (actually expressed in inverted page tables) Then in order to make it more Unix-familiar they mapped a conventional filesystem on top of that. I don't know if Rios and PowerPC followons retained that capability or went to more conventional paging architectures.
Double aside: Romp/Rios/PowerPC are yet another fallout of the Future Systems effort. Any big project has a backup plan, and one of the backup plans for FS was the 801 minicomputer, the original RISC.
Example 2: The OS/2 Workplace Shell
Just a bunch of UI glue, but what a bunch of it! It directly solved the broken link problems, and had a more consistent, if different set of mouse semantics. It also has a group feature that kind of got around his 'quit' problems.
But I disagree with overusing the inode the way he suggests. The inode is an internal structure and isn't meant to have a UI-level life. He really wants access to Data, not to Filename or Inode. Does he really want a database-type filesystem?
My own fantasy is a semi-conventional filesystem, but instead of a conventional directory structure use a semantic network. The role of directory navigation is taken on by relationships. It's an incomplete idea at the moment, though.
The living have better things to do than to continue hating the dead.
Have you actually ever had to use MSVC? I've not used the .Net version yet, but VC6 is great. It's not got a perfect UI, but it's a better C++ dev environment that anything else I've used. I've just moved over to working on Linux at work, and let me tell you, it's been painful. KDevelop is coming along nicely, but it's still nowhere near VC6.
I'd like to know what exactly it is in VC6 which is 'cruft'. Sure, notepad is a lot smaller, but it lacks a compiler, a debugger, project management, undo past save, syntax highlighting, autoindenting, code completion, a comprehensive help system etc... MSVC is much bigger, but then it's much more useful.
On the Lisa, your documents had two filenames: one for the computer and one for the user. If you renamed your document (i.e. the icon now reads "List of pr0n sites to visit" instead of "Winnie the Pooh Fan Sites"), as far as the operating system and LisaWrite were concerned, it was still the same file. The example of "cruft" that the author gave was that your "recent documents" list would be inaccurate after the rename. This problem wouldn't have existed under the Lisa's mechanism.
I do have to admit that it has been about 15 years since I've last used a Lisa nonetheless SEEN one, but I do have to say that Lisa's user experience was far better thought out than what we have today. Everything was document oriented, not application oriented like todays Windows and Apple GUIs.
Never hit your grandmother with a shovel, for it leaves a bad impression on her mind...
What IS preventing us from getting rid of the "quit" menu item? I mean, with today's amount of RAM, I think all of the binaries of a system can fit WELL within RAM+Pagefile. So why NOT have all programs "loaded at once"? In fact...if they are all "loaded at once", why do we even need to "load" them at all? When they are installed they should just be stuck into memory or virtual memory, and the first time you run the app it will page itself back in.
Perhaps it may not be entirely realistic at this point, but we should be asking these "why?" questions.
It's 10 PM. Do you know if you're un-American?
Auto-saves aren't a solution. The problem is that people (and OS designers) still think in 60's style of Memory/Storage world. Of course we should stop doing that. Just use Storage. The Memory is just a fast cache for the Storage.
Of course a application with no data should not just sit there, taking up display and memory space.
File picker sucks. I just can't agree with you there. They are evil, UI Challenged piece of shit. That drag'n drop problem you describe can easily be solved.
You are thinking it backwards. If you want to change a symbolic link, you er... change the symbolic link, not the file it points to! So I disagree there too.
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.
Do you really have so little faith in programmers? This is an implementation detail that the average Joe User should not worry about. It is in fact sooo simple I can even think up a method right here:
1. User drags a application to his hard drive.
2. The OS checks the file and what libraries it needs.
3. The OS installs those libraries.
4. Profit! (har har)
We only need a tiny bit of intelligence added to the OS for this to work.
Besides, I have recently begin doubting the existance of libraries. We have plenty of space these days, why not make everything statistically linked?
J.
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.
Just to keep myself honest, I force myself to do sysadmin tasks in vi. Generally I use emacs for source code. Tonight I used vi to write a small Perl program to change a bunch of URLs in a bunch of web pages to a different layout system. I've been writing a lot of PHP lately and I haven't used Perl for a couple of years. The entire project is a refresher course.
Editing Perl with vi! Talk about a cruft implosion. To make things worse, I was using a very bad version of vi that came standard with Debian potato. It doesn't indicate on the screen that you are in insert mode. Certain kinds of cursor motion break insert mode when you least expect it. It doesn't even have a line number indicator on the status bar.
Aside from all the obvious reasons I've been trying to figure out why I hate vi as much as I do. I've put up with worse and complained less. Yet somehow as much as I try to accept vi for what it is I fail miserably.
I was paying special attention to my vi misery as I permuted Perl's line noise. Here's what it comes down to. If you have N characters on a line, there are N+1 positions where you might wish to insert a new character. Yet in vi you can't actually reach all these positions without first entering insert mode: the position that appends to the end of the line is not available. This leads to the ludicrous effect that whenever you cancel insert mode, your cursor moves one character to the left (unless you are already at the beginning of the line). Oh, and you can place yourself at the end of a line when you are not in insert mode--if the line happens to be completely empty.
So there I am getting slap happy with vi (banging escape whenever I forget what mode I'm in, which is almost always) and every time I bang escape I have to watch carefully to see if my cursor skids left.
It's bad enough having two modes. But did the concept of current position also have to be different between the modes? Incredible. Just for this one reason vi constantly gives me the feeling I'm babysitting a naughty child.
On the other hand, emacs might be barroque, but I rarely spend much time thinking about my hands unless I'm trying to do something that isn't habitual. I rarely use a feature in emacs I didn't learn in the first two days. "feature freeze" in emacs is modal in its own way. One moment you are working productively, the next moment (or hour, or day) you are whittling away at one billion options you don't want. But there's the difference: emacs is modal once an hour, vi changes modes faster than you can blink, or think.
There's a general rule (apparently unknown to the anticruft crusader who launched this topic) that cruft is eliminated only when something new comes along that's ten times better. Only ten times. And vi still exists. Amazing.
After accidentally hitting a geocities site, I now have to *manually* close 150 pop-under/over/beside windows, each one of which pops up another 150 windows.
I want IE dead, and I want it now!
Where's my Exit menu item?
(I know, I know, it's in Mozilla. Time to switch.)
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
So then you either
1) Have to switch desktops, hope there is an open place there, find and click on it or
2) Shade a window, hope there is an empty space there, find and click on it.
Seems to me you just added at least 1 click and a mouse movement to the process, making it more difficult. Whenever I've needed to find open desktop on my machine it has been a frustating ordeal.
Just for kicks, I just shaded my mozilla window to try to find the nearest open part of the desktop. Guess what? Lower left corner, just above the "Big K"
One thing he forgot was the biggest cruft in our time. The QWERTY keyboard is designed to slow typists down so that keys don't get stuck when typing to fast. Typerwriters (at least the mechanical ones that had keys that got stuck) are long gone, but we still use this extremely inefficient layout.
As a result of this bad design, people have decided to design programming languages around the keyboard layout. As a result, we use ; to end statements since ; is on the home row. CRUFT!
Why aren't we told when editors moderate our posts?
"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.
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.
As off-base as I think the author is, it's good to think this way. Even if it's not practical or better.
Save is an advantage, not an obstacle. The article's author limits the use of Save to things like Word-processing (immediately betraying his experience with more esoteric formats). As others will surely point out, Save can save you when something you're working on goes on a tangent. Besides, Word (and others) can AutoSave.
Launching/Quitting programs, while arguably cruft, has been accepted insofar as people do like the tool metaphor. You use a jigsaw to cut complicated shapes in wood. A screwdriver for attaching things. Photoshop for graphics, etc. Although I will admit Quit is getting a bit weird... esp. on modern systems like OS X, where there isn't that much of a reason to Quit things. I still do it out of habit.
Filenames are... well, filenames, and they don't seem to ever change. I don't really see a disadvantage with a 256-character filename. The dot-3 suffix is a bit of an anachronism, but it's a comfy one, one that gives the user a bit of metadata as well as the computer. Windows' behaviour of only recognizing files with certain suffixes in file dialogs by default has reinforced this.
I don't know what he means by the File Picker. I launch/pick stuff from the Finder all the time.
What I'd really like to see is a better representation of relationships between files. Something akin to The Brain, or another derivative of Xerox's Hyperbolic Tree structures. Radial menus, with branches running in various directions to the related objects/files, have been proven to be more effective than lists of data (there's something humans like about remembering angles as opposed to just the names). People themselves need a better representation, too. iChat has taken baby steps towards this, but really, ponder for a moment; why can you not see the heads of all your friends popping up on your desktop? Why is it that we have to 'browse' for other people, either through an AIM window (another list) or some such mechanism? If I get an email from Mike I want to see a mail icon next to Mike's head. I want to send files to Mike by dropping them onto his head. I want to see *everything* that is related to Mike at a click.
Also, to mention another pet peeve: themes. People love themes. People abuse themes. There is a need here that has never been addressed fully, IMHO - the problem is that people are dressing up the cosmetics of the interface while doing nothing to change the behaviour. It's sort of ridiculous to think that we can come up with a Swiss Army Knife interface that will be maximally productive for all conceivable computer tasks. I've actually taken to creating several different accounts on OS X, each with their own specialized settings. If I'm doing graphics work, I want everything to look like a light table; big shiny icon previews, sorted by meta data (time photo was taken, type of graphic, etc.) If I'm doing coding, I want list views or column views everywhere, and lots of reporting tools running on the desktop (bandwidth, terminal). There really should be interface schemas that can switch on-the-fly to whatever sort of task you are engaged in.
If Jesus wants me it knows where to find me.
That's the kind of stuff we have to figure out. I'm not blowing off the rest of your post, but the question above is where we start. We start by defining the problem, sub-problems, etc. For the way things work now, obviously we'd want to figure out a better way for the example you gave, rather than just saving entire undiffed streams.
Everbody should use VAX/VMS!
I think while the author has some interesting points about interface problems, the issue here is that both the current MacOS X and Windows XP interfaces still owe a lot to the GUI concepts pioneered at Xerox PARC during the 1970's--and because of its massive infiltration any attempt at an alternative isn't exactly going to be popular. Indeed, most of the themes in both Gnome and KDE follow the same ideas pioneered from Xerox PARC's work.
Let's see if someone with the money to burn can come up from scratch with a GUI for Linux that implements a lot of the interface suggestions the author mentions--I wish them lots of luck!
like plan9 does
no root = fewer nasty accidents
by moving stuff out of the kernel and into user space
foot shooting is still possible but by no means so easy as rm -rf * in the wrong directory.
[having a file server with NO user space and automated versioned backups built in helps too]
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
In Vernor Vinge's sci-fi novel A fire upon the deep, he presents the idea of "software archeology". Vinge's future has software engineers spending large amounts of time digging through layers of decades-old code in a computer system - like layers of dirt and rubbish in real-world archeology - to find out how, or why, something works.
Actually, it's not decades old - it's millenia and even millions of years old and was maintained by multiple civilizations of sentient beings ("sophonts") that built layers upon layers of translation.
In Vinge's A Deepness in the Sky the control code for the slower-than-light spaceships of the Qeng-Ho space traders is "merely" thousands of years old and written by humans only.
The Qeng-Ho measure time in seconds (kiloseconds, megaseconds, etc). They say that the reference time is the landing of man on the moon but can't account for an error on the order of magnitude of 10 megaseconds. (it's actually 14 megaseconds - the time from the moon landing to the Unix epoch)
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
Besides X:\Programs is a lie because that folder also contains configuration files, backups of replaced files, data files etc.etc.
what they need to come up with is something like
\bin
\etc
\usr\$HOME
hmm, I think I've seen that before somewhere, maybe it was Xenix
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
...in the "Interface Hall of Shame" using frames? :-)
human://billy.j.mabray/
"Every good system has a backup." -- Dale Hanchey
There's no documented way of calling SHGetFolderLocation from C# without having a System.ExecutionEngineException being thrown.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
If the site was up-to-date, they'd be going after iCal 1.0, which came with Jaguar just lately. Tons of critiques on Macintouch of the immaturity of that interface. Apple's not perfect, but they take interface seriously, and the users' standards reflect that.
"Fundamentalism" isn't about divine morality. It's about human authority.
Windows 95 introduced the concept of in-place editing throughout Windows. Word and other apps already supported in-place editing of OLE/COM objects (such as a spreadsheet embedded in a document). Win95 extended that concept to the "shell".
The most perverse example of this is renaming a file. I *like* editing the name in-place, but I *detest* the way they chose to implement it. When the filename is selected, single-click on it to rename it. On paper, this sounds fine. I'm sure the Microsoft system engineers approved this requirement as a nice convenience.
But how many times have you attemted to double-click a file and ended up in edit mode? Now to get out of it you have to either hit the Escape key, or single-click elsewhere. Then try the double-click again. If you haven't had your morning coffee yet, your double-clicks are probably a bit slow, so you repeat this cycle three time before you finally succeed at launching that program!
And how many times have you accidentally renamed a file this way and never known it, until you're searching for that file 10 days later?
I'm amazed this "feature" is still in XP. I wish there were a way to disable it.
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.
The author of the article, Matthew Thomas, also wrote two very good pieces
"Why Free Software Usability Tends To Suck"
"Why Free Software Usability Tends To Suck Even More".
They are an eye-opener for any one who has wondered why linux is still not ready for the desktop despite the prescense of so many talented programmers in the Free Software Community
Ergonomica Auctorita Illico!
On NT, minimized Windows apps use negligible system resources except swap space and toolbar space
:-)
Ok, thanks for the info. Yeah, when I talk Windows these days I always mean NT-based Windows. What you're saying about Win9x was funny and actually not that surprising at all. Backward compatibility with Win 2.x?! A truly impressive achievement by MS there.
Beware: In C++, your friends can see your privates!
I liked this page here
Some foolish Autodesk coder forgot to remove the tooltip comment:
"Click this to display an overview of the dialog box, idiot"
Forgetting this was probably a good way to get fired (as is mentioned) without a recommendation.
I've heard of a similar mistake, wherein a programmer for bank software was writing routines to do discounts, etc for customers who kept very large balances. To check the functionality of the routine, a message with some comment to the extent of "fat-cats with big walls" was printed as debug on transaction slips from the bank machine. However, the programmer forgot to remove this before the first production releases.
I'm assuming that he is also now an ex-coder (at least as far as the banks as concerned). As a warning, if you are going to put amusing and possibly insulting debug code in, make sure you write yourself lots of memos to remove it before production (or better yet, just use something not insulting).
Similarly, I remember at some point I was making a massmail system. On test messages, the header was "all is well and fine." Of course, in production one of the first messages was about a major security issue that resulted in formmail (yick) being removed from accounts, and since I forgot to remove the $subject="All is well and fine", the intended subject line was overwritten. I didn't get fired, but it did leave me red in the face. Luckily my boss and customers are understanding and have a sense of humour.
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
Here the author obviously hasn't used a PocketPC. With the PPC its very very easy not to close applications. What happens? The system slows down to a crawl as it tried to run 5 or 6 different applications. Again, this is the user being in control of the computer. I want the ability to close applications when I'm not using them. That is my decision, not the computers. It's the desktop analogy. Once i've finished with a book, I put it away because otherwise my desk gets cluttered. I don't leave it out because otherwise my desk gets full and working becomes a problem. Sure, we could get around this by having the PC unload or suspend applications that aren't used in a while - but how does it decide? Just because I've not typed something into Word for the past 30 minutes doesn't mean that I'm not using it. You'd get to the point where the cleverness of the OS/Application was causing me more hassle as it tried to be helpful and suspend stuff for me.
On an all-in-ram storage device, if you are competant (i.e. not Microsoft or Sharp) you want to take advantage of a stateless interface model, where there is no quitting of applications or saving. You go to a different work area and the process is suspended in ram as you left it, and your data is just as you left it. It is still you making the decision; you are making the decision to put aside your work and go back to it at a later time. When you're not using an application, it's last operating state (maybe aside from the stack) is saved in ram. Of course, this design has traditionally only worked with devices that are mostly nothing but memory and it is generally understood by developers that applications are to be written to use as little memory as possible because RAM is the only storage you have. Devices like the Palm come to mind.
On a Palm, you don't quit the datebook, you write some stuff into it, go use another app, and when you go back to the datebook, you're back at the last thing your wrote, down to the last character and the last cursor position. No multiple processes necessary, because instead of having several multiple processes running at once and switching between them, one process is suspended while the user goes to another process.
PocketPC, on the other hand, is a total interface design failure and one of the shining examples of why the linux community looks like such idiots when they claim "Microsoft must spend billions on UI research, it's smart to copy what they do". PocketPC was basically a desktop UI grafted to a PDA with no consideration whatsoever as to the difference in design demands between a sit-down desktop with unlimited resources and where the user has hours to get work done and a mobile device with scarce resources where the user has 20 seconds to get down a phone number. Microsoft thought the mini-windows UI would work better than something like the Palm because for users coming from a Windows Desktop PC "it would be familiar". Bad UI decisions being made because some techie thought "it would be familiar". Where have I seen this before *cough*Xandros*cough*Lindows*cough*KDE*cough*
Perhaps what mpt was suggesting was that with today's fast, unreasonably large hard drives and copious amounts of RAM and CPU cycles, we now have enough resources to emulate the document-oriented, stateless, all-in-ram feel of something like a Palm. Mpt's not a hard-core techie, so he might not have considered all the process manipulation voodoo required to give the feeling of statelessness. But with some modifications to the kernel and perhaps the linker it might just now be possible with the technology we have.
Ergonomica Auctorita Illico!
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 agree with many of the points mentioned in this article, but I think that the author didn't bother to closely examine some of the newest innovations that try to get around some of these problems.
The main example I would use is saving and opening files in MacOS X. The author mentions the file dialog sheets as, "this interface has always been awkward to use, because it's not consistent with the file manager". He goes on to say that opening and saving files should be done through the file manager, but that cruft interferes.
This is not true at all. Pretty much every document can be opened and saved through drag-and-drop from the file manager (the Finder). Not only that, but in MacOS X the standard file dialogs are nearly duplicates of a Finder window type called a "column view". You navigate in these file dialogs just as you would in a Finder "column view". You can even create new folders in the file system in these dialogs in order to better organize your documents.
Sapere aude!
I'm sure we'd all be using super-duper Amigas.
For the longest time I've been using the Ximian desktop, but on my K6-2/400 Nautilus is pokey. Okay, Nautilus is pokey everywhere, on anything. I've been thinking about giving the ROX desktop a try.
Since the article mentioned that most of the cruft was to overcome limitations of now-twenty-year-old hardware, perhaps the BEST solution is a clean-slate system. Add "compatibility" back in via some sandbox functionality, but dispense with the junk from the get-go.
I think there's always going to be cruft; todays consession to necessity is ALWAYS going to end up as tomorrow's cruft.
But wait, there's more! Alien invasion by net takeover! Qeng Ho! Spiders! Trancendent artifacts! You must read this book, it was better than Cats...
One line blog. I hear that they're called Twitters now.
Besides, I have recently begin doubting the existance of libraries. We have plenty of space these days, why not make everything statistically linked?
/usr/lib). Assuming it would successfully link to those libraries, it would have the advantage of traditional shared-library systems (save resources and use upgraded stuff). But if the app couldn't link to a centralized dynamic library, it would use the version of that dynamic library that resides in its folder. Yes, this entire system might end up costing several GB for on a 80GB disk. So what?
Because this idea is extremely distasteful to many geeks who value 4MB of RAM and 100MB of space on an 80G disk more than they value a good, quick, painless install that fits in with the interface paradigm and is damn near impervious to dependency shennanigans and upgrade landmines.
I myself would favor a system where an application comes with all the dynamic libraries it needs to run (excepting a few monsters like libc and X) which are stored in its application folder. At first the application would try to link to the comptuers centralized repository of dynamic libraries (e.g.
Volow's First Law of Computing: The cost of something not working far exceeds any other cost
Ergonomica Auctorita Illico!
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.
The same thing happens if you use a vertical taskbar on the right side of your screen. The start button aligns to the left. I use the vertical taskbar becuase I can see more of the application names, but always have to consciously look for the start button.
Please consider making an automatic monthly recurring donation to the EFF
KDE Control Center->Look and Feel->Desktop-> Clicks on the desktop. By default, left-clicks on the desktop are bound to "no action", right-clicks are bound to "desktop menu", middle-clicks are bound to "window list menu". Sounds like you want to bind left-click to "application menu", so go do that.
The reason it's not done that way by default is because that behavior would confuse Windows users. Also remember that a lot of people maximize every application they work with, 'cause of poor eyesight or tiny monitors or deep-seated fear of "messy desks".
On a more abstract level, clicking on the root window to bring up a menu of applications only works when there's some root window visible, you will have a hard time enforcing that without writing your own WM, and you'll end up with a similar problem: There's a guaranteed bit of root window always visible at the bottom of the screen, but it's just a blank space without the mnemonic features ("start" or "K" button) people have gotten used to.
Give a monkey a brain and he'll swear he's the center of the universe.
This guy has it backwards.
"I assumed blithely that there were no elves out there in the darkness"
Unless the author has come to rely on that bug/feature... then they begin distributing the old library with their app taking extra space in the app directory, or sometimes enjoy writing over the newer one if they put it in the system directory.
Is it just me or did the Amiga do libraries much more efficiently?
Please consider making an automatic monthly recurring donation to the EFF
I hate when it not only steals the focus, but the whole damned window! A number of times I've been typing a brillant Slashdot post, get an email with a link, click on the link, and rather than popping up a new IE window, it steals my Slashdot one, scrubbing the post. This doesn't happen all the time, which is worse than it always happening.
One line blog. I hear that they're called Twitters now.
So where on the web that Google knows, or in Google groups, did anyone link the special folders to that enumeration. The only references I found were the MSDN pages for SHGetSpecialFolder (which didn't mention the link), and some Estonian's VB code for using a call to the unmanaged SHGetSpecialFolder (which broke spectacularly in C#).
Thank you, thank you!
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
No [...] What you want is for application Foo to stop using resources on your system (or to use very little). Why not have this done automagically when you close the last document of the appropriate type? Then when you reopen that document, the app should automatically start up. Why have Word open at all if you have no open documents?
Fine, but you still need a "Close All" button to close all the open documents. If doing this also causes the app to shut down, it's functionally a "Quit" button, and your app users will think of it as one.
>K
>;k
While I like it for some things, CTRL-C brings up a freakin' color wheel. Come on! Call me a MS lover all you want (I'm not) but CTRL-C is a defacto standard to copy stuff to a clipboard. GAIM overrides this with the most annoying thing that could happen when you press CTRL-C - an unrelated pop-up window. :(
creation science book
Some of those issues are why I moved to Opera. Opera doesn't have a perfect interface, but it doesn't have Mozilla's "Horse designed by committee" interface, either.
Boobies never hurt anyone. - Sherry Glaser.
Most people wouldn't hit save, ctrl+z, bg, fg a different job, do some work, ctrl+z, bg, fg the original job, etc. Maybe K & R did, but most people just waited until W, X, and NEWS were available before they learned to work that way.
Swapping applications on the command line is annoying and hard, that is why most people who use the CLI a lot use X with many xterms, or they install screen and use fewer (but more than 1) xterms.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
So, are there any radical GUI and/or OS projects on SourceForge worth looking at that address the author's objections?
.02 worth...
Personally I'd be interested in a GUI where the system comes up just showing a column with rotating levels - each level representing something about the system (drives, folders, applications), and with "balls" on each level to click that open things into an application specific GUI.
For example, Photoshop does not use the standard Mac or Windows GUI. It has a number of application specific widgets. Why shouldn't other programs do the same?
My
When you have data files and execution files, all with the extension hidden, many sharing colourful icons (as data files have the same icon as a program), how the hell do you know what you are dragging?
I sure as hell don't, unless I go around turning off all the (say this is a Will Farrel voice) "happy, happy" Windows UI "features."
It's bad design like this that teaches users to always right drag, because then they get a menu of options and can choose the one they want (rather than what Windows thinks they want). Why you can't just left drag and have the menu come up after, I don't know!
Ever notice how you usually click apply before ok in a property sheet dialog? Same crap. Lumping layer upon layer on a UI, never thinking to strip away the useless parts, leads to learned behaviours which are totally non-sensical (like people who type www. in front of everything, because ignorant DNS admins don't include A records for the base domain name).
Making quit harder makes sense. I've accidently quit Mozilla a few times (it stays open until I upgrade my daily, usually once a month if there are no bugs I'm tracking). That loses so much work or items that may be open, it's not funny. Since there is no part of the history dialog that shows what was open when you last quit, I tend to lose information. In an SDI program that has many windows, quit can close other windows that you weren't meaning to close!
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
I do agree with you though. I had many years getting pissed at that one, until someone else pointed that out to me.
dominionrd.blogspot.com - Restaurants on
That's what ~/.tmp is for. Have it culled of files older than a week automatically. If you need something, you can get it out. Otherwise it will be removed eventually. You won't even have to name it, as the rest of its meta-data attributes will index it in your new OS.
Why is this bad? I think it makes a lot of sense, especially if you want to shift from CLI in GUI to true GUI use.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
"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."
/. moderators have this crack habit.
I guess you don't use source control, VMS, or ReiserFS.
"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."
You've also never owned a Palm Pilot.
"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 [sic] have one file manager, which is running all the time, instead of a "file picker"."
And you've never used the OS/2 WPS or its file template creation folder, or undershood how this fellow was writing obout how to extend that idea further with branching (see version control above).
"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)."
And you've never used hardlinks!
So why, exactly, are you such a highly moderated oracle of knowledge if you've not used the current incantation of the things you rant about? Oh, right, because
Before you react and freak out about something, take a step back and think. Your work habtis will be changed, because the way you work will be changed. Of course if you try and think of your current work habits over top of a new way of working, you'll see problems that aren't there.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Start -> Shutdown :)
HTH. HAND!
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
I wish desktop editing was so easy. Any changes are masked behind undo features, as they should be. The chances you'll undo to a certain level decrease as each day passes, so a timed expire of older undo versions is just another neat feature of this OS he proposes.
Need a really old version? That's what backups and centralized version control are for. ReiserFS wants to address some of this.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
(1) Others have mentioned the problems with version management. As for the sensible name, what is the sensible name for a drawing (et bloody cetera)?
(2) Many apps still take some seconds (which is quite long when you have adopted to the speed of modern computers) to open. Having to wait that amount of time everytime I want to work on an other document - thanks for removing the cruft, klutz. As for the big fucking sign telling you wich app is open...
(3) Oh, wow, he doesn't see the problems of the "obvious way to save a document in a particular folder is to drag it to that folder in the file manager" - like not seeing that folder, for example. He is keeping his pace well.
(4) Shockhorror, he's right.
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
One of the biggest bits of interface cruft that I've had to deal with is the C:\ drive-naming scheme. I'm sure it made some form of sense when QDOS was being put together. But we've clearly moved beyond that now.
I use ArcView (a crufty bit of GIS software in its own right) on a daily basis, and share ArcView files with the other folks in my lab. ArcView allows a user to save his map-work to a single file that references multiple databases. Unfortunately, it references all the database files with the letter-based paths. Of course, if I pass that file to somebody else on a different machine, they have to have the exact same drive letters to be able to open the files. This means that I can't save anything on my own hard-drive, since it will always be C: or D:, and they will have to map it somewhere in the G: to Z: range.
Further, this imposes a limit of 26 total mapped drives. Now, for some things, it is possible to use the \\host\sharename method to address files, but many software packages do not allow use of the 'network neighborhood' when browsing for files, so this doesn't work too well under many circumstances.
C:\ = Cruft!
if ($it != $onething) {$it = $another;}
I disagree with this. First, it won't work. What actually is being delayed is not the "raise" of the window, but the creation of the window. I suppose you could have an "active app" and only raise that, but even then there is a problem in that the creation of the app could be delayed. Unless you say that all new windows appear below the focus window always there is no way to solve it.
Also, I actually am a big proponent of ONLY allowing programs to raise themselves, and focus should only change by a program doing a "set the focus to this window" call. This would get rid of the "click raises" behavior that makes overlapping windows useless (a program could instead raise only if the user clicks on an area that does nothing else). It would also get rid of the need for child windows, hieraarchies, window type flags, and all the other complexities that have come up because programs have the need to instruct the window manager what windows they want to not be buried and where the input focus could go. So therefore I certainly don't want the apps to be unable to raise themselves.
"However, for the most part, this effort has been piecemeal and on the fringe. So far, there has not been a mainstream computing platform which has seriously attacked the cruft that graphical interfaces have been dragging around since the early 1980s."
I disagree. To me, this is one of the strengths of PalmOS: Palm was willing to rethink some of the established ideas of what a handheld should be and how a computer should work, and the result was a very practical and efficient system. I wouldn't say Palm got everything right, but they definitely cut the cruft.
Bow-ties are cool.
Newer versions of Microsoft Word have a sort of "version control": the Undo stack gets saved with the rest of the document, and you can save a document, open it days later, and undo things.
Until users really understand this, however, there are potential privacy problems. "I don't want anyone to know my salary, so I'll just delete the part where it mentions that." And the salary info is still there, just an undo away.
If you use Word and you have any concern about private data, do a Save As in RTF format, and distribute the RTF.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
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...
I've often had to resort to registry shredding to get things moved around. Just open up regedit and do a global search for subdirectory of the app you're trying to move. Similarly, you can search/substitute X: values with Y: values if you're shifting partitions around.
Obviously this isn't something most users know how to do (or should do!), but it can be done.
My bigger beef with the registry is that apps scatter pieces of their initialization all over the place. It makes it impossible to backup and restore individual apps by saving their registry tree, because you usually find that there are critical pieces of information whose names bear no resemblance to the application.
I do not fail; I succeed at finding out what does not work.
Timeo idiotikOS et dona ferentes
Personally I find the mix of mouse and keys works well. I don't find the moving from mouse to keyboard and back again a problem most of the time - I'm a programmer, not a typist. I spend a lot of the time with my fingers off the keyboard anyway. I'm absolutely sure that debugging would be considerably slower without the GUI.
I would spend the time to learn Emacs if I felt that it was considerably superior than the current alternatives, but I don't see why it would be, and otherwise I'm not going to learn a whole new user interface just to use an editor.
I've not had this problem except with Windows -- mainly because the apps that suffer most from the "I did something that required CPU cycles, therefore I will tell you about it in a popup" disease seem to be Windows apps. So I'll tell you the Windows solution:
Go to microsoft.com. Find wherever they've hidden TweakUI this month. Download it. (If necessary, download the whole "power tools" thingy that it's a part of.) Install it. (Install the "open cmd.exe at this directory" power tool too, while you're at it.)
Go to the [Out-Of-]Control Panel, fire up TweakUI, and disallow applications to grab focus. There's even a "what should they do instead" selection that lets you make them blink.
Disadvantage: some programs fire off a splash screen, then bring it down and replace it with the real program. Window focus doesn't traverse like that now, so the real program won't start off with focus, even though you the last thing you did was to double-click its startup icon. Minor annoyance only.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
The reason you can't find it is that it's called "SHGetSpecialFolderPath", not "SHGetSpecialFolder." Google tends to always be a better solution than MSDN's built-in search... it's just not a mind reader. :)
The apps would only load their own copy iff they have trouble linking to the centralized library.
Ergonomica Auctorita Illico!
Right or wrong, you should always stick to standards. If you implement an entirely new GUI for your wizbang app, you can be sure people will hate it because it won't be intuitive - even if your GUI is a better system.
Microsoft may have made a lot of mistakes in designing their GUI, but it is now the standard. KDE offers a GUI configuration that closely emulates Windows because it reduces the fear factor for the newbie. Improvements need to be made in KDE to make it act even more like Windows. Not because Windows has a good GUI, but because people are comfortable with it.
Let's win people over by offering them a familiar desktop, better performance and no blue screens. GUI changes should be left to the elite.
-- Will program for bandwidth
Those points are mostly *already fixed* in GNOME 2.0! Look at it: it's a highly consistent interface, with very little configuration options that can confuse the user.
Those arguments of him are a bit outdated.
People!
You're all acting as if the ideal interface is designed for a single, highly idealized user (probably that guy with the 2.5 kids, damn shame about that.)
All those "contradictory" and "confusing" interface elements coexist so that the user may use any combination of them to get their work done. Who here is using their computer in it's exact default state? How many here exclusively use or don't use the Open/Save file picker? I know many slashdotters run pretty much exclusively from the command prompt, but I suspect most of you occassionally drag something via the GUI. Nice to have that option, huh? All about choice, best tool for the job, etc.
Go ahead, design next year's kewl new GUI based solely on the needs of a newbie, conveniently overlooking the fact that it will effectively lock out us old-timers who like to micro-manage (is that a pun in this context?) which apps we have running, where and when we're saving our files, etc.
Face it, no GUI is perfect. They're all crude, 2D digital representations of a 3D analog environment, trying to present concrete objects and abstract ideas in the same context. No matter what you do, there will still be some learning and adaptation of your mental paradigms, and that will vary for each user. At some point you gotta just accept that and move on.
Quantum materiae materietur marmota monax si marmota monax materiam possit materiari?