Abstract
In the late 1980s, software went through a major transition. Before about 1985, the primary goal of software was making it possible to solve a problem, by any means necessary. Do you need to punch cards with your input data? No big deal. A typo on one card means you have to throw it away and start over? No problem. Humans will bend to the machines, like Charlie Chaplin in Modern Times. Suddenly with personal computers the bar was raised. It wasn't enough just to solve the problem: you had to solve it easily, in a way that takes into account typical human frailties. The backspace key, for example, to compensate for human frailty, not to mention menus, icons, windows, and unlimited Undo. And we called this usability, and it was good. Lo and behold, when the software industry tried to hire experts in usability, they found that it was a new field, so nobody was doing this. There was this niche field in psychiatry called ergonomics, but it was mostly focused on things from the physical world, like finding the optimal height for a desk chair. Eventually usability came into its own as a first-class field of study, with self-trained practitioners and university courses, and no software project could be considered complete without at least a cursory glance at usability. We're about to undergo a similar transition. As soon as the Internet happened, software stopped being solely about computer-to-human interaction and started being about human-to-human interaction. We had new applications like the Web, email, instant messaging, and bulletin boards, all of which were about humans communicating with one another through software. Now, suddenly, when you create software, it isn't sufficient to think about making it possible to communicate; you have to think about making communication socially successful. In the age of usability, technical design decisions had to be taken to make software easier for a mass audience to use; in the age of social software, design decisions must be taken to make social groups survive and thrive and meet the goals of the group even when they contradict the goals of the individual. A discussion group designed by a usability expert might be optimized to make it easy to post spam about Viagra. But in social software design it's pretty obvious that the goal is to make certain things harder, not easier, and if you can make it downright impossible to post spam, you've done your job. Features need to be designed to make the group successful, not the individual. Today, hardly anybody really studies how to design software for human-to-human interaction. The field of social software design is in its infancy. In fact, we're not even at the point yet where the software developers developing social software realize that they need to think about the sociology and the anthropology of the group that will be using their software, so many of them just throw things together and allow themselves to be surprised by the social interactions that develop around their software. Clay Shirky has been a pioneer in this field, and his talk A Group Is Its Own Worst Enemy will be remembered as a watershed in the widespread realization that in this new era, sociology and anthropology are just as crucial to software design as usability was in the last. - Ed.
Original language | English (US) |
---|---|
Title of host publication | The Best Software Writing I |
Publisher | Apress |
Pages | 183-209 |
Number of pages | 27 |
ISBN (Print) | 1590595009, 9781590595008 |
DOIs | |
State | Published - 2005 |
ASJC Scopus subject areas
- General Computer Science