Interactions

An enduring contribution can take different forms. It can be a brick, soon covered by others yet a lasting part of a field’s foundation. Alternatively, it can be a feature that remains a visible inspiration.

Eminent scientists and engineers have offered insights into making an impact.

Inspiration

“If you want to predict the future, invent it,” said Alan Kay. In the 1960s, Kay conceived of the Dynabook. His work was widely read and had a lasting impact: 50 years later, tablets are realizing his vision. Vannevar Bush’s 1946 essay “As We May Think” has been aptly termed science fiction—an outline of an impossible optomechanical system called the Memex—but it inspired computer scientists who effectively realized his vision half a century later in a different medium: today’s dynamic Web.

Kay and his colleagues took a significant step toward the Dynabook by developing the Xerox Alto. Bush attempted to build a prototype Memex. However, generations of semiconductor engineers and computer scientists were needed to reach their goals—introducing a second factor.

Perspiration

A century ago, the celebrated inventor Thomas Edison captured the balance, proclaiming that genius was “1% inspiration, 99% perspiration.” He recognized the effort involved in inventing the future, but by attributing output to input this way he overlooked the fact that not all clever, industrious people thrive. Circumstances of birth affect a person’s odds of contributing; even among those of us raised in favorable settings, many creative, hard-working people have a tough time. More is needed.

Divination

A century before Edison, Louis Pasteur observed that “chance favors the prepared mind.” This elegantly acknowledges the significance of perspiration and inspiration while recognizing the role of luck.

Lasting impact awards

On a less exalted level, several computer science conferences have initiated awards for previously published papers that remain influential. My 1988 paper on challenges in developing technology to support groups received the first CSCW Lasting Impact Award at CSCW 2014 in Baltimore. The remainder of this essay examines how that paper came to be written and why it succeeded. Avoiding false modesty, I estimate that the impact was roughly 1% inspiration, 25% perspiration, and 75% a fortunate roll of the dice. (If you prefer 100% totals, reduce any of the estimates by 1%.)

Seeing how one career developed might help a young person, although 30 or 40 years ago I would have avoided considering the role of luck. Like all students in denial about the influence of factors over which they have no control, I would have been anxious thinking that intelligence and hard work would not guarantee success. But those who move past Kay and Edison to Pasteur can use help defining a path toward a prepared mind.

The origin of my paper

“Why CSCW applications fail: Problems in the design and evaluation of organizational interfaces,” was an unusual paper. It didn’t build on prior literature. It included no system-building, no usability study, no formal experiment, and no quantitative data. The qualitative data was not coded. The paper didn’t build on theory. Why was it written? What did it say?

The awkward title reflected the novelty, in 1988, of software designed to support groups. Only at CSCW‘88 did I first encounter the term groupware, more accessible than CSCW applications or Tom Malone’s organizational interfaces. Individual productivity tools—spreadsheets and word processors— were commercially successful in 1988. Email was used by some students and computer scientists, but only a relatively small community of researchers and developers worked on group support applications.

I had worked as a computer programmer in the late 1970s, before grad school. In 1983 I left a cognitive psychology postdoc to resume building things. Minicomputer companies were thriving: Digital Equipment Corporation, Data General, Wang Labs (my employer), and others. “Office information systems” were much less expensive, and less powerful, than mainframes. They were designed to support groups and were delivered with spreadsheets and word processing. We envisioned new “killer apps” that would support the millions of small groups out there. We built several such apps and features. One after another, they failed in the marketplace. Why was group support so hard to get right?

Parenthetically, I also worked on enhancements to individual productivity tools. There I encountered another challenge: Existing software development practices were a terrible fit for producing interactive software to be used by non-engineers.

Writing the paper

In 1986 I quit and spent the summer reflecting on our experiences. I wrote a first draft. My colleague Carrie Ehrlich and I also wrote a CHI’87 paper about fitting usability into software development. A cognitive psychologist, Carrie worked in a small research group in the marketing division. She had a perspective I lacked: Her father had been a tech company executive. She explained organizations to me and changed my life. The 1988 paper wouldn’t have been written without her influence. It was chance that I met Carrie, and partly chance that I worked on a string of group support features and applications, but I was open to learning from them.

In the fall, I arrived in Austin, Texas to work for the consortium MCC. The first CSCW conference was being organized there. “What is CSCW?” I asked. “Computer Supported Cooperative Work—it was founded by Irene Greif,” someone said. I attended and knew my work belonged there. The field coalesced around Irene’s book Computer Supported Cooperative Work, a collection of seminal papers that were difficult to find in the pre-digital era. Irene’s lasting impact far exceeds that of any single paper. I may well have had little impact at all without the foundation she was putting into place.

My research at MCC built on the two papers drafted that summer: (i) understanding group support, and (ii) understanding development practices for building interactive software. MCC, like Wang and all the minicomputer companies, is now gone. Wedded to AI platforms that also disappeared, MCC disappointed the consortium owners, but it was a great place for young researchers. I began a productive partnership there with Steve Poltrock, another cognitive psychologist, which continues to this day. We were informally trained in ethnographic methods by Ed Hutchins and in social science by Karen Holtzblatt, then a Digital employee starting to develop Contextual Design. MCC gave me the resources to refine the paper and attend the conference.

The theme: Challenges in design and development

Why weren’t automated meeting scheduling features used? Why weren’t speech and natural language features adopted? Why didn’t distributed expertise location and project management applications thrive? The paper used examples to illustrate three factors contributing to our disappointments:

1. Political economy of effort. Consider a project management application that requires individual contributors to update their status. The manager is the direct beneficiary. Everyone else must do more work. If individual contributors who see no benefit do not participate, it fails. This pattern appeared repeatedly: An application or feature required more work of people who perceived no benefit. Ironically, most effort often went into the interface for the beneficiary.
   
   Was this well known? Friends and colleagues knew of nothing published. I found nothing relevant in the Boston Public Library. Later, I concluded that it was a relatively new phenomenon, tied to the declining cost of computing. Mainframe computers were so expensive that use was generally an enterprise mandate. At the group level, mandated use of productivity applications was uncommon.


2. Managers decide what to build, buy, and even what to research. Managers with good intuition for individual productivity tools often made poor decisions about group support software. For example, audio annotation as a word processor feature appealed to managers who used Dictaphones and couldn’t type. But audio is harder to browse, understand, and reuse. We built it, no one came.


3. You can bring people into a lab, have them use a new word processor for an hour, and learn something. You can’t bring six people into a lab and ask them to simulate office work for an hour. This may seem obvious, but most HCI people back then, including me, had been trained to do formal controlled lab experiments. We were scientists!

The paper used features and applications on which I had worked to illustrate these points.

Listening to friends

The first draft emphasized the role of managers. I still consider that to be the most pernicious factor, having observed billions of dollars poured into resource black holes over decades. But my friend Don Gentner advised me to emphasize the disparity between those who do work and those who benefit. Don was right. Academia isn’t strongly hierarchical and doesn’t resonate to management issues. Academics were not my intended audience and few attended CSCW’88, but those who did were influential. Criticizing managers is rarely a winning strategy, anyway.

Limited expectations

Prior to the web and digital libraries, only people who attended a conference had access to proceedings. I wanted to get word out to the small community of groupware developers at Wang Labs, Digital Equipment Corporation, IBM, and elsewhere, so they could avoid beating their heads against the walls we had. Most CSCW 1988 attendees were from industry. I assumed they would tell their colleagues, we would absorb the points, and in a few months everyone would have moved on.

It didn’t matter if I had missed relevant published literature: The community needed the information! Conferences weren’t archival. The point was to avoid more failed applications, not to discover something new under the sun.

The impact

At the CSCW 2014 ceremony for my paper, Tom Finholt and Steve Poltrock analyzed the citation pattern over a quarter century, showing a steady growth and spread of the paper’s influence. I had been wrong—the three points had not been quickly absorbed. They remain applicable. A manager’s desire for a project dashboard can motivate an internal enterprise wiki, but individual contributors might use a wiki for their own purposes, not to update status. Managers still funnel billions of dollars into black holes. Myriad lab studies are published in which groups of three or four students are asked to pretend to be a workgroup.

All my subsequent jobs were due to that work. Danes who heard me present it invited me to spend two productive years in Aarhus. A social informatics group at UC Irvine recruited me, after which a Microsoft team building group support prototypes hired me. Visiting professorships and consulting jobs stemmed from that paper and my consequent reputation as a CSCW researcher.

Why the impact?

The analysis resonated with people’s experience; it seemed obvious once you heard it. But other factors were critical to its strong reception. The paper surfaced at precisely the right moment. In 1984 my colleagues and I were on the bleeding edge, but by 1988 client-server architectures and networking were spreading. More developers worked on supporting group activities. The numbers of developers focused on group support had risen from handfuls in 1984 to hundreds in 1988, with thousands on the way.

I was fortunate that the CSCW’88 program chair was Lucy Suchman. Her interest in introducing more qualitative and participatory work undoubtedly helped my paper get in despite its lack of literature citation, system-building, usability study, formal experiment, quantitative data, and theory. In subsequent years, such papers were not accepted.

The most significant break was that the paper was scheduled early in a single-track conference that attracted a large, curious crowd. Several speakers referred back to it and Don Norman called it out in his closing keynote.

Finally, ACM was at that time starting to make proceedings available after conferences, first by mail order and then in its digital library.

Extending the work involved some perspiration. A journal reprinted the paper with minor changes. A new version was solicited for a popular book. Drawing on contributions by Lucy Suchman, Lynne Markus, and others, I expanded the factors from three to eight for a Communications of the ACM article that has been cited more than the original paper.

No false modesty

I was happy with the paper. I had identified a significant problem and worked to understand it. But as noted above, the positive reception followed a series of lucky breaks. Acknowledging this is not being modest. Perhaps I can convince you that I’m immodest: Other papers I’ve written have involved more work and in my opinion deeper insight, but had less impact.

Fifteen years later I revisited the issue that I felt was the most significant—managerial shortsightedness. The resulting paper, which seemed potentially just as useful, was rejected by CSCW and CHI. It found a home, but attracted little attention. Authors are often not the best judges of their own work, but when I consider the differences in the reception of my papers, factors beyond my control seem to weigh heavily.

Ways to contribute

The Moore’s law cornucopia provides diverse paths forward. Your most promising path might be to invent the future by building novel devices. In the early 1980s, we found that that does not always work out. To avoid inventing solutions that the rest of us don’t have problems for, prepare with careful observation and analysis, and hope the stars align.

A second option, which has been the central role of CHI and CSCW, is to improve tools and processes that are entering widespread use.

Third, you can tackle stubborn problems that aren’t fully understood. My 1988 paper was in this category. It is difficult to publish such work in traditional venues. With CSCW now a traditional venue, you might seek a new one.

In conclusion, Pasteur’s advice seems best—prepare, and chance may favor you. Preparation involves being open and observant, dividing attention between focal tasks, peripheral vision, and the rear-view mirror. For me, it was most important to develop friendships with people who had similar and complementary skills. It takes a village to produce a lasting impact.

Jonathan Grudin