Slashdot Mirror
When Good Interfaces Go Crufty
An anonymous reader writes "A good article over at mpt on why good interfaces go crufty." A nice read before or after a visit to the Interface Hall of Shame.
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
But you can always go for google:
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
Ive never really found anything that matches 12vc's at vga res for doing stuff.. great thing about command line apps is there practicly always designed well because theres no bs gui to worry about and distract the attention of what actualy needs to be done.
moo
See http://info.astrian.net/jargon/terms/c/crufty.html
Hey! That's my sig you're smoking there!
are examples of crufters ;)
notepad, pico, vi, emacs.. examples of cruftbusters.
moo
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.
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./i> No, the hackers aren't lazy - they're just too busy trying to ape the MS windowes look and feel....
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."
You probably don't have a background either eh? :-)
nosig today
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!
Anyone from the UK may have noted that Crufts is the name of the annual dog show of the Kennel Club in the uk.
4.a. Use hard links instead of symlinks. A hard link is just that, a link to an inode. The problem is that the file remains under the link name if it is removed, but it should not. The solution would be to label a file as "soft", and when it is deleted under another name, the soft file would become an invalid hard link, or maybe a symlink to the deleted file name.
-- 1.e4 c6 2.d4 d5 3.Sc3 de4: 4.Se4: Sd7 5.Sg5 Sgf6 6.Ld3 e6 7.S1f3 h6 8.Se6:
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.
You idiot.
Macs only run one application at a time? Have you ever used a Mac?
Windows 95 the best GUI ever? You haven't used many GUIs have you.
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.
I studied computer science and cognitive science, and am currently a GUI programmer. I have to say I agree with the article on some points. For example, if save is actually an undo marker, why not implement undo markers properly?
However I think that with his drag and drop saving/renaming he misses an important user interface concept: guiding the user.
When I, as a new user of some program, am looking for a way to achieve task x, then the first thing I do is browse the menus. If I find a menu point that looks like what I want, I choose it. If the program then needs more information, it throws up a modal dialog asking me for it and giving me the opportunity to cancel out of the task. So the user always has something in the hand telling him how to accomplish the next step in his task. The only thing he really has to learn for this, is to search through the menus.
Drag and drop offers none of this. You drag on something and it doesn't give you any information about where it can be dropped. It might not even be draggable. The information might not even have a graphical "handle" on which the user could drag, or he might not be able to find the handle.
For this reason drag and drop works mostly as a supplement to menu-based program manipulation. It takes the foreground when editing explicitly graphical information such as page layout, but otherwise it can in my opinion never be the primary method for operating a program.
Myrle
Just change the skin to something that doesn't have colorful, bubbly bitmaps!
Grandparent wants programs to use a simple, non-ugly skin by default.
Will I retire or break 10K?
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.
are they suggesting there weren't multi-tasking operating systems in the 1970s?
No. They are suggesting that software developers in the 1970s did not produce operating systems with all three following qualities: 1. multitasking, 2. ability to run on home computers, and 3. popularity.
Will I retire or break 10K?
Ok, yeah, I guess Windows also have that feature.
On NT, minimized Windows apps use negligible system resources except swap space and toolbar space. On Windows 9x, on the other hand, there are two memory spaces called "user.exe heap" and the "gdi.exe heap". Each is 64 KB in size, for backward compatibility with Windows 2.x and 3.x, and cannot be enlarged nor swapped. Every window, minimized or not, will use some resources.
Will I retire or break 10K?
For example, Kazaa Lite (just a program I happened to be running while reading this article) has the following items under the file menu: Connect, Disconnect, New Search, Hide in systray and Exit. None of these actions have anything to do with manipulating files. Using the file menu as a garbage bin for a bunch of random actions seems to be quite common and I'm surprised that the article didn't mention this issue.
Why can't I just copy a file from the CD/Net and be done with it?
Dependencies. If you could install apps by merely dragging them into place, what design would you propose to eliminate the cruft of having to install libraries that the app uses?
Will I retire or break 10K?
Use hard links instead of symlinks.
Hard links cannot point across partitions in most filesystems.
Will I retire or break 10K?
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.
Unless you subscribe to the one giant filesystem to rule the one disk school.
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!
Nothing confuses the user more than when they can't open that nice .doc or .wpd that they receive as an email attachment from a user using a different version of the application, or a competing version. I think clean XML, or SGML is the way to go.
IMO the absolute fscking all-time number-one of really annoying "innovation" that Linux(...) desktop application programmers so happily copy from Windows is the Start Button.
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?
In almost all Linux(...) window managers including my favorite gnome-incompatible WindowMaker, the application menu can be reached just by clicking on the desktop, which is IMO the easiest and fastest way to do this by far.
KDE and Gnome developers what were you thinking? (This is not a rethorical question, please reply). How anyone can compare those two methods and go for the Button completely elludes me.
my
These guys obviously come from the WIN-DOS world, where apps quit when you close the last window. *** NEWSFLASH *** That's completely fucked up, and unfortunately those fuckers from Redmond implement that shit in their OS X ports of WIN-DOS media player (WIMP) (however not in the Awfice suite).
The program shall quit when I say it should quit. The app should make no assumptions on my behalf, depending on how many windows are open. Jesus fucking Christ in a river crutch...
frawaradaR anahaha islaginaR!
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???
This article is right on the money, and funnily enough addresses exactly the same topics as David Gelernter (/. NYT article a few days ago) tries to address with Lifestreams and related systems.
Filesystems are the biggest bottleneck to improving the OS ui, they singlehandedly are responsible for most of the problems these people mention. An ideal OS is persistent from the bottom up, and doesn't require you to think about load/save, start/stop, and storage locations.
How would this work? The user would just deal with documents, or objects, or however you'd want to call them. If he wants to view or edit them he just does so, he is not concerned with loading (there document is there, why does it require an intermediate action to make it even more available than it is?), he is not concerned with starting applications (maybe the document requires some code to make the editing possible, but why should the user care?).
But maybe most importantly he doesn't care about storage locations. Documents just exist, and don't have a particular location. So how does one "organize"? by queries (much like what we know from databases, just with a greatly simplified UI), or rather "persistent dynamic queries": persistent because they are always instantly viewable like directories, and dynamic because they refresh themselves automatically depending or new or changed objects. Want to see all emails from a certain sender? create a query and new emails from that sender automatically end up there. This allows people to create any amount of organisation in their document soup when they need it, not when they create documents.
Some posters complained that automatic persistence would not give you any control over throwing away unwanted changes... that's why a good OS should automatically keep track of a version history or persistent undo. Some others complained that not exiting applications would clog memory... that's why a good OS should be able to track down which code components are no longer needed for current documents being accessed, and act accordingly.
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...
(of shamed sites) Ugh what a disgrace - I recall the review of Quicktime 4 or 3 from ages back - ridiculing the concept of a hand held style interface. (see quote) "The QuickTime 4.0 Player contains many examples of how the software must adopt the limitations of the physical device it is based on, but the first example the user is likely to discover is the volume control. Since a real-world hand-held electronic device typically employs a thumbwheel to control the volume, the designers concluded that it would work just as well in a software application. What the designers failed to realize is that a thumbwheel is designed to be operated by a thumb, not a mouse. Watching new users try to adjust the volume can be a painful experience. The user invariably tries to carefully place the cursor at the bottom of the exposed portion of the control, then drags it to the top of the control and releases, then carefully positions the cursor again at the bottom of the control, drags upward, and well, you get the picture. " Hence, WinDVD and Power DVD SORELY belong in this list. Hideous Hideous packages.
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.
Just because something is based on getting around a technical limitation doesn't mean it's not a good idea. Examples:
1) Save. Everyone's been burned by the Damn-I-Forgot-To-Save problem at least once, but the alternative is not always a very good option. When using large files, such as graphic documents or (shudder) video files, having your work auto-save as you go without your specifically saying so would slow you down to the point in stupidity. It needs to be the user's responsibility to save their own work, because sometimes the 'flow' you're in doesn't allow for momentary delays.
2) Save locations. I've been doing this trick of late where I save everything I do to the Documents folder (used to the be the desktop, but that was even worse). Then I would sort through everything afterwards and move them to the right folders. Bad idea. I presently have close to 150 files flying about randomly in the documents folder, and I know I will likely never sort them properly. Forcing people to choose where their files go is a matter of, again, putting the responsiblity of a messy filesystem into the hands of the user. It's like with my receipts for taxes: if I didn't have those inboxes on my desk, I'd toss them all in the drawer, and get burned in an audit. You need that choice.
3) Quit. I hate explaining quit to Switchers, but again the issue of larger, more complex programs defeats the argument of "just stop the program when it's not in use". If I had to wait for Photoshop to load back into memory every time I closed the last document, played in Illustrator, and then went back to Photoshop, I would likely die. Text editors can load in 2 seconds, but computers are still not in the state where they can load ALL programs that fast.
So why not let developers put Save and Quit in the programs that need them? Because then you have a truly awful time trying to explain to users how every program works. Photoshop? Quit that one. BBEdit? It closes on its own. Inconsistency is the ultimate interface evil.
Until all computers ARE good enough to run EVERY program flawlessly, cruft needs to be around. It may seem obnoxious to those comfortably working in the can-be-done-easily zone of computing, but to those whose fields are still in the pushing-the-envelope zone, we're not done with cruft yet.
The world's only surviving livewriter.
(Se.cx)
and my friends wonder why I love miranda, god trillian looks like a freak show.
miranda is truely art- simple basic, functional - and I'm not even doing it to be trendy! - it's great.
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...
While I don't readily agree that Windows 95 was the best gui ever, I do agree that the Mac gui was quite confusing. It made it seem like there was only one program running and the method to switch between programs was not very self explanatory. The task bar introduced in Windows 95 became a beautiful device, displaying important running programs and was always visible by default. There are quite a few other things introduced that helped to make Windows 95 a good gui. I liked the toolbars with common apps on them in the *nix world, but they were too hard to modify. They make a big deal over the start menu, however, it is much easier to use than navigating a file system.
-]Phreak Out[-
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.
Motherboard Monitor...
Technically a marvelous tool but...
Worst.... Interface..... EVER!
Pity that OpenDOC didn't catch on (or was too difficult to develop for).
IIRC, this was the basic goal of OpenDOC. Make the UI document centric, with all applications offering services that are completely interoperable. (i.e. move away from "monolithic" applications) Want to add a spreadsheet to the document - no problem, graphic - likewise. All tools accessible in all documents. Want to use a different spell checker, or different text editor - use whichever one you want!
OLE *tries* to do this - but sticks to the monolithic applications.
Most of these criticisms are not new. These same arguments are presented in the book About Face: The Essentials of User Interface Design by Alan Cooper published in 1995. What this article has done is add some additional historical context and technical details. Useful, but not particularly new.
Alan Cooper has more to say about these and other issues of user interface design. And, though you might not always agree, they are at least thought provoking.
Besides the "Thats the way we've always done it argument", there are two other reasons why things have not changed. One, usually software development is not about creating the best solution. Rather, it is typically about creating the "good enough" solution. And two, there is not yet any hard usability data which shows that investing time and money in changes at this level of detail will have an impact significant enough to justify it's cost.
I would really like to see more work done on the latter.
or use Next/OS X
I know that Mac OS X has "app bundles" and "frameworks", but how does the system resolve things if you don't have a particular "framework" or version thereof installed on your system?
Will I retire or break 10K?
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.
linked at the bottom of the article. I was just wondering if anyone uses it? If so what are peoples thoughts on it...?
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.
will cause the program to ask you by what name you'd like to refer to the new document
This is the kind of shit I don't want to waste my time with. Name the damn thing for me - don't bother me when I'm working.
Spoon not. Fork, or fork not. There is no spoon.
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.
Do you really think that the whiners who complained so bitterly while learning the horrible ways that Windows and MACOS and Unix/Linux work are going to want to relearn it? How about we try to change the command line options of TAR or the script syntax of BASH to be a little less horrible? Any takers? I thought not.
2. The OS checks the file and what libraries it needs.
3. The OS installs those libraries.
Then how would the OS find those libraries? It's typically not space-practical to include libraries with every app that uses the libraries without distributing the app on a physical medium such as a CD.
We have plenty of space these days, why not make everything statistically linked?
Take video codecs for example. Do you want to require every app that plays video to contain copies of every single video codec ever produced? Or are you willing to accept that parts things such as QuickTime should stay in dynamically loaded plug-ins?
Will I retire or break 10K?
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.)
I think a fair few people agree that a lot of today's UI systems aren't as transparent as they should be, and that we should be looking forward and changing different facets of the UI. However, I think that a lot of the "improvements" suggested by the article have downsides of their own.
:). If he's talking about simply removing the "quit" thing in the file menu, I don't really care either way, as long as there's some way of closing the window. I tend to use the little "x" anyway.
:)
The storing diffs/CVS-like method might sound OK at first, especially since we now have disk space to burn, but even that hits snags. What if I wanted to ftp a 200 page document up to a server somewhere? Would all the undo levels be transferred as well? This is largely unnecessary, since I'll never need to undo all my typing, but I'll still have to transfer it all up. What if I want to create a "final", version of this document? CVS tackles this issue with servers. The server contains all the diffs. You only download the one image, and can "undo" at will, at the cost of getting the older version from the server again. Although this can be done with documents, I believe the increased functionality and "user-friendliness" isn't worth the trouble.
That's just for documents. What about, say, videos? To make even a single change could leave a single undo level in the order of gigabytes. Can we store diffs that big? With this in mind, is it wise to work hard to destroy the concept of "saving", and decrease performance to unacceptable levels?
Speaking of a concrete example: There's a simple little program that I got with my graphics tablet called "Art Dabbler". It does what the article suggests(ie: there is no concept of "saving"). It tackles the undo problem simply: There is only one level of undo, and exiting assumes what you've already done is ok(ie: undo is not written to disk). If I want to delete multiple strokes, I have to get out an eraser and rub them out. It functions almost like a real notebook(there's even a little paper-like texture when I use the pencil tool), but with small benefits, like I can rub out ink, and I have 1 undo level(better than real life! you can't hit CTRL-Z and get rid of real lines). So what use is it? Other than cutesyness, absolutely none. You can't use it for any real purpose. I think that speaks for itself. Part of the brilliance in computing lies in the concept of saving -- of having control over what's in volatile storage and what's in non-volatile storage.
He makes an excellent point on the quitting though. I used an old mac system and that manual quitting even though there's no window thing freaked me out. That's probably the sole reason I don't like macs more(that plus I like 10 buttons or so on my mouse, not 1)! I don't know if macs still do this, but Linux certainly doesn't, so I'm quite happy on that front
I think we SHOULD think about tomorrow. However, we need to think these things though, and if it doesn't work today, then maybe it's not such a good idea after all.
To those who think Linux blindly copies MS, I'd like to say, that we ARE making headway in terms of UI design. Take a look at fluxbox and tabbing. It's a really neat concept.
PS: Sorry about the size
-- f00!
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.
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?
Any document based program should automatically save and track changes. The current system leaves me having to save multiple copies of documents if I want to go back. I should be able to rewind the document through it's creation. Given current processing power and storage capacities there is no technical reason not to have these systems.
Use a script to mirror your gnome/KDE settings, then use windowmaker/ fluxbox/ waimea/ e/ insert-favourite-wm to mirror the menu. That way if there IS free desktop space you just click on that. If not, you just mosey on up/down to the start button equivalent.
Works for me!
-- f00!
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.
But helpfiles too, this is taken from the Norton Antivirus helpfile:
Error troubleshooting
If Email Scanning displays an "Error" status:
1 Turn on Email Scanning using the procedure described above.
2 If step 1 does not fix the error, restart your computer.
3 If step 2 does not fix the error, uninstall and reinstall Norton AntiVirus.
Do I have to mention that it didnt work?
Anataka suki desu. Itsumo. Itsumademo.
AmigaOS had a very nice way of dealing with this. AmigaOS allows you to create a temporary short identifier for any directory in the filing system, using the same syntax as it uses for the filing system root (ie. a name followed with a colon).
When loading from hd0:applications/pagestream 3.41/documents/, instead of going through that path every time you can simply assign that name to (for example) 'source:' instead. Of course you can do the same for the destination, calling it 'dest:'.
Pressing the right mouse button in a filer window brings up the list of assigned names. Now the sequence of changing from one to the other becomes very short: click on 'save', right-click once, click on the assigned name that you want, click on ok. The need to drill down through endless directories is gone.
Since it is easy to create and remove assigned names on the fly, the list of assigned names is typically short enough to still be useful. I still miss this system every day...
Quit is not cruft. And the start menu kicks ass! It's one of the things that really made me happy when I moved from the Mac to Windows. It gives me fast access to open any program detached from the rest of the desktop. On the mac I had to make a folder and fill it with shortcuts, but there was no way to make it go away and appear quickly. YAY PROGRAM FILES!
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.
What's worse with GAIM defaults is sometimes the new message window will pop up and NOT TAKE FOCUS (while happily taking focus away from your current app), leaving your keystrokes going into oblivion. But it can be fixed by changing popup focus in preferences, or tabbed messaging in preferences. Still, it's a bad default.
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.
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
Cruft he calls it contemptedly, but it can be useful cruft. He also recognizes this, but doesn't really whip up The Solution.
And you can't, not without having a clear idea what you want to accomplish and WHO IS YOUR TARGET USER.
I prophesize that computer UIs will go two ways:
A) A Point'n Drool interface for the unwashed masses
B) A more efficient and accurate Point'n Drool interface for the more technical inclined
C) Command-line for Linux-can't-get-a-date-geeks and bearded sysadmins
Oh, that was THREE Paths Of the Future, but what the heck. There'll probably sneak in a fourth in the last minute too:
D) A supersonic 3D virtual freak-fantasy with as much pr0n and stimulating external gadgets your heart can resist.
And then there is the Hollywood version where you click on a button that does what you want to do, with passwords filling up your whole screen.
So all, in all. You have to know who your target user is before fixing what's already broken, but useful.
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.
They actually have a very good reason for doing this. They are making a clone of the windows software and that is exactly what the windows software does. As another poster pointed out you can change this behavior in your preferences or use an away message so that the windows don't pop up when you are busy.
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.
>|<*:=
When I got my iPaq 3850 this was the most annoying thing I found with it. If I hit something that looks similar to an 'X' button in Windows I expect the application to close. Off course it doesn't, it stays in the back-ground and not long after having a few applications open the system would crawl forcing me to go to the iTask Manager and close applications (usually all to save time) so that I could have my responsive system again.
Thankfully there was a ROM update for the iPaq which has reduced this greatly. I really can't remember if it closes applications down while they are in the background if there is too many running, or it just starves applications that are in the background of resources ... I believe that it is the latter (considering how many applications I see running when I do go to the "task manager").
Some applications do have an 'Exit' feature although that is rare. I really wish that MS would have chosen another icon that wasn't an 'X'. I really think two thirds of the traffic light anology would have been good with the PocketPC. a 'Red' circle would 'close; exit; quit; whatever!' the application, while an 'Orange' circle would hide it in the back-ground.
R
This article is written by a whiner of the Nth degree (trust me, it takes one to know one).
You have click "Save" and "Quit," you have to right click to move applications, the "filesaver" and "filepicker" don't look alike, etc. etc. BOO-Phunking-HOO. Somebody has too much time on their hands.
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!
This has been one thing that IE on Windows has shafted me many times with. The following is very common in order to happen (a download manager like the MACOS and OSX versions would help me things):
I don't even want to remember the amount of files on a dial-up connection I have lost with this (because I don't want loads of 3rd Party Applications like GetRight running in my system tray for any length of time) but my sanity has not been helped by the occurances :)
One of them starts with the phrase: "We came across this informative error message in Microsoft's Visual Basic 5.0 recently." (Who's this 'we'? The author and his imaginary friend?)
The Visual Basic help page told him:
He translates this to:
No, the number is not meaningless, and yes, you can find out what caused it, if you had the brain cells needed to understand the concept of a return value!
That's bad enough; then there's this one, starts with the phrase "Is it any wonder that many people consider programmers to be geeks?":
The error message reads:
Now, I will be the first to admit that this isn't the clearest error message in the world. For instance: "Error code 503: Polite people begin transmission with HELO" might have worked better. However, the author proves his utter lack of clue with his response.
HELO! That's exactly what it IS! It's a dialogue between the machines to set up the connection, that one of them screwed up! Also, how exactly do you say that error message without somehow touching on the concept that the two machines are sending messages back and forth?!
Not satisifed with this, the author goes on to mock and ridicule the person who wrote the code:
There's that 'we' again. Maybe it's the Royal We.
*fume*. I simply cannot comment on this.
if the answer isn't violence, neither is your silence / freedom of expression doesn't make it alright
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.
People who are complaining about the UI for a versioned document system haven't used Adobe Photoshop recently.
It saves as much undo information as you need AND allows you to back up to a certain point, then go forward on a new "branch". And if you don't like where that branch is going, you can back up again and go back to where you were originally. It's the "History" pane and it's a real innovation in document UI.
That's the way all applications should work, in my opinion.
There's a good article in the Salon archives about all the roughshod abandonment of good user interface design when Apple went to the "brushed aluminum" look of the QuickTime player (Linux-only people will just have to take it on faith).
One of the major problems was placing one person's aesthetics over actual human interaction studies. Well, there's more in the article.
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!
Naked Objects is a Java framework designed to allow developers to get back to the central ideas of true Obect Oriented design and development, which, naturally includes proper OO User Interfaces.
Even though so many developers use OO languages, they often end up with designs that harken back to the bad old days of data processing - data fed into procedure oriented programs. OOUI is in an even sadder state. Most deisgns seem to use the UI to cloak what's going on in the underlying object model (if there is one). It's especially ironic when you realize that some of the few programs that acutally use truly OOUI's are the Integrated Development Environments that those same developers use to create those horrible UI's. Can't they even see what's right in front of them?
Current design philosophy ends up giving the users horrible interfaces that just get in the way of actually getting the job done. Even worse, this process oriented view of the world treats the users as slaves to our machines that can do pattern recoginition better than the machine can. The Naked Objects approach, views the users as problem solvers and provides several different ways to accomplish a task. You've seen it before in spread sheets, drawing programs and IDE's. Naked Objects brings this level of expressiveness to every program and frees the user to be creative rather than just some cog in a machine.
So throw off your GUI and expose your business objects for the world to manipulate! Rejoice in the Naked Objects philosophy and free yourself of all that cruft weighing you down. So run free and let your objects swing in the breeze and... er, um... you get the idea :)
Signatures are a waste of bandwi (buffering...)
in win2k and above, applications are generally prevented from stealing focus from another application. thus the flashing entry in the taskbar.
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!
-
The problem of oversimplification in Microsoft software is pervasive. Getting people to access "the Internet" through the one icon all the time might make things easier to start off with but doesn't give your average user much of an idea of what they're doing. It also means that if you're on a helpdesk you have to deal with bizzare assertions such as: "the internet's not working", or confounded silence when you ask someone what web browser they're using.
-
The point about the inconsistency between file manager and "open" dialogue interfaces is very apt. In my last job I did a lot of desktop support and found that a lot of people just didn't use or understand the need for something like Windows Explorer, no matter how much gentle chiding I subjected them to. So I'd keep having to explain to them why they shouldn't use the the open command in Word if they just wanted to open any old document... of course this presumes that the person you're talking to understands what a Word document is. Microsoft doesn't help here--if you're accessing files on a network then you almost have to be using shared drives. The problem is that "My Computer" isn't very good at navigating these and they now hide "Windows Explorer" deep within the Start menu, as if they're somehow ashamed of its existence.
-
In GUI applications that use sticky menus, (i.e. anything not made for a pre-MacOS8 Macintosh) if you want to close an open menu, you have to click outside it. In some apps if you click in the wrong place, the program does something that you didn't want it to do. One (completely arbitrary) example of this is Konqueror. If you click outside of a menu in order to close it and the mouse pointer happens to be hovering over a link, or a folder, you end up opening whatever it is you clicked on. So you get around this by having to hunt around the window for a "safe" region to click on. Mozilla, on the other hand, doesn't have this problem.
-
Of course, there's the classic example of UI cruftiness--in order to shut down Windows, you have to go through the Start menu.
I guess it's all a result of things becoming more complicated, as well as software companies wanting to maintain their marketshare without alienating their users. I tend to think that, as far as elegance and simplicity goes, nothing has beaten the Macintosh, circa System 6.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.
Microsoft's Internet Explorer for Windows, while having many interface flaws, sensibly abolished the "Exit" menu item.
Well duh. It never unloads itself from RAM. Even if there was an option all it could do is close the window.
MS explaining benefits of a standardly adopted OS:
Your honor we hold serious the responsibility bestowed upon us due to our monopoly on desktop OS's to prevent dramatic erosion in our nation's GDP by preserving the cruft in our products.
Tablet considerations:
MS pushing its tablet out (and others knee jerk contemplation of jumping on that bandwagon) brings up an interesting consideration.
Is their custom XP OS suited for tablet usage?
Who actually understands at this point the eventual real world tasks that this tablet device will provide a widespread solution for.
These yet unknown tasks (if any) will surely require GUI behavior that is more specific to the task at hand than that which MS (or any other vendor at this point) can presently envision.
It will be interesting to see which of their Tablet specific XP features evolve into cruft as their target market inevitably and substantially shifts from what they presently are guessing.
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.
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.
Well, I have to say I disagree with the author here (by his own description, a 24 year old college student working in a cyber cafe).
1. Why do we make people save their documents manually? Because they don't always want to save their changes. Duh!
2. Why do we "punish" users by making them explicitly quit or exit a program? Um, otherwise all programs they've ever run would always be running, and eventually system resources would be compromised.
3. Why do we still make people use file pickers? Well, it's an alternative to drag and drop. In most apps, you can drag and drop, or use the app's file picker. It's your choice. Drag and drop, while "cool," has disadvantages. Number one is screen real estate. Few people have 1600x1280 (or higher res) screens where thay can actually see the file manager and their other apps at the same time. This means to use drag and drop, you have to flip back and forth, move windows, etc. In the end, it is easier to use a file picker sometimes.
4. Why do subdirectory structures exist? Well, sonny, let's see you organize the 1,000's of files on your hard disk without a subdirectory structure. The idea of using subdirectories is exactly like that in the physical world (filing cabinets, with dividers and folder). It is a system that works quite well for organizing large collections of documents.
The naive te of this article is really astounding!
if the stuff 'isn't being used' are you sure? I recall hearing something about how you can pass date by using so-called 'unused' bits some IP header format. . . The system would 'ignore' these bits. But a virus would look to them and the virus could thus get secret data. . . I remember hearing that this flaw was corrected by actually making sure that the bits were set to some known value (ie fill with zeros). Otherwise the interface had a big hole in it. So . . . my question for you is: are your 'unused fields' really not being used by someone? If they are not needed, they should be removed unless you don't worry about malicious virus writters. just a point, and probably you don't have a problem.
This guy has it backwards.
"I assumed blithely that there were no elves out there in the darkness"
In the Palm OS with power off, the system starts back where the user left off. This is done with persistent memory. I recall a model for a file system that just saved everything is series as it was created. That would involve a lot of file storage. As file storage was developed in the past when it was expensive, this kind of a file system was not desirable. But now with DVD Read/Write soon to be obiquitous, that kind of a file system seems to be less of a rediculous idea. If you are worried that you will loose key-strokes: save everyone to a file. Append to that file every time that you type. But these ideas are not standard. So much was designed in the dinosaur days of small memory space when storage was expensive. The whole UNIX virtual file system is a good example of this. People in control of the industry have a vested interest to keep these dinosaurs alive (service contracts, etc). A lot of us who know how to design next generation system are OUT OF WORK. No one wants us to come in and tell their clients how these large corporations are ripping off the clients. And so we stay out of work. We have new ideas but we are pidgen-holed into deadend work. Our jobs are shipped to Bangalore. And the dinosuars still rule the earth. . . Yes, you can save every keystroke. You can have a file system that saves every version. You would want to specify which files would be in this type of a bin. I think that we should put governmental law making on such a system. Every person accessing the law writting software would need to identify himself. And then any change would be tracked so that we can KNOW who is doing what, who is draining the system. But I think that I am off topic now. So I will stop.
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.
What about OS for people with diabilities? We need to keep working and providing better ways to do things. It has not all been done. We need to do things for those who can't even pick up a mouse or type because they have handicaps. Don't stop thinking, don't stop dreaming.
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.
Thanks Microsoft! I surely did want your bloated junk running all the time or I wouldn't run your OS in the first place!
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.
Actually, Explorer, and the Windows Shell API in general, already has the capability (since '95) of representing multiple files/directories as an "application," or an aggregation of files.
It's just that no one has taken advantage of this capability and written the appropriate extension for this type of shell object.
A few examples of "aggregating" files together to form one shell object exist already though, such as the control panel and the recycle bin.
There are also zip viewer extensions which represent a zip file as if it were just another folder.
So, it can be done under Windows. Why hasn't MS or someone else already done it?
(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.
Sexist.
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.
And here you go: winnapp-patch.zip
Please be gentle to my 256/64Kbps ADSL line, okay? Besides, this is only to get rid of Program Files. Getting rid of "My Documents" (et al) is quite easy once you get the hang on the registry. Perhaps, I'll summarize how to do it when I got more time: I already have a draft lying around (just notes jotted down).
Hope it well help some people.
Seriously, it just saves (or at least, can be configured to save) the whole session (as seperate from any edited files) after so many keystrokes or time of inactivity.
Crash? Power cut? No problem. Bring emacs back up, read the message about recover-session and off you go...
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)
Maybe I'm just being pissy, but that was the dumbest thing I've read all week. And it wasn't the irritating "style".
I like to know when my document has saved. I like to control it. It matters to me what is on the hard drive, because that is what is visible to other processes/users/machines. I like that I can undo a change that I haven't saved without modifying the underlying file (hint - think of a header file that would trigger a major recompilation). Leave me in control!
As for different ways to create a folder in the file picker vs. file manager, I can't speak for macs, but I think it's the same for Windows (you can right click in the file picker dialog).
And having control over what is loaded into memory - is he insane? Why doesn't your computer load every executable into memory on startup? That would save tons of time later on! Does he choose to have the Netscape QuickStart (or whatever they call it) - the one that preloads bloatware for faster launch when you actually want to use it? I don't. Not for Netscape, RealPlayer, whatever. Leave me in control!
And does anyone think that item 4 contradicts (the second) item 1 + (the second) 2? If you can't quit an application that autosaves your document at whim, and you rename the file, what do you expect to happen?
Your favorite
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. :)
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
...nothing ever gets changed:
Microsoft has a monopoly.
As somebody already said, there's no incentive to make things better. You can read the same story with regards to the history of the x86 architecture. Just replace MS with IBM.
What about *nix and Mac's? Making (more) money is paramount to all companies. That means converting users from Windows. That means to promote user-friendliness, the UI of these systems have to be familiar to users who are already familiar with Windows. Certainly, small improvements can come about, but there can be no revolution in this type of environment. Rather, it would seem that everything'll be headed towards the most popular UI.
Then what remedies exist for this problem? Nothing within our lifetimes, short of a gun to a programmer's head and Saddam's voice saying, "Make this better," which may just do the trick, if there are also guns to the users' heads saying, "Use this program."
But it doens't matter. The sun's gonna explode in 6 years anyway.
1) Today applications DON'T take seconds to start. In fact, the bloat in software has kept the pace with advances in hardware, thus making the software today take the same resources (percentage-wise) as the one yesterday. Netscape, Photoshop, Real player, any application not deeply embedded in Windows take forever to start requiring all those nifty "accelerators" ran at login time that use up real memory trying to cope with this problem. Even if it didn't, so long as computers have limited resources (and hardware manufacturers will make sure the prices are never so low for us to afford plenty of ).
2) Same goes for documents. Saving documents in Word, images in Photoshop is never blazingly fast. Let alone that file versioning a la VMS fills the disk space quite quickly and would require an interface to "clean up" the unnecessary revisions lying around.
By the way, Word does by default do incremental saves which a lot of us here seemed to like so much; I hope we still remember the events concerning inadvertent release of information through documents published on the web that were saved using this mechanism. Besides, all the points made about me choosing when to save are valid - I really want to have the choice of when to write my changes.
3) Inodes - just by mentioning that the author proves he has no idea what he is talking about. Unix has had this for a long time - there are hard links which use inodes and there are symbolic links which just point to the path. So Unix offers both, care to check which type is most commonly used ?
For one, hard links are not portable across filesystems (partitions). Also, deleting a hard linked file does not actually release the disk space until all links have been removed. This can cause some serious confusion to the head of the Windows user. Hard links are difficult to back up and restore properly.
Want more ? When an application saves a file it usually creates a new file, writes the data then moves it over the original file (to avoid data loss due to write errors). Guess what happens to the inode number.
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?
even people who have spent their life trying to design the best user interfaces have made mistakes too. take a look at jef raskin's (designer of the mac interface) canon cat as an example. :)
Large print giveth, and the small print taketh away
The idea is that the unused bits were not checked. Thus the IP software didn't have any way of knowing that the header was compromised. And the header was exactly the same as far as the IP software was concerned. If you start to mucky around in the bits and bytes that ARE used by the header, then you have changed the header and the packet will route somewhere else. So, that isn't going to help you if you are a malicious hacking bastard. . .
What this means is that for bits that are routed around the internet, there is never a "Don't Care" bit as there would be with a chip interface. Any bit that is "UNUSED" should be set as either a zero or a one so that it can not be used by hackers. If the bit is USED then if hackers change it, it will reroute the packet and the software will know this. IE: board design with interfaces has this slight difference from design with IP headers.
Another point: With programmable logic chips there really are no "Don't Care" inputs. You must tie the unused gates either HIGH or LOW or else your programmable chip may not work as designed. This is always a good idea for board design in that it prevents oscillation and power burning by unused gates.