Hide full article
While at the 1998 Association for Computing Machinery (ACM) Conference on Computer Supported Cooperative Work a few weeks ago here in Seattle, I had the opportunity to attend Douglas Engelbart's Turing Award Lecture. I was struck by how closely our computing today mirrors Engelbart's demonstrations in the late 1960s and at how seriously we have missed the major thrust of his goals.
<http://www.acm.org/sigchi/cscw98/>
Who Is Douglas Engelbart? Douglas Engelbart is best known for inventing the mouse, but he's done much more than that. We tend to credit Apple for the graphical interface popularized by the Macintosh, although many also spread the credit to Xerox PARC for inspiring Steve Jobs and others from Apple. Fewer people realize that much of what Xerox showed Apple - a mouse-driven, graphical windowing system - was part of Engelbart's pioneering work from more than ten years before. In the late 1960s, while working at SRI (now a non-profit research organization, then the Stanford Research Institute), Engelbart and his lab came up with NLS (oNLine System), which was first demonstrated at the 1968 Fall Joint Computer Conference. After Engelbart left SRI, many of the people on his team went to Xerox PARC to carry on the work they'd started with Engelbart.
<http://www.bootstrap.org/dce-bio.htm>
The presenter who introduced Engelbart's lecture played 6 minutes of the original 90-minute NLS presentation, showing such firsts as the mouse, multiple windows, 2-dimensional display editing, hypertext, shared-screen collaboration, videoconferencing, and integrated hypermedia email. Other firsts for Engelbart include in-file object addressing and linking, outline processing, cross-file editing, hypermedia publishing, and context-sensitive help.
Engelbart saw his many ideas and inventions as technical ends to a goal that also required progress in media, language, customs, knowledge, skills, and procedures. Back in the 1950s, Engelbart realized that the rate of change in the world was increasing radically, and the complexity and urgency of the world's problems were increasing along the same lines. On a purely elemental level, he felt that the survival of the human race hinged on our ability to improve - to evolve if you will - at a rate sufficient to keep up. Since biological evolution works on a long time frame, the evolution in question would have to come with the tools we invent and use, the customs and communities we form, and the ways in which we work together.
The man doesn't think small, and neither should we.
What Are We Missing? There's no question that the technical ideas Douglas Englebart showed back in 1968 are finally becoming commonplace. Watching that 1968 demonstration was a bit depressing, since I couldn't help but wonder why it took the industry 30 years to achieve on a large scale what Englebart had shown on a small scale. There's no question that technology had some catching up to do - for instance, his lab had to build its own CRT display to support NLS, at a cost of $80,000 in 1968 dollars.
It's easy to think that Engelbart's work led directly to the development of easy-to-use, single-user systems like the Macintosh. But, at least as the Macintosh existed in the early days, it was almost antithetical to some of Engelbart's core ideas. First, single-user, isolated systems did not lend themselves to collaboration. Engelbart's lab was the second site on the ARPANET, and he was thrilled with the idea of using networked computers to foster cooperation and collaboration. Second, the mantra of the Macintosh was ease-of-use, and although no one, including Engelbart, would argue that systems should be unnecessarily hard, I don't believe he's a fan of simplicity for simplicity's sake.
The thrust of Englebart's work is directed toward augmenting the human intellect, not popularizing computer technology. He feared that as technology improved at a rate far surpassing improvements in non-technical fields, we would use it to automate intellect, rather than augment it. In short, merely automating simple tasks, though useful, doesn't lend itself to collaboration and solving the big problems.
Engelbart suggested that we think for a moment about bicycles - they're truly odd devices, requiring incredible balancing and coordination skills to ride. No one is born knowing how to ride a bicycle. We start with tricycles that let us practice some of the necessary skills without worrying about balance. Then we graduate to normal bikes with training wheels, and finally to real bicycles. Millions of people rely on bicycles for transportation, and bicycle racers perform astonishing feats on them.
But learning to ride a bike is hard, and even after we've learned, it's a dicey business fraught with potholes, dogs, cars, and even mere inattention, any of which can cause a loss of balance. Wouldn't it seem to be easier to stick with tricycles? Sure, a few tricycles are made for adults, but for most of us a two-wheeled bicycle is enough better, faster, and smaller that it's worth the learning curve.
We put an incredible amount of effort and mental energy into making software and hardware easier to use, and that's a worthwhile goal. But, just as a vast amount of development goes into making bicycles faster and more capable (think clipless pedals, shocks on mountain bikes, and aerodynamic handlebars that make bikes more efficient, if harder to ride), shouldn't we also concentrate on augmenting the capabilities of sophisticated computer users? And, shouldn't we attempt to create a learning situation where users can graduate from a simple system to a more complex one, rather than trying to serve everyone's needs in a single system? Microsoft tried that with Word 4.0's short menus (which hid more advanced features until you switched to full menus). Short menus flopped because users hated being told they were too dumb to handle full menus, it was too hard to figure out how to switch into full menus, and commands for some basic tasks were available only on the full menus. Microsoft abandoned short menus quickly, and in so doing, perhaps threw the baby out with the virtual bath water.
One interesting gap in the realization of Engelbart's research is the chord keyboard. He never meant the mouse to be used with a normal keyboard, for the obvious reason that you can't type and mouse at the same time, thus limiting your ability to enter and manipulate different types of information. His intention was that you'd use a chord keyboard with one hand and a mouse with the other. I suspect that heavy text entry environments would be more likely to have a pair of chord keyboards so you could double your speed when typing, then push one out of the way for access to the mouse for editing. Chord keyboards never caught on, despite their utility because they require learning. It's not hard, but it's a lot harder than the less-efficient keyboard most of us use. You can still buy chord keyboards from Infogrip - I know a few people who use them, mostly because of hand problems.
<http://www.infogrip.com/>
Human/Organizational Aspects -- We've not only missed a few of the technical aspects of Douglas Engelbart's vision, we've also missed many of the non-technical aspects. Engelbart believes our tools and non-technical features such as language, customs, skills, and so on evolve together slowly over time. For instance, consider the skills required to drive on a crowded freeway, a situation that didn't exist 100 years ago. As our technology has improved, so have our coordination and awareness skills. But, technologies can improve much faster than our skills (many can drive cars, but few can fly helicopters), and we often experience social conflict when cultural customs run counter to technological advances, such as birth control pills and nuclear weapons.
Engelbart's solution for this conundrum is concentration on so-called "improvement activities." In his view, organizations and groups of all kinds have (or should have) three basic activities, as follows:
- A activities which serve the customer or end user
- B activities which improve the product cycle and A activities in general
- C activities which improve quality and reduce the time of the B improvement cycle
In essence, A serves the customer, B tries to help A do an increasingly better job, and C in turn attempts to improve the work done by B.
Unfortunately, the marketplace is a lousy environment to foster exploration into improvement. Most companies focus almost all their attention on A, with a little on B, and almost none on C. The most interesting example of this that I've seen is that companies that produce productivity tools seldom use them any more efficiently or productively than the general public. At Microsoft, for instance, the description - indeed, the philosophy - of being forced to use specific Microsoft products is "eating our own dog food." It's not a pretty image.
Wouldn't you think a large software company would try to knock off two birds with one stone by creating products that radically improve the productivity of its own employees, with the understanding that doing so would result in products that would better meet the needs of other customers? Yet it seems uncommon for large companies to consider the needs or desires of their employees as in any way typical of the needs and desires of their customers. As a result, these companies tend to ignore the feedback that is both closest and easiest to collect.
The other obvious obstacle for Engelbart's organizational solution in a capitalistic society is that companies see no reason to work together, even when collaboration would benefit both. People engaged in C-level activities must instead form their own communities to share ideas for improving the improvement process, without direct responsibility to a company's competitive situation (because competition inherently stands in the way of cooperation). Frankly, getting past financial navel-gazing is difficult for many companies, though a number of large and well-known organizations have joined Engelbart's Bootstrap Alliance, which is dedicated to exploring the development of organizations that can maneuver successfully into the increasingly complex future. Members include the likes of Sun Microsystems, ETS (Educational Testing Service), NTT, U.S. General Services Administration, the CIA, IBM, Hewlett-Packard, and the National Science Foundation.
<http://www.bootstrap.org/alliance/>
Will Douglas Englebart Succeed? Listening to Engelbart in person is persuasive, undoubtedly much more so than my retelling. He's one of those speakers whom you listen to, thinking, "He's right. He's completely right." But history is full of people who have been right. In fact, my final question to Engelbart after his talk was, "Do you feel like Cassandra?" to which he replied with a small laugh and a soft "Sometimes." (In Greek legend, Apollo cursed Cassandra with the ability to foretell the future, but nobody would believe her.)
Look at it this way: Engelbart's statement of the problem we face, that the rate of change in the world is constantly increasing, is hard to dispute. It's something I've worried about for some years now as well, mostly because I fear that our individual abilities to deal with this constant change are breaking down. Despite my side interests in communities and a long history of observing and working with Internet groups, I never made the conceptual leap Engelbart did, that the only solution is to develop systems for continually improving our collective ability to handle change.
Put another way, the cascade reaction of change travels with the electronic winds. A change anywhere in the world can encourage some other change elsewhere in the world. Although we're agents of change, we're already losing the capacity to deal with changes we've fostered. Just look at the calls to return to "traditional values" and the popularity of nostalgia movements. Whatever your opinion of these movements, their mere existence shows our discomfort with the ways we have changed society. But you can neither force nor coax the genie back into the bottle.
So, let's agree with Engelbart's statement of the problem. There's also no denying that his technical vision was on target. Perhaps we never ended up using those chord keyboards, but Engelbart's track record is unsurpassed. It may have taken 30 years, but he's been proven right in the technical field.
We're left then with his ideas about fostering improvement activities. They may be difficult to accept, especially for competitive companies that can't see beyond the next quarterly report. Without trying these ideas though, will we be able to keep up with the changes we've set in motion? It's as though we keep walking further out into the ocean only to be knocked down by ever-larger waves of change, knowing full well the waters will soon close over our heads. Perhaps we should instead focus on building a boat, even if that means going back to shore for a little while. We must learn to ride on top of the waves.
Almost exactly five years ago, I attended another conference in Seattle - Hypertext '93 - where I heard an address by Ted Nelson, the father of hypertext. I noted with some sadness in "Xanadu Light" in TidBITS-204 that Nelson was treated with "a complicated mix of awe and devotion combined with an almost cruel pity and ridicule" because of failing to ship a product.
<http://db.tidbits.com/article/02326>
Well, Douglas Engelbart has not only shipped a product, he shipped an entire computing paradigm, so I say we give his non-technical ideas a chance. I just hope we have another 30 years for them to catch on. In the meantime, you can read more about Douglas Engelbart and his ideas at the Bootstrap Institute Web site.
<http://www.bootstrap.org/>
