Jef's Notes for This Film and History©
Jef's Notes for this film and history
©copyright 2005 Jef Raskin all rights reserved
Jef often wrote out his ideas as a discipline he says in one of our interviews that writing helped to clarify what he wanted to say. This document helped us to shape the focus of the movie working titled "Magic of the Humaned Interface." Because it is Jef's writing we are not releasing the rights. Please contact RCHI if you'd like to use any of this material.
Director Jennie Bourne
My name will always be associated with something I did a quarter of a century ago: the creation of the Macintosh computer project when I worked at Apple. I cannot duck that connection, nor would I want to. It is an achievement of which anybody would be proud: the Mac was instrumental in changing the way computers look and feel, and the way in which they are used. The changes were based on a deeply-held code of the right and wrong ways to treat my fellow humans, and a study of psychology more than on any desire to advance technology per se, though it was necessary to do that, too in order to achieve my primary aims.
I was working on a far better way to use technology and writing two books when I recently learned that I have an incurable cancer. One book was to be "The Mac and Me", a personal history, a corrective to decades of misinformation on the origins and principles behind the Mac, and a tribute to my parents who taught the importance of uncompromising moral integrity by example. It was to be an autobiography that would tell what it was like to be with Steve Jobs and Steve Wozniak in their garage in 1976, and to chart the changes, some funny and some ugly, that prominence and wealth brought out from theirs' and others' personalities. There will be some of that here.
The other book, "Archy: A Humane Computer Environment" was to describe a better approach to using computers; the system I call "Archy". Its advantages are obvious to beginners and ordinary users, but quite out of the main stream and difficult to understand for many of those immersed in current methods -- as was the Macintosh when I first proposed it -- Archy is by far the easiest to learn and most pleasant way to use computers and other information-based technology I know of. I will not ask you to take my word but show you why, and an accompanying web site will let you download it. Archy is also more efficient than today's "Graphic User Interfaces" (GUIs) such as Windows and the Mac OS and will increase the productivity of any enterprise or individual that chooses to use it. It also represents a rethinking of the design of computer software in a more general sense.
We know that Archy is very easy to learn, this is not at all theoretical. Parts of it have been implemented and tested for years with thousands of users. Typically, users moving from Archy to a GUI make comments such as "why did they do that in so stupid a way". Moving from a GUI to Archy is accompanied by remarks such as, "It can be done that easily!". Many questions have the form "How do you do this?" for various things you have to do in a GUI and for which the surprising answer is, often, "You don't have to." Here's a conversation with a GUI user learning Archy. The GUI user is trying to find out how to "save" a memo:
"How do you save what you've just written?"
"Don't worry, it's saved."
"But what if I didn't want to save it?"
"Delete it."
Compare that with a conversation with someone moving from Archy to a GUI,
"Where did my memo go?"
"Did you save it?"
"No, why do you have to do that?"
"Because if you don't save something, the computer throws it away."
"You've got to be kidding."
Though millions of people have come to accept it as normal, it doesn't take long to realize that it is dumb to be throwing things away as the default behavior of most applications, yet that's what computers have been doing to us for years. GUIs are full of that kind of incompetent design decision. I know very well how this design error came about historically, but we should have fixed it long ago. In Archy, it is fixed.
While many realize that the Windows and Mac GUIs (and those that have come since) can be obnoxious -- witness the unending stream of cartoons and jokes about them -- few realize just how punitive they are and just how deeply the problems are woven into the design of modern GUIs. Most people assume that there is something inherent in the nature of computers that forces them to be as they are. This is false, it is just human inertia, a degree of ignorance, and lack of moral fiber that has kept the industry from doing better.
I was careful to say "the Windows and Mac GUIs" in the paragraph above to distinguish the interfaces from their respective operating systems. There are vigorous discussions about the relative merits of different operating systems, such as those two and Linux. However, when you want to do a task using the computer -- which is what most of us want to do with them -- as opposed to doing developmental work on computers themselves you should have to consider only the content of what you want to work on and what you want to accomplish (adjust a picture, calculate an interest rate, whatever). There is no need to involve yourself in dealing with an operating systems. May I repeat this with emphasis: from a user's perspective THERE IS NO NEED TO HAVE TO DEAL WITH AN OPERATING SYSTEM. Just as you do not need to know or care what particular brand of parts are used inside the box, you should not need to know anything about the operating system (OS). That you currently are made to be aware of the OS is a fundamental design flaw in present user interface design.
Current manuals (not from the manufacturers, who have abandoned this responsibility) for Windows or the MacOS run to about 1,000 pages and they are by no means complete. Any product that requires manuals of that size for ordinary use (not expert use or programmer use) cannot begin to claim ease of learning as one of its attributes. Also, much of what you have to learn is arbitrary, almost chaotic. This has come about because current GUIs fix apparent problems by adding new methods to the old ones. A heavy price is paid for this methodology. Aside from the likelihood of adding some new difficulties of its own, each new widget adds to the already overbearing weight of what the user has to know to use the system effectively.
Part of my task is in making it clear that Archy is not just a collection of "fixes" to current designs. It is fundamentally and necessarily different. What Archy sacrifices is familiarity. This means that even if you are an experienced computer user, you will not be able to use Archy without having to learn a few new things.
Here is a lesson right out of " Sesame Street ": Something cannot be better than another thing if it is the same as that thing. To be better it must be different. But if it is different, then it is not familiar.
And that's a major hurdle where companies such as Microsoft and Apple fail us: they try to keep their computer systems "backwards compatible". Their designers and marketers are gutless in the face of their own success. It seems to require an independent voice to point out the obvious, and instead of just complaining, this voice knows how to solve the problem.
Another problem that today's GUIs share is a heritage from a time when nobody knew what computers were going to be used for. There are many "features" that make them slow and awkward for expert use. It is now possible to design systems which let expert users fly while also making it easier for novices to get started! Usually, a novice will find Archy easier to learn than will many experts, because the beginner doesn't have so much to unlearn. And both novices and experts use Archy the same way. Many designers have said that this is an impossible goal. Archy shows that they were wrong.
I trust that the simple logic of what is said here will be sufficiently convincing on its own. For those who enjoy looking up sources and understanding technical details, especially of relevant portions of human cognitive psychology, I have written another book, The Humane Interface (Addison-Wesley 2000. Call it "THI" for short.)
I will not rewrite that material in this book but I will refer to it freely. If you get a copy in English, try to make sure that it is the sixth printing or later as the book has been considerably updated since its release. It is also available in a number of other languages including Russian, Dutch, German, Japanese, Chinese, Spanish, Italian, and Korean.
Many of the difficulties we have in using computers are so absurd that they are the easy butt of jokes. We all know this and complain continually about our computers and other information-based products. These difficulties are primarily due to bad design of the systems.
User-accessible operating systems are a relic of past interface design errors. Any effort you put into working with the OS (e.g. the desktop) is a waste of your time. The persistence of a visible OS is a fundamental mistake.
One broad solution to the present mess is embodied in an interface called Archy which while as powerful as any of today's software in what it allows you to accomplish with computers, it is easier to learn, more pleasant, and more productive. Using it makes you happier than using existing interfaces. It can be much better because it has allowed itself to be different than present methods even though this will make it feel unfamiliar at first. After a short while, however, using Archy makes using conventional systems feel stupid.
I mentioned a "lack of moral fiber" above. This is not a term of art often encountered in computer science, and I am afraid that some might find such a critical remark offensive. But I can find no other explanation of why so many designers and implementers who should know better use a poor interface widget or method in the product they are working on. Here are some of the excuses I hear for doing sub-standard work:
* it is the easy way out technically
* it avoids confrontation with co-workers
* it would take too long to do it right
* it looks really cool
* it isn't my business to fix the design
* the interface building tool we use does it only this way
* that's the way everybody does it
* it would violate these arbitrary guidelines, or
* they were told to do it that way and feared for their job (or their bonus) if they didn't.
I have had discussions with fellow interaction designers from many companies. They often tell me that they know better (and sometimes they do!), but they trot out the usual platter of excuses.
This is a moral issue. I would not accept such answers from, say, a doctor. Do we interface designers value our integrity less? The happiness and productivity of millions of people around the world depends on the quality of our work. For an increasing segment of the population, the computer is central to their lives. It has gotten to the point where millions of people use the computer all day at work, then come home and blog or surf, read and send emails, and play computer games.
Is my care, concern, and sense of responsibility overblown? I must leave that to you to judge. But how I came to feel as I do may help you make that judgment. It arose from lessons my parents taught, by example, when I was a child. Here is one of them.
In the 1950s, before Martin Luther King had come into prominence and before the great civil rights movement of the 1960s had come together, I lived with my parents and my brother Michael in the town of Brentwood , New York . It is an hour's drive east from New York City , in the middle of the 120-mile lump of sandy terminal moraine dumped there by a retreating glacier that is called " Long Island ". It was not and is not a place of scenic beauty and its one brief fling with ambition came and went at the end of the 19th century when it called itself "The City of Modern Times", built on a utopian vision of a colony where all are artists and thinkers. The city was dedicated to the sciences, the fine arts, and to free love. This history was, as far as I know, never mentioned in the Brentwood school curriculum.
Brentwood 's schools, as I learned from a recent radio report on the city suffer from the same academic malaise they did in my time there.
Brentwood was divided into a western portion, populated by blacks from the south or from New York City , and Puerto Ricans. The term "blacks" would have been politically incorrect at the time. The western area consisted of square block after square block of houses of minimum legal size, with dirt for lawns, and rusting automotive parts repositories for decoration. There were a few scrub pines, and laundry waving in the breeze. We lived in the eastern half, the white half, near the golf club, with lush grass lawns. The streets on our side were lined with tall maples, our address was 64 Van Cedar street . The odd name came from a time when a sequence of streets named for presidents grew to meet a set of streets named for trees. The city fathers, observing that Van Buren now ran directly into Cedar, and not wanting a street to change name in the middle, made the compromise.
My parents, Bill and Frieda, owned a general store across from the railroad station. Our family was well-liked and respected and we got along with everybody. My father was in the Lion's club, and he had a way of solving problems and bridging differences with a touch of humor that made him welcome as a speaker and a participant in civic affairs.
Our personal circle of friends did not tend to include our customers and in-town acquaintances. Our visitors were relatives or "bohemian" artists and musicians, unusual and interesting people of types not encountered in Brentwood . Later I was to realize that our not being Christians might have had something to do with it. My father was a decided atheist. He told me more than once that any belief in God had been beaten out of him by the Rabbis at the yeshiva. Oddly, it seemed to me, among our few local friends were the Catholic priest and a Lutheran minister. I asked my father why these men, whose very profession put them at odds with his views, were our friends. He asked back, "Do you enjoy their company, are they interesting and learned?" I had to admit that they were enjoyable to talk with. And my father admonished me not to hold a prejudice, any more than I'd want them to dislike him because of his beliefs. He also pointed out that whatever he might think of their religious beliefs and organizations, they were honest and good people who thought first of their congregation and not of themselves and, he asked, isn't that the kind of person you'd want for a friend? "But not all ministers..." I began. "Exactly," my father replied. It was his unfaltering message: do not hold stereotypes, take each person on their individual merits. See what that particular person does. The cliché is true: actions speak louder than words.
When the high school needed an English teacher, Bill submitted the name and resume of a friend of ours who had a degree in English and who wrote professionally. No other candidate came close to his qualifications. At about the same time, Bill nominated another friend who had just moved into Brentwood for the Lion's club. Both men were black. This was the 1950s. There were no black students and no black teachers in the high school. There were no black members in the Lion's club.
The repercussions were not slow in coming. My brother and I were soon being called "nigger lover" in school, and were attacked more than usual. The few friends I had became fewer. Some teachers became colder.
Business began to fall off at the store. I was sitting in the store one day after school and a customer came in, she stood tall and looked aloof, and spoke to my father,
"Mr. Carleton," she said "You will understand why we will no longer be shopping here." She called him "Mr. Carleton" as did many others because the store was "Carleton 5 & 10" having been moved from Carleton Avenue in the town in which we had previously lived, Central Islip .
Most people didn't extend even this courtesy, but silently stopped frequenting the store, did not pick up items they had ordered, or ceased paying their bills. We had a family meeting. Bill told us that if he continued to sponsor the Negroes (the politically correct term at the time) that we would have a very poor year. The Christmas season was coming up; it represented a large part of our annual income. There would not be toys for my brother and I for the holidays. We would get along, but there would be no extras, no going out for meals, and we'd have to economize everywhere.
"Frieda and I can't decide this for you," said Bill to Michael and I. "we can go back to the way things were if you wish. Or we can continue supporting our friends, but it's going to be hard." I don't remember my brother and I taking long to decide. The injustice of racial prejudice had long been abundantly clear to us. The evils of McCarthyism, still of recent memory, had taught me that even our own government could forget the principles on which our country was built. Scare tactics, demagoguery, greed, the quest for power, and ignorance all work to undermine and topple our Constitution.
I may have had a strong leaning toward math and sciences, but the civics I learned in school also struck home. To me, the principles of our country made sense, and I was (and am) proud to be an American who stands behind our Constitution -- even when our leaders forget.
And so our family chose to fight for what we believed. One of our religious friends who did not abandon us found it ironic that his church was less righteous than "my atheist friend Bill". You'd think that people would learn, but as I write this in 2004, some churches are as virulently opposed to accepting homosexuality as they were against accepting racial equality.
Things did become hard for my family. We ended up losing the store, we went from driving Packards and Buicks to tiny imports (we had a Renault Dauphine that left us stranded one day by burning itself into a smoking lump). The teasing at school was incessant. Kids would drive by our house, yelling taunts. One night, a shot was fired from a moving car; the .22 bullet lodged in the outside wall of my room: it had hit a stud and did not penetrate inside. The neat, round hole was there for many years.
There is, of course, much more to the story, how we ended up with a store on the Puerto Rican side of town, how the Lion's club split in two as the civil war once split our nation, and how the pharmacist next door to our store, Antonio Hernandez, became a best friend and taught my brother and I safely to make and use rockets, gunpowder, nitroglycerine, throwing knives, and participate in other boyhood delights. Video games don't even come close.
Knowing this background, perhaps you can understand why I find a moral imperative in making good computer interfaces and why I am disgusted with those who continue to foist bad ones on the public. Computers (including devices with embedded computers, such as cell phones, PDAs, and all the rest) are used by hundreds of millions of people. These users suffer not only unnecessary frustration and annoyance, but their life's time is wasted. There is too much unhappiness in the world, and I do not want to be contributing to it. If I could see a way to end war and hunger, I'd rather be doing that. But I don't know how to do either of those, and I do know how to make technology easier to use.
It is not only mental pain that bad interfaces design causes. Research (cited in THI) has shown that most cases of Carpal Tunnel Syndrome, a painful condition that can incapacitate people who use keyboards, is caused by mouse usage rather than by typing. One of the advantages of Archy is that the mouse is almost never used in text-based tasks. This not only helps prevent injury, but makes the interface considerably faster and simpler to use (to the surprise of many who think that use of the mouse is the sine qua non of good interface design). Better interface design can prevent physical human suffering.
Physical pain can also be caused by bad mechanical design. That is dealt with by the discipline of ergonomics, which applies knowledge of human physiology to product design. This is a worthy subject that has been discussed, understood, and taught widely and often well, and will be mentioned only occasionally here. We will primarily deal with problems addressed by cognetics, which applies knowledge of cognitive psychology to product design because it is underutilized, seldom taught, and generally not understood.
BELIEVING IN YOURSELF, WHEN JUSTIFIED
How can you tell, when you hold an opinion different than that of the majority, if you are a self-deluded Don Quixote or a knight with clear vision and bound on a true quest?
I was lucky to have had a teacher who set as firm a basis for intellectual rigor as my parents set for moral strength. L. Roland Genise is a tough, small man who had fought in WWII, ending up in Japan . He made the classic move from teaching Physical Education to teaching Math. But, unlike the many jokes made about ex-phys-ed math teachers, he had come upon a genuine understanding of and passion for the subject. He could reach even the unlikeliest students and pull them into his interest. A half-century later, talking to other alumns, he is the one teacher whom we all remember.
Mr. Genise (as I always addressed him) had a number of teaching techniques aimed at fostering intellectual independence. For example, when you completed a demonstration at the board, he would ask, "Are you sure?" in the exact same tone of voice whether you were right or wrong. He gave no hint at all, and you couldn't "game" him. This was math, answers are either right or wrong and, even more important, the method was right or wrong. He was not upset at an error in calculation (so long as you got them right most of the time). What was important is that you had the idea and the method right, that is, that you *understood* what you were doing and why. And that you could explain it to others.
After studying math with Mr. Genise, you thought of yourself differently. Being right or wrong was no longer a judgment from on high, it was not the teacher's affirmation that counted, but the essential *rightness* of your work. Mr Genise's confidence in you rubbed off and became your confidence in yourself. But it was not a false confidence, because you knew that you could do the proof or solve the problem. As Mr. Genise put it, "That's a good proof. If the world's greatest mathematician came through the door and said it was wrong, you'd still be right!" The message: authority unsupported carries no weight. Make a claim to Mr. Genise, and he'd say, "I'm from Missouri , show me."
Mathematics also teaches humility. If the authority of another counted for little, it meant that your own opinion was worthless unless you could prove your point. I learned the art of egoless argument. To be shown to be wrong was never to be taken personally. If your feeling of self-worth is not caught up in winning arguments, then you can never lose. If you were right and you could show you were right, then you win. If you were wrong, and were shown that you were wrong then you've learned something valuable, and you win.
The appreciation of egoless argument (or the lack of such an understanding in others) has gotten me into trouble more than once. The problem was often compounded by my turning out to be right and probably also by a youthful arrogance that acted like a red flag to inferior teachers. An example that severely tested my faith in my ability to reason correctly arose from a seemingly inconsequential hobby of mine, building and flying model airplanes.
Mr. Rathbone, a science teacher, was explaining how airplanes can sustain themselves in the air. He followed the explanation given in most textbooks: there is a curve on the top of the wing, the bottom of the wing is flat. Think of two air molecules, one going over the longer, curved top and one going under the shorter, straight bottom. For some unexplained reason, the molecules arrive at the back of the wing simultaneously, therefore the one on top must have gone faster. Then, by a principle known as "Bernoulli's Law", the top of the wing experiences a lowered air pressure and the wing is sucked upwards.
Bernoulli's law had been demonstrated in class, as it has been for generations, by blowing over the top a slip of paper and seeing the paper rise, paradoxically, into the stream of air.
I was nodding along with the class when I suddenly noticed that there was a problem. The teacher's explanation could not possibly be right! I raised my hand and when called upon said that if the explanation just given was true, then it would be impossible for an airplane to fly upside down. Also, I had built many model planes with wings that were just flat sheets of balsa, without a curve anywhere. They could fly.
Mr. Rathbone told me that planes could not fly upside down, except briefly so that they didn't seem to lose altitude. I countered that I had seen airplanes fly upside down for extended periods of time at airshows. He said that I had not been observing carefully.
As an avid watcher of airplanes, I knew otherwise. The next day I brought in a model plane I built and showed that the wings were flat and that it could be flown upside down or upright by adjusting the elevators on the back of the airplane before tossing it. I was sent to the principal's office for the offense of "flying a paper airplane in class".
Mr. Rathbone was no longer willing to discuss the topic with me, so I spoke to Mr. Genise, who appreciated the logic of my argument but wisely referred me to the library and advised further research. I read book after book on how airplanes fly. All agreed with Mr. Rathbone. Grownups I spoke to, including a pilot I knew, gave the same explanation.
Nonetheless, I was certain that I was right scientifically (experiment prevails over opinion). My parents had set the moral standard (stick to your guns), and mathematics had given me a model of intellectual rigor (authority can never trump logic). But things can get mighty lonely if you adhere to these codes.
Advanced texts on aerodynamics, then and now, do get it right (in case you were getting worried: our airliners would not fly otherwise). But I did not have access to them then nor would I have been able to understand them if I had. Years later I was to find better ways of explaining how planes fly suitable for school-age readers. One of these articles that has been widely cited appears in [Appendix Coanda].
This incident is one of those that has shaped my life. It gave me the emotional strength to fight for inventions such as the Macintosh and now for Archy. But I am also making a point about reading this book. Recall that the basic reasoning that let me know that Rathbone was wrong was very simple: If lift is caused by the top of the wing being longer than the bottom, then airplanes couldn't fly upside down. But they can and do, so the explanation of lift is wrong. You don't need to know any aerodynamics, just that planes can fly upside down. Similarly, this book does not require specialized computer knowledge for its understanding. Just common sense and the ability to recognize bullshit when you see it. I cannot think of any good way to put that point into more polite language.
In all of human accomplishment, no propositions have come to such universal acceptance as those of mathematics. There is no culture or creed that will find the Pythagorean theorem false, unless its practitioners are being deliberately provocative. The basic tenets of logic (e.g. the first order predicate calculus) serve as the oxygen which all civilized discourse breathes. In spite of the claims of a few doctrinaire academics, there is no "male" and "female" mathematics. A proof that works for Mr. X in Baltimore will also work for Ms. Y in Beijing . The calculator designed in India gives the same results as one designed in Indiana . No exceptions.
How could a youngster who found sectarian differences so upsetting, illogical, and futile not be attracted to the one and only subject that was not susceptible to personal influences or political corruption (no legislature can declare that pi is exactly 22/7 and make it stick). How liberating to know a language and method used everywhere in the world without need for translation. It offered (and still offers) a haven from the more sordid aspects of human endeavor.
It was upsetting, when I reached college, to learn that there were mathematicians who behaved badly and illogically outside of their field. I should have known. When I became a Cub Scout, I read the rule book, put on the uniform, and took it all seriously. Other kids, I observed, put on the uniform and continued to behave as badly as they always had and, naturally, laughed at me when I pointed out the discrepancy.
I quickly left the Scouts, but stuck with the math. The history of mathematics has always embodied a striving for certainty, but it is seldom taught from that point of view. In fact, this part of its history is seldom taught at all, yet its unexpected twists are as colorful and fascinating a tale as one could weave.
Like democracy, the strand of mathematics having to do with certainty started in ancient Greece . Euclid 's great contribution was not geometry, but his approach to mathematics, which relied on a process that started with a minimum collection of "self-evident" postulates that he thought any rational being could agree to, and a set of definitions to assure that all would use the same meanings for their words.
Propositions that can be derived from the postulates via logic are called "theorems" and inherit their truth from the postulates if the logic is correct. It was the structuring of the chain from postulates to theorems that was Euclid 's greatest achievement. The flaw: what is self-evident to one person might not be so to another. Mathematics might be different for different people.
By the 18th century, Immanuel Kant built a leg of his philosophy by using geometry as an example of a necessary truth. This was just in time to have his philosophical edifice undercut by the discovery of non-Euclidean geometry. There are many possible geometries, and some proceeded from turning a long-held "self-evident" axiom on its head. It had taken about two thousand years, but mathematical truth became liberated from any particular set of convictions about their modeling the "real" world. Any useful and consistent set of axioms was as acceptable as any other. This made it harder to see how mathematics might connect to the physical world, but no longer was the acceptance of an axiom subjective. Many fascinating questions about choices of axioms arose, and are still actively being pursued, but that is a separate topic.
In 1900 David Hilbert proposed that it might be possible to generate and prove all theorems mechanically (we would now say "with a computer program") from the proper set of axioms. After all, each of the steps in a proof is just manipulation of symbols according to straightforward rules. The process was underway in the work of Russell and Whitehead.
It would have been lovely to be able to rid math of possible human error by this means. But, in the 1930s, Kurt Gödel unexpectedly proved that what Hilbert proposed was not possible. Given any particular set of axioms (of at least enough scope to handle arithmetic) there were true theorems that could not be proved. In spite of some odd claims one reads in the popular literature, Gödel's work didn't destroy mathematics or change even a single theorem. It affirms that math is open-ended in the sense that we cannot find one "system" that will handle all of our mathematical needs.
My search for a methodology that would tend to keep me from self-delusion (not exactly a unique thing for a philosopher to attempt) kept my studies focused on mathematics up into graduate school. The same search drove others into philosophy, religion, mysticism, or -- most commonly -- to abandon the attempt in favor of just getting on with things.
The link from mathematics back to the physical world, its applicability, especially given the history outlined here, can become difficult to justify. To Euclid , axioms were obviously true statements about the world. But now axioms are understood as both arbitrary and abstract (though with some restrictions, for example, within a system axioms may not contradict one another). That mathematics, pure and august, so often and well describes the world has upset many scientists and philosophers. The most well-known statement of this position being that of Nobel Laureate Eugene Wigner in his essay, "The unreasonable effectiveness of mathematics in the natural sciences". A similar discussion came from the noted computer scientist Richard Hamming. If they are right we have nothing stronger than a mystery linking the methods of mathematics to practical applications. But they are wrong, and my answer is reprinted in [Appendix: Reasonable Effectiveness].
There is a bottom line here: I may have gone about it in an extreme fashion, but being aware of how easily we fall into believing our own hyperbole has helped guide me and the projects I've worked on along practical paths. Not theoretical paths, but workable, pragmatic, and profitable ones.
The second line of defense is the scientific method. xxx
OUR MAIN HURDLE TO COMMUNICATION
The only difficulty some readers may find is in overcoming their familiarity with the status quo. Humans have a strong preference for the familiar and we become comfortable with some things not because they are truly convenient and wonderful, but because we have become used to them. "I can see the problem Raskin is talking about," you might think from time to time, "but it's something I can live with." You'd be correct, there are many undesirable things that we can tolerate. But why should we if we don't have to? Beware the "death by a thousand clicks," no one of which is fatal by itself but which taken together make for the dreadful computer interfaces we now endure.
I cannot put the warning more clearly than did Thomas Jefferson, when he wrote: "All Experience hath shewn, that Mankind are more disposed to suffer, while Evils are sufferable, than to right themselves by abolishing the Forms to which they are accustomed."
Jefferson knew that we tend to be slow to realize that long-established ways are no longer serving us. But when the present practices are finally presented so that the Evils become self-evident, we are moved to change, and a revolution is fomented.
CHAPTER: SOME PROBLEMS, EXPOSED
A very readable and accurate exposure (it is more than a mere critique) of the absurd failings of Microsoft Word, appeared as part of an article by Louis Menand in the New Yorker Magazine ( 6 Oct 2003 ). What makes it significant is not so much its content (much the same objections have been posted elsewhere), but the fact that it appeared in the New Yorker. To enjoy the article you'd have had to have been a victim of Word's predatory power, this means that the editors expected that their readers had already suffered the problems Menand cited. It would be hard to find a more crushing condemnation of Microsoft Windows and Word.
Menand's anger is palpable. He begins by comparing using a computer instead of a typewriter: "The potential for rage and heartbreak is even greater, in fact, for the very technology that is supposed to speed the task of information-processing is now your most insidious foe.
"First of all, it is time to speak some truth to power in this country: Microsoft Word is a terrible program . Its terribleness is of a piece with the terribleness of Windows generally, a system so overloaded with icons, menus, buttons, and incomprehensible Help windows that performing almost any function means entering a treacherous wilderness of pop-ups posing alternatives of terrifying starkness: Accept/Decline/Cancel; Logoff/Shut Down/Restart; and the mysterious Do Not Show This Warning Again. You often feel that you're not ready to make a decision so unalterable; but when you try to make the window go away your machine emits an angry beep. You double-click. You triple-click. Beep beep beep beep beep . You are being held for a fool by a chip.
"When, in the old days, you hit the wrong key on your typewriter, you got one wrong character. Strike the wrong keys in Word and you are suddenly writing in Norwegian Bokmal ( Bokmal ?). And you have no idea how you got there; you can spend the rest of the night trying to get out."
Menand missed more fundamental flaws in the software, having come to unconsciously accept many of Windows' details, especially those that are common across programs -- for example, he might be surprised to learn that using windows (those rectangles that we summon and dismiss) is itself a mistake. Like most of us, he probably assumes that they are a necessary part of computer usage.
For example, an obvious problem with current interfaces (this applies to graphics packages as well as text handling) is that you are always at risk for losing a portion of your work. In giving presentations I often ask if this problem has happened to members of the audience. All, or all but one or two, raise their hands, so there's a very good chance it's happened to you.
Usually you lose only a few lines or a paragraph, which is bad enough, but the other day Word lost an entire document: I was writing quickly. By habit I use the Save command (Ctrl-S) every few lines so that I do not lose my work in case of a power failure or error on my part. As soon as I issue the Save, I immediately return to my furiously typing. Except this time I had missed the S by one key and typed the Select All command (Ctrl-A). One-off typing is a not-uncommon error and would be of no consequence here except for an absurd rule: typing replaces whatever is selected. This means that my entire text was erased. I am an experienced typist and don't watch the screen all that much, especially when working from notes. After a few words of typing I habitually did a Save. Only then did I realize that all I had left was the last few words of typing. The rest was gone.
It is more common that users (including myself) catch the error in time to Undo it. But the question is: why should the system have been designed to put your work at risk at all? Even if you could always catch the mistake, why should the system be designed to lead you into making the mistake in the first place. This design decision was originally made to save one keystroke on certain occasions, namely the occasion where you were making a selection with the intention of erasing it and retyping something in its place. In return for occasionally saving that one keystroke, people lose work every day, and it takes a lot more keystrokes to recover, if you can recover, from the error.
This design error is somewhat typical in that it penalizes the better typists, in this case, those who do not have to watch the screen as they work. Note that I did not say that "I lost an entire document" but that "Word" lost it. We must never blame ourselves when an interface takes advantage of a normal human characteristic to cause an error.
Another way to look at it is that erasure of the selection is a "side effect" of typing. The normal way to erase a selection is to use the "Backspace" key. But in this one case, tapping any typing key will erase the selection. It is an obviously wrong interface design decision.
The solution is straightforward: do not have typing replace the selection. Ever. If you want to delete something, then explicitly delete it with the Backspace key, the same key that you use to delete typing. If you wish to replace a block of text with something else, then select the block, delete it, and type away.
Along these same lines, there is clearly no reason to have a "trash basket" or whatever kind of receptacle the system provides to discard files. The consistent, simple, thing to do is to be able to use the Backspace key to delete anything that is selected. It is much easier to learn a system when there is only one way to accomplish any one a conceptually identical set of tasks.
We must never blame ourselves when an interface takes advantage of a normal human characteristic to cause an error.
There are two elementary and fundamental ideas that have just been discussed. The first is that
When a command requires a selection on which to operate, always make the selection first, then issue the command.
This is by no means a new principle in interface design (where it is sometimes called the "noun-verb" principle or "object-action") however, given that its benefits have been known for so long it is startling how often it is violated. Please see THI p 59 ff.
The second elementary principle is to always do the same task the same way. This idea seems too trivial to mention. After all, who would want a user to have to learn a second perfectly good method for doing something after they have already learned a first good method? And who would want to spend the resources implementing additional methods, or documenting them, or requiring the service center to explain them?
In THI, I gave this principle the tongue-in-cheek name of the "principle of monotony". To make something monotonous, in common parlance, means to make it dull and unexciting. But, when it comes to interfaces, isn't that just what you want? You don't want your attention called to the interface, but left at what you are working on. The only good interfaces are those that do not call attention to themselves, that do not get articles written about them in the New Yorker.
There is some legitimate weight that can be given to marketing's desire to make an interface "flashy". The designers' task in that case is to make sure that the sizzle does not ruin the product.
A prime example of a good concept gone haywire is how the mouse is used in standard GUIs. the term "mouse" is often used in a generic sense to refer to any of a number of common pointing devices, such as trackballs and touchpads. Appropriate uses of the mouse primarily include those where the mouse is used to point to and delineate graphic objects.
In practice, the mouse is most often used to select and manipulate text, and to position the cursor for typing. Even if a user's application is a graphic one, the mouse is still used in text to assign file names, in filling out forms, in sending and receiving graphics, in creating and editing textual elements within the graphics, and in using the web.
In that we are about to show that the mouse is remarkably slow in doing these tasks, it is ironic that the mouse was chosen because of its speed. As the mouse's inventor, Doug Englebart, said of his study of GIDs, "We were looking for the best -- the most efficient -- device. We approached NASA in 1966, and said, 'let's test them,' and determine the answer once-and-for-all. With NASA funding, the team developed a set of simple tasks, and timed a group of volunteers in doing those tasks with the various devices. For example, the computer would generate an object in a random position on the screen, and a cursor somewhere else. We timed how long it took the users to move the cursor to the object. It quickly became clear that the mouse out-performed all the others." (www.superkids.com/aweb/pages/features/mouse/mouse.html)
Because pointing is a very frequent operation, Englebart's insistence that it be done in minimal time is entirely appropriate. We spend about 1/3 of our time at the computer manipulating the mouse, depending somewhat on the tasks we use the computer for (Homan, M. M. and Armstrong T. J. Evaluation of Three Methodologies for Assessing Work Activity During Computer Use. AIHA Journal (64) Jan/Feb 2003 p 48. Pooled data from figures 4 and 6).
To see why a mouse or other GID is inherently slow, consider the steps you must take in order to point with it. It is quite an amazing process. Say that your hands are on the keyboard and you are gazing at the display. You notice an object which you'd like to point to (say, in order to type there). Your first step is to visually search for and find the cursor's present location. Without that knowledge you don't know in what direction you will have to move the cursor. Sometimes you even have to "wiggle" the cursor to make it move so that you can locate it visually. As you start moving the cursor toward its target, you have to search with your eyes to see exactly where the target is (especially if it is a particular place in text). Until the cursor and target are close enough to both be seen together, you repeat this process until you've brought the cursor to where you want it, you tap the mouse button, and you move your hands back to the keyboard to type what you wanted to insert.
As experiment has shown (Cite THI and Card, Moran, and Newell) the time spent in motion for each mouse move as described is, on average, about 2.1 seconds.
While Englebart determined that the mouse is faster in graphics situations than the other GIDs he studied, it turns out that there are methods useful in text-based situations (and in situations which are often done graphically but which can be done more efficiently if redesigned to use text) which are much faster. For example, a technique called "Leap", under the same conditions as given for the mouse timing, allows you to point in an average of 0.9 seconds. This is more than twice as fast as a mouse. (Cite THI)
The difference is analogous to science fiction's " Warp Drive " (to use Star Trek nomenclature). With a mouse, you have to get from here to there by passing through all the space between them. With Leap, you can "go faster than light" and get there directly through hyperspace.
As we did in understanding how we use a mouse, consider the many fewer steps you must take in order to Leap. Say that your hands are on the keyboard and you are gazing at the display. You notice an object which you'd like to point to (say, in order to type there). You press and hold a Leap key and while holding it type the character on which you want the cursor to be placed. You do not have to look back at where the cursor is. Then type whatever characters follow it until the cursor appears on your desired character; release the Leap key.
No time is spent hunting back and forth with your eyes, no time is spent moving your hand to the mouse, and the greatest part of the mouse-use time, which is spent moving the mouse itself (1.1 of the 2.1 seconds) is reduced to 0.
As noted, we spend about 1/3 of our time using the computer making mouse moves. This amounts to 20 minutes of every hour. If Leap was used instead of a mouse, the time spent pointing would drop to a bit under 9 minutes. That is a time saving of 11 minutes per hour. If this one straightforward change were made, the productivity of products such as Word would increase by about 20%. There aren't many situations where double-digit productivity increases can be had.
SIDEBAR: HOW THE MOUSE GOT INTO THE MAC
The mouse itself was invented by Douglas Englebart at the Stanford Research Institute (SRI) about 1963-64. It is one of a number of graphic input devices (GIDs) that allow you to indicate, by means of two-dimensional motion, a location on a display. Other examples are touch-screens, tablets, trackballs, joysticks, and eye- or head-tracking devices. Often, when people speak of "a mouse" they are referring to any GID.
Prior to the Mac, most personal computers had means for connecting an optional joystick or other GID. A little software, mostly in the game category, was designed to work with a GID. The Macintosh was different: from the beginning, I included graphics as an essential element of computer use and of interface design. The Mac was not only to have a GID, but the GID was to be mandatory and integrated into the basic methods by which the Mac was to be used. This is something I had wanted to do at least since my "Quick Draw Graphics System" was published in 1967.
At the time (and for many years afterward) the standard approach for computers was to use "hardware character generators" used to display text and to have graphics -- if graphics were to be had at all -- as a separate "output" mode. I also saw the need for communicating graphics to the computer: In the winter of 1965-66 I built a GID, which I used primarily to input musical notation to the computer. The Xerox Palo Alto Research Center (PARC), founded in 1971, made considerable use of the mouse and did much to popularize it among researchers and computer scientists. I spent many enjoyable hours with friends at PARC starting in 1973. At the time I was a professor at the University of California and a visiting scholar at the Stanford Artificial Intelligence Laboratory -- which was a short bike-ride from PARC. The PARC/Stanford nexus was definitely the right place to be for someone interested in human factors and computers. But human-computer interaction was a field that did not exist then. The field of computing was about to explode: the first real personal computers (with switch-and-light input and output) were introduced in 1975. My friends (especially Douglas Wyatt) and I built a few of these primitive kits. I met Steve Jobs and Steve Wozniak in their now-legendary garage in 1976 and they gave me an Apple I kit so that I could write about it. The kit was incomplete (though in a way that was pretty standard at the time) in that it didn't include the keyboard or some major power supply components, and the buyer was expected to go to used electronics stores, find and modify the parts needed to complete it. If you didn't know your basic electronics, you were out of luck.
Wozniak's electronic design for the Apple I was a step ahead of the industry, the Apple II was even better as Woz had a talent for clean simple design and getting the most out of the parts he chose. I joined Apple in January, 1978, as their 31st employee. But while the company was excited about the Apple II product line at the time, I saw that entire family of computers as primitive and backwards-looking. By 1979 I had started writing down the specifications for a computer I named "Macintosh". The specifications did not begin with hardware, or even software, but by considering what people would do with it. Then I asked myself how they would accomplish these tasks, what steps they would have to take to get the job done. In other words, I started the design from the interface out.
An essential insight was that everything you see on a display is a graphic: after all, letters are nothing special, just particularly shaped graphics. I wanted to be able to make characters in different sizes, styles, and alphabets. I threw out the idea of a graphics "mode" and specified an architecture that was all-graphic, all the time. To be able to point to and manipulate graphics I specified that the Mac had to have a GID.
The use of the mouse became the sine qua non of the GUI. It was the visible manifestation of how different the Mac was from its competitors. But it also became a trap for the designers who took over the Mac when I left Apple. It was clear that the mouse was be a major Macintosh marketing element. As such, we learned about its capabilities and limites by trying to use it to do as many tasks as possible, whether it was suitable or not. It became clear that the mouse was not the best tool. I started to develop a superior set of methods (called "Lex" and "Rex") but did not have the chance to develop them. Later, at Information Appliance Inc. I found a still better solution.
In the meanwhile the mouseheads at Apple took an evangelistic stance and decreed that the mouse would be used for nearly everything. No experiments were done to see whether this made sense, and human factors on the Mac project mostly degenerated into whatever the programmers thought felt or looked good. They did a lot of good work, and the lead programmer (Bill Atkinson) had been my student for years and had absorbed a lot of human factors knowledge -- and he was very smart. But they ignored even the little research that was then available, were often forced to make bad decisions when Steve Jobs insisted on this or that detail, and made a lot of elementary errors that persist in the Mac's interface (and in exacerbated form in Windows) to this day.
END OF SIDEBAR
If one stops and asks, when and how should the mouse be used in an interface, the obvious answer is this: when it makes the user happier and more productive than not using a mouse would.
intro | Archy | Summary | Moral Values | Interfaces and Cognetics | Believe in Yourself | Roots of Certainty | Second Line of Defense | Problems Exposed | Hurdles to Communication |Summary | Infested with Mice
Sidebar: How the Mouse got into the Mac