Shrinking our turf: Defining CS out of Interaction Design

A member of the SIGCSE mailing list asked the other day for recommendations on teaching a course on “HCI or Interaction Design.” We at Georgia Tech teach a variety of undergraduate and graduate courses like that, and I figured that lots of others do, too. I was surprised at some of the responses:

“Our main theme was that computer scientists should know how to implement interfaces but should not try to design them. Frankly, I’ve not seen any evidence that has changed my mind since then.”

“My personal experience with over 20 years of teaching GUIs is that CS students can be taught to be quite good at the software development aspects of GUIs, that they can be taught to at least understand good interaction design techniques, but that it does not really resonate with them and they do not tend to do it well, and that most of them are hopeless with respect to artistic design.”

Not all of the responses had this attitude that I might call “Not on my turf.” Bill Manaris pointed out that he was part of a workshop that defined an interesting series of courses that aimed to teach HCI and interaction design front-and-center in an undergraduate computer science curriculum. Overall, I got the strong message from the thread that the recommendation was: Computer scientists build software, but don’t expect them to deal well with interactions with people.

My first thought was reflexive. “What?!? We do this all the time!” Georgia Tech’s Computer Science degree explicitly has a Thread on People, Students who study the People thread (which is pretty popular) explicitly take courses in psychology, interface design, as well as how to build user interface software. Our students go on to take jobs where they do design user interfaces, and work as part of teams building and evaluating user interfaces. Not all computer science students at Georgia Tech take the People Thread, but that’s fine. Not all computer scientists study AI, but I haven’t heard anyone argue that AI isn’t part of computer science. There are lots of kinds of computer scientists.

My second thought was more reflective. “Why are we defining CS out of the role of interaction design?” Surely, knowing something about computer science makes for a better interaction designer. Painters start out by studying what their paints and brushes are capable of. All designers first start by exploring the potential of their design materials. Surely we can all agree computer science is connected to interaction design.

I can’t disagree with the experiences described in the messages — I’m sure that the SIGCSE members who posted really did see what they saw. Those experiences say that students who currently go into computer science are not interested in nor have an aptitude for interaction design. I can believe that, but that doesn’t define the discipline. That observation is an outcome of our recruitment efforts, our lack of computer science in high schools (so only some students ever get introduced to CS), and the culture of our field that is mostly white, male, and with less value for interaction with people. The fact that Georgia Tech CS students (and certainly students at other schools, especially those offering the courses that the Manaris workshop designed) can do interaction design, successfully, is an existence proof.

A bigger question for me is, “Why would we want to define computer science out of any design activity involving computing?” What is the value of saying, “Computer scientists can’t do X” for any value of X? Why would we want to shrink our intellectual turf? Wikipedia defines: “Computer science or computing science (abbreviated CS) is the study of the theoretical foundations of information and computation and of practical techniques for their implementation and application in computer systems.” While that isn’t a great definition, “practical techniques” allows for a wide range of activities, including interaction design. Why would we want to give that up and say that that’s not CS?

In the College of Computing at Georgia Tech, we talk about Computing as becoming as large and broad as Engineering. The virtual world can be even larger and more complex than the natural world. Eventually, we expect that there will be recognized Schools of Computing, just as there are recognized Schools of Mechanical, Chemical, Civil, and Electrical Engineering today. Here at Georgia Tech, we already have three Schools: Computer Science (traditional definition), Interactive Computing, and Computational Science and Engineering. All of us faculty in the College of Computing see ourselves as computer scientists.

There are going to be branches of computer science. One of those will include HCI and interaction design. Let’s grow our branches, not prune them off.

I have had several computer science educators tell me over the last year that software engineering is a distinct field from computer science, an attitude that disturbs me greatly since most computer science graduates will end up in some sort of software engineering jobs. I think there is a real purist movement going on right now in computer science.

I tell almost the same to my students: “I teach you programming in the small, not software engineering.” (I assume that programming is the heart of Computer Science.)

Purism (and arrogance) would be to invoke the authority of Dijkstra on the matter and denigrate or dismiss Software Enginering.

Simply, when I open a textbook on Software Engineering, I cannot relate to most of its contents, except the parts about development tools, testing, verification and formal methods. But the bulk of it is about methods for developing large scale software in teams, design patterns, project management, ergonomy of interfaces etc. This is very important, but different from Computer Science, just like electric engineering is.

I don’t think that we can use Computing as an umbrella word and pretend that these differences do not exist or do not matter. (Of course, the name “Computer Science” is problematic in itself, but this is another story.)

(Disclosure: I graduated in Software Engineering and then turned to a PhD in Computer Science.)

I suppose many things nowadays fit the label “design pattern”. My understanding is that design patterns tend to be seen as solutions to a programming problem, when often it is a work around a feature in the programming language itself. This view fits the Software Engineering approach, were practical aspects prime and Java, for example, must be used (visitor pattern, anyone?). A computer scientist would be more interested in the language features that give rise to these design patterns in the first place.

It is not my intention to balkanize the field. Just like CS grew out of electrical engineering, so software engineering grew out of CS. But everything here is useful and complementary. (I forgot to cite above the important issue of software maintenance.)

At the schools where I have taught, the vast majority of CS majors have ended up in software engineering-related positions, either directly out of undergrad, or after a masters degree. Are we willing to say that their aspirations are not part of our field? If so, we software engineering types are going to have to start our own programs – and where do you think the students will go?

It would be a shame to split the field because computer science is the core of software engineering. A working software engineer needs to know data structures and algorithms, database theory (although I am hearing people argue that databases are also not part of computer science), operating systems, and many other areas that have traditionally been computer science. The software engineering material – such as good design, teamwork, and testing methods – are really a layer that sits on top of computer science. It just happens to be a layer that is very relevant to the aspirations of most of our students.

If you consider a problem-solving strategy like `divide and conquer’ as a design pattern, then I would say that it CS, but it is abstract enough to be claimed by other fields, like cognitive psychology etc.

I’m reminded of what Newell, Perlis, and Simon wrote in “What is Computer Science?”:

Phenomena define the focus of a science, not its boundaries. Many of the phenomena of computers are also phenomena of some other science.

and (earlier)

The phenomena of all sciences change over time; the process of understanding assures that this will be the case. Astronomy did not originally include the study of interstellar gases; physics did not include radioactivity; psychology did not include the study of animal behavior. Mathematics was once defined as the “science of quantity.”

In the context of HCI, for example, there’s the classic The Psychology of Computer Programming from 1971, when a significant proportion of the people who used computers were also the people who built and programmed them. HCI has changed a lot since then, and it’s expanded so much that nowadays there are probably as many non-computer scientists as computer scientists working in the field. This is a case of the shift that Newell et al. were talking about, I think. But it’s too early to set boundaries, to say, “This is computer science but this other thing is not.”

Just as many colleges now demand that their technical majors take a certain percentage of liberal arts courses, CS majors should be required to take at least one course in interface design. These days, a technical education of any kind should require flexibility of thought.

I think its premature to decide that something is not Computer Science, and also risky. I worked as an HCI person in Software Engineering at Bell Labs. I used ethnographic techniques to understand the human processes used to construct software systems and how to make them more effective. Then I went to work as an HCI person in Xerox PARC’s Computer Science Lab. I used ethnographic techniques to pursue problems below the application layer of the machine, for example usable security and networking.

To me computers are human-built and human-used machines, and that is part of the phenomena under investigation. The outcomes of which can result in changing the machine itself or changing the way that people interact around, with, and through the machine. I may draw on disciplines from outside of Computer Science (to find problems that push on the machine in new ways, methods for tackling problems within Computer Science), but the way I see it is that the phenomenon under investigation in Computer Science is the machine. I think we should own that phenomena in its entirety and I do not understand why anyone would want to hand over parts of the machine to any other discipline. Or, how, precisely that would be done.

I have never thought of myself as anything other than a Computer Scientist. Rather I’ve always thought that the relative youth of Computer Science was an opportunity, a license to creatively pursue a range of problems before we get trapped in ways of knowing that overly constrain us. While I have other interests, I have a real passion for combining parts of the field, which is why I’ve spent a lot of time working HCI into other subdisciplines of Computer Science.

“Our main theme was that computer scientists should know how to implement interfaces but should not try to design them. Frankly, I’ve not seen any evidence that has changed my mind since then.”

Whatever else you might think about the relation between HCI and CS…this statement is ridiculous.

I’m presuming that the shift from “should know how” to “should not try” isn’t significant, i.e., not a reflection on the capabilities of computer scientists per se. The suggestion that computer scientists should not be aware of the design requirements of something within their implementational purview is nonsense.

(And I presume we me more than “mere” implementation.)

For example, one needs to understand the effect of perceived performance on acceptibility to understand why e.g., a GC approach which consumes more overall time (but has imperceptible pauses) is far superior in certain cases to one with maximal throughput.

Mark, I was thinking some about this question the other day. I think there’s a powerful (if somewhat long) positive case to be made for expanding CS turf from a historical perspective.

If you look at academia since (at least) the professionalization of science in the mid-19th century up to about the middle of the 20th-century, the major trend was the refinement of large, broad disciplines into increasingly more specific sub-disciplines. For instance the development of relationships like “Science contains Physics, which in turn contains Particle Physics.” In my mind, I think of this as being very Victorian in conception: Let’s enumerate, categorize and taxonomize (academic) thought, so that we can nicely and neatly display our collection of knowledge in curio cabinets.

However, if you look at a lot of academic disciplines that have sprung up in the second half of the 20th century, this kind of historical narrative—of progressive refinement of the hierarchy of knowledge—is a very poor description. Computer Science, which grew neither entirely out of Electrical Engineering or Mathematics departments is a poster child for these new areas of knowledge: cross-disciplinary fields.

We don’t have to look at academia as a hierarchy of knowledge. If we want, Computer Science can be about anything and everything that has any connection to computers and computation.

Imagine we’re 50 years in the future. What will be the role of Computer Science in academia? Will we be providing basic foundation courses to students in other disciplines where all of the innovation is happening? (e.g. many Math departments today) or will we also be doing the innovating ourselves? We all believe that tomorrows innovation is going to involve computers and computational thinking in a deep way. But if we push all of the cross-disciplinary startup disciplines doing that innovation out of Computer Science today, they’ll just go start their own disciplines that will out innovate us tomorrow. Why would we possibly want to do that? Haven’t we learned anything from our own history?

I got a PhD in computer science, taught for 4 years in an uncomfortable joint position between a EE and CS department that did not talk to each other, then for almost 2 decades in a computer engineering department (which covered anything to do with “designing digital systems that work”). The CS kept wanting to redefine computer engineering to be pure hardware and CS to be pure software and theory, but the computer engineering faculty (an equal mix of CS and EE degrees) were not buying that partition. The applied discrete math course ended up being taught by computer engineering, because the CS folks didn’t want to step outside their comfort zone—same for technical writing.

Eventually a bioinformatics group was formed (2 computer engineering faculty and one CS faculty) and that lead to a new department, with all three of us as founding members. The bioinformatics grad degree has widened now to “biomolecular engineering and bioinformatics” and has more biologists than computer scientists on the faculty.

In some ways, it is good that CS departments are such purists, because it allows new fields to start without the overwhelming baggage of a huge, very slow-moving department, but at the cost of having to create a new department to do anything new. I was lucky in that the computer engineering department had a much broader view of the field and was willing to host the bioinformatics degree for the 3 years it took to get approval for a new department through the bureaucracy.