Skip to main content

Shirky: Situated Software

Popularity Report

Total Popularity Score: 0
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...

Rank

Public Sticky notes

...software designed in and for a particular social situation or context. This way of making software is in contrast with [...] the Web School [...], where scalability, generality, and completeness were the key virtues

Highlighted by memoriatechnica

Situated Software

Highlighted by colcord

Part of the future I believe I'm seeing is a change in the software ecosystem which, for the moment, I'm calling situated software. This is software designed in and for a particular social situation or context. This way of making software is in contrast with what I'll call the Web School (the paradigm I learned to program in), where scalability, generality, and completeness were the key virtues. I see my students cheerfully ignoring Web School practices and yet making interesting work, a fact that has given me persistent cognitive dissonance for a year, so I want to describe the pattern here, even in its nascent stages, to see if other people are seeing the same thing elsewhere.

Highlighted by ironick

We've always had a tension between enterprise design practices and a "small pieces, loosely joined" way of making software, to use David Weinberger's felicitous phrase. The advantages to the latter are in part described in Worse is Better and The Cathedral and the Bazaar. Situated software is in the small pieces category, with the following additional characteristic -- it is designed for use by a specific social group, rather than for a generic set of "users".

Highlighted by babybjorn

Both groups had the classic problem of notification -- getting a user to tune in requires interrupting their current activity, not something users have been known to relish. Billions were spent on Web School applications that assumed users would bookmark for a return visit, or would happily accept email alerts, but despite a few well-publicized successes like Schwab.com and eBay, users have mostly refused to "check back often."

Highlighted by locative

We constantly rely on the cognitive capabilities of individuals in software design -- we assume a user can associate the mouse with the cursor, or that icons will be informative. We rarely rely on the cognitive capabilities of groups, however, though we rely on those capabilities in the real world all the time.

Highlighted by locative

The suggestion about general web accessibility for the CoDeck interface came in the form of a rhetorical question -- "Why not make it as broadly accessible as possible?" In the Web School, of course, the answer is "No reason", since more users are always A Good Thing, but for CoDeck there were several good reasons for not simply turning their project into a Web video app.

First, the physicalization of the interface, using the gutted BetaMax deck, provides a communal affordance that it is impossible to replicate over the web. Second, since CoDeck serves a tight community, the density of communication among ITP video makers would be diluted by general accessibility. Third, having the video deck in the lounge makes it self-policing; the cohesion of the community keeps it largely free from abuse, whereas a generally accessible and password-free "upload and critique" video site would become a cesspool of porn within hours. Finally, serving a local community maximizes use of free bandwidth on the local network, enabling features that would saddle a public system with crippling costs.

Highlighted by locative

Whatever the WeBe group could do to make ITP group purchases easier, they didn't need to build identity or reputation systems. Because the software was situated in a particular (and particularly tight) community, they got those things for free.

Highlighted by locative

Situated software isn't a technological strategy so much as an attitude about closeness of fit between software and its group of users, and a refusal to embrace scale, generality or completeness as unqualified virtues. Seen in this light, the obsession with personalization of Web School software is an apology for the obvious truth -- most web applications are impersonal by design, as they are built for a generic user. Allowing the user to customize the interface of a Web site might make it more useful, but it doesn't make it any more personal than the ATM putting your name on the screen while it spits out your money.

Highlighted by locative

Situated software, by contrast, doesn't need to be personalized -- it is personal from its inception. Teachers on the Run worked this way. Everyone knew that Paul and Keren built it. You could only rate Clay and Marianne and Tom and the other ITP professors. You didn't even know it even existed unless you were on the ITP mailing list. The application's lack of generality or completeness, in other words, communicated something -- "We built this for you" -- that the impersonal facade of RateMyProfessors.com doesn't have and can't fake.

Highlighted by locative

One of my students mentioned building a web application for his mother, a schoolteacher, to keep track of her class. If you were working alone, unpaid, and in your spare time, there's no way you could make an application that would satisfy the general and complete needs of schoolteachers everywhere. You could make one for your mom, though.

Highlighted by locative