Slashdot Mirror
Let's Kill the Hard Disk Icon
Kellym writes "The desktop metaphor is under attack these days. Usability experts and computer scientists like Don Norman, David Gelernter and George Robertson have declared the metaphor "dead." The complexities blamed on the desktop metaphor are not the fault of the metaphor itself, but of its implementation in mainstream systems. The default hard disk icon is part of the desktop metaphor. And the icon is the cause of the complexity created by the desktop"
About the time I got to him describing Linux GUIs as "simpler and are easier to use and manage" I was starting to realize that while the author starts off with an appeal to authority "X, Y, Z say I'm right!" the article was mostly just a few ill-explained conjectures interspersed with a bunch of filler.
Where's some real data on desktop usability? Surely if the desktop is considered so wretched, there'd be a score of empirical HCI studies that:
1) Proposed an alternative
2) Actually went out and prototyped the alternative
3) Showed that the alternative was more efficient than the desktop
But I'm not seeing anything coming out that would seem to indicate that the desktop was dead.
The author is against the heirarchical tree structure of directories for organizing content but mistakenly identifies this with the "hard disk icon" (which is, in fact, just a doorway into the heirarchical structure).
In it's place he would do away with the hierarchical directories and replace it with multiple "desktops" (e.g. flat, non-heirarchical, visually-managed workspaces).
The glaring problem with this is that most professional computer users (ie. discounting grandma who sends email three times a month and opened Word once) have so many files/applications on their computers that they would need dozens (or hundreds!) of these desktop workspaces to manage all of the files & applications.
True, some Linux desktop environments have multiple desktops, but check and see how many users have more than six or eight desktops configured. Very few. There's a usablility threshold where if setting up more "categories" (in this case more desktops) actually decreases usability, whereas setting up "sub-categories" within the top-level categories will increase usability. Hence: heirarchy.
The entire field of taxonomy is dedicated to this principle.
As a previous poster said: This article is daft. (And poorly written.)
The desktop and window interface as we know it was developed in Xerox Palo Alto laboratories.
Why we still 20-30 yrs later have no good new metaphors is because there is no fundamental development dedicated to that effort.
The machines today come, thanks to ID and other game companies, equipped with graphics chips more than able to create an immersive 3D environment. This capability is totally unused in daily usage.
Trash the disk metaphor like it has been trashed in UNIX file hierarchy: you can still know everything about your disks, but they have become irrelevant in the directory structure.
A good 3D environment should trash the desktops as well and use spaces instead. Yes you can have your 2D windows for text terminals and whatever current applications, but you can as well do your 3D CAD/CGI design/rendering in space provided by a 3D GUI. Imagine being able to "turn around" with mouse or similar (headmounted?) device in order to look around; to be able to "zoom" into and past separate windows and work areas (workspaces) with mouse wheel or cursor keys.
Imagine being able to link to each other related files/items in a 3D-space instead of 2D. What would that do to your DB schemes. Or to zoom into a software package's source icon to see its design, zoom into a class to see its components, and zoom into a method to see its source.
Etc.
This would require trial-and-error, examining, playing around. Where is the team that is being paid for this development?
Any hints would be greatly appreciated. I could even be interested in such work myself.
Consistency is overrated.
The complexities blamed on the desktop metaphor are not the fault of the metaphor itself, but of its implementation in mainstream systems. The default hard disk icon is part of the desktop metaphor. And the icon is the cause of the complexity created by the desktop.
If the desktop metaphor is perfect, yet the "hard drive" icon is part of the metaphor, the how can he claim that the metaphor is perfect and it's the implementation that's wrong?
Ignoring the fact that they contradict themselves in the first paragraph, there's plenty of other glaring holes in the argument.
"The extension of the "rules of the desktop" to cover the entire capacity of the hard disk is the main reason why systems that support multiple desktops seem simpler and are easier to use and manage."
Who says it's simpler? You still need to initially setup that desktop, which involved setting up shortcuts to locations in the file system. Try doing that without delving into the hard drive while still maintaining a super simplistic environment (i.e. no command line either). Besides, maybe I have a lot of data and need 20 desktops to organize it correctly. So instead of setting the default "open" path in the application of my choice, I would have to switch desktops to open a file. What if I want several things of different types open at once?
"It is possible to build labyrinths of internal directories that eventually become too deep to navigate via the mouse. The feeling of such spiral filing systems is of endless depth, requiring great effort to retrieve a piece of information. It is difficult to create the same spiral feeling on the desktop."
So sub-folders are a bad thing I guess. Yes, it's terribly confusing to have a tree like "documents/company/forms/standard contracts". That would be too confusing to navigate. But if you had someway of setting a "view" on the desktop that would be simpler. And this "view" menu would be incredibly simplistic to use and would be able to differentiate between Forms and Letters in a DOC or PDF file? Gee, that sounds like more work when I create the document too.
"To reap the benefits of the desktop metaphor, we have to design computer systems that leave the user clearly anchored in the desktop metaphor at all times. But in the multiple desktop, you are always on a desktop and can't ever get lost inside the computer."
Ok, but you could get lost in all the desktops you'd need to setup.
The desktop was designed to give users quick access to common programs. You don't need every file you ever need to use, sitting on your desktop, or even some virtual desktop somewhere. Because if you only use it once every six months, you're going to forget what desktop it's on anyways. Intelligent directory trees and default "file-open" locations are the way to do it. The methods outlined in this article would require a lot of extra setup the user would have to do, and doesn't address new files being added by another user on a network.
I guess I was really bored this morning, I didn't intend to comment that much on an opinion piece on some other site. Which makes me wonder, why are we linking to use opinions on other sites? Maybe the author is somebody I know, but isn't this like linking to a slashdot users comments?
The article is simply nostalgia wrapped in a thesis. I think the argument for killing the hard drive icon is very valid, but the rest of the paper devolves into the meanderings about desktops.
Multiple desktops are simply windows. Call them whatever you want, but the authors want a windowing motif without a base window to throw junk onto.
The other problem is the incredible naivetee of this statement from the article: Add unlimited files without fear of clutter. (You can change views in a directory.) The first time you used a Disk Operating System, you had a tendancy to throw all of your files into one directory. That's my definition of clutter, and it is no different than the desktop paradigm where junk files reside.
I think the authors are forgetting history and the reasons why we don't use bare-bones DOS to operate our applications. They're also forgetting that with a computer monitor, if you remove all of your desktops, what's left? there has to be some basic background, even if it has no functionality.
Personally I use 0 (zero) icons on my desktop.
They are BEHIND these damn window things - WTF use are they there?????
All my shortcuts go on the menu. Where I can get them, without hiding the current app.
Desktops are useful, in real life, when they are large enough to sit *around* your work. You can reach out and grab pens and such. Desktops, on PCs, have never yet been big enough for me to feel comfortable with more than a couple of (non-overlapping) windows up at a time. (Don't get me started on overlapping windows... grrr...)
And I NEVER store files on the desktop. Why? Because, sonny, this is Win2K with a roaming profile. Everything you write there is synched with the server (which, half the time, is in a different city from me). T r y l o g g i n g o n t o d a.... oh feck it can I log on as you today?
- Cantankerous Old Git
Alan Cooper wrote a whole book [amazon.com] about how letting computer nerds design computer programs is wrong and stupid.
That is until you realize that, like designing a house, if you don't know what you're doing the whole thing is going to fall apart the instant you look at it funny.
The really interesting thing is that computer programs are quite often designed by People Who Aren't Computer nerds. They're called "customers." Often, these "customers" come by to meddle with the design during its building phase. If this were done during the construction of a house, you would have spaghetti for plumbing, electrical wiring that wouldn't pass inspection, and it would probably float in the air by magic. And this is often exactly what happens to software when you go through a few "design changes" as you make attempts to show the customer what you're spending his hard-earned (or maybe not-so-hard-earned in the case of some companies) cash on during the coding phase of the software. And what they believe to be "minor interface adjustments" typically turn out to be major overhauls that require an almost total rewrite because of how it was originally programmed. The problem is that it needs to be finished in a week, because that was "the last of the changes." If you've ever wondered why programmers don't sleep in that last week of development, that's why.
Don't fool yourself. You wouldn't let a bridge be designed by Joe Average, now would you? Coding's at least as complex.
"No problem. I have the capacity to do infinite work so long as you don't mind that my quality approaches zero."-Dilbert
Don't compare programming to construction. They are so similar, yet implemented so differently it's a shame. There are long lists of rules and codes by which construction has to do things. Are some of these things the "best" way? Probably not, but it is the accepted way and is therefore ubiquitous. Due to this, advances in construction techniques happen slowly, and usually come about through improved tools rather than new rules or codes.
However, in the programming world, nothing is standardized. There are approximately 8 bajillion ways to encode the alphabet. There are a dozen different libraries to display a bitmap image. There are 18 different widget sets in X to accomplish the same thing, and two major toolkits for writing software for Unix.
Advances happen often and create whole new directions to take programming, but these advances happen in the basic rules and codes while the programmer use the same old vi,gcc,gdb from the 19th century.
Computer nerds are poor designers, because they have a skewed outlook of what a computer can and should do. A nerd looks at a computer and sees a box filled with limitations. A nerd sees a computer as a natural extension of his hands and head. A user is 180 out of phase: they see a computer as a magick box with an obtuse and difficult operating mechanism.
Don't fool yourself. You wouldn't let a bridge be designed by Joe Average, now would you? Coding's at least as complex
I wouldn't let a programmer build a bridge either: they'd invent a new method of smelting ore and an entirely new branch of mathematics to build it, it would cost 3 times as much as was estimated, and would be 10 years late in construction. And, after it was built, it would fall into the river and the programmers would blame Microsoft.
I know how complex programming is. I also know that "but it's so haaaard!" is a pretty lame excuse for not doing it right. Programmers, by and large, do not do it right when it comes to design. They are great implementers, but poor designers, because they end up solving the wrong problems.
Perhaps I'm unclear when I say "design"--I don't mean how the inner workings of a computer program passes bits around. That's not design. Designing comes long before fingers touch keyboards. It's where real designers decide what problem the program should solve and how the user will interact with the program. After this has been designed, then the programmers implement this set of specifications. I'm not talking about those designers who put a pretty picture on a CD-player program: I'm talking about real designers that work just as hard as programmers do to design, test, lather, repeat as neccessary to create a good, usable program.
Potato chips are a by-yourself food.
>the GNU people (it was the GNU, people
>right?)
Yes.
>that decided that 'man' wasn't good enough and
>they wanted to reinvent it;
It's not that they wanted to reinvent itthat's a probelem; that would have been survivable. It's that info is just plain an abomination. It seems to be an "emacs everywhere" notion. It's a pain to navigate, counter-intuitive, and the type of thing that could only have come out of the emacs or redmond mentalities.
hawk
Played with GTK's open widget? I think it's the greatest thing since sliced bread. Why? It incorporates the best of the mouse-based paradigm that users are used to and additionally adds the keyboard-based commands that power users crave.
Have some (well-written) GTK apps installed? (Some apps written by less-clued folks try to implement their own open boxes... ugh!). Open such an application and go to file/open (alt+f o). Now, type part of a filename and press . If possible, the filename will be completed for you; if several options are available, the windowed listing will be reduced to them. If the only option is a directory, you'll instantly see the contents of that directory (and if it has only one subdirectory, you'll be instantly inside that too). There are lots of other goodies it's capable of as well (some globbing capabilities, &c).
The point of this is that it's possible to write an interface which is intuitive for first-time users but also insanely powerful for power users. It also demonstrates how a good set of underlying libraries can provide applications with really nifty functionality without the programmer even having to be aware that it's available.