February 2010

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 /

the dangers of universal design

20 Feb
in

In a café (Tully's). The thing you throw away most often (coffee cups) are no more distinguished than things you would probably never dispose off here (chinese takeout boxes). This design runs the danger of being designed for everywhere and being good nowhere. Unless, of course, the person trying to figure out whether the item they have in hand already knows what 'compostable' means - in which case the sign privileges cultural knowledge of a category ('compostable'). Or, as in my case, there is a helpful store employee who notices my confusion and helps identify the right bin.

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 /

on context & interaction: an email case study

6 Feb
in

[the following is a response to a thoughtful and provocative essay by the wonderful folks at Johnny Holland, where Stephen Anderson attemps to outline an informatics-based behaviour influence/modification system for email, and I contend, arguing that it's technology, not behaviour, that needs to be fixed. you should read the article, followed by my comment and Stephen's response in order for the following to make sense.]

Stephen writes:

If I was designing a new email platform from the ground up with these things built in, the execution would probably be different– I’d build some of these ideas into the architecture of the system– take a “break away from the conventional ideas that have got us in this mess, ” to quote the article. But, that would introduce a bigger problem: asking people to change their email platform (which is a much, much more daunting challenge than the gaming I describe in the article!)

Yes, its a tricky business1. Create a temporary fix on a broken system and risk cementing it even further, or create an entirely new system and cause upheaval? I don't have any good answers, but I suspect a redesign of email needn't cause much upheaval at all, and in fact might make things even more invisible.

Stephen further comments on context:

Your comment about context seems to me the more challenging one– and a critical consideration.

Context is a tricky business. Paul Dourish has written extensively on context; if you can survive his invented terminology ('technomethodology'?!!) - and 'where the action is' is an excellent read - he has interesting things to say about context, the most consequential of which is that context is created through interaction. What this means for our email quandary is that email software could become much better at knowing what to support by paying attention to its interactions with the user.

To elaborate: most (desktop) software at present is usually state-ful but path-agnostic. If you think of software as something that's a set of states (displaying email, writing email, downloading attachments etc), then interaction is a path through software states. [most web software is actually stateless on the server side, which is why cookies are used to track state on the client side].

Most software doesn't actually track the path through a particular state was reached. For instance, when composing a new email, it doesn't matter if you are replying to an existing email or starting a new thread, whether you were just viewing a project folder or your inbox. The email compose window functions the same way, and what it does and presents to you are largely identical in all cases (if you use the postbox email client, the sidebar always shows all attachments, regardless of who is involved in the email.)

But if email software were to act differently depending on the path taken to the current state, then each state has actually a lot more information to act on, and this makes for opportunities to better understand what the user is doing and adapting accordingly. So, if you were viewing a project folder and composed a new email, that email could get automatically put in the project folder. Or if an email is referred to repeatedly during the course of a day to then suggest showing it in a more persistent view. Or when responding repeatedly to emails from a particular person, to prioritise new mail notifications from that person. (these are just crude examples: actual behaviour would probably have to be a lot more sophisticated)

These are ways to be path-sensitive (and hence interaction-sensitive, and context-sensitive) within an application. But the notion of context extends a little further than that - full context-sensitivity must, I think, consider:

  • interaction paths (whether within or across applications)
  • contemporaneity (what else is being interacted with/running/happening)
  • tendencies (what happens more or less often - this is where most personal informatics focuses, and its the idea behind gmail labs' ‘Bob’ features - ‘Don't forget Bob’ and ‘Got the wrong Bob?’ and Firefox's awesome bar)
  • interaction patterns (sequences that are semantically meaningful, even if not constantly repeated)
  • organizational structures (or information relationships)

[This is not even taking into account the place (say, a meeting room), the people involved (and their relationship to you), and the actual content of the email (or whatever else) itself. Which is a discussion for another day.]

This is where we can return to the central quandary posed by the personal informatics behaviour modification system Stephen proposes: bandage a broken system or force re-learning? I think that this may be a non-issue: if email clients are ‘smarter’ in this sense, we might be able to use the same interface to deliver much more complex behaviour. So, when Stephen writes

For one person, 10 emails a day is the norm. For someone else, juggling several 100 emails a day may present no problem

he's actually thinking of how to make an interface that has to work for different people with different behaviours. But this notion of context-sensitivity suggests interfaces that behave differently depending on, say, the number of emails a day, and so work for the same person when they receive 10 emails a day equally well as when they receive a hundred. (That's within-subject, not across-subject variance, for you psych geeks).

Which also brings us to the issue of whether normative behaviour modification when it comes to email is a good idea in the first place: email use co-evolves with the existence of other collaboration & communication tools, and some of the reasons for behaviour modification (or context-sensitivity, for that matter) might no longer exist, and the associated behaviours might simply cease to be. 

This is a worthy experiment. Are there any interaction designers, inspired engineers or tinkerers who want to take this on? I'm interested in developing this further. 

Notes:
1. Gratuitious arguments using the Chandler Project will be summarily ignored. 

3 comments Link /