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.
Re:somewhat OT
by
Tim+Browse
·
· Score: 5, Insightful
This one's easy actually - a friend of mine independently came to the same conclusion as me on this one, which is that Microsoft deliberately chose "Program Files" as both a 'long filename' and a filename with a space in it precisely to speed the adoption of long filenames. They did it to bring into sharp relief any program that didn't support LFN properly. Remember, Windows 95 was the time when they introduced their "Designed for Windows" logo, which at the time was a pretty big deal, and as far as I can remember, pretty much mandated support for LFN.
The PROGRA~1 is ugly, but it only happens on old programs - I certainly now use it as an indicator of quality in a Windows app (it reflects how much the author respects the user experience).
Now, if you want a real gripe, I hate the way most apps just plain don't work if you install them somewhere other than Program Files. I also hate the way most apps have a slavish belief in whatever path information they stored in the registry, meaning you can't ever move an installed app. I try to make my own apps as location agnostic as possible (Mac users: feel free to gloat at this point, with considerable justification).
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.
Re:Why do we have to save our work by hand?
by
panaceaa
·
· Score: 5, Insightful
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?
I really like the article's idea. I've lost a lot of work in my lifetime due to software crashes, power outages, or clicking things without thinking. On the other hand, it's not often that I change things temporarily and then revert back to the saved version. (Probably 20 to 1 ratio) With this paradigm, it'd be easy to get in the habit of marking a document as 'temporary' with all the benefits.
It might make even more sense when content management platforms mature. These platforms keep track of different versions of a document, allowing you to revert back or see document evolution with ease. Then you can have it both ways, your latest changes will always be saved, and you can revert to previous versions. But of course, then you'd have the non-intuitive 'Save This as New Version' button, since you wouldn't be saving your documents manually anymore.
Re:Crufts - Not only software!
by
Anonymous Coward
·
· Score: 5, Insightful
Good user interface is hard and even though the author claims that "we have the technology now", some of the ideas just reflect his personal preference and are not really the obviously better design. Many times the interface which users would find "working as expected" requires nothing short of magic (or artificial intelligence, whichever arrives first). "Industrial design" has one major advantage over user oriented design: It's learnable. Learning a system which itself adapts its behaviour to the user can be really frustrating and time consuming because it follows more complicated hidden rules. That's why "power users" turn off as many automagic functions as possible.
The real user interface crimes are when well researched principles of perception are ignored: Making every icon round by dropping the actual icon into a marble of colored glass may be pleasing to the eye, but it's working against the way we recognize patterns. Adding bevelled lines around and between everything, even when there is no logical or functional separation, makes user interfaces distracting. And those are just the worst offenders in the graphical representation area.
More cruft!
by
krazyninja
·
· Score: 5, Insightful
The most annoying one I have found is when you are typing away madly at the keyboard, and this window pops up saying "xxx yyy operation failed", or "zzz download complete". It does two agonising things: 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."
Re:Why do we have to save our work by hand?
by
Katravax
·
· Score: 5, Insightful
There are already programs that support undo past save. If we do something intelligent like get rid of the save command, we should also do something intelligent like undo past save. For the file-size whiners (like myself), we could have the option to lose prior undo information to reduce the file size.
File systems that support multiple streams (like NTFS) could save undo information in a separate stream. "Not everyone has such a file system," you might say. I say, whatever -- if we're talking about moving forward here, we'll have to go past FAT and other beginner's file systems.
We're not talking about taking away something that's required for usability today. We're talking about improvements for the next generation. Get over your "Save" command. You'll be able to undo beyond the automatic save.
Did I read that right?
by
flippet
·
· Score: 5, Insightful
We have the technology. So why do we still punish people by including "Quit" or "Exit" menu items in programs? Cruft.
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."
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!
The cure is worse than the disease.
by
tlambert
·
· Score: 5, Insightful
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).
Well, you wrote my comment for me, but I'll add that the author tries to deflect this sentiment at the end by implying that anyone who disagrees with his preferences has obviously just bought into the dominant paradigm. ("But I *like* QWERTY...").
I suppose the proper reponse to him is, "If you're under 25 years old you obviously haven't had enough time to really think about this problem."
And some specific criticisms:
- Lots of modern software does, in fact, automatically save your documents. But by doing at least one manual save you get to pick a name and a location so you can find it again without needing Autonomy built into your computer. And while I like that the computer saves its own copy for safety, I specifically do NOT want it overriding the master copy without permission.
- On Mac OS X the file picker does in fact look exactly like the file manager, with a few extra buttons around it.
- I read his criticism of the "Quit" function several times and still don't understand his gripe. Yes, our computers can multi-thread so we can run multiple applications, but they have limited memory so we can't run EVERYTHING at once. And I for one would rather control which ones are running rather than wondering what my computer chose to quit. Also, Windows doesn't behave as he describes...close the last window and the application quits. Finally, there aren't any "mystery" menu commands unless you don't actually look at the menu bar when you use hot keys. I will admit that the "invisible application" phenomenon can be confusing to new Mac users, but I disagree with MPT's prescribed solutions. The current state is less "cruft" than it is the lack of a perfect alternative.
Overall grade for mpt's "cruft" essay: C+.
-- Actually, I was trying to be Insightful, not Funny.
Re:Why do we have to save our work by hand?
by
kcbrown
·
· Score: 5, Insightful
Version control is something any user-friendly system should handle automatically. It seems to me that programs should automatically save the diffs against the previous version and should save the full version on a very regular basis (with saves happening after a relatively short timeout or after a certain amount of changes have been made, whichever comes first). Reverting to an old version is a matter of applying the diffs in reverse to the current version. You should always be able to drop back to any previous version you want.
There's no need for a "save as new version" button: the program will do that automatically when you exit, when you switch to a different program, or when the timeout/max diff condition occurs.
What is needed in addition is something that should be intuitively obvious: "create a new document based on this one". This will create a "fork", and doing so will cause the program to ask you by what name you'd like to refer to the new document (as it should whenever you create a new document). Perhaps this is what you were talking about.
We've gotten so used to working with low-level files that methodologies like this get discarded automatically by developers. But that should be done only if there's a lot of hard data that shows that users actually have a harder time dealing with it that way. That may be true of users who are used to dealing with files, but I strongly suspect people who are new to computers will have an easier time with an application that doesn't know about "files" but only about "documents". The system should keep track of the mapping between the two, and the filestore should never be seen directly except with a tool designed to manage it.
All IMHO, of course.
-- Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
Re:He has a point but he dosn't get it!!!!
by
BlueGecko
·
· Score: 5, Insightful
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
No it isn't; it's a kluge to hide the fact that applications have gotten more complex and Microsoft wasn't prepared to deal with it. On the Macintosh, until about 1995, applications, generally speaking, did not need support files. You had the application, you had a preference file, and possibly you had an extension or two, but the application usually sat by itself. However, at about that time, both in response to Windows and in response to the fact that applications simply were getting far more complex, most applications began having massive numbers of support folders. Macs just ignored the implications and kept on treckin'; Windows adopted the solution you mention.
But Mac OS X, and OPENSTEP/NEXTSTEP before it, manage to keep the Mac metaphor while still hiding the implementation details, and it does it much better. Each application is actually a fairly complex directory structure, and all support files can be hidden within the application itself. This can include movies, help files, whatever--you name it, it's there. Now, to the user, you still have just the application, but the application can suddenly be dragged around at will without disturbing anything. For the application, you now can also guarantee a very rigid directory structure that the user can't even mess with. Next time you're on an OS X system, control-click a program and choose "Show Package Contents," or, if you prefer, cd right into the app. You'll see what I mean.
That's the right way to solve the problem, and that's why he's slamming Windows' metaphor and lauding ROX/OS X app wrappers/packages/bundles.
Re:My cruft-o-meter:
by
RustyTaco
·
· Score: 5, Insightful
Find somebody who knows how to use AutoCAD and be educated on how GUI & command-line are not mutually exclusive concepts. AutoCAD has the GUI for all gui bits, but still has a command line for when it's easier and saner (think typing in desired dimensions instead of trying to fake it with a mouse) to type things in. As most people can type faster than they can take their eyes off what their working on, move the mouse to the top of the screen and guess at which icon is which it also seems to be great for switching tools & modes quickly.
More programs really should allow that sort of functionallity. Now I have to see if anybody is working on it for The Gimp.:)
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.
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.
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?
I really like the article's idea. I've lost a lot of work in my lifetime due to software crashes, power outages, or clicking things without thinking. On the other hand, it's not often that I change things temporarily and then revert back to the saved version. (Probably 20 to 1 ratio) With this paradigm, it'd be easy to get in the habit of marking a document as 'temporary' with all the benefits.
It might make even more sense when content management platforms mature. These platforms keep track of different versions of a document, allowing you to revert back or see document evolution with ease. Then you can have it both ways, your latest changes will always be saved, and you can revert to previous versions. But of course, then you'd have the non-intuitive 'Save This as New Version' button, since you wouldn't be saving your documents manually anymore.
my blog
Good user interface is hard and even though the author claims that "we have the technology now", some of the ideas just reflect his personal preference and are not really the obviously better design. Many times the interface which users would find "working as expected" requires nothing short of magic (or artificial intelligence, whichever arrives first). "Industrial design" has one major advantage over user oriented design: It's learnable. Learning a system which itself adapts its behaviour to the user can be really frustrating and time consuming because it follows more complicated hidden rules. That's why "power users" turn off as many automagic functions as possible.
The real user interface crimes are when well researched principles of perception are ignored: Making every icon round by dropping the actual icon into a marble of colored glass may be pleasing to the eye, but it's working against the way we recognize patterns. Adding bevelled lines around and between everything, even when there is no logical or functional separation, makes user interfaces distracting. And those are just the worst offenders in the graphical representation area.
1. The alphabet you are typing corresponds to a shortcut in the window, and the window happily closes itself, having done god-knows-what-damage-it-did.
2. It slows down your pace, disturbs your thinking process, and by the time you close the window and move to the position you were in before, one more word gets added to your swearing vocabulary.
"Do something man. Right now."
There are already programs that support undo past save. If we do something intelligent like get rid of the save command, we should also do something intelligent like undo past save. For the file-size whiners (like myself), we could have the option to lose prior undo information to reduce the file size.
File systems that support multiple streams (like NTFS) could save undo information in a separate stream. "Not everyone has such a file system," you might say. I say, whatever -- if we're talking about moving forward here, we'll have to go past FAT and other beginner's file systems.
We're not talking about taking away something that's required for usability today. We're talking about improvements for the next generation. Get over your "Save" command. You'll be able to undo beyond the automatic save.
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."
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!
Personally, I don't like cruft, but the way he wants to "correct" some of the things he doesn't like, well... the cure is worse than the disease.
My idea of hell is an editor that auto-saves code that I'm in the process of hacking up in an editor to let me think about the problem over top of code that already works.
My idea of hell is a platform where every document I've ever opened has no way to close it and no way to exit the application that's got it up in a window, because there;s no 'Quit' or 'Exit' option.
My idea of hell is not being able to drag something in a GUI from one folder to another, because they have an obscure "parent of my parent" relationship, which makes me have to cut and paste the document, instead of just dragging it, because I on;'y have one file manager, which is running all the time, instead of a "file picker".
My idea of hell is symbolic links that get changed when I rename a file out from under them because the OS thinks it knows what I want better than I do, so it's impossible to replace a file with another, while keeping, and the old one, unless you copy it, rename the original, rename the copy, and then edit the original (instead of replacing it).
-- Terry
Well, you wrote my comment for me, but I'll add that the author tries to deflect this sentiment at the end by implying that anyone who disagrees with his preferences has obviously just bought into the dominant paradigm. ("But I *like* QWERTY..."). I suppose the proper reponse to him is, "If you're under 25 years old you obviously haven't had enough time to really think about this problem." And some specific criticisms: - Lots of modern software does, in fact, automatically save your documents. But by doing at least one manual save you get to pick a name and a location so you can find it again without needing Autonomy built into your computer. And while I like that the computer saves its own copy for safety, I specifically do NOT want it overriding the master copy without permission. - On Mac OS X the file picker does in fact look exactly like the file manager, with a few extra buttons around it. - I read his criticism of the "Quit" function several times and still don't understand his gripe. Yes, our computers can multi-thread so we can run multiple applications, but they have limited memory so we can't run EVERYTHING at once. And I for one would rather control which ones are running rather than wondering what my computer chose to quit. Also, Windows doesn't behave as he describes...close the last window and the application quits. Finally, there aren't any "mystery" menu commands unless you don't actually look at the menu bar when you use hot keys. I will admit that the "invisible application" phenomenon can be confusing to new Mac users, but I disagree with MPT's prescribed solutions. The current state is less "cruft" than it is the lack of a perfect alternative. Overall grade for mpt's "cruft" essay: C+.
Actually, I was trying to be Insightful, not Funny.
There's no need for a "save as new version" button: the program will do that automatically when you exit, when you switch to a different program, or when the timeout/max diff condition occurs.
What is needed in addition is something that should be intuitively obvious: "create a new document based on this one". This will create a "fork", and doing so will cause the program to ask you by what name you'd like to refer to the new document (as it should whenever you create a new document). Perhaps this is what you were talking about.
We've gotten so used to working with low-level files that methodologies like this get discarded automatically by developers. But that should be done only if there's a lot of hard data that shows that users actually have a harder time dealing with it that way. That may be true of users who are used to dealing with files, but I strongly suspect people who are new to computers will have an easier time with an application that doesn't know about "files" but only about "documents". The system should keep track of the mapping between the two, and the filestore should never be seen directly except with a tool designed to manage it.
All IMHO, of course.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
But Mac OS X, and OPENSTEP/NEXTSTEP before it, manage to keep the Mac metaphor while still hiding the implementation details, and it does it much better. Each application is actually a fairly complex directory structure, and all support files can be hidden within the application itself. This can include movies, help files, whatever--you name it, it's there. Now, to the user, you still have just the application, but the application can suddenly be dragged around at will without disturbing anything. For the application, you now can also guarantee a very rigid directory structure that the user can't even mess with. Next time you're on an OS X system, control-click a program and choose "Show Package Contents," or, if you prefer, cd right into the app. You'll see what I mean.
That's the right way to solve the problem, and that's why he's slamming Windows' metaphor and lauding ROX/OS X app wrappers/packages/bundles.
Find somebody who knows how to use AutoCAD and be educated on how GUI & command-line are not mutually exclusive concepts. AutoCAD has the GUI for all gui bits, but still has a command line for when it's easier and saner (think typing in desired dimensions instead of trying to fake it with a mouse) to type things in. As most people can type faster than they can take their eyes off what their working on, move the mouse to the top of the screen and guess at which icon is which it also seems to be great for switching tools & modes quickly. :)
More programs really should allow that sort of functionallity. Now I have to see if anybody is working on it for The Gimp.
- RustyTaco