Posted by: Anonymous Coward
on March 02, 2004 12:49 AM
There is a large conceptual difference between a task-oriented interface and the list-of-features. Please Red Hat, do not, I repeat NOT, try to do the kind of interface esr proposes!
The graying-out "feature" that esr proposes is what makes MacOS and MSWindows computer's so fscking hard to use! What happends when you want to do something? You inevitably have to figure out the way the author wants you to do it -- otherwise you'll get all your alternatives "grayed out", in a graphical user interface maze of passages, all alike. Do you export the printer on the server, mount it on the client, or both? In which order?
Microsoft has spend the latest five years of fixing the mistake with this interface by conducting comprehensive user studies and placing all kinds of shortcuts all over the place. This graphical TIMTOWTDI-frenzy creates a new problem: There's no way to really tell if your way of doing things will work or not, because there is always another way to try. Most ways all lead to the same dead end.
Logic breaks. That is important to understand. If you gray out the SMB print share when no Windows machine is on the network, how do you add a printer somebody exported via SMB from a Macintosh? How do you know if your software doesn't support IPP or if some internal logic failed (or suffered a sudden network glitch) in it?
The way esr proposes breaks what I believe to be the most important rule of UI design: The computer is supposed to augment the human! Not the other way around. It should be easy to do whatever I want to do with the computer. Hiding away options from me isn't that way.
The solution is to differentiate the task-oriented interface from the configuration one. I believe the new Control Centre being sketched for KDE 4.0 may be along those lines. That would be a great thing.
A perfect example, by the way, of why we need more than one Linux desktop. Dumbing-down the interface has the side effect of increasing the amount of hand-editing (or registry-twiddling) when the interface doesn't offer what you need.
Learn about Linux
Download Linux
Get Linux help
CUPS/RH: Please don't!
Posted by: Anonymous Coward on March 02, 2004 12:49 AMThe graying-out "feature" that esr proposes is what makes MacOS and MSWindows computer's so fscking hard to use! What happends when you want to do something? You inevitably have to figure out the way the author wants you to do it -- otherwise you'll get all your alternatives "grayed out", in a graphical user interface maze of passages, all alike. Do you export the printer on the server, mount it on the client, or both? In which order?
Microsoft has spend the latest five years of fixing the mistake with this interface by conducting comprehensive user studies and placing all kinds of shortcuts all over the place. This graphical TIMTOWTDI-frenzy creates a new problem: There's no way to really tell if your way of doing things will work or not, because there is always another way to try. Most ways all lead to the same dead end.
Logic breaks. That is important to understand. If you gray out the SMB print share when no Windows machine is on the network, how do you add a printer somebody exported via SMB from a Macintosh? How do you know if your software doesn't support IPP or if some internal logic failed (or suffered a sudden network glitch) in it?
The way esr proposes breaks what I believe to be the most important rule of UI design: The computer is supposed to augment the human! Not the other way around. It should be easy to do whatever I want to do with the computer. Hiding away options from me isn't that way.
The solution is to differentiate the task-oriented interface from the configuration one. I believe the new Control Centre being sketched for KDE 4.0 may be along those lines. That would be a great thing.
A perfect example, by the way, of why we need more than one Linux desktop. Dumbing-down the interface has the side effect of increasing the amount of hand-editing (or registry-twiddling) when the interface doesn't offer what you need.
#