This link has been bookmarked by 39 people . It was first bookmarked on 02 Aug 2006, by Jamie Dinkelacker.
-
19 Aug 09
-
25 Apr 09
-
24 Aug 08
-
14 Aug 08
Kevin Deegan-KrauseClay Shirky's writings about the Internet, including Economics and Culture, Media and Community, Open Source
-
13 Aug 08
-
01 May 08
-
25 Mar 08
-
28 Feb 08
-
04 Jan 08
-
01 Dec 07
Michel Bauwenssoftware 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
-
13 Aug 07
-
Situated Software
-
-
30 Jul 07
-
07 Jul 07
flyingkumquatSource: shirky.com<br>
Date: March 30, 2004<br>
By: Clay Shirky -
08 May 07
-
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."
-
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.
- 5 more annotations...
-
-
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. -
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.
-
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.
-
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.
-
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.
-
-
-
01 May 07
-
27 Mar 07
-
22 Nov 06
-
15 Sep 06
mark van"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
-
02 Aug 06
-
08 Jul 06
-
28 Apr 06
-
08 Feb 05
-
23 Dec 04
-
22 Nov 04
Nick Gallaka Disposable Applications
-
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.
-
-
12 Oct 04
-
17 Aug 04
-
03 Aug 04
-
21 Apr 04
-
05 Apr 04
-
02 Apr 04
Michael GilesAn interesting piece on the business of software.
-
01 Apr 04
-
31 Mar 04
-
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".
-
-
-
...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
-
-
31 Jan 04
M GClay Shirky on small, form-fit applications
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.