computer literacy

Dylan Evans recently wrote an article "Smash the Windows" (discovered via Slashdot), arguing that for computer users to be truly empowered, they must reach a much higher level of computer literacy, understanding the "insides" of the machine. Underlying this argument is a fundamental belief I share: people need to have an appropriate understanding of their tools. But even with my hyperbole filter turned up to the max, I found this article to be misguided, insulting, and fundamentally flawed. I'll start with the insulting. Consider this choice quote:

It's not just laziness, of course, that prevents people from getting to grips with computers. Cowardice also plays its part.

When someone is more concerned with being right then with helping the audience that is supposedly trapped, each "a prisoner of [their] ignorance", something is wrong. But that's not all that's wrong here.

Evans argues that computer users are largely unaware of the workings of the underlying machine, and that the graphical interface obscures the understanding of these workings. He instead advocates the use of the command line interface and the learning of programming languages as the necessary path for all users to reach "power user" status. He is right to note that many users do not understand the mechanisms at work in their computer, often preventing them from getting the most mileage out of their computer.

However, he neglects the fact that command line interfaces and programming languages are themselves carefully crafted user interfaces, an abstraction over the messy details of machine language instructions, which in turn abstract the electrical circuits we send electrons coursing through to perform computation. GUIs are just another push forward in this trend... and a incredibly powerful one at that. Human predilections for visual imagery are not something to tossed aside callously -- these skills provide ways in which to fundamentally improve human-machine communication: increasing communication bandwidth, decreasing users' cognitive burden, and often times enhancing learnability.

Consider the countless UNIX hackers who, though quite skilled with the command line interface, run the gkrellm program, providing visual monitors on system level features such as CPU utilization, memory load, and network traffic. This is a simple instance where visual representations are more intuitive and effective. To ignore this and then go on to say that computers "prefer text" is a gross mischaracterization. Programmers may prefer text because it requires less implementation and design effort. To the computer it is nothing but a series of high and low voltages coursing through silicon. This doesn't argue for an embandonment of graphical (or tactile, or auditory, etc) interfaces, it argues for continued exploration of better tools for creating such interfaces.

At the heart of Evans argument is the need for understanding how the underlying system works. I agree that this is an important part of interaction that current interfaces (both textual and graphical) obscure. To paraphrase Paul Dourish, in human-computer interaction we call this accountability: that system activity is observable and reportable, such that third parties can make sense of the activity within the context in which it arises. System activities should be observable by users on demand, and preferably in a number of fashions (system logs, charts and monitors, or more fanciful visual abstractions) so that users can interactively learn the traits of the system. Evans seems to confuse the medium through which this information is carried with the information itself.

Ideally, system design should include mechanisms for communicating that design, so that users can learn the internals of their machines through time. An interesting example would be a monitor that visually depicts the movement of data between physical and virtual memory, I suspect a simple experiment would show that an understanding of systems concepts such as thrashing would quite naturally emerge through such an interface.

In the end, I'm sympathetic to the underlying lack of user power Evans attempts to address--hell, that's why I do what I do--but I find the approach he espouses reactionary and the way in which he espouses it troubling. Introducing more programming education will undoubtedly provide the next generation with an important set of skills and conceptual structures that will facilitate success and technological competence, but let's not unduly limit the ways in which this can be expressed.

And so ends my ranting. :)