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.
Man, when I started out (1973), you had to be really, really dedicated to use a computer. Everyone who used one knew how to program (ok, mostly because they didn't do much else). When I hacked into my first UNIX system (1975, one of the hundreds at Bell Labs in Holmdel), half the users didn't even have passwords. Didn't need 'em, UNIX (System III, maybe something even earlier) was just to hard to use.
Now anyone can learn a computer. My Mom knows three operatings systems (AmigaOS, MacOS, Windows). What's this world coming to? They were hard to create, they should be hard to use. In fact, most of you shouldn't be on a computer, either. I think the test should be "can I design one from scratch". In case there's no silicon FAB in your backyard, you can use FPGAs...
-Dave Haynie
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.
If you look at the very bottom of an article (before the footnotes and bibliography), you'll notice that Dilger writes:
What he's saying essentially is that he is opening a formal enquiry into this particular subject. It's the beginning of a scholarly dialogue about the ideology of ease; understanding this can be greatly beneficial to both academics and programmers and developers.Should car makers include displays for compression per cylinder? Mixture? Exaust spectralnalysis? All of these items would be educational to the user and give the user a better understanding of how and why his car works, but it would not help him get to work in the morning
I don't think your analogy is quite correct here. The Microsoft Office "hidden" menus are hiding functionality that cannot be duplicated with other features. If you were talking about how Microsoft hides things like the status of the disk cache or the the number of free clusters or something like that, you'd be correct.
But what we're talking about here is more akin to car makers who might, for example, hide the cruise control buttons or the car's stereo behind panels for fear that new users would find them to difficult to use. Imagine walking into a car where everything but the minimal tools you need to get you to work in the morning were hidden behind panels. The only things visible would be the ignition, the shifter, the steering wheel, the pedals, and the speedometer. The fuel gauge, the temperature gauge, the stereo, A/C controls, cruise control, etc. are all hidden behind panels that must be opened first before they can be used. That's what MS Office is doing.
My journal has hot
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
"I see no reason why computers can't have several layers of user friendliness. When you're comfortable with one leve and ready to move on, you enable the next layer of complexity."
Good point. However, most important for mindshare and marketshare, is how easy to use the "newbie" level is, because this is where the overwhelming majority of users will enter the system. If this level is sufficiently buggy, the new users will never bother to become advanced users, they'll just walk away. If the "newbie" level *requires* use of the power-user interface (like editing config files, or using the command line) to get basic things done such as modem setup, or printer setup, then, again, new users will never bother to become advanced users. Therefore, the most user-friendly level should have sufficient power to do the things that even beginning users need to do, easily, consistenly, and seamlessly.
Multi-level UIs is where OSes are converging. From the power-user side, the free *nices are adding increasingly easy to use GUIs - desktops and window managers. From the newbie side, the MacOS is layering it's extremely consistent, easy to learn GUI over a full BSD unix, with terminal windows/command line, bash, gcc, apache, etc. That's what MacOS X is.
But in order to succeed, an OS must ensure that the *easiest* UI level, the GUI, is seamless and easy to use. Power users expect, and can tolerate a little complexity, but most new users cannot, and it is from the legions of new users that tomorrows power users will come. If you want these future power users to end up on your OS of choice, then you need to make sure that the entry level UI on your OS is extremely consistent and user freindly. So far, the free *nices are not there yet. Much of this is due to the inconsistency of X application user interfaces on the one hand. On the other, it is due to the immature state of the free desktops, by which I mean, their failure to provide complete access to every sort of configuration a new user will likely need to do in a consistent, easy to understand way. Great progress has been made, but they're still not there yet.