topic: systems

Talking Carls and the Vegetable Principle

22 Feb
in

A snaggle of Talking Carls

At a lunch the other day, someone introduced the Talking Carl app for the iPhone, which has the delightful feature of repeating what it hears (after a slight delay) in a suitably humour-inducing manner. Carl (who is essentially a simple sound processor/modulator) can also be tapped or poked to produce sounds congruent with his character. This being a meeting full of designers, iPhones were promptly produced, Carls downloaded, and a chorus ensued.

What the designers did not probably anticipate was the way a number of people at the table decided to put their Carls together as in the photo above, thus creating a self-sustaining feedback loop with unpredictable sounds, and consequently, much experimentation. Two things coincided to create this happy raucuous system of Carls: the fact that Carls 'speak' after a slight delay, allowing a person to 'activate' their Carl and having time to move it into position; and the fact that the iPhone's microphone & speaker are at the same end of the phone.

This is a moment of emergence, wherein the ant becomes the anthill. Here, a set of people have taken objects (for that is what running apps are, after all) designed for single-person use, and combined them to create a group behaviour that is completely different from the individual one. Insofar as this is much like how Unix is constructed or how computer software collaborates, this is nothing new. However, in that this act of composition is being performed without any acts of construction (programming), this use of digital interactive objects as tools for creating yet other kinds of interaction - because the Carl you engage with alone is not the Carl you 'prime' for the symphony - is exceedingly rare (because rarely designed to afford). The symphonic Carl is not mediating the interactions between people, but is a tool with which people have different kinds of interactions, and a tool which enriches interactions.

Two lessons: first, that it's better to create tools for experiences instead of trying to create experiences (i.e. give me the vegetables, not the processed soup). Second, that technologies (through use) can interact to create unpredictable outcomes, which might not always be as benign as our lunchtime cacophony.

1 comment Link /

reified categories and process structures

15 Feb
in

antique ticket sale counter, still in use a ticket counter held by a San Francisco MUNI ticket assistant/checker

The mechanical ticket counters above are worked by an old gentleman who waits at a MUNI tram stop in the morning and hands out tickets to commuters before their tram arrives, so as not to overload the driver and create a payment queue on the steps of the vehicle. I didn't have time to take a detailed set of photographs, but it appears that one of the counters is used to track normal tickets, and the other to track (cheaper) ones sold to seniors.

Note the construction: two separate devices lashed together and to a roughly machined acrylic sheet with rubber-bands and cable ties. Also note how the counter buttons are on the same side (because they're identical), necessitating placing one below the other so as not to block access, and forcing left-handed use; presumably they were not designed for this use by what appears to be the International Register Co. This is either a hack by the ticket seller to make accounting easier, or something issued by the transportation company and

  1. fixed later by the ticket seller or someone like him
  2. in the original state of construction, but conceived and constructed to accomodate new categories (seniors?) or roles (ticket sellers at the bus stands to help increase throughput for an increased commuter population?)
  3. in the original state of construction and conceived & constructed to a plan (“here's how we'll help our new ticket sellers keep track of how much money they should have at the end of their shift”)

In any case, the categories in use (‘adult’ and ‘senior’) have become reified in the construction of this equipment, which is only necessary because there are two categories. If there was only one kind of ticket, the ticket seller could simply note the serial number of the first ticket and multiply the ticket price by the difference from the last serial number left at the end of the shift (with minor procedural modifications in the case of multiple ticket books having been consumed). With two categories, however, accounting becomes a little harder, especially when people queue up for tickets fast. Note how the ticket seller has a cache of tickets cut to the correct time cut-offs to make it easy to hand out tickets quickly.

While this is a technology for accounting, it is not necessarily a technology for accountability (whereas a electronic ticket vending machine could do both). One would guess that fully electronic ticketing in the Promised Land of Ubicomp would obviate the need for this hack. In case this is a grassroots innovation, it shows how policies from above collide with the messiness of processes as they are actually carried out, making people create work-arounds in response.

The lesson? Categories & processes interact: if you create or change categories, you might possibly be affecting processes downstream somewhere, and someone might have to invent a way of dealing with it. So before you create personas & segmentations, pause and think about what they'll make people do, and what they are for: accounting or accountability?

(Now would be a good time to read Geoffrey Bowker & Susan Leigh Star's Sorting Things Out: Classification & its Consequences. Complex, detailed, but much recommended, especially if you want an interesting perspective on why health insurance costs are so high).

Link /
Syndicate content