Slashdot Mirror
Are Computers Getting Too Easy To Use?
An unnamed correspondent writes: "The latest issue of the Journal of Electronic Publishing has a paper by Bradley Dilger called The Ideology of Ease. Dilger writes that making computers "easy" may also make them less useful. 'Ease is never free: its gain is matched by a loss in choice, security, privacy, health, or a combination thereof,' he says." Some of the allusions seem a little stretchy (I'm not sure that Marx has much to do with user interface design) but Dilger makes an interesting case for re-thinking the motives behind some moves toward "easiness." Especially as GUIs for Linux proliferate, it makes sense to think about exactly what constitutes ease.
I ask this because all the comments so far are based on the statements in the /. summary, not the article itself.
His argument is that ease-of-use has ceased to be the means (as it was initially with the desktop metaphor) but the end of GUI design. That is, programmers are now trying to make things easy on the user, instead of easy to use productively.
An example of his point I'd like to reference is the "smart menus" in Microsoft Office, which deliberately hide functions in order that the user doesn't have to see them. That actually makes it harder to use the software's functions, and it doesn't make it any easier to use the existing ones; it simply lets the user feel at-ease, never even seeing options he doessn't understand.
Steven E. Ehrbar
While I agree that his statement is bullshit, your reply implies some steaming hot crap of its own.
While you can make the GUI itself as usable as you want, you certainly can't make the system as a whole easy to use unless the underlying non-GUI architecture is clean, consistent, tight, and well-organized. Typical end-users need more than a pretty symbolic graphic interface slapped over top of a chaotic, complex system; they need a system that is simple and well-organized in every place it is exposed, including the filesystem hierarchy and the ability to install and configure hardware and applications.
GNU/Linux or GNU/BSD systems are the furthest thing from this. They are chaotic and their overall organization (or lack thereof) hasn't been thought out well at all. It's not that the development community is incapable of developing a well-organized GNU/Linux or GNU/BSD system; it's that no one seems even remotely interested in doing so.
For instance, every program uses a different configuration file format, often times with its own steep learning curve. This is a headahce not only for expert users who want to configure everything with a text editor (they must usually learn a new and different scripting language just to configure each new app!), but for developers who have to implement a custom GUI configurator app and different file format parsing code for every program. What is needed in this instance is a common XML/schema-based configuration file format so that developers can write a single configurator app and have it suck in a schema that comes with every app it is used to configure; the configurator dynamically creates dialogs, controls, etc, based on the schema and can then be used to configure any program in existence--while expert users or administrators who want to telnet in and edit a configuration by hand can easily do so to an XML-based config file, and can then even run a common XML validator that verifies the syntactical correctness and well-formedness of the XML configuration file before doing something crucial like restarting a key system service.
Another foolish oversight in underlying GNU/Linux design is the practice of hard-coding absolute directory path references into programs. For instance, if you relocate gcc to a new directory, it breaks unless you (1) recompile it from sources and compile in a different hard-coded directory expectation, or (2) download binaries that someone else has already gone to the trouble of compiling that way for you. As an end-user or administrator, you have very little choice about where you can install a new program's files within the filesystem. This sucks for distribution makers who might want to make a simpler, better-organized filesystem hierarchy to make a GNU/Linux system that is more suited to normal people. For instance, I might want to create a distribution that has only 3 major root-level directories: /apps, /docs, and /system. But I can't do this now without hacking around on source code and rewriting every single app and utility and daemon I include in my system--and that's preposterous. Instead, every app should have been smartly programmed to not expect the existence of a file in a particular place in the filesystem, but instead to assume the existence of an environment variable in which it can look to retrieve the needed path; in this way, I (as an end user of intermmediate knowledge or as a distribution maker) can rearrange the filesystem hierarchy as I see fit, without having to hack around on the source for every installed program and recompiling it. In fact, I can even relocate installed binaries and other files and still have the program work--something that's a clear advantage over the world of Windows.
- "It's just a matter of opinion!" - PRIMUS
Ease is never free: its gain is matched by a loss in choice, security, privacy, health, or a combination thereof.
This sounds suspiciously like something out of an economics textbook: if you're at an equilibrium, utility maximizing point, you can't gain something without giving up something else in return.
However, the above is true only if you're at an equilibrium point, when all factors are in balance and you're forced to trade off one for another. The fact of the matter is, most software is difficult to use simply because it is poorly designed, with skill or little thought given to the end user experience -- end of story.
There is easy-to-use, and then there is easy-to-learn. They are often orthogonal. That seems to be especially true in computer UI's.
It seems to me that the MacOS is easy-to-learn, judging by the things the Mac-o-philes tell me. That is, you can easily get things done, without any need for any understanding of what is going on behind the scenes. That isn't really a bad thing, either, until you NEED to know what's going on.
That's where the author's example came in: the kiddies would use ftp, and not have a clue where the file wound up, or even that they had downloaded a file. They hadn't learned that you start an application, and then open a file... they had learned that you click on something, and it opens...
If you save a file somewhere on a Unix box, but don't know where, or exactly what the name was, you can use grep with regular expressions, or any one of a number of methods to search the directories where you have write permissions and find it. If you have that problem under Windows, there aren't any reg-exps, just ? and *. Reg-exps are hard to learn, but so powerful and easy to use. They just don't seem to fit the Windows/Mac way of doing things. This is the difference between easy-to-use and easy-to-learn In a Nutshell (hey, that's a catchy phrase, I should trademark it!).
I read that fellow's article,and I'm still scratching my head. I know that you have to salt a scholarly paper with some big words, and some obfuscation, lest people realize that you really aren't adding anything to the field, but this was ridiculous. What field is this guy in? The standards for content are very different than in Econometrica, or even American Statistician.
I'm really not sure what his point was, but I have the uneasy feeling that he had one.
Nels
See what I've been reading.
This is an interesting way to start a Sunday. :)
I've got to stress that the headline and snippet chosen here is NOT an accurate summary of my article. As I say time and time again in the article, I have NO problem with the general trend of computers becoming easy to use. My problem is that this ease is sometimes portrayed as the only way to do it, in a variety of different contexts, and by a variety of different agents. "Is it easy?" can become the only question asked, and that compresses the possibilities of computing for a lot of perfectly capable folks.
More on this very complex problem later... got a lot to do today. Thanks to everyone who has commented so far -- many of the points made are quite salient. I hoped to start an academic discourse about ease stuff; a Slashdot discourse is great as well.
best,
Bradley