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)
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
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....
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
Let the system handle it. When it's idle, it can clean the processes up itself. Think of garbage collection under Java or flushing a disk cache...
I wrote a GTK+ text editor that saves the document on every keystroke with a frequency limiter so that you don't save more than once every 5 seconds. It used a background thread for the saving so the user interface didn't hiccup, and every save file contained a complete undo/redo history to the beginning of the document's life. It had no save buttons, only "open" and "close". I never finished it because it was plaintext-only anyways, so nobody was ever gonna use it.
11*43+456^2
Anyone from the UK may have noted that Crufts is the name of the annual dog show of the Kennel Club in the uk.
Of course what we really need is built-in version control at the filesystem level. That way it can save all the time (automagically) and the user can specific when to commit a revision (the equivalent of a CVS tag). You'd have all the benefits of not losing data during a crash, along with the ability to jump back to arbitary points and restore or branch from there.
It would also make system auditing much easier as you could tell who had been altering files and what they'd changed.
Like an eraser, or a bottle of tippex, that's what the "undo" button is there for. All this means is that the save process has to be a bit more sophisticated and store the last n changes.
A more sophisticated file system could help us there. During the day, we rsync the development areas every 15 minutes. It takes a trivial amount of space and CPU time. Yet for years I was stuck in the metaphor of doing nightly backups and telling folks they couldn't get back the files they changed in the morning.
The point is that saving files or versions in case we stuff things up shouldn't be our problem. We should have 'hard' commit points (this is a published document/reviewed code). Between then 'soft' checkpointing could be managed by the OS.
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.
Especially since mpt acted as the UI module owner for Mozilla.
A good example of open source design gone bad; where every voice is counted, regardless of whether that voice has any merit to it or not. Like a mirage, lack of ownership makes any ownership look a solution to the problem. Enthusiasm and verbosity belie the lack of expertise.
The ROX Desktop has gone someway to implementing this on X - rather than blindly re-implementing the Windows Way like so many other projects.
Speaking of GEOS... how to abtain one now for my linux box and it's c64 emulator...
I also read this: rox - desktop , it seems quite ideal at least in theory, when I get home from office have to install that and run some fieldtests.
P_tr
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.
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
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.
As a long time user of a foreign language Windows (Dutch) I can assure you it's almost never a problem. C:\Windows is the same in all language versions, as is C:\Program Files.
The only thing that causes problems is c:\windows\desktop, as "desktop" does get translated (it's c:\windows\bureaublad in Dutch).
Never heard of version control?
I'm currently evaluating a new IDE for developers in my area, IntelliJ IDEA 3. Anyway, it has gone away from the Save-button paradigm as well. Whilst there is still a manual save button, which you can hit whenever you like, it background saves a lot. Whenever you compile it autosaves, whenever you close a file it autosaves (without prompting) and whenever the app window loses focus it autosaves all open files.
The way it gets around the "but I didn't mean to save those changes" problem is with a local VCS. Every time it does an autosave it keeps a version, and automatically deletes those older than x days (configurable). This works alongside your "real" version control (say CVS or Bitkeeper) - essentially the local one protects you from those "oops" moments when you accidentally write over a modified file, and the external VCS does what it does now, holding actual useful revisions for a file forever.
You could compare this system to a multi-level undo feature which spans saves, but it's better than that - as being a proper VCS you can visually diff between versions, label particular versions etc. It takes a while to get used to the "what do you mean it's already saved!" aspect, but it's really very neat, and it means you essentially will never lose any work again.
Oh and yes, it ends up using a fair amount of disc space, but so what? It's a lot cheaper than my time. I could easily see a similar system working well with a wordprocessor, in fact Word has something similar with it's revision tracking. All you have to add in is the ultra-frequent non-obtrusive autosaves, and removal of unimportant old versions to keep size manageable.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
For ultimate Cruft, what about dragging something over the taskbar icon for the app. I've never understood why this doesn't do exactly the same as dragging the item over the application window, but the damned thing doesn't work. And I can start dragging something and then press Alt-Tab to bring up a menu of currently-running apps. But I can't drop the item onto that menu of apps. Why the hell not???
Now, if the hardware were to change such that we weren't tethered to mice and keyboards, then I can see some interesting possibilities. But things being what they are, I'm quite content with my shell and VI.
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.
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...
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.
No you don't. (Ok, if you have to use task manager, kill, or Force Quit you do, but let's assume a well-behaving program.) 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?
Under that sort of system, you would want a way to create new documents, but Windows has a "New" menu that will create a blank document of a given type.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
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.
I think that argument only works down to a certain level, no matter what the technology is. Obviously, as a software engineer, I have a fairly good understanding of how computers work. However, if pushed, my deep knowledge about the electronics which make up a CPU and the underlying technology is pretty weak. I don't need to know this stuff for the application development I do in Java or C++. If I did embedded systems programming the situation might be very different. Also, if I did know this stuff I might write better programs, perhaps, but I don't *need* to know in order to write adequate, functional code which performs half-decently, is easy to maintain and re-use.
:).
In the Microwave Oven example, I don't think it is at all obvious to joe user how it works. All they know is that they can set it for a specific length of time, and maybe different power levels, and that it heats stuff up. I go a few steps beyond that in that I have a chemical physics degree (from a long time ago!) so that (if I dig deeply!) I can remember stuff about molecular orbitals and energy absorption etc.. but I still don't know exactly how the microwaves are produced because I never asked anyone - nor do I need to in order to get my hot ready meal every evening (I work long hours, OK? don't hassle me over my eating habits!
(before you all start explaining microwave ovens to me I really don't want to know - if I did I could work it out for myself or look it up!)
So, I maintain that a user really only needs to go as deep as required for the job they are doing, or possibly a tiny bit deeper for that little extra understanding. In the case of someone using a computer for word processing they need to know how to turn the machine on, how to start the word processor and how to type - they don't need to know about disk caches, or saving in blocks rather than bytes, or CPU cycles.. Knowing about these things does nothing to help them do their job. There's no reason *why* they should have to know these things - computers are there to help people, after all, not to hinder them.
It's the job of the software engineer (and the product manager, and maybe the UI designer) to make life as easy as possible for the user, based on the known knowledge that user has.
Q.
AMEN TO THAT!
Really, if MS and KDE want to keep the feature of the "SetFocus" function, they should at least put a window manager level preference setting to turn it off. If set, no application will be able to take the focus away from another.
If I want to type in a window - I'll click on it or tab to it or whatever.
When web browsing I have a habit of opening multiple windows at once so that web sites can load in the background while I read other sites. At home I just run Mozilla, and tabbed browsing works great - about the only interruption is when I need to enter a master password (which shouldn't interrupt me, but I can live with that). At work I use IE, and I'm constantly pestered by windows raising to the top simply because they've finished loading...
Ditto with applications. First thing I do after I log in is typically launch a few apps of the desktop - before it gets buried. Then for the next minute while login scripts run and the disk thrashes I can't use my computer - not because of it being too slow, but because one window after another keeps grabbing focus simply because it has loaded...
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.
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.
Some months ago I wrote a short paper on the (then, 0.9.12) new XINE user interface which was really horrible to use. They took that "real-world device" metaphor too far; you can also observe this in other (preferably multimedia) programs (a detailed analysis on the Apple Quicktime Player can be found on the Interface Hall of Shame), XMMS also comes to my mind as an example on how not to do it.
So: Better have one theme that keeps focus on usability than tons of ugly, non-intuitive and mis-metaphored skins.
"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.